DoS-атака на линейку оборудования MikroTik и виртуальные RouterOS

[Contriver]

Да и вообще это с его слов «нормальная ситуация», что производительности ЦП не хватает для обработки такого кол-ва пакетов…

или же купить более производительный роутер

CCR1036 куда уж мощнее 36 ядер 1,2ГГЦ
Неплохая позиция производителя, некто ожирает ресурсы роутера — так купите новый мощнее, мы с вас щё и прибыль получим. Зачем им патчить прошивку!
MikroTik советует отключить в меню Ip service все сервисы — они встали на безликий путь остальных производителей роутеров.
MikroTik как раз хорош универсальностью.
С таким отношением завтра найдут ещё кучу уязвимостей приводящих к перегрузке и что получим ответ производителя в духе… так как уязвимость не критическая(не приводит к взлому) купите более производительный!
Неплохой маркетинг, производитель сливает уязвимость и предлагает купить более мощный, заявляя это всё ЦРУ и злые ХАКЕРЫ виноваты!

[vasilevkirill]

А что вы собственно ожидали от MikroTik? чтобы они за вас создали правила в фаерволе?
Так как это не проблема MikroTik это проблема протокола.
Если вы завтра создадите пару сотен правил фаервола и пропускная способность будет ниже чем ширина канала и вы получите на входе полную загрузку канала, в итоге вы получите 100% загрузку CPU и все вытекающие последствия…
Создавайте правила фаервола которое смотрит количество пакетов RST за N время и добавляйте src адрес в адрес лист, после чего добавьте это адрес в дроп а таблице RAW
/ip firewall filter
add action=add-src-to-address-list address-list=DDOS address-list-timeout=1d chain=input limit=1k,5:packet protocol=tcp src-address-list=!DDOS tcp-flags=rst

/ip firewall raw
add action=drop chain=prerouting src-address-list=DDOS

Естественно указать интерфейсы входящие откуда ожидаете проблему (обычно со стороны провайдера)
Также можете указать конкретно порты сервисов, чтобы не весь трафик rst проверять

[Fess]

Не поможет. Вы пытаетесь дропнуть пакет, который не имеет смысла дропать в принципе. Соединения, как такового, нет, но прилетает пакет о его закрытии. Вы его ещё и дропаете, добавляя нагрузку на CPU. Причём, могу уточнить, что пакеты можно слать на ЛЮБОЙ порт, даже с отсутствующими сервисами. Т.е. на 8888, если он у вас не обслуживается. Тупо, лупите роутер пакетами. Это не уязвимость конкретного роутера, — тот же эксплоит работает на других софтроутерах.

[vasilevkirill]

Вперёд 5.19.245.3 Версия 6.38.5
http://5.19.245.3/graphs/

[Fess]

Ну уж будьте любезны, атакуйте свой маршрутизатор сами?

[vasilevkirill]

=) RAW отрабатывает до connection-tracker

[Fess]

Безусловно, но я не о том.
Производительность конкретного роутера:
https://routerboard.com/RB951G-2HnD#perf
При размере кадра 64 байта(а именно столько и формируется), максимально, маршрутизатор прожует 269600 пакетов в секунду. Достаточно 18 mbps, чтобы завалить конкретно этот маршрутизатор пакетами. Вы же предлагаете ещё и обработать каждый из этих пакетов. Я и говорю, что не поможет. Это просто ограничения конкретного железа(?).

[vasilevkirill]

Если нечего не делать, то конечно помрёт, но у нас есть возможность по крайней мере слегка разгрузить нагрузку, за счёт прерывания трафика в цепочки Prerouting

[vasilevkirill]

Иначе на следующем этапе будет попытка установить статус соединения (Established, related или invalid), а это уже выборка из памяти connection-tracker-a

[Fess]

Что мёртвому припарка. Проблема в том, что маршрутизатор закидывают огромным количеством пакетов и он просто не справляется с их количеством. О чём производитель говорит в спецификации оборудования, на которую я Вам привёл ссылку. Да, Ваше правило спасло бы, если бы не тот факт, что атака производится на мощности оборудования, которые Вы не способны защитить изнутри и средствами самого маршрутизатора. Вообще никак!
Защититься возможно, если Вы поставите перед ним какой-нибудь IDS и порежете такого рода пакеты. И, в свою очередь, у этого IDS тоже будет ограничение по количеству обрабатываемых пакетов.
Ещё интересно, как защититься от такого количества RST, если злоумышленник решит рандомно менять ip.src в каждом пакете?

