☰

Bind: consulta (cache) './ANY/IN' negada - é um ataque DDos?

tag-icon • tag-icon domain-name-system bind named-conf
Bind: consulta (cache) './ANY/IN' negada - é um ataque DDos?

Meu syslog está recebendo mensagens 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

e não sei se isso é um ataque DDoS ou apenas um comportamento estranho de ligação.

Então eu configurei uma prisão fail2ban simples que bloqueia IPs que produzem mais de 20 desses erros em 24h. Depois do fim de semana verifiquei e fiquei surpreso: mais de 1000 IPs foram bloqueados. Incluindo alguns famosos como 1.1.1.1. Então isso não pode estar certo.

Meu servidor é um Debian 9 gerenciado via Plesk Obsidian. Não tenho nenhuma configuração especial feita para bind9/named (até onde eu sei). É o servidor ns principal para todos os meus domínios.

Portanto, a questão é: o que posso fazer para proteger meu servidor contra uma enxurrada de consultas de DNS ou devo simplesmente ignorá-las.

Responder1

É difícil dizer com certeza, mas à primeira vista parece que poderia ser uma tentativa de ataque de reflexão (ou um teste para a viabilidade de usar seu servidor em tal ataque).

A ideia por trás de tal ataque é enviar consultas por UDP com um endereço IP de origem falsificado para um servidor de resolução aberta para gerar tráfego para o alvo do ataque (o host que realmente possui o IP de origem falsificado), usando uma consulta que é conhecida por gerar um grande resposta para obter alta amplificação da largura de banda do invasor necessária para enviar as consultas.

Supondo que seja esse o caso, as implicações são:

  • Você não é o alvo real, mas sim apenas "emprestar" sua largura de banda. O endereço de origem é quem supostamente está sendo atacado (ou quem está investigando se o seu servidor pode ser usado para tais fins).
  • Na verdade não funcionou. Como você está negando essas solicitações, as respostas não são grandes como . ANYseria a resposta real. (Presumivelmente por não permitir a recursão em primeiro lugar, o que é bom).

Quanto à sua sensação de que parece legítimo porque um dos endereços IP de origem é 1.1.1.1, eu diria que minha reação instintiva é exatamente o oposto. Ver 1.1.1.1o endereço de origem desta consulta indica imediatamente que algo estranho está acontecendo:

  • Sabemos que 1.1.1.1é anycast, o que torna uma péssima ideia iniciar consultas a partir deste endereço. Se você responder a uma consulta, 1.1.1.1sua resposta será roteada para a 1.1.1.1instância mais próxima (no sentido de BGP), não para aquela que gerou a consulta.
  • Mesmo ignorando a escolha do endereço de origem, por que o resolvedor público da Cloudflare enviaria uma consulta ao seu servidor para . ANY? Você não é a autoridade .e eles também não têm motivos para encaminhar dúvidas para você.

Ou seja, acho que você está certo ao dizer que essas consultas provavelmente "não são boas".
Agora, não tenho tanta certeza se é uma boa ideia bloquear o tráfego desses endereços. O problema aqui é que ele abre espaço para ataques DoS fáceis. Alguém pode usar esse seu comportamento de bloqueio para fazer com que seu servidor pare de responder a consultas de endereços arbitrários, que podem ser abusados ​​para negar tráfego legítimo.

informação relacionada