Bugtraq mailing list archives

Re: denial of service attack possible


From: avalon () coombs anu edu au (Darren Reed)
Date: Sat, 28 Oct 1995 02:16:47 +1000


In some mail from Mark Thomas, sie said:

Hi,

I posted this to sun-managers, but it has some nasty consequences if deliberately
exploited.  If anyone has any more info, or ideas for a fix, please let me know.

Subject: denial of service problem on port 80 with 4.1.4
To: sun-managers () ra mcs anl gov
Date: Fri, 27 Oct 1995 00:59:49 -0400 (EDT)

I run a web server on a 110 MHz SPARC-5 clone running 4.1.4 with the below kernel
and libc patches, and a second sbus FSBE SCSI and buffered ethernet card:
[...]
These connections persisted over an hour, and finally I had to block the
specific remote machine with a filter rule in the router, at which point
the web server picked up with it's usual incoming connection activity.
(greater than 10,000 web connections per hour)

The explanation from the remote site was that they were running tia
(The Internet Adapter), and that it was causing these problems, and
they were working with the makers of the software to fix it.

It concerns me that one remote site can so easily completely block all
incoming tcp/ip connections on a port.  Is this a kernel bug, or something
I can take some measure to prevent on this end?

I know it is not a httpd program related problem, because the problem persisted
even when I tried running a completely differently designed web server program
on that port.  I am also wondering if this particular bug or problem might
account for other periodic times when my machine takes a long time to accept
incoming connections.

If anyone has any more specifics on this problem, please let me know.  When
the server is healthy netstat indicates a couple SYN_RCVD state services, but
they never last from one netstat command to another for the same remote IP.

This is (I assume) a well known denial of service "problem".

It is part of the bug exploited by the IP spoofing programs which setup a
priveledged port to which the fake connection is meant to come from.

There is nothing in any unix which provides any way to deal with this problem
as they all setup fixed size accept queues for TCP SYN packets.  Part of
the "things done" to Solaris 2.4 is upping this number from 8 to 32.

Ideally, they would be allowed to accumulate much further than this but
expire much quicker.  Or have a FIFO...which could also be bad.  I don't
know that there is any solution to this - a serious attack can screw you
up real bad - and I don't know that IPv6/SSL/SKIP/Photuris will solve it
either.


darren



Current thread: