Attaques en déni de service distribué : étude de cas

La plupart des cyberattaques subies par les entreprises sont la conséquence directe d’une méconnaissance des risques et de négligences humaines, elles pourraient être évitées relativement facilement. Il est une menace contre laquelle il est très délicat de lutter : le déni de service distribué (ou DDOS).  A cet égard, les désagréments subis récemment par Mastercard, Paypal ou Postfinance en Suisse1 en représailles aux mesures prises à l’encontre de Wikileaks, constituent un exemple évocateur. Le présent article propose d’expliciter quelque peu la notion de DDOS avant de fournir une mesure de remédiation facilement applicable pour les petites structures victimes de telles attaques.

 Qu’est-ce que le DDOS ?

Les attaques de type DDOS visent à rendre un service présent sur Internet (site web par exemple) indisponible en le bombardant de requêtes jusqu’à saturation. Pour ce faire, l’attaquant utilise généralement la puissance cumulée d’un grand nombre d’ordinateurs sous son contrôle (également dénommées « zombies »), pour constituer ce que l’on appelle un « botnet ».

Les attaques DDOS sont motivées par la volonté de nuire (à un ennemi politique ou à un concurrent par exemple) ou par l’appât du gain (demande de rançon). Elles sont particulièrement pernicieuses pour les raisons suivantes :

  1. Facilité de mise en œuvre : Pour une somme dérisoire (moins de 10$ par heure, 50$ pour 24h), n’importe qui peut louer un botnet sur Internet, auprès d’individus spécialisés dans ce genre de malversation.
  2. Difficulté à contrer l’attaque : Lorsqu’elle est touchée par une telle attaque, une organisation se doit de bloquer le trafic malveillant tout en essayant de maintenir un accès au service pour ses utilisateurs légitimes. Si l’attaque est bien ficelée, la distinction est très difficile à opérer.
  3. Évolution de l’attaque : Lorsque l’organisation victime met en œuvre une contremesure, l’attaquant adapte en général très rapidement sa stratégie pour maintenir la pression. La migration des services visés vers d’autres plages d’adresses IP constitue, à ce titre, une solution illusoire.

Les préjudices subis par une organisation sous DDOS peuvent s’avérer rapidement très problématiques. Ils sont de plusieurs ordres :

  • Impact sur l’image de marque : Lorsque l’affaire est relayée par les médias, l’entreprise souffre immanquablement d’une publicité négative. Voici un exemple très parlant de réaction aux déboires de Postfinance « Ralentissement ? Non, actuellement le site est complètement inaccessible. Très pratique pour faire ses paiements ! Merci la poste ! Et si des hackers peuvent le rendre inaccessible, alors on peut se demander s’ils ne peuvent pas accéder aux données bancaires qu’il contient ? »2
  • Impact financier matérialisé par la perte de clients indisposés par l’interruption de service et le manque à gagner lié aux transactions rendues impossibles, sans compter les coûts de remédiation à l’attaque ou le versement d’une éventuelle rançon.
  • Impact sur la productivité, une partie de l’infrastructure étant indisponible et des ressources devant être mobilisées en réaction à l’attaque.

Comme souligné précédemment, la mitigation d’un tel risque n’est pas aisée. Les grandes entreprises peuvent mettre en place des plans de crise, en coordination avec leur(s) fournisseur(s) d’accès. Certains de ces fournisseurs disposent en effet d’outils de filtrage sophistiqués permettant de bloquer les attaques en amont et peuvent allouer les ressources nécessaires pour endiguer les flux malveillants le cas échéant. Par contre, les FAI de plus petite taille voient bien souvent leurs propres infrastructures paralysées en cas d’attaque dirigée contre l’un de leurs clients et se voient contraints d’interrompre purement et simplement le routage du trafic vers ce dernier.

Étude de cas

Cette étude de cas se base sur un exemple concret, vécu en 2010 par une PME genevoise, qu’on nommera victime_ddos.

Contexte

La société victime_ddos dispose d’une connexion Internet ADSL de débit 20Mbps/2Mbps. Elle héberge dans ses locaux ses serveurs web et de messagerie.

