Comecei a escrever sobre o maior ataque de negação de serviço (DDOS) conhecido pela mídia. Deixar isso bem claro e um papo para um outro post.

Pois bem, comecei a escrever, pesquisar material, vídeos e tal. Acabo me deparando com o artigo do Suffert. Como sempre, o autor consegue passar os detalhes mais importantes.

Antes de colocá-lo/copiá-lo para o pessoal entender – Suffert, este breve post sobre o caso em pauta foi uma piada. hehehe

A “grande mídia” começou a cobrir com mais frequência incidentes relacionados à cibersegurança, e hoje várias fontes publicaram notícias sobre os efeitos de ataques que foram motivados pela briga entre duas empresas holandesas, a SpamHaus (que mantém listas para bloqueios de spam) e a CyberBunker (que hospeda vários spammers e possui como um de seus clientes a WikiLeaks).

Como o assunto começou a ser também comentado aqui no Brasil, resolvi escrever este breve post sobre o caso em pauta.

Ataques Distribuídos de Negação de Serviço (Distributed Denial of Service – DDOS) são uma realidade – e um problema – na Internet há muito tempo. Eles ocorrem diariamente, mas geralmente não tem um efeito noticiável nas redes e computadores que não são alvos ou origem dos ataques distribuídos. O mais importante é antes de mais nada deixar claro que um ataque de negação de serviço não “invade” os computadores e redes afetados, mas impede que eles se comuniquem, tendo um efeito desastroso na disponibilidade de serviços online.

Um outro ponto importante a  se considerar é que existe uma dificuldade significativa na atribuição de responsabilidade em ataques de negação de distribuídos, especialmente pelo volume de origens utilizadas (usualmente botnets ou farms de servidores em nuvem) e pela possibilidade de se forjar (spoofar) os endereços de origem em certos tipos de ataque (mais informações abaixo).

Este tipo de ataque é também muito utilizado por Hacktivistas para protestar contra empresas ou contra o governo (há  inclusive uma tentativa de ‘legalizar’ deste tipo de ataque como protesto nos Estados Unidos e na Inglaterra). Há também quem julgue que este tipo de ataque é uma forma de censura, por “calar” o inimigo à força.

As legislações de vários países consideram este tipo de ataque um crime, incluindo a nova legislação que cobre os chamados “crimes eletrônicos”, que entrará em vigor na semana que vem em Brasil.

Lei n° 12.737 :


Art. 3o  Os arts. 266 e 298 do Decreto-Lei no 2.848, de 7 de dezembro de 1940 – Código Penal, passam a vigorar com a seguinte redação:

“Interrupção ou perturbação de serviço telegráfico, telefônico, informático, telemático ou de informação de utilidade pública

Art. 266.  ………………………………………………………………

§ 1o  Incorre na mesma pena quem interrompe serviço telemático ou de informação de utilidade pública, ou impede ou dificulta-lhe o restabelecimento.

§ 2o  Aplicam-se as penas em dobro se o crime é cometido por ocasião de calamidade pública.” (NR)

Existem várias técnicas diferentes que podem ser utilizadas para efetuar um ataque do tipo DDOS, incluindo a utilização de Botnets (criadas ou alugadas), a utilização de “Booters” como no caso recenteataque ao site do BrianKrebs, a utilização de ferramentas com o consentimento do usuário para ataques de grupos (como o Hoic/Loic), entre outros. Entre todas elas, a mais eficiente foi a utilizada neste caso.

[ Ataques de Negação de Serviço Distribuídos utilizando Servidores DNS Recursivos Abertos ]

No caso em pauta (a briga entre duas empresas holandesas), de um lado temos a SpamHaus  – responsável por lutar contra os spammers, através de blacklists utilizadas por grande parte dos servidores de email do mundo para evitar spams de redes reconhecidamente problemáticas, e de outro o CyberBunker – empresa de hospedagem que é um paraíso para spammers e outros cibercriminosos – seus termos de uso só banem a pornografia infantil e o terrorismo, o resto vale!

A CyberBunker (e possivelmente outros atores ainda não identificados) estava se sentindo incomodado pela frequente inclusão de suas redes nas listas negras da SpamHaus, e decidiu reagir de forma bastante ruidosa.

O ataque massivo de DDOS teve como o alvo o site da SpamHaus ese iniciou no dia 19 de março, mas nos dias subsequentes ele cresceu muito, a ponto de gerar lentidão na comunicação de algumas redes em diferentes lugares do mundo.

