[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