Системы хранения Synology — достаточно распространенная нынче штука. Они удобные, тихие, компактные, с кучей возможностей. Однако собственное облако — это хорошо, но надо серьезно задуматься о безопасности. Далее мы рассмотрим, как гибко ограничить доступ к пользовательским веб приложениям Synology. Будем использовать авторизацию x509 сертификатами, именем и паролем и ограничение по IP адресам.
В DSM есть 2 типа приложений с веб интерфейсом:
- системные (сам рабочий стол, PhotoStation, VideoStation, TimeMachine и пр)
- пользовательские. Работают при включенном сервисе WebStation. Например: dokuWiki, mediaWiki, RSS reader, и пр)
Самая простая защита от доступа из вне — перенести приложение на нестандартный порт. С системными приложениями это сделать несложно — в панели управления есть соответствующие настройки.
С пользовательскими чуть сложнее, к тому же иногда хочется оставить их на стандартном 443 порту, доступными по протоколу HTTPS (от использования HTTP есть смысл отказаться совсем).
Итак, я опишу некую “жизненную” конфигурацию. Дано:
— Synology DSM 5.2-5592 Update 4
— Включен сервис WebStation, на нем запущено:
- DokuWiki (Wiki со своими внутренними пользователями)
- Tiny RSS (RSS reader)
- Cops (Каталог электронной библиотеки)
— Доступ к самой DSM возможен снаружи и из внутренней сети.
Надо заметить, что уровень доверия к системным приложениям DSM достаточно высок — обновления безопасности системы выпускаются часто. Чего не скажешь про пользовательские приложения. На мой взгляд именно их уязвимости (потенциальные) и представляют основную угрозу безопасности всей системе и пользовательским данным конкретного приложения. Поэтому доступ к ним необходимо ограничить. Опять же — некоторые приложения не подразумевают никакой авторизации и разграничения прав доступа к своим данным, рассчитывая на использование только во внутренней сети.
Ограничивать доступ будем следующим образом:
DokuWiki — свободный доступ из внутренней сети. Снаружи доступ только при наличии сертификата. Используется модуль apache mod_ssl. Затем вступает в действие внутренняя система авторизации. Как я уже писал выше, в DokuWiki свои собственные пользователи и своя система прав на доступ к статьям.
Tiny RSS — свободный доступ из внутренней сети. Снаружи доступ только при наличии сертификата. Используется модуль apache mod_ssl. Больше никаких дополнительных средств ограничения доступа не требуется.
Cops — свободный доступ из внутренней сети. Из вне доступ по имени и паролю. Используется модуль apache mod_auth_digest. Подразумевается, что снаружи могут подключаться всевозможные “электронные книги” и я не уверен, что на них возможно загрузить пользовательский сертификат и использовать его в веб-браузере.
Таким образом для ограничения доступа используются различные модули веб сервера Apache.
Теперь реализация, настроим авторизацию по сертификатам
Идея здесь такая, что только пользователь, имеющий сертификат, подписанный нашим CA, имеет доступ к определенной части сайта.
- Нам необходимо создать самоподписанный CA (Certificate Authority) и с помощью него создать клиентский сертификат. Как это делать описывать не буду — существует много инструкций, например: www.opennet.ru/base/sec/ssl_cert.txt.html, да и наверняка у некоторых уже есть собственный CA, который можно использовать для наших целей. Да, и чтобы соответствовать реалиям, мы чуть усложним задачу и добавим промежуточный CA, т.е. сделаем цепочку: Root CA — Intermediate CA — client:
- Создаем самоподписанный RootCA.crt
- Создаем InterCA.crt, подписанный RootCA.crt
- Создаем клиентский: client.crt, подписанный промежуточным
- Из созданных сертификатов делаем bundle командой: cat RootCA.crt InterCA.crt >ca-bundle.crt
- Копируем ca-bundle.crt и InterCA.crt на Synology в папку /usr/syno/etc/ssl/ssl.crt/
- Редактируем соответствующий конфиг apache (/etc/httpd/conf/extra/httpd-ssl.conf-cipher), добавляем в него строки:
SSLCACertificatePath "/usr/syno/etc/ssl/ssl.crt" # Комплект из корневого и промежуточного сертификата SSLCACertificateFile "/usr/syno/etc/ssl/ssl.crt/ca-bundle.crt" # авторизоваться смогут только клиентские сертификаты, подписанные этим СА SSLCADNRequestFile "/usr/syno/etc/ssl/ssl.crt/InterCA.crt" - Настраиваем DokuWiki. Создаем /volume1/web/dokuwiki/.htaccess файл или добавляем в существующий строки:
# Если mod_revrite недоступен, то жестко включаем авторизацию по сертификатам. SSLVerifyClient require <IfModule mod_rewrite.c> # Включаем необязательную авторизацию SSLVerifyClient optional # Глубина проверки. Т.к. у нас bundle состоит из 2х - корневого и промежуточного сертификатов. SSLVerifyDepth 2 # Условие редиректа: Если не было успешной авторизации сертификатом RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS$ # Условие редиректа: Если клиент не из локальной сети 192.168.1.x RewriteCond %{REMOTE_ADDR} !^192.168.1.[0-9]*$ # Если оба условия выполнены - делаем редирект на ошибку 403 RewriteRule ^ - [F] </IfModule> - Перезагружаем httpd-user сервис командой: synoservicectl —restart httpd-user
- С DokuWiki все.
- Аналогичным образом прописываем .htaccess для TynyRSS
Затем настроим авторизацию по имени-паролю:
- Создаем файл с пользователями и паролями командой: /etc/httpd/passwddg -с /etc/httpd/passwddg “Books Library” bookuser. Таким образом пользователь bookuser будет иметь возможность подключиться к сервису. Обратите внимание, если вы будете добавлять других пользователей в тот же файл, необходимо убрать ключ -с, иначе файл с паролями перезапишется!
- Настраиваем Cops. Создаем /volume1/web/cops/.htaccess файл или добавляем в существующий строки:
# для разнообразия ограничиваем доступ только к PHP файлам. Этого достаточно. <FilesMatch "\.php$"> Order allow,deny # разрешаем доступ только с домашней подсети 192.168.1.x Allow from 192.168.1 # включаем Digest авторизацию AuthDigestProvider file # Файл, в котором хранятся пользователи и пароли из предыдущего шага AuthUserFile /etc/httpd/passwddg AuthType Digest # Имя защищенного ресурса, задается в файле с паролями на предыдущем шаге AuthName "Books Library" # Разрешаем доступ для любого пользователя, прошедшего авторизацию Require valid-user # для получения доступа должно быть выполнено любое условие. # Либо клиент с IP адресом из домашней подсети, # либо авторизованный именем и паролем пользователь Satisfy Any </FilesMatch> - Перезагружаем httpd-user сервис: synoservicectl —restart httpd-user
- C Cops тоже все готово!
Пару слов об использованных методах авторизации
auth_digest: пришла на смену auth_basic и отличается от предшественницы тем, что пароль не передается в открытом виде, соответственно ее можно использовать поверх HTTP.
SSL: как часть модуля mod_ssl. Основное: каждый, кто будет иметь клиентский сертификат, подписанный нашим CA будет иметь доступ к необходимым приложениям.
Как можно усовершенствовать авторизацию с помощью сертификатов?
— Можно для разных приложений использовать разные CA
— Можно разрешать доступ пользователю на основе различных полей сертификата
— Можно выпускать клиентский сертификат на короткий срок — например на неделю или на месяц
— Можно (даже нужно) добавить в конфигурацию путь к CRL (список отозванных сертификатов) для оперативной блокировки отдельных пользователей
— Клиентские сертификаты можно закрывать паролем и/или хранить на USB eToken
Удачной настройки!
ссылка на оригинал статьи http://habrahabr.ru/post/266991/
Добавить комментарий