Безопасность: Настройка демилитаризованной зоны
Демилитаризованная зона (англ. Demilitarized Zone, DMZ) – это конфигурация сети, направленная на усиление безопасности сети организации, в которой открытые для общего доступа сервера находятся в отдельном изолированном сегменте сети. Данная концепция обеспечивает отсутствие контактов между открытыми для общего доступа серверами и другими сегментами сети в случае взлома сервера.
Как правило, в изолированном сегменте сети располагается сервер-ретранслятор, обеспечивающий перенаправление запросов из внешней сети в сеть организации. Примерами таких серверов могут служить ViPNet Coordinator и обратный прокси-сервер (Reverse proxy).
Обратный прокси-сервер (Reverse proxy)
В качестве Reverse proxy может быть использован любой веб-сервер (NGINX, Apache, IIS). Как правило, для продуктов DIRECTUM используется Reverse proxy на базе IIS.
Для настройки потребуются Application Request Routing и URL Rewrite, которые можно установить при помощи Web Platform Installer.
Для начала создаем веб-сайт, который будет принимать запросы из внешней сети. Для него необходимо указать соответствующие привязки (имя хоста и порт). Так как все веб-решения компании DIRECTUM предполагают работу с важной информацией, необходимо настроить
сайт на использование HTTPS-соединения. Обычно для HTTPS-соединения используется 443 порт. Соответственно, данный порт необходимо указать в настройках DMZ-брандмауэра.
Следующим шагом добавляем правило перенаправления при помощи модуля URL Rewrite:
Если настройка осуществляется впервые, IIS сообщит о необходимости включения Reverse proxy-функциональности и предупредит, что Reverse proxy может как усилить защиту периметра организации, так и, наоборот, снизить безопасность, предоставив доступ внутренним сервисам организации из сети Internet.
После включения Reverse proxy-функциональности необходимо задать правила перенаправления:
В поле «Правила для входящего трафика» указывается адрес и порт сервиса для перенаправления, находящегося во внутренней сети организации. Напомню, что входящие адреса, запросы с которых будут перенаправлены, задаются выше в настройках привязок веб-сайта.
Для снижения нагрузки на DMZ-сервер можно включить SSL-разгрузку. В этом случае все внешние HTTPS-запросы будут перенаправлены по HTTP во внутреннюю сеть. Мы не рекомендуем применять такие подходы, чтобы не снижать общую безопасность схемы взаимодействия, поэтому в настройках брандмауэра внутренней сети также потребуется открыть 443 порт (или иной, указанный в правилах URLRewrite).
Пример настройки:
Сервер веб-приложения DIRECTUM располагается во внутренней сети организации и имеет один интерфейс: 192.168.1.2/255.255.255.0.
Брандмауэры сети DMZ и внутренней сети настраиваются на разрешение входящих и исходящих соединений по порту 443 протокола HTTP.
Для обеспечения дополнительной защиты рекомендуется ограничить доступ к веб-серверу DIRECTUM из внутренней сети и разрешить сетевые соединения только с необходимыми службами (СУБД, сервер сеансов, Workflow и т.д.). Для этого следует настроить правила брандмауэра веб-сервера DIRECTUM для входящих и исходящих соединений и разрешить соединения по следующим портам:
- протокол TCP/IP;
- для связи с SQL сервером – по умолчанию порт 1433;
- для связи с сервером с установленной службой Сервер сеансов – по умолчанию порт 32300;
- для связи с сервером с установленной службой WorkFlow – по умолчанию порт 32310;
- для работы сервера веб-доступа по протоколу HTTPS – порт 443;
- протокол UDP/IP: для разрешения имен NetBIOS – по умолчанию порты 137-139.
Указан минимальный набор портов и протоколов связи. При использовании в продуктивной среде возможно расширение разрешающих правил. К примеру, для работы служб файловых хранилищ понадобится дополнительно открыть порты 445 и 32320 по протоколу TCP.
Вместо заключения
В этой небольшой статье были рассмотрены практические шаги, с помощью которых можно повысить уровень безопасности сети организации. Для того чтобы ознакомиться с другими средствами обеспечения безопасности следите за тегом безопасность.
Очень классная и полезная статья! Спасибо!
Спасибо, Алексей.
Михаил, верно ли я понимаю, публикуемый сервер(DMZ) не должен находится в домене и должен взаимодействовать с веб-сервером Directum по перечисленным портам в статье.
заранее спасибо!
Сергей, варианты развертывания DMZ могут быть разными, но задача его в том, чтобы отделить точки входа внешнего доступа от внутренней сети. Чтобы если злоумышленник смог подключиться к серверу, который транслируется в интернет, оттуда он не смог получить доступ к внутренней сети.
Для этого и сильно ограничивают связь DMZ с контуром предприятия. Чем больше точек взаимодействия с внутренней сетью, тем ниже безопасность. Включение в домен данной машины не исключение, и может оказаться дырой в безопасности (зависит от того как влючите), так как позволит получить доступ к ресурсам, предоставит авторизацию и взаимодействие с доменом.
Михаил, огромное спасибо за ответ. Верно я понимаю, что запуск сценария не включая публикуемую машину(DMZ) в домен возможно ?
Сергей, не понял Ваш вопрос.
можно ли не вводить публикуемую машину(DMZ) в домен и настроить взаимодействие(через firewall открыть определенные порты) с веб-сервером Directum?. Техническая поддержка одной из сопровождавшей компании ответили, что сервер обязательно должен находится в домене.
Сергей, конечно. Машина DMZ может быть даже на Linux с одним ReverseProxy. Её задача принять трафик с одного канала и отправить его на другой.
С другой стороны, если в компании несколько сервисов публикуются наружу с различными протоколами, то управлять машинами в DMZ становится накладно. В этом случае рекомендуется создавать отдельный домен, для управления этой зоной. Эта тема немного раскрывается здесь: http://it2web.ru/index.php/adds/110--dmz-active-directory.html?showall=1 советую почитать.
Михаил, огромное Вам спасибо за подробный ответ!
Я извиняюсь, но не могу понять, чем ваша конфигурация с проксёй в плане безопасности отличается от простого PAT на пограничном фаяре внутренней сети компании? Все порты будут закрыты, открыт только TCP 443 значит в модели угроз остаётся только одна уязвимость уровня приложения и это уязвимость самого NOMAD. Т.е. сколько проксей впереди не ставь уровень безопасности не изменится, т.к. ломать будут уровень приложения не ниже (в TCP, IP, Ethernet все уязвимости уже давно закрыты)... поправьте если не прав! Еще есть варианты с DDOS, но ваша схема с проксёй её не решает (по крайней мере в статье про это ни слова). Обойти PAT теоретически возможно если у вас старый алгоритм трансляции на маршрутизаторе, но обход PATa уже давно лечится. А вот к безопасности номад есть вопросы... Например защита от брутфорс атак, SQL инъекций, перехват переменных состояния сеансов авторизированных пользователей, фильтрация по макам. Существуют какие то настройки безопасности NOMAD по этим вопросам? Существуют ли какие то методики (или есть ли возможности) мониторинга активности пользователей в NOMAD например через Zabbix (например кол-во попыток входа пользователя по неверному паролю, не регламентированное/подозрительное поведение клиента Jazz/Solo, макадреса устройств получивших доступ и т.д.). Спасибо!
Никита, день добрый.
> не могу понять, чем ваша конфигурация с проксёй в плане безопасности отличается
Об этом написано в другой статье.
> А вот к безопасности номад есть вопросы... Например защита от брутфорс атак, SQL инъекций, перехват переменных состояния сеансов авторизированных пользователей, фильтрация по макам.
Как-то всё в кучу. Выше Вы говорили об уровне приложения, и тут же в пример приводите фильтрацию MAC (которой даже IIS не занимается). Отфильтровать MAC можно на фаерволе через ACL (мы же не будем про спуфинг MAC говорить). Этим не может и не должно заниматься ПО прикладного уровня. Как минимум, свой интерфейс и свои особенности настройки для каждого внешнего ресурса - будет доставлять проблемы в администрировании.
"брутфорс атак" - перебор пароля отслеживается. После пяти неудачных попыток входа, IP-адрес блокируется на 30 минут (значения не настраиваются). Отмечу, что в случае с работой "за прокси", важно чтобы сервер означивал XFF-заголовки, чтобы не заблокировать IP самого прокси и работу всех пользователей.
"SQL инъекций" - со стороны NOMAD все запросы параметризируются. Но не стоит забывать и про прикладной слой самой системы (ISBL-разработка), в котором могут быть внесены уязвимости при выполнении доработок (относительно коробочного решения).
"перехват переменных состояния сеансов авторизированных пользователей" - как и большинство веб-приложений, NOMAD использует 128-битный идентификатор сессии, который передаётся в Cookie. Естественно, для взаимодействия клиента и сервера должны использоваться шифрованные каналы связи (HTTPS, VPN). Но в отличие от веб-сайтов, в мобильном взаимодействии XSS-атаки исключены.
"макадреса устройств получивших доступ и т.д." - если вы интересуетесь относительно системы DIRECTUM, то NOMAD предоставляет возможность просмотра/контроля инсталляций мобильных приложений у пользователя. Если необходим уровень MAC-адресов, то необходимо использовать MDM-решения (например SafePhone). Так же возможна настройка ограничения доступа относительно white/black-списка по группам или пользователям системы и внедрение свой логики во взаимодействие клиента и сервера с помощью плагинов.
"мониторинга активности пользователей в NOMAD например через Zabbix" - NOMAD логирует все обращения клиентов к серверу в server*-логе, и состояние ресурсов сервера в performance-логе. Мониторить активность пользователей, изменение IP-адресов, и попытки подбора пароля можно по Server-логу. Системы мониторинга по типу Zabbix и ElasticStack имеют механизмы для чтения лога. Описания/рекомендаций по подобной настройке - нет. Но формат лога очевидный:
Так же NOMAD использует систему nlog для логирования, которая может расширяться отдельно (таргеты для Elastic есть, для Zabbix не нашёл). Есть своя утилита, для формирования статистики за период (не realtime). У нас в компании активность мобильных пользователей отслеживается при помощи ElasticStack.
"подозрительное поведение клиента Jazz/Solo" - сам NOMAD не отслеживает, но возможно применение DLP-систем. Стоит учитывать, что характер поведения пользователей изменяется в зависимости от организации. (Я понимаю, что Вы имели в виду поведение мобильного приложения: интенсивность и последовательность операций, но они сильно зависят от кейсов конечного пользователя). На самом деле, отслеживание аномалий поведения достаточно интересная тема, здесь есть желание попробовать ML модуль ElasticStack, но конкретных сроков/планов пока нет.
Так же у DIRECTUM есть документ "DIRECTUM. Рекомендации по обеспечению информационной безопасности при работе с системой" в котором затронута и мобильная составляющая системы.
Авторизуйтесь, чтобы написать комментарий