Minecraft Server für Angriffsresistenz optimieren

Die meisten Minecraft-Server-Admins betrachten DDoS-Schutz als etwas Externes. Ein Traffic-Filter, eine Firewall, ein Anti-DDoS-Dienst. Das ist alles richtig und notwendig. Aber es gibt etwas, das oft uebersehen wird: Der Server selbst muss optimiert sein, um Lastspitzen zu verkraften.

Die Logik ist einfach. Wenn Ihr Server im Normalbetrieb bei 90% Ressourcenauslastung laeuft, reicht ein kleiner Anstieg, um ihn lahmzulegen. Laeuft er bei 40-50%, gibt es einen Leistungspuffer. Dieser Puffer (Headroom) bestimmt, ob Ihr Server einen Angriff uebersteht oder bei den ersten Anzeichen zusaetzlicher Last abstuerzt.

Dieser Artikel behandelt konkrete Optimierungsschritte fuer maximalen Leistungspuffer.

Warum Leistung gleich Widerstandsfaehigkeit ist

Waehrend eines DDoS-Angriffs auf einen Minecraft-Server passieren mehrere Dinge gleichzeitig:

• TCP-Verbindungen steigen sprunghaft an (SYN Flood, Bot-Joins)
• CPU-Auslastung steigt durch Paketverarbeitung
• GC-Pausen werden laenger, da die Objektanzahl waechst
• TPS sinkt, die Tick-Schleife verlangsamt sich
• Spieler beginnen zu laggen, bekommen Timeouts und verbinden sich erneut, was noch mehr Last erzeugt

Dies ist ein Kaskadeneffekt. Ein Server, der bereits am Limit laeuft, gerät in eine Abwaertsspirale. Ein Server mit Leistungspuffer kann den Anstieg absorbieren, waehrend der externe Schutz die Bots herausfiltert.

Mehr darueber, wie man Lags von Angriffen unterscheidet, finden Sie in unserem Lag-Diagnose-Guide.

JVM-Flags: Das Leistungsfundament

Die Java Virtual Machine ist die Umgebung, in der Ihr Minecraft-Server laeuft. JVM-Einstellungen beeinflussen direkt die Ausfuehrungsgeschwindigkeit, GC-Stabilitaet und das Verhalten unter Last.

Aikar's Flags

Der Industriestandard fuer Minecraft-Server. Diese Flags konfigurieren den G1 Garbage Collector fuer Minecraft-spezifische Lastmuster:

java -Xms10G -Xmx10G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar server.jar --nogui

Wichtige Punkte:

• -Xms und -Xmx gleich setzen: eliminiert dynamische Heap-Aenderungen. Die JVM reserviert sofort den gesamten Speicher und verschwendet keine Zeit mit Erweiterungen unter Last. Kritisch bei Angriffen, wenn der Speicherdruck ploetzlich steigt.
• G1NewSizePercent=30 und G1MaxNewSizePercent=40: vergroesserte Young Generation. Minecraft erzeugt enorme Mengen kurzlebiger Objekte (Chunk-Daten, Paketpuffer, Entity-Ticks). Eine groessere Young Gen sammelt diese guenstig ein, ohne Full GC.
• AlwaysPreTouch: Die JVM beruehrt beim Start jede Speicherseite und zwingt das Betriebssystem, den physischen Speicher tatsaechlich zuzuweisen. Ohne dieses Flag kann es waehrend eines Angriffs passieren, dass die JVM Speicher anfordert, den das OS bereits an andere Prozesse vergeben hat.

Wie viel RAM zuweisen

Verbreiteter Irrtum: "mehr RAM = besser." Das stimmt nicht.

Bei G1GC gilt: groesserer Heap = laengere GC-Pausen. Ein Server mit 32 GB Heap kann GC-Pausen von 500-800 ms bekommen, was sich in spuerbaren Freezes aeussert.

Empfehlungen:

• Vanilla/Paper bis 30 Spieler: 4-6 GB
• Paper/Purpur 30-100 Spieler: 8-12 GB
• Grosse Netzwerke 100+ Spieler: 12-16 GB pro Instanz
• Proxy (Velocity/BungeeCord): 512 MB - 2 GB

