3

For Linux kernel 2.6.32 if I set net.ipv4.tcp_syncookies = 1 will that be always used or only during a SYN flood attack?

I found 2 sources which say the opposite.

1:

"There are, however, two caveats that take effect when SYN cookies are in use. Firstly, the server is limited to only 8 unique MSS values, as that is all that can be encoded in 3 bits. Secondly, the server must reject all TCP options (such as large windows or timestamps), because the server discards the SYN queue entry where that information would otherwise be stored. [1]

While these restrictions necessarily lead to a sub-optimal experience, their effect is rarely noticed by clients because they are only applied when under attack. In such a situation, the loss of the TCP options in order to save the connection is usually considered to be a reasonable compromise."

2:

"The downside is that not all TCP data can fit into the 32-bit Sequence Number field, so some TCP options required for high performance might be disabled." This means that options such as selective ACKs and TCP Window Scaling won't work if you turn on SYN Cookies, even if your server isn't currently under attack."

PhilR
  • 483
  • 1
  • 4
  • 14
defiler
  • 31
  • 3
  • 3
    I think it would be a good idea to mention where you got those two quotes from. – kasperd Sep 30 '15 at 10:37
  • 1
    Those two sources don't say the opposite. One says syn cookies are only sent when under attack. The other says that enabling syn cookies prevents selective ACK and TCP window scaling from working even when the server isn't under attack. Quite possibly, it's precisely because what the first source says is true that the second source needs to point out that this happens regardless of whether the server is under attack or not. (If that never made any difference, why point out specifically in this case that it doesn't?) – David Schwartz Sep 30 '15 at 10:51

1 Answers1

2

The second source

"this means that options such as selective ACKs and TCP Window Scaling won't work if you turn on SYN Cookies, even if your server isn't currently under attack"

is simply bullshit, until

"TCP: request_sock_TCP: Possible SYN flooding on port 53. Sending cookies. Check SNMP counters"

happens there is nothing disabled.

This is easy provable by comparing your performance with iperf3 and enabling/disabling "net.ipv4.tcp_sack" and "net.ipv4.tcp_window_scaling" while keep "net.ipv4.tcp_syncookies = 1" enabled.

Why do you read random sources instead the official ones? https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

tcp_syncookies - BOOLEAN
    Only valid when the kernel was compiled with CONFIG_SYN_COOKIES
    Send out syncookies when the syn backlog queue of a socket
    overflows. This is to prevent against the common 'SYN flood attack'
    Default: 1

    Note, that syncookies is fallback facility.
    It MUST NOT be used to help highly loaded servers to stand
    against legal connection rate. If you see SYN flood warnings
    in your logs, but investigation shows that they occur
    because of overload with legal connections, you should tune
    another parameters until this warning disappear.
    See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.

    syncookies seriously violate TCP protocol, do not allow
    to use TCP extensions, can result in serious degradation
    of some services (f.e. SMTP relaying), visible not by you,
    but your clients and relays, contacting you. While you see
    SYN flood warnings in logs not being really flooded, your server
    is seriously misconfigured.
PhilR
  • 483
  • 1
  • 4
  • 14