Some useful tcp settings for ddos mitigation

Ever been ddosed and see your server dropping before the pipe is even full? Anyone who has dealt with attacks surely have. Usually syn attacks cause this by depleting tcp resources, thats why they are so effective.

I will first recommend being on a protected network, there is only so much you can handle with your server depending on your available resources and bandwith allocations so having a network that can automatically deal with this type of malicious traffic is your best bet. As Ive always said it just does not get better then staminus.net for this, its by far the best and a great deal for the money.

Then I will recommend having a good firewall such as CSF, using the ct_limit settings to about 60 with skip time wait or 120 without skipping time wait. Either way some legit users may be banned, not many but some will. This isnt an exact science and you will have to do some experimenting to find a balance. I also recommend using something like the syn_deflate script I came up with. Although CSF does have ct_states where you can set it to ban on syn_recv its a good idea to perform regular connection tracking to ban the ips that have built up many connections without sending enough syn to fire that. So both is ideal.

In order to handle these type of attacks to the full potential of your port speed you must have a good amount of memory, usually 2-4 gb depending on your other server needs. The default tcp settings for linux are conservative at best and under normal circumstances does just fine but in the event of attacks or high traffic sometimes they dont.
First we will discuss the conntrack tables, the ip_conntrack and nf_conntrack tables are usually loaded by firewall scripts such as apf or csf. These can be very useful for connection tracking and stateful packet inspection but they can be worse then not having them loaded at all if you do not have your stack tuned right. The CONNTRACK_MAX is the maximum number of “sessions” (connection tracking entries) that can be handled simultaneously in kernel memory.

When you see this:

nf_conntrack: table full, dropping packet

or

ip_conntrack: table full, dropping packet

It means as it says, the loaded conntrack settings are just not enough. So its time to tune them up some. There is a memory calculation for this, to read more on that you can use this semi-outdated but still fairly accurate documentation.

On systems with 2gb of ram I usually set both conntrack tables to 1048576 This will use about 384 of ram. of course you can set this to more if needed but if you are using a good firewall that is banning on ips with so many connections and so many syn_recv connections this should be fine and take a lot of abuse. If you have less then 2gb of ram you will need to calculate what you can safely use.

To see all the current conntrack counts and settings do

sysctl -a | grep conntrack

After modifying them to monitor your current count

sysctl -a | grep conntrack_count

Of course there can always be some experimenting you can do, and I’m sure there are some different suggestions for memory equations out there so find what suits you best.When getting into the other tcp settings like default timeouts and such its always best to check out different recommendations and see for yourself the benefits and cons of each.

My next article will be on other types of tuning you can do to help prevent other types of tcp resource starvation.