If you wanted to go overboard, don’t even make the server accessible publicly. Distribute keys to a Wireguard network that is accessible publicly. Mandate your players obtain keys from you to play.

IMO the biggest attack vector there would be a Minecraft exploit like log4j, so the most important part to me would make sure the game server is properly sandboxed just in case. Start from a point of view of, the attacker breached Minecraft and has shell access to that user. What can they do from there? Ideally, nothing useful other than maybe running a crypto miner. Don’t reuse passwords obviously.

With systemd, I’d use the various Protect* directives like ProtectHome, ProtectSystem=full, or failing that, a container (Docker, Podman, LXC, manually, there’s options). Just a bare Alpine container with Java would be pretty ideal, as you can’t exploit sudo or some other SUID binaries if they don’t exist in the first place.

That said the WireGuard solution is ideal because it limits potential attackers to people you handed a key, so at least you’d know who breached you.

I’ve fogotten Minecraft servers online and really nothing happened whatsoever.

Whitelist and an autobackup mod

So the local machine doesn’t really need the firewall; it definitely doesn’t hurt, but your router should be covering this via port forwarding (ipv4) or just straight up firewall rules (ipv6).

You can basically go two routes to reasonable harden the system IMO. You can either just set up a user without administrative privileges and use something like a systemd system level service to start the server as that user and provide control over it from other users … OR … if you’re really paranoid, use a virtual machine and forward the port from the host machine into the VM.

A lot of what you’re doing is … fine stuff to do, but it’s not really going to help much (e.g. building system packages with hardening flags is good, but it only helps if those packages are actually part of the attack surface or rather what’s exposed to the remote users in someway).

Your biggest risk is going to be plugins that aren’t vetted doing bad things (and really only the VM or using the dedicated user account provides an insulation layer there – the VM really only adds protection against privilege escalation which is pretty hard to pull off on a patched system).

My advice for most people:

• Make a new user on the system to run each game you want to run
• Run the game using systemd and that user
• Use something like kopia + the root user’s crontab (easier than systemd timers, but systemd timers also work) to backup the files on disk

For Minecraft in particular, to properly back things up on a busy server you need to disable auto save, manually force save, do the backup and then enable auto save again after your backup. Kopia can issue commands to talk to the server to do that, but you need a plugin that can react to those commands running on the server (or possibly to use the server console via stdin). Realistically though, that’s overkill and you’ll be just fine backing up the files exactly as they are periodically.

Kopia in particular will do well here because of its deduplication of baked up data + chunking algorithm that breaks up files. That has saved me a crazy amount of storage vs other solutions I’ve tried. Kopia level compression isn’t needed because the Minecraft region files themselves are already highly compressed.

You should isolate it. Use Docker or Podman or any container solution to put the server in a container for isolation from the main system. Any external directory outside the container the server won’t write to should be in read only mode.

If the server is only for your friends. Stop exposing your network to the public and instead use VPNs.