DNS флуд снаружи

Тема в разделе "Вопросы начинающих", создана пользователем ea100, 23 июл 2015.

  1. ea100

    ea100 Новый участник

    Добрый день, коллеги!
    Положили мне сегодня канал какие-то злые хацкеры! 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 сервер?
     
  2. Илья Князев

    Илья Князев Администратор Команда форума

    Последнее редактирование модератором: 23 янв 2019
    Mama нравится это.
  3. papuas

    papuas Новый участник

    Видимо стоит галочка в 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
     
    Последнее редактирование: 21 сен 2015
  4. baklan56

    baklan56 Участник

    Thanks, papuas, это то что нужно. На графике внизу трафик который рубится? Как найти у кого на компе зараза?
     
  5. Илья Князев

    Илья Князев Администратор Команда форума

    Атака снаружи. Смысл - подмена IP-отправителя на IP жертвы и отправка запроса открытому DNS. При этом запрос обычно на какую-нибудь большую запись.
    Цель - завалить с вашей помощью канал жертвы флудом.
     
  6. baklan56

    baklan56 Участник

    Илья, я все посмотрю и прочитаю в указанных тобой статьях, но и ты пойми - нужно принять быстрое решение, мне люди письма шлют (как и еа100 я подозреваю), провайдер нервничает. Поэтому в оперативном плане popuas реально выручил, а ты в обидку...
     
  7. baklan56

    baklan56 Участник

    Видишь что мне шлют?
    Получили жалобу на Ваш 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
     
  8. Илья Князев

    Илья Князев Администратор Команда форума

    Никакой "обидки" с моей стороны нет.
    Было указано что проблема в файрволле. Было предложено два варианта
    1. Восстановить дефолтную конфигурацию файрволла (там все хорошо прикрыто)
    2. Или разобраться как работает файрволл.
    Потом объяснено в чем смысл атаки и что ваши пользователи не при чем.
    Почему вы решили, что я на что-то обиделся, я не понял. ))
     
  9. baklan56

    baklan56 Участник

    Видишь что мне шлют?
    Получили жалобу на Ваш 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
     
  10. Илья Князев

    Илья Князев Администратор Команда форума

    Вам же прямо в письме провайдер указал
    Что, между прочим очень любезно с его стороны.
     
  11. baklan56

    baklan56 Участник

    Илья, я так понимаю что это подстава с моего ip... Дело в том, что Микротик купили с убитой конфигурацией и я по твоей статье все прописывал вручную, неоткуда было восстанавливать дефолтную конфу. Все я сделал как написал popuas, как считаешь, с провайдером у меня все ровно будет?
     
  12. Илья Князев

    Илья Князев Администратор Команда форума

    Ну от 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
     
  13. baklan56

    baklan56 Участник

    СПС, счас сделаю
     
  14. Илья Князев

    Илья Князев Администратор Команда форума

    Себя не подрежте, если снаружи сидите. Или если VPN-ы есть.
     
  15. baklan56

    baklan56 Участник

    Илья, все готово, СПС, подскажи плиз, на графике для правила с UDP уже почти 800 000 пакетов прошло, все фунциклирует нормально?
     
  16. baklan56

    baklan56 Участник

    я понял, я снаружи, по все пока хорошо
     
  17. Илья Князев

    Илья Князев Администратор Команда форума

    Поставьте пока не отвалились самым верхним правилом
    chain=input protocol=tcp dst-port=8291 action=accept
     
  18. Илья Князев

    Илья Князев Администратор Команда форума

    Проверить закрытие DNS снаружи делаем
    nslookup https://ya.ru/ <внешний ip микротика>
     
    Последнее редактирование модератором: 23 янв 2019
  19. baklan56

    baklan56 Участник

    Да, Илья, статьи конечно посмотрю, это уже второй микротик, я писал, оч хорошо себя показывают в работе в офисе.
    старый MikroTik RB2011UiAS-2HnD-IN работал 2 года без проблем с почти 100 клиентами, потом стал подвисать 1 раз в 2-3 дня.
    новый MikroTik Cloud Core Router CCR1009-8G-1S быстро завести не получилось, через WINBOX только попал в него, ну и
    по твоим статьям по первоначальной настройке, как и на старом, все руками завел. Только запустил и тут этот хацкер,
    блин, как ждал. Новый не подвисает, работает все на ура, СПС тебе, пошел спать.
     
  20. baklan56

    baklan56 Участник

    счас конечно сделаю