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
Received on Mar 18 2000
Intro
