Toutes les versions de cet article : [English] [français]

Le 31/1/2015, 00:41
DDOS sur La Quadrature du Net, analyse

Les 20 et 22 janvier dernier, le serveur de la Quadrature du Net, association de défense des libertés des citoyens sur Internet, dont je suis cofondateur et que ma société héberge gracieusement, a subi des attaques par déni de service réparties.

Voici une petite analyse de ce que nous avons pu comprendre de ces attaques ...

Introduction : le DNS

Lorsque vous allez sur un site web, par exemple http://fr.rsf.org, votre navigateur demande à un serveur DNS, service généralement fourni par votre fournisseur d’accès, où se situe ce site web sur Internet, et le serveur DNS vous donne l’adresse IP (ici 78.109.93.7) du site de RSF.

Ensuite, votre navigateur appelle cette adresse IP et lui demande la page http://fr.rsf.org. Le serveur web sachant qu’il héberge ce nom de domaine, prend la page dans son disque dur et vous la retourne.

Déroulement des attaques contre LQDN

Le 20 janvier dernier donc, nous notons en pleine journée un pic important de charge sur le serveur, nommé PI, de la Quadrature du Net. Nous nous connectons à ce serveur et constatons plusieurs phénomènes intéressants :

- De nombreuses requêtes sur le serveur DNS de la Quadrature pour d’autres domaines que ceux que nous hébergeons, ces requêtes sont donc refusées et une ligne dans le journal est inscrite pour le signaler
- De très nombreuses requêtes sur le serveur web HTTPS n’aboutissent pas, bloquant de nombreuses connexions au serveur web, saturant ce dernier.
- De très nombreuses requêtes parviennent sur le serveur web HTTP ou HTTPS sur des pages web que nous n’hébergeons pas, à savoir des domaines comme tracker.thepiratebay.org ou www.facebok.com !

Ces 3 problèmes se retrouvent dans les journaux (appelés log en anglais) du serveur, sous les lignes ci-dessous :

Exemple de requête DNS non autorisée :

Jan 20 08:03:59 pi named[28980]: client 125.76.247.217#33795: query (cache) 'graph.facebook.com/AAAA/IN' denied
Jan 20 08:09:19 pi named[28980]: client 58.215.136.127#10144: query (cache) 'cs20.wpc.edgecastcdn.net/AAAA/IN' denied

Exemple de requête web n’aboutissant pas :

117.136.8.66 - - [20/Jan/2015:09:31:29 +0100] "-" 408 - "-" "-" 0 -
121.18.112.74 - - [20/Jan/2015:09:31:29 +0100] "-" 408 - "-" "-" 0 -

Exemple de requête sur des domaines que nous n’hébergeons pas : (log access puis error)

122.69.74.16 - - [20/Jan/2015:09:32:30 +0100] "GET /announce?info_hash=&peer_id=&ip=122.69.74.16&port=11628&uploaded=703804438&downloaded=703804438&left=314346&numwant=200&key=27066&compact=1 HTTP/1.0" 404 418 "-" "Bittorrent" 0 tracker.thepiratebay.org
123.53.192.27 - - [20/Jan/2015:09:31:58 +0100] "POST /restserver.php HTTP/1.1" 404 416 "-" "-" 0 api.facebook.com

[Tue Jan 20 07:46:34 2015] [error] [client 14.125.231.76] File does not exist: /var/alternc/bureau/admin/announce
[Tue Jan 20 08:33:29 2015] [error] [client 49.72.210.45] File does not exist: /var/alternc/bureau/admin/graph.facebook.com, referer: http://quetwo.com/2011/12/01/arduinoconnector-ane/

Comment bloquer cette première attaque ?

Nous avons donc 3 motifs d’attaques susceptibles d’être bloquées.

La première, l’attaque par requêtes DNS incorrectes, n’est pas facile à bloquer, car le protocole DNS n’échange pas d’information avec l’adresse IP source de la requête. Cela signifie que n’importe quel internaute peut envoyer une requête DNS avec comme adresse IP source une autre que la sienne, la réponse (ou le refus de réponse) parviendra à quelqu’un d’autre !

