Статья 802.1X. Ритуал безопасности, который все делают, но в который никто не верит

Перед вами не статья, а скорее технический дневник, результат чьих-то многих ночей в лабе, пачек выкуренных сигарет над строками дампа и десятков сломанных конфигов. Сегодня мы говорим о 802.1X. Не так, как о нем говорят на сертификационных курсах. А так, как о нем говорят в курилке усталые админы, которые знают, что их крепость построена на песке. И так, как о нем молча думаем мы, разглядывая логи и пакеты в поисках той одной аномалии, которая откроет путь.

Наша цель не просто перечислить уязвимости CVE. Наша цель - понять философию слабости этой системы. Почему даже безупречно настроенный с точки зрения учебника 802.1X оставляет зазоры? Как эти зазоры становятся щелями, щели - туннелями, а туннели - дорогой прямо в сердце периметра?

Мы будем копать слой за слоем. От физического провода до RADIUS-атрибутов. От состояния порта до психологии администратора. Это путешествие вглубь. Если ты ждешь быстрых ответов и скриптов «нажми-кнопку-получи-лазейку», тебе не сюда. Здесь мы разбираем мотор, чтобы понять, почему он стучит. И как этот стук можно использовать, чтобы заглушить сигнализацию.

Инструменты? Они будут нашими попутчиками. Старые, новые, кастомные. От scapy, который является продолжением наших рук, до специфичных утилит, которые придется собрать из полудохлого кода на Гитхабе. Я не буду давать тебе рыбу. Я научу тебя понимать океан, его течения и то, как рыба думает. А потом мы вместе сделаем динамит.

1/10: Фундамент иллюзии

1.1. Религия Port-Based Access Control

802.1X - это не протокол аутентификации. Это протокол управления состоянием порта на основе аутентификации. Важно уловить разницу с самого начала. Его задача - сказать свитчу: «Этот физический порт сейчас переходит из состояния Х (закрыто/гость) в состояние Y (открыто/доверенно)». Всё. Вся магия - в процессе, который принимает это решение.

Триада акторов священна:

• Supplicant (Проситель): Клиент. Тот, кто хочет доступа. Обычно - ПО на устройстве (wpa_supplicant, Cisco AnyConnect, встроенный клиент Windows).
• Authenticator (Проверяющий): Свитч (или точка доступа). Дверник. Его задача - передать просьбу «просителя» куда следует и, получив ответ, открыть или не открыть дверь.
• Authentication Server (Сервер аутентификации): Обычно RADIUS-сервер (FreeRADIUS, Cisco ISE, Microsoft NPS). Тот, кто принимает решение. Царь и бог.

Между Supplicant и Authenticator течет EAP over LAN (EAPOL). Между Authenticator и Authentication Server - EAP over RADIUS (EAP-пакеты, упакованные в атрибуты RADIUS).

Идеально. Красиво. Абстрактно.

1.2. Первая трещина: Что такое «состояние порта» на самом деле?

Свитч - глупая железка. Он оперирует не абстракциями, а таблицами: MAC-адресная таблица (CAM), таблица ACL, таблица VLAN (VLAN membership). Когда порт в состоянии 802.1X unauthorized, он физически НЕ ЗАКРЫТ. Он фильтрует трафик на основе EtherType. Разрешены только кадры с 0x888E (EAPOL). Всё.

А теперь вопросы, которые задают только на практике:

1. А что с широковещательными (ff:ff:ff:ff:ff:ff) кадрами? ARP-запросы? STP BPDU? CDP/LLDP? Теоретически, стандарт говорит «только EAPOL». На практике, многие свитчи всегда пропускают BPDU и служебные протоколы канального уровня, иначе сломается STP, и вся сеть встанет. Это бэкдор. Если я отправлю кадр, похожий на BPDU, но с внедренными данными? Это сложно, но не невозможно. Проверял на старых ProCurve - некоторые пропускали кастомные LLC-кадры.
2. А что происходит в момент перехода состояния? Порту дана команда перейти из unauthorized в authorized. Свитч применяет к порту новый VLAN, снимает фильтрацию. Это атомарная операция? Или есть микросекунда, когда порт уже в новом VLAN, но старые ACL еще не применились? Или наоборот? Время - союзник атакующего.
3. «Авторизованный порт» - значит ли это, что авторизован только Supplicant? Или весь поток данных? Стандарт подразумевает контроль на уровне порта. Но данные идут не от порта, а от MAC-адреса. И здесь начинается магия (и ужас) проверки источника (Source Check).

1.3. Source Check - Страж, который часто спит

Идея: на авторизованном порту свитч должен пропускать фреймы только с MAC-адреса авторизованного Supplicant. Звучит здорово. Включается командой типа dot1x host-mode single-host или аналогичной.

Реализация:

