[1058] in linux-security and linux-alert archive
Re: [linux-security] inetd and denial-of-service
daemon@ATHENA.MIT.EDU (infinity)
Sat Aug 24 19:16:53 1996
From: infinity <route@infonexus.com>
To: shagboy@bluesky.net
Date: Thu, 22 Aug 1996 08:49:02 -0700 (PDT)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <Pine.LNX.3.91.960821225700.133A-100000@cirrus.bluesky.net> from "Racer X" at Aug 21, 96 11:19:14 pm
-----BEGIN PGP SIGNED MESSAGE-----
Racer X's thoughts were:
| I started thinking about this a couple of days ago (right after I read
| the source for the SYN-flooder in the latest 2600). I thought of a way
| to at least try to avoid total denial-of-service.
|
| >From the sources I have seen for SYN-flooders, they generally forge the
| source address. One style is to generate random source addresses, the
By very defintion of a SYN flood, the source address has to be
forged.
| other is to take a user-specified address. A way around the first style
| is this:
A randomly generated source address would be a horrible idea. You
have a better than even chance of generating one that is reachable.
| If the max number of connects per unit time is passed, stop the server
| for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on
| that port. Any that can't be reversed should be immediately dropped.
A host may have DNS entries and still be unreachable (and vice
versa).
| Once you're back under the limit, restart the server.
SYN flooding doesn't attack TCP-based servers so much as it
attacks the TCP kernel. The monitoring and actions taken
should reflect this...
| You could get around the second style by specifying a max number of
| connects to accept from any one site at a time. However, passing this
| limit would not shut down the server, it would just deny that site until
| it was back under limit.
Bad idea. You cannot control any aspects of the Internet past yur
box (or boxes). Therefore, you cannot control which hosts will go
down. (Aside: I've thought about coding a SYN flooder that plays
two reachable hosts off each-other. It floods both, exactly at
the same time, each SYN-ladden packet purporting to come from the
other host on it's flooded port.)
| The more I think about this though, the more it seems this would be
| better implemented in TCP wrappers (tcpd). It doesn't seem TOO difficult
| to do, although I'm not sure if you would have to do anything in kernel
The best way to do this is in the kernel. Briefly: A list of
concurrent pending connection requests needs to be kept for
each TCP port that is listen()ing. When this number of
connection requests reachs n (n==backlog, or n==backlog-1)
it does a few other checks, like perhaps the time in which all
of these arrived (connections that arrive very close together
would be indicative of a SYN flood) and it waits a few seconds.
if the state does not proceed into SYN_SENT or CLOSED it frees
the associated memory and tears down all the connection requests.
The n value should be different for different ports. TCP/80 for
example, would see it being higher...
| space too. For instance, if you have a connect that is in state
| SYN_RECV, can you just arbitrarily drop it, or do you have to wait for
| something to timeout in the TCP code?
The TCP Connection-Establishment timer of 75 seconds causes
connections to time out. In Linux however, this is not the
case. Below is an excerpt from my whitepaper I did on TCP
SYN flooding (from Project Neptune available in the next
issue of Phrack).
- ------------------------------------Excerpt-------------------------------
--[ Linux Anomaly ]--
In doing my research for this project, I noticed a very strange
implementation error in the TCP module of Linux. When a particular TCP
server is flooded on a Linux host, strange things are afoot... First, it
appears that the connection-establishment timer is broken. The 10 spoofed
connection-requests keep the sockets in the SYN_RCVD state for just
over 20 minutes (23 minutesto be exact. Wonder what the signifigance of
this is... Hmmm...). Much longer than the 75-seconds it *should* be. The
next oddity is even more odd... After that seemingly arbitrary time period
(I have to determine what the hell is going on there), TCP moves the flooded
sockets into the CLOSE state, where they *stay* until a connection-request
arrives on a *different* port. If a connection-request arrives on the
flooded port (now in the CLOSE state), it will not answer, acting as if it
is still flooded. After the connection-request arrives on a different port,
the CLOSEd sockets will be destroyed, and the original flooded port will be
free to answer requests again. It seems as though the connection-request
will spark the CLOSEd sockets into calling listen()... Damn wierd if you ask
me...
The implications of this are severe. I have been able to completely
disable all TCP based servers from answering requests indefinitely. If all
the TCP servers are flooded, there are none to recieve the valid connection
request to alleviate the CLOSE state from the flooded connections. Bad
news indeed.
- ------------------------------------Excerpt-------------------------------
I have since learned a few things from Erik Schenk...
1) The Linux TCP kernel does not directly setup timers for connection
establishment or keepalive timeouts.
2) The Linux TCP kernel counts retransmissions.
3) It takes 15 retransmission before a pending connection request is
torn down. This is 1389 seconds, or 23 minutes...
This is to say that a Linux box is painfully vulnerable to
SYN floods. There is a patch in the works...
- --
[ route@infonexus.com ] Editor, Phrack Magazine / Guild Corporation Chair
the greatest trick the devil ever pulled was
convincing the world he didn't exist
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMhyBbQtXkSokWGapAQFZwgQAl6oljDTIflypKJRSXvCfkzwOIK7rU4Uq
t+lkIfnqsLMxH1hgSGxOIUaV2lA7gn6wdesKoDxqv9xpKAU7PpyfpQxZkTdVyGTS
nffv0wz8tRy3YxW2Od1mDf+a3RxfHSF61jPQB0GgvJYovZDg1Abp+0ovSosuQ01k
yldDUV3ofvo=
=j+7P
-----END PGP SIGNATURE-----
