Post-mortem on the recent technical issues

🕒 1 month(s) ago

Bonjour,

Ces derniÚres semaines, nous avons encaissé des dysfonctionnements techniques d'une certaine ampleur causant plusieurs pannes de nos services.

Panne serveur

27 septembre 2019 à 00h32 : Le serveur sur lequel était hébergé notre VPS s'éteint.

En conséquence, tous nos services et notre site web se retrouvent hors-ligne.

00h40 : Nous prenons conscience de ce problĂšme par chance, faute de manque de monitoring.

Nous tentons d'abord de redémarrer le serveur depuis l'interface de notre hébergeur, Proxgroup. Mais puisque toute la node qui l'héberge est hors-ligne, l'opération échoue.

01h00 : Nous avons publié une annonce de service sur Mastodon.

01h17 : Nous créons un ticket sur l'interface de Proxgroup, au niveau d'urgence "critique". Nous craignons en avoir pour la nuit voire le week-end

01h29 : Comme par miracle, l'un des membres du staff de Proxgroup nous répond 12 minutes aprÚs, en ayant constaté le problÚme et redémarré le serveur.

Notre serveur a donc été redémarré à 01h26, avec tous ses services.

01h40 : AprÚs avoir vérifié plus amplement que tout est bien fonctionnel à nouveau, nous publions une deuxiÚme annonce de service sur Mastodon.

Selon leur page de statut, il s'agirait d'une panne rĂ©seau. En tout cas, il s'agit du premier incident de la sorte depuis que nous sommes chez eux et ils ont rĂ©agi en un temps record (12 minutes Ă  1h30 du matin, quand mĂȘme). Un grand merci Ă  eux !

"Attaque" sur le proxy DoH

Nous avons constatĂ© une montĂ©e en charge phĂ©nomĂ©nale de notre proxy DoH Ă  partir du 24 septembre 2019 Ă  09h10. Nous recevions peu de requĂȘtes, mais provenant d'un trĂšs grand nombre d'IPs. Les requĂȘtes Ă©taient Ă©trangement formĂ©es et semblaient utiliser des implĂ©mentations obsolĂštes du DoH ou mĂȘme des extensions qui ne semblent pas documentĂ©es.

Ce "spam" générait une quantité assez importante de trafic et a eu pour conséquence quasiment immédiate de bannir notre proxy des résolveurs de FDN, bloquant l'accÚs au service pour tous les utilisateurs.

Nous n'avons malheureusement pas mis en place une solution de monitoring et de protection suffisamment efficace pour couvrir ce vecteur d'attaque. Nos ratelimits s'appliquent par IP pour ne pas dégrader la qualité du service pour les autres clients.

Notre serveur a donc continuĂ© Ă  se faire spammer durant 24 heures. Le trafic a augmentĂ© de maniĂšre exponentielle, mais nos serveurs ont tenu bon. Cependant, aucune de ces requĂȘtes n'a abouti car nous Ă©tions bannis par FDN.

Durant ces 24 heures, nous sommes passĂ©s de 40-80 IPs uniques par jour utilisant nos services Ă  20 000 IPs uniques, ainsi que 565 000 requĂȘtes provenant de ces IPs contre environ 60 000 habituellement, soit environ 10 fois notre trafic habituel.

Le 26 septembre 2019 vers minuit, nous nous sommes rendus compte de l'attaque et avons immédiatement stoppé le service.

Il nous a fallu plusieurs heures pour dĂ©velopper des solutions de protection, qui ont consistĂ© Ă  bloquer ces "requĂȘtes malformĂ©es".

Graph d'activitĂ© sur le DoH Screenshot : RequĂȘtes traitĂ©es par le service DoH.

Graph d'activitĂ© sur le DoH + IPs bannies Screenshot 2 : RequĂȘtes traitĂ©es par le service DoH, en incluant les visiteurs uniques dont l'IP est immĂ©diatement bannie sans donner suite Ă  la requĂȘte.

Nous avons demandé conseil à Stéphane Bortzmeyer et FDN pour avoir plus de détails sur la maniÚre dont nous devons gérer la situation.

Entre-temps, nous avons repĂ©rĂ© un commit sur le dĂ©pĂŽt de la liste des rĂ©solveurs de dnscrypt-proxy, un logiciel assez connu qui permet de chiffrer des requĂȘtes DNS.

La date du commit concorde : l'ajout de notre proxy Ă  cette liste est sans aucun doute l'Ă©lĂ©ment dĂ©clencheur qui a entraĂźnĂ© cette gargantuesque montĂ©e en charge. Cela explique pourquoi autant d'IPs nous ont attaquĂ©es en mĂȘme temps et pourquoi elles n'Ă©taient pas dans les blacklists de spam connues : elles Ă©taient lĂ©gitimes.

Ce commit a été rédigé par jedisct1, qui est notamment le développeur de doh-proxy et edgedns, logiciels que nous utilisons pour faire tourner nos services, et contient plusieurs erreurs :

  • Il mentionne que nous sommes l'association FDN (faux !) ;
  • Il mentionne que nous utilisons le DNS public de Google (encore plus faux !!).

Nous l'avons donc contacté pour démentir ces faits et, constatant que notre infrastructure n'allait pas tenir le coup si nous restions sur cette liste, nous avons émis une pull request sur son dépÎt pour retirer notre proxy des résolveurs DNSCrypt.

Depuis, nous avons optimisĂ© notre configuration pour rĂ©sister plus efficacement contre ce flux de requĂȘtes ; la mise Ă  jour de la liste devrait se propager peu Ă  peu et soulager notre service.

Entre-autres, nous avons paramétré notre cache DNS pour qu'il garde en mémoire ses entrées pendant 30 minutes minimum, sans tenir compte des entrées DNS dont le TTL est inférieur à 30 minutes ; cela devrait soulager les résolveurs de FDN pour un temps.

Raccourcisseur de liens

Nous avons dû faire face à une utilisation malveillante de notre service, nous l'avons donc remplacé.

Voir notre article sur rs-short pour plus de détails.

Leçons tirées

  • Nous devons installer des solutions de monitoring plus solides afin de voir venir ce genre de catastrophes et agir promptement.
  • En gagnant de la visibilitĂ©, nous nous exposons Ă  des montĂ©es en charge rapides et des attaques plus nombreuses et plus complexes Ă  gĂ©rer.
  • Il est peu concevable d'hĂ©berger un service en libre accĂšs et de partir du principe que "nous serons trop petits pour subir quoi que ce soit".
  • Il ne sert Ă  rien de paniquer comme un dingue lorsque les services sont down. Il faut respirer, lĂ , du calme, tout va bien, on va s'en sortir, ce n'est pas grave, allez, on rĂ©flĂ©chit ensemble et on y va.

On a encore du progrÚs à faire. En espérant ne pas décevoir vos attentes. :D

À bientît,

~ N&B