• Вариант А (Строгий): Свитч жестко привязывает авторизованный MAC к порту. Все фреймы с других MAC-адресов отбрасываются. Это то, что нам продают.
• Вариант Б (Ленивый): Свитч запоминает первый авторизованный MAC и затем… забывает о проверке. Или проверяет только в момент обучения (попадания MAC в CAM-таблицу). Что, если я отправлю фрейм с поддельным source MAC до того, как легитимный клиент начнет слать данные? Я «займу» слот в его таблице. Что будет? Зависит от реализации: может, конфликт, может, свитч начнет перенаправлять трафик на мой порт. Это классическая атака на CAM-таблицу, но в контексте 802.1X она приобретает новые оттенки.
• Вариант В (Отсутствующий): Source Check выключен ради совместимости (например, для того же IP-телефона с пасс-слотом). Порт становится обычным портом доступа. Любой MAC проходит.

Инструментальная разведка: Как понять, что творится?
Мы не гадаем. Мы смотрим.

1. Подключаем два устройства к одному порту через дешевый немой хаб (или используем сетевое T-образное ответвление, если позволяют деньги и риск).
2. Устройство 1 - легитимный клиент, проходит 802.1X.
3. Устройство 2 - наш ноутбук в режиме монитора.
4. На легитимном клиенте запускаем непрерывный ping до шлюза.
5. С нашего ноутбука начинаем отправлять кадры с разными MAC-адресами (используя macchanger или scapy) и ловим отклики. Если пинг прерывается при отправке кадров с определенным MAC - значит, Source Check работает и реагирует на «чужие» MAC конфликтом или сбросом состояния порта. Если пинг идет, а наши «левые» кадры уходят в сеть - Source Check отключен или работает некорректно.
   
   

   # Пример быстрой проверки с hping3 (этот кадр НЕ EAPOL, это ARP)
   sudo hping3 -1 -a 11:22:33:44:55:66 -s 67 -d 54 -p 68 192.168.1.1 -c 5 -i u100000
   # Смотрим, прервется ли ping легитимного клиента.

Вывод Главы 1: Сама базовая механика - контроль состояния порта - уже несет в себе семена проблем: неполная фильтрация до аутентификации, размытость момента перехода и ненадежность контроля источника. Мы еще даже не добрались до EAP, а уже имеем три вектора для изучения.

2/10: EAPOL - Язык ангелов и демонов

2.1. Структура фрейма: не просто 0x888E

EAPOL-фрейм - это не только EAPOL-Start или EAP-Packet. Это несколько типов, и каждый - потенциальный инструмент влияния.

• EAPOL-Start (0x01): Инициация. Supplicant -> Authenticator. «Эй, давай начнем».
• EAPOL-Logoff (0x02): Supplicant -> Authenticator. «Я выхожу». Критически важный тип.
• EAPOL-Key (0x03): Для WPA/WPA2. В проводном 802.1X используется редко, но его наличие может смутить свитч.
• EAPOL-Encapsulated-ASF-Alert (0x04): Пережиток для мониторинга. Почти не используется, но кто его знает...
• EAPOL-Packet (0x00): Самый частый. Внутри него живет собственно EAP-диалог.

Уязвимость 2.1.A: Инжекция EAPOL-Logoff - классика, но с вариациями.
Мы все знаем про атаку отравления сессии. Но давай разберем нюансы:

• Timing Attack: Отправка одного Logoff'а - это DoS на несколько секунд. Но что, если отправить его сразу после получения клиентом EAP-Success? В этот момент клиент считает себя авторизованным, свитч тоже. Logoff может вызвать не просто деаутентификацию, а перевести порт в состояние held (блокировки) из-за подозрения в коллизии, если такая логика заложена.
• Spoofing with VLAN Tag: А если отправить EAPOL-Logoff с 802.1Q VLAN tag? Некоторые свитчи в multi-VLAN окружении могут обрабатывать тегированные кадры на не тегированном порту неожиданным образом. Можно ли заставить свитч «сбросить» авторизацию для конкретного VLAN? Экспериментальный вектор.
• Циклическая бомбардировка: Скрипт, который слушает EAPOL-трафик, находит успешную аутентификацию (пакет EAP-Success) и мгновенно в ответ шлет EAPOL-Logoff. Это превращает порт в «мерцающий»: авторизация -> мгновенный Logoff -> повторная попытка клиента -> авторизация -> Logoff. Сеть для жертвы становится непригодной. Защита? dot1x timeout quiet-period не помогает, так как Logoff - это легитимный пакет, он не вызывает периодов тишины. Нужны механизмы вроде dot1x violation или security violation, которые отслеживают MAC-флуд или подозрительные EAPOL-фреймы.
  
  

  # Пример продвинутого сниффера/инжектора на scapy (концепт)
  from scapy.all import *
  import time
  
  def packet_callback(pkt):
      if pkt.haslayer(EAPOL):
          # Ищем EAP-Success (код 3 в EAP-слое внутри EAPOL-Packet)
          if pkt[EAPOL].type == 0:  # EAPOL-Packet
              if pkt[EAP].code == 3:  # EAP-Success
                  print(f"[!] Detected EAP-Success for MAC: {pkt.src}")
                  # Конструируем Logoff от имени этого MAC
                  logoff_pkt = Ether(src=pkt.src, dst=pkt.dst)/EAPOL(version=pkt[EAPOL].version, type=2) # type=2 = Logoff
                  # Отправляем 5 раз подряд для надежности
                  for _ in range(5):
                      sendp(logoff_pkt, iface="eth0", verbose=False)
                      time.sleep(0.01)
                  print(f"[+] Injected EAPOL-Logoff for {pkt.src}")
  
  sniff(iface="eth0", prn=packet_callback, filter="ether proto 0x888e", store=0)

