O que acontece durante um evento de DDoS

Nada é ligado

Não há botão. A limpeza (scrubbing) é executada permanentemente na frente de todos os sites, de quatro terabits por segundo nos locais menores a doze nos maiores, e a decisão de descartar um pacote é tomada em hardware na borda, na entrada. Os primeiros trinta segundos de um ataque são, portanto, filtrados exatamente como os últimos trinta, o que não é verdade para qualquer sistema que tenha que detectar um ataque, redirecionar um prefixo e esperar que o anúncio se propague.

O que você vê de dentro

Geralmente nada. UDP refletido, um SYN flood, um conjunto de respostas DNS amplificadas: um ataque volumétrico de qualquer forma é descartado a montante e nunca chega à sua porta. O gráfico no painel mostra isso. Seus contadores de interface não mostram.

O que pode chegar até você é qualquer coisa indistinguível do tráfego real: um flood HTTP lento, uma série de requisições para o seu endpoint mais caro, uma execução de preenchimento de credenciais. A camada 7 é onde a borda não pode ajudar sem conhecer a sua aplicação, e é para isso que existe o complemento DDoS Pro: assinaturas personalizadas, limites de taxa por caminho e uma pessoa para escrevê-las enquanto isso está acontecendo.

Verifique seus próprios limites antes de concluir qualquer coisa

Boa metade dos ataques reportados para nós é uma tabela conntrack enchendo ou uma fila de escuta transbordando sob tráfego normal de segunda-feira.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
nstat -az TcpExtListenOverflows TcpExtSyncookiesSent
ss -s
journalctl -k --since "15 min ago" | tail -50

nf_conntrack: table full, dropping packet no log do kernel é o seu firewall falando sobre si mesmo, não a rede reportando um ataque.

O que fazemos

A detecção é baseada em fluxo e por destino. Uma correspondência de assinatura descarta o tráfego correspondente em segundos e deixa o resto do seu em paz. Quando o volume excede o que um site pode absorver, o que é raro e já aconteceu, o endereço de destino é filtrado por completo por uma janela declarada, em vez de deixar o site degradar para todos. Você recebe um e-mail nomeando a janela, e ela é medida em minutos.

O tráfego de ataque nunca é contabilizado contra o uso justo. Não é seu tráfego e você não pediu por ele.

O que podemos lhe dizer depois

Vetor, taxa de pico de bits, taxa de pico de pacotes, duração e a geografia aproximada das fontes. Isso é o que os contadores de fluxo contêm.

O que não podemos entregar é uma captura de pacotes, porque não existe uma. Não registramos o tráfego que cruza sua instância, e essa política não tem exceção que se ligue quando o tráfego se torna hostil. O detalhe está em o que registramos. As pessoas ocasionalmente acham isso frustrante no meio de um incidente, e é a mesma propriedade que torna o resto da política válido.

O que não fazer

• Não mude o endereço. O ataque o segue em menos de um minuto e agora seu DNS também está errado.
• Não reinicie. Uma instância reiniciando é uma instância mais lenta, não uma instância filtrada.
• Não cole uma regra nftables de mil linhas em pânico. Qualquer coisa que você descartar na instância já atravessou a parte cara da rede.
• Verifique /status primeiro. Se o site em si tiver um incidente, ele é publicado lá antes do seu ticket ser escrito.

Abra o ticket mesmo assim

ID da instância, carimbos de data/hora com fuso horário, qual foi o sintoma real e se o serviço estava acessível a partir de uma segunda rede. O tempo mediano de primeira resposta é de onze minutos a todas as horas do dia, e durante um evento ao vivo a resposta vem de alguém que já está observando o gráfico.