Re: [Csgo_servers] Why does Valve want to keep the CS client and server side consistent?

[via csgo_servers list]

To my understanding the standalone dedicated server will be returning 
for CS2, it's just currently "/valve time'd./"

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] Why does Valve want to keep the CS client and server side consistent?

[via csgo_servers list]

Hello there,


Ever since CS:GO I've been wondering what the "Dedicated" in "Dedicated 
Server" means.


On the server side, the same files still have to be downloaded as on the 
client side. This results in 30+ GiB of space on the server.



This creates a huge waste of space. I think the server does need some 
data, but not at all the files of images, music and videos, etc.



Now in CS2, Valve has even removed the "Dedicated Server". As a result, 
users must be logged into their Steam account to download the server.



What exactly has led to this situation today?


Best regards,

Gentry

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] What do we make of the "Community Dedicated Server" note in the 9/28 Release Notes?

[via csgo_servers list]

oh well, I neglected to mention that 
<https://steamdb.info/app/730/history/?changeid=20460215>, thanks for 
the heads up.


在 2023/10/1 0:59, Isla 写道:
The game has been available on Linux since release. Simply download 
730, you can't use anonymous login to download it though so make a 
throw away account (I like to remove the steam guard as well) and done


On Sat, 30 Sept 2023 at 18:57, wordlesswind - i at qingly.me 
<http://qingly.me> (via csgo_servers list) 
 wrote:


https://store.steampowered.com/news/app/730/view/3747614808342659052/



[ COMMUNITY DEDICATED SERVERS ]

  * To launch a community dedicated server, you can use this
reference command line:

  * cs2 -dedicated +map de_dust2

  * To enable logging, add to your server commandline:

  * +sv_logfile 1 -serverlogging

  * Or add to a config file:

  * sv_logfile 1
  * log on

  * To enable HTTP logaddress forwarding, ensure logging is
enabled as above and use:

  * logaddress_add_http ":"

  * Dispatched logs can be handled the same way as CS:GO



This is a note made because native CS2 Linux clients and servers
will not be considered for some time. Or is it because there is no
native Linux side anymore due to Proton working well?

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] What do we make of the "Community Dedicated Server" note in the 9/28 Release Notes?

[via csgo_servers list]

https://store.steampowered.com/news/app/730/view/3747614808342659052/



[ COMMUNITY DEDICATED SERVERS ]

  * To launch a community dedicated server, you can use this reference
command line:

  * cs2 -dedicated +map de_dust2

  * To enable logging, add to your server commandline:

  * +sv_logfile 1 -serverlogging

  * Or add to a config file:

  * sv_logfile 1
  * log on

  * To enable HTTP logaddress forwarding, ensure logging is enabled as
above and use:

  * logaddress_add_http ":"

  * Dispatched logs can be handled the same way as CS:GO



This is a note made because native CS2 Linux clients and servers will 
not be considered for some time. Or is it because there is no native 
Linux side anymore due to Proton working well?

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] Okay, so the waiting is over and .... nothing.

[via csgo_servers list]

I mean, they did say Community servers won’t be there at launch.


> Can I run or play on community servers in Counter-Strike 2?
> 
> Not at launch, but Community server support is coming soon.

https://help.steampowered.com/en/faqs/view/5ED2-ED8E-81F4-0C18
Steam Support :: Counter-Strike 2 Release
help.steampowered.com


> On 28 Sep 2023, at 00:17, Mecha Weasel  wrote:
> 
> Existing CS:GO server installation (app id 740) says it is already up to date.
> Of course, I don't believe this because manually running an update on it via 
> SteamCMD didn't download any new content.
> 
> Trying to connect from CS:GO / CS2 client (whatever we're calling it), when I 
> try to manually connect to server with "connect" command in console, it says:
> 
> "Unable to establish a connection to the game-server"
> 
> So much for those believing that before the launch Valve would bother to 
> update community server operators on what's happening, and what (if anything 
> to do).  This is EFFECTIVELY abandonment.
> 
> 
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com /
> 

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] About compression algorithms

[via csgo_servers list]

It seems that Valve is still using bzip2 to distribute CS2 demos and 
other files. This reminds me that as of now, Steam is still using LZMA 
instead of the improved LZMA2. and not Zstandard, which is considered 
even better.


Wouldn't switching to a better compression algorithm give better gains?
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] CS2 dedicated servernotes?

[Cheriny - i at qingly.me (via csgo_servers list)]

Didn't the Reborn update for Dota 2 overwrite an older version of Dota 2?

Artifact is a failure and not informative. Valve has always been a 
strong company in my eyes and if they aren't showing it then they 
realize that in some ways they are missing the mark.


在 2023/9/9 10:38, Vi 写道:


This is unlikely from valve. For example, when artifact tried having a 
remake to improve the game, they instead split the game into two apps, 
where both includes each other. This is more likely than a full 
delisting, and would make sense with the track record that Valve has. 
Valve is not one to pull a service offline, even if it ends up being 
abandoned. If you have a source of otherwise, please share. Otherwise, 
hoping for the worst like that is not the best situation.


On 2023-09-07 09:47 am, Cheriny - i at qingly.me (via csgo_servers 
list) wrote:
keeping the old version of the game would be detrimental to the new 
game. 


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] CS2 dedicated servernotes?

[Cheriny - i at qingly.me (via csgo_servers list)]

Overwatch 2 was playable in the Chinese mainland before Blizzard and 
NetEase broke their contract.


As well, I don't think Valve will keep CS:GO. CS2 has been changed to 24 
rounds, and keeping the old version of the game would be detrimental to 
the new game.



在 2023/9/7 21:40, Naleksuh 写道:
As far as I know that's only the case in China. Do you have a source 
that CSGO is becoming unplayable globally?




 On Wed, 06 Sep 2023 11:52:55 -0700 *Bakugo * 
wrote ---


This is literally just another Overwatch 2 situation. CS2 is a
mandatory update to CSGO, it is not a new game that exists
separately. Maybe they'll be kind enough to keep an old branch
around so you can still play it on community servers, but
matchmaking will definitely not be available and inventories
probably won't either.

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re:[Csgo_servers] CS2 dedicated servernotes?

[Cheriny - i at qingly.me (via csgo_servers list)]

Relax friends, Valve didn't even provide servers to partner Perfect 
World, even though Perfect World doesn't have access to the servers, 
which are entirely maintained by Valve. However CS2 (which will most 
likely be known as the new CS:GO in the Chinese mainland due to legal 
restrictions that require the game's name change to be applied to the 
government) has yet to go live in the Chinese mainland.


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] The possibility of the community-driven Datagram Relayservice

[via csgo_servers list]

I verified this and unfortunately "-enablefakeip" is not present in 
"engine(2).dll" for CS:GO, CS:GO DS or CS2, so it doesn't apply to CS. 
So let's hope that official support or community support will follow.


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re:[Csgo_servers] The possibility of the community-driven Datagram Relayservice

[via csgo_servers list]

Thank you Isla for telling me this. According to the Valve Developer 
Community 
, 
it seems to be available in CS:GO, the question is whether it can be 
used on dedicated servers and whether this "Fake IP" is persisted for 
sharing?

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] The possibility of the community-driven Datagram Relay service

[via csgo_servers list]

Hello,


As far as I know, the Counter-Strike community servers have been 
subjected to DDoS attacks from competitors for a long time. This 
situation is exaggerated to the point that anytime a server is made 
public it will be attacked.


So that led to only a few teamed community servers existing near me. I 
wonder if it would help to have a professional anti-DDoS company launch 
a network access service for Counter-Strike. But currently, in order to 
use the anti-DDoS service, we have to use the servers they provide, not 
just the access network.


If Counter-Strike were to launch a community-driven Datagram Relay 
service with associated programs, would it be possible for people to 
access Datagram Relay for Counter-Strike game servers in the same way 
that they can access WAF for websites?



Best regards,

wordlesswind

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] Feasibility of running the server on FreeBSD

[via csgo_servers list]

Hello everyone,

I have recently developed a keen interest in FreeBSD and I would like to 
migrate some projects to FreeBSD.


I was wondering if any of you have successfully run a CS:GO server with 
plugins on FreeBSD? How is the situation?


Or does Valve have a focus on running CS:GO / CS2 servers on FreeBSD?

I did find some information online, such as this: 
https://help.steampowered.com/faqs/view/02F3-F456-2A32-C298/


This may not seem like a problem, but is FreeBSD's Linux binary 
compatibility really that good?


Best regards,
wordlesswind
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Sv: Re: [hlds_linux] Re: [Csgo_servers] Counter-Strike 2 Test Dedicated Server?

[via csgo_servers list]

The game just released to beta. It will take some time before something like 
sourcemod will work.