2.2. Манипуляции с EAPOL-Start и Identity Request/Response

Стандартный диалог: Supplicant шлет Start, Authenticator отвечает EAP-Request/Identity. Supplicant шлет
EAP-Response/Identity (логин, часто в виде user@domain или просто хостнейм).

Что если:

• Подавить Start со стороны клиента? Некоторые клиенты (особенно встроенные в IoT) не инициируют Start, ждут запроса от свитча. Если свитч настроен агрессивно (dot1x port-control auto), он сам будет периодически слать EAP-Request/Identity. Мы можем, находясь на том же порту (через хаб), отправлять EAP-Response/Identity раньше легитимного клиента, подставляя левый идентификатор. Сработает ли? Если свитч ведет диалог только с одним Supplicant за раз - возможно, мы «застолбим» порт, и легитимный клиент получит таймаут. Опять DoS, но уже на уровне протокола.
• Перехватить и модифицировать Identity Response? В теории, если мы на пути (MitM), мы можем изменить идентификатор, который идет на RADIUS. Например, подставить идентификатор привилегированной учетной записи службы. Но RADIUS тогда потребует пароль, которого у нас нет. Однако, если используется EAP-TLS с сертификатами, и мы можем подменить identity, чтобы указать на другое устройство, для которого у нас есть сертификат? Это уже серьезно.

2.3. Пассивное наблюдение за EAPOL - Утечка информации

EAPOL-фреймы летают в открытом виде. Что они выдают?

• MAC-адрес Supplicant (источник EAPOL-Start).
• Идентификатор пользователя/устройства (в EAP-Response/Identity). Часто это COMPUTERNAME$ для машинных учеток или user@domain.lan. Это золото для разведки. Зная шаблоны именования, можно понять структуру сети, имена критических серверов (SRV-AD$, SRV-SQL$).
• Тип используемого EAP-метода. Клиент в Identity Response может сразу указать, какие методы он поддерживает (описано в RFC). Это говорит о типе ОС и ее конфигурации.

Контрмеры (глазами защитника):

• Включить dot1x reauthentication с небольшим интервалом. Это не остановит атаку, но ускорит восстановление.
• Настроить storm-control на уровне broadcast/multicast и dot1x max-req (лимит попыток запроса идентичности). Это усложнит бомбардировку.
• Рассмотреть MACsec (802.1AE) для шифрования всего трафика, включая EAPOL, между клиентом и свитчом. Это тяжело, дорого, но это единственный способ полностью скрыть EAPOL-диалог от прослушки в пределах провода.

3/10: Танцы с RADIUS - Аутентификатор как марионетка

3.1. RADIUS как слабое звено

Authenticator слепо доверяет RADIUS-серверу. Его логика: «Если RADIUS сказал Accept - открываю. Reject или нет ответа - не открываю». Значит, цель атакующего - повлиять на это решение.

3.2. Поддельный RADIUS-сервер (Rogue RADIUS)

Сценарий: мы убедили свитч, что наш сервер - это легитимный RADIUS. Как?

• Смена IP-адреса RADIUS на свитче: Требует доступа к управлению. Не наш метод.
• Атака на протокол разрешения адресов: Если свитч находит RADIUS по имени (например, radius1.corp.local), можно попробовать отравить кэш DNS или NetBIOS. В современных сетях сложно.
• Использование легального IP, но своего сервера (ARP Spoofing): Если мы в том же VLAN, что и RADIUS-сервер, можно попробовать ARP-spoofing, чтобы перехватить трафик на порт 1812. Но RADIUS использует общий секрет (shared secret) для подписи пакетов. Не зная его, мы не сможем сформировать корректный ответ Access-Accept. Однако, мы можем вызвать Access-Reject или просто глушить запросы, вызывая server-timeout и активируя fallback (если он есть).

3.3. Атака на общий секрет (Shared Secret)

Shared secret - это симметричный ключ между свитчом и RADIUS. Хранится в конфиге свитча. Если мы его получим (через уязвимость, бэкап, инсайдера), мы можем:

• Создать свой Rogue RADIUS, который будет принимать любые запросы и отвечать Access-Accept на любые логины.
• Расшифровать пароли в некоторых старых методах аутентификации (например, если используется PAP внутри EAP, что является преступлением, но встречается в устаревших системах SCADA).
  Получить секрет сложно. Но не невозможно. Часто он один для всех свитчей в группе, редко меняется и может быть простым по политике сложности.

3.4. Манипуляция с RADIUS-атрибутами - Искусство обмана

