Paper und Spigot Sicherheitseinstellungen: Was aktivieren und was deaktivieren

Ein Minecraft-Server hat Dutzende von Konfigurationsdateien. Und in jeder von ihnen gibt es Einstellungen, die die Sicherheit direkt beeinflussen. Das Problem: die meisten Admins lassen die Standardwerte stehen. Und Standardwerte sind auf Kompatibilitaet ausgelegt, nicht auf Schutz.

In diesem Artikel gehen wir jede Datei einzeln durch. Fuer jede Einstellung erklaere ich nicht nur "stell diesen Wert ein", sondern warum. Das Verstaendnis der Gruende ist wichtiger als das Kopieren fremder Konfigurationen.

server.properties: das Fundament

Diese Datei wird beim Serverstart als erste gelesen. Sie steuert das grundlegende Verhalten von vanilla Minecraft, und hier befinden sich die kritischsten Schalter.

online-mode

online-mode=true

Dies ist die wichtigste Sicherheitseinstellung auf dem gesamten Server. Punkt. Wenn online-mode=true ist, verifiziert der Server jeden verbindenden Spieler ueber die Authentifizierungsserver von Mojang. Das garantiert, dass der Spieler tatsaechlich den Account besitzt, mit dem er sich anmeldet.

Wenn online-mode=false ist, kann jeder unter jedem Namen beitreten. Unter dem Admin-Namen einloggen? Kein Problem. Den Namen eines anderen Spielers nehmen und seine Sachen stehlen? Einfach. Alles was noetig ist, ist den Namen im Launcher zu aendern.

Die einzige Ausnahme: wenn der Server hinter einem Proxy laeuft (Velocity, BungeeCord). In diesem Fall ist online-mode=false auf Backend-Servern akzeptabel, weil der Proxy die Authentifizierung uebernimmt. Dann braucht man aber zwingend korrekt konfiguriertes Forwarding (dazu weiter unten mehr).

Wenn du einen Standalone-Server ohne Proxy betreibst, muss online-mode auf true stehen. Ohne Ausnahme.

enable-query

enable-query=false

Das Query-Protokoll erlaubt externen Anwendungen, Informationen ueber deinen Server abzufragen: Spielerliste, Version, Beschreibung, installierte Plugins. Klingt harmlos, erzeugt aber in der Praxis zwei Angriffsvektoren.

Erstens: Informationsleck. Ein Angreifer erhaelt deine Plugin-Liste mit Versionen. Wenn er weiss, dass du AuthMe 5.6.0 verwendest, kann er nach bekannten Schwachstellen fuer diese Version suchen. Die Online-Spielerliste hilft dabei, die Serveraktivitaet zu bestimmen und den besten Zeitpunkt fuer einen Angriff zu waehlen.

Zweitens: Query laeuft ueber UDP. Ein UDP-Port, der beliebige Anfragen annimmt, ist ein fertiger Amplifikationsvektor. Angreifer koennen deinen Query-Port fuer reflektierte Angriffe gegen andere Server nutzen.

Schalte Query ab. Fuer Monitoring gibt es bessere Loesungen: Plugins mit APIs, RCON (mit Einschraenkungen), externe Monitoring-Dienste.

enable-rcon

enable-rcon=false
rcon.port=25575
rcon.password=

RCON (Remote Console) gibt vollen Zugriff auf die Serverkonsole ueber das Netzwerk. Das ist wie SSH, nur fuer Minecraft. Und das Problem ist genau dasselbe: wenn jemand RCON-Zugang bekommt, hat er die volle Kontrolle ueber den Server.

Wenn du RCON nicht brauchst, schalte es ab. Wenn du es brauchst (fuer Automatisierung, Control Panels), dann:

1. Verwende ein starkes Passwort, mindestens 20 Zeichen
2. Beschraenke den Zugriff per Firewall auf localhost oder die Panel-IP
3. Oeffne den RCON-Port niemals nach aussen

# RCON nur von localhost erlauben
iptables -A INPUT -p tcp --dport 25575 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 25575 -j DROP

network-compression-threshold

network-compression-threshold=256

Dieser Parameter bestimmt die minimale Paketgroesse (in Bytes), ab der komprimiert wird. Der Standardwert 256 bedeutet, dass Pakete groesser als 256 Bytes vor dem Senden komprimiert werden.

Was hat das mit Sicherheit zu tun? Komprimierung reduziert den Traffic, erhoeht aber die CPU-Last. Ein Angreifer, der viele kleine Pakete sendet, kann den Server dazu zwingen, Ressourcen fuer unnoetige Komprimierung/Dekomprimierung zu verschwenden.