Donc, si l’on bloque les IP effectuant ces demandes bizarres, on risque de bloquer n’importe qui, et d’empêcher l’accès à nos sites à des internautes légitimes...


La seconde, l’attaque par SYN flood, n’est elle pas anonyme. En effet, lorsque l’on se connecte à un serveur web, on échange et reçoit plusieurs paquets d’informations entre le serveur et le navigateur, d’une manière décrite dans le protocole TCP. Sa forme simplifiée est :

  • Navigateur envoie un paquet TCP/SYN à Serveur
  • Serveur répond avec un paquet TCP/SYN+ACK à Navigateur
  • Navigateur répond avec un paquet TCP/ACK à Serveur.
  • La discussion peut commencer, les 2 parties se sont reconnues.

Ce protocole implique donc que l’adresse IP source (le Navigateur) soit bien qui il prétend : si j’émets un paquet TCP/SYN avec une IP source qui n’est pas la mienne, le paquet TCP/SYN+ACK ne me reviendra pas (il arrivera à l’adresse IP source contrefaite) et je ne pourrai donc pas envoyer la bonne réponse TCP/ACK.

Or, dans le cas des pages non terminées (timeout), nous avions bien un échange SYN puis SYN+ACK puis ACK. L’IP source est donc bien celle qui nous attaque, on peut la bloquer.


Pour le troisième cas, c’est encore mieux, nous recevions même une requête bien formée de chaque navigateur demandant ces pages farfelues que nous n’hébergions pas, et nous passions un certain temps à lui répondre "Page non trouvée", la fameuse Erreur 404 !

Nous avons donc utilisé le système de blocage basé sur IPSET, récemment mis en place par Octopuce pour bloquer précisément ce type d’attaques, peu dangereuse pour le réseau mais fatigantes pour les serveurs web

à l’aide des 2 règles ci-dessous, nous pouvions donc bloquer les internautes malveillants :

pi# tail -F access.log|grep --line-buffered '"-" 408 -' |sed -ue 's/^\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1.\2.\3.\4/'|blacklist add
pi# tail -F error.log|grep --line-buffered "File does not exist: /var/alternc/bureau/admin/" | sed -ue 's/^.*client \([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*$/\1.\2.\3.\4/'| blacklist add

En l’espace de quelques minutes, nous avions bloqué 3000 puis jusqu’à 17400 adresses IP.

Encore quelques minutes plus tard, l’attaque était complètement bloquée, le pare-feu du serveur refusait toute tentative de connexion de ces adresses IP.

Seconde attaque, on passe au blocage élargi

Le nombre de requêtes étant retombé à presque rien, et les IP bloquées disparaissant progressivement (puisque ne tentant plus de frapper à nouveau), tout était calmé le matin suivant.

Le 22 janvier, soit 48 heures après la première attaque, même problème. Adrienne, la coordinatrice des campagnes de la Quadrature du Net, me prévient qu’elle n’arrive plus à lire son mail : elle a détecté l’attaque juste avant nos sondes de supervision !

Immédiatement, je relance les 2 requêtes de blocage automatique ci-dessus, mais rapidement, l’outil blacklist me signale qu’il n’arrive plus à ajouter des adresses IP ! Nous avons atteint plus d’1 million d’adresses bloquées, saturant les limites que nous avions posées à IPSET !

Nous avons donc sorti une artillerie plus rapide, mais aussi plus floue : au lieu de bloquer les adresses IP individuellement, on bloque des préfixes /24 (nom donné à 256 adresses IP consécutives, dont les 3 premiers nombres sont identiques)

Les règles de filtrages changent :

pi# tail -F access.log|grep --line-buffered '"-" 408 -' |sed -ue 's/^\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1.\2.\3.0\/24/'|blacklist add
pi# tail -F error.log|grep --line-buffered "File does not exist: /var/alternc/bureau/admin/" | sed -ue 's/^.*client \([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*$/\1.\2.\3.0\/24/'| blacklist add

Rapidement, on atteint les 8000 blocs de 256 adresses bloquées, et à nouveau tout se calme.