Когда RADIUS шлет Access-Accept, он может включать атрибуты, которые говорят свитчу, что делать дальше:

• Tunnel-Private-Group-ID (атрибут 81): Чаще всего - VLAN ID в виде строки (например, "101").
• Filter-ID (атрибут 11): Имя ACL, который нужно применить к порту.
• Session-Timeout (атрибут 27): Через сколько секунд инициировать повторную аутентификацию.

Уязвимость 3.4.A: VLAN Hopping через подмену атрибутов (если мы MitM).
Предположим, мы находимся на пути между Authenticator и легальным RADIUS (маловероятно, но возможно в плохо сегментированной сети управления). Мы видим Access-Accept для пользователя из отдела продаж с атрибутом Tunnel-Private-Group-ID = "200" (VLAN 200). Мы на лету меняем его на "10" (VLAN 10, админская сеть). Свитч, получив модифицированный пакет, поместит пользователя в VLAN 10. Это Holy Grail проводных сетей. Защита: IPsec между свитчами и RADIUS-серверами или использование защищенных протоколов типа RadSec (RADIUS over TLS).

3.5. Атаки на доступность RADIUS - Активация Fallback

Это одна из самых практичных атак. Цель - не взломать, а отключить механизм 802.1X, заставив сеть перейти в запасной режим.

• DoS на RADIUS-сервер: Любыми средствами. SYN-флуд на порт 1812, атака на уязвимость в службе, исчерпание пула потоков.
• DoS на путь к RADIUS: Если у свитча несколько RADIUS-серверов, можно попытаться отключить каналы связи до них (например, атакой на маршрутизатор).

При срабатывании fail open порты уходят в auth-fail-vlan. Наша задача - исследовать этот VLAN. Он часто бывает плохо изолирован. Наша тактика: вызвать отказ, затем подключиться. Инструменты: классические сетевые сканеры (nmap), но с фокусом на поиск сервисов управления, стыков с основной сетью.

Если ты хочешь понять, как атакующий может развернуть ложный сервер и манипулировать сетевой аутентификацией, стоит посмотреть практический разбор инструментов Rogue Toolkit для развёртывания злых точек доступа.

4/10: Эшелоны обхода - MAB, Web Auth и другие удобства

4.1. MAC Authentication Bypass (MAB) - Дверь для ленивых

MAB - это костыль. Прекрасный, удобный, но костыль. Логика: если устройство не отвечает на EAP-запросы, считать его MAC-адрес логином и паролем, отправить это на RADIUS.

Уязвимость 4.1.A: Подделка MAC-адреса.
Тривиально. ifconfig eth0 hw ether 00:11:22:33:44:55. Если этот MAC есть в базе RADIUS (как раз для того принтера), мы получаем его доступ. Админы часто заносят в список MAC-адреса критических устройств: точки доступа, IP-камеры, контроллеры. Получив доступ от их имени, мы часто оказываемся в отдельном, менее защищенном VLAN для IoT-устройств, откуда могут быть мосты в другие сегменты.

Уязвимость 4.1.B: Угадывание MAC-адресов (MAC Spoofing Brute Force).
OUI (первая половина MAC) известна для вендоров. Вторая половина - часто последовательна. Можно написать скрипт, который будет циклически менять MAC и пытаться получить IP (через DHCP). Если получил - значит, MAB сработал. Скрипт для scapy будет громоздким, но идея проста: в цикле while менять MAC, отправлять DHCP Discover и слушать Offer.

# Концепт скрипта brute force MAB (требует доработок, запуск в изолированной среде!)
from scapy.all import *
import random

base_mac = "00:50:56"  # Пример OUI VMware (часто в тестовых средах)
iface = "eth0"

def gen_mac():
    return base_mac + ":{:02x}:{:02x}:{:02x}".format(random.randint(0,255), random.randint(0,255), random.randint(0,255))

for i in range(1000):
    new_mac = gen_mac()
    print(f"[*] Trying MAC: {new_mac}")
    # 1. Меняем MAC системы (требует прав)
    # os.system(f"sudo ifconfig {iface} down")
    # os.system(f"sudo ifconfig {iface} hw ether {new_mac}")
    # os.system(f"sudo ifconfig {iface} up")
    # time.sleep(1)
    # 2. Отправляем DHCP Discover (это уже трафик данных, но если MAB работает, порт откроется)
    dhcp_discover = Ether(src=new_mac, dst="ff:ff:ff:ff:ff:ff")/IP(src="0.0.0.0",dst="255.255.255.255")/UDP(sport=68,dport=67)/BOOTP(chaddr=[mac2str(new_mac)])/DHCP(options=[("message-type","discover"),"end"])
    sendp(dhcp_discover, iface=iface, verbose=False)
    # 3. Слушаем ответы (упрощенно)
    # ... (sniff на DHCP Offer)

4.2. Web Authentication (Web Auth) - Портал захвата

Часто используется для гостей. Устройство подключается, попадает в изолированную VLAN, и все HTTP-запросы перенаправляются на портал ввода логина/пароля.

