ownCloud, как утверждает Википедия — это Свободное и открытое веб-приложение для синхронизации данных, расшаривания файлов и удалённого хранения документов в «облаке». И, как мне кажется, довольно интересное решение для организации собственного домашнего облака.
Однако, ownCloud, устанавливающийся в виде плагина в системе FreeNAS, да и просто из коробки, имеет ряд недостатков, от которых хотелось бы избавится даже при использовании дома:
- Во-первых, устанавливается в связке с SQLite, что подходит только если у вас небольшое кол-во файлов и пользователей, и абсолютно не подходит, если вы планируете синхронизацию с помощью клиента. У меня же хранилище уже расползлось почти на 5Tb и установленный таким образом ownCloud просто отказывался видеть часть файлов. Да и без синхронизации отдача от облака не велика. Заменим базу данных на MariaDB.
- Во-вторых, отсутствует работа по https, а мне совсем не нравится мысль о том, что кто-то может перехватить мои файлы. Включим https.
- В-третьих, начисто отсутствует защита от банального подбора пароля методом брутфорса. Защитимся от брутфорса с помощью fail2ban.
- В-четвёртых, мне лень часто просматривать логи на предмет взлома, но очень хочется оперативно узнавать о таких попытках. Настроим push-оповещения о попытках подбора пароля с помощью сервиса pushover.net.
Хочу сразу оговориться. Я не являюсь IT-специалистом, я всего лишь менеджер проектов в одном из российских системных интеграторов, а данная «инструкция» родилась в попытках настроить все 4 указанных пункта на своей домашней системе, FreeNAS работающей из-под Esxi. Инструкция написана новичком для новичков, поэтому если где-то есть явные ляпы или ошибки в командах и конфигах, то прошу указать их в комментариях.
Все настройки будем делать из консоли, ручками, максимально приближено к тому, как это, как мне видится, делают «взрослые» айтишники.
1 Подготовка Jail для ownCloud
1.1 Создаём Jail
Данный шаг описывать не буду. Если у вас получилось установить FreeNAS и он у вас работает, то проблем с данным шагом у вас быть не должно. Создание первого Jail может занять довольно продолжительное время.
1.2 Открываем доступ по SSH к данному Jail
Удобнее всего дальнейшую настройку выполнять не через web-терминал, а через полноценную программу-терминал. Например, putty. Для этого откроем доступ по SSH к нашему Jail и создадим нового пользователя, от которого и будем проводить дальнейшую настройку.
Выбираем в web-интерфейсе FreeNAS созданный нами Jail и нажимаем внизу кнопку Shell.
В веб-консоли Jail вводим:
# sysrc sshd_enable="YES"
Запускаем демон для работы ssh:
# service sshd start
Создаём пользователя от имени которого будем потом настраивать нашу систему. Пользователь будет иметь привилегии superuser, для чего мы включим его в группу wheel.
# adduser
Usrname: Новый пользователь от имени которого мы будем производить все манипуляции в терминале. Вводим, например, superstepa.
Full name: Полное имя этого пользователя. Вводим, например, Dyadya Stepa Policeman.
Uid (Leave empty for default): Ну раз просят оставить пустым, то так и сделаем. Смело жмём Enter.
Login group [superstepa]: Мы хотим чтобы наш пользователь обладал всеми правами местного администратора — superuser, а следовательно включаем его в группу wheel.
Login group is wheel. Invite superstepa into other groups? []: Нажимаем Enter.
Login class [default]: Жмём Enter.
Shell (sh csh tcsh git-shell nologin) [sh]: Оставляем по-умолчанию sh. Просто жмём Enter.
Home directory [/home/superstepa]: И опять Enter.
Home directory permissions (Leave empty for default): И снова Enter.
Use password-based athentications? [yes]: Хотим чтобы аутентификация этого пользователя проходила по паролю? Конечно да! Жмём Enter.
Use an empty password? (yes/no) [no]: Мы же за безопасность и не хотим чтобы у нового пользователя с правами superuser был пустой пароль. А значит очередной раз жмём Enter.
Use a random password? (yes/no) [no]: Я просто уверен, что придуманный нами пароль самый надежный. И мы хотим использовать именно его. А следовательно Enter.
Enter password: Ага, а вот и он. Вводим свой пароль.
Enter password again: Вводим его снова.
Lock out the account after creation? [no]: Нет, блокировать этот аккаунт не нужно. Просто Enter.
OK? (yes/no): Проверяем всё ли верно и если да, то пешем yes.
Add another user? (yes/no): Других пользователей нам не надо. No.
2 Установка и подготовка к работе ownCloud
Присоединяемся с помощью программы-терминала к нашему Jail.
Вводим имя созданного нами пользователя и его пароль.
На приглашение командной строки $ пишем su. Теперь приглашение командной строки сменится на что-то типа root@ownCloud:/usr/home/superstepa #, а все наши команды будут выполняться от имени superuser.
Для упрощения, приглашение командной строки я буду обозначать символом #, а мои комментарии, которые вводить не надо, буду начинать с //.
2.1 Устанавливаем необходимые пакеты
Сначала обновляем текущие пакеты:
# pkg upgrade
Затем устанавливаем необходимые для работы ownCloud пакеты (на все возникающие вопросы отвечаем yes):
# pkg install mariadb100-server php56-extensions php56-bz2 php56-curl php56-exif php56-fileinfo php56-gd php56-mbstring php56-mcrypt php56-pdo_mysql php56-openssl php56-zip php56-zlib pecl-APCu pecl-intl
Для того, чтобы включить работу по https, собираем с нужными нам пакетами, а затем и устанавливаем из портов, web-сервер nginx:
# portsnap fetch extract // скачиваем копию коллекции портов, это может занять много времени
# cd /usr/ports/www/nginx && make config // конфигурируем и собираем web-сервер nginx
В процессе сборки убеждаемся, что выбраны следующие пакеты:
IPV6
HTTP
HTTP_CACHE
HTTP_DAV
HTTP_FLV
HTTP_GZIP_STATIC
HTTP_PERL
HTTP_REWRITE
HTTP_SSL
HTTP_STATUS
WWW
# make install
2.2 Создаём самоподписанные ключи и сертификаты
# cd /usr/local/etc/nginx/
Создаём корневой ключ server.key (алгоритм шифрования des3, длиной 1024 bit):
# openssl genrsa -des3 -out server.key 1024
Для этого система дважды попросит ввести парольную фразу. Придумываем её и вводим.
Создаём корневой сертификат:
# openssl req -new -key server.key -out server.csr
Отвечать на вопросы можно как угодно. Главное:
— на первый запрос Enter pass phrase for server.key ввести правильный пароль от корневого ключа созданного ранее,
— обязательно ответить на все вопросы, иначе клиент ownCloud в дальнейшем может отказаться от синхронизации файлов,
— запомнить введённые данные, чтобы в дальнейшем можно было легко вспомнить, что сертификат именно Ваш,
— запомнить пароль введённый на вопросе A challenge password []:.
Можно изменить срок действия нашего сертификата, например до 10000 дней, добавив в команду выше аргумент -days 10000.
# cp server.key server.key.org //копируем наш ключ
# openssl rsa -in server.key.org -out server.key //удаляем пароль из ключа
# openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt // Генерируем сертификат
2.3 Включаем автозапуск web-сервера, PHP и базы данных
# sysrc nginx_enable="YES" php_fpm_enable="YES" mysql_enable="YES"
2.4 Устанавливаем редактор для удобного редактирования конфигов
Всё-таки мы еще «маленькие» и пользоваться предустановленным редактором vi нам еще сложновато, поэтому поставим простенький редактор nano (на все возникающие вопросы отвечаем yes).
# pkg install nano
Shared object «libiconv.so.2» not found, required «libgmoudle-2.0.so.0
Для того чтобы это исправить выполним всего 2 команды:
# pkg delete -f gettext
# pkg upgrade
2.5 Корректируем конфиг веб-сервера nginx
Как настоящие администраторы, всегда перед корректировкой конфига делаем его копию, чтобы в случае возникновения проблем всегда можно было откатиться назад:
# cp /usr/local/etc/nginx/nginx.conf /usr/local/etc/nginx/nginx.old
И редактируем файл конфига:
# nano /usr/local/etc/nginx/nginx.conf
worker_processes 2;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
access_log logs/access.log main;
sendfile off;
keepalive_timeout 65;
gzip off;
ssl_certificate /usr/local/etc/nginx/server.crt; // для того чтобы работал https
ssl_certificate_key /usr/local/etc/nginx/server.key; // для того чтобы работал https
server {
listen 443 ssl; // для того чтобы работал https
root /usr/local/www;
location = /robots.txt { allow all; access_log off; log_not_found off; }
location = /favicon.ico { access_log off; log_not_found off; }
location ^~ /owncloud {
index index.php;
try_files $uri $uri/ /owncloud/index.php$is_args$args;
client_max_body_size 512M; // максимальный размер файла для загрузки
location ~ ^/owncloud/(?:\.|data|config|db_structure\.xml|README) {
deny all;
}
location ~ \.php(?:$|/) {
fastcgi_split_path_info ^(.+\.php)(/.*)$;
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
include fastcgi_params;
fastcgi_param MOD_X_ACCEL_REDIRECT_ENABLED on;
}
location ~* \.(?:jpg|gif|ico|png|css|js|svg)$ {
expires 30d; add_header Cache-Control public;
}
}
}
}
Выход из редактора по нажатию Ctrl+X. Не забываем при выходе сохранять изменения.
2.6 Корректируем конфиг php
# cp /usr/local/etc/php.ini-production /usr/local/etc/php.ini
# nano /usr/local/etc/php.ini
always_populate_raw_post_data = -1 // не забываем убирать ; в начале строки
date.timezone = Europe/Moscow // либо указать Ваш часовой пояс
cgi.fix_pathinfo=0
upload_max_filesize = 512M // либо указать максимальный размер файла доступный для загрузки в наше облако
post_max_size = 512M // либо указать максимальный размер файла доступный для загрузки в наше облако
2.7 Корректируем php-fpm.conf:
# cp /usr/local/etc/php-fpm.conf /usr/local/etc/php-fpm.old
# nano /usr/local/etc/php-fpm.conf
listen = /var/run/php-fpm.sock
listen.owner = www // не забываем убирать ; в начале строки
listen.group = www
env[PATH] = /usr/local/bin:/usr/bin:/bin
2.8 Корректируем /var/db/mysql/my.cnf:
# cp /var/db/mysql/my.cnf /var/db/mysql/my.old
# nano /var/db/mysql/my.cnf
[server]
skip-networking
skip-name-resolve
innodb_flush_method = O_DIRECT
skip-innodb_doublewrite
innodb_flush_log_at_trx_commit = 2
innodb_file_per_table
expire_logs_days = 1
2.9 Запускаем веб-сервер nginx, PHP, MariaDB и настраиваем базу данных:
# service nginx start && service php-fpm start && service mysql-server start
Если всё было сделано верно, то всё запустится без ошибок и можно попробовать пройти в браузере по адресу https://<YOUR_JAIL_IP>.
Нам напомнят, что сертификат у нас самоподписанный, но приняв его мы попадём на страницу с надписью 403 Forbidden.
Настраиваем базу данных MariaDB:
# mysql_secure_installation
Set root password? [Y/n]: Вводим Y.
New password: Вводим новый пароль root.
Re-enter new password: Повторяем введённый ранее пароль.
На все остальные вопросы отвечаем Y, либо просто жмём Enter
Настраиваем базу данных ownСloud введя свои значения, где owncloud — название базы, ownclouduserdb — имя пользователя для работы с базой, а passwordownclouddb — пароль этого пользователя:
# mysql -u root -p
CREATE DATABASE owncloud;
GRANT ALL PRIVILEGES ON owncloud.* TO 'ownclouduserdb' IDENTIFIED BY 'passwordownclouddb';
FLUSH PRIVILEGES;
quit;
2.10 Скачиваем и устанавливаем актуальную версию OwnCloud
По ссылке смотрим текущую актуальную версию ownCloud. На момент написания статьи это была версия 8.0.2.
Скачиваем архив, где вместо 8.0.2 указываем текущую актуальную версию:
# fetch "http://download.owncloud.org/community/owncloud-8.0.2.tar.bz2"
Разархивируем:
# tar jxf owncloud-*.tar.bz2 -C /usr/local/www
Удаляем ненужный теперь нам архив:
# rm owncloud-*.tar.bz2
Назначаем системных владельцев (пользователя и группу) ownCloud:
# chown -R www:www /usr/local/www/owncloud /mnt/files
2.11 Создаём задание в crone:
# setenv EDITOR nano // для редактирования будем использовать установленный нами редактор nano
# crontab -u www -e
Прописываем в нём:
*/15 * * * * /usr/local/bin/php -f /usr/local/www/owncloud/cron.php
Если всё было прописано верно, то мы получим следующее системное сообщение:
crontab: installing new crontab
Идём теперь в браузере по адресу https://<YOUR_JAIL_IP>/owncloud и производим там последние настройки. Не забываем, что нам надо изменить тип применяемой базы данных, а для этого нажмём Хранилище и база данных и выберем наш тип базы: MySQL/MariaDB.
Имя пользователя: Имя администратора нашего облака. Например, Stepanadministratovich.
Пароль: Пароль администратора.
Каталог с данными: Я предпочитаю /mnt/files/. В этот каталог я потом монтирую существующие у меня Volumes хранилища FreeNAS. Если надо объяснить как, то пишите в комментариях.
Пользователь базы данных: Мы его создавали ранее на шаге 2.9 ownclouduserdb.
Пароль базы данных: Также назначали ранее на шаге 2.9 passwordownclouddb.
Название базы данных: Всё тот-же шаг 2.9 owncloud.
Наш ownCloud уже готов к работе.
3 Дополнительные настройки
3.1 Просим поисковых роботов (Yandex, Google и т.д.) не индексировать наш сайт:
# ln -s /usr/local/www/owncloud/robots.txt /usr/local/www
4 Защита от подбора пароля
4.1 Устанавливаем fail2ban из портов:
# cd /usr/ports/security/py-fail2ban
# make install clean
папка action.d — содержит файлы действий
папка filter.d — файлы фильтров
файл fail2ban.conf — основной файл конфигурации
файл jail.conf — файл настройки защиты конкретных сервисов
4.2 Настраиваем логирование в ownCloud:
Создаём файл в который будут писаться логи ownCloud при неудачной попытке входа:
touch /var/log/owncloud-acces.log
Файл должен быть доступен для записи пользователю www:
# cd /var/log/
# chown www:www owncloud-acces.log
Включаем логирование неудачных входов в ownCloud:
# nano /usr/local/www/owncloud/config/config.php
'logtimezone' => 'Europe/Moscow', // или другой Ваш часовой пояс
'logfile' => '/var/log/owncloud-acces.log',
'loglevel' => '2',
'log_authfailip' => true,
Затем выполним в консоли команду:
# nano /var/log/owncloud-acces.log
Если всё сделано правильно, то в файле появятся записи вида:
{»reqId":«es09787k250rv52fu0iu44124z494687»,«remoteAddr»:«192.168.1.1»,«app»:«core»,«message»:«Login failed: 'Admin' (Remote IP: '192.168.1.10', X-Forwarded-For: '')»,«level»:2,«time»:«2015-04-04T18:59:50+03:00»}
4.3 Создаём файл фильтра для fail2ban:
nano /usr/local/etc/fail2ban/filter.d/owncloud.conf
[Definition]
failregex={"app":"core","message":"Login failed: user '.*' , wrong password, IP:<HOST>","level":2,"time":".*"} // для версий ownCloud<= 7.0.1
{"app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>', X-Forwarded-For: '.*'\)","level":2,"time":".*"} // для версий ownCloud=7.0.2-7.0.5
{"reqId":".*","remoteAddr":"<HOST>","app":"core","message":"Login failed: .*","level":2,"time":".*"} // для версий ownCloud>=8
По сути это парсер, который во всей той служебной информации, которую ownCloud пишет в свой лог, должен найти ip-адрес того, кто пытался подобрать пароль на вход. Те элементы, что никогда не меняются в записях лога — указаны тут в явном виде. Те, что меняются — заменены на *. Ну а собственно ip-адресс, который мы ищем, заменён на переменную <\HOST>\.
4.4 Редактируем файл настроек сервисов:
# cp /usr/local/etc/fail2ban/jail.conf /usr/local/etc/fail2ban/jail.old
# nano /usr/local/etc/fail2ban/jail.conf
[owncloud]
enabled = true
filter = owncloud
port = https
logpath = /var/log/owncloud-acces.log // путь к файлу логов ownCloud, который указывали на шаге 4.2
ignoreip = 192.168.1.59 // здесь указываются ip-адреса которые банится не будут
maxretry = 2 // количество неудачных попыток до бана
bantime = 86400 // время бана в секундах
findtime = 600 // время в течение которого введено необходимое для бана к-во попыток в секундах
action = bsd-ipfw // указываем какие файлы действий выполнять
pushover-notify // описание данного файла действий будет ниже по тексту статьи, вводить здесь название данного действия необходимо с новой строки и после нажатия клавиши Tab.
4.5 Проверяем работает ли наш фильтр и может ли он найти в логе ownCloud нужные строки с попытками неудачного входа:
# fail2ban-regex /var/log/owncloud-acces.log /usr/local/etc/fail2ban/filter.d/owncloud.conf
Если всё верно, то внизу выдачи будет строка вида:
Lines: 2 lines, 0 ignored, 2 matches, 0 missed [processed in 0.0 sec]
4.6 Настраиваем действия, которые будут производится в случае неудавшихся попыток входа:
# cp /usr/local/etc/fail2ban/action.d/bsd-ipfw.conf /usr/local/etc/fail2ban/action.d/bsd-ipfw.local
# nano /usr/local/etc/fail2ban/action.d/bsd-ipfw.conf
Оставляем в нём всё по умолчанию. В нём уже прописано правило, что при отправке в бан, ip-адрес добавляется в table(1) файервола ipfw:
actionban = ipfw table \<table\> add \<ip\>
Добавляем в сам файервол ipfw правило, блокирующее все ip-адреса, находящиеся в таблице table(1), т.к. пока нет никаких правил у файервола что делать с адресами из этой нашей таблицы(1):
# ipfw add 1 deny all from table\(1\) to me
ipfw list //Просмотреть имеющиеся правила
ipfw delete 13 //Удалить правило 13
ipfw add 14 <правило> //Добавить правило 14
ipfw table 1 add 192.168.1.5 //добавление в таблицу
ipfw table 1 add 192.168.1.0/24 //добавление в таблицу подсеть
ipfw table 1 list //посмотреть что в таблице
ipfw add deny ip from table(10) to me //Всё с таблицы 50 ко мне
ipfw table 1 delete 192.168.1.5 //удаляем из таблицы
ipfw table 1 flush //чистим всю таблицу
4.7 Запускаем fail2ban:
Перед запуском создадим для fail2ban файл описывающий действие pushover-notify, о котором была уже речь выше и о котором мы ещё поговорим:
#touch /usr/local/etc/fail2ban/action.d/pushover-notify.conf
Прописываем автостарт fail2ban в /etc/rc.conf:
# sysrc fail2ban_enable="YES"
И запускаем его:
# /usr/local/etc/rc.d/fail2ban start
Если всё сделали правильно, то он запустится, если нет — разбирайтесь где ошибка. Если запустился, то проверяем на бан: заходим со стороннего ip-адреса с неправильным паролем. Должно забанить на время, которое мы указали в файле jail.conf.
fail2ban-client status // Посмотреть какие джейлы активны
fail2ban-client status owncloud // Посмотреть статус конкретного джейла, где owncloud - это имя нашего джейла
fail2ban-client set owncloud unbanip MYIP // Удалить конкретный ip-адрес из бана, где MYIP - этот самый ip-адрес
Собственно теперь у нас есть ownCloud, работающий на «взрослой» базе данных по https с защитой от подбора паролей.
Почти всё, но давайте ещё добавим уведомление о блокировке при неправильном вводе пароля в виде push-уведомлений на наш телефон.
5 Уведомление о блокировке ip-адреса
Для push-уведомлений будем использовать сервис pushover.net. Я думаю Вам теперь не составит труда разобраться с его API. Но если возникнут сложности, то пишите в комментариях и я добавлю соотвествующее описание по работе с данным сервисом.
5.1 Настраиваем уведомления pushover о неудачных попытках входа и бане:
# nano /usr/local/etc/fail2ban/action.d/pushover-notify.conf
[Definition]
actionstart=
actionstop=
actioncheck=
actionban = url -k https://api.pushover.net/1/messages.json -F token=<token> -F user=<user> -F title="ownCloud Alarm" -F message="<ip> is banned after <failures> attemts against <name>"
actionunban = url -k https://api.pushover.net/1/messages.json -F token=<token> -F user=<user> -F title="ownCloud Alarm" -F message="<ip> is unbanned"
[Init]
name = default
token = [API Token/key (application key)]
user = [User key]
, где [API Token/key (application key)] и [User key] соответствующие значения с сайта pushover.net.
Перезапускаем fail2ban
# /usr/local/etc/rc.d/fail2ban restart
Проверяем работу уведомлений выполнив несколько неудачных попыток входа в ownCloud:
Вот и всё. Не забываем пробросить на роутере порты 80 и 443 для доступа к ownCloud.
И да, для большей безопасности можно заменить стандартные порты на что-то более экзотическое.
Комментарии (47)
Meklon
06.04.2015 13:30+1Благодарю. Кстати, тем, кто обновляется до 8.02 c nginx. Процесс обновления становится колом из вебморды с ошибкой CSRF attack. Connection will be closed.
Нужно все делать через консоль.
sudo -u www-data php occ upgrade
Я сегодня долго ругался. Не забывайте бэкапить базу данных, /var/www/owncloud и data-директорию. Зачастую не все так гладко проходит. Лучше потестить.
roller
06.04.2015 14:40Как бы так авторизовать клиента более надежно чем через логин пароль?
Вообще, параноя возобладала и пока что обращения к ownCloud завернул в ssh-туннель с пробрасыванием порта на localhost.
istui
06.04.2015 15:18посмотрите авторизацию сертификатом.
Не уверен, что мобильный клиент это сможет сделать, но в браузере входить сможете без проблем
ssl_client_certificate /etc/nginx/client-ca.crt;
ssl_verify_client on;
и никто, кроме владеющих сертификатом от client-ca, доступ не получитroller
06.04.2015 15:42В том и вопрос что мне нужен не мобильный клиент и не браузер, а чтобы их родной клиент ходил с сертификатом на ownCloud.
https://github.com/owncloud/client/issues/69istui
06.04.2015 15:49ну тогда (если речь идет не о мобильном клиенте) можно придумать костыль в виде nginx на локальной машине с вот такой директивой.
При необходимости, win32-версия nginx вполне хорошо переносится на флешке.
ACooper Автор
06.04.2015 22:32Мне на днях попалась такая вещь, как Google Authenticator.
Сразу родилась мысль о возможности её использования.
Поиск в google подсказал, что уже есть соответствующее стороннее расширение.
Попробую его на выходных.
fkvf
06.04.2015 15:32Во-первых, устанавливается в связке с SQLite, что подходит только если у вас небольшое кол-во файлов и пользователей, и абсолютно не подходит, если вы планируете синхронизацию с помощью клиента. У меня же хранилище уже расползлось почти на 5Tb и установленный таким образом ownCloud просто отказывался видеть часть файлов. Да и без синхронизации отдача от облака не велика.
А можете показать логи из sqlite/owncloud-client по поводу проблем синхронизации?
У меня чуть меньше 1 тб и таких проблем не наблюдается.ACooper Автор
06.04.2015 21:59К сожалению логов с sqlite не осталось. Про проблемы с синхронизацией честно предупреждают при первом входе в систему (см. скриншот в пункте 2.11).
У меня же проблема была в следующем: после установки ownCloud в качестве плагина, я подменял папку для хранения файлов, заданную в настройках ownCloud, на существующий у меня Storage FreeNAS в котором и хранятся мои 5Tb. После чего ownCloud видел только часть файлов из Storage. Я думал, что необходимо какое-то время для индексации, но файлы так и не появлялись.
istui
06.04.2015 15:41+1Очень хорошая статья. Спасибо!
Отдельный респект за собранные в одном месте настройки fail2ban для owncloud.
Если у вас сервис доступен открыто из Сети и имеется свой домен — для удобства лучше использовать бесплатный сертификат от StartSSL, WoSign Let's Encrypt (запуск ожидается летом 2015). В таком случае не придется устанавливать сертификат на все свои устройства.
Бесплатные домены, помимо .tk, можно получить здесь.
Еще мои уточнения/замечания (раз уж статья идет как мануал :):
- при ответе на вопросы при создании сертификата лучше указать домен/IP-адрес облака, чтобы ограничить его зону применения
- openssl genrsa -des3 -out server.key 1024 — 1024 бит явно недостаточно по сегодняшним меркам, я бы рекомендовал 2048-4096
- openssl x509 -req -days 3650 -in server.csr -sha256 -signkey server.key -out server.crt — используем современный хэш (как вариант — sha384)
- в jail.conf лучше еще включить защиту от перебора SSH
ACooper Автор
06.04.2015 22:45Спасибо за уточнения. В таком случае может и des3 следует заменить на что-то другое?
Сейчас посмотрел, что думает о моём соединении Google Chrome, а там: «Соединение зашифровано с помощью устаревших технологий».
Здесь явно ещё есть простор для улучшений.
Про защиту от перебора по SSH не понял. Если не пробрасывать 22 порт наружу, то зачем это?istui
07.04.2015 22:01des3 — это алгоритм, которым шифруется приватный ключ при хранении на диске / переносе между серверами. На диске некоторые администраторы вообще хранят ключ без шифрования (чтобы не вводить пароль при рестарте сервера), хоть это и не рекомендуется. При переносе между серверами / backup приватный ключ можно шифровать -aes256.
На само соединение SSL\TLS шифрование ключа не влияет никак, это скорее мера защиты от его кражи. А вот длина ключа (к-во бит) как раз играет существенную роль.
Касательно устаревших технологий — у меня в nginx.conf обычно:
Если нет необходимости поддерживать старых (WinXP и старше) клиентовssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA';
SLIDERWEB
13.04.2015 11:30Для гарантированного получения A+ в списке цепочек я рекомендую использовать такую настройку протокола:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'HIGH:!aNULL:!MD5:!kEDH'; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
Как показала практика, при жеской прописке алгоритмов, в зависимости от типа и содержания сертификата, возможно занижение рейтинга до A и ниже. (почему — не знаю, тоже не гуру, но опытный)
n1nj4p0w3r
13.04.2015 15:19Скорее всего, причина в том, что указывая вручную алгоритмы вы указывали вначале более слабые либо не поддерживающие forward secrecy алгоритмы, чего лучше не делать еще со времен уязвимости BEAST, примерно тогда стандартом стал honor cipher order, который по-сути является форсируемым со стороны сервера порядком алгоритмов, клиенты же подключаются по первому поддерживаемому, что и стало причиной снижения рейтинга, сертификат в данном случае роли не играет.
Лично я использую такой порядок циферов:
ssl_ciphers 'ECDH+AESGCM256:DH+AESGCM256:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES128:RSA+AESGCM256:RSA+AES256:RSA+AESGCM128:RSA+AES128:RSA+3DES:!aNULL:!MD5:!DSS'; # RSA+3DES не помечен как уязвимый и висит для поддержки IE 8 / XP, в 99% случаях можно безболезненно убрать
n1nj4p0w3r
06.04.2015 22:07+1Вместо поднятия ssh внутри jail и создания лишнего юзера, можно было бы обойтись ssh на хосте и последовательностью:
jls #отображает список jail и их порядковый номер jexec порядковый_номер(или имя) tcsh #войти в шелл jail
Фича с fail2ban+pushover хороша, возьму на заметку
sergrt
06.04.2015 23:19+1В качестве дополнения, если кто-то выбирает себе облако:
ownCloud хорош (почти) во всём, что касается веба. Почти — потому что таки медленно работает в сравнении с альтернативами.
Для синхронизации с использованием клиентов, десктопных или мобильных, годится с трудом. Кучу маленьких файлов (исходники, иконки, и т.д.) обрабатывает удивительно огромное количество времени. Проблема, как я понял, в архитектуре, и исправлениям с помощью твиков не подлежит. Тип БД и ресурсы сервера существенного влияния не оказали.
Наиболее продвинутые альтернативы — Bittorrent Sync и Seafile. Btsync быстрый и в меру удобный, но последнее обновление сделало его непригодным для привычного использования.
Seafile порадовал всем, чем только может порадовать сервер «облака». Файлы ещё ни разу не пропадали и не портились, синхронизация быстрая. Условный минус — отсутствие на сервере «ортодоксальной» файловой системы хранения данных, но это решаемо. Однако оба эти продукта несколько проигрывают в функциональности веб-интерфейса.
Renatk
07.04.2015 12:31Заработало ли снова редактирование в браузере документов *.doc? Т.к. в версии 8.0 модуль был сломан, а в 8.0.2 я его не нашёл. При этом в 7 ветке все работает отлично.
ACooper Автор
07.04.2015 23:08Проверил. Не заработало или я не нашел. Как это выглядело в 7 ветке?
n1nj4p0w3r
08.04.2015 06:40Во всех ветках, начиная с 6 одинаково: в owncloud устанавливается приложение documents, на сервере устанавливается open/libreoffice, ну и на страничке администрирования нужно указать наличие open/libreoffice.
К слову: в 8й версии большую часть «вторичных»(documents,bookmarks,etc.) приложений из основного пакета убрали и их надо ставить либо включив appstore в config.php, либо по старинке — ручками.
Ну и у меня что на 8, что на 8.0.2 documents работает нормально: doc/docx показывает и редактировать дает, возможно при переезде с 7 на 8 что-то просто не учли.Meklon
08.04.2015 07:41У меня, кстати, приложение галерея отвалилось. Как её переустановить вообще?
n1nj4p0w3r
08.04.2015 08:01Можно с гитхаба стянуть нужную версию и распаковать в $ownclouddir/apps не забыв поchmodить и поchownить ну и удалить старое, если оно там есть, либо вообще отказаться от нынешнего приложения и сразу начать пользоваться его будущей заменой
n1nj4p0w3r
08.04.2015 08:23Не вспомнил сразу: версия приложения подставляемая гитхабом к имени папки ломает загрузку приложений, так-что, после распаковки папку нужно переименовать в gallery или galleryplus, в зависимости от выбранного варианта.
Meklon
08.04.2015 09:48Изучу, спасибо. А удаление кошерное как делается? Никак не привыкнуть, что нормальный apt-get не используется толком.
n1nj4p0w3r
08.04.2015 18:07Не очень понял вопрос, удаление чего?
Сам owncloud из репо дистрибутива лично я не ставлю, это скорее мера «на потрогать», чем для постоянного пользования.Meklon
08.04.2015 20:14Хм. Почему? Они сами рекомендуют именно так делать, вроде. Но в итоге немного странно получается, что часть вещей обновляется руками все равно.
n1nj4p0w3r
08.04.2015 20:41+1Да вроде не рекомендуют, просто предоставляют возможность. Тот-же автор публикации самостоятельно устанавливал owncloud в jail несмотря на то, что у freenas есть поддерживаемый плагин.
Сейчас они(owncloud) движутся в сторону своего appstore и понятно почему — каждое приложение упаковывать под разные системы управления пакетами в т.ч. от сторонних разработчиков — геморрой, а в некоторых случаях может быть лицензионно не возможно, так-что репозитории ос просто не способны решить проблему удобства администрирования(какой смысл, если некоторые приложения тогда прийдется ставить ручками и следить за их актуальностью?), минорные апдейты owncloud ставит прямо из веб-интерфейса, так-что вы ничем не рискуете, кроме одного вечера на чтение документации ну и стопки новых знаний, если подобным ранее подробно не занимались.
К слову о документации, недавно открыл для себя очень полезную опцию конфигурации, которая, учитывая количество css и js файлов может заметно сократить скорость загрузки веб-интерфейса (в моем случае ~1.5сек превратились в 600мсек)
arabesc
07.04.2015 23:30Создаём самоподписанные ключи и сертификаты
Как у вас работает синхронизация с iOS клиентами при таких сертификатах?
Имею тут проблему, у ownCloud баг давно заведен, фиксить не торопятся.ACooper Автор
08.04.2015 22:53Проблем не замечал. Всё работает.
arabesc
08.04.2015 23:00В том баге человек отписался, что проблемы наблюдается при подключенном аккаунте Dropbox'а. У меня подключен, отключать еще не пробовал.
А вообще, я смотрел сниффером запросы к серверу от web и iOS клиента, они несколько различаются по набору http-команд, что плохо.
AlexanderS
Я когда на дебиане FTP-сервак поднимал тоже на хабре статью выкладывал. Ибо надо было как-то все свои действия законспектировать (в первую очередь самому себе), а тут получилось и записал себе и помощь тем, кто будет разбираться.
Вашу статью — однозначно в избранное. Давно уже хочется самому поробовать сделать себе облако и «пощупать» лично, а тут как раз занятный мануал )
reff
Пощупать можно, развернув готовый appliance.
AlexanderS
А конкретнее можно?
У меня просто времени не хватает на все и я не совсем в теме.
reff
Можно. Например, ownCloud Virtual Machines, bitnami.com/stack/owncloud/virtual-machine
Собрат Pydio живёт по адресу pyd.io/download/#11
AlexanderS
О! Отличная штука. И главное ее можно воткнуть на комп и даже пользоваться, пробросив порты в WMNat и на роутере.
Как доделаю робота думаю руки дойдут)
ACooper Автор
Именно в процессе такого конспектирования и родилась идея этой статьи. Так как я всё это делаю впервые, то было очень сложно добиться работающей системы без подробных записей как делать.
На самом деле, со времён сборки мною небольшого сервера-хранилки для дома — ноябрь прошлого года, уже накопилось несколько таких конспектов. Сейчас этот сервер умеет следующее:
— ESXi с проброшенными в виртуальные машины SATA-контроллерами и инъектированными драйверами сетевой карты и самих SATA-контроллеров. Всё остальное уже крутится в виртуальных машинах.
— FreeNAS как хранилка файлов.
— TimeMachine для ноутбуков с OS X.
— Торрентокачалка с полюбившимися мне push-уведомлениями о завершении закачки.
— Автоматическое скачивание новых серий популярных сериалов и интересных мне раздач при их обновлении. Также с push-уведомлениями о начале скачивания.
— Plex медиа-сервер. Для удобного хранения и просмотра видео-коллекции. Доступен не только для меня, но и для родных/друзей. Также с всевозможными push-уведомлениями.
— Трансляция каналов torrent-tv на телевизоры.
Сейчас ещё осваиваю умный дом на z-wave. Но это уже на отдельной железке
Если что-то заинтересовало, то готов написать еще статьи.
Meklon
Вот про torrent.TV по подробнее, пожалуйста. Можно отдельной статьей, если время есть.
ACooper Автор
Всё решение состоит из набора софта работающего as is.
Но были и нюансы.
Вроде бы для комментария много писать, а для статьи мало.
Но так как на Хабре не так много было статей по данной тематике, то во мне побелило решение написать статью.
Предупрежу сразу — реализованное у меня решение будет стоить несколько сотен рублей разово и что-то около 3х рублей в день.
Meklon
Я бы все равно послушал)
michaelkl
А вот расскажите, как на домашнем сервере-хранилке вы обеспечиваете надёжность хранения. Вот вы написали, что у вас накопилось 5 Tb данных. А это всё куда-то регулярно копируется в резервную копию? Куда? Или обходитесь простым RAID-зеркалированием? Есть ли какой-то мониторинг «здоровья» жёсткого диска?
n1nj4p0w3r
Обычно FreeNAS означает ZFS.
michaelkl
Я спрашиваю не потому, что не знаю, как решаются такие проблемы. Я спрашиваю потому, что мне интересно, как их решает автор, и я надеюсь почерпнуть в его ответе что-то новое для себя.
ACooper Автор
Боюсь Вас разочаровать, но ничего нового я в этом направлении не придумал.
Избавиться в домашних условиях от единой точки отказа довольно проблематично и дорого.
А по сему всё банально:
— В FreeNAS используется ZFS с raidz1 (выдерживает смерть одного любого диска), состояние дисков отслеживается через S.M.A.R.T. силами самой системы FreeNAS, а в случае обнаружения проблем — должно прийти письмо на почту;
— критичные для меня данные просто синхронизируются в google drive их клиентом для Win (стоит на виртуальной машине на том же ESXi что и FreeNAS).
Таким образом, от смерти одного диска я вроде бы защищен, при смерти всех дисков у меня остаются необходимые мне данные.
ACooper Автор
Забыл еще уточнить:
— ESXi крутится на флешке, с флешки снят образ;
— у FreeNAS сделан бекап настроек и копия самой виртуальной машины.
Всё это хранится на другой машине и в случае аварии я могу довольно быстро всё восстановить на ней.
istui
Темы очень интересные и полезные, был бы рад увидеть статьи по всем пунктам.
Еще было бы интересно вынести всю музыку с компьютеров на сервер, так, чтобы ее можно было проигрывать в iTunes — как на OS X / Windows, так и в iOS — чтобы не занимать память устройств. Насколько я знаю, «Домашняя коллекция» iTunes такое умеет, но при этом требует постоянно работающий экземпляр iTunes на MAC или PC. Если есть какие-либо способы эмуляции Домашней коллекции свободным ПО, чтобы все разместить на домашнем *nix-сервере — было бы тоже интересно об этом узнать.
ACooper Автор
Была подобная мысль, но остановилась пока только на идеи с виртуальной машиной и Hackintosh.
Либо попробовать плагин firefly.
На сколько я сужу по поиску, у NAS QNAP есть iTunes Music Server. Значит решение задачи существует.