Содержание
Инструменты пользователя
Инструменты сайта
Содержание
Цель: организовать закрытую сеть WiFi cо списком доступа по MAC-адресу и централизованным управлением этим списком на точках доступа TP-Link TL-WR842ND.
Требуемый уровень безопасности допускает организацию доступа к беспроводной сети на основе списка разрешенных MAC-адресов. В тоже время есть потребность ограничить любого желающего от доступа к сети. Хотя с другой стороны, любой желающий, просканировав эфир, может определить MAC-адреса разрешенных пользователей, и подключиться к сети скопировав полученный MAC на свой беспроводной интерфейс. Это противоречие и предстоит разрешить в работе: ограничить возможность доступа к сети «любому желающему» наиболее простыми методами с возможностью централизованного управления доступом (без надобности вносить изменения на каждой точке доступа в отдельности).
Для знакомства с теорией безопасности Wi-Fi , то неплохой обзор есть на Хабре: WPA2-Enterprise, или правильный подход к безопасности Wi-Fi сети
Добавим то, что автор при сравнении WPA2 Personal и WPA2 Enterprise основным отличием считает использование индивидуального ключа на каждого пользователя в WPA2 Enterprise .
А нам интересен WPA2 Enterprise для централизованного управления клиентами, а именно ведения списка MAC -адресов.
FreeRADIUS из коробки уже настроен на многие типы авторизации, конфиг достаточно большой и разбит на отдельные файлы. Понять что от чего зависит сходу достаточно непросто. Вот перевод статейки которая приблизительно описывает, чем занимается радиус сервер, чтобы разрешить или запретить доступ к сети.
RADIUSPicking Auth-TypeAuthenticating
Вот мой вольный перевод этой статьи, за достоверность не ручаюсь.
И на всякий случай синхронизирую термины:
Большинство проблем с конфигурацией связаны с непониманием концепции FreeRADIUS . Редактирование конфигурационных файлов и перебор возможных опций не поможет понять концепцию.
Ни вы, ни радиус не знает и не решает, что клиент вам пришлет в запросе. Ответственность за то, что содержится в запросе лежит 100% на клиенте.
Радиус сервер смотрит на запрос и говорит:
Ответ на этот вопрос зависит от того, какие типы аутентификации вы включили, что сервер может найти в базе данных, и что содержится в запросе.
Сервер начинает опрашивать модули этапа авторизации (в конфиге есть отдельная секция authorize <> ):
В какой-то момент один из модулей скажет:
Модули делают это на основании просмотра ключевых атрибутов пришедших в запросе, таких как MS-CHAP-Challenge (для MS-CHAP ), или CHAP-Challenge (для CHAP ), or EAP-Message (для EAP ). Или же на основании предположения, что надо бы добавить что-то в каждый запрос.
Если модуль думает, что у него есть шанс чтобы ещё и аутентифицировать пользователя, он скажет:
Если модуль ничего не распознаёт, или знает, что нет необходимости что-то искать, то он просто ничего не делает.
В конце авторизации, сервер проверит добавлен ли Auth-Type к запросу. Если нет, то немедленно отклонит запрос.
Давайте предположим, что клиент отправил запрос с атрибутом User-Password, и модуль pap включен в секции autorize <> . Тогда pap модуль установит Auth-Type = pap.
Таким образом, сервер снова обратится к модулю pap, но уже на стадии аутентификации ( она также имеет свою секцию в конфиге authenticate <> ), pap ответит:
Итак, затем идет сравнение локального заранее известного правильного пароля с тем, который ввел пользователь (пришел в запросе). Это то, как работает аутентификация.
«правильный» пароль (заранее известный правильный пароль) был добавлен другим модулем. Например, модуль pap просто выполняет PAP аутентификацию и ничего больше. Преимущества такого подхода в том, что «правильный» пароль может быть добавлен в запрос из текстового файла users , SQL , LDAP , /etc/passwd , внешней программы и т.д. и т.п. в очень широких пределах.
Например, если подключен модуль LDAP в секции authorize <> , и сервер обрабатывает запрос, то если модуль найдет у себя запись с паролем (где-нибудь в каталоге LDAP), то он добавит этот пароль в запрос, чтобы другой модуль на этапе аутентификации мог использовать его.
Что, если клиент отправит MSCHAP запрос? Что будет с этим запросом делать радиус-сервер?
В этом случае, модуль mschap ищет в запросе атрибут MS-CHAP на этапе авторизации и когда находит устанавливает атрибут Auth-Type на себя (mschap), но уже для этапа аутентификации. Модуль базы данных (например, такой как LDAP, выше) получает информацию о «правильном» пароле и добавляет её в запрос. Затем модуль mschap вызывается уже для процесса аутентификации. Он просматривает запрос в поисках «правильного» пароля либо в виде текста, либо в виде NT-HASH (почему? Смотрите таблицу протоколов http://deployingradius.com/documents/protocols/compatibility.html ). Если ни один требуемый вид пароля не будет предоставлен хранилищем данных, то mschap скажет:
Но сервер уже исчерпал варианты, его единственный вариант был mschap, так как это то, что клиент послал в запросе. Mschap модуль не смог ничего сделать, потому что ему не предоставили «правильный» пароль. Таким образом сервер за неимением вариантов запрос отклоняет. MSCHAP данные могли быть корректными, но у сервера не было способа убедиться в этом. Поэтому он ответил отказом.
Выводы
На имеющихся беспроводных маршрутизаторах TP-Link TL-WR842ND с заводской прошивкой у нас есть возможность использовать следующие типы защиты: WPA2–PSK, WPA2–Enterprise. Остальные варианты не рассматривались из-за их неактуальности: открытая сеть не соответствует поставленной цели; WEP – давно скомпрометирован; WPA-PSK/Enterprise – есть же WPA2 c более строгим подходом к шифрации.
WPA2-PSK – использует Pre-shared key, который в общем случае устраивал бы, но так как было желание управлять допущенными к сети MAC-адресами пользователей централизованно, а не на каждой точке в отдельности, доставляет некоторое неудобство.
WPA2-Enterprise – использует RADIUS-сервер для авторизации/аутентификации; учет пользователей (accounting) не поддерживается точкой доступа TP-Link TL-WR842ND. Отправляет в запросе к RADIUS MAC-адрес пользователя – следовательно можно вести список разрешенных MAC на RADIUS-сервере. WR842ND не умеет подставлять MAC-адрес вместо имени пользователя и пароля (такая возможность есть, например, в RouterOS от Mikrotik), поэтому придется заводить учетные данные (пользователь/пароль) либо на каждого пользователя можно с привязкой к MACy, либо одну общую учетку, о которой будут осведомлены все заинтересованные пользователи, а список MAC-адресов будет вестись отдельно.
Так как централизованно управлять списком доступа на основании MAC-адресов позволяет RADIUS-сервер, то выбор защиты Wi-Fi сети пал на WPA2-Enterprise.
WPA2-Enterprise поддерживает ряд методов аутентификации EAP. Для Window актуальны EAP-TLS и EAP-PEAPv0. EAP-TLS – поможет избавить пользователя от введения логина и пароля, но здесь встанет другая задача по разворачиванию инфраструктуры открытых ключей и распределению сертификатов. Причем встанет проблема установки сертификатов на мобильных устройствах. Хоть данный метод самый надёжный, но из-за сложности развёртывания и сопровождения для наших нужд он отпадает.
EAP-PEAPv0 с MS-CHAPv2 – от пользователя требуется доверие к точке доступа/серверу и знание связки логин/пароль. Доверие к точке доступа/серверу достигается проверкой предъявляемого сервером сертификата, либо отключением этой проверки. Суть метода состоит в создании защищённого туннеля внутри которого осуществляется аутентификация пользователя по методу MS-CHAPv2. Простое развёртывание и сопровождение, особенно если слепо доверять точке доступа/серверу. Но страдает безопасность от «активных» злоумышленников.
Метод EAP-PEAPv0 с MS-CHAPv2 существенно проще в реализации, чем EAP-TLS и позволит организовать закрытую сеть, тем самым «любому желающему» будет гораздо сложнее, нежели просто определить разрешенный MAC-адрес, если конечно у него не будет альтернативного метода получения доступа к учетным данным.
Реализация метода EAP-PEAPv0 с MS-CHAPv2 во FreeRADIUS позволяет выдавать пользователю индивидуальную связку логин/пароль и привязывать их к MAC-адресу его оборудования. Хотя для наших целей это было признано нецелесообразным из-за дополнительной нагрузки на администраторов сети по сопровождению пользователей. Поэтому будет общий логин/пароль на всех, так как некоторые wi-fi клиенты не дают возможности оставлять данные поля пустыми.
Итог: беспроводной маршрутизатор TP-Link TL-WR842ND будет работать в режиме точки доступа с методом безопасности WPA2-Enterprise, который предполагает использование RADIUS-сервера. RADIUS-сервер на базе FreeRADIUS будет реализовывать список доступа на основе MAC-адресов и производить аутентификацию пользователей по методу EAP-PEAPv0 с MS-CHAPv2. При данном методе, пользователю необходимо доверять точеке доступа/серверу (или проверять сертификат для установки доверия) и знать учетные данные (логин/пароль) для прохождения MS-CHAPv2 аутентификации.
Демон FreeRADIUSa после установки сразу же стартует, то есть после выполнения команды apt-get install freeradius мы имеем на выходе запущенный RADIUS-сервер. Официальная документация рекомендует вносить как можно меньше изменений в исходную конфигурацию, ибо она продумана для многих типичных задач RADIUS-сервера. FreeRADIUS «из коробки» уже умеет работать с WPA2-Enterprise, в том числе и с EAP-PEAPv0 c внутритуннельной аутентификацией MS-CHAPv2. Поэтому настройка FreeRADIUS заключается в том, чтобы создать собственный сертификат сервера, завести клиентов (точки доступа) , завести учетные данные для MS-CHAPv2 и добавить возможность фильтрации запросов по MAC-адресами из разрешенного списка.
Следует отметить, что приведенные команды и фрагменты конфигурации тестировались на Debian 7.5 c FreeRADIUS 2.1.12+dfsg-1.2
2.1 Создание production-сертификатов
Так как большинство методов корпоративного WPA2 требуют наличия сертификата и закрытого ключа как минимум на сервере, то придется его создать. Чтобы создать самоподписанный сертификат нам нужен сертификат и закрытый ключ собственного удостоверяющего центра, которые тоже придется создать.
Инструменты для создания сертификатов нужных freeradius у Debian лежат по пути /usr/share/doc/freeradius/examples/certs. Содержимое этого каталога следует скопировать в /etc/freeradius/certs. Необходимы файлы:
А также можно скопировать README, в котором расписано что и зачем нужно и как этим пользоваться, поэтому дальше пойдут необходимые команды с краткими пояснениями, за более подробной инфой в README.
Для работы скриптов понадобится openssl и make.
Создаем файл с параметрами Диффи-Хеллмана, если он вдруг отсутствует в каталоге /etc/freeradius/certs:
Результат работы: файл dh
Создаём корневой сертификат или сертификат удостоверяющего центра. Если до этого уже были какие-то сертификаты (обычно тестовые), то удаляем:
Редактируем под себя файл ca.cnf . Следует обратить внимание на default_md = md5 (лучше поставить sha1), default_days = 365 ( возможно через год не захочется генерировать новый сертификат, тогда лучше ставить побольше), input_password/output_password и нужно отредактировать под себя всю секцию [certificate_authority] .
Результаты работы: ca.pem , ca.key и ca.der – сертификат удостоверяющего центра, его закрытый ключ и сертификат в формате понятном для Windows соответсвенно.
Создание серверного сертификата: Редактируем под себя файл server.cnf . Следует обратить внимание на default_md = md5 (лучше поставить sha1), default_days = 365 ( возможно через год не захочется генерировать новый сертификат, тогда лучше ставить побольше), input_password/output_password и нужно отредактировать под себя всю секцию [server] . Важно чтобы значение commonName отличалась от соответствующего сертификата удостоверяющего центра.
Результат работы: помимо прочих файлы server.pem и server.key – сертификат и закрытый ключ сервера.
В конфигурации пути к сертификатам сгенерированным в папке /etc/freeradius/certs прописаны по умолчанию.
Если был изменён пароль на закрытый ключ сервера ( output_password ), то его придется указать в конфиге. А также нужно закомментировать путь к скрипту создания временных сертификатов. Это делается в файле /etc/freeradius/eap.conf в следующей секциии:
2.2 Описываем RADIUS-клиентов (точки доступа)
Добавляем в файл /etc/freeradius/clietns.conf следующее:
2.3 Заводим учетные данные для аутентификации по логину и паролю
В файл /etc/freeradius/users добавляем первую строку следующего содержания:
2.4 Добавляем список доступа на основе MAC-адресов
Конфигурация FreeRADIUS не поддерживает списка MAC-адресов из коробки. Хотя MAC-адрес можно указать как дополнительный атрибут проверки в файле /etc/freeradius/users , например:
Для запроса с именем пользователя user будет проверяться пароль и сравниваться атрибут Calling-Station-Id . Чтобы это работало в случае ЕAP-PEAP следует в файле /etc/freeradius/eap.conf установить параметр сopy_request_to_tunnel = yes в секции приведённой ниже:
Точка доступа в запросе шлет параметр Calling-Station- >“MAC-адрес«, причем формат представления MAC-адреса может быть различным на разных точках доступа. Чтобы избежать проблем из-за различного представления MAC-адреса, следует их приводить к одному виду. Для этого в фйле /etc/freeradius/policy.conf имеется уже готовая процедура – r ewrite.calling_station_id . Чтобы ей воспользоваться её название нужно вставить в начало секции authorize <> после объявления preprocess (если он есть) в файлах /etc/freeradius/site-available/default и /etc/freeradius/site-available/inner-tunnel следующим образом:
Процедура нормализует формат MAC-адреса в атрибуте Callin-Station-Id из запроса, пришедшего на сервер, к формату xx-xx-xx-xx-xx-xx – нижний регистр и все через «минус». Поэтому в файле /etc/freeradius/user следует придерживаться данного формата. В принципе уже можно делать список доступа для фильтрации по MAC.
Вариант1.
Достаточно в файл users в самое его начало добавлять нужных пользователей с параметром Calling-Station-Id , если учетные данные нужны одинаковые, то можно их просто повторить, например:
Тем самым на одну пару логин/пароль вешаем три различных MAC-адреса.
Вариант2.
Можно пойти другим путём и создать для списка разрешенных MAC-адресов отдельный файл. Для этого создаем в каталоге /etc/freeradius/ файл authorized_macs и объявляем его в модуле files . Для этого вставляем в конец файла /etc/freeradius/modules/files следующий кусок конфига:
Чтобы проверка MAC-адресов из файла /etc/freeradius/authorized_macs выполнялась, нужно в файл /etc/freeradius/sites-available/default в секцию authorize <> после объявления rewrite.calling_station_id вставить прокомментированные строки:
Теперь файл authorized_macs заполняем разрешенными для авторизации MAC-адресами. Каждый MAC на новой строке. Следует учитывать, что формат строго следующий: xx-xx-xx-xx-xx-xx , где x-либо цифра, либо буквы от a до f в нижнем регистре. Например:
Следует отметить, что атрибут Calling-Station-Id указанный в файле users для определённой пары логин/пароль также будет действовать, но его проверка будет осуществляться на этапе, который проходит позднее. Так что если поступит запрос со значением Calling-Station-Id , не указанном в файле authorized_macs, то этот запрос сразу отклонится, вне зависимости, что указано в файле users.
Итог: выше описаны необходимые измения в конфигурации по-умолчанию, чтобы получить требуемый функционал от freeradius. Еще нужно настроить точки доступа, куда нужно вписать IP адрес RADIUS-сервера и секретную фразу из секций client <> . Также в конфигурации описано много лишних методов аутентификации и модулей дополнительной обработки, которые можно удалить/закомментировать без ущерба функционалу. При выбранном типе аутентификации у FreeRADIUS нет возможности выдавать клиентам IP адреса и прочие сетевые настройки, это должен делать отдельный DHCP-сервер.
При изменении файлов конфигурации, в том числе файлов users и authorized_macs требуется принудительное перечитывание конфига сигналом SIGHUP :
При изменениях в конфиге radiusd.conf лучше демон перезагрузить:
Чтобы проверить конфигурацию следует запускать демон в режиме отладки:
При таком запуске можно увидеть как freeradius распарсил конфиг и увидеть как он обрабатывает запросы. Очень помогает при отыскании различных проблем или при объяснении неожиданного поведения.
В комплекте идет полезная утилитка radtest – простой RADIUS-клиент. С ней можно проводить некоторые простые тесты для проверки конфигурации. Возможный пример использования (тестирование внутритуннельной аутентификации по порту 18120):
В общем случае алгоритм привязки RADIUS-сервера к беспроводной сети может быть реализован следующим образом:
1. Сетевой администратор дает команду RADIUS-серверу завести новую учетную карточку пользователя с занесением в нее имени пользователя, под которым он будет проходить аутентификацию, и его пароля.
2. Внесенный в базу RADIUS-сервера пользователь с помощью беспроводной связи подключается к точке доступа, чтобы проверить электронную почту.
3. Точка доступа запрашивает у пользователя его имя и пароль.
4. Точка доступа связывается с RADIUS-сервером и дает запрос на аутентификацию пользователя.
5. RADIUS-сервер находит валидное имя пользователя и пароль, разрешает новую сессию и заводит в журнале соответствующую запись о начале новой сессии.
6. Точка доступа предоставляет пользователю возможность работать с теми сервисами, которые ему предписаны.
7. По окончании сессии, которая может быть прервана либо самим пользователем, либо RADIUS-сервером (например, истек установленный по регламенту, или настроенный промежуток времени работы), RADIUS-сервер делает в журнале запись об окончании сеанса.
Процедура должна строго выполняться и быть реализована логически верно – т.к. относится к управлению доступом.
Команды настройки RADIUS сервера.
Поскольку в качестве операционной системы RADIUS сервера будет использоваться Debian, то приведем команды непосредственной настройки сервера FreeRADIUS для ОС Debian.
1) Инсталляция и настройка FreeRADIUS.
Запуск RADIUS-сервера в режиме отладки:
# radiusd -sfxxyz -l stdout
В версии, поставляющейся в debian, файл называется freeradius (/usr/sbin/freeradius), а запуск в отладочном режиме, согласно официальной документации [1] осуществляется опцией -X, т.е.
Проверка конфигурационного файла FreeRadius-сервера:
2) Конфигурационные файлы FreeRADIUS.
FreeRADIUS использует несколько конфигурационных файлов. У каждого файла есть свой man, который описывает формат файла и примеры конфигураций.
Radiusd.conf – главный конфигурационный файл в котором указываются пути к другим конфигурационным файлам, log файлы, устанавливаются различные параметры контролируемые администратором.
Dictionary – этот файл обычно статический и его не надо изменять. Он определяет все возможные атрибуты RADIUS использующиеся в других конфигурационных файлах.
Clients.conf – в файле содержится описание клиента. Синтаксис записей следующий:
Обязательные атрибуты secret и shortname, опционально можно задать атрибут nastype, который определяет тип клиента (все возможные типы описаны в man clients.conf)
Пример задания клиента:
Hints –Определяет префикс/суффикс для пользовательских имен – атрибут user-name. Используется для отсечения префикса/суффикса в ситуациях когда:
1. Атрибут user-name перед авторизацией/тарификацией нужно избавить от имени домена и т.п., переданного клиентом, таким образом препроцессор трансформирует ‘user@domain.com’ в ‘user’.
2. Необходимо одному и тому же пользователю предоставлять разные сервисы и/или использовать разные схемы авторизации/аутентификации. Тогда для пользователя ‘user’ при входе как ‘user.ppp’ или ‘user.telnet’ можем определить разные схемы авторизации и при входе как ‘user.telnet’ можем добавить проверку вхождения в группу telnet-пользователей.
Huntgroups – позволяет определить разные группы NAS, к сожалению критерий для включения в группу один – IP-адрес NAS (дополнительно можно указывать порт или диапазон портов). При разборе users файла конфигурации позволяет использовать различные схемы авторизации/аутентификации/учета исходя из значения атрибута Huntgroup-Name
ciscogrp NAS-IP-Address == 192.168.10.1
ciscogrp NAS-IP-Address == 192.168.10.2
ciscogrp NAS-IP-Address == 192.168.10.3
apache NAS-IP-Address == 192.168.11.4
hpgroup NAS-IP-Address == 192.168.12.1
hpgroup NAS-IP-Address == 192.168.12.2
3) Настройка атрибутов FreeRADIUS для динамического размещения порта коммутатора в VLAN’е по результатам аутентификации.
Для динамического размещения порта коммутатора в VLANе по результатам аутентификации используются туннельные атрибуты (tunnel attributes):
– Tunnel-Type=VLAN (type 13)
– Tunnel-Medium-Type=802 (type 6)
RADIUS-сервер включает туннельные атрибуты в Access-Accept сообщение.
Это основные атрибуты, которые нужны для динамического размещения порта в VLAN’е по результатам аутентификации. Другие атрибуты RADIUS относящиеся к использованию 802.1x перечислены в RFC 3580.
Значения этих атрибутов для конкретного пользователя указываются в файле users (/etc/freeradius/users):
nata Cleartext-Password := "password"
4) Инсталляция и настройка dialupadmin.
Программа dialupadmin предназначена для администрирования RADIUS-сервера через Web.
В данный момент dialupadmin работает только с PHP4 для PHP5.
Команды настройки на стороне коммутатора Cisco.
1) Базовая настройка 802.1X на коммутаторе Cisco.
Для того чтобы выполнить базовую настройку коммутатора для работы по 802.1X необходимо:
– настроить параметры RADIUS-сервера;
– включить AAA и настроить аутентификацию 802.1X на коммутаторе;
– включить аутентификацию 802.1X глобально на коммутаторе;
– настроить аутентификацию 802.1X на интерфейсах коммутатора;
– (опционально) полезным будет также указать интерфейс коммутатора, адрес которого будет использоваться как адрес отправителя в сообщениях RADIUS-серверу.
Пример базовой настройки 802.1X на портах 1-12 и настройка параметров RADIUS-сервера:
radius-server host 192.168.1.3
radius-server key radiuskey
!Указание интерфейса коммутатора, адрес которого будет использоваться как адрес отправителя в сообщениях RADIUS-серверу:
ip radius source-interface Loopback0
aaa authentication dot1x default group radius
!Включение аутентификации 802.1X на коммутаторе:
!Включение 802.1X на интерфейсах:
interface range FastEthernet0/1 – 12
dot1x port-control auto
2) Настройка параметров RADIUS-сервера.
Если используется аутентификация на RADIUS-сервере, то должны быть настроены адрес (или имя) сервера и пароль использующийся между сервером и аутентификатором:
Switch(config)# radius-server host [host name | IP address] auth-port [port] acct-port [port]
Switch(config)# radius-server key [string]
По умолчанию на коммутаторах Cisco для аутентификации используется порт 1645.
3) Настройка аутентификации 802.1X на коммутаторе.
Switch(config)# aaa new-model
Для аутентификации при доступе к порту коммутатора, необходимо указать методы аутентификации:
Switch(config)# aaa authentication dot1x method1 [method2 . ]
– group — использовать сервер аутентификации;
– enable — использовать пароль привилегированного режима enable;
– krb5 — использовать Kerberos 5 аутентификацию;
– line — использовать пароль line;
– local — использовать локальные имена и пароли;
– none — не выполнять аутентификацию.
4) Включение аутентификации 802.1X на коммутаторе.
Включить аутентификацию 802.1X на коммутаторе:
Switch(config)# dot1x system-auth-control
5) Настройка аутентификации 802.1X на интерфейсах.
Каждый порт коммутатора, на котором должна выполняться аутентификация необходимо настроить следующим образом (порт коммутатора должен быть в режиме access):
Switch(config-if)# dot1x port-control
– orce-authorized — обязательно авторизовать клиента. Аутентификация не обязательна. Используется по умолчанию;
– force-unauthorized — не переводить порт в авторизованное состояние. Это означает, что трафик клиента через этот порт проходить не может;
– auto — использовать 802.1X для перехода из неавторизованного в авторизованное состояние.
При настройке работы RADIUS-сервера, не стоит путать понятия «аутентификация» и «авторизовать». Клиент может быть авторизованным для использования порта, но при этом даже не проходить аутентификацию.
К порту коммутатора, использующему 802.1X, обычно подключается один компьютер. Если к нему подключено несколько компьютеров, необходимо дать для этого порта команду:
Switch(config-if)# dot1x multi-hosts
6) Настройка динамического размещения порта коммутатора в VLAN’е по результатам аутентификации.
Поддержка протокола 802.1X позволяет коммутатору помещать порт в различные VLAN’ы в зависимости от результатов аутентификации клиента. Для этого необходимо:
1. Настроить RADIUS-сервер таким образом чтобы он передавал информацию и о принадлежности пользователя к VLANу (передается VLAN ID или имя VLAN);
2. Настроить пулы адресов на DHCP-сервере;
3. Настроить на коммутаторе авторизацию на RADIUS-сервере для присвоения номера VLAN’а;
4. Настроить на коммутаторе соответствующие VLAN’ы.
Настройка на коммутаторе авторизации на RADIUS-сервере для присвоения номера VLAN’а:
Switch(config)# aaa authorization network default group radius
Коммутаторы Cisco поддерживают следующие виды VLAN’ов:
– пользовательский VLAN — обычный VLAN созданный администратором;
– Guest VLAN — VLAN в который помещаются клиенты не поддерживающие 802.1X. Коммутатор помещает клиента в guest VLAN когда клиент не отправляет пакеты EAPOL или не отвечает на EAPOL Запрос/Identity;
– Restricted VLAN — в этот VLAN помещаются клиенты не прошедшие аутентификацию.
Настройка существующего VLAN’а в качестве guest VLAN’а на интерфейсе:
Switch(config-if)# dot1x guest-vlan
Настройка существующего VLAN’а в качестве restricted VLAN’а на интерфейсе:
Switch(config-if)# dot1x auth-fail vlan
7) Проверка работы 802.1X и RADIUS.
test aaa group username password new-code
| | | следующая лекция ==> | |
| Обоснование выбора стандарта IEEE 802.1Х при проектирование систем распределенной и параллельной обработки данных , обзор стандартов группы (IEEE 802.10, IEEE 802.1Q) | | | Возможности безопасной интероперабельности с режимами работы продуктов системы обработки данных |
Дата добавления: 2018-11-25 ; просмотров: 941 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ
Рассмотрим настройку Radius аутентификации на Cisco устройствах, посредством службы Политики сети и доступа (Network Policy Server) на Windows Server 2012 R2.
Добавление роли, настройка Active Directory
Добавляем роль , переходим в Диспетчер серверов — Управление — Добавить роли и компоненты.
Выбираем роль (Службы политики сети и доступа):
Выбираем службу ролей (Сервер политики сети):
Для завершения установки роли, нажимаем Установить и дожидаемся установки компонента, после чего нажимаем Завершить.
В Active Directory необходимо создать группу безопасности (прим. NPS_Cisco) и включить в нее пользователей кому будет разрешена аутентификации на маршрутизаторах и коммутаторах Cisco.
Настройка Network Policy Server
Открываем оснастку Сервер политики сети (Network Policy Server).
Для полноценного использования функций NPS-сервера в домене, выполним регистрацию его в Active Directory. В оснастке на NPS (Локально), нажимаем правой кнопкой мыши и выбираем Зарегистрировать сервер в Active Directory (Register server in Active Directory):
Подтверждаем регистрацию сервера в Active Directory:
После регистрации NPS в Active Directory, добавим клиента RADIUS. На строке RADIUS-клиенты и серверы (RADIUS Clients and Servers) щелкаем правой кнопкой мыши и выбираем Новый документ (NEW):
Во вкладке «Параметры» вводим Понятное имя (Friendly name), IP-адрес (Address) и Общий секрет (Shared Secret). Во вкладке «Дополнительно» указываем Имя поставщика (Vendor name) — Cisco
Раскрываем ветку Политики (Policies) — Сетевые политики (Network Policies) и щелкаем правой кнопкой мыши и выбираем Новый документ (NEW):
Задаем Имя политики (Policy name), Тип сервера доступа к сети (Type of network access server) оставляем без изменения:
Задаем условия, которые должны соответствовать для успешной аутентификации. Создадим два условия:
- Группы пользователей (указываем ранее созданную в Active Directory группу безопастности)
- Понятное имя клиента (указываем дружественные имена, начинающиеся с префикса CISCO_)
Результат добавления условий:
Указываем разрешение доступа, оставляем значение Доступ разрешен (Access Granted).
Cisco поддерживает только методы Проверка открытым текстом (PAP, SPAP) (Unencrypted authentication (PAP, SPAP)). Снимите все флажки и отмечаем только Проверка открытым текстом (PAP, SPAP):
После настройки методов проверки подлинности вам будет предложено настроить Ограничения (Constraints), пропускаем этот раздел и переходим к следующему шагу.
Настройка параметров (Configure Settings), переходим в Атрибуты RADIUS (RADIUS Attributes) — Стандарт (Standard). Удаляем имеющиеся там атрибуты и нажимаем Добавить… (Add…)
Тип доступа выбираем Service-Type, нажимаем Добавить, выставляем значение атрибута Login 
переходим в Атрибуты RADIUS (RADIUS Attributes) — Зависящие от поставщика (Vendor Specific), добавляем новый атрибут, и нажимаем Добавить… (Add…)
В пункте Поставщик (Vendor), указываем Cisco и нажимаем Добавить… (Add…). Будет предложено добавить сведения об атрибуте, нажимаем Добавить… (Add…) и устанавливаем значение атрибута:
