Sicherheits-Checkliste fuer Minecraft Server: 15 Punkte fuer 2026

Minecraft-Server-Sicherheit ist keine einmalige Sache. Es ist ein Prozess. Du kannst das beste Hosting haben, die besten Plugins, aber wenn du vergessen hast, RCON nach aussen zu schliessen oder ein Standardpasswort irgendwo gelassen hast, ist das alles egal.

Diese Checkliste umfasst 15 konkrete Punkte, die jeder Server-Admin 2026 erledigen sollte. Keine vagen Ratschlaege wie "sei vorsichtig", sondern konkrete Massnahmen mit Konfigurationsbeispielen und Befehlen. Geh jeden Punkt durch, hake ab was erledigt ist, und am Ende ist dein Server deutlich besser geschuetzt.

1. Server-Software aktuell halten

Klingt offensichtlich, aber veraltete Versionen sind die Ursache der meisten Kompromittierungen. Paper, Velocity, Plugins, Java selbst - alles muss aktuell sein.

Paper veroeffentlicht regelmaessig Sicherheitspatches. Als 2024 eine Schwachstelle in der Chunk-Datenverarbeitung entdeckt wurde, kam der Patch innerhalb von Stunden. Aber wenn du einen drei Monate alten Build nutzt, hilft dir dieser Patch nicht.

Was zu tun ist:

• Folge Papers Discord-Announcements
• Pruefe Plugin-Updates mindestens woechentlich
• Nutze Paper 1.21.x oder neuer
• JDK 21+ (LTS) fuer aktuelle Java-Sicherheitspatches

# Java-Version pruefen
java -version

# Neuestes Paper herunterladen (Beispiel)
wget https://api.papermc.io/v2/projects/paper/versions/1.21.4/builds/latest/downloads/paper-1.21.4-latest.jar

Aktualisiere nicht alles gleichzeitig auf dem Produktionsserver. Erst Testserver, dann Produktion. Richte einen separaten Ordner oder Docker-Container zum Testen ein. Update einspielen, 30 Minuten laufen lassen, Logs pruefen, sicherstellen dass keine Plugins crashen. Erst dann auf Produktion uebertragen.

Ein separater Punkt zu Plugins: Viele Admins installieren ein Plugin und vergessen es fuer Jahre. Dabei hat der Autor es laengst aufgegeben, und es gibt eine bekannte Schwachstelle. Geh einmal im Monat deine Plugin-Liste durch und entferne alles, was nicht genutzt wird. Weniger Plugins bedeutet eine kleinere Angriffsflaeche.

2. Firewall einrichten

Die Firewall ist deine erste Verteidigungslinie. Ohne sie kann jeder deine Ports scannen und offene Dienste finden.

Minimale iptables-Regeln fuer einen Minecraft-Server:

# Bestehende Verbindungen erlauben
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Loopback erlauben
iptables -A INPUT -i lo -j ACCEPT

# SSH (Port aendern, siehe Punkt 4)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Minecraft (Hauptport)
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT

# Alles andere ablehnen
iptables -A INPUT -j DROP

Wenn du ein Netzwerk mit mehreren Servern betreibst, sollten Backend-Ports nur vom Proxy erreichbar sein:

# Backend-Server nur localhost
iptables -A INPUT -p tcp --dport 30001:30010 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 30001:30010 -j DROP

Wir haben einen eigenen Artikel ueber iptables fuer Minecraft, wenn du tiefer einsteigen willst.

Regeln speichern, damit sie einen Neustart ueberleben:

apt install iptables-persistent
netfilter-persistent save

3. SSH-Keys statt Passwoerter

Passwoerter fuer SSH sind veraltet. Brute-Force-Angriffe auf SSH laufen staendig, und selbst ein starkes Passwort kann irgendwann geknackt werden. SSH-Keys beseitigen das Problem komplett.

# Auf deinem lokalen Rechner: Key generieren
ssh-keygen -t ed25519 -C "minecraft-admin"

# Auf den Server kopieren
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server

In /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
MaxAuthTries 3

sudo systemctl restart sshd

