Wireless-инфраструктура в корпоративной среде до сих пор воспринимается как вспомогательный сервис. Доступ для сотрудников, гостевой сегмент, IoT. При этом беспроводной доступ фактически является отдельным периметром. Он не совпадает с внешним периметром компании, не ограничивается интернет-шлюзом и живёт по своим правилам аутентификации.
В 2026 году большинство организаций всё ещё используют WPA2-Enterprise. Причина не в отставании - а в совместимости, инвентаре устройств и сложной миграции. WPA3 внедряется, но не массово. В инфраструктуре одновременно сосуществуют WPA2-Enterprise, WPA2-PSK, гостевые SSID, IoT-сегменты и BYOD-профили. Это не единая модель доверия, а набор разноуровневых механизмов, объединённых в один радиосегмент.
Wireless pentesting в такой среде - это не проверка стойкости пароля. Это аудит всей цепочки: от 802.11-ассоциации до доступа в корпоративную VLAN. Где проверяется сертификат, где возможен downgrade, какие EAP-методы разрешены, как сегментируется трафик после аутентификации, есть ли изоляция клиентов, контролируется ли Rogue AP. Ошибка на любом этапе превращается в рабочий вектор атаки.
WPA3 действительно усложнил оффлайн-атаки на PSK за счёт SAE. Но он не устраняет уязвимости, связанные с конфигурацией. Mixed-mode остаётся распространённым, проверка серверных сертификатов на клиентах часто формальная, MSCHAPv2 продолжает использоваться в PEAP, а IoT-устройства в принципе не поддерживают современные профили. В итоге безопасность определяется не стандартом, а настройкой.
Отдельный слой - это атаки уровня Evil Twin и credential interception. В средах с WPA2-Enterprise основной целью становится не взлом шифрования, а получение учётных данных через имитацию инфраструктуры. Это уже не криптография, это эксплуатация доверия протокола аутентификации.
Если атакующий проходит аутентификацию или обходит её, он получает сетевое присутствие внутри организации. Дальше всё упирается в сегментацию, контроль east-west трафика и зрелость внутренней защиты.
Оборудование и инструменты: без правильного железа теста не будет
Wireless-пентест начинается не с airodump и не с hashcat. Он начинается с железа. Если у адаптера нет стабильного monitor mode'a и injection - всё остальное превращается в имитацию работы. Можно что-то посканировать, но полноценную атаку не собрать.Большая часть встроенных Wi-Fi карт в ноутбуках для тестирования не подходит. Драйверы режут monitor mode, injection работает нестабильно, чипсет не отдаёт корректные 802.11-фреймы. Иногда удаётся что-то выжать, но это нестабильная история. В продакшн-тесте так работать нельзя.
Ключевой критерий - поддержка:
- monitor mode без костылей;
- packet injection;
- корректная работа в 2.4 и 5 GHz;
- стабильность драйвера под Linux.
Один из типовых вариантов для тестирования - Alpha AWUS036ACH. Работает в двух диапазонах, поддерживает injection, драйверы под Kali ставятся без боли. Не идеален, но предсказуем. Для полевых тестов этого достаточно.
Если задача шире - развертывание Rogue AP, автоматизация сценариев, MITM-цепочки, тогда в игру входит специализированное железо. Например WiFi Pineapple. Это уже не просто адаптер, а платформа. Web-интерфейс, модули для Evil Twin, captive portal, автоматический harvesting. Он удобен и быстр, но есть нюанс - такие устройства заметны в инфраструктуре, если у заказчика есть WIDS/WIPS. В вашем сценарии это нужно учитывать.
Минимальный сетап для полноценного wireless pentest'a может выглядеть так:
| Компонент | Требование | Зачем это нужно |
|---|---|---|
| Wi-Fi адаптер | Monitor mode + injection | Capture handshake, deauth, Rogue AP |
| Антенна | Стабильный приём в 2.4/5 GHz | Устойчивость сигнала при capture |
| Linux-дистрибутив | Kali / Parrot / кастом | Нативная поддержка aircrack-ng и hostapd |
| GPU (опционально) | CUDA/OpenCL | Ускорение hashcat при WPA2-PSK |
Без GPU атаки на сложные PSK превращаются в теоретическую проверку. PMKID или handshake можно снять быстро, а вот перебор без нормальной видеокарты - это уже вопрос времени, и иногда очень долгого.
По инструментам. База остаётся прежней: aircrack-ng suite, airodump-ng, aireplay-ng. Это фундамент. Для WPA2-Enterprise нужен hostapd-wpe или модифицированные сборки hostapd с поддержкой перехвата EAP-учёток. Для анализа трафика - Wireshark с пониманием 802.11-фреймов, иначе часть нюансов просто не видна.
Отдельная история - драйверы. Некоторые адаптеры формально поддерживают injection, но при высокой плотности клиентов начинают дропать пакеты. Это ломает сценарий деаутентификации и мешает стабильно ловить хэндшейк. Проверять нужно заранее, а не в момент теста. Если начинают сыпаться ошибки - адаптер меняется без обсуждений.
Ещё момент, который часто упускают. 6 GHz диапазон. Он уже используется, особенно в новых офисах с Wi-Fi 6E. Не все адаптеры его поддерживают. Если тест ограничен 2.4 и 5 GHz, часть SSID может вообще не попасть в разведку. Но это редкость.
Wireless-пентест сильно зависит от физики сигнала и возможностей оборудования. Криптография может быть одинаковой, но стабильность атаки - нет. Поэтому выбор железа - это не формальность, а основа всей методологии.
Reconnaissance: что реально происходит в эфире
Разведка в wireless - это не быстрый скан на 30 секунд. Это наблюдение. Причём внимательное. Если этап Recon сделан поверхностно, дальше атака строится на догадках. А в Wi-Fi догадки стоят времени.Первое, что нужно понять - в эфире почти всегда больше сетей, чем видно при обычном подключении через ОС. Клиент показывает только то, что считает доступным. В monitor mode картина меняется. Видны скрытые SSID, BSSID одной и той же сети на разных каналах, клиенты, которые уже аутентифицированы, roaming между точками доступа, иногда даже фрагменты EAP-обмена.
База для пассивной разведки - airodump-ng. Минимальный запуск выглядит так:
Bash:
airmon-ng start wlan0
airodump-ng wlan0monСмотрим на поле ENC. WPA2-PSK или WPA2-Enterprise. Если Enterprise - дальше важен тип EAP, но его airodump напрямую не покажет. Придётся анализировать трафик глубже.
Обращаем внимание на клиентов. Наличие активных станций - это индикатор, что handshake можно перехватить. Если клиентов нет, PMKID-атака становится приоритетом. Если клиенты есть, можно оценить интенсивность трафика и поведение при смене канала.
airodump-ng даёт первичный срез, но для длительного наблюдения удобнее использовать Kismet. Он работает пассивно, собирает статистику, строит карту каналов, сохраняет PCAP. При длительном тесте это полезно - можно увидеть, как сеть ведёт себя в течение дня, как меняется плотность клиентов, какие SSID появляются временно.
Kismet показывает больше, чем просто список сетей. Видны probe-запросы клиентов. Это отдельный слой информации. Устройство, которое активно ищет определённый SSID, уже раскрывает часть своей истории. Иногда в probe-списке встречаются внутренние SSID, которые не транслируются публично. Это не взлом, это утечка через поведение клиента.
Дальше начинается интереснее. При анализе beacon-фреймов можно определить:
- поддерживаемые стандарты 802.11 (n/ac/ax);
- включён ли PMF;
- используется ли WPA3 в mixed-mode;
- конфигурацию RSN.
В разведке важно не спешить. Часто wireless-пентест заваливают тем, что сразу начинают бомбить deauth-пакетами. Это шумно, заметно и иногда бессмысленно. Сначала нужно понять, как устроена сеть. Сколько SSID на одной инфраструктуре, есть ли изоляция клиентов, как распределены каналы.
Ещё один момент - мощность сигнала. Если уровень RSSI на границе тестовой зоны слабый, атаки будут нестабильны. Capture может рваться, handshake будет битым, PMKID не снимется. Иногда достаточно сместиться на несколько метров, и картина меняется. Это физика, от неё никуда не спрятаться.
Когда разведка сделана правильно, у нас появляется карта:
- какие сети существуют;
- какие из них корпоративные;
- где WPA2-PSK, где Enterprise;
- есть ли WPA3;
- есть ли активные клиенты;
- есть ли скрытые SSID;
- какие каналы перегружены.
И вот здесь возникает вопрос, который часто игнорируют. Что из этого действительно входит в scope? Если в эфире видны соседние сети, их нельзя трогать. Поэтому после Recon обычно фиксируется список целевых SSID и BSSID, чтобы дальнейшие атаки были строго в рамках разрешённого теста.
WPA2-PSK: handshake, PMKID и реальная стойкость пароля
WPA2-PSK до сих пор встречается в корпоративной среде чаще, чем хотелось бы. Иногда это гостевой сегмент, иногда IoT, иногда отдельный VLAN для подрядчиков. Формально - допустимо. По факту - всё упирается в качество ключа и в то, как именно настроена инфраструктура.Атака на WPA2-PSK почти всегда начинается с получения материала для оффлайн-анализа. Никто не ломает шифрование в эфире. Снимается handshake или PMKID, дальше начинается перебор вне сети. И если пароль слабый, это лишь вопрос времени.
4-Way Handshake capture
Классическая схема - перехват четырёхстороннего рукопожатия между клиентом и точкой доступа. В момент подключения клиент и AP обмениваются наборами значений, на основе которых вычисляется PTK. В этом обмене нет самого пароля, но есть всё, что нужно для его проверки оффлайн.Логика простая. Мы ждём, пока клиент подключится, или аккуратно инициируем переподключение через deauth. Главное - получить корректный handshake без потерь пакетов.
Типовой сценарий выглядит так:
Bash:
airodump-ng -c <channel> --bssid <AP_MAC> -w capture wlan0mon
aireplay-ng --deauth 5 -a <AP_MAC> -c <CLIENT_MAC> wlan0monНо здесь есть нюанс. Если клиентов нет, deauth бесполезен. В пустой сети handshake не появится. И вот тут на сцену выходит более удобный механизм.
PMKID-атака
PMKID позволяет получить материал для оффлайн-брута без участия клиента. Точка доступа может отправить PMKID в первом же EAPOL-сообщении при попытке ассоциации. Если инфраструктура это допускает - задача упрощается.В современных версиях aircrack-ng и hcxdumptool это реализуется напрямую. Мы инициируем ассоциацию и ловим PMKID. Без деаутентификации, без активных клиентов.
После получения файла с хешем перебор выглядит так:
Bash:
hashcat -m 22000 capture.22000 wordlist.txt -r rules/best64.ruleИ вот здесь начинается практическая часть. Многие корпоративные PSK выглядят длинными, но формируются по шаблону. Сезон + год, название компании + цифры, вариации с заменой букв. Если словарь составлен грамотно и к нему добавлены rule-based модификации, такие ключи падают быстрее, чем ожидается.
GPU ускорение меняет картину радикально. Одна современная видеокарта способна проверять сотни миллиардов кандидатов в секунду для WPA2. Если пароль реально случайный и длиной 16+ символов - шанс перебора мал. Но таких ключей в живой инфраструктуре немного.
Есть ещё деталь, которую иногда упускают. Если PSK используется на нескольких SSID, компрометация одного сегмента автоматически открывает остальные. Особенно часто это встречается в IoT и технических сетях, где администраторы не заморачиваются с разными ключами.
С точки зрения отчёта пентестера важны не только факт подбора пароля, но и:
- длина и сложность ключа;
- время перебора при используемой конфигурации;
- возможность lateral movement из полученного VLAN;
- повторное использование PSK на других сегментах.
И вот на этом месте обычно возникает резкий контраст. PSK-сегмент может быть менее защищён, чем Enterprise, но его эксплуатация проще и быстрее. Иногда именно через гостевой Wi-Fi начинается полноценный pivot.
WPA2-Enterprise: атаки на 802.1X и перехват учётных данных
Если WPA2-PSK - это история про пароль, то WPA2-Enterprise - это история про доверие. Здесь уже нет общего ключа. Есть 802.1X, есть RADIUS, есть EAP-методы. И именно в этой цепочке чаще всего что-то настроено формально.На бумаге всё выглядит жёстко: уникальная аутентификация, динамические ключи, централизованный контроль. В реальности картина зависит от выбранного EAP-метода. PEAP с MSCHAPv2 всё ещё встречается массово. EAP-TLS внедрён далеко не везде. И вот тут начинается зона атаки.
Evil Twin + hostapd-wpe
Классический вектор - поднять Rogue AP, имитирующий корпоративный SSID. Не просто точку доступа с таким же именем, а полноценную копию параметров сети: шифрование, канал, RSN-настройки. Клиент должен увидеть привычную инфраструктуру.Для перехвата учётных данных используется модифицированный hostapd с поддержкой WPE. Он позволяет логировать EAP-обмен и, в случае PEAP/MSCHAPv2, сохранять challenge-response для последующего оффлайн-анализа.
Сценарий выглядит так. Клиент подключается к поддельной точке доступа. Если на устройстве не настроена строгая проверка серверного сертификата, оно принимает сертификат атакующего. Дальше начинается EAP-аутентификация, и учётные данные проходят через наш RADIUS.
В MSCHAPv2 пароль напрямую не передаётся, но "вызов-ответ" (Challenge-response) можно перебрать оффлайн. Это уже не Wi-Fi-атака в чистом виде, а криптоанализ NTLM-хеша. И если пароль доменной учётки слабый - получаем полноценный доступ.
Если используется EAP-TLS и клиенты корректно проверяют сертификат сервера, атака останавливается. Но проблема в том, что в реальных сетях проверка сертификата часто отключена или настроена без жёсткой привязки к конкретному CA.
EAP Downgrade
Иногда инфраструктура поддерживает несколько EAP-методов. Клиент и сервер договариваются о допустимом варианте. Если не ограничить список строго, возможен downgrade до менее защищённого метода.Это тонкая история. Нужно корректно эмулировать сервер, предложить нужный EAP-тип и заставить клиента согласиться. Если политика на стороне клиента мягкая, он может перейти с EAP-TLS на PEAP. Дальше - всё по предыдущему сценарию.
Здесь многое зависит от конфигурации supplicant’а на клиенте. В Windows-профилях, например, часто встречается разрешение на несколько методов без жёсткой валидации сервера. Это не уязвимость стандарта, это слабая политика.
Credential relay
Есть ещё более аккуратный вариант - не просто перехватить challenge-response, а попытаться релеить аутентификацию к реальному RADIUS-серверу. Сложнее в реализации, требует синхронизации и контроля таймингов, но даёт возможность получить валидную сессию без знания пароля.Это уже ближе к продвинутым Red Team сценариям. Цель - не собрать хеш, а получить сетевой доступ. Если реле проходит успешно, атакующий оказывается внутри корпоративного VLAN с легитимной аутентификацией.
Теперь о слабых местах, которые встречаются чаще всего:
| Проблема | Последствие |
|---|---|
| Нет строгой проверки серверного сертификата | Уязвимость к Evil Twin |
| Использование PEAP/MSCHAPv2 | Возможность оффлайн-брута NTLM |
| Разрешено несколько EAP-методов | Риск downgrade |
| Отсутствие client isolation | Возможность lateral movement после входа |
И здесь начинается важный момент. После успешного перехвата учётки это уже не wireless-атака. Это доменная атака. Полученная пара логин/пароль может использоваться для VPN, OWA, внутренних сервисов.
WPA3: что реально изменилось и где остаётся поверхность атаки
WPA3 появился как ответ на главный упрёк к WPA2-PSK - оффлайн-брут после перехвата handshake. Вместо классического четырёхстороннего обмена в режиме PSK используется SAE, он же Dragonfly. Логика другая: пароль не превращается напрямую в материал для проверки вне сети. Каждая попытка аутентификации требует активного взаимодействия с точкой доступа. Казалось бы, перебор умер.Но в инфраструктуре всё редко работает в идеальном режиме.
SAE и Dragonfly handshake
SAE строится на обмене элементами эллиптической криптографии. Клиент и точка доступа генерируют временные ключи, используя пароль как часть вычислений. Даже если атакующий перехватывает handshake, он не получает данные, пригодные для классического оффлайн-брута.Это серьёзный шаг вперёд. Захват трафика больше не даёт прямого входа в hashcat. Атака превращается в online-перебор, который ограничен таймингами и защитой от повторных попыток.
Но тут вступает в игру реальность внедрения.
Во многих корпоративных сетях WPA3 включён в режиме transition. Это означает одновременную поддержку WPA2-PSK и WPA3-SAE для совместимости со старыми клиентами. Если клиент может подключиться по WPA2, атакующий тоже может инициировать сценарий WPA2. В итоге защита зависит не от того, что точка доступа умеет, а от того, что разрешено.
В mixed-mode фактически сохраняется старая поверхность атаки. Если PSK слабый, handshake по WPA2 всё ещё может быть перехвачен. И никакой SAE тут не спасает.
Dragonblood и связанные уязвимости
Исследования, получившие общее название Dragonblood, показали, что реализация SAE может быть подвержена побочным каналам и downgrade-сценариям. Речь не о полном компромиссе протокола, а о нюансах реализации: тайминги, выбор групп, обработка ошибок.В некоторых конфигурациях возможно принудительное использование более слабых параметров или сбор информации о корректности пароля через анализ поведения точки доступа. Это уже не классический перебор, а аккуратная эксплуатация деталей.
Справедливости ради - большинство вендоров закрыли выявленные проблемы патчами. Но проблема не в наличии уязвимости, а в том, что инфраструктура обновляется неравномерно. Контроллер обновлён, а часть точек доступа нет. Или наоборот.
Есть ещё один момент. WPA3-Enterprise существует в двух вариантах: стандартный и 192-bit security mode. Второй встречается редко из-за требований к оборудованию и сертификатам. В реальности чаще используется тот же 802.1X с EAP, просто поверх WPA3. Это означает, что атаки на неправильную конфигурацию EAP никуда не делись. Если клиент не проверяет сертификат сервера, Evil Twin остаётся рабочим сценарием.
Коротко по состоянию дел:
| Компонент | Что улучшено | Что остаётся проблемой |
|---|---|---|
| SAE | Нет оффлайн-брута handshake | Mixed-mode сохраняет WPA2 |
| PMF | Защита от deauth | Часто отключён или опционален |
| WPA3-Enterprise | Усиленная криптография | Ошибки в EAP-конфигурации |
WPA3 усложняет жизнь атакующему, но не делает wireless автоматически безопасным. Если миграция проведена частично, если включён transition mode, если клиентские профили настроены без строгой политики - поверхность атаки остаётся.
И здесь важный сдвиг. Если в WPA2-PSK основной целью был пароль, то в WPA3 акцент смещается на конфигурацию и сегментацию. Атакующему сложнее получить ключ, зато по-прежнему возможно получить доступ через слабую модель доверия или через неправильно настроенный Enterprise-сегмент.
Post-Exploitation через Wi-Fi: pivot и закрепление
Когда wireless-пентест дал доступ, история только начинается. Успешная аутентификация в SSID - это не финал теста. Это точка входа. Дальше нужно понять, в каком сегменте мы оказались и насколько он изолирован.Первое, что делается после подключения - инвентаризация. IP-адрес, шлюз, VLAN, доступность внутренних ресурсов. Часто беспроводной сегмент логически считается отдельным, но маршрутизация до внутренних сервисов разрешена частично или полностью. Особенно если это корпоративный SSID с 802.1X.
Если получена доменная учётка через Enterprise-сценарий, картина меняется резко. Уже можно аутентифицироваться к SMB, LDAP, Kerberos. Wireless превращается в обычный внутренний хост, только без физического подключения к розетке. И если сегментация построена формально, lateral movement ничем не ограничен.
Pivoting через Wi-Fi выглядит банально, но эффективно. Сначала проверяется доступность контроллеров домена, файловых серверов, внутренних веб-сервисов. Потом - стандартный набор: Kerberoasting, LDAP enumeration, проверка слабых сервисных аккаунтов. Всё это уже не про радио, а про внутреннюю безопасность.
Есть сценарий тоньше. Если wireless-сегмент изолирован, но разрешён доступ к определённым зонам, можно использовать его как точку для туннелирования. Поднимается reverse-туннель на внешний сервер, и дальнейшая атака координируется удалённо. Это удобно в Red Team, когда физическое присутствие ограничено.
Иногда встречается архитектура, где гостевой Wi-Fi полностью изолирован от внутренней сети, но контроллер беспроводной инфраструктуры доступен из того же сегмента. Если контроллер уязвим или неправильно настроен, через него можно получить доступ к управлению всей WLAN-инфраструктурой. Это уже отдельный класс рисков - компрометация точки управления.
Rogue AP persistence
Если тест допускает активные сценарии, можно рассмотреть закрепление через Rogue AP. Логика такая: атакующий разворачивает точку доступа с параметрами корпоративного SSID и старается удерживать клиентов, даже если основная атака завершена.Для этого используется агрессивный broadcast beacon’ов с более сильным сигналом, иногда - selective deauth реальной точки доступа. Клиенты, особенно мобильные устройства, могут автоматически переподключаться к более сильному сигналу.
В продакшн-среде такой сценарий быстро заметен при наличии WIDS/WIPS. Но если мониторинга нет или он настроен формально, Rogue AP может существовать достаточно долго. И всё это время собирать учётные данные или проксировать трафик.
С точки зрения отчёта post-exploitation через Wi-Fi оценивается по нескольким критериям:
| Параметр | Что проверяется |
|---|---|
| Сегментация | Есть ли доступ к внутренним VLAN |
| Контроль east-west | Фильтруется ли трафик между хостами |
| Доступ к AD | Возможность доменной аутентификации |
| Детектирование Rogue AP | Реакция инфраструктуры |
Если wireless-сегмент даёт прямой доступ к домену без дополнительной проверки устройства, это уже архитектурная проблема. Даже при использовании 802.1X важно, чтобы после аутентификации применялись политики NAC или динамическая сегментация.
Post-exploitation через Wi-Fi часто воспринимается как вторичный этап. На практике именно он показывает зрелость сети. Получить доступ - это половина дела. Ограничить его - вот где начинается настоящая защита.
Защитные меры: как сделать Wi-Fi не дыркой, а управляемым сервисом
Защита обычно ломается не на уровне стандарта, а на уровне решений в духе давайте включим и пусть живёт. В Wi-Fi так не работает: чуть расслабился в профилях клиентов или оставил transition ради совместимости - и всё, окно для атаки снова открыто. Не драматизирую, просто это типичная математика доверия.Самая здравая цель - сделать так, чтобы компрометация Wi-Fi не давала удобного маршрута внутрь. И чтобы атакующему было больно уже на этапе попытки подмены инфраструктуры, а не после того как он собрал креды и ушёл в AD.
WPA3 migration roadmap без ловушек
Миграция на WPA3 обычно стопорится на старых клиентах. Решение почти всегда одно и то же: включают WPA3 transition mode. И на этом месте безопасность часто становится “как раньше, только с галочкой WPA3”.Нормальная миграция - это про раздельные контуры. Не один SSID на всех и всё, а постепенное выведение WPA2 в отдельный загон.
Тут удобно держать в голове простую модель:
| Сегмент | Что делать с WPA3 | Типовая ошибка |
|---|---|---|
| Корпоративный доступ | WPA3-Enterprise (или WPA2-E, но с жёстким EAP-TLS) | оставляют PEAP/MSCHAPv2 как совместимость |
| Гостевой | WPA3-SAE или OWE (если подходит) | оставляют WPA2-PSK с “человеческим” паролем |
| IoT | отдельный SSID/VLAN, строгая сегментация | пихают IoT в общий Wi-Fi с теми же ключами |
| Старые клиенты | отдельный SSID с ограничениями | делают transition на основном SSID |
Если уж transition mode неизбежен, то его хотя бы не надо ставить на главный корпоративный SSID. Лучше отдельный легаси SSID с коротким списком разрешённых сервисов и строгим мониторингом. И да, это тот случай, когда сетевики сначала ворчат, а потом привыкают.
802.1X с EAP-TLS: закрываем главный класс атак
Если в сети до сих пор PEAP/MSCHAPv2 - это не приговор, но это и не уровень 2026 года. Основная проблема PEAP/MSCHAPv2 не в том, что кто-то прямо сейчас его ломает, а в том, что он хорошо конвертируется в оффлайн-задачи. Перехватил challenge-response, дальше начинается перебор. И он не упирается в вашу WLAN - он упирается в качество паролей.EAP-TLS закрывает этот класс проблем красиво: нет пароля - нечего перехватывать. Есть сертификат клиента, есть проверка сертификата сервера, есть нормальная PKI-дисциплина. Да, это сложнее в эксплуатации. Зато это реально работает.
Критичные детали, на которых всё держится:
- клиент обязан проверять серверный сертификат и цепочку доверия, без вариантов
- желательно делать привязку к конкретному CA/шаблону, а не доверять любому корпоративному корню “на всякий случай”
- отключать fallback на другие EAP-методы в профиле, иначе downgrade остаётся рабочим
- RADIUS не должен быть “болтливым” в ошибках аутентификации, чтобы не подсказывать атакующему лишнего
Код:
# eap.conf (упрощённо)
eap {
default_eap_type = tls
tls-config tls-common {
private_key_file = /etc/raddb/certs/server.key
certificate_file = /etc/raddb/certs/server.crt
ca_file = /etc/raddb/certs/ca.crt
verify_client_cert = yes
require_client_cert = yes
}
tls {
tls = tls-common
}
}WIDS/WIPS, сегментация и контроль после входа
Даже с EAP-TLS можно профакапиться, если после аутентификации клиент попадает в жирный внутренний сегмент. Поэтому защита Wi-Fi заканчивается не на моменте, когда клиент прошёл 802.1X. Дальше начинается политика доступа.WIDS/WIPS нужен не ради галочки. Он нужен, чтобы:
- видеть Rogue AP и Evil Twin попытки,
- видеть аномалии в эфире,
- связывать это с инцидентами по доступу, а не просто хранить алерты.
Сегментация - отдельная боль. В идеале wireless-клиент попадает в динамический VLAN/SGT в зависимости от роли, устройства и политики. В чуть менее идеальном сценарии - хотя бы отдельные VLAN под corp/guest/iot и жёсткие ACL между ними. Минимальная цель: чтобы гостевой и IoT не имели маршрута к AD, management-интерфейсам, контроллерам, внутренним API и админским подсетям.
И последнее: мониторинг после входа. Если у вас есть NAC/политики соответствия устройства - отлично, используйте их. Если нет, хотя бы контролируйте east-west: кто к кому ходит, какие порты, какие протоколы, какие объёмы. Wi-Fi-клиенты - это такой же внутренний трафик, его нельзя оставлять без наблюдения только потому что он пришёл через радио.
Подведем итоги
Wireless-пентест - это не про перехват пакетов ради галочки и не про красивый скрин с найденным SSID. Это про проверку границ доверия. Если через Wi-Fi можно получить доменную учётку, выйти в продовый сегмент или спокойно жить с Rogue AP под носом у инфраструктуры - проблема не в стандарте 802.11. Проблема в архитектуре и в том, как именно она настроена.WPA3 усложняет атаки, EAP-TLS закрывает целый класс рисков, WIDS/WIPS добавляет видимость. Но ни один из этих элементов по отдельности не делает сеть устойчивой. Решает связка: строгая конфигурация, изоляция сегментов, контроль после аутентификации и отсутствие компромиссов ради удобства. Wireless - это тот же внутренний доступ, только по радио. Если он выдан, дальше всё работает по тем же законам lateral movement и privilege escalation.
Полный цикл wireless pentesting нужен не ради демонстрации уязвимости, а ради понимания, где именно сеть теряет контроль. Разведка показывает реальную поверхность. Атаки на WPA2/Enterprise выявляют слабые профили. Post-exploitation вскрывает сегментацию. Защита проверяется не настройкой в контроллере, а невозможностью повторить атаку в тех же условиях.
И если после теста Wi-Fi перестаёт быть слепой зоной и становится управляемым компонентом безопасности - значит работа сделана правильно.
Последнее редактирование:
