Null-Angriffe und BungeeCord-Exploits: Minecraft Server schützen

Was sind Null-Angriffe und warum funktionieren sie so gut

Wer einen Minecraft-Server betreibt, wird früher oder später mit Null-Angriffen konfrontiert. Das sind keine klassischen DDoS-Attacken, die einfach die Bandbreite überfluten. Null-Angriffe arbeiten cleverer - sie senden fehlerhafte, leere oder speziell konstruierte Pakete, die den Server zwingen, Ressourcen für die Verarbeitung von Müll zu verschwenden.

Das Prinzip ist simpel: Das Minecraft-Protokoll erwartet Daten in bestimmten Formaten. Wenn ein Paket mit Null-Länge, ungültiger ID oder abgeschnittenen Daten ankommt, versucht der Server es zu parsen, wirft eine Exception und verbrennt dabei CPU. Multipliziert mit tausenden Verbindungen pro Sekunde fängt selbst ein starker Server an zu stottern.

Typen von Null-Angriffen auf Minecraft

Null Ping

Die einfachste Variante. Der Angreifer sendet SLP-Anfragen (Server List Ping) mit leerem oder beschädigtem Payload. Der Server versucht auf jede einzelne zu antworten, generiert das MOTD, zählt Spieler, baut JSON-Antworten. Bei tausenden Anfragen pro Sekunde verbringt der Server einen erheblichen Teil der CPU-Zeit nur mit Antworten an Fake-Pings.

In den Logs zeigt sich das als massenhafte Verbindungen ohne anschließenden Login. Spieler beschweren sich derweil über Lag oder können nicht joinen.

Null Login

Aggressiver. Ein Bot startet die Login-Prozedur, sendet ein Login-Start-Paket mit leerem Namen oder ungültigen Daten. Der Server reserviert Ressourcen für eine neue Session, beginnt die Verarbeitung und trifft dann auf einen Parsing-Fehler.

Besonders hart trifft das Server mit aufwändigen Login-Plugins wie AuthMe oder LoginSecurity. Jeder Fake-Login kann SQL-Abfragen, Prüfungen und andere Logik auslösen.

Invalid Packet Length

Der Angreifer sendet ein Paket, dessen Header eine bestimmte Länge angibt, die tatsächlichen Daten aber eine andere Größe haben. Oder die Länge ist negativ. Oder es ist ein VarInt mit Maximalwert.

Manche Server-Implementierungen crashen dabei. Vanilla und Paper fangen das grundsätzlich ab, aber Plugins die Pakete selbst parsen, können einen OutOfMemoryError werfen wenn sie versuchen einen Buffer nach der angegebenen Länge zu allokieren.

Protocol Manipulation

Der ausgefeilteste Typ. Bots senden Pakete in falscher Reihenfolge, nutzen nicht existierende Packet-IDs oder senden Pakete für den falschen Protokoll-Status (zum Beispiel Play-Pakete während des Handshakes).

Auf verwundbaren Servern kann das zu State-Desynchronisation und Speicherlecks führen. Ich habe Fälle gesehen, wo solche Angriffe dazu führten, dass der Server keine neuen Verbindungen mehr annahm, obwohl er technisch nicht gecrasht war.

BungeeCord: das größte Kopfzerbrechen

BungeeCord wird nach wie vor auf einer riesigen Anzahl von Servern verwendet. Und ist immer noch eine Quelle kritischer Schwachstellen bei falscher Konfiguration. Was fast immer der Fall ist.

IPForward Spoofing

Wenn BungeeCord ip_forwarding aktiviert hat, überträgt es die IP des Spielers an den Backend-Server über ein spezielles Feld im Handshake-Paket. Das Problem: Dieser Mechanismus hat keinerlei Authentifizierung. Überhaupt keine.

Wenn jemand sich direkt mit dem Backend-Server verbindet und das Handshake-Paket fälscht, kann er sich mit jeder beliebigen IP anmelden. Und wenn IP-basierte Account-Bindung aktiv ist, kann er sich als jeder beliebige Account einloggen.

Direkter Backend-Zugriff

Der häufigste Fehler ist, die Ports der Backend-Server offen zu lassen. Wenn die Spigot/Paper-Server von außen erreichbar sind, kann ein Angreifer sich direkt verbinden und BungeeCord komplett umgehen. Mit bungeecord: true in der spigot.yml vertraut der Server jedem Handshake-Paket.

Handshake- und UUID-Spoofing

BungeeCord fügt beim Weiterleiten von Spielern zusätzliche Daten in das Handshake-Paket ein: IP des Spielers, UUID und Profildaten. Ein Angreifer kann ein Paket mit beliebigen Daten in diesen Feldern erstellen.

Damit lässt sich die UUID eines Spielers fälschen und man loggt sich mit vollen Rechten als jemand anderes ein. Bei Servern im Offline-Mode ist das trivial, aber selbst Online-Mode-Server sind verwundbar wenn das Backend die UUID aus dem Handshake ohne Prüfung akzeptiert.

Velocity vs BungeeCord: Sicherheitsvergleich

Velocity wurde von Grund auf mit Blick auf die Fehler von BungeeCord entwickelt. Der Unterschied ist erheblich.

BungeeCord:

• IPForward ohne Authentifizierung
• Kein eingebauter Backend-Schutz
• Paketverarbeitung blockiert oft den Hauptthread
• BungeeGuard-Plugin als Notlösung für grundlegende Sicherheit nötig
• Schwachstellen im Paket-Parsing werden regelmäßig gefunden

