[cod] Updating iptables if you don't have the --reap option of the recent module

escapedturkey escapedturkey at escapedturkey.com
Fri Jun 28 11:39:34 EDT 2013


Are you familiar with tcpdump and wireshark? I'm curious if you can
find out what exactly the flood contains.

http://www.wireshark.org/docs/wsug_html_chunked/AppToolstcpdump.html

I use the original rules created by Boyd. Also, I have an additional
rule set attached. Please correct me if the rules are incorrect.

#!/bin/bash
# The main logic of ServerArk, all done with iptables!
# Version 1.01
# (C) 2012 Boyd G. Gafford Ph.D. (Usage is under the LGPL)
# To contact me, simply post on the forum at elitewarriors.net.
#
# Please note these rules ONLY affect UDP packets to the game servers,
nothing else!
# This script will protect all Q3-protocol servers on the port 28960.
It protects
# against both 'getstatus' and 'getinfo' attacks, as well as
'getchallenge' atttacks,
# even from a UDP flood with random source IPs.

# Add a limit/drop chain for "getstatus" packets that limits it to 10
a second for all servers.
# If you are only protecting one server, you can set the number from
10 down to 4 (or 2 even).
iptables -N LIMITSTAT
iptables -A LIMITSTAT -p udp -m limit --limit 10/sec --limit-burst 10 -j ACCEPT
iptables -A LIMITSTAT -p udp -j DROP

# Add a limit/drop chain for "getinfo" packets that limits it to 10 a
second for all servers.
# If you are only protecting one server, you can set the number from
10 down to 4 (or 2 even).
iptables -N LIMITINFO
iptables -A LIMITINFO -p udp -m limit --limit 10/sec --limit-burst 10 -j ACCEPT
iptables -A LIMITINFO -p udp -j DROP

# Add a limit/drop chain for "getchallenge" packets that limits it to
5 a second for all servers.
# If you are only protecting one server, you can set the number from 5
down to 2.  Setting it
# at 2 means only 2 players could connect to the server per second.
Set LIMITCONN to the
# same, as there is one getchallenge/connect packet sequence per valid
player connection.
iptables -N LIMITCHLG
iptables -A LIMITCHLG -p udp -m limit --limit 5/sec --limit-burst 5 -j ACCEPT
iptables -A LIMITCHLG -p udp -j DROP

# Add a limit/drop chain for "connect" packets that limits it to 5 a
# second for all servers.
# If you are only protecting one server, you can set the number from 5
down to 2.  Setting it
# at 2 means only 2 players could connect to the server per second.
Set LIMITCHLG to the
# same, as there is one getchallenge/connect packet sequence per valid
player connection.
iptables -N LIMITCONN
iptables -A LIMITCONN -p udp -m limit --limit 5/sec --limit-burst 5 -j ACCEPT
iptables -A LIMITCONN -p udp -j DROP

# Add a limit chain that prevents more than 70 packets a second per player.
# This is the main logic of ServerArk, but just performed by an iptable rule.
# We allow up to 128 players which is enough for 4 servers full (at 32
# players each).
# If you only have one server, you could the size and max to 32.
# If you have players who have manually set their packet rate up to
100, just change the 70 to 100.
iptables -N LIMITPLRS
iptables -A LIMITPLRS -p udp -m hashlimit --hashlimit-name PLAYERS
--hashlimit-above 70/sec --hashlimit-burst 70 --hashlimit-mode
srcip,srcport --hashlimit-htable-size 128 --hashlimit-htable-max 128
--hashlimit-htable-gcinterval 1000 --hashlimit-htable-expire 10000 -j
DROP
iptables -A LIMITPLRS -p udp -j ACCEPT

