SYN flooding and DoS attack

It has become popular now days to receive incoming attack from foreign server, with the only goal to discard all access/connections to your server. Those attacks are generally call “DoS” or “Denial of Service” attack.

SYN flood or SYN attack is a denial-of-service method affecting hosts that run TCP server processes.
The attack takes advantage of the state retention TCP performs for some time after receiving a SYN segment to a port that has been put into the LISTEN state.

The basic idea is to exploit this behavior by causing a host to retain enough state for bogus half-connections that there are no resources left to establish new legitimate connections (RFC4987).

SYN flood is relatively hard to mitigate, and that's why very popular. Why? It often uses random source IPs which cannot be banned, as they are generated in each packet; It consumes little resources on the attacker side and lots of on the victim’s; The protection is quite complex, full of nuances and requires time to understand and implement.

How are the SYN attacks performed? One example of a tool often used to perform SYN attacks is hping3. You can use this tool to make your own stress testing before the attackers do it for you.

hping3 is a very rich tool that can do quite a lot types of attacks with customizable parameters. I will not give you a master-class of using it here. These parameters can help you test your server whether it is ready for small SYN attacks or not:

# hping3 -S --faster -p 80 xx.xx.xx.xx 80 (HTTP) is an example of destination port. 

Look at the other parameters (hping3 --help) to understand how the attacks can differ from each other.

Use it with caution and only for testing purposes! To be honest, most of the Internet is vulnerable to such attacks, even if the attacker's bandwidth is much less than the victim's.
If the attack is not consuming a large amount of bandwidth (speed), you have the option of using DoS-Deflate.
From your command prompt: wget  http://www.inetbase.com/scripts/ddos/install.sh
sh install.sh
Protecting your Server, The Linux kernel allows you to directly change the various parameters needed to mitigate against SYN flood attacks.
We won't go into detail here about what each one does specifically, however if you are interested you can read about them in detail here.

First, we'll set the variables to be active immediately?

echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 2048 > tcp_max_syn_backlog
echo 3 > /proc/sys/net/ipv4/tcp_synack_retries

This sets the kernel to use the SYN cookies mechanism, use a backlog queue size of 2048 connections, and the amount of time to keep half-open connections in the queue (3 equates to roughly 45 seconds). Making the Changes Persist To make these changes persist over consecutive reboots, we need to tell the sysctl system about these modified parameters.
We use the /etc/sysctl.conf file to do so. We will add the following lines to the bottom of the file?

Flood Protection :

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_backlog = 2048
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_syn_retries = 3     # default=5
net.ipv4.tcp_synack_retries = 3        # default=5
net.ipv4.tcp_max_syn_backlog = 65536        # default=1024
net.core.wmem_max = 8388608        # default=124928
net.core.rmem_max = 8388608       # default=131071
net.core.somaxconn = 512        # default = 128
net.core.optmem_max = 81920        # default = 20480


then setup my response time test, ran sysctl -p and disabled syncookies by

sysctl -w net.ipv4.tcp_syncookies=0