Entendendo o último mês de ataques DDoS

F5

Neste artigo, analisaremos brevemente o impacto dos ataques de #DDoS sem precedentes ocorridos em setembro e outubro de 2016 e ofereceremos orientações para quem deseja aumentar sua resiliência.

Vamos comemorar a chegada da Internet das Coisas! Sabemos que ela finalmente chegou porque foi usada como arma cibernética três vezes desde setembro. Tudo começou com um ataque de grandes proporções ao jornalista e blogueiro Brian Krebs, cujo site krebsonsecurity.com era hospedado e protegido pela CDN da Akamai. O ataque foi grave o suficiente para afetar outros clientes da Akamai, levando a empresa a deixar de oferecer proteção gratuita ao blogueiro.

Pesquisadores do setor (incluindo os da F5) foram alertados sobre uma nova botnet composta por DVRs, câmeras de vídeo e outras “coisas”. Mas os DVRs e as câmeras de vídeo são relevantes porque têm tanto alta capacidade de processamento (podendo, portanto, hospedar malwares sofisticados) quanto conexões de upload de alta largura de banda (a partir das quais lançaram ataques de até 100 Mbps cada). O tráfego total do ataque direcionado a Krebs foi de 620 Gbps, o que, na época, representou o maior ataque DDoS do mundo.

O segundo ataque tirou do ar a OVH, a maior provedora de hospedagem da França (a terceira maior do mundo, segundo as publicações), durante boa parte de um dia. Muitas reportagens apontaram que o ataque à OVH teve quase o dobro do tamanho do ataque a Krebs, chegando a um terabit por segundo.

O terceiro e possivelmente pior ataque teve como alvo a Dyn, empresa de serviços de DNS. A Dyn é a provedora de DNS de muitos sites de destaque, incluindo Twitter, Spotify e GitHub (onde, ironicamente, o código da botnet de IoT foi publicado).

Então, quem fez isso?

Por uma estranha coincidência, no mês anterior, Bruce Schneier, uma figura de destaque do setor, vinha concedendo uma série de entrevistas nas quais alertava sobre a iminência de ataques DDoS de grande escala promovidos por Estados-nação. Suas informações privilegiadas vinham de fontes não identificadas do setor, que estavam detectando ataques DDoS de calibração contra a infraestrutura central da Internet.

Mas, ao que tudo indica, esses ataques de sondagem podem ter sido apenas uma coincidência. O próprio Schneier admitiu em seu blog que não acredita que o ataque à Dyn tenha sido realizado por um Estado-nação. Mas talvez esse Estado-nação esteja apenas observando e aguardando.

A chave para identificar os responsáveis nos casos Krebs, OVH e Dyn provavelmente virá do próprio Brian Krebs.

“O ataque à DYN ocorreu poucas horas depois de o pesquisador da DYN Doug Madory fazer uma palestra sobre ataques DDoS em Dallas, Texas, durante uma reunião do North American Network Operators Group (NANOG). …o ataque DDoS recorde de 620 Gbps contra o KrebsOnSecurity.com ocorreu poucas horas depois de eu publicar a matéria na qual Madory e eu colaboramos.”

É muito provável que o adversário seja um indivíduo (ou um pequeno grupo) com alguma motivação contra Brian Krebs, Doug Madory ou ambos.

Todos nós poderíamos entender que milhões de usuários seriam afetados por uma guerra cibernética em grande escala entre a China e os Estados Unidos. Mas e se isso acabar se revelando uma questão pessoal de um único indivíduo contra outro? Isso é ainda mais assustador do que um ataque de um Estado-nação. Que tipo de Internet construímos, se uma única pessoa ressentida com outra pode interromper serviços essenciais para milhões de pessoas?

Como chegamos até aqui?

A F5 vem monitorando a busca por dispositivos da Internet das Coisas (IoT) há mais de um ano. Nosso primeiro relatório sobre esse assunto foi publicado em julho de 2016 e mostrou um aumento de 140% em relação ao ano anterior nas varreduras de força bruta em telnet e SSH. Telnet e SSH são portas de administração remota amplamente utilizadas e, muitas vezes, são deixadas inadvertidamente expostas à Internet com o nome de usuário e as senhas padrão do fornecedor (ou fáceis de adivinhar).

