On Thu, 23 Dec 1999, Chuck Phillips wrote:
> Date: Thu, 23 Dec 1999 22:26:58 -0700 (MST)
> From: Chuck Phillips <cdp@peakpeak.com>
> To: linux-kernel@vger.rutgers.edu
> Subject: SYN-flooding Linux (on BUGTRAQ was "Re: Various Errors in Slackware")
>
> David,
>
> Sorry for picking on you, but IMHO, this thread needs to be redirected to
> the linux kernel mailing list where it's more likely to get fixed.
>
> David Ford writes:
> > I would check with Alan on the SYN cookies, iirc, there is a good reason why
> > SYN cookies are not turned on by default. In 2.3.x it is not turned on by
> > default in the kernel compile and again must be explicitly enabled in /proc
> > after adding it to the kernel.
> >
> > According to the Configure.help:
> > If you are SYN flooded, the source address reported by the kernel is
> > likely to have been forged by the attacker; it is only reported as
> > an aid in tracing the packets to their actual source and should not
> > be taken as absolute truth.
>
> Note that this has nothing to do with turning on SYN cookies and everything
> to do with the nature of SYN flooding. If the source address isn't forged,
> then it's probably not SYN flooding, at least, not very *effective* SYN
> flooding. Ideal SYN flood source addresses (from the cracker's
> perspective) are many different IP addresses for which no RST's or various
> ICMP messages will be returned. Now that I think about it, a
> typically-configured *firewall* (one that drops everything without reply)
> is possibly the very best source address. Collect a lot of these firewall
> IP addresses and you're all set -- with false alarms on the firewalls as a
> secondary effect. :-(
Note that there are two logics here (if you could really think that),
technical validity and political validity. Technically minded folk
understand the hows and whys of the SYN flood. Others pop off angry or rude
emails to a variety of supposed origin sites that are "flooding" them.
> Aside: When diagnosing possible SYN floods, it's not enough to check for a
> huge number of incoming SYN's or even many dropped connections -- like at
> least one commercial IDS does. This could simply be the result of a _very
> busy site_ receiving more valid connection requests than it can handle.
Here is where the below paragraph came into play, false positives.
Uninformed people would them complain (sometimes quite rudely) to the
supposed source of the attack.
> NAT-based load balancers actually can make this worse if the balancer
> itself can't keep up. When evaluating capacity of a load balancer, check
> whether the number of benchmark destination hosts exceeds the number *one*.
> (It's been done.:-) Also check the number of simultaneous connections.
> Throughput in an unrealisticly optimistic scenario isn't very useful.
> Likewise for firewalls, check the capacity with refragmentation turned
> *on*. (Some don't even offer this as an option!)
>
>
> > SYN cookies may prevent correct error reporting on clients when the
> > server is really overloaded. If this happens frequently better turn
> > them off.
>
> It would be nice to know exactly *how* things are supposed to fail when
> this happens instead of just knowing they *might*. Briefly looking at the
> code, I see the algorithm depends on calls to a random number generator
> which *tends* to be expensive. I would *expect* more CPU overhead as a
> result. This could be bad for an already overloaded machine, but as you
> said, Alan is probably the person to answer this one.
Statistics are a heavily desired item, i love them. Knowing how they come
about is also desirable.
> What I can say is that a co-worker and I recently did tests of Apache,
> squid and telnet connections during massive syn-flooding with and without
> syn-cookies on a test network. (By massive, I mean random source addresses
> on a test network with 100BTX end-to-end connections.) Without syn
> cookies, *all* of these services became unavailable pretty quickly and it
> took almost ten minutes after the flooding ceased before the server fully
> recovered. With syn-cookies turned on, squid and Apache ran a little
> slower but otherwise were unaffected. Telnet "worked" but was so slow as
> to be unusable for all practical purposes. (I expect this has something to
> do with delays every 1-2 characters for telnet vs. per almost 1500
> characters for HTTP.)
I run several servers that do a plethura of things. I have been attacked a
number of times in the past, probably more than most here. SYN cookies DO
keep the daemons alive.
> As a result, I'm thinking syn-cookies should be enabled by default,
> *perhaps* unless the server is underpowered (and there already is a
> separate configuration parameter for this). This means a documentation
> change at the very least and a small change at most.
If the server is that underpowered, SYN cookies or not, it's going down.
imho, syn cookies should be on. Or at least on by default along with a
variety of other things for a "server" policy. Perhaps it's time to add a
function in the config dependancies to have a template configuration of
default items by selecting the type of machine this kernel is going on?
> What I would really be interested in knowing is which magic linux kernel
> parameter(s) need to be tweaked to increase the maximum number of half-open
> SYN connections. On _similar x86 hardware_, Linux 2.2.14pre13 handled less
> than 500 simultaneous connections while a Solaris 8 beta handled a little
> over 4,000 without missing a beat. 500 simultaneous connections isn't a
> lot. In the real world of extremely busy servers, end-to-end bandwith
> tends to be much lower than our most *unreal* test case -- and as a direct
> result -- the number of valid simultaneous connections can easily exceed
> 500 on popular sites.
Without looking at the code again...in the past, it was a staticly chosen
size. We have to be careful about this because this code is in the fast
path and increasing the table size for the cookies can have a direct impact
on the fast path latency.
-d
--
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/