Como a Hostinger Lida com os Ataques DDoS

Como Reconhecer um Ataque de Negação de Serviço (DDoS)

Para evitar um ataque, é preciso saber o que está por vir. Quando detectamos uma tentativa de interrupção da operação regular de um servidor, serviço ou rede-alvo por meio da sobrecarga de tráfego indesejado, significa que estamos sob ataque de negação de serviço (ou DDoS).

Um ataque DDoS tenta negar o acesso a um servidor de destino gerando um grande número de tráfego malicioso que consome os recursos disponíveis do alvo. Para evitá-los, implementamos soluções de filtragem de tráfego para impedir tais ataques e garantir o máximo de uptime (tempo de atividade do site) possível.

Estamos sempre melhorando nossos serviços e renovando nossos sistemas para mantê-los sempre preparados para esses ataques. Neste artigo, mostraremos como combatemos os ataques DDoS e explicaremos nosso filtro de tráfego Wanguard e a infraestrutura geral.

Como é um Ataque DDoS?

Aqui vai um exemplo real de um ataque DDoS. Imagine 400 Mbps de tráfego UDP direcionado a um VPS com 100 Mbps de largura de banda disponível. 

Resultados do tempo de carregamento do site simples do Jekyll:

Antes do ataque: 0,08 segundos

Durante o ataque: 23,35 segundos (1ª tentativa), 30,86 segundos (2ª tentativa)

Os ataques DDoS costumam ser difíceis de serem combatidos porque, geralmente, eles envolvem várias botnets direcionadas a você. Uma botnet é uma rede de computadores infectada, por isso, combatê-las sozinhas pode, na maioria das vezes, ser uma batalha perdida.

Como Lidamos com os Ataques DDoS

Temos duas soluções de minimização DDoS para lidar com ataques em nossa infraestrutura: ⁣ black hole acionado remotamente (RTBH) e filtragem de tráfego.

A filtragem RTBH oferece uma maneira de eliminar o tráfego indesejado rapidamente, antes que ele adentre nossa infraestrutura. Embora esse método proteja nossa infraestrutura como uma provedora de serviços, ele impede que todo o tráfego chegue até nós — algo que nossos clientes não gostam. Isso porque, com o tempo, os sites e VPS ficam totalmente inacessíveis. Como consequência, os cibercriminosos alcançam seus objetivos.

Filtragem de tráfego é o próximo nível de proteção DDoS para nossos serviços. Ele só impede o tráfego malicioso em vez de diminuir todos os tráfegos. O tráfego malicioso é identificado examinando os pacotes que navegam por nossa estrutura. Os seguintes elementos de tráfego são inspecionados para padrões específicos? 

• pacote de carga útil
• porta de origem
• IP de origem
• porta de destino
• país
• e mais

Esse processo de filtragem é feito na nossa infraestrutura antes que o tráfego chegue aos nossos serviços, assim, nossos clientes não têm nada com que se preocuparem.

Filtragem de Tráfego

Configuração

Nós implementamos a filtragem fora de linha para a nossa configuração. Como raramente sofremos ataques DDoS, a filtragem em linha seria ineficiente em praticidade e custos reais —por isso usamos o método RTBH. 

Nossa configuração envolve instâncias de filtro conectadas a spine switches dos quais o tráfego desviado circula. Usamos o sFlows, enviados de instâncias spine para a instância de filtro, para investigar e desviar o tráfego, se necessário. O tráfego limpo é encaminhado para ps switches leaf, enquanto o tráfego malicioso é descartado na instância do filtro. É importante notar que o desvio de tráfego e os processos de filtragem são totalmente automatizados. 

Se algum servidor de destino apresentar um pico de tráfego acima de nossos limites estabelecidos, o endereço IP é anunciado para as spines usando o ExaBGP. Quando o tráfego chega a uma instância de filtro, examinamos os pacotes de entrada para identificar o padrão de ataque. Após concluídas, novas regras são adicionadas ao firewall, impedindo que tráfegos maliciosos cheguem ao seu destino.

Hardware

O servidor de filtro depende dos principais elementos: CPU e NIC. Depois de alguns testes e pesquisas, decidimos o seguinte:

CPU: Intel(R) Xeon(R) Silver 4215R @ 3.2 GHz

NIC: Intel XL710 (40G)

Durante o ataque de DDoS com ~15 Mpps e 8 Gbps de tráfego, o uso da CPU parece com isso:

Automatização

