[cod] CoD2 UDP flood

Tue Feb 28 11:28:29 EST 2012

The original script appears to cover the main IP address and all aliased IP
addresses. Is this true?

On Tue, Feb 28, 2012 at 9:42 AM, Geoff Goas <gitman at gmail.com> wrote:

> 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*
>
>
> _______________________________________________
> cod mailing list
> cod at icculus.org
> http://icculus.org/mailman/listinfo/cod
>
>

-- 
EscapedTurkey.com Billing and Support
https://www.escapedturkey.com/helpdesk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20120228/1bf3fc4e/attachment-0001.htm>