[cod] CoD2 UDP flood

Marco Padovan evcz at evcz.tk
Thu Feb 23 09:30:52 EST 2012


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
> <mailto: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
>>     <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 <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/8c2ad751/attachment-0001.htm>


More information about the cod mailing list