[cod] CoD2 UDP flood

Marco Padovan evcz at evcz.tk
Thu Feb 23 07:33:19 EST 2012


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
> <mailto: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
>>     <mailto: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
>>>         <mailto: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 <mailto:cod at icculus.org>
>>>             http://icculus.org/mailman/listinfo/cod
>>>
>>>
>>>
>>>
>>>         -- 
>>>         /*Geoff Goas
>>>         Systems Engineer*/
>>>
>>>
>>>
>>>         _______________________________________________
>>>         cod mailing list
>>>         cod at icculus.org <mailto:cod at icculus.org>
>>>         http://icculus.org/mailman/listinfo/cod
>>
>>         _______________________________________________
>>         cod mailing list
>>         cod at icculus.org <mailto: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 <mailto:cod at icculus.org>
>>     http://icculus.org/mailman/listinfo/cod
>
>     _______________________________________________
>     cod mailing list
>     cod at icculus.org <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20120223/01ef046e/attachment-0001.htm>


More information about the cod mailing list