Weisen Sie nie mehr als 16 GB einer einzelnen Instanz zu. Wenn Sie mehr Ressourcen brauchen, skalieren Sie horizontal mit mehreren Servern hinter einem Proxy.

GC-Probleme diagnostizieren

Wie erkennt man, ob der GC den Server bremst? Aktivieren Sie das Logging:

-Xlog:gc*:file=gc.log:time,uptime:filecount=5,filesize=10M

Oder verwenden Sie Spark:

/spark gc

Warnzeichen:

• GC-Pausen laenger als 100 ms treten oefter als einmal pro Minute auf
• Full GC findet ueberhaupt statt (bei richtig konfiguriertem G1GC sollte das nicht passieren)
• Heap-Belegung liegt konstant ueber 70%

Bei diesen Symptomen liegt das Problem wahrscheinlich an einem von drei Dingen: zu wenig RAM fuer Ihre Plugin- und Spieleranzahl, ein Speicherleck in einem Plugin, oder falsche JVM-Flags.

GraalVM vs OpenJDK

Fuer Minecraft 1.17+ lohnt sich GraalVM. Sein JIT-Compiler erzeugt optimaleren nativen Code, was eine 10-15% Verbesserung bei MSPT bringt. Waehrend eines Angriffs koennen diese 10-15% den Unterschied zwischen stabilen 20 TPS und einem Abfall auf 15 ausmachen.

Bei der Wahl der Java-Version: Paper 1.20.5+ erfordert Java 21. Verwenden Sie immer die von Ihrer Server-Software empfohlene Version.

Paper/Purpur-Konfiguration

Paper (und sein Fork Purpur) enthaelt dutzende Einstellungen, die die Leistung beeinflussen. Die richtige Konfiguration senkt die Grundlast und gibt Ressourcen fuer die Bewaeltigung von Lastspitzen frei.

paper-global.yml

chunk-loading:
  autoconfig-send-distance: true
  global-max-chunk-load-rate: 300.0
  global-max-chunk-send-rate: 80.0
  global-max-concurrent-loads: 6.0
  max-concurrent-sends: 2
  min-load-radius: 2
  player-max-chunk-load-rate: 100.0
  player-max-concurrent-loads: 4.0
  target-player-chunk-send-rate: 40.0

• global-max-chunk-load-rate: begrenzt die Chunk-Ladegeschwindigkeit. Bei einem Bot-Flood treten dutzende Bots gleichzeitig bei, und jeder loest Chunk-Laden aus. Ohne Limit sind CPU und Festplatte sofort ausgelastet.
• global-max-concurrent-loads: kritische Einstellung. Begrenzt paralleles Chunk-Laden. Der Standardwert ist zu hoch fuer Server unter Angriff.

paper-world-defaults.yml

entities:
  spawning:
    spawn-limits:
      monsters: 50
      animals: 8
      water-animals: 3
      ambient: 1
    tick-rates:
      monsters: 2
      animals: 4
      water-animals: 4
      ambient: 8

environment:
  optimize-explosions: true
  treasure-maps:
    enabled: false

misc:
  redstone-implementation: ALTERNATE_CURRENT

• Reduzierte Mob-Spawn-Limits: weniger Mobs = weniger Entity-Ticks = mehr CPU-Headroom. Bei Angriffen zaehlt jedes Prozent CPU.
• Erhoehte Entity-Tick-Rates: Mobs werden seltener geprueft. Visuell nicht erkennbar, aber die CPU-Ersparnis ist erheblich.
• ALTERNATE_CURRENT Redstone: 2-3x schneller als die Vanilla-Redstone-Implementierung.

server.properties

view-distance=8
simulation-distance=5
network-compression-threshold=256

• view-distance=8: 10 Chunks sind fuer die meisten Server uebertrieben. 8 ist eine gute Balance. Jeder zusaetzliche Chunk View-Distance erhoeht die Last quadratisch.
• simulation-distance=5: getrennt von View-Distance. Entities und Redstone ticken nur in diesem Radius.

Weitere Sicherheitseinstellungen fuer Paper und Spigot werden in einem eigenen Artikel behandelt.

Linux-Kernel-Tuning (sysctl)

Wenn Ihr Minecraft-Server auf einem dedizierten Server oder VPS mit Linux laeuft, koennen Kernel-Einstellungen die Netzwerk-Angriffsresistenz drastisch verbessern.

