Ddos атака на wifi что это

DOS-атака на Wi-Fi.

Привет, начинающий хакер.

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

Что такое DOS-атака?

DOS — это аббревиатура от английского Denial of Service, что переводится как «отказ в обслуживании» — т.е. это атака на систему, с целью довести её до такого состояния, когда доступ к ресурсам затруднён или невозможен. Что касается всем известного DDOS (Distributed Denial of Service) то это тоже самое, с той разницей, что DDOS проводится с использованием большого числа компьютеров. Обычно DDOS используется против крупных коммерческих сервисов или государственных порталов, сервера которых, как правило неплохо защищены и обычный DOS могут даже не заметить.

Вполне очевидно (из определения) что DOS атаку можно провести на любую систему, сеть, службу и т.д. в том числе и на wi-fi. И именно этим мы сегодня и займёмся.

WebSploit

С чего начать использование WebSploit? Правильно, с его установки:

После установки запускаем его:

И на экране появиться приветствие с номером версии, датой последнего обновления и т.д., а также предложение к вводу команды:

Команд которые можно использовать не так много, что, скорее, хорошо:

set — установить значение параметров для модулей
scan — сканировать wi-fi (беспроводные модули)
stop — остановить атаку и сканировать (беспроводные модули)
run — выполнить модуль
use — выбрать модуль для использования
os — запуск команд Linux (например: ifconfig)
back — выйти из текущего модуля
show modules — показать модули из текущей базы данных
show options — показать текущие параметры выбранного модуля
upgrade — обновить до новой версии
update — обновление Websploit Framework

Теперь, чисто в образовательных целях, ознакомимся с доступными модулями утилиты:

Список доступных модулей не такой уж и маленький:

Логика использования каждого из предложенных модулей довольно похожа, и понятна из доступных в этом фреймворке команд, и мы разберем её на примере wi-fi jammer.

Но перед этим необходимо провести парочку подготовительных мероприятий (в другом окне терминала), а именно перевести наш беспроводной адаптер в режим мониторинга:

Предварительно, командой iwconfig проверь как называется твой беспроводной интерфейс. А иногда (редко) может понадобиться завершить процессы о которых нас предупреждает airmon-ng. Это можно сделать командой kill и указать PID процесса.

Теперь нам нужно определиться с какой именно wi-fi сетью мы будем работать, для этого давай посмотрим какие сети есть в пределах досягаемости:

Мы будем работать со специально созданной мной для этого сетью home 33. Собственно, из всех имеющихся сведений о сети, нам понадобятся: BSSID, CH, ESSID

Теперь вернёмся к WebSploit и задействуем нужный нам модуль:

теперь можем ознакомиться с настройками этого модуля:

В разделе Options мы видим какие параметры нужно дать модулю для работы:

Убедившись что всё правильно, можем запускать:

После этого утилита начнёт работу, а все кто подключен к атакуемой wi-fi с горечью обнаружат, что у них пропал интернет.

Остановить процесс можно командой stop.

Защита от DOS атаки на wi-fi

Если твоя сеть оказалось под такой атакой, но твой компьютер подключен к роутеру по проводу, то ты эту атаку даже не заметишь. А если серьёзно, то есть несколько простых правил которые если не гарантируют защиту от подобного рода вмешательств, то, как минимум, увеличивают шанс неудачи для злодея. Во-первых своевременно обновляй прошивку роутера, и как бы банально это не звучало, это не становиться менее важным, ведь многие игнорируют этот простой момент, а производители роутеров, в обновлениях, частенько закрывают многие дырки и исправляют уязвимости, а иногда добавляют определенные элементы защиты, поэтому этот совет важен в общем контексте безопасности твоей сети, а не только в разрезе защиты от DOS. Во-вторых некоторые роутеры имеют встроенные механизмы защиты от подобных (и не только) вмешательств, поищи в настройках роутера, что-нибудь наподобие (названия варьируются в зависимости от производителя): flooding protection, ping of death, scanner protection и т.д., и включи их, лишним точно не будет. Ну и напоследок ещё одна банальность — сделай свою сеть скрытой, конечно от целенаправленной атаки именно на тебя не спасёт, но от «мамкиных хацкеров» идеальная защита.

Читайте также:  Сколько трафика съедает прямой эфир

А на этом, пожалуй всё. Используй полученные знания только во благо и не забывай возвращаться к нам, чтобы узнать ещё много интересного.

Источник

История одной DDOS атаки на роутер и методы защиты Juniper routing engine

