SYN cookie

Un SYN Cookie est un choix particulier de numéro de séquence Initial (ISN) effectué par un serveur lors d'une demande de connexion TCP[1]^,[2]. Il permet au serveur de sauvegarder l'état des connexions semi-ouvertes dans le numéro de séquence initial renvoyé au client lors de l'initialisation de la connexion [3]^,[4]^,[5]^,[6]^,[7]. Ce mécanisme permet de se prémunir d'attaque par inondation de requêtes SYN[2] qui cherche, à partir de paquet SYN falsifié avec des adresses sources aléatoires, à allouer la totalité de la mémoire du serveur afin qu'il se trouve dans l'incapacité de pouvoir répondre aux clients légitimes [8]. Cette protection devient active uniquement lorsqu'il y a trop de connexions semi-ouvertes [2]. Néanmoins, la génération et la vérification du SYN cookie consomment beaucoup de ressources CPU, ce qui rend cette méthode efficace uniquement en cas d'attaque par inondation de requêtes SYN de faible envergure[5].

Un SYN cookie est structuré de la manière suivante :

Valeur d'un SYN Cookie.

• les 5 premiers bits sont égaux à ${\displaystyle T{\bmod {3}}2}$, où ${\displaystyle T}$ est un compteur de temps de 5 bits qui augmente toutes les 64 secondes ;
• les 3 bits suivants représentent le Maximum Segment Size (MSS) que le serveur a choisi en réponse au MSS spécifié par le client ;
• les 24 derniers bits sont obtenus à l'aide d'une fonction de hachage cryptographique[1].

Ce choix de numéro de séquence a été motivé par le fait que le protocole TCP exige que les numéros de séquence augmentent lentement[1]. Dans le cas présent, le numéro de séquence initial du serveur augmente légèrement plus rapidement que le numéro de séquence initial du client[1].

Le mécanisme exact d'encodage de l'état dans le numéro de séquence SYN+ACK peut dépendre de l'implémentation [9]. Sur Linux, les SYN cookies sont encodés de la manière suivante [10]:

${\displaystyle syncookie=H(s_{1},sa,sp,da,dp)+ISN_{c}+(t\times 2^{24})+(H(s_{2},sa,sp,da,dp,t){\bmod {2}}^{24})+MSS_{i}}$[11]

où ${\displaystyle ISN_{c}}$ représente le numéro de séquence initial du paquet SYN choisi par le client, ${\displaystyle t}$ représente le compteur de temps de 5 bits augmentant toutes les 64 secondes, ${\displaystyle MSS_{i}}$ représente une valeur codée du MSS comprise entre 0 et 7, ${\displaystyle s_{1}}$ et ${\displaystyle s_{2}}$ représentent des clefs secrètes que seul le serveur connaît, ${\displaystyle H}$ représente une fonction de hachage cryptographique telle que MD5 ou SHA-1, ${\displaystyle sa}$, ${\displaystyle sp}$, ${\displaystyle da}$ et ${\displaystyle dp}$ représentent respectivement l'adresse source, le port source, l'adresse de destination et le port de destination du paquet SYN[11].

Négociation TCP en 3 phases utilisant SYN Cookie

Le déroulement d'une connexion TCP utilisant SYN Cookie est similaire au déroulement d'une connexion TCP classique[12]. Elle s'effectue à l'aide d'une négociation en 3 phases :

1. SYN : le client désire se connecter au serveur TCP. Pour ce faire, il envoie un paquet SYN contenant un numéro de séquence initial, noté ${\displaystyle ISN_{c}}$, en tant que numéro de séquence[11] ;
2. SYN+ACK : le serveur, lorsqu'il reçoit le paquet SYN du client, calcule un SYN Cookie noté ${\displaystyle ISN_{s}}$, incrémente ${\displaystyle ISN_{c}}$ et envoie un paquet SYN+ACK contenant ${\displaystyle ISN_{s}}$ en tant que numéro de séquence et ${\displaystyle ISN_{c}}$ en tant que numéro d'accusé de réception[5] ;
3. ACK : à la réception du paquet SYN+ACK du serveur, le client incrémente ${\displaystyle ISN_{s}}$ et envoie au serveur un paquet ACK contenant ${\displaystyle ISN_{s}}$ en tant que numéro d'accusé de réception[4].

Le serveur vérifie alors la validité du numéro d'accusé de réception du paquet ACK[11]. S'il est valide, le serveur alloue de la mémoire pour la connexion et passe son état en mode ESTABLISHED[5]. Dans le cas contraire, le paquet ACK est rejeté[13].

