Minecraft-Proxy vor DDoS-Angriffen schützen

Ein Minecraft-Netzwerk mit Proxy hat einen einzigen Punkt, an dem alles zusammenläuft: die Adresse, die Ihre Spieler eingetippt haben. Fällt eine Lobby aus, merken es die Leute, die gerade dort stehen. Fällt der Proxy aus, sind alle draußen, auch die, die seit vier Stunden auf dem Survival-Server bauen. Dieser Beitrag zeigt, wie Sie einen Minecraft-Proxy vor DDoS-Angriffen schützen: zuerst die Backends, die fast jedes angegriffene Netzwerk offen im Internet stehen hat, danach das Weiterleitungsgeheimnis, dann die vier Angriffsarten am Proxy mit den passenden Konfigurationsblöcken, und zum Schluss die Stelle, an der lokale Maßnahmen physikalisch aufhören.

Alle Angaben beziehen sich auf BungeeCord, Waterfall oder Velocity vor Paper-, Spigot- oder Fabric-Backends unter Debian 12, Debian 13, Ubuntu 22.04 LTS oder Ubuntu 24.04 LTS. Die Befehle sind für root geschrieben, als normaler Benutzer stellen Sie sudo voran. Die protokollspezifischen Angriffe auf einen einzelnen Java-Server behandelt Minecraft-DDoS-Schutz und Nullping-Schutz, die Bedrock Edition mit ihrem UDP-Protokoll behandelt Minecraft-Bedrock-Server vor DDoS-Angriffen schützen. Hier geht es ausschließlich um das, was erst durch den Proxy entsteht.

Wenn der Angriff gerade läuft: Starten Sie den Proxy nicht neu. Ein Neustart wirft alle verbliebenen Spieler heraus und liefert Ihnen kein einziges Messergebnis. Sichern Sie zuerst die Werte aus dem Abschnitt "Messwerte sammeln, bevor es knallt", danach sind sie unwiederbringlich weg.

Warum ein Minecraft-Proxy der empfindlichste Punkt im Netzwerk ist

Ein Proxy ist gleichzeitig die beste und die schlechteste Nachricht für den DDoS-Schutz. Die beste, weil es genau eine öffentliche Adresse gibt, auf die sich jede Schutzmaßnahme richten lässt: ein Port, ein Protokoll, ein Regelsatz. Die schlechteste, weil diese eine Adresse auch das einzige Ziel ist, das ein Angreifer treffen muss. Ein Minecraft-Netzwerk mit Proxy hat keinen zweiten Eingang, über den Spieler hereinkommen könnten, wenn der erste dicht ist.

Dazu kommt die Angriffsfläche des Proxys selbst. Er nimmt jede eingehende TCP-Verbindung an, liest den Handshake, entscheidet über Status oder Login, führt die Mojang-Authentifizierung durch, baut eine zweite Verbindung zum Backend auf und reicht danach jedes Paket in beide Richtungen weiter. Ein Backend-Server macht davon nur den letzten Teil. Der Proxy trägt also die gesamte Verbindungslast des Netzwerks, und er trägt sie doppelt, weil zu jeder Spielerverbindung eine Backend-Verbindung gehört. Was ein DDoS-Angriff grundsätzlich ist, erklärt Was ist ein DDoS-Angriff?.

Wie ein Proxy-Netzwerk aufgebaut ist

Ein Minecraft-Proxy ist ein Programm, das sich gegenüber dem Spieler wie ein Minecraft-Server verhält und gegenüber den echten Servern wie ein Spieler. Er spricht dasselbe Protokoll auf Port 25565 TCP, beantwortet die Serverlisten-Abfrage, führt die Anmeldung durch und verbindet den Spieler danach mit einem der Backend-Server. Wechselt der Spieler die Welt, bleibt seine Verbindung zum Proxy bestehen, nur die dahinterliegende Verbindung wird ausgetauscht. Genau deshalb merken Spieler einen Serverwechsel nur als kurzen Ladebildschirm.

Der übliche Aufbau sieht so aus, und die Zahlen sind die Voreinstellungen der jeweiligen Software:

Spieler  -->  play.example.com  (A- oder SRV-Eintrag im DNS)
              |
              v
         Proxy  25565/TCP   (Velocity, Voreinstellung bind = "0.0.0.0:25565")
         Proxy  25577/TCP   (BungeeCord, Voreinstellung listeners.host: 0.0.0.0:25577)
              |
     +--------+--------+------------------+
     v                 v                  v
  Lobby 25566      Survival 25567     Minigames 25568
  127.0.0.1        127.0.0.1          10.0.0.12

Zwei Details daran sind für den Schutz entscheidend. Erstens kennt die Java Edition SRV-Einträge im DNS, Spieler tippen also nur play.example.com ohne Portnummer. Welche Adresse dahintersteht, ist beliebig, und sie lässt sich ohne Zutun der Spieler ändern. Zweitens müssen die Backend-Ports nirgendwo öffentlich sein. Der Proxy erreicht sie über 127.0.0.1, über ein privates Netz oder über eine Adresse, die nur er kennt.

Die Ports, um die es tatsächlich geht

Ein Proxy-Netzwerk braucht nach außen genau einen offenen Port. Alles andere in dieser Tabelle gehört hinter eine Firewall:

Die Zeile mit 25577 ist der Grund für ein Missverständnis, das sich hartnäckig hält: BungeeCord lauscht ab Werk auf 25577, Velocity dagegen auf 25565. Wer von BungeeCord auf Velocity wechselt und die alte Firewallregel behält, hat plötzlich einen Proxy auf einem Port offen, für den er nie eine Regel geschrieben hat, und einen freigegebenen Port, auf dem nichts mehr lauscht. Sehen Sie nach dem Wechsel mit ss -lntp nach, was wirklich bindet.

Der häufigste und teuerste Fehler: erreichbare Backend-Server

Das ist der wichtigste Abschnitt des Beitrags, und er kostet Sie kein Geld, nur zwanzig Minuten. Wer die Backend-Server offen ins Internet stellt, hat den Proxy umsonst. Ein Angreifer, der die Adresse eines Backends kennt, umgeht damit jede Maßnahme, die Sie am Proxy getroffen haben: jede Verbindungsbremse, jede Warteschlange, jede Anmeldeprüfung, jedes Bannsystem.

Der Schaden ist dabei nicht auf Verfügbarkeit beschränkt. Er ist in den allermeisten Netzwerken zugleich ein vollständiger Rechteverlust, und warum das so ist, steht im nächsten Kapitel über das Weiterleitungsgeheimnis.

