Защита серверных ролей

Как правило, в сети используются несколько общих ресурсов (приложения, файлы, принтеры) и базы данных. Часто корпоративные сети имеют подключения к Интернету. Ни одна сеть не обходится без базовых механизмов ее организации, таких как службы каталогов, механизмы разрешения имен и адресация узлов. Функционирование и использование вышеперечисленных компонентов обуславливают сервера. В зависимости от типа использования сервера последние разделяют на роли. Всем известно о существовании контроллеров доменов, DNS-, DHCP-, WINS-серверах, серверах баз данных, серверах печати и почтовых серверах. Каждый из указанных серверов генерирует свой трафик, использует определенные протоколы и реализует специфические функции в сети. Поэтому необходимо применять разные методы защиты для каждого типа сервера. Ниже дадим рекомендации по настройке брандмауэра для работы с контроллером домена, опишем механизм защиты DNS-сервера, обсудим настройку безопасных VPN, а также рассмотрим использование шаблонов безопасности.

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

Репликация осуществляется по двум протоколам RPC и SMTP. Поэтому на брандмауэре необходимо настроить защиту этих протоколов и открыть дополнительные порты. Причем необходимо учесть, что в качестве транспортной технологии используется и TCP, и UDP. Таким образом, на брандмауэре необходимо открыть следующие порты для репликации: DNS (53 TCP и UDP), протокол LDAP (3268 TCP, 389 TCP), NetBIOS (137 TCP и UDP, 138 UDP, 139 TCP), RPC (135 TCP и UDP), SNB (445 TCP и UDP), WINS (42 TCP и UDP, 1512 TCP и UDP). Следует учесть, что если в сети настроен внутренний DNS, порты для NetBIOS открывать не нужно. Однако, если последний протокол все же необходим для старых приложений, открытие для него указанных портов облегчает злоумышленникам взлом сети. Еще одной проблемой может стать использование динамических портов для протокола RPC. По умолчанию для этого протокола может использоваться любой случайный порт (всего более 64000 портов TCP). Открыв эти порты на брандмауэре, можно свести эффективность работы межсетевого экрана к нулю.

Для реализации этой функции необходимо включить серверную службу сопоставления портов через порт 135. Она сообщит обеим сторонам подключения номер случайного порта для репликации. В принципе, репликацию можно организовать через туннель, что также сократит количество открытых портов, но для этого необходимо наличие VPN-подключения, защищенного IPSec. Также следует учесть, что если вместо локальной DNS на клиентских компьютерах используются файлы HOSTS, то открывать порты для репликации DNS не нужно (также не нужно этого делать, если DNS не интегрирована в Активный каталог).

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

Механизм разрешения имен также нуждается в защите. На систему DNS возможны следующие виды атак: footprinting (похищение данных зоны с именами и адресами компьютеров), redirection (подмена IP-адресов и перенаправление компьютеров на сервер злоумышленника), DоS (перегрузка DNS-сервера запросами, остановка разрешения имен), IP spoofing (подделка пакетов с целью выдать компьютер злоумышленника за компьютер корпоративной сети), cache poisoning (запись в кэш DNS-сервера неверной информации).

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

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

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

Для организации безопасного туннельного VPN-соединения необходимо настроить граничные сервера в сети и разрешить туннель на брандмауэре. Логично если граничными точками VPN-подключения будут ISA Serverа. Первоначально в консоли Управление ISA Server необходимо включить доступ VPN-клиентов, выбрать их количество, выбрать участников безопасности, которым дано право использовать VPN и выбрать протокол туннелирования (PPTP или L2TP/IPSec). В дальнейшем нужно выбрать сети для доступа, т.к. по умолчанию прослушиваются только внешние сети, и назначить VPN-клиентам IP-адреса (можно настроить статический пул на ISA Server или использовать внутренний DHCP).

Необходимо также выбрать метод аутентификации клиента. Если в сети используются смарт-карты, можно использовать протокол EAP-TLS или использовать протокол по умолчанию MS-CHAPv2. Если для аутентификации клиентов при связи ISA Server и контроллера домена предполагается использовать промежуточное звено, то можно использовать аутентификацию RADIUS. В Активном каталоге выбрать учетные записи пользователей, которым разрешить доступ по VPN. Потом на брандмауэре необходимо создать правило, предоставляющее этим клиентам доступ к сети. В последствии на клиентских компьютерах необходимо создать сетевое подключение VPN, указав адреса граничных ISA Serverов.

При создании подключения VPN протокол L2TP/IPSec использовать предпочтительнее, чем протокол PPTP. Причем при использовании первого протокола рекомендуется использование сертификата.

Защита серверов от внешних атак не гарантирует полной безопасности сети – злоумышленники могут быть и внутри предприятия. Поэтому необходимо настраивать параметры безопасности серверов в корпоративной сети, а не только ограничивать трафик на брандмауэре.

Необходимо спроектировать политику паролей, политику блокировки учетных записей, настроить права пользователей и прочие доступные параметры безопасности операционных систем серверов. Безусловно, можно настраивать каждый сервер в отдельности, а можно унифицировать процесс. Для этого необходимо спроектировать структуру организационных подразделений в Активном каталоге в зависимости от ролей серверов. Проще говоря, необходимо создать подразделение, в которое поместить сервера, выполняющие одинаковые или сходные функции (например, ОП серверы печати, ОП файловые серверы ). Можно группировать серверы с разными ролями в одно подразделение (например, унифицировано настроить DNS и DHCP-сервера). Затем с помощью оснастки Анализ и настройка безопасности можно создать шаблон с настройками для того или иного организационного подразделения и средствами групповой политики в Активного каталоге привязать его к организационному подразделению.

Вообще, в Windows Server 2003 есть заранее разработанные шаблоны безопасности для различных серверных ролей. Информацию по этим шаблонам можно получить либо в справочной системе, либо физически изучив их параметры, просмотрев их в оснастке Анализ и настройка безопасности. По возможности рекомендуется применять эти базовые шаблоны, лишь по необходимости меняя базовые настройки на собственные.