Velocity:

• Modern Forwarding mit Secret Key (HMAC)
• Backend akzeptiert nur Verbindungen mit gültiger Signatur
• Strengeres Protokoll-Parsing
• Bessere Isolation zwischen Verbindungen
• Aktive Entwicklung mit schnellen Sicherheitsfixes

Wer einen Proxy von Grund auf aufsetzt, sollte Velocity nutzen. Wer bereits auf BungeeCord ist und nicht migrieren kann, sollte weiterlesen.

BungeeCord absichern

Backend-Ports sperren

Das ist Schritt eins. Backend-Server dürfen nur von der IP des BungeeCord erreichbar sein.

Mit iptables:

iptables -A INPUT -p tcp --dport 25565 -s BUNGEE_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -j DROP

Wenn BungeeCord und Backend auf der gleichen Maschine laufen, Backend an localhost binden:

server-ip=127.0.0.1

BungeeGuard installieren

BungeeGuard fügt einen geheimen Token in den Weiterleitungsprozess ein. Der Backend-Server prüft diesen Token und lehnt Verbindungen ohne ihn ab. Nicht perfekt, aber hebt die Hürde deutlich.

IPForward richtig konfigurieren

Ohne BungeeGuard oder Firewall ist IPForward einfach nur ein Sicherheitsloch. Beide Schutzschichten sind notwendig.

Velocity absichern

Modern Forwarding

In velocity.toml:

player-info-forwarding-mode = "modern"

Velocity generiert eine forwarding.secret-Datei. Das gleiche Secret wird in der Backend-Server-Konfiguration eingetragen. Modern Forwarding nutzt HMAC zur Datensignierung, ohne das Secret ist eine Fälschung unmöglich.

Für Paper in config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "Secret aus forwarding.secret kopieren"

Wann Anti-Bot-Plugins helfen und wann nicht

Anti-Bot-Plugins wie BotSentry, Antibot und EpicGuard arbeiten auf Anwendungsebene. Sie prüfen Verhalten nach der Verbindung - Bewegungsgeschwindigkeit, Paket-Timing, Captcha.

Sie helfen bei:

• Langsamen Bot-Angriffen (dutzende Verbindungen pro Sekunde)
• Bots die versuchen sich einzuloggen und zu spielen
• Chat-Spam durch Fake-Spieler

Sie helfen nicht bei:

• Null-Angriffen auf Protokollebene - das Paket crasht die Verarbeitung bevor das Plugin es sieht
• Massenverbindungen (tausende pro Sekunde) - der Server kommt nicht hinterher
• Angriffen in der Handshake/Login-Phase - Anti-Bot-Plugins greifen erst nach dem Login

Für Null-Angriffe und Protocol-Level-Flood braucht man Filterung bevor die Pakete den Java-Server erreichen. MineGuard filtert solche Pakete auf Netzwerkebene bevor sie den Server überhaupt erreichen und verwirft ungültige Verbindungen ohne das Gameplay zu beeinflussen.

Plugin-Empfehlungen

BungeeGuard - Pflicht bei BungeeCord. Fügt Authentifizierung zwischen Proxy und Backend hinzu. Kostenlos, leichtgewichtig, minimale Konfiguration.

TCPShield Plugin - Bei Nutzung von TCPShield extrahiert das Plugin korrekt die echte IP aus dem Proxy Protocol. Ohne erscheinen alle Spieler mit der Proxy-IP von TCPShield.

EpicGuard - Eine der besten Anti-Bot-Lösungen. Prüft GeoIP, Verbindungsrate, DNSBL. Funktioniert gut gegen langsame Bot-Angriffe. Rettet nicht vor Protocol-Level-Angriffen, aber als zusätzliche Schutzschicht hervorragend.

Warum Proxy Protocol besser ist als IPForward

IPForward in BungeeCord überträgt die IP über ein modifiziertes Handshake-Paket. Das ist eine nicht standardisierte Lösung, gebunden an das Minecraft-Ökosystem. Proxy Protocol (HAProxy Protocol) ist ein Industriestandard.

Vorteile von Proxy Protocol:

• Standardisiert, von vielen Systemen unterstützt
• Arbeitet auf Transportebene, vor dem Minecraft-Protokoll-Parsing
• Schwerer zu fälschen, da es vor den Anwendungsdaten verarbeitet wird
• Kompatibel mit jedem externen Schutzsystem

MineGuard unterstützt Proxy Protocol nativ, was eine korrekte Weiterleitung der echten Spieler-IPs an den Server ermöglicht, ohne IPForward und seine Schwachstellen.

Sicherheits-Checkliste

Schnellcheck für deinen Server:

• Backend-Ports per Firewall gegen externe Verbindungen gesperrt
• BungeeGuard oder Modern Forwarding konfiguriert und aktiv
• online-mode auf dem Proxy aktiviert
• Logs auf anomale Verbindungen überwacht
• IPForward nicht ohne zusätzlichen Schutz im Einsatz
• Backend server-ip an localhost oder interne IP gebunden
• Anti-Bot-Plugin als zusätzliche Schutzschicht installiert
• Proxy Protocol konfiguriert bei externer Schutzlösung

Wenn auch nur ein Punkt nicht erfüllt ist, ist dein Server verwundbar. Null-Angriffe und BungeeCord-Exploits sind keine theoretische Bedrohung - jeder Server mit 50+ Spielern hat damit zu tun. Richte den Schutz ein, bevor es zum Problem wird.