As you are probably aware by navigating here, a SYN Flood' or SYN Attack is a DoS and/or DDoS method of attack which takes advantage of the three-way handshake in TCP/IP networking. In this guide we aim to help system administrators mitigate the effects of and even fully prevent against SYN flooding. This guide is especially useful for firms and individuals who cannot afford services like CloudFlare or others that purport to stop DDoS.

High Level View

Do not mistake the following words for an advertisement for CloudFlare. CloudFlare is merely a service provider, however, they do manage to do what they say they will do, that is, cut down on prevent altogether DDoS attacks. Well, that's innacurate. They don't prevent the attacks themselves. They slow them down, but the attacks can still happen, however futilely. Hacked.com suffered such an attack in recent memory, and CloudFlare was effective at slowing it down. The service offers an easy and integrated way for inexperienced systems administrators to deal with it, or even for professional level administrators to have an added layer of protection. In some cases, the service requires human verification, and in others, knows to simply black list IPs after so many attempts. CloudFlare is a widely-used solution. Here are some others, in the same category:

  • Incapsula
  • Yottaa
  • Many have been acquired by larger firms, such as Akaimai, which is the original CDN and high-traffic solution.

From a high-level view, it seems that this would be the easiest way to go. But it also costs money, and in the end it amounts to paying for something that ultimately can be done yourself -- which is not exactly congruent with the hacker ethos of figuring things out for yourself and doing them as such. So even if you decide to go with one of these solutions, perhaps you should also know what they are doing for you, and if you even need them. More to the point, if they're effective, or if they're simply saving you the time and worry. After all, despite having CloudFlare installed, the DDoS Hacked.com and partner site CCN.la experienced was a hassle, and users experienced intermittent downtime.

First Steps

  • Realize that DDoS is an inherent part of the three-way handshake design of the TCP.

That's right. In order for communications to happen online, three-way handshakes are necessary. The SYN Flood involves overwhelming the system's kernel memory. One solution is to have a whole lot of memory, but that can only get you so far. To protect themselves, most servers will simply backlog excess SYN-RECEIVED messages, such that the system effectively becomes unusual for short periods while the server waits for ACK messages that never come.

Even then, the backlog can become a problem as well. Under normal load, there's no issue, because these requests themselves are tiny, tiny files, in the bytes, and in the 20 years since SYN attacks were popularized, memory and other server resources have advanced by leagues.

So, do not go into this with the idea that you can shut down DDoS altogether. The only way to effectively do that is to not serve content online. Currently. It's always possible that future protocol innovations will make the three-way handshake unnecessary.

  • Determine need

Does your server provide more than 100 connections at a given second? If so, it's already taxed heavily. In such a case, you will need some form of DDoS protection eventually. Is it less? Well, there are still measures you can take on your own, but perhaps a commercial solution on top of everything else is undesirable. The liklihood of becoming the target of a DDoS is directly related to several factors about the website itself, including the content served, the audience, and the popularity of the site. There are crews which exist solely to extort websites via denial-of-service attacks, after all.

Simple Solutions

  • Increase your SYN-RECEIVED backlog
  • Increase resources available to your server, including RAM.
- On a VPS hosting solution such as Digital Ocean, this is trivially done. 
  • Reduce the SYN-RECEIVED timer, so that the server waits a shorter time before dropping a request, legitimate or otherwise. This can be backfire when under attack because it will disrupt legitimate requests that have been queued behind attack packets.
  • Use SYN cookies

Tips

Basic Linux

Assuming an Apache 2 server running on Linux, the following tips will help somewhat.

First, you can set SYN Cookies to true on IPV4. IPV6 may be done differently, but IPV4 is still the dominant mode of packet transfer. This command does that on most Linux systems:

  • sysctl -w net.ipv4.tcp_syncookies=1

You may need to research for your specific distribution of Linux.

Also useful, and built in to Linux servers, is the SYN backlog itself. Here you can define how many half-open connections are allowed at any one time. Depending on your resources, you may want to go as high as 4096. Or, if you're sure you'll only ever have a small amount of people on your site, and that something else would be out of the ordinary and most likely an attack, you can also do a smaller number, like 128.

  • sysctl -w net.ipv4.tcp_max_syn_backlog="_X_"

You will need root to run either of the previous commands.

Apache2 Specific

mod_evasive

Mod_evasive is a third-party module for the Apche 2x series which was designed specifically to deal with denial-of-service and similar attacks. The biggest boost to your Apache system is that mod_evasive is able to detect that a denial-of-service attack, or potential denial-of-service attack, is in progres. As such, it's recommended here.

