Nmap Development mailing list archives
Re: Diet Nmap v3.95 Released
From: Martin Mačok <martin.macok () underground cz>
Date: Tue, 13 Dec 2005 23:43:49 +0100
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
Current thread:
- Re: Diet Nmap v3.95 Released William MacKay (Dec 11)
- Re: Diet Nmap v3.95 Released Schneelocke (Dec 11)
- Re: Diet Nmap v3.95 Released Ismail Donmez (Dec 11)
- Re: Diet Nmap v3.95 Released Ron (Dec 11)
- Re[2]: Diet Nmap v3.95 Released Thierry Zoller (Dec 11)
- <Possible follow-ups>
- Re: Diet Nmap v3.95 Released Martin Mačok (Dec 12)
- Re: Diet Nmap v3.95 Released Fyodor (Dec 13)
- Re: Diet Nmap v3.95 Released Nicob (Dec 13)
- Re: Diet Nmap v3.95 Released Martin Mačok (Dec 13)
- Re: Diet Nmap v3.95 Released uzy (Dec 13)
- Re: Diet Nmap v3.95 Released Martin Mačok (Dec 14)
- Re: Diet Nmap v3.95 Released Fyodor (Dec 13)
- Re: Diet Nmap v3.95 Released Schneelocke (Dec 11)