По долгу службы мне часто приходится сталкиваться с DDOS на сервера, но некоторое время назад столкнулся с другой атакой, к которой был не готов. Атака производилась на роутер Juniper MX80 поддерживающий BGP сессии и выполняющий анонс подсетей дата-центра. Целью атакующих был веб-ресурс расположенный на одном из наших серверов, но в результате атаки, без связи с внешним миром остался весь дата-центр. Подробности атаки, а также тесты и методы борьбы с такими атаками под катом.

История атаки

Исторически сложилось, что на роутере блокируется весь UDP трафик летящий в нашу сеть. Первая волна атаки (в 17:22) была как раз UDP трафиком, график unicast пакетов с аплинка роутера:

и график unicast пакетов с порта свича подключенного к роутеру:

демонстрируют, что весь трафик осел на фильтре роутера. Поток unicast пакетов на аплинке роутера увеличился на 400 тысяч и атака только UDP пакетами продолжалась до 17:33. Далее атакующие изменили стратегию и добавили к атаке UDP еще и атаку TCP SYN пакетами на атакуемый сервер, а также на сам роутер. Как видно по графику, роутеру стало настолько плохо, что он перестал отдавать SNMP в zabbix. После волны SYN на порты роутера стали отваливаться BGP сессии с пирами (используется три аплинка с каждого получаем full view по ipv4 и по ipv6), в логах появились трагические записи:

Как было выяснено позже, после атаки, волна TCP SYN увеличила нагрузку на routing engine роутера после чего упали все BGP сессии и роутер не смог самостоятельно восстановить работу. Атака на роутер длилась несколько минут, но из-за дополнительной нагрузки, роутер не мог обработать full view с трех аплинков и сессии снова рвались. Восстановить работу удалось только поочередным поднятием всех BGP сессий. Дальнейшая атака шла на сам сервер.

Испытание в условиях стенда и воспроизведение атаки

В качестве цели атаки использовался Juniper MX80 с той же версией прошивки, что и на боевом роутере. В качестве атакующего использовался сервер с 10Gb картой и установленной на нем ubuntu server + quagga. Генератором трафика выступал скрипт с вызовом утилиты hping3. Для проверки пагубного воздействия “всплесков” трафика, скрипт генерировал трафик с временными разрывами: 30 секунд атака — 2 секунды атаки нет. Также, для чистоты эксперимента, была поднята BGP сессия между роутером и сервером. В установленной на тот момент конфигурации боевого роутера, порты BGP и SSH были открыты на всех интерфейсах/адресах роутера и не фильтровались. Аналогичная конфигурация была перенесена на стендовый роутер.

Первым этапом испытаний стала атака TCP SYN на BGP (179) порт роутера. Ip адрес источника совпадал с адресом пира в конфиге. IP address spoofing не исключался, так как у наших аплинков не включен uPRF. Сессия была установлена. Со стороны quagga:

Со стороны Juniper:

После начала атаки (13:52) на роутер летит

1.2 Mpps трафика:

или 380Mbps:

Нагрузка на CPU RE и CPU FE роутера возрастает:

После таймаута (90 сек) BGP сессия падает и больше не поднимается:

Jul 4 13:54:01 MX80 rpd[1407]: bgp_hold_timeout:4035: NOTIFICATION sent to 9.4.8.2 (External AS 4567): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 9.4.8.2 (External AS 4567), socket buffer sndcc: 38 rcvcc: 0 TCP state: 4, snd_una: 3523671294 snd_nxt: 3523671313 snd_wnd: 114 rcv_nxt: 1556791630 rcv_adv: 1556808014, hold timer out 90s, hold timer remain 0s