Wichtig: Stelle sicher, dass dein Key funktioniert, bevor du Passwoerter deaktivierst. Oeffne eine zweite SSH-Verbindung mit dem Key, pruefe ob alles klappt, und schliesse erst dann die erste. Sonst sperrst du dich aus und musst deinen Hosting-Anbieter bitten, die Einstellungen zurueckzusetzen.

Bonus: Wenn ihr mehrere Admins seid, sollte jeder seinen eigenen Key nutzen. Teilt nicht einen Key im ganzen Team. So seht ihr immer in den Logs, wer sich verbunden hat, und koennt den Zugang einer bestimmten Person widerrufen, ohne die Keys aller anderen zu aendern.

4. Standard-Ports aendern

Port 22 fuer SSH und 25565 fuer Minecraft kennt jeder Script-Kiddie. Port-Aenderungen stoppen keinen gezielten Angriff, eliminieren aber 90% des automatisierten Scannens.

Fuer SSH:

# /etc/ssh/sshd_config
Port 2847  # Beliebiger nicht-Standard-Port

Den Minecraft-Port zu aendern ist schwieriger, weil Spieler ihn kennen muessen. Aber den SSH-Port: immer aendern. Bei Netzwerken nutze nicht-Standard-Backend-Ports und blockiere sie mit der Firewall (siehe Punkt 2).

Fail2ban fuer SSH hinzufuegen:

apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2847
maxretry = 3
bantime = 3600
findtime = 600

Fail2ban sperrt automatisch IPs, die versuchen, deinen SSH-Zugang zu knacken.

5. Echte Server-IP verstecken

Wenn ein Angreifer deine echte IP kennt, kann er dich direkt treffen und jeden Schutz umgehen. Die IP zu verstecken ist entscheidend.

Wichtige Methoden:

• Nutze einen Proxy oder DDoS-Schutz (Spieler verbinden sich zur Schutz-IP, nicht zu deiner)
• Exponiere deine IP nicht in DNS-Eintraegen
• Nutze nicht dieselbe IP fuer Website und Gameserver
• Pruefe historische DNS-Eintraege (SecurityTrails, Shodan)

IPs leaken oft an unerwarteten Stellen: Plugin-Logs, Discord-Webhooks, Panel-URLs. Pruefe alles.

Eine weitere haeufige Leak-Quelle: DNS-Konfigurationsfehler. Vielleicht hast du frueher deine Domain direkt auf den Server gezeigt und spaeter einen Proxy hinzugefuegt. Aber der historische A-Record bleibt in Datenbanken wie SecurityTrails. Ein Angreifer prueft die DNS-Historie und findet deine echte IP in einer Minute. Vor dem Aktivieren eines Proxys am besten die Server-IP wechseln, wenn moeglich.

Wir haben dieses Thema ausfuehrlich in unserem Guide zum Verstecken der Minecraft-Server-IP behandelt.

6. Velocity statt BungeeCord

Wenn du ein Server-Netzwerk mit Proxy betreibst, ist BungeeCord ein ernstes Risiko. Sein IPForward-System sendet Spieler-UUIDs im Klartext. Mit direktem Zugang zu einem Backend-Server kann ein Angreifer sich als beliebiger Spieler einloggen.

Velocity Modern Forwarding nutzt HMAC-SHA256 zur Signierung. Nicht faelschbar.

# velocity.toml
player-info-forwarding-mode = "modern"

# paper-global.yml auf Backend-Servern
proxies:
  velocity:
    enabled: true
    online-mode: false
    secret: "dein-secret-aus-forwarding.secret"

Selbst wenn ein Backend-Port versehentlich offen ist, werden Verbindungen ohne gueltige HMAC-Signatur abgelehnt. Ein grundlegend anderes Sicherheitsniveau.

Vollstaendiger Vergleich und Migrationsleitfaden: Velocity vs BungeeCord.

7. server.properties absichern

Mehrere server.properties-Einstellungen werden uebersehen. Das sollten sie nicht.

# Query-Protokoll deaktivieren
enable-query=false

# RCON deaktivieren (oder nur localhost)
enable-rcon=false