Уязвимость 4.2.A: Обход портала через не-HTTP трафик.
А что, если портал проверяет только HTTP? Можно попробовать:

• HTTPS: Если он не перехватывается, может вести напрямую наружу.
• DNS-туннелирование: Через DNS-запросы, если DNS-сервер в этой VLAN разрешает внешние запросы.
• Использование других разрешенных протоколов: Например, VPN (IPsec, OpenVPN) на нестандартных портах.
  Инструмент: proxychains + nmap для сканирования разрешенных портов и протоколов изнутри VLAN.

4.3. Multi-Domain/Multi-Auth - Хаос как норма

Режим, когда на одном порту аутентифицируются отдельно устройство (например, телефон) и отдельно пользователь (компьютер за телефоном). Создает сложную машину состояний.

Уязвимость 4.3.A: Атака на доверие между доменами.

Часто Data VLAN (для компьютера) имеет доступ к Voice VLAN (для телефона) для управления. Если мы проникли в Data VLAN через компьютер, можем атаковать телефон, который находится в Voice VLAN. Уязвимости в веб-интерфейсе телефона, слабые пароли, устаревшее ПО. Телефон становится точкой входа в голосовой сегмент, который часто имеет свои, особые пути в инфраструктуру.

5/10: Глубже в кроличью нору - Атаки на EAP-методы

5.1. EAP-PEAP/MSCHAPv2 - Фасад, который трещит

Мы уже говорили об Evil Twin. Углубимся.

• Стадия 1: Захват handshake. Нам нужно получить challenge-response пары MSCHAPv2. Их дают hostapd-wpe или EAPHammer.
• Стадия 2: Оффлайн брут.
  
  

  # Используем asleap с словарем
  asleap -C <challenge> -R <response> -W /path/to/wordlist.txt
  # Или John the Ripper с форматированием
  echo "username:$NETNTLM$challenge$response" > hash.txt
  john --format=netntlm hash.txt

  
  
• Стадия 3: Relay-атака (EAP-Relay). Сложнее. Нужен инструмент, который действует как прокси. eaprelay.py (редкий скрипт) или настройка FreeRADIUS в режиме прокси с подменой. Идея: наш сервер одновременно является Authenticator для жертвы и Supplicant для настоящего RADIUS. Получив challenge от настоящего RADIUS, мы передаем его жертве, получаем response и отправляем обратно. Требует точного соблюдения таймингов.

5.2. EAP-TTLS/PAP - Позор, который еще жив

EAP-TTLS может использовать внутри себя PAP, который передает пароль в открытом виде внутри TLS-туннеля. Если мы смогли встать MitM и установить свой TLS (с самоподписанным сертификатом), мы получаем пароль в чистом тексте. Это золотая жила для устаревших сетей Wi-Fi, но иногда встречается и в проводных для специфичного оборудования.

5.3. EAP-FAST - Сложный, но не безупречный

Разработан Cisco как замена LEAP. Использует Protected Access Credential (PAC). Атаки сложны, но были (например, связанные с угадыванием или перебором PAC-файлов). Требуют глубокого изучения и в основном актуальны для беспроводных сетей.

5.4. EAP-TLS - Король, которого можно обойти?

Сертификаты. Проверка клиента. Кажется, неуязвимо. Но:

• Кража сертификата с клиента. Если у нас есть доступ к машине (физический или через вредонос), мы можем вытащить сертификат и приватный ключ (часто защищенные паролем, который можно сбрутить или извлечь из памяти).
• Слабости в реализации TLS. Устаревшие версии библиотек, поддержка слабых шифров. Можно попытаться downgrade-атаку, если и клиент, и сервер поддерживают старый TLS 1.0 с экспортными шифрами.
• Подделка цепочки доверия. Если клиент настроен доверять внутреннему CA, а мы скомпрометировали этот CA или можем добавить свой сертификат в хранилище доверенных корневых сертификатов клиента (через групповую политику или фишинг), мы снова можем стать MitM.

Для примера практических техник обхода IEEE аутентификации смотри материал о пяти способах получения доступа к защищённой беспроводной сети, где описываются методы имитации IEEE 802.1X Authenticator и Authentication Server с помощью hostapd‑wpe и Evil Twin‑инструментов.

6/10: Пост-аутентификация - Жизнь внутри порта

6.1. VLAN Hopping - классика жанра

Даже будучи корректно помещенным в свой VLAN, можно попытаться выпрыгнуть.

• Double Tagging: Если порт настроен как switchport mode access (а так и должно быть для 802.1X), эта атака не работает. Но если по ошибке порт в режиме trunk или dynamic auto, и есть native VLAN, отличная от назначенной - возможно.
• Перехват и подмена DHCP-ответов с указанием другого шлюза или опции 82 (Circuit ID), которая может влиять на назначение VLAN на некоторых свитчах.

6.2. Атаки на соседние устройства в том же VLAN

