[cod] CoD2 UDP flood

Tue Feb 28 12:00:30 EST 2012

In regards to destination matching, yes.

On Tue, Feb 28, 2012 at 11:28 AM, escapedturkey <
escapedturkey at escapedturkey.com> wrote:

> 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
>
>
> _______________________________________________
> 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/d4f44727/attachment-0001.htm>