Wie Angreifer Ihre Backends finden

Es gibt vier Wege, und keiner davon setzt besonderes Können voraus.

Erstens: Portscans auf 25565 bis 25575. Der gesamte IPv4-Adressraum wird laufend auf offene Minecraft-Ports abgesucht, und die Ergebnisse landen in öffentlich durchsuchbaren Verzeichnissen. Wer seine Backends aufsteigend ab 25566 vergibt, was fast alle tun, macht es besonders leicht: Ein Scan über elf Ports einer bekannten Adresse liefert die gesamte Topologie.

Zweitens: die Statusantwort selbst. Ein Minecraft-Server beantwortet die Serverlisten-Abfrage, bevor sich irgendjemand angemeldet hat. Die Antwort ist ein JSON-Dokument mit Versionsname, Protokollnummer, aktueller und maximaler Spielerzahl, der Beschreibung aus motd und einer Stichprobe der verbundenen Spieler samt UUID. Genau daran erkennt ein Scanner, dass hinter Port 25567 kein Webdienst, sondern eine Minecraft-Welt steht, und er liest gleich mit, ob sich der Angriff lohnt.

Drittens: die alte Adresse im DNS. Viele Netzwerke haben vor dem Proxy einen einzelnen Server betrieben, und der A-Eintrag von damals zeigt weiterhin auf dessen Adresse. Historische DNS-Daten sind öffentlich abrufbar. Wer einen Proxy vorschaltet, ohne die alte Adresse zu wechseln, verteilt die Backend-Adresse quasi selbst.

Viertens: Plugins und Statusseiten. Ein Discord-Bot, eine Weboberfläche mit Spielerzahl je Welt oder ein Abfrage-Plugin, das den GS4-Query auf jedem Backend einschaltet, veröffentlicht die Adressen an einer Stelle, an die beim Absichern niemand denkt.

Die Firewallregeln, die das schließen

Die Regel lautet in einem Satz: Auf die Backend-Ports darf ausschließlich die Adresse des Proxys zugreifen, alles andere wird verworfen. Läuft der Proxy auf demselben Rechner wie die Backends, ist das trivial, denn dann binden die Backends auf 127.0.0.1 und sind von außen technisch nicht erreichbar. In der server.properties jedes Backends:

server-ip=127.0.0.1
server-port=25566
online-mode=false
enable-status=false
enable-query=false
enable-rcon=false
network-compression-threshold=-1

Zur Erklärung der beiden ungewöhnlichen Zeilen. online-mode=false ist auf einem Backend hinter einem Proxy richtig und sogar notwendig, weil die Mojang-Anmeldung bereits am Proxy stattgefunden hat und ein zweites Mal nicht möglich ist. Genau diese Zeile ist aber auch der Grund, warum ein erreichbares Backend so gefährlich ist. network-compression-threshold=-1 schaltet die Kompression zwischen Proxy und Backend ab, weil beide auf demselben Rechner liegen und das Komprimieren dort nur Rechenzeit kostet. Steht ein Backend auf einem anderen Rechner, lassen Sie den Wert auf 256. Die Grundinstallation eines solchen Servers beschreibt Minecraft-Server auf Debian installieren.

Liegen die Backends auf anderen Rechnern, brauchen Sie eine echte Firewall. Mit nftables, hier vollständig als Datei, damit die Regeln einen Neustart überleben:

table inet mcbackend {
    chain input {
        type filter hook input priority filter ; policy drop ;

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        ip saddr 203.0.113.10 tcp dport 22 accept
        ip saddr 198.51.100.7 tcp dport 25566-25575 accept

        icmp type echo-request limit rate 5/second accept
        counter drop
    }
}

Die Datei kommt nach /etc/nftables.conf, davor gehört die Zeile #!/usr/sbin/nft -f. Danach systemctl enable --now nftables und unbedingt nft list ruleset zur Gegenprobe. Die Adresse 198.51.100.7 steht hier für Ihren Proxy, 203.0.113.10 für den Ort, von dem aus Sie administrieren. Wer lieber mit UFW arbeitet, erreicht dasselbe so, und die Reihenfolge ist wichtig, damit Sie sich nicht aussperren:

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH Buero'
ufw allow from 198.51.100.7 to any port 25566:25575 proto tcp comment 'Proxy zu Backends'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status numbered

Die ausführliche Anleitung samt Rettungsweg steht in UFW-Firewall einrichten, ohne sich selbst auszusperren. Prüfen Sie danach von einem fremden Rechner aus, ob die Backends wirklich zu sind. Nicht annehmen, nachsehen:

nmap -Pn -p 25565-25580 IHRE.BACKEND.IP.ADRESSE
nmap -Pn -p- --min-rate 1000 IHRE.PROXY.IP.ADRESSE

Die erwartete Ausgabe für das Backend ist filtered auf allen Ports. Steht dort open, haben Sie das Problem, um das es in diesem Kapitel geht. Für den Proxy ist genau ein Port offen, und zwar der, auf dem er lauscht.

Warum Pterodactyl hier eine eigene Falle stellt

Wer seine Server über ein Panel verwaltet, hat den Punkt schnell übersehen. Pterodactyl vergibt jeder Instanz eine Zuordnung aus IP-Adresse und Port, und die Voreinstellung ist die öffentliche Adresse des Knotens, nicht 127.0.0.1. Ein Backend, das Sie im Panel anlegen, ist damit ab der ersten Sekunde aus dem Internet erreichbar, auch wenn der Proxy daneben steht. Legen Sie für die Backends eine Zuordnung auf 127.0.0.1 an und weisen Sie diese der Instanz zu. Die Installation des Panels beschreibt Pterodactyl-Panel installieren.

Dasselbe gilt für Docker-Container. Eine Zuordnung mit -p 25566:25565 veröffentlicht den Port auf allen Adressen des Rechners und umgeht dabei die Ketten von UFW, weil Docker seine Regeln in die Kette DOCKER-USER vor die Filterregeln schreibt. Richtig ist -p 127.0.0.1:25566:25565.

Das Weiterleitungsgeheimnis: warum ein offenes Backend Operatorrechte verschenkt

Jetzt zu dem Punkt, der aus einem Verfügbarkeitsproblem ein Sicherheitsproblem macht. Damit ein Backend weiß, wer da eigentlich verbunden ist, muss der Proxy ihm die echte IP-Adresse, die UUID und das Spielerprofil mitteilen. Dafür gibt es zwei grundverschiedene Verfahren.

