> 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 where we disagree again :-). I too wrote a L7 firewall nearly
a decade ago (which is still running today) looking at common floods
and (incredibly) slow paths in the engine to patch them. I didn't go
so far as to what JohnS did with a third-party condom app in the
middle (although I did indeed wear it at points in time). Adjusting L7
"appliances" to me here actually makes more sense. For whatever reason
I'm still getting daily DDoS attacks and various mitigations have held
true - and if I'm a GSP a dozen lines of code resolves the issue for
my entire client base which is another win.
If the issue is GSPs, their customers will bring the doors down quite
quickly on a well-defined query protocol change. That's why pulling
this data from the GMS removes 90%+ of the hurdles for everyone, and
the remaining 10%- feels incredibly trivial as it may not even exist.
I guess where things are breaking down for me is why is the client
querying the server, to get the ISBN|IBAN equivalent for a catalog
return, to go back to the GMS to say "give me the goods" | "hook me
up" when the GMS can return all relevant data upon query. The query
can even be secured by the user pubkey - so if folks start flooding
you'll know exactly which {A,S}ID it is and drop them. If the query is
invalidly signed - ban the tuple for a minute. These queries don't
even need to happen anymore as far as I'm aware, the only thing
missing is latency which is the revival of A2A_PING and that's a 1
byte amplification which is less than the current proposal.
The summary I suppose is I don't understand why this is so complicated
;-). This doesn't need to happen to begin with, but there's many
different avenues to boil the ocean that avoid massive headaches for
all and can really improve the lives of players by avoiding "fake
player" servers with guaranteed signed client counts.
Kyle.
On Fri, Dec 4, 2020 at 11:31 AM Fletcher Dunn - fletcherd at
valvesoftware.com (via csgo_servers list)
<[email protected]> wrote:
>
> 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: [email protected]
> <[email protected]> On Behalf Of David Parker
> Sent: Thursday, December 3, 2020 8:46 PM
> To: [email protected]
> Cc: [email protected]
> 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 (via csgo_servers list)
> <[email protected]> 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. 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: [email protected]
> <[email protected]>
> Sent: Thursday, December 3, 2020 2:42 PM
> To: '[email protected]'
> <[email protected]>; [email protected]
> 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/
>
>
>
> --
>
> 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:
> 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/
