Keeping Up with DDoS Trends
The Distributed Denial of Service (DDoS) attack landscape has been rapidly changing over the past few months, with the level of sophistication of attack vectors increasing almost daily. Online facing companies, especially those in the gaming sector, need to be agile and keep up to speed before they get permanently crippled by this new wave of attacks.
These attacks have been targeting popular community servers for well-known games such as Counter-Strike: Global Offensive and Garry’s Mod causing frustration to both the players and gaming communities.
What is it about these new attacks that makes them so dangerous?
More recently we have seen a rise in application-specific (layer 7) DDoS attacks targeting our gaming network. In particular, these attacks are mimicking legitimate player traffic. This can cause major headaches for mitigation experts trying to determine a “bad” packet from a good one. Unlike traditional Volumetric attacks, which attempt to overload the host’s network, these attacks are very small ~50 – 500Mbit and 100KPPS – 1MPPS and rely on the application itself being overloaded by “attack packets”.
Lets deep dive into the attack
To gain a deeper understanding of these attacks we need to first have a more in-depth understanding of the games themselves, in particular A2S or (source query traffic). Without going into an excessive amount of information, this protocol allows for the player and server to communicate and authenticate. Now that we have a basic understanding of the attacks, let’s have a look at the payload of an attack packet and a real packet side by side so that we can understand the level of sophistication involved. The below information was gathered from our GSL mitigation devices.
Attack Source Packet:
Packet Length: 71
TTL (time to live): 111
Real Source Packet:
Packet Length: 71
TTL (time to live): 115
As you can see, there is no difference between the packets at all, moreover, the length of the packet and TTL (time to live) are all being mimicked (within normal traffic ranges) to appear legitimate. In traditional attacks (Volumetric), this wouldn’t cause an issue as the attack is so small and wouldn’t overload the connection to the server or backbone networks.
However, the issue arises in the fact that games such as Counter-Strike: Global Offensive (and other source games) applications accept the traffic and process it without questioning if it is legitimate or not. This results in the host’s machine ‘spiking’ in CPU usage as the application is trying to process the hundreds of thousands to millions of “bad” packets flooding it. This affects just the one server and causes “Choke”, “Var” and high latency in the game, since just that one service's CPU core becomes overloaded.
SRCDs Application under attack
System CPU usage
What can be done?
To prevent attackers bypassing our new mitigation rules, we won’t be able to provide exact details on how we’ve gone about stopping these attacks. We will however provide some basic insights into how we have implemented them.
This is where the importance of onsite highly advanced DDoS mitigation appliances come in. In the case of Global Secure Layer, we utilise an international setup of NTD devices, that provide us with the ability to investigate and mitigate new attacks on the fly. Using the dashboard we can see the traffic flowing towards the attacked IP in real-time.
As you can see there are a number of very large spikes in the packets targeting the service IP - this usually indicates a DDoS attack, let’s dig a little deeper and see what the packets were.
Looking at the payload (UDP data) at the time of the large spikes, we see the following, a clear indication of a A2S / Source Query attack payload. Now how do we go about stopping this attack? The easy and obvious answer would be to simply block the entire payload, however as we mentioned previously this is legitimate traffic as well. Blocking the entire payload would result in no players being able to join the service, effectively doing exactly what the attackers want.
This is where we can’t provide more detail, as it would expose too much of the new attack vector rules we put in place. All that we can say is that the new rules name is “syd_A2SGETSUM” and is currently deployed across our global network.
We hope you enjoyed this deep dive into the changing landscape of attacks, let us know if you would like to see more of these casual but hopefully informative blog posts.
Author: Callum, Chief Operating Officer at GSL