Flood DDoS
Le flood DDoS est le premier incident de SysAdmin Crisis : du trafic d'adresses non clientes et une bande passante qui vire au rouge. Sa signature.
Dernière mise à jour:
Un flood est le premier incident que le jeu enseigne, et le seul qui puisse apparaître dès la première nuit. Du trafic arrive d'adresses qui ne sont pas des clients, la barre de bande passante se remplit, et tout ce qui se trouve derrière commence à souffrir.
Ce qu'il fait
L'attaque monte en puissance sur environ quinze secondes de temps réel au lieu d'arriver d'un coup : vous disposez donc d'une fenêtre entre la première ligne étrange et la première barre rouge. À son pic, elle vise tout juste sous la capacité totale de bande passante du parc de serveurs — ce qui signifie que la capacité compte, et qu'un parc plus grand absorbe réellement davantage.
Dès que la demande dépasse environ 1,35× la capacité, les machines situées derrière entrent en saturation : le CPU grimpe à 99 %, la latence monte et, à peu près toutes les quinze secondes, une cible de plus passe à DOWN.
La signature dans les logs
Un flood ne s'annonce pas par son nom ; vous voyez le symptôme sous forme de lignes du noyau et de monit sur les machines de périphérie. Les lignes ci-dessous sont des exemples, et les valeurs changent à chaque nuit :
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
Ces lignes ne vous disent pas la source. netstat et le log d'accès web montrent qui envoie les requêtes ; résumer le log avec grep, awk et sort | uniq -c est le vrai travail de cet incident. Toutes les adresses du jeu proviennent des blocs de documentation de la RFC 5737 — 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — donc une adresse extérieure à ces blocs n'est jamais un attaquant.
Si vous n'y touchez pas
La bande passante sature d'abord, puis le CPU, puis les machines tombent une à une. Un serveur tombé est collant : il ne revient pas tout seul. Et comme un incident non résolu commence à accumuler de la dette de SLA une fois son délai de grâce expiré, un flood que vous ignorez coûte de la disponibilité deux fois — une fois par les machines qu'il fait tomber, une fois par l'horloge. Voir escalade et SLA.
Le distinguer des autres
| Ressemble à | Ce qui les distingue |
|---|---|
| Processus qui s'emballe | La pression sur le CPU d'un flood touche tout le parc de serveurs et s'accompagne d'avertissements SYN du noyau ; un processus qui s'emballe est un unique processus nommé sur une unique machine. |
| Fuite mémoire | Une fuite fait grimper la RAM, pas la bande passante, et ne présente aucune signature de trafic. |
| Surchauffe | La chaleur peut survenir après un flood comme effet secondaire. Si les deux sont actifs, la température est un symptôme, pas la cause. |
Quand il apparaît
| Première nuit | 1 — c'est aussi la deuxième leçon du tutoriel |
| Nécessite | au moins une machine web dans le parc de serveurs |
| Simultanément | un seul flood, jamais deux |
| Variante | à partir de la nuit 6, un flood peut arriver distribué : cinq sources réparties sur les trois blocs de la RFC 5737 au lieu d'une adresse unique |
La variante distribuée est décidée par le PRNG à graine, si bien que la même graine produit chaque fois la même nuit — voir déterminisme et graines.