Note de S/ash : cette traduction est loin d'être exempt de défaut. Notamment, j'ai eu du mal à traduire certaines expressions anglaise. Je les ais donc laissé avec une traduction approximative entre parenthèses. Certaines expression peuvent paraître maladroit voir difficile à comprendre. Si vous avez de meilleur traduction, merci de me prévenir : slash-rtc@fr.st NOTE : Je parle ici d'hote de confiance pour désigné 'trusted host' c'est-à-dire l'hote à qui la victime fait confiance ==Phrack Magazine== Volume Seven, Issue Forty-Eight, File 14 of 18 [ IP-spoofing Demystified ] (Trust-Relationship Exploitation) by daemon9 / route / infinity for Phrack Magazine June 1996 Guild Productions, kid comments to route@infonexus.com Traducteur : S/ash RtC : www.rtc.fr.st Le but de cet article est d'expliquer le spoofing IP à tout le monde. Pour le comprendre, il est nécessaire de posséder une petite connaissance du fonctionnement de Unix et du TCP/IP. Oh, et d'avoir un minimun de cervelle. Le spoofing IP est une attaque technique complexe qui est fait de plusieurs composentes. (En réalité, le spoofing n'est pas l'attaque, mais une des étapes de l'attaque. L'attaque est en fait l'exploitation les relations de confiance. Peut importe, dans cet article, le spoofing fera référence à l'attaque entière.) Dans cet article, j'expliquerai l'attaque en détail, y comprit les informations sur les systèmes d'exploitations et réseaux utiles. [SECTION I. INTRODUCTION] --[ Les acteurs ]-- A: la cible B: un hôte à qui la cible fait confiance X: Un hôte inaccessible Z: L'attaquant (1)2: Hôte 1 appairaissant comme l'hôte 2 (IP Masquerading) --[ Les Schémas ]-- Il y a quelques schémas dans cet article et ils doivent tous être interprétés comme suit : t hôte a contôle hôte b 1 A ---SYN---> B t : Un instant (un tick). Il n'y a pas de distinction faite sur le temps passé entre deux tick, c'est juste du temps passé. C'est en général pas beaucoup. hôte a : Une machine participant à la conversation TCP. contrôle : Ce champs montre tout les bits de contrôle interessant mis à 1 dans l'en-tête TCP et la direction du flux de données. hôte b : Une machine participant à la conversation TCP. Dans ce cas, au premier instant référencié dans le temps l'hôte a envoie un segment TCP à l'hôte b avec le flag SYN. A moins que cela ne soit mentionné, nous ne sommes en général pas concerné par la portion de données du segment TCP. --[ Relations de confiance ]-- Dans le monde Unix, des relations de confiance peuvent etre facilement données à tous. Imaginez que vous possédez un compte sur la machine A et sur la machine B. Pour facilement aller d'une machine à l'autre avec un minimum de commandes, vous voulez établir une relation complète de confiance entre chaque hote. Dans votre home directory sur la machine A vous créez un fichier .rhost : `echo "B username" > ~/.rhosts`. Sur la machine B vous créez un .rhost : `echo "A username" > ~/.rhosts`. (Le root peut également mettre des règles similaires dans /etc/hosts.equiv à la place, la différence étants que les règles sont alors valables pour tout utilisateur de l'hote). A présent, vous pouvez utiliser toutes les commandes r* sans s'inquietez avec l'authentification par mot de passe. Ces commandes authorisent l'authenfication basée sur l'adresse, ce qui enclenchera la demande d'authentification selon l'adresse IP du client. --[ Rlogin ]-- Rlogin est un protocol client-serveur simple qui utilise TCP comme protocol de transport. Rlogin authorise un utilisateur à se connecter d'un hote à un autre hote, et, si la machine cible fait confiance à l'autre, rlogin authorisera à ne pas demander de password. Donc, sur notre exemple précendent, nous pourrons utiliser rlogin pour se connecter de A vers B (et vice-versa) sans que l'on nous demande un mot de passe. --[ Internet Protocol ]-- IP est le protocole réseau sans connexion et non sur de la suite TCP/IP. Il possède (NDT : dans la version IPv4) 2 champs 32 bits dans l'en-tete pour contenir les informations sur les adresses. IP est également le plus utilisé de tout les protocoles TCP/IP puisque presque tout le traffic TCP/IP est encapsulé dans des datagrams IP. Le role de l'IP est de diriger les paquets sur le réseau. Il ne fourni aucun méchanisme pour le décompte des paquets ou pour etre sur qu'un paquet est arrivé ; pour cela il compte sur les couches supérieures. L'IP envoie simplement des datagrams et espère qu'ils arriveront intact. Si ce n'est pas le cas, l'IP peut essayer de renvoyer un message d'erreur ICMP vers la source, mais ce paquet peut également etre perdu. (ICMP : Internet Control Message Protocol est utilisé pour informer de l'état du réseau et différentes erreurs de l'IP et des autres couches) IP n'est pas destiné à garantir qu'un paquet a été délivré. Puisque IP n'utilise pas de connexion, il ne conserve aucune information sur l'état d'une quelconque connexion. Chaque datagram IP est envoyé sans tenir compte du datagram précedent ou suivant. Ceci, combiné au fait qu'il est aisé de modifier la pile IP pour authoriser une adresse IP arbitraire dans le champs de l'adresse source (et destination), font que l'IP est facilement mystifiable. --[ Transmission Control Protocol ]-- TCP est le protocol de transport orienté connexion et fiable de la suite TCP/IP. Orienté connexion signifie simplement que 2 hotes participant à une discution doivent d'abord établir une connexion avant que des données puissent etre échangées. La fiabilité est assurée par différents moyens mais seulement deux nous interessent : le séquencement des données et la notification. TCP assigne des numéros de séquence à chaque segment et notifie de la réception de chaque segment et de celle de tout les segments. (Les notifications (ACK) utilisent des numéros de séquence mais ne sont pas elle meme notifié). Cette fiabilité rend le TCP plus difficile à duper que l'IP. --[ Numéro de séquence (SEQ), Notification (ACK) et autre flags ]-- Puisque TCP est fiable, il doit etre capable de s'y retrouver parmis les données perdues, dupliquées ou invalides. En assignant un numéro de séquence à chaque octet transféré, et en requièrant une notification de l'autre hote à la réception, TCP peut garantir une livraison fiable. Le recepteur utilise les numéros de séquence pour s'assurer de l'ordre correct des données et éliminer les données dupliquées. Les numéros de séquence TCP peuvent etre imaginé simplement comme des compteurs de 32 bits. Leur valeur allant de 0 à 4,294,967,295. Chaque octet échangé à travers une connexion TCP (à part ceux avec certains flags) est séquencé. Le champ de numéro de séquence dans le header TCP contiendra donc le numéro de séquence du *premier* octet du segment de donnée du paquet. Le champs du numéro de notification (ACK) contient la valeur du numéro de notification du prochain paquet *attendu*, et également atteste que *toutes* les données sont ok à travers ce numéro ACK. (minus one ???) TCP utilise le concept de taille de fenetre pour le controle du flux. Il utilise une fenetre glissante (NDT : erghh) pour dire à l'autre hote quel taille de donnée il peut recevoir. Puisque la taille de fenetre est codé sur 16 bits, un paquet TCP peut contenir au plus 65535 octets. La taille de fenetre peut-etre vues comme une information d'une machine à l'autre sur le numéro le plus élevées qu'un numéro de séquence peut avoir. Les autres flags de l'en-tete TCP à remarquer sont RST (reset), PSH (push), et FIN (finish). Si un RST est reçu, la connexion est immédiatement arreter. RSTs sont normalement envoyé quand une machine reçoit un segment qui ne correspond pas à la connexion en cour (nous rencontrerons ce cas dans exemples plus loin). Le flag PSH dit au récepteur de passer les données à la couche d'application le plus rapidement possible. Le flag FIN est le moyens normal par lequel une application ferme une connexion (la fin d'une connexion se fait par un processus en 4 étapes). Quand une machine reçoit un FIN, il lui renvoie un ACK (notification), et n'attend plus aucune données (l'envoie est quand meme encore possible). --[ Etablissement d'une connexion TCP ]-- Pour échanger des données en utilisant TCP, les hotes doivent établir une connexion. TCP établit une connexion par un processus en 3 étapes appelé la '3-way handshake' (traduction littérale : la poignée de mains en 3 étapes). Si la machine A fait tourner un client rlogin et veut se connecter à un démon rlogin de la machine B, cela se fera sur le modèle suivant : fig(1) 1 A ---SYN---> B 2 A <---SYN/ACK--- B 3 A ---ACK---> B A l'étape (1) le client dit au serveur qu'il veut une connexion. C'est le seul but du flag SYN. Le client dit au serveur que le numéro de séquence fournit est valide, et doit etre vérifié. Le client mettra son ISN (initial sequence number) dans le champs de numéro de séquence. Le serveur, après la réception de ce segment (2) répondra par son propre ISN (donc le flag SYN est mis à 1) et il notifie (flag ACK mit à un) de la réception du premier segment du client (ISN du client + 1). Puis le client renvoie une notification ACK (NDT : je dirais maintenant seulement ACK) par le numéro ISN du serveur (3). A présent, le transfert de données peut etre effectué. --[ L'ISN et l'Incrémentation du Numéro de Séquence ]-- Il est important de comprendre comment les numéros de séquences sont initialement choisi, et comment ils changent en fonction du temps. Le numéro de séquence initial, quand un hote est mis en service, est initialisée à 1. (TCP nomme en fait cette variable 'tcp_iss' comme le numéro de séquence d'*envoie* initial (initial *send* sequence number). L'autre variable de numéro de séquence est 'tcp_irs' qui est le numéro de séquence de *réception* initial (initial *receive* sequence number) et est connu pendant l'établissement d'une connexion en trois étapes. Nous nous embeterons pas avec la distinction entre ces deux variables.) Cette pratique est mauvaise, et cela est précisé dans un commentaire de la fonction tcp_init() (NDT : ???). Le numéro ISN est incrémentée toutes les 128,000 seconde, ce qui fait que le compteur 32 bits ISN fait un tour complet en 9.32 heures si aucune connexion ne se produit. Dans l'autre cas, à chaque appel à connect(), le compteur est incrémenté de 64.000. Une raison importante de cette prédictabilité est pour mimiser les chance que des données provenant d'une vieille incarnation périmée (C'est à dire avec les memes adresses IP et memes port TCP) de la connexion en cours n'arrivent et ne foute le bordel. Le concept du temps d'attente 2MSL s'applique ici, mais dépasse le but de cet article. Si les numéros de séquence étaient choisi au hasard quand une connexion se met en place alors rien ne garantirait que les numéros de séquenve devrait etre différent des connexions précédentes. Si certaines données restaient collées dans une boucle de routage quelque part et se libèraient plus tard pour arriver pendant une nouvelle connexion du meme type (ie meme port/ip), cela pourrait réellement faire tout planter. --[ Ports ]-- Pour garantir un accès simultanée au module TCP, TCP fournit une interface utilisateur appelée port. Les ports sont utilisés par le noyau pour identifier les processus réseau. Il y a des couches de transport strictes (il est d'ailleur dit que IP pourrait s'en occuper plus). Avec l'adresse IP, le port TCP fournit un point de chute pour les communications réseaux. En fait, à tout moment, *toutes* les connexions Internet peuvent etre décrites par 4 chiffres : l'adresse IP source, le port source, l'adresse IP de destination et le port de destination. Les (logiciels) serveurs sont 'liées' aux ports 'bien-connus' et donc peuvent etre localisé sur les ports standard sur différents systèmes. Par exemple, le démon rlogin s'installe sur le port TCP 513. [SECTION II. L'ATTAQUE] ...The devil finds work for idle hands.... --[ Rapidement... ]-- L'IP-spoofing repose sur différentent étapes, qui sont rapidement décrites ici, puis expliquées en détails. D'abord, la victime est choisie. Puis, un type de confiance est découvert, authorisant certains hotes. L'hote à qui la victime fait confiance est déconnecté, et les numéros de séquences TCP de la victime sont analysées. L'identité de l'hote de confiance est usurpé, les numéros de séquence devinés, et une tentative de connexion est réalisé sur un service qui se fie seulement à l'adresse IP. Dans le cas d'un succès, l'attaquant exécute une simple commande pour laisser une backdoor. --[ Choses utiles ]-- Il y a une séries de choses dont vous aurez besoins pour mettre en place cette attaque (NDT : j'ai pas commpris à quoi correspondait sa numérotation) : (1) Un cerveaux, un esprit, ou tout autre périphérique de réflexion (1) Une victime (1) Un hote de confiance (1) Une machine d'attaque (avec un accès root) (NDT : norm, ta unix box (Linux, FreeBSD ou tout autre grille-pain fournissant un accès raw sockets). (1) Un logiciel d'IP-spoofing En général, l'attaque est faite à partir du compte root de la machine d'attaque vers le compte root de la victime. Si l'attaquant s'emmerde avec tous ces problèmes, il serait stupide de ne pas le faire pour avoir le root (Bien que l'accès root et nécessaire pour réussir cette attaque, elle n'en est pas nécessairement l'issue). --[ IP-Spoofing is a 'Blind Attack' ]-- (NDT : L'IP-Spoofing est une 'attaque aveugle') Beaucoup comprenne l'ip-spoofing, mais le facteur critique est que l'attaque est aveugle. L'attaquant est sur le point d'usurper l'identité d'un hote de confiance dans le but de déjoué la sécurité de la victime. On rend l'hote de confiance incapable de réalisée la méthode décrite plus loin. Tant que la victime le croie, elle entretient une conversation avec un parti de confiance. En réalité, l'attaquant est assis dans certains coins sombre de l'Internet, frabriquant ses paquets supposés venant de l'hote de confiance alors qu'il est bloqué dans une bataille de DoS (denial of service). Les datagrammes IP envoyé avec l'adresse IP modifié arrive à la cible (rappelé vous que l'IP est un protocol sans connexion -- chaque datagramme est envoyé sans information sur l'autre hote) mais le datagramme de la victime est renvoyé (destiné à l'hote de confiance) fini dans le 'bitbucket' (NDT : what is bitbucket ??). L'attaquant ne les voient jamais. Ils sont supposés aller à l'hote de confiance. Autant que la couche réseau le sachent, c'est de la d'où ils viennent, et c'est là où les réponsent doivent etre envoyés. Bien sur, une fois que les datagrammes sont routé à leur destination, et atteigne la couche TCP, il sont supprimés (l'hote de confiance ne peut répondre - voir plus loin). Donc l'attaquant doit etre malin et *savoir* ce qui a été envoyé, et quel réponse le serveur attend. L'attaquant ne peut pas voir ce que l'hote à envoyer, mais il peut *prédire* ce qu'y va etre envoyé ; ceci ajouté à la connaissance de ce qui va etre envoyé, authorise l'attaquant à travailler dans l'obscurité. --[ Relation de confiance ]-- Après qu'une cible a été choisie, l'attaquant doit déterminer les relations de confiance (pour ici, nous supposerons que la cible *fait* confiance à quelqu'un. Si ce n'est pas le cas, l'attaque ne peut se terminer ici). Savoir quel sont les hotes de confiance peut etre ou ne pas etre facile. Un 'showmount -e' permet de voir où les systèmes de fichiers sont exportés, et un rpcinfo peut également donnés des informations interessantes. Si suffisamment d'information sont récupérés sur la victime, cela ne devrait pas etre trop difficile. Si tout cela échoue, essayer les adresses IP voisine en brute force peut etre une option interessante. --[ Déconnecter les hotes de confiance part un SYN flood ]-- Une fois que l'hote de confiance est trouvé, il doit etre déconnecter. Puisque l'attaquant cherche à lui voler son identité, il (NDT: l'auteur mets toujours she, à croire que l'attaquant doit etre une fille, il est plus probable que l'autheur (daemon9 ? infinity ?) en soit une) doit s'assurer que l'hote ne peut recevoir de traffic réseau et foutre le merdier dans l'attaque. Il y a plusieur moyens de le faire, celui dont je vais discuter est le TCP SYN flooding. (NDT : autres moyens : DDoS divers (cf mon article), DoS spécifique à l'OS de l'hote). Une connexion TCP est initialisée par une requete au serveur avec le flag SYN dans l'header TCP. Normalement le serveur doit répondre par un SYN/ACK au client identifié par l'adresse source 32 bits du header IP. Le client enverra alors un ACK au serveur (comme montré dans la figure 1 au-dessus) et le transfer de données peut commencer. Il y a une limite aux nombres de requete SYN TCP peut gérer for une socket donnée. Cette limite est apelée le backlog, et est la taille de la queue où sont stocké les connexions rentrantes (et donc incomplètes). Cette limite de queue s'applique aussi bien aux nombres de connexions incomplètes (le processus en 3 étapes n'est pas fini) qu'aux nombres de connexions complètes qui n'ont pas été sortit de la queue par l'application par le biais du signale système accept(). Si ce backlog est atteint, TCP refuse tout nouveau paquet SYN jusqu'à ce que les connexions en attentes puissent etre gérées. A partir de là l'attaque à réussi. L'attaquant envoie plusieurs requete SYN au port TCP qu'il veut désactiver. L'hote d'attaque doit aussi etre sur que l'adresse IP source est fausse, spoofé d'un autre hote actuellement désactivé (La victime répondra à cette adresse. IP informera TCP que l'hote est injoignable, mais TCP considère ces erreurs comme temporaire, laisse IP les résoudre (rerouter les paquets, etc) et les ignore). L'adresse IP doit etre injoignable car l'attaquant ne veut pas recevoir les SYN/ACKs qui viendrait de la victime (il en résulterait un renvoie de RST au TCP de la victime, ce qui foutrait en l'air l'attaque). Le processus est le suivant : fig(2) 1 Z(x) ---SYN---> B Z(x) ---SYN---> B Z(x) ---SYN---> B Z(x) ---SYN---> B Z(x) ---SYN---> B ... 2 X <---SYN/ACK--- B X <---SYN/ACK--- B ... 3 X <---RST--- B En (1), l'attaquant envoie une multitude de requete SYN à la victime (rapelé vous que la victime est l'hote de confiance) pour remplir la queue jusqu'au backlog avec des connexions en attentes. (2) La cible répond par des SYN/ACKs à ce qu'il croit etre la source des SYNs. Pendant ce temps tout autre connexion à ce port sera ignoré. Les implémentations TCP différentes ont des tailles de backlog différentes. BSD a en général un backlog de 5 (Linux en a un de 6). Il y a aussi des marges de 'grace' de 3/2. TCP acceptera backlog*3/2+1 connexions. Cela autorise une connexion sur une socket meme si le backlog est de 0. AuthNote: [pour un traitement plus en profondeur du TCP SYN flooding, allez voir mon papier définitif sur le sujet. Cela couvre le processus en détail, aussi bien en théorie qu'en pratique. Il y contient un code robuste, un analyseur statistique, et un long article. voir dans l'issue 49 de Phrack. -daemon9 6/96] --[ Analyse et prédiction des numéros de séquence ]-- A présent, l'attaquant a besoin de se faire une idée sur la situation du numéro de séquence TCP de la victime. L'attaquant se connecte à un port TCP de la cible (SMTP est un bon choix) juste avant de lancer une attaque et de completer le processus de connexion en trois phases. Le processus est exactement le meme qu'en fig (1), exepté le fait que l'attaquant va enregistrer la valeur de l'ISN envoyé par la victime. Souvent, ce processus est répété plusieurs fois et l'ISN final envoyé est sauvegardé. L'attaquant a besoin de ce faire une idée sur la gueule du RTT (round-trip time) entre la cible et sa machine. (Le processus peut etre répété plusieurs fois et la valeur moyenne du RTT calculé). Le RTT est nécessaire pour etre capable de prédire le prochain ISN. L'attaquant possède maintenant les bases (le dernier ISN envoyé) et sait de combien le numéro de séquence est incrémenté (128.000/seconde et 64.000 par connexion) et a maintenant une bonne idée sur le temps que met un datagramme IP pour traversé l'Internet jusqu'à la cible (environ, la moitié du RTT, car la plupart du temps les routes sont symétriques). Après que l'attaquant ait en sa possession ces informations, il peut immédiatement procéder à la phase suivante de l'attaque (si une autre connexion TCP arrive sur n'importe quel port de la cible avant que l'attaque ne soit faite, l'ISN prédit par l'attaquant sera différent de 64.000 par rapport à l'ISN réel). Quand le segment spoofé a fait son chemin vers la cible, plusieur choses peuvent se passer : - Si le numéro de séquence est EXACTEMENT celui que TCP esperait qu'il soit, les données seront placé sur la place suivante disponible dans le buffer de réception. - Si le numéro de séquence est PLUS PETIT que la valeur voulue, les données seront considérés comme une retransmission et seront ignoré. - Si le numéro de séquence et PLUS GRAND que la valeur voulue mais quand meme dans les limites de la taille de fenetre, les données seront considérés comme des données à venir après, et gardés par TCP, attendant l'arrivée des données manquante. Si un segment arrive avec un numéro de séquence PLUS GRAND que la valeur voulue et qui n'est plus dans les limites de la taille de fenetre, le segment sera supprimé et TCP renverra un segment avec le numéro de séquence *voulu*. --[ Tromper... ]-- A ce momment commence l'essentiel de l'attaque par derrière commence : fig(3) 1 Z(b) ---SYN---> A 2 B <---SYN/ACK--- A 3 Z(b) ---ACK---> A 4 Z(b) ---PSH---> A [...] L'attaquant spoof son adresse IP avec celle de l'hote de confiance (qui doit etre encore sous les effets de l'attaque DoS) et envoie ces requete de connexion au port 513 de la victime (1) (NDT : ici, il s'agit du port rlogin, mais on peut facilement le faire sur un protocol différent comme NFS). En (2), la victime répond à la requete de connexion spoofée par un SYN/ACK, qui fera son chemin jusqu'à l'hote de confiance (qui s'il *pouvait* s'occuper des segments TCP entrant, considèrerait ce segment comme une erreur, en enverrait immédiatement un RST à la cible). Si tout ce passe comme prévu, le SYN/ACK sera ignoré par l'hote de confiance débordé. Après (1), l'attaquant doit attendre un peu pour laisser la cible le temps d'envoyer le SYN/ACK (l'attaquant ne peut pas voir ce segment). Puis, en (3), l'attaquant envoie un ACK à la cible avec le numéro de séquence prédit (plus un, car nous le notifions (ACK)). Si l'attaquant a bien prédit l'ISN, la victime acceptera l'ACK. La cible est alors compromise et le transfert de données peut commencer (4). En général, après l'avoir compromis, l'attaquant inserera une backdoor sur le system ce qui autorisera une intrusion plus simple. (souvent c'est 'cat + + >> ~/.rhosts' qui est fait. C'est une bonne idée pour plusieurs raisons : c'est rapide, efficace, et non-interactif. Rappelez-vous que l'attaquant ne peut voir aucun traffic venant de la cible, donc toutes les réponse seront envoyé vers l'oubli). --[ Pourquoi ça marche ? ]-- L'IP-Spoofing marche parce que les services basés sur des relations de confiance repose sur une identification par adresse réseau. Comme IP est facile à tromper, la modification des adresses n'est pas difficile. Le plus difficile dans l'attaque est la prédiction du numéro de séquence, car c'est ici qu'entre en jeu le travail de prédiction. Réduire les inconnues et la prédiction au minimum, et l'attaque aura de meilleur chance de réussir. Meme une machine qui gérerai toute les connexions TCP entrante avec le TCP wrappers de Wietse Venema serait encore vulnérable à l'attque. Les wrappers TCP se repose uniquement sur un nom d'hote ou une adresse IP pour l'authentification... [SECTION III. MESURES PREVENTITIVES] ...A stich in time, saves nine... --[ Ne pas faire confiance ]-- Une solution facile pour prévenir cette attaque est de ne pas utiliser d'authentification par adresse. De désactiver toute les r* commandes, de retirer tout les fichiers .rhosts et de vider le fichier /etc/hosts.equiv. Cela forcera tout les utilisateurs à utiliser d'autre moyens d'accès (telnet, ssh, skey, etc). --[ Filtrage des paquets ]-- Si votre site possède une connexion directe à l'Internet, vous pouvez utilisez les routeurs pour vous aidez. D'abord assurez-vous que seul les hotes du réseau interne peuvent participer à des relations de confiance (aucun hote du réseau ne doit faire confiance à une machine externe). Les routeurs filtrerons simplement *tout* le traffic venant de l'exterieur (L'Internet) qui est supposé venir de l'intérieur (réseau interne). --[ Méthodes Cryptographiques ]-- Une méthode trivial pour empécher l'IP-spoofing est de requerir que tout le traffic du réseau soit encryptée ou authentifié. Bien que plusieurs solutions existe, cela prendra du temps avant que de tel mesure soit employé en standard defacto. --[ Initial Sequence Number Randomizing ]-- Comme les numéros de séquence ne sont pas choisi aléatoirement (ou incrémenté aléatoirement), cette attaque fonctionne. Bellovin a décrit une correction pour TCP qui consiste en la séparation des espaces de numéro de séquence. Chaque connexion aura son propre espace de numéro de séquence. Le numéro de séquence sera encore incrémenté comme auparavant, mais il n'y aura plus de relation entre les numérotations des différent espaces. La suggestion repose sur la formule suivante : ISN=M+F(localhost,localport,remotehost,remoteport) Où M est le timer de 4 microseconde et F un hachage cryptographique. F ne doit pas etre calculable de l'extérieur ou l'attaquant pourrait encore deviné les numéros de séquence. Bellovin suggère que F soit un hachage du l'identifiant de connexion et d'un vecteur secret (un nombre au hasard, ou un nombre en relation avec l'hote combiné avec l'heure d'installation (NDT : ou de lancement ? il s'agit de la traduction de boot, mais il reste plus probable que ce soit l'heure de mise en service de la machine)). [SECTION IV. SOURCES] -Livre: TCP/IP Illustrated vols. I, II & III -RFCs: 793, 1825, 1948 -People: Richard W. Stevens, and the users of the Information Nexus for proofreading -Sourcecode: rbone, mendax, SYNflood Cet article a été rendu possible grace à l'aide de la Guild Corporation.