Med venlig hilsen / Kind regards
Dennis Hermannsen
Prima Servers ApS [https://primaservers.com]


På 24-03-2023 11:36:26, ?? - number201724 at me.com (via csgo_servers list) 
 skrev:
It looks like cs2 does not have server plugin(addons) loading like csgo, 
metamod and sourcemod are broken.

在 2023年3月24日，下午4:08，Mecha Weasel  写道：



I spotted this video online. Of course, I can not be sure information contained 
is actually accurate.
https://youtu.be/ruGmwiE_xyI?t=20 [https://youtu.be/ruGmwiE_xyI?t=20]


It implies the need for community servers to get off any old Linux releases - 
mentioning Ubuntu 20.04 or later and Debian 11 or later.
It also seems to emphasize a long-term strategy to move dedicated servers to 
Docker containers, instead of running directly on the OS.

As I said, not sure about the reliability of the information.
But, short of official statements from Valve (hint), 





On Thu, Mar 23, 2023 at 12:37 PM Michael Flaherty - michaelwflaherty at me.com 
[http://me.com] (via csgo_servers list) mailto:csgo_servers@list.valvesoftware.com]> wrote:

You may run a dedicated server from the cs2 client with the following.

cs2.exe -dedicated 

There's no word of a separate "src2ds" bin, nor any further elaboration for the 
future of community servers from Valve. There's a blog post coming sometime in 
the future regarding this topic, we'll have to wait.

Thanks,

- Michael Flaherty

On Mar 23, 2023, at 12:31 PM, Mecha Weasel mailto:weasel.steamid@gmail.com]> wrote:



Is there any information available yet on hosting CS2 community servers? Just 
an updated CS:GO server install? or something more complicated?

Will there be a test dedicated server install available to the community during 
the CS2 test?

- Weasel
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com [https://list.valvesoftware.com]/
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com [https://list.valvesoftware.com]/
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com [https://list.valvesoftware.com]/
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] Counter-Strike 2 Test Dedicated Server?

[via csgo_servers list]

You may run a dedicated server from the cs2 client with the following.cs2.exe -dedicated There's no word of a separate "src2ds" bin, nor any further elaboration for the future of community servers from Valve. There's a blog post coming sometime in the future regarding this topic, we'll have to wait.Thanks,- Michael FlahertyOn Mar 23, 2023, at 12:31 PM, Mecha Weasel  wrote:Is there any information available yet on hosting CS2 community servers? Just an updated CS:GO server install? or something more complicated?Will there be a test dedicated server install available to the community during the CS2 test?- Weasel
___To unsubscribe, edit your list preferences, or view the list archives,please visit:https://list.valvesoftware.com/___To unsubscribe, edit your list preferences, or view the list archives,please visit:https://list.valvesoftware.com/

Re: [Csgo_servers] Custom map downloads from community servers broken?

[via csgo_servers list]

No issues over here regarding FastDL either.

- Tito
Head of Community Relations and Management

Killzone Gaming

Sent from mobile.

On Thu, 9 Feb 2023, 10:15 pm Dennis Hermannsen - dennis at primaservers.com
(via csgo_servers list),  wrote:

> I don't see any problems with fast download on any of our servers.
> Could it be that you're serving the content over HTTPS but the SSL
> certificate expired?
>
> Med venlig hilsen / Kind regards
> *Dennis Hermannsen*
> Prima Servers ApS <https://primaservers.com>
>
> På 08-02-2023 00:22:08, Weasel [Saphe.Space]  skrev:
> BUG?: Custom map downloads from community servers broken?
> I've always been able to connect to my community servers, get downloads
> quickly (via fast-download URL, etc) for custom maps. models, sounds, etc.
> without any problems.
>
> It's been a few weeks since the last time I played. I logged-in Yesterday
> to play, and the downloading of much of that custom stuff (in particular
> custom maps) seems broken - even though I have client-side settings set to
> allow all downloads from servers, etc.
>
> Is this just ME? or happening for everyone? Is it documented somewhere as
> an intentional "feature" (perhaps to force use of maps from the "Workshop"
> instead?)?
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/
>
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Sv: [Csgo_servers] Custom map downloads from community servers broken?

[via csgo_servers list]

I don't see any problems with fast download on any of our servers.
Could it be that you're serving the content over HTTPS but the SSL certificate 
expired? 

Med venlig hilsen / Kind regards
Dennis Hermannsen
Prima Servers ApS [https://primaservers.com]


På 08-02-2023 00:22:08, Weasel [Saphe.Space]  skrev:
BUG?: Custom map downloads from community servers broken?
I've always been able to connect to my community servers, get downloads quickly 
(via fast-download URL, etc) for custom maps. models, sounds, etc. without any 
problems.

It's been a few weeks since the last time I played. I logged-in Yesterday to 
play, and the downloading of much of that custom stuff (in particular custom 
maps) seems broken - even though I have client-side settings set to allow all 
downloads from servers, etc.

Is this just ME? or happening for everyone? Is it documented somewhere as an 
intentional "feature" (perhaps to force use of maps from the "Workshop" 
instead?)?


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com [https://list.valvesoftware.com]/
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] Re: 1.38.5.2update - SteamRT v3 sniper - are youready?

[via csgo_servers list]

So steamrt/sniper/platform is a base image?

I need to build a Dockerfile and automate the download of SteamCMD and 
CS:GO DS.


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] 1.38.5.2 update - SteamRT v3 sniper - are you ready?

[via csgo_servers list]

Game update 1.38.5.2 introduced several Linux libraries compiled with GCC-5 or 
later. While we didn't expect any ABI incompatibilities, some community 
dedicated server systems needed to update their libstdc++ installation. 
Generally speaking, if your dedicated server is running on an older Linux OS, 
you should be able to recompile your libraries with a more recent version of 
GCC and add your library path to LD_PRELOAD. For example, libraries recompiled 
with GCC-9.3.0 worked well on CentOS7 for some community server operators.

Going forward, we are planning to update our Linux compiler toolchain for 
dedicated servers with more recent libraries. Future libraries update will bump 
the requirements up to glibc 2.31 (Ubuntu 20.04 / Debian 11), that's why we are 
reaching out to community server operators now and advising to upgrade 
production Linux OS installations ahead of time.

The best option for operating community dedicated servers will be to host a 
Docker container on your Linux OS, even though running servers in an 'as is' 
fashion on a suitably recent Linux distribution with recent libraries might 
also work.

A future update to our dedicated servers will be compiled against the sniper 
platform runtime, which we already publish here:
  https://gitlab.steamos.cloud/steamrt/sniper/platform/container_registry/95

Using the sniper image runtime on community dedicated servers has the advantage 
that we will build our dedicated servers exactly for this target, and as long 
as the host Linux OS can run this Docker container, server operators will not 
have to deal with any ABI compatibility issues.

We recommend that server operators should start preparing to run community 
dedicated servers using a suitable Linux OS & Docker solution. Server operators 
should be able to start using the sniper runtime image now, which is available 
here:
  https://gitlab.steamos.cloud/steamrt/sniper/platform/container_registry/95
... just run the current dedicated servers in it, and this will guarantee that 
your dedicated servers will be ready to run future updates when they are 
released.

GL HF!

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] AArch64 Architecture for CS:GO Server

[via csgo_servers list]

Hello,

I was wondering if Valve would be interested in releasing an AArch64 
architecture version for Steam, SteamCMD, the CS:GO client and the CS:GO 
server.


On the user side, MAC devices with Apple Silicon SoCs and Windows on ARM 
with Qualcomm SoCs are in active development. In particular, Apple has 
introduced the Metal 3 API in an attempt to improve the general image 
computing capabilities of MAC devices. While I'm disgusted by Apple's 
lack of Vulkan support, MoltenVK makes the situation a little less ugly.


In the cloud, Oracle Cloud, Alibaba Cloud and Huawei Cloud have all 
launched VPS with AArch64 architecture.


The AArch64 ecosystem is getting better and better, and I hope that 
Valve is paying attention to it as well.


Best regards,
wordlesswind
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

RE: [External Mail] Re: [Csgo_servers] Update broke Windows servers?

[via csgo_servers list]

I’ll forward the details to the CS:GO team.

-Eric


From: csgo_servers@list.valvesoftware.com  
On Behalf Of Naleksuh
Sent: Thursday, June 23, 2022 9:27 PM
To: csgo_servers 
Subject: [External Mail] Re: [Csgo_servers] Update broke Windows servers?

Hm, for me when I start with SourceMod I get the crash after a few seconds but 
when I rename "addons" folder to something else, it starts up as normal. Might 
not be a Valve issue, then. @erics Thoughts?



 On Thu, 23 Jun 2022 21:23:22 -0700 John 
mailto:lists.va...@nuclearfallout.net>> wrote 
---

Negative, this is on a fresh server without mods.

-John

On 6/23/2022 7:54 PM, Naleksuh wrote:



___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
It works fine as long as you aren't using SourceMod or similar. You would 
likely need to reach out to them.



 On Thu, 23 Jun 2022 19:29:05 -0700 John 
 wrote 
---

Windows servers seem to not be able to start following the update a few
hours ago. Linux servers do start. Is this a known issue that is being
worked on?

(The console pops up but there is an immediate crash.)

-John
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/



___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/



___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] After updating to 1.37.7.8, the server crashes after setting the priority to srcds_linux

[via csgo_servers list]

After debugging, if you start the csgo server, and then modify the 
priority through "chrt -ar -p 98 $pid", and enter exit after the 
modification, it will crash under the void CModelLoader::UnloadModel( 
model_t *pModel) function.


https://prnt.sc/xstfpi

But he will not generate coredump but will be killed directly by 
kill(SIGKILL).



On 1/29/2021 1:37 AM, Marco Padovan wrote:

Possibly related to libSDL2-2.0.so.0 when scheduler is not SCHED_OTHER?

I didn't test much but from a quick lock crash seems to happen when 
doing a changelevel


try with just the renice to confirm it's related to the scheduler in use

On Thu, 28 Jan 2021 at 13:40, YUAN RUI - number201724 at me.com 
<http://me.com> (via csgo_servers list) 
<mailto:csgo_servers@list.valvesoftware.com>> wrote:


After updating to 1.37.7.8, the server crashes after setting the
priority to srcds_linux <https://steamdb.info/patchnotes/6148716/>


#!/bin/bash
#

__
PROCESS_NAMES=(
  srcds_linux
);

for pid in $(for executable in ${PROCESS_NAMES[@]}; do pgrep
${executable} ;done) ;do
  chrt -r -p 98 $pid
  renice 1 -p $pid
done


The srcds_linux process will inexplicably prompt Killed

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/ <https://list.valvesoftware.com/>

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] After updating to 1.37.7.8, the server crashes after setting the priority to srcds_linux

[via csgo_servers list]

After updating to 1.37.7.8, the server crashes after setting the 
priority to srcds_linux 



#!/bin/bash
# 
__

PROCESS_NAMES=(
  srcds_linux
);

for pid in $(for executable in ${PROCESS_NAMES[@]}; do pgrep 
${executable} ;done) ;do

  chrt -r -p 98 $pid
  renice 1 -p $pid
done


The srcds_linux process will inexplicably prompt Killed

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] Public steam client released with server browser changes

[via csgo_servers list]

The steam client was updated with the changes to the server browser protocol 
that have been discussed.

More info here:
https://steamcommunity.com/discussions/forum/14/2974028351344359625/

The latest binaries for all gameserver platforms, with experimental features to 
harden against server browser packet attacks, can be obtained here:
http://media.steampowered.com/apps/steamworks/steam_bins_6246211.zip

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] Beta server binaries available for testing

[via csgo_servers list]

Hello!

Some beta steam binaries are available for testing.  They have several 
improvements meaningful to dedicated servers, mostly related to handling of 
server browser packets such as the A2S_INFO packet that has been discussed.

If you do not set any environment variables, the new binaries have the 
following change:


*Improved challenge generation.  (Challenges are generated using 
siphash, so there is no table to search or fill up.)

There are also some environment variables that can be set to active new 
features and behaviour:


*STEAM_GAMESERVER_A2S_INFO_REQUIRE_CHALLENGE=1.  This will opt into the 
new behavior we have been discussing for A2S_INFO packets.  It is primarily 
intended for testing 3rd party query clients.  It is *not* currently compatible 
with the main steam client, so it should not enabled be otherwise!  It is 
compatible with the current steam beta client.


*STEAM_GAMESERVER_RATE_LIMIT_200MS=N.  This will drop any 
connectionless packets (A2S_INFO, A2S_RULES, A2S_PLAYERS) from a given IP after 
more than N are received in a 200ms window.  By default, this rate limiting is 
disabled, but a reasonable value might be somewhere around 25-75 range.


*STEAM_GAMESERVER_PACKET_HANDLER_NO_IPC.  If this variable is set, then 
the Steamworks packet handling calls will use a "fast path".  The design of the 
Steamworks SDK did not have dedicated servers in mind, and most API calls are 
serialized over an IPC, and in fact execute in the steam client process.  A 
dedicated server does not communicate with a steam client (there usually isn't 
one running), but to keep the code simple, the same basic design is used - 
there are two threads, and all API calls are serialized and executed in the 
Steam thread.  This common architecture makes all access to the steam related 
data structures essentially single-threaded, vastly simplifying the code.  But 
it adds some overhead for calls, and for the packet handling in particular that 
overhead can be significant.  Turning on the environment variable will bypass 
this serialization and context switch, which makes these calls, much, much 
faster.  Note that this only affects a server in "shared socket mode" - meaning 
the game port and the query port are the same.

You can download the appropriate binaries here:
http://media.steampowered.com/apps/steamworks/steam_bins_6243860.zip

If you have an opportunity to try out these changes, please let me know if you 
are able to tell any differences, or run into any problems.  If this testing 
goes well and does not uncover any issues, we will probably change the defaults 
to enable the IPC bypass and enable some rate limiting at a conservative rate.

NOTE: CSGO servers sometimes process A2S_INFO in the engine, based on the 
values of host_info_show, host_players_show, and host_rules_show.  The 
corresponding packets will use go through these steamclient binaries, if 
host_info_show=2, host_players_show=2, or host_rules_show is true, respectively.
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

RE: [External Mail] [Csgo_servers] RE: Changes to A2S_INFO - take 2

[via csgo_servers list]

>Third-party server-list browsers/query tools?
Correct, and thanks for asking for this clarification.  All games that use the 
ISteamMatchmakingServers API from the Steamworks SDK (that’s basically all 
games) get that code from the steam client, so they are all updated when we 
update the client.  (Although there is a transition period as players update 
their client.  It does not happen instantly.)  This is why releasing a new 
steam client beta can break existing games, as happened this week.

>When we say "server-side plugins, what are we talking about?
That was an overly specific term on my part.  For purposes of this discussion, 
I just mean that any special processing or filtering that is being done to 
these packets, it doesn’t have to be a “plugin”.  All of that will continue to 
work, because the client will continue to behave exactly as it did before.

From: csgo_servers@list.valvesoftware.com  
On Behalf Of Mecha Weasel
Sent: Friday, December 4, 2020 12:38 PM
To: csgo_servers@list.valvesoftware.com
Subject: Re: [External Mail] [Csgo_servers] RE: Changes to A2S_INFO - take 2

Just for clarification:

When we say 3rd party "clients", what are we talking about?  Third-party 
server-list browsers/query tools? Certainly not things like the CS:GO game 
client or TF2 game client (etc.)?

When we say "server-side plugins", what are we talking about? SourceMod 
plug-ins? off the top of my head, I can not think of any SourceMod plug-in that 
does anything with the server list.  Maybe a plug-in that manages "tags"?

Thanks,

- W

On Fri, Dec 4, 2020 at 11:56 AM Fletcher Dunn - fletcherd at 
valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) 
mailto:csgo_servers@list.valvesoftware.com>>
 wrote:
>Switching from the padding method to the challenge method is just pushing the 
>burden
>of change to another set of people. You will break countless middleware that 
>depend on it like this:
>https://github.com/blastehh/SourceQueryCacheMono and requiring stateful 
>firewalls to block a2sinfo spam.

It should be clear to the readers of this mailing list who understood the new 
proposal that this has the situation exactly backwards.  The updated client 
that shipped yesterday behaves exactly as it always has, until the server 
changes its behavior.  The initial padding plan broke existing deployments 
because some deployments assume the client will have very specific behaviour.  
With the new plan, server-side plugins will continue to work until the server 
operator elects to opt into the new behaviour.  If you are a server operator 
and you want to keep using this, then by all means, keep using it!  Migration 
to the new protocol is totally up to you.

Also, the challenge protocol is really simple, and does not specify the 
contents of a challenge, so it should not be difficult to extend tools such as 
this to take advantage of the new protocol, if so desired.

If anyone has a burden of change forced on them, it is third party *clients*.  
Once the main client speaks the new protocol, some servers will want to take 
advantage of it.  Valve will likely update our own games to do this.  (At least 
by default.  We will retain a way for community server operators to opt out.)  
At this point, third party clients will need to be updated if they wish to 
communicate with those servers who have decided to use the new protocol.

If there are any opensource projects that seek assistance in making these 
changes, feel free to email me or contact me on github:
https://github.com/fletcherdvalve

-Original Message-
From: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> 
mailto:csgo_servers@list.valvesoftware.com>>
 On Behalf Of Tim Anderson
Sent: Thursday, December 3, 2020 9:56 PM
To: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>
Subject: [External Mail] [Csgo_servers] RE: Changes to A2S_INFO - take 2

So this is where you can actually talk to a Valve employee. It is sad to see 
such an important change only being talked about here.

I have to agree with Kyle Sanderson here. This is rather strange seeing 
precious Valve employee time being devoted to a small ddos vector when there 
are countless >20x methods that will never be fixed.

Switching from the padding method to the challenge method is just pushing the 
burden of change to another set of people. You will break countless middleware 
that depend on it like this:
https://github.com/blastehh/SourceQueryCacheMono and requiring stateful 
firewalls to block a2sinfo spam.

I think it would be a better solution to tell the game server providers to stop 
their strict filtering. They are used to frequent game updates anyway.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/

