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].

: document utilisé comme source pour la rédaction de cet article.

• (en) D. J. Bernstein, « SYN cookies », sur cr.yp.to (consulté le 1^er décembre 2019). 
• (en) Andi Kleen, « syncookie.c », sur github.com (consulté le 8 février 2020). 
• (en) C.L. Schuba, I.V. Krsul, M.G. Kuhn et E.H. Spafford, « Analysis of a denial of service attack on TCP », Proceedings. 1997 IEEE Symposium on Security and Privacy (Cat. No.97CB36097), IEEE,‎ 1997, p. 208-223 (ISBN 978-0-8186-7828-8, DOI 10.1109/SECPRI.1997.601338, lire en ligne, consulté le 8 février 2020). 
• (en) David Wetherall, « 10 Networking Papers: readings for protocol design », ACM SIGCOMM Computer Communication Review, vol. 36, n^o 3,‎ 5 juillet 2006, p. 77 (DOI 10.1145/1140086.1140096, lire en ligne, consulté le 1^er décembre 2019)
• (en) Jin-Ho Kim, Heejo Lee et Saewoong Bahk, « A connection management protocol for stateful inspection firewalls in multi-homed networks », Journal of Communications and Networks, vol. 10, n^o 4,‎ décembre 2008, p. 455–464 (ISSN 1229-2370 et 1976-5541, DOI 10.1109/JCN.2008.6389863, lire en ligne, consulté le 1^er décembre 2019). 
• (en) Dongqing Yuan et Jiling Zhong, « A lab implementation of SYN flood attack and defense », Proceedings of the 9th ACM SIGITE conference on Information technology education - SIGITE '08, ACM Press,‎ 2008, p. 57 (ISBN 978-1-60558-329-7, DOI 10.1145/1414558.1414575, lire en ligne, consulté le 1^er décembre 2019). 
• (en) Bo Hang et Ruimin Hu, « A novel SYN Cookie method for TCP layer DDoS attack », 2009 International Conference on Future BioMedical Information Engineering (FBIE),‎ décembre 2009, p. 445–448 (DOI 10.1109/FBIE.2009.5405818, lire en ligne, consulté le 1^er décembre 2019). 
• (en) Bo Hang, Ruimin Hu et Wei Shi, « An Enhanced SYN Cookie Defence Method for TCP DDoS Attack », Journal of Networks, vol. 6, n^o 8,‎ 1^er août 2011, p. 1206–1213 (ISSN 1796-2056, DOI 10.4304/jnw.6.8.1206-1213, lire en ligne, consulté le 1^er décembre 2019). 
• (en) Juan Jose Echevarria, Pablo Garaizar et Jon Legarda, « An experimental study on the applicability of SYN cookies to networked constrained devices: SYN cookies for constrained devices », Software: Practice and Experience, vol. 48, n^o 3,‎ mars 2018, p. 740–749 (DOI 10.1002/spe.2510, lire en ligne, consulté le 1^er décembre 2019). 
• (en) C. Smith et A. Matrawy, « Comparison of operating system implementations of SYN flood defenses (Cookies) », 2008 24th Biennial Symposium on Communications,‎ juin 2008, p. 243–246 (DOI 10.1109/BSC.2008.4563248, lire en ligne, consulté le 1^er décembre 2019). 
• (en) Pi-E Liu et Zhong-Hua Sheng, « Defending against tcp syn flooding with a new kind of syn-agent », 2008 International Conference on Machine Learning and Cybernetics, vol. 2,‎ juillet 2008, p. 1218–1221 (DOI 10.1109/ICMLC.2008.4620589, lire en ligne, consulté le 1^er décembre 2019). 
• (en) András Korn, Defense mechanisms against network attacks and worms, 2011 (lire en ligne). 
• (en) Fengli Zhang, Ji Geng, Zhiguang Qin et Mingtian Zhou, « Detecting the DDoS attacks based on SYN proxy and Hop-Count Filter », 2007 International Conference on Communications, Circuits and Systems,‎ juillet 2007, p. 457–461 (DOI 10.1109/ICCCAS.2007.6251605, lire en ligne, consulté le 1^er décembre 2019). 
• (en) Udaya Kiran Tupakula, Vijay Varadharajan et Srini Rao Pandalaneni, « DoSTRACK: a system for defending against DoS attacks », Proceedings of the 2009 ACM symposium on Applied Computing - SAC '09, ACM Press,‎ 2009, p. 47 (ISBN 978-1-60558-166-8, DOI 10.1145/1529282.1529291, lire en ligne, consulté le 1^er décembre 2019)
• (en) Shaila Ghanti et G. M. Naik, « Efficient Data Transfer Rate and Speed of Secured Ethernet Interface System », International Scholarly Research Notices, vol. 2016,‎ 2016, p. 1–8 (ISSN 2356-7872, PMID 28116350, PMCID PMC5223014, DOI 10.1155/2016/9458627, lire en ligne, consulté le 1^er décembre 2019)
• (en) M. Casado, P. Cao, A. Akella et N. Provos, « Flow-Cookies: Using Bandwidth Amplification to Defend Against DDoS Flooding Attacks », 200614th IEEE International Workshop on Quality of Service,‎ juin 2006, p. 286–287 (DOI 10.1109/IWQOS.2006.250484, lire en ligne, consulté le 1^er décembre 2019). 
• (en) Hal Berghel, « Hijacking the web », Communications of the ACM, vol. 45, n^o 4,‎ 1^er avril 2002, p. 23 (DOI 10.1145/505248.505263, lire en ligne, consulté le 1^er décembre 2019)
• (en) André Zúquete, « Improving the Functionality of SYN Cookies », dans Advanced Communications and Multimedia Security, vol. 100, Springer US, 2002 (ISBN 978-1-4757-4405-7, DOI 10.1007/978-0-387-35612-9_6, lire en ligne), p. 57–77. 
• (en) Marco de Vivo, Gabriela O. de Vivo, Roberto Koeneke et Germinal Isern, « Internet vulnerabilities related to TCP/IP and T/TCP », ACM SIGCOMM Computer Communication Review, vol. 29, n^o 1,‎ 1^er janvier 1999, p. 81 (DOI 10.1145/505754.505760, lire en ligne, consulté le 1^er décembre 2019)
• (en) Paul Chaignon, Diane Adjavon, Kahina Lazri et Jérôme François, « Offloading Security Services to the Cloud Infrastructure », Proceedings of the 2018 Workshop on Security in Softwarized Networks: Prospects and Challenges - SecSoN '18, ACM Press,‎ 2018, p. 27–32 (ISBN 978-1-4503-5912-2, DOI 10.1145/3229616.3229624, lire en ligne, consulté le 1^er décembre 2019)
• (en) S. KhakAbi, « Preventing SYN flood DoS attacks (Abstract) An improvement to SYN cookies », 2009 IEEE International Conference on Intelligence and Security Informatics,‎ juin 2009, p. 235–235 (DOI 10.1109/ISI.2009.5137317, lire en ligne, consulté le 1^er décembre 2019). 
• (en) Edoardo Biagioni, « Preventing UDP Flooding Amplification Attacks with Weak Authentication », 2019 International Conference on Computing, Networking and Communications (ICNC), IEEE,‎ février 2019, p. 78–82 (ISBN 978-1-5386-9223-3, DOI 10.1109/ICCNC.2019.8685648, lire en ligne, consulté le 1^er décembre 2019)
• (en) Yogesh Prem Swami et Hannes Tschofenig, « Protecting mobile devices from TCP flooding attacks », Proceedings of first ACM/IEEE international workshop on Mobility in the evolving internet architecture - MobiArch '06, ACM Press,‎ 2006, p. 63 (ISBN 978-1-59593-566-3, DOI 10.1145/1186699.1186717, lire en ligne, consulté le 1^er décembre 2019)
• (en) Peter G. Neumann, « Risks to the public in computers and related systems », ACM SIGSOFT Software Engineering Notes, vol. 22, n^o 2,‎ 1^er mars 1997, p. 19–24 (DOI 10.1145/251880.251918, lire en ligne, consulté le 1^er décembre 2019)
• (en) H. K Molia, S. M. Gambhir et M. D. Titiya, « TCP based SYN Flood Attack-Analysis, Detection and Prevention », 3rd International Conference on Multidisciplinary Research & Practice, vol. 4, n^o 1,‎ 24 décembre 2016, p. 249–253 (lire en ligne, consulté le 1^er décembre 2019)
• (en) Dakshil Shah et Varshali Kumar, « TCP SYN Cookie Vulnerability », arXiv:1807.08026 [cs],‎ 20 juillet 2018 (lire en ligne, consulté le 1^er décembre 2019). 
• (en) W. Eddy, « TCP SYN Flooding Attacks and Common Mitigations », sur tools.ietf.org, août 2007 (consulté le 1^er décembre 2019). 
• (en) P. Karn, Qualcomm, W. Simpson et DayDreamer, « Photuris: Session-Key Management Protocol », sur tools.ietf.org, mars 1999 (consulté le 8 décembre 2020). 
• (en) L. Ricciulli, P. Lincoln et P. Kakkar, « TCP SYN flooding defense », CNDS,‎ janvier 1999 (lire en ligne, consulté le 1^er décembre 2019)
• (en) R. Shea et J. Liu, « Understanding the impact of Denial of Service attacks on Virtual Machines », 2012 IEEE 20th International Workshop on Quality of Service,‎ juin 2012, p. 1–9 (DOI 10.1109/IWQoS.2012.6245975, lire en ligne, consulté le 1^er décembre 2019). 
• (en) Ramón Cáceres, Fred Douglis, Anja Feldmann et Gideon Glass, « Web proxy caching: the devil is in the details », ACM SIGMETRICS Performance Evaluation Review, vol. 26, n^o 3,‎ 1^er décembre 1998, p. 11–15 (DOI 10.1145/306225.306230, lire en ligne, consulté le 1^er décembre 2019)
• (en) Bianca Schroeder et Mor Harchol-Balter, « Web servers under overload: How scheduling can help », ACM Transactions on Internet Technology, vol. 6, n^o 1,‎ 1^er février 2006, p. 20–52 (DOI 10.1145/1125274.1125276, lire en ligne, consulté le 1^er décembre 2019)