Материалы распечатаны с сайта OSzone.net. Дальнейшее применение материалов в других печатных изданиях, включая электронные статьи, должно сопровождаться указанием имени сайта OSzone.net и имени автора, если присутствует.

Защита сети от неуправляемых клиентов OSzone.net » Microsoft » Информационная безопасность » Защита сети от неуправляемых клиентов

Иcточник: Microsoft TechNet Опубликована: 18.03.2007

Введение

Ознакомьтесь с этим руководством по безопасности для компаний среднего размера. Корпорация Майкрософт надеется, что приведенные в документе сведения помогут создать более безопасную и производительную вычислительную среду.

Аннотация

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

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

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

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

Обзор

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

Введение

В этом разделе содержатся основные положения документа, а также обзор его структуры и некоторые сведения относительно целевой аудитории данного документа.

Определение

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

Трудности

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

Решения

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

Для кого предназначено это руководство

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

Конкретные технологии, обсуждаемые в данном документе.

•	Проверка подлинности IEEE 802.1X.
•	Политики IPsec.
•	Сетевая безопасность.
•	Microsoft® Systems Management Server 2003.
•	Microsoft Windows Server™ 2003.
•	Служба каталогов Active Directory®.
•	Microsoft Operations Management Server.
•	Microsoft Internet Authentication Service.
•	Проверка подлинности RADIUS.

Определение

В этом руководстве в дополнение к функциям управления службы администрирования безопасности и контроля над происшествиями MOF (SMF) используется модель процессов Microsoft Operations Framework (MOF).

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

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

Рис. 1. Применение MOF

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

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

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