# Wenn RCON benoetigt: starkes Passwort, nur localhost
rcon.password=LangesKomplexesPasswort2026!
rcon.port=25575

# Rate-Limiting
rate-limit=10

# Sichere Profile erzwingen
enforce-secure-profile=true

Hinter einem Proxy (Velocity) sollten Backends nur auf localhost lauschen:

server-ip=127.0.0.1
server-port=30001

Zu online-mode: Hinter einem Proxy auf Backends false setzen und auf dem Proxy true. Ohne Proxy: immer true.

Ein weiterer wichtiger Parameter ist max-players. Setze einen realistischen Wert. Wenn du normalerweise 50 Spieler hast, macht 1000 keinen Sinn. Das ist weniger Sicherheit als Ueberlastschutz. Wenn ein Botnet Bots flutet, bremst das Slot-Limit die Serverlast zumindest teilweise.

Die Einstellung prevent-proxy-connections lohnt sich zu aktivieren, wenn du keinen Proxy nutzt. Sie blockiert Verbindungen ueber VPNs und Proxys, was Angreifern das Leben schwerer macht. Aber wenn deine Spieler oft VPNs nutzen, verursacht das Probleme.

8. Berechtigungssystem einrichten

Minecrafts Standard-Berechtigungssystem ist minimal. Du brauchst LuckPerms.

Kernregeln:

• Nutze niemals ops.json. Verwende Berechtigungsgruppen
• Erstelle eine Hierarchie: default > vip > moderator > admin > owner
• Jede Gruppe bekommt nur die Berechtigungen, die sie braucht
• Vergib niemals * (alle Berechtigungen) an irgendeine Gruppe

/lp group default permission set minecraft.command.msg true
/lp group moderator permission set essentials.kick true
/lp group moderator permission set essentials.ban true
/lp group admin parent add moderator

Achte auf Plugin-Berechtigungen. Manche Plugins geben der Standardgruppe bei der Installation Zugriff auf gefaehrliche Befehle. Pruefe die plugin.yml jedes neuen Plugins.

WorldEdit, FAWE, Multiverse geben enorme Macht. Beschraenke ihre Berechtigungen auf Owner und vielleicht Senior Admin.

Haeufiger Fehler: Moderatoren /give oder /gamemode-Rechte geben. Ein kompromittierter Moderator-Account mit solchen Rechten zerstoert die Server-Wirtschaft in Minuten. Moderatoren brauchen Kick, Ban, Mute und Teleport. Alles andere ist ueberfluessig.

Pruefe Berechtigungen regelmaessig. Nutze /lp user <name> permission info um zu sehen, welche Berechtigungen ein bestimmter Spieler hat. Du wirst ueberrascht sein, wie viele unnoetige Berechtigungen sich angesammelt haben.

9. Anti-Cheat installieren

Cheater sind nicht nur ein Gameplay-Problem. Manche Cheats koennen deinen Server durch Paket-Exploits, Item-Duplikation oder Chunk-Ueberladung crashen.

Beliebte Optionen 2026:

• Grim - kostenlos, Open Source, gut bei Movement-Cheats
• Vulcan - kostenpflichtig, umfassender. Erkennt Combat, Movement, Player-Exploits
• Spartan - Mittelweg, gut fuer kleinere Server

Jeder Anti-Cheat ist besser als keiner. Aber konfiguriere ihn richtig: zu aggressive Einstellungen kicken legitime Spieler mit schlechter Verbindung.

Neben Standard-Anti-Cheat achte auf Crash-Schutz. Es gibt spezielle Clients (wie Meteor, Wurst), die ungueltige Pakete oder Buecher mit riesigen NBT-Daten senden und den Server oder einzelne Spieler crashen. Plugins wie Grim oder dedizierte Loesungen wie PacketLimiter helfen, solche Pakete zu filtern, bevor sie Schaden anrichten.

Richte Logging fuer verdaechtige Aktivitaeten ein. Wenn der Anti-Cheat einen Spieler kickt, sollten diese Informationen mit Details aufgezeichnet werden: welcher Check ausgeloest wurde, Koordinaten, Zeitpunkt. Das hilft, False Positives von echten Cheatern zu unterscheiden.

