Comment on a survécu à une attaque DDOS

Comme j’en ai parlé hier, la communauté d’Hackademics à avant hier soir subit une attaque DDOS Web modérée (une centaine d’IP faisant environ 50.000 requêtes toutes les 10 secondes).

Même si nous avons subi cette attaque et que nous avons du fermer le serveur web pendant un certain temps (ce qui prouve un léger manque de préparation), je suis assez content de me rendre compte que nous avons assez bien su la gérer.Nous avons gardé notre calme et avons directement bien réagi face à l’attaque. Les services étant en effet de retour en ligne après 2 heures de downtime environ.

Mais pour bien faire, laissez moi vous raconter toute l’histoire.

Lundi soir, vers 22h, j’ai reçu une notification Telegram de mon serveur Nagios me signalant que tous les sites hébergés sur le serveur d’Hackademics étaient disparu d’un seul coup.

Après un test manuel, pour vérifier que ce n’était pas Nagios qui était à incriminer, nous nous  sommes rendu compte qu’en effet, le serveur semblait bel et bien avoir un problème.

Un htop en ssh nous a montré que tous les CPUs étaient à 100% que la RAM allait bientôt exploser et que Nginx était assez loin d’être content.

Du coup, pour commencer par libérer des ressources sur le serveur, nous avons commencé par fermer quelques ressources qui n’étaient pas indispensables (Gitlab pour exemple qui est fort consommateur. Cela a permis de ne pas se retrouver avec un plantage complet du serveur et une impossibilité de se connecter en SSH.

Ensuite, une analyse des logs de Nginx nous a fait nous rendre compte que c’était le site par défaut (une simple page web statique que nous avons mise en place) qui était DDOS par des requêtes GET à un rythme assez important.

Évidement, lors de l’installation du serveur, nous avions pensé qu’une attaque DDOS des sites était possible. Nous avons donc mis en place un anti DDOS avec Nginx, une limite de requêtes par seconde et fail2ban. Cependant, nous l’avons mise en place sur les sites importants du serveur et n’avons pas pensé à le faire sur le site par défaut.

Notre première action a donc été de fermer les ports 80 et 443 avec une règle firewall. Cela ayant permis de faire redescendre la charge du serveur à un niveau normal pendant que nous prenions une décision éclairée.

Et pour cette décision, notre premier choix n’a malheureusement pas été le bon. En effet, nous nous sommes dit que nous pourrions rendre ce site par défaut uniquement accessible à l’IP locale du serveur. Cette idée pouvait paraître intéressante mais un test de réouverture des ports webs à montré que les requêtes arrivant quand même à Nginx, la charge était toujours assez importante bien que légèrement réduite.

Du coup, notre seconde idée, qui fut elle fructueuse, a été d’opérer un blocage firewall de toutes les IPs ayant tenté de se connecter au serveur depuis le dernier logrotate lundi matin.

Ce bloquage firewall se déroulant en amont de Nginx, ce dernier ne recevait plus les requêtes et la charge du serveur était donc revenue à la normale.

Nous avons ainsi donc pu ré-ouvrir les ports, les sites, les services qui avaient été fermés et la situation était revenue à la normale … ou presque.

En effet, bloquer toutes les IPs depuis le logrotate a également banni certains clients légitimes. Nous étions bien évidement conscients de ce problème mais avons toutefois décidé de laisser ce filtrage légèrement trop restrictif entre lundi 23h et mardi 6h.

Mardi matin, nous avons alors débanni toutes les IPs (dont celles de l’attaque terminée de la nuit) et avons alors pris le temps de définir quand l’attaque avait exactement commencé pour savoir quelles IPs en faisaient vraiment partie. Pour ce faire, nous avons utilisé l’outil de mitigation de DDOS que je vous ai présenté hier et la situation est maintenant revenue à la normale.

Après un jour de recul sur le problème, voici les enseignements que j’en tire :

  • L’utilisation de Nagios et des notifications de ce dernier sur une application que j’utilise tout au long de toutes mes journées nous a permis d’être mis au courant juste une ou deux minutes après le début de l’attaque et nous a donc permis d’être pro-actifs dans notre réponse et d’éviter un plantage complet
  • Nous devrions mettre une protection anti-DDOS sur tous les sites et pas uniquement les plus importants
  • Mettre en place le blocage au niveau du serveur Web n’est pas suffisant vu qu’il subit quand même la charge même si cette dernière est amoindrie
  • À la place de bloquer toutes les IPs depuis le logrotate, nous aurions pu bloquer directement les bonnes avec notre outil de mitigation.

En conclusion donc, même si certains points de notre réaction pourraient et vont être améliorés, je pense que nous avons assez bien surmonté l’attaque. Les décisions ont été rapidement prises et misent en place et la situation était revenue à la normale deux heures après le début de l’attaque.

Il est certain qu’elle était d’ampleur modérée mais pour un serveur de petite taille, une attaque modérée peut rapidement prendre une assez grande ampleur.

Finalement, nos actions pendant l’attaque n’auront été que palliatives mais les enseignements que nous en avons tirés vont également nous permettre d’améliorer notre comportement préventif. Que du positif donc !

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *