Parsing attacks into pieces: SYN-flood

Spoofed SYN is an attack in which packet headers are faked so that the real sender is replaced by an arbitrary or non-existent IP address.

Since, in essence, SYN is a frequent tool of “ intense competition ” and - at the same time - most DDoS mitigation solutions show impressive effectiveness precisely on this type of attack, we will start a SYN-flood, considering the spoofed-type attack as terrible of them.

Disclaimers

Disclaimer # 1

Everything described in this and subsequent topics is in fact not know-how. All methodologies are open, and at one time or another (some from 2003) were published in open sources. I took the trouble only to reduce them to one and describe a “ global strategy ” of protection focused on system administrators serving small projects located on dedicated servers (the described strategy can be applied in shared projects, but the implementation will be so prohibitively terrible that There is no desire to write about it)

Disclaimer # 2

In the topic hardware protection solutions are not considered - firstly, they are well reviewed in numerous articles by the manufacturers of these same solutions, and secondly, projects that have one server can not often afford them (roughly speaking, the price of working solutions starts from 20 thousand euros ), thirdly, the author does not have sufficient data and experience in working with such specialized hardware to draw global conclusions about the methods and effectiveness of such protection - it is hardly interesting for anyone to review the solutions from two vendors of a dozen, not supported by major operating statistics for their use. But it is worth noting that both hardware solutions that I had to use are usually very effective on SYN attacks when certain conditions are met .

Disclaimer №3

The topic does not consider providers of protection against DDoS attacks - the service engineers of these organizations will be able to describe their working methods better and in more detail. It would probably be worthwhile to review the providers themselves as such - from the client’s point of view (at different times the projects in which I participated were clients of Dragonara, Blacklotus, Gigenet, Vistnet (at the moment), Prolexic (at the moment) and a number of sellers of services of the above companies), but this is out of the scope of the topic, try to talk about it later. Again, it is worth noting that all the protection providers with which the author’s projects are working or working cope with the problem of SYN-attacks, showing good efficiency.
')

Some mechanics and wikipedia

I would not like to turn the topic into a kind of RFC and quote well known truths, so we limit ourselves to what TCP is interesting from the point of view of a SYN attack and go over the tops.

First, TCP is one of the most used transport protocols, on top of which most application protocols reside. Secondly, it has a number of special features (clearly confirming the start and end of the connection, flow control, etc.) - which make its implementation relatively complex and resource-intensive.

In the context of the article, it is interesting to consider the mechanism for establishing a TCP connection — a three-way handshake. In the first approximation at the “client-server” level, it looks like this: the client sends a SYN-packet to the server, to which the SYN + ACK responds. The client sends an ACK to the server's SYN in response and the connection enters the established state.

SYN-attack — Sending a mass of SYN-packets to an open port of a server that does not establish a real connection for one reason or another, which entails creating “half-open connections” that overwhelm the connection queue, forcing the server to deny service to other clients. Plus, TCP RFC requires the server to respond to each incoming SYN, which additionally hits both server resources and the data transfer channel. In other matters, if you have already encountered - in fact - any DDoS attacks - you know the above described without me. Go to the specific recommendations.

Alone in the field

Use what is at hand, and do not look for something else for yourself - what can be done while alone with the attack? Honestly, not much, but it happens that there is enough of that. The following describes what to do with FreeBSD, since in our projects in 90% of cases this system is used. However, from OS to OS, the difference will be small - the principles are the same.

The first is that you need to access the server (yes, this can also be a difficulty, especially if the attack is large-scale and / or long-lasting - the server simply chose all buffers or has 100% CPU). Usually, it is enough to close the attacked service with a firewall or simply its service to extinguish (however, if an attack is detected, this must be done anyway, at least in order to be able to do something else on the server).

The second is to get the first information about the attack. If you have already monitored incoming traffic - fine, if not - we open the firewall / raise the service and use the good old tcpdump and netstat to find out what exactly is attacking and what is the size of the attack in packets per second. Along the way, you can quickly see the networks from which mass requests come - whether they belong to a typical audience for your service. All this will come in handy in the future.

