Raised This Month: $ Target: $400
 0% 

Hardening SRCDS with iptables rules


Post New Thread Reply   
 
Thread Tools Display Modes
Author Message
databomb
Veteran Member
Join Date: Jun 2009
Location: california
Old 02-24-2011 , 19:59   Hardening SRCDS with iptables rules
Reply With Quote #1

A lot of people have been asking about how to protect a Linux server against denial of service (DoS) attacks lately. The vast majority of these attacks involve one individual using a scripted program to execute an attack on a single server target. The goal of using iptables here is to handle networking traffic before it reaches srcds where it could cause undesired latency for players. Also, keep in mind that these iptables rules will do nothing in the face of a large-scale sustained DDoS attacks. With that in mind, effectively iptables rules will mitigate script kiddies' DoS, small-scale DDoS, and even larger pulsed DDoS attacks.

Before you begin changing the iptables rules, unless you have physical access to the server you should consider scheduling a periodic iptables rules flush in case a change causes the system to lock everyone out. To do this, make a shell script with the proper permissions and put the following inside it:
Code:
iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
Then configure it to run at a scheduled time using crontab or similar program. Remember to unschedule this once you've finished setting up the firewall.

The first measure of protection is to develop a white-list of IP addresses that have your permission to access rcon; otherwise, it's best to completely hide rcon from the outside world.
Code:
iptables -A INPUT -p tcp --destination-port 27015 -j LOG --log-prefix "SRCDS-RCON " -m limit --limit 1/m --limit-burst 1
iptables -A INPUT -p tcp --destination-port 27015 -j DROP
Many of the programs available in the nether-regions of the Internet spam queries to the server. These programs have a few commonalities such as the length of their packets. One popular iptables rule blocks anything with length 28. To suppress these attacks, we'll block any packets with a length between 0 and 32. You won't see any valid game packets below 32 bytes.
Code:
iptables -A INPUT -p udp --destination-port 27015 -m length --length 0:32 -j LOG --log-prefix "SRCDS-XSQUERY " --log-ip-options -m limit --limit 1/m --limit-burst 1
iptables -A INPUT -p udp --destination-port 27015 -m length --length 0:32 -j DROP
Similarly, how the game responds to fragmented packets is defined by a few net_ cvars. Check the values of your cvars and configure your firewall rules accordingly. This is the calculation I used to determine the maximum acceptable packet size:
Maximum Size = (`net_maxroutable`) + (`net_splitrate`) * (`net_maxfragments`)
which gives 2520 bytes under the default configuration.
Code:
iptables -A INPUT -p udp --destination-port 27015 -m length --length 2521:65535 -j LOG --log-prefix "SRCDS-XLFRAG " --log-ip-options -m limit --limit 1/m --limit-burst 1
iptables -A INPUT -p udp --destination-port 27015 -m length --length 2521:65535 -j DROP
Another rule to consider is a limit on how many UDP IP packets we receive over a set period of time. This is difficult to implement but the general idea is to add all of the cmdrate values for all connected clients and specify a burst that has some leeway, say 120%. For example, let's say there are currently 10 connected clients each with a cmdrate of 33 packets per second, so 10*33 = 330 per second with 330*0.2 = 66 burst. So your iptables rule would include something like,
Code:
-m hashlimit --hashlimit-mode dstport,dstip --hashlimit-name StopFlood --hashlimit 330/s --hashlimit-burst 66
Implementing this kind of dynamic firewall rule is left as an exercise for the reader.

After this we'll accept all 'established' UDP connections. Since UDP is a stateless protocol, 'established' is a bit of a misnomer. In this sense, established means that there has been communication in both directions from the same source port to the same destination port and a timeout value has not been reached.
Code:
iptables -A INPUT -p udp -m state --state ESTABLISH -j ACCEPT
Handling 'new' or unsolicited UDP connections such as requests to join the game server or miscellaneous queries will be rate-limitted. A hash-limit is used to throttle connection attempts that become excessive. This is so sensitive that hitting 'Refresh' in the server browser window too often will trigger these rules. There are several different options for how to configure the hash-limits so I'll briefly discuss two different scenarios.
1) You run multiple game servers on different ports but same IP
For this you'd want to make the hash-limit come from the source IP and go to the destination port (srcip,dstport).
Code:
iptables -A INPUT -p udp -m state --state NEW -m hashlimit --hashlimit-mode srcip,dstport --hashlimit-name StopDoS --hashlimit 1/s --hashlimit-burst 3 -j ACCEPT
2) You run a single game server on a single IP
For this it's easier just to specify the source IP for the hash (srcip).
Code:
iptables -A INPUT -p udp -m state --state NEW -m hashlimit --hashlimit-mode srcip --hashlimit-name StopDoS --hashlimit 1/s --hashlimit-burst 3 -j ACCEPT
Finally, for all packets that weren't matched to an acceptance rule above, we'll drop them here.
Code:
iptables -A INPUT -p udp -j LOG --log-prefix "UDP-SPAM " --log-ip-options -m limit --limit 1/m --limit-burst 1
iptables -A INPUT -p udp -j DROP
Some iptables rule sets include exemptions for Valve's master servers. Unfortunately, due to the nature of UDP, there is little stopping an attacker from spoofing these master server addresses. It's better to allow the current clients a playable experience than worrying about appearing unavailable for some brief period of time.

