BLOG

Compreendendo o último mês de ataques DDoS

Miniatura F5
F5
Publicado em 27 de outubro de 2016

Neste artigo, daremos uma breve olhada no impacto dos ataques #DDoS sem precedentes de setembro e outubro de 2016 e forneceremos orientação para aqueles interessados em melhorar sua resiliência.

Vamos comemorar a chegada da Internet das Coisas! Sabemos que ele finalmente chegou porque foi usado como arma cibernética três vezes a partir de setembro. Tudo começou com um ataque massivo ao jornalista blogueiro Brian Krebs, cujo site krebsonsecurity.com era hospedado e protegido pela CDN Akamai. O ataque foi grave o suficiente para afetar outros clientes da Akamai, então eles abandonaram a defesa pro bono do blogueiro.

Pesquisadores da indústria (incluindo o F5) foram alertados sobre uma nova botnet composta de DVRs, câmeras de vídeo e outras “coisas”. Mas os DVRs e as câmeras de vídeo são importantes porque têm alta capacidade de CPU (que pode, portanto, hospedar malware sofisticado) e uplinks de alta largura de banda (dos quais eles lançam ataques de até 100 Mbs cada). O tráfego total de ataque direcionado ao Krebs foi de 620 Gbs, o que na época foi o maior ataque DDoS do mundo.

O segundo ataque derrubou a OVH, o maior provedor de hospedagem francês (número três no mundo, se você acredita na literatura) por boa parte do dia. Muitos relatos da mídia listaram o ataque OVH como quase o dobro do tamanho do ataque Krebs; um terabit completo por segundo.

O terceiro e possivelmente pior ataque ocorreu contra a Dyn, a empresa de serviços de DNS. Dyn é o provedor de DNS para muitos sites importantes, incluindo Twitter, Spotify e GitHub (onde ironicamente o código do botnet IoT foi postado).

Então, quem fez isso?

Por uma estranha coincidência, o luminar da indústria Bruce Schneier estava fazendo entrevistas no mês anterior alertando sobre ataques DDoS massivos de estados-nação que estavam por vir. Suas informações privilegiadas vieram de fontes anônimas da indústria que estavam detectando ataques DDoS de calibração contra a infraestrutura central da Internet.

Mas, ao que parece, 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 um estado-nação. Mas talvez esse estado-nação esteja apenas observando e esperando.

A chave para a atribuição nos casos Krebs, OVH e Dyn provavelmente pode vir do próprio Brian Krebs .

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

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

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

Como chegamos aqui?

A F5 monitora a busca por dispositivos de Internet das Coisas (IoT) há mais de um ano. Nosso primeiro relatório sobre esse problema foi publicado em julho de 2016 e mostrou um aumento de 140% nas varreduras de força bruta de telnet e SSH ano a ano. Telnet e SSH são portas de administração remota amplamente utilizadas e muitas vezes são deixadas expostas à Internet sem que você saiba, com nomes de usuário e 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 (varredura de portas telnet e senhas padrão de fornecedores em dispositivos IoT) para criar uma botnet de capacidade única.

Todo mundo é um alvo novamente. Os pastores de bots não têm medo de usar suas armas cibernéticas contra alguns dos maiores provedores do mundo — alvos que antes eram considerados intocáveis.

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

Mergulho profundo no que sabemos

Na verdade, temos uma boa ideia das capacidades da botnet de IoT, Mirai. Os pesquisadores da F5 escreveram uma análise técnica do bot Mirai logo após seu autor divulgar o código-fonte no hackforums.net.

O poder de fogo coletivo é provavelmente uma ordem de magnitude maior do que o das botnets anteriores; mais de terabits por segundo.

A botnet IoT inclui (mas não está limitada a) as seguintes técnicas avançadas de DDoS. A seção de orientação prescritiva abaixo fornecerá recomendações sobre como mitigar esses problemas, quando possível.

Inundações HTTP GET resistentes a redirecionamento

Inundações HTTP GET já eram perniciosas. Durante anos, invasores conseguiram desabilitar sites enviando uma enxurrada de solicitações HTTP para objetos grandes ou consultas lentas em bancos de dados. Normalmente, essas solicitações fluem diretamente por um firewall padrão porque se parecem com solicitações HTTP normais para a maioria dos dispositivos com processamento de pacotes de hardware. O código de ataque Mirai vai um passo além ao identificar os depuradores DDoS baseados na nuvem e, em seguida, contornar quaisquer redirecionamentos 302 que os depuradores enviem de volta. Os redirecionamentos costumavam ser uma boa maneira de bloquear bots simples, mas este não é mais simples .

DNS Tortura da Água

O bot Mirai inclui um ataque de “tortura de água” contra um provedor de DNS alvo. Essa técnica é diferente do ataque regular de reflexão e amplificação de DNS porque exige que significativamente menos consultas sejam enviadas pelo bot, permitindo que o servidor DNS recursivo do ISP execute o ataque no servidor DNS autoritativo alvo. Neste ataque, o bot envia uma consulta DNS bem formada contendo o nome de domínio alvo a ser resolvido, enquanto acrescenta um prefixo gerado aleatoriamente ao nome. O ataque se torna efetivo quando o servidor DNS de destino fica sobrecarregado e não responde. Os servidores DNS do ISP então 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 postagem no blog, Resumo da Análise da Dyn do ataque de sexta-feira, 21 de outubro , que a tortura da água foi de fato usada contra eles.

