☰

Enlace: consulta (caché) './ANY/IN' denegada: ¿es un ataque DDos?

tag-icon • tag-icon domain-name-system bind named-conf
Enlace: consulta (caché) './ANY/IN' denegada: ¿es un ataque DDos?

Mi syslog aparece flotando con mensajes como

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

y no sé si se trata de un ataque DDoS o simplemente un comportamiento extraño de vinculación.

Así que configuré una cárcel fail2ban simple que bloquea las IP que producen más de 20 errores de este tipo en 24 horas. Después del fin de semana lo comprobé y me quedé asombrado: se han bloqueado más de 1000 IP. Incluyendo los famosos como 1.1.1.1. Entonces esto no puede ser correcto.

Mi servidor es un Debian 9 administrado a través de Plesk Obsidian. No he realizado ninguna configuración especial para bind9/named (hasta donde yo sé). Es el servidor ns principal para todos mis dominios.

Entonces la pregunta es: ¿Qué puedo hacer para proteger mi servidor contra tal avalancha de consultas DNS o debería simplemente ignorarlas?

Respuesta1

Es difícil decirlo definitivamente, pero a primera vista parece que podría ser un intento de ataque de reflexión (o una prueba de la viabilidad de usar su servidor en tal ataque).

La idea detrás de tal ataque es enviar consultas a través de UDP con una dirección IP de origen falsificada a un servidor de resolución abierta para generar tráfico al objetivo del ataque (el host que realmente tiene la IP de origen falsificada), utilizando una consulta que se sabe que genera una gran respuesta para obtener una gran amplificación del ancho de banda del atacante necesario para enviar las consultas.

Suponiendo que ese sea el caso, las implicaciones son:

  • Usted no es el objetivo real, sino que simplemente pretende "prestar" su ancho de banda. La dirección de origen es quién supuestamente está siendo atacado (o quién está investigando si su servidor podría usarse para tales fines).
  • En realidad no funcionó. Como usted niega estas solicitudes, las respuestas no son tan grandes como lo . ANYsería la respuesta real. (Presumiblemente por no permitir la recursividad en primer lugar, lo cual es bueno).

En cuanto a su sensación de que parece legítimo porque una de las direcciones IP de origen es 1.1.1.1, diría que mi reacción instintiva es exactamente lo contrario. Ver 1.1.1.1la dirección de origen de esta consulta indica inmediatamente que algo extraño está sucediendo:

  • Sabemos que 1.1.1.1es anycast, lo que hace que sea una mala idea iniciar consultas desde esta dirección. Si responde a una consulta, 1.1.1.1su respuesta se enrutará a la 1.1.1.1instancia más cercana (en el sentido de BGP), no a la que generó la consulta.
  • Incluso ignorando la elección de la dirección de origen, ¿por qué el solucionador público de Cloudflare alguna vez enviaría una consulta a su servidor . ANY? Usted no es la autoridad .y ellos tampoco tienen motivos para enviarle consultas.

Es decir, creo que tiene razón en que estas consultas probablemente "no traen nada bueno".
Ahora bien, no estoy tan seguro de si es una buena idea bloquear el tráfico de estas direcciones. El problema aquí es que se abre a ataques DoS fáciles. Alguien puede utilizar este comportamiento de bloqueo suyo para hacer que su servidor deje de responder a consultas de direcciones arbitrarias, de las que se podría abusar para denegar tráfico legítimo.

información relacionada