BungeeCord ip_forward: alte Kompatibilität, keine Prüfung

Das ältere Verfahren heißt in BungeeCord ip_forward und in Velocity legacy. Es funktioniert, indem der Proxy das Adressfeld des Handshake-Pakets zweckentfremdet und dort hinter die eigentliche Adresse die echte Spieler-IP, die UUID und die Profileigenschaften anhängt, getrennt durch Nullbytes. Das Backend zerlegt dieses Feld und glaubt dem Ergebnis. Eingeschaltet wird es auf beiden Seiten:

ip_forward: true                 # config.yml des Proxys

settings:                        # spigot.yml des Backends
  bungeecord: true

Der entscheidende Satz dazu: Dieses Verfahren enthält keinerlei kryptographische Prüfung. Das Backend hat keine Möglichkeit festzustellen, ob das Handshake-Paket wirklich von Ihrem Proxy kam. Die Dokumentation von PaperMC nennt die Weiterleitung nach BungeeCord-Art deshalb ausdrücklich grundsätzlich unsicher.

Was das praktisch bedeutet, rechnen wir einmal durch. Ein Backend hinter einem Proxy läuft zwingend mit online-mode=false, weil die Mojang-Prüfung am Proxy stattgefunden hat. Ist dieses Backend aus dem Internet erreichbar, kann sich jeder mit einem handelsüblichen Werkzeug direkt darauf verbinden und dabei die angehängten Felder frei setzen. Er wählt einen Namen, eine UUID, eine Absenderadresse. Ein erreichbares Backend mit legacy-Weiterleitung bedeutet, dass sich jeder als beliebiger Spieler ausgeben kann, einschließlich Ihrer Operatoren. Es braucht dafür keinen Fehler in Ihrer Software und kein gestohlenes Kennwort, nur die Adresse und die Portnummer.

Velocity Modern Forwarding: gemeinsamer Schlüssel statt Vertrauen

Velocity löst das Problem an der Wurzel. Modern Forwarding überträgt IP-Adresse, UUID und Profil nicht im Handshake, sondern als eigenen Schritt im Anmeldeablauf, und es unterschreibt diese Daten mit einem gemeinsamen Geheimnis. Das Backend prüft die Unterschrift und weist alles zurück, was nicht von einem Proxy mit demselben Schlüssel kommt.

Velocity legt den Schlüssel beim ersten Start selbst an. In der velocity.toml:

player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"

Auf jedem Paper-Backend ab 1.19.4 steht das Gegenstück in config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: 'INHALT_DER_DATEI_FORWARDING_SECRET'

Drei Hinweise aus der Praxis. Der Wert von online-mode unter proxies.velocity muss demselben Wert wie online-mode in der velocity.toml entsprechen, sonst bekommen Ihre Spieler abweichende UUIDs und verlieren ihr Inventar. Die Datei forwarding.secret ist UTF-8, darf nicht leer sein und verträgt kein zusätzliches Leerzeichen und keinen Zeilenumbruch am Ende. Und auf Paper-Versionen bis 1.18.2 heißt der Abschnitt nicht proxies.velocity in der paper-global.yml, sondern settings.velocity in der paper.yml.

Die Einschränkung von Modern Forwarding ist die Mindestversion: Es setzt Minecraft 1.13 oder neuer auf dem Backend voraus. Wer noch 1.8-Server im Netzwerk hat, kann es dort nicht verwenden.

BungeeGuard als Zwischenlösung für alte Versionen

Für genau diesen Fall gibt es BungeeGuard. Das Plugin hängt an die legacy-Weiterleitung ein geheimes Token in den Profileigenschaften an, und auf dem Backend prüft ein Gegenstück, ob dieses Token in seiner Liste steht. Ohne gültiges Token wird die Verbindung abgewiesen. Velocity unterstützt das Verfahren eingebaut:

player-info-forwarding-mode = "bungeeguard"
forwarding-secret-file = "forwarding.secret"

Das ist eine echte Verbesserung gegenüber blankem ip_forward, aber die Reihenfolge stimmt trotzdem: BungeeGuard ist die Lösung für Netzwerke, die auf Rechnern ohne eigene Firewall liegen oder alte Protokollversionen bedienen müssen. Auf einem eigenen Server bleibt die Firewallregel das erste Mittel, und BungeeGuard kommt als zweite Schicht dazu. Die Autoren des Plugins schreiben das selbst so.

Die vier Weiterleitungsmodi im Vergleich

Die Empfehlung daraus ist eindeutig: Modern Forwarding, wo die Versionen es zulassen, BungeeGuard, wo sie es nicht zulassen, und in beiden Fällen zusätzlich die Firewallregel aus dem vorigen Kapitel. Der Modus none ist kein Sicherheitsgewinn, sondern verliert nur die echten IP-Adressen, was jedes Bannsystem und jede Missbrauchsverfolgung wertlos macht.

Was die Statusantwort über Ihr Netzwerk verrät

Die Serverlisten-Abfrage ist der Teil des Protokolls, der vor jeder Anmeldung abläuft. Der Client öffnet eine TCP-Verbindung, schickt ein Handshake-Paket mit dem Zustandswert 1, fordert den Status an und bekommt ein JSON-Dokument zurück. Kein Nachweis, kein Konto, keine Spur im Anmeldeprotokoll. Die Antwort enthält in der Voreinstellung:

{
  "version": { "name": "1.21.4", "protocol": 769 },
  "players": {
    "max": 500,
    "online": 37,
    "sample": [ { "name": "Spielername", "id": "…" } ]
  },
  "description": { "text": "Unser Netzwerk" },
  "enforcesSecureChat": true,
  "favicon": "data:image/png;base64,…"
}

Für einen Angreifer sind drei Felder interessant. players.online verrät ihm, wann sich ein Angriff lohnt, also abends und am Wochenende. version.protocol verrät ihm, welche Protokollfehler bei Ihnen greifen könnten. Und players.sample liefert ihm Namen und UUIDs echter Spieler, die er für gezielte Bot-Joins oder für Täuschungsversuche verwenden kann.

Die Statusantwort kürzen

Auf den Backends schalten Sie die Statusantwort vollständig ab. Ein Backend hinter einem Proxy braucht sie nicht, denn es wird nie in einer Serverliste stehen. In der server.properties:

enable-status=false

Damit beantwortet der Server Statusabfragen überhaupt nicht mehr und erscheint in Scans als Port, der zwar offen ist, aber schweigt. Wenn Sie die Statusantwort auf einem Backend aus betrieblichen Gründen brauchen, kürzen Sie wenigstens die Spielerliste:

hide-online-players=true

Am Proxy selbst bleibt die Statusantwort natürlich an, sonst verschwindet Ihr Netzwerk aus den Serverlisten Ihrer Spieler. Sie können aber steuern, wie viel dort steht. In Velocity:

show-max-players = 500
sample-players-in-ping = false
ping-passthrough = "disabled"

Mit sample-players-in-ping = false, der Voreinstellung, zeigt Velocity beim Überfahren der Spielerzahl keine Namensliste. Mit ping-passthrough = "disabled" beantwortet der Proxy die Abfrage aus seiner eigenen Konfiguration und fragt dafür kein Backend an. Das ist zugleich eine Schutzmaßnahme: Bei "all" oder "description" löst jede eingehende Statusabfrage eine Abfrage an ein Backend aus, und eine Ping-Flut erreicht damit auch Server, die gar nicht im Internet stehen.

BungeeCord kennt für denselben Zweck einen Zwischenspeicher, der ab Werk aus ist:

remote_ping_cache: 10000
remote_ping_timeout: 5000
log_pings: false

Der Wert -1 schaltet den Zwischenspeicher ab, jede Abfrage geht dann an das Backend durch. Mit 10000 liefert der Proxy zehn Sekunden lang dieselbe Antwort aus dem Speicher. log_pings: false ist keine Schutzmaßnahme, verhindert aber, dass eine Ping-Flut Ihre Festplatte mit Protokollzeilen füllt, und genau daran sterben Proxys öfter als an der Paketlast selbst.

Die vier Angriffsarten, die einen Minecraft-Proxy treffen

Angriffe auf einen Proxy unterscheiden sich von einer reinen Bandbreitenflut darin, dass sie das Protokoll benutzen. Sie sind deshalb billig, sehen auf den ersten Blick wie echte Spieler aus und lassen sich nicht allein an der Datenmenge erkennen.

Die erste und die zweite Art kosten den Angreifer fast nichts. Eine TCP-Verbindung aufzubauen und stehen zu lassen ist auf seiner Seite ein Eintrag in einer Schleife, auf Ihrer Seite ein Socket mit Puffer im Kernel und ein Objekt in der Java-Halde des Proxys. Das Verhältnis ist das eigentliche Problem: Der Angreifer zahlt Bytes, Sie zahlen Speicher.

Die vierte Art ist die einzige, die sich nicht rein netzwerkseitig lösen lässt, weil sie protokollkonform ist. Läuft Ihr Netzwerk im Online-Modus, ist sie außerdem teuer für den Angreifer, weil jedes Konto Geld kostet und nach einem Bann verloren ist. Läuft es im Offline-Modus, ist sie umsonst, und dann brauchen Sie einen vorgeschalteten Prüfschritt.

Gegenmaßnahmen am Proxy, mit konkreten Konfigurationsblöcken

1. Verbindungsobergrenze je Quelladresse mit nftables

Die wirksamste lokale Maßnahme gegen die Verbindungsflut ist eine Obergrenze je Quelladresse, gesetzt im Kernel, bevor der Proxy überhaupt davon erfährt. Mit nftables braucht das zwei dynamische Mengen: eine für die gleichzeitig offenen Verbindungen, eine für die Rate neuer Verbindungen.

table inet mcproxy {
    set gleichzeitig {
        type ipv4_addr
        size 131072
        flags dynamic
    }

    set rate {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 2m
    }

    chain input {
        type filter hook input priority filter ; policy accept ;

        tcp dport 25565 ct state new add @gleichzeitig { ip saddr ct count over 12 } counter drop
        tcp dport 25565 ct state new add @rate { ip saddr limit rate over 20/minute burst 10 packets } counter drop
    }
}

Die erste Regel verwirft neue Verbindungen, sobald dieselbe Quelladresse mehr als zwölf gleichzeitig offen hat. Die zweite verwirft sie, sobald dieselbe Quelladresse mehr als zwanzig neue Verbindungen pro Minute aufbaut, mit einem Puffer von zehn für den normalen Startvorgang. Beide Zahlen sind Startwerte, keine Wahrheit. Ein einzelner Spieler öffnet beim Start des Clients mehrere Verbindungen, weil die Serverliste jeden Eintrag einzeln abfragt, und hinter einem großen Anschluss teilen sich mehrere Spieler eine Adresse. Messen Sie erst eine Woche im Normalbetrieb, bevor Sie enger stellen.

Wer den Angriff gerade erlebt und schnell etwas braucht, kann dasselbe mit iptables hinschreiben:

iptables -I INPUT -p tcp --dport 25565 --syn -m connlimit --connlimit-above 12 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 25565 --syn -m hashlimit --hashlimit-name mcnew --hashlimit-mode srcip --hashlimit-above 20/min --hashlimit-burst 10 -j DROP
iptables -L INPUT -n -v --line-numbers

Die dritte Zeile ist die wichtigste: Steigen die Trefferzähler nicht, wird Ihre Regel nicht erreicht. Bei aktivem UFW stehen eigene Regeln sonst hinter den UFW-Ketten und laufen ins Leere. Dauerhaft gehören sie in /etc/ufw/before.rules oder werden mit apt-get install -y iptables-persistent und netfilter-persistent save gesichert.

2. Halboffene Verbindungen und die Annahme-Warteschlange des Kernels

Gegen die reine SYN-Flut hilft ein Mechanismus, den Linux mitbringt und der bei TCP im Gegensatz zu UDP wirklich greift. SYN-Cookies sind ein Verfahren, bei dem der Kernel den Zustand einer halboffenen Verbindung nicht speichert, sondern in die Sequenznummer der Antwort hineinrechnet, sodass eine Flut gefälschter Verbindungsanfragen keinen Speicher mehr belegt:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=8192
sysctl -w net.ipv4.tcp_synack_retries=2
sysctl -w net.ipv4.tcp_abort_on_overflow=0

Dauerhaft kommen die Zeilen ohne -w nach /etc/sysctl.d/99-mcproxy.conf, danach sysctl --system. Der Wert somaxconn ist die Obergrenze für die Warteschlange fertig aufgebauter, aber noch nicht abgeholter Verbindungen. Wird sie überschritten, verwirft der Kernel stumm, und der Zähler dafür ist:

nstat -az | grep -E 'TcpExtListenOverflows|TcpExtListenDrops|TcpExtSyncookiesSent'
ss -ltn '( sport = :25565 )'

Steigt TcpExtListenOverflows, holt der Proxy die Verbindungen nicht schnell genug ab. Die Spalte Recv-Q in der zweiten Zeile zeigt den aktuellen Füllstand dieser Warteschlange, die Spalte Send-Q ihre Obergrenze. Das ist die härteste Messgröße dafür, ob der Engpass im Kernel oder im Proxy liegt.

3. connection_throttle in BungeeCord und Waterfall

BungeeCord bringt eine eingebaute Verbindungsbremse mit, und sie ist ab Werk eingeschaltet. In der config.yml:

connection_throttle: 4000
connection_throttle_limit: 3
timeout: 30000
server_connect_timeout: 5000
player_limit: -1
max_packets_per_second: 4096
max_packets_data_per_second: 33554432

Die beiden ersten Werte gehören zusammen: Hat eine IP-Adresse innerhalb von connection_throttle Millisekunden bereits connection_throttle_limit Mal verbunden, muss sie diese Zeitspanne abwarten, bevor sie es wieder darf. Die Voreinstellung erlaubt also drei Verbindungen in vier Sekunden je Adresse. Für ein Netzwerk unter Beschuss ist das großzügig, 8000 Millisekunden bei einem Limit von 2 sind ein vertretbarer nächster Schritt. Über 10000 Millisekunden hinaus sperren Sie regelmäßig eigene Spieler aus, die nach einem Absturz sofort wieder verbinden wollen.

max_packets_per_second und max_packets_data_per_second sind die Paketgrenzen, die BungeeCord je Verbindung durchsetzt: 4096 Pakete pro Sekunde und 32 MiB pro Sekunde. Sie treffen genau die Muster, die ein einzelner Client niemals erzeugt, und schützen den Proxy davor, dass eine einzige Verbindung ihn allein beschäftigt.

timeout ist die Lesezeitschranke für die Spielerverbindung, server_connect_timeout die Wartezeit beim Verbinden zum Backend. Setzen Sie die erste nicht zu niedrig, sonst fliegen Spieler mit schwankender Verbindung heraus, und nicht zu hoch, sonst halten halboffene Sitzungen ihren Speicher lange.

4. login-ratelimit und Zeitschranken in Velocity

Velocity nennt dieselbe Bremse anders und stellt sie im Abschnitt [advanced] der velocity.toml ein:

[advanced]
login-ratelimit = 3000
connection-timeout = 5000
read-timeout = 30000
compression-threshold = 256
command-rate-limit = 50
kick-after-rate-limited-commands = 0
tab-complete-rate-limit = 10
log-player-connections = true
enable-reuse-port = false

login-ratelimit ist die Mindestzeit in Millisekunden, die zwischen zwei Verbindungen derselben IP-Adresse liegen muss, Voreinstellung drei Sekunden, und der Wert 0 schaltet die Bremse ab. connection-timeout gilt für den Verbindungsaufbau zum Backend, read-timeout für das Lesen von einer Verbindung. command-rate-limit begrenzt Befehle auf einen alle 50 Millisekunden, also zwanzig pro Sekunde, was Befehlsfluten von übernommenen Konten abfängt.

enable-reuse-port ist der Punkt, den man unter Last kennen sollte. Velocity nimmt Verbindungen standardmäßig in einem einzigen Thread an und verteilt sie danach. Mit true nutzt der Proxy die Kernelfunktion SO_REUSEPORT, sodass mehrere Threads gleichzeitig annehmen. Auf einem Mehrkernsystem mit sehr vielen eingehenden Verbindungen ist das genau der Engpass, der die Annahme-Warteschlange aus Punkt 2 überlaufen lässt. Die Funktion braucht Linux, und sie will vor dem Ernstfall getestet sein.

5. Den Anmeldeweg dicht machen

Drei Einstellungen entscheiden darüber, wie teuer ein Bot-Join für den Angreifer ist. In der velocity.toml:

online-mode = true
force-key-authentication = true
prevent-client-proxy-connections = false
kick-existing-players = false

online-mode = true ist die wichtigste Zeile des gesamten Beitrags für alles, was nicht reine Bandbreite ist. Sie erzwingt die Mojang-Anmeldung am Proxy, und damit kostet jeder Bot ein gekauftes Konto. In BungeeCord heißt dieselbe Einstellung online_mode: true und steht ebenfalls ab Werk an.

prevent-client-proxy-connections kickt Spieler, deren Netzbetreiber laut Mojang-Authentifizierungsserver ein anderer ist als der, von dem die Verbindung kommt. Das trifft Anonymisierungsdienste, trifft aber auch Spieler mit Mobilfunkanschluss oder betrieblichem Netzzugang. Velocity nennt es selbst eine schwache Schutzform. Schalten Sie es nur ein, wenn Sie ein konkretes Problem damit haben, und rechnen Sie mit Beschwerden. Das Gegenstück in BungeeCord heißt prevent_proxy_connections und steht ab Werk auf false.

kick-existing-players entscheidet, was passiert, wenn dasselbe Konto ein zweites Mal verbindet. Mit false wird die neue Verbindung abgelehnt, mit true die alte getrennt. Unter Beschuss ist false die ruhigere Wahl, weil ein Angreifer mit einem gestohlenen Konto sonst Ihre echten Spieler im Wechsel hinauswirft.

6. Warteschlange und vorgeschalteter Prüfschritt

Gegen Bot-Joins und gegen Beitrittswellen nach einem Neustart hilft eine Warteschlange. Das Prinzip: Der Spieler landet nach der Anmeldung nicht sofort auf der Lobby, sondern in einem minimalen Wartebereich, und von dort werden die Spieler mit einer festen Rate weitergeleitet. Der Wartebereich ist kein vollwertiger Server, sondern eine leere Welt ohne Weltgenerierung, ohne Entitäten und ohne Plugins, die der Proxy selbst bereitstellt.

Zwei Dinge gewinnen Sie dadurch. Erstens trifft eine Beitrittswelle nicht mehr Ihre echten Backends, sondern einen Bereich, in dem ein Spieler ein paar Kilobyte kostet statt eines geladenen Chunk-Bereichs. Zweitens haben Sie einen Ort, an dem sich Bots aussortieren lassen, bevor sie irgendetwas anfassen: Ein Bot, der stur ein Beitrittspaket sendet, verhält sich anders als ein echter Client, der auf Schwerkraft reagiert, seine Client-Einstellungen sendet und auf Transaktionen antwortet.