The third is on the interface where the attacked IP address is located should remain only one. Each alias will decrease system performance. This is expressed in different numbers for different systems, but these numbers are serious, each alias can cost an additional 2-3 thousand packets per second.

Fourth , if you use any firewall for incoming traffic at the attacked address, all rules except blocking should be disabled — for example, when a SYN attack is spoofed, the likelihood that the PF SYN-proxy from PF will go to zero and CPU it will take very seriously.

Fifth , we set up the system. Miracles will not be here, they need a piano in the bushes in the form of trained drivers and specially purchased network cards, and the only two general recommendations that seriously affect the ability to receive SYN-attacks have long been known to all:
- Smudge interrupt handling on server processors;
- Enable syn-cookies and disable syn-cache.

The rest of the tuning system will help squeeze out an additional 5-10 thousand packages, which is unlikely to be decisive in the conditions of attack. In case he comes in handy to someone, this is the most common config (without including options that require rebuilding the kernel or specialized drivers):

net.isr.direct=1 kern.ipc.nmbclusters=400000 net.inet.tcp.nolocaltimewait=1 net.inet.tcp.recvspace=16384 net.inet.tcp.sendspace=32768 net.inet.tcp.msl=5000 net.inet.tcp.blackhole=1 net.inet.ip.intr_queue_maxlen=3000 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.log_redirect=1 net.inet.ip.redirect=0 net.inet.icmp.maskrepl=1 net.inet.tcp.syncookies_only=1 net.route.netisr_maxqlen=4096 kern.ipc.maxsockbuf=83886080 net.inet.ip.intr_queue_maxlen=10240 

The system of the level of the desktop computer, configured in accordance with these recommendations:

 first# netstat -w1 -h -d      input     (Total)      output packets  errs idrops    bytes   packets  errs    bytes colls drops   260K  0   0     15M    230K   0     13M   0   0 

System level IBM System x3630 M3, configured in accordance with these recommendations:

 second# netstat -w1 -h -d      input     (Total)      output packets  errs idrops    bytes   packets  errs    bytes colls drops   477K  0   0     36M    457K   0     25M   0   0 

Detailed configurations of the OS and machines, and, in fact, how we came to them - I will try to tell you in the next topic.

One thing we do

What to do besides tuning the system In principle, there is something to do.

It is worth making a small digression - most hosting companies will be extremely reluctant to help in the fight against the attack, if they help at all, and they are hard to blame for this. But at least they will provide information about the attack - if you have to work with defense providers, this, together with the information you collected during the attack, will make your life a lot easier.

If the hoster has got an understanding (which is really a big rarity ) - then we work according to the following algorithm - parallel and block, block and parallel :
If we have several network cards (if not, please put them) —including them in LACP mode (you will need to enable similar options on the host switch) —it will actually give you a one-and-a-half increase in performance (we will consider some subtleties of the process later - to comprehend the immense topic does not work) We leave here to this performance:

 second# netstat -w1 -h -d      input     (Total)      output packets  errs idrops    bytes   packets  errs    bytes colls drops   1.2M  16K   0     65M    1.1M   0     59M   0   0 

Please block all unused ports and protocols - a SYN-attack can easily be replaced by a UDP attack.
Virtually any hosting company is capable of these actions. But if you are lucky enough to work with a serious company - ask to block traffic from a region where most of your project’s audience (for example, China) doesn’t live - this usually means a blackhole announcement for your network for backbone providers of a particular region. As a rule, a SYN-attack is made from Asia, because of its cheapness and mass character, and, therefore, such an announcement can seriously help in the fight against the attack or rule out its possibility altogether.

In addition to the measures described above, it is advisable to use a GeoDNS-like service — under some conditions (an attack is carried out on a domain, for example) this will work in the same way as announcing blackhole for certain networks.

At last

I hope the article will help you cope with the problem of SYN-flood, not exceeding the annual budget of some African countries. Of course, only the most general recommendations are given here, but believe me - in 90% of cases they are quite enough. And most importantly - don't panic!

UPD. Continuation is in the process of writing, and will soon be posted here. Stay with us!