SYN cookies

• 1 Implementation
• 2 Drawbacks
• 3 History
• 4 See also
• 5 References

SYN cookies are the key element of a technique used to guard against SYN flood attacks. It was invented by Daniel J. Bernstein and Eric Schenk in September 1996.,  who defines SYN cookies as "particular choices of initial TCP sequence numbers by TCP servers.". The first implementation (for SunOS) was released by Jeff Weisberg a month later, and Eric Schenk released his Linux implementation in February 1997 (the current implementation uses e.g. net.ipv4.tcp_syncookies).

In particular, the use of SYN cookies allows a server to avoid dropping connections when the SYN queue fills up. Instead, the server behaves as if the SYN queue had been enlarged. The server sends back the appropriate SYN+ACK response to the client, but discards the SYN queue entry. If the server then receives a subsequent ACK response from the client, the server is able to reconstruct the SYN queue entry using information encoded in the TCP sequence number.

So SYN cookie is not some special file or record in a file like is case with http cookies, but a specially constructed the initial TCP sequence number.

In order to initiate a TCP connection, the client sends a TCP SYN packet to the server. In response, the server sends a TCP SYN+ACK packet back to the client. One of the values in this packet is a sequence number, which is used by the TCP to reassemble the data stream.

According to the TCP specification, that first sequence number sent by an endpoint can be any value as decided by that endpoint. SYN cookies are initial sequence numbers that are carefully constructed according to the following rules:

• let t = A  slowly incrementing timestamp (typically time() logically right-shifted 6 positions, which gives a 64 second resolution)
• let m = The maximum segment size (MSS) value that the server would have stored in the SYN queue entry
• let s = The result of a cryptographic hash function computed over the server IP address and port number, the client IP address and port number, and the value t. The returned value s must be a 24-bit value.

The initial TCP sequence number, i.e. the SYN cookie, is computed as follows:

• First 5 bits: t mod 32
• Next 3 bits: an encoded value representing m
• Final 24 bits: s

(Note: since m must be encoded using 3 bits, the server is restricted to sending up to 8 unique values for m when SYN cookies are in use.)

When a client sends back a TCP ACK packet to the server in response to the server's SYN+ACK packet, the client MUST (according to the TCP spec) use n+1 in the packet's Acknowledgement number, where n is the initial sequence number sent by the server. The server then subtracts 1 from the acknowledgement number to reveal the SYN cookie sent to the client.

The server then performs the following operations.

• Checks the value t against the current time to see if the connection is expired.
• Recomputes s to determine whether this is, indeed, a valid SYN cookie.
• Decodes the value m from the 3-bit encoding in the SYN cookie, which it then can use to reconstruct the SYN queue entry.

From this point forward, the connection proceeds as normal.

The use of SYN cookies does not break any protocol specifications, and therefore is compatible with all TCP implementations. There are, however, two caveats that take effect when SYN cookies are in use. First, the server is limited to only 8 unique MSS values, as that is all that can be encoded in 3 bits. Second, the server must reject all TCP options (such as large windows), because the server discards the SYN queue entry where that information would otherwise be stored.

These restrictions does not matter much and their effect is rarely noticed by clients. Furthermore, these restrictions need only apply when the server is under attack, and the connection would have otherwise been denied. In such a situation, the loss of a few of the more esoteric TCP/IP options in order to save the connection is a very reasonable compromise. Version 2.6.26 of the Linux kernel added limited support of TCP options, by encoding them into the timestamp.

NEWS CONTENTS

• 200102 : linux - A lot of TCP time wait bucket table overflow in CentOS 6 - Server Fault ( linux - A lot of TCP time wait bucket table overflow in CentOS 6 - Server Fault, )
• 200102 : Tricky net.ipv4 variables in sysctl.conf ( Tricky net.ipv4 variables in sysctl.conf, )
• 200102 : SYN cookies by D. J. Bernstein ( SYN cookies, )

Old News ;-)

linux - A lot of TCP time wait bucket table overflow in CentOS 6 - Server Fault

we have the following output from dmesg:

__ratelimit: 33491 callbacks suppressed
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow

Also we have the following setting:

cat /proc/sys/net/ipv4/tcp_max_tw_buckets
524288

We are under some kind of attack, but we could not detect what cause this problem?

linux tcp centos6 asked Nov 17 '12 at 17:59

