Perplexité sur la vitesse de nmap

Le
Nina Popravka
Je l'utilise habituellement à partir de bécanes sous XP SP2, ça se
traîne, et j'ai toujours mis ça sur le compte de la limitation à 10
nouvelles connexions sortantes incomplètes par période de je sais plus
combien
<http://technet.microsoft.com/en-us/library/bb457156.aspx#EHAA>
(oui, je sais, y a un patch, mais je ne patche pas mes couches IP avec
un truc venant de je sais pas où)
et j'ai vécu avec en pestant un peu.

Là, en scannant un ubuntu, je découvre avec stupéfaction que ça va à
la vitesse de l'éclair.
Illustration (le premier scan concerne un Ubuntu, le deuxième un Mac
sous MacOSX, tout le monde est sur le même LAN, en ethernet, et à
moins d'un mètre de moi) :

C:Program FilesNmap>nmap -p1-65535 192.168.100.52

Starting Nmap 4.22SOC2 ( http://insecure.org ) at 2007-11-09 11:36
Paris, Madrid

Interesting ports on 192.168.100.52:
Not shown: 65524 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
2000/tcp open callbook
2049/tcp open nfs
7001/tcp open afs3-callback
36324/tcp open unknown
48095/tcp open unknown
53193/tcp open unknown
MAC Address: 00:10:DC:92:F5:A6 (Micro-star International CO.)

Nmap finished: 1 IP address (1 host up) scanned in 4.516 seconds

C:Program FilesNmap>nmap -p1-65535 192.168.100.53

Starting Nmap 4.22SOC2 ( http://insecure.org ) at 2007-11-09 11:37
Paris, Madrid

Interesting ports on 192.168.100.53:
Not shown: 65525 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
88/tcp open kerberos-sec
139/tcp open netbios-ssn
445/tcp open microsoft-ds
515/tcp open printer
548/tcp open afpovertcp
3031/tcp open unknown
5900/tcp open vnc
MAC Address: 00:0A:95:68:5E:CE (Apple Computer)

Nmap finished: 1 IP address (1 host up) scanned in 3100.718 seconds

4 secondes d'un côté, 3100 de l'autre, toutes choses égales par
ailleurs.
Pourquoiiiiiiiii ??????????????????
--
Nina
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
newsreader
Le #874632
Je l'utilise habituellement à partir de bécanes sous XP SP2, ça se
traîne, et j'ai toujours mis ça sur le compte de la limitation à 10
nouvelles connexions sortantes incomplètes par période de je sais plus
combien...
(oui, je sais, y a un patch, mais je ne patche pas mes couches IP avec
un truc venant de je sais pas où...)
....et j'ai vécu avec en pestant un peu.

Là, en scannant un ubuntu, je découvre avec stupéfaction que ça va à
la vitesse de l'éclair.
Illustration (le premier scan concerne un Ubuntu, le deuxième un Mac
sous MacOSX, tout le monde est sur le même LAN, en ethernet, et à
moins d'un mètre de moi) :

4 secondes d'un côté, 3100 de l'autre, toutes choses égales par
ailleurs.
Pourquoiiiiiiiii ??????????????????


Peut-être que la machine sous MacOSX a un comportement qui a pour
conséquence de nombreuses tentatives de la part de NMAP ou qu'il prend son
temps à répondre.
Vois si tu peux capturer ce qui sort de ta machine pour voir si dans les 2
cas ça se passe de la même manière.

Sinon, vois en limitant les timeouts et les réessais avec --max-retries,
--host-timeout et --max-scan-delay au mini partout si t'as toujours 3100
s...


Lolotte
--
(enlever pasdespam pour répondre)
http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups,
recherche whois, les codes postaux, des jeux et plein d'autres bêtises...

Hubert
Le #874631
Là, en scannant un ubuntu, je découvre avec stupéfaction que ça va à
la vitesse de l'éclair.
Illustration (le premier scan concerne un Ubuntu, le deuxième un Mac
sous MacOSX, tout le monde est sur le même LAN, en ethernet, et à
moins d'un mètre de moi) :


La présence d'un firewall qui envoie un reset à toute connexion non
autorisée au lieu d'attendre un timeout ?

--
Hubert.

Nina Popravka
Le #874630
On 09 Nov 2007 12:04:56 GMT,
(Lolotte) wrote:

Vois si tu peux capturer ce qui sort de ta machine pour voir si dans les 2
cas ça se passe de la même manière.


J'ai wiresharké avant de poser la question, et je ne vois pas de
différence fondamentale...
--
Nina

Nina Popravka
Le #874629
On Fri, 09 Nov 2007 13:17:33 +0100, Hubert
La présence d'un firewall qui envoie un reset à toute connexion non
autorisée au lieu d'attendre un timeout ?


Ben non, y a pas de fw sur les machines. Enfin si, sur le Mac y a le
"firewall" de Léopard qui fait des choses bizarres, mais il est
(normalement) désactivé. Je vais quand même tenter en le démarrant
sous Tiger.
Et de toute manière j'ai *toujours* vu nmap se traîner quand on
l'exécute à partir de XP...
--
Nina

newsreader
Le #874627
On 09 Nov 2007 12:04:56 GMT,
(Lolotte) wrote:

Vois si tu peux capturer ce qui sort de ta machine pour voir si dans les 2
cas ça se passe de la même manière.


J'ai wiresharké avant de poser la question, et je ne vois pas de
différence fondamentale...


Ben si au moins de temps, non ?
Tu me confirmes que tu scannes ton Ubuntu et ton MaxOSX depuis la même
machine ?
Sur cette machines quand tu wiresharkes, tu dois au moins voir que les
accès à chaques ports sont plus espacés sur le MacOSX, non ?
Est-ce que chacun des attaqués répond de la même manière (réponse et temps
de réponse, notamment sur les ports fermés) ? Est-ce que nmap répête ?

Lolotte
--
(enlever pasdespam pour répondre)
http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups,
recherche whois, les codes postaux, des jeux et plein d'autres bêtises...


Aurelien
Le #874626
Et de toute manière j'ai *toujours* vu nmap se traîner quand on
l'exécute à partir de XP...


Tu as essayée de lancer le .reg fourni avec la version windows de nmap ?
Ca doit normalement optimiser un peu le fonctionnement de windows sur
le réseau.

Pour info contenu de ce fichier :

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters]
"MaxUserPort"=dword:0000fffe
"TcpTimedWaitDelay"=dword:0000001e
"StrictTimeWaitSeqCheck"=dword:00000001

--
Aurélien

Nina Popravka
Le #874625
On 09 Nov 2007 12:33:11 GMT,
(Lolotte) wrote:

Tu me confirmes que tu scannes ton Ubuntu et ton MaxOSX depuis la même
machine ?
Toutafé.


Sur cette machines quand tu wiresharkes, tu dois au moins voir que les
accès à chaques ports sont plus espacés sur le MacOSX, non ?
Ah bin quand même, oui...


Est-ce que chacun des attaqués répond de la même manière (réponse et temps
de réponse, notamment sur les ports fermés) ?
De la même manière, plus lentement...


Est-ce que nmap répête ?
Hé non...


Bon, je dois me casser, je regarderai de plus près ce soir...
--
Nina

Pascal Hambourg
Le #876937
Salut,

Je l'utilise habituellement à partir de bécanes sous XP SP2, ça se
traîne, et j'ai toujours mis ça sur le compte de la limitation à 10
nouvelles connexions sortantes incomplètes par période de je sais plus
combien...


Comme d'autres l'ont déjà dit, l'effet de cette limitation dépend du
temps que met la cible à répondre.

Une réflexion, cependant. Je ne sais pas comment ça se passe sous
Windows, mais sous Linux nmap a deux types principaux de scan TCP :

- le "TCP connect scan" (-sT), qui utilise la fonction connect() de l'OS
et qui ouvre une socket TCP ; c'est le type de scan par défaut lorsque
nmap est exécuté par un utilisateur non privilégié.

- le "SYN scan" (-sS), qui utilise une socket "raw" et envoie
directement les TCP SYN sans passer par la couche TCP de l'OS ; c'est le
type de scan par défaut lorsque nmap est exécuté par un utilisateur non
privilégié.

Si c'est la même chose sous Windows, le SYN scan ne devrait pas être
affecté par la limitation du nombre de connexion TCP half-open de Windows.

Pascal Hambourg
Le #876936
[Grmbl, supersedes]

Salut,

Je l'utilise habituellement à partir de bécanes sous XP SP2, ça se
traîne, et j'ai toujours mis ça sur le compte de la limitation à 10
nouvelles connexions sortantes incomplètes par période de je sais plus
combien...


Comme d'autres l'ont déjà dit, l'effet de cette limitation dépend du
temps que met la cible à répondre.

Une réflexion, cependant. Je ne sais pas comment ça se passe sous
Windows, mais sous Linux nmap a deux types principaux de scan TCP :

- le "TCP connect scan" (-sT), qui utilise la fonction connect() de l'OS
et qui ouvre une socket TCP ; c'est le type de scan par défaut lorsque
nmap est exécuté par un utilisateur non privilégié.

- le "SYN scan" (-sS), qui utilise une socket "raw" et envoie
directement les TCP SYN sans passer par la couche TCP de l'OS ; c'est le
type de scan par défaut lorsque nmap est exécuté par un utilisateur
privilégié (root).

Si c'est la même chose sous Windows, le SYN scan ne devrait pas être
affecté par la limitation du nombre de connexion TCP half-open de Windows.

Nina Popravka
Le #876714
On Fri, 09 Nov 2007 15:54:51 +0100, Pascal Hambourg

Si c'est la même chose sous Windows, le SYN scan ne devrait pas être
affecté par la limitation du nombre de connexion TCP half-open de Windows.


Ouais, je m'en suis rendu compte tout à l'heure...
Bon, je vais déjà installer le .reg qui traînait effectivement dans le
dossier nmap, merci au contributeur qui me l'a signalé, je devrais
RTFMer davantage :-)
--
Nina

Publicité
Poster une réponse
Anonyme