NAC на 802.1X: как ноутбук без патчей попадает в карантин автоматически

Разговор про NAC обычно начинается с одного и того же: «у нас периметр закрыт, VPN с сертификатами, зачем ещё что-то». Потом кто-нибудь приходит в офис с личным ноутбуком, подключается к корпоративной Wi-Fi, и оказывается, что на нём три месяца не было обновлений и антивирус с просроченными базами. Периметр при этом не пострадал ни на секунду - угроза уже внутри.

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

Почему NAP, а не Cisco NAC Appliance

На рынке сейчас две очевидные альтернативы: Cisco NAC Appliance и Microsoft Network Access Protection. Cisco - это отдельная аппаратная платформа с собственным лицензированием. Работает независимо от инфраструктуры, хорошо интегрируется с оборудованием Cisco, но цена входа ощутимая. У клиента уже работал Windows Server 2008, Active Directory и WSUS - NAP в этой связке выглядел органично. Плюс агент NAP встроен в Vista и Windows 7, для XP SP3 ставится отдельно, но тоже без сюрпризов.

Принципиально NAP - это не брандмауэр и не система обнаружения вторжений. Это механизм проверки состояния здоровья клиента перед тем, как пустить его в сеть. Клиент сообщает о себе набор параметров (Statement of Health), сервер оценивает соответствие политике и решает: в основную сеть или в карантин.

Архитектура: 802.1X как точка принятия решения

Для принуждения к политике выбрали 802.1X - проверка идёт прямо на уровне порта коммутатора или точки доступа, до получения IP-адреса из основной сети. Альтернатива - DHCP enforcement, когда карантин реализуется через выдачу ограниченного IP. Проще в развёртывании, но легко обойти статическим адресом. 802.1X надёжнее.

Схема получилась такая:

На роль RADIUS-сервера поставили Network Policy Server - он входит в состав Windows Server 2008 и умеет работать с NAP напрямую. NPS получает от клиента Statement of Health, сопоставляет с политиками System Health Validators и возвращает коммутатору атрибуты VLAN.

Политика проверяет три вещи: Windows Firewall включён, Windows Update в норме (нет критических обновлений старше 30 дней), антивирус установлен и базы не устарели более чем на 3 дня. Последнее потребовало System Health Validator от вендора антивируса - в нашем случае Symantec Endpoint Protection, у него есть готовый модуль для NAP.

Карантинный VLAN: чиним, а не блокируем

Устройства, не прошедшие проверку, уходят в отдельный VLAN с ограниченной маршрутизацией: доступ только к WSUS, к серверу обновлений антивируса и к веб-странице с объяснением ситуации. Интернет - нет, внутренняя сеть - нет.

Это принципиальный момент: карантин не блокирует устройство намертво, а создаёт условия для самовосстановления. Клиент с установленным агентом NAP сам скачивает обновления, после чего автоматически проходит повторную проверку и перемещается в основную сеть - без звонка в helpdesk и без участия администратора. На практике на это уходит от 10 минут до получаса в зависимости от количества обновлений.

Первый месяц

За первые четыре недели карантинный VLAN поймал 12 устройств. Интересно что именно:

• Личные ноутбуки сотрудников - главный источник. Человек работает дома, автообновления не настроены или отключены, антивирус не продлили. В офис приходит - попадает в карантин.
• Ноутбуки подрядчиков - те ещё приходят со своим железом и своим ПО. Два устройства вообще оказались без антивируса.
• Забытый тестовый ноутбук - лежал в ящике три месяца, его подключили для демонстрации оборудования. Логично, что обновлений не видел с лета.

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

Что пошло не так с первого раза

XP SP2. Один ноутбук работал на XP SP2 - агент NAP туда не ставится, нужен как минимум SP3. Устройство уходило в карантин безвозвратно, потому что и починить себя не могло. Пришлось для таких случаев настроить отдельную политику: устройства без агента NAP помечаются как non-compliant и попадают в ещё более ограниченный VLAN с предложением обновиться вручную.

Сторонние антивирусы с несовместимыми SHV. Несколько ноутбуков подрядчиков работали с антивирусами, для которых нет готового System Health Validator под NAP. Агент сообщает о неизвестном антивирусном состоянии - и сервер расценивает это как несоответствие. Решили прагматично: для таких устройств можно выдать исключение через AD-группу, но это ручная операция.

Коммутаторы. Не все коммутаторы клиента поддерживали 802.1X с динамическим назначением VLAN. На двух этажах пришлось оставить DHCP enforcement как временную меру - до замены оборудования.

Несколько наблюдений

NAP не заменяет управление обновлениями. Это разные слои. WSUS и SCCM следят за тем, чтобы корпоративные машины получали патчи в срок. NAP - это проверка на входе для всего остального: гостей, подрядчиков, личных устройств, которые в WSUS не состоят. Одно другое не отменяет.

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

Пользователи восприняли спокойно. Страница с объяснением в карантинном VLAN оказалась важной деталью. Когда человек понимает что происходит и видит прогресс обновления - нет паники и звонков. Когда соединение просто не работает без объяснений - жалобы гарантированы.

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