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.
H
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 k
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
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" ha
scritto:
___
To unsubscribe, edit your list preferences, or view the list archives,
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,
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 year
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" 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 statu
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 id
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 li
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 is
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" ha
scritto:
> On Thu, Jan 06, 2011 at 04:16:23PM +0100, M
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 wrote:
> 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
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 la
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 -- * *
0.
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
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 matc
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 20
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 sirq-
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 s
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 gameserve
20 matches
Mail list logo