RE:NODE

Minecraft11 min read

Minecraft server security checklist

A Minecraft server security checklist: online-mode and offline risks, whitelist, ops, RCON and query, plugin sources, Log4Shell, proxies and panel accounts.

0 readers

Most Minecraft servers that get "hacked" were not broken into. Somebody joined as an operator on an offline-mode server, used a plugin that ran console commands for anyone, guessed an RCON password, or installed a leaked premium plugin with a backdoor in it. The checklist that prevents nearly all of it is short: keep online-mode=true (or configure a proxy's forwarding correctly), whitelist private servers, give operator to almost nobody and use a permissions plugin instead, leave RCON and query off unless something needs them, install plugins only from their authors, keep the server software current, and protect the panel account that controls all of it. The rest of this post explains each item and how to check it.

Know what you are defending#

Different threats need different defences, and it helps to name them:

ThreatWhat it looks likeMain defence
ImpersonationSomeone joins as an admin's nameonline-mode, proxy forwarding
Random griefersStrangers arrive and destroy buildsWhitelist, claims, logging
Abuse of permissionsA moderator or plugin does too muchLuckPerms, no wildcard grants
Remote accessRCON or a web panel taken overOff by default, strong secrets
Malicious pluginsA backdoor in a jarTrusted sources only
Software vulnerabilitiesCrash or code exploitsCurrent Paper builds
Account takeoverYour panel or Mojang account stolen2FA, separate passwords

Grief protection in the gameplay sense - claims, rollbacks, anti-xray - is covered in grief protection and anti-cheat. This post is about the server itself.

online-mode, and the danger of offline mode#

server.properties
online-mode=trueenforce-secure-profile=true

online-mode=true makes the server check every player's login with Mojang's session servers. The name and UUID a player arrives with are then proven to belong to them.

With online-mode=false, the server takes the player's name on trust. Anyone can join as Notch, as your own name, or as any operator in ops.json, and the server will give them operator rights - offline-mode UUIDs are derived from the name, so the same name always maps to the same offline UUID. On a public offline-mode server, your op list is a list of names anyone can type.

There is exactly one legitimate reason to run online-mode=false: a backend server behind a proxy that does the authentication and forwards verified identities. That is only safe when forwarding is configured so the backend rejects connections that did not come through the proxy - Velocity's modern forwarding on Paper does this, BungeeCord's needs BungeeGuard or a firewall. BungeeCord vs Velocity explains why that difference is a security question.

"Cracked" servers that accept players without a paid account rely on offline mode plus an authentication plugin that makes players register a password in game. That moves your security from Microsoft's account system to a plugin and the passwords players pick, and every offline server is a target for exactly this impersonation. If you run one, understand that you have chosen the harder problem.

Whitelist and who can join#

For a private server, the whitelist is the strongest single setting you have:

server.properties
white-list=trueenforce-whitelist=true

The two keys do different jobs:

  • white-list=true refuses anyone not in whitelist.json.
  • enforce-whitelist=true kicks players who are online but not on the list when the whitelist is reloaded - so removing someone takes effect immediately rather than at their next login.

Use whitelist add <name> and whitelist remove <name> from the console rather than editing the JSON by hand; the server resolves names to UUIDs for you.

Why bother on a server nobody knows about: public scanners sweep the internet for Minecraft servers continuously and publish what they find, including version, player count and whether a whitelist is on. Groups use those lists to find open servers and grief them, sometimes within hours of a server first starting. Obscurity is not a defence. A friends-only server without a whitelist is a public server that has not been found yet.

For public servers, the whitelist is replaced by claims, logging and moderation - but the impersonation and permission items below matter even more. The whitelist and permissions guide covers the mechanics in full.

Operators and permissions#

Operator status is a blunt instrument. Level 4, the default for op, can run every command, including stop, op and anything a plugin registers for operators. Many plugins grant all their permissions to ops by default.

server.properties
op-permission-level=4function-permission-level=2

The checklist:

  1. Owners only. One or two people with operator. Everyone else - moderators, builders, helpers - gets a LuckPerms group with exactly the permissions their job needs.
  2. **No * permission.** Granting * to a group is operator under another name, including the parts you did not think about, such as plugins' permissions for running console commands.
  3. Watch for command-runner permissions. Plugins that run commands as console (/sudo-style commands, command signs, NPC click actions, menu plugins) are as powerful as operator in the wrong hands. Their permission nodes belong to owners only.
  4. Review `ops.json` occasionally. Names accumulate there. A former staff member's account that still has op is a risk if their Minecraft account is ever stolen.
  5. Log staff actions. CoreProtect records blocks and containers; most moderation plugins record punishments. Accountability deters more than it detects.

LuckPerms is the permissions plugin to use, and its guide shows a group ladder that does not need operator for anything below owner.

RCON, query and the status ping#

Three network services can be on beside the game port. Each should be off unless something uses it.

server.properties
enable-rcon=falsercon.port=25575rcon.password=broadcast-rcon-to-ops=trueenable-query=falsequery.port=25565enable-status=truehide-online-players=false

RCON gives full console access to anyone with the password, over a protocol that sends that password in plain text. If you do not have a tool that needs it, leave enable-rcon=false. If you do, use a long random password, do not expose the port beyond what needs it, and never reuse the password anywhere. The panel's console replaces RCON for most people. RCON safely covers the protocol and the rules in detail.

Query (enable-query) answers GameSpy-style queries with the server's player list, plugins and version over UDP. Server list sites use it. It reveals your plugin list - a map for anyone looking for a vulnerable plugin. Turn it on only if a listing site you use requires it.

Status (enable-status) is the normal server-list ping. Turning it off makes the server show as offline in clients' server lists, which annoys players more than it slows scanners. hide-online-players=true hides the player names in the hover list, which is a reasonable privacy choice for a small server.

Plugin sources and leaked plugins#

Every plugin you install runs with the full power of the server process: it can read every file, open network connections, run console commands and download more code. A plugin is not a feature, it is software you are trusting completely.

  • Download from the author's own page. Hangar (PaperMC), Modrinth, SpigotMC and the author's GitHub releases. Not re-uploads, not "mirror" sites, not files passed around Discord.
  • Never use leaked or "nulled" premium plugins. Paid plugins redistributed for free are the main delivery method for backdoored jars. Typical payloads give a specific player operator on command, run remote commands, steal files or spread to every other jar in the plugins folder. The plugin works normally, which is the point.
  • Prefer maintained plugins. An abandoned plugin will not be fixed when a vulnerability is found in it.
  • Watch what a plugin asks for. A cosmetics plugin that wants its own web server port or downloads updates from a random domain deserves a second look.
  • Keep a list. Know what is in your plugins folder and why. Anything you cannot explain should go.

If you suspect a compromised jar - an op appearing that nobody granted, unknown jars or files, console commands nobody typed - treat the whole server as compromised. A backdoor that spreads between jars means deleting one plugin is not enough. What to do when your server is hacked covers containment, and keeping a modded server clean has the habits that prevent it.

Keep the server software current#

Minecraft has had serious vulnerabilities, the most famous being Log4Shell (CVE-2021-44228) in December 2021: a chat message could make an unpatched server or client download and run code. Vanilla 1.18.1 and later include the fix, and older versions needed a JVM flag or patched config to be safe. Servers still running unpatched old versions are still exploitable.

Beyond headline vulnerabilities, Paper's builds regularly fix crash exploits - malformed packets, oversized books or items, chunk-ban tricks - that let a single player knock a server offline or make chunks unloadable. These are fixed quietly and continuously.

  1. Run a current build of Paper for the Minecraft version you use.
  2. Update builds regularly, not just versions. A build update within the same Minecraft version is low risk.
  3. If you must run an old version for compatibility, know that you are accepting unpatched bugs and limit who can join.

Minecraft version upgrades covers upgrading without breaking the world.

Network protection and what it does not cover#

Some attacks target the network rather than the game. Floods of traffic at your port can make the server unreachable no matter how it is configured, and connection floods - thousands of fake logins - can tie up the server's login handling.

Paper and Velocity have built-in rate limits on connections and logins, and rate-limit in server.properties caps packets per second per player (0 disables). On RE:NODE there is upstream filtering that drops obvious volumetric floods, plus reflection and malformed traffic; attacks that look like real players are not filtered, and no host can promise otherwise. What we do about attacks is the honest version of that sentence.

Protect your own address too. The server's IP is public by design, but your home IP is not: do not run tools or plugins that reveal player IPs to other players, and be careful what staff share in screenshots of the console, which shows every joining player's IP address.

Protect the panel and the accounts around it#

The server is only as secure as the accounts that control it:

  • Your hosting panel account. It can stop the server, read every file, download every backup. Use a unique password and two-factor authentication. On RE:NODE, 2FA uses codes from any authenticator app plus single-use recovery codes - keep the recovery codes somewhere offline, because an account that has lost both cannot be recovered. Two-factor on your panel account walks through it.
  • Staff access. Give staff subusers with only what they need - console only, files only, no billing - rather than your login. RE:NODE records a per-server activity log, so you can see who did what. Subusers and least privilege covers the design.
  • SFTP credentials. They are per server; do not paste them in Discord.
  • Your Minecraft account. An owner whose Microsoft account is stolen hands the attacker operator on every server they own. Secure it with 2FA as well.
  • Integrations. Discord bots with console channels, web panels, store plugins - each is another way in. A DiscordSRV console channel is console access for everyone who can post in it.

The checklist#

Copy this, and go through it before launch and again every few months:

code
[ ] online-mode=true on every server players reach directly[ ] proxy backends reject direct connections (tested from outside)[ ] white-list=true and enforce-whitelist=true on private servers[ ] ops.json holds only owners[ ] no group has the * permission[ ] command-running plugin permissions held by owners only[ ] enable-rcon=false, or a long unique password and limited exposure[ ] enable-query=false unless a listing site needs it[ ] every plugin downloaded from its author, none leaked[ ] Paper on a current build[ ] panel account with 2FA and recovery codes stored offline[ ] staff on subusers or roles, not shared logins[ ] backups scheduled, and one restore actually tested

The last line is not decoration. Every item above reduces the chance of a bad day; a working backup is what ends one. On RE:NODE, backup slots come with every Minecraft plan, stored off the machine they protect, and can be locked so rotation does not delete the one taken before an incident. Backups that actually restore explains why the test matters.

FAQ#

Is an offline-mode Minecraft server safe?

Not when players can reach it directly. Without online mode, anyone can join with any name, including operators' names. The only safe use is a backend behind a correctly configured proxy that rejects direct connections.

Do I need a whitelist if my server address is secret?

Yes. Scanners find Minecraft servers across the whole internet within hours and share the lists. An unlisted server is not a hidden one. A whitelist is the only thing that keeps a private server private.

Should I give my moderators operator?

No. Give them a permissions group with the commands they need. Operator grants everything, including what plugins give to ops by default, and turns a stolen moderator account into a stolen server.

Is it safe to use free copies of paid plugins?

No. Leaked premium plugins are the most common source of backdoors on Minecraft servers. The plugin will work, and so will the hidden code that gives someone else control.

How do I know if my server has been compromised?

Unexplained operators, commands in the log nobody typed, new or modified jars in plugins, unknown files or scheduled tasks. Treat any of these as a compromise of the whole server, restore from a known-good backup, and change every credential.


Comments

Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.

0/2000