May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

SYN cookies

News  SYN Flooding Recommended Links Network Utilities
DoS Attacks TCP handshake Humor Etc

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:

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

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

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.

Top Visited
Past week
Past month


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

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

asked Nov 17 '12 at 17:59

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.

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

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

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

Google matched content

Softpanorama Recommended

Top articles


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



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


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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


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


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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


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