user@MX80> monitor traffic interface ge-1/0/0 count 20
13:55:39.219155 In IP 9.4.8.2.2097 > 9.4.8.1.bgp: S 1443462200:1443462200(0) win 512
13:55:39.219169 In IP 9.4.8.2.27095 > 9.4.8.1.bgp: S 295677290:295677290(0) win 512
13:55:39.219177 In IP 9.4.8.2.30114 > 9.4.8.1.bgp: S 380995480:380995480(0) win 512
13:55:39.219184 In IP 9.4.8.2.57280 > 9.4.8.1.bgp: S 814209218:814209218(0) win 512
13:55:39.219192 In IP 9.4.8.2.2731 > 9.4.8.1.bgp: S 131350916:131350916(0) win 512
13:55:39.219199 In IP 9.4.8.2.2261 > 9.4.8.1.bgp: S 2145330024:2145330024(0) win 512
13:55:39.219206 In IP 9.4.8.2.z39.50 > 9.4.8.1.bgp: S 1238175350:1238175350(0) win 512
13:55:39.219213 In IP 9.4.8.2.2098 > 9.4.8.1.bgp: S 1378645261:1378645261(0) win 512
13:55:39.219220 In IP 9.4.8.2.30115 > 9.4.8.1.bgp: S 1925718835:1925718835(0) win 512
13:55:39.219227 In IP 9.4.8.2.27096 > 9.4.8.1.bgp: S 286229321:286229321(0) win 512
13:55:39.219235 In IP 9.4.8.2.2732 > 9.4.8.1.bgp: S 1469740166:1469740166(0) win 512
13:55:39.219242 In IP 9.4.8.2.57281 > 9.4.8.1.bgp: S 1179645542:1179645542(0) win 512
13:55:39.219254 In IP 9.4.8.2.2262 > 9.4.8.1.bgp: S 1507663512:1507663512(0) win 512
13:55:39.219262 In IP 9.4.8.2.914c/g > 9.4.8.1.bgp: S 1219404184:1219404184(0) win 512
13:55:39.219269 In IP 9.4.8.2.2099 > 9.4.8.1.bgp: S 577616492:577616492(0) win 512
13:55:39.219276 In IP 9.4.8.2.267 > 9.4.8.1.bgp: S 1257310851:1257310851(0) win 512
13:55:39.219283 In IP 9.4.8.2.27153 > 9.4.8.1.bgp: S 1965427542:1965427542(0) win 512
13:55:39.219291 In IP 9.4.8.2.30172 > 9.4.8.1.bgp: S 1446880235:1446880235(0) win 512
13:55:39.219297 In IP 9.4.8.2.57338 > 9.4.8.1.bgp: S 206377149:206377149(0) win 512
13:55:39.219305 In IP 9.4.8.2.2789 > 9.4.8.1.bgp: S 838483872:838483872(0) win 512

Вторым этапом испытаний стала атака TCP SYN на BGP (179) порт роутера. Ip адрес источника выбирался рандомно и не совпадал с адресом пира указанным в конфиге роутера. Эта атака произвела на роутер такой же эффект. Дабы не растягивать статью однообразными выводами логов, приведу только график нагрузки:

По графику отчетливо видно момент начала атаки. BGP сессия также упала и не смогла восстановиться.

Читайте также:  Почему по кабелю скорость ниже чем по wifi

Концепция построения защиты RE роутера

Особенность работы оборудования Juniper заключается в разделении задач между routing engine (RE) и packet forwarding engine (PFE). PFE обрабатывает весь поток проходящего трафика осуществляя его фильтрацию и маршрутизацию по заранее сформированной схеме. RE занимается обработкой прямых обращений к роутеру (traceroute, ping, ssh), обработкой пакетов для служебных сервисов (BGP, NTP, DNS, SNMP) и формирует схемы фильтрации и маршрутизации трафика для PFE роутера.

Основная идея защиты роутера состоит в фильтрации всего трафика предназначенного для RE. Создание фильтра позволит перенести нагрузку, создаваемую DDOS атакой, с CPU RE на CPU PFE роутера, что даст возможность RE обрабатывать только реальные пакеты и не тратить процессорное время на другой трафик. Для построения защиты необходимо определить, что фильтруем. Схема написания фильтров для IPv4 была взята из книги Douglas Hanks Jr. — Day One Book: Securing the Routing Engine on M, MX and T series. В моем случае на роутере схема была следующей:

По протоколу IPv4

  • BGP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка bgp neighbor. Разрешаем только подключения tcp established, то есть фльтр будет отбрасывать все SYN прилетающие на этот порт, а сессия BGP будет начинаться только от нас (BGP сосед аплинка работает в пассивном режиме).
  • TACACS+ — фильтруем пакеты по source и destination ip, source ip может быть только из внутренней сети. Ограничиваем полосу пропускания в 1Mb/s.
  • SNMP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка snmp-clients в конфиге.
  • SSH — фильтруем пакеты по destination ip, source ip может быть любой, так как есть необходимость экстренного доступа к устройству из любой сети. Ограничиваем полосу пропускания в 5Mb/s.
  • NTP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка ntp servers конфига. Ограничиваем полосу пропускания в 1Mb/s (в дальнейшем порог был уменьшен до 512Kb/s).
  • DNS — фильтруем пакеты по source и destination ip, source ip может быть любой из списка dns servers конфига. Ограничиваем полосу пропускания в 1Mb/s.
  • ICMP — фильтруем пакеты, пропускаем только на адреса принадлежащие роутеру. Ограничиваем полосу пропускания в 5Mb/s (в дальнейшем порог был уменьшен до 1Mb/s).
  • TRACEROUTE — фильтруем пакеты, пропускаем только пакеты с TTL равным 1 и только на адреса принадлежащие роутеру. Ограничиваем полосу пропускания в 1Mb/s.
