Добрый день, коллеги! Положили мне сегодня канал какие-то злые хацкеры! 53 порт UDP (DNS). Так я и не понял почему он смотрит наружу и отвечает на запросы. Временное решение: /ip firewall filter # Добавляем ip-адрес в черный список add chain=input action=add-src-to-address-list address-list=dnsflood address-list-timeout=1h dst-port=53 in-interface=eth1 protocol=udp #блокируем add action=drop chain=input dst-port=53 in-interface=eth1 protocol=udp src-address-list=dnsflood За 25 минут в черном списке появилось 128 адресов... Вопросы новичка: как можно защититься от DOS атак и как правильно настроить DNS сервер?
Посмотрите внимательно, какие правила создаются в /ip firewall filter дефолтной конфигурацией. ну и читайте статьи по фильтрации пакетов. Настройка фильтрации трафика на Mikrotik. Часть 1 Настройка фильтрации трафика на Mikrotik. Часть 2 Настройка фильтрации трафика на Mikrotik. Часть 3
Видимо стоит галочка в IP>DNS> Allow Remote Requests - разрешать удаленные запросы, это означает, что ваш mikrotik dns занимается обслуживанием рекурсивных запросов по умолчанию на всех интерфейсах. Этим правилом увы, ничего не решить. Дело в том, что ip источника которые Вы блокируете, могут быть фейковые. Хацкер просто генерит пакеты и подменяет ip источника. Чтобы не принимать входящие requests на 53 порт внешнего интерфейса (и вести лог если нужно): /ip firewall filter add chain=input action=drop in-interface=wan protocol=udp dst-port=53 log=yes log-prefix=query_in_drop
Thanks, papuas, это то что нужно. На графике внизу трафик который рубится? Как найти у кого на компе зараза?
Атака снаружи. Смысл - подмена IP-отправителя на IP жертвы и отправка запроса открытому DNS. При этом запрос обычно на какую-нибудь большую запись. Цель - завалить с вашей помощью канал жертвы флудом.
Илья, я все посмотрю и прочитаю в указанных тобой статьях, но и ты пойми - нужно принять быстрое решение, мне люди письма шлют (как и еа100 я подозреваю), провайдер нервничает. Поэтому в оперативном плане popuas реально выручил, а ты в обидку...
Видишь что мне шлют? Получили жалобу на Ваш iP адрес. Просьба принять меры. You appear to be running an open recursive resolver at IP address 176.126.40.202 that participated in an attack against a customer of ours, generating large UDP responses to spoofed queries, with those responses becoming fragmented because of their size. Please consider reconfiguring your resolver in one or more of these ways: - To only serve your customers and not respond to outside IP addresses (in BIND, this is done by defining a limited set of hosts in "allow-query"; with a Windows DNS server, you would need to use firewall rules to block external access to UDP port 53) - To only serve domains that it is authoritative for (in BIND, this is done by defining a limited set of hosts in "allow-query" for the server overall but setting "allow-query" to "any" for each zone) - To rate-limit responses to individual source IP addresses (such as by using DNS Response Rate Limiting or iptables rules) More information on this type of attack and what each party can do to mitigate it can be found here: http://www.us-cert.gov/ncas/alerts/TA13-088A If you are an ISP, please also look at your network configuration and make sure that you do not allow spoofed traffic (that pretends to be from external IP addresses) to leave the network. Hosts that allow spoofed traffic make possible this type of attack. Example DNS responses from your resolver during this attack are given below. Date/timestamps (far left) are UTC. 2015-12-15 18:23:46.948638 IP (tos 0x0, ttl 50, id 5314, offset 0, flags [+], proto UDP (17), length 1500) 176.126.40.202.53 > 162.248.89.x.44070: 59371| 22/0/0 cpsc.gov. AAAA 2600:803:240::2[|domain] 0x0000: 4500 05dc 14c2 2000 3211 78df b07e 28ca E.......2.x..~(. 0x0010: a2f8 592f 0035 ac26 1007 185b e7eb 8380 ..Y/.5.&...[.... ... (The final octet of our customer's IP address is masked in the above output because some automatic parsers become confused when multiple IP addresses are included. The value of that octet is "47".) -John President NFOservers.com
Никакой "обидки" с моей стороны нет. Было указано что проблема в файрволле. Было предложено два варианта 1. Восстановить дефолтную конфигурацию файрволла (там все хорошо прикрыто) 2. Или разобраться как работает файрволл. Потом объяснено в чем смысл атаки и что ваши пользователи не при чем. Почему вы решили, что я на что-то обиделся, я не понял. ))
Видишь что мне шлют? Получили жалобу на Ваш iP адрес. Просьба принять меры. You appear to be running an open recursive resolver at IP address 176.126.ххх.хххthat participated in an attack against a customer of ours, generating large UDP responses to spoofed queries, with those responses becoming fragmented because of their size. Please consider reconfiguring your resolver in one or more of these ways: - To only serve your customers and not respond to outside IP addresses (in BIND, this is done by defining a limited set of hosts in "allow-query"; with a Windows DNS server, you would need to use firewall rules to block external access to UDP port 53) - To only serve domains that it is authoritative for (in BIND, this is done by defining a limited set of hosts in "allow-query" for the server overall but setting "allow-query" to "any" for each zone) - To rate-limit responses to individual source IP addresses (such as by using DNS Response Rate Limiting or iptables rules) ... (The final octet of our customer's IP address is masked in the above output because some automatic parsers become confused when multiple IP addresses are included. The value of that octet is "47".) -John President NFOservers.com
Илья, я так понимаю что это подстава с моего ip... Дело в том, что Микротик купили с убитой конфигурацией и я по твоей статье все прописывал вручную, неоткуда было восстанавливать дефолтную конфу. Все я сделал как написал popuas, как считаешь, с провайдером у меня все ровно будет?
Ну от open dns resolver ты вроде закрыл. Остальное не готов сказать. Дефолтная конфа она при сбросе маршрутизатора появляется. На файрволле там в общем-то 4 основных правила (последовательность важна!) 1. chain=input protocol=icmp action=accept 2. chain=input connection-state=established,related action=accept 3. chain=input in-interface=WAN action=drop //если несколько wan-интерфейсов - повторяем нужное кол-во раз 4. chain=forward connection-state=invalid action=drop
Илья, все готово, СПС, подскажи плиз, на графике для правила с UDP уже почти 800 000 пакетов прошло, все фунциклирует нормально?
Поставьте пока не отвалились самым верхним правилом chain=input protocol=tcp dst-port=8291 action=accept
Да, Илья, статьи конечно посмотрю, это уже второй микротик, я писал, оч хорошо себя показывают в работе в офисе. старый MikroTik RB2011UiAS-2HnD-IN работал 2 года без проблем с почти 100 клиентами, потом стал подвисать 1 раз в 2-3 дня. новый MikroTik Cloud Core Router CCR1009-8G-1S быстро завести не получилось, через WINBOX только попал в него, ну и по твоим статьям по первоначальной настройке, как и на старом, все руками завел. Только запустил и тут этот хацкер, блин, как ждал. Новый не подвисает, работает все на ура, СПС тебе, пошел спать.