Os ataques DDoS sem precedentes contra Krebs, OVH e Dyn, em outubro de 2016, usaram exatamente essa técnica (a varredura de portas telnet e senhas padrão de fabricantes em dispositivos de IoT) para criar uma botnet com recursos únicos.

Todos voltaram a ser alvos. Os controladores de botnets não têm medo de usar sua arma cibernética contra alguns dos maiores provedores do mundo — alvos que antes eram considerados intocáveis.

Embora possa parecer que esses ataques aconteceram da noite para o dia, na realidade, o controlador da botnet vem, há pelo menos um ano, procurando, encontrando e comprometendo lentamente dispositivos de IoT vulneráveis.

Análise detalhada do que sabemos

Na verdade, temos uma boa noção dos recursos da botnet de IoT Mirai. Os pesquisadores da F5 publicaram uma análise técnica detalhada do bot Mirai pouco depois de seu autor divulgar o código-fonte no hackforums.net.

O poder de ataque coletivo provavelmente é uma ordem de grandeza maior que o das botnets anteriores, ultrapassando terabits por segundo.

A botnet de IoT inclui, entre outras, as seguintes técnicas avançadas de DDoS. A seção de orientações prescritivas abaixo apresentará recomendações sobre como mitigá-las, quando possível.

Inundações de HTTP GET resistentes a redirecionamento

Os floods de HTTP GET já eram nocivos. Há anos, invasores conseguem tirar sites do ar enviando uma enxurrada de solicitações HTTP para objetos grandes ou consultas lentas a bancos de dados. Normalmente, essas solicitações atravessam diretamente um firewall padrão, pois, para a maioria dos dispositivos com processamento de pacotes por hardware, elas parecem solicitações HTTP comuns. O código de ataque do Mirai vai além: identifica os sistemas de mitigação de DDoS baseados em nuvem e contorna todos os redirecionamentos 302 que eles retornam. Os redirecionamentos costumavam ser uma boa maneira de frustrar bots simples, mas este não é simples.

Tortura da Água no DNS

O bot Mirai inclui um ataque de “tortura por água” contra um provedor de DNS alvo. Essa técnica difere dos ataques convencionais de reflexão e amplificação de DNS porque exige que o bot envie um número significativamente menor de consultas, permitindo que o servidor DNS recursivo do provedor de internet execute o ataque contra o servidor DNS autoritativo alvo. Nesse ataque, o bot envia uma consulta DNS bem-formada contendo o nome de domínio alvo a ser resolvido e acrescenta a ele um prefixo gerado aleatoriamente. O ataque se torna eficaz quando o servidor DNS alvo fica sobrecarregado e deixa de responder. Em seguida, os servidores DNS do provedor de internet retransmitem automaticamente a consulta para tentar outro servidor DNS autoritativo da organização alvo, atacando assim esses servidores em nome do bot.

A Dyn confirmou em sua publicação no blog, Resumo da análise da Dyn sobre o ataque de sexta-feira, 21 de outubro, que a técnica de tortura da água foi de fato usada contra ela.

“Por exemplo, o impacto do ataque gerou uma enxurrada de tentativas legítimas de repetição à medida que os servidores recursivos tentavam atualizar seus caches, criando um volume de tráfego de 10 a 20 vezes maior que o normal em um grande número de endereços IP. Quando ocorre congestionamento no tráfego de DNS, as novas tentativas legítimas podem aumentar ainda mais o volume de tráfego.

Parece que os ataques maliciosos tiveram origem em pelo menos uma botnet, e a enxurrada de novas tentativas deu a falsa impressão de um conjunto de endpoints significativamente maior do que agora sabemos que realmente era. Ainda estamos analisando os dados, mas, no momento da elaboração deste relatório, a estimativa é de até 100.000 endpoints maliciosos.”