256 ist die optimale Balance. Fuer Server hinter einem Proxy kann man -1 setzen, weil der Proxy die Komprimierung uebernimmt. Fuer Standalone-Server bei 256 bleiben.

rate-limit

rate-limit=15

Begrenzt die Anzahl der Pakete pro Sekunde von einer einzelnen Verbindung. Der Standardwert 0 bedeutet kein Limit. Das ist schlecht. Ein einzelner Client mit modifiziertem Launcher kann Tausende Pakete pro Sekunde senden und den Server ueberlasten.

Ein Wert von 15 bedeutet, dass der Server eine Verbindung kickt, die mehr als 15 Pakete pro Tick (50ms) sendet. Das reicht fuer normales Gameplay, schneidet aber aggressiven Spam ab.

prevent-proxy-connections

prevent-proxy-connections=false

Dieser Parameter laesst den Server pruefen, ob sich ein Spieler ueber einen Proxy oder VPN verbindet, wobei die Mojang API verwendet wird. Wenn die Pruefung zeigt, dass die IP des Spielers von der bei der Authentifizierung verwendeten IP abweicht, wird die Verbindung abgelehnt.

Auf dem Papier klingt das nuetzlich. In der Praxis verursacht es mehrere Probleme. Erstens fuegt es Latenz bei Verbindungen hinzu, weil der Server eine Anfrage an die Mojang API sendet. Zweitens kann es legitime Spieler blockieren, die VPNs fuer Sicherheit oder aufgrund von ISP-Einschraenkungen verwenden.

Fuer Standalone-Server kann man prevent-proxy-connections=true als zusaetzliche Schutzschicht aktivieren. Aber wenn du bereits ein VPN-Blocking-Plugin verwendest (oder einen Dienst wie MineGuard, der Bots und Proxies auf Netzwerkebene filtert), bringt diese Einstellung wenig.

Hinter einem Proxy (Velocity/BungeeCord) diese Einstellung auf false lassen, sonst werden alle Verbindungen abgelehnt.

max-players

max-players=100

Das erscheint als Kapazitaetseinstellung, nicht als Sicherheitseinstellung. Aber denk mal nach: wenn auf deinem Server normalerweise 30 Spieler sind, warum das Limit bei 1000 lassen? Bei einem Bot-Angriff werden alle 1000 Slots mit Bots belegt, und jeder einzelne erzeugt Serverlast.

Setze max-players etwas ueber deinen tatsaechlichen Spielerzahlen. Bei normalerweise 30 Spielern setze 50-70. Das begrenzt das Ausmass von Bot-Angriffen.

spigot.yml: die naechste Schicht

Spigot fuegt seine eigene Einstellungsebene ueber vanilla hinzu. Viele betreffen die Performance, aber einige sind kritisch fuer die Sicherheit.

connection-throttle

settings:
  connection-throttle: 4000

Definiert das Mindestintervall (in Millisekunden) zwischen Verbindungen von derselben IP-Adresse. Ein Wert von 4000 bedeutet, dass eine IP maximal einmal alle 4 Sekunden verbinden kann.

Warum das wichtig ist: bei einem Bot-Angriff kommen Hunderte Verbindungen pro Sekunde von jeder IP. Connection Throttle blockiert wiederholte Versuche und reduziert die Last auf den Authentifizierungsprozess.

Wichtiger Hinweis: wenn der Server hinter einem Proxy steht, kommen alle Verbindungen von einer IP (der Proxy-IP). In diesem Fall muss connection-throttle deaktiviert werden (auf -1 setzen), sonst werden legitime Spieler blockiert.

# Hinter einem Proxy:
settings:
  connection-throttle: -1

bungeecord

settings:
  bungeecord: false

Dieses Flag aktiviert die IP-Forwarding-Unterstuetzung von BungeeCord. Wenn bungeecord: true, vertraut der Server den Spieler-IP-Daten, die der Proxy ueber ein spezielles Feld im Handshake-Paket sendet.

Das Problem: wenn du bungeecord: true auf einem Server aktivierst, der nicht hinter einem Proxy steht, kann jeder seine IP faelschen. Das ist keine theoretische Schwachstelle. Es gibt fertige Tools fuer IP-Spoofing ueber BungeeCord-Forwarding.

Einfache Regel: bungeecord: true nur wenn der Server tatsaechlich hinter BungeeCord steht UND der Backend-Port per Firewall gegen externe Verbindungen geschuetzt ist. In allen anderen Faellen false.

