Способ авторизации eap md5

Защита беспроводных сетей, WPA: теория и практика (часть первая)

Тема безопасности беспроводных сетей по-прежнему остается актуальной, хотя уже достаточно давно существуют надежные (на сегодняшний момент, конечно же) методы защиты этих сетей. Разумеется, речь идет о технологии WPA (Wi-Fi Protected Access).

Большинство существующего на данный момент Wi-Fi оборудования имеет поддержку данной технологии, но, к сожалению, до сих пор в нашей лаборатории попадаются экземпляры, не знающие о WPA. Это более чем странно — заканчивается 2005 год, а некоторые производители до сих пор считают, что технология WEP спасет пользователей беспроводной сети от утечки информации. WEP уже давно устарела. На смену этой технологии пришел WPA, а также на горизонте виднеется новый стандарт 802.11i (некоторые производители преподносят его, как WPA2).

Технология WPA, призванная временно (в ожидании перехода к 802.11i) закрыть бреши WEP, состоит из нескольких компонентов:

• протокол 802.1x — универсальный протокол для аутентификации, авторизации и учета (AAA)
• протокол EAP — расширяемый протокол аутентификации (Extensible Authentication Protocol)
• протокол TKIP — протокол временнОй целостности ключей, другой вариант перевода — протокол целостности ключей во времени (Temporal Key Integrity Protocol)
• MIC — криптографическая проверка целостности пакетов (Message Integrity Code)
• протокол RADIUS

За шифрование данных в WPA отвечает протокол TKIP, который, хотя и использует тот же алгоритм шифрования — RC4 — что и в WEP, но в отличие от последнего, использует динамические ключи (то есть ключи часто меняются). Он применяет более длинный вектор инициализации и использует криптографическую контрольную сумму (MIC) для подтверждения целостности пакетов (последняя является функцией от адреса источника и назначения, а также поля данных).

RADIUS-протокол предназначен для работы в связке с сервером аутентификации, в качестве которого обычно выступает RADIUS-сервер. В этом случае беспроводные точки доступа работают в enterprise-режиме.

Если в сети отсутствует RADIUS-сервер, то роль сервера аутентификации выполняет сама точка доступа — так называемый режим WPA-PSK (pre-shared key, общий ключ). В этом режиме в настройках всех точек доступа заранее прописывается общий ключ. Он же прописывается и на клиентских беспроводных устройствах. Такой метод защиты тоже довольно секьюрен (относительно WEP), очень не удобен с точки зрения управления. PSK-ключ требуется прописывать на всех беспроводных устройствах, пользователи беспроводных устройств его могут видеть. Если потребуется заблокировать доступ какому-то клиенту в сеть, придется заново прописывать новый PSK на всех устройствах сети и так далее. Другими словами, режим WPA-PSK подходит для домашней сети и, возможно, небольшого офиса, но не более того.

В этой серии статей будет рассмотрена работа WPA совместно с внешним RADIUS-сервером. Но прежде чем перейти к ней, немного подробнее остановимся на механизмах работы WPA. А перед этим рассмотрим технологию WPA2.

Технология WPA являлась временной мерой до ввода в эксплуатацию стандарта 802.11i. Часть производителей до официального принятия этого стандарта ввели в обращение технологию WPA2, в которой в той или иной степени используются технологии из 802.11i. Такие как использование протокола CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol), взамен TKIP, в качестве алгоритма шифрования там применяется усовершенствованный стандарт шифрования AES (Advanced Encryption Standard). А для управления и распределения ключей по-прежнему применяется протокол 802.1x.

Как уже было сказано выше, протокол 802.1x может выполнять несколько функций. В данном случае нас интересуют функции аутентификации пользователя и распределение ключей шифрования. Необходимо отметить, что аутентификация происходит «на уровне порта» — то есть пока пользователь не будет аутентифицирован, ему разрешено посылать/принимать пакеты, касающиеся только процесса его аутентификации (учетных данных) и не более того. И только после успешной аутентификации порт устройства (будь то точка доступа или умный коммутатор) будет открыт и пользователь получит доступ к ресурсам сети.

Функции аутентификации возлагаются на протокол EAP, который сам по себе является лишь каркасом для методов аутентификации. Вся прелесть протокола в том, что его очень просто реализовать на аутентификаторе (точке доступа), так как ей не требуется знать никаких специфичных особенностей различных методов аутентификации. Аутентификатор служит лишь передаточным звеном между клиентом и сервером аутентификации. Методов же аутентификации, которых существует довольно много:

