SYN cookie

Les SYN cookies (syncookies) sont des valeurs particulières des numéros de séquences initiales générés par un serveur (ISN: Initial Sequence Number) lors d'une demande de connexion TCP. La technique mise en œuvre permet notamment de se défendre contre les attaques par inondation de requêtes SYN et accessoirement par IP spoofing. Elle connaît cependant plusieurs inconvénients tels que la falsification et la perte d'informations du paquet SYN. Plusieurs améliorations ont été proposées afin de pallier ces inconvénients. Des extensions ont également été développées, notamment dans le cadre du multi-homing.

Principe

Définition

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

Valeur d'un SYN Cookie

Structure

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

Codage

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

Déroulement d'une connexion TCP avec SYN Cookie

Négociation en 3 phases

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

Vérification du SYN cookie

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

Inconvénients

Falsification de connexion

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

Perte des informations du paquet SYN

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

Autres inconvénients

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

Activation de SYN Cookie

Windows

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

Linux

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

Améliorations des performances

En 2006, KhakAbi a proposé une amélioration consistant à stocker dans une table de hachage les informations du paquet SYN telles que les options TCP, la taille des fenêtres et le MSS. Puisque cette méthode sauvegarde l'état des connexions, elle peut utiliser ces informations afin de proposer une connexion optimale. Cela implique également que les SYN Cookies peuvent être utilisés même lorsque le serveur ne subit pas d'attaque par inondation de requête SYN. Il n'est plus nécessaire non plus pour le serveur d'avoir un dispositif de détection^[13].

En 2007, plusieurs améliorations ont été proposées. Han Jianying et al. ont proposé une amélioration consistant à stocker temporairement les informations de base du paquet SYN afin d'identifier leur légalité. Cette amélioration vise à lutter contre l'inondation par requêtes ACK. Bien qu'elle permette de réduire le taux d'occupation du CPU, elle nécessite une consommation d'espace de stockage supplémentaire. Peng Di et al. ont, quant à eux, proposé une amélioration consistant à modifier le processus de réponse du protocole TCP pour le paquet SYN au niveau du système de défense. Cette méthode permet de réduire le temps de vérification du cookie et d'améliorer l'efficacité du système de défense^[6]. Cependant, elle n'est applicable que dans le scénario où le système de défense est séparé du serveur^[6].

En 2008, Jian Xiaochun et al. ont proposé une amélioration consistant à attendre la retransmission du paquet SYN du client. Cette méthode permet de réduire les aspects de calcul. Néanmoins, elle nécessite des ressources systèmes supplémentaires car elle implique de maintenir une table de hachage. Elle augmente également le temps de réponse pour une connexion TCP normale^[6].

En 2009, Bo Hang et al. ont proposé une amélioration consistant à modifier l'algorithme utilisé pour calculer les SYN Cookies. Leur méthode est basée sur 3 composants : le contrôleur, la détection d'attaque et la réponse à l'attaque^[6]. C'est en cas de détections d'attaque que le nouvel algorithme est utilisé^[22]. Cet algorithme redéfini le numéro de séquence initial de 32 bits^[6] de la manière suivante : un seul bit pour l'horodatage du cookie^[22] et 31 bit pour la valeur du cookie au lieu de 8 bits pour l'horodatage et 24 bits pour la valeur du cookie. Le nouvel algorithme utilise la méthode de chiffrement Blowfish avec une clef de 32 bits^[22] qui est plus rapide que les fonctions de hachage cryptographique^[23]. Cela a grandement réduit la complexité de calcul avec un gain d'environ 30 % sur le temps de calcul du cookie^[23].

Extensions de SYN Cookie

Flow-Cookies

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

M-SYN cookies

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

SYN Cookie dans l'internet des objets

Une étude a été réalisée sur l'utilisation de SYN Cookie au niveau des systèmes de classe 2, c'est-à-dire des dispositifs de l'internet des objets (IoT) à ressources limitées disposant d'une mémoire de 50 à 250 ko. Ces systèmes sont particulièrement vulnérables à ce type d'attaque à cause de la faible quantité de mémoire dont ils disposent. En effet, une inondation de requêtes SYN à faible débit ou même une augmentation soudaine du trafic entrant peut perturber ce dispositif s'il agit en tant que serveur. Cette étude a montré que les SYN Cookies étaient plus efficace que le recyclage d'anciennes connexions semi-ouvertes pour contrer une attaque par inondation de requête SYN de faible envergure^[29],[30].

Alternatives à SYN Cookie

Il existe plusieurs alternatives à SYN cookie pour se prémunir d'attaques par inondation de requêtes SYN :

• Synkill^[31] ;
• Syn-agent^[5] ;
• SYN Proxy^[32].

Histoire

Phil Karn (en) est le premier à avoir conçu un protocole Internet qui utilise les cookies afin de se protéger contre les attaques par déni de service^[33]. Le 16 septembre 1996, D. J. Bernstein eu l'idée d'utiliser des SYN cookies afin de se prémunir des attaques par inondation de requêtes SYN, considérées jusque là comme un problème insoluble. D. J. Bernstein et Eric Schenk ont travaillé sur les détails d'implémentation au cours des semaines suivantes. Eric Schenk eu l'idée d'ajouter quelque chose au numéro de séquence initial du client afin d'être conforme aux exigences du protocole TCP. Pour finir, D. J. Bernstein a proposé que les cookies dépendent du temps afin d'empêcher, dans un premier temps, qu'un attaquant puisse collecter des cookies valides sur un ordinateur public et, dans un second temps, les réutiliser depuis un autre endroit. En octobre 1996, Jeff Weisberg a publié une implémentation des SYN Cookies pour SunOS. Quelques mois plus tard, en février 1997, Eric Schenk a publié, à son tour, une implémentation des SYN Cookies pour Linux^[1].

Notes et références

1. Bernstein.
2. Kim 2008, p. 457.
3. Zúquete 2002, p. 57.
4. Smith 2008, p. 243.
5. Liu 2008, p. 1219.
6. Hang 2009, p. 446.
7. Korn 2011, p. 47.
8. Liu 2008, p. 1218.
9. Eddy 2007, p. 8.
10. Kleen 1997, p. 1.
11. Kim 2008, p. 458.
12. Zúquete 2002, p. 61.
13. KhakAbi 2009, p. 235.
14. Shah 2018, p. 1.
15. Shah 2018, p. 3.
16. Smith 2008, p. 244.
17. Shea 2012, p. 9.
18. Korn 2011, p. 48.
19. Korn 2011, p. 42.
20. Korn 2011, p. 43.
21. Yuan 2008, p. 58.
22. Hang 2009, p. 447.
23. Hang 2009, p. 448.
24. Casado 2006, p. 286.
25. Casado 2006, p. 287.
26. Kim 2008, p. 456.
27. Kim 2008, p. 459.
28. Kim 2008, p. 460.
29. Echevarria 2018, p. 741.
30. Echevarria 2018, p. 748.
31. Schuba 1997, p. 214.
32. Zhang 2007, p. 458.
33. Karn 1999.

Annexes

Bibliographie

 : 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)

• Portail de la sécurité informatique