Pull to refresh

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

Reading time5 min
Views16K
Системы хранения 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, имеет доступ к определенной части сайта.

  1. Нам необходимо создать самоподписанный 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/
  2. Редактируем соответствующий конфиг 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"
    

  3. Настраиваем 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>
    

  4. Перезагружаем httpd-user сервис командой: synoservicectl --restart httpd-user
  5. С DokuWiki все.
  6. Аналогичным образом прописываем .htaccess для TynyRSS


Затем настроим авторизацию по имени-паролю:


  1. Создаем файл с пользователями и паролями командой: /etc/httpd/passwddg -с /etc/httpd/passwddg “Books Library” bookuser. Таким образом пользователь bookuser будет иметь возможность подключиться к сервису. Обратите внимание, если вы будете добавлять других пользователей в тот же файл, необходимо убрать ключ -с, иначе файл с паролями перезапишется!
  2. Настраиваем 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>
    

  3. Перезагружаем httpd-user сервис: synoservicectl --restart httpd-user
  4. C Cops тоже все готово!


Пару слов об использованных методах авторизации


auth_digest: пришла на смену auth_basic и отличается от предшественницы тем, что пароль не передается в открытом виде, соответственно ее можно использовать поверх HTTP.
SSL: как часть модуля mod_ssl. Основное: каждый, кто будет иметь клиентский сертификат, подписанный нашим CA будет иметь доступ к необходимым приложениям.

Как можно усовершенствовать авторизацию с помощью сертификатов?
— Можно для разных приложений использовать разные CA
— Можно разрешать доступ пользователю на основе различных полей сертификата
— Можно выпускать клиентский сертификат на короткий срок — например на неделю или на месяц
— Можно (даже нужно) добавить в конфигурацию путь к CRL (список отозванных сертификатов) для оперативной блокировки отдельных пользователей
— Клиентские сертификаты можно закрывать паролем и/или хранить на USB eToken

Удачной настройки!
Tags:
Hubs:
Total votes 8: ↑8 and ↓0+8
Comments0

Articles