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
<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
<kyle.l...@gmail.com <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),
<csgo_servers@list.valvesoftware.com
<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)<csgo_servers@list.valvesoftware.com>
<mailto:csgo_servers@list.valvesoftware.com> wrote:
_______________________________________________
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/
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
