14.07.2007

Network Access Protection – безопасная работа в сети c Windows Server 2008

image

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

Андрей Бирюков

MCSE+Security, MCDBA, CCNP

Глобальная сеть Интернет таит в себе много угроз для пользователей: вирусы, черви, троянские кони… Все эти угрозы хорошо знакомы каждому системному администратору. Многие считают, что для борьбы с ними достаточно межсетевого экрана, корпоративного антивируса и своевременной установки обновлений. Однако жизнь показывает, что таких мер не всегда достаточно. Приведем несколько примеров. Во многих организациях для проникновения в корпоративную сеть достаточно просто подключиться к любой свободной сетевой розетке. И злоумышленник тут же получит IP адрес по DHCP и сможет без труда просканировать сеть на предмет наличия доступных ресурсов. Может он и не сможет сразу завладеть учетной записью доменного администратора, но зачастую этого и не требуется.

Другой пример, более близкий к реальности. Сотрудник возвращается из командировки со своим ноутбуком. Естественно антивирусные базы не обновлялись и критические обновления не устанавливались. Как водится, на ноутбуке у пользователя были права локального администратора (а что, у вас в организации не так?!) в связи с чем за время командировки лэптоп превращается в настоящий “зверинец”, содержащий вредоносное ПО всех мастей. Когда, с такого ноутбука пользователь заходит в локальную сеть, вредоносное ПО начнет пытаться размножаться, что может привести к весьма неприятным последствиям.

Основной вывод, который можно сделать из приведенных примеров это то, что необходимо отслеживать каждую подключающуюся в сеть машину на предмет “благонадежности”. Многие разработчики выпустили свои решения, позволяющие решить данную проблему. Наиболее известным является Cisco Network Admission Control от корпорации Cisco. Мне приходилось внедрять Cisco NAC L2 вместе с антивирусом от Trend Micro. Однако, данное решение обладает рядом недостатков, что усложняет его внедрение.

Вот мы наконец и подошли к теме сегодняшней статьи, а именно к описанию технологии Network Access Protection, представленной в Microsoft Server 2008 и Windows Vista. Вообще, Windows Server 2008 Longhorn (уже прозванный в народе “длиннорогим”) обладает целым рядом нововведений, в том числе и связанных с безопасностью, некоторые из которых, возможно, станут темами последующих статей. Но сегодня мы обсудим технологию NPS, впервые появившуюся в качестве серверного решения именно в Windows Server 2008.

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

Что же представляет из себя Network Access Protection, из каких компонент состоит и как работает? Основным элементом, осуществляющим проверку хоста является Network Policy Server (NPS), служба, входящая в состав Windows Server 2008. NPS является RADIUS сервером, и пришел на смену Internet Autentification Server (IAS), входившему в состав Windows Server 2003. NPS осуществляет аутентификацию и авторизацию попытки сетевого подключения, основываясь на политиках безопасности, определяет, можно ли хосту подключиться к сети. В качестве примера, я продемонстрирую установку и настройку сервера Network Policy Server и соответствующих политик. Для простоты будем считать, что у вас уже установлен Windows Server 2008. В окне Add Roles Wizard, которое как и версии 2003 появляется после загрузки системы, выбираем Network Policy and Access Service.

На следующем шаге определяемся с компонентами, которые нам необходимо установить. В данном случае, нас интересует только Network Policy Server.

Подтверждаем выбранные опции и запускаем процесс установки.

Как видно все довольно просто. Теперь откроем консоль настройки установленного приложения. Делается это как и в прежних версиях Windows, из раздела Administrative Tools. Консоль администрирования NPS после установки выглядит так

Теперь необходимо настроить политики Запроса соединения (Connection Request Policies). Данные политики определяют набор правил, которые использует NPS для проверки попыток соединений. В качестве примера, настроим одну из таких политик.

Для этого необходимо в консоли администрирования NPS выбрать Policies, и далее Health Policies.

Политики состояния системы (Health Policies) позволяют определить требования к состоянию системы с помощью System Health Validators (SHV), так называемых маркеров, которые сообщают NPS о состоянии системы машины, запрашивающей подключение (NAP клиента). Вот пример health policy.

Маркер SHV может иметь следующее состояния:

Client passes all SHV checks – проверки всех маркеров прошли успешно. В таком случае, как правило, пользователь получает полный доступ к сети (естественно в рамках своих полномочий)

Client fails all SHV checks – не одна проверка не пройдена. Как правило, таких пользователей лучше не пускать в сеть вообще.

