Nmap Announce mailing list archives
(Semi ;-) SUMMARY: Setting nmap host_timeout too low may cause DoS on inetd (?)
From: "Alek O. Komarnitsky" <alek () ast lmco com>
Date: Sat, 18 Mar 2000 15:49:47 -0700 (MST)
I wrote earlier:
Nmap Folks, I think I might have a "inadvertant" denial of service attack caused by nmap on Solaris2.6{+} and HPUX10.20 machines. I recently setup a web page using nmap to do misc. port scanning; with the main intention being to look for web servers - we're trying to clamp down a bit on 'em and get 'em semi-under-control. In order for it to run super-duper fast, I added a: $NMAP_OPTIONS = "--initial_rtt_timeout 300 --host_timeout 5000"; BTW, it sure seems like rtt_timeout is actually in HUNDREDTH's of a second rather than milliseconds - since when I use this on a host that is not up; it times out in 3 seconds ... changing 300 to 1500 causes the timeout in 15 seconds (I'm using nmap Beta13 on a Solaris2.7 box). I might be a bit agressive with the host_timeout ... all hosts are semi-local-LAN/WAN ... and I'm only hitting a hundred or so specified ports; but we're just trying to do quick-n-dirty stuff, and it's cool to see the results from 500+ machines in a flash - nmap is QUITE cool! NOTE: Just using standard "TCP" scans running as a non-root user. A few percent of the scanned machines end up with a "hanging" inetd; so inbound telnet/etc. connections are no longer accepted. Interestingly enough, one can often "clear" it by doing another scan to just the targeted host. And on a few machines, inetd flatout died - so then you are basically hosed! Sun Bug ID4260432 describes a situation somewhat similar to this ... but the problem in not repeatable in any way ... the vast majority of the time; the scan just finishes and we are all happy. So ... my guess is that on those "few" boxes, I don't quite get done in time and nmap aborts, leaving some half-open connections ... which then causes inetd to crash-n-burn. Ideally, inetd should not be so fragile! ;-) Bumping the host_timeout may be all I need to do. I emphasize my attempt here is NOT to cause a DoS, but to provide a quick-n-dirty (and safe! ;-) web based scanning tool for internal use. Does any of this make sense and/or sound familier to people? Thanx, alek P.S. Apologies if I missed an archive of the Email list - if this topic has been covered elsewhere, pls point me that direction.
And then in a followup:
The odd thing IMHO is that I'm only scanning about a hundred or so ports; most of which don't answer in the first place. Plus, the more common scenerio is that inetd seems to go into "sleep mode" (ex: telnet's connect but hang) but if I do ANOTHER scan, then it "wakes" back up and all is well. And yes, in a few cases, inetd just dies (but only on the (few) SunOS4.x machines and the HP-UX boxes) - note that "inetd sleeping" occurs on the Solaris boxes. Remember that I'm using this in a tool to allow admins to do port scanning for Web Servers on various ports - I won't look too "good" if my tool also causes a DoS on your server when it does the scanning! ;-) I can understand "older" OS's (Greg mentioned VMS) and Windoze to having problems; but I would expect my (reasonably patched up-to-date) Solaris machines to handle this a bit better.
I got several responses (some that went to the list too) and also spent a fair amount of time going through the BugTraq archives at securityfocus.com. WRT Sun machines, we are pretty up-to-date on patches so we have the mutex DoS issue covered. One thing I did do was disable additional services in /etc/inetd.conf and specifically the xaudio one, since it calls Xaserver which does not exist, and Sun Bug ID#4169474 suggests that this can cause inetd to go into a loop. WRT HP machines, I loaded PHNE_16832 (yes, we're not quite as up-to-date on patches there as we are on the Sun platform! ;-) which replaced /usr/sbin/inetd dated from 1996 with one from 1999. Note that both had the string "looping" in 'em when I did a strings ... but the README associated with this implies it could help. WRT nmap: I changed the options FROM/TO: -p "list-of-ports" --initial_rtt_timeout 300 --host_timeout 5000 -p "list of ports" --initial_rtt_timeout 500 --host_timeout 15000 -sT although I thought "-sT" is the default, so that should be redundant. Again, I emphasize I'm not trying to be "stealthy" here ... just want to have a quick-n-dirty way of seeing which services are running. So ... having done all that, I pounded the crap out of a couple of dozen machines and could not cause any of 'em to go "haywire" - i.e. sleeping inetd. But remember that I could not duplicate the original problem ... so I'm not totally convinced I "really" fixed something here ... but we'll see if any oddball stuff crops up in the next few weeks. Thanx again for the response from folks ... and to Fyodor and others who have written an extremely useful tool. alek
Current thread:
- (Semi ;-) SUMMARY: Setting nmap host_timeout too low may cause DoS on inetd (?) Alek O. Komarnitsky (Mar 18)