-------[  RtC Mag, At the end of the universe  ]

--------------[  IP-spoofing Demystified  ]
---------[ in Phrack 48 ]

----[  by daemon9 / route / infinity [Guild Productions] <route@infonexus.com> ]
----[  Translated by S/ash [RtC] <slash-rtc@fr.st>  ]


Note de S/ash : cette traduction est loin d'tre exempt de dfaut.
Notamment, j'ai eu du mal  traduire certaines expressions anglaise.
Je les ais donc laiss avec une traduction approximative entre 
parenthses. Certaines expression peuvent paratre maladroit 
voir difficile  comprendre. Si vous avez de meilleur traduction, 
merci de me prvenir : slash-rtc@fr.st
NOTE : Je parle ici d'hote de confiance pour dsign '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 <slash-rtc@fr.st>
		                 RtC : www.rtc.fr.st <rtc@fr.st>


        Le but de cet article est d'expliquer le spoofing IP  tout le
monde. Pour le comprendre, il est ncessaire de possder 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 ralit, 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 rfrence  l'attaque entire.) Dans cet article, j'expliquerai
l'attaque en dtail, y comprit les informations sur les systmes
d'exploitations et rseaux utiles.


                [SECTION I.  INTRODUCTION]


        --[ Les acteurs ]--


        A:      la cible
        B:      un hte  qui la cible fait confiance
        X:      Un hte inaccessible
        Z:      L'attaquant
        (1)2:   Hte 1 appairaissant comme l'hte 2 (IP Masquerading)


        --[ Les Schmas ]--

          Il y a quelques schmas dans cet article et ils doivent
tous tre interprts comme suit :

 t     hte a     contle      hte 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 gnral
pas beaucoup.
hte a :   Une machine participant  la conversation TCP.
contrle : Ce champs montre tout les bits de contrle interessant mis  1
dans l'en-tte TCP et la direction du flux de donnes.
hte b :   Une machine participant  la conversation TCP.

Dans ce cas, au premier instant rfrenci dans le temps l'hte a envoie
un segment TCP  l'hte b avec le flag SYN. A moins que cela ne soit
mentionn, nous ne sommes en gnral pas concern par la portion de 
donnes du segment TCP.


        --[ Relations de confiance ]--

        Dans le monde Unix, des relations de confiance peuvent etre
