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: <> 
On Behalf Of David Parker
Sent: Thursday, December 3, 2020 8:46 PM
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.


On Thu, Dec 3, 2020 at 10:54 PM Fletcher Dunn - fletcherd at<> (via csgo_servers list) 
A steam client beta has been released:

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.  

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: 
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!

Sent: Thursday, December 3, 2020 2:42 PM
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:

To unsubscribe, edit your list preferences, or view the list archives,
please visit:

Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177

To unsubscribe, edit your list preferences, or view the list archives,
please visit:
To unsubscribe, edit your list preferences, or view the list archives,
please visit:

Reply via email to