Synproxy

Synproxy

Synproxy is a really cool feature of linux kernel newer than 3.12. It is by default available in CentOS 7 and newer. The purpose is that a kernel handles new incoming connections instead of a directly send the packet to the application. The kernel waits until the full TCP handshake is established and if it is,only than it gives the full connection to the service listening on the port.

In practice if you have for instance web server and you notice DoS or DDoS syn attack, you will see that your server has a hundreds of SYN_RECEIVED connections in your connection table.. For every such a connection the server needs to allocate memory, CPU, wait for timeout and it consumes system resources which can cause regular clients not to be served.

You can test it with „hping3 –random-source“. If you see SYN_RECEIVED, your synproxy is not working properly or is not implemented yet.

How to implement synproxy:

In the *raw table (iptables) you have to exclude service you want to protect from tracking.

-A PREROUTING -p tcp -m tcp --dport 80 --syn -j CT --notrack

Than in the *filter rules :

-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460 
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate INVALID -j DROP

The idea is quite simple. Excluded packets are sent to synproxy. Every such a packet is now considered to be invalid, so be sure to put DROP invalid rule only after synproxy rule, otherwise your service would not be reachable. In case of regular client full tcp handshake is made the webpage is working. For spoofed source IP addresses the synproxy will drop such a connections with minimum performance effect after a while.

You can also check the command:

watch 'cat  /proc/net/stat/synproxy '

If the values are increasing as a service is contacted it means your synproxy is working correctly. You will also not see SYN_RECEIVED when using ‚netstat‘ command. Additionaly you should be able to see ‚nf_synproxy_core‘ module loaded with ‚lsmod‘.

It is a drawback in this solution, that if you implement synproxy you CANNOT implement hashlimit, ratelimit rules on that direct machine because these are based on connection tracking. So you need to consider all these circumstances. (You can do it on mod_security on application layer than)

For the complete antiDoS solution, you also need to tweak some kernel parameters (like tcp timeout) and sanitize other incoming packets to drop as much junk traffic as possible.