[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