Antonto Sep 16 2015 at 18:07

Ограничение доступа к веб-приложениям в Synology DSM

5 min

16K

Системы хранения 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:
1. Создаем самоподписанный RootCA.crt
2. Создаем InterCA.crt, подписанный RootCA.crt
3. Создаем клиентский: client.crt, подписанный промежуточным
4. Из созданных сертификатов делаем bundle командой: cat RootCA.crt InterCA.crt >ca-bundle.crt
5. Копируем 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

Удачной настройки!

Tags:

synology

Hubs:

Information Security