ignore security and it'll go away

nmap.local.linux.DoS.txt

nmap.local.linux.DoS.txt
Posted Aug 17, 1999

Apparently, another denial of service attack that utilizes nmap tcp connect() port scans has been discovered. So far, it appears that only Linux is locally vulnerable. This attack kills virtually all services, and can be executed by any local user.

tags | exploit, denial of service, local, tcp
systems | linux
MD5 | 3a23d0795e8f640d9b7cc31f1c84142d

nmap.local.linux.DoS.txt

Change Mirror Download
Date: Thu, 3 Jun 1999 06:22:50 +0200
From: cami <cami@dockside.co.za>
To: nmap-hackers@insecure.org
Subject: (local?) linux DoS using nmap

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)

-----------------------------------------------------------------------------

Date: Thu, 3 Jun 1999 01:08:27 -0500 (CDT)
From: Mr. Man <mrman@darkside.org>
To: cami <cami@dockside.co.za>
Cc: nmap-hackers@insecure.org
Subject: Re: (local?) linux DoS using nmap


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.

-----------------------------------------------------------------------------

Date: Thu, 3 Jun 1999 08:48:59 -0400 (EDT)
From: Vidyut Luther <aeon@linuxpowered.com>
To: Mr. Man <mrman@darkside.org>
Cc: cami <cami@dockside.co.za>, nmap-hackers@insecure.org
Subject: Re: (local?) linux DoS using nmap

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)

-----------------------------------------------------------------------------

Date: Thu, 3 Jun 1999 17:16:48 +0200
From: cami <cami@dockside.co.za>
To: nmap-hackers@insecure.org
Subject: Re: (local?) linux DoS using nmap

> What kernel version are you running, and do you have SYN Cookies enabled

2.2.5

>only ftp is affected;

Sadly i'd have to say you are incorrect.
To spice up the attack.. try something like this..

kernel:~$ nmap 127.0.[0-255].[0-255] -sT

And what do u get? all services go bye-bye.

>I assume it will recover after some time.

Unfortuately, wrong again. I sat waiting for
my services to come around with no luck.

>so now we have not only disabled ssh.
>it got to scanning 127.0.5.* the load
>went right down to 10. and ssh was
>running again.

Very true, sshd seems to struggle but does
indeed come back up (although with much
difficulty.)

I've managed to code a little tool that "locks"
up sshd remotely rendering it useless.
(along with basically any other daemon
running on a linux machine)

btw.. just out of interests sake, i'm running
Slackware 4.0.0 with syn cookies enabled
on a pII 350 and 128m ram.

Please also take note i've tested this against
every version of linux i can get my hands on
and it _does_ work on all distributions.

Anyone run this against any FreeBSD machines
etc..?

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)

-----------------------------------------------------------------------------

Date: Sat, 5 Jun 1999 06:24:14 -0400 (EDT)
From: Ken Williams <jkwilli2@unity.ncsu.edu>
To: cami <cami@dockside.co.za>
Cc: nmap-hackers@insecure.org
Subject: Re: (local?) linux DoS using nmap

On Thu, 3 Jun 1999, cami wrote:

> Date: Thu, 3 Jun 1999 17:16:48 +0200
> From: cami <cami@dockside.co.za>
> To: nmap-hackers@insecure.org
> Subject: Re: (local?) linux DoS using nmap

-----snip-----

> Anyone run this against any FreeBSD machines
> etc..?

no effect at all on services or load for the following:

FreeBSD 2.2.8-STABLE
FreeBSD 3.1-RELEASE
FreeBSD 3.2-STABLE
FreeBSD 4.0-CURRENT
SunOS 5.5.1 sun4u sparc
SunOS 5.6 sun4u sparc
SunOS 5.7 sun4u sparc
SunOS 5.7 x86

-- ken

-----------------------------------------------------------------------------

Date: Sun, 6 Jun 1999 11:59:32 -0300 (ADT)
From: moses@pentagram.nslug.ns.ca
To: nmap-hackers@insecure.org
Subject: Re: (local?) linux DoS using nmap

On Thu, 3 Jun 1999, cami wrote:

> kernel:~$ nmap 127.0.[0-255].[0-255] -sT
>
> And what do u get? all services go bye-bye.

If you look through your logs you'll see entries like this:
Jun 6 11:54:30 pentagram inetd[327]: ftp/tcp server failing (looping),
service terminated

man inetd says you can change this by appending a number after the
wait/nowait entry in inetd.conf:

The optional ``max'' suffix (separated from ``wait'' or ``nowait'' by a
dot) specifies the maximum number of server instances that may be
spawned from inetd within an interval of 60 seconds. When omitted,
``max'' defaults to 40.

Just kill -1 inetd to reenable.

I think ssh getting slow was just ssh getting slow (from all the daemons
being forked).

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

May 2012

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    37 Files
  • 2
    May 2nd
    53 Files
  • 3
    May 3rd
    33 Files
  • 4
    May 4th
    4 Files
  • 5
    May 5th
    10 Files
  • 6
    May 6th
    17 Files
  • 7
    May 7th
    19 Files
  • 8
    May 8th
    36 Files
  • 9
    May 9th
    34 Files
  • 10
    May 10th
    35 Files
  • 11
    May 11th
    20 Files
  • 12
    May 12th
    18 Files
  • 13
    May 13th
    11 Files
  • 14
    May 14th
    27 Files
  • 15
    May 15th
    58 Files
  • 16
    May 16th
    54 Files
  • 17
    May 17th
    25 Files
  • 18
    May 18th
    53 Files
  • 19
    May 19th
    9 Files
  • 20
    May 20th
    15 Files
  • 21
    May 21st
    25 Files
  • 22
    May 22nd
    32 Files
  • 23
    May 23rd
    35 Files
  • 24
    May 24th
    26 Files
  • 25
    May 25th
    25 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2012 Packet Storm. All rights reserved.

close