That's quite fair Kyle. I'm not as versed on the intricacies of how changes to CSGO specifically will propagate across other games. However, I see what you mean. Since the shared object/library will be modified (shared across other SRCDS, not just CSGO servers), only those who have active maintainers would transition to the next "level" and those without dedicated maintainers will be left off to the side. Wouldn't this be a good discussion to have with the HLDS community as a whole then instead of just the CSGO_Servers listserv?
If I'm reading this correctly, it'd be disappointing to lose those games. Would there be a way for us to get around this, such as having "legacy" server browser or such? Or would this be a hard cut? Is there a potential for community-supported solutions? Has anyone ever thought about this before? This opens up more questions regarding future/potential support for other legacy software. However, as far as progress goes, I see this as a step forward. Ideally we'd like a solution that supports all options but if we're at a crossroads, I hate to say it for the nostalgic guy in me, but I'm still leaning towards option 2. - Tyler Janse On Tue, Nov 17, 2020 at 11:16 AM Kyle Sanderson <kyle.l...@gmail.com> wrote: > All good Tyler. Yes, while this is on csgo_servers, the first paragraph > clearly states this impacts all consumers. > > ``` > 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 is not just a change against CSGO, this is a change across the entire > platform that has massive implications. Additionally, CSGO has not > responded to these messages (completely, anyway) by default for many years > (over 6 years if memory serves) which makes this all the more difficult to > comprehend as this is not a change that impacts CSGO in the slightest. > > I really don't like this proposal because it's going to break old, stable, > orphaned games that no one has the source code to anymore as the studios / > artists are long gone. This is why I was claiming arson - because these > games will finally die. I think the vast majority of us are against game > death which is why I was/am quite irked by some of the comments saying this > is fine for GSPs. > > Kyle. > > On Tue, 17 Nov 2020, 07:48 Tyler Janse, <tylerrobinja...@gmail.com> wrote: > >> Kyle, >> >> I understand your argument however I think you're focusing on the wrong >> baseline. I'm familiar with SNMP and NTP and the volume of reflection >> attacks. >> >> SNMP and NTP are significantly more widely adopted than SRCDS which is >> why you'll get those volumes of traffic. I'm not disagreeing with you on >> that. However, the point still stands that this is only focusing on >> A2S_INFO protocol and the potential changes to the structure of said >> protocol to minimize such issues. This isn't a discussion about changes to >> the SNMP and NTP protocol to mitigate these issues (most might argue >> "configure SNMPD right!" or "put it behind a firewall"...). Also I don't >> see the "breaking tens of orphaned games" when this is the CSGO_Servers >> listserv. If you're talking about servers that have been orphaned then >> those servers probably haven't been updated anyways, therefore preventing >> people (with updated game clients) from connecting to them. With or >> without this change, server hosters have to update the game and underlying >> mods anyways to continue to get players into their games. >> >> I think we can sum this up in a fairly simple way. >> >> *PROS* >> - Reduce potential for reflection attacks from SRCDS >> >> *CONS* >> - Additional effort needed to modify solutions built on top of this >> protocol >> >> I'm not saying that developer time and attention is nothing, especially >> since so much has been built off the backs of third party developers and >> modders. However, from what I see, it seems like this time investment will >> continue to refine the underlying servers that props this game up. I see >> the argument of SNMP and NTP irrelevant as we're talking here about >> something else. >> >> Also notice that they've published a schedule of staged deployments for >> this solution. It's not like they're going to flip the switch tomorrow and >> all hell breaks loose. If I'm misinformed, then please let me know. >> >> There's no reason to be condescending. I'm not trying to be an arsonist >> or "ruin everyone's fun". Let's have a healthy discussion instead of >> biting off everyone's head. >> >> - Tyler >> >> >> >> On Tue, Nov 17, 2020 at 9:50 AM David Parker <dpar...@utica.edu> wrote: >> >>> I will also jump in here and say that I like option #2 better. It's >>> simpler and more consistent with the other protocols used by SRCDS, and >>> keeps the packets nice and small while also (hopefully) mitigating these >>> attacks. >>> >>> And Fletcher, I appreciate you reaching out and soliciting feedback >>> before making this change. Scrambling to implement a change in our >>> A2S_INFO clients after the fact would not have been much fun. >>> >>> Thanks! >>> >>> On Tue, Nov 17, 2020 at 3:33 AM YUAN RUI - number201724 at me.com (via >>> csgo_servers list) <csgo_servers@list.valvesoftware.com> wrote: >>> >>>> 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, <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 <kyle.l...@gmail.com> >>>>> wrote: >>>>> >>>>>> lol. Who are you. >>>>>> >>>>>> Best, >>>>>> Kyle. >>>>>> >>>>>> On Mon, 16 Nov 2020, 19:45 Calvin Judy - calvin at swiftnode.net >>>>>> (via csgo_servers list), <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 at swiftnode.net >>>>>>> (via csgo_servers list) <csgo_servers@list.valvesoftware.com> >>>>>>> <csgo_servers@list.valvesoftware.com> wrote: >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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/ >>>> >>>> _______________________________________________ >>>> 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/ > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/
