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

[Martin Mačok <martin.macok () underground cz>]

On Fri, Jan 07, 2005 at 10:04:51AM +0100, Sébastien CONTRERAS wrote:

> When scanning machine B  (IP=192.168.254.10, no firewall on this
> machine and no application listening on port 136) with NMAP (NMAP on
> machine A), NMAP gives me two different output depending on the
> options (-sS or -sT).

This is strange and worth an investigation.

Which nmap version do you use? Which OS?

Could you run the scans with --packet_trace -vvv -dd ?

Could you try "nc -vvv 192.168.254.10 136" too? (so wee see how plain
connect() behaves)

Could you make the dumps with "tcpdump -v 'host 192.168.254.10 or icmp'"?
(did you use tethereal with no filter or with 'host X.Y'? I've seen
cases where the destination was responding while there were ICMP DU
from the gateway received too)

> If we look at packets corresponding to port 136, the packet sequence
> is always (independently I use the -sS or -sT options) :
>  A > B [SYN]
>  B < A [RST, ACK]
>
> So my question is :
> Why NMAP say that port 136 is closed in case 1/, and filtered in
> case 2/ whereas the packet generated are the same ? Is this a bug
> ? or do I forget something ?

Is it possible that you received ICMP error message (so connect()
returned EACCESS or EHOSTDOWN) and you didn't see it with ethereal
because of ethereal filter? (just a wild guess)

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