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

Thu Mar 28 15:16:39 -03 2013

Peço a permissão para fazer alguns comentários...

On 28/03/2013 11:24, Patrick Tracanelli wrote:
> 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.

Compartilho o seu pensamento, tivemos a infelicidade (ou oportunidade) 
de travar uma "guerra" em nossa rede local com um hacker que utilizava 
uma jaula FreeBSD de um determinado cliente, da qual eu o observava 
através do host. Depois da massiva inserção de e-mails na fila deste 
servidor, defendido facilmente, a brincadeira ficou séria em cima dos 
serviços de DNS. Na época os links eram menores que os de hoje mas o 
ataque estava em rede local, me impressionava os efeitos devastadores de 
alguns simples aplicativos baixados de um servidor na Rússia em nossa 
rede local, por isso resolvi estudar o caso.

Não sei se por limitação minha mas não encontrei solução com o BIND, não 
tínhamos recursivo aberto para o mundo e o ataque tinha origem em uma 
rede interna nossa separada e isolada do restante mas obrigatoriamente 
deveria ser atendida pelos servidores recursivos. Foi neste momento que 
passei a concordar plenamente com D. J. Bernstein, separamos em máquinas 
distintas os servidores com autoridade sobre os domínios dos servidores 
recursivos, chegando na solução que temos hoje utilizando djbdns. Nesta 
configuração passamos pelo ataque com algumas falhas, diferente da total 
indisponibilidade da solução convencional adotada anteriormente.

>
> 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.

A motivação dos ataques em nossa rede local eram apenas para causar 
indisponibilidade em servidores de IRC, imaginem o potencial de uma rede 
LTE com bilhões de dispositivos com uma voraz motivação financeira por 
trás, me faz pensar que em um futuro muito próximo vamos conviver 
diariamente com indisponibilidades de serviços diversos, seria o caos da 
rede de celular brasileira implantada na inernet mundial.

Suponham a determinação financeira de baixar o valor de um Facebook ou 
qualquer outra empresa na NASDAQ, por exemplo, com o único objetivo de 
se obter lucros, com estas baixas. A compra de ações mais baratas por um 
determinado grupo financeiro que tem o "poder" de provocar uma 
diminuição no valor de uma empresa somente utilizando recursos 
computacionais já disponíveis, via ataques de negação de serviço, parece 
ser um negócio lucrativo, uma nova especulação de formato eletrônicom 
silenciosa no primeiro momento para o mundo dos negócios, mas totalmente 
controlável e implementável para quem detiver o conhecimento.

Quanto mais refinado e concentrado for este conhecimento mais perigoso 
vão se tornar os resultados desta guerra, para amplificar o problema, no 
ambiente empresarial as decisões hoje estão mais inclinadas para 
praticidade e efeitos visuais em detrimento da segurança. Vejo hoje 
"firewall" e outros ítens de segurança virtualizados, cadê a proteção do 
host das VMs? Está dentro de uma das VMs? Inúmeras redes utilizando 
servidores recursivo como o 8.8.8.8, fácil inserir um problema aqui, não 
concorda?

>
> 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.

Se você encontrou um cenário como este, respaldado pelo conhecimento que 
você tem e que neste cenário ainda não está acontecendo o que aconteceu 
em Ashburn, tenha certeza que o "inferno" para os administradores de 
rede está próximo e como se trata de Brasil somente depois de um grande 
evento haverá a busca para entender o que está acontecendo e suas soluções.

>   
>
> 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.

Acho que neste momento se for colocado em pauta esse assunto com os 
dirigentes dos negócios corre-se o risco do administrador ser taxado de 
paranóico. Vai ser necessário algumas falhas para provocar um movimento 
e que este movimento crie resultados semelhantes ao de Cristine Hoepers 
e Klaus Steding-Jessen em "Gerência da Porta 25".

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

Não falo muito mas esse assunto é instigante e foi muito interessante 
sua análise.

Paulo.

>
> --
> 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!"
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter