Backups/hping3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
906782e134452cf0f8a1c98477b4284b6818446d
hping3/docs/french/HPING2-HOWTO.txt

476 lines
22 KiB
Plaintext
Raw Normal View History

first draft
2022-04-13 18:01:39 +08:00
N.B. : ce HOWTO n'est pas termin<69>, et par endroits tr<74>s b<>te. Je laisse cela
ici seulement parce que peut <20>tre que c'est mieux que rien.
HPING2 HOWTO
Changes Log
-----------
Aug 7 1999 vi HPING2-HOWTO.txt
Aug 8 1999 __0000, __0001, __0002, __0003
Aug 10 1999 __0004
Index
-----
[cherchez __XXXX afin de sauter au point que vous souhaitez]
__0000: Avis de copyright
__0001: Qu'est ce que hping ?
__0002: Qu'est ce que j'ai besoin de conna<6E>tre de TCP/IP pour
utiliser hping ?
__0003: Premiers pas avec hping
__0004: Le champ IP id et comment scanner des ports TCP en utilisant
de l'usurpation d'adresse.
__0005: Comment tester des r<>gles de filtrage. (A faire)
__0006: Comment transf<73>rer des fichier au travers de firewalls. (A
faire)
__000A: Exemple d'utilisation de hping (A faire)
__0000: Avis de copyright, Licence, et tout ce genre de choses
Copyright (C) Salvatore Sanfilippo, 1999.
La permission est accord<72>e de faire et distribuer des copies de ce manuel
<20> condition que l'avis de copyright et cet avis de permission soient
pr<70>serv<72>s sur toutes les copies.
Permission est accord<72>e de copier et distribuer des versions modifi<66>es de
ce manuel sous les conditions de copie verbatim, <20> condition que le
travail d<>riv<69> soit distribu<62> sous les termes d'un avis de permission
identique <20> celui-ci. Les traductions tombent dans la cat<61>gorie des
''versions modifi<66>es.''
Garantie : Aucune.
Recommandations : les redistributions commerciales sont autoris<69>es et
encourag<61>es; cependant, il est fortement recommand<6E> que le redistributeur
contacte l'auteur avant redistribution, dans l'int<6E>r<EFBFBD>t de garder les
choses <20> jour (vous pouvez m'envoyer une copie de ce que vous faites
pendant que vous y <20>tes). Les traducteurs sont <20>galement encourag<61>s <20>
contacter l'auteur avant traduction. Le version imprim<69>e aura plus
d'allure.
Recyclez.
__0001 : Qu'est ce que hping ?
Hping est un logiciel pour tester des piles TCP/IP, pour d<>couvrir des
politiques de firewalls, pour scanner les ports TCP de nombreuses mani<6E>res
diff<66>rentes, pour transf<73>rer les fichiers au travers de firewalls et
beaucoup d'autres choses. En utilisant hping vous pouvez m<>me faire
beaucoup de choses qui ne concernent pas la s<>curit<69>. Par exemples vous
pouvez tester les performances r<>seau, v<>rifier si un syst<73>me tourne,
v<>rifier si le champ TOS est g<>r<EFBFBD>, etc.
__0002 : Qu'est ce que j'ai besoin de conna<6E>tre de TCP/IP pour utiliser
hping ?
Si vous connaissez TCP/IP vous trouverez hping tr<74>s utile, sinon vous
pouvez utiliser hping seulement pour faire des tests connus. Voir __000A
pour quelques exemples.
__0003 : Premiers pas avec hping
La plus simple utilisation de hping est la suivante :
#hping host
Cette commande envoie un paquet TCP sans drapeau au port 0 du syst<73>me
cible chaque seconde et montre les r<>ponses du syst<73>me. Par exemple :
# hping www.debian.org
ppp0 default routing interface selected (according to /proc)
HPING www.debian.org (ppp0 209.81.8.242): NO FLAGS are set, 40 headers + 0 data bytes
40 bytes from 209.81.8.242: flags=RA seq=0 ttl=243 id=63667 win=0 time=369.4 ms
40 bytes from 209.81.8.242: flags=RA seq=1 ttl=243 id=63719 win=0 time=420.0 ms
40 bytes from 209.81.8.242: flags=RA seq=2 ttl=243 id=63763 win=0 time=350.0 ms
[Ctrl+C]
--- www.debian.org hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
Comme vous pouvez le voir le syst<73>me r<>pond avec un paquet TCP avec les
drapeaux RST et ACK positionn<6E>s. Ainsi vous <20>tes capable d'effectuer un
'ping TCP', utile quand ICMP est filtr<74>. Par d<>faut le port 0 est utilis<69>
parce qu'il serait <20>trange qu'il soit <20> l'<27>tat LISTEN (ndt : en <20>coute).
Si nous envoyons un paquet TCP sans drapeau <20> un port <20> l'<27>tat LISTEN, de
nombreuses piles TCP/IP ne renverront pas de r<>ponse. Ainsi nous sommes
capables de savoir si un port est dans l'<27>tat LISTEN. Par exemple :
# hping www.debian.org -p 80
ppp0 default routing interface selected (according to /proc)
HPING www.debian.org (ppp0 209.81.8.242): NO FLAGS are set, 40 headers + 0 data bytes
[Ctrl+C]
--- www.debian.org hping statistic ---
5 packets trasmitted, 0 packets received, 100% packet loss
Puisque le port 80 de www.debian.org est en mode LISTEN nous n'obtenons
aucune r<>ponse.
Mais qu'arrive-t-il si nous essayons de 'hpinger' un port bloqu<71> par un
firewall ? Cela d<>pend de la politique / configuration du firewall.
Habituellement nous obtenons un paquet ICMP ou rien. Par exemple :
# hping www.yahoo.com -p 79
ppp0 default routing interface selected (according to /proc)
HPING www.yahoo.com (ppp0 204.71.200.67): NO FLAGS are set, 40 headers + 0 data bytes
ICMP Packet filtered from 206.132.254.41 (pos1-0-2488M.hr8.SNV.globalcenter.net)
--- www.yahoo.com hping statistic ---
14 packets tramitted, 0 packets received, 100% packet loss
Le firewall de yahoo ne permet pas de connexion sur le port 79, donc il
r<>pond avec un paquet ICMP Packet filtered (ICMP unreachable code 13).
Cependant il y a beaucoup de firewalls qui ignorent simplement le paquet.
Par exemple :
# hping www.microsoft.com -p 79
ppp0 default routing interface selected (according to /proc)
HPING www.microsoft.com (ppp0 207.46.130.150): NO FLAGS are set, 40 headers + 0 data bytes
--- www.microsoft.com hping statistic ---
4 packets tramitted, 0 packets received, 100% packet loss
Aucune r<>ponse de microsoft. Est-ce que le port est bloqu<71> ou en mode
LISTEN ? D<>couvrir cela est tr<74>s simple. Nous essayons juste de mettre le
drapeau ACK au lieu d'envoyer un paquet TCP sans drapeau. Si le syst<73>me
r<>pond, peut-<2D>tre que ce port est en mode LISTEN (mais il est possible
qu'il y ait une r<>gle qui refuse les paquets TCP sans drapeau mais
autorise les paquets ACK).
# hping www.microsoft.com -A -p 79
ppp0 default routing interface selected (according to /proc)
HPING www.microsoft.com (ppp0 207.46.130.149): A set, 40 headers + 0 data bytes
--- www.microsoft.com hping statistic ---
3 packets tramitted, 0 packets received, 100% packet loss
Toujours pas de r<>ponse, ainsi ce port semble <20>tre filtr<74>. Quoi qu'il en
soit, il est possible que microsoft utilise un firewall 'intelligent' qui
sait que pour me connecter je dois d'abord envoyer un paquet SYN.
# hping www.microsoft.com -S -p 79
ppp0 default routing interface selected (according to /proc)
HPING www.microsoft.com (ppp0 207.46.130.149): S set, 40 headers + 0 data bytes
--- www.microsoft.com hping statistic ---
3 packets tramitted, 0 packets received, 100% packet loss
Ok.. il semble que le port 79 de microsoft est r<>ellement filtr<74>.
Pour clarification nous envoyons quelques paquets ACK au port 80 de
www.debian.org :
# hping www.debian.org -p 80 -A
ppp0 default routing interface selected (according to /proc)
HPING www.debian.org (ppp0 209.81.8.242): A set, 40 headers + 0 data bytes
40 bytes from 209.81.8.242: flags=R seq=0 ttl=243 id=5590 win=0 time=379.5 ms
40 bytes from 209.81.8.242: flags=R seq=1 ttl=243 id=5638 win=0 time=370.0 ms
40 bytes from 209.81.8.242: flags=R seq=2 ttl=243 id=5667 win=0 time=360.0 ms
--- www.debian.org hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
Nous pouvons voir les r<>ponses m<>me si le port 80 est en mode LISTEN parce
qu'un port en mode LISTEN ne devrait pas r<>pondre <20> des paquets TCP avec
seulement un drapeau NULL, FIN, Xmas, ou Ymas. ACK et RST sont deux
drapeaux TCP importants qui permettent de tester des ACL (ndt : listes de
contr<74>le d'acc<63>s) et de deviner le champ ip->id en ne laissant pas de
trace dans les journaux (g<>n<EFBFBD>ralement).
__0004 : Le champ IP id et comment scanner des ports TCP en utilisant de
l'usurpation d'adresse.
Chaque paquet IP est identifi<66> par un champ id de 16 bits. Gr<47>ce <20> ce
champ id les piles IP sont capables de g<>rer la fragmentation. De nombreux
OS traitent ip->id trivialement : incr<63>menter ce champ de 1 champ pour
chaque paquet envoy<6F>. En utilisant ce champ id vous <20>tes au minimum
capable d'estimer le trafic et de scanner en usurpant l'adresse source.
OpenBSD >= 2.5 et beaucoup d'autres mettent en oeuvre un champ id
al<61>atoire non r<>p<EFBFBD>titif ainsi vous ne pouvez pas jouer avec le champ
ip->id. Le champ ip->id des syst<73>mes Windows n'est pas positionn<6E> dans le
m<>me ordre (ndt : dans le bon ordre), donc vous devez sp<73>cifier l'option
--winid ou -W si vous utilisez hping2 contre un syst<73>me Windows.
N.B. : Vous <20>tes capable de scanner un syst<73>me avec un champ ip->id
s<>re/al<61>atoire parce que pour spoofer vos paquets vous avez besoin
d'un syst<73>me tiers avec un champ id incr<63>mental, mais vous n'avez
pas besoin que la cible de votre scan ait un champ id incr<63>mental.
Comment estimer le trafic d'un syst<73>me en utilisant le champ ip->id ?
C'est vraiment tr<74>s simple :
# hping www.yahoo.com -p 80 -A
ppp0 default routing interface selected (according to /proc)
HPING www.yahoo.com (ppp0 204.71.200.74): A set, 40 headers + 0 data bytes
40 bytes from 204.71.200.74: flags=R seq=0 ttl=53 id=29607 win=0 rtt=329.4 ms
40 bytes from 204.71.200.74: flags=R seq=1 ttl=53 id=31549 win=0 rtt=390.0 ms
40 bytes from 204.71.200.74: flags=R seq=2 ttl=53 id=33432 win=0 rtt=390.0 ms
40 bytes from 204.71.200.74: flags=R seq=3 ttl=53 id=35368 win=0 rtt=380.0 ms
40 bytes from 204.71.200.74: flags=R seq=4 ttl=53 id=37335 win=0 rtt=390.0 ms
40 bytes from 204.71.200.74: flags=R seq=5 ttl=53 id=39157 win=0 rtt=380.0 ms
40 bytes from 204.71.200.74: flags=R seq=6 ttl=53 id=41118 win=0 rtt=370.0 ms
40 bytes from 204.71.200.74: flags=R seq=7 ttl=53 id=43330 win=0 rtt=390.0 ms
--- www.yahoo.com hping statistic ---
8 packets tramitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 329.4/377.4/390.0 ms
Comme vous pouvez le voir le champ id augmente. Le paquet avec le num<75>ro
de s<>quence 0 poss<73>de un champ id <20>gal <20> 29607, le num<75>ro 1 <20> 31549, ainsi
le syst<73>me www.yahoo.com a envoy<6F> 31549-29607 = 1942 paquets en environ
une seconde. En utilisant l'option -r ou --relid, hping affiche le delta
entre les champs id des deux derniers paquets re<72>us.
# hping www.yahoo.com -P 80 -A -r
ppp0 default routing interface selected (according to /proc)
HPING www.yahoo.com (ppp0 204.71.200.68): A set, 40 headers + 0 data bytes
40 bytes from 204.71.200.68: flags=R seq=0 ttl=53 id=65179 win=0 rtt=327.1 ms
40 bytes from 204.71.200.68: flags=R seq=1 ttl=53 id=+1936 win=0 rtt=360.0 ms
40 bytes from 204.71.200.68: flags=R seq=2 ttl=53 id=+1880 win=0 rtt=340.0 ms
40 bytes from 204.71.200.68: flags=R seq=3 ttl=53 id=+1993 win=0 rtt=330.0 ms
40 bytes from 204.71.200.68: flags=R seq=4 ttl=53 id=+1871 win=0 rtt=350.0 ms
40 bytes from 204.71.200.68: flags=R seq=5 ttl=53 id=+1932 win=0 rtt=340.0 ms
40 bytes from 204.71.200.68: flags=R seq=6 ttl=53 id=+1776 win=0 rtt=330.0 ms
40 bytes from 204.71.200.68: flags=R seq=7 ttl=53 id=+1749 win=0 rtt=320.0 ms
40 bytes from 204.71.200.68: flags=R seq=8 ttl=53 id=+1888 win=0 rtt=340.0 ms
40 bytes from 204.71.200.68: flags=R seq=9 ttl=53 id=+1907 win=0 rtt=330.0 ms
--- www.yahoo.com hping statistic ---
10 packets tramitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 320.0/336.7/360.0 ms
<20>videmment si on v<>rifie le champ id toutes les demi-secondes plut<75>t que
toutes les secondes, l'incr<63>ment sera diminu<6E> de moiti<74>.
# hping www.yahoo.com -P 80 -A -r -i u 500000
ppp0 default routing interface selected (according to /proc)
HPING www.yahoo.com (ppp0 204.71.200.68): A set, 40 headers + 0 data bytes
40 bytes from 204.71.200.68: flags=R seq=0 ttl=53 id=35713 win=0 rtt=327.0 ms
40 bytes from 204.71.200.68: flags=R seq=1 ttl=53 id=+806 win=0 rtt=310.0 ms
40 bytes from 204.71.200.68: flags=R seq=2 ttl=53 id=+992 win=0 rtt=320.0 ms
40 bytes from 204.71.200.68: flags=R seq=3 ttl=53 id=+936 win=0 rtt=330.0 ms
40 bytes from 204.71.200.68: flags=R seq=4 ttl=53 id=+987 win=0 rtt=310.0 ms
40 bytes from 204.71.200.68: flags=R seq=5 ttl=53 id=+952 win=0 rtt=320.0 ms
40 bytes from 204.71.200.68: flags=R seq=6 ttl=53 id=+918 win=0 rtt=330.0 ms
40 bytes from 204.71.200.68: flags=R seq=7 ttl=53 id=+809 win=0 rtt=320.0 ms
40 bytes from 204.71.200.68: flags=R seq=8 ttl=53 id=+881 win=0 rtt=320.0 ms
--- www.yahoo.com hping statistic ---
9 packets tramitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 310.0/320.8/330.0 ms
N.B. Attention, en utilisant ip->id vous n'<27>tes capable que d'estimer *le
nombre de paquets envoy<6F>s/unit<69> de temps*. Vous ne pouvez pas
toujours comparer diff<66>rents syst<73>mes. Le champ ip->id concerne
toutes les interfaces d'un syst<73>me et par exemple si un syst<73>me
utilise de la traduction d'adresse ou redirige les connexions TCP
vers un autre syst<73>me (par exemple un firewall utilis<69> pour cacher un
serveur web) l'incr<63>ment du champ ip->id peut r<>sulter en de fausses
augmentations.
En 'hpingant' les boites windows sans utiliser l'option --winid vous
verrez que les incr<63>ment sont des multiples de 256 <20> cause d'un ordre des
octets invers<72>. Ceci peut <20>tre r<>ellement utile pour d<>terminer le type
d'OS.
#hping win95 -r
HPING win95 (eth0 192.168.4.41): NO FLAGS are set, 40 headers + 0 data bytes
46 bytes from 192.168.4.41: flags=RA seq=0 ttl=128 id=47371 win=0 rtt=0.5 ms
46 bytes from 192.168.4.41: flags=RA seq=1 ttl=128 id=+256 win=0 rtt=0.5 ms
46 bytes from 192.168.4.41: flags=RA seq=2 ttl=128 id=+256 win=0 rtt=0.6 ms
46 bytes from 192.168.4.41: flags=RA seq=3 ttl=128 id=+256 win=0 rtt=0.5 ms
--- win95 hping statistic ---
4 packets tramitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.5/0.6 ms
Les syst<73>mes windows sont "marqu<71>s", ainsi pour d<>couvrir si un syst<73>me
est un Windows vous avez juste besoin d'envoyer quelques paquets.
Comment effectuer des scans SYN spoof<6F>s en utilisant un champ id incr<63>mental
? Ce qui suit est le message original (ndt : du moins sa traduction) <20>
bugtraq <20> propos de la m<>thode de scan usurp<72>e/indirecte/passive, dessous
j'essayerai d'expliquer les d<>tails et comment cela est possible m<>me avec
UDP avec quelques restrictions.
---- le postage <20> bugtraq <20> propos des scans usurp<72>s ----
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
---- EOF ----
Comme vous pouvez le voir un scan usurp<72> est trivial <20> r<>aliser,
particuli<6C>rement en utilisant hping2 vous <20>tes capable de sp<73>cifier un
intervalle en micro secondes (-i uX) ainsi vous n'avez pas besoin que le
syst<73>me B soit un syst<73>me totalement passif. Vous pouvez lire l'incr<63>ment
du champ id une fois toutes les secondes en envoyant 10 paquets SYN par
seconde. Si vous envoyez un nombre ad<61>quat de paquets SYN par seconde,
l'incr<63>ment du champ id attendu est si important que vous <20>tes <20> m<>me de
voir si le port est ouvert ou ferm<72> m<>me si le syst<73>me B envoie d'autres
paquets. Exemple :
# hping awake.host.org -p 80 -A -r
ppp0 default routing interface selected (according to /proc)
HPING server.alicom.com (ppp0 111.222.333.44): A set, 40 headers + 0 data bytes
40 bytes from 111.222.333.44: flags=R seq=0 ttl=249 id=47323 win=0 rtt=239.7 ms
40 bytes from 111.222.333.44: flags=R seq=1 ttl=249 id=+6 win=0 rtt=630.0 ms
40 bytes from 111.222.333.44: flags=R seq=2 ttl=249 id=+6 win=0 rtt=280.0 ms
40 bytes from 111.222.333.44: flags=R seq=3 ttl=249 id=+8 win=0 rtt=340.0 ms
40 bytes from 111.222.333.44: flags=R seq=4 ttl=249 id=+5 win=0 rtt=440.0 ms
40 bytes from 111.222.333.44: flags=R seq=5 ttl=249 id=+5 win=0 rtt=410.0 ms
40 bytes from 111.222.333.44: flags=R seq=6 ttl=249 id=+8 win=0 rtt=1509.9 ms
40 bytes from 111.222.333.44: flags=R seq=7 ttl=249 id=+4 win=0 rtt=1460.0 ms
40 bytes from 111.222.333.44: flags=R seq=8 ttl=249 id=+7 win=0 rtt=770.0 ms
40 bytes from 111.222.333.44: flags=R seq=9 ttl=249 id=+5 win=0 rtt=230.0 ms
...
comme vous pouvez le voir, ce syst<73>me n'est pas inactif, il envoie environ
6 paquets chaque seconde. Maintenant scannez le port 80 de www.yahoo.com
pour voir s'il est ouvert :
root.1# hping -a server.alicom.com -S -p 80 -i u10000 www.yahoo.com
ppp0 default routing interface selected (according to /proc)
HPING www.yahoo.com (ppp0 204.71.200.74): S set, 40 headers + 0 data bytes
[attendre quelques secondes et presser CTRL+C]
--- www.yahoo.com hping statistic ---
130 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
En observant la sortie de 'hping awake.host.org -p 80 -A -r' il est
simple de comprendre que le port 80 de www.yahoo.com est ouvert :
40 bytes from 111.222.333.44: flags=R seq=59 ttl=249 id=+16 win=0 rtt=380.0 ms
40 bytes from 111.222.333.44: flags=R seq=60 ttl=249 id=+75 win=0 rtt=850.0 ms
40 bytes from 111.222.333.44: flags=R seq=61 ttl=249 id=+12 win=0 rtt=1050.0 ms
40 bytes from 111.222.333.44: flags=R seq=62 ttl=249 id=+1 win=0 rtt=450.0 ms
40 bytes from 111.222.333.44: flags=R seq=63 ttl=249 id=+27 win=0 rtt=230.0 ms
40 bytes from 111.222.333.44: flags=R seq=64 ttl=249 id=+11 win=0 rtt=850.0 ms
notez que 16+75+12+27+11+1-6 = 136 et que nous avons envoy<6F> 130 paquets.
Ainsi il est tr<74>s probable que les incr<63>ments soient produits par nos
paquets.
Conseil : en utilisant un syst<73>me inactif pour r<>aliser un scan usurp<72> il
est utile de ne montrer que les r<>ponses qui montrent un
incr<63>ment diff<66>rent de 1. Essayez
`hping host -r | grep -v "id=+1"'
Reference in New Issue Copy Permalink