Коллеги, добрый день!
Я Станислав Калабин, инженер-архитектор компании Axel PRO. Если постараться найти открытую информацию про 802.1x на популярных видеохостингах, презентациях или рекламных материалах, то все выглядит идеально:
есть корпоративный ноутбук, который подключается к сетевому порту;
коммутатор блокирует доступ в сеть до прохождения проверки;
EAP-TLS запускает процесс обмена сертификатами между клиентом и сервером аутентификации;
после успешной проверки сертификата устройству предоставляется доступ в сеть;
пользователь получает нужный VLAN и спокойно работает в разрешенном сегменте.
Красиво, логично и безопасно.
Но в реальной корпоративной сети все обычно устроено сложнее.
Помимо ноутбуков и рабочих станций, в инфраструктуре присутствуют десятки типов устройств. Большинство из них относятся к классу IoT (Internet of Things, «интернет вещей») и специализированного оборудования, хотя сюда также входят принтеры, МФУ, IP-телефоны и другие корпоративные устройства, которые не умеют проходить стандартную аутентификацию 802.1x:
принтеры/МФУ;
IP-телефоны;
камеры видеонаблюдения;
терминалы;
ТВ-панели;
тонкие клиенты;
контроллеры;
устройства АСУ ТП;
и множество других конечных точек.
Часть из них вообще не поддерживает 802.1x. Часть поддерживает его формально, но использовать такую реализацию в промышленной эксплуатации рискованно. Также есть устройства на которых, не смотря на поддержку 802.1x не представляется возможность его настроить. Например, гостевые устройства или устройства подрядчиков.
Именно такие устройства часто становятся отдельной задачей для ИТ и ИБ-департаментов. Их необходимо подключить к сети, сохранить удобство эксплуатации и при этом не создавать неконтролируемые точки доступа внутри инфраструктуры.
На практике проблема неуправляемых устройств обычно решается с помощью механизма MAB (MAC Authentication Bypass), который позволяет использовать MAC-адрес устройства в качестве идентификатора при отсутствии поддержки 802.1x.
Однако сам по себе MAB не решает всех вопросов безопасности и управления доступом. Именно поэтому возникает следующий логичный вопрос: как контролировать устройства, которые не поддерживают полноценную аутентификацию по 802.1x?
Что делать с устройствами, которые его не поддерживают?
Именно здесь начинается зона ответственности NAC-систем.
В этой статье разберем, как совместное применение 802.1x и NAC, на примере решения AxelNAC, позволяет контролировать IoT-устройства, принтеры, IP-телефоны и другие конечные устройства без поддержки 802.1x, применять к ним политики доступа и выстраивать единый безопасный подход для всей корпоративной сети.
Также обсудим:
почему классический 802.1x не покрывает всю инфраструктуру;
как подключать принтеры, камеры и IoT без потери контроля;
зачем нужен MAB;
как NAC видит неуправляемые коммутаторы.
Что такое 802.1x
Для тех, кто ранее не сталкивался с этой технологией, 802.1x – это стандарт сетевой аутентификации устройств и пользователей при подключении к проводной или беспроводной сети.
С его помощью можно проверять, кто именно подключается к сети, и автоматически применять нужную политику доступа. Этот протокол работает на основе порта доступа и аутентификационного сервера, обеспечивая контроль над доступом к сети. 802.1x поддерживает различные методы аутентификации, включая EAP (Extensible Authentication Protocol).
Как работает 802.1x
На конечном устройстве запускается клиент (supplicant) 802.1x. После подключения к порту коммутатора или Wi-Fi контроллеру они выступают в роли аутентификатора (authenticator) и временно блокируют доступ в сеть.
Далее начинается EAP-аутентификация с участием RADIUS-сервера или NAC-системы. Например, при использовании EAP-TLS выполняется проверка сертификатов устройства и сервера.
При успешной аутентификации, коммутатор открывает порт, а NAC/RADIUS применяет необходимую политику (VLAN, ACL или другие параметры доступа).
802.1x отлично работает там, где используются:
корпоративные ноутбуки;
доменные ПК;
управляемые рабочие станции;
устройства с централизованной выдачей сертификатов;
корпоративный Wi-Fi.
Несмотря на очевидные преимущества, 802.1x невозможно применить ко всем устройствам в корпоративной сети. Основной причиной является то, что на устройстве должен быть суппликант, поддержка EAP и возможность управлять учётными данными или сертификатами.
В реальной инфраструктуре это выполняется далеко не всегда. Даже если поддержка заявлена, на практике она часто ограничена или нестабильна. Устройства могут некорректно работать с EAP, терять авторизацию при повторной аутентификации или требовать ручного вмешательства при обновлении сертификатов. В условиях эксплуатации это создает дополнительные риски.
В результате в одной сети неизбежно появляется класс устройств, которые не могут быть подключены через 802.1x.
Как подключают неуправляемые устройства с помощью MAB
Для подключения таких устройств используется механизм MAB (Mac Authentication Bypass).
Суть данного метода проста. Если устройство не умеет проходить аутентификацию по 802.1x, тогда в качестве его идентификатора используется MAC-адрес.
Процесс выглядит следующим образом:
устройство подключается к порту коммутатора;
коммутатор не получает ответа от суппликанта и инициирует MAB;
MAC-адрес устройства передается на RADIUS или NAC-сервер;
сервер принимает решение на основе этого MAC-адреса;
в ответ возвращается политика доступа (например, VLAN или ACL).
Таким образом, устройство получает доступ в сеть без полноценной аутентификации, но с применением централизованной политики.
С точки зрения эксплуатации MAB это удобный механизм. Он позволяет подключать неуправляемые устройства без изменения их конфигурации и без установки дополнительного ПО.
Однако важно понимать, что MAB решает задачу идентификации устройства, но не обеспечивает полноценную аутентификацию.
Особенности настройки MAB на сетевом оборудовании
MAB не является автоматическим поведением коммутатора по умолчанию. Для его работы необходимо явно настроить соответствующий режим на порту доступа. В большинстве решений (например, у Cisco) задается порядок использования методов аутентификации (802.1x, затем MAB) и приоритет этих методов.
Это означает, что поведение порта может отличаться в зависимости от конфигурации:
при отключенном MAB устройство без суппликанта просто не получит доступ;
при высоком приоритете MAB он всегда будет использоваться, даже при наличии 802.1x;
при настройке правильной последовательности будет попытка аутентификации по 802.1x, а уже после по MAB.
Конкретная реализация зависит от вендора и модели оборудования. На своей практике встречались с решениями, где невозможно одновременно использовать 802.1x и MAB на одном порту, однако это относится к устаревшим или дешевым устройствам.
Отдельно стоит отметить, что RADIUS/NAC-система не управляет логикой выбора метода аутентификации на коммутаторе. Она принимает решение уже после того, как коммутатор передал запрос (802.1x или MAB) на сервер аутентификации.
Ограничения MAB
Несмотря на простоту и удобство, механизм MAB имеет ряд ограничений, которые важно учитывать при проектировании сети.
Главная особенность MAB в том, что в качестве идентификатора используется только MAC-адрес устройства. В отличие от 802.1x, здесь отсутствует криптографическая аутентификация, проверка учетных данных или сертификатов.
Это приводит к ряду рисков:
1. Подмена MAC-адреса
MAC-адрес не является защищенным идентификатором. Его можно изменить на уровне операционной системы или сетевого адаптера.
Злоумышленник может определить разрешенный MAC-адрес в сети и получить доступ с теми же правами, что и легитимное устройство, пройти идентификацию по MAB и сервер не сможет отличить подмену.
2. Сложности масштабирования
В небольшой сети управление списками MAC-адресов может выглядеть приемлемо. Но по мере роста инфраструктуры возникают проблемы:
необходимо вести и актуализировать базы MAC-адресов;
устройства меняются, перемещаются или заменяются;
увеличивается количество ошибок и неучтенных записей.
В какой-то момент управление доступом превращается в ручной процесс, плохо поддающийся контролю.
Сам по себе MAB не является проблемой. На практике он давно стал стандартным способом подключения устройств без поддержки 802.1x.
Однако при использовании MAB важно соблюдать несколько правил, чтобы обеспечить высокий уровень безопасности сети, а не одну большую дыру в безопасности:
предоставлять таким устройствам только минимально необходимый доступ;
по возможности исключать использование MAB в публичных и неконтролируемых зонах;
применять дополнительные механизмы контроля, такие как профилирование устройств и динамические политики доступа.
Именно поэтому MAB обычно рассматривается не как самостоятельный механизм защиты, а как часть общей NAC-архитектуры.
MAB считается удобным механизмом для подключения устройств без поддержки 802.1x, но по факту это компромисс. Так называемый удобный «костыль».
Роль NAC в контроле неуправляемых устройств, на примере AxelNAC
Вышеперечисленные ограничения MAB показывают, что этого механизма недостаточно для построения безопасной и управляемой сети.
Решение данной задачи выполняют NAC-системы, которые могут:
учитывать контекст подключения;
применять гибкие политики;
работать как с 802.1X, так и с MAB.
NAC выступает в роли сервера аутентификации, но его функциональность значительно шире. Он не просто проверяет учетные данные или MAC-адрес, а принимает решение о доступе на основе набора факторов.
В случае неуправляемых устройств NAC дополняет механизм MAB и устраняет его основные ограничения.
1. Профилирование устройств
Одной из ключевых возможностей NAC является определение типа подключенного устройства.
Даже если устройство проходит аутентификацию по MAB и идентифицируется только по MAC-адресу, система может дополнительно анализировать:
OUI (Organizationally Unique Identifier – уникальный идентификатор организации находится в первых трех октетах MAC-адреса);
DHCP вендор (DHCP Vendor Class);
отпечаток DHCP (DHCP fingerprint);
отпечаток DHCPv6 (DHCPv6 fingerprint);
данные протоколов CDP и LLDP;
информацию, полученную по SNMP;
User-Agent браузера при работе через Captive Portal.
На основе этих данных NAC формирует профиль устройства. Это позволяет уйти от простого разрешения MAC-адреса к более осмысленной модели «тип устройства + динамическая политика» и появляется автоматическая инвентаризация всех устройств в сети.
2. Применение политик доступа
После определения типа устройства NAC может автоматически применить к нему соответствующую политику доступа.
Важно понимать, что сами по себе VLAN, ACL или механизмы сегментации не являются уникальными возможностями NAC. Все эти инструменты давно существуют на сетевом оборудовании и могут использоваться статически.
Основное отличие заключается в том, что NAC позволяет централизованно и автоматически применять необходимые политики на основе результатов аутентификации и профилирования устройства.
В зависимости от политики это может быть:
назначение VLAN;
применение динамических ACL;
ограничение доступа к определенным сервисам.
Таким образом устройствам можно разрешить минимальный доступ. Принтеру предоставить доступ только до принт сервера , камере к системе видеонаблюдения, а IP-телефону назначить голосовой сегмент.
3. Централизация управления
Все решения о доступе принимает только NAC-система.
Это дает несколько ключевых преимуществ:
единая политика для всей сети;
отсутствие локальных списков на коммутаторах;
упрощение эксплуатации;
прозрачность подключенных устройств и их прав.
4. Контроль и реакция на изменения
В отличие от статического MAB, NAC позволяет отслеживать изменения в сети.
Например:
появление нового устройства;
перемещение устройства по сети, как в физическом смысле, так и в логическом ;
появление неизвестного DHCP-отпечатка;
попытки подключения с неизвестного MAC-адреса.
В зависимости от политики система ограничивает доступ, помещает устройство в карантин и отправляет событие в систему мониторинга.
802.1x и MAB – это механизмы получения идентификатора устройства, а NAC – система, которая принимает решение о том, что с этим устройством делать дальше.
Именно за счет этой связки становится возможным контролировать не только управляемые рабочие станции, но и весь класс неуправляемых устройств, которые ранее были ограничены в модели безопасности.
Однако возможности NAC не ограничиваются аутентификацией устройств по 802.1x или MAB. Во многих корпоративных сетях требуется предоставить контролируемый доступ и пользователям, которые подключаются с личных устройств, гостевых ноутбуков или оборудования подрядчиков. Для таких сценариев NAC поддерживает дополнительные механизмы аутентификации, одним из которых является Captive Portal.
Этот механизм используется в сценариях, где требуется аутентификация гостевого пользователя или подрядчика.
В этом случае:
пользователь подключается к сети;
при попытке открыть любой ресурс он перенаправляется на веб-портал;
проходит аутентификацию (логин/пароль, SMS, гостевой доступ и т.д.);
после этого NAC применяет соответствующую политику доступа.
Таким образом, даже для «неуправляемых» или внешних устройств появляется контролируемый и отслеживаемый механизм подключения.
NAC в сетях без поддержки 802.1x и на неуправляемом оборудовании
Может показаться, что внедрение NAC невозможно без полной поддержки 802.1x на сетевом оборудовании. Действительно, если коммутатор не умеет работать с 802.1x, то он не сможет передавать EAP-запросы на сервер аутентификации.
Однако на практике подобные ограничения далеко не всегда становятся «блок-фактором» для внедрения NAC.
В рамках AxelNAC реализованы дополнительные механизмы работы с оборудованием после этапа аутентификации клиента. Например, такие действия, как реаутентификация, назначение Captive Portal или динамическое изменение политики доступа, могут выполняться различными способами, иногда даже без прямого участия коммутатора.
При этом сам этап передачи аутентификационных данных от клиента к серверу без 802.1x действительно невозможен. Но это не означает, что NAC нельзя использовать в сетях с неуправляемыми коммутаторами или устаревшим оборудованием.
В одном из проектов AxelNAC внедрялся на промышленном предприятии, где сеть была далека от классической трехуровневой архитектуры (вся структура определялась потребностями конечных абонентов, наличием линий связи и оборудования). Часть устройств подключалась через неуправляемые коммутаторы и хабы, однако далее по цепочке все равно находился управляемый коммутатор с поддержкой 802.1x.
Несмотря на то, что согласно RFC 3748 кадры EAPOL (стандарт описывающий протокол транспорта аутентификационных данных от клиента к коммутатору) не должны пересылаться далее первого уровня доступа, многие неуправляемые устройства просто передают такой трафик дальше.
В результате:
конечное устройство отправляет EAPOL;
неуправляемый коммутатор пересылает его далее;
первый управляемый коммутатор начинает процесс аутентификации;
NAC применяет политику доступа к сессии устройства.
Таким образом даже в подобной архитектуре продолжают работать:
назначение VLAN;
ACL;
Captive Portal;
MAB;
динамическое изменение политики через CoA (Change of Authorization).
Разумеется, подобная схема имеет ограничения. Она не обеспечивает защиту трафика внутри самого неуправляемого сегмента. Также необходимо учитывать ограничения оборудования по количеству одновременных 802.1x и MAB-сессий на одном порту.
Например, коммутатор НР2510al-24G поддерживает до 256 сессий 802.1x и до 256 MAB-сессий, тогда как НР2910al-24G всего 8 сессий 802.1x и 32 сессии MAB. Учитывая эти ограничения клиенту все же пришлось заменить часть оборудования, но в большинстве случаев обошлось переключением порта с гроздью хабов из одного управляемого коммутатора в другой.
Тем не менее даже в такой «гибридной» сети NAC позволяет получить главное:
инвентаризацию устройств;
контроль подключений;
обнаружение нелегитимных устройств;
базовую сегментацию сети;
централизованную политику доступа.
За счет этого внедрение NAC можно начинать еще до полной модернизации access-инфраструктуры, постепенно повышая уровень контроля и сегментации сети без одномоментной замены всего оборудования.
Заключение
В итоге важно понимать, что 802.1x не является «универсальным решением для всей сети». Это мощный и правильный механизм сетевой аутентификации, но его возможности ограничены типом подключаемых устройств и особенностями инфраструктуры.
На практике любая инфраструктура неизбежно состоит не только из управляемых ноутбуков и рабочих станций, но и множества других устройств, для которых классический 802.1x либо недоступен, либо создает слишком много эксплуатационных проблем.
Именно поэтому в современных корпоративных сетях ключевую роль начинают играть NAC-системы. Они позволяют понимать, что именно подключается к сети, как это устройство должно себя вести и какой уровень доступа ему действительно необходим.
При этом внедрение NAC не всегда требует полной модернизации access-инфраструктуры или одномоментной замены оборудования. Во многих случаях начать можно постепенно – с инвентаризации устройств, контроля подключений и базовой сегментации сети, поэтапно повышая уровень прозрачности и безопасности всей инфраструктуры.