O pesquisador da F5, Liron Segal, havia detalhado a mecânica do ataque Water Torture do bot em uma publicação feita semanas antes — Mirai, o bot que derrubou Krebs.

Ataques de camada 4 atualizados

De acordo com o criador do bot, o chamado ataque “TCP STOMP” é uma variação da inundação simples de ACK, criada para contornar dispositivos de mitigação. Ao analisar a implementação real desse ataque, parece que o bot abre uma conexão TCP completa e, em seguida, continua inundando-a com pacotes ACK que possuem números de sequência legítimos para manter a conexão ativa.

Com base em nossa compreensão dos vetores de ameaça individuais associados ao novo bot de IoT, podemos fornecer algumas orientações para mitigar cada um deles.

Vamos deixar uma coisa clara antes de começarmos as orientações. Os ataques à Krebs, à OVH e à Dyn estão em uma categoria à parte. Evidentemente, as técnicas existentes de mitigação de DDoS não conseguiram repelir os invasores com facilidade — daí as interrupções e a ampla cobertura da mídia. No entanto, em muitos casos, a mitigação acabou surtindo efeito. Uma arquitetura adequada, com o uso de Anycast e data centers distribuídos, também ajudou. Vale observar que a Costa Oeste e as regiões ocidentais dos EUA praticamente não foram afetadas pelo ataque à Dyn.

Orientações prescritivas

Nossas orientações vêm de nossos próprios clientes. Há vinte anos, a F5 fornece aplicações para as marcas mais renomadas do mundo, e muitos desses clientes sofrem ataques DDoS todos os dias. Nossos clientes mais experientes dividem suas defesas em três ou quatro zonas:

• Mitigação de ataques na nuvem
• Defesa de rede
• Defesa de aplicações
• DNS, quando aplicável

Portanto, uma arquitetura com máxima resistência a DDoS se parece com isto:

Esta é a arquitetura de referência para proteção contra DDoS, amplamente utilizada há anos pelos clientes da F5. A arquitetura de referência completa e as práticas recomendadas podem ser encontradas em F5.com. No entanto, para facilitar a consulta, as orientações relevantes para esses ataques são detalhadas abaixo.

Defesa contra ataques volumétricos

A empresa francesa de hospedagem OVH foi atingida por um ataque volumétrico de 990 Gbps. Houve relatos de que o ataque à Dyn atingiu um pico de 1,2 terabits. Ataques dessa magnitude geralmente só podem ser mitigados por serviços de limpeza de tráfego na nuvem especializados em defesa em larga escala. Esses serviços, incluindo o Silverline DDoS Protection da F5, interceptam o tráfego do ataque, removem o tráfego malicioso e enviam apenas o tráfego legítimo ao destino por meio de túneis previamente configurados.

Orientação: As organizações devem garantir que tenham contratos com um ou mais serviços de mitigação em nuvem antes de sofrerem um ataque. A configuração dos túneis previamente acordados não é algo que possa ser feito facilmente durante um ataque volumétrico. Contrate um serviço de defesa contra DDoS com mitigação em nuvem como parte de sua estratégia de proteção contra DDoS.

Orientação: A dispersão de ataques pode ser sua aliada contra ataques volumétricos. Lembre-se de que o DNS também pode ser seu aliado; use Anycast em seus data centers globais para conteúdo replicado, a fim de dispersar ataques DDoS quando ocorrerem. Cada data center que participa do Anycast pode ajudar a dividir o ataque.

Materiais relevantes:

• F5 Silverline DDoS – Métodos de implantação
• O guia de estratégias de DDoS da F5: dez etapas para combater ataques DDoS em tempo real
• Práticas recomendadas de proteção contra DDoS da F5
• Arquitetura de referência de DDoS da F5

Defesa de Rede

