Attaque SYN flood (syn flood attack) : variantes et mesures de pro­tec­tion

En tant qu’attaque par déni de service (DoS), le SYN flood vise à empêcher l’uti­li­sa­tion légitime d’un système en ligne. Le concept d’une attaque DoS revient à peu de chose près à envoyer mas­si­ve­ment des courriers à une ad­mi­nis­tra­tion sans but véritable. En faisant déborder les boîtes aux lettres, les courriers légitimes ne par­vien­nent plus à l’ad­mi­nis­tra­tion ou ne peuvent plus être traités. L’attaquant a atteint son objectif : le fonc­tion­ne­ment normal est in­ter­rompu.

Le SYN flood est une attaque DoS. L’attaquant envoie un flot de paquets de données mal­veil­lants au système cible. Le but est de saturer la cible et ainsi d’empêcher l’uti­li­sa­tion 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 com­mu­ni­ca­tion réseau afin de faire plier le système cible. Le SYN flood fonc­tionne ainsi dif­fé­rem­ment des attaques vo­lu­mé­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 im­por­tante que possible.

Également connu sous le nom d’« attaque semi-ouverte », le SYN flood est une cy­be­rat­taque dirigée contre la connexion réseau. Le hacker utilise le hand­sha­king en trois temps du Trans­mis­sion 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 nom­breuses con­nexions semi-ouvertes sont créées sur le serveur. Ce processus lie des res­sources au serveur qui ne sont alors plus dis­po­nibles pour l’uti­li­sa­tion véritable.

Regardons comment fonc­tionne l’éta­blis­se­ment d’une connexion TCP normale et en quoi ce fonc­tion­ne­ment est perturbé pendant les attaques SYN flood.

Avec l’Internet Protocol (Ip), le Trans­mis­sion 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’in­ter­vient le hand­sha­king en trois temps :

1. Le client envoie un paquet SYN (« syn­chro­nize ») au serveur. – « Bonjour, je sou­hai­te­rais établir une connexion avec vous. »
2. Le serveur répond avec un paquet SYN/ACK (ACK = « ack­now­ledge ») et crée dans le backlog SYN une structure de données appelée « Trans­mis­sion Control Block » (TCB) pour la connexion. – « D’accord, aucun souci. Dans ce cas, utilise les pa­ra­mètres de connexion suivants. »
3. Le client répond au paquet SYN/ACK avec un paquet ACK ce qui met fin au hand­sha­king. La connexion est alors dis­po­nible et les données peuvent être envoyées dans les deux sens. Du côté du serveur, le Trans­mis­sion 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é­clen­cher 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é­tra­tion. Cet outil permet de simuler une bande passante d’attaques de réseau. Pour des raisons de sécurité, nous pré­sen­tons uni­que­ment un modèle ap­proxi­ma­tif du code hping pour un SYN flood avec l’adresse IP usurpée :

Les options de cette commande sont in­té­res­santes :

• L’option « --syn » demande à l’outil d’utiliser le TCP comme protocole et d’envoyer des paquets SYN.
• L’option « --flood » est tout par­ti­cu­liè­re­ment im­por­tante ici. Selon la do­cu­men­ta­tion de la commande hping, celle-ci fait en sorte que des paquets soient envoyés aussi ra­pi­de­ment que possible.
• L’option « --rand-source » permet au hacker de falsifier son adresse IP. Une adresse IP aléatoire est ren­seig­née à la place de la véritable adresse de l’ex­pé­di­teur.

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 cor­res­pon­dante 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 ex­pé­ri­menté voudra également empêcher cela pour garder semi-ouvertes un nombre de con­nexions 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é re­la­ti­ve­ment fa­ci­le­ment. 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’ex­pé­di­teur 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éa­gis­sent 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 « dis­tri­buée », l’attaque est réalisée par de nombreux or­di­na­teurs en même temps. Ha­bi­tuel­le­ment, il s’agit d’un réseau de machines dé­tour­nées qu’on appelle botnet. Les or­di­na­teurs zombies du botnet sont sous le contrôle du hacker et envoient des paquets SYN à la cible à la demande du hacker.