Client passes one or more SHV checks – клиент прошел одну или несколько проверок. Здесь все определяет то, какие проверки прошел пользователь. Как правило, в такой ситуации лучше всего разрешить доступ только в карантинную сеть, где он сможет установить недостающие обновления и патчи.

Client fails one or more SHV checks – клиент не прошел одну или несколько проверок. Случай аналогичный предыдущему. Разница лишь в том, что для вас приоритетней.

Client reported as transitional by one or more SHV’s – транзитный маркер возвращается, когда машина только подключилась к сети, и состояние SHV еще не определено.

Client reported as infected by one or more SHV’s – состояние Infected. Антивирусные продукты, интегрированные с NAP могут возвращать такое состояние SHV.

Client reported as unknown by one or more SHV’s – состояние неизвестен обычно бывает на тех машинах, которые несовместимы, либо на них не установлен клиент NAP. Понятно что такие машины тоже лучше в сеть не пускать.

Далее необходимо определить, политики, определяющие критерии, по которым определяется состояние клиента, а также действия NPS. Для этого в разделе Network Access Protection выбираем System Health Validators.

В первом окне определяются различные состояния SHV. В окне Configure определяются более подробные настройки.

Как видно, мы можем определить различные параметры, которым должна соответствовать каждая машина, пытающаяся подключиться к нашей сети. Обратите внимание на то, что политики для Windows Vista и для Windows XP немного различаются.

Для настройки действий, которые производятся в случае соответствия SHV той или иной политике необходимо открыть консоль Network Policies, далее в NAP Enforcement, в закладке Settings определяем Network Policy.

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

Как все это работает

Теперь, когда я описал настройку всех основных компонент NAP, необходимо пояснить, как все это работает. Клиентская машина, на которой установлена Windows XP+SP2 или Vista пытается установить соединение. Это выражается в RADIUS Access- Request запросе к серверу NPS. Сервер NPS сравнивает содержимое Access-request сообщения с политиками, которые мы определили при настройке Health Policy. В зависимости от того, соответствует или нет данная информация политикам, NPS применяет к пользовательской станции то или иное действие, определенное в network Policy. Далее служба NPS отправляет RADIUSAccess-Accept сообщение с информацией об уровне доступа пользователя.

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

У многих может возникнуть вполне резонный вопрос: что произойдет, если в сеть попытается подключиться рабочая станция с операционной системой неподдерживаемой NAP, к примеру с Linux? Ответ прост: NPS не сможет получить от такой машины маркер SHV, соответственно, к ней должна быть применена политика для состояния Unknown и при правильной настройке политик NPS, такая машина не должна получить доступ в сеть.

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

Использованные источники:

1. http://www.microsoft.com/nap

2. http://www.microsoft.com/technet/network/nap/napoverview.mspx

или введите имя

