[GTER] RES: RES: DNS queries for "." (ddos reflection attack)

[Wederson R. (CeBoLiNhA)]

Saudações,

O meu respondeu:

F.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
192.228.79.201


[]'s

-----------------------------------------
.'. Wederson Rodrigues .'.  (CeBoLaRk)
VIP - Vilhena Internet Provider
Gerente de T.I.

http://www.vipvilhena.com.br
MSN: cebolark at hotmail.com
SKYPE: cebolark
EMAIL: wederson at vipvilhena.com.br
Celular: 0xx69 8124-4697
-----------------------------------------

-----Mensagem original-----
De: gter-bounces at eng.registro.br [mailto:gter-bounces at eng.registro.br] Em
nome de Luiz Otavio O Souza
Enviada em: quarta-feira, 21 de janeiro de 2009 15:01
Para: Grupo de Trabalho de Engenharia e Operacao de Redes
Assunto: Re: [GTER] RES: DNS queries for "." (ddos reflection attack)

>>>
>>> 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 :)

--
gter list    https://eng.registro.br/mailman/listinfo/gter