Защита сети от неуправляемых клиентов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другим компонентом 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 является центральной частью этого решения и выполняет перечисленные ниже функции.

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

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

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

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

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

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

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

Из этих трех методов первый (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.