Os ataques que inicialmente se direcionavam à SpamHaus (dia 19,75Gbs) foram progredindo para seus fornecedores de conectividade (upstream providers) e chegaram até as redes que formam a infraestrutra de conectividade da internet (IX – internet exchange). Na imagem abaixo, divulgada pela CloudFlare, é visível o efeito do ataque no London Internet Exchange (também foram afetados os IX de Amsterdam, Frankfurt e Hong Kong. No pico do ataque o trhoughput foi de 300Gbps (300 Gigabytes por segundo).

No dia 20, a empresa chegou a comemorar a resolução do problema com o post The DDoS That Knocked Spamhaus Offline (And How We Mitigated It) – detalhes abaixo (as ênfases foram incluídas por mim):

“In the Spamhaus case, the attacker was sending requests for the DNS zone file for ripe.net to open DNS resolvers. The attackerspoofed the CloudFlare IPs we’d issued for Spamhaus as the source in their DNS requests. The open resolvers responded with DNS zone file,generating collectively approximately 75Gbps of attack traffic. The requests were likely approximately 36 bytes long (e.g. dig ANY ripe.net @X.X.X.X +edns=0 +bufsize=4096, where X.X.X.X is replaced with the IP address of an open DNS resolver) and the response was approximately 3,000 bytes, translating to a 100x amplification factor.

We recorded over 30,000 unique DNS resolvers involved in the attack. This translates to each open DNS resolver sending an average of 2.5Mbps, which is small enough to fly under the radar of most DNS resolvers. Because the attacker used a DNS amplification, the attacker only needed to control a botnet or cluster of servers to generate 750Mbps — which is possible with a small sized botnet or a handful of AWS instances. It is worth repeating: open DNS resolvers are the scourge of the Internet and these attacks will become more common and large until service providers take serious efforts to close them.”

Ou seja a CloudFlare  ao redirecionar os pacotes que tinham como endereço os IPs do alvo (SpamHaus) para múltiplos IPs espalhados em vários continentes, aliviou o efeito do ataque e permitiu uma melhor conectividade para as redes próximas ao alvo, mas (potencialmente) afetou as demais redes para onde o tráfego foi redirecionado. Isto normalmente nem é percebido para ataques menores, mas este ataque de 300Gbps, foi diferente.

Um vídeo muito interessante sobre ataques de negação de serviço distribuídos utilizando amplificação de DNS foi feito pelo Team Cymru (também parceiro da Apura):




[ Mitigação / Defesa ]

Além dos serviços de mitigação comerciais existentes (#shamelessplugApura é parceira da SAIC/CloudShield e provê este tipo de serviço) – O que podemos fazer?

I – Em 2009 eu tive a oportunidade de fazer sugestões e revisar um excelente documento produzido pelo CERT.BR, entitulado “Recomendações para Evitar o Abuso de Servidores DNS Recursivos Abertos

A descrição dos passos do ataque pode ser vista nos parágrafos e imagem abaixo:

“Uma das técnicas de DDoS utilizadas atualmente envolve a exploração de servidores DNS recursivos abertos, para gerar grandes quantidades de tráfego de resposta DNS para uma vítima cujo endereço IP está sendo forjado.

Um dos problemas fundamentais explorado nesses ataques é o fato do sistema de DNS utilizar UDP (Internet User Datagram Protocol) como protocolo principal de comunicação. Como este protocolo não requer o estabelecimento de uma sessão entre o cliente e o servidor e não possui métodos de autenticação, fica facilitada a ação de forjar a origem de uma consulta DNS.

1 – O atacante publica um registro muito grande, em geral TXT, em um servidor DNS sob seu controle (muitas vezes esse pode ser um servidor previamente comprometido pelo atacante).
2 – O atacante, de posse de uma lista de servidores DNS recursivos abertos, envia a estes servidores centenas ou milhares de consultas pelo registro publicado no passo 1, forjando o endereço IP da vítima, ou seja, colocando o endereço IP da vítima como endereço de origem da consulta (2a). Deste modo, o atacante faz com que as respostas sejam enviadas para a vítima e não para a máquina que fez as consultas. Na primeira consulta recebida por um servidor recursivo este vai buscar a resposta no servidor controlado pelo atacante (2b), nas demais consultas a resposta será enviada diretamente do cache do servidor recursivo aberto.
Em diversos casos documentados as consultas feitas à lista de servidores abertos foram realizadas por uma grande quantidade de bots, o que em geral aumenta ainda mais o volume de tráfego sendo enviado para a vítima.
3 – A vítima recebe as respostas DNS, que costumam gerar uma amplificação de aproximadamente 10 a 80 vezes o tráfego inicial de consultas, pois, para uma consulta média de aproximadamente 50 bytes, podem ser retornados cerca de 4.000 bytes de resposta para a vítima.”
Para solucionar o problema dos servidores DNS recursivos abertos é necessário separar os servidores autoritativo e recursivo e atribuir políticas de acesso diferentes a cada um. Isto pode ser feito de duas maneiras:
Colocando os servidores DNS em computadores diferentes, com configurações e políticas de acesso diferentes; ou Utilizando o conceito de views (visões ou vistas) do BIND 9 (Berkeley Internet Name Domain versão 9).

 

Para a lista completa de sugestões de mitigação para servidores DNS (BIND9 e Microsoft DNS), veja as instruções técnicas diretamente o site do CERT.BR.
II – Dicas importantes de mitigação utilizando DNS rate limit podem ser vistas no site da CloudShield: “3 Ways to Use DNS Rate Limit Against DDoS Attacks
III – O pessoal da Whitehat Security publicou um “DDoS RunBook” (formato .docx)  para auxiliar as empresas a se prepararem para este tipo de incidente de segurança, criando um plano de resposta. Se você faz parte de um time de segurança da informação ou CSIRT, recomendo.
 
IV – Uma dica valiosa para empresas/órgãos preocupados em não participar deste tipo de ataque por possuir servidores mal configurados em suas redes é fornecida no documento do CERT.BR (I) . Trata-se do serviço disponibilizado pelo “DNS Factory” – http://dns.measurement-factory.com/cgi-bin/openresolverquery.pl, onde qualquer um pode solicitar que a lista dos Open Resolvers sobre sua responsabilidade sejam enviadas para os emails de contato (RFC 2142) das redes em questão.
 
V – A Radware publicou um “DDoS Survival Handbook” – muito útil também.
VI – O Team Cymru, publicou um interessante documento sobre o histórico dos ataques de DDOS: http://www.team-cymru.com/ReadingRoom/Whitepapers/2010/ddos-basics.pdf
[ Outras leituras recomendadas sobre o tópico ]

 

Colocarei os meus comentários em um outro post, até porque este ficou grande pacas.. 🙂