On remarquera, après l’opération (graphe capturé le dimanche qui suit) les pics dans le nombre de requêtes sur le serveur web Apache de la Quadrature : (notez que ce n’est pas notre serveur web principal, celui-ci ne sert que des sites auxiliaires et un webmail. Tau, serveur de www.laquadrature.net, n’a pas subi d’attaque)

D’où viennent ces attaques, et pourquoi ?

Étant donnée l’ampleur de cette seconde attaque (on parle de millions d’adresses IP et de quelques millions de requêtes DNS / HTTP / HTTPS incorrectes), une enquête, même rapide, s’imposait, pour mieux connaître la provenance, et peut-être trouver une raison à cette attaque, pour pouvoir mieux, ou plus rapidement, la contenir la prochaine fois.

Nous avons tout de suite vérifié le ou les pays d’origine des internautes : rapidement, le diagnostic est sans appel :

  • 7980 blocs d’IP chinois
  • 4 japonais
  • 6 de Honk Kong
  • 8 de Taiwan

L’attaque est donc quasi exclusivement chinoise...

De l’Internet chinois et du fonctionnement de sa censure

Depuis, et avec l’aide de Stéphane Bortzmeyer résumant ici les événements, on a mieux compris ce qu’il se passe :

  • la Chine censure l’Internet chinois, c’est bien connu
  • pour cela, elle détourne, (entre autres) les requêtes DNS dans son réseau (et aussi pour de petits bouts de l’Internet japonais, coréen ou taïwannais qui passent par elle)
  • lorsqu’elle répond à une requête vers un site censuré, elle répond "n’importe quelle IP incorrecte"

on pensait depuis longtemps que ces IP incorrectes étaient choisies au hasard, mais rien ne le prouve.

Par contre, depuis peu, on voit fleurir des gros pics de requêtes à destinations de sites censurés en Chine sur des IPs comme celle de la Quadrature du Net, mais cela arrive à d’autres : http://furbo.org/2015/01/22/fear-china/

Moralité, on a donc vu arriver sur le serveur de la Quadrature du Net des requêtes issues de la censure chinoise !

On sent donc passer le vent d’un boulet façon attaque par rebond du grand pare-feu chinois anti liberté d’expression et d’information...

Conséquences politiques

Volontaire ou non, ce comportement technique peut être dû à plusieurs scénarios :

  • le système de censure chinois a choisi de répondre aux requêtes DNS sur des sites censurés avec des IPs moins nombreuses qu’avant (donc concentrant le traffic vers ces IPs ?)
  • un des administrateurs systèmes du great firewall of China arrondit ses fins de mois en vendant des DDOS, des attaques, au plus offrant (en bitcoin ? ;) ) et se sert du système de censure chinois pour ce faire
  • la Chine a choisi une liste de cibles et renvoi le trafic censuré de ses citoyens vers ces cibles, ajoutant l’utile (la censure) à l’agréable (la chute de ses opposants à l’étranger)... la Quadrature, en tant qu’association de défense des libertés à l’ère numérique, semble une cible toute trouvée parmi d’autres bien entendu.
  • rien de tout cela, et c’est juste pas de bol

Par contre, cette attaque montre une chose claire sur le fonctionnement de l’Internet d’aujourd’hui : un gros (ici un très gros, la Chine) peut sans problème faire tomber un petit ou un tout petit, en saturant son réseau, ses serveurs, ses infrastructures, de requêtes ou de débit farfelus.

Internet devient difficile à tenir quand on n’est pas Orange, Cloudflare ou Google ... et que l’on héberge des contenus qui déplaisent.

Que peut-on faire contre cela ? Généraliser l’analyse anti-ddos en cœur de réseau comme le font les Illiad, Ovh & co, avec du matériel Arbor ou équivalent ? Triste car nécessite de l’écoute en profondeur des paquets, et peut porter atteinte à la neutralité du réseau... Par ailleurs, les DDOS nécessitent de très gros tuyaux capables de filtrer un tel trafic, et donc de gros moyens.

L’Internet est-il en train de condamner les petits acteurs ?

... à réfléchir.