Für Velocity gibt es diese Familie fertig: LimboAPI stellt die virtuellen Wartebereiche bereit, LimboQueue setzt darauf die Warteschlange und LimboFilter den vorgeschalteten Prüfschritt samt Fallprüfung und optionalem Bildrätsel. Eigenständige schlanke Wartebereiche wie NanoLimbo lassen sich mit BungeeCord und Velocity gleichermaßen als normales Backend eintragen. Welches Werkzeug Sie wählen, ist zweitrangig, das Prinzip ist der Gewinn.

Ein Hinweis zur Reihenfolge: Eine Warteschlange löst kein Bandbreitenproblem. Sie wirkt gegen Anmeldungen, nicht gegen Pakete. Wenn Ihr Anschluss voll ist, erreicht der Wartebereich niemanden mehr.

7. Die Verbindungsverfolgung des Kernels im Blick behalten

Ein Engpass, der bei einer Verbindungsflut früh zuschlägt: Der Kernel legt für jede Verbindung einen Eintrag in der Verbindungsverfolgung an. Läuft die Tabelle voll, verwirft er auch Pakete echter Spieler, und im Systemprotokoll steht nf_conntrack: table full, dropping packet.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
conntrack -S
dmesg -T | grep -i conntrack | tail -20

Liegt der Zählerstand dauerhaft nahe an der Obergrenze, erhöhen Sie die Tabelle und verkürzen zugleich die Zeitschranke für halboffene Verbindungen:

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_recv=20
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

Die dritte Zeile verdient eine Erklärung, weil sie bei anderen Diensten gefährlich wäre. Die Voreinstellung für aufgebaute Verbindungen sind fünf Tage. Bei Minecraft können Sie deutlich kürzer gehen, weil das Protokoll regelmäßig Keep-Alive-Pakete sendet: Der Server schickt sie etwa alle fünfzehn Sekunden, und bleibt die Antwort aus, trennt er die Verbindung ohnehin. Eine Stunde ist also reichlich bemessen. Rechnen Sie außerdem mit rund 300 Byte Arbeitsspeicher je Eintrag, eine Million Einträge kosten Sie also etwa 300 MB.

8. Messwerte sammeln, bevor es knallt

Der Schritt, den fast niemand vorher macht: eine Vergleichsbasis anlegen, solange alles normal läuft. Ohne Normalwert können Sie nach einem Vorfall nicht sagen, ob 900 neue Verbindungen pro Minute viel waren oder einfach Freitagabend. Mit apt-get install -y vnstat sysstat conntrack läuft die Messung dauerhaft mit.

sar -n DEV 1 10
sar -n TCP,ETCP 1 10
ss -s
ss -tn state syn-recv '( dport = :25565 or sport = :25565 )' | wc -l
nstat -az | grep -E 'TcpActiveOpens|TcpPassiveOpens|TcpAttemptFails|TcpExtListenOverflows'
ip -s link show eth0

Vier Werte sind bei einem Proxy besonders aussagekräftig. TcpPassiveOpens zählt die eingehenden Verbindungen und ist die Zahl, die bei einer Verbindungsflut als Erstes explodiert. Die Anzahl der Verbindungen im Zustand SYN-RECV zeigt eine SYN-Flut unmittelbar. TcpExtListenOverflows beweist, dass der Proxy nicht mehr hinterherkommt. Und TcpAttemptFails steigt, wenn Verbindungen scheitern, was ein guter Frühindikator für einen gesättigten Anschluss ist. Wie Sie die Werte auswerten, steht in DDoS-Angriff erkennen.

Dazu kommen die Werte des Proxys selbst. Bei einer Java-Anwendung ist der belegte Halden-Speicher die Größe, die eine Flut halboffener Anmeldungen als Erstes sichtbar macht. Läuft er voll, bricht der Proxy mit einem Speicherfehler ab, und alle Spieler des Netzwerks sind gleichzeitig draußen. Wie Sie das messen und beheben, steht in Minecraft Out of Memory: Java Heap Space beheben. Ruckelt es dagegen ohne auffällige Netzwerkwerte, liegt es meist an einem Backend, und dafür ist Minecraft-Server-Lag beheben der passende Beitrag.

BungeeCord, Waterfall oder Velocity: was für den Schutz zählt

Die Wahl des Proxys ist keine Geschmacksfrage mehr, seit PaperMC am 26. März 2024 das Ende von Waterfall bekanntgegeben hat. Der Stand in der Sache:

Sachlich zusammengefasst: Velocity ist neuer, nimmt Verbindungen effizienter an und hat als einziges der drei ein Weiterleitungsmodell mit kryptographischer Prüfung. Waterfall war der gepflegte BungeeCord-Zweig, bis PaperMC das Projekt beendet hat, und ist damit für ein neues Netzwerk keine sinnvolle Wahl mehr. BungeeCord bleibt richtig, wenn Sie auf Plugins angewiesen sind, die es nur dort gibt, oder wenn Sie Backends unter 1.13 bedienen müssen. Wer BungeeCord behält, muss die Firewallregel aus dem zweiten Kapitel umso ernster nehmen, denn dort ist sie der einzige Schutz vor der Übernahme beliebiger Spielerprofile.

Wo diese Maßnahmen aufhören: Bandbreite und Paketrate

Jetzt der Teil, den keine Konfigurationsdatei lösen kann. Alle bisherigen Maßnahmen laufen auf Ihrem Server, also am Ende der Leitung. Eine Firewallregel entscheidet über ein Paket, das bereits über das Kabel gelaufen ist. Sie können es verwerfen, aber nicht ungesendet machen.

Rechnen Sie einmal mit. Ihre Leitung ist voll, sobald jemand mehr als 125 Megabyte pro Sekunde schickt. Ein Angriff von 5 bis 50 Gbit/s liegt beim Fünf- bis Fünfzigfachen davon. Ob Ihre nftables-Regel dahinter gut ist, spielt dann keine Rolle mehr, denn die Pakete Ihrer Spieler kommen schon vorher nicht durch.

Bei einem Proxy kommt eine zweite Grenze dazu, die vor der Bandbreite zuschlägt. Jede neue Verbindung kostet Rechenzeit im Kernel und im Proxy, und die Anmeldung kostet zusätzlich eine Anfrage an die Mojang-Server. Ein Angriff, der Ihre Leitung nicht einmal zu einem Zehntel füllt, kann Ihren Proxy trotzdem unerreichbar machen, weil die Annahme-Warteschlange überläuft. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem kam niemand mehr rein". Im Spiel äußert sich dasselbe als Zeitüberschreitung beim Verbinden, während die bereits verbundenen Spieler noch eine Weile weiterspielen.

