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
I'm getting high cpu usage because, due to how our system works, we had
to filter ALL the ports... even the ports where other gameservers type
(call of duty, mumble voice server and all the other) were running...
I'm just talking of only 20mbits/sec dataflow... but appear to be enough
to put
With 1000ports protected and 4 rules for each port on simple testserver
(xeon 3430):
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
7 root -76 0 000 S 29.5 0.0 204:01.74 sirq-net-rx/0
21 root -76 0 000 S 8.3 0.0 9:02.45
1000 ports? you say below 10 servers are protected, if it has sourcetv too
thats in total 20 ports x4 = 80 ports..
I only protect the ports that need protecting by only selecting the ports
of the source servers.
Dont know your setup further though, but here it seems running ok.
On Thu, 06 Jan
On Thu, Jan 06, 2011 at 01:19:32PM +0100, Marco Padovan wrote:
With 1000ports protected and 4 rules for each port on simple testserver
If you're saying that each packet has to traverse 4000 rules
in your setup, then that would explain why it's so slow.
Is the port number relevant for the
On Thu, Jan 06, 2011 at 01:58:13PM +0100, frostschutz wrote:
Can you post an (excerpt) of the rules you're using?
Noticed this was posted earlier.
Note: This is _untested_, it's been a while since I used iptables.
$IPTABLES -N QUERYLIMIT
$IPTABLES -A QUERYLIMIT -m limit --limit 20/s -j ACCEPT
Chain QUERYLIMIT (4 references)
pkts bytes target prot opt in out
source destination
180990905 ACCEPT all -- * *
0.0.0.0/00.0.0.0/0 limit: avg 20/sec burst 5
110 4974 DROP all -- * *
On Thu, Jan 06, 2011 at 04:16:23PM +0100, Marco Padovan wrote:
as suspected that appear to keep a single bucket and allowing 20/sec on
the whole server... not on every single port :(
Yes, it's a single bucket. Does it really have to be per server?
I'd just use a sane value for limit and a
My guess is the person that is doing the attack is on this reading the little
discussion. :p
Sent from my iPhone 4
On Jan 6, 2011, at 7:47 AM, frostschutz frostsch...@metamorpher.de wrote:
On Thu, Jan 06, 2011 at 04:16:23PM +0100, Marco Padovan wrote:
as suspected that appear to keep a
Ok will see what will happen this evening...
Fail2ban cannot help due to spoofed ips.
The single bucket is problematic due to how we manage the gameservers, will
update the status this evening :p
Il giorno 06/gen/2011 16.50, frostschutz frostsch...@metamorpher.de ha
scritto:
On Thu, Jan 06,
It seems you have never heard of:
sv_max_queries_sec
sv_max_queries_sec_global
sv_max_queries_window
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
On Thu, Jan 06, 2011 at 06:14:01PM +0100, Ronny Schedel wrote:
It seems you have never heard of:
sv_max_queries_sec
sv_max_queries_sec_global
sv_max_queries_window
Those do not work properly. Just so you know.
___
To unsubscribe, edit your list
On Thu, Jan 06, 2011 at 05:28:43PM +0100, Marco Padovan wrote:
The single bucket is problematic due to how we manage the gameservers, will
update the status this evening :p
So I came across this in the iptables man page...
hashlimit
This patch adds a new match called 'hashlimit'. The
Nice! Will give it a try if it's already part of the kernel I use :)
Thank you
Il giorno 06/gen/2011 18.43, frostschutz frostsch...@metamorpher.de ha
scritto:
On Thu, Jan 06, 2011 at 05:28:43PM +0100, Marco Padovan wrote:
The single bucket is problematic due to how we manage the gameservers,
Hello.
Now one unfortunate fact about DoS attacks is that they are designed
to interrupt service. The main reason why they work so well is
because UDP packets can be spoofed. Thus you are unable to identify a
IP to ban as the IPs reported will not be the real source of the
packet. Almost a
While true, it is somewhat different in matters of actual possession of
resources to blow a connection out of the sky with 40x155mbit hacked boxes
and able to take down 5-6 different gameservers with your crappy 512kbit
dsl-line from home due to improper handling of packets.
-TheG
On Thu, Jan 6,
I agree... this is not a matter of bandwidth but it has to do with improper
packet handling of a small amount of traffic...
Il giorno 06/gen/2011 22.52, Björn Rohlén bjorn.roh...@gmail.com ha
scritto:
___
To unsubscribe, edit your list preferences, or
hashlimit was exactly what I needed!
Set it up correctly ... will see tomorrow what will happen :)
Il 06/01/2011 18:40, frostschutz ha scritto:
On Thu, Jan 06, 2011 at 05:28:43PM +0100, Marco Padovan wrote:
The single bucket is problematic due to how we manage the gameservers, will
update the
On Fri, Jan 07, 2011 at 12:36:10AM +0100, Marco Padovan wrote:
hashlimit was exactly what I needed!
Set it up correctly ... will see tomorrow what will happen :)
Great... :)
My own box runs without iptables and TF2 servers without mods.
No problems so far - I'm not running anything well
There were bots spoofing their IPs doing the stupid packet length
attack (The one that you can preform with ease on Dialup). I stopped
checking my kern.log files a while ago as none of the IPs matched up
with any players. The fix for this is simple, install DAF, or filter
the port with IPTables.
20 matches
Mail list logo