“Por exemplo, o impacto do ataque gerou uma tempestade de atividade legítima de repetição, à medida que 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 de tráfego DNS, tentativas legítimas podem contribuir ainda mais para o volume de tráfego.

Parece que os ataques maliciosos foram originados de pelo menos uma botnet, com a tempestade de tentativas fornecendo um falso indicador de um conjunto significativamente maior de endpoints do que sabemos agora. Ainda estamos trabalhando na análise dos dados, mas a estimativa no momento deste relatório é de até 100.000 endpoints maliciosos. ”

O pesquisador do F5, Liron Segal, havia detalhado a mecânica do ataque de Tortura de Água do bot em sua postagem 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 do simples ACK flood, destinado a contornar dispositivos de mitigação. Ao analisar a implementação real deste ataque, parece que o bot abre uma conexão TCP completa e então continua inundando com pacotes ACK que têm números de sequência legítimos para manter a conexão ativa.

Dada a nossa compreensão dos vetores de ameaça individuais com o novo bot de IoT, podemos fornecer algumas orientações para a mitigação desses vetores de ameaça individuais.

Vamos deixar claro antes de começar a orientação. Os ataques Krebs, OVH e Dyn são uma classe à parte. Claramente, as técnicas existentes de mitigação de DDoS não repeliram facilmente os invasores — daí as interrupções e a cobertura da mídia. No entanto, a mitigação acabou surtindo efeito em muitos casos. E uma arquitetura adequada, como o uso de Anycast e data centers dispersos, também ajudou. Observe que a Costa Oeste e as regiões ocidentais dos EUA não foram afetadas pelo ataque Dyn.

Orientação prescritiva

Nossa orientação vem dos nossos próprios clientes. A F5 fornece aplicativos para as principais marcas do mundo há vinte anos, e muitos desses clientes são atacados com DDoS todos os dias. Nossos clientes mais experientes dividem suas defesas em três ou quatro zonas:

  • Limpeza de nuvens
  • Defesa de rede
  • Defesa de aplicação
  • DNS, quando aplicável

Uma arquitetura superlativa resistente a DDoS, portanto, se parece com isto:

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

Defesa Volumétrica

A empresa de hospedagem francesa OVH foi atingida por um ataque volumétrico de 990 Gbs. Houve relatos de que o ataque Dyn atingiu o pico de 1,2 terabits. Ataques desse tamanho geralmente só podem ser mitigados por depuradores de nuvem especializados em defesa em escala. Os depuradores de nuvem, incluindo o Silverline DDoS Protection da F5, interceptam o tráfego de ataque, limpam-no e enviam apenas o tráfego bom para o alvo por túneis pré-organizados.

Orientação: As organizações devem garantir que tenham acordos com um ou mais depuradores de nuvem antes de serem atacadas. Configurar os túneis pré-organizados não é algo que pode ser feito facilmente no meio de um ataque volumétrico. Contrate uma defesa DDoS de limpeza de nuvem como parte de sua estratégia DDoS.

Orientação: A difusão de ataques pode ser sua amiga para ataques volumétricos. Lembre-se de que o DNS também pode ser seu amigo; transmita seus data centers globais para conteúdo replicado para difundir ataques DDoS quando eles ocorrerem. Cada data center que participa do Anycast pode ajudar a dividir o ataque.

Materiais relevantes:

Defesa de rede

O bot Mirai inclui vários ataques de camada 4 em seu arsenal: inundações SYN padrão, inundações TCP e inundações UDP. Esses antigos vetores de ameaça devem ser mitigados em um depurador de nuvem ou, se forem suficientemente pequenos, na camada de defesa da rede no data center. A camada de defesa da rede é construída em torno do firewall da rede. Ele foi projetado para mitigar ataques computacionais, como inundações de SYN e inundações de fragmentação de ICMP. Essa camada também atenua ataques volumétricos até o congestionamento do ponto de entrada (normalmente 80 a 90 por cento do tamanho nominal do tubo).

Orientação: Muitos firewalls não são resistentes a ataques DDoS, a menos que sejam configurados corretamente. Verifique as configurações com o fornecedor do firewall da sua rede. Alguns clientes colocarão dispositivos anti-DDoS na frente de seus firewalls para repelir ataques de camada 4.

Orientação: O módulo de firewall F5 (BIG-IP Advanced Firewall Manager (AFM)) foi projetado especificamente para repelir ataques de camada 4. Alguns arquitetos usam o BIG-IP AFM apenas para esse caso, seja na frente ou substituindo firewalls de rede convencionais. 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 aliviar o trabalho da CPU.

Materiais relevantes:

Defesa de Aplicação

O bot Mirai pode gerar inundações HTTP GET impressionantes e lidar com direcionamento. Como as inundações GET parecem tráfego normal para os dispositivos de defesa da rede, elas devem ser tratadas na camada de aplicação. Os ataques de inundação GET são de longe o tipo de ataque mais comum na camada de aplicação que a F5 vê, e há muitas maneiras de mitigá-los, dependendo do portfólio de produtos que o cliente está usando.

Orientação: Para bots que podem lidar com redirecionamentos simples, a F5 recomenda limitar as conexões com base em sua métrica de solicitação por segundo ou usar o que é chamado de “login-wall”. Um login wall requer uma conexão autenticada com o aplicativo antes que ele possa consumir recursos dinâmicos ou não armazenados em cache, como consultas de banco de dados.

Materiais relevantes:

Defesa DNS

Há dois problemas de DNS que vale a pena discutir em relação ao ataque Dyn. A primeira e mais direta é o que fazer se seu provedor de DNS for tirado do ar por um dos novos tipos de ataques. Dyn era o provedor de serviços de nomes para Twitter, GitHub e Spotify, então, quando Dyn foi bloqueado, os usuários finais não conseguiram encontrar endereços IP para esses serviços.

Orientação: Crie resiliência em seu plano de DNS que inclua, mas não se limite a, vários provedores de DNS para atender endereços para seus aplicativos críticos. Dessa forma, se um dos provedores sucumbir temporariamente a um ataque, o outro provedor poderá atender seus endereços. Isso pode deixar seus usuários finais lentos em alguns milissegundos, mas seus aplicativos e serviços ainda estarão disponíveis.

A segunda questão é o que fazer se 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 (não apenas um único aplicativo) são afetados. Esse ponto único de falha total, juntamente com a infraestrutura de DNS frequentemente subprovisionada, torna o DNS um alvo tentador para invasores.

Lembre-se de que, mesmo que seu próprio servidor não esteja sob ataque, uma interrupção a jusante de você pode fazer com que um conjunto diferente de servidores DNS inunde seus servidores DNS com solicitações, enquanto eles tentam preencher seus próprios caches. A Dyn relatou de 10 a 20 vezes mais solicitações normais quando isso aconteceu com eles, e isso veio de servidores DNS legítimos tentando lidar com a situação.

Orientação: Uma porcentagem significativa de serviços de DNS são subprovisionados a ponto de não conseguirem suportar ataques DDoS de pequeno a médio porte. Os caches DNS se tornaram populares porque podem aumentar o desempenho percebido de um serviço DNS e fornecer alguma resiliência contra ataques de consulta DNS padrão. Os invasores mudaram para o que é chamado de ataques “no such domain” (ou NXDOMAIN), que drenam rapidamente os benefícios de desempenho fornecidos pelo cache.

Para clientes da F5, a F5 recomenda usar como front-end os serviços de DNS com o módulo proxy DNS chamado F5 DNS Express™. O DNS Express atua como um resolvedor absoluto na frente dos servidores DNS existentes. Ele carrega as informações de zona dos servidores e resolve cada solicitação ou retorna NXDOMAIN. Não é um cache e não pode ser esvaziado por meio de inundações de consulta NXDOMAIN.

Orientação: Lembre-se de que o DNS pode ser seu amigo durante um ataque DDoS; faça anycast dos seus data centers globais para obter conteúdo replicado para dissipar ataques DDoS quando eles ocorrerem.

Orientação: Considere o posicionamento dos serviços DNS. Muitas vezes, o serviço DNS existe como seu próprio conjunto de dispositivos, separado do primeiro perímetro de segurança. Isso é feito para manter o DNS independente dos aplicativos que ele atende.

Algumas grandes empresas com vários data centers atendem DNS fora do perímetro de segurança principal usando uma combinação de BIG-IP DNS com 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 se a camada de defesa da rede ficar offline devido a DDoS.

Materiais relevantes:

Conclusão

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

Como você pode ver, a F5 tem muita 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 todas as partes — da F5 aos parceiros e clientes.

Se você for um cliente, ou mesmo se não for, e sofrer um ataque, lembre-se de que a proteção DDoS da F5 Silverline está a apenas um telefonema de distância: 866-329-4253.

Quanto à ameaça da IoT, os blackhats compartilham entre si o tempo todo (eles compartilharam o Mirai depois que ele atacou Krebs e OVH, e ele foi usado no ataque Dyn). Nós, da comunidade InfoSec, precisamos seguir o exemplo deles e nos unir para resolver esse problema global da IoT. Não temos escolha a não ser fazer isso. É da natureza humana entender problemas, resolvê-los e, portanto, evoluir.

Sem dúvida, haverá contratempos nos próximos anos, à medida que os ataques aumentam em tamanho, os serviços de limpeza aumentam em largura de banda para acomodar esses grandes ataques e os fabricantes de dispositivos de IoT descobrem como lidar com as inseguranças de seus dispositivos. Organizações e consumidores precisam se acostumar a essa ameaça em evolução, assim como a todos os outros grandes problemas anteriores a essa.