Оказавшись в VLAN, мы среди «доверенных» устройств. Запускаем сканирование ARP (arp-scan), ищем уязвимые устройства: принтеры с веб-интерфейсом на 80 порту, IP-камеры, СХД. Часто их пароли - по умолчанию.

6.3. Эксплуатация доверия к Domain Join

Компьютер в корпоративной сети, скорее всего, в домене. У него есть машинная учетная запись. Можно попробовать атаки Kerberos (например, серебряные/золотые билеты), если у нас есть достаточные привилегии на самой машине (полученные через эксплойт). Это уже пост-эксплуатация, но корни ее - в первоначальном доступе через сеть.

7/10: Инструментарий алхимика - От скриптов до железа

7.1. Аппаратные ключи для тестов

• Yersinia: Старый, но грозный фреймворк для атак на Layer 2. Умеет генерировать специфичные EAPOL-фреймы (в том числе Logoff). Запуск: yersinia -G (графический режим).
• Ethercap (устарел, но): Мог манипулировать EAPOL.
• Самопальный свитч на Linux: Используя macvlan, bridge-utils и hostapd, можно сделать софтовый свитч, который ведет себя как Authenticator, но полностью под нашим контролем. Это для глубокого понимания процесса.

7.2. Скрипты и фреймворки Python

• Scapy - это всё. Напишем свой небольшой EAP-клиент и сервер.
  
  

  # Пример: Прослушка и печать EAP-Identity
  from scapy.all import *
  def eap_sniff(p):
      if p.haslayer(EAP):
          if p[EAP].code == 2: # Response
              if p[EAP].type == 1: # Identity
                  print(f"Identity: {p[EAP].identity}")
  sniff(prn=eap_sniff, filter="ether proto 0x888e", store=0)

  
  
• Импровизированный Rogue Authenticator на Scapy: Нужно реализовать простой state machine: слушать EAPOL-Start, отвечать EAP-Request/Identity, принимать ответ, предлагать выбранный EAP-метод, вести диалог. Это сотни строк кода, но это возможно.

7.3. RADIUS-инструменты

• FreeRADIUS: Не только сервер. Его утилиты radclient и radeapclient позволяют отправлять тестовые запросы, полезно для фаззинга.
  
  

  # Отправка Access-Request с файлом атрибутов
  echo "User-Name=test, User-Password=123" > request.txt
  radclient -f request.txt localhost:1812 auth secret

8/10: Защита с позиции параноика - Если бы ты был админом...

8.1. Жесткая настройка порта

• switchport mode access (абсолютно).
• switchport voice vlan X (только если нужно).
• authentication host-mode multi-domain или multi-auth - только при необходимости, с пониманием рисков.
• authentication port-control auto (строгий режим).
• dot1x pae authenticator
• dot1x timeout quiet-period 1 (минимум).
• dot1x timeout server-timeout 5 (небольшой).
• dot1x max-req 2 (мало попыток).
• dot1x guest-vlan, dot1x auth-fail vlan. Лучше authentication event fail action deny (закрывать порт).
• spanning-tree portfast + spanning-tree bpduguard enable (для быстрого перехода и защиты от BPDU).

8.2. Бдительность на RADIUS

• Разные Shared Secrets для групп устройств.
• Использование RadSec (RADIUS over TLS) между свитчами и серверами.
• Логирование всех событий (особенно Access-Reject и Accounting). Анализ с помощью SIEM.
• Сертификаты. Только EAP-TLS для пользователей. Сертификаты клиентов, выданные внутренним CA.
• Проверка сертификата клиента обязательна. Отключение всех слабых EAP-методов.

8.3. Сетевая сегментация

• Выделенный VLAN для управления свитчами.
• Отдельный VLAN для RADIUS-серверов.
• Микросегментация внутри пользовательских VLAN (например, с помощью Private VLAN).
• ACL между VLAN, особенно ограничивающие доступ из пользовательских VLAN к управлению и инфраструктуре.

8.4. Мониторинг и реагирование

• Алерты на множественные EAPOL-Logoff с одного порта.
• Алерты на частые смены состояния порта (authorized/unauthorized).
• Алерты на попытки аутентификации с MAC, который ранее был в другом VLAN.
• Алерты на использование неразрешенных EAP-методов.
• Network Detection and Response (NDR): Системы вроде ExtraHop, Darktrace, которые изучают нормальное поведение протоколов и ловят аномалии в EAPOL-диалогах.

(Глава 9/10: Практикум - От теории к лабе)

Здесь будет пошаговая инструкция по построению тестового стенда в Eve-NG/Proxmox.

1. Железо: 1 коммутатор (образ Cisco IOL), 1 сервер (VM для FreeRADIUS на Ubuntu), 2 клиента (Windows 10, Kali Linux).
2. Базовая конфигурация свитча (приведена выше).
3. Настройка FreeRADIUS: Установка, настройка clients.conf (свитч как клиент), настройка mods-enabled/eap (включаем только
   eap-tls и eap-peap для тестов), настройка пользователей в mods-enabled/files.
