Железный RX. Безопасность на уровне IIS

DirectumRX фактически является набором приложений IIS, которые имеют доступ к БД через ряд компонентов операционной системы. Приложения имеют доступ к ресурсам сети в зависимости от прав, которые были выданы системным администратором при развертывании системы. Зачастую заказчики разворачивают DirectumRX из инсталлятора и не производят дополнительных настроек, оставляя систему практически незащищенной.

Очень часто системные администраторы разворачивают приложения DirectumRX от собственной учетной записи, либо используют учетную запись локального администратора или даже доменного администратора, и выводят систему в Интернет, минуя DMZ, тем самым подвергая опасности всю сеть предприятия.

В данной статье рассмотрим основные ошибки, подсмотренные на рабочих местах пользователей локальных DirectumRX и предоставим соответствующие рекомендации по повышению безопасности DirectumRX.

Дисклеймер 

Рекомендации представленные в статье не являются официальной документацией какой бы то ни было компании. Рекомендации предоставляются на основании личного опыта автора по настройке системы DirectumRX. Автор статьи не несет ответственности и не предоставляет гарантий в связи с публикацией фактов, сведений и другой информации, а также не предоставляют никаких заверений или гарантий относительно содержащихся здесь сведений. 

Ошибка №1. Общая доменная учетная запись для сервисных служб, обладающая широкими полномочиями

Допустим, некий злоумышленник нашел лазейку в сервисе IIS, использовал эксплойт на известную уязвимость и получил права выполнять какие-либо операции от имени пула IIS. В этом случае злоумышленник имеет доступ ко всем сервисам предприятия и может нарушить доступность всех сервисов, либо получить доступ ко всем информационным потокам.

Что делать:

1. Для каждого пула IIS (для каждого приложений DirectumRX) необходимо завести специальную учетную запись, которая больше нигде не будет использоваться кроме данного сервера.
2. Учетные записи должны быть различными. Если злоумышленник получит доступ к одному пулу, то для получения доступа к другим пулам ему также придется постараться, а такую активность можно быстро вычислить.
3. Учетные записи должны обладать ограниченными правами, достаточными для выполнения задач:
   1. Сервер приложений DirectumRX должен иметь доступ к папке со своими файлами, а также иметь доступ к БД
   2. Служба Workflow должна иметь доступ к папке со своими файлами, доступ к очередям MSMQ, доступ к БД
   3. Сервис Агентов, аналогично серверу приложений

Ошибка №2. Прямой доступ в Интернет минуя DMZ

Очень часто пользовали DirectumRX с локальной инсталляцией после разворачивания системы обеспечивают прямой доступ к системе. Либо открывают прямой доступ к системе через маршрутизатор, либо в некоторых случаях размещают DirectumRX на сервере, где уже есть службы и сервисы, выведенные в Интернет.

DMZ (англ. Demilitarized Zone — демилитаризованная зона, ДМЗ) – сегмент сети, содержащий общедоступные сервисы, для которых не требуется применять корпоративные стандарты безопасности. Не следует путать DMZ с брандмауэром. При атаке на общедоступный сервис в DMZ снижается риск компрометации внутренних серверов, поскольку внешние и внутренние серверы физически отделены друг от друга.  

