[cod] CoD2 UDP flood

Tue Feb 28 09:42:03 EST 2012

I wouldn't say that its decreasing the effectiveness... I was getting false
positives when just using srcip mode because people (including myself)
monitor all of the servers, so they get queried all at once. It still works
just as great, blocking the abusers and letting the non-abusers query as
much as they want.

Here are my CentOS rules (copied from /etc/sysconfig/iptables)...

-A INPUT -p udp -m udp --dport 27960:30000 -j QUERY-CHECK
-A QUERY-BLOCK -m recent --set --name blocked-hosts --rsource -j DROP
-A QUERY-CHECK -s 208.100.38.104/29 -p udp -m udp -j RETURN
-A QUERY-CHECK -s 67.202.93.155/32 -p udp -m udp -j RETURN
-A QUERY-CHECK -p udp -m string ! --string "getstatus" --algo bm --from 31
--to 65535 -j RETURN
-A QUERY-CHECK -p udp -m udp --sport 0:1025 -j DROP
-A QUERY-CHECK -p udp -m udp --sport 3074 -j DROP
-A QUERY-CHECK -p udp -m udp --sport 4000 -j DROP
-A QUERY-CHECK -p udp -m udp --sport 7777 -j DROP
-A QUERY-CHECK -p udp -m udp --sport 9987 -j DROP
-A QUERY-CHECK -p udp -m udp --sport 15541 -j DROP
-A QUERY-CHECK -p udp -m udp --sport 27005:27100 -j DROP
-A QUERY-CHECK -p udp -m udp --sport 25200 -j DROP
-A QUERY-CHECK -p udp -m udp --sport 25565 -j DROP
-A QUERY-CHECK -p udp -m udp --sport 45000 -j DROP
-A QUERY-CHECK -p udp -m udp --sport 50000 -j DROP
-A QUERY-CHECK -m recent --update --seconds 30 --hitcount 1 --name
blocked-hosts --rsource -j DROP
-A QUERY-CHECK -m hashlimit --hashlimit 2/sec --hashlimit-burst 10
--hashlimit-mode srcip,dstip --hashlimit-name getstatus
--hashlimit-htable-expire 30000 -j RETURN
-A QUERY-CHECK -j QUERY-BLOCK

Besides the changes already mentioned, I added a few more source ports that
I saw were being used. My server IP's are 208.100.38.104/29 and
67.202.93.155/32 so those are excluded. I also bumped the hashlimit-burst
from a default of 5 to 10, and modified the port range on the INPUT rule.
Please note that if your --to and --from string matching is working
already, then don't pay attention to my values. I'm still not sure why 32
and 41 don't work...

On Tue, Feb 28, 2012 at 6:12 AM, Marco Padovan <evcz at evcz.tk> wrote:

