I should clarify... Using an iptables rule like that assumes that the
status request packets are always the same size, and they are a
different size than the normal game data packets. You can also do
string matching within packets using iptables (if you have the
appropriate modules installed), but on a game server, that would
probably add so much processing overhead it's not even worth it.
- Dave
On 06/15/2012 12:40 PM, David Parker wrote:
I guess one way Valve could solve this would be to change the way
"status" works on the client. They could have the server send
server-state information to the clients at some interval, like once
per second, or perhaps each time something changes (player joins or
leaves, map changes, etc.) and then have the "status" command on the
client just read its most recent data. That would prevent status
requests from hitting the server at all. It adds some overhead
compared to the real-time request/reply method, but it eliminates the
need to process each status request that comes in.
Or, if the incoming "status" packets are always the same size, you
could also use iptables to rate-limit them (just replace N with the
packet size in bytes):
iptables -A INPUT -p udp -m length --length N -m limit --limit 3/s -j
ACCEPT
(Note: I didn't test this iptables rule, I just slapped it together as
a demonstration)
- Dave
On 06/14/2012 03:06 PM, Alvaro Gutierrez Lorenzo wrote:
I don't think it's still a popular attack, since it is only useful
when you can't ban in an effective way the attacker (e. g.
Free-to-Play scheme). I dont think it's a widely known attack, on my
case it was just a single person who was attacking all our servers,
as we verified comparing IPs.
What I would suggest you to do is to have SMAC (Sourcemod anti-cheat)
command monitor plugin running, and from time to time (or everytime
find there are lag issues) check this plugin's logs (called
cmd_[date].log, under the Sourcemod's log directory) to see if
someone is attacking you by this means. It's easy to spot even
without actually opening the log file, a usual day log will not grow
over 1MB while when you have been attacked the log will easily reach
300Mb (I've seen >3Gb log files on my server because of this). Inside
it looks like thousands of lines stating
"[date]: Console<0><Console><Console> executes: status" during a
single second.
If you ever spot this attack, then you could take this measure to
stop it. Meanwhile, I would not take much care, since it's easy and
quick to solve (thanks to the people on this mailing list, thank you
all again ;) ).
El 14/06/2012 20:46, doc escribió:
Kind of a scary thread, I do a lot of terrible data collection on my
own
server/website using the "status" command and I'd hate to have to
alias it
to nothing to avoid problems like this.
Is this something I assume is important enough to look into?
On Wed, Jun 13, 2012 at 5:40 AM, Alvaro Gutierrez Lorenzo<
rugnor.maj...@gmail.com> wrote:
It worked perfectly! Simple attack, simple solution.
Never thought of this ways, now it seems so obvious XD
I made plugins and searched for the most strange ways of solving
it, yet
it was "single-line" simple ^^
Well, it disables status, but that's a minimal sacrifice (SMAC
provides a
secure alternative also, so there's no problem at all).
I will spread this through the servers I know: each and every one is
victim of this issue, that makes over a dozen grateful servers&
communities, many thanks ^^
I've checked this happens without any mods, so some official
attention on
this would be the perfect happy ending, but this workaround solves the
problem so everything fine!
El 13/06/2012 4:04, 1nsane escribió:
While not a good solution at all. Have you tried aliasing status to
nothing?
"alias status"
This will obviously disable the status command entirely. But
perhaps it
won't kill the server then?
On Tue, Jun 12, 2012 at 7:49 PM, Alvaro Gutierrez Lorenzo<
rugnor.maj...@gmail.com> wrote:
Sorry for the "double mail", I just though that if the fix for that
removed the cooldown time for status, there would be no
protection over
this command, making possible this attack.
Invalid Protocol mentionned this protection on an earlier mail.
Is it a silly idea? I've never experienced such cooldown
protection, that
would explain why.
El 13/06/2012 1:31, Joe Brown escribió:
This was used (and may still be) in hacks as a way to stop
admins from
using the status command to see your STEAMID in the client console.
Spamming it like that blocked all clients connected to the
server from
being able to use the status command, preventing or extending
the time
it
takes to ban someone.
Correct me if I'm wrong but I thought the was fixed in an update.
Date: Wed, 13 Jun 2012 01:23:23 +0200
From: rugnor.maj...@gmail.com
To: hlds_linux@list.valvesoftware.****com<hlds_linux@list.**
valvesoftware.com<hlds_linux@list.valvesoftware.com>>
Subject: Re: [hlds_linux] Overflow attack to Source servers
That's a critical detail I forgot to mention, so sorry: RCON
is port
closed, so every attempt to access RCON gives a "Time Out".
I'm totally sure it's "status", here I paste an excerpt from
the SMAC
log, made just by the same plugin you suggest:
Sat Mar 31 14:56:34 2012: Console<0><Console><Console>
executes:
status
Sat Mar 31 14:56:34 2012: Console<0><Console><Console>
executes:
status
Sat Mar 31 14:56:34 2012: Console<0><Console><Console>
executes:
status
Sat Mar 31 14:56:34 2012: Console<0><Console><Console>
executes:
status
Sat Mar 31 14:56:34 2012: Console<0><Console><Console>
executes:
status
Sat Mar 31 14:56:34 2012: Console<0><Console><Console>
executes:
status
Sat Mar 31 14:56:34 2012: Console<0><Console><Console>
executes:
status
Sat Mar 31 14:56:34 2012: Console<0><Console><Console>
executes:
status
Sat Mar 31 14:56:34 2012: Console<0><Console><Console>
executes:
status
...
(Well an this goes on for thousands and thousands of lines, making
pretty ~1GB files each day XD)
I added status as a SMAC blocked command, still no luck. (used
smac_addcmd as stated in the link you provided, but as you say
SMAC
wont
block commands coming from the server).
The command can be captured and processed prom a plugin, but in
every
teast I made I always got client 0 (console) as the triggerer, (of
course testing from the game, through a clean client account,
not from
console). I think the server has never blocked me from executing
status,
even reproducing the attack (which is just spamming status from a
game's
client console).
The server would block it surely if it was marked as client
triggered.
At least where I can personally try (TF2 dedicated, Linux),
it's always
executed as from console. Some other server owners are working
with me
on this, and this works like this on their's too (CSS and CSGO
confirmed
to be vulnerable to this attack too).
Something that comes to my mind is if some "lower" addon like
Metamod
is actually always deflecting this command through the console;
I need
to try again on a clean install to check it.
______________________________****_________________
To unsubscribe, edit your list preferences, or view the list
archives,
please visit:
https://list.valvesoftware.****com/cgi-bin/mailman/listinfo/***
*hlds_linux<https://list.**valvesoftware.com/cgi-bin/**
mailman/listinfo/hlds_linux<https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux>
______________________________****_________________
To unsubscribe, edit your list preferences, or view the list
archives,
please visit:
https://list.valvesoftware.****com/cgi-bin/mailman/listinfo/***
*hlds_linux<https://list.**valvesoftware.com/cgi-bin/**
mailman/listinfo/hlds_linux<https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux>
______________________________**_________________
To unsubscribe, edit your list preferences, or view the list
archives,
please visit:
https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux>
______________________________**_________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux>
_______________________________________________
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
--
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux