Syn flood

Vous aimez que l'on vous parle ? Vos serveurs aussi. Mais trop de conversations simultanées fait mal à la tête, surtout quand personne ne finit ses phrases ; et il en est de même avec vos serveurs.

Présentation

Le syn flood est une attaque réseau faisant partie de la classe des DDoS (Distributed Denial of Service), qui elle-même fait partie de la classe des DoS (Denial of Service).

Comme tout DoS, l'attaque vise à saturer la machine (ou le réseau) attaqué afin qu'elle/il ne puisse plus rendre le service pour lequel elle/il est conçu-e.

Elle utilise la pile TCP, et elle consiste à ouvrir des connexions sans jamais les fermer.

Pour rappel: une ouverture de connexion TCP (TCP, hein, pas UDP) consiste en un three way handshake (poignée de main en trois étapes), dont voici le détail avec pour l'exemple les serveurs de nos stars mondiales, Alice et Bob.

ServeurAlice, poliment : Salut, ServeurBob, je peux te parler?

ServeurBob, s'il est disponible, et tout aussi poliment: Salut, ServeurAlice, oui bien sûr!

ServeurAlice heureux: chouette!

Et le serveur d'Alice dit ce qu'il a à dire.

Dans le texte, et sans le sous-titrage, ça donne:

A->B: paquet TCP avec flag SYN levé, à destination d'un port supposé ouvert, disons 80

B->A: paquet TCP avec flags SYN et ACK levés

A->B: paquet TCP avec flag ACK levé.

Quand le serveur de Bob reçoit le premier TCP SYN, il note dans un coin de sa têt ... mémoire que c'est le serveur d'Alice (avec tel port source) qui lui parle, lui envoie un SYN ACK (là, la connexion est dans l'état half-open, semi-ouvert) et ... attend la suite.

Suite, normalement, qui est soit un ACK signifiant que le serveur d'Alice désire réellement établir la connexion, soit un RST (reset, mettant fin à la connexion) signifiant que le serveur d'Alice, en fait, boude et ne veut pas/plus parler au serveur de Bob (et dans ce cas, le serveur de Bob libère la mémoire)

Le problème, c'est que bien souvent le nombre de connexions half-open est limité par le noyau de l'OS. Ça s'appelle la queue de backlog (à ne pas confondre avec le backlog que l'on utilse dans les méthodes agiles), et sur mon Linux (2.6.30) c'est le paramètre /proc/sys/net/ipv4/tcp_max_syn_backlog, et il est mis à 1024 (hé oui, mon Linux est une fille : il peut tenir 1024 conversations simultanées). Sur les Windows, il n'y a pas réellement de valeur par défaut mais il existe un mécanisme de backlog dynamique.

Supposons que le serveur d'Alice soit possédé par une malotrue jalouse, Eve, et envoie plein de paquets SYN au serveur de Bob, et ignore les réponses de Bob (ne renvoie pas le ACK correspondant). Dans ce cas, le serveur de Bob va allouer de la mémoire à ces connections half-open, envoyer les paquets SYN ACK adéquats, et attendre (que le caramel ... )

