На китайских интернет-аукционах появилось громадное количество устройств для проведения различных атак на 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- 1e	3     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:

BSSID			PWR	RXQ	Beacons	#Data,	#/s	CH	MB	ENC	CIPHER	AUTH	ESSID      
BB:BB:BB:BB:BB:BB	-61	50	349	49	0	7	405	WPA2	CCMP	PSK	TEST3

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

BSSID			PWR	RXQ	Beacons	#Data,	#/s	CH	MB	ENC	CIPHER	AUTH	ESSID      
BB:BB:BB:BB:BB:BB	-40	51	355	50	0	7	405	WPA2	CCMP	PSK	TEST3

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

 BSSID				STATION		PWR	Rate	Lost	Frames
BB:BB:BB:BB:BB:BB	DD:DD:DD:DD:DD:DD	-42	24e- 1	1112	1489
BB:BB:BB:BB:BB:BB	11:11:11:11:11:11	-56	0 -18	0	7
BB:BB:BB:BB:BB:BB	22:22:22:22:22:22	-64	18e- 1e	0	2

Представленная выше информация достаточна, для подтверждения высказанной гипотезы. Однако запишем трафик и проанализируем его для того, чтобы увидеть прямые доказательства 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 или старые добрые провода.