>
> Why should you decrease the filter effectiveness?
>
> Iptables filtering works better then the patched binaries because it
> monitor all the servers on all the ports and all the ips....
>
> Il 28/02/2012 12:09, escapedturkey ha scritto:
>
> Can you please share your changes? I assumed the rules would cover
> multiple IP aliases. This is incorrect?
>
>  Thanks. =)
>
> On Tue, Feb 28, 2012 at 2:47 AM, Geoff Goas <gitman at gmail.com> wrote:
>
>> Well I can say the iptables rules have been running fantastically. I
>> added a few tweaks such as not blocking the server's own set of IP's (there
>> are quite a few internal queries going on), and also setting the
>> hashlimit-mode to be based on source and destination IP since I have
>> different server instances on different addresses, and I wanted a little
>> more granularity to the matching. My ingress rates are still noticeably
>> higher than they used to be, but at least the outbound bandwidth isn't
>> being exploited anymore.
>>
>> Does anyone know the default value for hashlimit-htable-expire? I haven't
>> been able to find it, so I've manually set it to 30 seconds.
>>
>>
>>
>>    On 02/24/2012 03:38 PM, River Hosting wrote:
>>>
>>> Hello again guys,
>>>
>>>
>>>
>>> I was adding some new rules into the firewall and it looks like the
>>> flooding has stopped!
>>>
>>>
>>>
>>> Now using;
>>>
>>> - *serverark* (recently posted on this list)
>>>
>>> - *getstatus_ban.sh* (recently posted aswell)
>>>
>>> - *iptables*
>>>
>>>
>>>
>>> Since this morning the traffic dropped from 6 Mbit/s to 45 Kb/s.
>>>
>>> When filtering, shutting down all gameservers running on your box for
>>> about 24-48 hours may do the trick. After that time just reboot them and
>>> let the magic happen... :)
>>>
>>>
>>>
>>>
>>>
>>> Met vriendelijke groeten,
>>>
>>> With kind regards,
>>>
>>> Julian Maartens
>>> River Hosting
>>>
>>> info at riverhosting.nl
>>> http://www.riverhosting.nl
>>>
>>>
>>>
>>> *Van:* Marco Padovan [mailto:evcz at evcz.tk <evcz at evcz.tk>]
>>> *Verzonden:* vrijdag 24 februari 2012 14:05
>>> *Aan:* Call of Duty server admin list.
>>> *Onderwerp:* Re: [cod] CoD2 UDP flood
>>>
>>>
>>>
>>> You can either use the one you linked from modsrepository or the more
>>> "complex" one that was posted on this list
>>>
>>> Il 24/02/2012 14:03, david.lauriou at wanadoo.fr ha scritto:
>>>
>>> the rules is ?
>>>
>>>
>>>
>>>  ----- Original Message -----
>>>
>>> *From:* Marco Padovan <evcz at evcz.tk>
>>>
>>> *To:* cod at icculus.org
>>>
>>> *Sent:* Friday, February 24, 2012 2:00 PM
>>>
>>> *Subject:* Re: [cod] CoD2 UDP flood
>>>
>>>
>>>
>>> that rule is very basic.
>>>
>>> cod1, cod1.5, cod2 and cod4 all suffer the same problem and are
>>> exploited in the same exact way.
>>>
>>> So an iptables that fixes the cod4 problem works also for cod2 and cod1
>>>
>>> Il 24/02/2012 13:51, david.lauriou at wanadoo.fr ha scritto:
>>>
>>> i've find this :
>>> http://wiki.modsrepository.com/index.php/Call_of_Duty_4:_Servers
>>>
>>> its for cod4 not for COD2 !
>>>
>>>
>>>
>>>  ----- Original Message -----
>>>
>>> *From:* Marco Padovan <evcz at evcz.tk>
>>>
>>> *To:* cod at icculus.org
>>>
>>> *Sent:* Friday, February 24, 2012 1:49 PM
>>>
>>> *Subject:* Re: [cod] CoD2 UDP flood
>>>
>>>
>>>
>>> NO!
>>>
>>> Read the messages that got posted in the last 2 days...
>>>
>>> This should be a proper ruleset:
>>> http://icculus.org/pipermail/cod/2012-February/015927.html
>>>
>>> Il 24/02/2012 13:47, david.lauriou at wanadoo.fr ha scritto:
>>>
>>> like this ?
>>>
>>>
>>>
>>> IPTABLES -A INPUT -p UDP -m length --length 42 -m recent --set --name getstatus_cod
>>>
>>> IPTABLES -A INPUT -p UDP -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP
>>>
>>>   ----- Original Message -----
>>>
>>> *From:* Marco Padovan <evcz at evcz.tk>
>>>
>>> *To:* Call of Duty server admin list. <cod at icculus.org>
>>>
>>> *Sent:* Friday, February 24, 2012 1:35 PM
>>>
>>> *Subject:* Re: [cod] CoD2 UDP flood
>>>
>>>
>>>
>>> iptables rules
>>>
>>> Il 24/02/2012 13:28, david.lauriou at wanadoo.fr ha scritto:
>>>
>>> for COD4 what is the best method to remove udp Flooding exploit ?
>>>
>>>
>>>
>>>  ----- Original Message -----
>>>
>>> *From:* Marco Padovan <evcz at evcz.tk>
>>>
>>> *To:* Call of Duty server admin list. <cod at icculus.org>
>>>
>>> *Sent:* Friday, February 24, 2012 12:10 PM
>>>
>>> *Subject:* Re: [cod] CoD2 UDP flood
>>>
>>>
>>>
>>> Be aware that there are two different ways to talk about offset: packet
>>> offset (includes header) and payload offset (does not include header)
>>>
>>> Il 24/02/2012 10:41, Geoff Goas ha scritto:
>>>
>>> You're right, and I see my error. That is frustrating because I have no
>>> idea why it doesn't work with the offset specified then.
>>>
>>> On Fri, Feb 24, 2012 at 4:10 AM, Luca Farflame Fabbro <
>>> farflame at cybergames.it> wrote:
>>>
>>> Try this command
>>>
>>> tcpdump -c 4 -nnvvvXS dst port 28960
>>>
>>> where port is the port that you want to monitor
>>>
>>> should be something like
>>>
>>>
>>>
>>>         0x0000:  4500 002b 35b3 0000 7511 179b b612 80ad
>>>  E..+5...u.......
>>>
>>>         0x0010:  c0a8 010c 7012 7120 0017 0000 ffff ffff
>>>  ....p.q.........
>>>
>>>         0x0020:  6765 7473 7461 7475 730a 0000 0000       getstatus.....
>>>
>>>
>>>
>>> On Feb 24, 2012, at 9:54 AM, Geoff Goas wrote:
>>>
>>>
>>>
>>>
>>>
>>>  That is strange, because if I use those values, it does not work. If I
>>> use "--from 31" alone, then it works. As soon as I change that to 32, it
>>> stops working. When I inspect the packets in Wireshark, the "getstatus"
>>> string starts at offset 48 if counting from 1. Would there be a way for
>>> iptables to print to log what it sees in the specified offset range?
>>>
>>> On Fri, Feb 24, 2012 at 3:28 AM, Luca Farflame Fabbro <
>>> farflame at cybergames.it> wrote:
>>>
>>> It doesn't matter the length of the packet.
>>>
>>> That rule will try to find the string "gestatus" starting at position 32
>>> bytes from start of packet and searching for it at maximum at position 41.
>>>
>>> The Q3 protocol for that command expects the string to be in that range.
>>>
>>>
>>>
>>> On Feb 24, 2012, at 1:11 AM, Geoff Goas wrote:
>>>
>>>
>>>
>>>  Is the offset range of 32-41 based on a 60-byte packet?
>>>
>>> On Thu, Feb 23, 2012 at 10:34 AM, Marco Padovan <evcz at evcz.tk> wrote:
>>>
>>> iptables -A INPUT -p udp -m string --string "getstatus" --algo bm --from
>>> 32 --to 41 -j DROP
>>>
>>> --
>>> *Geoff Goas
>>> Systems Engineer*
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>>
>>> --
>>> *Geoff Goas
>>> Systems Engineer*
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>>
>>> --
>>> *Geoff Goas
>>> Systems Engineer*
>>>
>>>
>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>>
>>> 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
>>>
>>>
>>
>>
>>
>> --
>> *Geoff Goas
>> Systems Engineer*
>>
>>
>> _______________________________________________
>> cod mailing list
>> cod at icculus.org
>> http://icculus.org/mailman/listinfo/cod
>>
>>
>
>
> --
> EscapedTurkey.com Billing and Support
>  https://www.escapedturkey.com/helpdesk
>
>
>
> _______________________________________________
> cod mailing listcod at icculus.orghttp://icculus.org/mailman/listinfo/cod
>
>
> _______________________________________________
> cod mailing list
> cod at icculus.org
> http://icculus.org/mailman/listinfo/cod
>
>

-- 
*Geoff Goas
Systems Engineer*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20120228/523d2df3/attachment-0001.htm>