O bot Mirai inclui em seu arsenal vários ataques de camada 4: inundações SYN padrão, inundações TCP e inundações UDP. Esses antigos vetores de ameaça devem ser mitigados por um serviço de limpeza de tráfego na nuvem ou, se forem suficientemente pequenos, pela camada de defesa de rede no data center. A camada de defesa de rede é estruturada em torno do firewall de rede. Ela foi projetada para mitigar ataques computacionais, como inundações SYN e inundações de fragmentação ICMP. Essa camada também mitiga ataques volumétricos até o ponto de saturação da entrada (normalmente entre 80% e 90% da capacidade nominal do link).

Orientação: Muitos firewalls não são resistentes a ataques DDoS, a menos que sejam configurados corretamente. Consulte o fornecedor do seu firewall de rede para saber quais configurações usar. Alguns clientes instalam dispositivos anti-DDoS à frente de seus firewalls para repelir ataques de camada 4.

Orientação: O módulo de firewall da F5 (BIG-IP Advanced Firewall Manager (AFM)) foi projetado especificamente para repelir ataques de camada 4. Alguns arquitetos usam o BIG-IP AFM justamente para essa finalidade — seja à frente dos firewalls de rede convencionais ou em substituição a eles. Os dispositivos de hardware com AFM usam matrizes de portas programáveis em campo para repelir mais de 30 tipos de inundações de pacotes e retirar essa carga de trabalho da CPU.

Materiais relevantes:

• Mitigação de DDoS com o BIG-IP AFM
• Ficha técnica do F5 BIG-IP Advanced Firewall Manager
• Os dez principais recursos avançados de segurança da F5 no BIG-IP 12.1
• Práticas recomendadas de proteção contra DDoS da F5

Defesa de aplicações

O bot Mirai pode gerar inundações impressionantes de solicitações HTTP GET e lidar com redirecionamentos. Como as inundações de GET parecem tráfego normal para os dispositivos de defesa da rede, elas precisam ser tratadas na camada de aplicação. As inundações de GET são, de longe, o tipo mais comum de ataque à camada de aplicação observado pela F5, e há muitas maneiras de mitigá-las, dependendo do portfólio de produtos utilizado pelo cliente.

Orientação: Para bots capazes de lidar com redirecionamentos simples, a F5 recomenda limitar as conexões com base na métrica de solicitações por segundo ou usar o que se chama de “barreira de login”. Uma barreira de login exige que a conexão seja autenticada no aplicativo antes de poder consumir recursos dinâmicos ou não armazenados em cache, como consultas a bancos de dados.

Materiais relevantes:

• Práticas recomendadas de proteção contra DDoS da F5
• Proteção da página de login com o ASM
• DevCentral: iRule simples de barreira de login

Defesa de DNS

Há duas questões de DNS relacionadas ao ataque à Dyn que merecem ser discutidas. A primeira, e mais simples, é o que fazer se o seu provedor de DNS ficar fora do ar devido a um dos novos tipos de ataque. A Dyn era a provedora de serviços de nomes do Twitter, GitHub e Spotify; portanto, quando foi bloqueada, os usuários finais não conseguiram encontrar os endereços IP desses serviços.

Orientação: incorpore resiliência ao seu plano de DNS, incluindo, entre outras medidas, vários provedores de DNS para fornecer os endereços de suas aplicações críticas. Dessa forma, se um dos provedores ficar temporariamente indisponível devido a um ataque, o outro poderá fornecer seus endereços. Isso pode aumentar o tempo de resposta para os usuários finais em alguns milissegundos, mas suas aplicações e serviços continuarão disponíveis.

A segunda questão é o que fazer se o seu próprio servidor DNS for atacado. O DNS é o serviço mais visado, seguido pelo HTTP. Quando o DNS é interrompido, todos os serviços externos do data center (e não apenas uma única aplicação) são afetados. Esse ponto único de falha total, aliado à infraestrutura de DNS muitas vezes subdimensionada, torna o DNS um alvo atraente para invasores.

Lembre-se de que, mesmo que seu próprio servidor não esteja sob ataque, uma interrupção em um ponto posterior da rede pode fazer com que outro conjunto de servidores DNS sobrecarregue seus servidores DNS com solicitações ao tentar preencher os próprios caches. A Dyn relatou um volume de solicitações de 10 a 20 vezes maior que o normal quando isso aconteceu com ela, e essas solicitações vinham de servidores DNS legítimos que tentavam lidar com a situação.

