Ce qui se passe pendant un événement DDoS

Rien ne s’allume

Il n’y a pas de bouton. Le nettoyage s’exécute en permanence devant chaque site, de quatre térabits par seconde sur les plus petits sites à douze sur les plus grands, et la décision de laisser tomber un paquet est prise dans le matériel en périphérie à l’entrée. Les trente premières secondes d’une attaque sont donc filtrées exactement comme les trente dernières, ce qui n’est vrai d’aucun système qui doit détecter une attaque, rediriger un préfixe et attendre que l’annonce se propage.

Ce que vous voyez de l’intérieur

Habituellement, rien du tout. UDP réfléchi, inondation SYN, ensemble de réponses DNS amplifiées : une attaque volumétrique de toute forme est abandonnée en amont et n’atteint jamais votre port. Le graphique dans le panneau le montre. Vos compteurs d’interface, non.

Ce qui peut vous atteindre, c’est tout ce qui est impossible à distinguer d’un trafic réel : une inondation HTTP lente, un flux de requêtes vers votre point de terminaison le plus coûteux, une exécution de bourrage d’identifiants. La couche 7 est l’endroit où la périphérie ne peut pas aider sans connaître votre application, c’est pour cela que le module complémentaire DDoS Pro existe : signatures personnalisées, limites de débit par chemin et une personne pour les écrire avec vous pendant que cela se produit.

Vérifiez vos propres limites avant de conclure

Bonne moitié des attaques qui nous sont signalées sont une table conntrack qui se remplit ou une file d’écoute qui déborde sous un trafic de lundi ordinaire.

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 dans le journal du noyau, c’est votre pare-feu qui parle de lui-même, pas le réseau qui signale une attaque.

Ce que nous faisons

La détection est basée sur les flux et par destination. Une correspondance de signature abandonne le trafic correspondant en quelques secondes et laisse le reste du vôtre tranquille. Là où le volume dépasse ce qu’un site peut absorber, ce qui est rare et s’est déjà produit, l’adresse de destination est filtrée en bloc pendant une fenêtre définie au lieu de laisser le site se dégrader pour tous ceux qui l’utilisent. Vous recevez un e-mail nommant la fenêtre, et elle se mesure en minutes.

Le trafic d’attaque n’est jamais compté dans l’usage raisonnable. Ce n’est pas votre trafic et vous ne l’avez pas demandé.

Ce que nous pouvons vous dire ensuite

Vecteur, débit de pointe, taux de paquets de pointe, durée et géographie approximative des sources. C’est ce que contiennent les compteurs de flux.

Ce que nous ne pouvons pas remettre, c’est une capture de paquets, parce qu’il n’y en a pas. Nous n’enregistrons pas le trafic traversant votre instance, et cette politique n’a aucune exception qui s’active lorsque le trafic devient hostile. Les détails sont dans ce que nous journalisons. Les gens trouvent parfois cela frustrant en plein incident, et c’est la même propriété qui donne de la valeur au reste de la politique.

Ce qu’il ne faut pas faire

• Ne changez pas l’adresse. L’attaque la suit en moins d’une minute et maintenant votre DNS est faux aussi.
• Ne redémarrez pas. Une instance qui redémarre est une instance plus lente, pas une instance filtrée.
• Ne collez pas une règle nftables de mille lignes en panique. Tout ce que vous abandonnez sur l’instance a déjà traversé la partie coûteuse du réseau.
• Vérifiez d’abord /status. Si le site lui-même a un incident, il est publié là avant que votre ticket ne soit écrit.

Ouvrez le ticket quand même

ID d’instance, horodatages avec fuseau horaire, ce qu’était réellement le symptôme et si le service était joignable depuis un deuxième réseau. Le délai de première réponse médian est de onze minutes à chaque heure de la journée, et pendant un événement en direct, la réponse vient de quelqu’un qui regarde déjà le graphique.