Лекция 1. Сетевая безопасность. План защиты.
Независимо от объема компьютерной сети проблема защиты информации и
общей сетевой безопасности никогда не потеряет своей актуальности по той
причине, что термин сетевая безопасность включает в себя не только процедуры
защиты информации от хищения или изменения, но и, главным образом, комплекс
мероприятий по предотвращению в сети всевозможных сбоев. Таким образом,
специалист по сетевой безопасности должен владеть не только инструментами по
безопасному хранению и передаче информации, но и адекватно реагировать на
системные сбои.
Как и в любом проекте, при разработке системы безопасности сетевой
инфраструктуры необходимо руководствоваться известным принципом «цель
оправдывает средства». При чем этот принцип необходимо учитывать со всех
сторон. То есть при разработке системы сетевой безопасности необходимо четко
определить цель – защитить автоматические бизнес-процессы, протекающие на
предприятии и, во-вторых, выбрать для решения этой задачи адекватные средства.
Для этого необходимо определить требования руководства предприятия к защите
сети в форме единого документа. В дальнейшем единый документ, согласованный
сторонами, должен быть дополнен планом выполнения поставленных задач.
Анализ поставленных руководством требований к безопасности сети необходимо
проводить, учитывая следующие факторы:
1. сметная стоимость проекта (успешная реализация любого проекта, в т.ч.
связанного с обеспечение сетевой инфраструктуры зависит от реальных
финансовых возможностей предприятия);
2. соответствие системы безопасности требованиям закона (зачастую данные
определенного типа и методы работы с ними подчинены законодательному
регулированию, например, личные данные работников; необходимо, чтобы
проектируемая система безопасности отвечала государственным стандартам по
работе с данными);
1
3. принцип совместимости (проект должен реализовываться «малой кровью» с
максимальным использованием возможностей уже имеющихся на предприятии
систем);
4. принцип масштабируемости (при разработке системы безопасности всегда
необходимо учитывать возможный в будущем рост корпоративной сети);
5. принцип удобства сопровождения (система документирования является
одной из основных частей безопасности, поэтому возможность эффективной
поддержки системы должна быть «поставлена во главу угла»);
6. удобство работы конечных пользователей (в случае если система
безопасности сети внедряется на предприятии управленческим решением, то,
как правило, это вызывает негативную реакцию со стороны конечных
пользователей в силу того, что им приходится отказываться от выработанных
привычек при работе с сетью; негативное отношение персонала может свести
на нет всю проделанную работу, поэтому при разработке и внедрении систем
защиты корпоративной сети с пользователями необходимо вести
разъяснительную работу).
Таким образом, очевидна необходимость проведения аудита уже имеющихся
на предприятии систем, опрос конечных пользователей системы и
интервьюирование руководства предприятия для того, чтобы анализ адекватности
системы безопасности корпоративной сети можно было успешно завершить.
Результатом проведенного анализа должен стать комплект документов,
содержащий описание аппаратных и программных средств, используемых в
корпоративной сети, описание автоматизированных бизнес-процессов, которые
необходимо защитить, классификацию информации, используемой организацией,
характеристику рисков используемой системы и описание влияния сотрудников на
автоматизированную систему. Необходимо выяснить для чего используются те
или иные данные, каков будет ущерб от ошибок или нехватки данных, а также
определить степень конфиденциальности той или иной информации, поскольку
данные разных типов требуют разной степени защиты. В данном случае цена
ошибки или угрозы определяет количество затрат на защиту данных от этих
ошибок и угроз.
2
Не нужно забывать, что одним из самых уязвимых мест в
автоматизированной системе является человек. При разработке системы
безопасности для последующего разграничения прав доступа к ресурсам и
полномочий на действия в корпоративной сети необходимо иметь структурную
схему предприятия и связанную с ней схему прав и полномочий сотрудников с
выделением границ безопасности.
План защиты сети должен состоять из следующих структурных элементов:
1. описание способов профилактики и устранения последствий атак
на корпоративную сеть;
2. применяемые базовые принципы защиты информации;
3. методы моделирования угроз;
4. описание ответных действий при атаке;
5. описание процедуры аварийного восстановления;
6. описание сетевых сегментов.
В этой связи под базовыми принципами защиты информации необходимо
понимать следующее:
1. принцип открытости системы (использование общепринятых
стандартизированных алгоритмов зачастую гораздо лучше и эффективнее, чем
использование малоизвестных или самостоятельно разработанных защитных
алгоритмов);
2. принцип простоты (при взаимодействии с конечным пользователем
система защиты должна быть простой, чтобы не создать путаницу; сложные
механизмы должны быть отделены от пользователя);
3. принцип минимальной уязвимости (в случае если нужно защитить
информацию от копирования, нужно просто снять с системных блоков
пишущие устройства, а не применять сложных прав доступа к ним);
4. принцип наименьших привилегий (по умолчанию все порты и доступ
к файлам для пользователей закрыты, сами пользователи разделены на группы
и получают минимальных набор прав, необходимый для выполнения их
производственных функций);
3
5. принцип контроля (всегда необходимо контролировать состояние
системы, поддерживая ее техническое состояние на актуальном уровне, при
этом также необходимо контролировать поведение администратора системы с
помощью аудита, не забывая, что человек является слабым звеном в системе).
При разработке плана защиты около 30 процентов времени необходимо
выделять моделированию угроз. В конечном итоге это снизит риск уязвимости
системы. Процесс моделирования угроз необходимо проводить следующим
образом:
1. сформировать команду по моделированию (в нее должны входить
специалисты, имеющие опыт работы с внедряемым оборудованием и
программным обеспечением);
2. использовать данные анализа, проведенного на предыдущих этапах
построения концептуального плана защиты (на этой стадии выявляются
недостатки собранной и разработанной к данному моменту документации);
3. поиск угроз (обсуждаются и прорабатываются все высказанные
варианты атак с указанием степени их опасности и разработкой плана реакции
на каждую из угроз);
4. выбор механизмов и методов предотвращения смоделированных
угроз (при выборе технических средств необходимо учитывать их
совместимость с уже имеющимися в корпоративной сети устройствами и
программами. После проведения аудита имеющихся систем необходимо иметь
список их технических ограничений для того, чтобы можно было в полной
мере использовать возможности нового оборудования и программ и во
избежание конфликтов новых систем с уже имеющимися).
После выбора технических средств реализации системы безопасности
необходимо позаботиться о трех важных аспектах, два из которых являются
техническими (спланировать процедуры восстановления и обсудить
возможность сегментирования сети), а третий – психологический (это публичная
реакция на атаку корпоративной сети).
Разделение сети на обособленные сегменты должно обеспечивать
соответствие ее физической и логической инфраструктур. Компьютеры,
4
выполняющие сходные задачи должны объединяться в группы. Разным группам
компьютеров в зависимости от их задач требуется разная степень защиты,
реализуемая разными механизмами. Сегментированная сеть понятнее в
администрировании, т.к. разные администраторы четко знают пределы своей
ответственности.
Процедуры экстренного восстановления нельзя сбрасывать со счетов,
поскольку часто от скорости восстановления системы после сбоя зависит
количество убытков организации. Поэтому при разработке плана защиты сети
необходимо утвердить стратегию архивации, создать специальную группу
администраторов, занимающихся восстановлением.
Что касается психологического аспекта, необходимо учесть, что активное
внедрение в сознание пользователей информации о защите системы почти столь
же эффективно, как и непосредственное наличие этой системы защиты. В случае
обнаружения атаки на корпоративную сеть и ее успешного отражения,
необходимо доводить информацию об этом до сведения сотрудников. Подобная
информация остановит большинство внутренних атак на сеть, которые могли быть
предприняты сотрудниками предприятия.
5
Лекция 2. Службы сертификации и их применение.
В концептуальном плане защиты корпоративной сети предприятия
необходимо уделять внимание многим аспектам, в том числе защите логической и
физической инфраструктуры сети в отдельности, и этим двум элементам в
совокупности. Под логической инфраструктурой сети, как правило, понимают
набор программных компонент, использующихся в сети и обеспечивающих ее
функционирование. Основными элементами, требующими защиты в данном
случае, является целостность данных и возможность контроля данных об
отправителе в момент их приема. Решить обе эти задачи возможно с помощью
механизма электронной цифровой подписи (ЭЦП). Определенные значения,
используемые в этом механизме хэш-функции, говорят о том, изменялись ли
данные с момента их создания и кем были проведены данные изменения.
В Windows Server 2003 реализовать механизм ЭЦП можно с помощью служб
сертификации. Сертификаты являются одним из элементов системы Открытых
ключей (PKI). Эта система позволяет контролировать не только целостность
информации и аутентифицировать отправителя и получателя, но и обеспечивает
конфиденциальность информации с помощью шифрования. Рекомендация по
использованию PKI одна - ее нужно использовать при любой возможности (для
опознавания пользователей, компьютеров, шифрования данных, при передаче их
по VPN и пр.).
Может показаться, что PKI – панацея от несанкционированного доступа к
данным. В действительности имеется ряд трудностей при внедрении этой системы
на предприятии в эксплуатацию: сложная техническая настройка, дополнительное
вложение на приобретение лицензии и необходимость постоянного аудита сбоев.
В случае если для компании перечисленные аспекты не представляют трудностей,
система Открытых ключей и цифровых сертификатов будет представлять собой
мощнейшую систему защиты информации.
Система Открытых ключей состоит из центров сертификации (ЦС),
выстроенных в иерархическую структуру; политики применения сертификатов;
собственно цифровых сертификатов.
6
Центр сертификации – это служба, отвечающая за выдачу сертификатов
пользователям, компьютерам или организациям. Каждый сервер под управлением
WS2003 может выполнять роль ЦС. С точки зрения серверной роли ЦС может
быть корневым или подчиненным. Корневой ЦС сам себе выдает сертификат, а
подчиненный получает его от другого ЦС (не обязательно от корневого). Центры
сертификации могут интегрироваться в домен, а могут быть изолированными от
домена. ЦС могут выстраиваться в многоуровневую иерархию, на вершине
которой находится корневой ЦС, выдающий сертификаты центрам сертификации
первого уровня. Центры сертификации первого уровня выдают сертификаты
центрам сертификации второго уровня. Последние выдают сертификаты
конечным пользователям, компьютерам и службам. Данная иерархия является
трехуровневой. В этом случае ЦС второго уровня называются промежуточными,
а ЦС третьего уровня – выдающими. В зависимости от типа компании и структуры
ее сети в иерархии ЦС может отсутствовать второй уровень. Но в любом случае,
иерархия ЦС не должна иметь меньше двух уровней, т.к. если корневой ЦС будет
выдавать сертификаты конечным пользователям, это снизит общую безопасность
сети.
В зависимости от физического расположения ЦС иерархия этой структуры
может быть: географической (корневой ЦС в главном офисе, выдающие – в
филиалах; при этом промежуточные сервера могут быть размещены по одному
для нескольких филиалов), организационной (корневой ЦС – в отделе
управления, выдающие ЦС – в обособленных структурных подразделениях),
комбинированной (для организации с географически удаленными филиалами,
имеющие обособленные структурные подразделения).
В любом случае, при проектировании иерархии ЦС необходимо
руководствоваться следующими рекомендациями:
1. корневой ЦС не интегрировать в домен и не держать постоянно
подключенным к сети;
2. по возможности ограничить доступ к корневому ЦС, лучше держать его
в закрытом сейфе и подключать к сети только по необходимости;
7
3. по возможности разрешить выдающим ЦС выдачу сертификатов только
отдельных типов (например, один сервер выдает сертификаты для смарт-карт,
второй – для шифрования и т.д.).
Цифровой сертификат – это набор данных, позволяющий поставить
открытый ключ с объектом, имеющим соответствующий закрытый ключ. В этом
наборе содержатся следующие данные: имя владельца; имя ЦС, выдавшего
сертификат; подпись ЦС, выдавшего сертификат; задачи, для которых
используется сертификат и копия открытого ключа. Сертификаты могут
выдаваться для следующих целей: для идентификации контроллера домена, для
проверки подлинности сервера, для подписи сертификата и списка отозванных
сертификатов, для шифрования в IPSec и для EFS.
Вне зависимости от задачи, для которой выдан сертификат, механизм
проверки подлинности основан на механизме построения цепочки сертификатов,
который включает в себя следующие шаги:
1. ЦС подписывает все выданные им сертификаты своим закрытым
ключом, а открытый ключ ЦС позволяет установить факт выдачи указанного
сертификата данным ЦС (при наличии в иерархии только корневого ЦС все
сертификаты указывают только на него; в двухуровневой иерархии открытый
ключ выдающего ЦС используется для проверки подписи сертификата
пользователя, а открытый ключ корневого ЦС – для проверки подписи
сертификата выдающего ЦС; при трехуровневой иерархии в этой системе
появляется еще одно дополнительное звено);
2. Построенная на первом шаге цепочка сертификатов будет
действительной, если она оканчивается на доверяемом корневой ЦС – таком
ЦС, информация о котором присутствует в хранилище сертификатов
компьютера, производящего проверку сертификата конечного пользователя;
3. Если цепочку сертификатов не удается построить до доверяемого
корневого ЦС, то ей (а значит и полученным данным) доверять нельзя. Однако
надежность того или иного центра сертификации может быть подтверждена
самим пользователем.
8
Если цепочка сертификатов разорвана, это значит, что, либо нет нужных
данных в хранилище сертификатов компьютера, либо на каком-то шаге
построения цепочки был обнаружен отозванный сертификат. Все отозванные
сертификаты образуют так называемый список отзыва сертификатов (CRL).
Основная идея использования сертификатов в том, что на предприятии
создается собственная система, позволяющая в любой момент отследить
подлинность информации и участников безопасности. При использовании
длинных шифровальных ключей эту систему практически невозможно взломать,
однако пользователи должны доверять только той информации, которая имеет
действительный сертификат, вся остальная информация и соединения
автоматически отклоняются. Это значит, что необходимы механизмы для выдачи
и контроля над актуальностью сертификатов.
Заявки на сертификаты можно подавать для самих центров сертификации и
для конечного пользователя вручную или автоматически.
Заявка на сертификат для пользователя может быть подана через браузер или
специальную оснастку Сертификаты. Заявка для ЦС формируется при его
установке. В обоих случаях необходимо указывать ЦС, выдающий сертификат и
цели его использования. В зависимости от настройки ЦС сертификат выдается
либо сразу, либо после подтверждения заявки администратором, либо после того,
как он сгенерирован на изолированном ЦС. В случае если заявка одобрена,
сертификат помещается в хранилище сертификатов, на сервере запускаются
службы сертификации, а клиенты могут осуществлять необходимые действия.
Если в системе ЦС настроены специальные шаблоны сертификатов возможна
автоматическая подача заявок на них. Для этого администраторы ЦС должны
настроить соответствующие политики распространения сертификатов на ЦС.
Подача заявки заканчивается либо установкой сертификата, либо отказом в его
выдаче. В любом случае до начала функционирования автоматической системы
подачи заявок на сертификаты необходимо настроить процедуру распространения
сертификата корневого ЦС через сведения о центрах сертификации в домене, и
процедуру распространения CRL корневого ЦС.
9
При выдаче сертификата устанавливается срок его действия. После истечения
этого срока выполнение задач, для которых был выдан сертификат, становится
невозможным. В этом случае сертификат можно продлить путем направления
нового запроса в ЦС. В случае если обновление сертификатов происходит
автоматически, необходимо проверять подлинность подавшего заявку о
продлении сертификата.
В зависимости от задач сертификаты могут действовать в течение пяти лет, но
как правило, сертификаты выдаются на год. Однако в течение этого времени
администратор может отозвать любой выданный ЦС сертификат и поместить
информацию о нем в CRL. При этом необходимо учесть, что на центрах
сертификации публикуются разностные CRL (содержащие информацию об
отозванных сертификатах с момента опубликования полных CRL). Далеко не все
приложения могут работать с разностными CRL. Поэтому администратору ЦС
необходимо публиковать на соответствующих серверах полный CRL как можно
чаще и следить за этой процедурой постоянно.
Размещение ЦС, политики подачи заявок и контроля отозванных
сертификатов должны быть утверждены административным решением на
предприятии. Неукоснительное следование этим решениям позволит клиентам
корпоративной сети общаться только с доверенными пользователями и
использовать неизмененную во время передачи информацию. Проектировщику
системы безопасности при разработке указанных документов необходимо
учитывать множество параметров как, то привилегии учетных записей
пользователей на запрос сертификатов, сроки действия сертификатов, иерархию
ЦС, методы кэширования CRL, время распространения информации по сети и пр.
Хотя WS2003 предоставляет администратору консоли Центр сертификации и
Сертификаты, упрощающие первичную настройку, проектированию системы
открытых ключей на предприятии необходимо уделить не менее 25% рабочего
времени и трудозатрат.
10
Лекция 3. Защитные экраны.
Защита границ корпоративной сети предприятия от внешних угроз, контроль
входящего и исходящего Интернет трафика и маршрутизация внутри локальных
подсетей являются важными элементами системы безопасности. С каждым разом
угроза заражения данных вирусами и уровень хакерских атак на сеть возрастают, а
нерадивые пользователи стремятся «обойти» установленные ограничения. Решить
задачи по контролю маршрутизации пакетов можно с помощью
профессиональных программных брандмауэров.
Одним из таких решений является Microsoft Internet Security and
Acceleration Server 2004 (ISA Server). Этот брандмауэр может контролировать
сетевой трафик на пяти уровнях стека протоколов TCP/IP, кроме канального и
физического уровней. Он способен контролировать не только заголовки пакетов,
но и раскрывать их содержимое, анализировать скрытую информацию. Этой
системой также, безусловно, поддерживается контроль адресов пакетов.
ISA Server можно использовать не только как внешний сетевой экран, с
помощью которого корпоративная сеть отделяется от Интернета, но также и как
контролер Интернет-трафика во внутренней сети. Также ISA Server можно
использовать в качестве прокси. Он способен кэшировать содержимое внешних
web-узлов. При этом их содержимое будет сохраняться в локальной сети. В
случае повторного обращения пользователей к внешнему web-серверу ответ даст
ISA Server компании, что существенно разгрузит внешний канал связи. Его кэш
достаточно производителен, т.к. содержимое сохраняется не только на жестких
дисках, но и в оперативной памяти сервера. При этом сам кэш представляет собой
единый индексированный файл, что существенно ускоряет поиск нужной
информации. Кэшировать объекты можно по расписанию.
Это полезно если клиенты корпоративной сети часто пользуются одним и тем
же сайтом, информация на котором меняется. В этом случае ISA Server может
загружать новую версию сайта раз в несколько минут, предоставляя
пользователям максимально адекватную времени информацию. В случае если на
предприятии используются несколько ISA Serverов, между ними можно
распределить задачи по кэшированию.
11
Располагая ISA Server на границе корпоративной сети и внешнего Интернета,
можно использовать его как брандмауэр. В этом случае внешний адрес
присваивается только ISA Server, который проводит безопасную идентификацию
внешних пользователей и осуществляет их связь с внутренними серверами
компании. При этом внутренние серверы компании не видны из Интернета, но
прошедшие проверку пользователи могут получить доступ к их сервисам.
Как брандмауэр ISA Server поддерживает множество фильтров, пакетов,
каналов и приложений, что позволяет дать доступ только к явно указанным
ресурсам в случае необходимости. Используя комбинацию фильтров можно
защитить данные даже тогда, когда протоколы, по которым происходит связь,
сами по себе являются небезопасными. Также брандмауэр способен определять
вторжение в автоматическом режиме по заранее заданным шаблонам.
ISA Server имеет очень гибкий инструмент по настройке внутренней и
внешней сетевой топологии. Этот элемент является важным, т.к. позволяет
отделить внутренние сети от внешних и применять различные политики доступа к
различным сетевым сегментам. Компьютеры объединяются в группы в
соответствии с диапазонами адресов, что позволяет в настройках ISA Serverа
создать максимально точную модель корпоративной сетевой топологии. Поэтому
можно управлять потоками данных не только между внутренней сетью и внешним
Интернетом, но и между отдельными сетевыми сегментами предприятия.
ISA Server 2004 поставляется в двух вариантах: Standard Edition и Enterprise
Edition. ISA Server Standard Edition также входит в комплект поставки Small
Business Server Premium Edition. Версии продукта отличаются друг от друга
возможностью масштабирования и интеграции с Активным каталогом. В
дальнейшем мы будем рассматривать ISA Server 2004 Enterprise Edition, которая
поддерживает до 25 серверов в одном массиве, поддерживает технологию
балансировки сетевой нагрузки (NLB), возможность управления несколькими
серверами централизованно и полную интегрируемость в Активный каталог.
С точки зрения аппаратных требований этот программный продукт
поддерживает процессоры от 1 ГГц, оперативную память от 512 Мб,
неограниченное число сетевых адаптеров и не менее двух выделенных разделов
12
дисковой системы. Следует отметить, что ISA Server не является самостоятельной
операционной системой и устанавливает поверх Windows Server 2003.
Важным аспектом является лицензирование ISA Server. Отличительной
чертой является необходимость лицензии на каждый используемый в системе
процессор. Поэтому при модернизации процессоры выгоднее заменять более
быстрыми, а не увеличивать их число. Однако для многоядерных процессоров
достаточно одной лицензии.
Управлять возможностями ISA Server и проводить его настройку можно с
помощью множества мастеров и консоли Управление ISA Server. ISA Server
поддерживает средства удаленного администрирования.
13
Лекция 4. Установка ISA Server 2004.
Перед установкой ISA Server 2004 необходимо напомнить, что этот
программный продукт и не является самостоятельной операционной системой и
может быть установлен на компьютер только под управлением WS2003 или более
поздней операционной системы. Перед установкой необходимо загрузить все
важные обновления операционной системы, а также проверить работоспособность
сетевых адаптеров, установленных на компьютере, где предполагается установка
ISA Server. На внутренних сетевых адаптерах должны быть настроены
статические адреса. Все подключения удаленного доступа, которые планируется
использовать, должны быть сконфигурированы до установки ISA Server. Также
необходимо учесть, что после установки ISA Server будут отключены следующие
серверные службы: ICS/ICF, NAT, SNMP, FTP, NNTP, IIS, WWW.
Нужно помнить, что внутренние сетевые адаптеры ISA Server не имеют
шлюза по умолчанию, поэтому для обеспечения связи ISA Server с внутренней
сетью необходимо корректировать таблицу его маршрутизации.
ISA Server необходимо размещать на отдельном компьютере, не перегружая
его другими серверными ролями. Крайне не рекомендуется запускать ISA Server
на контроллере внутреннего домена организации. Если ISA Server планируется
использовать в качестве брандмауэра, эффективнее установить его в составе
рабочей группы или в отдельном домене.
Для автоматической установки можно использовать разработанные сценарии
развертывания. В зависимости от стратегии внедрения ISA Server существуют
сценарии развертывания для рабочей группы, для филиала компании и для службы
каталогов Active Directory.
Для успешной работы ISA Server необходим еще один сервер, выполняющий
специальную роль хранения конфигурации ISA Server (CSS). Наличие этого
сервера увеличивает безопасность системы и делает ее более гибкой. Наличие
специального сервера хранения более не делает необходимым интеграцию
конфигурационной информации ISA Server в Активный каталог, а это позволяет
установить ISA Server в рабочую группу, что повышает безопасность сети.
14
Установить CSS можно с помощью специального мастера с установочного
диска ISA Server. CSS также устанавливается на компьютер, находящийся под
управлением WS2003 или старше. Нюанс заключается в том, что даже для
установки ISA Serverа, как сервера кэширования, необходимо приобрести не
только сам ISA Server, но и две копии WS2003, что делает систему достаточно
дорогой. Теоретически и сам ISA Server и CSS можно поставить на контроллер
домена (тем самым не приобретая отдельных копий WS2003), но делать это
крайне не рекомендуется.
Необходимо обеспечить бесперебойную связь CSS и ISA Server. Для этого
предусмотрена технология ADAM. Установить ее компоненты можно с
установочного диска ISA Server 2004. После установки в системной папке
Windows создается системная папка ADAM. Из нее нужно запустить программу
ldp.exe. С помощью нее можно установить соединение между CSS и ISA Server.
Для этого в настройках соединения в этой программе необходимо ввести полное
доменное имя CSS-сервера и изменить значение базового порта с 389 на 2171 или
2172. Первый порт используется, если используется встроенная аутентификация
Windows. Второй порт используется, если на предприятии внедрена система
открытых ключей. Необходимо еще раз обратить внимание, что эта процедура
должна быть выполнена на том компьютере, где предполагается установить ISA
Server.
После всего этого можно приступать непосредственно к установке ISA Server
2004. После запуска одноименного мастера с установочного диска необходимо
следовать его инструкциям, в нужный момент указав адрес CSS-сервера,
используя по необходимости имеющиеся сертификаты, задав диапазоны
внутренних адресов и определив политику предприятия.
Установку ISA Server можно автоматизировать, используя пять
предустановленных конфигурационных файлов, находящихся в папке FPC на
установочном диске (InstallNewManagementServer.ini – установка сервера CSS,
InstallStandAloneServer.ini – установка ISA Server и сервера CSS,
InstallArrayAndServer.ini – установка ISA Server и создание нового массива,
InstallJoinedServer.ini – установка ISA Server и присоединение его к заданному
15
массиву, UninstallServer.ini – отмена установки). Необходимо отредактировать
желаемые параметры в этих файлах, а потом, запустив их выполнение из
командной строки, имеющей следующий синтаксис:
“Путь_к_ISASetup\setup.exe” [/[x|r]] /v /q[b|n] FULLPATHANSWERFILE= “\
Путь_к_файлу_конфигурации\Имя_файла\”.
Ключи команды следующие: \r – автоматическая установка, \x – автоматическое
удаление, \v – обязательный параметр для установки, необязательный для
удаления, \q[b|n] – тип «тихой» установки (b – с диалоговыми окнами, n – без
диалоговых окон). Для автоматического восстановления можно использовать
команду PathToISASetup\setup.exe REINSTALL=ALL.
Во избежание проблем при установке ISA Server необходимо помнить, что
установка возможна только от имени учетной записи администратора сервера;
автоматическая установка невозможна, если на компьютере уже установлен ISA
Server 2000. При использовании конфигурационных файлов необходимо
заключать полный путь к ним в косые черты и кавычки. Удаленную установку
необходимо производить, используя удаленный рабочий стол, а не сервер
терминалов.
Выше была описана установка ISA Server в домене. Чтобы установить ISA
Server в рабочей группе необходимо, во-первых, создать сертификат сервера и
позаботиться о централизованной аутентификации (например, использовать
RADIUS). Во-вторых, определиться с «видом рабочей группы»: можно установить
CSS-сервер в домене, а ISA Server в рабочей группе, CSS и ISA Server в рабочей
группе, а можно создать два массива ISA серверовов (один в составе рабочей
группе и подключен к внешнему Интернету, а второй включен в корпоративный
домен и обслуживает корпоративную сеть). Оба массива связаны сетью
периметра. Третий вариант представляет собой самый безопасный из возможных,
и при достаточном финансировании именно он рекомендуется к использованию. В
целом, использование ISA Serverов в составе рабочих групп наряду с
корпоративным доменом гораздо безопаснее, чем интеграция брандмауэра в
домен, но требует настройки системы открытых ключей и дополнительных
финансовых затрат на программное обеспечение.
16
После установки ISA Server необходимо помнить, что весь трафик через все
протоколы и порты по умолчанию запрещен, а изменять настройки ISA Server
могут только пользователи с административными привилегиями. Причем
существуют две схемы административных ролей: администраторы предприятия
и администраторы массива. Администраторы предприятия получают доступ ко
всем ISA серверам, а администраторы массива имеют полномочия только в
пределах своего массива.
Существуют две роли администраторов предприятия: Enterprise Auditor
(просматривает настройки предприятия и массивов) и Enterprise Administrator
(неограниченный доступ к настройке любых параметров ISA Server).
Существуют три роли администраторов массивов: Monitoring Auditor
(позволяет просматривать настройки и осуществлять заранее заданный
мониторинг ISA Server, но не позволяет менять настройки мониторинга), Auditor
(позволяет просматривать политики брандмауэра, создавать отчеты и управлять
внутренними службами, включает в себя полномочия роли Monitoring Auditor),
Administrator (не ограниченный доступ к настройкам в пределах массива).
17
Лекция 5. Установка и настройка клиентов ISA Server 2004.
В зависимости от доступа к ISA Server и ресурсам на нем или за ним
выделяют три клиента ISA Server:
1. клиент брандмауэра (направляет запросы в службу брандмауэра в ISA
Server, поддерживает много протоколов);
2. Web-прокси (направляет запросы протоколов FTP, HTTP, HTTPS в
службу брандмауэра на ISA Server);
3. SecureNAT (на клиентском компьютере осуществляет маршрутизацию
запросов на ISA Server путем выбора последнего в качестве основного
шлюза).
Клиенты ISA Server отличаются друг от друга сложностью настройки,
встроенными возможностями и реализуемым уровнем безопасности. Если ISA
Server используется как сервер кэширования, на клиентах необходимо настроить
Web-прокси. Если нужна простая маршрутизация без аутентификации и контроля
над действиями пользователей, то нужно применять SecureNAT. Если нужна
максимальная безопасность и поддержка различных протоколов, на компьютерах
необходимо установить клиент брандмауэра.
В зависимости от потребности сети клиенты ISA Server можно комбинировать
друг с другом вплоть до установки на одном компьютере всех трех клиентов. При
этом необходимо помнить, что если используются операционные системы помимо
Windows, то клиент брандмауэра работать не будет, и не зависимо от типа клиента
ISA Server все запросы по протоколу HTTP обрабатывает так, как если бы они
поступили от клиентов Web-прокси.
Рассмотрим установку и настройку клиентов по возрастанию ее сложности.
Чтобы установить на компьютере SecureNAT достаточно в настройках протокола
TCP/IP клиентского компьютера в поле «Основной шлюз» ввести адрес
внутреннего адаптера ISA Server или маршрутизатора, на котором имеется
маршрут к ISA Server. В случае, если в сети для адресации используется DHCP-
сервер, для настройки SecureNAT необходимо в параметрах DHCP-сервера или в
параметрах области настроить параметр 003 Router, присвоив ему значение
внутреннего адреса ISA Server.
18
SecureNAT не поддерживает аутентификацию клиентов. Поэтому
ограничивать доступ к сетевым ресурсам можно только на основании адреса
компьютера. На этом настройка SecureNAT завершается. При работе с клиентами
такого вида необходимо контролировать внутренний адрес ISA Server. И если он
изменился, изменять адреса основного шлюза на клиентских компьютерах. Также
необходимо учитывать, что клиенты SecureNAT разрешают имена при помощи
DNS. Поэтому если такому клиенту не удается подключиться к какому-либо
ресурсу, необходимо проверить настройки DNS и связь клиента с ISA Server.
Клиенты SecureNAT поддерживаются большинством операционных систем и
браузеров.
Клиент Web-прокси работает в любой операционной системе и с любым
браузером, поддерживающим технологию HTTP1. Этот клиент поддерживает
четыре протокола: HTTP, HTTPS, FTP, Gofer. Этот клиент поддерживает
аутентификацию пользователей. Поэтому ограничить доступ к отдельным
ресурсам можно для отдельных учетных записей.
Для настройки Web-прокси на клиенте необходимо настроить свойства
соединения в браузере. Для этого необходимо указать адрес proxy-сервера и порт,
по которому осуществляется соединение. Причем эти настройки должны
совпадать с настройками на самом ISA Serverе.
На ISA Server Web-прокси, как правило, настраивают во внутренних сетях и
сети-периметра. Для включения Web-прокси на сервере необходимо в консоли
Управление ISA Server выбрать нужную сеть и в ее свойствах поставить значок
напротив параметра «включить клиент Web-прокси» и указать соответствующий
номер порта. В случае, если в организации внедрена система Открытых ключей,
можно установить поддержку SSL. В противном случае для аутентификации
клиентов предусмотрено еще четыре вида технологий (простая, встроенная
Windows, RADIUS, встроенная с проверкой). Клиентский компьютер можно
настраивать как вручную, так и с помощью групповых политик (если сеть
построена на основе доменов).
Проблемы при использовании Web-прокси чаще всего связаны с состоянием
службы Microsoft Firewall (эту службу нужно перезапустить, если на ISA Server
19
установили новый сетевой адаптер, если клиенты теряют подключение к ISA
Server, надо проверить кабели и работоспособность самого подключения
командой Ping). Напомним, что настройки портов для использования Web-прокси
на ISA Server и на клиентских компьютерах должны быть одинаковыми.
Перейдем к работе с клиентом брандмауэра. Установка клиента брандмауэра
состоит из трех частей: создание для него общего ресурса, установки на
клиентских компьютерах и настройки.
Создать общий ресурс для клиента брандмауэра можно либо на ISA Server,
либо на другом сервере, что предпочтительнее. При этом на внутреннем
интерфейсе ISA Server рекомендуется отключить общий доступ к файлам и
принтерам. Для создания общего ресурса необходимо запустить установку ISA
Server с компакт-диска, выбрать выборочную установку и установить клиент
брандмауэра на жесткий диск. При этом на системном диске будет создана папка
MSPCLNT. С клиентских компьютеров необходимо зайти в эту папку и запустить
программу setup. В домене клиент брандмауэра можно распространить в сети с
помощью групповой политики.
После этого можно переходить к настройке брандмауэра на ISA Server и
клиентских компьютерах. На ISA Server необходимо включить поддержку клиента
брандмауэра для необходимых наборов сетей, настройки же клиента брандмауэра
осуществляются аналогично Web-прокси. Также можно настроить обход
настройки для локальных доменов и разрешить прямой доступ к определенным
Web-сайтам и приложениям. Также необходимо помнить, что для правильной
работы клиента брандмауэра на ISA Server должны быть открыты TCP и UD
порты 1745.
Для настройки клиента брандмауэра на локальном компьютере существует
специальный графический интерфейс, доступ к которому можно получить,
щелкнув на специальный значок в системном трее (он появится там после
установки брандмауэра).
Также можно настроить четыре конфигурационных файла, находящихся в
профиле текущего пользователя и в общих настройках для всех пользователей
(файлы профиля пользователя перекрывают общие настройки). Имя ISA Server и
20
параметры его автообнаружения настраиваются в файле common.ini. Параметры
отображения значка брандмауэра в области уведомлений и возможность
автоматического определения параметров Web-прокси настраиваются в файле
management.ini. Параметры работы приложений и параметры обработки
специальных видов трафика для конкретного клиента настраиваются в файле
application.ini. Диапазоны внутренних сетей для клиента брандмауэра можно
настроить в файле locallat.txt.
21
Лекция 6. Мониторинг ISA Server 2004.
Контроль за работоспособностью самого ISA Server представляет собой
важную задачу, поэтому необходимо осуществлять мониторинг важных служб и
подсистем ISA Server. Из консоли Управление ISA Server можно следить за
информацией о количестве и состоянии сеансов, состоянии служб, трафике,
проходящем через ISA Server, конфигурации элементов массива, к которому
подключен ISA Server, а также получать информацию о предустановленных и
созданных администратором оповещениях. Указанную информацию можно
получить на соответствующих вкладках узла Мониторинг в консоли Управление
ISA Server. По умолчанию частота обновления информации 60 секунд. Можно в 2
раза уменьшить или увеличить эту частоту.
Перейдем к рассмотрению названных компонентов мониторинга более
подробно. Оповещение – возможность отправки сообщений администратору о
том, что произошло какое-то событие или превышено пороговое значение того
или иного счетчика. ISA Server содержит 56 предустановленных оповещений.
Можно создавать собственное оповещение. Реакцией на оповещение может быть
одно из пяти действий: отправка сообщения администратору по электронной
почте, запуск программы, запись в системном журнале, запуск / остановка
службы ISA Server.
Оповещение создают с помощью специального Мастера, который позволяет
выбрать условия и события, которые будут приводить к срабатыванию
оповещения, сервер, на котором будет применять оповещение, степень его
важности и тип реакции. Следует учесть, что если в качестве реакции выбрана
отправка сообщения по электронной почте, то следует использовать почтовый
сервер в локальной сети, т.к. трафик внешнему серверу может быть запрещен
брандмауэром.
В случае, если в качестве реакции выбран запуск той или иной программы,
необходимо будет указать реквизиты учетной записи пользователя, от имени
которого программу можно запустить. Найдя и проанализировав причину
срабатывания оповещения, его (оповещение) нужно сбросить или подтвердить.
Сброс оповещения означает стирание информации о нем из системного журнала, а
22
подтверждение этого оповещения делает информацию о нем доступной для
других администраторов.
Наиболее эффективным средством мониторинга является создание записей в
системном журнале и последующее их изучение. По умолчанию события
регистрируются в журналах службы Microsoft Firewall, Web-прокси и SMTP
Massage Screener. Эти журналы могут представлять собой текстовые записи, а два
первых могут быть частью базы SQL сервера. Просматривать эти журналы можно
из консоли Управление ISA Server, в которой для облегчения поиска записей
предусмотрена удобная система фильтрации. Также некоторые события ISA Server
как серверной роли регистрируются в журнале Система ОС Windows Server 2003,
который можно просмотреть с помощью утилиты Просмотр событий. На
основании информации из журналов администратор может создавать отчеты о
статистике работы сервера. Отчеты можно формировать вручную или
автоматически.
Работоспособность ISA Server обеспечивают следующие службы:
Microsoft ISA Server Control (отвечает за срабатывание оповещений,
обеспечивает обновление конфигурации элементов массива и управляет
перезапуском других служб);
Microsoft Firewall (обрабатывает запросы клиентов ISA Server, при остановке
этой службы ISA Server блокируется службой Firewall Engine);
Microsoft ISA Job Scheduler (по расписанию кэширует информацию о Web-
серверах);
ISA Server Storage (управляет чтением и записью информации в локальном
хранилище конфигурации);
Firewall Engine (управляет трафиком через брандмауэр. Если она
остановлена, то разрешен любой трафик.);
Microsoft Data Engine Service (управляет базой данных журналов ISA
Server);
Network Load Balancing (распределяет сетевую нагрузку в массиве ISA
Serverов);
Remote Access Service (обеспечивает функционирование VPN).
23
Управлять службами можно как из консоли Управление ISA Server, так и с
помощью стандартной консоли Службы, находящейся в Панели инструментов.
Информацию о количестве и типах подключений к ISA Server можно
получить, управляя сеансами. О сеансах можно получить не только развернутую
информацию (имя пользователя, установившего сеанс, время сеанса, IP-адрес
компьютера, тип клиента и прочее), но и фильтровать, а при необходимости и
разъединять сеансы.
Для оценки производительности ISA Server существует специальная
одноименная консоль. В ней в режиме реального времени можно отслеживать
состояние различных параметров работы сервера в зависимости от выбранных
счетчиков производительности. Встроенных счетчиков масса. Все они разбиты по
группам в зависимости от контролируемых объектов. Особо нужно
контролировать следующие объекты: ISA Server Cache (содержит счетчики
наблюдения за кэшем, например, общее число Интернет-адресов) , ISA Server
Firewall Packet Engine (содержит счетчики брандмауэра, например, число
отброшенных пакетов), ISA Server Firewall Service (счетчики наблюдения за
сеансами), ISA Server Web Proxy (счетчики для контроля клиентов Web-прокси).
Следить за счетчиками в режиме реального времени эффективно при
соблюдении следующих условий:
1. есть предположение о проблемном элементе в работе системы;
2. для данного элемента сформирована «базовая линия».
Первое условие позволит выделить конкретные счетчики для анализа.
Базовая линия – это набор показаний счетчиков при нормальной работе системы.
Данные показания будут служить эталоном для последующего сравнения с ними
текущих показаний счетчиков. Поэтому соблюдение второго условия позволит
ответить на вопрос: действительно ли наблюдаемый элемент системы является
проблемным?
24
Лекция 7. Сетевые шаблоны.
Для управления трафиком между сегментами на ISA Server необходимо
настроить несколько базовых объектов: протоколы, наборы пользователей,
фильтры содержимого пакетов и сетевые компоненты. Среди последних можно
выделить диапазоны адресов, подсети, наборы компьютеров, наборы допустимых
имен, ссылок и прослушивателей. Причем можно настраивать как разрешенные,
так и запрещенные объекты. Настройка указанных компонентов осуществляется с
помощью графических Мастеров и выполняется в зависимости от потребности
организации и сетевой топологии. Указанные объекты могут быть сгруппированы
по категориям. Например, это касается протоколов – языков обмена данными
между компьютерами. Можно осуществлять настройку каждого протокола в
отдельности или целой категории протоколов. Для фильтрации и перенаправления
трафика в зависимости от пользователя, осуществляющего прием или передачу,
нужно сконфигурировать набор пользователей по аналогии с группой
пользователей в Активном каталоге.
Безусловно, особый интерес представляют возможные источники и
получатели трафика на уровне сетевого интерфейса. Для контроля над ними
необходимо настраивать сетевые объекты. Сети разделяются на четыре вида:
локальную (включает IP-адреса самого ISA Server), внутреннюю (включает все
IP-адреса, связанные с внутренним сетевым адаптером), внешнюю (включает все
ненастроенные IP-адреса, изменить ее вручную нельзя), клиентов VPN
(создаются автоматически при подключении удаленного клиента).
Сети можно объединять в наборы, чтобы управлять ими совместно. В случае,
если в корпоративной сети используется несколько коммутационных устройств,
причем часть из них не подключена ко внутреннему адаптеру ISA Server
непосредственно, для управления трафиком в них нужно использовать
специальный объект – Подсеть.
В случае если в сети существуют компьютеры, для которых необходимы
особые правила регулирования сетевого трафика, то необходимо управлять их
единичными IP-адресами. Ими управляют с помощью специального объекта,
который называется Компьютер. Из Компьютеров можно создавать наборы.
25
Для управления трафиком в зависимости от Web-адреса удаленного узла или
от его имени можно создавать наборы URL и доменных имен, а также задать IP-
адреса и номера портов, на которых ISA Server прослушивает Web-запросы с
помощью Прослушивателей.
После создания базовых объектов можно начинать управлять трафиком. В
ISA Server обработка трафика осуществляется на основе определенной политики
брандмауэра, которая состоит из правил трех уровней, применяемых
последовательно: сетевые правила (определяют способ пересылки пакетов
между сегментами сети – с помощью NAT или маршрутизации, если способ явно
не выбран, то трафик запрещается), правила системной политики (определяют
каким образом ISA Server передает данные дальше в сети), правила политики
брандмауэра (определяют метод передачи данных между сетями; по умолчанию
запрещают весь трафик). Управлять всеми видами правил можно из консоли
Управление ISA Server.
В любом случае механизм обмена данными между сетевыми сегментами
сводится к следующему: если отношения между сетями не настроено, то трафик
запрещен; если применяется система NAT, то адреса целевой сети будут скрыты
от адресов исходной; если применяется маршрутизация, оригинальный адрес
источника будет сохранен, а частные и общие адреса будут заданы.
Создавая правила того или иного уровня, необходимо располагать их в
следующем порядке: глобальные запрещающие правила; глобальные разрешающие
правила; правила для конкретных компьютеров; правила для конкретных
пользователей; прочие разрешающие правила.
Совокупность правил доступа на разных уровнях называется сценарием
политики брандмауэра. Создание того или иного сценария должно четко отражать
потребность организации. Проще говоря, правила доступа описывают, как
исходная сеть получает доступ к целевой сети. При попытке получить доступ к
ресурсу, трафик к которому контролирует ISA Server, клиент, инициирующий
связь, должен пройти проверку. При прохождении такой проверки службами ISA
Server должны быть получены ответы на следующие вопросы в порядке очереди:
1. разрешен ли протокол для связи;
26
2. разрешен ли адрес и порт источника;
3. разрешен ли доступ данному клиенту в данное время;
4. разрешен ли целевой ресурс;
5. прошел ли пользователь аутентификацию;
6. разрешена ли передача содержимого данного типа.
Связь разрешается, если получены положительные ответы на все вопросы. При
попытке ответить на указанные вопросы в порядке очереди проверяются:
1. набор протоколов;
2. набор компьютеров или сетей;
3. расписание доступа;
4. набор IP-адресов доменных имен и URL;
5. реквизиты пользователя;
6. список разрешенного содержимого.
Необходимо обратить внимание, что изменение политик брандмауэра не
затрагивает текущие сеансы.
Физическая сетевая топология должная четко отражаться в программных
компонентах, защищающих корпоративную сеть, для этого в ISA Server 2004 есть
возможность работать с сетевыми шаблонами. Рассмотрим четыре наиболее часто
используемых сетевых шаблона.
В случае, если ISA Server отделяет корпоративную сеть от внешнего
Интернета и используется как в качестве брандмауэра, так и в качестве сервера
кэширования, необходимо использовать шаблон Edge Firewall.
Если на ISA Server установлено три сетевых адаптера, подключенные к
внутренней сети, внешней сети и сети периметра соответственно, то необходимо
использовать шаблон 3-Leg Perimeter.
В случае, если на границе корпоративной сети последовательно установлены
два ISA Server, то нужно использовать два шаблона Front Firewall и Back
Firewall. При этом внешний брандмауэр обеспечивает проверку на уровне
адресов, а внутренний - на уровне приложений.
Настройка указанных шаблонов сводится к трем этапам. Сначала необходимо
указать наборы IP-адресов, соответствующих внутренней сети, внешней сети и
27
сети периметра (последней – в зависимости от шаблона). Дальше необходимо
указать IP-адреса ISA Server, подключенные к соответствующим сетям. В конце
необходимо выбрать одну из сценариев разрешающих правил, который
предоставляет шаблон. Описание предлагаемых сценариев содержит в себе
графический мастер, с помощью которого осуществляется настройка указанных
шаблонов. Доступ к этому мастеру можно получить из консоли Управление ISA
Server. В случае, если потребуется изменить сценарий, можно создать
собственные разрешающие правила в шаблоне.
28
Лекция 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 открывать не нужно. Однако, если последний протокол все же
29
необходим для старых приложений, открытие для него указанных портов
облегчает злоумышленникам взлом сети. Еще одной проблемой может стать
использование динамических портов для протокола RPC. По умолчанию для этого
протокола может использоваться любой случайный порт (всего более 64000
портов TCP). Открыв эти порты на брандмауэре, можно свести эффективность
работы межсетевого экрана к нулю.
Для реализации этой функции необходимо включить серверную службу
сопоставления портов через порт 135. Она сообщит обеим сторонам подключения
номер случайного порта для репликации. В принципе, репликацию можно
организовать через туннель, что также сократит количество открытых портов, но
для этого необходимо наличие VPN-подключения, защищенного IPSec. Также
следует учесть, что если вместо локальной DNS на клиентских компьютерах
используются файлы HOSTS, то открывать порты для репликации DNS не нужно
(также не нужно этого делать, если DNS не интегрирована в Активный каталог).
Независимо от использования описанных выше механизмов существует риск
перехвата информации при репликации Активного каталога через границы сети,
поэтому по возможности нужно рассмотреть вопрос о целесообразности создания
всех контролеров домена в главном офисе компании и последующей доставки их в
удаленные филиалы. Последующую репликацию можно осуществлять следующим
образом: архивировать базу данных Активного каталога в главном офисе,
записывать ее на переносимый физический носитель и отправлять с курьером в
филиалы. Этот вариант не обеспечит единовременно актуальной базы Активного
каталога в пределах всей сети, но если изменения в сети редки, а безопасность
превыше всего, такой вариант тоже можно использовать.
Механизм разрешения имен также нуждается в защите. На систему DNS
возможны следующие виды атак: footprinting (похищение данных зоны с именами
и адресами компьютеров), redirection (подмена IP-адресов и перенаправление
компьютеров на сервер злоумышленника), DоS (перегрузка DNS-сервера
запросами, остановка разрешения имен), IP spoofing (подделка пакетов с целью
выдать компьютер злоумышленника за компьютер корпоративной сети), cache
poisoning (запись в кэш DNS-сервера неверной информации).
30
Первым звеном защиты от этих атак должно стать разделение 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
31
или L2TP/IPSec). В дальнейшем нужно выбрать сети для доступа, т.к. по
умолчанию прослушиваются только внешние сети, и назначить VPN-клиентам IP-
адреса (можно настроить статический пул на ISA Server или использовать
внутренний DHCP).
Необходимо также выбрать метод аутентификации клиента. Если в сети
используются смарт-карты, можно использовать протокол EAP-TLS или
использовать протокол по умолчанию MS-CHAPv2. Если для аутентификации
клиентов при связи ISA Server и контроллера домена предполагается использовать
промежуточное звено, то можно использовать аутентификацию RADIUS. В
Активном каталоге выбрать учетные записи пользователей, которым разрешить
доступ по VPN. Потом на брандмауэре необходимо создать правило,
предоставляющее этим клиентам доступ к сети. В последствии на клиентских
компьютерах необходимо создать сетевое подключение VPN, указав адреса
граничных ISA Serverов.
При создании подключения VPN протокол L2TP/IPSec использовать
предпочтительнее, чем протокол PPTP. Причем при использовании первого
протокола рекомендуется использование сертификата.
Защита серверов от внешних атак не гарантирует полной безопасности сети –
злоумышленники могут быть и внутри предприятия. Поэтому необходимо
настраивать параметры безопасности серверов в корпоративной сети, а не только
ограничивать трафик на брандмауэре.
Необходимо спроектировать политику паролей, политику блокировки
учетных записей, настроить права пользователей и прочие доступные параметры
безопасности операционных систем серверов. Безусловно, можно настраивать
каждый сервер в отдельности, а можно унифицировать процесс. Для этого
необходимо спроектировать структуру организационных подразделений в
Активном каталоге в зависимости от ролей серверов. Проще говоря, необходимо
создать подразделение, в которое поместить сервера, выполняющие одинаковые
или сходные функции (например, ОП серверы печати, ОП файловые серверы).
Можно группировать серверы с разными ролями в одно подразделение (например,
унифицировано настроить DNS и DHCP-сервера). Затем с помощью оснастки
32
Анализ и настройка безопасности можно создать шаблон с настройками для того
или иного организационного подразделения и средствами групповой политики в
Активного каталоге привязать его к организационному подразделению.
Вообще, в Windows Server 2003 есть заранее разработанные шаблоны
безопасности для различных серверных ролей. Информацию по этим шаблонам
можно получить либо в справочной системе, либо физически изучив их
параметры, просмотрев их в оснастке Анализ и настройка безопасности. По
возможности рекомендуется применять эти базовые шаблоны, лишь по
необходимости меняя базовые настройки на собственные.
33
Лекция 9. Защита передачи данных внутри сети.
Необходимость защиты передачи данных в географически удаленных сетях
или трафика между корпоративной сетью и внешним Интернетом не вызывает
сомнений. Однако защите трафика внутри корпоративной сети части не уделяют
должного внимания. При разработке политики безопасности половинчатые меры
защиты просто не допустимы. Поэтому контролю и защите внутрикорпоративного
сетевого трафика нужно уделять должное внимание.
Первоначально необходимо выбрать метод защиты данных при их передаче.
В случае если сеть сильно сегментирована, а ее сегменты соединены друг с другом
посредством брандмауэров и имеют разный уровень доверия, предпочтительно
защитить данные при помощи VPN-туннеля. Если нужно контролировать трафик
между определенными компьютерами или запретить использование определенных
портов, лучше использовать политики IPSec. Трафик между клиентами и
серверами во внутренней сети лучше всего защищать при помощи SSL.
Рассмотрим использование политик IPSec в частной сети. Вообще политика
– это набор правил, привязанный средствами GPO к определенному участнику
безопасности (подразделение, группа, учетная запись). Сами по себе политики
IPSec представляют из себя систему фильтров, основанных на адресах,
протоколах, номерах портов и прочих элементах сетевого соединения. Фильтры
могут блокировать трафик, разрешать его или разрешать подключения в
зависимости от установленных правил.
Каждая политика IPSec содержит следующие элементы:
1. правила (набор фильтров; фильтров может быть несколько, но действие
одно);
2. список фильтров (конкретное определение портов, адресов, имен и пр.);
3. действие фильтра (определяет что предпринимается в случае если
текущая ситуация совпадает с одним из критериев списка фильтров);
4. общая конфигурация (настройка на использование определенных
протоколов проверки целостности и подлинности, типа аутентификации,
размер группы Диффи-Хеллмана).
34
При создании той или иной политики рекомендуется опробовать ее в тестовой
подсети. Если она успешно работает, то ее можно разворачивать во всей сети.
Фильтры можно создавать из оснастки Управление политики IP-безопасности,
непосредственно в Активном каталоге или с помощью утилиты Netsh.
При разработке фильтров следует учитывать следующие рекомендации:
1. необходимо разработать общий фильтр, блокирующий весь трафик, и
специальные правила, разрешающие только необходимый вид трафика;
2. на брандмауэре необходимо разработать фильтр по умолчанию,
закрывающий все порты и систему фильтров, открывающие нужные
порты по необходимости;
3. необходимо четко определяться с областью действия политики IPSec
(применять политику нужно только к тем участникам безопасности,
которым она действительно нужна).
Для каждого правила в политике необходимо настроить блокирующий или
разрешающий фильтр, а для каждого фильтра в свою очередь необходимо
настроить: протокол, исходный порт, адрес, маску подсети и имя отправителя,
целевой порт, имя, адрес и маску подсети получателя.
В случае если требуется проверить наличие тех или иных параметров
настройки безопасности на разных сетевых узлах или применять защитные
алгоритмы в зависимости от настроек конечного пользователя можно
использовать согласуемые политики IPSec. Кроме указанных выше составных
частей согласуемые политики содержат еще множество настроек, определяющих
согласование параметров конечных точек подключения и способов передачи
данных.
Все согласуемые политики требуют аутентификации, поддерживают
шифрование данных. В случае если на конечных точках подключения настроены
разные алгоритмы проверки подлинности или шифрования данных, подключение
между узлами будет невозможно. Аналогичный результат будет и в случае если на
одном из узлов вообще отсутствует соответствующая политика. При выборе
алгоритма аутентификации политики IPSec можно руководствоваться
рекомендациями приведенными ниже. Для аутентификации можно применять
35
общий ключ, сертификат или протокол Kerberos. Общий ключ применять не
рекомендуется, его можно использовать для тестирования IPSec. Протокол
Kerberos хорошо работает в доменах, но если активный каталог не доступен,
проверку по данному протоколу пройти не удастся.
Сертификаты представляют мощное средство защиты, но для их
использования необходимо внедрение иерархических центров сертификации,
реализующие систему открытых ключей. При этом необходимо контролировать
локальные хранилища сертификатов корпоративных компьютеров и обеспечивать
доступ к актуальному списку отозванных сертификатов.
В семейство протоколов IPSec входят протоколы AH и ESP. В купе они
обеспечивают проверку подлинности отправителя, целостность данных и защиту
от атак повтором пакетов. Выбор между ними можно сделать исходя из
требований к аутентификации и шифрованию. AH не поддерживает шифрование
данных, но обеспечивает надежную аутентификацию всего пакета в целом (и
данных, и заголовочной информации). ESP поддерживает шифрование, но
подписывает не весь пакет, а только его полезные данные, обеспечивая лишь
целостность последних.
При выборе туннельного режима нужно учитывать следующее:
1. трафик, защищенный IPSec, не требует туннелирования;
2. для VPN предпочтительнее туннель L2TP, чем туннель на основе IPSec;
3. в случае, если согласуемая политика настроена на границе сети, лучше
использовать туннельный режим.
Для шифрования можно использовать два алгоритма DES и 3DES. Второй
алгоритм более надежен, а первый поддерживается большим числом
операционных систем. Необходимо помнить, что протокол AH не поддерживает
шифрование и для использования обоих алгоритмов необходим протокол ESP. На
рынке существуют аппаратные ускорители шифрования. Если требуется
передавать большие объемы защищенных данных, то следует рассмотреть вопрос
о приобретении таких ускорителей.
Целостность данных обеспечивают протоколы MD5 и SHA1, второй протокол
гораздо эффективнее, но очень сильно загружает процессор.
36
Размер ключа защиты согласования политик зависит от размера группы
Диффи-Хеллмана, который может принимать значения 1, 2 и 3. Чем больше
размер группы, тем длиннее ключ и тем выше защита, однако больше и время,
требуемое для расчета ключа. Если согласование политики требуется для
компьютеров только под управлением Windows Server 2003, то размер группы
Диффи-Хеллмана следует выбрать равный 3. Для других операционных систем
значение этой группы присваивают равное 1 или 2.
При разработке политик IPSec необходимо следовать следующим правилам:
1. спроектировать единую политику, подходящую для всех компьютеров
(одному клиенту можно присвоить не более одной политики, поэтому
необходимо скомбинировать настройки, подходящие для всех);
2. не использовать стандартные политики IPSec;
3. не стоит шифровать трафик между контроллером домена и его
клиентами (возникает коллизия с аутентификацией);
4. по возможности использовать аппаратный ускоритель шифрования;
5. необходимо настроить IPSec для защиты трафика при загрузке
компьютеров (это позволит избежать уязвимости из-за сбоя групповой
политики);
6. всегда тестировать разработанную политику вне рабочей сети
(проблемы с применением новой политики могут вызвать отказ
сетевого взаимодействия и убытки).
37
Лекция 10. Отношения доверия в лесах и доменах.
Часто бывает, что корпоративная сеть состоит из нескольких доменов, а
иногда и лесов, в этом случае в корпоративной сети можно выделить внутреннюю
и внешнюю границы. Сетями, находящимися за внешней границей по-прежнему
будем считать сети никак не подконтрольные организации, внутренними же
границами будем считать границы доменов или лесов корпоративной сети
предприятия.
Для того чтобы пользователи различных доменов имели доступ через
внутренние границы корпоративной сети между доменами и лесами, необходимо
установить отношения доверия. Чтобы построить систему отношений доверия
необходимо: задокументировать текущую архитектуру лесов или доменов;
определить потребность в доступе к ресурсам во всех имеющихся доменах;
выбрать направление доверия; определить ограничение отношений доверия.
Предположим, что документация по архитектуре существующих доменов
является частью Политики безопасности корпоративной сети, поэтому сразу
перейдем ко второму этапу и укажем аспекты, требующие внимания при анализе
потребностей доступа к ресурсам. Во-первых, необходимо убедиться, что доступ к
данным через внутреннюю границу действительно необходим (вполне возможно,
что данные можно разместить на внешнем Web-сервере, тогда отпадет
необходимость в пересечении внутренней границы. Во-вторых, необходимо
определиться с локализацией ресурсов, к которым необходим доступ (определить
находятся ли требуемые ресурсы в одном или в разных доменах, а может быть на
единственном сервере). В-третьих, необходимо выяснить, кто будет давать
разрешения на доступ, кто будет его контролировать (определиться с владельцами
нужных объектов и административными учетными записями).
Доверие бывает следующих типов:
1. отсутствие доверия (применяется по умолчанию в доменах
WindowsNT 4.0; делает домен изолированной сущностью; предполагает, что
пользователи получат доступ к ресурсам этого домена при наличии в нем
соответствующей учетной записи);
38
2. доверие между доменами одного леса (все домены WS2003 в одном
лесу связаны двухсторонними переходными отношениями. Это значит, что
каждый домен, являющийся участником таких отношений доверяет другому
домену, который также является участником указанного доверия);
3. спрямляющее доверие (отношения доверия с доменом из того же леса,
является односторонним и не переходным; также отличается от доверия
между доменами в одном лесе тем, что позволяет сократить путь доверия. В
этом случае запрос сеансовых билетов происходит непосредственно в
целевом домене и не проходит полный путь иерархии доменов в лесе.);
4. внешнее доверие (отношения доверия между доменом WindowsNT 4.0
и некоторым лесом или доменом другого леса. Является односторонним и не
переходным. Для установки двухстороннего доверия нужно использовать два
разнонаправленных доверия, которыми надо связать все требуемые пары
доменов.);
5. доверие между лесами (это двухсторонние или односторонние
отношения доверия между разными лесами, всегда являющиеся переходными.
Для их организации оба леса должны работать в режиме WS2003.).
Созданные доверия рекомендуется ограничивать. Доверие в принципе
ограничивается автоматически, но можно добавить и созданное вручную
ограничение. Автоматически доверие ограничивается: направлением; кругом
доверяемых доменов и лесов (по умолчанию доверительные отношения между
двумя доменами разных лесов не распространяются на остальные домены); типом
доступа (для всех участников безопасности доступ к общим ресурсам в
доверительных доменах должен быть определен явно, потому что отношения
доверия не отменяют механизм авторизации).
Вообще говоря, злоумышленник может использовать доверие для
несанкционированного доступа в другом домене, поэтому необходимо
устанавливать дополнительные ограничения на отношения доверия. Во-первых,
необходимо использовать фильтрацию SID. Этот механизм включается
автоматически и обеспечивает неприменение внешних идентификаторов
безопасности при доступе к внутренним ресурсам леса. Если бы такой механизм
39
отсутствовал, получилось бы, что администраторы доверяемого домена
становились бы администраторами в доверяющем. Аналогичная ситуация
произошла бы и с другими участниками безопасности. Поэтому в доверяющем
домене идентификаторы безопасности из других доменов не должны произвольно
использоваться. Механизм фильтрации SID можно отключить, но делать это
крайне не рекомендуется.
Также с точки зрения безопасности важно понимать, что вновь созданное
отношение доверия уязвимо из-за потенциально широкого доступа к объектам
группы Все. Любой пользователь из доверяемого домена будет иметь полномочия
этой группы в доверяющем домене, даже если ему явно не назначено разрешение
на доступ к объектам. Поэтому доступ к важным ресурсам этой группы следует
ограничить еще до создания доверительных отношений. То же самое касается
группы Сеть. Также доверие следует ограничить следующим образом:
1. отключить список участников доверия домена (не стоит отключать
Запись с информацией о домене полностью. Это равносильно запрету
использования доверия. Для ограничения нужно использовать запись
TopLevelExclusion, которое позволяет исключить часть пространства из
доверия.);
2. ограничить проверку подлинности (можно явно разрешить проверку
на уровне сервера или домена. Без такой проверки ни один пользователь из
доверяемого домена обратиться к ресурсам доверяющего.);
3. установить разрешение на проверку подлинности (это можно
сделать в свойствах безопасности контроллера домена для установления
доверия между доменами или лесами или в свойствах безопасности
конкретного сервера).
Для функционирования доверия также необходимо соблюдение ряда
физических условий. Во-первых, домены должны быть физически соединены
кабелем, во-вторых, необходима адекватная настройка системы DNS, ведь имена
должны разрешаться по обе стороны доверия. Если пространство имен DNS
разделено между разными серверами, то они должны быть доступны по обе
стороны доверия. В-третьих, если внутренние границы сети соединены между
40
собой брандмауэрами, то на последних необходимо открыть следующие порты:
RPC локального администратора безопасности (по умолчанию он динамический,
но для уменьшения числа открытых портов его номер необходимо задать в
следующем разделе реестра HKLM\system\currentcontrolset\servicies\ntds\
parameters – параметр TCP/IP Port); RPC NETLOGON ( он задается в реестре по
адресу HKLM\system\currentcontrolset\servicies\netlogon\parameters), а также порты
с номерами 88 для аутентификации Kerberos, 135 – для контроля над Action
Control Listами объектов.
Внедряя доверие, необходимо руководствоваться следующими
рекомендациями:
для сокращения пути доверия и времени отклика нужно использовать
спрямляющее доверие;
для доступа к ресурсам домена WindowsNT 4.0 нужно использовать
внешнее одностороннее доверие;
двустороннее доверие между лесами подойдет для лесов WS2003 при
условии размещения общих ресурсов в обоих лесах;
если пользователям одного домена WS2003 необходим доступ к
ресурсам в разных доменах другого леса необходимо использовать
одностороннее доверие между исходным доменом и каждым из
целевых;
если используются домены WS2000 нужно использовать попарную
связь лесов с двухсторонними довериями.
Грамотно настроенные отношения доверия позволят пользователю проходить
аутентификацию в своем домене пи доступе к ресурсам другого домена или леса, а
это значит, что для обеспечения санкционированного доступа к ресурсам
необходимо будет контролировать его не во всей сети, а только в пределах
нужного домена. Отношения доверия облегчают труд администраторов и делают
систему доступа к ресурсам более прозрачной и контролируемой.
41
Лекция 11. Доступ к объектам в корпоративной сети.
Разграничение доступа к общим ресурсам является одним из важнейших
элементов системы сетевой безопасности. Протокол LDAP, на базе которого
функционирует Активный каталог, предоставляет гибкую систему управления
участниками безопасности путем объединения их в специфические группы, при
этом разрешение на доступ к общим объектам могут назначаться как конкретным
пользователям, так и целым группам. Один пользователь может быть членом
нескольких групп, а группы могут вкладываться друг в друга.
Разберем базовый механизм доступа к объектам. Когда пользователь входит в
домен, вводя реквизиты своей учетной записи, последовательно происходит два
действия: идентификация и аутентификация. Процесс идентификации
заключается в проверке наличия введенных реквизитов учетной записи в базе
данных Активного каталога. В случае если идентификация завершилась
положительно, начинается процесс аутентификации, смысл которого заключается
в назначении пользователю прав доступа к общим ресурсам. В процессе
аутентификации создается так называемый маркер доступа. Это специальная
функция, с помощью которой можно определить получит пользователь доступ к
объекту или нет. Смысл его действия в следующем: каждый объект файловой
системы имеет список управления доступом (ACL), представляющий собой
список полномочий, делегированный участникам безопасности Активного
каталога для доступа к данному ресурсу. Каждое полномочие из этого списка
представляет собой логическую функцию, аргументом которой является маркер
доступа. Если значение функции истинно, то данное полномочие считается
делегированным участнику безопасности и доступ к объекту разрешается. В
противном случае доступ к объекту будет запрещен.
В случае если общие ресурсы расположены на томах NTFS, то ACL таких
объектов представляет собой пересечение разрешений общего доступа и
разрешений NTFS. Причем явные запреты приоритетнее явных разрешений.
Поскольку пользователь может быть членом разных групп, зачастую бывает
сложно определить какие права на доступ к тому или иному объекту являются
42
действующими для данного пользователя. Это можно выяснить, используя
вкладку Действующие разрешения в свойствах объекта.
Действующие разрешения формируются по следующим правилам: явное
разрешение для пользователя приоритетнее разрешений для групп, членом
которых он является. Явные запреты приоритетнее явных разрешений. Однако
информация на вкладке Действующие разрешения не всегда бывает актуальной,
т.к. в ней не учитываются разрешения для встроенных групп безопасности
Windows таких как Все, Сеть и прочие. В любом случае, действующие
разрешения на доступ к объекту можно определить, используя указанные выше
правила и учитывая наследование. По умолчанию разрешения дочерних объектов
наследуются от родительских. Однако явно установленные разрешения
приоритетнее унаследованных.
По необходимости наследование разрешений можно отключить.
Восстанавливать наследование можно двумя способами: от дочернего объекта
(явно назначенные разрешения не заменяются родительскими, а отсутствующие
разрешения наследуются от родительского объекта), от родительского объекта
(при этом явные разрешения, назначенные дочернему объекту, будут заменены
разрешениями родительского объекта).
В любом случае, при назначении разрешений на доступ к объектам
необходимо пользоваться принципом наименьших привилегий, который
заключается в том, чтобы дать пользователю ровно столько прав, сколько ему
необходимо для производственных задач.
Обычно при настройке разрешений на доступ к объектам используют
следующую схему: в разрешениях общего доступа для группы Все разрешают
Полный доступ, конкретные же разрешения настраивают с помощью разрешений
NTFS. В случае если необходима более тонкая настройка, разрешения общего
доступа также настраивают для конкретных групп или пользователей.
В Windows Server 2003 существуют три группы безопасности (группы
распространения мы не рассматриваем, т.к. они используются для рассылки
электронных сообщений, а для назначения прав доступа используются группы
безопасности): локальная доменная, глобальная и универсальная (указанные
43
группы существуют в доменах, на отдельных компьютерах, также существуют
локальные группы. В случае, если доменные учетные записи и учетные записи
локального компьютера являются зеркальными, необходимо учитывать
разрешения для групп локального компьютера.).
Локальная доменная группа объединяет пользователей из этого домена или
других доменов и используется для назначения прав на ресурсы только того
домена, в котором они созданы.
Глобальные группы содержат учетные записи пользователей только своего
домена, но могут использоваться для назначения прав во всех доменах
предприятия.
Универсальные группы содержат учетные записи пользователей из любых
доменов на предприятии и могут использоваться для назначения прав на любые
общие ресурсы на предприятии.
Группы могут вкладываться друг в друга по следующим правилам: локальные
доменные группы и глобальные группы могут быть членами универсальных
групп. Глобальные доменные группы могут быть членами локальных групп.
Локальные группы могут быть членами локальных групп в этом же домене,
универсальные группы могут вкладываться в любые другие. По возможности
следует избегать использования универсальных групп.
Также рекомендуется управлять доступом на уровне групп, а не на уровне
конкретных пользователей. В этом случае комбинации предустановленных
разрешений на доступ к объектам конкретному пользователю может не хватить.
Тогда следует использовать механизм делегирования административных
полномочий. От имени администратора с помощью Мастера делегирования можно
прямо назначить любые из возможных прав на доступ к конкретному объекту.
Мастера отзывов полномочий не существует, поэтому отменить
делегирование можно только через Мастер делегирования, сняв галочки напротив
соответствующих прав.
При назначении или отмене прав следует учитывать один нюанс: изменения
ACL-объекта не актуальны для текущей сессии. Маркер доступа создается при
входе пользователя в систему и сравнивается с ACL объекта при первом доступе к
44
объекту. Поэтому при изменении ACL нужно разорвать текущую сессию
пользователя, чтобы изменения начали действовать немедленно. Сделать это
можно из оснастки Общие папки.
Необходимо следить за использованием пользователями общих ресурсов, для
этого нужно использовать Аудит доступа к объектам. Сведения о доступе к
объектам будут записываться в журнал Система, который можно просмотреть с
помощью утилиты Просмотр событий. Для настройки аудита доступа к объектам
необходимо две вещи: включить аудит в свойствах безопасности самого объекта и
активировать специальную политику аудита на сервере, где расположен общий
ресурс (в политике аудита включить параметр Аудит доступа к объектам). При
этом необходимо выбрать тип регистрируемых событий: успех или отказ
различных действий с общим ресурсом (создание, изменение, удаление).
Параметры настройки журнала аудита можно получить в справочной системе
Windows.
Для обеспечения безопасности необходимо защищать данные не только при
передаче по сети и ограничивать к ним доступ посредством аутентификации, но и
защищать их от копирования на переносные устройства локального компьютера.
Для этого существует система шифрования файлов EFS. Включить шифрования
можно в свойствах безопасности объекта. Принцип работы этой системы таков:
пользователь задает специальный пароль, на основе которого данные шифруются
специальным сложным функциональным преобразованием. Этот пароль хранится
вместе с Идентификатором безопасности пользователя. При доступе к объекту
зашифровавшего его пользователя данные автоматически расшифровываются.
Прочим пользователям будет предложено ввести пароль. Если пароль будет
утрачен, расшифровать информацию может только специальный Агент
восстановления – пользователь с соответствующим правом, причем он должен
быть создан в системе до того как файл был зашифрован. Пароль Агента
восстановления универсален для зашифрованных файлов. В случае утраты пароля
и отсутствия в системе Агента восстановления, расшифровать информацию будет
невозможно. Поэтому, если пользователи не умеют работать с системой EFS, ее
внедрение может причинить больше неудобств, чем выгод. Необходимо помнить,
45
что при копировании зашифрованных файлов на тома под управлением любой
файловой системы информация остается зашифрованной в отличие от сохранения
разрешений (при копировании файла с тома NTFS на том FAT32 остаются только
разрешения общего доступа).
46
Лекция 12. Проектирование защищенной инфраструктуры клиентов.
Клиентские компьютеры корпоративной сети, как и сервера, играют
различные роли. Очевидно, что защиту этих компьютеров также можно построить
на основе этих ролей. Однако в отличие от сетевых серверов роли клиентских
компьютеров не всегда совпадают с функциями пользователей, которые за ними
работают. Поэтому, проектируя защиту клиентских компьютеров, необходимо
сделать следующее: разработать соответствующую схему подразделений для
клиентских компьютеров и пользователей; разработать соответствующие
групповые политики и применить их к подразделению. Рассмотрим более
подробно оба этих компонента.
Активный каталог хранит не только учетные записи пользователей, но и
учетные записи компьютеров со своими именами, свойствами и
идентификаторами безопасности. Разрабатывая схему организационных
подразделений для пользователей, естественно руководствоваться
принадлежностью пользователя к тому или иному структурному подразделению
организации и его административной ролью в корпоративной сети.
При разработке юнитов для компьютеров можно разбить их на группы по
территориальному принципу (по одному юниту на каждый офис или отдел), в
зависимости от операционных систем, которыми управляются компьютеры (один
юнит для Windows NT, один для Windows XP и т.д.) или в зависимости от того
является ли компьютер переносным или настольным (один юнит для переносных
компьютеров, один для настольных, один для серверов).
Наиболее выгодной представляется иерархическая структура юнитов для
компьютеров. В этом случае для юнитов верхнего уровня применяется деление в
зависимости от операционных систем. На втором уровне юниты разбиваются по
географическому принципу, а на третьем – в зависимости от того являются ли
компьютеры переносными. При этом групповые политики можно применять к
юнитам всех уровней и обеспечить за счет этого более адекватную настройку
параметров в зависимости от корпоративных требований. В принципе допускается
любая комбинация дочерних и родительских подразделений, т.к. в групповых
политиках можно настроить фильтры их применения.
47
Для защиты клиентских компьютеров как в отдельности, так и являющихся
членами подразделений, можно спроектировать шаблон безопасности.
Применение шаблонов безопасности к клиентским компьютерам напоминает
защиту серверов с помощью шаблонов. Существуют четыре предустановленных
шаблона безопасности для клиентов Windows XP, которые предоставляют
настройки средней или высокой безопасности для портативных или настольных
клиентов. Безусловно, можно разработать свой шаблон безопасности и
интегрировать в групповую политику именно его. Если компьютер является
членом иерархии организационных подразделений, то рекомендуется разработать
базовый шаблон безопасности для юнита верхнего уровня и варьировать
настройки в шаблонах для вложенных юнитов.
При разработке шаблонов безопасности нужно следовать рекомендациям,
приведенным ниже. Группе Все запретить вход в систему через Службу
терминалов. Подобное право нужно выдать только конкретным пользователям,
которые в нем нуждаются. Пользователям всех категорий запретить изменять
системное время своих компьютеров. Ограничить права на локальный вход в
систему, заставляя пользователей аутентифицироваться в домене. Разделить
полномочия резервного копирования и восстановления файлов. Последнее право
назначить только специальной группе администраторов, чтобы злоумышленники
и вредоносные программы не заменяли важные файлы своими. По возможности
запретить кэширование учетных данных, используемых для идентификации.
Отключить возможность копирования дискет и доступ ко всем дискам из Консоли
восстановления, чтобы злоумышленник не мог скопировать локальную базу
данных безопасности. Обязательно настройте использование ограниченных групп,
это исключит возможность самостоятельного делегирования расширенных прав
пользователям.
В шаблоне необходимо оставить включенными только необходимые
системные службы, в обязательном порядке отключив Службу удаленного
администрирования. В базовом шаблоне безопасности необходимо настроить
надежные политики паролей и блокировки учетной записи пользователя. Также в
48
шаблоне можно настроить политику аудита в зависимости от требований на
предприятии.
Для большей защиты клиентского компьютера в шаблоне необходимо
ограничить удаленный доступ и права пользователей на удаленное выключение
компьютера. Также необходимо переименовать учетную запись администратора,
запретить отображение последнего имени пользователя. Важно запретить
локальное хранение хэша пароля LAN Manager, и использовать для сетевой
аутентификации протокол NTLM или NTLMv2. Необходимо также очищать файл
подкачки при входе в систему, и отключить возможность входа в Консоль
восстановления с автоматическими административными правами.
Вообще говоря, шаблон безопасности состоит из двух частей: базовых
элементов безопасности (о которых говорилось выше) и административной
части. С помощью последней можно управлять различными настраиваемыми
параметрами операционной системы (например, отображением дисков в окне Мой
компьютер, видом Панели управления, возможностями Проводника и прочее).
Подобных параметров более 200. Таким образом, функциональные возможности
клиентской операционной системы можно настроить максимально адекватно
пользовательским задачам. Принцип настройки один – оставить пользователю
только те функциональные возможности, которые ему действительно нужны. Это
преобразованный принцип наименьших привилегий. Настраивать шаблоны
безопасности можно с помощью редактора Объекты групповой политики.
Мощным инструментом защиты операционной системы являются Политики
ограниченного использования программ. С помощью этого инструмента можно
разрешить или запретить запуск исполняемых файлов в операционной системе.
При настройке Политик ограниченного использования программ необходимо:
выбрать тип файла, который считается программой (существует список
расширений исполняемых файлов по умолчанию, который можно редактировать),
выбрать возможность запуска файлов из списка (разрешить или запретить),
выбрать правило использования.
Правила использования бывают: для путей (распространяются на конкретную
папку или файл), для хэша (привязываются к конкретному файлу и действуют для
49
него вне зависимости от переименования или иного изменения файла), для
сертификата (ограничивают запуск программ в зависимости от наличия
цифровой подписи) и для зоны Интернета (определяют возможность запуска
программ, полученных из Интернета). Основного эффекта от применения политик
ограниченного использования программ можно добиться следующим образом:
1. запретить запуск программ со сменных носителей, создав правила для
путей к соответствующим дискам (таким образом можно защититься от
вредоносных программ, запускаемых при старте сменных носителей);
2. разрешить пользователям записывать данные только в те папки, для
которых установлены запретительные политики использования
программ. Исполнение программ для пользователей разрешить только
из тех папок, для которых у пользователя нет права на запись (таким
образом записанные пользователем вредоносные программы не могут
запуститься или перезаписаться в места, из которых возможен запуск).
50
Лекция 13. Защита беспроводных сетей.
Под беспроводной сетью будем понимать такую сеть, в которой есть хотя бы
один сегмент, соединяющий два и более беспроводных устройства по радиоканалу
стандарта 802.11. Топологически такие сети можно разделить на два вида: с
точкой доступа (через сервер с радиоустройством, одновременно подключенный
к радиосети), ad hoc (клиенты взаимодействуют напрямую без точки доступа).
Рассмотрим беспроводную сеть с точкой доступа, реализованная по любому
коммерческому стандарту 802.11 (a, b, g, i), кроме 802.1х. Вне зависимости от
количества точек доступа беспроводной сетевой сегмент идентифицируется
единственным идентификатором (SSID). Существуют три встроенных механизма
безопасности для защиты беспроводных сетей: проверка подлинности,
шифрование, WPA.
Подлинность проверяется двумя механизмами: открытой проверкой (на
точке доступа задаются ограничения MAC-адресов беспроводных сетевых
устройств), закрытым ключом (пользователям беспроводной сети сообщается
пароль, который они вводят вручную при установке соединения).
Шифрование в беспроводных сетях осуществляется по алгоритму RC4.
Шифрование поддерживает два вида ключей: глобальный и сеансовый.
Глобальный ключ применяется для защиты группового и широковещательного
исходящего трафика точки доступа, а сеансовый ключ – для одноадресного
исходящего трафика точки доступа, а также группового и широковещательного
входящего трафика точки доступа. Оба типа ключей распространяются между
клиентами сети и вводятся вручную.
WPA обеспечивает улучшенное шифрование по протоколу TKIP, который
контролирует и целостность данных. Проверка подлинности проверяется
протоколом IAP.
Через беспроводные сети могут осуществляться следующие виды атак:
перехват трафика,
взлом адресов протокола ARP,
атаки вирусов, попавших в сеть с компьютера взломщика,
51
перенаправления (в данном случае осуществляется взлом на уровне
SSL. Взломщик подделывает MAC-адрес точки доступа и направляет
пользователю запрос на прием удостоверений нового сервера,
подконтрольного ему.),
несанкционированные подключения (к любой беспроводной сети
можно подключить, приблизившись на достаточное расстояние. При
использовании открытой системы идентификации любой может
получить доступ к корпоративной сети.),
подключение несанкционированных точек доступа (пользователи могут
сами установить необходимое оборудование, не включив на нем
защитных механизмов), перегрузка сети (атака типа DoS),
радиопомехи.
Чтобы усилить защиту беспроводной сети следует:
изменить заводской SSID,
отключить широковещательную рассылку SSID,
необходимо использовать шифрование с уникальными ключами,
защитить протокол SSNP (изменить сообщество для этого протокола,
заданное по умолчанию, продумать защиту от PROTOS),
использовать фильтрацию MAC-адресов, установив в списке
допустимых беспроводных клиентов,
совместно со службой безопасности предприятия нужно бороться с
установкой несанкционированных точек доступа (необходимо
проверять какое оборудование вносят на предприятие и обнаруживать
точки доступа с помощью SSNP-агентов.
Безусловно необходимо уделить внимание выбору и установке антенн у точек
доступа. По возможности нужно использовать антенны направленного действия
или передатчики с малым радиусом действия, чтобы не расширять
территориальных границ беспроводной сети. Целесообразно считать точку
доступа частью демилитаризованной зоны или сети, не пользующейся доверием.
Поэтому рекомендуется отделять точки доступа от проводных сетей
брандмауэром.
52
Качественным скачком в безопасности беспроводных сетей является стандарт
802.1х. Он позволяет использовать максимально безопасную проверку
подлинности беспроводных клиентов и осуществлять безопасную шифрованную
передачу данных. В этом стандарте для шифрования используются динамические
ключи, которые не нужно устанавливать вручную. Однако для внедрения данного
стандарта необходимо три вещи:
1. для аутентификации клиентов беспроводной сети необходимо
настраивать RADIUS-сервер со специальной политикой удаленного
доступа для беспроводных сетей;
2. в организации должна быть внедрена система Открытых ключей, т.к.
для проверки подлинности стандарт 802.1х использует протокол EAP-
TLS;
3. точку доступа можно организовать только под WS2003, а беспроводные
клиенты должны управляться Windows XP SP1 или выше.
Таким образом, внедрение RADIUS-сервера может потребовать коренного
изменения топологии корпоративной сети. Внедрение системы Открытых ключей
потребует либо развертывание собственной иерархии центров сертификации, или
приобретение сертификатов у сторонних фирм. Внедрение стандарта 802.1х
обеспечивает максимальный уровень защиты беспроводной сети, но требует
большой административной настройки и финансовых затрат.
53
Лекция 14. Проектирование защиты Web-сервера.
Web-сервера в корпоративных сетях часто становятся первым объектом для
атаки, потому как они доступны не только внутренним пользователям, но и из
внешнего Интернета. Поэтому нужно уделять особое внимание проектированию
их защиты. Во-первых, нужно стараться, чтобы Web-сервер не выполнял никаких
других серверных ролей, в полном объеме использовать принцип наименьших
привилегий, и использовать на этом сервере только необходимые приложения и
службы.
В дальнейшем рассмотрим базовые принципы защиты Web-сервера под
управлением WS2003, созданного на базе технологии IIS 6.0. Для того чтобы
свести к минимуму возможность атаки Web-сервера необходимо отключить ряд
служб операционной системы, в частности:
службу автоматического обновления и BITC (обновление может
вызвать перебои в работе системы, а отключение Web-сервера недопустимо
также как сбой контроллера домена. Для обновления Web-серверов
рекомендуется использовать специальные механизмы, а не указанные службы),
службу удаленного управления реестром,
службу терминалов (с точки зрения удаленного администрирования эту
службу не стоит отключать полностью, необходимо не устанавливать ее в
режиме приложений),
SMTP (если Web-сервер не предполагается использовать для
управления почтовой рассылкой, эту службу нужно отключить).
Отключение указанных служб позволит сократить количество открытых
портов в системе и уменьшить количество работающих процессов, что, в общем,
повысит уровень безопасности сервера. Аналогичных рекомендаций нужно
придерживаться при выборе наполнения самой службы IIS.
Необходимо ограничить набор функций, устанавливаемых на Web-сервер по
умолчанию. Например, если Web-сервер не выполняет других серверных ролей, то
можно не устанавливать консоль Сервер приложений (ее заменит Диспетчер IIS, а
если администрировать Web-сервер предполагается удаленно, можно не
устанавливать и его). Если на сервере нет распределенных приложений, можно не
54
устанавливать Поддержку объектов COM+. Таким образом, однозначно
установленными и включенными должны быть: служба Интернета и служба
доступа к общим файлам..
Для ограничения доступа к размещенным на сервере Web-сайтам и прочим
ресурсам можно ограничивать по IP-адресам и доменным именам. Это актуально
для пользователей беспроводных сетей, которым, вполне возможно, потребуется
запретить доступ к корпоративному сайту. При проектировании Web-сайта
необходимо пользоваться следующими рекомендациями:
1. содержимое Web-сервера нужно хранить на диске отдельно от
системного диска (это предотвратит атаку directory traversal);
2. настроить разрешения участников безопасности на доступ к корневому
Web-каталогу;
3. размещать папки Web-сайтов в папках верхнего уровня;
4. размещать каждый Web-сайт в отдельном каталоге;
5. если для доступа к Web-сайту используются анонимные учетные
записи, необходимо ограничить их доступ к другим частям сервера (это
же касается всех учетных записей);
6. согласовать разрешения на доступ к файлам и папкам с разрешениями
на доступ через Web.
Из последнего элемента списка следует, что при определении действующих
разрешений для пользователя при доступе к Web-сайтам используются не только
разрешения файловой системы NTFS (на томе которой расположен сайт), но и
Web-разрешения. Как и при доступе к общим папкам действуют самые жесткие
разрешения из пересечений разрешений указанных двух видов.
Данные Web-сервера также нуждаются в защите при передаче. В зависимости
от типа канала их можно защищать с помощью SSL, IPSec, VPN. SSL использует
сертификаты для аутентификации и шифрования данных, передаваемых между
клиентами сервера. Если в организации внедрена система Открытых ключей,
SSL рекомендуется для защиты клиент-серверных приложений (например,
взаимодействие между SQL Server и IIS) или для создания прямого туннеля между
IIS-сервером и брандмауэром, который будет передавать Web-данные клиенту.
55
Для защиты канала связи, который использует администратор для управления
Web-сервером, применяют IPSec. В случае если корпоративная сеть имеет
несколько географически удаленных сегментов с распределенными по ним web-
серверами для доступа к корпоративным клиентов к web-серверу компании
выгодно использовать VPN. В этом случае можно будет организовать
аутентификацию пользователей средствами активного каталога и безопасную
передачу данных через туннель.
Технологии IIS поддерживают несколько методов аутентификации
пользователей:
1. анонимная (доступ осуществляется без паролей и логина, доступ к
сайтам осуществляется на основании разрешений NTFS и web-разрешений для
учетной записи пользователя, с реквизитами которой он вошел в домен.
Разрешение анонимного доступа проверяются первыми, даже если для web-
сайта выбраны другие методы аутентификации);
2. встроенная проверка Windows (не поддерживается через прокси-
сервер, основана на обмене данными по протоколу NTNL);
3. краткая проверка Windows (требует от пользователя логии и пароль,
которые передаются серверу в зашифрованном виде по протоколу MD5);
4. базовая (требует логин и пароль, передаваемый по сети открытым
текстом);
5. проверка с использованием паспорта .NET (используются реквизиты
действующей учетной записи паспорта .NET).
В случае если для сайта назначены несколько методов аутентификации, IIS
выберет самый защищенный. Однако если в числе прочих выбран анонимный
доступ, он будет использоваться в первую очередь, а если выбрана
аутентификация по паспорту .NET, другие методы будут недоступны.
Если Web-сервис требует надежной аутентификации, можно настроить
службы IIS на использование сертификатов. Службы IIS имеют собственные
хранилища сертификатов. Каждый Web-сайт располагает собственным списком
доверенных сертификатов. Поэтому при использовании системы открытых
ключей для доступа к web-сайту, для каждого из размещенных на сервере сайтов
56
необходимо устанавливать свои сертификаты и управлять их списками отдельно.
А вот список отозванных сертификатов в IIS общий.
В случае если доступ к Web-сайту осуществляется посредством VPN или по
коммутируемой линии, для аутентификации применяют технологию RADIUS.
При использовании этой технологии нужно пользоваться следующими
рекомендациями:
1. в свойствах учетных записей пользователей на вкладке Входящие
звонки необходимо настроить управление подключением на основе политики
удаленного доступа;
2. для доступа к Web-сайтам спроектировать специальные группы
безопасности в зависимости от ролей пользователей;
3. для разработанных групп создать политики удаленного доступа;
4. необходимо шифровать данные, которыми обмениваются клиенты и
сервис RADIUS;
5. необходимо вести анализ журналов безопасности сервиса RADIUS.
Мониторинг web-сервера должен быть основан на базовых принципах
мониторинга производительности и безопасности для серверов. Количество
записей в журнале безопасности на этом сервере, как и на любом другом, зависит
от его загруженности и действующей политики аудита. Однако необходимо
учесть, что служба IIS ведет собственные файлы журналов, для работы с
которыми встроенной группе SYSTEM необходимо дать Полный доступ,
Администраторам – разрешение на чтение, изменение и удаление, а группе Все
полностью запретить доступ.
57
Recommended