Читайте также:  Что такое контроллер беспроводной lan

По протоколу IPv6, в моем случае, фильтры накладывались только на BGP, NTP, ICMP, DNS и traceroute. Единственное отличие в фильтрации ICMP трафика, так как IPv6 использует ICMP в служебных целях. Остальные протоколы не использовали IPv6 адресацию.

Написание конфигурации

Для написания фильтров в juniper существует удобный инструмент — prefix-list, который позволяет динамически составлять списки ip адресов/подсетей для подстановки в фильтры. Например, для создания списка адресов ipv4 BGP соседей указанных в конфиге, используется следующая структура:

результат составления списка:

show configuration policy-options prefix-list BGP-neighbors-v4 | display inheritance
##
## apply-path was expanded to:
## 1.1.1.1/32;
## 2.2.2.2/32;
## 3.3.3.3/32;
##
apply-path «protocols bgp group neighbor »;

Составляем динамические списки префиксов для всех фильтров:

Составляем полисеры для ограничения пропускной способности:

Ниже, под «копи-паст», конфигурация фильтров конечного варианта защиты (были уменьшены пороги пропускной способности трафика NTP и ICMP, причины снижения порогов подробно описаны в разделе тестирования). Настраиваем фильтры ipv4:

Далее необходимо применить фильтры на служебный интерфейс lo0.0. В системе JunOS этот интерфейс используется для передачи данных между PFE и RE. Конфигурация примет следующий вид:

Порядок указания фильтров в input-list интерфейса очень важен. Каждый пакет будет проверяться на валидность проходя по фильтрам указанным в input-list слева направо.

Тестирование фильтров

После применения фильтров, провел ряд тестов на том же стенде. После каждого теста выполнялась очистка счетчиков firewall. Нормальная (без атаки) нагрузка на роутере видна на графиках в 11:06 — 11:08. График pps за весь период тестов:

График CPU за весь период тестов:

Первым проводился тест флуда icmp c порогом трафика 5Мб/с (на графиках 10:21 — 10:24). По счетчикам фильтра и на графике видно ограничение по трафика по пропускной способности, но даже этого потока было достаточно для повышения нагрузки, поэтому порог был уменьшен до 1Мб/с. Счетчики:

Повторный тест флуда icmp c порогом трафика 1Мб/с (на графиках 10:24 — 10:27). Нагрузка на RE роутера упала с 19% до 10%, нагрузка на PFE до 30%. Счетчики:

Следующим был проведен тест флуда на порт BGP роутера с постороннего (не включеного в конфиг) ip адреса (на графиках 10:29 — 10:36). Как видно из счетчиков, весь флуд осел на discard-tcp фильтре RE и лишь увеличил нагрузку на PFE. Нагрузка на RE не изменилась. Счетчики:

сессия не падает:

Четвертым был проведен тест флуда (на графиках 10:41 — 10:46) UDP на порт NTP (в настройках фильтра взаимодействие по этому порту ограничивается серверами указанными в конфиге роутера). По графику, нагрузка поднимается только на PFE роутера до 28%. Счетчики:

Пятым был проведен тест флуда (на графиках 10:41 — 11:04) UDP на порт NTP с IP spoofing. Нагрузка на RE увеличилась на 12%, нагрузка на PFE увеличилась до 22%. По счетчикам видно, что флуд упирается в порог 1Мб/с, но этого достаточно для повышения нагрузки на RE. Порог трафика в итоге был уменьшен до 512Кб/с. Счетчики:

Повторный тест флуда (на графике ниже 11:29 — 11:34) UDP на порт NTP с IP spoofing, но с порогом трафика 512Кб/с. График нагрузки:

Счетчики:

Заключение

В итоге всех проведенных тестов удалось получить, устойчивую к DDOS атакам, конфигурацию фильтров трафика RE. В настоящий момент эта конфигурация уже применена на боевом роутере и проблем не выявлено. По счетчикам с боевого MX80:

видно какое количество “левого” трафика оседает на фильтре discard.

Буду рад ответить на все вопросы в комментариях.

Источник