___

RE: [External Mail] [Csgo_servers] RE: Changes to A2S_INFO - take 2

[via csgo_servers list]

>Switching from the padding method to the challenge method is just pushing the 
>burden
>of change to another set of people. You will break countless middleware that 
>depend on it like this:
>https://github.com/blastehh/SourceQueryCacheMono and requiring stateful 
>firewalls to block a2sinfo spam.

It should be clear to the readers of this mailing list who understood the new 
proposal that this has the situation exactly backwards.  The updated client 
that shipped yesterday behaves exactly as it always has, until the server 
changes its behavior.  The initial padding plan broke existing deployments 
because some deployments assume the client will have very specific behaviour.  
With the new plan, server-side plugins will continue to work until the server 
operator elects to opt into the new behaviour.  If you are a server operator 
and you want to keep using this, then by all means, keep using it!  Migration 
to the new protocol is totally up to you.

Also, the challenge protocol is really simple, and does not specify the 
contents of a challenge, so it should not be difficult to extend tools such as 
this to take advantage of the new protocol, if so desired.

If anyone has a burden of change forced on them, it is third party *clients*.  
Once the main client speaks the new protocol, some servers will want to take 
advantage of it.  Valve will likely update our own games to do this.  (At least 
by default.  We will retain a way for community server operators to opt out.)  
At this point, third party clients will need to be updated if they wish to 
communicate with those servers who have decided to use the new protocol.

If there are any opensource projects that seek assistance in making these 
changes, feel free to email me or contact me on github:
https://github.com/fletcherdvalve

-Original Message-
From: csgo_servers@list.valvesoftware.com  
On Behalf Of Tim Anderson
Sent: Thursday, December 3, 2020 9:56 PM
To: csgo_servers@list.valvesoftware.com
Subject: [External Mail] [Csgo_servers] RE: Changes to A2S_INFO - take 2

So this is where you can actually talk to a Valve employee. It is sad to see 
such an important change only being talked about here.

I have to agree with Kyle Sanderson here. This is rather strange seeing 
precious Valve employee time being devoted to a small ddos vector when there 
are countless >20x methods that will never be fixed.

Switching from the padding method to the challenge method is just pushing the 
burden of change to another set of people. You will break countless middleware 
that depend on it like this:
https://github.com/blastehh/SourceQueryCacheMono and requiring stateful 
firewalls to block a2sinfo spam.

I think it would be a better solution to tell the game server providers to stop 
their strict filtering. They are used to frequent game updates anyway.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

RE: [External Mail] Re: [Csgo_servers] RE: Changes to A2S_INFO - take 2

[via csgo_servers list]

Yes, the A2S_INFO w/ challenge just appends the 4 byte challenge after “TSource 
Engine Query\0”.  PLUS in the future there may be other stuff!  Specifically, a 
future update to the protocol may append a server-assigned “revision number” of 
the game data (map name, server name, tags, etc) obtained from the master 
server.  The game server may then omit those details in its reply that have not 
changed since that revision.  This is totally optional.  The server can 
continue to provide all the details if it wishes.  (Or if some middle box is 
caching them.)  But if it wishes to send a smaller reply, it can do so.

Unfortunately, my testing revealed that at least one relatively large game 
hosting provider was blocking packets that had only 4 extra 0’s appended to the 
original A2S_INFO request.  So for that hosting provider, at least, there 
doesn’t appear to be any change that could be made to the original packet that 
would not get blocked.  And that is just the first example of very aggressive 
filtering brought to our attention, because it was a relatively large user of 
this service, from a partner with whom we happen to be in frequent 
communication.  There are presumably many other hosting providers and server 
operators that have already (quite reasonably) taken draconian steps such as 
this to protect their servers against abuse of this ancient and poorly-designed 
protocol from the early 2000’s.

This is why “Just tell the game hosting providers to change their filters” is 
not a serious alternative.  There are too many of them, and there is not a 
clear channel through which the communication could be made to reach all of 
them.  This forum is perhaps the best, and many did not get the first message.  
Even now, they are slow to respond when I was in direct communication when 
them.  So “Just make them change the filters” in practice means to go ahead and 
break games, and use player reports of the game being broken to get the 
attention of the operators.  Personally I find that approach unacceptable.  
This latest proposal is definitely not the ideal design one would make if one 
were starting from scratch with no existing users.  But it seems to be a good 
path forward to address the reflection attack vulnerability, given the current 
state of affairs and the constraints that are in place given how many users of 
this protocol there are.  This plan puts the control in the hands of the server 
operators.  If compatibility with third party clients is important to them, 
they can retain the current behavior indefinitely.  It’s up to them.  The 
official client will be ready to prove they are not spoofing soon, and they can 
request that proof when they decide they value protection against the 
reflection amplification over compatibility.

From: csgo_servers@list.valvesoftware.com  
On Behalf Of David Parker
Sent: Thursday, December 3, 2020 8:46 PM
To: csgo_servers@list.valvesoftware.com
Cc: hlds_annou...@list.valvesoftware.com
Subject: [External Mail] Re: [Csgo_servers] RE: Changes to A2S_INFO - take 2

Thanks for the updates.  I assume this means that the "TSource Engine Query\0" 
remains in place, and the challenge response (when provided) gets appended 
after the trailing null byte?

Also, this may be a silly question, but is there a smaller padded packet size 
that could be used, which doesn't trigger DDoS protections but is still big 
enough that it makes a reflection attack less appealing to the asshats who 
launch them?  Just curious.

Thanks,
Dave

On Thu, Dec 3, 2020 at 10:54 PM Fletcher Dunn - fletcherd at 
valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) 
mailto:csgo_servers@list.valvesoftware.com>>
 wrote:
A steam client beta has been released:

https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2896341257765264787

It understands how to respond if the server issues a challenge in response to 
an A2S_INFO request.  Importantly because of the existing filtering environment 
servers run in, the client will behave EXACTLY as it did before, until the 
server replies in the new method.  
(https://twitter.com/ZPostFacto/status/1334700095221104640)

The protocol is now as follows:


•Client will send the exact A2S_INFO packet that it has always sent, no 
more, no less.

•A new server will reply with a challenge, using the same S2C_CHALLENGE 
packet that’s used for the A2S_PLAYERS and A2S_RULES packets.  (Indeed, if a 
client is quick enough, it can use the same challenge for multiple requests.)

•Now, a client will send a A2S_INFO with the challenge appended.  Also: 
DO NOT ASSUME THAT ANY EXTRA BYTES AFTER THE CHALLENGE ARE INVALID.  This is 
reserved for future expansion to the protocol!  There are some more protocol 
changes in development right now designed to have the client obtain more 
information from the master server, thus reducing the amount of information 
that must come from the server.  Th

[Csgo_servers] RE: Changes to A2S_INFO - take 2

[via csgo_servers list]

A steam client beta has been released:

https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2896341257765264787

It understands how to respond if the server issues a challenge in response to 
an A2S_INFO request.  Importantly because of the existing filtering environment 
servers run in, the client will behave EXACTLY as it did before, until the 
server replies in the new method.  
(https://twitter.com/ZPostFacto/status/1334700095221104640)

The protocol is now as follows:


*Client will send the exact A2S_INFO packet that it has always sent, no 
more, no less.

*A new server will reply with a challenge, using the same S2C_CHALLENGE 
packet that's used for the A2S_PLAYERS and A2S_RULES packets.  (Indeed, if a 
client is quick enough, it can use the same challenge for multiple requests.)

*Now, a client will send a A2S_INFO with the challenge appended.  Also: 
DO NOT ASSUME THAT ANY EXTRA BYTES AFTER THE CHALLENGE ARE INVALID.  This is 
reserved for future expansion to the protocol!  There are some more protocol 
changes in development right now designed to have the client obtain more 
information from the master server, thus reducing the amount of information 
that must come from the server.  Those improvements won't be possible if 
assumptions are made about packet sizes!

I'll post again when there are server binaries available that can opt into the 
new behavior, fixing the reflection attack vulnerability.  You will not want to 
opt in until all clients you care about are speaking the new protocol.  For 
steam clients, that will probably at least a couple of weeks.

Please share this with any authors of third party clients that you know!


From: csgo_servers@list.valvesoftware.com 
Sent: Thursday, December 3, 2020 2:42 PM
To: 'hlds_annou...@list.valvesoftware.com' 
; csgo_servers@list.valvesoftware.com
Subject: [Csgo_servers] Changes to A2S_INFO - take 2

The previous change to pad the server browser query A2S_INFO packets has 
triggered some aggressive Anti-DDoS filters for some games.  This change was 
made to address a reflection amplification attack in the protocol.  So it looks 
like we will need to address the vulnerability by securing the response with a 
challenge, in the same way that the A2S_PLAYERS and A2S_RULES queries work.  
We'll be releasing a new client soon that sends the small A2S_INFO packets 
again, but also understands how to reply to a server that replies with a 
challenge instead of the data.  This protocol does make it more complicated to 
write a custom client for the protocol (although not drastically so), and means 
that the query traffic cannot be trivially filtered at the edge.  
Unfortunately, it looks like in the current environment, that is what we need 
to do.

Further bulletins as events warrant.

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] Changes to A2S_INFO - take 2

[via csgo_servers list]

The previous change to pad the server browser query A2S_INFO packets has 
triggered some aggressive Anti-DDoS filters for some games.  This change was 
made to address a reflection amplification attack in the protocol.  So it looks 
like we will need to address the vulnerability by securing the response with a 
challenge, in the same way that the A2S_PLAYERS and A2S_RULES queries work.  
We'll be releasing a new client soon that sends the small A2S_INFO packets 
again, but also understands how to reply to a server that replies with a 
challenge instead of the data.  This protocol does make it more complicated to 
write a custom client for the protocol (although not drastically so), and means 
that the query traffic cannot be trivially filtered at the edge.  
Unfortunately, it looks like in the current environment, that is what we need 
to do.

Further bulletins as events warrant.
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

RE: Re[2]: [External Mail] Re: [Csgo_servers] Steam Client beta released with changes to the A2S_INFO protocol

[via csgo_servers list]

Ah, thanks, I’ll double-check that.

From: csgo_servers@list.valvesoftware.com  
On Behalf Of Nicholas Hastings
Sent: Tuesday, December 1, 2020 9:22 AM
To: csgo_servers@list.valvesoftware.com
Subject: Re[2]: [External Mail] Re: [Csgo_servers] Steam Client beta released 
with changes to the A2S_INFO protocol

I don't know offhand if it factors in, but the CS:GO engine also uses custom 
responses for A2S_PLAYERS and A2S_INFO by default, rather than deferring to 
steamclient.

-- Original Message --
From: "Fletcher Dunn - fletcherd at valvesoftware.com (via csgo_servers list)" 
mailto:csgo_servers@list.valvesoftware.com>>
To: 
"csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>"
 
mailto:csgo_servers@list.valvesoftware.com>>
Sent: 12/1/2020 12:06:07 PM
Subject: RE: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Previously, an A2S_PLAYER packet with a challenge of zero (or any incorrect 
challenge for that matter) was interpreted as a challenge request, and the 
server would reply with a challenge number for the client to use.  The new 
behavior will be that if the packet is padded to be at least 1200 bytes, the 
server should just go ahead and reply with the info, even if the field where 
the challenge normally goes is zero.

The CSGO server has not yet been updated to use the new binaries, however!  Let 
me work with the CSGO guys to get that updated.

I was about to suggest that you obtain the latest binaries to use for testing 
by opting into the beta client on linux.  However, those are compiled to target 
a newer distro, and we compile special “server” binaries that target older 
distro.  If you have a server running on a relatively recent distro, I believe 
it should work to mix those binaries, but I cannot say for sure – I have not 
ever actually tested this.

From: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> 
mailto:csgo_servers@list.valvesoftware.com>>
 On Behalf Of David Parker
Sent: Monday, November 30, 2020 1:45 PM
To: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>
Subject: Re: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Thanks, Fletcher.  But doesn't A2S_PLAYER require the challenge response to be 
included in the query?

In my testing I have found that SRCDS will accept a challenge request which is 
padded to 1200 bytes and return a challenge response.  And then I can send an 
A2S_PLAYER query with that challenge response and pad it to 1200 bytes, and 
then get the player info back.  I just wanted to see if this is the correct way 
moving forward, or if the need for a challenge was removed.  And if so, what it 
has been replaced with.

Can I just send a header and 0x55 with nothing after it, if it's padded to 
>=1200 bytes?

Thanks!

On Mon, Nov 30, 2020 at 3:41 PM Fletcher Dunn - fletcherd at 
valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) 
mailto:csgo_servers@list.valvesoftware.com>>
 wrote:
The new gameserver code will drop all A2S_PLAYER packets < 1200 bytes, if the 
environment variable is set.  No challenge is necessary for packets >= 1200, 
but if the environment variable is set to allow <1200 packets, then the 
challenge will be required for such packets.

The new client code will always send 1200 byte packets.  It will also know how 
to do the challenge handshake, for compatibility with old servers.

From: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> 
mailto:csgo_servers@list.valvesoftware.com>>
 On Behalf Of David Parker
Sent: Monday, November 23, 2020 10:39 AM
To: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>
Subject: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Hi Fletcher,

I was just hoping you could clarify something for me.  For A2S_PLAYER, is the 
challenge still required once the 1200 byte minimum is implemented?  And if so, 
does the challenge query need to be >1200 bytes, or just the subsequent 
A2S_PLAYER query which includes the challenge response?

Thanks!
Dave

On Wed, Nov 18, 2020 at 7:53 PM Fletcher Dunn - fletcherd at 
valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) 
mailto:csgo_servers@list.valvesoftware.com>>
 wrote:
A Steam client beta has just been released, with the following change notes 
relevant to the A2S_INFO discussion:

Server Browser

•   Server browser packets (A2S_INFO, A2S_PLAYER, A2S_RULES) sent by 
clients will now be at least 1200 bytes. (For more details, see 
https://steamcommunity.com/discussions/forum/14/2989789048633291344/) Third 
party tools that send these packets are especially encouraged to read this 
thread.)

•   Improved gameserv

RE: [External Mail] Re: [Csgo_servers] Steam Client beta released with changes to the A2S_INFO protocol

[via csgo_servers list]

>then does that mean that the whole challenge request/response model is 
>effectively moot?

For new servers, yes, after they are updated with new code (and do not 
intentionally relax the 1200 requirement using the environment variable).  
However, clients will still need to understand the challenge handshake, if they 
wish to talk to any older servers that do not update and still require the 
challenge.

From: csgo_servers@list.valvesoftware.com  
On Behalf Of David Parker
Sent: Tuesday, December 1, 2020 10:25 AM
To: csgo_servers@list.valvesoftware.com
Subject: Re: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Thanks for clarifying that, Fletch.  That answers my question.  In my test 
queries I am padding the packets with zeros, but I was querying against current 
production versions of TF2 and CS:GO, not the new testing binaries.  So that 
explains why I still needed a challenge response to get anything from 
A2S_PLAYER, regardless of the packet size.

So if this change is going to require that all A2S_INFO, A2S_RULES, and 
A2S_PLAYER queries are >=1200 bytes, and any such request which is >=1200 bytes 
gets an immediate response with no challenge required, then does that mean that 
the whole challenge request/response model is effectively moot?  Because if I'm 
understanding this correctly, the server won't answer a challenge request which 
is <1200 bytes, and will respond to a proper one with the requested information.

I'm mostly just trying to determine which steps can be disabled or removed 
completely in my query app, once these engine changes are live.

Thanks!

On Tue, Dec 1, 2020 at 12:09 PM Fletcher Dunn - fletcherd at 
valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) 
mailto:csgo_servers@list.valvesoftware.com>>
 wrote:
But to answer this question:

>Can I just send a header and 0x55 with nothing after it, if it's padded to 
>>=1200 bytes?

Yes (after the first four 0xff bytes).

Also, is it required that you always pad with *zeros*.  (Just in case we need 
to extend the protocol in the future.)


From: Fletcher Dunn
Sent: Tuesday, December 1, 2020 9:06 AM
To: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>
Subject: RE: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Previously, an A2S_PLAYER packet with a challenge of zero (or any incorrect 
challenge for that matter) was interpreted as a challenge request, and the 
server would reply with a challenge number for the client to use.  The new 
behavior will be that if the packet is padded to be at least 1200 bytes, the 
server should just go ahead and reply with the info, even if the field where 
the challenge normally goes is zero.

The CSGO server has not yet been updated to use the new binaries, however!  Let 
me work with the CSGO guys to get that updated.

I was about to suggest that you obtain the latest binaries to use for testing 
by opting into the beta client on linux.  However, those are compiled to target 
a newer distro, and we compile special “server” binaries that target older 
distro.  If you have a server running on a relatively recent distro, I believe 
it should work to mix those binaries, but I cannot say for sure – I have not 
ever actually tested this.


From: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> 
mailto:csgo_servers@list.valvesoftware.com>>
 On Behalf Of David Parker
Sent: Monday, November 30, 2020 1:45 PM
To: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>
Subject: Re: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Thanks, Fletcher.  But doesn't A2S_PLAYER require the challenge response to be 
included in the query?

In my testing I have found that SRCDS will accept a challenge request which is 
padded to 1200 bytes and return a challenge response.  And then I can send an 
A2S_PLAYER query with that challenge response and pad it to 1200 bytes, and 
then get the player info back.  I just wanted to see if this is the correct way 
moving forward, or if the need for a challenge was removed.  And if so, what it 
has been replaced with.

Can I just send a header and 0x55 with nothing after it, if it's padded to 
>=1200 bytes?

Thanks!

On Mon, Nov 30, 2020 at 3:41 PM Fletcher Dunn - fletcherd at 
valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) 
mailto:csgo_servers@list.valvesoftware.com>>
 wrote:
The new gameserver code will drop all A2S_PLAYER packets < 1200 bytes, if the 
environment variable is set.  No challenge is necessary for packets >= 1200, 
but if the environment variable is set to allow <1200 packets, then the 
challenge will be required for such packets.

The new client code will always send 1200 byte packets.  It will als

RE: [External Mail] Re: [Csgo_servers] Steam Client beta released with changes to the A2S_INFO protocol

[via csgo_servers list]

But to answer this question:

>Can I just send a header and 0x55 with nothing after it, if it's padded to 
>>=1200 bytes?

Yes (after the first four 0xff bytes).

Also, is it required that you always pad with *zeros*.  (Just in case we need 
to extend the protocol in the future.)


From: Fletcher Dunn
Sent: Tuesday, December 1, 2020 9:06 AM
To: csgo_servers@list.valvesoftware.com
Subject: RE: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Previously, an A2S_PLAYER packet with a challenge of zero (or any incorrect 
challenge for that matter) was interpreted as a challenge request, and the 
server would reply with a challenge number for the client to use.  The new 
behavior will be that if the packet is padded to be at least 1200 bytes, the 
server should just go ahead and reply with the info, even if the field where 
the challenge normally goes is zero.

The CSGO server has not yet been updated to use the new binaries, however!  Let 
me work with the CSGO guys to get that updated.

I was about to suggest that you obtain the latest binaries to use for testing 
by opting into the beta client on linux.  However, those are compiled to target 
a newer distro, and we compile special “server” binaries that target older 
distro.  If you have a server running on a relatively recent distro, I believe 
it should work to mix those binaries, but I cannot say for sure – I have not 
ever actually tested this.


From: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> 
mailto:csgo_servers@list.valvesoftware.com>>
 On Behalf Of David Parker
Sent: Monday, November 30, 2020 1:45 PM
To: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>
Subject: Re: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Thanks, Fletcher.  But doesn't A2S_PLAYER require the challenge response to be 
included in the query?

In my testing I have found that SRCDS will accept a challenge request which is 
padded to 1200 bytes and return a challenge response.  And then I can send an 
A2S_PLAYER query with that challenge response and pad it to 1200 bytes, and 
then get the player info back.  I just wanted to see if this is the correct way 
moving forward, or if the need for a challenge was removed.  And if so, what it 
has been replaced with.

Can I just send a header and 0x55 with nothing after it, if it's padded to 
>=1200 bytes?

Thanks!

On Mon, Nov 30, 2020 at 3:41 PM Fletcher Dunn - fletcherd at 
valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) 
mailto:csgo_servers@list.valvesoftware.com>>
 wrote:
The new gameserver code will drop all A2S_PLAYER packets < 1200 bytes, if the 
environment variable is set.  No challenge is necessary for packets >= 1200, 
but if the environment variable is set to allow <1200 packets, then the 
challenge will be required for such packets.

The new client code will always send 1200 byte packets.  It will also know how 
to do the challenge handshake, for compatibility with old servers.

From: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> 
mailto:csgo_servers@list.valvesoftware.com>>
 On Behalf Of David Parker
Sent: Monday, November 23, 2020 10:39 AM
To: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>
Subject: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Hi Fletcher,

I was just hoping you could clarify something for me.  For A2S_PLAYER, is the 
challenge still required once the 1200 byte minimum is implemented?  And if so, 
does the challenge query need to be >1200 bytes, or just the subsequent 
A2S_PLAYER query which includes the challenge response?

Thanks!
Dave

On Wed, Nov 18, 2020 at 7:53 PM Fletcher Dunn - fletcherd at 
valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) 
mailto:csgo_servers@list.valvesoftware.com>>
 wrote:
A Steam client beta has just been released, with the following change notes 
relevant to the A2S_INFO discussion:

Server Browser

•   Server browser packets (A2S_INFO, A2S_PLAYER, A2S_RULES) sent by 
clients will now be at least 1200 bytes. (For more details, see 
https://steamcommunity.com/discussions/forum/14/2989789048633291344/) Third 
party tools that send these packets are especially encouraged to read this 
thread.)

•   Improved gameserver challenge generation to harden against certain DoS 
attacks

https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2896339990496271925

Also, if you use the steamclient.dll/.so with that beta, you can activate the 
new, stricter message handling on the gameserver by setting the environment 
variable STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200

This is just the beta steam client, not the full public release.  Only a

RE: [External Mail] Re: [Csgo_servers] Steam Client beta released with changes to the A2S_INFO protocol

[via csgo_servers list]

Previously, an A2S_PLAYER packet with a challenge of zero (or any incorrect 
challenge for that matter) was interpreted as a challenge request, and the 
server would reply with a challenge number for the client to use.  The new 
behavior will be that if the packet is padded to be at least 1200 bytes, the 
server should just go ahead and reply with the info, even if the field where 
the challenge normally goes is zero.

The CSGO server has not yet been updated to use the new binaries, however!  Let 
me work with the CSGO guys to get that updated.

I was about to suggest that you obtain the latest binaries to use for testing 
by opting into the beta client on linux.  However, those are compiled to target 
a newer distro, and we compile special “server” binaries that target older 
distro.  If you have a server running on a relatively recent distro, I believe 
it should work to mix those binaries, but I cannot say for sure – I have not 
ever actually tested this.

From: csgo_servers@list.valvesoftware.com  
On Behalf Of David Parker
Sent: Monday, November 30, 2020 1:45 PM
To: csgo_servers@list.valvesoftware.com
Subject: Re: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Thanks, Fletcher.  But doesn't A2S_PLAYER require the challenge response to be 
included in the query?

In my testing I have found that SRCDS will accept a challenge request which is 
padded to 1200 bytes and return a challenge response.  And then I can send an 
A2S_PLAYER query with that challenge response and pad it to 1200 bytes, and 
then get the player info back.  I just wanted to see if this is the correct way 
moving forward, or if the need for a challenge was removed.  And if so, what it 
has been replaced with.

Can I just send a header and 0x55 with nothing after it, if it's padded to 
>=1200 bytes?

Thanks!

On Mon, Nov 30, 2020 at 3:41 PM Fletcher Dunn - fletcherd at 
valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) 
mailto:csgo_servers@list.valvesoftware.com>>
 wrote:
The new gameserver code will drop all A2S_PLAYER packets < 1200 bytes, if the 
environment variable is set.  No challenge is necessary for packets >= 1200, 
but if the environment variable is set to allow <1200 packets, then the 
challenge will be required for such packets.

The new client code will always send 1200 byte packets.  It will also know how 
to do the challenge handshake, for compatibility with old servers.

From: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> 
mailto:csgo_servers@list.valvesoftware.com>>
 On Behalf Of David Parker
Sent: Monday, November 23, 2020 10:39 AM
To: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>
Subject: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Hi Fletcher,

I was just hoping you could clarify something for me.  For A2S_PLAYER, is the 
challenge still required once the 1200 byte minimum is implemented?  And if so, 
does the challenge query need to be >1200 bytes, or just the subsequent 
A2S_PLAYER query which includes the challenge response?

Thanks!
Dave

On Wed, Nov 18, 2020 at 7:53 PM Fletcher Dunn - fletcherd at 
valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) 
mailto:csgo_servers@list.valvesoftware.com>>
 wrote:
A Steam client beta has just been released, with the following change notes 
relevant to the A2S_INFO discussion:

Server Browser

•   Server browser packets (A2S_INFO, A2S_PLAYER, A2S_RULES) sent by 
clients will now be at least 1200 bytes. (For more details, see 
https://steamcommunity.com/discussions/forum/14/2989789048633291344/) Third 
party tools that send these packets are especially encouraged to read this 
thread.)

•   Improved gameserver challenge generation to harden against certain DoS 
attacks

https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2896339990496271925

Also, if you use the steamclient.dll/.so with that beta, you can activate the 
new, stricter message handling on the gameserver by setting the environment 
variable STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200

This is just the beta steam client, not the full public release.  Only a set of 
users will be using this client, and we are not quite to deployment step #1 
described below.



From: Fletcher Dunn
Sent: Monday, November 16, 2020 4:47 PM
To: 
'hlds_annou...@list.valvesoftware.com<mailto:hlds_annou...@list.valvesoftware.com>'
 
mailto:hlds_annou...@list.valvesoftware.com>>
Subject: RFC: Changes to the A2S_INFO protocol

Hello!

Over the next couple of months we will be releasing some changes to how servers 
and clients using steamclent.so/dll<http://steamclent.so/dll> handle the 
venerable Source engine A2S_INFO message used by the server browser.  This 
includes the Steam client server browser, al

RE: [External Mail] Re: [Csgo_servers] Steam Client beta released with changes to the A2S_INFO protocol

[via csgo_servers list]

The new gameserver code will drop all A2S_PLAYER packets < 1200 bytes, if the 
environment variable is set.  No challenge is necessary for packets >= 1200, 
but if the environment variable is set to allow <1200 packets, then the 
challenge will be required for such packets.