Le mécanisme de vérification du numéro de séquence SYN+ACK dépend de l'encodage de celui-ci [9]. Sur Linux, les SYN cookies sont vérifiés de la manière suivante [10] :

${\displaystyle MSS_{i_{2}}=acknum-seqnum-t\times 2^{24}-H(s_{1},sa,sp,da,dp)-(H(s_{2},sa,sp,da,dp,t){\bmod {2}}^{24})}$[11]

où ${\displaystyle acknum}$ et ${\displaystyle seqnum}$ représentent respectivement le numéro d'accusé de réception et le numéro de séquence du paquet ACK, ${\displaystyle t}$ représente le compteur de temps de 5 bits augmentant toutes les 64 secondes, ${\displaystyle s_{1}}$ et ${\displaystyle s_{2}}$ représentent des clefs secrètes que seul le serveur connaît, ${\displaystyle H}$ représente une fonction de hachage cryptographique telle que MD5 ou SHA-1, ${\displaystyle sa}$, ${\displaystyle sp}$, ${\displaystyle da}$ et ${\displaystyle dp}$ représentent respectivement l'adresse source, le port source, l'adresse de destination et le port de destination du paquet ACK[11].

Si ${\displaystyle MSS_{i_{2}}}$ est compris entre 0 et 7, le paquet ACK est considéré comme légitime. Le serveur crée alors une connexion avec le MSS correspondant à ${\displaystyle MSS_{i_{2}}}$. Dans le cas où un paquet est falsifié, ${\displaystyle MSS_{i_{2}}}$ tend à être très différent d'une valeur comprise entre 0 et 7[11].

Il a été montré que les SYN Cookies dépendent uniquement du paquet ACK final. En effet, comme le serveur ne sauvegarde pas l'état de la connexion[3]^,[4]^,[5]^,[6]^,[7], il ne peut savoir si le paquet SYN+ACK a été perdu et ne peut donc pas le retransmettre[14]. Cela constitue une faille de sécurité[7] : un attaquant peut essayer d'inonder le serveur de paquet SYN afin qu'il se décide d'utiliser SYN Cookie[4]^,[15]. Il peut ensuite inonder le serveur de paquet ACK falsifié, c'est-à-dire de paquet ACK contenant des numéros de séquence aléatoires, en espérant que l'un d'entre-eux soit un SYN Cookie considéré par le serveur comme étant valide[4]^,[14].

Il a également été montré qu'il n'est pas nécessaire de deviner les 32 bits du numéro de séquence initial et que deviner les 24 derniers bits est suffisant [14]. Un attaquant peut donc espérer deviner une valeur correct de SYN Cookie avec une probabilité de ${\displaystyle 1/2^{24}}$ [16]. En effet, puisque ses paquets sont falsifiés avec des adresses IP aléatoires[4], il ne peut pas savoir si une tentative de connexion a réussi[16]. Si l'attaquant désire falsifier une connexion par minute, il doit envoyer en moyenne ${\displaystyle 2^{24}}$ paquets ACK, ce qui correspond à un débit de 85 Mb/s [16]. Ce type d'attaque, à la différence d'une attaque par inondation de requêtes SYN, n'a pas pour objectif de consommer la mémoire du serveur[16]. Elle cherche plutôt à consommer son CPU en lui faisant valider la totalité des SYN Cookies qui, pour la plupart d'entre-eux, sont invalides puisque générés de manière aléatoire[16]^,[14]. En plus de consommer le CPU du serveur, cette attaque pénalise également sa bande passante[16].

Un inconvénient de l'utilisation des SYN Cookies est qu'il réduit les performances du serveur[12]. En effet, il ne prend pas en compte les paramètres contenus dans le champ « options » lorsque le client envoie son segment SYN[12]^,[16]. Ces paramètres, tels que la taille d'une fenêtre de réception[12]^,[16]^,[7], l'acquittement sélectif[12], le Round-Trip Time (RTT) [12], le Protect Against Wrapped Sequences (PAWS)[12] ou le MSS permettent des communications plus efficaces [12]^,[16]^,[7]. Néanmoins, cette perte n'est pas permanente puisque les SYN Cookies ne sont activés uniquement lorsque le serveur subit une attaque[16]^,[7], c'est-à-dire lorsque toutes les ressources du serveur sont occupées par des connexions semi-ouvertes [2]. Le reste du temps, les SYN Cookies sont désactivés[16]^,[7].

Les autres inconvénients de l'utilisation des SYN Cookies sont :

