Game Server Security: The Things That Actually Get People

Game servers do not get compromised by sophisticated attacks. They get compromised because RCON was left on the default password, because a database was listening on a public interface, because a control panel was two years out of date, or because somebody installed a plugin from a forum post by a stranger.

None of that is exotic. All of it is preventable in an afternoon, and the order matters, the cheap fixes cover most of the risk.

What is happening to your machine

From the moment a server has a public IP, it receives automated scans. Continuously. Not because anyone has noticed you, but because the entire address space is scanned constantly by everything from research projects to botnets looking for open ports and default credentials.

This is the correct mental model: not "will someone attack me" but "everything is being tried on every machine all the time, and the question is whether anything works."

Which is good news, because it means you are defending against automation rather than attention. Closing the easy doors removes almost all of it.

The order to do things in

1. SSH keys, and disable password login.

The single highest-value change. Generate a key pair, put the public half on the server, and then in /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no

Restart SSH. Automated password guessing now has nothing to guess.

Test with a second session open before you disconnect the first: locking yourself out of your own machine is an unnecessary way to spend an evening. Linux basics covers the mechanics of getting in.

2. A firewall that denies by default.

A fresh machine usually permits everything. Every port anything listens on is reachable from the entire internet, including things you assumed were internal.

With ufw, which is the least painful option:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 27015
sudo ufw enable

Open the game port, the query port if it is different, and SSH. Nothing else, until you need it and know why.

The query port catches people out constantly — a server that plays fine but is invisible on every list is usually a game port that is open and a query port that is not. How game server queries work explains why they are separate, and port forwarding covers the home-connection version.

3. Change every default password, starting with RCON.

RCON is remote console access to your game server. Anyone with the password can change the map, kick everyone, alter settings, and on some games execute commands that reach further than that.

Default and weak RCON passwords are scanned for actively, and a compromised RCON is a compromised server. RCON explained covers the protocol; the security summary is: long random password, never the same as anything else, and firewall the port to your own address if you can.

The same applies to database passwords, panel passwords, and anything that shipped with a default.

4. Do not run the game server as root.

Its own unprivileged user, with access to its own directory and nothing else. If a plugin is malicious or an exploit lands, this is the difference between losing a game server and losing a machine.

Keeping a game server running covers doing this with systemd, where it is one line.

5. Keep the system patched.

apt update && apt upgrade, regularly, or enable unattended security updates. Unpatched software is the second most common route in after credentials.

The plugin problem

This is where game servers differ from ordinary machines, and it is the risk most owners underrate.

A plugin runs inside your server with the server's permissions. A malicious one can read your files, open a connection out, or give someone in-game powers they should not have. You are trusting the author completely.

Get plugins from the official resource site for your platform, not from a link in a Discord message or a forum attachment. SourceMod, AMX Mod X and Oxide all have official repositories, and things posted there have at least been seen by other people.

Be suspicious of paid plugins distributed as cracked copies. This is one of the most reliable ways to run somebody else's code on your machine, and it happens routinely on smaller servers trying to save money.

Prefer maintained things. A plugin whose last release was three years ago will break, and if it has a vulnerability nobody is fixing it. Updating without breaking things covers keeping the stack current.

Remove what you do not use. Every installed plugin is attack surface. The ones nobody has used since last year are pure risk.

Control panels

Pterodactyl, TCAdmin and similar are useful and they are also a web application exposed to the internet with administrative control over your machine.

Keep it updated. Panel vulnerabilities are published and then scanned for within days.

Put it behind HTTPS, with a real certificate.

Restrict it if you can, to your own IP, or behind a VPN. A panel that only you use does not need to be reachable by everyone.

Give sub-users the minimum. If you have staff with panel access, they should not all have the ability to delete the server.

DDoS, briefly

Different from the above; not a break-in, just volume. It is also the thing small servers worry about most and can do least about directly.

The realistic answers are provider-level: choose a host with DDoS mitigation included, and understand what their threshold is. Nothing you configure on the machine itself stops a saturated uplink. Stopping DDoS attacks on a small game server covers what is and is not possible, and dedicated versus VPS covers which hosts include what.

The one thing you control: do not publish your machine's real IP if you are behind any kind of proxy or filtering. It is frequently leaked through a status page, an old DNS record, or a plugin that phones home.

Backups are a security control

The category people forget. Every compromise, every deletion, every ransomware attempt has the same answer if you have a recent backup you have restored from.

Off the machine. A backup on the same server is not a backup against anything that reaches the server.

Tested. An untested backup is a hypothesis. Restore one, once, on purpose, and find out how long it takes.

Game server backups is the fuller treatment, and it is the single item on this page with the best ratio of effort to consequence.

Your staff are part of the threat model

Not because they are untrustworthy, but because access granted casually is access that persists indefinitely.

Grant the minimum. A moderator who needs to kick and ban does not need file access, database access, or the ability to delete the server. Most panels and most admin plugins support tiered permissions and most servers use one tier for everyone.

Separate accounts, never shared. A shared admin password means no accountability and no way to revoke one person's access. When someone leaves, you are changing a password everyone knew.

Remove access when people leave. The most commonly skipped step in any community. Someone steps down as staff, stays in the Discord, and keeps panel access for two years. This is not paranoia, the majority of "we got griefed by an admin" stories are about a former admin whose access was never revoked.

Log administrative actions. Whatever your admin plugin offers. SourceBans and its equivalents exist partly for this: an audit trail turns a dispute about who banned whom into a lookup. Moderating a community covers the human side.

Be careful who gets RCON. It is the highest-privilege thing most servers hand out, and it is frequently given to whoever asks.

When something has already happened

If you think a server has been compromised, the order matters.

Take it offline first. Not "investigate while it runs". A compromised server may be being used for something else entirely.

Do not restore over the top. Restoring a backup onto a machine that is still compromised gets you a compromised machine with older data. If the machine itself is suspect, rebuild it and restore onto the new one.

Rotate every credential. SSH keys, RCON, database, panel, and anything that shared a password with them.

Work out how, before you reopen. Reopening without knowing the route means it happens again next week. The log is where the answer usually is — reading game server logs covers finding it.

Tell your players something. If anything of theirs was exposed, they need to know. A community that finds out later from somebody else is a community you have lost, and the disclosure costs far less than the silence.

An afternoon's checklist

1. SSH keys on, password login off, root login off
2. Firewall denying by default, three ports open
3. RCON password changed to something long and random
4. Game server running as its own user
5. System packages updated, unattended security updates enabled
6. Plugins audited: sources known, unused ones removed
7. Panel updated and restricted
8. Backups off-machine, and one restore tested

That covers the overwhelming majority of how game servers actually get compromised. None of it is clever, and that is rather the point: the attacks are not clever either.