There are other iptables firewalls posted that use packet inspection to deny a few of these scripted DoS attacks. Generally, if it's easily detected by a simpler iptables rule, then use that instead. Also, there are quite a few SourceMM or SM extensions that attempt to deal with this issue as well: DAF, Query Cache, et. al. It's best to avoid letting srcds or any related plugins or extensions deal with these problems. But, other than resource consumption, there's no harm in using both approaches.

Other Considerations:
If you're default policy on the INPUT chain is to accept traffic, consider changing it to drop. If you do so, remember to make allowances for already established tcp connections.
If your net_splitrate is 0 and you won't fragment packets, consider disabling fragmentation completely for srcds traffic.
If you receive attacks from shady foreign countries such as Burma or North Korea, consider black-listing these entire countries.
__________________
databomb is offline
marvel
BANNED
Join Date: Dec 2009
Old 02-24-2011 , 20:15   Re: Hardening SRCDS with iptables rules
Reply With Quote #2

Nice guide, I'm using these rules for a long time now and nobody bothered me with DoS attacks since.

It does however require a dedicated server with root access and it won't protect you against DDoS attacks (then again, what will?).
marvel is offline
2GOOD
New Member
Join Date: May 2009
Old 04-10-2012 , 13:23   Re: Hardening SRCDS with iptables rules
Reply With Quote #3

Can I apply these rules to hlds - for example the packet length 0 to 32
2GOOD is offline
pillepallus
Senior Member
Join Date: Oct 2011
Old 04-10-2012 , 15:16   Re: Hardening SRCDS with iptables rules
Reply With Quote #4

Quote:
Originally Posted by 2GOOD View Post
Can I apply these rules to hlds - for example the packet length 0 to 32
yes and the others rules too.
pillepallus is offline
alexclaudiu2003
Senior Member
Join Date: Aug 2011
Location: Romania
Old 04-21-2012 , 08:19   Re: Hardening SRCDS with iptables rules
Reply With Quote #5

For Windows 7 ? anti flooding ?
alexclaudiu2003 is offline
databomb
Veteran Member
Join Date: Jun 2009
Location: california
Old 04-21-2012 , 09:39   Re: Hardening SRCDS with iptables rules
Reply With Quote #6

No
__________________
databomb is offline
jackliu92
Senior Member
Join Date: Aug 2006
Old 04-26-2012 , 04:38   Re: Hardening SRCDS with iptables rules
Reply With Quote #7

Hmm,
I found some more additional rules that reduce resource usage during a DDOS attack, but it is not iptables related.

Protocol Related: TCP
File related: /etc/sysctl.conf
To see your current setting, use command: sysctl -a | grep ipv4 | grep syn

Here is the setting I use on my server:
Quote:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
I am not sure about syncookies, and syn backlog, but people say it is better to have them as above[Do some googling if you want].
Originally both retries settings are 3, change them to 1 can reduce your server and network load during DDOS attack.

Use command "sysctl -p" to apply new settings.
Please do this if you want and you know what you are doing. I am posting this as a suggestion, or discussion. I will not responsible for any cause by using what I said above.
__________________

Last edited by jackliu92; 04-26-2012 at 04:40.
jackliu92 is offline
x00
Member
Join Date: Sep 2011
Old 04-26-2012 , 06:57   Re: Hardening SRCDS with iptables rules
Reply With Quote #8

Quote:
Originally Posted by jackliu92 View Post
Hmm,
I found some more additional rules that reduce resource usage during a DDOS attack, but it is not iptables related.

Protocol Related: TCP
File related: /etc/sysctl.conf
To see your current setting, use command: sysctl -a | grep ipv4 | grep syn

Here is the setting I use on my server:

I am not sure about syncookies, and syn backlog, but people say it is better to have them as above[Do some googling if you want].
Originally both retries settings are 3, change them to 1 can reduce your server and network load during DDOS attack.

Use command "sysctl -p" to apply new settings.
Please do this if you want and you know what you are doing. I am posting this as a suggestion, or discussion. I will not responsible for any cause by using what I said above.
And FYI, this only works on a dedicated box and on a VPS without a shared kernel.

-x00
__________________
꞉⋮꞉

Last edited by x00; 04-26-2012 at 07:52.
x00 is offline
deadlyruler
Member
Join Date: Dec 2008
Old 06-10-2012 , 19:29   Re: Hardening SRCDS with iptables rules
Reply With Quote #9

Hey when I try to enter iptables -A INPUT -p udp -m state --state NEW -m hashlimit --hashlimit-mode srcip --hashlimit-name StopDoS --hashlimit 1/s --hashlimit-burst 3 -j ACCEPT I get Unknown error 18446744073709551615
Do you happen to know why this happens?
deadlyruler is offline
databomb
Veteran Member
Join Date: Jun 2009
Location: california
Old 06-10-2012 , 21:01   Re: Hardening SRCDS with iptables rules
Reply With Quote #10

Quote:
Originally Posted by deadlyruler View Post
Hey when I try to enter iptables -A INPUT -p udp -m state --state NEW -m hashlimit --hashlimit-mode srcip --hashlimit-name StopDoS --hashlimit 1/s --hashlimit-burst 3 -j ACCEPT I get Unknown error 18446744073709551615
Do you happen to know why this happens?
You may not have all the needed kernel modules loaded for iptables with hashes.
__________________
databomb is offline
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 13:11.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Theme made by Freecode