%20'.%2FANY%2FIN'%20%D0%BE%D1%82%D0%BA%D0%BB%D0%BE%D0%BD%D0%B5%D0%BD%20%E2%80%94%20%D1%8D%D1%82%D0%BE%20DDoS-%D0%B0%D1%82%D0%B0%D0%BA%D0%B0%3F.png)
Мой системный журнал переполнен сообщениями типа
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-атак. Кто-то может использовать это ваше блокирующее поведение, чтобы заставить ваш сервер перестать отвечать на запросы с произвольных адресов, что может быть использовано для запрета легитимного трафика.