Parsing attacks: SYN-flood

Spoofed SYN - an attack in which packet headers are falsified in such a way that an arbitrary or non-existent IP address takes the place of the real sender.

Since, in fact, SYN is a frequent tool for " intense competition " and - at the same time - most DDoS mitigation solutions show impressive effectiveness in this particular type of attack, we will start with the SYN flood, considering the spoofed attack type as the most formidable ones.

Disclaimers


Disclaimer No. 1

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

Disclaimer No. 2

The topic does not consider hardware protection solutions - firstly, they are well considered in numerous articles by manufacturers of these very 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 unlikely that anyone will be interested in an overview of 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 under a number of conditions .

Disclaimer No. 3

The topic does not cover providers of protection against DDoS attacks - 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 it is out of the scope of the topic, try to talk about it later. Again, it is worth noting that all security providers with which the author's projects work or have worked, cope with the problem of SYN attacks, showing good efficiency.

A bit of mechanics and wikipedia


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

First, TCP is one of the most used transport protocols, on top of which most application protocols are located. Secondly, it has a number of special features (clearly confirmed by the beginning 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 a first approximation, at the client-server level it looks like this: the client sends a SYN packet to the server, to which SYN + ACK responds. The client sends an ACK to the SYN server in response and the connection goes into the established state.

SYN attack - sending to the open server port a mass of SYN packets that do not lead to the establishment of a real connection for one reason or another, which entails the creation of “half-open connections” that overwhelm the connection queue, forcing the server to deny service to future clients. In addition, TCP RFC obliges the server to respond to each incoming SYN, which additionally affects both server resources and the data transmission channel. In other matters, if you have already encountered - in fact - any DDoS attacks - you know the above described without me. We pass to specific recommendations.

Alone in the field


Use what’s under your arm and don’t look for something else - what can you do when you are alone with the attack? Honestly, not much, but it happens that this is enough. 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.

First , you need to access the server (yes, this can also be difficult, especially if the attack is large-scale and / or long-term - the server just selected all the buffers or has 100% CPU load). Usually, it’s enough to close the attacked service with a firewall or just repay it — the service — (however, if an attack is detected, this must be done anyway, if only to be able to do something else on the server).

Second- get the first information about the attack. If you have already done monitoring of incoming traffic - fine, if not - open the firewall / raise the service and use the good old tcpdump and netstat to find out exactly what the attacks are and what the size of the attack is in packets per second. Along the way, you can quickly view the networks from which bulk requests come - whether they are part of an audience typical of your service. All this will come in handy in the future.

Third - on the interface where the attacked IP address is located, only one should remain. Each alias will reduce 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 to the attacked address - all rules, except blocking, should be disabled - for example, with a spoofed SYN attack, the probability that you will be helped by a SYN-proxy from PF tends to zero, and the CPU it will take very seriously.

Fifth - configure the system. There will be no miracles, they need a piano in the bushes in the form of prepared drivers and specially purchased network cards, and the only two general recommendations that seriously affect the ability to receive a SYN attack have long been known to everyone:
- Smudge the processing of interrupts on server processors;
- Enable syn-cookies and disable syn-cache.

The rest of the tuning system will help squeeze out additional 5-10 thousand packets, which in the conditions of an attack is unlikely to be decisive. In case it comes in handy for someone, here’s 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 desktop computer system 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’ll try to tell in the next topic.

We do one thing


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

Here it is worth making a small digression - most hosting companies will help in the fight against the attack extremely reluctantly, if at all, and it’s hard to blame them. But at least they will provide information about the attack - if you have to work with security providers, this, together with the information that you collected during the attack, will make life easier.

If the hoster has an understanding (which is really a 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) - turn them on in LACP mode(for this you will have to enable similar options on the host switch) - this will actually give a one-and-a-half performance increase (we will look at some of the subtleties of the process later - it’s impossible to grasp the immensity within the topic)

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 fortunate enough to work with a serious company - ask to block traffic from a region where most of the audience of your project does not live (for example, China) - usually this means a blackhole announcement for your network for backbone providers in a particular region. As a rule, a SYN attack is carried out from Asia, due to its cheapness and mass character, and, therefore, such an announcement can seriously help in the fight against an attack or even exclude its possibility.

In addition to the above measures, you can advise using the GeoDNS-like service - under certain conditions (an attack is carried out on a domain, for example), this will work similarly to the announcement of a blackhole for certain networks.

In the end


I hope this article will help you deal with the problem of SYN flood without exceeding the annual budget of any African country. 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 The continuation is in the process of writing, and will soon be posted here. Stay with us!

Also popular now: