[cod] CoD2 UDP flood

escapedturkey escapedturkey at escapedturkey.com
Thu Feb 23 07:10:04 EST 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20120223/d98e134e/attachment.htm>


More information about the cod mailing list