[cod] CoD2 UDP flood

escapedturkey escapedturkey at escapedturkey.com
Thu Feb 23 09:53:44 EST 2012


# These commands, for instance, would block external IPs that send queries
# at a rate of 2/second or higher:
# add a host to the banlist and then drop the packet.
/sbin/iptables -N QUERY-BLOCK
/sbin/iptables -A QUERY-BLOCK -m recent --set --name blocked-hosts -j DROP
# is this a query packet? if so, block commonly attacked ports outright,
# then see if it's a known attacking IP, then see if it is sending at a high
# rate and should be added to the list of known attacking IPs.
/sbin/iptables -N QUERY-CHECK
/sbin/iptables -A QUERY-CHECK -p udp -m string ! --string "getstatus"
--algo bm --from 32 --to 41 -j RETURN
/sbin/iptables -A QUERY-CHECK -p udp --sport 0:1025 -j DROP
/sbin/iptables -A QUERY-CHECK -p udp --sport 3074 -j DROP
/sbin/iptables -A QUERY-CHECK -p udp --sport 7777 -j DROP
/sbin/iptables -A QUERY-CHECK -p udp --sport 27015:27100 -j DROP
/sbin/iptables -A QUERY-CHECK -p udp --sport 25200 -j DROP
/sbin/iptables -A QUERY-CHECK -p udp --sport 25565 -j DROP
# is it already blocked? continue blocking it and update the counter so it
# gets blocked for at least another 30 seconds.
/sbin/iptables -A QUERY-CHECK -m recent --update --name blocked-hosts
--seconds 30 --hitcount 1 -j DROP
# check to see if it exceeds our rate threshold,
# and add it to the list if it does.
# /sbin/iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip
--hashlimit-name getstatus --hashlimit-above 2/second -j QUERY-BLOCK
# CentOS 5 or CentOS 6 compatible
/sbin/iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip
--hashlimit-name getstatus --hashlimit 2/s -j RETURN
/sbin/iptables -A QUERY-CHECK -j QUERY-BLOCK
# look at all the packets going to q3/cod*/et/etc servers
# /sbin/iptables -A INPUT -p udp --dport 27960:29000 -j QUERY-CHECK
/sbin/iptables -A INPUT -p udp --dport 27000:30000 -j QUERY-CHECK

./spamblock.bsh
iptables: Chain already exists.
iptables: Chain already exists.

iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
QUERY-CHECK udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:27000:30000

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain QUERY-BLOCK (1 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0 recent: SET name: blocked-hosts side: source

Chain QUERY-CHECK (1 references)
target prot opt source destination
RETURN udp -- 0.0.0.0/0 0.0.0.0/0 STRING match !"getstatus" ALGO name bm
FROM 32 TO 41
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp spts:0:1025
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:3074
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:7777
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp spts:27015:27100
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:25200
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:25565
DROP all -- 0.0.0.0/0 0.0.0.0/0 recent: UPDATE seconds: 30 hit_count: 1
name: blocked-hosts side: source
RETURN all -- 0.0.0.0/0 0.0.0.0/0 limit: up to 2/sec burst 5 mode srcip
QUERY-BLOCK all -- 0.0.0.0/0 0.0.0.0/0

Should I be concerned with " iptables: Chain already exists."?


On Thu, Feb 23, 2012 at 9:44 AM, Marco Padovan <evcz at evcz.tk> wrote:

>  sure, do it :)
>
> Il 23/02/2012 15:44, escapedturkey ha scritto:
>
> I support most Q3 engine games. Some go beyond the range specified in the
> original post.
>
>  Can I change:
>
>  iptables -A INPUT -p udp --dport 27960:29000 -j QUERY-CHECK
>
>  To:
>
>  iptables -A INPUT -p udp --dport 27000:30000 -j QUERY-CHECK
>
>  Or will that cause problems?
>
>  Ex: JK2 =28070 JA = 29070
>
> On Thu, Feb 23, 2012 at 9:30 AM, Marco Padovan <evcz at evcz.tk> wrote:
>
>>  Let us know if that works ;)
>>
>> Il 23/02/2012 15:20, escapedturkey ha scritto:
>>
>> Thank you. Much appreciated. =)
>>
>> On Thu, Feb 23, 2012 at 7:33 AM, Marco Padovan <evcz at evcz.tk> wrote:
>>
>>>  Ehm,
>>> nope :D
>>>
>>> You need all the lines John posted:
>>>
>>> http://icculus.org/pipermail/cod/2012-January/015861.html
>>>
>>> To make it works in centos5 / 6 change into that ruleset:
>>>
>>> iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip
>>> --hashlimit-name getstatus --hashlimit-above 2/second -j QUERY-BLOCK
>>>
>>> in this way (two different lines):
>>> iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip
>>> --hashlimit-name getstatus --hashlimit 2/s -j RETURN
>>> iptables -A QUERY-CHECK -j QUERY-BLOCK
>>>
>>>  all the other rules should be kept as they are :)
>>>
>>> Il 23/02/2012 13:10, escapedturkey ha scritto:
>>>
>>> Thank you. I missed those lines.
>>>
>>>  Here is what I have so far:
>>>
>>>  /sbin/iptables -N QUERY-BLOCK
>>> /sbin/iptables -A QUERY-BLOCK -m recent --set --name blocked-hosts -j
>>> DROP
>>> /sbin/iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip
>>> --hashlimit-name getstatus --hashlimit 2/s -j RETURN
>>> /sbin/iptables -A QUERY-CHECK -j QUERY-BLOCK
>>>
>>>  Is this correct?
>>>
>>>  Thank you again. =)
>>>
>>> On Thu, Feb 23, 2012 at 5:32 AM, Marco Padovan <evcz at evcz.tk> wrote:
>>>
>>>>  did you issued all the other commands?
>>>>
>>>> like:
>>>>
>>>>  iptables -N QUERY-BLOCK
>>>> iptables -A QUERY-BLOCK -m recent --set --name blocked-hosts -j DROP
>>>>
>>>>  ?
>>>>
>>>> Il 23/02/2012 03:54, escapedturkey ha scritto:
>>>>
>>>> iptables v1.4.7: Couldn't load target
>>>> `QUERY-BLOCK':/lib64/xtables/libipt_QUERY-BLOCK.so: cannot open shared
>>>> object file: No such file or directory
>>>>
>>>>  Any ideas?
>>>>
>>>>
>>>>  On Wed, Feb 22, 2012 at 4:51 PM, Marco Padovan <evcz at evcz.tk> wrote:
>>>>
>>>>>  on centos5 and centos6
>>>>>
>>>>> modifying this line:
>>>>>  iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip
>>>>> --hashlimit-name getstatus --hashlimit-above 2/second -j QUERY-BLOCK
>>>>>
>>>>> in this way (two different lines):
>>>>> iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip
>>>>> --hashlimit-name getstatus --hashlimit 2/s -j RETURN
>>>>> iptables -A QUERY-CHECK -j QUERY-BLOCK
>>>>>
>>>>> should mimic the same behaviour
>>>>>
>>>>> Il 22/02/2012 18:43, Geoff Goas ha scritto:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On CentOS 5.5, *--hashlimit-above* is not a valid option for the
>>>>> "hashlimit" match. Which version of iptables introduces this, and how can I
>>>>> mimic that same ruleset with the options available to me in version 1.3.5
>>>>> of iptables?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On Fri, Jan 20, 2012 at 7:51 PM, John <lists.cod at nuclearfallout.net>wrote:
>>>>>
>>>>>>  On 1/20/2012 3:27 PM, Marco Padovan wrote:
>>>>>>
>>>>>> I was referring to dynamic filtering using -m recent
>>>>>>
>>>>>>  [not] to manually adding IPs O.o
>>>>>>
>>>>>>
>>>>>> Marco's right about this. The most effective way to prevent effects
>>>>>> from these attacks on Linux is to use a combination of the "string",
>>>>>> "hashlimit", and "recent" modules. Done right, the solution is mostly
>>>>>> automatic, so you shouldn't need to manually add IPs.
>>>>>>
>>>>>> These commands, for instance, would block external IPs that send
>>>>>> queries at a rate of 2/second or higher:
>>>>>>
>>>>>> # add a host to the banlist and then drop the packet.
>>>>>> iptables -N QUERY-BLOCK
>>>>>> iptables -A QUERY-BLOCK -m recent --set --name blocked-hosts -j DROP
>>>>>>
>>>>>> # is this a query packet? if so, block commonly attacked ports
>>>>>> outright,
>>>>>> # then see if it's a known attacking IP, then see if it is sending at
>>>>>> a high
>>>>>> # rate and should be added to the list of known attacking IPs.
>>>>>> iptables -N QUERY-CHECK
>>>>>> iptables -A QUERY-CHECK -p udp -m string ! --string "getstatus"
>>>>>> --algo bm --from 32 --to 41 -j RETURN
>>>>>> iptables -A QUERY-CHECK -p udp --sport 0:1025 -j DROP
>>>>>> iptables -A QUERY-CHECK -p udp --sport 3074 -j DROP
>>>>>> iptables -A QUERY-CHECK -p udp --sport 7777 -j DROP
>>>>>> iptables -A QUERY-CHECK -p udp --sport 27015:27100 -j DROP
>>>>>> iptables -A QUERY-CHECK -p udp --sport 25200 -j DROP
>>>>>> iptables -A QUERY-CHECK -p udp --sport 25565 -j DROP
>>>>>> # is it already blocked? continue blocking it and update the counter
>>>>>> so it
>>>>>> # gets blocked for at least another 30 seconds.
>>>>>> iptables -A QUERY-CHECK -m recent --update --name blocked-hosts
>>>>>> --seconds 30 --hitcount 1 -j DROP
>>>>>> # check to see if it exceeds our rate threshold,
>>>>>> # and add it to the list if it does.
>>>>>> iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip
>>>>>> --hashlimit-name getstatus --hashlimit-above 2/second -j QUERY-BLOCK
>>>>>>
>>>>>> # look at all the packets going to q3/cod*/et/etc servers
>>>>>> iptables -A INPUT -p udp --dport 27960:29000 -j QUERY-CHECK
>>>>>>
>>>>>> The "recent" module makes it possible to block up to 100 IPs at once
>>>>>> with this method (any attackers beyond this would only be rate-limited).
>>>>>> That number can be raised when the module is loaded, but I haven't seen 100
>>>>>> attacks happening at once yet (typically it's maybe 5-20 at once). You can
>>>>>> see blocked hosts later by looking at /proc/net/xt_recent/blocked-hosts.
>>>>>>
>>>>>> (If you don't have "recent", you could get away without it -- just be
>>>>>> aware that some of the packets will get through, increasing load on the
>>>>>> game server. Without "hashlimit", you'd still see an advantage from the
>>>>>> port checks, but you'd need to manually block IPs that are being hit on
>>>>>> other ports. Without "string", you'd similarly be down to just port checks,
>>>>>> and need to take out the other rules.)
>>>>>>
>>>>>> -John
>>>>>>
>>>>>> _______________________________________________
>>>>>> cod mailing list
>>>>>> cod at icculus.org
>>>>>> http://icculus.org/mailman/listinfo/cod
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Geoff Goas
>>>>> Systems Engineer*
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cod mailing listcod at icculus.orghttp://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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cod mailing listcod at icculus.orghttp://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
>>>
>>>
>>>
>>> _______________________________________________
>>> cod mailing listcod at icculus.orghttp://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
>>
>>
>>
>> _______________________________________________
>> cod mailing listcod at icculus.orghttp://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
>
>
>
> _______________________________________________
> cod mailing listcod at icculus.orghttp://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20120223/c0745142/attachment-0001.htm>


More information about the cod mailing list