4. Генерация сертификатов для EAP-TLS с помощью easy-rsa.
5. Настройка клиента Windows для 802.1X (через ncpa.cpl -> свойства адаптера -> вкладка Безопасность).
6. Запуск атак:
   • Из Kali, подключенной к тому же порту через хаб: сниффинг EAPOL, инжекция Logoff.
   • Создание Rogue Authenticator на отдельной VM.
   • Подмена MAC и тест MAB.
7. Анализ логов на FreeRADIUS и свитче.

10/10: Философия щели

Послушай. Давай начистоту. Если ты дочитал до этого места, продираясь сквозь дебри состояний портов, лес EAP-методов и болота RADIUS-атрибутов, ты уже не тот, кто зашел в эту тему с первой страницы. Ты видел изнанку. И теперь нам нужно поговорить о самом важном: не о том, как это ломается, а о том, почему это ломается всегда. О метафизике уязвимостей.

802.1X - не просто протокол. Это памятник человеческой наивности. Прекрасный, почти поэтичный пример того, как благородное стремление к абсолютной безопасности неминуемо рождает чудовищную сложность. А сложность, как ржавчина, точит любую конструкцию изнутри, создавая пустоты, трещины и те самые щели, в которые мы с тобой сегодня заглядывали. Это не баги в коде, не опечатки в черновике RFC 3748. Это что-то глубже. Это системные, концептуальные, экзистенциальные уязвимости.

Они живут не в строках конфигурации, а в пространстве между Намерением и Реальностью.

• Намерение: Абсолютный контроль. Ни один бит не просочится в сеть без полного и безоговорочного одобрения Царя-Сервера.
• Реальность: Свитч, который в пятницу в 18:01 должен пропустить бухгалтера Марию Ивановну, потому что у нее «горит отчёт», а её ноутбук почему-то не принимает сертификат. И вот уже в конфиге появляется auth-fail-vlan guest, правило dot1x timeout max-req 10, а где-то в RADIUS заводится статическая запись для MAC-адреса принтера в коридоре, потому что «он старый и не умеет в эту вашу аутентификацию».

Уязвимости плодятся в щелях между Теорией и Практикой.

• Теория: Один порт - один клиент - одна аутентификация. Чисто, стерильно, математически безупречно.
• Практика: IP-телефон, за ним - компьютер пользователя, а в соседнюю розетку - ноутбук совместителя из подрядной организации. Рождаются режимы multi-auth, multi-domain, voice vlan, data vlan, MAB для гостей и WebAuth для курьеров. Каждое исключение это новая машина состояний. Каждая новая машина состояний - новый непроверенный переход, новый таймаут, новое условие if-else в прошивке свитча, которое написал уставший инженер в два часа ночи перед релизом.

Они процветают благодаря двум силам: Слепому Доверию и Человеческой Усталости.

• Доверие: Доверие к сертификату из определённого CA. Доверие к тому, что RADIUS-сервер отвечает всегда и только правду. Доверие к тому, что фрейм с EtherType 0x888E - это настоящий EAPOL, а не наша подделка. Доверие к тому, что MAC-адрес в кадре это реальный адрес сетевой карты, а не результат работы macchanger. Вся эта пирамида построена на предположении, что все участники следуют правилам. Хакерское мышление начинается с вопроса: «А что, если нет?»
• Усталость: Усталость админа, который конфигурирует сотой по счёту коммутатор по типовой табличке из Excel. Усталость архитектора, который просто хочет, чтобы «всё работало», и включает fail open, потому что звонки от разгневанных пользователей при недоступности сети страшнее абстрактной угрозы проникновения. Усталость от сложности, которая заставляет выбирать PEAP вместо EAP-TLS, потому что возиться с PKI «ой, ну нафиг». Эта усталость - самый плодородный грунт для наших изысканий.

Понимаешь теперь? Наша работа никогда не заключалась в том, чтобы ткнуть пальцем и сказать: «Смотрите, это дерьмо! Не используйте!». Любая система безопасности, от навесного замка на сарае до гомоморфного шифрования в квантовом облаке, это компромисс. Компромисс между безопасностью, стоимостью, удобством и производительностью. Сказать «это дерьмо» это детский сад. Это уровень пафосного комментария на YouTube.

Настоящая работа - понять этот компромисс глубже, чем его понимают создатели и админы. Понять не только что они пожертвовали, но и как именно эта жертва деформировала систему. Где математическая чистота стандарта упирается в аналоговую грязь реального мира: в криво написанную проверку состояний в прошивке, в баг в библиотеке TLS, в то, как парсится поле identity в RADIUS-пакете. Нужно почувствовать систему на вкус, узнать её запах, понять её ритмы и сбои. Стать, на время, частью этой системы, чтобы увидеть мир её глазами. И тогда, только тогда ты увидишь те самые щели. Не как ошибки, а как неизбежные последствия.