Noch besser: verwende Velocity mit Modern Forwarding anstelle von BungeeCord.

moved-wrongly-threshold und moved-too-quickly-multiplier

settings:
  moved-wrongly-threshold: 0.0625
  moved-too-quickly-multiplier: 10.0

Diese Parameter steuern die serverseitigen Anti-Cheat-Bewegungspruefungen. moved-wrongly-threshold definiert die erlaubte Abweichung der Spielerposition von der erwarteten. moved-too-quickly-multiplier setzt den Multiplikator fuer die maximale Bewegungsgeschwindigkeit.

Standardwerte sind fuer die meisten Server ausreichend. Fuer ernsthaften Cheat-Schutz verwende ein dediziertes Anti-Cheat-Plugin (Grim, Vulcan), anstatt dich auf die eingebauten Pruefungen zu verlassen.

log-filter und player-shuffle

settings:
  log-filter:
    - "Moved too quickly!"
    - "moved wrongly!"

Das Logging von "Moved too quickly" und "moved wrongly" ist fuer die Diagnose nuetzlich, aber bei einem Bot-Angriff koennen diese Nachrichten den Log mit Tausenden Zeilen pro Sekunde fluten und IO-Last erzeugen. Wenn du packet-limiter und Anti-Cheat konfiguriert hast, kannst du diese Nachrichten in den Log-Filter aufnehmen.

timeout-time und restart-on-crash

settings:
  timeout-time: 30
  restart-on-crash: true

timeout-time bestimmt, nach wie vielen Sekunden der Server eine haengende Verbindung als tot betrachtet. Der Standard von 60 Sekunden ist zu viel. 30 Sekunden reichen fuer normales Gameplay, aber tote Verbindungen werden schneller geschlossen.

restart-on-crash: true startet den Server bei einem Absturz automatisch neu. Kritisch wichtig fuer den Schutz vor Crash-Exploits: wenn ein Angreifer einen Weg findet, den Server zum Absturz zu bringen, kommt er wenigstens automatisch wieder hoch.

paper-global.yml: Papers Werkzeuge

Paper fuegt eine grosse Anzahl von Sicherheitseinstellungen hinzu, die Spigot nicht hat. Das ist einer der Hauptgruende, Paper statt reines Spigot zu verwenden.

packet-limiter

packet-limiter:
  kick-message: '<red><lang:disconnect.exceeded_packet_rate>'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0

Das ist Papers eingebautes Anti-Crash-System. Der Packet-Limiter verfolgt die Anzahl der Pakete jedes Typs innerhalb eines Zeitintervalls und kickt den Client, wenn das Limit ueberschritten wird.

Standardkonfiguration: maximal 500 Pakete beliebigen Typs pro 7 Sekunden. Fuer ServerboundCommandSuggestionPacket (Tab-Vervollstaendigung) ist das Limit strenger: 15 Pakete pro Sekunde. Warum? Weil Tab-Vervollstaendigung serverseitige Verarbeitung ausloest und das Spammen dieser Pakete erhebliche Last erzeugen kann.

Fuer zusaetzlichen Schutz koennen Limits fuer andere "teure" Pakete hinzugefuegt werden:

packet-limiter:
  kick-message: '<red><lang:disconnect.exceeded_packet_rate>'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0
    ServerboundContainerClickPacket:
      interval: 1.0
      max-packet-rate: 25.0
    ServerboundPlaceRecipePacket:
      interval: 1.0
      max-packet-rate: 5.0

Setze die Limits nicht zu niedrig. Wenn max-packet-rate fuer all auf 100 steht, werden normale Spieler bei aktivem Gameplay gekickt (Truhen oeffnen, Handeln, PvP). 500 pro 7 Sekunden sind ungefaehr 71 Pakete pro Sekunde, was fuer normales Spielen ausreicht.

velocity-support

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: 'komplexer-geheimer-schluessel-aus-velocity'

Wenn du Velocity als Proxy verwendest, ersetzt dieser Abschnitt das veraltete bungeecord: true in spigot.yml. Modern Forwarding in Velocity verwendet HMAC zur Signierung der Spielerdaten, was IP-Spoofing unmoeglich macht (im Gegensatz zu BungeeCord).

Das secret muss mit dem forwarding-secret auf der Velocity-Seite uebereinstimmen. Verwende einen langen, zufaelligen Schluessel.

Aktiviere velocity-support und bungeecord nicht gleichzeitig. Das ergibt keinen Sinn und kann Konflikte erzeugen.

Logging

logging:
  log-player-ip-addresses: false

