Home page logo
/

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


  By Date           By Thread  

Current thread:
  • (Semi ;-) SUMMARY: Setting nmap host_timeout too low may cause DoS on inetd (?) Alek O. Komarnitsky (Mar 18)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault