Re: [PATCH] improvements and a new(?) type of scan

[Fyodor <fyodor () insecure org>]

On Tue, Apr 02, 2002 at 04:54:49PM +0200, Phil wrote:
> I've implemented today a new type of scan and some improvements needed by
> it, that could be used elsewhere.

He Phil -- neat patch.  Sorry it took so long for me to respond.
Regarding your changes:

> This give the posibility to outputs like :
> Port       State       Service
> 22/tcp     filtered    ssh
> 23/tcp     filtered    telnet                   Blocked (ICMP port-unreachable)
> 24/tcp     filtered    priv-mail                Blocked (ICMP port-unreachable)

That is very useful information (especially if you also gave the
source IP of the ICMP error).  However every character in that part of
Nmap output is precious.  I wouldn't want to fill it with something
that is only shown for filtered ports.  But I might consider someday
having a general "notes" section there.

On the other hand, I would like to include that information in the
XML output.  For example, my XML output proposal from a couple years
ago ( http://lists.insecure.org/nmap-dev/2000/Jul-Sep/0038.html )
included a "filteredby" tag:

<port protocol="UDP" port="31337">
   <state state="filtered" conf="5" /><filteredby><packet proto="ICMP"
   type="3" code="3" name="ICMP port unreachable" srcipaddr="10.3.7.4"
   ip_v="4" /></filteredby>
   <service name="backorifice" conf="3" method="table" />
</port>

I would probably accept a patch which adds this information (after the
next stable version of Nmap is released).

> (note that there is always the problem of the ICMP rate limitation :
> port 22 is blocked, too)

Good point.

> * A magic IPID number :
>   At the begining, nmap choose a random magic number. Each time a tcp
>   or udp packet is sent, the IPID is initialised with the dest port number
>   xor-ed with the magic number.
>   Now we're able to find a probable related scan port with an icmp reply,
>   even if the tcp citation has been mangled (see later for
> application).

Your Linux NAT disclosure hole was a great find!  The ipfilter team
fixed that pretty quickly, right?  Have you seen any other routers
vulnerable to this?  I am hesitant about making these sorts of changes
to exploit a bug in (now) older versions of one platform.

>   This consists in sending packets as in a normal scan, but with a TTL
>   small enough to only reach the gateway we want to firewalk.

This is a feature that I have been wanting to add, but haven't had a
chance.  Since a nonbeta release is imminent (I really mean it! Going
out this month!), I am trying to apply only bugfixes.  But if someone
sends a clean patch after the next stable release which adds --ttl ,
I'll probably apply it.

> Here is an example of what we can get (I need 20 hops to reach google) :
>
> ./nmap -sS www.google.com  -t 19

Yep.  And I think it has as much or more potential with UDP.  But I am
torn between just adding a TTL option and saying 'let the user handle
it' or building the smarts into Nmap to pick the appropriate TTLs and
interpret the results.

Cheers,
-F


---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).