Une attaque DDOS (Distributed Denial Of Service) est un type d’attaque qui vient surcharger un serveur. Envoyez des milliers de requêtes, voire des millions, à un serveur dans un laps de temps suffisamment court et celui-ci ne sera plus en mesure de répondre aux requêtes qu’on lui envoie.

Durant la semaine qui vient de s’écouler le Luxembourg a été la cible d’attaques par DDOS à deux reprises. Ce sont d’abord les sites de l’Etat qui ont été pris pour cible. Le site du Gouvernement, plusieurs Ministères et le site de la Sécurité Sociale ont été indisponibles et se sont vu afficher un message d’erreur pendant plusieurs heures. La seconde vague a ciblé des sites de localités importantes au Luxembourg rendant également les visites sur ces sites impossibles.

Un niveau d’attaque que je juge élevé, car pas mal de services digitaux ainsi que l’accès à de l’information importante se sont vu temporairement bloqués. Et cela impacte directement tous les citoyens et frontaliers du Luxembourg.

À l’heure où j’écris ces lignes, il y a visiblement encore une attaque en cours et je manque d’information sur sa nature et son ampleur ainsi que les sites qu’elle vise. Tout ce que je sais, c’est que je suis développeur au Luxembourg et que je gère des sites qui pourraient potentiellement être pris pour cible. Pour cette raison, j’ai une petite pensée pour toutes les équipes qui sont sur le pied de guerre en ce moment même pour faire face à cette attaque.

Quand je vois des sites importants tomber, ça me laisse perplexe et je me demande ce que je ferais si cela devait m’arriver. Quelle serait l’intensité de l’attaque ? Combien de sites seraient touchés en simultané ? Comment pourrais-je me protéger contre ce type d’attaque ? Tant de questions que je me pose et qui me laissent un peu dubitatif. Malheureusement, je ne pourrais y répondre que lorsque j’y serai été confronté.

Lorsque j’ai pris connaissance de l’attaque, j’ai directement pris l’initiative d’émettre la première alerte par rapport aux sites web dont nous avons la gestion, et en quelque sorte envisagé le pire. Avec l’équipe, nous avons lancé une petite cellule de crise afin de se préparer au mieux à faire face aux mêmes types d’attaques. Après cette réunion nous avons donc entrepris une série d’actions. Des actions que je vais te décrire ci-après et que je te recommande fortement d’étudier et de mettre en place si tu penses pouvoir être la cible de d’attaque par déni de service.

La première chose que nous avons fait était de déterminer les cibles les plus probables. Chacun y va un peu de son évaluation personnelle mais il en est ressorti principalement les sites d’utilité publique, le secteur hospitalier ainsi que les e-commerces. Ces dernières années le secteur hospitalier est pris pour cible de manière récurrente, je trouve cela vraiment lamentable. Heureusement ici que le DDOS ne détruit ni ne vole de données.

La seconde chose que nous avons faite est de contrôler l’ensemble des firewalls des serveurs des sites de notre fameuse liste de cibles potentielles. Ce n’est pas forcément évident d’ajuster un firewall contre du DDOS car on souhaite que le site soit toujours disponible mais l’idée est de réduire tout ce qui pourrait arriver sur le serveur (réduction de la surface d’attaque). En conséquence il faut tout restreindre à part deux ports, le 80 et 443, qui correspondent aux ports HTTP et HTTPS. Je conseillerais même de désactiver l’ICMP (ping). Au niveau des autres ports, il faut ajuster la configuration, par exemple chez nous le port SSH (usuellement le 22) n’est autorisé uniquement que depuis notre adresse IP.

Sur les serveurs où nous avons reçu des connexions depuis la Russie, qui semble-t-il est le pays d’origine de ces vagues de DDOS, nous avons fait le choix de passer la mitigation en statut actif (par défaut c’est en automatique). OVH propose ce service qui permet d’analyser constamment le trafic et de bloquer des attaques.

La troisième chose que nous avons entreprise est de contrôler nos backups et notre système de sauvegarde. Cela peut paraître futile au premier abord, mais si jamais nous n’avions plus la capacité d’accéder à une machine pendant plusieurs heures ou plusieurs jours, cela me semble logique d’avoir les dernières versions des fichiers avec les données les plus récentes disponibles et d’avoir la possibilité de redéployer celle-ci au besoin.

Je gère pas mal de WordPress et malheureusement sa notoriété est aussi sont point faible. C’est un des CMS les plus utilisés dans le monde et donc l’un des plus attaqués. À cela s’ajoute qu’il y a toujours une pléiade de plugins qui accompagnent le coeur de WordPress pour accélérer le développement ou l’agrémenter de fonctionnalités. Le problème, c’est les failles de sécurité sont découvertes souvent plusieurs jours avant la planification de mises à jour de notre côté. Même si ce n’est pas la nature de l’attaque en cours qui est de surcharger la machine et non d’exploiter une faille particulière, j’ai tout de même fortement recommandé de mettre à jour certains sites web.

Le monitoring passif est quelque chose de vital dans notre métier. À l’agence, nous avons du monitoring qui opère sur des parties bien distinctes. Le plus important est de savoir si un site est UP (accessible) ou DOWN (non accessible). Pour ça, on se sert d’un outil externe, StatusCake qui vient lancer des requêtes à intervalles régulières et qui notifie l’équipe par e-mail ou sms dès qu’un site vient à être inaccessible.

Le second outil est un plugin dédié à WordPress qui vient faire un travail sur plusieurs aspects dont la détection de brute force et l’altération de fichier pour ne citer que ces deux points. Le programme vient automatiquement bannir des IPs pendant un certain temps, ce qui nous permet de nous concentrer sur autre chose.

Enfin, la consommation de ressources anormale ou élevée (qui dépasse des seuils définis) est l’un des points qui peut être révélateur d’une attaque. Dans la plupart des cas, une grosse attaque DDOS va venir augmenter l’ensemble des métriques du serveur et on en sera directement informés.

L’objectif parallèle à cette situation est aussi de relever le niveau de compétence des membres de l’équipe sur les aspects de sécurité. On essaye de se former en continu et de faire un partage de connaissance dès que cela se présente à nous. Dans la situation présente, savoir agir et agir rapidement est tout aussi important que de prévenir.

Pour ma part, j’ai formé les équipes à identifier des adresses IPs dans des fichiers de logs et à les bannir (au besoin).

Se faire attaquer par une seule adresse IP, cela porte un nom, du Flood ou encore DOS. C’est le genre d’attaque qu’on subit régulièrement et qui est facile à bloquer. On met une règle un peu où on veut, firewall réseau, WAF, ou encore Apache. En général c’est très efficace et rapide à mettre en place.

Une attaque DDOS utilise plusieurs ordinateurs. Cela peut aller de multiples machines louées pour réaliser l’attaque, de personne qui « prêtent » leur ordinateur pour participer à l’attaque sans avoir de connaissance technique, jusqu’aux machines zombies, c’est-à-dire des ordis qui se sont fait infectés par un virus et qui vont participer à l’attaque à l’insu de leur propriétaire. C’est extrêmement compliqué à contrer car cela génère beaucoup trop d’IPs pour les lister manuellement dans un fichier de configuration d’IPs à bannir. En tout cas par un humain.

C’est ici qu’intervient le blocage par CIDR qui permet de bannir une place d’adresses IPs avec une syntaxe particulière (par exemple 31.32.33.0/24). C’est idéal pour bannir des attaques qui proviennent d’un bloc d’IPs précis.

Bloquer une adresse IP ou un CIDR c’est bien, mais ça ne suffirait pas à bloquer des attaques provenant de plusieurs territoires. C’est ce qu’il y a en ce moment, on voit des attaques principalement en provenance de Russie mais pas que. Bloquer un pays c’est possible, il suffit de collecter l’ensemble des blocs d’IPs attribuer à la Russie et de tous les bloquer. Ce qui est compliqué c’est d’avoir une liste relativement à jour et de procéder à un blocage exhaustif car cela peut représenter des milliers, voire des millions d’adresses IPs.

En tout cas on a préparé les équipes à cette éventualité. Si on devrait n’autoriser l’accès aux sites qu’uniquement depuis le Luxembourg ainsi que les pays limitrophes, on est techniquement préparés à le faire.

C’est sans doute le plus compliqué dans ce type d’attaque. Conserver l’accès à son serveur. Pour moi, il ne faut pas faire dans la dentelle et ça vient à couper tout sauf notre propre adresse IP. C’est une opération qui doit se faire le plus haut possible, c’est-à-dire devant le serveur, genre au niveau de l’hébergeur. Si ce n’est pas faisable, tu peux tenter de le faire plus bas, par exemple au niveau de la config Apache ou Nginx.

Une autre solution est de ne pas tenter de bloquer le DDOS mais simplement d’optimiser la délivrance du contenu. Un peu comme si tu travaillais chez Facebook et que c’était normal de devoir servir des millions de requêtes. Pour ça il existe quelques astuces. Servir rapidement c’est déjà stopper Apache au profit de Nginx qui sera capable de répondre à plus de requête. Ensuite servir uniquement du fichier statique. Transformer tout un site dynamique en site statique demande plusieurs jours de travail donc ce n’est pas envisageable comme solution de secours. À ce moment-là, je te conseillerais de passer l’ensemble du trafic sur une page de maintenance (statique) qui explique la situation à tes clients en attendant un retour à la normale ou une adaptation du site web.

