Different attacks, different issues
We categorize attacks into two primary categories. Layer 7 and Layer 4 – which we’ll refer to as L7 and L4 in the rest of this post.
L4: Network Layer
L4 attacks aim to bring a server down by basically overloading its connection to the internet. For example, if a server has a “unprotected” 100Mbps connection to the internet, and an attack of 200Mbps hits that server, it’s internet connection can be saturated and go down.
Generally, L4 attacks aren’t hard to block. You just need a larger internet capacity than the attacker. We leverage OVH’s over 3Tbps “VAC” system with some custom rules to handle all our layer 4 attacks – and it works really well.
These attacks work universally on any internet-connected service, and they’re very easy to launch. But they’re expensive because you always need more bandwidth than the person you’re attacking.
In all our years of operating, we’ve never had issues with L4 attacks because we can leverage the beefy “VAC” system OVH provide.
L7: Application Layer
L7 attacks are generally a lot smaller than L4 attacks and aim to bring down the server by overloading the server itself. For example, they might try to overload the CPU or a design flaw in the application.
These attacks are generally cheaper to launch and harder to block because they mimic real-user behaviour. However, they’re game/application-specific and require some brains to develop.
While providers like OVH often provide L7 protection, it’s generally only good against the most common types of L7 attacks. New or unusual attacks will bypass these systems.
How we previously handled L7
Previously we use pattern recognition to block layer 7 attacks based on existing attack patterns we’ve observed historically. This is how most mitigation systems work. We were able to do a better job than other companies because we could just focus on Minecraft and Garry’s Mod, and had connections to the people that often developed these attacks.
It’s a situation where being a smaller company is an advantage – as we could be more responsive to emerging threats in these games, rolling out, or rolling back changes almost immediately, because we had greater real-time visibility into how the changes impacted our customers.
PlayerGate works in a new way because it doesn’t look for patterns that are found in attacks like previous systems. Instead, it looks for patterns that would be hard for an attacker to emulate. And because updates constantly change minor details in how games work, attackers will need to keep up with any changes, which is time-intensive.
This makes it much more expensive for attackers to get their foot in the door since they need to accurately emulate a lot of real-game behaviour before they can launch the attack. There are basically no attacks that are currently this advanced for games.
For the very few (private) attacks that do try to emulate the game, we can still identify highly specific abnormalities in how their client behaves, because they can’t perfectly emulate how the game would behave without a huge time investment, and in turn increased resource demand to launch the increasingly complex attacks.
Traditionally mitigation systems would work as a cat-and-mouse game, with hosting companies responding to emerging threats as they appear. PlayerGate turns traditional mitigation systems on their head, putting ourselves ahead of the attackers, while simplifying our protection stack, making it more cost-effective to run.
Since September we have been running this system on some customers who previously got targeted frequently by attackers with 100% efficacy.
However, the one catch is we will need to restart game servers for the system to be deployed. This is a one-time process, and we will be announcing the time-table for this in Discord shortly.
We want to roll this system out sooner than later, so you can expect that follow up this week.