Выявление DoS атаки на Wi-Fi сеть

На китайских интернет-аукционах появилось громадное количество устройств для проведения различных атак на Wi-Fi протокол, например, Jammer. Каждый из нас может столкнуться с ситуацией, когда в настроенной и сданной в успешную эксплуатацию сети появляются проблемы, причины которых могут оказаться весьма неожиданными. В статье я хочу рассказать, как выявить DoS атаку на радиоканал Wi-Fi, и обозначить способы противодействия. Материалы не несут технической сложности и доступны в интеллектуальном смысле широкому кругу читателей, которые могут элементарно столкнуться с соседом, начитавшимся распространённых мануалов по взлому Wi-Fi, оттачивающим свои скилы на практике и тем самым намеренно или не очень вредящим своими действиями добропорядочным соседям.

1. Постановка задачи

Смоделируем ситуацию. Имеется беспроводная сеть 2.4 ГГц, в которой регулярно, но без какой-то понятной причины и периодичности, на клиентских устройствах случается что-то такое:

Описание того, какие бывают уязвимости протокола Wi-Fi, как их можно эксплуатировать, какие риски информационной безопасности они несут, а также существующий программный арсенал для их проведения я намеренно опускаю, так как это не относится к теме статьи. На просторах сети легко найти много инструкций, с помощью которых можно научиться хакать беспроводные сети. Например, вот сборка Wi-Fi Jammer на Arduino. Или вот взлом Wi-Fi-сетей, защищённых WPA и WPA2. А вот совсем свежий отличный подробный мануал DIY на подобную тему. Ими может воспользоваться человек без специальных технических знаний, который впоследствии может доставить хлопот вашей сети.

Вернёмся к предмету разговора. Как видно из рисунка, произошёл разрыв L1 – L3 соединений с точкой доступа и маршрутизатором. Disconnect через небольшое количество времени будет автоматически восстановлен. На устройствах под управлением Linux это выглядит примерно так:

wlan0     IEEE 802.11  ESSID:"TEST3"             Mode:Managed  Frequency:2.442 GHz  Access Point: BB:BB:BB:BB:BB:BB             Bit Rate=135 Mb/s   Tx-Power=15 dBm              Retry short limit:7   RTS thr:off   Fragment thr:off           Encryption key:off           Power Management:off           Link Quality=50/70  Signal level=-60 dBm   <...> wlan0     IEEE 802.11  ESSID:off/any             Mode:Managed  Access Point: Not-Associated   Tx-Power=15 dBm              Retry short limit:7   RTS thr:off   Fragment thr:off           Encryption key:off           Power Management:off 

Задача заключается в том, чтобы показать, какие технические факторы сигнализируют о DoS атаке на Wi-Fi сеть. Поехали…

2. Исследование

Лог точки доступа (в качестве примера использовано устройство MikroTik) ничего явно указывающего на проблему не содержит:

14:05:54 wireless,info DD:DD:DD:DD:DD:DD@wlan: disconnected, received deauth: class 3 frame received (7)  14:05:55 wireless,info DD:DD:DD:DD:DD:DD@wlan: connected, signal strength -74  14:05:55 wireless,info DD:DD:DD:DD:DD:DD@wlan: disconnected, received deauth: class 3 frame received (7)  14:06:06 wireless,info DD:DD:DD:DD:DD:DD@wlan: connected, signal strength -69 

Даже если активировать режим debug, конкретики не прибавится:

14:08:04 wireless,debug wlan: DD:DD:DD:DD:DD:DD attempts to associate  14:08:04 wireless,debug wlan: DD:DD:DD:DD:DD:DD not in local ACL, by default accept 

Анализ L1 соединения на стороне точки доступа показывает, что клиент резко пропадает, после некоторого времени появляется в таблице регистраций:

/interface wireless registration-table print interval=0.2  # INTERFACE     MAC-ADDRESS       AP  SIGNAL-STRENGTH TX-RATE UPTIME                0 wlan         DD:DD:DD:DD:DD:DD no  -77dBm@1Mbps    144.... 4h16m40s              1 wlan         11:11:11:11:11:11 no  -76dBm@HT40-1   120M... 3h24m33s              2 wlan         22:22:22:22:22:22 no  -79dBm@6Mbps    86.6... 3h4m54s               3 wlan         33:33:33:33:33:33 no  -71dBm@1Mbps    57.7... 2h9m56s 

Имеем первую ясность, проблема на L1 уровне, и скорее всего, на клиентской стороне, иначе бы лог был более детальный, чем просто «мерцающий» беспроводной клиент. Переходим к радиообследованию, для чего воспользуемся бесплатной программой Linssid (платные аналоги, вроде inSSIDer и Wi-fi-scanner здесь ни к чему) с графическим интерфейсом пользователя:

apt install linssid linssid

Имеем табличное представление загруженности эфира в диапазоне 2.4 ГГц:

Графический вариант не сильно отличается по информативности. Сразу видно, что ситуация шаблонна. Точки доступа работают где хотят, а не так, как бы хотелось. Про качественную утилизацию эфирного времени говорить не приходится. Оптимально каналы Wi-Fi должны либо совсем не пересекаться, либо наоборот, быть одинаковыми, как бы договариваясь за эфир, а не вещать в перехлёст даже чуть-чуть:

