Minecraft-Server in Docker absichern

Schutzbereiche getrennt betrachten

Der öffentliche Minecraft-Port exponiert die Anwendung. Plugins und Mods führen darin Code aus. Docker und SSH verwalten den Host darunter. Daraus entstehen fünf getrennte Grenzen:

1. Spielerauthentifizierung und Whitelist
2. Minecraft-/RCON-Netzwerk
3. Plugin-/Mod-Lieferkette
4. Containerrechte und Host-Mounts
5. Hostadministration, Updates und Recovery

Kein einzelner Compose-Schalter deckt alles ab.

Gehärtete Compose-Grundlage

Das Beispiel setzt voraus, dass ./data UID/GID 1000:1000 gehört:

services:
  mc:
    image: itzg/minecraft-server:java25
    restart: unless-stopped
    user: "1000:1000"
    read_only: true
    tmpfs:
      - /tmp:size=256m
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    ports:
      - "25565:25565"
    environment:
      EULA: "TRUE"
      TYPE: PAPER
      VERSION: "26.1.2"
      ONLINE_MODE: "TRUE"
      ENABLE_WHITELIST: "TRUE"
      RCON_PASSWORD_FILE: /run/secrets/rcon_password
    volumes:
      - ./data:/data
    secrets:
      - rcon_password

secrets:
  rcon_password:
    file: ./rcon_password.secret

Erzeuge ein langes zufälliges Passwort in rcon_password.secret, beschränke die Host-Rechte und schließe die Datei aus Git aus. Compose bindet sie schreibgeschützt unter /run/secrets/rcon_password ein.

Nur /data bleibt dauerhaft beschreibbar. Das Root-Dateisystem ist read-only, /tmp flüchtig. Der feste Non-Root-Nutzer erlaubt, alle Linux-Capabilities zu entfernen.

Kontrollen verifizieren

Prüfe die vollständig aufgelöste Compose-Datei. Docker behandelt auch Includes und Bind Mounts als vertrauenswürdige Host-Anweisungen:

docker compose config
docker compose up -d mc
docker compose exec mc id
docker port "$(docker compose ps -q mc)"
docker inspect "$(docker compose ps -q mc)" --format 'readonly={{.HostConfig.ReadonlyRootfs}} user={{json .Config.User}} caps={{json .HostConfig.CapDrop}} security={{json .HostConfig.SecurityOpt}}'

Erwartet werden UID/GID 1000, ausschließlich Port 25565, kein Host-Mapping für RCON, read-only Root-FS, entfernte Capabilities und no-new-privileges.

docker compose exec mc rcon-cli version
docker compose exec mc rcon-cli whitelist add dein-minecraft-name
docker compose exec mc rcon-cli whitelist list
docker compose exec mc rcon-cli save-all flush

Ersetze dein-minecraft-name vor dem zweiten Befehl durch den echten Benutzernamen.

Authentifizierung aktiviert lassen

Bei direkter Veröffentlichung muss ONLINE_MODE: "TRUE" bleiben. Die Whitelist reduziert berechtigte Spieler, ersetzt aber nicht die Mojang-/Microsoft-Authentifizierung.

Offline-Mode ist nur hinter einem korrekt gesicherten Proxy vertretbar, der authentifiziert und jeden direkten Backend-Zugriff verhindert.

Nur notwendige Ports veröffentlichen

Ein normaler Java-Server benötigt TCP 25565. Veröffentliche nicht vorsorglich:

• RCON 25575
• JMX 7091
• beliebige Query-/Plugin-Ports
• den Docker-Socket

Adminbefehle laufen über docker compose exec mc rcon-cli .... Begrenze Host- und Hetzner-Cloud-Firewall wie im Port-25565-Guide.

Plugins, Mods und Compose als Code behandeln

Paper warnt, dass Plugins innerhalb des Prozesses uneingeschränkten Zugriff besitzen. Installiere nur vertrauenswürdige, möglichst geprüfte Releases, pinne Versionen und führe ein Inventar.

Bei fremden Compose-Dateien sind besonders kritisch:

• privileged: true
• network_mode: host oder pid: host
• cap_add, besonders SYS_ADMIN
• Geräte und breite Host-Mounts
• /var/run/docker.sock
• ungeprüfte entfernte include-/extends-Inhalte

Der Paper-Plugin-Guide beschreibt einen kontrollierten Lebenszyklus.

Host und Recovery absichern

Containerhärtung repariert kein offenes SSH-Konto und keinen ungepatchten Docker-Daemon:

• SSH-Schlüssel und administrativen Non-Root-Nutzer verwenden
• Sicherheitsupdates für OS und Docker installieren
• Mitgliedschaft in der docker-Gruppe streng begrenzen
• Host-Firewall eng halten
• Backups außerhalb des Hosts speichern und Restores testen
• Secrets aus Git, Shell-History und Screenshots fernhalten

Backups auf demselben kompromittierten Host können mitgelöscht werden. Nutze automatische Backups mit zweiter Fehlerdomäne.

Kontrolliert aktualisieren

Ziehe Image-Sicherheitsfixes regelmäßig, ohne gleichzeitig unbeaufsichtigt Minecraft zu wechseln. Pinne VERSION, sichere den Stand und folge dem Update- und Rollback-Runbook.

Docker Rootless kann Daemon- und Runtime-Rechte reduzieren, ist aber eine Hostmigration. Befolge die offiziellen Voraussetzungen und teste Ports, Bind-Mount-Rechte, cgroups und Autostart neu.

Fehlerbehebung

Nächste Schritte

• Internetzugriff mit dem Hetzner-/Linux-Firewall-Guide kontrollieren.
• Recovery über automatische Docker-Backups vorbereiten.
• Instabilität mit dem Restart-Loop-Runbook untersuchen.