How does your ip tables rules look. Like ?
Den 8 jan 2011 03.56 skrev Marco Padovan evolutioncr...@gmail.com:
Il 08/01/2011 01:01, frostschutz ha scritto:
On Fri, Jan 07, 2011 at 11:50:56PM +0100, Marco Padovan wrote:
I suppose those are all spoofed udp packets as they were the last
this should do the trick:
iptables -N QUERYLIMIT
iptables -A QUERYLIMIT -m hashlimit --hashlimit-mode dstport
--hashlimit-name srcdsquery --hashlimit 20/s --hashlimit-burst 10 -j ACCEPT
iptables -A QUERYLIMIT -j DROP
iptables -N QUERY
iptables -A QUERY -p udp -m udp -m string --algo bm
box keeping up :)
50k packets dropped in just 15minutes
Chain QUERYLIMIT (4 references)
pkts bytes target prot opt in out
source destination
346357 17999035 ACCEPT all -- * *
0.0.0.0/00.0.0.0/0 limit: avg 15/sec
On Fri, Jan 07, 2011 at 08:09:40PM +0100, Marco Padovan wrote:
20 minutes later:
Chain QUERYLIMIT (4 references)
pkts bytes target prot opt in out source
destination
396253 20611768 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
I thoutgh about that too... but monitoring the situation closely it
appear to be cristal clear:
http://pastebin.com/asHm8GkW
I getting spikes of 50k packets in very short periods (60seconds)
I'll try to monitor all my servers in HLSW seeing how much time they are
going offline...
btw...
No offense, but have you tried to look at where those dos attack comes from?
You could block the IP-address of the attacker.
/Chris
Den 07/01/2011 kl. 22.32 skrev Marco Padovan:
I thoutgh about that too... but monitoring the situation closely it appear to
be cristal clear:
I suppose those are all spoofed udp packets as they were the last time I
checked them :(
I do not have direct access to the upstream links so I cannot trace them
and link them to a specific bw supplier :(
just increased the limits but still getting the drop rule hit hard...
it's difficult
You could use iptraf do look after the packets. You can configure it to put all
the packet-logs into a file and then take a look at the file.
/Chris
Den 07/01/2011 kl. 23.50 skrev Marco Padovan:
I suppose those are all spoofed udp packets as they were the last time I
checked them :(
I do
On Fri, Jan 07, 2011 at 11:50:56PM +0100, Marco Padovan wrote:
I suppose those are all spoofed udp packets as they were the last time I
checked them :(
Only you can tell. (We can't look at the packets you're getting:)
it's difficult to justify these spikes as legit traffic..
10k spikes are
Il 08/01/2011 01:01, frostschutz ha scritto:
On Fri, Jan 07, 2011 at 11:50:56PM +0100, Marco Padovan wrote:
I suppose those are all spoofed udp packets as they were the last time I
checked them :(
Only you can tell. (We can't look at the packets you're getting:)
Didn't took the time because
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
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.
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
in the engine. A cvar to limit the number of queries per
second would be great.
- Dave
- Original Message -
From: Marco Padovan evolutioncr...@gmail.com
Date: Wednesday, January 5, 2011 5:42 pm
Subject: [hlds_linux] tf2 denial of service - please do something!
To: Half-Life dedicated Linux
Normally, the packets that are send in other byte sizes, because srcds can't
handle those bytesizes (i think).
All the DoS-attacks i had used the packet size of either 24 or 46. I solved
this by blocking this byte size on the port (27015). I haven't had any DoS'es
since.
Regards.
Chris
32 matches
Mail list logo
