[GTER] DDoS de ontem e o de amanhã - Lições Aprendidas?

[Patrick Tracanelli]

Senhores,

Eu não sei se alguem teve o desprazer de estar conectado no IXP Ashburn durante a última brincadeirinha de DDoS causada por um único esquentadinho contra o SpamHaus. Os 300Gbps de tráfego vocês sabem causou lag geral, não só no Netflix, AppStore, etc; infelizmente um cliente meu conectado em Ashburn também, e ao tentar ver de perto, o tcpdump de tráfego udp na porta 53 gerava tanto volume que minha sessão ssh desconectava.

Depois que o negocio começou ser contido e observando a taxonomia do ataque eu fui fazer um teste simples aqui dos nossos participantes do PTT-Metro.

Pois bem, segue um dado alarmante na minha humilde opinião.

De todos os participantes do PTT-SP, PTT-MG, PTT-DF, PTT-RJ e PTT-BA, 38% tem seus servidores DNS primário para seu domínio principal com recursion aberto para o mundo. 

O teste eu fiz da forma mais simples possível, colocando um registro DNS novo e aleatório num dominio q mantenho e rodando um shell pra fazer dig desse registro na base de ns1.

Com whois -h whois.registro.br <ASN> eu peguei o CIDR e o dominio de cada participante e depois com whois de novo os name servers configurados para dominio ou nserver pro CIDR (reverso).

Pois bem, servidores DNS que pro mundo deveriam responder apenas consultas de autoridade, responderam pra um IP da califórnia, recursivamente.

Estamos falando de participantes do PTT Metro, por natureza "bem conectados" abrindo margem pra serem usados em mais um ataque eventual de amplificação DNS.

Como complemento, com dig testei validação de DNSSEC nesses servidores, e 12% se mostraram com "dnssec-validate yes" (ou equivalente).

Bom não sei se todos concordam comigo, mas pra mim isso é sério. O mínimo que um participante de um IXP/PTT deveria ser obrigado, é tomar conta pelo menos da sua própria cozinha, já que da cozinha alheia (potencial cliente ou transportado do participante) é uma outra conversa.

Forçar boas práticas de configuração aos participantes, transformar em pre-requisito, são minha primeira sugestão pra esse grupo de trabalho. Automação de testes como esse que eu fiz é trivial, lightweight, não intrusivas e testam o mínimo de responsabilidade dos participantes. 

Ontem o Demi twitou sua percepção sobre a perda de posições do Brasil no ranking de SPAM associando o fato a gerência da porta 25. Gerencia da porta 25 é outra prática que eu acho que deveria ser requisito testado dos participantes do PTT Metro.

Infelizmente não é tão trivial separar respostas DNS recursivas da autoritativas como submit-smtp de smtp MX. Não temos uma porta diferenciada pra recursão ou autoridade DNS, envolve análise de payload. Mas… um probe simples como eu fiz é trivial.

Se tivessemos participantes mais pro-ativos, eles testes poderiam ser feitos por iniciativa propria. O Rubens me lembrou ainda dos serviços prestados pelo Mauch (gratuito) e Team Cymru (gratuito por um periodo, depois pago) que testam recursão aberta pro mundo, ou seja mastigado pra quem não tem como testar de fora pra dentro facilmente.

Não sei se todos estão cientes aqui (todos creio que não) mas há alguns anos atrás o Daniel Julius Bernstein (qmail, djbdns, etc) publicou um paperzinho (irresponsavelmente? full disclosure pra que te quero…) ensinando com meia duzia de awk/sed/dig como gerar amplificação de 5x com DNSSEC e usou o twitter.com e logico isc.org e vixie.org de exemplo. Gerou 20Gbit/s de tráfego pra cima do twitter. De 1 única máquina iniciando a amplificação. Hoje spamhaus não tem mais DNSSEC publicado e se vocês derem dig +dnssec no twitter.com verão que twitter também não.

Mas ontem não foi apenas DNSSEC usado na amplificação contra o SpamHaus. E me da medo ver que quase 40% dos DNS primários dos participantes do PTT Metro são potenciais geradores de tráfego cuja capilaridade em bps e pps somada eu prefiro não tentar estimar, contra qualquer alvo.

Não sei se todos compartilham da minha certeza que estamos há pelo menos 2 anos vivendo numa guerra fria novamente. E não estou falando de Korea do Norte e seu kim rin-tin-tin ameaçando nuclearmente skorea, eua e israel. Estou falando dos Chineses vs NSA. Huawei vs Mandiant vs NSA vs Senado americano; tao ai dropbox, linkedin, apple, facebook, twitter, falhas de 0day massiva em java, adobe, exploradas pelos chineses (algumas vendidas por greyhats researchers brasileiros, btw). Temos worm instalando proxy de proposito geral em uma taxa de mais de 20 mil androids por dia… uma potencial botnet de dispositivos móveis controlada "sabe deus por quem" prontinhas pra entrar em operação, em dispositivos móveis, colocando a expressão "DDoS" em um novo patamar. Uma "moving DDoS" em potencial com os dispositivos roaming entre redes wifi e 3G/LTE da residencia do proprietario, empresa, starbucks da esquina, aeroportos, etc; algo além do que se consegue com webLOICs. 

Isso somado a uma infra-estrutura de Internet da década de 80, com BGP, DNS, SMTP e pilha IPv4 praticamente sem evolução relevante de arquitetura, por si só, já assombra.

Somar a isso tudo uma postura não responsável dos operadores de rede participantes do PTT Metro é, na minha opinião, ainda pior.

Acho que probes de posturas responsáveis aos participantes do PTT antes da ativação (e potencialmente durante, por amostragem) algo simples de ser feito e com potencial indicação de problema. Deveria ser requisito pre-ativação. Por mais que não seja o objetivo do PTT-Metro acho que um Suricata identificando DNS com recursão aberta, e gerando como active-response uma notificação ao participante do PTT, outra ação possível, leve e fácil. Não sei se isso fere alguma regra de participação mas pelo q me lembro não. 

Não sei se mais alguém se importa ou se preocupa, mas se esse grupo de trabalho achar benéfico e quiser se agrupar pra trabalhar, de maneira formal, discutir, enumerar, podem contar comigo no apoio a um PTT Metro com participantes mais responsaveis.

Estar no PTT sem dúvidas é algo benéfico pra todo mundo, sobre a ótica de negócio, qualidade, possibilidades de interconexão, e diversos outros quesitos avaliados de negócio. Mas a capilaridade de um IXP pode também se tornar uma arma, IMHO.

Vespera de feriado acho que vou ficar falando sozinho hehe ;-)

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 at sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"