Netzwerkpuffer

# /etc/sysctl.d/99-minecraft.conf

# Socket-Puffer vergroessern
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576

# TCP-Puffer (min, default, max)
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

Standard-Linux-Puffer sind fuer allgemeine Workloads dimensioniert. Ein Minecraft-Server mit 50+ Spielern erzeugt erheblichen Netzwerkverkehr. Groessere Puffer verhindern Paketverluste bei Spitzen.

Verbindungs-Backlog

net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 65535

Kritisch wichtig bei DDoS. Wenn SYN-Pakete den Server ueberfluten, fuellt sich die Verbindungswarteschlange. Mit dem Standard-somaxconn=128 koennen sich legitime Spieler nicht verbinden, selbst wenn der Server sie problemlos bedienen koennte. Ein Backlog von 65535 gibt dem Server Zeit, die Warteschlange abzuarbeiten.

TCP-Tuning

# TIME_WAIT-Sockets wiederverwenden
net.ipv4.tcp_tw_reuse = 1

# Schnelleres TIME_WAIT-Recycling
net.ipv4.tcp_fin_timeout = 15

# Keepalive fuer Erkennung toter Verbindungen
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5

# SYN-Flood-Schutz
net.ipv4.tcp_syncookies = 1

• tcp_tw_reuse: erlaubt die Wiederverwendung von TIME_WAIT-Sockets fuer neue Verbindungen. Bei Angriffen, wenn Bots sich staendig verbinden und trennen, koennen TIME_WAIT-Sockets ohne diese Einstellung die verfuegbaren Ports erschoepfen.
• tcp_syncookies: muss aktiviert sein. Dies ist der in Linux eingebaute SYN-Flood-Schutz. Wenn die SYN-Warteschlange ueberlaeuft, verwendet der Kernel SYN-Cookies, anstatt Ressourcen pro SYN zuzuweisen.
• tcp_fin_timeout=15: Standard sind 60 Sekunden. Bei Angriffen haengen tausende halboffene Verbindungen im FIN_WAIT-Zustand und verbrauchen Kernel-Speicher.

Dateideskriptor-Limits

# systemd Unit
[Service]
LimitNOFILE=1048576

Jede TCP-Verbindung = ein Dateideskriptor. Das Standard-Limit von 1024 oder 4096 ist bei einem Angriff sofort erschoepft. Erhoehen Sie es auf 1 Million.

Plugin-Optimierung

Plugins sind nach dem Server-Kern selbst der groesste Ressourcenverbraucher. Ein schlecht geschriebenes Plugin kann mehr CPU verbrauchen als alle anderen zusammen.

Schwere Plugins finden

/spark profiler start
# 5-10 Minuten warten
/spark profiler stop

Achten Sie auf zwei Metriken:

1. Tick-Time-Beitrag: wie viele Millisekunden jedes Plugin pro Tick hinzufuegt
2. Thread-Aktivitaet: ob das Plugin den Hauptthread mit synchronen Operationen blockiert

Haeufige Probleme

Dynmap: Die Weltkartengenierung verursacht massive CPU- und Festplattenbelastung. Wenn Sie es verwenden, begrenzen Sie die Rendergeschwindigkeit stark.

Wirtschafts-Plugins mit MySQL: Synchrone DB-Abfragen blockieren den Hauptthread. Stellen Sie sicher, dass Ihre Plugins asynchrone Abfragen unterstuetzen.

WorldEdit: Massenoperationen verursachen Freezes. Verwenden Sie stattdessen FAWE (FastAsyncWorldEdit).

Allgemeine Regeln

• Jedes Plugin muss begruendet sein. "Fuer alle Faelle" ist kein guter Grund.
• Testen Sie Plugins unter Last auf einem Staging-Server, bevor Sie sie produktiv einsetzen.
• Halten Sie Plugins aktuell. Entwickler beheben haeufig Speicherlecks und optimieren die Performance.
• Verwenden Sie nicht mehr als ein Plugin fuer die gleiche Aufgabe.

Plugin-Task-Scheduling

