Why free game servers get abused, and how a host copes without punishing players

Every free hosting offer eventually meets the same visitor: someone who does not want a game server, but wants a computer and a network connection that somebody else pays for. This is not a story about one bad week at one company. It is a pattern as old as free hosting, and understanding it explains why free offers come with limits, why some disappear, and why a host sometimes has to say no to a request that looks innocent.

This is the general companion to our own account of two free servers turned into a proxy. That article tells what happened to us. This one explains the economics behind it. We will not describe how we detect abuse, because a detection rule published is a detection rule bypassed. We will describe the problem and the design choices that any honest host faces.

What people try to do with a free server

The goals are boring and commercial. A free server offers a processor, some bandwidth, an address that is not yours, and no bill. That is useful for:

• Cryptocurrency mining. Free compute turned into money. Security researchers documented large campaigns against free tiers of cloud and CI platforms. BleepingComputer's report on research by Sysdig describes one actor, nicknamed Purpleurchin, with 300 accounts on GitHub, 2,000 on Heroku and 900 on Buddy.works, rotating through mining containers and making over a million function calls a day.
• Relays and proxies. Selling or using other people's traffic through an address that is not yours: to scrape, to dodge blocks, to hide. The server is the exit door; the host's reputation pays for it when that address ends up on blocklists.
• Hosting things that need a clean address for a few days, such as phishing pages or command servers for malware, abandoned as soon as the address is flagged.
• Attacking others, with floods or scans, using the host's bandwidth.

None of these needs a game. The game server is just the form the free offer takes.

Why free in particular

The pattern is easy to see in the numbers of the economy. When a service costs nothing and asks for nothing, the cost of trying is zero, and zero cost scales. If one account in a hundred gets away for a few days with a miner, the abuser has made money and lost nothing. Heroku's abuse team put it this way at Black Hat USA 2020, quoted by The Register in its account of the free tier's end: "If you have a free service, a free trial, or any offering that has an angle to extract value, somebody is already trying to figure out a way to make money off of it." Heroku's general manager Bob Wise said his teams were spending "an extraordinary amount of effort" managing fraud and abuse of the free plans, and the free plans ended on 28 November 2022. Abuse was not the only factor in a decision like that, but it was a stated one.

For a small host the same arithmetic is harsher: abuse does not need to be common to be expensive. One server relaying traffic can get an address blocklisted, which hurts every honest customer on the network. One miner can slow the neighbours. And one incident costs a person's time, which is the scarcest resource of a small company.

Why blocking incoming traffic is not the answer

A common instinct is to say "just close the ports". That protects against attacks coming in. It does nothing about a program that starts the connection itself, from the inside, to a service on the Internet that relays things back. That is how tunnelling software works, and many tunnelling services are legitimate and widely used for development.

So the useful control is the one on the way out: what a free server may connect to, how much, and for how long. A game server needs to talk to its players and to a few services (updates, the account system of the game). It does not need to reach the entire Internet and the other machines of the host's own network. How a host draws that line is where design effort goes, and it is the part we will not detail.

What a host can do, at the level of principles

Without giving a recipe, the sound approaches share a few ideas.

Make abuse less rewarding rather than trying to prove intent. A small resource ceiling, an offer that ends if unused, and limits that suit a game and not a mining rig, turn the economics against the abuser without needing to read anyone's mind.

Assume the file lies. In our case a working lobby server with one class altered passed every visible check. The name of a file, the name of a server and what the console shows tell you little. The honest stance is that what a customer uploads is untrusted code, running in a box that cannot hurt others.

Isolate, then observe. Put each server in its own container with limits, so that a bad one affects only itself, and then watch resource and network behaviour for patterns that do not look like the game. Unusual constant load, unexpected binaries, connections to services a game never uses: signals worth a human look, never a verdict by themselves.

Keep a human in the loop. Automated rules produce false positives, and a false positive is a real player losing a server. The right answer to a doubtful case is to look at it and, if needed, ask.

Keep the evidence. Copy the files before deleting the server. We learned this one the hard way. Without a copy you cannot report it, learn from it, or tell the owner exactly what you saw.

Tell the people upstream. The hosting provider of the download site and the registrar of the domain can cut the infrastructure at the source, which does more than closing one account. Public repositories of malware samples such as MalwareBazaar exist so that analysts can share what they find.

The cost for honest users, and why it is not nothing

Every control has a cost on the legitimate side. A strict outbound policy can break a plugin that calls a web service. A strict signup can turn away a teenager without a payment card. A rule that stops a miner can also stop a heavy but honest mod. A host that says it has no false positives is not looking.

The trade-off we choose is simple to state: keep free offers limited to what a real player does, explain the limits, and let a person answer when someone is caught by a rule. If you are blocked and you did nothing wrong, tell us how you got there; it is the best way we have of fixing our rules.

What you can do as a customer

You do not run a hosting company, but you can avoid becoming the unwitting channel:

• Do not run a .jar, a plugin or a script you did not get from its author. Cracked plugins and "optimised server jars" shared in chats are a classic route for hidden payloads. Prefer the official project pages.
• Compare checksums when the author publishes them: sha256sum file.jar and compare the line with the project's.
• Read what a plugin asks for. A plugin that makes network connections for no visible reason deserves a question.
• Keep your own accounts safe. Use a different password on every service, and turn on two-factor authentication where it exists. A hijacked account is a free server for someone else.
• Look at your server's resource graphs now and then. A server that is busy when nobody is online is worth a look. The same advice for your own machines is in the first 30 minutes on a fresh Ubuntu server.

What this means for choosing a free server

A free offer is not worse because of its limits. It is worse when it hides them, or when it does not say what happens when someone breaks the rules. Read the terms, look for a sentence about abuse, and look for a way to talk to a person. A real free Minecraft server that stays on, and a straight answer about how it is protected, is what we aim for with the free offer on our home page. If you have questions about how it works, ask on the contact page or on Discord.