Attaque SYN flood (syn flood attack) : variantes et mesures de protection

En tant qu’attaque par déni de service (DoS), le SYN flood vise à empêcher l’utilisation légitime d’un système en ligne. Le concept d’une attaque DoS revient à peu de chose près à envoyer massivement des courriers à une administration sans but véritable. En faisant déborder les boîtes aux lettres, les courriers légitimes ne parviennent plus à l’administration ou ne peuvent plus être traités. L’attaquant a atteint son objectif : le fonctionnement normal est interrompu.

Le SYN flood est une attaque DoS. L’attaquant envoie un flot de paquets de données malveillants au système cible. Le but est de saturer la cible et ainsi d’empêcher l’utilisation légitime.

À l’instar du ping of death, le SYN flood est une attaque de protocole. Ces attaques visent à exploiter un point faible dans la communication réseau afin de faire plier le système cible. Le SYN flood fonctionne ainsi différemment des attaques volumétriques que sont le ping flood, l’UDP flood et le HTTP flood. Dans ces dernières, le hacker s’efforce de chasser la cible du réseau à l’aide d’une bande passante aussi importante que possible.

Également connu sous le nom d’« attaque semi-ouverte », le SYN flood est une cyberattaque dirigée contre la connexion réseau. Le hacker utilise le handshaking en trois temps du Transmission Control Protocol (TCP) de façon abusive. Au lieu de gérer une connexion entre un client et un serveur de la façon prévue, de nombreuses connexions semi-ouvertes sont créées sur le serveur. Ce processus lie des ressources au serveur qui ne sont alors plus disponibles pour l’utilisation véritable.

Regardons comment fonctionne l’établissement d’une connexion TCP normale et en quoi ce fonctionnement est perturbé pendant les attaques SYN flood.

Avec l’Internet Protocol (Ip), le Transmission Control Protocol (TCP) est l’un des piliers d’Internet. Comme le protocole TCP est un protocole orienté connexion, le client et le serveur doivent tout d’abord établir une connexion avant de pouvoir échanger des données ensemble. C’est ici qu’intervient le handshaking en trois temps :

1. Le client envoie un paquet SYN (« synchronize ») au serveur. – « Bonjour, je souhaiterais établir une connexion avec vous. »
2. Le serveur répond avec un paquet SYN/ACK (ACK = « acknowledge ») et crée dans le backlog SYN une structure de données appelée « Transmission Control Block » (TCB) pour la connexion. – « D’accord, aucun souci. Dans ce cas, utilise les paramètres de connexion suivants. »
3. Le client répond au paquet SYN/ACK avec un paquet ACK ce qui met fin au handshaking. La connexion est alors disponible et les données peuvent être envoyées dans les deux sens. Du côté du serveur, le Transmission Control Block est supprimé du backlog SYN. – « Super, merci. On peut échanger des données à présent ! »

Ce processus se déroule en arrière-plan à chaque fois que vous vous connectez à un serveur pour visiter un site Internet ou consulter vos e-mails.

Pour déclencher un SYN flood, le hacker utilise un logiciel spécial. On peut par exemple citer l’outil apprécié hping utilisé pour le test de pénétration. Cet outil permet de simuler une bande passante d’attaques de réseau. Pour des raisons de sécurité, nous présentons uniquement un modèle approximatif du code hping pour un SYN flood avec l’adresse IP usurpée :

Les options de cette commande sont intéressantes :

• L’option « --syn » demande à l’outil d’utiliser le TCP comme protocole et d’envoyer des paquets SYN.
• L’option « --flood » est tout particulièrement importante ici. Selon la documentation de la commande hping, celle-ci fait en sorte que des paquets soient envoyés aussi rapidement que possible.
• L’option « --rand-source » permet au hacker de falsifier son adresse IP. Une adresse IP aléatoire est renseignée à la place de la véritable adresse de l’expéditeur.

