Résumé

  • Le SYN flood exploite une asymétrie : le serveur réserve un état semi-ouvert avant que l’initiateur n’achève la poignée de main, si bien que des requêtes peu coûteuses peuvent saturer une file finie.
  • Le RFC 4987 retient deux défenses d’extrémité : conserver un état réduit dans un cache SYN borné, ou ne rien conserver et reconstruire l’état à partir d’un cookie SYN renvoyé dans l’ACK.

À l’arrivée d’un SYN, un serveur à l’écoute prend une décision qui paraît minuscule. Il mémorise la tentative, envoie un SYN-ACK et attend. Pour un client honnête, ce comportement est banal. Pour l’attaquant, il révèle une avance de crédit : le serveur paie en mémoire et en temporisateurs avant que le prétendu client ait montré qu’il pouvait seulement entendre la réponse.

Le RFC 4987 décrit l’exploitation de cette avance. Une pile TCP classique conserve un état SYN-RECEIVED pendant que la poignée de main reste inachevée. La file des connexions semi-ouvertes a une taille finie. Il suffit d’y faire entrer des demandes plus vite qu’elles n’en sortent pour empêcher de nouvelles connexions légitimes d’y trouver place. Le document étudie l’épuisement de l’état TCP de l’hôte et l’indisponibilité de l’application. Il ne prétend pas résoudre le cas différent où le volume de paquets sature d’abord la liaison réseau.

L’adresse source usurpée est un moyen pratique de rendre le demandeur muet, mais elle n’est pas une condition universelle. Des machines compromises peuvent envoyer depuis des adresses routables et maintenir la même pression. Le mécanisme dépend de trois faits plus simples : chaque SYN provoque une allocation, le stock d’états semi-ouverts est limité et la cadence de requêtes dépasse celle de la récupération. Dans le modèle du RFC, ce sont les nouvelles connexions entrantes vers le port visé qui souffrent directement, non les connexions déjà établies.

Les premières réponses déplacent souvent le seuil sans renverser l’asymétrie. Agrandir la file oblige le serveur à financer davantage de mémoire mais donne aussi à l’attaquant une cible plus grande à remplir. Raccourcir le délai SYN-RECEIVED libère les entrées plus tôt, au prix d’abandonner des clients honnêtes ralentis par le réseau ; l’attaquant peut accroître son rythme. Recycler la plus ancienne structure semi-ouverte transforme l’âge en critère d’éviction sans savoir quel client est réel.

Le filtrage d’entrée réduit les attaques qui dépendent de l’usurpation, mais son déploiement n’est pas universel et il ne supprime pas les botnets à adresses valides.

Se souvenir de moins, mais de façon contrôlée

Le cache SYN change le prix du premier message. Au lieu de créer immédiatement un bloc de contrôle TCP complet, le serveur garde une fiche plus petite, suffisante pour terminer ensuite la poignée de main. Le cache est borné. Le RFC décrit également une répartition par hachage secret entre plusieurs compartiments. Si la fonction était prévisible, l’attaquant pourrait concentrer toutes ses demandes sur un seul compartiment, même lorsque le reste du cache est libre. Le secret rend cette concentration ciblée plus difficile, tandis que les bornes plafonnent la mémoire et le travail de recherche.

Ce cache reste un état. Il doit expirer proprement et conserver la possibilité de retransmettre un SYN-ACK perdu. Envoyer une réponse puis oublier le devoir de retransmission transformerait une perte ordinaire en refus de connexion. L’avantage n’est donc pas d’effacer TCP, mais de remettre à plus tard la structure coûteuse tout en préservant assez de comportement pour atteindre le dernier ACK.

Placer le reçu dans la réponse

Le cookie SYN pousse la logique plus loin. Le serveur ne conserve aucun état SYN-RECEIVED pour cette tentative. Il construit son numéro de séquence initial de sorte que l’ACK final lui rapporte les éléments nécessaires à la validation et à la reconstruction. Ce n’est qu’après le retour d’un ACK valable qu’il alloue le bloc de contrôle complet.

L’annexe A illustre une construction combinant le numéro de séquence de l’initiateur, un codage de la taille maximale de segment, un compteur temporel, les adresses et ports, et une fonction secrète. À la réception de l’ACK, le serveur vérifie le résultat avec son secret et des valeurs récentes du compteur. Il s’agit du reçu compact d’un échange précis, pas de l’authentification d’une personne ou d’une application. L’ACK montre qu’un expéditeur possède des informations issues du SYN-ACK, sous réserve de la résistance du calcul aux devinettes ; il ne crée pas une identité durable.

L’absence d’état a cependant un coût sémantique. Entre SYN et ACK, TCP conserve normalement des choix négociés. La place disponible dans un cookie est limitée : les constructions courantes peuvent donc restreindre le window scaling, SACK ou de futurs paramètres. Le RFC évoque aussi les données portées par le SYN. Si l’ACK final est perdu et que le serveur attend des données du client avant de parler, l’absence d’état peut empêcher une retransmission normale du SYN-ACK. La dépense a été différée, mais une partie de la mémoire du protocole l’a été aussi.

Les deux techniques peuvent coopérer. Le serveur utilise son cache SYN quand il reste de la capacité, puis passe aux cookies quand la borne est atteinte. Cette solution hybride conserve davantage de négociation en régime normal et réserve le reçu sans état aux périodes de pression. Un pare-feu ou un proxy peut aussi terminer ou relayer l’ouverture, mais il déplace le détenteur de l’état et peut modifier la sémantique de bout en bout. La décision de ressource n’a pas disparu ; elle a changé de propriétaire.

Publié en août 2007, le RFC 4987 est un document Informationnel, non une obligation de la voie Standards Track. Son analyse considère le cache SYN et les cookies SYN comme les modifications d’extrémité viables de son époque, tout en jugeant le cache plus approprié comme comportement ordinaire lorsqu’il est disponible. Cette recommandation historique ne prouve rien sur les réglages actuels d’un système d’exploitation.

La règle durable est plus générale : ne pas engager une ressource rare, coûteuse et dirigée par l’adversaire dès le premier message non vérifié lorsqu’une représentation moins chère et réversible peut faire progresser l’échange. Attendre le retour d’un élément de la réponse améliore la preuve de joignabilité. Cela ne transforme pas le transport en système d’identité, et le report peut perdre du contexte utile. Une défense honnête doit donc montrer à la fois l’état qu’elle économise et la sémantique qu’elle abandonne.

La source unique est le RFC 4987, « TCP SYN Flooding Attacks and Common Mitigations ». Le présent article reste dans ses limites : état TCP de l’hôte, défenses analysées et compromis explicités, sans affirmation sur les déploiements, réglages ou fréquences d’attaque actuels.