Ha­bi­tuel­le­ment, un serveur répond à un paquet SYN in­di­vi­duel avec plusieurs paquets SYN/ACK. Un hacker peut exploiter ce processus pour dé­clen­cher 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 con­sé­quent, il existe aujourd’hui toute une série de mesures de pro­tec­tion efficaces. Certaines d’entre elles ont toutefois des effets se­con­daires négatifs ou fonc­tion­nent uni­que­ment dans certaines con­di­tions. De manière générale, dis­tin­guer les paquets SYN mal­veil­lants des paquets légitimes n’est pas évident. La plupart des mesures de pro­tec­tion 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’ex­ploi­ta­tion. D’un point de vue con­cep­tuel, vous pouvez vous re­pré­sen­ter le backlog SYN comme un tableau. Chaque ligne contient les in­for­ma­tions con­cer­nant l’éta­blis­se­ment d’une connexion TCP in­di­vi­duelle. Le système d’ex­ploi­ta­tion gère les con­nexions dans un premier temps. Lorsqu’une connexion est établie après avoir passé le hand­sha­king en trois temps, elle est alors transmise à l’ap­pli­ca­tion é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 fa­ci­le­ment être augmentée. En principe, le backlog SYN peut contenir des milliers d’entrées per­met­tant 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 sup­pres­sion laissera de la place pour une nouvelle connexion semi-ouverte. Associée avec un backlog SYN suf­fi­sam­ment étendu, cette approche peut permettre de maintenir un système ac­ces­sible pendant une attaque SYN flood. Cette méthode se révèle toutefois inef­fi­cace dans le cas d’un volume d’attaque élevé.

L’idée du cache SYN est simple : au lieu d’en­re­gis­trer un Trans­mis­sion Control Block (TCB) complet dans le backlog SYN pour chaque connexion semi-ouverte, seul un TCB minimal est conservé. Cette tech­no­lo­gie utilise un hachage cryp­to­gra­phique pour empêcher que le hacker puisse deviner des in­for­ma­tions critiques de la connexion. Le cache SYN s’est révélé une tech­no­lo­gie efficace. Les données de connexion peuvent uni­que­ment être perdues dans de rares cas par­ti­cu­liers.

Le concept du cache SYN a été étendu en 1996 avec l’invention des cookies SYN. Ces cookies renoncent en­tiè­re­ment à l’uti­li­sa­tion du Trans­mis­sion Control Block comme structure de données. À la place, les pa­ra­mètres de connexion cor­res­pon­dants sont codés dans le numéro de séquence du paquet SYN/ACK. Le hachage cryp­to­gra­phique fait en sorte que le hacker ne puisse pas dé­chif­frer fa­ci­le­ment 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é­cia­le­ment à cet effet. Le serveur utilise le numéro de séquence du paquet ACK pour vérifier cryp­to­gra­phi­que­ment l’éta­blis­se­ment de la connexion et l’établir. L’uti­li­sa­tion des cookies SYN offre une pro­tec­tion efficace contre les attaques SYN flood mais elle peut réduire la per­for­mance dans certains cas.

Les deux tech­no­lo­gies peuvent également être associées. Dans un fonc­tion­ne­ment 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é­clen­ché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 four­nis­seurs 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 in­di­vi­duels. Ceci permet de dis­sé­mi­ner 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 tech­no­lo­gies de filtrage, la tech­no­lo­gie Anycast s’est établie au niveau du réseau. Les requêtes adressées à des systèmes reliés via Anycast sont au­to­ma­ti­que­ment re­di­ri­gées vers un serveur situé à proximité géo­gra­phique. 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 Cloud­flare séduisent par leur élégance et leur ré­sis­tance.

Le blog de Cloud­flare offre un aperçu captivant des évo­lu­tions cons­tantes en matière de lutte contre les attaques SYN flood. Outre la stratégie d’at­té­nua­tion basée sur un bot, les sig­na­tures de paquet SYN semblent également très pro­met­teuses. Cette méthode implique la gé­né­ra­tion d’em­preintes digitales lisibles par l’homme pour les paquets SYN entrants. Ces em­preintes digitales per­met­tent de déduire des in­for­ma­tions sur le système d’ex­ploi­ta­tion de la machine ayant envoyé le paquet SYN initial. Dans le cadre de l’analyse des em­preintes digitales, les paquets envoyés pendant une attaque SYN flood ne cor­res­pon­dent pas au modèle et sont donc filtrés.