[sphinx]

after first rules of flush and delete, add:

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -s 10.0.0.0/8 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -s 192.168.0.0/16 -j DROP
iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP
iptables -A INPUT -p udp --sport 0 -j DROP
iptables -A INPUT -p udp -m pkttype --pkt-type broadcast -j DROP
iptables -A INPUT -p icmp -f -j DROP

that will protect your server of invalid packets (tcp and udp), packets with abnormal source ip, udp packets without source port, broadcast udp and fragmented icmp packets.
at the end of all rules add:

iptables -A OUTPUT -s 'your.server.ip.address' -p icmp --icmp-type 3 -j DROP

this will prevent your server to further load your connection with unreacheable icmp packets in case of flood.

[WebNoob]

I would love to see a similar system for windows 2008 r2 ;-)

[hamilton5]

sphinx... great work using the search...
This thread is over a year old. There is a protect server/ ddos thread posted weekly no worries

iptables would not harden SRCDS.

[databomb]

Originally Posted by sphinx after first rules of flush and delete, add: iptables -A INPUT -m conntrack --ctstate INVALID -j DROP iptables -A INPUT -s 10.0.0.0/8 -j DROP iptables -A INPUT -s 172.16.0.0/12 -j DROP iptables -A INPUT -s 192.168.0.0/16 -j DROP iptables -A INPUT -s 224.0.0.0/4 -j DROP iptables -A INPUT -s 240.0.0.0/5 -j DROP iptables -A INPUT -p udp --sport 0 -j DROP iptables -A INPUT -p udp -m pkttype --pkt-type broadcast -j DROP iptables -A INPUT -p icmp -f -j DROP that will protect your server of invalid packets (tcp and udp), packets with abnormal source ip, udp packets without source port, broadcast udp and fragmented icmp packets. at the end of all rules add: iptables -A OUTPUT -s 'your.server.ip.address' -p icmp --icmp-type 3 -j DROP this will prevent your server to further load your connection with unreacheable icmp packets in case of flood.

Good job adding on. I should probably add this to the main post or maybe it belongs in a wiki. The last part is especially important to avoid having your server being involved in something called a reflection attack which uses forged IP headers to spam unreachable ICMP messages to any IP.

WebNoob, time to switch OS.. the overhead and cost of windows is not justified with srcds.

hamilton5, although DDoS attacks continue to plague the community, that does not mean iptables does not significantly harden your srcds.

[sphinx]

one more trick: if you ever plan to use fail2ban to protect srcds, i'll recommand to use ipset.
that way, even if your firewall will have A LOT of rules added by a fail2ban jail in case of flood, no significant delay will be added to server connections.
a 'classic' jail will do the job also.

[PAL-18]

On some sites, they mention adding:

-m state --state NEW,ESTABLISHED,RELATED

To iptables rules. Is the state command really needed? Or is it just unnecessary bloat?

[databomb]

Originally Posted by PAL-18 On some sites, they mention adding: -m state --state NEW,ESTABLISHED,RELATED To iptables rules. Is the state command really needed? Or is it just unnecessary bloat?

The states that iptables tracks are still useful even for UDP; however, I'm not convinced on the efficacy of having a rule with the three specific states you listed above.

[sphinx]

yesterday i got a flood from the same source ip, same 27015 port, with the same udp packet legth of 33.
because of the 27015 source port my concluzion is that was a stupid with a cs rented server.
this possibility is real, so my ideea is to drop any udp packet from port 27015, so insert this rule in firewall.

iptables -A INPUT -p udp --sport 27015 -j DROP

[11530]

Originally Posted by sphinx iptables -A INPUT -p udp --sport 27015 -j DROP

But wouldn't that'd block any A2S_*/A2A_* queries to your server?

[sphinx]

Originally Posted by 11530 But wouldn't that'd block any A2S_*/A2A_* queries to your server?

no, the rule it is about source port, not destination port.