[NiTr0_ua]

ну и кто помешает слать RST пакеты с рандомным src ip? заспуфить сорс ип — много ума не надо, тут ведь не требуется установленная tcp сессия (т.е. получение какого-либо ответа на заспуфленый ip)…

[vasilevkirill]

Конечно можно, поэтому это проблема не только MikroTik-а

[SolarW]

Что-то не все так просто с таким правилом…
Поставил для теста только первую часть, которая собирает айпишки в адрес-лист.
За полчаса насобиралось под полсотни апишек в список…
Сомнения у меня что это атакующие…

[vasilevkirill]

Можно сделать и так. Но небольшая модификация эксплоита и уже работать не будет

/ip firewall filter
add action=add-src-to-address-list address-list=TEST_DDOS address-list-timeout=1d chain=input connection-state=invalid dst-port=8291 in-interface=ether5 limit=1k,5:packet protocol=tcp tcp-flags=rst

[SolarW]

Проблема похоже в том, что я кажется не совсем правильно понимаю кусок первоначального правила
limit=1k,5:packet
Предполагал что это имеется в виду тысяча пакетов данного вида в секунду.
Но судя по количеству айпишек которые за ночь в список набились (порядка 500 штук) — взяло большое сомнение…
Неужели с каждой из этих айпишек более чем по 1000 TSP RST per sec на меня валило?

[IgorGIV]

Не совсем понятно, для чего оставлять данный порт смотрящим наружу? Проще поднять VPN на самом маршуртизаторе, и только полключившись к нему уже ходить в админку.

[gromka]

На это представитель сказал, что VPN поднятый на этом же микротике — это тоже ip service по этому проблема будет актуальна.

[IgorGIV]

О! Спасибо за уточнение. В самой статье этого не увидел. Что ж, это грустно.

[vesper-bot]

Интересно, если зафлудить микротик, на котором поднят IPsec в каком-то виде, пакетами IKE (TCP/500, UDP/500) — он тоже подвиснет?

[institor]

Я вообще не понимаю, при чем тут микротик? Это обычный DoS.

[NiTr0_ua]

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

[nApoBo3]

Не понятно где здесь уязвимость микротика. Т.е. если любое другое оборудование с поднятым сервисом загрузить специально сформированными пакетами у него не будет загрузки процессора?

[Mystray]

Это проблема любого т.н. софт-роутера без сильного разделения data и control. Даже правила INPUT цепочки вполне себе доходят до ядра и обрабатываются теми же механизмами, что и транзитные.
Старшие хардварные братья имеют вполне себе защиту контрол-плейна, вроде COPP/LPTS, ddos-protection или аналогов. Да даже более-менее серьезные виртуальные роутеры вроде J vMX, C CSR1000v или HP VSR имеют более сильное разделение, и обработка фаервола/полиси происходит не в том же самом месте, где обработка control-plane сервисов, а сильно раньше и с большей эффективностью

[NiTr0_ua]

нет, в данном случае — это не проблема софт-роутера как такового. это проблема вполне конкретной реализации софт-роутера. которой почему-то плохеет при получении RST пакета на открытый tcp порт (что-то не то напатчевали латыши или нанятые ними индусы в линукс ядре)…

[NiTr0_ua]

микротик складывается от смешного pps, сгенеренного перловым скриптом. даже 8-ядерный зион, который вполне себе нормально эдак несколько Мппс обычного трафика жует (а то и десяток-другой Мппс).

т.е. любой пользователь, имеющий дома 100мбит (а скорее — даже меньше) канал, может положить любой микротик, на котором открыт хоть 1 tcp порт. это не уязвимость, не? :)

[dimsoft]

А если не открыт а port knocking — тоже ляжет?

[Chupaka]

Даже эксплойт не нужен, hping3 SYN-пакетами заваливает ЦПУ отлично. В качестве контрмеры и в raw prerouting, и в filter input всё прекрасно дропается.

Из интересного — на виртуалке SYN-flood'ил порт 21 (в сервисах FTP был включен) — роутер практически сразу уходил в перезагрузку.