Yes, status will not give an answer continuously, but the server is
still processing the command (even if it doesnt give an answer due to
the protection), so the overflow occurs. I guess the engine protection
is enabled due to the fact it wont continuously answer in a visible
manner to the command. I will do the cleaning and reinstalling anyways,
just in case.
For the "send reliable overflow" thing, what we found to avoid that
limitation (and what we thing the attacker is actually making somehow)
is bind the cfg with fewer status lines (the one that wont trigger
instantly that) to a couple keys, then press them quickly and
alternatively, so the message wont come out and the server eats all the
statuses. It's a quick and dirty solution, I guess the attacker has some
way to make something similar automatically...
I have quickly tried the alias method suggested by 1nsane and seems to
work! I have still to try it better, I think we only scratched what the
attacker is really doing and our simulated attacks are just like 10% of
what we experience on a real attack, so let me see during a real attack.
If it really works, that would make a perfect workaround until we find a
real solution or the root of the problem, so many, many thanks. Thank
you all for your interest!
I feel that I should dig deeper on the status processed as 0 client
issue, it's very weird, and looks like some kind of vulnerability to me.
El 13/06/2012 4:37, Invalid Protocol escribió:
I did few tests using a TF2 Linux server:
a) The anti-spam protection from engine works: a client receives back only
one response every few seconds.
b) The source for "status" command, at least from SourceMod's point of view,
is always the server (client's index is always 0).
I connected two clients to a server and one executed a script with 457
status commands. The server and the second client were ok, but the one who
executed the script died with "send reliable stream overflow" error. For a
script with 456 status commands the client receives back one reply and
doesn't die.
Probably you have something that disables engine's protection. Try to remove
all plugins (metamod, sourcemod etc...) and see if the server is still
vulnerable. Then add back the plugins, one by one...
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Alvaro
Gutierrez Lorenzo
Sent: Wednesday, June 13, 2012 2:50 AM
To: Half-Life dedicated Linux server mailing list
Subject: Re: [hlds_linux] Overflow attack to Source servers
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.
_______________________________________________
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