• EAP-SIM, EAP-AKA — используются в сетях GSM мобильной связи
• LEAP — пропреоретарный метод от Cisco systems
• EAP-MD5 — простейший метод, аналогичный CHAP (не стойкий)
• EAP-MSCHAP V2 — метод аутентификации на основе логина/пароля пользователя в MS-сетях
• EAP-TLS — аутентификация на основе цифровых сертификатов
• EAP-SecureID — метод на основе однократных паролей

Кроме вышеперечисленных, следует отметить следующие два метода, EAP-TTLS и EAP-PEAP. В отличие от предыдущих, эти два метода перед непосредственной аутентификацией пользователя сначала образуют TLS-туннель между клиентом и сервером аутентификации. А уже внутри этого туннеля осуществляется сама аутентификация, с использованием как стандартного EAP (MD5, TLS), или старых не-EAP методов (PAP, CHAP, MS-CHAP, MS-CHAP v2), последние работают только с EAP-TTLS (PEAP используется только совместно с EAP методами). Предварительное туннелирование повышает безопасность аутентификации, защищая от атак типа «man-in-middle», «session hihacking» или атаки по словарю.

На рис.1 показана структура EAP кадра. Протокол PPP засветился там потому, что изначально EAP планировался к использованию поверх PPP туннелей. Но так как использование этого протокола только для аутентификации по локальной сети — излишняя избыточность, EAP-сообщения упаковываются в «EAP over LAN» (EAPOL) пакеты, которые и используются для обмена информацией между клиентом и аутентификатором (точкой доступа).

Схема аутентификации состоит из трех компонентов:

• Supplicant — софт, запущенный на клиентской машине, пытающейся подключиться к сети
• Authenticator — узел доступа, аутентификатор (беспроводная точка доступа или проводной коммутатор с поддержкой протокола 802.1x)
• Authentication Server — сервер аутентификации (обычно это RADIUS-сервер)

Теперь рассмотрим сам процесс аутентификации. Он состоит из следующих стадий:

1. Клиент может послать запрос на аутентификацию (EAP-start message) в сторону точки доступа
2. Точка доступа (Аутентификатор) в ответ посылает клиенту запрос на идентификацию клиента (EAP-request/identity message). Аутентификатор может послать EAP-request самостоятельно, если увидит, что какой-либо из его портов перешел в активное состояние.
3. Клиент в ответ высылает EAP-response packet с нужными данными, который точка доступа (аутентификатор) перенаправляет в сторону Radius-сервера (сервера аутентификации).
4. Сервер аутентификации посылает аутентификатору (точке доступа) challenge-пакет (запрос информации о подлинности клиента). Аутентификатор пересылает его клиенту.
5. Далее происходит процесс взаимной идентификации сервера и клиента. Количество стадий пересылки пакетов туда-сюда варьируется в зависимости от метода EAP, но для беспроводных сетей приемлема лишь «strong» аутентификация с взаимной аутентификацией клиента и сервера (EAP-TLS, EAP-TTLS, EAP-PEAP) и предварительным шифрованием канала связи.
6. На следующий стадии, сервер аутентификации, получив от клиента необходимую информацию, разрешает (accept) или запрещает (reject) тому доступ, с пересылкой данного сообщения аутентификатору. Аутентификатор (точка доступа) открывает порт для Supplicant-а, если со стороны RADIUS-сервера пришел положительный ответ (Accept).
7. Порт открывается, аутентификатор пересылает клиенту сообщение об успешном завершении процесса, и клиент получает доступ в сеть.
8. После отключения клиента, порт на точке доступа опять переходит в состояние «закрыт».

Описанный процесс проиллюстрирован на рис.3 (там показан один из простейших методов EAP):

Как видно из рисунка, для коммуникации между клиентом (supplicant) и точкой доступа (authenticator) используются пакеты EAPOL. Протокол RADIUS используется для обмена информацией между аутентификатором (точкой доступа) и RADIUS-сервером (сервером аутентификации). При транзитной пересылке информации между клиентом и сервером аутентификации пакеты EAP переупаковываются из одного формата в другой на аутентификаторе.

Детальное рассмотрение алгоритмов шифрования, а также методы генерации сессионных ключей шифрования, пожалуй, выходят за рамки данного материала, поэтому рассмотрю их лишь вкратце.