Il existe plusieurs variantes pour effectuer une attaque SYN flood. Le point commun de toutes ces variantes est que le hacker cherche à maintenir le serveur occupé le plus longtemps possible. Pour ce faire, le hacker doit veiller à ce que les paquets SYN/ACK envoyés par le serveur ne reçoivent pas de réponse. Si la machine du hacker répond avec un paquet ACK, l’entrée correspondante sur le serveur est supprimée du backlog SYN.

Si le hacker usurpe une adresse IP, les paquets SYN/ACK du serveur sont transmis à des tiers. Or, si une machine reçoit un paquet SYN/ACK d’un serveur sans que celui-ci ait envoyé un paquet SYN au préalable, la machine envoie un paquet RST (RST = « reset ») et met un terme à la connexion. Un hacker expérimenté voudra également empêcher cela pour garder semi-ouvertes un nombre de connexions aussi grand que possible sur le serveur.

Dans le cas d’une attaque directe, le hacker lance les attaques SYN flood sous sa propre adresse IP. Pour veiller à ce que les paquets SYN/ACK entrants soient rejetés, le hacker configure le pare-feu de sa machine de façon adéquate. Une autre approche consiste à limiter le trafic réseau aux paquets SYN sortants.

Dans le cas d’une attaque directe, le hacker agit sous sa propre adresse IP et peut être détecté relativement facilement. C’est pourquoi cette variante d’attaque est rarement utilisée.

L’attaque avec une adresse IP usurpée est plus répandue. Dans ce cadre, le hacker renseigne une adresse IP falsifiée dans le champ de l’expéditeur des paquets SYN et dissimule ainsi sa véritable origine. Les hackers préfèrent les adresses IP qui ne sont pas occupées au moment de l’attaque. De cette façon, ils s’assurent que les systèmes concernés, qui sont choisis au hasard, ne réagissent pas en envoyant un paquet RST pour faire suite aux réponses SYN/ACK du serveur à l’origine de l’attaque ce qui mettrait un terme à la connexion.

Dans cette variante d’attaque SYN flood « distribuée », l’attaque est réalisée par de nombreux ordinateurs en même temps. Habituellement, il s’agit d’un réseau de machines détournées qu’on appelle botnet. Les ordinateurs zombies du botnet sont sous le contrôle du hacker et envoient des paquets SYN à la cible à la demande du hacker.

Habituellement, un serveur répond à un paquet SYN individuel avec plusieurs paquets SYN/ACK. Un hacker peut exploiter ce processus pour déclencher une attaque SYN flood par réflexion. Pour ce faire, le hacker usurpe l’adresse IP de la victime et lance un SYN Flood DDoS contre un ou plusieurs serveurs tiers. Chacun des serveurs répond à chaque paquet SYN entrant avec plusieurs paquets SYN/ACK envoyés à la victime. Le trafic réseau est ainsi décuplé. La machine de la victime est bombardée par un flot de paquets SYN/ACK et s’écroule sous la charge.

Le principe général du SYN flood est connu depuis env. 1994. Par conséquent, il existe aujourd’hui toute une série de mesures de protection efficaces. Certaines d’entre elles ont toutefois des effets secondaires négatifs ou fonctionnent uniquement dans certaines conditions. De manière générale, distinguer les paquets SYN malveillants des paquets légitimes n’est pas évident. La plupart des mesures de protection connues sont utilisées sur le serveur, mais il existe également des solutions basées sur le cloud.

Le backlog SYN déjà évoqué fait partie du système d’exploitation. D’un point de vue conceptuel, vous pouvez vous représenter le backlog SYN comme un tableau. Chaque ligne contient les informations concernant l’établissement d’une connexion TCP individuelle. Le système d’exploitation gère les connexions dans un premier temps. Lorsqu’une connexion est établie après avoir passé le handshaking en trois temps, elle est alors transmise à l’application écoutant sur le port et retirée du backlog SYN.