Это попытка нарисовать карту. Не туристическую карту с яркими фотографиями, а старую, потрёпанную карту мореплавателя, с пометками на полях, сделанными кровью и сажей. Вот здесь, у мыса EAPOL-Logoff, водятся сирены, чьи песни разбивают сессии о скалы. Здесь, в болотах MAB, туман скрывает топи, затягивающие целые VLAN. А вот этот узкий, никому не известный проход между скал Multi-Domain State Machine ведёт прямиком в лагуну с сокровищами - в Voice VLAN. На карте нет гарантий. Есть только наблюдения: «здесь дракон», «здесь топь», «здесь, судя по всему, проход, о котором забыли даже картографы».

Процесс изучения: копаться в RFC, разбирать дампы в Wireshark, дизассемблировать прошивки.
Процесс тестирования: строить стенды, ломать их вдребезги, наблюдать, как они разваливаются, записывать каждый треск.
Процесс укрепления: не для того, чтобы построить стену (стены падают), а для того, чтобы создать систему, которая умеет падать правильно с наименьшими потерями, с громкой сигнализацией, с возможностью понять, что именно сломалось и как.
И снова - процесс изучения. Круг. Бесконечный.

Админ, который, прочитав это, вздохнёт, закроет браузер и пойдёт пересматривать конфиги своих свитчей, внося правки с новым, параноидальным пониманием - наш брат. Он не враг. Он такой же узник этой системы, как и мы. Его задача поддерживать её работу. Наша (в легальном, этичном поле) - показывать ему, где она даёт сбой. Мы тестеры на прочность. Саперы, ищущие мины на пути.

Пентестер, который использует эти идеи в рамках легального задания, чтобы написать в отчёте не шаблонное «проверил 802.1X - настроен», а конкретное: «обнаружена возможность отказа в обслуживании через инжекцию EAPOL-Logoff на портах в режиме multi-auth, что может нарушить работу VoIP-телефонии; рекомендовано включить storm-control для EAPOL-фреймов» - наш коллега. Он переводит наш язык щелей и теней на язык бизнес-рисков и бюджетов на исправление. Это важная работа.

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

802.1X - это во многом театр. Красивые декорации строгой аутентификации, за которыми суетятся уставные техники-свитчи, нервничает суфлёр-RADIUS, а режиссёр-архитектор уже ушёл в другой проект. Но ведь мы все - актёры в этом театре! Кто-то играет роль Доверенного Пользователя, кто-то - роль Непрошеного Гостя (в рамках сценария пентеста), кто-то - Роль Бдительного Стража (IDS/IPS).

Можно просто выходить на сцену и заученно читать свои строки: «Мой MAC - 00:11:22:33:44:55, мой сертификат валиден, впустите меня». А можно знать всю пьесу. Знать реплики других актёров. Знать, где на сцене скрипят половицы, а какой софит вот-вот отвалится. Знать, что суфлёр иногда запинается, а режиссёрская копия сценария лежит вон на том стуле. Это знание не делает спектакль фарсом. Оно делает тебя осознанным участником. Ты понимаешь иллюзию, но продолжаешь играть, потому что иначе спектакль остановится, а людям в зале (пользователям, бизнесу) нужно, чтобы он шёл.

Поэтому наш девиз, наш самый честный, негласный тост, поднимаемый чашкой с холодным кофе в четыре утра перед монитором, заваленным дампами, звучит так:

Исследуй. Сомневайся. Тестируй. Делись.

• Исследуй - потому что любопытство это топливо, а документация и RFC - лишь карта сокровищ, на которой не отмечены половина рифов.
• Сомневайся - во всём. В стандартах. В заявлениях вендоров. В своих же выводах. «Работает? Почему? А что, если…» - лучшая мантра.
• Тестируй - ибо теория без практики мертва, а практика без своей лаборатории - это вандализм в продакшене.
• Делись - потому что знание, запертое в голове, гниёт. Спорь, получай критику, дополняй свою карту новыми пометками, оставленными другими мореплавателями. Форум, блог, доклад на кухонной конференции - не важно. Важен диалог.

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

Держи свою карту под рукой. Карандаш наточен. Лаборатория - в рабочем состоянии.

Послесловие к послесловию.

Ты спросишь: «Зачем? Зачем тратить тысячи слов, недели времени, кучу нервов на разбор какой-то старой, покрытой пылью технологии? Уже есть нулевые доверия, SASE, ZTNA, всё это уходит в облако!».

Отвечу так. 802.1X - это архетип. Принцип, высеченный в камне: «Сначала докажи, кто ты, потом получи доступ». Этот принцип будет жить вечно, в любых оболочках. В облаке он превратится в модные «identity-aware proxies» и «conditional access policies». В мире IoT станет «цифровыми паспортами устройств». Но суть останется: есть врата, есть страж, есть пропуск.

Поняв, как ломается и обходится этот архетип в его классической, «чистой» форме (802.1X), ты получаешь линзу. Линзу, через которую ты сможешь разглядеть уязвимости в его будущих, более сложных реинкарнациях. Ты начнёшь видеть те же паттерны: состояния, таймауты, неявное доверие, fallback-механизмы только уже в мире API-токенов, политик SaaS-приложений и блокчейн-идентификаторов.

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

Так что да, оно того стоило.