Que se passe-t-il lorsque la taille de la queue du backlog est atteinte ? Si le serveur de Bob ne plante pas, il est en déni de service : il ne peut plus honorer les tentatives de connexion légitimes (d'Alice ou de ses autres ami-e-s)

Une attaque syn flood consiste à saturer le serveur de demandes de connexions pour justement provoquer ce déni de service.

Protection

Comme tout DoS, se protéger d'un syn flood n'est pas chose aisée, surtout quand l'attaque est en cours.

Mais cette technique étant relativement ancienne (mi 90) des mécanismes de prévention existent. Je vais décrire ici seulement les mécanismes que vous pouvez mettre en œuvre (il en existe que seul votre ISP peut implémenter).

Quand vous êtes sous le feu de l'attaque

Les écrans de monitoring de votre réseau vous indiquent que l'occupation mémoire de vos serveurs a grimpé en flèche, que le nombre de connexions simultanées est atteint, que le taux d'occupation de vos tuyaux crève le plafond, et votre pare-feu vous alerte qu'il y a bien trop de tentatives de connections ?

Si vous êtes chez vous, la led de votre box clignote comme une dingue et votre surf est lent (et accessoirement un tcpdump est bien trop bavard à votre goût) ?

Bravo, vous êtes en train de vous faire noyer.

Que faire ?

En tant qu'entreprise, les attaques syn flood sont monnaie courante. Et ce d'autant plus que vous êtes connu. La cause peut aller d'un piratin du dimanche qui s'ennuie chez lui parce qu'il pleut (dans ce cas le flood ne dure pas bien longtemps et n'est pas bien méchant, peut-être même que vous ne l'avez pas remarqué) à un réseau de pirates qui veulent vous faire chanter, et dans ce cas le flood peut durer plusieurs jours avec les conséquences que je vous laisse imaginer sur votre chiffre d'affaire et votre image.

Si les connexions arrivent d'un lot identifié d'adresses IP, il suffit de recenser ces adresses et de les bloquer pendant un certain temps : hé oui, ces IP peuvent être les machines de vos clients, entreprises ou particuliers, et leur interdire l'accès ad vitam aeternam n'est pas une bonne idée.

Si ce nombre d'adresses IP est conséquent, ce qui arrive le plus souvent, il ne vous reste plus beaucoup de choix:

• Faire le gros dos et attendre que l'orage passe. Ce n'est clairement pas la meilleure solution mais c'est parfois la seule ...
• Vous pouvez essayer de trouver une sorte de logique dans les adresses qui vous attaquent. En effet il se peut que vous soyez attaqué par un botnet. Celui-ci étant composé d'ordinateurs répartis dans le monde, vous pouvez essayer de vous couper de la partie du monde d'où proviennent les paquets : n'autorisez que les adresses dont le plan d'adressage est dans la partie du monde qui vous intéresse. Chaque pays ayant plus ou moins ses propres plages d'adresses (cf par ici). Néanmoins cette attaque est inefficace si les malotrus sont rusés au point d'usurper les adresses et les mettre dans le plan d'adressage qui vous intéresse.

Avant d'être sous le feu de l'attaque

Le mieux est encore de mettre en place les mécanismes de protection avant de subir l'attaque.

Au niveau infrastructure :

• Il faut dimensionner votre infrastructure pour supporter ce genre d'attaque. Si vous pensez que votre brin d'entrée est suffisamment dimensionné pour supporter le trafic "régulier", pas beaucoup plus, il y a de forte chances que vous soyez sensible à ces attaques.
• De même si vos serveurs sont un peu justes en mémoire et cpu, et si vous n'avez aucun moyen de superviser ce qu'il s'y passe.
• Avez-vous pensé aux processus à mettre en œuvre si cette attaque vous tombe dessus ?

Plus bas niveau, et plus immédiatement actionnable, au niveau matériel :

• Le plus répandu, et le plus efficace, est de limiter le nombre de sessions half-open simultanées. Tous les systèmes d'exploitations ont cette possibilité. Mais surtout votre pare-feu cette capacité, sous un nom ou un autre, avec plus ou moins de raffinement dans le paramétrage. Vos routeurs ont sans doute aussi ces options.
• Dans la même idée, vous pouvez jouer avec les paramètres de la pile IP de votre système d'exploitation, ou ce que propose votre pare-feu : durée de vie d'une session half-open, d'une session tcp, ... Sous Linux, visitez du côté de chez Swa... du côté de /proc/sys/net/ipv4/. La documentation se trouve dans les sources du noyau (Documentation/networking/ip-sysctl.txt) ou du coup sur le net. Sur les BSD c'est dans les paramètres du pare-feu (pf.conf). Sur Windows, il faut visiter la base de registre.
• Utiliser les cookies syn (non, ne téléphonez pas à votre (grand-)mère pour lui demander la recette ... ) : l'idée est de ne pas allouer la mémoire nécessaire à la connexion dès le premier paquet SYN reçu, mais à la place renvoyer au client, dans le paquet SYN ACK, un numéro de séquence spécial (chiffrement des ports sources et destination, adresses IP sources et destination, et timestamp). Le serveur alloue la mémoire une fois la réponse ACK reçue, réponse qui doit contenir le bon numéro de séquence, bien sûr.

Conclusion

J'espère que cet article vous a instruit sur ce type d'attaque et vous a fait prendre conscience de la menace.

Les moyens de s'en protéger sont multiples (et variés) et vont du tuning de système d'exploitation à l'adaptation de votre infrastructure.