With 1000ports protected and 4 rules for each port on simple testserver (xeon 3430):

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    7 root     -76   0     0    0    0 S 29.5  0.0 204:01.74 sirq-net-rx/0
   21 root     -76   0     0    0    0 S  8.3  0.0   9:02.45 sirq-net-rx/1
15408 ***   20   0  620m 506m  18m S  6.6  6.3 114:34.22 srcds_linux
12249 ***   22   2  363m 291m 3420 R  4.6  3.6   3:35.13 cod4_lnxded
 8495 ***   20   0 83864  19m 2104 S  3.6  0.2 545:31.54 hlds_i686
 8649 ***   20   0  173m  61m 7416 S  3.0  0.8 516:10.89 srcds_linux

29.5% + 8.3% of cpu usage just to correct an engine defect is too much...

currently, on that test box, there are like 10 servers protected... the rest are servers that does not need protection (cod, voice and so on)... and the traffic flow is very very very low!

Monitoring eth0...    (press CTRL-C to stop)

   rx:      632 kbit/s   777 p/s          tx:      308 kbit/s   220 p/s

:(

Il 06/01/2011 12:02, Arie ha scritto:
Ronny and me wrote that blogpost on vanillatf2. During our tests the filter
seemed effective and not causing too much CPU usage even when sending
multiple megabytes worth of packets per second, so I'm curious why you say
it's not going to work for you.

It would of course be better if the gameserver itself would use
sv_max_queries_sec_global properly. Right now this setting doesn't help
against these attacks.



On 5 January 2011 23:42, Marco Padovan<evolutioncr...@gmail.com>  wrote:

I'm hosting many tf2 servers and lately we are getting a lot of denial of
services...

basically we got our machservers spammed with query requests till the point
they time out (the machine is running properly, it's just the gameserver
slowly dieing)

an effective way to stop this kind of behaviour is:
http://www.vanillatf2.org/2011/01/fighting-dos-attacks/

but that cannot be handled properly on boxes as busy as ours...

basically with just little effort anybody is able to take down a single
gameserver spamming it with query requests :(

What can we do to stop that?
Is there a decent plugin/official fix to get rid of this problem instead of
doing packet inspection via iptables on boxes handling 10000+
packets/second?
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux

_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux

Reply via email to