Note: This journal entry was posted in 2015. While the material is technically timeless, it represents a significant departure from my modern writing habits. Please mind the style differences.
Terraria and Minecraft share a lot of similarities, but the unfortunate similarity shared between the two is the prolific variety of hacks and cheats that allow individuals to use clientside modding to their advantage. Unlike cheats in competitive games, however, these cheats often focus on world destruction or rampant grief that ruins hours of work. Leaving the server as a player to avoid the attack won’t do any good if the world is irreversibly damaged.
Most of the time, the cat and mouse game between the cheating and the anti-cheat communities reduces the threat potential to a spectrum, somewhere between undetectably low levels of cheating (exploiting TShock’s range checks, for instance) to demonstrably higher levels of exploiting (such as fuzzing TShock itself for vulnerabilities). Even if this weren’t the case, cheat authors would still constantly work-around ways to break in and tear apart servers as long as a pathway still exists to do so. Valve-Anti Cheat, the industry standard game anti-cheat mechanism, primarily relies on a balance between fear and trust to keep gamers happy and cheaters discouraged.
Instead of relying on technologies to detect and harbor cheaters, it is more productive to take to mitigate cheating by closing the entry pathway. Most of my experience comes from ShankShock, a six year old Minecraft community that’s seen its fair share of full scale attacks and more. Some of the ideas presented here require code to complete, but this is intentional: if every server has the same barriers to entry, then the system is worthless. My goal is to show how a single server, with active mitigation strategies, can achieve relatively grief-free existence simply by being a low-value target.
Advertise better, or less
Most attacks on Minecraft and Terraria are “acts of random hatred,” i.e. an attacker determines that they want to have some fun, so they pick a random server with a lot of players to show their skill (or lack thereof) to. They find servers the same way legitimate players do: advertisements on forums and server lists. If your community is comfortable with its player count, consider removing all advertisements entirely, or targeting your advertisements to certain niches. For example, an advertisement on the TShock forums targets primarily plugin developers and other people interested in modding – Terraria Online is a much more broad and diverse community. Trying to get on the “biggest” serverlist with a high player count attracts new players, but new attackers as well. Focus on the quality of your community over the quantity, and from there, develop an advertising strategy that fits your community well. ShankShock would, on average, get 10-20 new players a month, of which only 2-5 would stay. However, those 2-5 that did stay would end up becoming some of our most loyal and dedicated players and donors.
Raise the barrier to entry
Most attacks on servers are random, quick hits of adrenaline and entertainment for attackers. By this measure, increasing the barrier to entry once they do connect is essential to raising the effort required to attack. A new player who really and truly wants to join a server will be willing to go through some measure of rigor before playing, but many attackers would rather move on to a new, easier to grief server rather than continue to target a difficult one. This can be a double edged sword, as some too much rigor can offput real players as well. Finding balance here is key.
TShock already adds a barrier to entry common to servers – registration, however, this barrier is quite low, as every server has it. Adding a process such as email confirmation, or requiring a user to confirm their Steam, Facebook, and Twitter, instantaneously creates friction for attackers. One of the allures behind attacking a random server is anonymity; forcing a user to reveal their real name or confirming their identity reduces the disinhibition effect. These mitigation strategies aren’t perfect, but they do work. ShankShock was one of only a select few servers that required players to register; only after going to the website and entering an email address were players granted the permission to play. We didn’t need email confirmation; many attackers would disconnect upon being told to provide this information. The quality players did register, however, and were grateful for the attention to detail.
Build a honeypot
Some attackers will be willing to go through any measure of hoops to get access to your server. One of the next best defenses is a honeypotting strategy. A honeypot is effectively a sting operation; set some bait and hope that an attacker will be gravitated towards attacking the honeypot, rather than actual user created content. ShankShock employed this strategy with a variety of large monuments, and a purposefully designed spawnpoint that forced reading and following directions in order to escape. Breaking any blocks or placing any blocks immediately resulted in a permanent ban – a drastic course of action, but one that was effective in eliminating many attackers before they could do real damage.
Terraria has some specific problems in guaranteeing that a user is who they claim to be. If you require social media sign-in, you would presumably ban their social media accounts from being used in further registrations. This greatly improves the reliability of a honeypot, and again, requires attackers to re-register for other services to continue attacks.
Seeking recognition and attention is another driving factor for attackers. Envy and resentment are commonly linked with bullying – exactly what attackers are doing. Responding to bullies with defiance or lashing out is commonly regarded as the worst course of action to follow; it results in larger, more substantial attacks and threats.
When taking care of bad actors, communicate clearly and succinctly. When temporarily removing players, use language that conveys positive action rather than using negative punishment. For example, use “please refrain from breaking blocks in spawn or you may be detected as a griefer” rather than “stop griefing blocks at spawn.” When permanently removing players, your last words to them should only be “your IP address has been disabled” and optionally a reason why. Do not use vulgarity, or language that would elicit a larger, more destructive response.
Teach your administrators to respond to attacks with maturity, if an actor can be communicated with directly. If they’re watching chat (likely they are, to see your response), it is imperative that you do not confront them without thinking. Either do not communicate at all – simply ban and move on – or communicate with a level head, e.g. “please stop and discontinue your attack, or your account will be disabled.” Avoid more aggressive responses.
Ideally, players should respond in a similar fashion, but this can be harder to achieve at scale than simply the administrative team. Giving players a way to respond to threats in progress is a good start. Text message alerts or email alerts with an on-call admin staff can alert admins to threats as soon as they can be handled. Players have a course of action to take, and admins can respond promptly. I used
/ReportToAdmin and Pushover to achieve this in Minecraft.
Roll your own
Implementing a mitigation strategy that is custom tailored to your server is the best route to success. While the ideas presented here are what I have personally seen success with, they are hardly the only ways to mitigate threats in game servers. More importantly, if every server has the same barrier to entry, it becomes possible to script, predict, and penetrate prevention measures across a large swathe of servers. It will become a cat and mouse game, just with different tools. Think of what would work best in your situation, and plan and develop according to that.
Here are some more ideas for inspiration:
- Server promotion – Allow players to gain access to “less restricted” server environments after high amounts of playtime.
- Human vetting – Require whitelist applications and past experience for a new player to join.
- Lockdown – Allow admins to completely disable registering new players during attacks – instantly reducing the workload to only currently connected players.
- Do not use time based bans.
- Invite codes – Use invite codes on server lists and forum posts to track where new players originate from. Use this strategy to determine which ads should be removed.
- Pre-determined registration windows – Allow players to register only during certain hours. Players who wait for those times to register will be rewarded, whereas attackers will lose patience waiting for the window to open.
- Require a custom client – TShock reserved a network packet for communication between servers and custom clients that will not interfere with stock clients. Use this packet as a communication layer to require users to download a specific client to play. Attackers would then have to modify their hacked clients to connect.
- Require payment to register.
Many of these mitigation strategies can be implemented today, with very little code. Advertise less, and administrate your server effectively with a dedicated team that understands these values. Increase the barrier to entry, creating a safe environment that players become attached to; there is real value in being able to guarantee a grief free server. Finally, remember that your attackers are humans too. Just because they carry a hacked client does not mean that they do not have feelings. I have witnessed attacks cease simply because they become engaged in conversation instead. Remember that they’re usually seeking attention, or have envy for what you have. Offering something you have or talking to them can have a very real positive impact, in and outside the game world.
Be smart about how you run your server; spend less time banning and more time playing.
Discuss on the TShock Forum Thread.