Дополнительные сведения о MOF см. на веб-узле Microsoft Operations Framework Microsoft TechNet (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Дополнительные сведения о процессе управления безопасностью SMF см. на странице Security Management Functions (функции управления безопасностью) (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Управление рисками — это процесс определения уровня риска, приемлемого для организации, оценки текущих рисков, поиска способов достижения приемлемого уровня риска и устранения риска. Хотя в этом документе описываются некоторые концепции управления рисками, подробное обсуждение управления рисками является отдельной темой и выходит за рамки этого документа. Дополнительные сведения об анализе и оценке рисков см. в статье Security Risk Management Guide (руководство по управлению рисками, связанными с безопасностью) (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Трудности

Ниже перечислены некоторые трудности, связанные с защитой от неуправляемых компьютеров.

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

Решения

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

В следующем разделе приведены сведения, относящиеся к перечисленным трудностям и следующим подходам.

•	Использование изоляции домена и сервера IPsec для предотвращения получения неуправляемыми компьютерами доступа к сетевым ресурсам.
•	Использование карантина VPN для реализации политик безопасности на компьютерах, подключающихся к сети в удаленном режиме.
•	Использование проверки подлинности 802.1X для защиты от ненадежных беспроводных устройств.
•	Использование SMS для обнаружения неуправляемых компьютеров при их подключении к сети.

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

Оценка

В этом разделе предлагается ряд возможных действий по устранению проблем, которые неуправляемые компьютеры представляют для компаний среднего размера. Здесь также рассматриваются решения, которые необходимо принять перед тем, как предпринять любое из этих действий. Любое из рассматриваемых действий позволяет повысить уровень безопасности сети компании среднего размера. Тем не менее, при реализации в рамках комплексного подхода к безопасности совместное использование ответных действий приводит к более изощренному реагированию на проблемы, описанные в разделе «Трудности».

Использование IPsec для изоляции доменов и серверов

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

Таблица 1. Подходы к изоляции сети

Уровень модели OSI	Подход	Проблемы
Уровень 1	Использование отдельной кабельной системы для сегментов, которые требуется изолировать от надежной сети.	• Затраты, связанные с проведением нового кабеля для каждого нового подключения. • Повышенные административные накладные расходы на проведение кабелей при перемещении пользователей. • Недостаточная гибкость и сложность в управлении по мере роста компании. • Повышенная вероятность упущений и ошибок вследствие высоких требований к управлению.
Уровень 2	Использование виртуальных локальных сетей для создания логических подсетей, изолированных от надежной сети.	• Повышенные затраты, связанные с обновлением системы коммутации для поддержки виртуальных локальных сетей. • Повышенные административные накладные расходы на отслеживание изменений в сети, перемещений пользователей и ответы на запросы гостевых подключений. • Предрасположенность к упущениям и ошибкам при массовом перемещении пользователей и использовании мобильных устройств.

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

Изоляция сервера и домена, предлагаемая корпорацией Майкрософт, позволяет ИТ-администраторам ограничивать обмен данными по протоколу TCP/IP путем усиления встроенной групповой политики Active Directory и IPsec, что дает следующие преимущества.

•	Использование сетевого уровня модели OSI, что означает возможность охвата границ коммутаторов и маршрутизаторов.
•	Независимость от системы коммутации и физических ограничений сети.
•	Снижение затрат благодаря встроенным возможностям проверки подлинности компьютеров с ОС Windows.
•	Автоматизированное решение, не требующее постоянного обслуживания, связанного с изменениями сети и перемещениями пользователей.
•	Возможность не только проверять подлинность надежных компьютеров, но и шифровать обмен данными между надежными компьютерами.
•	Реализация политик безопасности за счет отказа в подключении неуправляемых устройств.
•	Улучшенное управление аудитом и ресурсами.
•	Возможность быстрой изоляции определенных ресурсов в случае возникновения атаки.

Типичные проблемы при использовании IPsec для безопасного взаимодействия были устранены благодаря недавним разработкам, направленным на решение этих проблем. А именно, трансляция сетевых адресов (NAT) больше не является проблемой, поскольку в новых версиях Microsoft Windows (например Windows Server 2003 и Microsoft Windows XP с пакетом обновления 2 (SP2) появились возможности прослеживания NAT. Кроме того, поддержка платформ, не поддерживающих IPsec, может осуществляться с помощью настраиваемых списков исключений или через переход на небезопасное взаимодействие с такими системами с использованием открытого текста.

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

Сведения об изоляции домена и сервера

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

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

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

Рис. 2. Изоляция сети с использованием доменов Active Directory

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

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

Рис. 3. Изоляция сети и пограничные группы

Модель изоляции сети, подобная этой, позволяет уменьшить зону безопасности сети компании. Тем не менее, это решение само по себе не может гарантировать, что надежные компьютеры не перестанут соответствовать стандартам, которые делают их надежными. Это решение само по себе не является комплексным решением для безопасности сети. Оно является частью более крупного комплексного процесса обеспечения безопасности, который, в сочетании с другими решениями, может помочь снизить риски, которым подвержены современные сети компаний среднего размера. А именно, при использовании совместно с другими решениями по обеспечению безопасности, такими как WSUS, SMS, MOM и др., можно использовать данный метод изоляции для обеспечения в изолированной сети соответствия требованиям политики безопасности.

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

Сведения об IPsec

IPsec является стандартом безопасности протокола Интернета, который обеспечивает общий механизм безопасности на уровне IP на основе политик, что идеально подходит для выполнения проверки подлинности между узлами. Политики IPsec определяются как правила и параметры безопасности, управляющие потоком входящего и исходящего трафика на компьютере. Эти политики централизованно управляются в Active Directory с помощью объектов групповой политики (GPO), используемых для назначения политики членам домена. Они обеспечивают возможность установления безопасных каналов связи между членами домена, что является основой этого решения.

IPsec использует протокол IKE для согласования параметров между двумя узлами для определения способа безопасного взаимодействия с помощью IPsec. Соглашения, установленные между двумя узлами, и различные параметры, определяющие метод согласования, называются сопоставлениями безопасности (SA). Microsoft Windows может использовать один из трех указанных ниже методов протокола IKE.

•	Протокол проверки подлинности Kerberos версии 5.
•	Цифровые сертификаты X.509 с соответствующими парами ключей RSA.
•	Предварительные ключи с использованием идентификационных фраз.

Примечание.   Хотя в качестве метода проверки подлинности можно использовать инфраструктуру открытых ключей (PKI), этот подход не рекомендуется использовать ввиду интеграции проверки подлинности домена Windows 2000 (Kerberos) в протокол согласования IKE.

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

Помимо проверки подлинности IPsec может выполнять другие полезные функции, включая возможности поддержания целостности и шифрования сетевого трафика с использованием параметров заголовков проверки подлинности (AH) и безопасного закрытия содержания (ESP). Хотя заголовки проверки подлинности (AH) можно использовать для того, чтобы гарантировать, что пакет не был изменен при передаче, использование заголовков для выполнения этой задачи приводит к несовместимости с трансляцией сетевых адресов (NAT). Протокол ESP, который обычно применяется для шифрования трафика, можно использовать в режиме нулевого шифрования (ESP/null), что обеспечивает проверку целостности данных, совместимую с NAT.

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

Дополнительные сведения см. на странице корпорации Майкрософт «Изоляция сервера и домена» (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Углубленная защита

Рис. 4. Модель углубленной защиты с логической изоляцией

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

•	Логическая изоляция не может защищать сетевые устройства, такие как маршрутизаторы.
•	Логическая изоляция не может защищать сетевые соединения, как это делают 802.11i WPA для шифрования беспроводных соединений и 802.1x EAP-TLS для контроля беспроводного доступа.
•	Логическая изоляция не может обеспечить безопасность всех узлов в сети, поскольку она распространяется только на компьютеры, которые имеют учетные данные надежного компьютера и подчиняются политике IPsec на основе доменов.
•	В отличие от протоколов HTTPS и SSL для веб-приложений логическая изоляция плохо приспособлена для обеспечения безопасности путей уровня приложений и не имеет автоматически настраиваемого метода для выполнения этой задачи.

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

Использование служб карантина VPN для защиты от неуправляемых удаленных компьютеров

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

Карантинный контроль доступа к сети на основе Microsoft Windows Server 2003 помогает устранить эту проблему путем задержки удаленного доступа к VPN до тех пор, пока состояние конфигурации подключающегося компьютера не будет проверено на соответствие текущим стандартам политики безопасности.

Сведения о службах карантина VPN

Карантинный контроль доступа к сети — это функция, предоставляемая семейством ОС Windows Server 2003, которая задерживает запуск служб удаленного доступа, пока подключающиеся удаленные компьютеры не будут изучены и проверены сценарием, настроенным администратором. Обычно при инициализации удаленного сеанса пользователь проходит проверку подлинности, а удаленному компьютеру предоставляется IP-адрес, но на этом этапе подключение переводится в режим карантина, при котором доступ к сети ограничен до тех пор, пока на удаленном компьютере не будет выполнен сценарий, предоставленный администратором. После выполнения сценария и получения сервером удаленного доступа уведомления о том, что удаленный компьютер соответствует настроенным сетевым политикам, режим карантина прекращается, а удаленному компьютеру предоставляется доступ к сети.

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

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

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

Примечание.   Карантинный контроль доступа к сети — это не то же самое, что и защита доступа к сети (NAP), новая платформа реализации политик, которая будет включена в новое семейство ОС Windows Server Longhorn. Дополнительные сведения о NAP см. в Приложении A «Защита доступа к сети» в конце этого документа.

Компоненты карантинного контроля доступа к сети

Рис. 5. Компоненты карантинного контроля доступа к сети Windows

На рисунке выше показаны типичные компоненты решения удаленного доступа Windows, в котором используется карантинный контроль доступа к сети. Ниже перечислены некоторые из этих компонентов.

•	Клиент удаленного доступа, поддерживающий карантин. Этот компонент представляет собой компьютер с версией Windows, поддерживающей профили диспетчера подключений, создаваемые с помощью пакета администрирования диспетчера подключений (CMAK), который поставляется совместно с Windows Server 2003. Поддерживается в версиях Windows, начиная с Windows 98 Second Edition. На этих клиентских компьютерах должен быть установлен компонент уведомлений, сценарий требований сетевой политики, и они должны быть настроены для запуска сценария после подключения.
•	Сервер удаленного доступа, поддерживающий карантин. Этот компонент представляет собой компьютер с Windows Server 2003 с запущенной службой маршрутизации и удаленного доступа, поддерживающий использование компонента прослушивания и атрибуты поставщика RADIUS (VSA) MS-Quarantine-IPFilter и MS-Quarantine-Session-Timeout наряду с установленным компонентом прослушивания.
•	Сервер RADIUS, поддерживающий карантин. Этот компонент не является обязательным и используется при настроенной на сервере удаленного доступа с Windows Server 2003 и IAS проверке подлинности RADIUS для поддержки атрибутов поставщика RADIUS MS-Quarantine-IPFilter и MS-Quarantine-Session-Timeout.
•	Ресурсы карантина. Эти компоненты представляют собой серверы и службы, к которым удаленный клиент может получить доступ, находясь в режиме карантина. Обычно они состоят из серверов, предоставляющих услуги DNS, профилей диспетчера подключений или поставщиков обновлений системы безопасности, предназначенных для приведения клиентов в соответствие с требованиями.
•	База данных учетных записей. Обычно этот компонент представляет собой домен Active Directory, в котором хранится учетная запись удаленного пользователя и размещены свойства доступа по коммутируемым линиям.
•	Политика карантина удаленного доступа. Эта политика необходима для обеспечения необходимых условий для работы подключений удаленного доступа и указания атрибутов MS-Quarantine-IPFilter или MS-Quarantine-Session-Timeout.

Углубленная защита

Рис. 6. Углубленная защита и карантинный контроль доступа к сети

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

Кроме того, данное решение улучшает защиту самой сети от разрушительного воздействия неправильно настроенных незаконно подключающихся удаленных компьютеров (включая распространение вредоносных программ, способное оказать пагубное влияние на производительность сети). Может показаться, что периметр сети не затрагивается этим решением, поскольку оно не защищает напрямую от атак на VPN (которая расположена именно на периметре) методом прямого подбора паролей. Однако это решение обеспечивает дополнительный уровень безопасности, с которым злоумышленнику придется столкнуться при попытке получения прямого доступа к ресурсам, расположенным во внутренней сети — даже если злоумышленнику удастся получить допустимые учетные данные для проверки подлинности.

Использование проверки подлинности 802.1X для защиты от неуправляемых клиентов беспроводных сетей

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

Сведения о проверке подлинности IEEE 802.1X

Проверка подлинности IEEE 802.1X представляет собой механизм контроля доступа на основе портов, который можно настроить на выполнение взаимной проверки подлинности между клиентами и сетью. После реализации такой настройки любое устройство, которому не удалось пройти проверку подлинности, не сможет участвовать ни в каком взаимодействии с выбранной сетью.

Стандарт 802.1X поддерживает расширяемый протокол проверки подлинности (EAP), который имеет ряд версий. В современных версиях Microsoft Windows имеется встроенная поддержка трех из них.

•	EAP-MD5. В версии MD5 сервер проверки подлинности отправляет клиенту (запрашивающему устройству) вызов, а запрашивающее устройство объединяет этот запрос вызова с собственным идентификатором или парольной фразой. Этот отклик преобразуется в хэш MD5 и отправляется обратно на сервер проверки подлинности, который расшифровывает и сопоставляет отклик с исходным вызовом. Если отклик соответствует вызову, значит, проверка подлинности прошла успешно. Этот метод не является безопасным в большинстве реализаций, поскольку отправляется сам пароль, который могут перехватить и расшифровать посторонние лица.
•	Защищенный EAP. В защищенном EAP (PEAP) для взаимной проверки подлинности используется сертификат на стороне сервера и сведения о проверке подлинности, полученные от клиента (например имя пользователя и пароль). В реализации этого стандарта, выполненной корпорацией Майкрософт, используется протокол проверки пароля MS-CHAP версии 2, проверка подлинности в котором основывается на традиционных сведениях об учетной записи домена и пароле и использовании сервера RADIUS. Этот метод обычно считается достаточно безопасным в небольших компаниях, которые не могут позволить себе дополнительные затраты на администрирование и создание инфраструктуры, необходимые при использовании метода EAP-TLS.
•	EAP-TLS. При использовании этого метода сервер проверки подлинности устанавливает с соискателем сеанс TLS с последующей отправкой клиенту цифрового сертификата. Запрашивающее устройство проверяет при получении этот сертификат, а затем отправляет в ответ свой собственный сертификат, который, в свою очередь, проверяется сервером проверки подлинности. Если каждая из сторон доверяет сертификату другой стороны, значит, проверка подлинности прошла успешно. Этот подход наилучшим образом подходит для сетей, которые могут поддерживать инфраструктуру открытых ключей и серверы проверки подлинности RADIUS. Это также наиболее безопасный из доступных вариантов для беспроводных сетей, особенно в сочетании с использованием стандарта 802.11i WPA2.

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

Причины неэффективности 802.1X для проводных сетей

Хотя использование стандарта 802.1X обычно помогает решить вопрос с безопасностью беспроводных сетей, имеются некоторые проблемы с внедрением этого метода для обеспечения безопасности проводных сетей. Первая проблема заключается в том, что, хотя в 802.1X имеется несколько объектов групповой политики Active Directory, которые поддерживают его реализацию в беспроводных сетях, проверка подлинности 802.1X в проводных сетях не поддерживается. Таким образом, подобное использование 802.1X потребует значительных накладных расходов на управление. Кроме того, многие коммутаторы, сетевые принтеры и иные устройства инфраструктуры проводной сети не поддерживают стандарт 802.1X, поэтому весьма вероятно, что для поддержки подобной реализации в большинстве сетей компаний среднего размера потребуется дорогостоящее обновление.

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

Примечание.   Эти недостатки и уязвимости не проявляются в беспроводных сетях. Данные проблемы с безопасностью 802.1X имеют место только при использовании этого стандарта в проводных сетях.

В связи с этими проблемами для изоляции домена и сервера рекомендуется использовать протокол IPsec, а не 802.1X. Однако эта рекомендация не означает, что для 802.1X нет места в сети компании среднего размера. Как было сказано ранее, 802.1X является ценным средством, помогающим устранить проблемы с безопасностью беспроводных сетей, а в сочетании с решением по изоляции сети на основе IPsec становится еще более безопасным.

Углубленная защита

Рис. 7. Углубленная защита с использованием 802.1X для безопасности беспроводной сети

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

Использование SMS-сервера для обнаружения и устранения уязвимостей неуправляемых компьютеров

Сервер Microsoft Systems Management Server (SMS) 2003 часто используется для управления компьютерами в сети, работы с данными о движении активов, а также распространения программного обеспечения и обновлений для поддержки соответствия политикам безопасности и поддержания единообразия платформ и установленного программного обеспечения. Функции сетевого обнаружения и инвентаризации SMS 2003 входят в область рассмотрения данного документа, поскольку они предоставляют метод, позволяющий обнаружить ненадежные компьютеры при их подключении к сети. Эти функции также помогают устранять уязвимости с учетом того, какие политики реализуются в ответ на использование неуправляемого компьютера.

В этом документе предполагается, что читатель использовал SMS-сервер и другие методы приведения компьютеров, входящих в домен, в соответствие с политиками безопасности, что включает установку всех обновлений безопасности. Таким образом, вопросы управления исправлениями с использованием SMS 2003 и других средств выходят за рамки данного документа. Дополнительные сведения по этим темам и иные сведения, относящиеся к SMS-серверу, см. в документе «Управление исправлениями с помощью Systems Management Server 2003» (эта ссылка может указывать на содержимое полностью или частично на английском языке) или на домашней странице Microsoft Systems Management Server (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Обнаружение и документирование имеющихся активов

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

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

Хотя SMS-серверу, возможно, не удастся собрать никакие сведения о таких неуправляемых компьютерах за исключением IP-адреса и имени, этих сведений самих по себе зачастую достаточно для определения того, являются ли сетевые устройства авторизованными или нет.

Разработка

В разделе «Оценка» показано, что сочетание различных решений, выполняющих определенные функции в сети компании среднего размера, является наиболее полным подходом к защите такой сети. Изоляция домена и сервера охватывает проводную сеть, гарантируя, что только известные и управляемые компьютеры могут получить доступ к надежным ресурсам. Карантин VPN гарантирует, что удаленные компьютеры, время от времени подключающиеся к локальной сети, будут соответствовать политикам безопасности. Проверка подлинности 802.1X обеспечивает безопасность беспроводной сети, позволяя устанавливать подключения только авторизованным компьютерам. Наконец, SMS-сервер используется для поддержания соответствия надежных компьютеров установленным политикам и обнаружения ненадежных неконтролируемых компьютеров при их подключении к сети. Сочетание всех этих решений позволяет защитить сеть от несанкционированных подключений и незаконно подключаемых компьютеров.

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

Использование IPsec для изоляции доменов и серверов

Разработка плана реализации изоляции домена и сервера на основе IPsec включает определение возможности реализации этого решения в данной сетевой среде, а также сбор предварительных сведений, необходимых для разработки плана реализации. Концепция изоляции сети на основе IPsec представлена в разделе «Оценка» данного документа. Теперь, когда преимущества этого подхода известны, имеется возможность сравнить их с возможными проблемами, связанными с подобной реализацией. В этом разделе рассматриваются некоторые проблемы, связанные с реализацией изоляции сети на основе IPsec, а также требования к подобной реализации для содействия процессу принятия решения.

Определение инфраструктуры сети

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

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

Документирование архитектуры сети должно с высокой степенью точности отражать текущее состояние и содержать указанные ниже сведения.

•	Сведения о брандмауэрах и средствах балансировки нагрузки и их местоположении.
•	Сведения о сетевых устройствах, включая размер ОЗУ, марку или модель и параметры MTU.
•	Отчеты о сетевом трафике и использовании сети.
•	Использование трансляции сетевых адресов.
•	Сегментация виртуальной локальной сети (VLAN).
•	Сетевые соединения устройств.
•	Сведения о системе обнаружения вторжений (IDS).

Определение потока сетевого трафика

Помимо сведений об устройствах и настройках, которые могут оказать влияние на изоляцию сети на основе IPsec, важно изучить структуру сетевого трафика внутри сети. При сборе сведений этого типа важно учитывать такие факторы как способ взаимодействия устройств, не работающих под управлением Windows (например компьютеры под управлением Linux), или устройств, использующих версию Windows до Windows 2000 с пакетом обновления 4, с другими компьютерами под управлением Windows. Дополнительные аспекты.

•	Имеются ли подсети, предназначенные для определенных типов трафика, например взаимодействия больших ЭВМ?
•	Необходимо ли разделять трафик между различными местоположениями?
•	Имеются ли типы трафика, требующие высокого уровня безопасности, обеспечиваемого шифрованием, например, при взаимодействии с базой данных сотрудников?
•	Имеются ли устройства, связанные с безопасностью, или параметры брандмауэра, которые могут оказать влияние на реализацию, например, блокировка UDP-порта 500?
•	Каким образом взаимодействуют приложения? Например, используют ли они удаленный вызов процедур (RPC), который может потребовать дополнительного рассмотрения?
•	Каким образом узлы и серверы взаимодействуют друг с другом? Используют ли они подключения уровня портов и протоколов или устанавливают множество сеансов, используя широкий диапазон протоколов?

Определение структуры Active Directory

Чтобы понять, какое влияние может оказать реализация IPsec на структуру Active Directory, помимо ранее собранных сведений о сети важно собрать сведения о структуре леса Active Directory, компоновке домена, схеме подразделений и топологии сайта. Эти сведения должны включать указанные ниже типы данных.

•	Количество лесов.
•	Количество доменов и их имена.
•	Количество и типы доверительных отношений.
•	Количество сайтов и их имена.
•	Структура подразделений и групповой политики.
•	Сведения о любых существующих политиках IPsec (если IPsec используется в настоящий момент).

Идентификация узлов.

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

•	Имена компьютеров.
•	IP-адреса, особенно статические адреса.
•	MAC-адреса.
•	Версия операционной системы, включая уровни пакетов обновления и ревизий исправлений.
•	Членство в домене.
•	Физическое местонахождение.
•	Роль и тип оборудования.

Определение емкости IPsec

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

•	Использование памяти сервера. Каждый сеанс может потреблять до 5 КБ ОЗУ.
•	Загрузка ЦП сервера, рабочей станции, и инфраструктурного устройства. Эти сведения особенно важны для серверов. Убедитесь в том, что устройства уже не используются слишком интенсивно.
•	Сетевая задержка и загрузка сети. При использовании IPsec задержка увеличится. Когда корпорация Майкрософт развернула IPsec, загрузка сети увеличилась с 1 % до 3 %.
•	Использование трансляции сетевых адресов (NAT) и типа шифрования. Взаимодействие с использованием заголовков проверки подлинности (AH) не проходит через NAT. Таким образом, для шифрования взаимодействия необходимо использовать безопасное закрытие содержания ESP. ESP создает большую нагрузку на сеть, чем шифрование AH, если только не используется нулевое шифрование ESP.
•	Влияние групповой политики. Объекты групповой политики IPsec оказывают влияние на время запуска компьютера и входа в систему. Для определения фактического влияния необходимо выполнить замеры времени до и после тестовой реализации.

Определение уровней доверия

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

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

•	Надежный. Состояние «Надежный» подразумевает, что риски, связанные с безопасностью узла, находятся под контролем, а другие надежные узлы могут рассчитывать на отсутствие вредоносных действий со стороны этого узла. Хотя это состояние не обязательно означает, что узел полностью безопасен, оно означает, что состояние этого узла находится в рамках ответственности ИТ-отдела и управляется с помощью определенного механизма, который может быть автоматическим или представлять собой документированный процесс. Поскольку этот узел является надежным, инфраструктура сети не должна препятствовать взаимодействию между этим узлом и другими надежными узлами. Поскольку можно с уверенностью предполагать, что на этом узле не будут выполняться никакие вредоносные действия, нет необходимости блокировать или фильтровать трафик с этого узла с помощью брандмауэров или подобных мер.
•	Заслуживающий доверия. Состояние «Заслуживающий доверия» означает, что, хотя компьютер способен стать надежным устройством, для сертификации в качестве надежного он все еще требует внесения дополнительных изменений в конфигурацию или установки каких-либо обновлений. Определение таких компьютеров особенно важно в процессе проектирования, поскольку они являются показателем количества усилий и затрат, которые могут потребоваться для создания изолированной сети.
•	Известный, ненадежный. Имеется ряд причин, по которым известный компьютер не способен стать надежным активом, включая финансовые ограничения, потребности бизнеса или даже функциональные требования. Например, финансирования проекта может быть недостаточно для обновления всех компьютеров, некоторые подразделения компании могут иметь собственные домены, или старое приложение может быть несовместимо с поддерживаемыми в настоящий момент операционными системами и поэтому не может быть запущено на безопасном компьютере. Вне зависимости от причины владельцы известных, но ненадежных компьютеров должны проконсультироваться, чтобы определить, можно ли что-либо сделать, чтобы привести компьютер в соответствие с установленными политиками и определить способы устранения этой проблемы при поддержании приемлемого профиля риска.
•	Неизвестный, ненадежный. Состояние «Неизвестный, ненадежный» должно быть состоянием по умолчанию для всех узлов. Узлы в этом состоянии неуправляемы, а их конфигурации неизвестны, поэтому им нельзя назначить никакое другое состояние. Следует предполагать, что эти узлы могут быть взломаны и использованы в качестве платформ для вредоносных действий, и поэтому данные узлы представляют неприемлемый уровень риска для компании. Это решение рассчитано на уменьшение потенциального влияния таких систем.

Использование собранных сведений

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

•	Стоимость обновлений, необходимых для приведения узлов в соответствие с состоянием «Надежный» и обеспечения совместимости с требованиями IPsec.
•	Стоимость обновления инфраструктуры или замены текущих сетевых устройств, которые не поддерживают IPsec.
•	Нахождение баланса между возможным снижением качества обслуживания на основе маршрутизатора и преимуществами изоляции сети для безопасности, поскольку при реализации IPsec назначение приоритетов на основе портов не будет работать, а качество обслуживания на основе IP-адресов продолжит функционировать.
•	Устройства для наблюдения за сетью и обнаружения вторжений могут не работать после внедрения IPsec, особенно, если используется шифрование ESP. Для решения этой проблемы можно использовать синтаксические анализаторы, если устройство поддерживает синтаксический анализатор IPsec.
•	Реализация IPsec может потребовать обновления оборудования из-за увеличения накладных расходов и требований к ЦП и оперативной памяти для серверов и сетевых устройств.
•	Возможны проблемы с управлением ожиданием, поскольку сетевая задержка может увеличиться.
•	Работа с поставщиками и гостевыми пользователями также может обернуться чрезмерными накладными расходами, поскольку у этих пользователей имеются ненадежные устройства и могут быть связанные с бизнесом причины, по которым им необходимо иметь доступ к сетевым ресурсам изолированной сети. Подобными исключениями трудно управлять, поскольку их количество и частота возникновения увеличиваются, но их можно обойти, используя пограничную зону между надежной и ненадежной сетями.

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

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

Использование служб карантина VPN для защиты от неуправляемых удаленных компьютеров

В случае стандартного сеанса сервера удаленного доступа на основе Windows сервер выполняет при инициализации сеанса клиентом удаленного доступа перечисленные ниже действия.

1.	Сервер удаленного доступа выполняет проверку на соответствие заданным политикам удаленного доступа и разрешает подключение.
2.	Сервер проверяет разрешения удаленного доступа пользователя.
3.	Сервер проверяет учетные данные пользователя с помощью Active Directory или иной службы проверки подлинности.
4.	Сервер назначает удаленному клиенту IP-адрес.

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

Карантинное VPN-подключение имеет, тем не менее, ряд отличий, которые показаны на следующем рисунке и приведены в списке.

Рис. 8. Процесс карантина VPN

1.	Удаленный клиент запускает сценарий диспетчера подключений, который выполняется перед подключением и проверяет основные необходимые условия подключения (такие как уровень обновлений безопасности и дату создания файла с сигнатурами вирусов) и сохраняет результаты. После выполнения этого сценария клиент устанавливает сеанс удаленного подключения через туннель VPN.
2.	Сервер удаленного доступа проверяет учетные данные пользователя с помощью службы RADIUS, которая для проверки учетных данных использует служба Active Directory.
3.	После того как служба Active Directory проверила подлинность пользователя, сервер удаленного доступа переводит клиента в состояние карантина, применяя политику удаленного доступа. В состоянии карантина доступ к сети ограничен согласно параметрам политики карантина. Подобный ограниченный доступ можно реализовать с помощью фильтра IP-адресов, ограничивающего доступ к определенным ресурсам, используемым для приведения клиента в соответствие с политикой или путем задания периода ожидания, по истечении которого клиент будет отключен.
4.	Сценарий, выполняемый после подключения, уведомляет сервер удаленного доступа о том, соответствует ли клиент указанным требованиям. Если соответствие подключения не подтверждено в течение периода ожидания, пользователь получает уведомление с подробными сведениями об ошибке, а подключение прерывается.
5.	Если сценарий, выполняемый после подключения, сообщает о том, что клиент соответствует указанным требованиям, сервер удаленного доступа отключает режим карантина путем удаления ограничений фильтра IP-адресов, предоставляя разрешение на доступ к сетевым ресурсам, указанным в политике удаленного доступа.

Клиент удаленного доступа может получить доступ только к тем ресурсам, которые расположены в указанной карантинной сети, независимо от того, является ли эта сеть отдельной подсетью или заданным набором серверов с доступом в Интернет. Карантинная сеть должна предоставлять ресурсы, которые позволили бы удаленному клиенту выполнить действия по приведению удаленного компьютера в соответствие со стандартами безопасности. Как правило, эти ресурсы включают доступ к серверу DNS для разрешения имен, файловому серверу для загрузки обновлений, а также, возможно, к веб-серверу для получения инструкций или обновлений через Интернет.

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

Примечание.   Политики IPsec можно записать в сценарий, если карантинное решение должно работать с компьютерами, не входящими в домен. В таких случаях для применения простых политик с сертификатами для поддержки проверки подлинности IPsec можно использовать команды netsh или lpseccmd.exe. Протокол IPsec может использоваться с входящими в домен компьютерами в конфигурации карантина VPN наряду с многоуровневым решением.

Клиентские компоненты карантина VPN

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

•	Проверка безопасности перед подключением для автоматического управления конфигурацией компьютера клиента.
•	Проверка безопасности после подключения и проверка входа в систему.

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

•	Создание списков телефонных номеров, которые можно использовать для подключений удаленного доступа.
•	Настройка графики, значков, сообщений и текста справки.
•	Выполнение пользовательских действий перед подключением и после подключения, включая такие действия как сброс профиля номеронабирателя и настройка правил фильтра пакетов брандмауэра Windows.

Другим компонентом CMAK является агент клиента (RQC.exe), который взаимодействует со службой карантина удаленного доступа (RQS.exe) на сервере удаленного доступа, используя порт TCP 7250. При установке карантинного подключения RQS отправляет RQC общий секретный ключ. Если клиент соответствует необходимым условиям, RQC отправляет общий ключ для выведения клиента из карантина.

Профили диспетчера подключений представляют собой самораспаковывающиеся пакеты номеронабирателя клиента диспетчера подключений, которые можно создавать и настраивать с помощью CMAK. Мастер CMAK проводит администраторов через процесс настройки профиля, который впоследствии можно распространять с помощью ряда механизмов, начиная с групповой политики и заканчивая функцией распространения программного обеспечения сервера Microsoft Systems Management Server (SMS) 2003. При выполнении созданного исполняемого файла на компьютере клиента, этот файл устанавливает на локальный компьютер профиль и параметры, необходимые для установки соединения с серверами удаленного доступа. Чтобы установить подключение после завершения установки, пользователю необходимо только указать имя профиля в меню Подключение в Windows XP.

Дополнительные сведения о CMAK см. на странице пакета администрирования диспетчера подключений веб-узла Microsoft TechNet (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Серверные компоненты карантина VPN

Сервер удаленного доступа VPN является центральной частью этого решения и выполняет перечисленные ниже функции.

•	Запуск службы карантина удаленного доступа (RQS.exe).
•	Применение политик удаленного доступа к параметрам карантинного доступа.
•	Осуществление взаимодействия с агентом клиента.
•	Получение сведений о соответствии политике от агента клиента.
•	Применение политик удаленного доступа для определения разрешений на доступ к сетевым ресурсам.

Служба карантина удаленного доступа является необязательным компонентом в Windows Server 2003 с пакетом обновления 1, поддерживающим необходимые API-интерфейсы для перевода компьютеров удаленных клиентов в режим карантина и вывода из него после отправки агентом клиента уведомления о соответствии политике. Эта служба (RQS.exe) осуществляет прослушивание порта TCP 7250 для получения уведомления от компонента со стороны клиента (RQC.exe) о том, что компьютер клиента соответствует требованиям политики. Это означает, что для правильного функционирования данного решения необходимо, чтобы все брандмауэры, включая брандмауэры, установленные на узлах, разрешали прохождение трафика через порт TCP 7250.

Сетевые компоненты карантина VPN

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

•	Сервер службы проверки подлинности в Интернете (IAS) RADIUS (рекомендуется). Хотя серверы службы проверки подлинности в Интернете (IAS) необходимы только при использовании RADIUS в качестве поставщика проверки подлинности, они имеют несколько неоспоримых преимуществ перед другими решениями для проверки подлинности, включая поддержку расширяемого протокола проверки подлинности для поддержки двухфакторной проверки подлинности с использованием сертификатов и смарт-карт. При использовании RADIUS рекомендуется использовать в качестве поставщика RADIUS службу проверки подлинности в Интернете (IAS), поставляемую совместно с Windows Server 2003, поскольку она поддерживает атрибуты поставщика MS-Quarantine Session Timeout и MS-Quarantine-IPFilter VSA. Другие серверы RADIUS могут их не поддерживать.
•	Active Directory (рекомендуется). Active Directory играет для RADIUS роль базы данных проверки подлинности учетных записей пользователей и интегрируется со службой проверки подлинности в Интернете (IAS) и другими службами. При использовании в сочетании с IAS она может поддерживать двухфакторную проверку подлинности с использованием сертификатов или других методов.
•	Сервер DHCP (рекомендуется). Серверы DHCP используются для предоставления IP-адресов удаленным клиентам.
•	Сервер DNS (рекомендуется). Сервер DNS предоставляет службы разрешения имен, чтобы клиенты в сети карантина могли подключаться к другим серверам (если таковые имеются), которые могут помочь привести компьютеры удаленных клиентов в соответствие с политиками.
•	Сервер WSUS (необязательно). Серверы WSUS могут предоставлять необходимые обновления безопасности и исправления, которые могут потребоваться удаленным компьютерам для соответствия требованиям, позволяющим выйти из состояния карантина. Также можно использовать другие методы, включая SMS 2003 или даже стандартные службы Windows Update, если компьютеры необходимо перенаправить на внешние источники для получения обновлений.
•	Файловый сервер (необязательно). Файловые серверы можно использовать для создания общих ресурсов, через которые компьютеры, находящиеся в состоянии карантина, могут получить доступ к обновлениям программного обеспечения и файлам с сигнатурами вирусов для антивирусного программного обеспечения, чтобы соответствовать требованиям политики.
•	Веб-сервер (необязательно). Веб-серверы можно использовать в режиме карантина для предоставления пользователям инструкций по выводу их компьютеров из состояния карантина. Для доставки некоторых пакетов обновления также используются веб-компоненты (примером могут служить некоторые антивирусные программы).

Использование проверки подлинности 802.1X для защиты от неуправляемых клиентов беспроводных сетей

Проверка подлинности 802.1X была представлена в предыдущем разделе как наиболее эффективный из доступных вариантов обеспечения защиты беспроводных сетей от ненадежных компьютеров. Были описаны различные методы 802.1X, изначально поддерживаемые в текущих версиях Microsoft Windows, и приведено объяснение того, почему проверка подлинности 802.1X неэффективна для проводных сетей (хотя она весьма эффективна для беспроводных сетей). Располагая этими сведениями, можно рассмотреть различия между поддерживаемыми методами и определить, какой из них наилучшим образом подходит для различных типов сетей компаний среднего размера.

Сравнение методов 802.1X

Как уже ранее обсуждалось, имеется три метода 802.1X, поддерживаемых в текущих версиях Microsoft Windows. Это следующие методы:

•	EAP-MD5;
•	защищенный EAP (PEAP);
•	EAP-TLS.

Из этих трех методов первый (EAP-MD5) считается наименее безопасным, поскольку при его использовании парольные фразы передаются в эфир и могут быть перехвачены. Другие два метода (PEAP и EAP-TLS) заслуживают рассмотрения при развертывании в сетях компаний среднего размера.

Реализация PEAP корпорации Майкрософт использует протокол проверки подлинности по методу «вызов-приветствие» версии 2 (MS-CHAP v2), который изначально был разработан в качестве метода проверки подлинности для удаленного доступа через VPN, но хорошо подходит для PEAP, поскольку может поддерживать политики надежных паролей пользователей, доступные через Active Directory. Этот подход проще в реализации, чем EAP-TLS, и дешевле в плане ресурсов и первоначальных затрат, поскольку для его реализации не требуется большого количества дополнительных серверов и услуг. Хотя для этого решения требуются сертификаты для серверов проверки подлинности, эти сертификаты могут создавать сторонние поставщики сертификатов, поскольку для реализации решения не требуется большого количества сертификатов.

Однако EAP-TLS считается наиболее безопасной из имеющихся реализаций проверки подлинности 802.1X, поскольку в нем для выполнения взаимной проверки подлинности требуются сертификаты как со стороны клиента, так и со стороны сервера. Поскольку для подобной реализации требуется большое количество сертификатов, для ее поддержки рекомендуется внедрить инфраструктуру открытых ключей, если таковая отсутствует. Таким образом, EAP-TLS требует больших затрат на реализацию и поддержку по сравнению с PEAP с использованием MS-CHAP версии 2.

Процесс принятия решения относительно 802.1X

Чтобы облегчить процесс принятия решения относительно выбора лучшей реализации 802.1X для конкретной сетевой среды, корпорация Майкрософт разработала следующее дерево решений для проверки подлинности 802.1X.

Рис. 9. Дерево решений 802.1X

Эта блок-схема может привести к некоторой путанице из-за использующегося в ней термина «крупный бизнес». Под этим термином следует понимать любую организацию, в которой работает по меньшей мере 500 сотрудников и имеется ИТ-отдел, состоящий по меньшей мере из 5 специалистов. С учетом этих сведений становится ясно, что для компании среднего размера подойдет любое решение. Таким образом, процесс принятия решений развивается в большей степени в направлении определения параметров приемлемого уровня риска и экономической эффективности.

Ключевое различие между PEAP и EAP-TLS состоит в необходимости создания инфраструктуры сертификатов. Поэтому EAP-TLS обычно рассматривается как вариант, более подходящий для крупного бизнеса, а PEAP считается достаточным для более мелких организаций, если не существует нормативно-правовых ограничений, требующих использования более строгих стандартов безопасности. Помимо экономических соображений у организаций иногда имеются дополнительные потребности в инфраструктуре сертификатов, что является дополнительным обоснованием вложений в инфраструктуру открытых ключей. В итоге, если для защиты веб-содержимого или подписывания кода необходимо множество сертификатов, единственным разумным выходом будет использование такого вложения в инфраструктуру для реализации наиболее безопасной разновидности проверки подлинности 802.1X.

Требования 802.1X PEAP

Решение на основе PEAP с использованием MS-CHAP версии 2 корпорации Майкрософт требует наличия по меньшей мере двух серверов RADIUS службы проверки подлинности в Интернете (IAS) для работы в качестве серверов проверки подлинности для беспроводных клиентов по базе данных учетных записей Active Directory. Количество необходимых серверов RADIUS может зависеть от количества удаленных площадок или необходимости обработки большого количества попыток проверки подлинности со стороны пользователей.

Наличие удаленных объектов не требует автоматически дополнительных серверов RADIUS проверки подлинности через Интернет (IAS). Однако если удаленные объекты не имеют избыточных подключений с высокой пропускной способностью или уже используют собственные контроллеры домена или иные локальные ресурсы, тогда для таких объектов необходимо добавить дополнительные серверы.

Требования 802.1X EAP-TLS

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

В итоге простая реализация EAP-TLS потребует по меньшей мере четыре сервера, еще больше потребуется для более крупных компаний или для территориально распределенных сетей. Два из этих четырех серверов будут работать в качестве резервных серверов RADIUS службы проверки подлинности в Интернете (IAS), а другие два будут функционировать в качестве инфраструктуры сертификатов. Рекомендуется, чтобы один из этих двух серверов сертификатов (корневой сервер сертификатов) настраивался в отключенном от сети состоянии и оставался отключенным. Это означает, что при определенных обстоятельствах количество серверов может быть сокращено до одного.

Использование WEP или WPA

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

Имеется два вида шифрования беспроводных соединений с одним дополнительным вариантом. Это следующие виды.

•	WEP. Стандарт WEP (Wired Equivalent Privacy) входил в исходный стандарт IEEE 802.11, в котором для защиты беспроводных взаимодействий использовалось 64-рязрядное или 128-рязрядное шифрование RC4. В этом методе были обнаружены серьезные недостатки, которые делали его крайне уязвимым для атак с использованием пассивного прослушивания. Имеется ряд средств, способных расшифровать передачи WEP за относительно короткий промежуток времени, иногда за считанные минуты. Как правило, WEP не рекомендуется использовать в корпоративных системах, но его можно сделать относительно безопасным с помощью различных методов, включая использование проверки подлинности 802.1X.
•	WPA. В качестве ответа на слабости, присущие стандарту WEP, консорциум ведущих компаний отрасли, включая корпорацию Майкрософт и институт Wi-Fi, создал стандарт WPA (Wi-Fi Protected Access), представлявший собой частичную реализацию стандарта 802.11i, который в то время еще разрабатывался. Этот стандарт обеспечивает намного более надежное шифрование, основанное на использовании для шифрования данных протокола TKIP (Temporal Key Integrity Protocol), который значительно превосходит уязвимый стандарт WEP. Большинство имеющихся в настоящее время на рынке беспроводных точек доступа, а также все текущие версии ОС Microsoft Windows поддерживают стандарт WPA.
•	WPA2. Стандарт WPA2 (Wireless Protected Access 2) был установлен в сентябре 2004 г. альянсом Wi-Fi. Он сертифицирован в качестве полной реализации спецификации IEEE 802.11i, которая была ратифицирована в июне 2004 г. Этот стандарт поддерживает методы проверки подлинности EAP на основе 802.1X или технологию PSK (иногда называемую персональным режимом WPA), но в нем реализован более совершенный механизм шифрования, использующий протокол CCMP (Counter-Mode/CBC-MAC Protocol), который называется улучшенным стандартом шифрования (AES). Эта реализация шифрования беспроводных соединений чрезвычайно надежна. Большинство поставщиков поддерживают WPA2 в каком-либо виде. Не являются исключением и текущие версии ОС Microsoft Windows.

Для шифрования данных, передаваемых по беспроводным сетям, следует использовать WPA2 или WPA, если это возможно. Однако ввиду новизны данных стандартов это не всегда возможно, особенно, если значительные средства были вложены в беспроводное оборудование, которое не поддерживает эти стандарты. Как было упомянуто ранее, можно повысить уровень безопасности, обеспечиваемый стандартом WEP, путем настройки проверки подлинности 802.1X и частой смены пар ключей. Однако даже в этом случае, использование WEP должно быть ограничено беспроводными сетями, которые находятся в состоянии перехода на стандарт WPA или WPA 2.

Использование SMS-сервера для обнаружения неуправляемых компьютеров

Сервер Microsoft Systems Management Server (SMS) 2003 является весьма универсальным средством управления в сети Майкрософт. С помощью SMS-сервера можно осуществить централизацию нескольких функций управления, включая доставку программного обеспечения, развертывание обновлений безопасности и аудит компьютеров. Среди этих функций основной является возможность автоматизированной и централизованной инвентаризации компьютеров, с которых устанавливаются эти крайне полезные средства. Именно при этом начинает действовать обнаружение неуправляемых систем.

Сервер SMS 2003 обеспечивает различные методы обнаружения, которые администраторы могут использовать для создания базы данных компьютеров, содержащей сведения о каждом компьютере в сети. Эти методы обнаружения варьируются от обнаружения на основе Active Directory (при котором список компьютеров обновляется на основе сведений, предоставляемых списком учетных записей компьютеров Active Directory) до сетевого метода обнаружения (при котором сеть активно проверяется на наличие любых подключенных устройств). Эти методы обнаружения можно настроить на автоматический запуск через предварительно определенные промежутки времени и обновление баз данных компьютеров по завершении работы.

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

Процесс сетевого обнаружения

Одним из недостатков подобного подхода к обнаружению неуправляемых компьютеров является то, что SMS-сервер может испытывать трудности при получении подробных сведений о компьютерах, использующих операционные системы, отличные от Microsoft Windows. На самом деле, даже версии Windows до Microsoft Windows 98 SE могут не обнаруживаться методами SMS 2003, поскольку они не поддерживают реализации интерфейса управления Windows (WMI). Соответственно, к данному решению необходимо добавить сценарии для обнаружения любого нового устройства, подключаемого к сети. На следующем рисунке показана работа такого процесса.

Рис. 10. Процесс обнаружения неуправляемого компьютера с помощью SMS

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

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

На этом этапе должно быть понятно, что процесс обнаружения неуправляемых компьютеров в сети зависит от внедрения процессов, которые подробно документируют сведения о каждом авторизованном подключении компьютера к сети. Такая документация должна содержать подробные сведения о компьютере, вне зависимости от использования для управления им автоматических методов (таких как SMS). Если такие сведения отсутствуют, то в документации должны быть данные о процессе, используемом для поддержания соответствия компьютера установленным политикам безопасности, если таковые имеются. Разумеется, в сети могут быть авторизованные компьютеры, для которых не требуется обязательного соответствия стандартам безопасности. Однако подобные компьютеры должны быть принудительно помещены в ненадежный сегмент сети, изолированный от надежной сети.

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

Развертывание и управление

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

Использование IPsec для изоляции доменов и серверов

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

Независимо от того, какой из методов используется, важно использовать опытные образцы из каждой группы на начальных стадиях развертывания, а также по возможности тестировать влияние этого решения в тестовой среде. Развертывание IPsec должно проходить в соответствии с формальной процедурой запросов контроля изменений, которая подробно описывает планы развертывания, а также запросы от владельцев технологических и бизнес-процессов.

Развертывание IPsec по группам

В методе внедрения изоляции сети на основе IPsec по группам используются полностью определенные политики IPsec. Для контроля над реализацией используются списки доступа (ACL) для объектов групповой политики, которые осуществляют доставку политик. Перед развертыванием во всех политиках IPsec должны быть полностью определены все исключения и безопасные подсети с помощью соответствующих действий фильтров.

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

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

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

Развертывание IPsec по политике

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

Преимущества использования метода поэтапного развертывания заключаются в том, что IPsec используется только для небольшой доли общего трафика TCP/IP, а не для всех подсетей, как в случае с подходом развертывания по группам. Кроме того, этот метод допускает тестирование всех сетевых путей из одной подсети, сокращая таким образом количество клиентов, затрагиваемых в случае возникновения каких-либо проблем. Проблема, связанная с этим подходом, заключается в том, что он применяется ко всем компьютерам в изолированном домене или группе, а не к определенным компьютерам, как в случае развертывания по группам. Кроме того, на определенном этапе все компьютеры столкнутся с трехсекундной задержкой при переходе в незащищенный режим при инициализации соединений с указанными подсетями.

Этот подход хорошо работает для сложных сетей с множеством подсетей, но малопривлекателен для более мелких сетей с относительно небольшим количеством подсетей.

Списки исключений

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

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

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

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

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

Примечание.   Для Microsoft Windows XP и Windows Server 2003 имеется исправление «Простая политика», которое делает использование списков исключений ненужным. Дополнительные сведения см. в статье 914841 базы знаний Майкрософт (эта ссылка может указывать на содержимое полностью или частично на английском языке) и в статье 914842 базы знаний Майкрософт (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Аспекты управления IPsec

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

•	Запрос на изменение (RFC).
•	Классификация изменения.
•	Авторизация изменения.
•	План развертывания изменения.
•	План выпуска изменения.
•	Просмотр изменения.

Корпорация Майкрософт рекомендует использовать в качестве платформы для управления IPsec Windows Server 2003. Чтобы облегчить выполнение задач управления, администраторы могут использовать оснастку MMC политики IPsec или средство Netsh с интерфейсом командной строки в консоли Windows Server 2003. В остальном управление политиками IPsec представляет собой довольно рутинную процедуру, поскольку они реализуются через групповую политику. Таким образом, добавление новых компьютеров в надежную сеть можно автоматизировать при использовании установленного процесса добавления компьютера.

Однако при рассмотрении изменений необходимо принимать во внимание ряд факторов.

•	Любые изменения, вносимые в действие фильтра, используемого для сопоставления безопасности IPsec, приведут к удалению сопоставлений безопасности, установленных в параметрах политики. Эта функция создает новую попытку быстрого режима, если какой-либо трафик находится в пути, что может привести к сбросу сетевого трафика.
•	Изменение метода проверки подлинности или метода безопасности основного режима может привести к тому, что IKE удалит существующие основные режимы. При определенных обстоятельствах эта функция может привести к сбою согласования с клиентами основного режима протокола IKE на стороне сервера.
•	При изменении политик IPsec в объекте групповой политики могут возникать определенные задержки (включая задержку при репликации Active Directory и задержку при опросе объекта групповой политики), которые могут продолжаться от нескольких минут до нескольких часов, в зависимости от размера и сложности среды.

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

•	Изоляция домена изоляции. Изменяя фильтр IPsec режима безопасного запроса для отключения небезопасного взаимодействия, изолированную сеть можно полностью отрезать от ненадежной сети при возникновении подозрений в том, что ненадежное устройство является платформой для вредоносных действий.
•	Блокировка подозрительных портов. Создав список фильтров с двумя односторонними фильтрами, можно блокировать трафик по портам. Этот подход следует использовать с осторожностью, поскольку он может привести к блокировке необходимого трафика, например трафика DNS, что затруднит последующее внесение изменений в IPsec или откаты в предыдущее состояние.
•	Изоляция дочерних доменов. Изменив политики на использование доменом предварительного ключа вместо протокола Kerberos для проверки подлинности IPsec, можно изолировать домен от других доменов в лесу.
•	Изоляция предварительно определенных групп. Путем использования предварительных ключей или сертификатов для проверки подлинности IPsec вместо протокола Kerberos можно создать группы изоляции, использующие различные ключи или сертификаты, предназначенные для выполнения такого же типа изоляции.

Использование служб карантина VPN для защиты от неуправляемых удаленных компьютеров

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

1.	Создание ресурсов карантина.
2.	Создание сценариев для проверки конфигураций клиентов.
3.	Установка компонента прослушивания Rqs.exe на серверах удаленного доступа.
4.	Создание карантинных профилей диспетчера подключений с помощью пакета администрирования диспетчера подключений Windows Server 2003.
5.	Распространение профилей диспетчера подключений на компьютеры клиентов удаленного доступа.
6.	Настройка политики карантина удаленного доступа.

1. Создание ресурсов карантина

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

Первый подход, заключающийся в назначении отдельных серверов, может сократить затраты, связанные с добавлением таких серверов для доставки обновлений, поскольку будут использоваться имеющиеся серверы. Однако такой подход требует создания сложных фильтров пакетов, поскольку каждому ресурсу потребуется собственный набор фильтров в атрибуте MS-Quarantine-IPFilter политики удаленного доступа при карантине.

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

2. Создание сценариев проверки

Сценарии карантина выполняют набор тестов, которые проверяют соответствие удаленных компьютеров политикам безопасности. После завершения этих тестов сценарию потребуется либо запустить клиентский компонент RQC.exe (в случае успешного выполнения), либо перенаправить клиентский компьютер на соответствующие ресурсы для приведения его в соответствие с установленными политиками. Разумеется, сценарий также может принудительно установить время ожидания и сообщение об ошибке, если сетевые политики предписывают использовать подобный подход. Эти сценарии могут быть простыми пакетными файлами командной строки, или сложными исполняемыми файлами.

Некоторые примеры сценариев доступны для просмотра и загрузки на странице образцов сценариев карантина VPN центра загрузки корпорации Майкрософт (эта ссылка может указывать на содержимое полностью или частично на английском языке).

3. Установка RQS.exe на серверах удаленного доступа

Процесс установки службы агента карантина удаленного доступа (Rqs.exe) на компьютер с Microsoft Windows Server 2003 отличается для серверов с установленным пакетом обновления 1 (SP1). Для краткости в этом разделе описывается только установка на Windows Server 2003 с пакетом обновления 1, поскольку предполагается, что на всех компьютерах установлены все последние пакеты обновления и обновления безопасности.

Установка Rqs.exe на сервер с Windows Server 2003 с пакетом обновления 1

1.	Нажмите кнопку Пуск и выберите пункт Панель управления.
2.	Щелкните значок Установка и удаление программ.
3.	Щелкните раздел Установка компонентов Windows.
4.	Выберите раздел Компоненты и щелкните пункт Сетевые службы.
5.	Щелкните пункт Состав.
6.	Выберите раздел Компоненты сетевых служб, щелкните пункт Служба карантина удаленного доступа и нажмите кнопку ОК.

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

Дополнительное действие в процессе установки включает изменение строк версии сценария таким образом, чтобы они соответствовали строке версии, настроенной для Rqc.exe в сценарии карантина. Службу Rqs.exe можно настроить таким образом, чтобы она принимала несколько строк версии сценария, которые, в свою очередь, записываются в реестр сервера удаленного доступа в параметре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rqs\AllowedSet, который расположен там, где необходимо применить эти параметры, с типом значения — REG_MULTI_SZ. Как правило, параметру RASQuarantineConfigPassed присваивается значение Allowed Set, но можно добавить дополнительные строковые значения.

4. Создание профилей диспетчера подключений для карантина

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

•	Выполняемое после подключения действие, которое запускает сценарий, созданный для проверки соответствия сетевой политике и самого сценария. Это делается на странице «Действия пользователя» мастера CMAK.
•	Также необходимо добавить в профиль компонент уведомления на странице Дополнительные файлы мастера CMAK.

5. Распространение профилей диспетчера подключений

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

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

6. Настройка политики удаленного доступа при карантине

Процедуры настройки политики удаленного доступа при карантине различаются в зависимости от того, настроены они или нет на использование сервера проверки подлинности в Интернете или другого поставщика услуг проверки подлинности.

•	Если политика настроена на использование сервера RADIUS проверки подлинности в Интернете, следует использовать оснастку «Служба проверки подлинности в Интернете».
•	Если политика настроена на использование поставщика проверки подлинности Windows, следует использовать оснастку «Маршрутизация и удаленный доступ».

При создании политики необходимо сначала создать политику удаленного доступа в нормальном режиме. Затем на вкладке Дополнительно свойств профиля политики удаленного доступа необходимо добавить атрибуты MS-Quarantine-Session-Timeout и MS-Quarantine-IPFilter.

При использовании RADIUS политику удаленного доступа при карантине необходимо будет реплицировать на другие серверы RADIUS путем копирования конфигурации или создания политики на каждом сервере вручную.

Использование проверки подлинности 802.1X для защиты от неуправляемых клиентов беспроводных сетей

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

•	WPA2/AES и EAP-TLS;
•	WPA2/AES и PEAP-MS-CHAP v2;
•	WPA/TKIP и EAP-TLS;
•	WPA/TKIP и PEAP-MS-CHAP v2.

Хотя EAP-TLS и PEAP-MS-CHAP v2 позволяют сделать стандарт WEP более безопасным, использование WEP в рамках любого решения рекомендуется только в процессе перехода на более безопасные стандарты WPA или WPA2.

Процессы внедрения EAP-TLS и PEAP-MS-CHAP v2 имеют много общего. Оба процесса требуют использования серверов RADIUS службы проверки подлинности в Интернете корпорации Майкрософт в качестве части решения, и оба они требуют использования сертификатов в некотором виде, но EAP-TLS требует наличия сертификатов как на компьютере клиента, так и на сервере, в то время как PEAP-MS-CHAP v2 требует наличия сертификатов только на серверах проверки подлинности. Поэтому при реализации EAP-TLS настоятельно рекомендуется создание инфраструктуры сертификатов, поскольку стоимость приобретения сертификатов у сторонних поставщиков для всех клиентов может быть слишком высока.

Проверка подлинности в беспроводной сети с использованием EAP-TLS и PEAP-MS-CHAP v2

Процессы внедрения EAP-TLS и PEAP-MS-CHAP v2 включают ряд деталей, выходящих за рамки данного документа. Однако имеется несколько превосходных ресурсов, помогающих при разработке и реализации решений для защиты беспроводных сетей. Некоторые из них перечислены ниже.

•	Страница «Развертывание безопасных сетей на основе стандарта 802.11 с использованием Microsoft Windows» веб-узла Microsoft TechNet, на которой содержатся сведения о реализации обоих подходов проверки подлинности на основе стандарта IEEE 802.1X (эта ссылка может указывать на содержимое полностью или частично на английском языке).
•	Доступная для загрузки статья «Защита беспроводных сетей с помощью служб сертификатов» (эта ссылка может указывать на содержимое полностью или частично на английском языке), содержит ресурсы и подробные сведения о реализации EAP-TLS в сетях Майкрософт.
•	Доступная для загрузки статья «Защита беспроводных сетей с помощью PEAP и паролей» (эта ссылка может указывать на содержимое полностью или частично на английском языке), содержит подробные сведения о реализации PEAP-MS-CHAP v2 в сетях Майкрософт.
•	Обновление WPA2 (Wi-Fi Protected Access 2) и WPS IE (Wireless Provisioning Services Information Element) для Windows XP с пакетом обновления 2 (эта ссылка может указывать на содержимое полностью или частично на английском языке), необходимо для поддержки в Microsoft Windows XP с пакетом обновления 2 стандарта WPA2.

Использование SMS-сервера для обнаружения и устранения уязвимостей неуправляемых компьютеров

Как уже было сказано в разделе «Разработка», процесс обнаружения SMS-сервера весьма полезен для поиска новых компьютеров, подключившихся к сети, если они могут находиться под управлением SMS-сервера. Также был упомянут тот факт, что SMS-сервер испытывает трудности с обнаружением некоторых неуправляемых компьютеров в процессе поиска и что для заполнения этого пробела необходимо использовать другой механизм.

Можно назвать несколько причин, по которым SMS-сервер может не обнаруживать компьютеры, подключенные к сети. Эти причины перечислены ниже.

•	Компьютер подключен к сети, но не работает во время обнаружения и не имеет учетной записи компьютера в домене.
•	Компьютер подключен к подсети, в которой используется брандмауэр или иное сетевое устройство, препятствующее взаимодействию между сервером SMS и этой подсетью.
•	Компьютер подключен к доступной подсети, но использует операционную систему, которую SMS не может обнаружить.

Чтобы решить эти проблемы необходимо специальное решение, сочетающее полезность SMS со сценариями, которые преобразуют исключения к виду, доступному для SMS. Настраиваемые сценарии можно использовать для проверки сети через постоянные промежутки времени, используя процесс планировщика, что позволяет обнаруживать устройства, появляющиеся лишь в течение коротких периодов времени. Подобные сценарии также можно запускать с рабочих станций или серверов, расположенных за пределами изолированных подсетей, что позволяет обнаруживать неуправляемые компьютеры, подключающиеся к этим ненаблюдаемым сегментам сети. Эти сценарии не используют процессы обнаружения на основе инструментария управления Windows (WMI) и поэтому не зависят от того, какие операционные системы используются на неуправляемых клиентах.

Дополнительные сведения об использовании SMS-сервера для обнаружения устройств в сети см. в документе «Управление исправлениями с помощью сервера Systems Management Server 2003» (эта ссылка может указывать на содержимое полностью или частично на английском языке) или на домашней станице Microsoft Systems Management Server (эта ссылка может указывать на содержимое полностью или частично на английском языке), где имеются дополнительные ссылки, включая ссылки на ресурсы по созданию сценариев SMS.

Аннотация

Этот документ показывает возможность использования комплексного подхода к решению проблем, связанных с неуправляемыми компьютерами. Изоляция сети на основе IPsec использовалась для предотвращения получения неуправляемыми компьютерами доступа к надежным сетевым ресурсам и принудительного установления соответствия заданным политикам путем отказа в обслуживании не соответствующим требованиям политик компьютерам. Службы карантина VPN можно использовать для принудительного приведения в соответствие с требованиями политик мобильных компьютеров, использующих решения на основе удаленного доступа, но редко подключающихся к локальной сети. Для защиты от незаконно подключаемых устройств в беспроводных сетях можно использовать стандарты IEEE 802.1X, WPA и WPA2. Наконец, SMS-сервер и сценарии обнаружения можно использовать для содействия обнаружению неуправляемых компьютеров, а также для поддержания управляемых компьютеров в актуальном состоянии со всеми установленными исправлениями и обновлениями безопасности.

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

Приложение A: Защита доступа к сети.

Защита доступа к сети (NAP) — новая функция, входящая в следующее поколение ОС Windows (Microsoft Windows Server Longhorn и Windows Vista™). Она предоставляет возможность принудительного приведения в соответствие с политиками состояния компьютеров. Используя NAP, администраторы могут устанавливать пороговые значения проверки состояния компьютеров через API-интерфейс, ограничивающие доступ к сети для тех компьютеров, которые не соответствуют требованиям в момент подключения к сети.

Гибкость NAP позволяет администраторам настраивать собственные решения согласно требованиям своей среды, просто записывая в журнал состояние компьютеров, подключающихся к сети, автоматически устанавливая обновления программного обеспечения или ограничивая возможность подключения компьютеров, не соответствующих требованиям. Кроме того, NAP обладает достаточной гибкостью для интеграции с приложениями сторонних производителей и индивидуальными программными решениями, обеспечивая таким образом комплексность реализации политик поддержания работоспособности компьютеров. Технология NAP также является комплексной; входящие в нее компоненты принудительного использования позволят администраторам принудительно устанавливать соответствие с политиками работоспособности через DHCP, VPN и беспроводные сети стандарта 802.1X. Кроме того, эта технология также совместима с IPsec.

Дополнительные сведения о NAP см. на домашней странице Network Access Protection (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Главная | Видео | Новости | Microsoft | Железо | Программы | СУБД | Форум