Комментарии 36
Так а причина в чем? Прошивку хакнули или это изначально было?
Автор включил в настройках ДНС-сервера галочку Allow remote requests и при этом не заблокировал фаерволом 53 порт снаружи. Вот все и пользуются его микротиком для днс-флуда. К сожалению микротик требует определенного уровня квалификации. А вообще хорошим тоном считается блокировать в фаерволе все извне, кроме того что явно разрешено.
Этот баг Микротика уже 100 раз описан. Надо закрывать 53-й порт на Микротике.
А в чем баг то? Роутер позволяет сделать доступным DNS сервер на себе. с натяжкой можно утверждать что "эта настройка не должна быть включена по умолчанию", но оборудование этого производителя и не позиционируется как "техника для домохозяек", за что многими и любима. В том что пользователь не в состоянии ее правильно настроить - Mikrotik не виновен.
В современных микротах в дефолтных настройках он снаружи не открыт:)
Всмысле в обновленных.
Строго говоря после покупки или резета Mikrotik предлагает либо сделать конфигурацию по умолчанию, в которой включен разумный FW и таких проблем нет, либо - сделать пустую конфигурацию, где ты сам себе злобный буратино и можешь настроить вообще все самостоятельно, возможно у топикстартера второй вариант вышел не так чтобы корректно :) Но опять же, Mikrotik тут невиновник.
А в чем баг то?
Баг в том, что DNS-сервер доступный извне - очень опасная штука, которая позволяет мультиплицировать атаку. То есть представьте, что злоумышленник обладает каналом в 1 мбит, то он используя такой DNS сервер может напосылать трафика на 1мбит, а он будет генерировать трафика на 8 мбит.
Подробнее например тут.
Так и есть, уже ранее не одна статья была как сразу после установки Mikrotik-а нужно прописывать такие правила DNS Flood, Honey Pot как пример на SSH-порт и др.
Сам ранее тоже не раз сталкивался с такой траблой.
Видно, что Mikrotik флудит на порт dns'а по разным адресам - вот и паразитный трафик.
Где это видно? На скриншоте видно что Mikrotik флудит с порта dns'а
Если включите логирование не только исходящего, но и входящего трафика - скорее всего увидите что сначала к вам приходит DNS запрос с этих адресов(на самом деле не с них, но микторику об этом неведомо) и потом идет ответ от вас.
Лично наше с коллегой мнение - как сейчас принято называть, заложенный в прошивке оборудования нерегламентированный функционал, а именно некий скрипт с целью производить DDoS-атаки.
Функционал вполне себе регламентированный - Allow Remote Requests в настройках DNS называется. По хорошему доступ к нему должен быть только из локально сети, но по дефолту открыт и наружу.
А разве по умолчанию он не заблочен при включенном firewall с настройками по quick setup?
У меня DNS включен, 2ip.ru говорит что 53 порт закрыт.
А ещё микротики бывает рутуют и подключают к ботнету, если прошивки не обновлять и открытые порты снаружи оставлять.
Как выше написали - проблема в некорректной настройке фаервола, превратившей ваш микрот в открытый днс-сервер. Проведите аудит настроек, возможно там еще что-то есть открытое.
На просторах Инета достаточно много статей по настройке безопасности Mikrotik. Если вкратце, то:
- Отключить все ненужные службы.
- Для нужных локальных служб установить допуск только из диапазона IP LAN.
- Дропать все входящие на WAN по 53 порту.
- Переназначить, если возможно, прокидываемые порты со стандартных на нестандартные.
- Установить ханипоты на незадействованные стандартные порты.
- Настроить порт-нокинг для внешних управляющих портов.
- Настроить серо-черные списки для блокировки подозрительной активности на открытых портах.
- И т.д. по вкусу.
У самих был достаточно мощный входящий DNS-трафик. После закрытия на WAN 53-го порта еще недели 2-3 наблюдались попытки. Потом сошли на нет.
Я б сформулировал чуть иначе - закрываем весь входящий трафик (ессно разрешив established и related). От прямых пробросов портов желательно отказаться, если бизнес/процессы требуют - реализовать f2b с проверкой на сервисе.
Портнокинг я бы заменил впн-ом с мфа, ханипоты - по вкусу, необходимости острой не вижу. Лучше ids/ips:)
Ну и да, феншуйно выводить управляющие интерфейсы в отдельный vlan с ограниченным доступом. И не забывать обновляться:)
Ну, если к SCADA-серверу регулярно подключаются через GSM/GPRS-модемы десятки и сотни удаленных контроллеров для передачи телеметрии (причем, каждый на свой порт, но с разных и притом динамических адресов), то совсем без проброса портов никак не получится. И динамическую фильтрацию, вроде F2B, не прикрутишь.
IDS/IPS — вещь хорошая, но не всегда необходимая. А ханипоты — это дешево, надежно и практично. Быстро и неотвратимо срабатывают на попытки сканирования стандартных портов. Но чреваты тем, что можно забыть про них и самозабаниться.
Было бы неплохо предусмотреть так же разбанивание каким-то образом, хотя бы по тому же портнокингу. Но не знаю как. Во-первых, если с IP из черного списка все пакеты дропать, то уже и портнокингом не достучишься. Во-вторых, как удалять адреса из списков? Как помещать — такое есть. А как удалять — не нашел.
по-хорошему такие штуки в впн заворачивать, но конечно главное поступать разумно - и осознанно:)
ну, как минимум разумно банить на какое-то время, а не навсегда (да и фолс-позитив срабатывания могут быть).
разбанивание по порт-нокингу - ну например скриптом можно сделать. условно, сделали определённый нокинг, удалённый адрес попал в нужный адрес-лист, а скрипт что регулярно дёргается шедулером - смотрит этот адрес-лист и удаляет из блеклиста.
Скриптом можно. Но морочно - не стоит того. Банить, разумеется, на время. В RouteOS, когда IP помещается в серо-черый список, то указывается, через какое время его оттуда удалить. Например, из черного списка - через неделю. А из серых - минут через 10-15.
Для VPN нужно соответствующее оборудование. У нас используются обычные промышленные GSM/GPRS-модемы ОВЕН и iRZ. Там таких наворотов нет. Зато есть возможность работать с двумя выходными каналами (2 симки различных операторов) и с двумя входящими каналами на серверах (2-3 IP от разных провайдеров).
А у промышленных роутеров iRZ есть поддержка двух SIM и VPN на любой вкус: PPTP, L2TPv2/v3, GRE, OpenVPN, EoIP. Но стоят они, как пролет Крымского моста.
Так что, вопрос только в целесообразности цены. Чаще всего, дорогие меры обеспечения безопасности не нужны. Вот если бы у нас было удаленное управление, то вопрос совсем другой. Но т.к. нам это запрещено (разрешено только получать телеметрию, а потом - по коням), то и потребности в VPN здесь нет.
вопрос ещё критичности передаваемых данных и защиты от перехвата..
в целом промышленные микроты (типа ltap mini) когда-то стоили разумно, аналогичное мы на них строили. в базе там один модем но 2 слота под симки (в старших моделях 3), можно переключать тудым-сюдым
Можно переключать, или автоматически переключаются с основного мобильного оператора на резервного и обратно?
можно переключать, логику придётся описывать самостоятельно (или взять готовые скрипты, емнип были у микрота на вики), и будет автоматически переключаться:)
PS да, есть - https://wiki.mikrotik.com/wiki/Dual_SIM_Application#Failover_script_example
Это всех роутеров касается,и особенно бытовых...
Хотелось бы добавить, что в стандартных настройках микротика 53 порт заблокирован на порту провайдера. Автор статьи удалил правило, блокирующее входящий трафик и разрешил удаленные подключения к DNS - т. е. сделал все, что нужно, чтобы проблема возникла. Многие пользователи микротика по незнанию делают тоже самое, случай не уникален.
Это проблема любого публичного днс сервера, атака называется DNS Amplification. С NTP протоколом присутствует такая же проблема, кстати.
/ip firewall raw
add action=drop chain=prerouting comment="block dns flood" dst-port=53 in-interface-list=WAN protocol=udp
add action=drop chain=prerouting comment="block dns flood" dst-port=53 in-interface-list=WAN protocol=tcp
Дорогой автор, а не проще ли было запретить правилом файервола все соединения из списка WAN на input и на forward, а потом раньше этого правила прицельно и с пониманием разместить нужные разрешающие правила? Как оно и сделано по дефолту в микротиках (заводской конфиг), на самом деле.
Ну, что все набросились-то с 53 портом? Человек может впервые столкнулся с этим, и знать-не знал, что его затыкать надо. Все мы когда-то начинали и набивали шишки ...
Его не надо закрывать, надо закрывать всё кроме нужного:) а набросились, потому что опубликовано некорректное решение проблемы + претензия к микротам))
В большинстве мануалов про настройку микротов с нуля пишут что-то вроде такого:
/ip firewall filter
add chain=input connection-state=established,related action=accept
add chain=input connection-state=invalid action=drop log=yes log-prefix=invalid
add chain=input in-interface-list=WAN protocol=icmp action=accept
add chain=input in-interface-list=WAN action=drop
Было такое у меня тоже когда-то. Закрыл 53-й порт для входящего трафика с интерфейса, который у меня определен как WAN. Открытый DNS используется злоумышленниками для атак на другие ресурсы. Для этого они отправляют запрос на DNS микротика с подмененным IP (IP жертвы). Микротик отправляет ответ в сторону жертвы. Такая вот флуд-атака.
Уважаемые коллеги!!! Всем спасибо, что направили в верную сторону. Да, действительно микротик настраиваю с нуля сам всегда, работаю с этим оборудование лет 7 уже. Никогда не сталкивался с таким паразитным трафиком, вот и описал свои мысли на этот счет.
Поправил ФВ по рекомендациям - трафик исчез.
Еще раз всем спасибо за правильное направление.
Всем респект и уважуха!!!
Главное не удалять последнее правило input drop wan, а то многим "мешает" -).
DNS flood с Mikrotik