Re: nmap's "-S" option and linux SAV

[Fyodor <fyodor () insecure org>]

On Sat, 15 Jul 2000 tech_related () ip pt wrote:

> nmap -sU -P0 -e ppp0 1-1024 192.168.0.2
>
> resulted in 
>
> Allt 1024 scanned ports on 192.168.0.2 are: filtered
>
> but (for example)
>
> nmap -sU P0 -e ppp0 1 192.168.0.2
>
> outputs "port 1, state open" (the same happened with all the ports in the 1-1024 range I cared to try).

This is a frequent question, probably because the behavior is not 100%
intuitive or documented very well.  For UDP scanning, Nmap can not
differentiate between truly open ports and ports that are filtered due to
DENY rules (which don't even send back an ICMP unreachable).  Thus Nmap
has to resort to some heuristics.  It generally assumes that such as port
is "open" to be on the safe side (we wouldn't want to tell you it is
filtered when it is really open and vulnerable).  But if hundreds of ports
are scanned, and none of them return any packets, then it is clear that
filtering is going on so Nmap marks the port "filtered".

This is not optimal.  I get a lot of panicked people mailing me with scans
that show the backorifice port "open".  In reality, their ISP is dropping
all packets to port 31337 so it just looks like it is open to Nmap.

I am looking into adding a firewalk-like technique to Nmap to help
diagnose these ambiguous filtered vs open.

Note that this problem affects UDP, FIN, XMAS, and NULL scans.  SYN and
connect() scans receive feedback when the port is open so they are not
troubled by this issue.

Cheers,
-F