[2310] in bugtraq
Re: denial of service attack possible
daemon@ATHENA.MIT.EDU (Darren Reed)
Fri Oct 27 17:00:22 1995
Date: Sat, 28 Oct 1995 02:16:47 +1000
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: Darren Reed <avalon@coombs.anu.edu.au>
X-To: BUGTRAQ@CRIMELAB.COM
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To: <199510270507.BAA26188@marksys.misty.com> from "Mark Thomas" at
Oct 27, 95 01:07:41 am
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
