Rapport d'incident : Atténuer un massive DDoS impactant notre infrastructure

TL;DR

Le jeudi 16 juillet 2020, notre infrastructure a été impactée par ce qui a finalement été diagnostiqué comme une attaque par déni de service distribué (DDoS), causant une indisponibilité partielle ou totale de nos osc-fr1 et osc-secnum-fr1 régions. L'attaque a eu un impact à la fois sur la plateforme Scalingo elle-même ainsi que sur les applications hébergées de nos clients. Cet article détaille le cours des événements, analyse la réaction de l'équipe et détaille quelles actions seront entreprises pour améliorer la situation à l'avenir.

Chronologie de l'incident

Tous les horaires sont en heure d'été d'Europe centrale (CEST).

• [10:58] Premiers alertes, certains composants de notre infrastructure sont détectés comme inaccessibles par nos sondes externes, notre équipe est alertée. Création d'un post sur notre page de statut annonçant des problèmes de réseau pour accéder à l'infrastructure. Début du diagnostic.

• [11:00] Notre infrastructure est inaccessible. Nos adresses IP publiques sur les régions osc-fr1 et osc-secnum-fr1 ne répondent à aucun type de demande effectuée par nos opérateurs. Notre fournisseur d'infrastructure Outscale est contacté.

• [11:18] La situation revient à la normale, durée de l'interruption : 20 minutes. Nous avons reçu l'accusé de réception qu'un problème de réseau impactait l'accès au réseau entier.

• [12:30] Des alertes se déclenchent à nouveau, même type de comportement que la vague précédente mais uniquement sur osc-fr1 : l'accès au réseau est indisponible pour la deuxième fois.

• [13:00] Nous recevons l'information d'Outscale que la source du problème semble être une attaque DDoS.

• [13:40] Outscale a décidé de couper le trafic de l'IP ciblée (c'est-à-dire de blackhouler le trafic) de notre infrastructure pour limiter l'impact de l'attaque sur leur infrastructure. Le trafic HTTP/HTTPS vers l'application est maintenant routé via notre IP de secours. Cela nous a laissé avec une seule IP pour gérer les demandes des clients à leurs applications. Certains de nos clients ont pu subir des délais d'attente de connexion pendant ce basculement.

• [13:57] Le réseau semble être opérationnel à nouveau, durée de l'interruption : 1h27.

• [16:45] Nouvelle vague d'attaque, sur notre IP de secours cette fois, jusqu'à 16:51, durée : 6 minutes d'indisponibilité.

• [17:41] Les alertes sonnent à nouveau, communication étroite avec Outscale sur ce qui est possible ici pour atténuer l'attaque de manière définitive. Heureusement, ils évaluaient une plateforme d'atténuation DDoS depuis quelques semaines. Ils proposent de l'installer pour nous afin de couper le trafic malveillant avant qu'il n'arrive au centre de données.

• [18:05] Il est décidé d'arrêter de faire circuler tout trafic par les deux IP qui sont la cible de l'attaque et de commencer à utiliser une nouvelle IP publique.

• [18:17] Une nouvelle IP publique est provisionnée et utilisée par défaut pour toutes les applications utilisant *.osc-fr1.scalingo.io ou les domaines ayant configuré un champ DNS CNAME. Les utilisateurs utilisant un champ A sont encouragés à nous contacter sur le chat de support pour obtenir la nouvelle IP à utiliser.

• [18:30] L'attaque est toujours en cours et a un impact sur toute la région. Outscale est toujours en train de mettre en place la solution anti-DDoS spécifiée ci-dessus.

• [19:15] La solution d'atténuation est mise en place, nos IP publiques initiales sont restaurées. L'attaque est toujours en cours, mais aucun impact sur l'infrastructure Scalingo ni celle d'Outscale. Cette dernière vague a entraîné une indisponibilité partielle de 1h34.

La durée totale cumulée d'interruption de cet incident était de 1h53, et une interruption partielle de 1h34.

Analyse

L'incident a été le premier DDoS massif subi par Scalingo. Nous avons été attaqués dans le passé mais pas à ce point. Un effet d'attaque DDoS est qu'il remplit complètement les tuyaux de réseau avec du contenu forgé, empêchant le trafic légitime d'atteindre sa destination.

Des milliers d'IP du monde entier ciblaient notre infrastructure avec un flot de requêtes : 8 Gbps de trafic et environ 1 000 000 connexions par seconde étaient tentées par l'attaquant. L'attaque a eu lieu sur le port 443 (HTTPS), et générait des requêtes HTTPS avec des en-têtes extrêmement volumineux pour amplifier le volume de données envoyées à notre plateforme. Nous supposons qu'il s'agissait d'un botnet loué, un grand ensemble de dispositifs infectés contrôlés à distance. Selon les statistiques de Cloudflare, en 2019, 92 % des attaques DDoS étaient inférieures à 10 Gbps, donc cette attaque était dans la partie supérieure des attaques DDoS courantes.

La cible de l'attaque était un site web spécifique hébergé par nos services. Il n'a pas été déterminé pourquoi leur site web était la cible d'une telle attaque. Il ne stocke aucune information sensible, ni quoi que ce soit de précieux qui pourrait généralement être la cible de ce type d'attaques.

Avoir plusieurs adresses IP pour servir notre infrastructure n'a pas aidé au début car toute la bande passante d'Internet du centre de données était remplie de requêtes des attaquants, bloquant l'accès à tout le réseau quel que soit l'IP cible. Nos services étaient impactés ainsi que d'autres entités partageant la même infrastructure. Avoir plusieurs adresses IP nous a aidés à atténuer l'attaque, modifiant la manière dont elles étaient routées individuellement.

Impact

Comme énuméré dans la chronologie des événements, 4 vagues d'attaques ont eu lieu. Au cours de ces événements, les symptômes suivants sont apparus :

• Délai d'attente lors de l'accès aux services Scalingo (Tableau de bord, API, Déploiement, Conteneurs One-off, etc.)

• Les auto-déploiements / applications de révision des intégrations SCM ont échoué. Nous avons peut-être manqué des opérations puisque les webhooks des différentes plateformes n'atteignaient pas non plus nos services.

• Délai/Connexion refusée lors de l'accès aux applications déployées sur Scalingo.

Communication

Notre page de statut https://scalingostatus.com a été mise à jour régulièrement tout au long de la journée.

Nous avons répondu à tous les messages venant par Intercom soit via le chat dans l'application, soit par notre email de support support@scalingo.com.

Notre compte Twitter @ScalingoHQ a posté sur les principales parties de l'incident.

Des informations spécifiques ont été transmises personnellement à certains clients ou à des personnes qui ont demandé.

Actions entreprises et plan futur

Au cours des incidents, plusieurs actions ont été tentées pour atténuer l'impact de l'attaque sur l'infrastructure d'Outscale et sur les clients de Scalingo.

• La première action entreprise a été d'identifier l'IP attaquée et de propager une instruction de route "Blackhole" aux voisins. Cette action a été entreprise par Outscale pour empêcher le trafic d'encombrer leur réseau entier. Nous avons ensuite uniquement utilisé la seconde IP pour acheminer les demandes des clients jusqu'à ce que l'attaque l'impacte également.

• Lors de l'opération normale, Scalingo a 2 principales IP pour atteindre les applications hébergées par Scalingo. Nous avons rapidement configuré une troisième IP de secours au cas où Outscale devait blackhouler nos deux IP habituelles. Nous avons gardé cette troisième IP secrète, jusqu'au moment où nous en avions vraiment besoin. Nous avons commencé à l'utiliser à 18h30.

• Outscale n'a pas encore de solution anti-DDoS officielle en tant que produit public. Cependant, ils étaient en train d'évaluer une telle solution. Au vu de la gravité de l'incident, il a été décidé d'en faire usage pour atténuer l'attaque à la fin de l'après-midi. Ils prévoient d'étendre son utilisation pour prévenir automatiquement les attaques futures.

• Gestion des requêtes HTTP : Un système de file d'attente existe déjà, si une application n'est pas en mesure de faire face à l'entrée des requêtes HTTP, après avoir mis en file d'attente 50 requêtes par conteneur, les requêtes suivantes sont automatiquement supprimées, empêchant ainsi de surcharger nos routeurs HTTP, ce processus a fonctionné correctement et ne sera pas modifié.

Quelques mots pour conclure

Tout d'abord, nous voulons remercier nos clients qui ont été très compréhensifs et encourageants pendant l'incident.

Nous sommes pleinement conscients qu'un tel incident a un impact important pour vous tous. C'est pourquoi notre équipe gère une rotation d'astreinte 24/7 pour gérer l'infrastructure afin que vous n'ayez pas à le faire.

Les incidents se produisent et c'est notre rôle de les gérer aussi bien que possible et d'être préparés pour eux.

Les attaques DDoS sont toujours difficiles à appréhender en raison de leur nature, des attaques fantômes remplissant simplement toute capacité possible disponible. Nous avons rédigé des procédures pour les traiter mais l'ampleur de cette attaque était énorme.

Nous avons eu un excellent contact avec l'équipe d'Outscale. Nous avons confiance dans notre choix de partenaire ici, ils nous ont aidés à nous remettre sur pied grâce à leur réseau de partenariats.

Nous surveillons de près la mise en œuvre de la fonctionnalité anti-DDoS proposée par Outscale pour protéger vos applications de ce type d'attaques à l'avenir.

Compensation financière

Comme l'indiquent nos conditions de service, nous proposons un SLA de 99,9 % à nos clients professionnels (99,96 % pour les bases de données utilisant un plan professionnel).

Nous sommes pleinement conscients que le temps d'arrêt survenu le 16 juillet a lourdement impacté cet engagement.

Par conséquent, tous les clients professionnels recevront automatiquement une compensation financière de 10 % sur leur facture pour le mois de juillet (5 % par heure de temps d'arrêt).

Pour être considéré comme un utilisateur professionnel, vous devez posséder au moins une application avec une base de données utilisant un plan professionnel et au moins 2 conteneurs servant un trafic web ou TCP à votre application.