свяжите: черная дыра для недопустимых рекурсивных запросов?

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

К сожалению, я не нашел способа позволить BIND делать это, но в случае, если iptables вам подходит, я использовал

iptables -t raw -I PREROUTING -i eth0 -p udp --destination-port 53 \
    -m string --algo kmp --from 30 \
    --hex-string "|01000001000000000000|" -j DROP

Я бы попробовал:

zone "." {
  type redirect;
  allow-query "none";
}

Ответы, отсылающие клиентов к корневым серверам, контролируются зоной "перенаправления". Это должно сказать ему, чтобы он не отвечал на них.

Это намекает в документации Bind9: http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06. html # id2592674

Вы можете заменить "none" на свою локальную подсеть.

Если у вас уже есть зона "." , просто добавьте allow-query "none"; к нему.

Как правило, я бы посоветовал:

Включить журналы привязки и записывать IP-адреса, которые получают отклоненный ответ. Установите программу fail2ban, добавьте действие blackhole: http://pastebin.com/k4BxrAeG (поместите правило в файл в /etc/fail2ban/actions.d)

Создайте файл фильтра привязки в / etc / fail2ban /filter.d с чем-то вроде этого (требуется отладка!)

[Definition]
failregex = ^.* security: info: client #<HOST>: query \(cache\) .* denied

Отредактируйте файл fail2ban.conf, добавьте раздел:

[bindban]

enabled  = true
filter   = bind
# "bantime" is the number of seconds that a host is banned.
bantime  = 6000
# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime  = 60
# "maxretry" is the number of failures before a host get banned.
maxretry = 150
action   = blackhole
logpath  = /var/log/named.log

Надеюсь, это поможет!

Вы пытались заблокировать строку isc.org или заблокировать для нее шестнадцатеричную строку?

У меня сработало:

iptables -A INPUT -p udp -m string - шестнадцатеричная строка "| 03697363036f726700 |" --algo bm -j DROP

Во-первых, я знаю, что это старый вопрос, но ...

Я использовал свой авторитетный, нерекурсивный DNS-сервер на протяжении десятилетий, но никогда не был жертвой любые DDoS-атаки на основе DNS - до тех пор, пока я не переключился на нового провайдера. Тысячи поддельных DNS-запросов наводнили мои журналы, и я был действительно раздражен - не столько из-за воздействия на мой сервер, сколько из-за того, что он загромождал мои журналы, и из-за неприятного ощущения злоупотребления. Похоже, что злоумышленник пытается использовать мой DNS в « атаке на авторитетный сервер имен ».

Я решил, что, хотя я ограничиваю рекурсивные запросы своей внутренней сетью (отрицая все остальные), я я лучше трачу циклы процессора на сопоставление строк в iptables, чем на отправку отрицательных ответов на поддельные IP-адреса (меньше беспорядка в моих журналах, меньше сетевого трафика и более высокий уровень моего собственного удовлетворения).

Я начал с того, что сделал все остальные, кажется, делают , выясняют, какие доменные имена запрашиваются, и создают строковое соответствие в этом домене с целевым DROP. Но вскоре я понял, что в итоге получу огромное количество правил, каждое из которых потребляет циклы процессора. Так что делать? Поскольку я не использую рекурсивный сервер имен, я решил, что могу выполнить сопоставление в реальных зонах, которые я ' чтобы увидеть счетчики пакетов (и байтов) для каждого правила в новой цепочке (вы можете переместить зону с наибольшим количеством пакетов в верхнюю часть списка, чтобы сделать его более эффективным).

В надежде, что кто-то сочтет это полезным :)

Эта атака называется усиленным отказом в обслуживании. Вы должны правильно настроить привязку, но этот трафик в первую очередь не должен попадать в вашу привязку. Заблокируйте его на первом сетевом устройстве, которое может это сделать в вашей сети. У меня была такая же проблема, и я решил ее с помощью правила глухого фырканья:

alert udp $ EXTERNAL_NET any -> $ HOME_NET 53 (msg: "PROTOCOL-DNS чрезмерные запросы типа ANY - потенциальный DoS"; byte_test: 1,! &, 0xF8,2; содержимое: «| 00 00 FF 00 01 |»; обнаружение_фильтра: отслеживать by_src, счет 30, секунд 30; метаданные: DNS службы; ссылка: url, foxpa.ws / 2010/07/21 / thwarting-the- isc-org-dns-ddos /; classtype: blocked-dos; sid: 21817; rev: 4;)

Основная идея: разрешить привязке классифицировать ответ DNS как Отказ, а затем использовать iptables для преобразования Отказанного в молчаливо игнорируемый.

Отказ - это простая часть в разделе параметров named.conf:

allow-recursion { none;};

Или, конечно, ваши любимые ACL для локальных исключений ...

Следующая безумная магия iptables, при необходимости измените или удалите "-o eth0". Эта команда предполагает стандартный 20-байтовый заголовок уровня IPv4 до UDP.

iptables -A OUTPUT -o eth0 -p udp --sport 53 -m string --from 30 --to 32 --hex-string "|8105|" --algo bm -j DROP

Эта команда включает поле флагов ответа DNS со следующими битами, установленными

• Ответ DNS
• Рекурсивный запрос
• Код ответа отклонен

Замечено сообщение журнала выполняет привязку в отладке «ошибка отправки ответа: хост недоступен», когда правило соответствует, чтобы получить некоторую обратную связь для тестирования.

Должен признать, что все это несколько бессмысленное упражнение. Если нет усиления, злоумышленник может так же легко отразить TCP SYN.

Как и вы, я не люблю, когда мой сервер участвует в DDOS, даже если он отвечает небольшими 30-байтными пакетами. Кроме того, по некоторым причинам я не могу использовать iptables для блокировки поддельных запросов. Уязвимость сервера была устранена 3 месяца назад, но ботнет по-прежнему отправляет поддельные запросы на сервер.

Таким образом, вы можете использовать этот простой патч, чтобы не отправлять ответ REFUSED (запросы будут отбрасываться):

--- bind9-9.9.5.dfsg/bin/named/query.c.orig        Thu Aug  6 21:56:57 2020
+++ bind9-9.9.5.dfsg/bin/named/query.c     Thu Aug  6 22:08:15 2020
@@ -1038,7 +1038,7 @@
                                         sizeof(msg));
                        ns_client_log(client, DNS_LOGCATEGORY_SECURITY,
                                      NS_LOGMODULE_QUERY, ISC_LOG_INFO,
-                                     "%s denied", msg);
+                                     "%s dropped", msg);
                }
                /*
                 * We've now evaluated the view's query ACL, and
@@ -5809,8 +5809,9 @@
                        } else
                                inc_stats(client, dns_nsstatscounter_authrej);
                        if (!PARTIALANSWER(client))
-                               QUERY_ERROR(DNS_R_REFUSED);
-               } else
+               //              QUERY_ERROR(DNS_R_REFUSED);
+                               QUERY_ERROR(DNS_R_DROP);
+               } else
                        QUERY_ERROR(DNS_R_SERVFAIL);
                goto cleanup;
        }
# diff -u query.c.orig query.c

... в результате вы получите красивые логи, подобные этому:

Aug  6 21:39:29 topor named[2652]: client 78.180.51.241#43072 (.): query (cache) './ANY/IN' dropped
Aug  6 21:40:00 topor last message repeated 1485 times

не должно быть ответа «ОТКАЗАНО», если запрос поступил из неавторизованной сети / для неподдерживаемого домена.