Так к примеру, для DirectumRX успешно может применяться реверс-прокси на базе IIS (подробнее https://www.iis.net/downloads/microsoft/application-request-routing).

Такая архитектура обеспечивает полное функционирование DirectumRX с возможностью применения windows-аутентификации и базовой аутентификации клиентских приложений DirectumRX. Прочие веб-сервисы с возможностью реверс-прокси не гарантируют корректное функционирование Windows-аутентификации.

Ошибка №3. Доступ открыт всем

Одним из преимуществ локальной инсталляции DirectumRX является возможность обеспечить ограниченный доступ к системе DirectumRX. Ограничить можно как по IP адресам, так и с использованием VPN-каналов. Однако подобные решения на практике встречаются крайне редко.

Ограничение доступа к системе по IP позволяет существенно сузить круг лиц, знающих о наличии на ваших серверах доступной для работы системы документооборота, но в данном случае исключаются мобильные пользователи, IP которых не является статическим. В этом случае поможет VPN соединение, к примеру, OpenVPN, который доступен практически на всех платформах, однако VPN снижает полосу пропускания, в связи с чем снижается скорость работы мобильного клиента.

Ошибка №4. Отсутствие фильтрации по расширениям файлов

Иногда встречаются случаи, когда папка с сервисами доступна на просмотр. Это является очень грубым нарушением. Злоумышленник не только сможет получить структуру каталогов, но и получить доступ к файлам, содержащим реквизиты доступа к БД. А если на вашу систему есть ссылка на корпоративном сайте, то, считайте, поисковые системы уже проиндексировали ваши каталоги, и они стали достоянием общественности.

Что фильтруем:

1. Файлы с расширением .xml, .config, .conf
2. Исключением является папка с клиентским приложением \Client, для нее необходимо открыть доступ на скачивание .config и .dic файлов

Ошибка №5. Равный доступ для всех администраторов в компании

Часто многие организации применяют разделение труда системных инженеров. Одни занимаются базами данных, другие безопасностью, третьи настройкой ландшафта. Такие же правила необходимо применять и при работе с IIS.

IIS позволяет настраивать роли, чтобы ограничить доступ системным инженерам, которые не допущены к настройке ландшафта. Но необходимо выдать им права на выполнение необходимых операций (аудит настроек, перезапуск определенных служб и т.п.).

Ошибка №6. Отсутствие антивирусного ПО на серверах IIS

Тут многие могут поспорить, что антивирусное ПО не требуется на серверах, куда нет доступа и не устанавливается стороннее ПО, и то что антивирус будет тормозить работу сервисов.

Однако при продуктивной работе с сервисами может случиться что угодно, либо может повлиять злоумышленник и сможет «заставить» развернутые службы скачать и исполнить вредоносное ПО. Антивирусное ПО обязательно должно быть развернуто на всех продуктивных серверах, это лучше принять как аксиому.

Чтобы снизить влияние антивируса на быстродействие служб, можно добавить в исключение папки приложений DirectumRX:

C:\inetpub\wwwroot\DirectumRX

C:\inetpub\wwwroot\DrxWorkflow

C:\inetpub\wwwroot\DrxAgent

и другие веб-сервисы, относящиеся к DirectumRX, можно добавить аналогичным образом в исключения.

Однако папку с клиентским приложением, лучше оставить под контролем, чтобы пресечь распространение вредоностного ПО, если злоумышленнику все же удалось подменить файлы клиента. 

Как известно, все полезно в меру, так и с безопасностью

Использование систем анализа трафика на выявление утечек и угроз, как правило парализуют работу системы DirectumRX. Служба поддержки не раз решала подобные инциденты, когда без видимых причин система не функционирует в сети пользователя. Системы анализа трафика повышают задержки при обработке запросов, подменяют SSL-сертификаты безопасности сервиса DirectumRX, что приводит к множественным ошибкам. Для анализа угроз достаточно использовать анализатор логов безопасности.

Установка автоматических обновлений также может стать источником многих неприятностей. Иногда устанавливаемые обновления могут конфликтовать с используемым в сервисах ПО, поэтому установка обновлений должна производиться в запланированное время и перед обновлением желательно сделать снимок (snapshot) инфраструктуры, чтобы при возникновении ошибок после применения обновлений можно было откатить изменения.

Вместо заключения

В данной статье мы рассмотрели основные ошибки, допускаемые пользователями локальных инсталляций DirectumRX, устраняя данные ошибки можно существенно повысить защищенность и доступность сервисов DirectumRX. В случае наличия дополнительных материалов или рекомендаций, прошу указывать в комментариях к данной статье. Самые интересные дополнения будут включены в статью с именем автора дополнения.

В следующей статье по данной тематике, мы рассмотрим настройки для повышения безопасности СУБД MSSQL.