DNS DDOS Attack - хотел бы понять лог

Как часть атаки DOOS (в основном неэффективной) я сейчас вижу сообщения журнала в форме:

<DATE> client <EXTERNAL-IP>#3074 (<NAME>): query: <SAME-NAME> IN RRSIG + (<ONE-OF-MY-IPs>)

Мое чтение журнала DNS предполагает, что это запрос, поступающий от <EXTERNAL-IP>, с результатом, который будет отправлен на <ONE-OF-MY-IP>. Это правильно?

Мы используем более старую версию BIND, которая скоро будет обновлена, но я надеялся понять, что на самом деле делает этот запрос (многие отправляются).

Изменить: Кроме того, было бы неплохо узнать, как они могут структурировать его для отправки результата на другой IP-адрес.

Формат журнала запросов BIND

Вы следовали за Аланом Клеггом (ISC) слайды по BIND Logging? На странице 16 говорится неправильно:

Адрес, на который отправляется ответ (в скобках)

Справочное руководство администратора BIND 9 сообщает, что на самом деле это адрес, по которому запрос был отправлен, т.е. IP-адрес вашего DNS-сервера. Структуру руководства непросто читать и ссылаться на нее, поэтому вот полный путь к соответствующей документации:

Из Справочного руководства версии 9.14.11,
- Глава 5. Справочник по настройке BIND 9,
  - Грамматика файла конфигурации,
    - logging Определение и использование утверждения,
      - В category Фраза,
        
        queries

Более четкое форматирование и акцент мой:

Запись журнала запросов сначала сообщает об идентификаторе объекта клиента в @0x<hexadecimal-number> формат.

Затем он сообщает IP-адрес и номер порта клиента, и

имя, класс и тип запроса.

Далее он сообщает

установлен ли флаг Recursion Desired (+ если установлено, - если не установлен),

был ли запрос подписан (S),

использовалась ли EDNS вместе с номером версии EDNS (E(#)),

использовался ли TCP (T),

установлен ли DO (DNSSEC Ok) (D),

был ли установлен CD (проверка отключена) (C),

был ли получен действительный DNS-сервер COOKIE (V), и

присутствовала ли опция DNS COOKIE без действительного COOKIE сервера (K).

После этого сообщается адрес назначения, на который был отправлен запрос.

Наконец, если в запросе клиента присутствовала какая-либо опция CLIENT-SUBNET, она включается в квадратные скобки в формате [ECS address/source/scope].

Так в:

info: client @0xf00 203.0.113.88#3074 (example.com): query: example.com IN RRSIG + (192.0.2.1)

203.0.113.88#3074 это IP-адрес и порт клиента
example.com это имя запроса, IN класс, и RRSIG тип (RFC 4034, 3)
+ сообщает, что клиент запросил рекурсию
192.0.2.1 это IP-адрес вашего DNS-сервера, на который был отправлен запрос

Атаки с усилением DNS и способы их устранения

В этой записи журнала нет никаких признаков DDoS-атаки. как таковой, и ответ отправляется обратно клиенту 203.0.113.88#3074. Если IP-адрес клиента был подделан, то усиление атаки об ответе на RRSIG запрос намного больше исходного запроса.

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

Незапрошенные ответы DNS отбрасываются, если / когда они достигают целевой машины, но к тому времени, когда они это сделали, они израсходовали сетевые ресурсы и небольшую часть процессорного времени на целевой машине.

Чтобы смягчить это, в зависимости от вашей ситуации:

Если это авторитетный сервер, не допускайте открытой рекурсии. Это исходит непосредственно от IANA Технические требования к авторитетным серверам имен:

Нет открытой рекурсивной службы имен

Авторитетные серверы имен не должны предоставлять рекурсивную службу имен. Это требование проверяется отправкой запроса за пределами юрисдикции органа с установленным битом «RD».

Если это рекурсивный сервер имен, ограничьте доступ только к вашим собственным сетям, которым должно быть разрешено использовать эту службу. Это можно сделать с помощью allow-query или allow-recursion.

allow-recursion

Указывает, каким хостам разрешено делать рекурсивные запросы через этот сервер. Если allow-recursion не установлен тогда allow-query-cache используется, если установлено, иначе allow-query используется, если установлено, в противном случае используется значение по умолчанию (localnets; localhost;) используется.
Ты можешь использовать Ограничение скорости ответа:
Чтобы позволить RRL защищаться от этого, отредактируйте named.conf и добавьте следующее rate-limit пункт к глобальным параметрам:
```
options {
         … 
          rate-limit {
              responses-per-second 10;
          };
      };
```
Это более подробно объясняется в официальной документации под options Определение и использование утверждения: Ограничение скорости ответа. Там вы можете найти
- почему и как использовать slip для усечения ответов (по умолчанию со значением 2)
- использовать qps-scale для усиления защиты во время атак.