Mod_evasive looks for the following behaviors:

  • More than a few concurrent requests in a given second.
  • More than 50 concurrent requests on a single child.
  • Blacklisted IPs trying anything at all.

It also makes it easier to log such behavior and determine if any port changes might be useful down the line.

Installation

To install mod_evasive, you will first need to get hold of it.

For Debian and Ubuntu, the following command will most likely get the program for you:

  • sudo apt-get install libapache2-mod-evasive

For CentOS and RHEL-based distributions, you'll want to do something like this:

Syn flood guide mod evasive1.png
  • yum update && yum install mod_evasive
Syn flood guide mod evasive2.png

Configuration

  • Ubuntu/Debian

You're almost done with Ubuntu and Debian. Your next steps are as follows:

Create a log directory mod_evasive.

  • sudo mkdir /var/log/mod_evasive

Give ownership of the logging directory to the www-data user, the same that controls all other web-based stuff in your server.

  • sudo chown www-data:www-data /var/log/mod_evasive/

Fix the mailer bug.

  • sudo ln -s /etc/alternatives/mail /bin/mail/

Modify the configuration parameters.

  • sudo nano /etc/apache2/mods-available/mod-evasive.conf

If nothing's there, generate and modify the following lines:

<ifmodule mod_evasive24.c>

  DOSHashTableSize 3097 

# Busier sites should increase this number. It will be increased to the next highest prime number based on the number given. It uses more memory (for the tables that are created), but also improves performance.

  DOSPageCount  2 

# The number of requests that can be made on the same URI per DOSPageInterval (defined below). In our case, 2 requests per second per IP seems sufficient.

  DOSSiteCount  50 

# as discussed above, if more than 50 requests are made for an object on a given site by the same origin, then that IP will be moved to the blocking list for the length of time specificed in DOSBlockingPeriod.

  DOSPageInterval 1 
  DOSSiteInterval  1  
  DOSBlockingPeriod  10 

# the default here is 10 seconds, you can modify it to a longer period. It is the length of time that the IP will be blocked, in seconds.

  DOSLogDir   /var/log/mod_evasive 

# as generated before -- if you put it somewhere else, be sure to change

  DOSEmailNotify  <YOU>@<DOMAIN>.<TLD>

# your e-mail address

  DOSWhitelist   127.0.0.1

# can add other whitelisted IP addresses </ifmodule>

Now that you are configured, you just have to enable the module, and then restart your Apache server.

  • sudo a2enmod mod-evasive
  • sudo service apache2 restart
  • CentOS Etc.

Configuring for any version of Linux will be somewhat similar, now that you've installed the module. You can use the same configuration from above, but here we'll repeat it for convenience:

As root:

  • nano /etc/httpd/conf.d/mod_evasive.conf

First, ensure the following line or something like it is at the top of the file:

  • LoadModule evasive20_module modules/mod_evasive24.so

You can then either stick with what's there, or modify and insert the following:

<ifmodule mod_evasive24.c>

  DOSHashTableSize 3097 

# Busier sites should increase this number. It will be increased to the next highest prime number based on the number given. It uses more memory (for the tables that are created), but also improves performance.

  DOSPageCount  2 

# The number of requests that can be made on the same URI per DOSPageInterval (defined below). In our case, 2 requests per second per IP seems sufficient.

  DOSSiteCount  50 

# as discussed above, if more than 50 requests are made for an object on a given site by the same origin, then that IP will be moved to the blocking list for the length of time specificed in DOSBlockingPeriod.

  DOSPageInterval 1 
  DOSSiteInterval  1  
  DOSBlockingPeriod  10 

# the default here is 10 seconds, you can modify it to a longer period. It is the length of time that the IP will be blocked, in seconds.

  DOSLogDir   /var/log/mod_evasive 

# as generated before -- if you put it somewhere else, be sure to change

  DOSEmailNotify  <YOU>@<DOMAIN>.<TLD>

# your e-mail address

  DOSWhitelist   127.0.0.1

# can add other whitelisted IP addresses </ifmodule>

  • CTRL+O to write out the file.
Syn flood guide mod evasive3.png

Restart your Apache2 server:

  • service httpd restart
Syn flood guide mod evasive4.png

Note: the above was conducted on CentOS version 7.1 64-bit via a bottom-rung Digital Ocean droplet.

See Also

Article tools