The new client code will always send 1200 byte packets.  It will also know how 
to do the challenge handshake, for compatibility with old servers.

From: csgo_servers@list.valvesoftware.com  
On Behalf Of David Parker
Sent: Monday, November 23, 2020 10:39 AM
To: csgo_servers@list.valvesoftware.com
Subject: [External Mail] Re: [Csgo_servers] Steam Client beta released with 
changes to the A2S_INFO protocol

Hi Fletcher,

I was just hoping you could clarify something for me.  For A2S_PLAYER, is the 
challenge still required once the 1200 byte minimum is implemented?  And if so, 
does the challenge query need to be >1200 bytes, or just the subsequent 
A2S_PLAYER query which includes the challenge response?

Thanks!
Dave

On Wed, Nov 18, 2020 at 7:53 PM Fletcher Dunn - fletcherd at 
valvesoftware.com<http://valvesoftware.com> (via csgo_servers list) 
mailto:csgo_servers@list.valvesoftware.com>>
 wrote:
A Steam client beta has just been released, with the following change notes 
relevant to the A2S_INFO discussion:

Server Browser

•   Server browser packets (A2S_INFO, A2S_PLAYER, A2S_RULES) sent by 
clients will now be at least 1200 bytes. (For more details, see 
https://steamcommunity.com/discussions/forum/14/2989789048633291344/) Third 
party tools that send these packets are especially encouraged to read this 
thread.)

•   Improved gameserver challenge generation to harden against certain DoS 
attacks

https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2896339990496271925

Also, if you use the steamclient.dll/.so with that beta, you can activate the 
new, stricter message handling on the gameserver by setting the environment 
variable STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200

This is just the beta steam client, not the full public release.  Only a set of 
users will be using this client, and we are not quite to deployment step #1 
described below.



From: Fletcher Dunn
Sent: Monday, November 16, 2020 4:47 PM
To: 
'hlds_annou...@list.valvesoftware.com<mailto:hlds_annou...@list.valvesoftware.com>'
 
mailto:hlds_annou...@list.valvesoftware.com>>
Subject: RFC: Changes to the A2S_INFO protocol

Hello!

Over the next couple of months we will be releasing some changes to how servers 
and clients using steamclent.so/dll<http://steamclent.so/dll> handle the 
venerable Source engine A2S_INFO message used by the server browser.  This 
includes the Steam client server browser, all Source engine games, and all 
Steam games using the ISteamMatchmaking API.  The purpose of these changes is a 
long overdue fix for a reflection attack vulnerability.

This email is to let you know what those plans are and to solicit your 
feedback.  Fixing the vulnerability requires changing the protocol and will 
necessarily break existing third party utilities that speak the protocol.

Currently, the A2S_INFO packet looks like this:
4 bytes: 0x
1 byte: 0x54  (A2S_INFO packet type identifier)
20 bytes: "Source Engine Query\0"

The proposal is for clients to modify the A2S_INFO  packet they send in one of 
two ways:

Option 1: Pad the message with zeros, so that the request is larger than the 
reply.  The passes size is TBD, but it will probably be at least 800 bytes, and 
perhaps as high as 1200.  Feedback is requested concerning this size.

Option 2: Append a 4-byte anti-spoofing challenge obtained using the existing 
A2S_PLAYER or A2S_RULES messages.

Note that both options produce a packet that is acceptable to the current code 
in steamclient.so/dll<http://steamclient.so/dll>.  However, any custom handlers 
might have stricter behavior, and will need to be updated to be aware than 
“extra” data might appear after the end of the magic string in packets from 
legitimate clients.

Once all clients are using one of these two options, a server wishing to avoid 
being vulnerable to reflection attacks could drop any A2S_INFO packets below a 
minimum size without a challenge.

The changes would be deployed as follows:


1.) First, we will release a new Steam client that sends A2S_INFO messages 
padding to a minimum size.  (Option #1 above.)  Since it takes time for Steam 
client updates to roll out to all Steam users, and for third parties to change 
their code to make queries in the new format, we will not change the server to 
require the new format by default.  However, the server code will be updated to 
look for an environment variable that can be used to opt into the new, stricter 
behavior.  This is so that third parties can test their clients to make sure 
they are compliant with the new server code.

2.) As more clients upgrade to the new code and

[Csgo_servers] Steam Client beta released with changes to the A2S_INFO protocol

[via csgo_servers list]

A Steam client beta has just been released, with the following change notes 
relevant to the A2S_INFO discussion:

Server Browser

*   Server browser packets (A2S_INFO, A2S_PLAYER, A2S_RULES) sent by 
clients will now be at least 1200 bytes. (For more details, see 
https://steamcommunity.com/discussions/forum/14/2989789048633291344/) Third 
party tools that send these packets are especially encouraged to read this 
thread.)

*   Improved gameserver challenge generation to harden against certain DoS 
attacks

https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2896339990496271925

Also, if you use the steamclient.dll/.so with that beta, you can activate the 
new, stricter message handling on the gameserver by setting the environment 
variable STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200

This is just the beta steam client, not the full public release.  Only a set of 
users will be using this client, and we are not quite to deployment step #1 
described below.



From: Fletcher Dunn
Sent: Monday, November 16, 2020 4:47 PM
To: 'hlds_annou...@list.valvesoftware.com' 

Subject: RFC: Changes to the A2S_INFO protocol

Hello!

Over the next couple of months we will be releasing some changes to how servers 
and clients using steamclent.so/dll handle the venerable Source engine A2S_INFO 
message used by the server browser.  This includes the Steam client server 
browser, all Source engine games, and all Steam games using the 
ISteamMatchmaking API.  The purpose of these changes is a long overdue fix for 
a reflection attack vulnerability.

This email is to let you know what those plans are and to solicit your 
feedback.  Fixing the vulnerability requires changing the protocol and will 
necessarily break existing third party utilities that speak the protocol.

Currently, the A2S_INFO packet looks like this:
4 bytes: 0x
1 byte: 0x54  (A2S_INFO packet type identifier)
20 bytes: "Source Engine Query\0"

The proposal is for clients to modify the A2S_INFO  packet they send in one of 
two ways:

Option 1: Pad the message with zeros, so that the request is larger than the 
reply.  The passes size is TBD, but it will probably be at least 800 bytes, and 
perhaps as high as 1200.  Feedback is requested concerning this size.

Option 2: Append a 4-byte anti-spoofing challenge obtained using the existing 
A2S_PLAYER or A2S_RULES messages.

Note that both options produce a packet that is acceptable to the current code 
in steamclient.so/dll.  However, any custom handlers might have stricter 
behavior, and will need to be updated to be aware than "extra" data might 
appear after the end of the magic string in packets from legitimate clients.

Once all clients are using one of these two options, a server wishing to avoid 
being vulnerable to reflection attacks could drop any A2S_INFO packets below a 
minimum size without a challenge.

The changes would be deployed as follows:


1.) First, we will release a new Steam client that sends A2S_INFO messages 
padding to a minimum size.  (Option #1 above.)  Since it takes time for Steam 
client updates to roll out to all Steam users, and for third parties to change 
their code to make queries in the new format, we will not change the server to 
require the new format by default.  However, the server code will be updated to 
look for an environment variable that can be used to opt into the new, stricter 
behavior.  This is so that third parties can test their clients to make sure 
they are compliant with the new server code.

2.) As more clients upgrade to the new code and third party tools are 
updated to send queries in the new format, server operators may elect to opt 
into the new behavior at their discretion using the environment variable.

3.) After some time has passed (and we have posted several warnings on this 
mailing list), we will ship a new steamclient.so/.dll that has the strict 
behavior enabled by default.  A different environment variable can be used to 
use the older, more permissive behaviour.

If you have any concerns or feedback about this change, please post it to 
hlds_annou...@list.valvesoftware.com.
  After feedback has been collected and details finalized, I'll post again with 
more technical details about the changes that are going to be made.

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

RE: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

>It depends now on what you're doing with SDR ;-).

Yes, there are mechanisms to measure the latency to servers in known data 
centers, as well as to arbitrary hosts on the Internet using SDR P2P 
functionality.  I was referring to the ordinary servers.

-Original Message-
From: Kyle Sanderson  
Sent: Tuesday, November 17, 2020 1:15 PM
To: Fletcher Dunn 
Cc: csgo_servers@list.valvesoftware.com
Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

> I think some ping will always be necessary to measure the latency and 
> confirm UDP connectivity

It depends now on what you're doing with SDR ;-).

If you're planning on opening this up for optimized PoPs you already have the 
latency from the client, and the latency from the PoP to the server so you can 
return the sum there. One of the no-steam guys did this in like 2003 with his 
browser but he didn't control the PoPs. The latency was still off because he 
did addition of the requesting client
+ his master latency to the server then divided by two - with SDR you
control the network (and the paths).

> that the server is running

Tweaking steamclient to be more happy with sharing alive updates (30s
heartbeats) with the GMS would probably do the trick for stale information. 
It's not like it needs to be super up to date (although it could impact the 
"wait for a server slot" feature).

Just a thought, anyway.

Kyle.

On Tue, Nov 17, 2020 at 12:23 PM Fletcher Dunn  
wrote:
>
> The GMS does indeed have all of this information.
>
> Let me investigate moving more data to be in the GMS reply, instead of being 
> returned in A2S_INFO.
>
> I think some ping will always be necessary to measure the latency and confirm 
> UDP connectivity and that the server is running.  But there are probably some 
> simple changes that can be made to reduce the size of these replies 
> significantly and move them to the GMS.
>
> -Original Message-
> From: Kyle Sanderson 
> Sent: Tuesday, November 17, 2020 11:38 AM
> To: csgo_servers@list.valvesoftware.com
> Cc: Fletcher Dunn 
> Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol
>
> >  However, I am currently working on integrating SDR functionality 
> > with the server browser, and so while I am touching this code, it seemed 
> > like the right time to address this longstanding issue.
>
> Ahha! If we're already in there making other changes - I'd like to propose 
> something else then.
>
> 1. Lets promote the GMS (if this still exists) to have all server information 
> (players, rules, etc).
> 2. Have steamclient default to leaving old queries enabled, but the games 
> themselves with a convar to disable old queries by default.
> 3. This way technically the client doesn't have to ping the server (I mean - 
> it should still A2A_PING at some point), and tiny GSPs won't have to deal 
> with conntrack as much.
>
> I think this is what was done with the old master > GMS flip(?) - same idea 
> here. There can be a huge win because the GMS can immediately return all 
> these results to the client (or pages - whatever), without destroying the 
> conntrack table on bad home appliances. Simple stream, challenge, response 
> with the full rendered list. "Steam Desktop Client" can still do the full 
> query in the favourites list, but do a GMS query first for results and if 
> it's missing try hitting it directly.
>
> WDYT?
>
> Kyle.
>
> On Tue, Nov 17, 2020 at 10:00 AM Fletcher Dunn - fletcherd at 
> valvesoftware.com (via csgo_servers list) 
>  wrote:
> >
> > John!  Good to hear from all old folks from years ago!
> >
> >
> >
> > TL/DR: New proposal: the server requires all 3 connectionless packets from 
> > clients to be at least 1200 bytes.
> >
> >
> >
> > I’ve gotten similar feedback from a few people now.  The only reason to 
> > consider allowing a smaller packet with a challenge is to give the client a 
> > way to reduce the bandwidth sent when pinging a ton of servers.  But doing 
> > this would impair the ability to filter out these packets further out, and 
> > it is also more complicated to implement.  (I wasn’t planning on changing 
> > the server browser in steamclient.dll to do it, I was just going to do the 
> > simple thing of padding the packet.)  Given that it is 2020 The Year of Our 
> > Lord Gaben, probably the extra bandwidth needed to ping a bunch of servers 
> > is just not significant.
> >
> >
> >
> > Regarding 1200: although this technically maybe not OK according to RFCs 
> > from the mid 90’s, being larger than the absurdly small minimum IPv4 MTU, I 
> > believe it is OK in practice in 2020 TYOOLG, especially since the minimum 
> &g

RE: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

The GMS does indeed have all of this information.

Let me investigate moving more data to be in the GMS reply, instead of being 
returned in A2S_INFO.

I think some ping will always be necessary to measure the latency and confirm 
UDP connectivity and that the server is running.  But there are probably some 
simple changes that can be made to reduce the size of these replies 
significantly and move them to the GMS.

-Original Message-
From: Kyle Sanderson  
Sent: Tuesday, November 17, 2020 11:38 AM
To: csgo_servers@list.valvesoftware.com
Cc: Fletcher Dunn 
Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

>  However, I am currently working on integrating SDR functionality with 
> the server browser, and so while I am touching this code, it seemed like the 
> right time to address this longstanding issue.

Ahha! If we're already in there making other changes - I'd like to propose 
something else then.

1. Lets promote the GMS (if this still exists) to have all server information 
(players, rules, etc).
2. Have steamclient default to leaving old queries enabled, but the games 
themselves with a convar to disable old queries by default.
3. This way technically the client doesn't have to ping the server (I mean - it 
should still A2A_PING at some point), and tiny GSPs won't have to deal with 
conntrack as much.

I think this is what was done with the old master > GMS flip(?) - same idea 
here. There can be a huge win because the GMS can immediately return all these 
results to the client (or pages - whatever), without destroying the conntrack 
table on bad home appliances. Simple stream, challenge, response with the full 
rendered list. "Steam Desktop Client" can still do the full query in the 
favourites list, but do a GMS query first for results and if it's missing try 
hitting it directly.