facilement donnes  tous. Imaginez que vous possdez 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
complte de confiance entre chaque hote. Dans votre home directory sur
la machine A vous crez un fichier .rhost : `echo "B username" > ~/.rhosts`.
Sur la machine B vous crez un .rhost : `echo "A username" > ~/.rhosts`.
(Le root peut galement mettre des rgles similaires dans /etc/hosts.equiv
 la place, la diffrence tants que les rgles sont alors valables pour
tout utilisateur de l'hote). A prsent, vous pouvez utiliser toutes les
commandes r* sans s'inquietez avec l'authentification par mot de passe.
Ces commandes authorisent l'authenfication base 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 prcendent, 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 rseau sans connexion et non sur de la
suite TCP/IP. Il possde (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 rseau. Il ne fourni
aucun mchanisme pour le dcompte des paquets ou pour etre sur qu'un
paquet est arriv ; pour cela il compte sur les couches suprieures.
L'IP envoie simplement des datagrams et espre 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 rseau et diffrentes erreurs de l'IP et des autres couches)
IP n'est pas destin  garantir qu'un paquet a t dlivr. 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 prcedent 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 donnes puissent etre changes. La fiabilit est assure par
diffrents moyens mais seulement deux nous interessent : le squencement
des donnes et la notification. TCP assigne des numros de squence  chaque
segment et notifie de la rception de chaque segment et de celle de tout les
segments. (Les notifications (ACK) utilisent des numros de squence mais
ne sont pas elle meme notifi). Cette fiabilit rend le TCP plus difficile 
duper que l'IP.


        --[ Numro de squence (SEQ), Notification (ACK) et autre flags ]--


        Puisque TCP est fiable, il doit etre capable de s'y retrouver parmis
les donnes perdues, dupliques ou invalides. En assignant un numro de
squence  chaque octet transfr, et en requirant une notification de
l'autre hote  la rception, TCP peut garantir une livraison fiable. Le
recepteur utilise les numros de squence pour s'assurer de l'ordre correct
des donnes et liminer les donnes dupliques.
        Les numros de squence 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 squenc. Le champ de numro de squence dans le header TCP contiendra
donc le numro de squence du *premier* octet du segment de donne du paquet.
Le champs du numro de notification (ACK)  contient la valeur du numro
de notification du prochain paquet *attendu*, et galement atteste que *toutes*
les donnes sont ok  travers ce numro 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 donne 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
numro le plus leves qu'un numro de squence peut avoir.
        Les autres flags de l'en-tete TCP  remarquer sont RST (reset),
PSH (push), et FIN (finish). Si un RST est reu, la connexion est
immdiatement arreter. RSTs sont normalement envoy quand une machine reoit
un segment qui ne correspond pas  la connexion en cour (nous rencontrerons
ce cas dans exemples plus loin). Le flag PSH dit au rcepteur de passer les
donnes  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 reoit un
FIN, il lui renvoie un ACK (notification), et n'attend plus aucune donnes
(l'envoie est quand meme encore possible).


        --[ Etablissement d'une connexion TCP ]--

        Pour changer des donnes 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 littrale : la poigne de
mains en 3 tapes). Si la machine A fait tourner un client rlogin et
veut se connecter  un dmon rlogin de la machine B, cela se fera
sur le modle 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 numro de squence
fournit est valide, et doit etre vrifi. Le client mettra son ISN (initial
sequence number) dans le champs de numro de squence. Le serveur, aprs la
rception de ce segment (2) rpondra par son propre ISN (donc le flag SYN est
mis  1) et il notifie (flag ACK mit  un) de la rception du premier segment
du client (ISN du client + 1). Puis le client renvoie une notification ACK
(NDT : je dirais maintenant seulement ACK) par le numro ISN du serveur (3).
A prsent, le transfert de donnes peut etre effectu.


        --[ L'ISN et l'Incrmentation du Numro de Squence ]--


        Il est important de comprendre comment les numros de squences
sont initialement choisi, et comment ils changent en fonction du temps.
Le numro de squence initial, quand un hote est mis en service, est
initialise  1. (TCP nomme en fait cette variable 'tcp_iss' comme le
numro de squence d'*envoie* initial (initial *send* sequence number).
L'autre variable de numro de squence est 'tcp_irs' qui est le numro
de squence de *rception* 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 prcis dans un commentaire de la
fonction tcp_init() (NDT : ???). Le numro ISN est incrmente 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 incrment de 64.000.
        Une raison importante de cette prdictabilit est pour mimiser les
chance que des donnes provenant d'une vieille incarnation prime (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 dpasse le but de cet article. Si les numros de squence
taient choisi au hasard quand une connexion se met en place alors rien ne
garantirait que les numros de squenve devrait etre diffrent des connexions
prcdentes. Si certaines donnes restaient colles dans une boucle de routage
quelque part et se libraient plus tard pour arriver pendant une nouvelle
connexion du meme type (ie meme port/ip), cela pourrait rellement faire tout
planter.


        --[ Ports ]--


        Pour garantir un accs simultane au module TCP, TCP fournit une
interface utilisateur appele port. Les ports sont utiliss par le noyau
pour identifier les processus rseau. 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 rseaux. En fait,
 tout moment, *toutes* les connexions Internet peuvent etre dcrites par 4
chiffres : l'adresse IP source, le port source, l'adresse IP de destination et
le port de destination. Les (logiciels) serveurs sont 'lies' aux ports
'bien-connus' et donc peuvent etre localis sur les ports standard sur 
diffrents systmes. Par exemple, le dmon 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 diffrentent tapes, qui sont rapidement
dcrites ici, puis expliques en dtails. D'abord, la victime est choisie.
Puis, un type de confiance est dcouvert, authorisant certains hotes. L'hote
 qui la victime fait confiance est dconnect, et les numros de squences
TCP de la victime sont analyses. L'identit de l'hote de confiance est usurp,
les numros de squence devins, et une tentative de connexion est ralis
sur un service qui se fie seulement  l'adresse IP. Dans le cas d'un succs,
l'attaquant excute une simple commande pour laisser une backdoor.


        --[ Choses utiles ]--


        Il y a une sries de choses dont vous aurez besoins pour mettre en
place cette attaque (NDT : j'ai pas commpris  quoi correspondait sa 
numrotation) :

                (1) Un cerveaux, un esprit, ou tout autre priphrique
                                             de rflexion
                (1) Une victime
                (1) Un hote de confiance
                (1) Une machine d'attaque (avec un accs root)
                    (NDT : norm, ta unix box (Linux, FreeBSD ou tout autre
                     grille-pain fournissant un accs raw sockets).
                (1) Un logiciel d'IP-spoofing

En gnral, 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 problmes, il serait stupide de ne pas le faire pour avoir
le root (Bien que l'accs root et ncessaire pour russir cette attaque,
elle n'en est pas ncessairement 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 djou la scurit
de la victime. On rend l'hote de confiance incapable de ralise la
mthode dcrite plus loin. Tant que la victime le croie, elle entretient
une conversation avec un parti de confiance. En ralit, l'attaquant est
assis dans certains coins sombre de l'Internet, frabriquant ses paquets
supposs 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 supposs aller  l'hote de confiance. Autant que la
couche rseau le sachent, c'est de la d'o ils viennent, et c'est l o les
rponsent doivent etre envoys. Bien sur, une fois que les datagrammes sont
rout  leur destination, et atteigne la couche TCP, il sont supprims
(l'hote de confiance ne peut rpondre - voir plus loin). Donc l'attaquant
doit etre malin et *savoir* ce qui a t envoy, et quel rponse le serveur
attend. L'attaquant ne peut pas voir ce que l'hote  envoyer, mais il peut
*prdire* 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 ]--


        Aprs qu'une cible a t choisie, l'attaquant doit dterminer
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
systmes de fichiers sont exports, et un rpcinfo peut galement donns
des informations interessantes. Si suffisamment d'information sont rcuprs
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.


        --[ Dconnecter les hotes de confiance part un SYN flood ]--


        Une fois que l'hote de confiance est trouv, il doit etre
dconnecter. 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 rseau
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 spcifique  l'OS de l'hote).
        Une connexion TCP est initialise par une requete au serveur avec
le flag SYN dans l'header TCP. Normalement le serveur doit rpondre 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 donnes peut commencer. Il y a une limite aux
nombres de requete SYN TCP peut grer for une socket donne. Cette limite
est apele le backlog, et est la taille de la queue o sont stock les
connexions rentrantes (et donc incompltes). Cette limite de queue s'applique
aussi bien aux nombres de connexions incompltes (le processus en 3 tapes
n'est pas fini) qu'aux nombres de connexions compltes qui n'ont pas t
sortit de la queue par l'application par le biais du signale systme accept().
Si ce backlog est atteint, TCP refuse tout nouveau paquet SYN jusqu'
ce que les connexions en attentes puissent etre gres. A partir de l
l'attaque  russi.
        L'attaquant envoie plusieurs requete SYN au port TCP qu'il veut
dsactiver. L'hote d'attaque doit aussi etre sur que l'adresse IP source
est fausse, spoof d'un autre hote actuellement dsactiv (La victime 
rpondra  cette adresse. IP informera TCP que l'hote est injoignable,
mais TCP considre ces erreurs comme temporaire, laisse IP les rsoudre
(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 rsulterait 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
rpond par des SYN/ACKs  ce qu'il croit etre la source des SYNs.
Pendant ce temps tout autre connexion  ce port sera ignor.
        Les implmentations TCP diffrentes ont des tailles de backlog
diffrentes. BSD a en gnral 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 dfinitif sur le sujet. Cela couvre
le processus en dtail, aussi bien en thorie 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 prdiction des numros de squence ]--


        A prsent, l'attaquant a besoin de se faire une ide sur
la situation du numro de squence 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 rpt plusieurs fois et l'ISN final envoy est
sauvegard. L'attaquant a besoin de ce faire une ide sur la gueule du
RTT (round-trip time) entre la cible et sa machine. (Le processus peut
etre rpt plusieurs fois et la valeur moyenne du RTT calcul). Le RTT
est ncessaire pour etre capable de prdire le prochain ISN. L'attaquant
possde maintenant les bases (le dernier ISN envoy) et sait de combien
le numro de squence est incrment (128.000/seconde et 64.000 par connexion)
et a maintenant une bonne ide 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 symtriques). Aprs que l'attaquant ait en
sa possession ces informations, il peut immdiatement procder  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 prdit par
l'attaquant sera diffrent de 64.000 par rapport  l'ISN rel).
        Quand le segment spoof a fait son chemin vers la cible,
plusieur choses peuvent se passer :
- Si le numro de squence est EXACTEMENT celui que TCP esperait
qu'il soit, les donnes seront plac sur la place suivante disponible
dans le buffer de rception.
- Si le numro de squence est PLUS PETIT que la valeur voulue, les
donnes seront considrs comme une retransmission et seront ignor.
- Si le numro de squence et PLUS GRAND que la valeur voulue mais
quand meme dans les limites de la taille de fenetre, les donnes
seront considrs comme des donnes  venir aprs, et gards par TCP,
attendant l'arrive des donnes manquante. Si un segment arrive
avec un numro de squence 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 numro de squence
*voulu*.


        --[ Tromper... ]--


        A ce momment commence l'essentiel de l'attaque par derrire 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 diffrent
comme NFS). En (2), la victime rpond  la requete de connexion spoofe par
un SYN/ACK, qui fera son chemin jusqu' l'hote de confiance (qui s'il
*pouvait* s'occuper des segments TCP entrant, considrerait ce segment comme
une erreur, en enverrait immdiatement un RST  la cible). Si tout ce passe
comme prvu, le SYN/ACK sera ignor par l'hote de confiance dbord. Aprs (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 numro de squence prdit (plus un, car
nous le notifions (ACK)). Si l'attaquant a bien prdit l'ISN, la victime
acceptera l'ACK. La cible est alors compromise et le transfert de donnes peut
commencer (4).
        En gnral, aprs 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 ide 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
rponse seront envoy vers l'oubli).


        --[ Pourquoi a marche ? ]--


        L'IP-Spoofing marche parce que les services bass sur des relations
de confiance repose sur une identification par adresse rseau. Comme IP est
facile  tromper, la modification des adresses n'est pas difficile. Le plus
difficile dans l'attaque est la prdiction du numro de squence, car c'est
ici qu'entre en jeu le travail de prdiction. Rduire les inconnues et
la prdiction au minimum, et l'attaque aura de meilleur chance de russir.
Meme une machine qui grerai toute les connexions TCP entrante avec le TCP
wrappers de Wietse Venema serait encore vulnrable  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 prvenir cette attaque est de ne pas
utiliser d'authentification par adresse. De dsactiver 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'accs
(telnet, ssh, skey, etc).


        --[ Filtrage des paquets ]--


        Si votre site possde une connexion directe  l'Internet,
vous pouvez utilisez les routeurs pour vous aidez. D'abord assurez-vous
que seul les hotes du rseau interne peuvent participer  des relations
de confiance (aucun hote du rseau 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'intrieur (rseau
interne).


        --[ Mthodes Cryptographiques ]--


        Une mthode trivial pour empcher l'IP-spoofing est de requerir
que tout le traffic du rseau soit encrypte 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 numros de squence ne sont pas choisi alatoirement
(ou incrment alatoirement), cette attaque fonctionne. Bellovin a dcrit
une correction pour TCP qui consiste en la sparation des espaces de numro
de squence. Chaque connexion aura son propre espace de numro de squence.
Le numro de squence sera encore incrment comme auparavant, mais il n'y
aura plus de relation entre les numrotations des diffrent 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'extrieur ou l'attaquant pourrait
encore devin les numros de squence. Bellovin suggre 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.

-------[  EOF