Si comme moi tu as de l’IP Fail Over sur ton domaine principal et que tu n’aurais plus accès à ton serveur mais que l’infra (hébergeur) est toujours accessible, tu peux monter une instance. Genre un petit Linux avec Nginx qui se charge uniquement de servir un fichier HTML. Ensuite au niveau de l’IP FO, tu envoies tout le trafic sur cette nouvelle machine le temps de récupérer l’accès au serveur et d’ajuster la config.

Par contre, j’ai pu voir que certains sites d’Etat était déjà dans une configuration avec du fichier statique et que cela n’a visiblement pas suffi.

Je ne vais pas rentrer dans une longue explication sur la configuration de serveur mais il existe encore une solution, elle est toute bête et « pas chère ». Ca s’appelle la scalabilité.

La scalabilité verticale, c’est simplement prendre une machine plus puissance. Doubler la puissance (notamment CPU) permet en général de servir plus de requêtes car le calcul de page dynamique se fait bien plus rapidement. C’est pas cher si tu le compares à un taux horaire d’expert en sécurité ou si tu payes un employé le week-end. Et c’est très facile à mettre en place. Si c’est du cloud ou un VPS, c’est fait en quelques clics sans même changer la configuration.

La scalabilité horizontale, c’est quand tu as une infrastructure avec plusieurs machines qui répondent. Ce n’est pas évident à mettre en place surtout si tu as un site dynamique, un système de session ou des informations qui sont sur une base de données mais qui doivent être partagées aux utilisateurs. Si c’est pensé dès le départ c’est facile, il suffit de scaler en fonction de la charge, si ce n’est pas déjà dynamique. Si ce n’est pas le cas, tu ne pourras sans doute pas la mettre en place sans revoir toute l’architecture du projet.

Je pense que pour répondre efficacement à ce genre d’attaque, il faut designer l’infra comme si contrer du DDOS était un besoin fonctionnel.

Déléguer la problématique à des experts me semble être une bonne solution, il y a plusieurs acteurs sur le marché comme P5 ou encore Cloudflare. Personnellement je n’ai pas d’expérience avec ces deux services mais je sais que je vais devoir me pencher sur le sujet.

Monter un reverse proxy est aussi une des solutions. Il y a beaucoup d’avantages. Tu peux gérer la sécurité sur un seul point d’entrée pour plusieurs domaines et le scaler facilement (voir point ci-dessus). Couplé avec du cache, tu peux également répondre à certaines requêtes sans faire le moindre appel aux serveurs qu’il y a derrière ou encore définir des règles bien spécifiques pour autoriser ou refuser certaines requêtes. Par exemple interdire de servir du contenu vidéo afin d’éviter les attaques par saturation de bande passante.

Mettre en place un CDN permet de distribuer une partie du contenu (notamment les fichiers statiques) depuis des services qui vont avoir une très grosse capacité de délivrance et en général de très bons systèmes de sécurité contre le DDOS. Il est possible aussi héberger l’ensemble d’un site web sur un service de CDN, à ce moment-là tu augmentes considérablement ta capacité à faire face à du DDOS.

Il existe bien évidemment une multitude de services et de techniques pour faire face à ce type de menace. Le choix de la mise en place sera d’abord une question de coût et ensuite pour, des raisons légales ou politiques. Au Luxembourg on évitera d’utiliser des services hors de l’union Européenne lorsqu’il y a du stockage de données utilisateurs.

On vit dans un monde où l’informatique est omniprésente. Avec l’automatisation et l’émergence de l’IA, nous devons nous attendre à bien pire dans les années à venir. Pour cette raison je pense qu’il faut mettre la sécurité beaucoup plus en amont des projets. Il faut sensibiliser nos clients sur les risques et pouvoir répondre à certains types d’attaques. Ne pas fermer les yeux et croire que tout est automatiquement géré par quelqu’un plus loin ou plus en dessous car ce n’est pas vrai. Il faut bien entendu déplacer le curseur en fonction du besoin et de la nature du projet.

Dans les prochains jours, je vais essayer de collecter des informations sur ce que les équipes qui ont dû faire face aux attaques ont mis en place pour contrer ces attaques. Les choix qu’ils ont opérés et ce qu’ils préconisent de faire en cas de DDOS. Voir un peu ce qu’il est possible d’implémenter chez nous, améliorer nos procédures et mieux se préparer à ce genre de situation.

La sécurité c’est un sujet qui malheureusement est autant passionnant qu’inquiétant. Passionnant car techniquement ça nous amène à des niveaux assez élevés et inquiétant car on voit que ça touche directement le fonctionnement de services importants pour les citoyens.