• inadaptés pour la protection des machines virtuelles à cause d’une surcharge trop rapide du CPU lors d’une attaque par inondation de requêtes SYN, même de faible envergure[17] ;
• les coûts de calcul supplémentaires nécessaires au traitement des paquets SYN et ACK entrant[4]^,[18] ;
• l'absence de retransmissions des paquets SYN+ACK[4]^,[18].

Sur Windows, il est possible d'activer une méthode similaire à SYN Cookie s'appelant SynAttackProtect[19]. Pour ce faire, il faut assigner la valeur recommandée 2[19] à la clef de registre SynAttackProtect se trouvant dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters. Il est également possible de choisir à partir de quel seuil une attaque par inondation de requêtes SYN sera détectée en modifiant les clefs de registre TcpMaxHalfOpen, TcpMaxHalfOpenRetried et TcpMaxPortsExhausted [20].

Sur Linux, il est possible de vérifier que les SYN Cookies sont actuellement activés au niveau du noyau soit en utilisant la commande sysctl -n net.ipv4.tcp_syncookies, soit en utilisant la commande cat /proc/sys/net/ipv4/tcp_syncookies. Si la valeur retournée par l'une de ces deux commandes est égale à 1, les SYN Cookies sont déjà activés. Sinon, il faut éditer le fichier /etc/sysctl.conf, passer la valeur net.ipv4.tcp_syncookies à 1 au lieu de 0, et recharger la configuration à l'aide de la commande sysctl -p ou redémarrer le serveur [1]^,[21].

Schéma du fonctionnement de flow-cookies.

Les flow-cookies sont un mécanisme dans lequel un serveur web coopère avec un intermédiaire, appelé cookie box, connecté à un lien haut débit. Ce mécanisme permet de tirer parti de la bande passante élevée de la cookie box pour le filtrage de paquet. Tout le trafic en provenance ou à destination du serveur Web protégé doit traverser la cookie box. Elle garantit que tous les paquets qui passent entre elle et le serveur appartiennent à un flux TCP légitime avec un expéditeur valide. Pour ce faire, la cookie box va placer un SYN Cookie dans chaque paquet sortant du réseau du serveur [24]. Le serveur web peut également demander à la cookie box de filtrer l'IP d'un client ayant un comportement anormal[25].

Protocole d'échange d'état de connexion avec M-SYN Cookie.

Le M-SYN cookie est un SYN cookie modifié pour les environnements multi-homed incluant le numéro d'identification du pare-feu[26]. Ce dernier est conçu pour partager les états de connexion entre les pare-feux via un choix particulier de numéro de séquence TCP [2].

Le M-SYN Cookie utilise l'ID du pare-feu à la place l'index MSS du cookie SYN afin d'enregistrer en toute sécurité les informations de l'expéditeur du cookie. La vérification des paquets SYN+ACK s'effectue par une fonction de hachage par clef. Pour utiliser cette fonction, tous les pare-feux doivent partager la même clef secrète. Protocole d'échange d'état de connexion avec M-SYN Cookie :

1. Le client envoie un paquet SYN qui arrive au pare-feu 1 ;
2. Le pare-feu 1 examine le paquet en fonction de ses règles de filtrage de paquets ;
3. Le pare-feu 1 remplace ${\displaystyle ISN_{c}}$ par le M-SYN Cookie, et conserve les informations de connexion dans sa table d'état ;
4. Le pare-feu 1 envoie le paquet SYN modifié au serveur ;
5. Le serveur envoie au client un paquet SYN+ACK qui passera par le pare-feu 2 ;
6. Le pare-feu 2 examine le paquet SYN+ACK et extrait l'ID du pare-feu 1. Si le paquet est invalide, il est abandonné ;
7. Le pare-feu 2 transmet le paquet SYN+ACK au pare-feu 1 ;
8. Le pare-feu 1 vérifie les informations de connexion du paquet et les envoie au pare-feu 2 avec le paquet SYN+ACK. S'il n'y a pas d'informations de connexion correspondantes, le pare-feu 1 abandonne le paquet ;
9. Le pare-feu 2 met à jour sa table d'état et remplace le numéro d'accusé de réception du paquet SYN+ACK par ${\displaystyle ISN_{c}+1}$ ;
10. Le pare-feu 2 envoie le paquet SYN+ACK modifié au client[27].

Ce protocole permet au pare-feu 1 et au pare-feu 2 de partager les informations de connexion[28]. Les paquets à venir, y compris le paquet ACK correspondant, peuvent passer directement à travers les deux pare-feu[28].