Re: denial of service attack possible

[nlawson () statler csc calpoly edu (Nathan Lawson)]

> 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.
>
> netstat -an indicated:
> Active Internet connections (including servers)
> Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
> tcp        0      0  205.164.146.26.80      146.94.1.2.2972        SYN_RCVD
> tcp        0      0  205.164.146.26.80      146.94.1.2.2763        SYN_RCVD
> tcp        0      0  205.164.146.26.80      146.94.1.2.2762        SYN_RCVD
> tcp        0      0  205.164.146.26.80      146.94.1.2.2612        SYN_RCVD
> tcp        0      0  205.164.146.26.80      146.94.1.2.2611        SYN_RCVD
> tcp        0      0  205.164.146.26.80      146.94.1.2.2610        SYN_RCVD
> tcp        0      0  205.164.146.26.80      146.94.1.2.2609        SYN_RCVD
> tcp        0      0  205.164.146.26.80      146.94.1.2.2541        SYN_RCVD
> tcp        0      0  *.80                   *.*                    LISTEN
>
> 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?

Yes, a remote site can block connections to a port in that manner.  It isn't
a kernel or http bug, but just a general decision made in the networking
code for BSD.  The problem it addressed was what to do with initial SYN's that
haven't been ACK'd.

There are several things that can be done in such a situation.  First, the
kernel can keep a queue of connection requests and process them in a FIFO
manner.  It would respond with a RST for any more incoming connections that
showed up while its queue was full.  Unfortunately, this doesn't fit the
goal of an RST which was designed to deal with permanent errors, not possible
temporary conditions like a busy machine.

Instead, the designers chose to drop newer requests silently.  The old
requests time out after about 90 seconds.  They expected the client's
application to timeout and resend the connection request.

This doesn't address direct d.o.s. attacks, though.  I think that Solaris's
tcp_eager_listeners option could be used to allow your application to process
connection requests before the complete 3-way handshake.  Other than that,
it's up to you whether you want to violate RFC's and perhaps break other things
by dropping connection requests from the queue faster or limiting the number
of requests from one machine.

Good luck,
Nate