Orientação: Uma porcentagem significativa dos serviços de DNS não dispõe de recursos suficientes, a ponto de não conseguir resistir nem mesmo a ataques DDoS de pequeno a médio porte. Os caches de DNS se popularizaram porque podem melhorar o desempenho percebido de um serviço de DNS e oferecer alguma resiliência contra ataques convencionais de consultas DNS. Os invasores passaram a usar os chamados ataques de “domínio inexistente” (ou NXDOMAIN), que rapidamente eliminam os benefícios de desempenho proporcionados pelo cache.

Para os clientes da F5, a F5 recomenda colocar o módulo de proxy DNS chamado F5 DNS Express™ à frente dos serviços de DNS. O DNS Express atua como um resolvedor autoritativo à frente dos servidores DNS existentes. Ele carrega as informações de zona dos servidores e resolve todas as solicitações ou retorna NXDOMAIN. Ele não é um cache e não pode ser esvaziado por inundações de consultas NXDOMAIN.

Orientação: Lembre-se de que o DNS pode ser seu aliado durante um ataque DDoS. Use Anycast em seus data centers globais para distribuir conteúdo replicado e dispersar os ataques DDoS quando eles ocorrerem.

Orientação: Considere o posicionamento dos serviços de DNS. Muitas vezes, o serviço de DNS opera em um conjunto próprio de dispositivos, separado do primeiro perímetro de segurança. Isso é feito para manter o DNS independente das aplicações que ele atende.

Algumas grandes empresas com vários data centers disponibilizam o DNS fora do perímetro de segurança principal usando uma combinação do BIG-IP DNS com o DNS Express e o módulo de firewall BIG-IP AFM. O principal benefício dessa abordagem é que os serviços de DNS permanecem disponíveis mesmo que a camada de defesa da rede fique inoperante devido a um ataque DDoS.

Materiais relevantes:

• F5 Friday: Sem DNS? Sem... nada
• Folha de dados do F5 DNS
• DevCentral: DNS Express e transferências de zona
• DevCentral: DNS Express - Parte 1
• A infraestrutura de DNS dinâmico
• Práticas recomendadas de proteção contra DDoS da F5
• Arquitetura de referência de DDoS da F5

Conclusão

Os ataques contra Krebs, OVH e Dyn marcam uma nova fase dos ataques DDoS. Ao mesmo tempo, assinalam o amadurecimento da Internet das Coisas.

Como você pode ver, a F5 tem ampla experiência em pesquisar, combater e escrever sobre DDoS, e queremos trabalhar com os clientes para manter seus aplicativos disponíveis. Isso exigirá vigilância de todos nós — da F5 aos parceiros e clientes.

Se você é cliente, ou mesmo que não seja, e estiver sob ataque, lembre-se de que a Proteção contra DDoS F5 Silverline está a apenas uma ligação de distância: 866-329-4253.

Quanto à ameaça da IoT, os hackers mal-intencionados compartilham informações entre si o tempo todo (eles compartilharam o Mirai depois que ele atacou Krebs e a OVH, e ele foi usado no ataque à Dyn). Nós, da comunidade de segurança da informação, precisamos seguir o exemplo deles e unir forças para resolver esse problema global da IoT. Não temos outra escolha. Faz parte da natureza humana compreender os problemas, corrigi-los e, assim, evoluir.

Sem dúvida, haverá alguns percalços nos próximos anos, à medida que os ataques aumentarem de escala, os serviços de mitigação ampliarem sua largura de banda para comportar esses grandes ataques e os fabricantes de dispositivos de IoT descobrirem como lidar com as vulnerabilidades de seus dispositivos. Organizações e consumidores terão de se adaptar a essa ameaça em constante evolução, assim como fizeram com todos os outros grandes desafios anteriores.

Sobre o autor

F5

Mais publicações de F5