L’une des méthodes les plus simples pour protéger un système contre les attaques SYN flood consiste à étendre le backlog SYN. Chaque entrée du backlog SYN nécessite une certaine quantité de mémoire vive ce qui limite le nombre d’entrées. Par défaut, cette limite est de quelques centaines d’entrées sous Linux mais cette valeur peut facilement être augmentée. En principe, le backlog SYN peut contenir des milliers d’entrées permettant ainsi d’absorber les attaques SYN flood les plus petites.

Une approche similaire consiste à supprimer la connexion semi-ouverte la plus ancienne dans le backlog SYN lorsque celui-ci est plein. Cette suppression laissera de la place pour une nouvelle connexion semi-ouverte. Associée avec un backlog SYN suffisamment étendu, cette approche peut permettre de maintenir un système accessible pendant une attaque SYN flood. Cette méthode se révèle toutefois inefficace dans le cas d’un volume d’attaque élevé.

L’idée du cache SYN est simple : au lieu d’enregistrer un Transmission Control Block (TCB) complet dans le backlog SYN pour chaque connexion semi-ouverte, seul un TCB minimal est conservé. Cette technologie utilise un hachage cryptographique pour empêcher que le hacker puisse deviner des informations critiques de la connexion. Le cache SYN s’est révélé une technologie efficace. Les données de connexion peuvent uniquement être perdues dans de rares cas particuliers.

Le concept du cache SYN a été étendu en 1996 avec l’invention des cookies SYN. Ces cookies renoncent entièrement à l’utilisation du Transmission Control Block comme structure de données. À la place, les paramètres de connexion correspondants sont codés dans le numéro de séquence du paquet SYN/ACK. Le hachage cryptographique fait en sorte que le hacker ne puisse pas déchiffrer facilement le numéro de séquence.

Un client légitime répond au paquet SYN/ACK avec un paquet ACK en utilisant le numéro de séquence préparé spécialement à cet effet. Le serveur utilise le numéro de séquence du paquet ACK pour vérifier cryptographiquement l’établissement de la connexion et l’établir. L’utilisation des cookies SYN offre une protection efficace contre les attaques SYN flood mais elle peut réduire la performance dans certains cas.

Les deux technologies peuvent également être associées. Dans un fonctionnement normal, le cache SYN est utilisé. Lorsque ce dernier est plein, on utilise alors des cookies SYN. Ceci permet de combiner les points positifs des deux méthodes.

La lutte contre les attaques DoS est aussi ancienne qu’Internet. Toutefois, les hackers modernes disposent d’une puissance de feu nettement plus grande grâce aux botnets. Avec leur énorme flot de données, les attaques DDoS déclenchées avec des botnets font plier les systèmes les plus solides. C’est la raison pour laquelle on utilise de plus en plus aujourd’hui les services de grands fournisseurs de cloud distribué dans le monde entier.

L’idée est de répartir le flux de données DDoS entrant entre de nombreux systèmes individuels. Ceci permet de disséminer la charge totale de l’attaque et d’atténuer le pic sur chaque système. De cette façon, le réseau peut résister aux attaques les plus lourdes.

Outre les technologies de filtrage, la technologie Anycast s’est établie au niveau du réseau. Les requêtes adressées à des systèmes reliés via Anycast sont automatiquement redirigées vers un serveur situé à proximité géographique. Il est ainsi possible de tuer dans l’œuf à un niveau local une attaque DDoS se déroulant à l’échelle mondiale. Les réseaux Anycast tels que celui de Cloudflare séduisent par leur élégance et leur résistance.

Le blog de Cloudflare offre un aperçu captivant des évolutions constantes en matière de lutte contre les attaques SYN flood. Outre la stratégie d’atténuation basée sur un bot, les signatures de paquet SYN semblent également très prometteuses. Cette méthode implique la génération d’empreintes digitales lisibles par l’homme pour les paquets SYN entrants. Ces empreintes digitales permettent de déduire des informations sur le système d’exploitation de la machine ayant envoyé le paquet SYN initial. Dans le cadre de l’analyse des empreintes digitales, les paquets envoyés pendant une attaque SYN flood ne correspondent pas au modèle et sont donc filtrés.