Первоначальная аутентификация производится на основе общих данных, о которых знают и клиент, и сервер аутентификации (как то логин/пароль, сертификат и т.д.) — на этом этапе генерируется Master Key. Используя Master Key, сервер аутентификации и клиент генерируют Pairwise Master Key (парный мастер ключ), который передается аутентификатору со стороны сервера аутентификации. А уже на основе Pairwise Master Key и генерируются все остальные динамические ключи, которым и закрывается передаваемый трафик. Необходимо отметить, что сам Pairwise Master Key тоже подлежит динамической смене.

Теперь перейдем от сухой теории к реальности, а именно реализации WPA в Windows XP. Нормальная поддержка WPA (с поддержкой AES) появилась, только начиная с windows service pack 2.

В закладке аутентификация доступны методы

• MD5-Challenge — самый примитивный и слабый, рассматривать не будем;
• PEAP (Protected EAP) позволяет производить аутентификацию на основе сертификатов или логина/пароля. Он нам интересен в первую очередь возможностью аутентификации пользователя, используя логин/пароль. При этом нам не требуется настраивать инфраструктуру открытых ключей (PKI). Достаточно подключить RADIUS-сервер к какой-либо базе (обычный файл, mysql, ldap) с хранящимися пользователями и производить аутентификацию пользователей по ней.
• Smart Card or Other Certificate — обычный EAP-TLS. Требует настроенной PKI, использует сертификаты для аутентификации клиентов. Более гибок (разумеется, после настройки PKI), чем аутентификация по логину/паролю. А также является единственным способом получить работающую связку беспроводных пользователей, работающих в Windows-домене.

Во второй части статьи будет рассмотрена настройка Windows-клиентов (Windows XP SP2), RADIUS-сервера (FreeRadius), и PKI на основе OpenSSL. Последние два компонента работают в операционной системе Gentoo Linux.

Источник

Обход 802.1х в LAN

Дисклеймер:

Внимание! Данная статья носит исключительно информационный характер и предназначена для образовательных целей.

Представим себе типичный внутренний пентест. Вы приезжаете к заказчику, подключаетесь к Ethernet-розетке. Вы заранее предупредили о своём приезде, попросили себе рабочее место с Ethernet-розеткой и договорились отключить 802.1x. В итоге нашли тонну критических уязвимостей и в деталях расписали, как всё плохо исправить. Вы выдали красивый отчёт, оценили риски и составили рекомендации. Заказчик смотрит в отчет, хмурит брови и выдает непробиваемый довод: просто я отключил 802.1х. Добились бы вы таких же результатов без доступов к сети?

В этом посте я продемонстрирую, как легко можно обойти 802.1x на внутреннем пентесте. За редкими исключениями, но их мы тоже обсудим.

Оглавление

Матчасть

IEEE 802.1X ― это стандарт, который используется для аутентификации и авторизации пользователей и рабочих станций в сети передачи данных. Он осуществляет контроль доступа и не позволяет неавторизованным устройствам подключаться к локальной сети. Наибольшее распространение протокол получил в беспроводных сетях, однако встречается и в проводных. В данной статье рассматривается его применение для проводных сетей.

Описание протокола 802.1x

Механизм аутентификации

В процессе аутентификации участвую 3 сущности:

Клиент (Client/Supplicant) ― программное обеспечение на стороне клиента, установленное на устройство пользователя и запрашивающее доступ к сети. Для запуска процесса аутентификации клиент использует Extensible Authentication Protocol via LAN (EAPoL)

Аутентификатор (Authenticator) ― устройство, которое обеспечивает связь клиента с сервером аутентификации по протоколу 802.1х и, в случае успешной авторизации ― доступ к сети.

Сервер аутентификации (Authentication Server) ― ААА-сервер, интегрированный с той или иной базой данных пользователей.

Аутентификация клиента происходит в несколько этапов:

На этом этапе клиент подключается к порту аутентификатора. Аутентификатор распознает факт подключения и активизирует логический порт для клиента, сразу переводя его в состояние «неавторизован» (uncontrolled). В результате через клиентский порт возможен лишь обмен трафиком протокола 802.1x, для всего остального трафика порт заблокирован.

