Re: NMAP : Different interpretation of "filtered" ports depending on -sS or -sT options. Bug ?

[Sébastien CONTRERAS <contrera () EIG UNIGE CH>]

> Could you get netcat for
> Windows and check "nc -vvv destination 136" if it tells "connection
> refused" immediately or "time out" too?

I have downloaded netcat for Windows and I have done a "nc.exe -vvv 
192.168.254.10 136". Here is the output :
C:\Program Files\NetCat>nc.exe -vvv 192.168.254.10 136
host1 [192.168.254.10] 136 (?): connection refused
sent 0, rcvd 0: NOTSOCK

The connection is refused.

The timeout really seems to come from NMAP. Someone to confirm this behavior 
on Windows version of NMAP ?

----- Original Message ----- 
From: "Martin Mačok" <martin.macok () underground cz>
To: <nmap-dev () insecure org>
Sent: Friday, January 07, 2005 6:18 PM
Subject: Re: NMAP : Different interpretation of "filtered" ports depending 
on -sS or -sT options. Bug ?


On Fri, Jan 07, 2005 at 02:55:07PM +0100, Sébastien CONTRERAS wrote:

> Someone as done the test on a Linux box running v3.75 ?

My nmap-3.78 -sT seems to be working well on Linux 2.4.

> I also noticed that when I'm using the -sT option, NMAP displays the
> results only 10 seconds after that the last packet corresponding to the
> scan has been received (no filters are set in my Ethereal :) ).

This would indicate that nmap's connect() didn't receive the RST
packet (nor any other response) because 10s actually equals the
timeout it uses when it gets no response.

Are you sure you have no personal firewall involved? (OK, you told you
tested it on XP SP1 too, so probably not...) Could you get netcat for
Windows and check "nc -vvv destination 136" if it tells "connection
refused" immediately or "time out" too?

> C:\Program Files\nmap-3.75>nmap -sT -p 135-136
> 192.168.254.10 --packet_trace -vvv -dd

> CONN (0.1500s) TCP localhost > 192.168.254.10:136 => Unknown error
> CONN (0.1600s) TCP localhost > 192.168.254.10:135 => Unknown error
> CONN (1.2610s) TCP localhost > 192.168.254.10:136 => Unknown error

This suggests that connect() returned -1 (ie. error, at least
on Unix) and WSAGetLastError() returned "Unknown error" as an
explanation(*).

Somehow later on, the descriptor for 135/tcp connect probe has changed
when doing select() on it and
getsockopt(..,SOL_SOCKET,SO_ERROR,&optval,...) filled in &optval with
NULL which indicates success (=> port open). The descriptor for
136/tcp probe has not changed and nmap gave up after 10 seconds.

(I'm sorry, I can't help you much with Windows, it's not my OS of
choice and I don't know much about it :-( )

(*) But you should get "Strange error on from connect (Unknown error)"
   message on stderr in this case too! I can't explain why you didn't
   :-/ ... is something wrong with stderr on Windows? Or should we
   fflush(stderr) in nmap too?

Martin Mačok
ICT Security Consultant

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-help () insecure org . List archive: http://seclists.org





---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List archive: http://seclists.org