При этом среднее значение уровня шума (noise floor) хорошее, поэтому физические факторы, связанные с распространением радиоволн в окружающей среде, в том числе применение не интеллектуальных подавителей Wi-Fi (вроде таких), здесь не причем:

/interface wireless monitor wlan                   status: running-ap                 channel: 2442/20-Ce/gn       wireless-protocol: 802.11             noise-floor: -104dBm          overall-tx-ccq: 69%      registered-clients: 3   authenticated-clients: 3             wmm-enabled: yes       current-tx-powers: 1Mbps:24(24/29),2Mbps:24(24/29),5.5Mbps:24(24/29),11Mbps:24(24/29),                          6Mbps:24(24/29),9Mbps:24(24/29),12Mbps:24(24/29),18Mbps:24(24/29),                          24Mbps:24(24/29),36Mbps:23(23/28),48Mbps:22(22/27),54Mbps:21(21/26),                          HT20-0:24(24/29),HT20-1:24(24/29),HT20-2:24(24/29),HT20-3:24(24/29),                          HT20-4:24(24/29),HT20-5:23(23/28),HT20-6:21(21/26),HT20-7:20(20/25),                          HT40-0:24(24/29),HT40-1:24(24/29),HT40-2:24(24/29),HT40-3:24(24/29),                          HT40-4:24(24/29),HT40-5:23(23/28),HT40-6:21(21/26),HT40-7:20(20/25)     notify-external-fdb: no 

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

Далее мы подтвердим гипотезу, используя для этого различные программные инструменты, применяемые для анализа информационной безопасности. Воспользуемся софтом Airodump-ng и запустим мониторинг нашей точки доступа:

airodump-ng -i wlan1 -c 7 --bssid BB:BB:BB:BB:BB:BB   BSSID              PWR RXQ  Beacons    #Data, #/s  CH   MB   ENC CIPHER  AUTH ESSID  BB:BB:BB:BB:BB:BB  -56 100      909     1610   12   7  405   WPA2 CCMP   PSK  TEST3   BSSID              STATION            PWR   Rate    Lost    Frames  BB:BB:BB:BB:BB:BB  DD:DD:DD:DD:DD:DD  -38    6e- 1e3     3478  BB:BB:BB:BB:BB:BB  11:11:11:11:11:11  -48   48e-24e    2     1430  BB:BB:BB:BB:BB:BB  22:22:22:22:22:22  -50   12e-18     0       34 

В момент срыва подключения, на клиентских устройствах можно увидеть ненормальные скачки принимаемого уровня сигнала PWR:

 BSSIDPWRRXQBeacons#Data,#/sCHMBENCCIPHERAUTHESSID       BB:BB:BB:BB:BB:BB-61503494907405WPA2CCMPPSKTEST3 

Как показано выше, он равен -61, в момент проведения DoS атаки становится -40. Указанные значения постоянно сменяют друг друга:

 BSSIDPWRRXQBeacons#Data,#/sCHMBENCCIPHERAUTHESSID       BB:BB:BB:BB:BB:BB-40513555007405WPA2CCMPPSKTEST3 

Кроме этого, наблюдаем таргетированный рост Lost пакетов:

  BSSIDSTATIONPWRRateLostFrames BB:BB:BB:BB:BB:BBDD:DD:DD:DD:DD:DD-4224e- 111121489 BB:BB:BB:BB:BB:BB11:11:11:11:11:11-560 -1807 BB:BB:BB:BB:BB:BB22:22:22:22:22:22-6418e- 1e02 

Представленная выше информация достаточна, для подтверждения высказанной гипотезы. Однако запишем трафик и проанализируем его для того, чтобы увидеть прямые доказательства DoS атаки: deauthentication packets, нацеленные на нашего клиента. Воспользуемся любым из следующих фильтров в Wireshark:

(wlan.fc.type == 0) && (wlan.fc.type_subtype == 0x0c) (wlan.fc.type eq 0) && (wlan.fc.type_subtype eq 0x0c) (wlan.fc.type eq 0) && (wlan.fc.type_subtype eq 12)

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

IEEE 802.11 Deauthentication, Flags: ........     Type/Subtype: Deauthentication (0x000c)     Frame Control Field: 0xc000         .... ..00 = Version: 0         .... 00.. = Type: Management frame (0)         1100 .... = Subtype: 12         Flags: 0x00     .000 0001 0011 1010 = Duration: 314 microseconds     Receiver address: DD:DD:DD:DD:DD:DD     <Receiver address DD:DD:DD:DD:DD:DD>     <Hardware address: DD:DD:DD:DD:DD:DD>     <Hardware address (resolved): DD:DD:DD:DD:DD:DD>     Destination address: DD:DD:DD:DD:DD:DD     <Destination address (resolved): DD:DD:DD:DD:DD:DD>     Transmitter address: BB:BB:BB:BB:BB:BB     <Transmitter address (resolved): BB:BB:BB:BB:BB:BB>     Source address: BB:BB:BB:BB:BB:BB     <Source address (resolved): BB:BB:BB:BB:BB:BB>     BSS Id: BB:BB:BB:BB:BB:BB     <BSS Id (resolved): BB:BB:BB:BB:BB:BB>     <Hardware address: BB:BB:BB:BB:BB:BB>     <Hardware address (resolved): BB:BB:BB:BB:BB:BB>     <Hardware address: BB:BB:BB:BB:BB:BB>     <Hardware address (resolved): BB:BB:BB:BB:BB:BB>     .... .... .... 0000 = Fragment number: 0     0000 0000 0000 .... = Sequence number: 0