divaka
132 We increased /proc/sys/net/ipv4/tcp_max_tw_buckets to 720000 but with no luck – divaka Nov 17 '12 at 18:12

Is there any reasonable limit of the above setting? We increased it to 1000000 and now the things look very well by now? – divaka Nov 17 '12 at 19:13

If you increase it, the attack will do more harm since you are allowing it to consume more memory. Is there some good reason you are increasing it? (Do you have plenty of memory to spare?) – David Schwartz Nov 18 '12 at 1:05

Try the following commands to determine if you have a lot of connections coming from one address or if you are under a distributed attack.

netstat -nt | cut -c 40- | cut -d: -f1 | sort | uniq -c | sort -n
netstat -nt | cut -d: -f2 | sort | uniq -c | sort -n

If you have high numbers from a few IP addresses it will be easier to limit the connections. You can then add deny rules or rate-limit rules to iptables to limit access from these addresses.

If you are under attack you may want to get your ISP involved as they can limit connections before they reach you.

Tricky net.ipv4 variables in sysctl.conf

Hello everybody,

This question is probably for tcp/linux kernel experts.

I am in process of installing mail server which potentially will serve for 10000 of users, so every aspect of kernel tuning is quite important for me, I have 2 cpu (Opteron) server running on CentOS 5.2 64bit with 16GB of RAM. I will have mysql database and spamassassin running on this server.

So I am trying to tune some net.ipv4 and kernel variables to handle a high load.

I must say that I familiarised myself with documentation about every variable which I am trying to tune and I know what it's trying to change:
I was reading this manual.
http://ipsysctl-tutorial.frozentux.n...-tutorial.html

I am interested only in this list of variables:

What do you think should you turn this on in my case?

net.ipv4.tcp_syncookies = 1
Are those numbers look right for my case?
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 3600

On some websites it's written that you shouldn't turn on those parameters when tcp_syncookies are on.
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_fack = 1

Should be this enabled in my case?
net.ipv4.tcp_timestamps = 1

Are those numbers right for my amount of ram?

net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.ip_local_port_range = 32768 61000 - is it the right amount of local ports for 10000 clients?