Standardmaessig protokolliert Paper die IP-Adressen der Spieler. Wenn du in einer DSGVO-Jurisdiktion bist (Europa) oder einfach die Speicherung personenbezogener Daten minimieren willst, schalte das ab. IP-Adressen in Logs sind ein Datenleck, wenn der Server kompromittiert wird.

paper-world-defaults.yml: Weltschutz

Diese Einstellungen gelten standardmaessig fuer alle Welten. Viele von ihnen verhindern bestimmte Exploits.

max-entity-collisions

collisions:
  max-entity-collisions: 2

Begrenzt die maximale Anzahl von Entity-Kollisionen pro Tick. Der Standardwert 8 erlaubt das Erstellen von Entity-"Crushern", die massive Kollisionsberechnungen erzeugen und die TPS in den Keller ziehen.

Ein Wert von 2 reduziert die Entity-Cramming-Last drastisch. Das schuetzt direkt vor einem bestimmten Typ von Crash-Exploits: Angreifer druecken Hunderte Mobs in einen Block, und der Server verbraucht alle Ressourcen fuer Kollisionsberechnungen.

max-auto-save-chunks-per-tick

chunks:
  max-auto-save-chunks-per-tick: 8

Bestimmt, wie viele Chunks der Server pro Tick auf die Festplatte speichert. Hoehere Werte bedeuten schnelleres Speichern, aber mehr Lag beim Auto-Save.

Aus Sicherheitsperspektive: wenn ein Angreifer viele Chunks modifiziert (TNT-Explosionen, Lava-Casts), bedeutet ein hoher Wert, dass der Server versucht, alle beschaedigten Chunks gleichzeitig zu speichern, was einen IO-Sturm erzeugt. Ein Wert von 8 gewaehrleistet fluessiges Speichern ohne spuerbare TPS-Einbrueche.

entity-per-chunk-save-limit

entity-per-chunk-save-limit:
  experience_orb: 16
  snowball: 8
  arrow: 16
  item: 32

Begrenzt die Anzahl der Entities eines bestimmten Typs, die pro Chunk gespeichert werden. Ohne dieses Limit kann ein Angreifer einen Chunk mit Tausenden Entities erstellen, der beim Laden ewig laggt.

Diese Limits beeintraechtigen normales Gameplay nicht, schuetzen aber vor gezielter Sabotage.

fix-entity-position-desync

fixes:
  fix-entity-position-desync: true

Behebt die Desynchronisation von Entity-Positionen zwischen Server und Client. Ohne diesen Fix koennen einige Cheats den Desync ausnutzen, um unsichtbare Entities zu erstellen oder sich durch Waende zu bewegen. Lass dies aktiviert.

anti-xray

anticheat:
  anti-xray:
    enabled: true
    engine-mode: 2

Anti-Xray ist keine Sicherheitseinstellung im klassischen Sinne, verhindert aber die Ressourcenausbeutung durch X-Ray-Cheats. engine-mode: 2 ersetzt versteckte Erze durch gefaelschte Bloecke, was etwas Last erzeugt, aber besseren Schutz bietet. engine-mode: 1 versteckt Erze einfach und verbraucht weniger Ressourcen.

Fuer Server mit ressourcenbasierter Wirtschaft (SMP, Survival) wird engine-mode: 2 empfohlen. Fuer Minigames und PvP, wo Erze keine Rolle spielen, reicht engine-mode: 1 oder deaktiviert.

bukkit.yml: grundlegende Limits

connection-throttle

settings:
  connection-throttle: 4000

Funktioniert aehnlich wie connection-throttle in spigot.yml. In der Praxis hat spigot Prioritaet, wenn beide gesetzt sind. Am besten den gleichen Wert in beiden Dateien setzen.

Gleiche Empfehlung: 4000 fuer Standalone, -1 hinter einem Proxy.

spawn-limits

spawn-limits:
  monsters: 50
  animals: 8
  water-animals: 3
  ambient: 1

Mob-Anzahl-Limits pro Welt. Die vanilla Standardwerte sind zu hoch. 70 Monster pro Spieler ist fuer die meisten Server uebertrieben.

Aus Sicherheitsperspektive: weniger Mobs bedeuten weniger Serverlast. Wenn ein Angreifer versucht, Lag durch Mob-Erzeugung auszuloesen (Spawner, Eier), beschraenken niedrige Limits seine Moeglichkeiten.

chunk-gc

chunk-gc:
  period-in-ticks: 400

Garbage Collector fuer Chunks. Bestimmt, wie oft der Server Chunks ohne Spieler in der Naehe prueft und entlaedt. Der Standard von 600 Ticks (30 Sekunden) kann auf 400 (20 Sekunden) reduziert werden.

Je schneller unnoetige Chunks entladen werden, desto weniger Speicher verbraucht der Server. Bei Angriffen mit Chunk-Generierung reduziert schnelles Entladen die Lastakkumulation.

Proxy-Konfiguration (Velocity)

Wenn der Server hinter Velocity steht, unterscheidet sich die Konfiguration:

# server.properties
online-mode=false
network-compression-threshold=-1
rate-limit=0

# spigot.yml
settings:
  bungeecord: false
  connection-throttle: -1

# paper-global.yml
proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: 'dein-geheimer-schluessel-aus-velocity-forwarding-secret'

Beachte: online-mode=false in server.properties, aber online-mode: true in velocity-support. Velocity uebernimmt die Authentifizierung, und der Backend-Server vertraut den Daten vom Proxy.

Und ganz wichtig: schliesse den Backend-Port per Firewall. Wenn Port 25565 bei online-mode=false von aussen erreichbar ist, kann sich jeder direkt verbinden und Proxy samt Authentifizierung umgehen.

Was Konfigurationen nicht loesen

Richtige Konfigurationseinstellungen schliessen viele Angriffsvektoren. Aber sie ersetzen keine anderen Schutzebenen.

Konfigurationen schuetzen nicht vor DDoS-Angriffen auf Netzwerkebene. Dafuer braucht man externe Verkehrsfilterung, zum Beispiel ueber MineGuard. Papers Paketlimits stoppen Crash-Exploits, aber gegen 10 Gbit/s Verkehr sind sie machtlos.

Konfigurationen ersetzen keine Firewall. Selbst mit perfekten server.properties-Einstellungen sind offene SSH-, RCON- und Datenbankports Sicherheitsluecken.

Konfigurationen ersetzen keine Updates. Wenn in Paper eine Schwachstelle gefunden wird, helfen keine Einstellungen. Man braucht den Patch.

Der beste Ansatz ist die Kombination: richtige Konfigurationen + Firewall + DDoS-Schutz + regelmaessige Updates. Jede Schicht deckt ihre eigenen Bedrohungen ab. Mehr zum umfassenden Ansatz gibt es in der Sicherheits-Checkliste fuer Minecraft-Server.

Haeufige Fehler

Einige typische Fehler, die selbst erfahrene Admins machen:

Aktiviertes bungeecord ohne Proxy. Vielleicht der gefaehrlichste Fehler. Der Admin hat irgendwann BungeeCord getestet, bungeecord: true aktiviert, dann den Proxy entfernt, aber vergessen, das Flag auszuschalten. Jetzt kann jeder seine IP beim Verbinden faelschen.

RCON mit einfachem Passwort, offen im Internet. Haeufig bei Servern mit Control Panels zu sehen. Das Panel laeuft auf einem anderen Server und verbindet sich per Netzwerk zum RCON. Aber der Port ist fuer alle offen, und das Passwort ist "minecraft123". Das Ergebnis ist vorhersehbar.

online-mode: false auf Standalone ohne Grund. Manche Admins deaktivieren die Authentifizierung, "damit gecrackten Clients beitreten koennen." Das oeffnet die Tuer fuer Account-Identitaetsdiebstahl. Wenn du gecrackten Client-Support brauchst, verwende AuthMe oder ein aehnliches Plugin, aber idealerweise bleib bei online-mode: true.

Zu aggressive Paketlimits. Wenn du max-packet-rate: 50 im Packet-Limiter setzt, werden Spieler massenhaft gekickt, wenn sie das Handelsmeneu eines Dorfbewohners oeffnen oder bei aktivem PvP. Teste Limits auf einem Staging-Server, bevor du sie auf die Produktion anwendest.

Zusammenfassung

Die Sicherheit eines Minecraft-Servers beginnt mit den richtigen Konfigurationen. Nicht mit Plugins, nicht mit DDoS-Schutz, sondern mit fuenf Dateien, die das grundlegende Verhalten des Servers steuern.

Konfiguriere server.properties, spigot.yml, paper-global.yml, paper-world-defaults.yml und bukkit.yml nach den Empfehlungen in diesem Artikel. Das dauert 15 Minuten und schliesst Dutzende von Angriffsvektoren, die taeglich ausgenutzt werden.

Danach: Firewall, Proxy, Monitoring und regelmaessige Updates. Jede Schicht fuegt Schutz hinzu, und keine von ihnen ist verzichtbar.