[GTER] RES: DNS queries for "." (ddos reflection attack)
Luiz Otavio O Souza
luiz at visualconnect.com.br
Wed Jan 21 17:01:02 -02 2009
>>>
>>> De volta ao tópico, eu ainda estou tentando convencer o BIND a parar de
>>> responder (resposta negativa ainda é resposta!) a queries para o qual
>>> não
>>> tem autoridade (incluindo a query pelo root), em uma view que está
>>> configurada assim:
>>>
>>> recursion no;
>>> additional-from-auth no;
>>> additional-from-cache no;
>>>
>>> A única coisa que não tentei ainda foi arrancar o hint do root zone da
>>> view...
>>>
>
> Fiz testes com dois servidores (BIND 9.4.3-P1): um deles usando
> views, seguindo o artigo [1] e outro usando a configuração que eu já
> tinha antes desse "ddos" começar ( sem views e sem esses parâmetros
> "recursion" e "additional..."). Em ambos os casos, não há recursão
> para quem não é "trusted".
>
> Deixei os dois servidores rodando, cada um com uma configuração (
> um com a nova e outro com a antiga ). Não notei diferença alguma na
> resposta à query ".". Se observo as inúmeras conexões "spoofadas", no
> firewall, percebo que o BIND responde a cada uma das consultas com um
> pacote UDP de length=45 e nele há um "Refused".
>
> Se eu uso o comando "dig . NS @ip.meu.servidor +noall +answer
> +short" (de fora de minha rede e com IP não "trusted"), os pacotes
> parecem ter o mesmo comportamento daqueles gerados pela consulta
> spoofada. Isso acontece com os dois servidores (conf nova e conf
> velha).
>
> Usei o comando "tcpdump -n -i eth0 -XX -v -s512 host
> <src.ip.aqui> and <dst.ip.aqui>" para coletar as informações ( ainda
> sou "beginner" nessa história de tcpdump ).
>
> Também experimentei tirar a zone "." da view "external", mas nada
> mudou. Como eu tenho um servidor de DNS exclusivo para a minha rede
> interna (RFC 1918), o uso de views, no meu caso, não mudou muita
> coisa. Vou continuar analisando, ainda assim, uma forma de separar os
> recursivos dos autoritativos, tentando seguir as "melhores práticas".
>
> Fiz uma pergunta [2] em um fórum do dnsreport.com mas, até o
> momento, pelo dito, não há uma solução definitiva.
>
> Pelo visto, parte crucial desse problema é mesmo o spoofing. Por
> enquanto, fica a regra no firewall com o DROP.
>
> Obrigado pela atenção.
>
> P.S. se houver sugestões de leitura sobre spoofing e sobre como lidar
> (argumentação) com as operadoras (fornecedora do link) nesse caso, por
> favor, me informem. :-)
>
> Cássio
É Cássio... o problema é mais embaixo... e você embora beginner, fez o
certo... OLHOU o que esta acontecendo :)
A algum tempo o padrão de configuração do bind vem recomendando adicionar os
root zones como slaves para "agilizar" as respostas entre outras coisas:
/* Slaving the following zones from the root name servers has some
significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
3. Greater resilience to any potential root server failure/DDoS
...
*/
Mas isso torna todos os servidores configurados dessa maneira como
verdadeiros amplificadores desse ataque. Veja o que um dos meus servidores
bsd esta respondendo quando consultado:
# dig . NS @xxx.xx.xx.xxx +noall +answer +short
B.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
O servidor esta corretamente configurado para não fazer consultas
recursivas, porém como o root zone "." foi adicionado como slave o servidor
se entende como autoritativo para zona e responde... imagine o trafego que
esses retornos estão gerando para o dono do ip spoofado.
Façam os testes em seus servidores, pois com essa configuração, mesmo
servidores apenas recursivos (como é o caso do que citei) podem estar
gerando esse trafego indesejado.
[]'s
Luiz
PS: Não tenho certeza se essa recomendação é do bind ou do SO... sorry.
PS: o ítem 3 é hilário no momento... ajudou o root server a se livrar dos
ddos e deixou todo problema nas nossas mãos :)
More information about the gter
mailing list