802.1X на Wi-Fi и проводных портах: SCEP, NPS и карантинный VLAN

Год назад разговор о контроле доступа к сети у большинства клиентов заканчивался на уровне «у нас WPA2-PSK с длинным паролем». Для небольшого офиса - приемлемо. Для организации с несколькими десятками рабочих мест, где сотрудники приходят со своими телефонами и ноутбуками, - уже нет.

Мы прошли через внедрение 802.1X у одного из клиентов - средний производственный офис, около 60 рабочих мест, смешанная сеть: проводные порты в open-space и Wi-Fi на двух точках доступа. Рассказываем, как это устроено.

Зачем вообще 802.1X, если есть WPA2

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

802.1X решает это иначе: каждое устройство предъявляет credential до того, как получит доступ к сети. В нашем случае - сертификат, выданный корпоративным CA. Нет сертификата - нет доступа к основной сети. Точка.

Как выглядит архитектура

Три компонента:

• Supplicant - устройство, которое хочет в сеть. На корпоративных машинах с Windows 7 это встроенный клиент, настраивается через GPO.
• Authenticator - коммутатор или точка доступа. У клиента стоят Cisco Catalyst 2960 на проводе и Cisco Aironet на беспроводе. Оба умеют 802.1X нормально.
• Authentication Server - NPS (Network Policy Server) на Windows Server 2008 R2. Это RADIUS, к которому коммутаторы и AP ходят за решением.

Схема проверки: устройство подключается к порту, коммутатор блокирует весь трафик кроме EAPOL, отправляет challenge на supplicant, тот отдаёт сертификат, коммутатор пересылает это в RADIUS через UDP, NPS сверяется с CA и AD - и говорит «пускай» или «не пускай». Если «пускай» - порт переходит в нужный VLAN, трафик идёт нормально.

SCEP и выдача сертификатов

Выдавать сертификаты вручную на 60 машин - занятие для мазохистов. Поэтому развернули SCEP (Simple Certificate Enrollment Protocol) через Network Device Enrollment Service (NDES) на Windows Server. Схема: GPO запускает задачу автозачисления, рабочая станция сама запрашивает сертификат у CA, CA выдаёт, сертификат ложится в личное хранилище компьютера. Без участия пользователя и без тикетов в поддержку.

Нюанс, который съел нам пару часов: права на шаблон сертификата. Нужно явно разрешить Domain Computers enroll на шаблоне Computer Authentication - по умолчанию права там выставлены не так, как ожидаешь. Второй нюанс: NDES требует отдельного сервисного аккаунта с правами на выдачу сертификатов, и этот аккаунт не должен быть Domain Admin - иначе CA ругается на безопасность конфигурации.

NPS-политики и VLAN-сегментация

В NPS настроили три политики подключения:

• Корпоративные устройства - сертификат из нашего CA, машина в AD, проходят аутентификацию - получают VLAN сотрудников.
• Карантинный VLAN - устройство подключилось, но сертификат не предъявило или не прошло проверку. Попадает в изолированный VLAN с доступом только к одному внутреннему ресурсу - странице с инструкцией «позвони в поддержку». Никакого интернета, никакого доступа к серверам.
• Guest VLAN - личные смартфоны и планшеты сотрудников, гости. Отдельная SSID с WPA2-PSK (пароль меняется раз в месяц), NAT наружу в интернет, никакого доступа к внутренней сети.

Последний пункт вышел самым обсуждаемым с клиентом. Люди привыкли раздавать с рабочего компьютера и ожидали, что телефон окажется во внутренней сети. Решение - отдельная SSID с нормальной скоростью в интернет, но без доступа к корпоративным ресурсам. Большинство сотрудников это устраивает: почта и мессенджеры через интернет работают, а зачем телефон во внутренней сети - никто толком объяснить не мог.

Что проверяли перед запуском

Карантинный VLAN тестировали отдельно: брали ноутбук без сертификата, подключали к порту, убеждались что он действительно попадает в карантин и не видит ничего лишнего. Несколько раз нарывались на то, что коммутатор отправлял машину в default VLAN вместо карантинного - проблема была в порядке политик NPS и в отсутствии явного Reject-VLAN в настройках порта.

На Cisco 2960 для карантина нужен authentication event fail action authorize vlan <id> и authentication event no-response action authorize vlan <id>. Без второй строки молчащее устройство (которое вообще не отвечает на EAP) просто зависало с заблокированным портом, а не получало карантинный VLAN. Это поведение не очевидно из документации.

Текущее состояние

Проводные порты и корпоративный Wi-Fi переведены на 802.1X. Рабочие станции получают сертификаты автоматически, пользователи ничего не замечают. Карантинный VLAN несколько раз срабатывал штатно - один раз чужой ноутбук в переговорке, один раз сотрудник принёс домашний нетбук.

Guest SSID живёт отдельно, сотрудники к ней адаптировались быстрее, чем мы ожидали.

Что осталось за рамками этого внедрения - NAC-решения уровня Cisco ISE или Bradford Networks, которые умеют проверять posture (обновления, антивирус) перед допуском в сеть. У этого клиента такая детализация избыточна, но для крупных сетей это следующий логичный шаг. Пока работаем с тем, что настроено.

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