Re: (local?) linux DoS using nmap

[Vidyut Luther <aeon () linuxpowered com>]

I tested this on my slackware box and I was able to kill off port 21. 
As for your comment about maybe inetd dieing ? I thought that was the
caseas well at first, then I tried port 22 (ssh). whats interesting to
note is that my load rocketed up to around 120. cpu usage was only 20%
though (results from what procmeter is displaying right now). woops load
just went up to 150 and is stayin there. 
anyway. if i try to ssh into my linux box right now. it's not gonna
happen. until i hit ctrl -c... but as a result of this. 
sendmail has stopped working (load over 25, I never changed that value..
don't know how many people do :/). 

so now we have not only disabled ssh, but also mail. Ok i'm writing this
mail as i'm running nmap in another window.. and whats funny is that once
it got to scanning 127.0.5.* the load went right down to 10.
and ssh was running again. I did a ctrl-c and restarted nmap, and now the
load is back up at around 150.. heh actually it's been at 182 for the past
4 minutes or so. yay. wierd now the same thing f the load plummeting
happens.. but now it was at the 127.0.33.* mark. :/
i'm not really sure why this happens. but..

doin this temporaririly disables ssh and mail. (once the load goes down,
mail starts up again, and ssh just takes forever to work, it's not really
turned off. Some people might have timeouts shorter than the amount of
time it takes to establish a connection. 

In case you're wondering the system I tested this on is a pII 233 with
128MB ram. and 128 MB swap.

results of uname -a : 
uname -a
Linux avalon 2.2.6 #3 Thu May 27 20:50:16 EDT 1999 i686 unknown

(i enabled syncookies when i compiled). 
and I guess as the topic suggests that command itself results in a
completeyly different output on freebsd. :/


Vidyut Luther
"Fear leads to anger, Anger leads to Hate, Hate leads to suffering" ---Yoda(Star Wars: The Phantom Menace)
http://www.linuxpowered.com
http://everything.linuxpowered.com <-- Alpha(so pardon the appearance)

On Thu, 3 Jun 1999, Mr. Man wrote:

> What kernel version are you running, and do you have SYN Cookies enabled
> in that kernel?  Also, were all the other services that died being called
> from the inetd superserver?  Inetd may have died, which I think might have
> been a previous problem with nmap and some versions of inetd.  I'm not
> sure which inetd is shipping with those distributions these days, but it'd
> be best to use an inetd that limits the amount of commections for each
> type of service per IP address.  
>
> The inetd that ships with my slackware 3.4 box has this option:
>
> -q queuelength
>         Sets the size of the socket listen queue to the specified value.
>         Default is 128.
>
> Adjusting the queue size one way or the other may help stop the problem.
>
> FreeBSD's inetd has the following options which I'm not sure these
> distributions have.  They are:
>
> -c maximum
>         Specify the default maximum number of services that can be in-voked.  
>         May be overridden on a per-service basis with the "max-child"
>         parameter.
>
> -C rate
>         Specify the default maximum number of times a service can be 
>         in-voked from a single IP address in one minute; the default is 
>         un-limited.  May be overridden on a per-service basis with the
>         "max-connections-per-ip-per-minute" parameter.
>
> -R rate
>         Specify the maximum number of times a service can be invoked in 
>         one minute; the default is 256.
>
> I hope that sheds some light on the problem.  I'm pretty sure inetd has
> just died, which causes all services normally called form it (ftpd,
> telnetd, etc.) to fail.
>
> Mr. Man - Darkside Labs
> If at first you don't succeed, destroy all evidence that you tried.
>
> On Thu, 3 Jun 1999, cami wrote:
>
> > Good day..
> >
> > I appologize if this is old but seems still to be
> > working/active on my own server. (slackware 4.0.0).
> > I would be interested to know which other distro's
> > this works against.
> >
> > Tested against:
> >   slackware 4.0.0
> >   debian 2.1
> >   Redhat 6.0
> >
> > I became aware of this when local users begun
> > to launch DoS attacks.
> >
> >
> > kernel:~$ nmap 127.[0-255].[0-255].[0-255] -p 21 -sT
> >
> > Starting nmap V. 2.12 by Fyodor (fyodor () dhp com, www.insecure.org/nmap/)
> > Interesting ports on localhost (127.0.0.1):
> > Port    State       Protocol  Service
> > 21      open        tcp        ftp
> >
> > Interesting ports on  (127.0.0.2):
> > Port    State       Protocol  Service
> > 21      open        tcp        ftp
> >
> > <snip>
> >
> > and it keeps going untill the +/-280th packet..
> >
> > <snip>
> > Interesting ports on  (127.0.1.32):
> > Port    State       Protocol  Service
> > 21      open        tcp        ftp
> >
> > No ports open for host  (127.0.1.33)
> > No ports open for host  (127.0.1.34)
> > No ports open for host  (127.0.1.35)
> >
> > etc.. etc..
> > <snip>
> >
> > I havent tested it on remote machines,
> > but this looks like a tcp/syn flood?
> >
> > Anyhow, local users can shutdown any
> > local daemon running on any port.
> > (apache was the only service
> >  that remaining running.)
> >
> > The rest of the other services became
> > unusable/(dead?).
> >
> > Any ideas how one could prevent this?
> > Sorry again if this is old.
> >
> > Regards
> >  hotmetal of (src)
> >  hotmetal () hack co za
> >
> > (      www.hack.co.za        )
> > (e x p l o i t    m a t r i x)
> > (world domination in progress)