In this first part of the written version of our webinar, we will discuss security in more detail. You can also watch the recording of our webinar above and click on the security chapter for more details on this subject. Please remember to accept all cookies, otherwise the video might not show up for you.
Let’s talk about security. It still is an often so forgotten aspect because it costs time and money now, while it saves you so many headaches than if you do so later in the future.
There are a lot of emotions involved with gaming; from players themselves, but also let’s not forget monetization, Twitch streams with subscribers, esports events with prizes. There are a lot of people that think nothing is more enjoyable than kicking down the sandcastle, ‘owning’ the servers that clan, or streamer, is currently playing on.
If you work with anything gaming-related, expect to get a lot of ‘free stress testing’ and other nastiness directed towards your infrastructure, network, and game. The battle for security starts by dedicating some time in your development process to it; namely ensuring that your server doesn’t easily crash when it’s fed random gibberish data.
That way you can make sure that people cannot easily spoof real game traffic or send many fake connection attempts to run you out of resources. Maybe consider even adding some special preambles to the traffic stream, making it harder for the average scripter to duplicate these kinds of attacks. Or maybe think about integrating your matchmaker, which sends any new player IPs who wish to join, to your game server, or firewall or platform partner, while automatically dropping any other requests arriving at the server itself.
We’ve seen a lot of incidents where new exploits for games were being written and within no time it was shared on closed social media groups. Before we knew it, whole continents were taken down for that game because it was constantly being attacked. Unfortunately, this usually happens quite sometime after the game’s release at which point it becomes incredibly difficult, to get a game development team back together to work on code made years ago to resolve this issue.
This has a major impact on the player’s experience; getting booted from a server once during the evening is acceptable. However, after multiple incidents, those players are unlikely to come back and might simply switch to a competitor’s game instead!
Aside from securing your application, you also need to think about how to tackle the DDoS attacks, either yourself on your own infrastructure or with partners. DDoS attacks come in several forms:
The first is Volume attacks, where basically the goal is to cause a traffic jam. This results in grinding all the traffic of the server, or even a whole data center to a grinding halt. Often, this is done using amplification attacks (unsecured systems on the internet, which traffic gets amplified/redirect to the victim), which are extremely low barrier and accessible to most scripters or even large professional botnets. In the latter case, it can become a truly professional criminal matter including extortion. Adding insult to injury is that the default response of many (cloud or infrastructure) providers is to shut down the machine which gets under a large volume attack. This usually increases the impact and requiring manual intervention to resolve.
Some attacks can be protocol-based, which are more common in web applications rather than live games. These kinds of attacks are aimed to exhaust the resources of the server itself. These include syn floods with high packets per second that take place on layer 3/4 of OSI, or, more common in gaming, application-based attacks that take place on layer 7.
Application-based attacks specifically target your game server process with attempts to crash it, or have it run out of resources by spamming it with fake data, spoofed players just to see what sticks to finally make the server unavailable. This is also the most dangerous form of DDoS attack because if they find a vector that works on a port that has to be open for legitimate traffic, it can be duplicated across all of your instances and suddenly you’ve lost a whole region. So, I want to stress why hardening your application during development is important in the long term.
The traditional way to solve this is to use a scrubbing center or service. Many well-known names in the industry offer this. For gaming, however, this approach is suboptimal for several reasons:
We have many real-life examples for Security, but let’s take a well-known shooter where security truly became a cat and mouse game. Scripters had found a weakness and started attacking the server instances with the most players in the region. Their script caused these servers to crash. It then moved to the next server and crashed that as well. This went on until the game had no more active players in that region.
I don’t have to spell out what this did with the player experience, and how much time and resources had to be spent at that moment, to try and remedy the situation. Therefore, I fully recommend that you should, if you can, spend some time and costs on security during development so you will have a head start in the cat and mouse game. This is bound to happen in a live service game and even more so if you go for esports.
While developing your game, taking security as a priority before the release of your game saves you a lot of headaches and stress in the future. It could affect your player’s experience and therefore decrease in players right after release.