Re: Diet Nmap v3.95 Released

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

On Tue, Dec 13, 2005 at 03:26:51AM -0800, Fyodor wrote:

> > http://Xtrmntr.org/ORBman/tmp/nmap/

> == nmap-3.30-idle.patch ==
>
> This patch allows a user to specify that SYN packets should be sent
> to the Idle proxy to probe for IPID rather than the default SYN/ACK.
> I can see hypothetical cases where this could be useful, but it is
> pretty obscure.  Do you use this a lot?

When I scan through "stateful" firewall I often can't get SYN+ACK
through but I can get SYN through.

(I use it rarely in pentests and a little bit more often as an IDLE
scan demonstration during my occasional pentest lectures.)

> == nmap-3.78-option-max_retransmissions.patch ==
>
> Looks good!  I applied this, though with a bunch of changes.  I named
> the option --max_retries (shorter, if not quite as descriptive) and
> made the values a little less aggressive.  I also decided to allow
> --max_retries 0 in case you don't want any retries at all (only
> advisable for informal surveys and other cases where missing occasional
> ports/hosts is acceptable).

Initially I was testing 0 too but it turned out kicking your rld
(rate-limit-detector) stuff in too early and it seemed to me that the
rld* code is not ready for zero max_retrans (though I can't remember
exactly what was wrong... it was 3.7x..). I bumped the minimum to
1 which seemed to be compatible with rld. You should know better...

> == nmap-3.81-osscan_no_ports_reuse.patch  ==
>
> This will break (ignore) -g for OS scan, and I'm uncomfortable with
> the way it sets o.magic_port in osscan.cc.  That value is really
> "supposed" to be read only, though it isn't enforced in the code. 

OK. My colleague wrote the patch when he was scanning through some
Checkpoint FW (or what...) with "stateful inspection" (or what :-) and
it was dropping the OS scan packets. This patch made them through ...
(ok, maybe we will try to make it cleaner next time)

> == nmap-3.81.top14-ports ==
>
> This is a patch to NmapFE to add an option to scan just the "top 14"
> ports.  Did you come up with these values from empirical scanning?

Not really (but yes, it was partly based on statistical processing our
older nmap output archives) but I'm often interested in just those
ports when sweeping through the network ... or just quickly/stealthy
testing if some host is accessible or not and what kind of host it
is... this patch is not very serious but I find it handy sometimes so
I was sharing it. I think Nmap deserves some real concept of "scan the
X most frequently used ports" because even -F scan often still too
slow and overhead/aggressive... quick hack may be sorting
nmap-services file according to real world occurence (though it could
be different for local networks and for the Internet) and using just
the first X lines when user asks for it.

> I wouldn't mind adding an option like this, but I'd like to see good
> reasoning for choosing a particular set of ports.  Maybe this list
> should be expanded to top 30 instead?

... yes and no :-) Actually we use -p$TOP10 and TOP14, TOP50, TOP100
and TOP256 (not to mention UDDP ;-)

> == nmap-3.95-CONNECT-closedfiltered.patch  ==
>
> I'm not convinced that connect() scan should change all instances of
> closed to closed|filtered.

OK :-) I can't believe I'm the only one who finds it confusing when
-sS scan tells that the port is filtered and -sT scan tells it is
closed ;-)

> == nmap-3.95-detect_TARPIT.patch ==
>
> This patch detects Labrea and iptables tarpits, and avoids scanning
> them if it finds them during ping scan.  Neat patch, and I'm glad it
> exists for people who want the functionality, but I'm not sure that it
> belongs in mainline Nmap.

I think the more important part of the patch is not the ping part but
the scan part. Maybe you could apply just the scan part. It shouldn't
break anything except for (already broken) Nmap wrappers ;-)

> == nmap-3.95-defeat_ratelimits.patch ==
>
> This looks promising, especially the ICMP error rate limiting part.
> I'm too tired tonight, but made a note to examine it later.

... I wrote the patch during last Christmas ... jingle bells, jingle
bells ... ;-)

Martin Mačok
ICT Security Consultant


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev