hping3/docs/french/SPOOFED_SCAN.txt

Ce qui suit est le postage original (ndt : du moins sa traduction) <20> bugtraq
<EFBFBD> propos de la m<>thode de scan usurp<72>e/passive/indirecte. Voir le fichier
HPING2-HOWTO pour plus d'informations.

antirez

---

  Salut,

        J'ai d<>couvert une nouvelle m<>thode de scan de ports TCP.  Au
        contraire de toutes les autres elle vous permet de scanner en
        utilisant des paquets usurp<72>s (ndt : dont l'adresse IP source est
        usurp<72>e), ainsi les syst<73>mes scann<6E>s ne peuvent pas voir votre
        adresse r<>elle. Afin de r<>aliser cela j'utilise trois particularit<69>s
        bien connues des mises en oeuvre TCP/IP de la plupart des OS.

          (1) * les syst<73>mes r<>pondent SYN|ACK <20> SYN si le port TCP cible
            est ouvert, et RST|ACK si le port TCP cible est ferm<72>.

          (2) * Vous pouvez conna<6E>tre le nombre de paquets que les syst<73>mes
            envoient en utilisant le champ id de l'ent<6E>te IP. Voir mes
            pr<70>c<EFBFBD>dents postages '<27> propos de l'ent<6E>te IP' dans cette mailing
            liste.

          (3) * les syst<73>mes r<>pondent RST <20> SYN|ACK, ne r<>pondent rien <20>
            RST.


        Les joueurs:

          syst<73>me A - le syst<73>me malfaisant, l'attaquant.
          syst<73>me B - le syst<73>me silencieux.
          syst<73>me C - le syst<73>me victime.

        A est votre syst<73>me.
        B est un syst<73>me particulier : il ne doit envoyer aucun paquet
         pendant que vous scannez C. Il y a <20>norm<72>ment de syst<73>mes <20> 'trafic
         nul' sur Internet, sp<73>cialement la nuit :)
        C est la victime, il doit <20>tre vuln<6C>rable aux scans SYN.

        J'ai appel<65> cette m<>thode de scan 'scan du syst<73>me muet' (ndt :
        l'autre traduction de 'dumb' est b<>te) en r<>f<EFBFBD>rence aux
        caract<63>ristiques du syst<73>me B.


        Comment elle fonctionne :

        Le syst<73>me A surveille le nombre de paquets sortants depuis B en
        utilisant le champ id de l'ent<6E>te IP. Vous pouvez faire ceci
        simplement en utilisant hping :

#hping B -r
HPING B (eth0 xxx.yyy.zzz.jjj): no flags are set, 40 data bytes
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=0 ttl=64 id=41660 win=0 time=1.2 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=1 ttl=64 id=+1 win=0 time=75 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=2 ttl=64 id=+1 win=0 time=91 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=3 ttl=64 id=+1 win=0 time=90 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=4 ttl=64 id=+1 win=0 time=91 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=5 ttl=64 id=+1 win=0 time=87 ms
-cut-
..
.

        Comme vous pouvez le voir, les incr<63>ments du champ id sont toujours
        de 1. Ainsi ce syst<73>me a la caract<63>ristique requise pour jouer le
        r<>le de B.

        Maintenant le syst<73>me A envoie des paquets SYN au port X de C en
        usurpant l'adresse source de B.
        (avec hping => 0.67 c'est tr<74>s facile, http://www.kyuzz.org/antirez)
        si le port X de C est ouvert, le syst<73>me C enverra SYN|ACK <20> B (oui,
        le syst<73>me C ne sait pas que le v<>ritable exp<78>diteur est A). Dans ce
        cas le syst<73>me B r<>pond au SYN|ACK avec un RST.
        Si nous envoyons au syst<73>me C quelques paquets SYN il r<>pondra <20> B
        quelques paquet SYN|ACK, ainsi B r<>pondra <20> C quelques RST... ainsi
        nous verrons que le syst<73>me B est en train d'envoyer des paquets !

.
..
-cut-
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=17 ttl=64 id=+1 win=0 time=96 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=18 ttl=64 id=+1 win=0 time=80 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=19 ttl=64 id=+2 win=0 time=83 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=20 ttl=64 id=+3 win=0 time=94 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=21 ttl=64 id=+1 win=0 time=92 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=22 ttl=64 id=+2 win=0 time=82 ms
-cut-
..
.

        Le port est ouvert !

        Par contre, si le port X de C est ferm<72> alors en envoyant <20> C
        quelques paquets SYN avec l'adresse usurp<72>e de B, il r<>pondra avec
        des paquets RST <20> B, et B ne r<>pondra pas (voir 3). Ainsi nous
        verrons que le syst<73>me B n'est en train d'envoyer aucun paquet :

.
..
-cut-
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=52 ttl=64 id=+1 win=0 time=85 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=53 ttl=64 id=+1 win=0 time=83 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=54 ttl=64 id=+1 win=0 time=93 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=55 ttl=64 id=+1 win=0 time=74 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=56 ttl=64 id=+1 win=0 time=95 ms
60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=57 ttl=64 id=+1 win=0 time=81 ms
-cut-
..
.

        Le port est ferm<72>.

        Tout ceci peut para<72>tre compliqu<71> <20> r<>aliser, mais utiliser deux
        sessions de hping dans des consoles virtuelles Linux ou sous X rend
        cela plus simple.
        La premi<6D>re session surveille le syst<73>me B : hping B -r
        La seconde session envoie des paquets SYN spoof<6F>s : hping C -a B -S

        D<>sol<6F> si mon anglais n'est pas clair.
        Cependant ce postage n'est pas ad<61>quat pour d<>crire exhaustivement
        cette m<>thode de scan, ainsi je vais <20>crire un article <20> ce sujet,
        en particulier comment mettre en oeuvre ceci dans un scanner de
        ports (i.e.  nmap), et <20> propos des caract<63>ristiques des joueurs et
        des OS utilis<69>s.

bonne nouvelle ann<6E>e,
antirez