[cod] CoD2 UDP flood

[RedDragon - Leader]

If you change these settings to a higher limit your server isnt save
again against udp flood.

Greetz RedDragon

Am 29.01.2012 11:36, schrieb Andrej Parovel:
> Hello,
>
> Thank you, I assumed it was these iptables problem, because i had
> never before these problems. With less strict do you mean these line:
>
> iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip
> --hashlimit-name getstatus --hashlimit-above 2/second -j QUERY-BLOCK
>
> to rise up these value (2 second)? Or maybe some other too?
>
> Thank you
>
> Andrej
>
> +386 31 247 707
> aparovel at gmail.com
>
> On 28.1.2012 20:52, B.M. Schiltmans wrote:
>> If you're using hlsw as rcon-tool, then yes I noticed that too.
>> Since hlsw is querying your server at quite a high rate, your filters
>> start dropping traffic. Ergo, no query-result and no rcon.
>> When you shut hlsw down, your filters relax and you can connect again.
>> Not sure if the query-interval is settable in hlsw, but you could
>> always try setting your filters a little less strict.
>>
>> Hope that helps.
>>
>> Grtz
>> Bram
>>
>> On 28-1-2012 20:35, Andrej Parovel wrote:
>>> Hello,
>>>
>>> Did maybe anybody notice or have the problem when applying iptables
>>> script witch is in the reply, that you can't then connect on RCON
>>> and also I can't reach my servers over HSLSW, but you can connect on
>>> the server and it is actualy running ok.
>>> Just rcon connecting problems and HSLW reaching.
>>>
>>> Thank you.
>>>
>>> Andrej
>>>
>>> +386 31 247 707
>>> aparovel at gmail.com
>>>
>>> On 21.1.2012 1:51, John 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
>>>
>>>
>>> _______________________________________________
>>> cod mailing list
>>> cod at icculus.org
>>> http://icculus.org/mailman/listinfo/cod
>>
>>
>> _______________________________________________
>> cod mailing list
>> cod at icculus.org
>> http://icculus.org/mailman/listinfo/cod
>
>
> _______________________________________________
> 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/20120129/59d6a8c1/attachment.htm>