WDYT?

Kyle.

On Tue, Nov 17, 2020 at 10:00 AM Fletcher Dunn - fletcherd at valvesoftware.com 
(via csgo_servers list)  wrote:
>
> John!  Good to hear from all old folks from years ago!
>
>
>
> TL/DR: New proposal: the server requires all 3 connectionless packets from 
> clients to be at least 1200 bytes.
>
>
>
> I’ve gotten similar feedback from a few people now.  The only reason to 
> consider allowing a smaller packet with a challenge is to give the client a 
> way to reduce the bandwidth sent when pinging a ton of servers.  But doing 
> this would impair the ability to filter out these packets further out, and it 
> is also more complicated to implement.  (I wasn’t planning on changing the 
> server browser in steamclient.dll to do it, I was just going to do the simple 
> thing of padding the packet.)  Given that it is 2020 The Year of Our Lord 
> Gaben, probably the extra bandwidth needed to ping a bunch of servers is just 
> not significant.
>
>
>
> Regarding 1200: although this technically maybe not OK according to RFCs from 
> the mid 90’s, being larger than the absurdly small minimum IPv4 MTU, I 
> believe it is OK in practice in 2020 TYOOLG, especially since the minimum MTU 
> for IPv6 is 1280.  In the SDR protocol used by CSGO and Dota, clients always 
> initiate their communication with a 1200 byte packet, and that has not caused 
> any problems.
>
>
>
> To Kyle Sanderson’s point: I realize that this is not the most pressing issue 
> facing the Internet today.  However, I am currently working on integrating 
> SDR functionality with the server browser, and so while I am touching this 
> code, it seemed like the right time to address this longstanding issue.  
> However, Valve is very sensitive to breaking old games.  It’s my 
> understanding that this plan allows old games to continue to operate, even if 
> the code cannot be updated.  If I’m mistaken, let me know.
>
>
>
> From: John 
> Sent: Tuesday, November 17, 2020 9:38 AM
> To: csgo_servers@list.valvesoftware.com
> Cc: Fletcher Dunn 
> Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol
>
>
>
> Fletcher,
>
> This sounds like a reasonable idea.
>
> Of the two, requiring a large request (#1) might be best. Both #1 and #2 help 
> with reflection attacks, but #1 also helps to mitigate directly spoofed query 
> attacks on game servers. There is less overhead involved on the server side 
> with rejecting an improperly sized packet than in generating a randomized 
> challenge response and having to locally store that state; and, should the 
> spoofer generate properly-sized packets, they would be limited to a lower 
> overall packet rate (which also drastically reduces overhead on the server 
> side). Further, an external firewall could easily drop improperly-formatted 
> packets based on size, cutting out many attacks.
>
> (By the same token, connection and all other unsolicited packets 
> should prob

RE: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

One more clarification: this proposal is only to change A2S_INFO, A2S_PLAYER, 
and A2S_INFO.  There are other connectionless packets in Source engine 
protocols.  We could update our own games to require that those be padded as 
well (and check the same environment variables).  But it's totally separate 
code.  (Not to mention other games!)  So, any filtering will need to be smarter 
than just checking if the first 32-bits are .

While I'm touching this code, I'm also hardening the challenge generation.

From: csgo_servers@list.valvesoftware.com 
Sent: Tuesday, November 17, 2020 10:29 AM
To: csgo_servers@list.valvesoftware.com
Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

As John said, padding with zeros will be easier to mitigate (and less resource 
intensive) for providers, and it solves the reflection.

Any word on the last bit of John's response regarding "abuse" of BGP/Anycasting 
to reply to source engine queries from the closest geographical location to the 
requester?

It's one thing for hosts to use edge locations to mitigate attacks, allowing 
inbound filtering to be spread across multiple edge locations. But people are 
taking it a step further and intentionally sending a cached query response from 
those edge locations to benefit from players thinking their server has the 
lowest latency in the server browser.



John!  Good to hear from all old folks from years ago!

TL/DR: New proposal: the server requires all 3 connectionless packets from 
clients to be at least 1200 bytes.

I've gotten similar feedback from a few people now.  The only reason to 
consider allowing a smaller packet with a challenge is to give the client a way 
to reduce the bandwidth sent when pinging a ton of servers.  But doing this 
would impair the ability to filter out these packets further out, and it is 
also more complicated to implement.  (I wasn't planning on changing the server 
browser in steamclient.dll to do it, I was just going to do the simple thing of 
padding the packet.)  Given that it is 2020 The Year of Our Lord Gaben, 
probably the extra bandwidth needed to ping a bunch of servers is just not 
significant.

Regarding 1200: although this technically maybe not OK according to RFCs from 
the mid 90's, being larger than the absurdly small minimum IPv4 MTU, I believe 
it is OK in practice in 2020 TYOOLG, especially since the minimum MTU for IPv6 
is 1280.  In the SDR protocol used by CSGO and Dota, clients always initiate 
their communication with a 1200 byte packet, and that has not caused any 
problems.

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

RE: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

>Any word on the last bit of John's response regarding "abuse" of 
>BGP/Anycasting to reply
>to source engine queries from the closest geographical location to the 
>requester?

I don't have a good answer for this right now, unfortunately.

From: csgo_servers@list.valvesoftware.com 
Sent: Tuesday, November 17, 2020 10:29 AM
To: csgo_servers@list.valvesoftware.com
Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

As John said, padding with zeros will be easier to mitigate (and less resource 
intensive) for providers, and it solves the reflection.

Any word on the last bit of John's response regarding "abuse" of BGP/Anycasting 
to reply to source engine queries from the closest geographical location to the 
requester?

It's one thing for hosts to use edge locations to mitigate attacks, allowing 
inbound filtering to be spread across multiple edge locations. But people are 
taking it a step further and intentionally sending a cached query response from 
those edge locations to benefit from players thinking their server has the 
lowest latency in the server browser.



John!  Good to hear from all old folks from years ago!

TL/DR: New proposal: the server requires all 3 connectionless packets from 
clients to be at least 1200 bytes.

I've gotten similar feedback from a few people now.  The only reason to 
consider allowing a smaller packet with a challenge is to give the client a way 
to reduce the bandwidth sent when pinging a ton of servers.  But doing this 
would impair the ability to filter out these packets further out, and it is 
also more complicated to implement.  (I wasn't planning on changing the server 
browser in steamclient.dll to do it, I was just going to do the simple thing of 
padding the packet.)  Given that it is 2020 The Year of Our Lord Gaben, 
probably the extra bandwidth needed to ping a bunch of servers is just not 
significant.

Regarding 1200: although this technically maybe not OK according to RFCs from 
the mid 90's, being larger than the absurdly small minimum IPv4 MTU, I believe 
it is OK in practice in 2020 TYOOLG, especially since the minimum MTU for IPv6 
is 1280.  In the SDR protocol used by CSGO and Dota, clients always initiate 
their communication with a 1200 byte packet, and that has not caused any 
problems.

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

As John said, padding with zeros will be easier to mitigate (and less 
resource intensive) for providers, and it solves the reflection.


Any word on the last bit of John's response regarding "abuse" of 
BGP/Anycasting to reply to source engine queries from the closest 
geographical location to the requester?


It's one thing for hosts to use edge locations to mitigate attacks, 
allowing inbound filtering to be spread across multiple edge locations. 
But people are taking it a step further and intentionally sending a 
cached query response from those edge locations to benefit from players 
thinking their server has the lowest latency in the server browser.




John!  Good to hear from all old folks from years ago!

TL/DR: New proposal: the server requires /all/ 3 connectionless 
packets from clients to be at least 1200 bytes.


I’ve gotten similar feedback from a few people now.  The only reason 
to consider allowing a smaller packet with a challenge is to give the 
client a way to reduce the bandwidth sent when pinging a ton of 
servers.  But doing this would impair the ability to filter out these 
packets further out, and it is also more complicated to implement.  (I 
wasn’t planning on changing the server browser in steamclient.dll to 
do it, I was just going to do the simple thing of padding the 
packet.)  Given that it is 2020 The Year of Our Lord Gaben, probably 
the extra bandwidth needed to ping a bunch of servers is just not 
significant.


Regarding 1200: although this technically maybe not OK according to 
RFCs from the mid 90’s, being larger than the absurdly small minimum 
IPv4 MTU, I believe it is OK in practice in 2020 TYOOLG, especially 
since the minimum MTU for IPv6 is 1280. In the SDR protocol used by 
CSGO and Dota, clients always initiate their communication with a 1200 
byte packet, and that has not caused any problems.



___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

RE: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

John!  Good to hear from all old folks from years ago!

TL/DR: New proposal: the server requires all 3 connectionless packets from 
clients to be at least 1200 bytes.

I've gotten similar feedback from a few people now.  The only reason to 
consider allowing a smaller packet with a challenge is to give the client a way 
to reduce the bandwidth sent when pinging a ton of servers.  But doing this 
would impair the ability to filter out these packets further out, and it is 
also more complicated to implement.  (I wasn't planning on changing the server 
browser in steamclient.dll to do it, I was just going to do the simple thing of 
padding the packet.)  Given that it is 2020 The Year of Our Lord Gaben, 
probably the extra bandwidth needed to ping a bunch of servers is just not 
significant.

Regarding 1200: although this technically maybe not OK according to RFCs from 
the mid 90's, being larger than the absurdly small minimum IPv4 MTU, I believe 
it is OK in practice in 2020 TYOOLG, especially since the minimum MTU for IPv6 
is 1280.  In the SDR protocol used by CSGO and Dota, clients always initiate 
their communication with a 1200 byte packet, and that has not caused any 
problems.

To Kyle Sanderson's point: I realize that this is not the most pressing issue 
facing the Internet today.  However, I am currently working on integrating SDR 
functionality with the server browser, and so while I am touching this code, it 
seemed like the right time to address this longstanding issue.  However, Valve 
is very sensitive to breaking old games.  It's my understanding that this plan 
allows old games to continue to operate, even if the code cannot be updated.  
If I'm mistaken, let me know.

From: John 
Sent: Tuesday, November 17, 2020 9:38 AM
To: csgo_servers@list.valvesoftware.com
Cc: Fletcher Dunn 
Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

Fletcher,

This sounds like a reasonable idea.

Of the two, requiring a large request (#1) might be best. Both #1 and #2 help 
with reflection attacks, but #1 also helps to mitigate directly spoofed query 
attacks on game servers. There is less overhead involved on the server side 
with rejecting an improperly sized packet than in generating a randomized 
challenge response and having to locally store that state; and, should the 
spoofer generate properly-sized packets, they would be limited to a lower 
overall packet rate (which also drastically reduces overhead on the server 
side). Further, an external firewall could easily drop improperly-formatted 
packets based on size, cutting out many attacks.

(By the same token, connection and all other unsolicited packets should 
probably also be required to be large.)

The only real downside would be that tools would need to be updated. I don't 
see a blocker there.

The specific size of the packets isn't too important as long as it beats 
lowest-common-denominator MTUs. 800-1200 should be fine.

One other consideration here is whether this can be coupled with changes 
designed to mitigate the negatives of proxied responses (some hosts have taken 
to advertising their prefixes from multiple PoPs and proxying query responses 
in order to fake lower latencies, which degrades the player experience). I 
can't immediately think of a good mechanism for that in the query protocol 
itself; the primary way to deal with it would seem to be at the global level, 
by penalizing servers whose latencies are measured to be low from multiple 
locations in an impossible way.

-John

On 11/16/2020 5:21 PM, Fletcher Dunn - fletcherd at valvesoftware.com (via 
csgo_servers list) wrote:
Hello!

Over the next couple of months we will be releasing some changes to how servers 
and clients using steamclent.so/dll handle the venerable Source engine A2S_INFO 
message used by the server browser.  This includes the Steam client server 
browser, all Source engine games, and all Steam games using the 
ISteamMatchmaking API.  The purpose of these changes is a long overdue fix for 
a reflection attack vulnerability.

This email is to let you know what those plans are and to solicit your 
feedback.  Fixing the vulnerability requires changing the protocol and will 
necessarily break existing third party utilities that speak the protocol.

Currently, the A2S_INFO packet looks like this:
4 bytes: 0x
1 byte: 0x54  (A2S_INFO packet type identifier)
20 bytes: "Source Engine Query\0"

The proposal is for clients to modify the A2S_INFO  packet they send in one of 
two ways:

Option 1: Pad the message with zeros, so that the request is larger than the 
reply.  The passes size is TBD, but it will probably be at least 800 bytes, and 
perhaps as high as 1200.  Feedback is requested concerning this size.

Option 2: Append a 4-byte anti-spoofing challenge obtained using the existing 
A2S_PLAYER or A2S_RULES messages.

Note that both options produce a packet that is acceptable to the current code 
in steamclient.so/dll.  However, 

RE: [External Mail] Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

Also, in case it isn’t clear, if the server is not updated the game still 
works.  Clients sending padded packets can work with old servers.

Are there any example of old *clients* that cannot be updated and need to talk 
to new servers?

From: csgo_servers@list.valvesoftware.com 
Sent: Tuesday, November 17, 2020 9:05 AM
To: csgo_servers@list.valvesoftware.com
Subject: RE: [External Mail] Re: [Csgo_servers] RFC: Changes to the A2S_INFO 
protocol

>proposing breaking tens of orphaned games

Can you give some examples of games that would be broken?

From: 
csgo_servers@list.valvesoftware.com 
mailto:csgo_servers@list.valvesoftware.com>>
 On Behalf Of Kyle Sanderson
Sent: Monday, November 16, 2020 11:44 PM
To: 
csgo_servers@list.valvesoftware.com
Subject: [External Mail] Re: [Csgo_servers] RFC: Changes to the A2S_INFO 
protocol

Tyler,

SNMP attacks are easily 1500x+ the reflection capability (yes, fifteen hundred 
times) from a single packet. NTP is a couple hundred but there were systemic 
fixes over half a decade ago. What is being proposed here is 100% a non-issue 
(SRCDS is again, 8x at best) for the entire internet, and is instead proposing 
breaking tens of orphaned games. I really don't know what yourself or Calvin 
are thinking but this is absolutely a non issue and is threatening the entire 
ecosystem over absolutely nothing. There's plenty of non-source games that use 
the same wire protocol (hell, even a call of duty game) - why are we changing 
it...

Why the hell are you guys thinking this is okay lol. I'm actually really 
confused now if you're not attempting to be arsonists.

Kyle.

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

RE: [External Mail] Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

>proposing breaking tens of orphaned games

Can you give some examples of games that would be broken?

From: csgo_servers@list.valvesoftware.com  
On Behalf Of Kyle Sanderson
Sent: Monday, November 16, 2020 11:44 PM
To: csgo_servers@list.valvesoftware.com
Subject: [External Mail] Re: [Csgo_servers] RFC: Changes to the A2S_INFO 
protocol

Tyler,

SNMP attacks are easily 1500x+ the reflection capability (yes, fifteen hundred 
times) from a single packet. NTP is a couple hundred but there were systemic 
fixes over half a decade ago. What is being proposed here is 100% a non-issue 
(SRCDS is again, 8x at best) for the entire internet, and is instead proposing 
breaking tens of orphaned games. I really don't know what yourself or Calvin 
are thinking but this is absolutely a non issue and is threatening the entire 
ecosystem over absolutely nothing. There's plenty of non-source games that use 
the same wire protocol (hell, even a call of duty game) - why are we changing 
it...

Why the hell are you guys thinking this is okay lol. I'm actually really 
confused now if you're not attempting to be arsonists.

Kyle.
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

In another case, someone sends a fake connect packet to fill the server.

FF FF FF FF connect.

The server always prompts "server is full."

They use proxy ips, and thousands of ips are sending fake data.


On 11/17/2020 3:44 PM, Kyle Sanderson wrote:

Tyler,

SNMP attacks are easily 1500x+ the reflection capability (yes, fifteen 
hundred times) from a single packet. NTP is a couple hundred but there 
were systemic fixes over half a decade ago. What is being proposed 
here is 100% a non-issue (SRCDS is again, 8x at best) for the entire 
internet, and is instead proposing breaking tens of orphaned games. I 
really don't know what yourself or Calvin are thinking but this is 
absolutely a non issue and is threatening the entire ecosystem over 
absolutely nothing. There's plenty of non-source games that use the 
same wire protocol (hell, even a call of duty game) - why are we 
changing it...


Why the hell are you guys thinking this is okay lol. I'm actually 
really confused now if you're not attempting to be arsonists.


Kyle.

On Mon, 16 Nov 2020, 22:56 Tyler Janse, <mailto:tylerrobinja...@gmail.com>> wrote:


Hi all,

I'd like to echo Calvin's opinion.  I think Option 2 is in the
right direction.  I don't have anything new technical-wise to
contribute beyond what's already been stated.

I don't think anyone is worried about carriers or datacenters
going down over source engine reflection attacks, and I made no
comment that would imply that.

My goal is to keep customer's services//online throughout the
attacks, regardless of method or size. DNS/NTP/SNMP reflections
are far less resource intensive to mitigate compared to attacks
that require hashlimits or DPI, even if they are magnitudes larger
on average.

I'd like to accent this thought.  We're talking about an issue
that can hit individual instances, not a whole datacenter.  This
is even more true in a game played in short periods (45 minutes
per game) compared to other longer-played/persistent games.

The fact that these options are proposed and community feedback is
solicited suggest that even internally they recognize this is an
issue that needs to be addressed.

Cheers.

Tyler


On Tue, Nov 17, 2020 at 12:27 AM Kyle Sanderson
mailto:kyle.l...@gmail.com>> wrote:

lol. Who are you.

Best,
Kyle.

On Mon, 16 Nov 2020, 19:45 Calvin Judy - calvin at
swiftnode.net <http://swiftnode.net> (via csgo_servers list),
mailto:csgo_servers@list.valvesoftware.com>> wrote:

So your argument is because there are reflection attacks
with higher amplification, Valve should, do nothing?

I don't think anyone is worried about carriers or
datacenters going down over source engine reflection
attacks, and I made no comment that would imply that.

My goal is to keep customer's services//online throughout
the attacks, regardless of method or size. DNS/NTP/SNMP
reflections are far less resource intensive to mitigate
compared to attacks that require hashlimits or DPI, even
if they are magnitudes larger on average.

I'm not sure why anyone would condemn Valve for patching a
well known reflection vector.



What are you talking about 
There's millions of other boxes. The genesis for all of this was 
SNMP
+- NTP, which came after and was 50x worse per academia. NTP, SNMP,
and CoD were the basic reflection staples of 2010.

There's MTU hacks that break other queries which further destroy the
ecosystem regarding statistics. Breaking outside of the hacked STB
ecosystem (and oh my lord is there a lot) this is not really a hot
market anymore. There's boxes that can actually saturate the entire
link now that don't have to spoof. My single port server receiving 
on
27015 killing an entire datacentre (which hit many other folks - to
the point of pings on IRC) from getting a simple reflection attack 
is
long gone.

Basically, it's great that you've found the entire Valve + 
self-hosted
ecosystem at its peak. But this is a decade old issue that no longer
impacts real carriers,
Kyle.

On Mon, Nov 16, 2020 at 6:43 PM Calvin Judy - calvin atswiftnode.net  
<http://swiftnode.net>
(via csgo_servers list)  
<mailto:csgo_servers@list.valvesoftware.com>  wrote:


___
To unsubscribe, edit your list preferences, or view the
list archives,
please visit:
https://list.valvesoftware

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

So your argument is because there are reflection attacks with higher 
amplification, Valve should, do nothing?


I don't think anyone is worried about carriers or datacenters going down 
over source engine reflection attacks, and I made no comment that would 
imply that.


My goal is to keep customer's services//online throughout the attacks, 
regardless of method or size. DNS/NTP/SNMP reflections are far less 
resource intensive to mitigate compared to attacks that require 
hashlimits or DPI, even if they are magnitudes larger on average.


I'm not sure why anyone would condemn Valve for patching a well known 
reflection vector.




What are you talking about 
There's millions of other boxes. The genesis for all of this was SNMP
+- NTP, which came after and was 50x worse per academia. NTP, SNMP,
and CoD were the basic reflection staples of 2010.

There's MTU hacks that break other queries which further destroy the
ecosystem regarding statistics. Breaking outside of the hacked STB
ecosystem (and oh my lord is there a lot) this is not really a hot
market anymore. There's boxes that can actually saturate the entire
link now that don't have to spoof. My single port server receiving on
27015 killing an entire datacentre (which hit many other folks - to
the point of pings on IRC) from getting a simple reflection attack is
long gone.

Basically, it's great that you've found the entire Valve + self-hosted
ecosystem at its peak. But this is a decade old issue that no longer
impacts real carriers,
Kyle.

On Mon, Nov 16, 2020 at 6:43 PM Calvin Judy - calvin at swiftnode.net
(via csgo_servers list)  wrote:

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

Kyle,

SRCDS doesn't need to be a "majority stakeholder" to receive patches to 
known security vulnerabilities. There's tens of thousands of srcds 
servers, nearly all of which can be sent a spoofed query and will 
respond to a victim address with server information. "Only 8x" is still 
enough to cause plenty of people issues, when this can be resolved by a 
patch like Fletcher is suggesting. We still see dozens of these attacks 
per month. Patching this won't have the same impact as patching the 
memcached reflection, but it will still result in a decrease in attacks, 
and allow a simplified mitigation solution.


To break down how 8x can still overwhelm plenty of providers:

Five servers/zombies on providers non-compliant with BCP38/RFC2827, each 
with 1000mbit uplinks, send spoofed source engine queries to 5,000 srcds 
servers. At 8x average amplification, the victim address will 
theoretically receive 40Gbps worth of responses from those 5,000 srcds 
instances.


Also, if I'm not mistaken, they did try to patch this previously a 
couple years ago on CSGO, with the addition of the sv_max_queries_sec. 
But unfortunately there's tens of thousands of srcds servers malicious 
actors can cycle through, so those commands aren't very effective at 
their default values.




I think where I'm going with this is why on gods green earth are we
doing this when SRCDS is just not a majority stakeholder on the
internet anymore. I'm confuzzled: and now I'm confused.

Kyle.


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

Fletcher,

Either option would work in theory, but #2 seems like the proper way to 
resolve this. Alfred spoke with me about this back in late 2015, but 
wasn't really concerned with patching it then, since then we've worked 
out many effective methods of filtering these attacks. (header 
checksums, rate limits, udp hashlimits) each method comes with their own 
tax on resources of our mitigation hardware. As a provider, having a 
unified, simple solution to filter these would be nice. Assuming this 
breaks older queries, there should also be a pretty significant decrease 
in the amount of attacks, as well as increasing the bandwidth required 
to launch them.

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

[Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

Hello!

Over the next couple of months we will be releasing some changes to how servers 
and clients using steamclent.so/dll handle the venerable Source engine A2S_INFO 
message used by the server browser.  This includes the Steam client server 
browser, all Source engine games, and all Steam games using the 
ISteamMatchmaking API.  The purpose of these changes is a long overdue fix for 
a reflection attack vulnerability.

This email is to let you know what those plans are and to solicit your 
feedback.  Fixing the vulnerability requires changing the protocol and will 
necessarily break existing third party utilities that speak the protocol.

Currently, the A2S_INFO packet looks like this:
4 bytes: 0x
1 byte: 0x54  (A2S_INFO packet type identifier)
20 bytes: "Source Engine Query\0"

The proposal is for clients to modify the A2S_INFO  packet they send in one of 
two ways:

Option 1: Pad the message with zeros, so that the request is larger than the 
reply.  The passes size is TBD, but it will probably be at least 800 bytes, and 
perhaps as high as 1200.  Feedback is requested concerning this size.

Option 2: Append a 4-byte anti-spoofing challenge obtained using the existing 
A2S_PLAYER or A2S_RULES messages.

Note that both options produce a packet that is acceptable to the current code 
in steamclient.so/dll.  However, any custom handlers might have stricter 
behavior, and will need to be updated to be aware than "extra" data might 
appear after the end of the magic string in packets from legitimate clients.

Once all clients are using one of these two options, a server wishing to avoid 
being vulnerable to reflection attacks could drop any A2S_INFO packets below a 
minimum size without a challenge.

The changes would be deployed as follows:


1.) First, we will release a new Steam client that sends A2S_INFO messages 
padding to a minimum size.  (Option #1 above.)  Since it takes time for Steam 
client updates to roll out to all Steam users, and for third parties to change 
their code to make queries in the new format, we will not change the server to 
require the new format by default.  However, the server code will be updated to 
look for an environment variable that can be used to opt into the new, stricter 
behavior.  This is so that third parties can test their clients to make sure 
they are compliant with the new server code.

2.) As more clients upgrade to the new code and third party tools are 
updated to send queries in the new format, server operators may elect to opt 
into the new behavior at their discretion using the environment variable.

3.) After some time has passed (and we have posted several warnings on this 
mailing list), we will ship a new steamclient.so/.dll that has the strict 
behavior enabled by default.  A different environment variable can be used to 
use the older, more permissive behaviour.

If you have any concerns or feedback about this change, please reply to this 
steam post:
https://steamcommunity.com/discussions/forum/14/2989789048633291344/

After feedback has been collected and details finalized, I'll post again with 
more technical details about the changes that are going to be made.
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] AW: Daily digest for csgo_servers@list.valvesoftware.com

[Neuro Toxin - corayzon at yahoo.com.au (via csgo_servers list)]

 Yep. 
All inaccurate. Valve will unlikely respond as its a can of worms they already 
lost the battle on. GSLT bans were issued on Monday, Wednesday and Fridays. The 
last GSLT banwave was issued 2018-10-24.
GSLT bans are no longer enforced. Any server admins with a token provider which 
have had token bans, they are being played. 
On Friday, 3 January 2020, 04:15:00 pm AEDT, John Doe 
 wrote:  
 
 He is not working for Valve. I have no idea why he is writing as if he were 
(its really funny tho). This is just some random person and he is just guessing 
as far as I understand.
Den fre 3 jan. 2020 kl 05:52 skrev Daniel Sensenbringer 
:


Hi Miguel,

 

Thanks for your answer. But I am asking myself one question according to your 
answer. Who are you, that you are able to answer this question? Are you from 
Valve? Your email doesn’t look like: mig...@hotmail.dk

 

In case you are not from Valve: Why do you know that a server sided 
skinchanger, that swaps the equipped model to the standard model is allowed?

 

Would be awesome if someone from Valve could answer this question. We need to 
be sure.

 

Best Regards

daniels

 

 

Von: CS:GO Dedicated Server Mailing List [mailto:nob...@simplelists.com] 
Gesendet: Freitag, 3. Januar 2020 01:41
An: csgo_servers@list.valvesoftware.com
Betreff: Daily digest for csgo_servers@list.valvesoftware.com

 

| 
(Previous discussion continued) 
 |
| 
Re: [VALVE] Disable new player models - Miguel Petersen (02 Jan 2020 08:43 UTC) 
 |  |  |
| 
(missing) 
 |
| 
(missing) 
 |
| 
(missing) 
 |
| 
(missing) 
 |
| 
(missing) 
 |
| 
Sv: Re: [VALVE] Disable new player models - Miguel Petersen (02 Jan 2020 12:11 
UTC) 
 |  |  |
| 
SV: [Csgo_servers] Re: [VALVE] Disable new player models - Christopher Szabo 
(02 Jan 2020 08:45 UTC) 
 |  |  |
| 
Sv: [VALVE] Disable new player models - Miguel Petersen (02 Jan 2020 09:12 UTC) 
 |  |  |
| 
Sv: [VALVE] Disable new player models - Miguel Petersen (02 Jan 2020 12:55 UTC) 
 |  |  |
| 
Sv: [VALVE] Disable new player models - Miguel Petersen (02 Jan 2020 14:55 UTC) 
 |  |  |


Re: [VALVE] Disable new player models by Miguel Petersen (02 Jan 2020 08:43 UTC)
Reply to list

Hi Chris,


I'm sorry but it's not possible to disable the Shattered Web Character models 
on official servers, you can do it with a plugin for your own server.

Faceit is not breaking the rules because it's not official servers.

"It's not allowed to: Interfering with systems that allow players to correctly 
access their own CS:GO inventories, items, or profile.!" 

​It means that it's not allowed to change the models on official Competitive 
Ingame 5vs5 servers, Casual, Dangerzone etc.


Have a good day!

Best regards
Miguel.  

Fra: csgo_servers@list.valvesoftware.com  
på vegne af Christopher Szabo 
Sendt: 19. december 2019 13:39
Til: csgo_servers@list.valvesoftware.com 
Emne: [Csgo_servers] Disable new player models 

 

Hi

I have a question regarding the Valve Guides lines for CSGO server owners. Its 
says its not allowed to:

"Interfering with systems that allow players to correctly access their own 
CS:GO inventories, items, or profile.!" 

So my question is: Does this mean that we can't inactive the new player models 
that people keep complaining about? Its possible to disable them with Sourcemod 
plugin. 

 I know Faceit has disabled them, so are they breaking the rules? Or is it 
in-fact allowed?

/ Chris

Sv: Re: [VALVE] Disable new player models by Miguel Petersen (02 Jan 2020 12:11 
UTC)
Reply to list

I know it's a huge problem that server owners are using these plugins. 


Robots are banning user tokens on daily basis regarding this problem, but I 
also know that when the token is banned, their system generates new steam 
accounts and autofill in the new token into the plugin. (Thats a part of the 
skin-changer plugin).

It's really hard to stop, but ofcourse I can see it from your perspective thats 
it's not okay.

But I can only say at the moment that it's still strongly forbidden. And I'm 
sorry to hear you lose many players on this, because you follow the guidelines.


Best regards
Miguel.

Fra: Christopher Szabo 
Sendt: 2. januar 2020 12:26
Til: Miguel Petersen 
Emne: Sv: Re: [VALVE] Disable new player models 

 

Also, I wasnt taking about a client skin changer, I was asking about giving 
players weapon skins/gloves that they dont currently own, on a comunity server 
via sourcemod plugins.

Is that allowed now? Because its like this, Ive been running a CS community for 
over 15 years now. We are following the guidelines and always have. But we 
compete against other servers that dont follow the guidelines...

They offer their players cool  Valve skins the players dont own, and they never 
get token banned.

This means that we follow the rules and we lose players and they break the 
rules and gain players without consequences. This is not fair at all.

I dont think its fair having rules that you dont enforce because the good guys 
gets screwed. 

Re: [Csgo_servers] Disable new player models

[Neuro Toxin - corayzon at yahoo.com.au (via csgo_servers list)]

 Note: Valve hasnt issued a GSLT banwave for well over a year.
So there's currently no consequence for not following the guidelines.
On Thursday, 19 December 2019, 11:40:03 pm AEDT, Christopher Szabo 
 wrote:  
 
  Hi

I have a question regarding the Valve Guides lines for CSGO server owners. Its 
says its not allowed to:
"Interfering with systems that allow players to correctly access their own 
CS:GO inventories, items, or profile.!"

So my question is: Does this mean that we can't inactive the new player models 
that people keep complaining about? Its possible to disable them with Sourcemod 
plugin.

 I know Faceit has disabled them, so are they breaking the rules? Or is it 
in-fact allowed?
/ Chris


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
  
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: RE: [Csgo_servers] PanoramaUI community server issue update July 26th motdfile

[Neuro Toxin (via csgo_servers list)]

 What about simplying allowing links in chat that when clicked on open via the 
overlay browser?
https://forums.alliedmods.net/showpost.php?p=2612564=340


On Saturday, 28 July 2018, 6:13:41 pm AEST, Neuro Toxin (via csgo_servers 
list)  wrote:  
 
  I just used the View Server Website button.
Which is absolutely great! Into the Steam overlay browser with a redirection 
page.
Plz plz plz, allow us to trigger this method via a !command and specify a URL.
A simple update to ShowMOTDPanel when MOTDPANEL_TYPE_URL is parsed to use the 
same method would be great!
It blocks all the ad providers with useless hidden spam while allowing 
legitimate use for rich server integration!
On Saturday, 28 July 2018, 5:31:43 pm AEST,  wrote: 
 
 
 
Valve doesn't matter what we want. They only want money. They don't do anything 
for server masters! When you try contact Valve directly, you have no any 
response from the Valve (they are ignore all emails). After a long time we want 
something and we will not get it. We are must listening any stupid ideas or 
restrictions from the Valve. The Valve will never do anything for the 
community. * of Valve.

- Fastmancz.

 
|  | Bez virů. www.avast.com  |

 
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
  
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
  
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: RE: [Csgo_servers] PanoramaUI community server issue update July 26th motdfile

[Neuro Toxin (via csgo_servers list)]

 I just used the View Server Website button.
Which is absolutely great! Into the Steam overlay browser with a redirection 
page.
Plz plz plz, allow us to trigger this method via a !command and specify a URL.
A simple update to ShowMOTDPanel when MOTDPANEL_TYPE_URL is parsed to use the 
same method would be great!
It blocks all the ad providers with useless hidden spam while allowing 
legitimate use for rich server integration!
On Saturday, 28 July 2018, 5:31:43 pm AEST,  wrote: 
 
 
 #yiv3350876402 #yiv3350876402 -- _filtered #yiv3350876402 {panose-1:2 4 5 3 5 
4 6 3 2 4;} _filtered #yiv3350876402 {font-family:Calibri;panose-1:2 15 5 2 2 2 
4 3 2 4;}#yiv3350876402 #yiv3350876402 p.yiv3350876402MsoNormal, #yiv3350876402 
li.yiv3350876402MsoNormal, #yiv3350876402 div.yiv3350876402MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;font-family:sans-serif;}#yiv3350876402
 a:link, #yiv3350876402 span.yiv3350876402MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv3350876402 a:visited, #yiv3350876402 