Seria difícil gerenciar várias instâncias de filtro em todos os servidores manualmente. Por isso, toda solução é completamente automatizada, desde a detecção até as configurações de limites. Atualmente, usamos o Chef e o Ansible para a infraestrutura como  código (IaC). Alterar os limites ou outras configurações para todas as instâncias de uma vez é tão fácil quanto alterar algumas linhas do código.

Configuração

Aqui está uma prévia da nossa configuração:

Nossa instância deve conseguir rotear pacotes entre as interfaces, portanto, o encaminhamento é habilitado para IPv4 e IPv6. Como não temos nenhuma rota por meio de interfaces utilizadas para desvio de tráfego, devemos desativar a filtragem do caminho inverso ou colocá-la em “modo solto” – como fizemos – assim, os pacotes que chegam através dessas interfaces não são descartados.

Aumentamos o número máximo de pacotes em um ciclo de pesquisa NAPI (net.core.netdev_budget) para 1000. Como preferimos a taxa de transferência em vez da latência neste caso, definimos nossos buffers para o máximo. 

Estamos executando esta solução há seis meses e podemos ver que estas pequenas mudanças são suficientes para lidar com qualquer ataque das escalas previstas. Não nos aprofundamos no ajuste do sistema, pois os valores padrão são razoáveis e não causam nenhum problema.

Em seguida, realizamos ações. Uma ação é acionada quando um ataque é detectado ou concluído. Nós a usamos para desviar o tráfego (anúncio de rota via ExaBGP), informar nossa equipe de monitoramento sobre o ataque (uma mensagem no Slack da instância), e outras ações.

Os limites também são gerenciados como código, proporcionando inúmeras opções para detectar um ataque. Por exemplo, se detectarmos pacotes de 100K UDP por segundo, direcionados a um único alvo, iniciamos o processo de filtragem. Também pode ser tráfego TCP, solicitações HTTP/HTTPS, e assim por diante.

Os prefixos que devem ser protegidos também são adicionados automaticamente a partir dos data bags do Chef.

Resultados

Como é o tratamento de um ataque DDoS no Grafana? Let’s look at a recent attack with 8 Gbps and 1 Mpps of traffic below.

Aqui está um tráfego de entrada para filtrar a instância:

E aqui está o tráfego de saída para o dispositivo final:

Pacotes de entrada por segundo:

Pacotes de saída por segundo:

Como você pode ver, há um pequeno aumento de tráfego que vai da instância filtrante para o dispositivo final. Ele é a brecha causada pelo processo de identificação do padrão de ataque. É um curto período de tempo, geralmente entre 1 e 10 segundos, mas é algo que nos exige cautela. Como visto no gráfico, assim que o padrão de ataque é identificado, você está seguro!

E quanto à velocidade da detecção de ataques? Esta parte depende de sFlows e, como sabemos, não é tão rápida quanto o espelhamento de porta. Dito isso, ele é fácil de configurar, flexível e custa menos. Quando um ataque começa, o tempo para desviar o tráfego para a instância do filtro leva entre 20 e 50 segundos.

É assim que todo o processo se apresenta a partir da instância-alvo:

Tráfego

Pacotes por segundo

Há um pequeno pico e estamos de volta à normalidade, como de costume. Dependendo do serviço que você estiver executando, você pode nem perceber o ataque.

Aqui na Hostinger, gostamos de saber o que está acontecendo em nossa infraestrutura, portanto, vamos investigar este caso um pouco mais:

Fonte do ataque. Notamos um aumento no tráfego IPv4 de alguns países, sendo a maioria vinda da Índia e Taiwan. Existe uma grande possibilidade de que esses IPs tenham sido falsificados, desta forma, essas informações podem ser imprecisas. Temos a lista de endereços de origem e ASNs, mas não vamos publicar aqui pelo mesmo motivo (spoofing).

Protocolo de ataque. Este ataque foi baseado principalmente no UDP, pois não vimos nenhum aumento incomum no gráfico TCP.

Tipo de ataque. Ele uma grande quantidade de tráfego para portas UDP aleatórias. Alguns deles são vistos no gráfico abaixo:

Conclusão

O RTBH é uma proteção DDoS eficaz, mas, em determinado momento, causa downtime (inatividade). Após a implementação da solução de filtragem de tráfego em nossa infraestrutura, somente descartamos o tráfego malicioso em vez de todos os demais. Notamos que o uso de RTBH diminuiu em 90-95%, resultando em um melhor uptime (tempo de atividade) para nossos serviços e clientes.