Differences

This shows you the differences between two versions of the page.

Link to this comparison view

unix:syncookie [2010/01/12 13:29] (current)
Line 1: Line 1:
 +Le principe de cookie existe depuis longtemps en informatique. Il permet par exemple au protocole HTTP pourtant transactionnel de gérer la notion d'​états en conservant ces informations dans un fichier à chaque extrêmité de la transmission. En 1996, Dan J. Bernstein et Eric Schenk proposèrent l'​utilisation de cookies cryptographiques encodés dans l'​Initial Sequence Number (ISN) TCP [1] afin de supprimer totalement le cache d'​information jusqu'​à la complétion de la connexion. Ceci permet en effet d'​éliminer le risque de SYN flood, puisque le SYN n'​entraîne aucune allocation de mémoire, ne remplit pas la queue d'​écoute des connexions incomplètes,​ et ne permet donc aucun épuisement de ressources. L'​encodage dans l'ISN tel que présenté par Bernstein et Schenk est le suivant :
  
 +- Les 5 premiers bits valent t mod 32 où t est un compteur temporel allant de paire avec un secret
 +- les 3 bits suivant correspondent au MSS (Maximum Segment Size) sélectionné par le serveur. Cet encodage est indispensable puisque le serveur ne conserve pas l'​état de la connexion en cours de complétion et oublit donc plusieurs options TCP comme le MSS, le window scale etc.
 +- les derniers 24 bits correspondent au secret selectionné par le serveur.
 +  Ce secret est un hash MD5 de l'​adresse source, de l'​adresse de destination,​ du port source, du port de destination et enfin du compteur t.
 +  secret = hash(saddr,​sport,​daddr,​dport,​ t)
 +
 +Pour FreeBSD, que nous prendrons en exemple puisqu'​il possède une implémentation récente et bien documentée [2], l'​encodage est sensiblement différent. Le compteur temporel, destiné à rendre caduc la collecte et la réutilisation de cookies par un attaquant, possède une durée de vie limitée à 4 secondes censée permettre à la connexion de se compléter. Ce choix permet de limiter le ACK flood puisqu'​il faudrait générer un très grand nombre de paquets en seulement 4 secondes. Il reste donc 25 bits pour le secret, et 7 bits encodant les informations de window et de MSS.
 +
 +Comme nous l'​avons déjà fait remarquer, les syncookies créent quelques problèmes en ne conservant aucun état avant la complétion effective de la connexion. Il perd notamment toutes les options contenues dans le SYN et il ne peut pas non plus retransmettre de SYN/ACK en cas de disparité d'​états entre le client et le serveur dû à des pertes par exemple. Mais les syncookies peuvent également poser des problèmes de sécurité. Un attaquant peut ainsi tenter un ACK flood en espérant tomber sur quelques cookies, complétant ainsi une connexion et consommant tout de même des ressources. Cette attaque a de plus la capacité d'​outrepasser les règles de stateful inspection se basant sur les segments SYN puisque la connexion est désormais initialisée en réalité par le segment ACK. Pour ce dernier problème, Bernstein a proposé de conserver un timestamp du plus récent dépassement par queue d'​écoute,​ et de ne pas créer d'​état à la suite d'un ACK correspondant à un cookie si il n'y a pas eu de dépassement récent. Cette solution se traduisant concrêtement par un fonctionnement classique de TCP en temps normal, et un basculement sur le mécanisme de syncookie en cas de détection de SYN flood via un remplissage des queues.
 +
 +Il y a sur ce point une divergence entre Linux et FreeBSD probablement dû à la différence d'âge des 2 implémentations,​ respectivement 1997 et 2002. Linux utilise très classiquement les syncookies comme une solution de secours suite à un flood détecté sur des queues classiques. FreeBSD a décidé de modifier son système stockant les états afin de le rendre plus résistant avant de passer en dernier recours à un mécanisme de syncookie. FreeBSD utilise désormais un syncache pour conserver l'​état d'une connexion jusqu'​à sa complétion. Il a donc été décidé de limiter fortement les données conservées en utilisant une table de hashage, en lieu et place de la classique liste linéaire par sockets, avec les sockets indexées par bucket via des listes chaînées. Ensuite, en cas de détection de flood, la plus ancienne entrée (par bucket ou sur la totalité du cache) est supprimée, avant de basculer sur les syncookies. Ce mécanisme permet à la fois de diminuer l'​occupation mémoire et d'​accélérer le parcours de la structure de données.
 +
 +Les syncookies sont présents sous Linux depuis les kernels 2.0.29 et 2.0.30, avec cependant quelques problèmes dans la branche 2.2 jusqu'​au 2.2.14, et rien à signaler en 2.4. Pour les utiliser, vous devez activer l'​option CONFIG_SYNCOOKIES lors de la configuration de votre kernel puis recompiler. Vous pourrez ensuite activer effectivement les syncookies de la manière suivante :
 +
 +# echo "​1"​ > /​proc/​sys/​net/​ipv4/​tcp_syncookies
 +
 +Sous FreeBSD, les syncookies et le syncache sont présent par défaut depuis la release 4.5. Il vous suffit de vérifier ou adapter les entrées de la MIB sysctl suivantes ​
 +
 +# sysctl -w net.inet.tcp.syncookies=1
 +# sysctl -w net.inet.tcp.syncache.hashsize=512
 +# sysctl -w net.inet.tcp.syncache.cachelimit=15359
 +# sysctl -w net.inet.tcp.syncache.bucketlimit=30
 +# sysctl -w net.inet.tcp.syncache.rexmtlimit=3
 +
 +[1] SYN Cookies
 +    http://​cr.yp.to/​syncookies.html
 +
 +[2] Resisting SYN flood DoS attacks with SYN cache
 +    http://​people.freebsd.org/​~jlemon/​papers/​syncache.pdf
 +
 +--eberkut
unix/syncookie.txt · Last modified: 2010/01/12 13:29 (external edit)