Inundação de DDoS
A inundação de DDoS, primeiro incidente do SysAdmin Crisis: tráfego de quem não é cliente e a banda no vermelho. Veja a assinatura nos logs.
Última atualização:
Uma inundação é o primeiro incidente que o jogo ensina, e o único que pode aparecer na primeira noite. O tráfego chega de endereços que não são clientes, a barra de largura de banda enche e tudo que está por trás começa a sofrer.
O que ele faz
O ataque cresce ao longo de cerca de quinze segundos de tempo real em vez de chegar de uma vez, então você tem uma janela entre a primeira linha estranha e a primeira barra vermelha. No pico, ele mira um pouco abaixo da capacidade total de largura de banda da frota — o que significa que a capacidade importa, e uma frota maior de fato absorve mais.
Quando a demanda passa de cerca de 1,35× a capacidade, as máquinas por trás entram em saturação: a CPU sobe a 99%, a latência aumenta e, mais ou menos a cada quinze segundos, mais um alvo cai para DOWN.
A assinatura nos logs
Uma inundação não se anuncia pelo nome; você vê o sintoma como linhas do kernel e do monit nas máquinas de borda. As linhas abaixo são exemplos, e os valores mudam a cada noite:
03:11:42 web-02 kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters.
03:11:45 web-02 monit[612]: 'web-02' cpu usage of 94% matches resource limit [cpu usage > 90.0%]
03:11:49 web-02 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Essas linhas não revelam a origem. netstat e o log de acesso web mostram quem está enviando requisições; resumir o log com grep, awk e sort | uniq -c é o trabalho de verdade deste incidente. Todo endereço do jogo vem dos blocos de documentação da RFC 5737 — 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — portanto um endereço fora desses blocos nunca é um atacante.
Se você deixar de lado
A largura de banda satura primeiro, depois a CPU, e então as máquinas começam a cair uma a uma. Um servidor derrubado fica caído: não volta sozinho. E, como um incidente sem resolução começa a acumular dívida de SLA quando sua janela de tolerância expira, uma inundação ignorada custa disponibilidade (uptime) duas vezes — uma pelas máquinas que derruba, outra pelo relógio. Veja escalonamento e SLA.
Como distingui-lo
| Parece com | O que o separa |
|---|---|
| Processo descontrolado | A pressão de CPU de uma inundação atinge a frota inteira e vem com avisos de SYN do kernel; um processo descontrolado é um único processo nomeado em uma única máquina. |
| Vazamento de memória | Um vazamento eleva a RAM, não a largura de banda, e não mostra assinatura de tráfego. |
| Superaquecimento | O calor pode chegar depois de uma inundação como efeito secundário. Se os dois estão em andamento, a temperatura é um sintoma, não a causa. |
Quando ele aparece
| Noite mínima | 1 — é também a segunda lição do tutorial |
| Requer | pelo menos uma máquina web na frota |
| Ao mesmo tempo | uma inundação, nunca duas |
| Variante | a partir da noite 6, uma inundação pode chegar distribuída: cinco origens espalhadas pelos três blocos da RFC 5737, em vez de um único endereço |
A variante distribuída é decidida pelo PRNG com semente, então a mesma semente produz a mesma noite todas as vezes — veja determinismo e sementes.