# Add the rules to pick out the various special packets and send them to
# appropriate limit chains.
# To protect 5 ports, just specify a range like "--dport 28960:28964" below.
/sbin/iptables -A INPUT -p udp --destination INSERTIPADDRESSHERE
--dport INSERTPORTHERE -m string --string "getstatus" --algo bm --from
32 --to 33 -j LIMITSTAT
/sbin/iptables -A INPUT -p udp --destination INSERTIPADDRESSHERE
--dport INSERTPORTHERE -m string --string "getinfo" --algo bm --from
32 --to 33 -j LIMITINFO
/sbin/iptables -A INPUT -p udp --destination INSERTIPADDRESSHERE
--dport INSERTPORTHERE -m string --string "getchallenge" --algo bm
--from 32 --to 33 -j LIMITCHLG
/sbin/iptables -A INPUT -p udp --destination INSERTIPADDRESSHERE
--dport INSERTPORTHERE -m string --string "connect" --algo bm --from
32 --to 33 -j LIMITCONN
/sbin/iptables -A INPUT -p udp --destination INSERTIPADDRESSHERE
--dport INSERTPORTHERE -m string --string "getstatus" --algo bm --from
32 --to 33 -j LIMITSTAT
/sbin/iptables -A INPUT -p udp --destination INSERTIPADDRESSHERE
--dport INSERTPORTHERE -m string --string "getinfo" --algo bm --from
32 --to 33 -j LIMITINFO
/sbin/iptables -A INPUT -p udp --destination INSERTIPADDRESSHERE
--dport INSERTPORTHERE -m string --string "getchallenge" --algo bm
--from 32 --to 33 -j LIMITCHLG
/sbin/iptables -A INPUT -p udp --destination INSERTIPADDRESSHERE
--dport INSERTPORTHERE -m string --string "connect" --algo bm --from
32 --to 33 -j LIMITCONN

# Send all other packets (normal player packets) to the limit players chain.
# A port range like "--dport 28960:28964" could also be used here as well.
/sbin/iptables -A INPUT -p udp --destination INSERTIPADDRESSHERE
--dport INSERTPORTHERE -j LIMITPLRS
/sbin/iptables -A INPUT -p udp --destination INSERTIPADDRESSHERE
--dport INSERTPORTHERE -j LIMITPLRS

# create chain Quake 3 anti-ddos

/sbin/iptables -N quake3_ddos

# accept real client/player traffic

/sbin/iptables -A quake3_ddos -m u32 ! --u32 "0x1c=0xffffffff" -j ACCEPT

# match "getstatus" queries and remember their address
/sbin/iptables -A quake3_ddos -m u32 --u32 "0>>22&0x3C@ 12=0x67657473
&& 0>>22&0x3C@  16=0x74617475" -m recent --name getstatus --set

/sbin/iptables -A quake3_ddos -m u32 --u32 "0>>22&0x3C@ 12=0x67657469
&& 0>>22&0x3C@  16&0xFFFFFF00=0x6e666f00"  -m recent --name getinfo
--set

# drop packet if "hits" per "seconds" is reached
# NOTE: if you run multiple servers on a single host, you will need to
higher these limits
# as otherwise you will block regular server queries, like Spider or QConnect
# e.g. they will query all of your servers within a second to update the list

/sbin/iptables -A quake3_ddos -m recent --update --name getstatus
--hitcount 20 --seconds 4 -j DROP
/sbin/iptables -A quake3_ddos -m recent --update --name getinfo
--hitcount 20 --seconds 4 -j DROP
/sbin/iptables -A INPUT -p UDP -m length --length 42 -m recent --set
--name getstatus_game
/sbin/iptables -A INPUT -p UDP -m length --length 42 -m recent --set
--name getinfo_game
/sbin/iptables -A INPUT -p UDP -m string --algo bm --string
"getstatus" -m recent --update --seconds 2 --hitcount 20 --name
getstatus_game -j DROP
/sbin/iptables -A INPUT -p UDP -m string --algo bm --string "getinfo"
-m recent --update --seconds 2 --hitcount 20 --name getinfo_game -j
DROP

# accept otherwise
/sbin/iptables -A quake3_ddos -j ACCEPT
# finally insert the chain as the top most input filter
# single server
# iptables -I INPUT 1 -p udp --dport 27960 -j quake3_ddos
# multiple servers

# COD 1/2/4
/sbin/iptables -I INPUT 1 -p UDP --destination-port 28960 -j quake3_ddos

# JA
/sbin/iptables -I INPUT 1 -p UDP --destination-port 29070 -j quake3_ddos

# JK2
/sbin/iptables -I INPUT 1 -p UDP --destination-port 28070 -j quake3_ddos

# IOQuake3, Quake3, RTCW, ET, OpenArena, SmokingGuns, STVEF, UrbanTerror,
/sbin/iptables -I INPUT 1 -p UDP --destination-port 27960 -j quake3_ddos

# Quake 2
/sbin/iptables -I INPUT 1 -p UDP --destination-port 27910 -j quake3_ddos

# Warsow
/sbin/iptables -I INPUT 1 -p UDP --destination-port 44400 -j quake3_ddos

# Tremulous
/sbin/iptables -I INPUT 1 -p UDP --destination-port 30720 -j quake3_ddos


