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) :
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
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
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) :
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...
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) :
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...
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) :
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
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.
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 ?
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
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
On 09 Nov 2007 12:04:56 GMT, newsreader@pasdespamdansmongrenier.com
(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
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
On Fri, 09 Nov 2007 13:17:33 +0100, Hubert wrote:
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
On Fri, 09 Nov 2007 13:17:33 +0100, Hubert <hubert@rdejeux.net> wrote:
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
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
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...
On 09 Nov 2007 12:04:56 GMT, newsreader@pasdespamdansmongrenier.com
(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...
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
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.
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.
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.
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
On 09 Nov 2007 12:33:11 GMT, newsreader@pasdespamdansmongrenier.com
(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
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
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.
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.
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
[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.
[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.
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
On Fri, 09 Nov 2007 15:54:51 +0100, Pascal Hambourg wrote:
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
On Fri, 09 Nov 2007 15:54:51 +0100, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org> wrote:
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
On Fri, 09 Nov 2007 15:54:51 +0100, Pascal Hambourg wrote:
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