10. Automatische Backups

Backups sind kein "falls etwas passiert", sondern ein "wenn etwas passiert". Ohne Backups bedeutet eine geloeschte Welt oder ein Datenbank-Wipe das Ende deines Servers.

Minimum-Setup:

• Taegliche Backups von Welten, Configs und Datenbanken
• Speicherung auf einem separaten Server oder in der Cloud (nicht dieselbe Festplatte)
• Rotation: mindestens 7 taegliche + 4 woechentliche aufbewahren

#!/bin/bash
DATE=$(date +%Y-%m-%d_%H-%M)
BACKUP_DIR="/backups/minecraft"
SERVER_DIR="/opt/minecraft"

# Auto-Save deaktivieren
screen -S minecraft -p 0 -X stuff "save-off$(printf '\r')"
screen -S minecraft -p 0 -X stuff "save-all$(printf '\r')"
sleep 5

# Backup
tar -czf "$BACKUP_DIR/backup-$DATE.tar.gz" \
    "$SERVER_DIR/world" \
    "$SERVER_DIR/world_nether" \
    "$SERVER_DIR/world_the_end" \
    "$SERVER_DIR/plugins"

# Auto-Save wieder aktivieren
screen -S minecraft -p 0 -X stuff "save-on$(printf '\r')"

# Backups aelter als 14 Tage loeschen
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +14 -delete

In Cron eintragen:

# Taeglich um 4:00 Uhr
0 4 * * * /opt/scripts/backup.sh

Teste deine Backups. Ein Backup, das nicht wiederhergestellt werden kann, ist nutzlos. Versuche einmal im Monat, ein Backup auf einem Testserver wiederherzustellen.

Vergiss nicht, die Datenbank zu sichern, wenn du MySQL/MariaDB fuer Plugins nutzt (LuckPerms, Wirtschaft, Spielerdaten):

# MySQL-Datenbank-Backup
mysqldump -u minecraft -p minecraft_db > "$BACKUP_DIR/db-$DATE.sql"

Speichere Backups nicht auf demselben Server. Wenn der Server stirbt oder gehackt wird, sind die Backups darauf ebenfalls weg. Nutze rsync auf einen zweiten Server, S3-kompatiblen Speicher (Backblaze B2 ist guenstig) oder sogar normales FTP auf eine andere Maschine. Der Schluessel ist physische Trennung.

11. Server-Ressourcen ueberwachen

Wenn du deinen Server nicht ueberwachst, erfaehrst du erst von Problemen, wenn Spieler sich beschweren. Dann kann es schon zu spaet sein.

Was ueberwachen:

• CPU - Dauerlast ueber 80% ist ein Problem
• RAM - Speicherlecks durch Plugins
• Festplatte - Logs und Chunks koennen allen Platz fressen
• Netzwerk - ungewoehnlicher Traffic deutet auf Angriff hin
• TPS - unter 18 bedeutet spuerbares Lag

Fuer einfaches Monitoring:

# htop installieren
apt install htop

# Spark - In-Game TPS-Monitoring und Profiling
# Als Plugin installieren, /spark tps, /spark profiler nutzen

Fuer ernsthaftes Monitoring nutze Prometheus + Grafana. Paper unterstuetzt Metrik-Export ueber Spark. Richte Alerts fuer Anomalien ein: CPU-Spitzen, TPS-Einbrueche, Traffic-Anstiege.

Es ist auch nuetzlich, die Verbindungsanzahl zu ueberwachen. Wenn du normalerweise 20-50 Spieler hast und ploetzlich 500 Verbindungen siehst, ist das wahrscheinlich ein Bot-Angriff. Schnelle Pruefung:

# TCP-Verbindungen auf Minecraft-Port
ss -tn state established '( dport = :25565 )' | wc -l

# Einzigartige IPs
ss -tn state established '( dport = :25565 )' | awk '{print $5}' | cut -d: -f1 | sort -u | wc -l

Richte Alerts in Telegram oder Discord ein. Wenn TPS unter 15 faellt oder CPU ueber 90% geht, solltest du das sofort erfahren und nicht erst 30 Minuten spaeter aus Spieler-Beschwerden.