Viele Plugins verwenden den Bukkit-Scheduler fuer periodische Aufgaben. Standardmaessig werden Tasks jeden Tick (50 ms) ausgefuehrt. Bei 30 Plugins mit je 2-3 Tasks pro Tick sind das 60-90 zusaetzliche Operationen pro Tick, bevor die Spiellogik ueberhaupt laeuft.

Verwenden Sie Spark, um zu identifizieren, welche Scheduled Tasks am haeufigsten ausgefuehrt werden. Manche Plugins bieten Konfigurationsoptionen fuer die Task-Frequenz. Folia (ein experimenteller Paper-Fork) adressiert dieses Problem durch Multithreading, aber die Plugin-Unterstuetzung ist noch begrenzt.

Chunk-Vorgenerierung

Die Generierung neuer Chunks ist eine der schwersten Operationen fuer einen Minecraft-Server. Jeder neue Chunk erfordert Terrain-, Struktur-, Biom- und Beleuchtungsgenerierung. Ein einzelner Generierungstick kann 50-200 ms dauern.

Waehrend eines Angriffs, wenn Bots beitreten und in verschiedene Richtungen fliegen, loest jeder einzelne neue Chunk-Generierung aus. Das toetet sofort die TPS.

Loesung: Chunky

/chunky radius 5000
/chunky start

Chunky generiert Chunks im angegebenen Radius vor. Nach der Generierung werden diese Chunks von der Festplatte geladen, was 10-100x schneller ist als die Neugenerierung.

Setzen Sie eine Weltgrenze, um die Karte zu begrenzen:

/worldborder set 20000

Das spart Speicherplatz und verhindert Last durch das Erkunden entfernter Gebiete.

Festplatten-I/O-Optimierung

NVMe vs HDD

Die Festplattengeschwindigkeit ist fuer Minecraft enorm wichtig. Chunks werden von der Festplatte geladen und gespeichert, Spielerdaten werden geschrieben. Bei Angriffen, wenn dutzende Bots I/O-Operationen erzeugen, wird eine langsame Festplatte zum Engpass.

• NVMe SSD: 3000-7000 MB/s Lesen. Chunks laden sofort.
• SATA SSD: 500-550 MB/s. Akzeptabel fuer kleinere Server.
• HDD: 100-150 MB/s. Inakzeptabel fuer Server mit 20+ Spielern oder unter Angriff.

tmpfs fuer Logs

mount -t tmpfs -o size=512M tmpfs /home/minecraft/server/logs

Minecraft-Logs koennen erhebliche I/O erzeugen. Das Verschieben der Logs auf tmpfs (RAM-Disk) gibt Festplatten-I/O fuer wichtigere Aufgaben frei.

Dateisystem-Tuning

Fuer Minecraft-Server empfiehlt sich ext4 mit noatime,nodiratime:

# /etc/fstab
/dev/nvme0n1p1 /home/minecraft ext4 defaults,noatime,nodiratime 0 2

Der noatime-Parameter deaktiviert die Aktualisierung des letzten Zugriffs-Timestamps beim Lesen von Dateien. Beim Laden tausender Region-Dateien reduziert das die Schreibzugriffe spuerbar. Unter Angriff, wenn Bots massenhaftes Chunk-Laden ausloesen, zaehlt jede vermiedene Schreiboperation.

I/O-Scheduler

Fuer NVMe-Laufwerke:

echo "none" > /sys/block/nvme0n1/queue/scheduler

NVMe-Laufwerke verarbeiten Anfragen parallel und benoetigen keinen I/O-Scheduler. Die Einstellung none entfernt unnuetzen Overhead.

Verbindungs-Rate-Limits

server.properties

max-players=100

Setzen Sie ein realistisches Limit. Wenn Ihr Server 50 Spieler komfortabel bedient, setzen Sie max-players nicht auf 1000 "fuer alle Faelle." Waehrend eines Angriffs fuellen Bots alle 1000 Slots.

Velocity Rate Limiting

Velocity (der empfohlene Proxy) hat einen eingebauten Rate-Limiter:

# velocity.toml
[advanced]
login-ratelimit = 3000
connection-timeout = 5000
read-timeout = 30000

login-ratelimit = 3000 bedeutet mindestens 3 Sekunden zwischen Login-Versuchen von einer IP. Das stoppt keine verteilte Attacke von tausenden IPs, schneidet aber einfache Bot-Floods von einer einzigen Quelle ab.

TPS-Stabilitaet waehrend Angriffen

TPS (Ticks Per Second) = 20 bedeutet, dass der Server 20 Spielticks pro Sekunde verarbeitet. Jeder Tick kann bis zu 50 ms dauern. Dauert ein Tick laenger als 50 ms, sinkt TPS unter 20.

MSPT (Milliseconds Per Tick) ist die praezisere Metrik. Ein Server mit 30 ms MSPT hat 20 ms Headroom. Ein Server mit 48 ms MSPT hat nur 2 ms Headroom.

Waehrend eines DDoS-Angriffs erhoeht jede zusaetzliche Last die MSPT:

• Verarbeitung von Bot-Paketen: +5-15 ms
• Chunk-Laden fuer neue Verbindungen: +10-50 ms
• Erhoehter GC-Druck: +5-20 ms

Ein Server mit 30 ms MSPT kann zusaetzliche 20 ms absorbieren und bleibt bei 20 TPS. Ein Server mit 48 ms MSPT faellt auf 10-15 TPS, Spieler beginnen zu laggen und sich zu trennen.

Ziel: MSPT im Normalbetrieb unter 35 ms halten, damit Puffer fuer Spitzen bleibt.

Angriffsflaeche reduzieren

Query und RCON deaktivieren

enable-query=false
enable-rcon=false

Das Query-Protokoll (UDP-Port 25565) ermoeglicht das Abrufen von Serverinformationen. Angreifer nutzen es fuer Aufklaerung und Amplification-Angriffe. RCON ist eine Remote-Konsole, die bei Internetzugang ein Brute-Force-Ziel wird.

Proxy-Geheimschluessel

Wenn Sie einen Proxy verwenden, erzwingen Sie die Verbindung ueber Secret-Key-Verifizierung. Dies verhindert direkte Verbindungen zu Backend-Servern unter Umgehung des Proxys.

Notfall-Whitelist

/whitelist on

Wenn ein Angriff zu stark ist und die Filterung nicht mithaelt, laesst eine temporaere Whitelist nur registrierte Spieler beitreten. Nicht ideal, aber besser als kompletter Ausfall.

Optimierung + externer Schutz

Server-Optimierung ersetzt keinen DDoS-Schutz. Sie ergaenzt ihn. Keine sysctl-Einstellung rettet Sie vor einem 10 Gbit/s UDP-Flood. Dafuer braucht es Traffic-Filterung auf Netzwerkebene.

Aber die Kombination aus einem optimierten Server und qualitativ hochwertiger Filterung (wie zum Beispiel MineGuard) liefert maximale Widerstandsfaehigkeit. Der Filter blockiert 99% des Muell-Traffics, und der optimierte Server verarbeitet das restliche 1%, das durchkommt.

Die Hosting-Wahl spielt ebenfalls eine Rolle. Mehr zur Auswahl von Hosting mit DDoS-Schutz finden Sie in unserem Hosting-Guide.

Schnelle Optimierungs-Checkliste

JVM: Aikar's Flags, gleiche Xms/Xmx, 8-12 GB pro Instanz, GraalVM in Betracht ziehen.

Paper/Purpur: Reduzierte Mob-Limits, erhoehte Tick-Rates, begrenztes Chunk-Laden, View-Distance 8, Simulation-Distance 5, ALTERNATE_CURRENT Redstone.

Linux-Kernel: somaxconn 65535, tcp_syncookies an, vergroesserte Puffer, erhoehte Dateideskriptor-Limits, reduzierter tcp_fin_timeout.

Plugins: Spark-Profiling durchgefuehrt, schwere Plugins ersetzt oder optimiert, asynchrone DB-Abfragen, ungenutzte Plugins entfernt.

Festplatte: NVMe/SSD, vorgenerierte Chunks (Chunky), Weltgrenze gesetzt.

Monitoring: Spark installiert, MSPT ueberwacht, Alarme bei TPS unter 18.

Leistungspuffer ist Ihre Versicherung. Je mehr Spielraum Ihr Server unter normalen Bedingungen hat, desto groesser sind die Chancen, dass er einen Angriff uebersteht, ohne dass Ihre Spieler etwas davon bemerken.