TCP SYN Cookies — DDoS Defence

A TCP SYN Cookie is typ­ic­ally used in DDoS engines and load bal­an­cers to cre­ate another level of pro­tocol secur­ity for Denial of Service attacks. Lets take a quick dive through the tech­no­logy.

What is a SYN Cookie and Why do I want them ?

A SYN cookie is a spe­cific choice of ini­tial TCP sequence num­ber by TCP soft­ware and is used as a defence against SYN Flood attacks.

In nor­mal oper­a­tion, a Client sends a SYN and the Server responds with a SYN+ACK mes­sage, the server will then hold state inform­a­tion in the TCP stack while wait­ing for Client ACK mes­sage. A simple SYN flood (using suit­able soft­ware) will gen­er­ate SYN pack­ets which would con­sume all avail­able TCP memory as the server must main­tain state for all half-​​open con­nec­tions. And since this state table is finite the server will no longer accept new TCP con­nec­tions and thus fail or deny ser­vice to the user¹.

This is highly lever­aged attack since a very small amount of band­width and CPU can exhaust the resources on a large num­ber of servers.

By spe­cific­ally cal­cu­lat­ing the TCP sequence num­ber with a spe­cific, secret math func­tion in the SYN-​​ACK response, the server does not need to main­tain this state table. On receipt of the ACK from the Client, the TCP sequence num­ber is checked against the func­tion to determ­ine if this is a legit­im­ate reply. If the check is suc­cess­ful, then the server will cre­ate the TCP ses­sion and the user con­nec­tion will pro­ceed as normal.

The TCP sequence num­ber at the com­mence­ment of a TCP sequence is nor­mally a ran­dom­ised choice. The TCP sequence is what NMAP uses to identify the OS since it ‘knows’ the some OS’s do not have high qual­ity ran­dom­isa­tion and NMAP uses algorithms to ana­lyse the ISN to ‘guess’ the OS. This is part of the func­tions of a PIX/​ASA fire­wall, it will improve the ran­dom­ness of the ISN to ensure

If the ACK response is not cor­rect the TCP ses­sion is not cre­ated. The effect is that SYN floods will no longer con­sume resources on serv­ers or load balancers/​ This is espe­cially true in high band­width envir­on­ments such as Data Centres.

How should I imple­ment SYN Cookies ?

In gen­eral terms, imple­ment­ing this type of code on serv­ers is a bad idea. The CPU require­ment to deliver the math­em­at­ics for the func­tion cal­cu­la­tion is bey­ond the capa­city of x86 serv­ers (and their OS’s) to reli­ably com­pute on a real time basis². The CPU impact may res­ult in serv­ers not able to deliver applic­a­tions or, at best, to work much more slowly in every circumstance.

The most com­mon imple­ment­a­tion is on load bal­an­cer and DDoS appli­ances, with ded­ic­ated CPU and OS that can pro­cess huge volumes of TCP sequence cal­cu­la­tions without loss of per­form­ance. In this case, the TCP estab­lish­ment is handled by using ses­sion ter­min­a­tion or by ses­sion interception.

DDoS engines³ will also use SYN cook­ies e.g. The Cisco Guard will use SYN cook­ies as a first level of DDoS defence once traffic is diver­ted to the module.

Should you be implementing ?

SYN Cookies is a simple DDoS defence today, and prob­ably suit­able for all Internet host­ing includ­ing mail server and cor­por­ate web servers.

Many DDoS attacks will simply over­run your Internet con­nec­tions with volume since a 100 MB eth­er­net con­nec­tion is now very small com­pared to, for example, 500 com­prom­ised desktops with an aver­age 200 Kbs of band­width each launch­ing an attack will sat­ur­ate your 100Mbs link and there is noth­ing you can do⁴. But a SYN attack can be accom­plished with a 2Mbs DSL line and is unlikely to over­run your band­width (since a SYN packet is 64 bytes).

Alternatives to SYN Cookies

You don’t have to use SYN cook­ies to defend against a SYN flood because most mod­ern fire­walls will mon­itor the state table, and dis­card con­nec­tions once a high water mark has been reached. Of course, smarter fire­walls will look at SYN pack­ets per second per pro­tocol and start to flag an attack plus start to purge half open con­nec­tions to ensure resource avail­ab­il­ity. But they often do not have intel­li­gent routines and may actu­ally dis­card good TCP ses­sions, espe­cially with high volume attacks) and thus cause a degraded ser­vice while the attack continues.

Conclusion

I have to admit that Internet DDoS attacks is some­thing of a spe­cial­ist art, and prac­ti­tion­ers must stay up to date with cur­rent trends. Experience is vital, not only in using the equip­ment, but in recog­ni­tion and identi­fy­ing new attacks. I am not one of them.

TCP SYN cook­ies is use­ful tool for pre­par­ing a defence in medium sized net­works where spend­ing money on a man­aged DDoS ser­vice is not possible.

Feedback

You leave a com­ment below, or head over to the for­ums at http://​eth​er​e​al​mind​.com/forums and start a topic. Look for­ward to hear­ing from you.

Reference

DJ Bernstein has an excel­lent post here which includes a lot of his­tory and it’s early devel­op­ment some­time around 1997.

The Wikipedia is also a good source of inform­a­tion here

A very com­plete defin­i­tion Defenses Against TCP SYN Flooding Attacks, warn­ing this is a deep tech­nical paper — geek meter pegs at eleven. (Thanks to Netfortius on twitter)

Footnotes

1. or worse, buf­fer over­flows or sys­tem memory exhaus­tion has occurred, not so much a prob­lem today [back]
2. although a MSWin /​ Linux server cer­tainly could com­pute the func­tions, its over­all per­form­ance would be severely impacted [back]
3. why are they called engines instead of appli­ances ? I don’t know, thats what I call them. Must be a mar­ket­ing thing [back]
4. at this point you will need to use your ser­vice pro­vider to mit­ig­ate the attack [back]

Please rate this post:

(No Ratings Yet)

 Loading ...