12. DDoS-Schutz

DDoS-Angriffe auf Minecraft-Server sind alltaeglich. Konkurrenten, veraeargerte Spieler, Script-Kiddies - die Motivation variiert. Ohne Schutz legt schon ein kleiner Angriff deinen Server lahm.

Wichtige Punkte:

• Hosting-Anbieter schuetzen meist vor volumetrischen Angriffen (L3/L4), aber nicht vor Application-Level (L7)
• Minecraft-spezifische Angriffe (Bot-Join-Flood, Null-Ping, Handshake-Flood) brauchen spezialisierte Filterung
• Ein einfacher TCPShield oder HAProxy hilft nicht gegen fortgeschrittene Angriffe

Spezialisierter Minecraft-Schutz (wie MineGuard) analysiert das Minecraft-Protokoll und blockt Bots auf Handshake-Ebene. Generische L3/L4-Filter koennen nicht zwischen Bot und Spieler unterscheiden, da beide identische TCP-Pakete verwenden.

Fuer die Grundlagen starte mit unserem Einsteiger-Guide zum Minecraft-Server-Schutz.

Separat erwaehnenswert: Java-Level-Exploits. Log4Shell (CVE-2021-44228) hat Tausende von Minecraft-Servern betroffen, als es auftauchte. Obwohl dieser spezifische Exploit laengst gepatcht ist, tauchen aehnliche JVM-Level-Schwachstellen immer wieder auf. DDoS-Schutz hilft nicht gegen Code-Exploits. Deshalb arbeiten Updates (Punkt 1) und DDoS-Schutz zusammen und decken verschiedene Bedrohungstypen ab.

13. Admin-Panels absichern

Pterodactyl, AMP, Multicraft - jeder Server hat irgendein Control Panel. Und oft ist es schlechter geschuetzt als der Server selbst.

Panel-Checkliste:

• Starkes Passwort + 2FA fuer alle Accounts
• HTTPS (nicht HTTP) - Let's Encrypt ist kostenlos
• Zugriff per IP einschraenken wenn moeglich
• Panel regelmaessig aktualisieren
• Eigene Subdomain (panel.example.com), nicht auf der Haupt-Server-IP

Fuer Pterodactyl konkret:

# SSL einrichten
apt install certbot python3-certbot-nginx
certbot --nginx -d panel.example.com

Wings (Pterodactyl-Daemon) muss ebenfalls geschuetzt werden. Port 8080 sollte nicht oeffentlich zugaenglich sein.

Wenn du SFTP fuer Datei-Uploads nutzt, stelle sicher, dass der SFTP-Benutzer nur Zugriff auf den Server-Ordner hat, nicht auf das gesamte Dateisystem. Pterodactyl erledigt das automatisch durch Docker-Isolation, aber bei normalem SFTP konfiguriere chroot.

Panel-Passwoerter muessen einzigartig sein. Verwende nicht dasselbe Passwort wie fuer SSH oder die Datenbank. Wenn ein Dienst kompromittiert wird, bleiben die anderen sicher.

14. Ungenutzte Features deaktivieren

Jeder offene Port und jeder aktivierte Dienst ist ein potenzieller Einstiegspunkt. Deaktiviere alles, was du nicht nutzt.

Haeufigste Uebeltaeter:

Query-Protokoll (Port 25565 UDP) - wird fuer Serverlisten genutzt. Wenn du nicht auf GameTracker o.ae. gelistet bist, deaktiviere es.

enable-query=false

RCON (Port 25575) - Remote-Konsole. Wenn du es nutzt, binde es an localhost. Wenn nicht, schalte es ab.

enable-rcon=false

JMX Monitoring - Java Management Extensions. Wenn aktiviert, gibt es vollen JVM-Zugriff. Stelle sicher, dass JMX-Ports geschlossen sind.

GeyserMC - wenn du es fuer Bedrock-Spieler nutzt, muss Port 19132 UDP offen sein. Wenn nicht, entferne das Plugin.

Einfache Regel: Wenn du nicht weisst, warum ein Port offen ist, schliesse ihn und schau, was kaputtgeht. Nichts kaputtgegangen? War nicht noetig.

