Date du post mortem : 15/01/2020
Participants du post mortem :
Note : L’incident suivant est relatif au datacenter situé chez AWS (euwest1) suite à une attaque.
Le 14/01/2020, à partir de 18h09, tous les proxys sont devenus indisponibles et les utilisateurs ont commencé à recevoir des erreurs 502. La bascule DNS s’est déclenchée automatiquement une première fois à 18h12, le trafic est revenu chez Fasterize de 18h17 à 18h21 puis a été basculé manuellement à 18h23.
L’indisponibilité des proxys est due à une saturation du CPU. Les pings et le trafic sont fortement impactés (erreur 502 et temps de réponse) et les proxys sont perçus comme indisponibles par les frontaux. Dans ce cas là, le code d’erreur généré par les frontaux (502) n’est pas utilisé pour faire un failover (ie. retry) à l’origine, ceci pour ne pas faire un retry sur un 502 qui proviendrait de l’origine et qui pourrait aggraver un éventuel problème de l’origine.
Après le débranchement de 18H23, nous constatons qu’il reste principalement un trafic suspicieux mélangeant diverses catégories d’attaques. Ces attaques échouent mais génèrent une consommation anormale sur les proxys.
Nous tentons de désactiver et redémarrer les proxys : tant que le proxy ne reçoit pas le trafic, il reste stable. Après une désactivation, il reste chargé quelques minutes puis finit par retrouver un état stable (signe qu’il n’y a pas un blocage permanent). A 19h15, nous identifions une exception non catchée lors de l’accès au storage qui fait redémarrer les processus plantés et amplifie la consommation CPU lors du chargement des configurations clientes.
Le blocage de l’attaquant sur le proxy résout le problème de charge : la consommation CPU se situe donc après le middleware de filtrage d’adresses IP.
Afin d’éviter les exceptions de connexion au storage, nous désactivons l’accès au header store (ie. Early Hints/preload) en patchant le code (pas de feature flag global).
La décision de rerouter le trafic sur Fasterize est prise lorsque l’attaque est clairement identifiée et mitigée.
18h09: premier pic d’erreurs 502 au niveau des proxys
18h10 : première alerte du système de supervision concernant l'indisponibilité des proxies
18h12 : bascule automatique vers les origines client
18h15 : l'équipe tech se réunit
18h17 : rebascule automatique vers Fasterize
18h19 : premier mail au support indiquant un problème de 502
18h21 : bascule automatique vers les origines client
18h23 : l’ensemble des clients de la plateforme est débranché manuellement via le système de coupure d’urgence.
18h29 : publication d’un message sur la page de status de la plateforme
18h36 : fin des erreurs 502
18h40 : première suspicion d’attaque en constatant des URL forgées - mais difficile de lier ces URL à la consommation CPU des proxys
19h15 : identification d’une exception non catchée lors de l’accès au storage depuis les proxys => redémarrage automatique des processus plantés
19h18 : test de désactivation du storage - sans effet
19h44 : adresse IP de l’attaquant bloquée au niveau des proxys
19h45 : nouveau message pour indiquer que nous avons identifié une saturation CPU des proxys
19h56 : envoi d’une requête d’abus à l’hébergeur de l’attaquant (abuse@ovh).
20h22 : nouveau message pour indiquer que nous avons identifié la corrélation entre une attaque sur un client et la saturation CPU
20h20 : prise d’un échantillon des requêtes provenant de l’attaque pour analyse ultérieure
20h25 : mise en place d'une règle WAF au niveau CDN afin de bloquer les requêtes provenant de l’adresse IP de l’attaquant
20h29 : nouveau message pour indiquer que le trafic est rerouté sur la plateforme.
20h50 : fin des requêtes provenant de l’attaquant
Temps de résolution :
L’ensemble des clients a été impacté, une petite partie nous a contacté : tickets (10) + appels en direct (1) + SMS (2)
Les pages et les objets cachés ont été servies normalement. Tout ce qui passait par le proxy a été impacté (panier, fragments SmartCache).
Court terme :
Moyen terme :