On Fri, Jun 28, 2013 at 6:40 AM, Andrej Parovel <aparovel at gmail.com> wrote:
> Hello,
>
> Is there any updated script? Because it seems that the script is not working
> enough any more. Now they can again flood over COD2 and COD4 servers UDP
> port.
>
> Andrej
>
> +386 31 247 707
> aparovel at gmail.com
>
> On 23.4.2012 17:09, Boyd G. Gafford Ph.D. wrote:
>
> After a bit more research on Centos 6.2, it turns out that (for this
> distribution) the --reap option is not in the kernel.  What that means is
> that even if you update iptables to 1.4.13 as described below, all you will
> end up with is the iptables module no longer complaining about the --reap
> option, but due to the kernel, the --reap option NOT working.
>
> If you do a "listgame.sh" on the server rules, if you are running Centos 6.2
> you will notice that players that are no longer collected stay in the list
> until the game rules are reset with a "unprotectgame.sh" followed by a
> "protectgame.sh", or when the server is physically rebooted.  With the
> standard Centos 6.2 kernel there is no other option.  That's what the --reap
> parameter did for you, and that is expire the whitelisted players after they
> have quit playing on the server for a while.
>
> It's interesting to note that Centos 6.2 uses the 2.6.32-220 kernel, while
> Ubuntu 10.10 server uses 2.6.32-305.  Ubuntu Server 10.10 does indeed work
> properly with --reap, so my guess is that Centos is just way behind in its
> kernel updates.
>
> The solution for those of you using Centos 6.2 is at sometime (perhaps
> overnight) run the script to unprotect the game server, followed by the
> script to re-protect it to clear the whitelisted players.  Just make sure
> that is done when nobody is currently playing on the server, or when you
> re-protect the server everyone will lag out and have to reconnect.
>
> For anyone who updates their kernel sucessfully so --reap works, forward
> along the steps you took so everyone else can benefit.  At this point I'm
> not going to try it myself due to time constraints.
>
> Thanks,
>
>   Boyd
> __________________________________
> Boyd G. Gafford Ph.D.
> Manager of Software Development
> Westport Research Associates Inc.
> 7001 Blue Ridge Blvd
> Raytown, MO 64133
> (816) 358-8990
> drboyd at westportresearch.com
>
>
> On 04/20/2012 09:40 AM, Boyd G. Gafford Ph.D. wrote:
>
> Just a note about using the protection scripts under some Linux
> distributions (especially older ones).  The protection scripts use the
> recent iptables module with the --reap parameter in order to expire
> whitelisted players that have quit playing on the server.  You really need
> this in order for the scripts to work.
>
> Escaped Turkey first reported this with Centos 6.2, so I installed this
> distribution on a VPS and verified it.  If you are using another flavor of
> Linux, you can check to see if the --reap parameter is already supported by
> doing a:
>
> main iptables
>
> followed by
>
> /--reap[enter]
>
> If you see "pattern not found", then you don't have an iptables that
> supports the --reap option, and need to update your iptables.  If your
> cursor lands on the option, then are are already good to go.
>
> In the case of most older Linux distributions, try updating them via the
> normal update process for the distribution first.  This usually gets you a
> newer iptables from the distribution's repository, which works nearly all of
> the time.
>
> However Centos 6.2 is a recent distribution, but for some reason --reap
> doesn't work.  So the best option is to update iptables to the latest.
> Here's how I did it (from root).  First off, if you don't have gcc or make
> installed, you need to do that first:
>
> # yum install gcc
> # yum install make
>
> Now just do the following, which downloads the latest iptables source,
> builds it and makes it active.
>
> # cd /root
> # wget www.netfilter.org/projects/iptables/files/iptables-1.4.13.tar.bz2
> # tar -jxvf iptables-1.4.13.tar.bz2
> # cd iptables-1.4.13
> # ./configure
> # make
> # make install
> # cp /usr/local/sbin/xtables-multi /sbin/iptables-multi
>
> And you are done!  Now your iptables module is updated to 1.4.13, complete
> with --reap option for the dynamic expiration of whitelisted players.
>
> And of course the process here is very similar if you have other
> distributions.
>
> Good luck,
>
>   Boyd
>
> __________________________________
> Boyd G. Gafford Ph.D.
> Manager of Software Development
> Westport Research Associates Inc.
> 7001 Blue Ridge Blvd
> Raytown, MO 64133
> (816) 358-8990
> drboyd at westportresearch.com
>
>
>
> _______________________________________________
> cod mailing list
> cod at icculus.org
> http://icculus.org/mailman/listinfo/cod
>
>
>
> _______________________________________________
> cod mailing list
> cod at icculus.org
> http://icculus.org/mailman/listinfo/cod
>



-- 
EscapedTurkey.com Billing and Support
https://www.escapedturkey.com/helpdesk


More information about the cod mailing list