Ein nuetzlicher Befehl zum Audit offener Ports:

# Alle lauschenden Ports anzeigen
ss -tlnp

# Oder sich selbst von aussen mit nmap scannen
nmap -sT -p 1-65535 your-server-ip

Scanne deinen Server einmal im Monat von aussen. Du wirst ueberrascht sein, wie viele Ports ohne dein Wissen offen sein koennen: Ein Plugin hat einen HTTP-Server auf Port 8123 gestartet, DynMap hat ein Web-Interface geoeffnet, MySQL lauscht auf 3306 nach aussen.

15. Incident-Response-Plan

Das ist der Punkt, den alle ueberspringen. Und dann um 3 Uhr nachts, wenn der Server down ist, wird hektisch gegoogelt "was tun".

Dein Plan sollte abdecken:

Bei DDoS-Angriff:

1. Schutz aktivieren / Schutz-Anbieter kontaktieren
2. Pruefen ob die echte IP geleakt ist (wenn ja: IP wechseln)
3. Spieler ueber Discord informieren
4. Angriff fuer Analyse protokollieren

Bei Einbruch:

1. Server sofort vom Netzwerk trennen
2. Alle Passwoerter aendern (SSH, Panels, RCON, Datenbank)
3. Logs pruefen - was wurde geaendert
4. Aus Backup wiederherstellen (siehe Punkt 10)
5. Schwachstelle beheben, die ausgenutzt wurde
6. Spieler benachrichtigen, falls Daten betroffen sein koennten

Bei Dupe/Exploit:

1. Server stoppen
2. Auf Backup vor dem Exploit zuruecksetzen
3. Plugin aktualisieren, das das Problem verursacht hat
4. Schaden an der Server-Wirtschaft bewerten

Schreibe diesen Plan auf und teile ihn mit allen Admins. Wenn ein Vorfall passiert, gibt es keine Zeit zum Nachdenken. Man muss dem Plan folgen.

Fuehre alle sechs Monate Uebungen durch. Tu so, als waere ein Vorfall passiert, und geh den Plan durch. Miss die Wiederherstellungszeit. Wenn die Wiederherstellung aus dem Backup 4 Stunden dauert, du aber 30 Minuten angenommen hast, ist es besser, das bei einer Uebung zu erfahren als bei einem echten Einbruch.

Bewahre den Plan an einem Ort auf, der auch erreichbar ist, wenn der Server down ist. Google Docs, Notion, ein ausgedrucktes Blatt Papier. Alles ausser dem Server selbst. Denn wenn der Server kompromittiert ist, kannst du den Plan, der auf diesem Server liegt, nicht lesen.

Halte diese Kontakte bereit:

• Hosting-Anbieter (Telefon, Ticket-System)
• DDoS-Schutz-Anbieter
• Senior-Administrator (Telefon)

Zusammenfassung

Schnelle Checklisten-Zusammenfassung:

1. Paper, Plugins, Java aktualisieren
2. iptables/ufw konfigurieren
3. SSH-Keys, keine Passwoerter
4. Nicht-Standard-Ports fuer SSH
5. Echte IP verstecken
6. Velocity statt BungeeCord
7. server.properties absichern
8. LuckPerms, kein OP
9. Anti-Cheat
10. Taegliche Backups
11. CPU/RAM/TPS ueberwachen
12. DDoS-Schutz
13. Panels absichern (2FA, HTTPS)
14. Query, RCON, Extras deaktivieren
15. Incident-Response-Plan

Du musst nicht alles an einem Tag erledigen. Starte mit den ersten fuenf Punkten - sie sind die kritischsten und dauern ein paar Stunden. Dann arbeite dich nach und nach durch den Rest.

Sicherheit ist ein Prozess, kein Zustand. Neue Schwachstellen tauchen staendig auf. Ueberarbeite diese Checkliste vierteljaehrlich und aktualisiere deine Konfigurationen.

Besser ein Wochenende in Sicherheit investieren, als Server und Spieler durch einen Angriff zu verlieren, der haette verhindert werden koennen.