Некоторое время я получал много DNS-запросов, но они время от времени приходили и уходили. Теперь он превратился в DDOS, когда несколько IP-адресов отправляют трафик одновременно. Скорость загрузки сильно загружала мое интернет-соединение. Я отключил рекурсию (она была включена по умолчанию), вероятно, это и было первопричиной проблемы. Но теперь где-то в даркнете кто-то написал, что на моем сервере включена (была) рекурсия. Итак, я включил ограничение скорости отклика с ограничением в 10 секунд. Теперь я получаю (только, ха-ха!) Около 6 миллионов запросов в день! Это разгрузило сетевое соединение, но мой файл журнала достигает нескольких сотен МБ в день. Сообщения выглядят так:
Jul 22 11:03:05 jelinux named[26058]: client 54.36.104.65#10683 (access-board.gov): query (cache) 'access-board.gov/ANY/IN' denied
Jul 22 11:03:05 jelinux named[26058]: client 54.36.104.65#10683 (access-board.gov): rate limit drop REFUSED error response to 54.36.104.0/24
Есть ли способ уменьшить объем трафика сообщений? Я хотел бы вести отчет об отклоненных IP-адресах, но, возможно, всего одна строка отчета для каждого IP-адреса каждую минуту или около того сообщила бы мне столько же о количестве атакующих IP-адресов и количестве запросов.
С отключенной рекурсией вы, вероятно, уже по существу тратите ресурсы злоумышленника (вы отправляете крошечные REFUSED ответы вместо большого ответа на ANY запрос, который они пытались сделать, так что больше никакого усиления), они просто еще не заметили, что они, вероятно, получат гораздо больше от использования других широко открытых рекурсоров. Возможно, поток запросов скоро закончится сам по себе.
Как вы отметили, встроенный механизм в BIND Ограничение скорости ответа, который можно настроить различными способами, включая отправку усеченных ответов, чтобы заставить реальных клиентов переключиться на TCP (полезно для обычных ответов, но вы уже отправляете REFUSED) или сразу отказаться от ответов. Тем не менее, он разработан таким образом, чтобы сервис оставался максимально доступным, что означает, что никого нельзя полностью отключать.
Хороший момент из раздела RRL руководства BIND (который также применим к любому другому решению, которое включает отбрасывание ответов) - это то, как отброшенные ответы на авторитетном сервере могут сделать вас более легкой мишенью для атак с отравлением кеша:
ПРИМЕЧАНИЕ. Отброшенные ответы от полномочного сервера могут снизить сложность успешного создания ответа третьей стороной рекурсивному преобразователю. Лучшая защита от поддельных ответов - это для уполномоченных операторов подписывать свои зоны с помощью DNSSEC, а для операторов распознавателей - для проверки ответов. Если это не вариант, операторы, которые больше озабочены целостностью ответа, чем смягчением последствий наводнения, могут рассмотреть возможность установки для скольжения значения 1, что приведет к усечению всех ответов с ограничением скорости, а не отбрасыванию. Это снижает эффективность ограничения скорости против атак отражения.
Есть и другие варианты, например dnsdist который вы можете разместить в качестве обратного прокси впереди и иметь его динамически отклонять или отбрасывать клиентов, которые превышают допустимую частоту запросов. Здесь хорошо то, что dnsdist, как следует из названия, поддерживает DNS и довольно гибкий. Таким образом, у вас будет возможность, например, агрессивно ограничивать ANY только запросы и / или rcode REFUSED, не влияя на другие запросы (не влияя на другие запросы, может быть основано на обычные правила вместо).
Также, как отметил Майкл, fail2ban который может динамически добавлять правила брандмауэра для блокировки IP-адресов на основе чрезмерного количества записей в журнале. Это немного грубо в сравнении, но, безусловно, было бы эффективным с точки зрения ограничения трафика и спама в журналах, но полностью отбрасывает трафик после его запуска.
Опять же, для любого варианта, связанного с отбрасыванием запросов, помните вышеупомянутое примечание об отравлении кеша.