span.yiv3350876402MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv3350876402 
p.yiv3350876402msonormal0, #yiv3350876402 li.yiv3350876402msonormal0, 
#yiv3350876402 div.yiv3350876402msonormal0 
{margin-right:0cm;margin-left:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv3350876402
 p.yiv3350876402ydpf285d862yiv5345857069msonormal, #yiv3350876402 
li.yiv3350876402ydpf285d862yiv5345857069msonormal, #yiv3350876402 
div.yiv3350876402ydpf285d862yiv5345857069msonormal 
{margin-right:0cm;margin-left:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv3350876402
 span.yiv3350876402StylE-mailovZprvy21 
{font-family:sans-serif;color:windowtext;}#yiv3350876402 
.yiv3350876402MsoChpDefault {font-size:10.0pt;} _filtered #yiv3350876402 
{margin:70.85pt 70.85pt 70.85pt 70.85pt;}#yiv3350876402 
div.yiv3350876402WordSection1 {}#yiv3350876402 
Valve doesn't matter what we want. They only want money. They don't do anything 
for server masters! When you try contact Valve directly, you have no any 
response from the Valve (they are ignore all emails). After a long time we want 
something and we will not get it. We are must listening any stupid ideas or 
restrictions from the Valve. The Valve will never do anything for the 
community. * of Valve.

- Fastmancz.

 
|  | Bez virů. www.avast.com  |

 
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
  
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] PanoramaUI community server issue update July 26th motdfile

[Neuro Toxin (via csgo_servers list)]

 I personally use them for almost everything. Administration, rules, logs, 
gamemode configs, user settings, forums, messages, stats, ban/kick messages, 
welcome motd, tracking.
>From a game server you can parse authentication keys for auto logins. Have 
>sites rcon commands back to complete rich server integrations. 
Selecting players models is great example. !model shows a page. Select a team. 
All the models are displayed with gifs of the models. Selecting a model rcons 
back to the server and the players model changes.
Administrating servers with !players which shows all players with steam 
profiles and options for kicking ect.
Some of us have hundreds of hours in codebases with hundreds of thousands of 
lines of code (sourcepawn, php, mysql, html, css, javascript) that create 
incredibly unique gamemodes and administration that now dont function at all.
It would be great to see HTML windows instead of a dodgy MOTD window popup 
hacks to display rich server content. 
I would personally love to see a ShowMOTDPanel equivalent like ShowHTMLPanel 
which takes a URL that doesnt need a dodgy popup call in javascript to show the 
URL. It could open the URL in the steam overlay with the standard Valve 
redirection warning page so the user can click to redirect or close the tab.
This would stop players being forced adds in a way that you cant even see them 
which spam sound and generate illegal revenue.
It would allow players to shift tab back into the game and leave browser tabs 
open to bounce back to.
Valve please consider the above. You could use this to create your own 
integrations and gives us more control and players a safer experience while 
squashing the dodgy ad providers.
Plz plz plz dont make me depressed by hitting delete on years spent coding my 
administration panels.
On Saturday, 28 July 2018, 6:04:26 am AEST, James F  
wrote:  
 
 In my eyes, advertisements aren't really a major problem in the csgo scene, 
loud obnoxious ones are. The way to counter would be to just have it so that 
videos with sound don't play automatically just like in the new chromium update.
My servers are heavily dependent on web commands and adding a button is an 
amazing counter but it just doesn't cut it in my eyes.
On Fri, 27 Jul 2018, 8:44 pm Mark Schieldrop,  wrote:


Sure, but when the ethically minded people are outnumbered by a large margin, 
it’s understandable why they’d choose to get rid of it even if it affects the 
few who used it appropriately.

 

From:  on behalf of Will Graham 

Reply-To: "csgo_servers@list.valvesoftware.com" 

Date: Friday, July 27, 2018 at 3:05 PM
To: "csgo_servers@list.valvesoftware.com" 
Subject: RE: [Csgo_servers] PanoramaUI community server issue update July 26th 
motdfile

 

Please do not assume that everyone on this list (or everyone that’s used MOTD 
panels) was doing so maliciously or for commercial gain.  Some of us using them 
ethically are penalized by this change as well.

 

Will Graham

CEVO Inc

 

From: csgo_servers@list.valvesoftware.com 
On Behalf Of Dennis B
Sent: Friday, July 27, 2018 3:02 PM
To: csgo_servers@list.valvesoftware.com
Subject: Re: [Csgo_servers] PanoramaUI community server issue update July 26th 
motdfile

 

Only reason why you want to show rules it  to be able to run your commercials, 
please do not add motd back, let them add a welcome message, period

 

2018-07-27 20:45 GMT+02:00 Ejziponken - :


Maybe they should make it so we add TEXT with CSS in a MOTD window, but not 
actually showing websites or have annoying ads showing in them. No redirects 
etc. 

 

 

Med vänliga hälsningar / Best regards

 

Christopher Szabo| Chairman of the Board

 

Skype: szaabo85 | E-mail:sza...@hotmail.com

Website: BrutalCS.nu | Facebook: Facebook.com/BrutalCS

 

Från:csgo_servers@list.valvesoftware.com  
för Brandon @ OBEK 
Skickat: den 27 juli 2018 20:34
Till: Csgo Servers
Ämne: [Csgo_servers] PanoramaUI community server issue update July 26th motdfile

 

Dear CSGO Devs,

 

Adding a button to the scoreboard is nice but doesn't solve or replace the 
important purpose of a motd that needs to be a welcome message when a player 
joins a community server. New players not knowing the rules or how to play the 
many different gamemodes/mods when joining a community server is going to be 
quite annoying and hurt the csgo community as a whole. All players need to 
equally see important information/rules upon joining a community server.

 

A suggested improvement would be to allow server owners the option (by cvar 
sv_disable_motd) to display an "I Agree" motd window on player join that can be 
set to a url of the server owner’s choice via the motdfile. Basically how it 
was but with an “I Agree” button to continue with users’ consent.

 

Please do not release Panorama UI as forced default for everyone without 
community servers having the option to show motd on player join.

 

Thank you.

 

---

Brandon






On Tue, Jul 24, 2018 at 8:10 PM, Brandon @ OBEK