[1083] in linux-security and linux-alert archive
Re: [linux-security] inetd and denial-of-service
daemon@ATHENA.MIT.EDU (Racer X)
Mon Aug 26 07:32:02 1996
Date: Sun, 25 Aug 1996 21:17:13 -0400 (EDT)
From: Racer X <shagboy@wspice.com>
Reply-To: shagboy@bluesky.net
To: infinity <route@infonexus.com>
cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199608221549.IAA15611@onyx.infonexus.com>
On Thu, 22 Aug 1996, infinity wrote:
> | >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.
No, it doesn't. Any hacker with any intelligence will forge it, but it
doesn't HAVE 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.
I'm not following you. First off, why would a randomly generated address
be a horrible idea? Why any worse than (say) the IP for
www.whitehouse.gov? And better than even? I don't think so. Not when
you consider that class A nets 57-126 are all "reserved", as are a bunch
of others.
> | 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).
That's not my point. The point is, if they DO have DNS entries, they are
much more likely to be legit than if they don't. Everyone, EVERYONE,
should be running DNS and have reverse maps. We (and lots of other
people) don't allow connects from hosts that can't be reversed.
> | 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.)
Again, I'm confused. I don't get the "which hosts will go down" part.
On the attacker's end, or yours?
> | 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...
Right, do it in the kernel and have something similar to ipfwadm to throb
the settings for each port. The only problem is, according to Alan Cox:
[me]
> > same problem, but it hits inetd instead. My question is - can a
> > connection that is in state SYN_RECV be arbitrarily terminated at any
> > time, or does it have to wait for the timeout in the TCP code?
[Alan]
> It cannot be terminated for the TIME_WAIT period without the risk of data
> corruption on other connections. So you are stuck with it for at least 2
> minutes (probably 4 to be right). BSD locks this to 75seconds +
> TIME_WAIT which isnt a bad plan so long as you don't plan to operate
> over amateur radio, into space and other unusual links
I'm not clear on why you have to wait for the timeout. I will take
his word for it tho, and see if I can find out exactly why.
> 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...
Could this have anything to do with the latest thread on "2.0.13 Sockets
stuck in close"? It sounds similar.
shag
Judd Bourgeois | When we are planning for posterity,
shagboy@bluesky.net | we ought to remember that virtue is
Finger for PGP key | not hereditary. Thomas Paine