Victime_ddos organise en avril 2010 une conférence. Elle publie quelques semaines auparavant un formulaire d’inscription sur son site web. Peu de temps après, elle reçoit un appel de son fournisseur d’accès, l’avertissant que son site www.victime_ddos.ch est la cible d’une attaque par DDOS. L’ampleur de l’attaque conduit à la saturation du réseau du FAI et contraint ce dernier à demander à ses propres fournisseurs (5 au total) de ne plus router l’adresse correspondant à www.victime_ddos.ch.

Victime_ddos tente alors de modifier l’adresse de son site web, en vain. L’attaque en effet vise le nom de domaine « www.victime_ddos.ch » et, à partir du moment où l’enregistrement de ce nom pointe vers la nouvelle adresse, l’attaque recommence.

Peu après, l’attaque s’étend au serveur mail de l’entreprise et vise désormais également le nom de domaine «mail.victime_ddos.ch ».
Si la direction de victime_ddos tolérait l’indisponibilité de son site web, elle est beaucoup plus préoccupée par son incapacité à communiquer avec le monde extérieur au travers de son serveur mail. Elle décide alors de réagir.

Solution adoptée

La solution ultime consiste à héberger les services visés chez un opérateur majeur disposant d’une large bande passante capable de supporter la puissance de l’attaque. L’on sait d’autre part que les loueurs de botnet sont très peu enclins à s’attaquer à de grosses structures qui disposent des moyens d’action nécessaires pour réagir et mettre fin à leurs agissements.

En attendant que la migration soit effective, ce qui prend environ deux jours, une solution temporaire a été mise en œuvre. Elle a consisté à utiliser l’environnement cloud gratuit Google App Engine (GAE) comme proxy inversé (reverse proxy).

La licence d’utilisation de ce service stipulant que Google dispose du droit d’utilisation des données à des fins commerciales a conduit victime_ddos à ne pas considérer cette solution comme définitive.

Pour le service web, un projet Open source de reverse proxy écrit en Python et utilisant les fonctions disponibles dans GAE a été utilisé.3 La nouvelle adresse IP du serveur web réel a été configurée et l’application a été installée dans le service GAE d’un nouveau compte Google, de façon totalement gratuite.

À ce compte a été attribué le nom de domaine « victime_ddos.ch » et l’enregistrement DNS « www.victime_ddos.ch » a été pointé vers des adresses IP de Google spécifiques à GAE.

Le service mail du même compte Google a été utilisé pour la messagerie électronique. Puisque ce service n’autorise pas la redirection, chacune des boîtes mail (@victime_ddos.ch) a été ajoutée comme adresse d’un groupe de type Restricted, et dans chaque groupe a été ajouté le membre correspondant avec un domaine secret : @secret.victime_ddos.ch.

L’enregistrement MX de victime_ddos a ensuite été redirigé vers les serveurs mail de Google et un nouvel enregistrement MX pour le domaine « secret.victime_ddos.ch » a été créé (« mail.secret.victime_ddos.ch »).

Ce dernier a enfin été configuré pour pointer vers la nouvelle adresse IP du serveur mail réel, où un alias du domaine « @ victime_ddos.ch  » a été ajouté, nommé « @ secret.victime_ddos.ch « , afin que les messages entrants puissent être redirigés vers les boîtes aux lettres correspondantes.

Conclusion

L’attaque par déni de service distribué vécue par victime_ddos s’est avérée frustrante. Face à un ennemi invisible œuvrant dans l’impunité la plus totale, elle a pu constater le risque de travailler avec un fournisseur d’accès local, contraint de couper la connexion vers les services attaqués afin de ne pas être paralysé lui-même.

Dans l’impossibilité de mettre fin aux hostilités, la société a finalement déplacé les services vers une infrastructure capable d’absorber la puissance de l’attaque. Cette stratégie s’est avérée efficace : elle constitue une parade peu coûteuse et rapide à mettre en œuvre face à ce type de menace.

Martino Dell’Ambrogio

Stéphane Adamiste

Notes :

[1] https://commedansdubeurre.ch/?story=211-cyberattaque-sur-postfinance-et-wikileaks-de-quoi-parle-t-on

[2] https://www.tdg.ch/actu/hi-tech/postfinancech-cible-hackers-pro-wikileaks-2010-12-07

[3] https://code.google.com/p/bs2grproxy/