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.
alek
> From: "Jones, Greg" <Greg.Jones_at_bskyb.com>
> Subject: RE: Setting nmap host_timeout too low may cause DoS on inetd (?)
> To: "'Alek O. Komarnitsky'" <alek_at_ast.lmco.com>,
> "'nmap-hackers_at_insecure.org'" <nmap-hackers_at_insecure.org>
>
> Yes that sounds too familar. I have killed inetd on HPUX and Solaris using
> regular TCP scans. I have also killed the IP stack on VMS 6.x and 7.x (UCX)
> using plain old TCP scans, each time I have been scanning over a LAN...
>
> regards
>
> G
>
> -----Original Message-----
> From: Alek O. Komarnitsky [mailto:alek_at_ast.lmco.com]
> Sent: 15 March 2000 17:31
> To: nmap-hackers_at_insecure.org
> Subject: Setting nmap host_timeout too low may cause DoS on inetd (?)
>
>
> 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.
>
> --------------------------------------------------
> For help using this (nmap-hackers) mailing list, send a blank email to
> nmap-hackers-help_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
Received on Mar 16 2000
Intro