Аутентификатор ожидает от клиента запрос на аутентификацию (EAPOL-Start). Когда аутентификатор получает запрос, он посылает клиенту EAP-request/identity. Клиент в ответ высылает EAP-response со своим идентификатором (например, именем пользователя), который аутентификатор перенаправляет в сторону сервера аутентификации, предварительно завернув в RADIUS Access-Request.

Сервер аутентификации и клиент договариваются о методе EAP, по которому будет проходить аутентификация.

Может происходить по-разному, в зависимости от метода EAP. В результате сервер аутентификации разрешает (accept) или запрещает (reject) доступ, с пересылкой данного сообщения аутентификатору. В случае успешной аутентификации аутентификатор переводит порт клиента в состояние «авторизован» (controlled), и начинается передача трафика клиента.

EAP используется для выбора метода аутентификации, передачи ключей и обработки этих ключей подключаемыми модулями, называемыми методами EAP. Рассмотрим самые распространённые методы EAP.

Сервер аутентификации посылает запрос EAP-Request-Identity клиенту.

Клиент в ответ посылает EAP-Response-Identity.

После получения EAP-Response-Identity сервер генерирует случайную строку (challenge string) и отправляет клиенту MD5-Challenge-Request с этой строкой.

Клиент объединяет имя пользователя, пароль в открытом виде и challenge string в одно значение и отправляет хэш MD5 этого значения на сервер аутентификации как MD5-ChallengeResponse

После получения MD5-Challenge-Response сервер аутентификации самостоятельно считает MD5-хэш от данных пользователя и отправленной строки challenge string и сравнивает с хэшом, полученным от клиента. Если хеши совпадают, аутентификация завершается успешно.

У этого метода EAP есть существенный недостаток: как MD5-Challenge-Request, так и MD5-Challenge-Response могут быть перехвачены. В результате можно сбрутить пароль пользователя.

EAP-PEAP/EAP-TTLS

Аутентификация проходит в 2 этапа – внешний и внутренний

1. Внешняя аутентификация:

1.1 Клиент посылает Authentication Request на сервер аутентификации.

1.2. Сервер в ответ посылает свой сертификат

1.3. Клиент проверяет сертификат сервера, и, если всё в порядке, внешняя аутентификация проходит успешно.

1.4. Клиент и сервер устанавливают TLS-соединение.

2. Внутренняя аутентификация через установленный безопасный канал. При этом существует много различных протоколов аутентификации, однако наиболее часто используется MS-CHAPv2.

Основная проблема такого подхода заключается в том, что соединение может быть установлено, даже если сертификат невалиден. Например, если в настройках не стоит галочка «Проверять сертификат сервера».

Отличие этого метода от предыдущего заключается в том, что на внешнем этапе аутентификации происходит проверка подлинности не только сервера, но и клиента. После взаимной проверки подлинности аутентификация проходит по протоколу TLS.

Это куда более безопасно, но сложнее в реализации. На всех клиентских устройствах нужно установить клиентский сертификат.

Основная проблема такого подхода заключается в том, что соединение может быть установлено, даже если сертификат невалиден. Например, если в настройках не стоит галочка «Проверять сертификат сервера».

MAB (MAC Authentication Bypass) – это вариант «аутентификации» для устройств, которые не поддерживают протокол 802.1x. Если к порту коммутатора, на котором настроена аутентификация, требуется подключить такое устройство, то, чтобы не отключать на этом порту аутентификацию, был придуман более слабый механизм. Весь процесс аутентификации по MAB заключается в проверке MAC-адреса устройства.

Атаки

А теперь самое интересное. Расскажу, как мы обходим 802.1X.

Обход MAB

Самый простой метод обхода. MAB вообще как будто был придуман специально для пентестеров. Даже в названии присутствует слово «Bypass».

В общем, находим старенький принтер (камеру, телефон, PDP-11…), узнаём его MAC-адрес и отключаем от коммутатора. Меняем свой MAC на МАС устройства и подключаемся вместо него.

В последнее время метод несколько потерял актуальность за счёт использования профилирования (подробнее в разделе «Как защититься»)

Классическая атака (Bridged-based)

Экскурс в историю

