Hi,
tcp(7) has this to say about syncookies:
tcp_syncookies
Enable TCP syncookies. The kernel must be compiled with
CONFIG_SYN_COOKIES. Send out syncookies when the syn backlog
queue of a socket overflows. The syncookies feature attempts
to protect a socket from a SYN flood attack. This should be
used as a last resort, if at all. This is a violation of the
TCP protocol, and conflicts with other areas of TCP such as
TCP extensions. It can cause problems for clients and relays.
It is not recommended as a tuning mechanism for heavily loaded
servers to help with overloaded or misconfigured conditions.
For recommended alternatives see tcp_max_syn_backlog,
tcp_synack_retries, tcp_abort_on_overflow.
syncookies are not a violation of the TCP protocol. They are just a
particular, but legal, choice of initial sequence numbers that eliminates
the need for a backlog. They do not cause problems for clients or relays.
How could they? They are just ordinary SYNACK packets, for God's sake.
It is true that a connection established using syncookies cannot use large
windows. This is however not a problem, because the connection would have
been completely lost without syncookies (because we only send them if the
backlog is full).
Syncookies are the only true defence against a SYN flood (the suggested
alternatives only make the attack more expensive).
There is, however, a real problem with syncookies; so why not eliminate the
misinformation and write about it instead?
Syncookies make 'bounce SYNACK flooding' possible. An attacker could flood a
syncookie-using server with spoofed SYN packets, to which the server would
respond with a SYNACK flood to the spoofed source.
I realize that DJB, one of the inventors of syncookies, is not popular,
perhaps not entirely without reason, but that hardly justifies spreading
misinformation about his work/code (which is nonetheless often done by
people he offended, and there are quite a few).
You are encouraged to refer to "SYN cookie monsters" under
http://cr.yp.to/syncookies.html for more details.
Note that I'm not a rabid DJB-fan or suchlike, so please don't dismiss the
above as a rant from a djb zealot.
Best regards,
Andras
Hello Andras, Could you please propose a specific patch? I don't think this bug is going to progress at all otherwise. BTW, I think TCP SYN,ACK flooding is possible without syncookies. Some machine sends packets with a spoofed "source" address and destination address and port of listening servers causing those servers to all respond to the (single) source address, which is the victim of the attaack. It doesn't matter if the victim is using syncookies, since they aren't receiving syn but syn,ack. If the servers are using a syncookie algorithm, they will still send syn,ack to the victim, causing just as much damage to it, but perhaps somewhat less to themselves, but this doesn't matter since the strength of the attack comes from the large number of machines all sending syn,ack responses. Or do you just mean that the attack is even more potent since the server has an essentially infinite syn queue, so can send more syn,ack to the victim?
On Sat, Jan 06, 2007 at 04:54:13PM -0500, Justin Pryzby wrote: Hi, I include the patch inline at the end. Note that I published a 'RESPIRE' (resource efficient synflood protection for internet routers and end-systems) algorithm in 2004 which actually filters incoming synfloods, but I'm not sure if it'd be appropriate to point that out in tcp(7) even though a Linux implementation is available and actually works. Of course, that's what I'd say, isn't it? :) Sure. Syncookies just make it easier, because the server(s) won't run out of SYNACKs, so the victim can receive an endless stream of them. Exactly. Andras Patch:--->8--- --- tcp.7 2007-01-06 23:43:02.000000000 +0100 +++ tcp.correct_syncookies.7 2007-01-07 00:01:02.051515105 +0100 @@ -8,11 +8,13 @@ .\" Modified, 2004-11-11, Michael Kerrisk and Andries Brouwer .\" Updated details of interaction of TCP_CORK and TCP_NODELAY. .\" +.\" Description of syncookies corrected by Andras Korn 2007-01-06. +.\" .\" FIXME 2.6.17-rc1 adds the following /proc files, which need to be .\" documented: tcp_mtu_probing, tcp_base_mss, and .\" tcp_workaround_signed_windows .\" -.TH TCP 7 2005-06-15 "Linux Man Page" "Linux Programmer's Manual" +.TH TCP 7 2007-01-06 "Linux Man Page" "Linux Programmer's Manual" .SH NAME tcp \- TCP protocol .SH SYNOPSIS @@ -465,12 +467,31 @@ Enable TCP syncookies. The kernel must be compiled with .BR CONFIG_SYN_COOKIES . Send out syncookies when the syn backlog queue of a socket -overflows. The syncookies feature attempts to protect a -socket from a SYN flood attack. This should be used as a -last resort, if at all. This is a violation of the TCP -protocol, and conflicts with other areas of TCP such as TCP -extensions. It can cause problems for clients and relays. -It is not recommended as a tuning mechanism for heavily +overflows. Syncookies eliminate the need for the server to allocate +state for half-open TCP connections, so that disabling a TCP service +by filling the backlog with half-open connections becomes impossible. +The server is always able to reply to incoming SYN packets with SYN +ACK packets, so all connection attempts can succeed. +The downside is that connections saved by syncookies cannot use +TCP extensions like large windows; however, considering that the +connections would have been lost otherwise, this may be an acceptable +trade-off. + +Another problem with syncookies is that they exacerbate the problem +of bounce SYNACK flooding. Because a server that uses syncookies +has, for all practical purposes, an infinite TCP backlog, it can pump +out SYNACK replies to all incoming SYN packets. If an attacker floods +your server with SYN packets from a spoofed source address, your server +will flood that address with SYNACK packets. + +If your bandwidth is asymmetric (e.g. because you have an ADSL connection), +syncookies may turn an incoming SYN flood into a bandwidth attack against +your upstream connection. If the intensity of the incoming flood is not +enough to flood your downlink, the uplink may still become congested due to +the outgoing SYNACK flood. Traffic shapers will often treat ACK packets +preferentially, lending this attack even more potency. + +Syncookies are not recommended as a tuning mechanism for heavily loaded servers to help with overloaded or misconfigured conditions. For recommended alternatives see .BR tcp_max_syn_backlog , @@ -858,3 +879,5 @@ RFC\ 2581 for TCP congestion control algorithms. .br RFC\ 2018 and RFC\ 2883 for SACK and extensions to SACK. +.br +http://cr.yp.to/syncookies.html for the syncookie algorithm. ---8<---
Hi Andi, Since you wrote much of the text of tcp.7, I thought it might be best to consult you. Would you be willing to take a look at the patch proposed here, and comment? For the full thread, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253588 Cheers, Michael Andras Korn wrote:
I don't think such a detailed discussion fits into the manpage. It drowns the other information and doesn't fit. If you want to change anything just say that syncookies are deprecated and shouldn't be used anymore.
They are far from deprecated; they are the only widely available defense against synfloods that is actually effective. There just are some caveats, which I tried to point out in my proposed patch. What do the others think? Should I write an abridged version? Andras
On Mon, Jan 08, 2007 at 03:19:47PM +0100, Andi Kleen wrote: Hi, It's been two weeks and no actual arguments were voiced for or against my proposed patch. tcp.7 contains bad FUD about syncookies, which is a disgrace. Nothing shipped by Debian should contain FUD. See the wikipedia article at http://en.wikipedia.org/wiki/Syncookies which also says that 'The use of SYN Cookies does not break any protocol specifications, and therefore should be compatible with all TCP implementations.' This is actually a well-known fact in the security community, which makes the presence of the FUD in tcp.7 all the more appalling. If you have any more technical concerns, I can refer you to peer-reviewed papers that deal with anti-synflood mechanisms. You won't find any that support the view that '[syncookies are] a violation of the TCP protocol.' No arguments have been brought forth to support this view in this thread either. Please, remove the FUD. I'd be happy to help, so if you don't like my proposed text, tell me how it should be different (e.g. shorter); but let's not wait another three years, shall we? Andras
tcp_syncookies (Boolean)
Enable TCP syncookies. The kernel must be compiled with CON-
FIG_SYN_COOKIES. Send out syncookies when the syn backlog queue
of a socket overflows. The syncookies feature attempts to pro-
tect a socket from a SYN flood attack. This should be used as a
~~~~~~~~~~~~~~~~~~~~~~~~
last resort, if at all. This is a violation of the TCP proto-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
col, and conflicts with other areas of TCP such as TCP exten-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sions. It can cause problems for clients and relays. It is not
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
recommended as a tuning mechanism for heavily loaded servers to
help with overloaded or misconfigured conditions. For recom-
mended alternatives see tcp_max_syn_backlog, tcp_synack_retries,
and tcp_abort_on_overflow.
I underlined the FUD.
Summary of facts:
- syncookies are a particular choice of initial sequence number. A host is
allowed to choose its inital sequence number. No violation there.
- as for the conflict: indeed, a connection saved by syncookies cannot use
large windows. But the connection would have been lost without syncookies,
because the backlog has to be full for syncookies to be used. So
effectively, you are saying that while syncookies 'conflict with TCP
extensions', dropping the connection attempts does not.
- because initial sequence numbers are arbitrary, a particular choice of
sequence number cannot cause problems for clients or relays, because they
can't assume anything about the ISN anyway.
- actually, there is no other working mechanism in the Linux kernel that
would allow a host to weather a syn flood while still being able to provide
TCP service on the attacked ports. (I guess you could come up with something
very complicated using tc, but that would still drop legitimate connections
from the same subnet as the attack.) Therefore, the best advice is in fact
to _enable_ syncookies unless the server has asymmetric bandwidth, with
upstream being much less than downstream.
But I'd be interested in hearing your arguments.
Andras
I don't see any FUD in there
Hey, you actually _wrote_ much of the Linux syncookie implementation. Now I'm really interested in knowing why you changed your mind about them. And the manpage should definitely include your arguments, if they are valid, which I still doubt. Andras
Seeing Andi's hostile and dismissive stance in this bug report it seems unlikely that he'd make a useful contribution; however, I'd like to refer the interested reader to this 2008 LWN article: https://lwn.net/Articles/277146/ -- it explains why syncookies are still a good thing to have, Andi's objections notwithstanding. Meanwhile, tcp(7), after all these years, still claims syncookies are "a violation of the TCP protocol", which is still false. Can the maintainer please accept my patch, or tell me how to change it so that it can be accepted? Andras