lkml.org 
[lkml]   [1999]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectSYN-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. :-(

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.
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.


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.)

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.


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.

Suggestions?

Thanks in advance,
Chuck Phillips

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.037 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site