CAPTCHA
Страницы: 1  2  
1
14-07-2007 16:38:53
А при работе в локалке заражение malware исключено? А если все патчи стоят, то как он себе их наловит?
0 |
1
15-07-2007 22:46:32
"А при работе в локалке заражение malware исключено?" Ессно не исключено, но за это отвечает антивирь. Антивирусные клиенты должны иметь актуальные базы, за этим и следит NAP.
0 |
14-07-2007 17:49:26
Все это конечно прекрасно, но админ с прямыми руками и под NT сервером создает такую локалку, в которую мышь не проскочит (ситуацию целенаправленной атаки не рассматриваем). 1. Если злоумышленник имеет физический доступ к локалке, то слушать трафик он сможет в любом случае. Вопрос лишь в том, сможет ли он его расшифровать - это вопрос используемых протоколов шифрации. 2. Если злоумышленник пытается получить IP, то DHCP не должен его выдавать при отсутствии соответствующего MAC-адреса в базе DHCP-сервера. Если выдает - это проблемы админа и его головы, а не сервера. 3. Допустим редкую ситуацию, когда IP выдаются без привязки к MACу. Такая машина что, сразу входит в домен, получает какие либо права на доступ к ресурсам в сети и во вне ее без проверки пары логин/пароль? Снова проблема админа, а не сервера. Если руки у админа кривые, то сколько не совершенствуй механизмы защиты - все без толку. У правильного же админа и так полно средств для рубки рук злодеям и дуракам.
0 |
1
14-07-2007 20:19:49
1. А сниффинг и клонирование МАК уже отменили?
0 |
15-07-2007 00:08:59
А о факте сниффинга админ узнает по факту, просматривая логи? А сервак пропускает сниффинг "мимо ушел" и не начинает кричать "караул"? См. примечание про подведомственность проблем
0 |
1
14-07-2007 20:24:06
1. Если злоумышленник имеет физический доступ к локалке, то слушать трафик он сможет в любом случае. Вопрос лишь в том, сможет ли он его расшифровать - это вопрос используемых протоколов шифрации. А какие протоколы шифрования обычно используются? В нормальных условиях, а не скажем в банках. Статический ип себе прописать нельзя? Опять же при необходимости с клонированием МАКа. В отношении домена согласен, но там уже есть варианты постучаться на машины сплоитом / ARP спуфинг, правда норм админы такого найдут довольно быстро, но это в теории, на практике хз.
0 |
15-07-2007 00:22:16
1. Кто запрещает использовать шифрование не только в банках? Давайте согласимся, что в офисе на 5-10 машин неизвестные как правило не смогут подключить свой комп к свободной розетке - это будет замечено визуально, то есть самым простым и надежным средством защиты - глазами Это скорее относится к достаточно большим сетям, требующим наличия квалифицированного админина. 2. Статический IP и сопоставленный ему MAC надо сначала узнать, а попытки узнать их должны в теории приводить к истерике систем оповещения админа о подозрительной активности. 3. Согласен, есть и будут инструменты обхода самой надежной системы безопасности, но если админ не пиво на работе пьет, то он должен засечь злоумышленника "до", а не "после". Если же строго по теме статьи, то в чем заключается новизна и крутизна рассматриваемой технологии? В проверке установлен ли на клиентской машине файрвол, антивирус, аниспайвар и т.д. 1. Допустим, все установлено - дальше что? Это не гарантия чистоты машины. 2. Алгоритм проверки? Сигнатуры, которые "летят" с каждой новой версией. Некие "типичные признаки наличия"? Бу-га-га. Про ошибки определения молчу. Я еще понимаю проверку не открыты ли на клиентской машине некие "особо опасные и подозрительные" порты, не запущены ли процессы, с подозрительно высокими привелегиями... много чего можно проверить, хотя тоже бредовая идея, но хоть какая-то идея. А то "требовать наличия файрвола" - изветно, что при наличии убого встроенного проверка будет пройдена, а при наличии последней версии того же Outpost'a - не факт. В общем "кликни и забыл" для юзеров мелкомягким показалось мало, теперь толкают то же, но для админов.
0 |
Статический IP и сопоставленный ему MAC надо сначала узнать, а попытки узнать их должны в теории приводить к истерике систем оповещения админа о подозрительной активности.Если ловить броадкасты и не давать своему компу посылать никаких данных в сеть - не будет никакой активности. А значит, и системы обнаружения этой самой активности будут молчать
0 |
16-07-2007 02:37:29
Характерно для целенаправленной атаки под непосредственным контролем злоумышленника, но в данном случае: 1. Захотят вторгнуться именно в сеть организации Х - вторгнутся при любой защите, были бы на это необходимые ресурсы. 2. Рассматриваемая система направлена на борьбу с типичными, неадресными "дырами" - затрояненный комп сотрудника и т.п. В этом случае источник угрозы не "молчит" в сети, а пытается получить "легальный" доступ. Если же "легальное" соединение получено, то вредоносному ПО сподручнее его и использовать, вместо того, чтобы пытаться установить еще одно, собственное. Впрочем, прослушка сети в этом случае все-таки может быть полезна с целью отлова "реквизитов" клиента с более высокими правами, но это опять-таки скорее ситуация "ручного" вторжения, а не троянской активности.
0 |
1
15-07-2007 22:53:22
"1. Если злоумышленник имеет физический доступ к локалке, то слушать трафик он сможет в любом случае. Вопрос лишь в том, сможет ли он его расшифровать - это вопрос используемых протоколов шифрации. 2. Если злоумышленник пытается получить IP, то DHCP не должен его выдавать при отсутствии соответствующего MAC-адреса в базе DHCP-сервера. Если выдает - это проблемы админа и его головы, а не сервера. " Хм, дело не в DHCP и снифферах. Прослушивать можно пытаться сколько угодно, но только пытаться, доступ к сети блокируется на больее низком уровне модели OSI. Аналогично Cisco NAC L2. "3. Допустим редкую ситуацию, когда IP выдаются без привязки к MACу. Такая машина что, сразу входит в домен, получает какие либо права на доступ к ресурсам в сети и во вне ее без проверки пары логин/пароль? Снова проблема админа, а не сервера. " У многих заказчиков при проведении аудита можно наблюдать такую картину: втыкаем в сетку недоменный ноут, запускаем сканер шаров и... обнаруживаем целые диски доступные как минимум на чтение для всех. Но это конечно проблема админов а не технологий.
0 |
1
15-07-2007 09:05:02
Как водится, на ноутбуке у пользователя были права локального администратора (а что, у вас в организации не так?!) не так. Да и вообще, в крупных сетях до сих пор юзают и win98, и NT4, и 2000. Как быть с такими машинами?
0 |
1
15-07-2007 22:57:46
Ну если у вас в сети все включая руководство сидят под пользовательскими учетками, то типа респект. К сожалению, вбольшинстве контор не так. Что касается старых мастдаев. Ну M$ есть M$ они усиленно продвигают висту, поэтому с поддержкой в предыдущих версиях скорее всего будут проблемы. Особенно проблемы будут с 98 и НТ4.
0 |
1
15-07-2007 12:18:06
Когда говорят про защиту от сетвых атак становится смешно, код закрыт.Где гарантия, что шпион или специальный сотрудник не оставит сотни тысяч бакдоров для себя или для спецслужб своей страны? Думаю как патриот, я бы в отечественной ОС обязательно сделал пару десятков таких средств для нашего ФСБ и тд. Нельзя пользватся котами в мешке, это преступная халатность. Ах да забыл эти бекдоры не смогут найти другие - даже смешно... Конечно их найдут и будут использовать, - причем обсолютно левые лица для воровства и своих нужд!!! Использование ОС в ответсвенных решениях и тем более для защиты от сетевых атак преступно. Заявления типа у нас работает происходят - от глупых людей - это лишь значит, что они не знают, о похищении ценных данных либо таковых не имеют
0 |
1
15-07-2007 23:01:46
Ну у нас из контор данные тащут вагонами. Базы ГИБДД, ЦБ РФ, МТС и т. д. И никакие бекдоры не нужно.
0 |
1
18-07-2007 22:10:53
А я про преступность использования ОС с закрытым кодом - а не про то как тащут, и про бессмысленность понятия - защита сети с помощью средств этой ОС. Кроме того кто ее покупает кормит воров, которые воруют код и скрывают это благодоря его закрытости. Исползование продуктов с закрытым кодом торговля краденым и косвенная поддержка воров. Я не против комерции - но нужно лецензировать исходник и поставлять все только в исходнике и давать права на модификацию этого исходника и его усовершенствование - долой шарлатанов из МС и других барых скрывающих "СВОЙ" код и "СВОИ РАЗРАБОТКИ".
0 |
1
11-09-2007 02:05:29
Собственно для нашей страны вот тут: http://www.microsoft.com/Rus/Security/Certificate/Default.mspx Для международных требований - свои сертификации.. А если код открыт - где гарантия что кто-либо в нем разбирается? Сколько миллионов строк кода он содержит? Вы можете разработать и сделать свою ОС ( как патриот), а потом договаривались с произовдителями и разработчиками оборудования и приложений, разрабатывали курсы ( и переводили их на татарский, к примеру), и обучали пользователей. И как только любой инцидент с вашей "патриотической" ОС и подарком от ФСБ вскроется - вы больше не продадите больше 100 коробок (лицензий, подписки) в год. Конец вашей ОС. На проприетарном ПО работают ведущие компании мира, проприетарное ПО пришут ведущие разработчики. Рухнул ли мир? нет. поднялось ли значимость и доступность ИТ - да. Есть ли у вас факт, подтверждающий ваши опасения - нет.
0 |
1
16-07-2007 10:06:22
После прочтения вопрос - зачем? и чем это принципиально лучше Cisco NAC с его недостатками??? Если учесть кроссплатформенность его и гораздо большую гибкость, и к тому же, поддержку на уровне доступа(порта коммутатора), что позволяет на 2уровне уже ограничить доступ к сети, исключить сниффинги и любые шторма. Могу я попросить вас сравнить 2 этих продукта, кратко и по пунктам? Поделитесь опытом.
0 |
1
11-09-2007 02:15:19
А также давайте учитывать цену решения на базе аппаратных компонент. Начальную, внедрения, поддержки и обслуживания. вернемся к исходному - чего же мы хотим - более высокой защищенности в обычной сети или испытательный полигон для хакеров в погоне за ценными ресурсами? NAP не является противопоставлением CISCO NAC, а логичным дополненеим его теми преимуществами, которые можно реализовать только с помощьюю программных решений. вот несколько ресурсов для ознакомления: - http://www.microsoft.com/presspass/press/2006/sep06/09-06SecStandardNACNAPPR.mspx - http://download.microsoft.com/download/d/0/8/d08df717-d752-4fa2-a77a-ab29f0b29266/NAC-NAP_Whitepaper.pdf
0 |
Страницы: 1  2