Bugtraq mailing list archives

Re: denial of service attack possible


From: atreus () primus COM (Michael R. Widner)
Date: Fri, 27 Oct 1995 11:07:05 -0700


In a previous message, Mark Thomas said:
Last night, the machine completely stopped accepting connections on
port 80 to the web server.
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?

This is a pretty well known problem, although I don't recall it being
discussed much here.  Most (all?) unixes can only handle a limited number
of connections in the SYN_RCVD state.  The simple denial of service
attack is to send a machine a large number of forged SYN packets with
a source IP address of 'X'.  The attacked machine sends SYN/ACK packets
to 'X' and tries to establish a connection.  If 'X' is listening it
will generally send back an RST packet and the connection will be closed.
If 'X' chooses to ignore the SYN/ACK packets (or more likely 'X' is
down or non-existent) then the attacked host will let the connections
sit in the SYN_RCVD state for some time.  Since there is a limit to how
many connections are allowed to be in this state, and since all 'real'
connection attempts must pass through this state, you have a very simple
denial of service attack.

I've been out of touch for some time, so perhaps somebody has found a
cure for this problem.  I have not yet heard of one, however.

-Mike



Current thread: