[cod] CoD2 UDP flood

Marco Padovan evcz at evcz.tk
Thu Feb 23 09:44:48 EST 2012


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


More information about the cod mailing list