Последнее время всё больше компаний начинает серьёзно относиться к сетевой безопасности. Особое внимание уделяется в том числе и контролю доступа к локальной сети внутри организации. Не редкость, что политика безопасности требует, чтобы абсолютно все подключаемые к проводной и беспроводной сетям устройства проходили аутентификацию (не рассматриваем оборудование, физически изолированное в серверных комнатах).
Мне, как сетевому инженеру, как раз и была поставлена задача всё это реализовать. Сразу отмечу, что у нас в компании более десяти офисов разных размеров, сети которых насчитывают от одного до тридцати коммутаторов уровня доступа Cisco Catalyst. Исторически сложилось, что практически в каждом офисе уже был поднят Microsoft Network Policy Server (NPS), как RADIUS-сервер для аутентификации беспроводных клиентов.
Именно все эти NPS и требовалось задействовать для выполнения поставленной задачи, так как вариант с централизованным RADIUS-сервером типа Cisco ISE/ACS отпадал из-за ненадёжности WAN-каналов, а покупать другие продукты не было средств.
Рассмотрим задачу более подробно.
1) Необходимо аутентифицировать:
2) Необходимо динамически назначать vlan для каждого аутентифицированного устройства, так как некоторые из них могут «путешествовать» по разным этажам (например, устройства видеоконференций). При этом телефоны должны попадать в тэгируемый голосовой vlan, а остальные устройства в data-vlan.
Рабочие станции было решено аутентифицировать по установленному сертификату с помощью 802.1x. Это легко реализуемо в NPS. Создаём Network Policy, в качестве условия выбираем Authentication Type = EAP (по факту это EAP-TLS, где защищённый канал между суппликантом и сервером аутентификации создаётся с использованием их сертификатов), NAS Port Type = Ethernet (для проводых подключений) или Wireless (для беспроводных).
Можно для верности добавить принадлежность компьютера к какой-либо доменной группе. Для назначения vlan используются стандартные RADIUS-атрибусы, хотя также можно использовать Vendor Specific Attributes, о чём будет рассказано чуть позже.
Что касается других устройств, то для них необходимо применить MAB (MAC-address Authentication Bypass), ввиду отсутствия поддержки 802.1x. При MAB коммутатор выступает в роли суппликанта и отправляет информацию о mac-адресе подключенного устройства RADIUS-серверу. Коммутаторы Cisco Catalyst поддерживают MAB, как fallback метод для 802.1х (когда коммутатор не получил EAPoL–ответа от клиента).
Так сложилось, что в NPS можно реализовать MAB только с привязкой к ActiveDirectory. Т.е. для каждого устройства должен быть заведён объект в AD, что нас категорически не устраивало. Решено было «допилить» NPS до нормальной поддержки MAB. К счастью, Microsoft предоставляет возможность подключать библиотеки расширения к NPS, чем я и воспользовался.
Собрав в кучу скупую техническую документацию Microsoft, описание RFC-стандарта для RADIUS и немногие примеры, встречающиеся в Интертете, и добавив к ним мои ограниченные познания в программировании, я получил положительный результат… спустя два месяца.
Библиотека запускается вместе с NPS и реализует метод RadiusExtensionProcess2, вызываемый при каждом новом запросе. Мой алгоритм проверяет запрос к RADIUS-серверу и сравнивает атрибуты Calling-Station-ID (mac-адрес клиента) и Username, так как при MAB они совпадают. Конечно, можно было идентифицировать MAB по другим атрибутам, но я выбрал именно этот способ.
После того, как мы установили, что данный запрос является MAB, необходимо сверить адрес клиента с базой mac-адресов. Все адреса привязываются к различным профайлам (data, voice, printer,…), для каждого из которых задаётся свой формат RADIUS-ответа.
Так как я имел дело с оборудованием Cisco, то решил добавлять в RADIUS-ответ Vendor Specific Attribute (VSA) – AV-Pair. С его помощью можно заставить коммутатор поместить клиента в какой-либо data/voice vlan (если честно, то я не стал здесь использовать стандартные RADIUS-атрибуты ещё и потому, что просто не смог добиться корректной работы программы).
Пример 1: поместить клиента в vlan 2:
tunnel-type=VLAN
tunnel-medium-type=ALL_802
tunnel-private-group-id=2
Пример 2: поместить клиента в голосовой vlan, сконфигурированный на этом порту:
device-traffic-class=voice
Если клиента нужно поместить в data vlan, который сконфигурирован на порту коммутатора, то нет необходимости добавлять VSA. Достаточно просто послать ResponseCode = AccessAccept.
Обращение к библиотеке производится после того, как NPS проверил все свои политики (Network Policies) на предмет совпадения их условий с параметрами клиента, поэтому имеющиеся старые политики для Wireless отлично работают и после внедрения MAB.
Совсем забыл сказать, что NPS содержит две группы политик: Connection Request Policies и Network Policies. Ранее я упоминал только о второй. В первой же достаточно создать одно правило, под которое будут попадать все запросы к RADIUS-серверу. Например, в качестве условия задать время с 00:00 до 24:00. Ну или если это вам не подходит, то можете указать с помощью regex-синтаксиса все возможные адреса сетевых устройств в параметре NAS IPv4 Address.
Вернёмся к моей библиотеке. Для управления базой данных мак-адресов я написал простенькую программу с графическим интерфейсом, которая позволяет формировать профайлы для разных типов устройств и связывать их с мак-адресами из базы данных. Выглядит она вот так:
Про настройку коммутаторов для 802.1x и MAB написано много, но я всё равно приведу пример:
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
dot1x system-auth-control
radius-server host <адрес сервера> key <ключ> (или то же самое через server group в новых IOS)
interface range <ваши порты доступа>
switchport mode access
switchport voice vlan (если нужно)
authentication port-control auto
authentication host-mode multi-domain
dot1x pae authenticator
mab
Тестовую версию библиотеки и программы управления можно скачать здесь.
Сейчас я её активно тестирую и параллельно разрабатываю новую более серьёзную версию с центральным управлением через веб-интерфейс, которая объединит несколько RADIUS-серверов из разных офисов и будет синхронизировать данные между ними, а также сможет дружить с основными СУБД и автоматически импортировать мак-адреса устройств из корпоративных инструментов инвентаризации. Надеюсь поведать о новом проекте в следующих постах.
Мне, как сетевому инженеру, как раз и была поставлена задача всё это реализовать. Сразу отмечу, что у нас в компании более десяти офисов разных размеров, сети которых насчитывают от одного до тридцати коммутаторов уровня доступа Cisco Catalyst. Исторически сложилось, что практически в каждом офисе уже был поднят Microsoft Network Policy Server (NPS), как RADIUS-сервер для аутентификации беспроводных клиентов.
Именно все эти NPS и требовалось задействовать для выполнения поставленной задачи, так как вариант с централизованным RADIUS-сервером типа Cisco ISE/ACS отпадал из-за ненадёжности WAN-каналов, а покупать другие продукты не было средств.
Рассмотрим задачу более подробно.
1) Необходимо аутентифицировать:
- корпоративные рабочие станции;
- IP телефоны и устройства конференций;
- сетевые принтеры;
- CCTV-камеры
- и т.д.
2) Необходимо динамически назначать vlan для каждого аутентифицированного устройства, так как некоторые из них могут «путешествовать» по разным этажам (например, устройства видеоконференций). При этом телефоны должны попадать в тэгируемый голосовой vlan, а остальные устройства в data-vlan.
Рабочие станции было решено аутентифицировать по установленному сертификату с помощью 802.1x. Это легко реализуемо в NPS. Создаём Network Policy, в качестве условия выбираем Authentication Type = EAP (по факту это EAP-TLS, где защищённый канал между суппликантом и сервером аутентификации создаётся с использованием их сертификатов), NAS Port Type = Ethernet (для проводых подключений) или Wireless (для беспроводных).
Можно для верности добавить принадлежность компьютера к какой-либо доменной группе. Для назначения vlan используются стандартные RADIUS-атрибусы, хотя также можно использовать Vendor Specific Attributes, о чём будет рассказано чуть позже.
Что касается других устройств, то для них необходимо применить MAB (MAC-address Authentication Bypass), ввиду отсутствия поддержки 802.1x. При MAB коммутатор выступает в роли суппликанта и отправляет информацию о mac-адресе подключенного устройства RADIUS-серверу. Коммутаторы Cisco Catalyst поддерживают MAB, как fallback метод для 802.1х (когда коммутатор не получил EAPoL–ответа от клиента).
Так сложилось, что в NPS можно реализовать MAB только с привязкой к ActiveDirectory. Т.е. для каждого устройства должен быть заведён объект в AD, что нас категорически не устраивало. Решено было «допилить» NPS до нормальной поддержки MAB. К счастью, Microsoft предоставляет возможность подключать библиотеки расширения к NPS, чем я и воспользовался.
Собрав в кучу скупую техническую документацию Microsoft, описание RFC-стандарта для RADIUS и немногие примеры, встречающиеся в Интертете, и добавив к ним мои ограниченные познания в программировании, я получил положительный результат… спустя два месяца.
Библиотека запускается вместе с NPS и реализует метод RadiusExtensionProcess2, вызываемый при каждом новом запросе. Мой алгоритм проверяет запрос к RADIUS-серверу и сравнивает атрибуты Calling-Station-ID (mac-адрес клиента) и Username, так как при MAB они совпадают. Конечно, можно было идентифицировать MAB по другим атрибутам, но я выбрал именно этот способ.
После того, как мы установили, что данный запрос является MAB, необходимо сверить адрес клиента с базой mac-адресов. Все адреса привязываются к различным профайлам (data, voice, printer,…), для каждого из которых задаётся свой формат RADIUS-ответа.
Так как я имел дело с оборудованием Cisco, то решил добавлять в RADIUS-ответ Vendor Specific Attribute (VSA) – AV-Pair. С его помощью можно заставить коммутатор поместить клиента в какой-либо data/voice vlan (если честно, то я не стал здесь использовать стандартные RADIUS-атрибуты ещё и потому, что просто не смог добиться корректной работы программы).
Пример 1: поместить клиента в vlan 2:
tunnel-type=VLAN
tunnel-medium-type=ALL_802
tunnel-private-group-id=2
Пример 2: поместить клиента в голосовой vlan, сконфигурированный на этом порту:
device-traffic-class=voice
Если клиента нужно поместить в data vlan, который сконфигурирован на порту коммутатора, то нет необходимости добавлять VSA. Достаточно просто послать ResponseCode = AccessAccept.
Обращение к библиотеке производится после того, как NPS проверил все свои политики (Network Policies) на предмет совпадения их условий с параметрами клиента, поэтому имеющиеся старые политики для Wireless отлично работают и после внедрения MAB.
Совсем забыл сказать, что NPS содержит две группы политик: Connection Request Policies и Network Policies. Ранее я упоминал только о второй. В первой же достаточно создать одно правило, под которое будут попадать все запросы к RADIUS-серверу. Например, в качестве условия задать время с 00:00 до 24:00. Ну или если это вам не подходит, то можете указать с помощью regex-синтаксиса все возможные адреса сетевых устройств в параметре NAS IPv4 Address.
Вернёмся к моей библиотеке. Для управления базой данных мак-адресов я написал простенькую программу с графическим интерфейсом, которая позволяет формировать профайлы для разных типов устройств и связывать их с мак-адресами из базы данных. Выглядит она вот так:
Про настройку коммутаторов для 802.1x и MAB написано много, но я всё равно приведу пример:
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
dot1x system-auth-control
radius-server host <адрес сервера> key <ключ> (или то же самое через server group в новых IOS)
interface range <ваши порты доступа>
switchport mode access
switchport voice vlan (если нужно)
authentication port-control auto
authentication host-mode multi-domain
dot1x pae authenticator
mab
Тестовую версию библиотеки и программы управления можно скачать здесь.
Сейчас я её активно тестирую и параллельно разрабатываю новую более серьёзную версию с центральным управлением через веб-интерфейс, которая объединит несколько RADIUS-серверов из разных офисов и будет синхронизировать данные между ними, а также сможет дружить с основными СУБД и автоматически импортировать мак-адреса устройств из корпоративных инструментов инвентаризации. Надеюсь поведать о новом проекте в следующих постах.
