3

In an effort to prevent DDOS attacks I followed suggestions to leave /proc/sys/net/ipv4/tcp_syncookies value set to 1 in my linux box to enable TCP syncookies.

However, when I look at this URL: http://ckdake.com/content/2007/disadvantages-of-tcp-syn-cookies.html

It tells me that if I enable tcp_syncookies then half the tcp features including large window management will be disabled which could then reduce performance.

I read elsewhere that part of the purpose of syn cookies is to expand a tcp syn backlog buffer beyond its upper limit (via /proc/sys/net/ipv4/tcp_max_syn_backlog) when more packets come in so packets don't drop.

I want to be able to disable syn cookies so I can take full advantage of tcp and make my server run faster and continue to not have DDOS attacks. I can easily increase the syn buffer and the maximum connections but I think theres a point where I'll run out of memory if I go too high.

Does anyone have a good alternative method to syn cookies on a heavy server without potentially being attacked by DDOS? I want to enjoy features of TCP and serve content very fast to users.

3 Answers3

5

Ubuntu 10.04 has default "sysctl.d/10-network-security.conf" setting below:

# Turn on SYN-flood protections.  Starting with 2.6.26, there is no loss
# of TCP functionality/features under normal conditions.  When flood
# protections kick in under high unanswered-SYN load, the system
# should remain more stable, with a trade off of some loss of TCP
# functionality/features (e.g. TCP Window scaling).
net.ipv4.tcp_syncookies=1
petertc
  • 2,190
  • 1
  • 13
  • 10
4

Apparently, tcp_syncookies introduces more benefits than disadvantages.

Instead of the typical speculation on random blogs, perhaps we could consult "the source":

With the updates for IPv6 and modern TCP option schemes syncookies appear primed to keep providing sweet relief in their somewhat esoteric networking security niche.

The linked article quotes some experiments and draws some conclusions:

Willy Tarreau: My tests on an AMD LX800 with max_syn_backlog at 63000 on an HTTP reverse proxy consisted in injecting 250 hits/s of legitimate traffic with 8000 SYN/s of noise.[..] Without SYN cookies, the average response time was about 1.5 second and unstable (due to retransmits), and the CPU was set to 60%. With SYN cookies enabled, the response time dropped to 12-15ms only, but CPU usage jumped to 70%. The difference appears at a higher legitimate traffic rate.

Ross Vandegrift: Under no SYN flood, the server handles 750 HTTP requests per second, measured via httping in flood mode. With a default tcp_max_syn_backlog of 1024, I can trivially prevent any inbound client connections with 2 threads of syn flood. Enabling tcp_syncookies brings the connection handling back up to 725 fetches per second.

This data compellingly supports the continued value of the syncookie and that position seems to have won the day. The IPv6 syncookie patches are now queued within the network 2.6.26 development tree.

Also, according to CentOS' documentation, this is used in an adaptive way, possibly in order to avoid disrupting legitimate traffic:

If the number set in tcp_max_syn_backlog is reached, this parameter kicks in so that your server isn't unreachable due to connections waiting for an ACK that will never come.

jmng
  • 140
  • 6
-1

Edit the file /etc/sysctl.conf, run:

# vi /etc/sysctl.conf

Append the following entry:

net.ipv4.tcp_syncookies = 1

Save and close the file. To reload the change, type:

# sysctl -p
Elizabeth Anderson
  • 1
  • Or, to try out the setting without making it permanent in a config file: `sysctl net.ipv4.tcp_syncookies=1`. (Your answer is relevant for a typical visitor here, but would better be a comment on the question as it does not answer the question itself. I guess is that's why somebody downvoted.) – tanius Jan 06 '19 at 20:46