Лекция Сетевая безопасность. План защиты

Вид материала

Содержание

Front Firewall
Лекция 8. Защита серверных ролей.
Лекция 9. Защита передачи данных внутри сети.
Лекция 10. Отношения доверия в лесах и доменах.
Политики безопасности корпоративной сети

Подобный материал:

1 2 3 4 5

сетевые правила (определяют способ пересылки пакетов между сегментами сети – с помощью NAT или маршрутизации, если способ явно не выбран, то трафик запрещается), правила системной политики (определяют каким образом ISA Server передает данные дальше в сети), правила политики брандмауэра (определяют метод передачи данных между сетями; по умолчанию запрещают весь трафик). Управлять всеми видами правил можно из консоли Управление ISA Server.

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

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

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

разрешен ли протокол для связи;
разрешен ли адрес и порт источника;
разрешен ли доступ данному клиенту в данное время;
разрешен ли целевой ресурс;
прошел ли пользователь аутентификацию;
разрешена ли передача содержимого данного типа.

Связь разрешается, если получены положительные ответы на все вопросы. При попытке ответить на указанные вопросы в порядке очереди проверяются:

набор протоколов;
набор компьютеров или сетей;
расписание доступа;
набор IP-адресов доменных имен и URL;
реквизиты пользователя;
список разрешенного содержимого.

Необходимо обратить внимание, что изменение политик брандмауэра не затрагивает текущие сеансы.

Физическая сетевая топология должная четко отражаться в программных компонентах, защищающих корпоративную сеть, для этого в ISA Server 2004 есть возможность работать с сетевыми шаблонами. Рассмотрим четыре наиболее часто используемых сетевых шаблона.

В случае, если ISA Server отделяет корпоративную сеть от внешнего Интернета и используется как в качестве брандмауэра, так и в качестве сервера кэширования, необходимо использовать шаблон Edge Firewall.

Если на ISA Server установлено три сетевых адаптера, подключенные к внутренней сети, внешней сети и сети периметра соответственно, то необходимо использовать шаблон 3-Leg Perimeter.

В случае, если на границе корпоративной сети последовательно установлены два ISA Server, то нужно использовать два шаблона ^ Front Firewall и Back Firewall. При этом внешний брандмауэр обеспечивает проверку на уровне адресов, а внутренний - на уровне приложений.

Настройка указанных шаблонов сводится к трем этапам. Сначала необходимо указать наборы IP-адресов, соответствующих внутренней сети, внешней сети и сети периметра (последней – в зависимости от шаблона). Дальше необходимо указать IP-адреса ISA Server, подключенные к соответствующим сетям. В конце необходимо выбрать одну из сценариев разрешающих правил, который предоставляет шаблон. Описание предлагаемых сценариев содержит в себе графический мастер, с помощью которого осуществляется настройка указанных шаблонов. Доступ к этому мастеру можно получить из консоли Управление ISA Server. В случае, если потребуется изменить сценарий, можно создать собственные разрешающие правила в шаблоне.

^ Лекция 8. Защита серверных ролей.

Как правило, в сети используются несколько общих ресурсов (приложения, файлы, принтеры) и базы данных. Часто корпоративные сети имеют подключения к Интернету. Ни одна сеть не обходится без базовых механизмов ее организации, таких как службы каталогов, механизмы разрешения имен и адресация узлов. Функционирование и использование вышеперечисленных компонентов обуславливают сервера. В зависимости от типа использования сервера последние разделяют на роли. Всем известно о существовании контроллеров доменов, 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 есть заранее разработанные шаблоны безопасности для различных серверных ролей. Информацию по этим шаблонам можно получить либо в справочной системе, либо физически изучив их параметры, просмотрев их в оснастке Анализ и настройка безопасности. По возможности рекомендуется применять эти базовые шаблоны, лишь по необходимости меняя базовые настройки на собственные.

^ Лекция 9. Защита передачи данных внутри сети.

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

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

Рассмотрим использование политик IPSec в частной сети. Вообще политика – это набор правил, привязанный средствами GPO к определенному участнику безопасности (подразделение, группа, учетная запись). Сами по себе политики IPSec представляют из себя систему фильтров, основанных на адресах, протоколах, номерах портов и прочих элементах сетевого соединения. Фильтры могут блокировать трафик, разрешать его или разрешать подключения в зависимости от установленных правил.

Каждая политика IPSec содержит следующие элементы:

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

При создании той или иной политики рекомендуется опробовать ее в тестовой подсети. Если она успешно работает, то ее можно разворачивать во всей сети. Фильтры можно создавать из оснастки Управление политики IP-безопасности, непосредственно в Активном каталоге или с помощью утилиты Netsh.

При разработке фильтров следует учитывать следующие рекомендации:

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

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

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

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

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

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

При выборе туннельного режима нужно учитывать следующее:

трафик, защищенный IPSec, не требует туннелирования;
для VPN предпочтительнее туннель L2TP, чем туннель на основе IPSec;
в случае, если согласуемая политика настроена на границе сети, лучше использовать туннельный режим.

Для шифрования можно использовать два алгоритма DES и 3DES. Второй алгоритм более надежен, а первый поддерживается большим числом операционных систем. Необходимо помнить, что протокол AH не поддерживает шифрование и для использования обоих алгоритмов необходим протокол ESP. На рынке существуют аппаратные ускорители шифрования. Если требуется передавать большие объемы защищенных данных, то следует рассмотреть вопрос о приобретении таких ускорителей.

Целостность данных обеспечивают протоколы MD5 и SHA1, второй протокол гораздо эффективнее, но очень сильно загружает процессор.

Размер ключа защиты согласования политик зависит от размера группы Диффи-Хеллмана, который может принимать значения 1, 2 и 3. Чем больше размер группы, тем длиннее ключ и тем выше защита, однако больше и время, требуемое для расчета ключа. Если согласование политики требуется для компьютеров только под управлением Windows Server 2003, то размер группы Диффи-Хеллмана следует выбрать равный 3. Для других операционных систем значение этой группы присваивают равное 1 или 2.

При разработке политик IPSec необходимо следовать следующим правилам:

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

^ Лекция 10. Отношения доверия в лесах и доменах.

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

Для того чтобы пользователи различных доменов имели доступ через внутренние границы корпоративной сети между доменами и лесами, необходимо установить отношения доверия. Чтобы построить систему отношений доверия необходимо: задокументировать текущую архитектуру лесов или доменов; определить потребность в доступе к ресурсам во всех имеющихся доменах; выбрать направление доверия; определить ограничение отношений доверия.

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

Доверие бывает следующих типов:

Blog

Лекция Сетевая безопасность. План защиты

Содержание