Are there any formulas that are helping you to calculate those numbers.(I wasn't able to find this information).

net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536

Maybe you know any other variables which I should tune in my case?

For ex.
kernel.shmmax = 1073741824 - will it be enough for me?

SYN cookies by D. J. Bernstein

cr.yp.to

Mail service for Panix, an ISP in New York, was shut down by a SYN flood starting on 6 September 1996. A week later the story was covered by the RISKS Digest, the Wall Street Journal, the Washington Post, and many other newspapers.

SYN flooding had been considered by security experts before. It was generally considered insoluble. See, for example, "Practical UNIX and Internet Security,'' by Garfinkel and Spafford, page 778:

The recipient will be left with multiple half-open connections that are occupying limited resources. Usually, these connection requests have forged source addresses that specify nonexistent or unreachable hosts that cannot be contacted. Thus, there is also no way to trace the connections back. ... There is little you can do in these situations. ... any finite limit can be exceeded.

Large SYN queues and random early drops make SYN flooding more expensive but don't actually solve the problem.

SYN cookies use cryptographic techniques to solve the problem. I pointed out how easy this was on 16 September 1996; Eric Schenk and I worked out the gory details over the next few weeks. Jeff Weisberg released a SunOS implementation in October 1996, and Eric Schenk released a Linux implementation in February 1997.

SYN cookies are now a standard part of Linux and FreeBSD. They are, unfortunately, not enabled by default under Linux. To enable them, add

     echo 1 > /proc/sys/net/ipv4/tcp_syncookies

to your boot scripts.

What are SYN cookies?

SYN cookies are particular choices of initial TCP sequence numbers by TCP servers. The difference between the server's initial sequence number and the client's initial sequence number is

• t mod 32, where t is a 32-bit time counter that increases every 64 seconds;
• an encoding of an MSS selected by the server in response to the client's MSS;
• a server-selected secret function of the client IP address and port number, the server IP address and port number, and t.

This choice of sequence number complies with the basic TCP requirement that sequence numbers increase slowly; the server's initial sequence number increases slightly faster than the client's initial sequence number.

A server that uses SYN cookies doesn't have to drop connections when its SYN queue fills up. Instead it sends back a SYN+ACK, exactly as if the SYN queue had been larger. (Exceptions: the server must reject TCP options such as large windows, and it must use one of the eight MSS values that it can encode.) When the server receives an ACK, it checks that the secret function works for a recent value of t, and then rebuilds the SYN queue entry from the encoded MSS.

A SYN flood is simply a series of SYN packets from forged IP addresses. The IP addresses are chosen randomly and don't provide any hint of where the attacker is. The SYN flood keeps the server's SYN queue full. Normally this would force the server to drop connections. A server that uses SYN cookies, however, will continue operating normally. The biggest effect of the SYN flood is to disable large windows.

Blind connection forgery

If an attacker guesses a valid sequence number sent to someone else's host then he can forge a connection from that host.

Attackers can try to cryptanalyze the server-selected secret function: inspect a series of valid cookies and then intelligently guess a new cookie. For a secure function, the attacker's chance of success is not noticeably better than the chance of success for a uniform random guess. Secret-key message authenticators are designed to provide exactly this type of security. The following function is extremely fast and appears to be secure: encode the input in 16 bytes; feed the result through Rijndael with a secret key; extract the first 24 bits of the result.

No matter what function is used, the attacker will succeed in a connection forgery after millions of random ACK packets. Servers can make this attack more expensive in two ways:

• Keep track of the most recent SYN queue overflow time (for each SYN queue, not in a global variable). Don't rebuild missing SYN entries if there hasn't been a recent overflow. This stops ACK forgeries from passing through SYN-blocking firewalls.
• Add another number to the cookie: a 32-bit server-selected secret function of the client address and server address (but not the current time). This forces the attacker to guess 32 bits instead of 24.

A new protocol with 128-bit sequence numbers would make blind connection forgeries practically impossible.

Who invented SYN cookies?

As far as I know, Phil Karn was the first to design an Internet protocol that used cookies to protect against blind denial-of-service attacks. But the idea is much older than this. Cookies can be found in sweepstakes mailings, for example.

I think I was the first to point out that TCP servers can use cookies without any changes to the TCP protocol. (Perry Metzger subsequently claimed that he had pointed this out earlier. However, Metzger didn't respond when I asked him for copies of the relevant messages. NANOG archives show that Metzger stated on 9 September 1996 that cookies would require a new "TCP++'' protocol, and on 17 September 1996 that ISPs had to filter their outbound packets.)

My first proposal didn't comply with the TCP requirement to use increasing initial sequence numbers. Eric Schenk had the idea of adding something to the client's initial sequence number.

I proposed time-dependent SYN cookies. The time dependence prevents attackers from (1) collecting valid cookies at a public computer and subsequently (2) reusing the cookies in a blind attack from somewhere else.

SYN cookie monsters

A few people (notably Alexey Kuznetsov, Wichert Akkerman, and Perry Metzger) have been spreading misinformation about SYN cookies. Here are some of their bogus claims:

• SYN cookies "present serious violation of TCP protocol.'' Reality: SYN cookies are fully compliant with the TCP protocol. Every packet sent by a SYN-cookie server is something that could also have been sent by a non-SYN-cookie server.
• SYN cookies "do not allow to use TCP extensions'' such as large windows. Reality: SYN cookies don't hurt TCP extensions. A connection saved by SYN cookies can't use large windows; but the same is true without SYN cookies, because the connection would have been destroyed.
• SYN cookies cause "massive hanging connections.'' Reality: With or without SYN cookies, connections occasionally hang because a computer or network is overloaded. Applications deal with this by simply dropping idle connections.
• SYN cookies cause "serious degradation of service.'' Reality: SYN cookies improve service. They do take a small amount of CPU time to compute, but that CPU time has to be spent anyway for hard-to-predict sequence numbers; see RFC 1948.
• SYN cookies cause "magic resets.'' Reality: SYN cookies never cause resets.

These people also have the annoying habit of crediting their bogus claims to other people, such as me. I don't know whether to attribute this to malice or stupidity; either way, I would like the record to be set straight.

I invited Kuznetsov to either retract or defend his claims. He refused to do so. I'm sure he's aware by now that his claims are false, and that any attempted defense will be promptly ripped to shreds; but he's still not admitting his errors. It's unfortunate that he doesn't have more respect for the truth.

I also invited Akkerman to either retract or defend his claims. He did not respond.

Recommended Links

Softpanorama Recommended

Top articles

Sites

CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks

SYN flood - Wikipedia, the free encyclopedia

SYN cookies by D. J. Bernstein

SYN cookies - Wikipedia, the free encyclopedia

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019