Dafür gibt es keine lokale Einstellung. Volumetrische Angriffe und große Verbindungsfluten müssen im Netz vor dem Server enden.

Reverse-Proxy-Netze wie TCPShield: ein anderer Ansatz

Ein verbreiteter Weg unter Minecraft-Netzwerken sind vorgeschaltete Reverse-Proxy-Dienste, TCPShield ist der bekannteste davon, NeoProtect und ähnliche Anbieter arbeiten nach demselben Muster. Das Prinzip: Sie tragen im DNS einen CNAME auf das Netz des Anbieters ein, die Spieler verbinden sich dorthin, der Dienst filtert und reicht den sauberen Verkehr an Ihren Proxy weiter. Die echte Spieler-IP kommt über ein Plugin oder über das PROXY-Protokoll bei Ihnen an, und Ihre Firewall lässt auf 25565 nur noch die Adressbereiche des Anbieters zu.

Das ist ein sauberer Ansatz und für viele Netzwerke eine gute Lösung, gerade wenn der Server bei einem Anbieter ohne eigene Filterung steht. Drei Punkte sollten Sie dabei kennen, und keiner davon ist ein Vorwurf, sondern schlicht eine Eigenschaft des Modells.

Erstens hängt der Schutz an der Firewallregel. Wer den CNAME einträgt, aber seinen Proxy weiter für die ganze Welt offen lässt, wird weiterhin direkt angegriffen. Die Adressliste des Anbieters muss gepflegt werden, sonst sperren Sie nach einer Erweiterung des Netzes Ihre eigenen Spieler aus.

Zweitens schützt das Modell den Spielverkehr, nicht den Server. Ihre echte Adresse bleibt angreifbar, sobald sie jemand kennt, und sie steht weiterhin in jedem alten DNS-Datensatz. Andere Dienste auf demselben Rechner, etwa ein Webpanel oder eine Datenbank, liegen außerhalb dieses Schutzes.

Drittens ist der Verkehr an einer zusätzlichen Stelle sichtbar. Das ist bei jedem vorgeschalteten Dienst so und kein Sonderfall.

Der Unterschied zur Filterung im eigenen Netz des Anbieters ist der Ort: Dort liegt der Schutz auf dem Weg zu Ihrem Server, ohne dass eine zweite Partei den Verkehr weiterreichen muss und ohne dass Ihre Adresse ein zweites Mal auftauchen kann. Beides funktioniert, es sind unterschiedliche Bauweisen.

Was KernelHost gegen DDoS-Angriffe auf Minecraft-Proxys stellt

Der Dauerschutz, der auf jedem Server inklusive ist

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und dauerhaft aktiv, ohne dass Sie etwas einschalten, bestellen oder konfigurieren müssen:

• Stufe 1: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk. Volumetrische Angriffe werden nah an ihrer Quelle bereinigt, bevor sie das Rechenzentrum erreichen.
• Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster erkannt und verworfen, Paket für Paket. Dazu gehören Verbindungsfluten auf 25565 TCP ebenso wie Handshake-Muster, die kein Minecraft-Client erzeugt.

Zwei Eigenschaften sind entscheidend. Der Schutz läuft permanent und muss nicht erst auf einen Angriff reagieren, es gibt also keine Minuten am Anfang, in denen der Proxy weg ist und Ihr gesamtes Netzwerk mit ihm. Und es wird kein Nullrouting eingesetzt: Ihre IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Wer die IP-Adresse aus dem Netz nimmt, erreicht für Sie dasselbe Ergebnis wie der Angreifer. Der Standort ist Frankfurt am Main. Welche Spiele und Protokolle abgedeckt sind, listet Gameserver-DDoS-Schutz in Echtzeit, die Funktionsweise der Filterung beschreibt Game-DDoS-Schutz mit Echtzeit-Filterung.

Advanced DDoS Protection, und warum die Schutz-IP auf den Proxy gehört

Manche Netzwerke werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen, und das trifft besonders die, die gerade wachsen. Dafür gibt es die Advanced DDoS Protection ab 50,00 € im Monat, PrePaid und ohne Mindestlaufzeit. Der Unterschied liegt nicht in mehr Kapazität, sondern in der Kontrolle:

• Dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server im eigenen Netz umgestellt wird. Auf Ihrer Seite ist kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich: Sie stellen getrennt ein, was auf 25565 TCP erlaubt ist, was auf 25577 TCP, und was auf 19132 UDP, falls Geyser danebensteht.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, statt auf ein Wartungsfenster zu warten.
• Schutzprofil passend zum jeweiligen Spiel. Für Minecraft gibt es fertige Profile, ebenso für eigene Anwendungen auf beliebigen TCP- oder UDP-Ports, also auch für einen Proxy auf einem selbst gewählten Port.

Und jetzt der Satz, auf den es bei einem Proxy-Netzwerk ankommt: Die Schutz-IP gehört auf den Proxy, nicht auf die Backends. Der Proxy ist die einzige Adresse, die Ihre Spieler kennen, und damit der einzige Punkt, an dem Schutz überhaupt wirken kann. Die Backends sollen nach dem zweiten Kapitel dieses Beitrags ohnehin von außen nicht erreichbar sein, und eine Schutz-IP für eine Adresse, die niemand erreichen kann, schützt nichts. Liegen Proxy und Backends auf verschiedenen Rechnern, bekommt der Proxy die Schutz-IP, und die Backends bekommen eine Firewallregel.

Die beiden Stufen im Vergleich

Für die meisten Proxy-Netzwerke reicht der inkludierte Dauerschutz zusammen mit geschlossenen Backends und einer sauberen Proxy-Konfiguration. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt. Wer sein Netzwerk derzeit woanders betreibt, löst das Problem am ehesten mit einem Umzug: Die Filterung wirkt im Netz vor dem Server, und dieses Netz muss uns gehören.

Häufige Fehler und Lösungen

"Spieler mit gefälschten Namen joinen, obwohl der Proxy im Online-Modus läuft": Ihre Backends sind aus dem Internet erreichbar, und die Angreifer verbinden sich direkt. Prüfen Sie das mit einem Portscan von außen, schließen Sie die Ports und stellen Sie auf Modern Forwarding oder BungeeGuard um. Solange die legacy-Weiterleitung ohne Firewallregel läuft, kann jeder einen beliebigen Namen und eine beliebige UUID behaupten.

