Привязка: запрос (кэш) './ANY/IN' отклонен — это DDoS-атака?

Привязка: запрос (кэш) './ANY/IN' отклонен — это DDoS-атака?

Мой системный журнал переполнен сообщениями типа

Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied

и я не знаю, является ли это DDoS-атакой или просто странным поведением bind.

Поэтому я установил простую клетку fail2ban, которая блокирует IP-адреса, которые выдают более 20 таких ошибок в течение 24 часов. После выходных я проверил и был поражен: заблокировано более 1000 IP-адресов. Включая такие известные, как 1.1.1.1. Так что это не может быть правдой.

Мой сервер — Debian 9, управляемый через Plesk Obsidian. Я не делал никаких специальных настроек для bind9/named (насколько я знаю). Это основной ns-сервер для всех моих доменов.

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

решение1

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

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

Если предположить, что это так, то последствия таковы:

  • Вы не являетесь фактической целью, скорее, вы просто хотите "одолжить" свою пропускную способность. Адрес источника - это тот, кто предположительно подвергается атаке (или кто зондирует, чтобы проверить, может ли ваш сервер использоваться для таких целей).
  • На самом деле это не сработало. Поскольку вы отклоняете эти запросы, ответы не такие большие, как . ANYмог бы быть реальный ответ. (Предположительно, из-за того, что изначально не разрешается рекурсия, что хорошо).

Что касается вашего ощущения, что это кажется законным, потому что один из исходных IP-адресов — 1.1.1.1, я бы сказал, что моя инстинктивная реакция прямо противоположна. Видя 1.1.1.1в качестве исходного адреса для этого запроса, сразу видно, что происходит что-то странное:

  • Мы знаем, что 1.1.1.1это anycast, что делает ужасной идеей инициировать запросы с этого адреса. Если вы отвечаете на запрос с, 1.1.1.1ваш ответ будет направлен на ближайший (в смысле BGP) 1.1.1.1экземпляр, а не на тот, который сгенерировал запрос.
  • Даже игнорируя выбор исходного адреса, зачем публичному резолверу Cloudflare вообще отправлять запрос на ваш сервер для . ANY? Вы не являетесь уполномоченным лицом для .и у них также нет причин пересылать вам запросы.

То есть, я думаю, вы правы, что эти запросы, вероятно, "нехороши".
Теперь, является ли хорошей идеей блокировать трафик с этих адресов, я не уверен. Проблема здесь в том, что это открывает возможность для легких DoS-атак. Кто-то может использовать это ваше блокирующее поведение, чтобы заставить ваш сервер перестать отвечать на запросы с произвольных адресов, что может быть использовано для запрета легитимного трафика.

Связанный контент