Invasão Servidor DNS [bind9] [RESOLVIDO]

verner_inec
(usa Debian)

Enviado em 05/09/2013 - 14:32h

Boa tarde pessoal!

Ultimamente temos notado que a velocidade da internet estava caindo muito, então verificamos que estamos sofrendo um ataque.
Com o comando: tcpdump -i net0 -nv port 53, aparece a linha a seguir milhões de vezes:

..... > 10.1.1.3:53: ......[1au] ANY xxx.com. (39)

O Ip aqui é fixo, então mesmo reiniciando o BIND e a conexão da internet isso volta.

Se alguém puder nos ajudar, obrigado!

danniel-lara
(usa Fedora)

Enviado em 05/09/2013 - 14:44h

usa o fail2ban
pra monitorar a porta do bind e ajuda para bloquear esse ip

rosnei
(usa Debian)

Enviado em 06/09/2013 - 18:20h

É necessário que seu servidor não esteja habilitado em /etc/bind/named.conf

recursion on;

mais informações em

http://www.cert.br/docs/whitepapers/dns-recursivo-aberto/

mude para

#recursion no;

Se estiver recebendo algo parecido com isto:

System Events
=-=-=-=-=-=-=
Jan 21 06:02:13 www named[32410]: client 66.230.128.15#15333: query (cache)
+'./NS/IN' denied

Tente o pacote fail2ban do Debian. A página inicial do fail2ban é http://www.fail2ban.org

Primeiro instale o pacote fail2ban Debian.

#apt-get install fail2ban

Depois faça o diretório do arquivo de log de ligação.

#mkdir /var/log/named
#chmod a+w /var/log/named

Em seguida, edite o arquivo / etc / bind / named.conf.local e adicione as seguintes linhas

logging {
channel security_file {
file "/var/log/named/security.log" versions 3 size 30m;
severity dynamic;
print-time yes;
};
category security {
security_file;
};
};

Reinicie o Bind usando / etc/init.d/service bind9 restart

Teste para se certificar de que ainda está trabalhando e também verificar o arquivo de log/var/ log/named/security.log está enchendo:

#Tail –f /var/log/named/security.log

Resposta

21-Jan-2009 07:19:54.835 client 66.230.160.1#28310: query (cache) './NS/IN' denied

Caso não tenha nada no log será necessário dar permissão no arquivo security.log como foi no meu caso.

Configurando fail2ban. Edite o arquivo / etc/fail2ban/jail.conf e mude a partir de:

[named-refused-udp]

enabled = false
para:
[named-refused-udp]

enabled = true
e:
[named-refused-tcp]

enabled = false
para:
[named-refused-tcp]

enabled = true

Em seguida, reiniciar fail2ban

/Etc/init.d/fail2ban restart

Agora, verifique se fail2ban está fazendo algo, verificando o arquivo de log localizado em / var/log/fail2ban.log ele deve conter algo como

2009-01-21 fail2ban.actions 07:34:32,800: WARNING [nome-recusou-udp] Ban 76.9.16.171
2009-01-21 07:34:32,902 fail2ban.actions: WARNING [nome-recusou-tcp] Ban 76.9.16.171

Verifique se fail2ban está modificando as regras do iptables

iptables-L

Agora, verifique se as regras do iptables do fail2ban são realmente parar de acesso

tail-f /var/log/named/security.log

Mensagens de erro de DNS devem ser de vários minutos de intervalo em vez de múltiplas por segundo.
Só com isso consegui resolver meu dilema.

Fontes originais de pesquisa
http://www.debian-administration.org/article/Blocking_a_DNS_DDOS_using_the_fail2ban_package
http://www.cert.br/docs/whitepapers/dns-recursivo-aberto/
A força de um guerreiro não se encontra no ataque, mas sim em ficar de pé em um forte ataque!!!