"Nach der Umstellung auf Velocity haben alle Spieler ihr Inventar verloren": Der Wert proxies.velocity.online-mode auf den Backends passt nicht zu online-mode in der velocity.toml. Beide müssen gleich sein, sonst berechnet der Server andere UUIDs und legt für jeden Spieler ein neues Profil an. Stellen Sie den Wert zurück, die alten Profildateien sind unter ihrer ursprünglichen UUID noch da.

"Velocity meldet, der Schlüssel sei ungültig": Fast immer liegt ein Zeilenumbruch oder ein Leerzeichen am Ende der Datei forwarding.secret oder im Feld secret der paper-global.yml. Prüfen Sie mit od -c forwarding.secret | tail -2, ob die Datei wirklich mit dem letzten Zeichen des Schlüssels endet.

"Der Proxy nimmt keine neuen Verbindungen mehr an, die Auslastung ist aber niedrig": Das ist die Annahme-Warteschlange. Prüfen Sie nstat -az | grep ListenOverflows und ss -ltn '( sport = :25565 )'. Steigt der Zähler und ist Recv-Q dauerhaft am Anschlag, erhöhen Sie net.core.somaxconn und probieren Sie bei Velocity enable-reuse-port = true.

"Meine Protokolldatei ist über Nacht auf 40 GB gewachsen": Das ist eine Ping-Flut in Verbindung mit log_pings: true, der Voreinstellung von BungeeCord. Setzen Sie den Wert auf false, bei Velocity prüfen Sie show-ping-requests und log-player-connections im Abschnitt [advanced]. Richten Sie zusätzlich eine Rotation ein, bevor die volle Platte den Proxy anhält. Was Sie bei voller Platte sofort tun können, steht in Festplatte voll unter Linux.

"Meine nftables-Regel zählt null Treffer": Drei Ursachen sind häufig. Die Regel steht in einer Kette, die nie durchlaufen wird, sie wurde nach dem letzten Neustart nicht wieder geladen, oder der Angriff ist volumetrisch und die Regel arbeitet korrekt an einem Anschluss, der schon gesättigt ist. Prüfen Sie mit nft list ruleset und achten Sie auf die counter-Werte.

"Eigene Spieler fliegen raus, seit ich die Verbindungsbremse schärfer gestellt habe": Ein einzelner Minecraft-Client öffnet mehrere Verbindungen kurz hintereinander, weil die Serverliste jeden Eintrag abfragt. Dazu kommen Spieler, die sich eine Adresse teilen. Gehen Sie bei connection_throttle_limit nicht unter 2 und bei login-ratelimit nicht über 5000, und prüfen Sie Ihre Werte gegen eine Woche Normalbetrieb.

"Mein bisheriger Anbieter hat meine IP-Adresse gesperrt": Das ist Nullrouting. Der Anbieter schützt damit sein eigenes Netz, für Sie ist das Ergebnis identisch mit einem erfolgreichen Angriff, meist noch für Stunden danach. Bei einem Proxy-Netzwerk ist der Schaden maximal, weil das Netzwerk keinen zweiten Eingang hat. Fragen Sie im Zweifel nach, ob gefiltert oder nullgeroutet wird. Die Antwort entscheidet mehr über Ihre Verfügbarkeit als jede Hardwareangabe.

"Im Mitschnitt sehe ich nichts Auffälliges": Wird der Verkehr schon im Netz davor gefiltert, kommt auf dem Server erwartungsgemäß nichts an. Das ist der Normalfall bei funktionierender Filterung. Umgekehrt gilt: Ist der Anschluss gesättigt, erreicht Sie unter Umständen nicht einmal mehr die SSH-Sitzung, mit der Sie messen wollten. Nutzen Sie dann die VNC-Konsole im Kundenbereich, die unabhängig vom Netzwerk des Gastsystems funktioniert.

Kurz zusammengefasst

• Ein Minecraft-Proxy-Netzwerk braucht genau einen offenen Port nach außen: den des Proxys. Velocity lauscht ab Werk auf 25565 TCP, BungeeCord und Waterfall auf 25577 TCP. Backends, Query auf 25565 UDP und RCON auf 25575 TCP gehören hinter die Firewall.
• Erreichbare Backend-Server sind der teuerste Fehler im gesamten Aufbau. Sie machen jede Maßnahme am Proxy wirkungslos, und mit der legacy-Weiterleitung erlauben sie jedem, sich als beliebiger Spieler auszugeben, einschließlich Ihrer Operatoren.
• Velocity Modern Forwarding prüft die weitergereichten Spielerdaten mit einem gemeinsamen Schlüssel und setzt Minecraft 1.13 auf dem Backend voraus. BungeeCord ip_forward prüft nichts, BungeeGuard schiebt ein Token nach. Die Firewallregel ersetzt keines der Verfahren und wird durch keines ersetzt.
• Die Statusantwort verrät Version, Spielerzahl und eine Stichprobe der Spielernamen, bevor sich jemand angemeldet hat. Auf Backends gehört enable-status=false, am Proxy ping-passthrough = "disabled" und ein Zwischenspeicher für die Abfragen.
• Die vier Angriffsarten am Proxy sind Verbindungsflut auf 25565, Handshake ohne Login, Ping-Flut auf die Serverliste und Bot-Joins mit gültigem Handshake. Die ersten drei kosten den Angreifer fast nichts und Sie Speicher.
• Lokal helfen eine Obergrenze je Quelladresse mit nftables, SYN-Cookies mit einer ausreichend großen Annahme-Warteschlange, connection_throttle: 4000 mit connection_throttle_limit: 3 in BungeeCord, login-ratelimit = 3000 in Velocity und eine Warteschlange vor der Lobby.
• Ab etwa 1 Gbit/s ist Ihre Leitung voll, und bei 64 Byte großen Paketen passen dort rund 1,49 Millionen Pakete pro Sekunde hinein. Bei einem Proxy läuft aber meist schon vorher die Annahme-Warteschlange über. Darüber entscheidet ausschließlich die Filterung im Netz vor dem Server.
• Bei KernelHost ist der zweistufige Dauerschutz in jedem Serverpaket enthalten, ab Bereitstellung aktiv und ohne Nullrouting. Die Advanced DDoS Protection ergänzt ihn um eine dedizierte Schutz-IP, und diese Schutz-IP gehört auf den Proxy.

Läuft Ihr Netzwerk bereits bei KernelHost, ist die Filterung aktiv, ohne dass Sie etwas tun müssen. Bemerken Sie trotzdem Auffälligkeiten, eröffnen Sie ein Support-Ticket, damit die Filterregeln für Ihre IP-Adresse nachjustiert werden. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfallchat unter +43 650 8209883.