В 2005 году Стив Райли, исследователь из Microsoft, обнаружил уязвимость в протоколе 802.1x, которая приводила к возможности атак «Человек посередине». Суть уязвимости заключалась в том, что аутентификация по протоколу 802.1x происходит только при установке нового соединения. Когда клиент, подключившийся к порту коммутатора, проходит аутентификацию, порт переходит в состояние «controlled» и все последующие соединения от этого клиента не требуют аутентификации. Злоумышленник, разместивший хаб между аутентифицировавшимся клиентом и портом коммутатора, может подключить своё устройство к хабу и отправлять пакеты в сеть, подменив исходные MAC- и IP-адреса на адреса легитимного клиента.

Очевидно, что у такой атаки были проблемы, связанные с состоянием гонки (race condition ― https://en.wikipedia.org/wiki/Race_condition). Если легитимный клиент отвечал быстрее, то нелегитимный терял соединение:

Хост злоумышленника отправляет SYN-пакет в сеть.

В ответ приходит SYN / ACK, который попадает на оба устройства: и хост злоумышленника, и хост клиента.

Клиент отправляет RST / ACK.

Хост злоумышленника отправляет ACK.

Если клиент успел отправить RST/ACK раньше, соединение разрывается. Поэтому в классическом варианте атаки можно было отправлять только UDP-трафик.

Логичным развитием MITM-атаки стало использование моста.

Алгоритм атаки

Нам понадобится ноутбук с двумя интерфейсами и какой-нибудь сотрудник компании (а точнее, его девайс).

Одним интерфейсом подключаемся к девайсу, а другим – к порту коммутатора (розетке на стене). Дальше делаем следующее:

Переводим интерфейсы в Promisc-режим

Поднимаем между ними мост и тоже переводим в Promisc-режим

MAC девайса меняем на MAC коммутатора

Настраиваем SNAT для пакетов, которые отправляем сами – они должны выглядеть так, как будто их отправил девайс.

Добавляется маршрут в сеть за коммутатором через мост

Rogue Gateway Attack

Тот же Evil Twin, только в LAN. Работает в случае, если клиент сконфигурирован так, что соединение может быть установлено даже в случае невалидного сертификата сервера. Например, в настройках не стоит галочка «Проверять сертификат сервера».

Поднимаем мост и начинаем слушать трафик. В результате выясняем параметры клиента и аутентификатора:

Маршрут по умолчанию

Дальше начинается сама атака.

Поднимаем поддельный RADIUS-сервер и выключаем интерфейс, подключенный к аутентификатору.

Затем отправляем на поддельный RADIUS-сервер кадр EAPOL-Start с MAC-адресом клиента. В результате сервер отвечает клиенту запросом EAP-Request-Identity.

Если клиент примет сертификат, то он аутентифицируется у поддельного сервера.

Атакующий прослушивает MS-CHAPv2-challenge и response, сгенерированный на основе NTLM-хэша пароля. [AY1] В случае использования словарного пароля его можно получить перебором по словарю.

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

Атака на EAP-MD5

EAP-MD5 ― это один из самых простых в настройке методов EAP. Он часто используется на периферийных устройствах.

Атака заключается в перехвате MD5-Challenge-Request и MD5-Challenge-Response с последующим брутом MD5-хэша. Для этого, как и в предыдущих атаках, поднимается мост между клиентом и аутентификатором.

Единственная проблема: клиент должен аутентифицироваться после того, как мы начали слушать трафик. Можно просто отключить его от сети и включить заново, однако это заметно и нельзя сделать удалённо (например, если мы оставили Raspberry Pi в офисе, а всю работу хотим сделать из дома). Можно заставить клиента ре-аутентифицироваться, просто отправив «EAPoL-start» аутентификатору от его имени.

Продемонстрируем классическую Bridged-Based атаку с использованием Fenrir.

Стэнд

Радиус-сервер (Cisco-ISE, интегрированная с AD)

На Cisco ISE были использованы следующие политики:

802.1x c EAP-MD5 – для всех подключаемых устройств

802.1x c EAP-TTLS – для всех подключаемых устройств

Доменная машина с Windows

Kali с Fenrir-ом

Описание атаки

Пробуем подключиться к порту свича, сети нет.

Подключаем доменный комп в интерфейс нашей kali, другой интерфейс подключаем к коммутатору.

Запускаем консоль Fenrir и настраиваем параметры моста: указываем MAC- и IP- адреса свича и клиента. Вводим команду create_virtual_tap

Видим, что появился новый интерфейс FENRIR. Прописываем для него IP-адрес.

Вводим команду run в консоли Fenrir и подключаемся к сети. Теперь мы можем сканить nmap-ом и запускать другие полезные тулзы типа crackmapexec.

Ограничения

Нужно как-то пронести устройство на территорию. Более того, воткнуть между коммутатором и авторизованным устройством. Если нет авторизованного устройства, ничего не получится.

Мы получаем доступ аналогичный тому, который имеет авторизовавшееся устройство. То есть если мы воткнемся между принтером и коммутатором, с одной стороны классно – мы сразу попали в сеть… а с другой — мы всего лишь жалкий принтер.

Как защититься?

Для защиты от дурака обхода MAB придумали профилирование. Например, в Cisco ISE есть профили для Windows, для разных моделей принтеров и т.д. Если настроена политика разрешать доступ по MAB-у только принтерам, подмена MAC хакеру уже не поможет. Хорошо настроенное профилирование обойти достаточно сложно, так как злоумышленник не знает ни параметров профилирования (какие метрики собираются для идентификации устройства), ни параметров устройства (точные значения этих метрик).

Что касается защиты от атак на EAP, стоит отказаться от EAP-MD5 либо использовать достаточно сильные пароли. В случае с EAP-TTLS/EAP-PEAP/EAP-TLS/EAP-TTLS нужно принудительно запретить установку соединения, если сертификат сервера невалиден.

Для защиты от MITM-атак могут помочь разные виды детекта аномалий в сети. Если хакер, подключившись к порту, запустит брут или скан, неадекватное поведение хоста можно будет легко обнаружить и заблокировать порт. Однако, чем тише поведёт себя хакер, тем сложнее будет его обнаружить. Детект аномалий ― вещь хорошая, но 100%-ной защиты не даёт. Для 100%-ной защиты от MITM-атак нет ничего лучше, чем сейф шифрование. Например, IPsec.

А ещё есть 802.1xАЕ, также известный как 802.1x-2010, который предусматривает шифрование. Правда, уже после аутентификации.

802.1x AE

Разработан специально для решения проблемы с MITM-атаками и включает протокол MACSec для шифрования трафика на уровне L2.

Соединение проходит в 3 этапа:

Аутентификация и распределение ключей. Предполагается, что аутентификация проходит с использованием одного из методов EAP, однако протокол позволяет также использовать PSK.

Согласование сеансового ключа

Создание безопасной сессии

Рассмотрим пример с EAP-аутентификацией.

Как было описано ранее (см. «Механизм аутентификации), когда клиент впервые подключается к порту коммутатора, аутентификатор отправляет EAPRequest-Identity клиенту. Клиент отвечает EAP-response, который пересылается серверу Аутентификации.

На следующем этапе клиент и сервер аутентификации согласовывают метод EAP, который будет использоваться для аутентификации. Далее клиент аутентифицируется по выбранному методу EAP. В случае успешной аутентификации клиент и аутентификатор устанавливают зашифрованный канал связи по протоколу MACSec.

Как видим, MACSec хорошо работает против классических bridged-based атак: встроить свои пакеты в зашифрованный трафик уже не получится. Однако атаки на слабые методы EAP (Rouge Gateway или атака на EAP-MD5) остаются актуальными.

Выводы

Большинство современных организаций если и внедряют NAC в корпоративной сети, то ограничиваются первой версией протокола 802.1x, которая не предусматривает шифрования канала после аутентификации. Как показано в статье, для злоумышленников не составит труда встроить свой трафик в такой канал (классическая bridged-based атака).

Внедрение шифрования — 802.1AE либо IPSec сопряжено с большими трудностями: как минимум, потребуется установка дополнительных компонентов на каждое клиентское устройство.

Даже при успешном внедрении 802.1AE остаются актуальными атаки, направленные на уязвимости EAP (Rouge Gateway или атака на EAP-MD5).

Идеальная конфигурация, которая на 99,9% защитила бы LAN от обхода авторизации, выглядит примерно так:

Всем устройствам вроде принтеров, телефонов и тп, на которые нельзя поставить клиент для macsec, устанавливается минимальный необходимый доступ.

На всех остальных устройствах используется MAСsec+EAP-TLS (с обязательной проверкой сертификата сервера)

На всех транковых портах (которым коммутаторы соединяются между собой) используется macsec+NEAT (это когда вышестоящий коммутатор авторизует нижестоящий), чтобы минимизировать риск MITM-атаки на межкоммутаторных портах.

Источник