Подобные DoS пакеты, распространяются для намеренной деаутентификации клиентов беспроводной сети. Для автоматизации их поиска существуют готовые бесплатные программные продукты, которые давно вошли в арсенал специалистов по информационной безопасности. Одним из таких является софт Kismet, ранее рассмотренный на Хабре, однако уже значительно изменившейся с тех пор. Он запускается на серверной части, к которой подключен Wi-Fi интерфейс с возможностью перевода в режим мониторинга. Клиентом выступает браузер, что позволяет очень гибко его применять. В настройках указываем интерфейс для сканирования беспроводных сетей:

Существует возможность настроиться на конкретную частоту Wi-Fi или работать в режиме сканирования частотных каналов:

В графическом интерфейсе можно увидеть информацию такую же, как в консольной программе Airodump-ng:

Во вкладке Alerts сразу видны уведомления о DoS атаке на Wi-Fi сеть, что делает жизнь проще, а профессию любимой:

3. Что с этим делать

Для защиты от подобного рода DoS атак более десяти лет назад разработан стандарт 802.11w (Protected Management Frames), в котором фреймы disassociation, reassociation, deauthentication подписываются ключом, известным только авторизованным клиентам и легитимным точкам доступа. В результате клиент может определить, получен данный фрейм от настоящей точки или от «подделки». Данный протокол входит в стандарт Wi-Fi Wave 2, однако его практическое распространение до сих пор незначительно. Так, оборудование MikroTik пока поддерживает его только на следующих изделиях (с определёнными ограничениями): hAP ac³, Audience, Audience LTE6 kit и RB4011iGS+5HacQ2HnD. В RouterOS соответствующая настройка находится здесь (подробнее тут):

 /interface wifiwave2 security management-protection (allowed | disabled | required) 

Если в существующей инфраструктуре точки доступа с поддержкой стека протоколов Wi-Fi Wave 2 не задействуются, то, в качестве пассивной меры защиты, может быть предложено планирование мест работы беспроводных клиентов в клетке Фарадея на удалении от границ внешнего периметра, чтобы сигналы от Wi-Fi Jammer устройств им были недоступны. Это скорее нереально, чем реально: так как на то они и wireless, что могут свободно перемещаться по офису.

Специалистам информационной безопасности при необходимости следует проводить анализ радиоэфира, как показано в статье. Однако встаёт логичный вопрос, что делать, если атака фиксируется на постоянной основе и не даёт работать. Можно предположить, что следует обратиться в компетентные государственные службы, осуществляющие поиск источников создания недопустимых помех, например, сюда, но я бы предложил локализовать источник проблем самостоятельно. Технически это возможно, как раз благодаря тому, что, как показано выше, в момент проведения DoS атаки на клиентских устройствах можно увидеть характерные не нормальные скачки принимаемого уровня сигнала PWR, так как Wi-Fi Jammer, представляясь легитимной точкой доступа, отправляет от её имени deauthentication packets. Нам понадобится беспроводная сетевая карта с возможностью подключения внешней антенны, например, что-то из этого, а также непосредственно направленная антенна, желательно с хорошим коэффициентом усиления. Далее остаётся походить по офису и соседним помещениям, в которые имеется доступ, в поисках источника интеллектуальных помех, где PWR сигнал будет больше (на всякий случай, -40 это больше, чем -61), а легитимные точки доступа располагаться не рядом.

Полторы недели назад коллеги писали о том, что у лидеров рынка Wi-Fi-оборудования на борту имеется функция активного подавления посторонних точек доступа: «Если клиент подключился к нелегитимной точке, корпоративная точка доступа может отключить клиента методом Wi-Fi deauthentication attack: отправить пакеты деаутентификации от имени нелегитимной точки, и клиент отсоединится от сторонней сети». Это такой DoS наоборот, который, кстати, может быть использован и в обратном направлении.

4. Выводы

Следовать современным технологиям и периодически своевременно обновлять парк оборудования — безусловно правильная стратегия, которой придерживаться, к сожалению, получается никому далеко не всем, особенно в последние экономически нелёгкие годы. Если читателю придётся столкнуться с ситуацией, когда подключения клиентов регулярно обрываются, при этом других технических проблем, которые могут приводить к подобным ситуациям, не выявлено, тогда troubleshooting функционирующей беспроводной сети может дойти и до представленного обследования. Если не хочется заниматься охотой на лис – тогда только 802.11w или старые добрые провода.