Minecraft-Bedrock-Server vor DDoS-Angriffen schützen

Ein Minecraft-Bedrock-Server, der abends für ein paar Minuten aus der Serverliste verschwindet und danach wiederkommt, hat selten ein Hardwareproblem. Meistens läuft ein Angriff, und er läuft genau dann, wenn die meisten Spieler online sind. Dieser Beitrag zeigt, wie Sie einen Minecraft-Bedrock-Server vor DDoS-Angriffen schützen: zuerst das, was Sie ohne Zusatzkosten selbst absichern können, danach die Stelle, an der diese Maßnahmen physikalisch aufhören, und zum Schluss, was im Netz vor dem Server passieren muss.

Alle Angaben beziehen sich auf einen Bedrock Dedicated Server, PocketMine-MP oder Nukkit 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. Wer die Java Edition betreibt, findet die dort typischen Protokollangriffe in Minecraft-DDoS-Schutz und Nullping-Schutz. Die reine Installation eines Bedrock-Servers beschreibt Minecraft-Bedrock-Server mit Nukkit installieren.

Wenn der Angriff gerade läuft: Ändern Sie jetzt nichts an der Konfiguration und starten Sie den Server nicht neu. Sichern Sie zuerst die Messwerte (Abschnitt "Messwerte sammeln, bevor es knallt"), nach dem Angriff sind sie unwiederbringlich weg.

Warum Minecraft-Bedrock-Server so oft Ziel von DDoS-Angriffen sind

Die Bedrock Edition ist die Fassung, die auf Konsolen, Smartphones, Tablets und Windows läuft, und sie stellt die größte Spielerbasis von Minecraft überhaupt. Wo viele Server stehen, entsteht der größte Anreiz für Angriffe: konkurrierende Netzwerke, gebannte Spieler, interne Streitigkeiten. Ein Angriff kostet den Auslöser dabei weder Können noch nennenswertes Geld, ein Server-Booter wird im Abonnement verkauft.

Der technische Grund liegt tiefer. Ein Bedrock-Server spricht UDP, nicht TCP, und er antwortet jedem, der fragt, lange bevor irgendeine Anmeldung stattgefunden hat. Genau diese beiden Eigenschaften machen Port 19132 UDP zu einem dankbaren Ziel. Was ein DDoS-Angriff grundsätzlich ist, erklärt der Beitrag Was ist ein DDoS-Angriff?.

RakNet: ein UDP-Protokoll, das antwortet, bevor sich jemand angemeldet hat

RakNet ist die UDP-Netzwerkbibliothek, über die die Minecraft Bedrock Edition ihren gesamten Spielverkehr abwickelt. UDP kennt keinen Verbindungsaufbau, den ein Server verlangen könnte, und Absenderadressen lassen sich deshalb fälschen. RakNet baut seine eigene Zuverlässigkeitsschicht darüber: Sequenznummern, Bestätigungen (ACK) und Negativbestätigungen (NAK), mit denen ein Client verlorene Pakete nachfordern kann.

Der Verbindungsaufbau besteht aus sieben Paketen, vier vom Client und drei vom Server:

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

Erst danach sendet der Client das Login-Paket mit seinen Xbox-Live-Nachweisen. Das ist der entscheidende Satz für jeden, der seinen Bedrock-Server absichern will: Der Server hat sieben Pakete verarbeitet, Rechenzeit und Speicher aufgewendet und mehrfach geantwortet, bevor er überhaupt erfährt, wer da anklopft. Jede Maßnahme, die an der Anmeldung ansetzt, greift also erst, nachdem die Last bereits entstanden ist.

Dazu kommt ein zweiter, noch früherer Einstiegspunkt. Damit ein Server in der Serverliste eines Spielers mit Name, Version und Spielerzahl erscheint, beantwortet er den Unconnected Ping (Paket-ID 0x01) mit einem Unconnected Pong (Paket-ID 0x1C). Dieser Austausch findet vor dem eigentlichen Verbindungsaufbau statt, verlangt keinerlei Nachweis und lässt sich beim Bedrock Dedicated Server nicht abschalten, ohne den Server aus jeder Serverliste zu nehmen.

Unconnected Ping als Verstärkungsvektor: die Zahlen

Ein Verstärkungsangriff (Amplification) ist ein Angriff, bei dem der Angreifer kleine Anfragen mit gefälschter Absenderadresse an fremde Server schickt, damit deren größere Antworten beim Opfer landen. Der Bedrock-Server wird dabei nicht angegriffen, sondern benutzt. Beim Unconnected Ping sieht die Rechnung so aus:

Zwei Dinge folgen daraus unmittelbar. Erstens: Ein langer Servername vergrößert die Antwort und damit den Verstärkungsfaktor, den Sie fremden Angreifern zur Verfügung stellen. Ein kurzer Name ist keine Kosmetik, sondern eine Schutzmaßnahme. Zweitens: Der Faktor 4 der Standardkonfiguration ist klein genug, dass Ihr Server als Reflektor uninteressant bleibt, aber groß genug, dass eine Ping-Flut Ihre eigene Ausgangsleitung mit dem Vierfachen dessen belastet, was hereinkommt.

Der Verstärkungsfehler von 2024 zeigt, wie schlimm es werden kann, wenn die Zuverlässigkeitsschicht selbst missbraucht wird. In der damals verwendeten RakNet-Bibliothek war das Paket Connection Request Accepted als zuverlässig markiert. Ein Angreifer konnte den Verbindungsaufbau mit gefälschter Absenderadresse bis zu diesem Punkt durchspielen und danach eine einzige Negativbestätigung mit dem Bereich 0 bis 8191 schicken. Der Server sendete daraufhin tausende Pakete an die gefälschte Adresse, ohne dass der Angreifer weiter etwas tun musste. Behoben wurde das, indem das Paket auf unzuverlässig umgestellt wurde, indem in Open Connection Reply 1 ein Cookie mitgeschickt wird, das ein echter Client zurückspiegelt, und indem Paketgrenzen eingezogen wurden: 120 Pakete je Quelladresse und 10-Millisekunden-Takt, 1.000 Pakete insgesamt je Takt.

Bedrock Edition oder Java Edition: was beim DDoS-Schutz anders ist

Wer schon einmal einen Java-Server abgesichert hat, überträgt fast alles falsch. Die beiden Editionen teilen den Namen, aber nicht das Netzwerkprotokoll:

Die Zeile zu den SYN-Cookies ist die wichtigste. Bei der Java Edition wehrt der Linux-Kernel eine SYN-Flut ab, ohne dass der Minecraft-Prozess davon etwas merkt. Bei der Bedrock Edition gibt es diese Hilfe nicht: Jedes einzelne UDP-Paket wird bis in den Serverprozess durchgereicht und dort ausgewertet. Ein Bedrock-Server hat gegen einen Flood auf Port 19132 keinen eingebauten Schutz im Betriebssystem, weil UDP keinen kennt.

Die Zeile zum fehlenden SRV-Eintrag hat eine praktische Folge, die viele überrascht: Sie können den Port bei der Bedrock Edition nicht hinter einem DNS-Eintrag verstecken. Spieler tragen Adresse und Port von Hand ein. Wer den Port verlegt, muss jedem Spieler den neuen Port mitteilen.

Die Ports, um die es tatsächlich geht

Ein Bedrock Dedicated Server bindet sich auf genau zwei Ports, und zwar auf beiden über UDP. In der server.properties:

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

Das sind die Voreinstellungen von Microsoft, nachzulesen in der Referenz zum Bedrock Dedicated Server. Rund um diese beiden Ports liegen weitere Dienste, die je nach Serversoftware mitlaufen:

Die dritte und die vierte Zeile sind die häufigsten vermeidbaren Fehler auf Bedrock-Servern. Bei Nukkit und PocketMine-MP steht enable-query ab Werk auf an, und bei Nukkit landet ein versehentlich eingeschaltetes RCON auf 19132 TCP, also auf derselben Portnummer wie das Spiel. Wer nur nach "19132 ist offen, passt schon" schaut, übersieht das.

Eine Eigenheit des offiziellen Bedrock Dedicated Server gehört ebenfalls hierher: Er kennt keine Direktive server-ip. PocketMine-MP und Nukkit haben sie (server-ip, bei PocketMine zusätzlich server-ipv6), der offizielle Server nicht. Er lauscht also immer auf allen Adressen des Systems, und die Firewall ist Ihre einzige Möglichkeit, das einzuschränken.

Was Sie selbst tun können, bevor Sie Geld ausgeben

Dieser Abschnitt ist der längste, und das mit Absicht. Ein sauber konfigurierter Bedrock-Server hält kleine und mittlere Angriffe aus eigener Kraft aus, unabhängig davon, bei wem er steht.

1. Bestandsaufnahme: was lauscht überhaupt auf 19132?

Bevor Sie eine einzige Regel schreiben, sehen Sie nach, was Ihr Server nach außen anbietet. Nicht raten, nachsehen:

ss -lntup
ss -lnup sport = :19132

Interessant ist die Spalte mit der lokalen Adresse. 0.0.0.0:19132 und [::]:19133 bedeuten "aus dem ganzen Internet erreichbar". Taucht daneben ein TCP-Eintrag auf derselben Portnummer auf, läuft RCON. Die Sicht des Angreifers liefert ein Portscan von außen, für UDP mit -sU:

nmap -Pn -sU -p 19132,19133 IHRE.SERVER.IP.ADRESSE
nmap -Pn -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

2. Nur 19132 UDP offen lassen, alles andere schließen

Für einen Bedrock-Server reicht eine einzige Freigabe nach außen, zwei mit IPv6. Mit UFW sieht das so aus, und zwar genau in dieser Reihenfolge, damit Sie sich nicht selbst aussperren:

ufw allow 22/tcp comment 'SSH'
ufw allow 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Haben Sie keine IPv6-Spieler, lassen Sie die Zeile für 19133 weg und setzen bei PocketMine-MP zusätzlich enable-ipv6=false. Jeder Port, den Sie nicht freigeben, ist ein Port, den Sie nicht verteidigen müssen. Die vollständige Anleitung samt Rettungsweg steht in UFW-Firewall einrichten, ohne sich selbst auszusperren.

3. Die LAN-Sichtbarkeit abschalten, sonst bleibt 19132 offen

Das ist die Falle, in die fast jeder tappt, der den Port verlegen will. Die Direktive enable-lan-visibility steht ab Werk auf true und sorgt dafür, dass der Server auf Suchanfragen im lokalen Netz antwortet. Microsoft schreibt dazu ausdrücklich, dass der Server dadurch zusätzlich auf die Standardports 19132 und 19133 bindet, auch wenn server-port und server-portv6 andere Werte haben.

Wer also den Port auf 19140 verlegt und sich in Sicherheit wiegt, lauscht weiterhin auf 19132. Für einen Server im Internet gehört deshalb in die server.properties:

enable-lan-visibility=false

Danach mit ss -lnup gegenprüfen, dass 19132 wirklich verschwunden ist. Nebenbei löst dieselbe Einstellung das Problem, dass zwei Bedrock-Server auf demselben Host sich gegenseitig den Port wegnehmen.

4. Query und RCON abschalten

PocketMine-MP und Nukkit bringen den GS4-Query mit, eine UDP-Serverabfrage nach dem Muster des UT3-Protokolls, und sie beantworten diese Abfragen auf demselben Port 19132, auf dem das Spiel läuft. Die ausführliche Antwort enthält den Servernamen, die Version, den Weltnamen, den Zustand der Whitelist, Adresse und Port, die Spielerzahl, die Namen aller verbundenen Spieler und bei PocketMine-MP auf Wunsch die vollständige Plugin-Liste. Das ist praktisch für Statusseiten und Discord-Bots, verrät einem Angreifer aber genau, wann sich ein Angriff lohnt, und kostet je Abfrage Rechenzeit.

enable-query=off
enable-rcon=off

Bei PocketMine-MP lauten die Werte false statt off, und die Plugin-Liste schalten Sie in der pocketmine.yml mit settings.query-plugins: false ab. Eine Einordnung, die man selten liest: Der GS4-Query von PocketMine-MP prüft ein Token, das mit der Absenderadresse gesalzen ist. Die große Antwort lässt sich damit nicht an eine gefälschte Adresse reflektieren. Die Abfrage kostet trotzdem Rechenzeit, und die veröffentlichten Daten helfen dem Angreifer bei der Zielauswahl. Der offizielle Bedrock Dedicated Server kennt weder Query noch RCON, dort entfällt dieser Punkt.

Falls Sie RCON tatsächlich brauchen, setzen Sie bei Nukkit unbedingt rcon.port auf einen eigenen Wert und geben ihn nur für Ihre eigene Adresse frei. Der Rückfall auf server-port bedeutet sonst, dass eine Fernsteuerung Ihres Servers auf 19132 TCP lauscht, also auf derselben Zahl, die Sie ohnehin überall als "offen" eingetragen haben.

5. Xbox-Live-Authentifizierung erzwingen

Die Xbox-Live-Authentifizierung ist die Prüfung, ob ein beitretender Spieler ein echtes, von Microsoft signiertes Konto besitzt. Sie steht in allen drei Serversoftwares ab Werk an und muss dort auch bleiben.

Beim Bedrock Dedicated Server heißt die Direktive online-mode, bei PocketMine-MP und Nukkit heißt sie xbox-auth. In beiden Fällen ist true der Werkszustand und der richtige Wert:

online-mode=true
xbox-auth=true

Microsoft formuliert dazu eine wichtige Einschränkung: Clients, die sich mit einem Server außerhalb des lokalen Netzes verbinden, brauchen die Xbox-Live-Authentifizierung ohnehin immer, unabhängig von dieser Einstellung. Der Nachweis wird als signierte Token-Kette im Login-Paket übertragen, zusammen mit der Xbox-Kennung (XUID) und dem Anzeigenamen.

Und jetzt der Teil, der gegen Missverständnisse hilft: Die Xbox-Live-Authentifizierung schützt Ihre Spiellogik, nicht Ihre Leitung. Sie findet im Login-Paket statt, also nach dem vollständigen RakNet-Verbindungsaufbau. Ein Angreifer, der Ihren Server flutet, will gar nicht beitreten. Seine Pakete werden abgelehnt, sind aber trotzdem angekommen, und genau das ist der Punkt.

6. Allowlist und Spielerobergrenze, und was sie nicht leisten

Die Allowlist (früher Whitelist) ist die Liste der Spieler, die beitreten dürfen. Beim Bedrock Dedicated Server schalten Sie sie mit allow-list=true ein, die Einträge stehen in der allowlist.json mit Name, XUID und dem Feld ignoresPlayerLimit. Bei Nukkit und PocketMine-MP heißt die Direktive weiterhin white-list.

allow-list=true
max-players=60
player-idle-timeout=15

Eine kurze Leerlaufzeit über player-idle-timeout ist gegen Slot-Erschöpfung wirksam: Spieler, die nur einen Platz belegen, fliegen nach der angegebenen Minutenzahl heraus. Der Wert 0 bedeutet, dass niemand jemals wegen Untätigkeit getrennt wird, und genau das nutzt ein Angreifer aus, der mit echten Konten Ihre Plätze blockiert.

Auch hier gilt die Grenze aus dem vorigen Abschnitt, und sie ist der am häufigsten übersehene Punkt überhaupt: Die Allowlist wird erst geprüft, wenn das Login-Paket verarbeitet ist. Sie verhindert Beitritte, keine Pakete.

7. Paketraten je Quelladresse begrenzen

Gegen kleine Angriffe und unsaubere Bots hilft eine Obergrenze je Quelladresse. Für UDP arbeitet man mit hashlimit, nicht mit connlimit, denn UDP kennt keine Verbindungen:

iptables -I INPUT -p udp --dport 19132 -m hashlimit --hashlimit-name bedrock_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

Die Regel verwirft UDP-Pakete, sobald dieselbe Quelladresse dauerhaft mehr als 400 Pakete pro Sekunde schickt. Der Wert ist ein Startwert, keine Wahrheit: Ein voller Server mit 60 Spielern und großer Sichtweite erzeugt deutlich mehr Pakete als ein leerer, und wer zu eng einstellt, wirft eigene Spieler heraus. Messen Sie erst eine Woche im Normalbetrieb.

Deutlich schärfer stellen dürfen Sie beim Unconnected Ping, denn ein echter Client fragt den Serverstatus nur, solange die Serverliste geöffnet ist, und dann im Sekundentakt. Mit nftables lässt sich genau dieses eine Paket treffen, weil die Paket-ID das erste Byte hinter dem UDP-Kopf ist:

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

Der Ausdruck @th,64,8 liest acht Bit ab dem 64. Bit des Transportkopfes, also das erste Byte der UDP-Nutzlast. Der Wert 0x01 ist die Paket-ID des Unconnected Ping. Dieselbe Stelle können Sie zum Beobachten nutzen, bevor Sie irgendetwas verwerfen:

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

Die erste Zeile zählt eingehende Statusabfragen, die zweite Ihre eigenen Antworten. Laufen beide im Sekundentakt in die Tausende, während kaum jemand spielt, sehen Sie eine Ping-Flut und nicht Ihre Spieler.

Zwei Hinweise zur Haltbarkeit. Reine iptables-Regeln sind nach einem Neustart weg, unter Debian und Ubuntu sichert man sie so:

apt-get install -y iptables-persistent
netfilter-persistent save

Und unter UFW gehören solche Regeln in /etc/ufw/before.rules, weil sie sonst beim nächsten ufw reload verschwinden.

8. Die Verbindungsverfolgung des Kernels entlasten

Ein Engpass, der bei UDP-Spielen viel früher zuschlägt als bei TCP: Der Kernel legt für jedes UDP-Paketpaar einen Eintrag in der Verbindungsverfolgung an. Bei einer Flut mit gefälschten Absenderadressen ist jedes Paket eine neue Quelladresse und damit ein neuer Eintrag. Läuft die Tabelle voll, verwirft der Server auch legitime Pakete, und im Protokoll steht "nf_conntrack: table full, dropping packet".

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Steht der Zählerstand dauerhaft nahe an der Obergrenze, können Sie den Spielverkehr von der Verfolgung ausnehmen. Das ist wirksam, aber nicht folgenlos, deshalb in beide Richtungen und mit anschließendem Verbindungstest:

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

Danach greifen zustandsbasierte Regeln für diesen Verkehr nicht mehr. Ihre Freigabe für 19132 UDP muss also eine echte Portfreigabe sein und darf sich nicht auf den Zustand ESTABLISHED verlassen. Prüfen Sie nach dem Setzen mit conntrack -L | grep 19132, dass keine Einträge mehr entstehen, und verbinden Sie sich einmal mit dem Spiel, bevor Sie die Regeln dauerhaft speichern.

9. Geyser und Floodgate sauber betreiben

Geyser ist eine Brücke, die Bedrock-Clients auf einem Java-Edition-Server spielen lässt: Es nimmt auf 19132 UDP Bedrock-Verbindungen an, übersetzt das Protokoll und spricht auf der anderen Seite mit dem Java-Server auf 25565 TCP. Floodgate ist die Ergänzung, die diesen Bedrock-Spielern den Beitritt ohne Java-Konto erlaubt. Für den DDoS-Schutz bedeutet das drei Dinge.

Erstens: Halten Sie Geyser aktuell. Genau diese Brücke war zweimal der Grund für dokumentierte Angriffe. Im März 2024 wurde der oben beschriebene Verstärkungsfehler in der RakNet-Bibliothek breit ausgenutzt, behoben ab Build 478. Im Juli 2025 folgte ein zweiter Fall: Ein wiederholt gesendetes Paket zur Bestätigung der Ressourcenpakete erzeugte mehrere Sitzungen je Spieler, und getrennte Clients konnten weiter Pakete schicken, weil der Netzwerkkanal nicht geschlossen wurde. Behoben ab Build 897. Beide Fälle sind vom Projekt selbst mit Zeitleiste veröffentlicht worden.

Zweitens: Der Java-Server gehört nicht ins offene Netz. In der Geyser-Konfiguration zeigt remote.address auf auto beziehungsweise 127.0.0.1 und remote.port auf 25565. Binden Sie den Java-Server entsprechend lokal und geben Sie 25565 TCP nach außen nicht frei. Sonst haben Sie zwei Angriffsflächen statt einer, und die zweite ist die, für die Sie sich nie Regeln überlegt haben.

Drittens: Die Datei key.pem ist ein Geheimnis. Sie ist der Schlüssel, mit dem Floodgate die Java-Authentifizierung für Bedrock-Konten überspringt. Wer sie in ein öffentliches Repository legt, in ein Support-Ticket kopiert oder auf einem Screenshot zeigt, hat die Anmeldung seines Servers verschenkt. Das Projekt warnt davor ausdrücklich.

10. Messwerte sammeln, bevor es knallt

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

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

Drei dieser Werte sind bei einem Bedrock-Server besonders aussagekräftig. Ein dauerhaft von null verschiedenes Recv-Q auf dem UDP-Socket von 19132 bedeutet, dass der Serverprozess die ankommenden Pakete nicht mehr schnell genug abholt. UdpRcvbufErrors zählt genau die Pakete, die deshalb verworfen wurden, und ist der härteste Beleg dafür, dass nicht die Leitung, sondern der Prozess der Engpass ist. UdpNoPorts steigt, wenn jemand Ports beschießt, auf denen gar nichts lauscht, ein typisches Bild bei einem breit gestreuten Portscan vor dem eigentlichen Angriff.

Bei tcpdump gilt: immer mit -c begrenzen, ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Wie Sie die Werte auswerten, steht in DDoS-Angriff erkennen.

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 Firewall-Regel 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 hashlimit-Regel dahinter gut ist, spielt dann keine Rolle mehr, denn die Pakete Ihrer Spieler kommen schon vorher nicht durch.

Die zweite Größe ist die Paketrate, und bei einem Bedrock-Server schlägt sie fast immer zuerst zu. Der gesamte Spielverkehr besteht aus vielen kleinen UDP-Paketen, und genau in dieser Disziplin ist ein Angreifer am günstigsten unterwegs. Ein Angriff, der Ihre Leitung nicht einmal zu einem Drittel füllt, kann Ihren Server trotzdem lahmlegen, weil die Rechenzeit für das Auswerten und Verwerfen draufgeht. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem waren alle draußen". Im Spiel äußert sich dasselbe als Lag-Spitzen, Gummiband-Effekte und Verbindungsabbrüche mitten im Bauen.

Dafür gibt es keine lokale Einstellung. Volumetrische Angriffe müssen im Netz vor dem Server enden.

Was KernelHost gegen DDoS-Angriffe auf Bedrock-Server 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 auch UDP-Muster auf 19132, die kein RakNet-Verhalten zeigen.

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 Server weg ist. 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.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen. Dafür gibt es die Advanced DDoS Protection ab 50,00 EUR 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 ein, was auf 19132 UDP erlaubt ist, was auf 19133 UDP, und was auf einem abweichenden Port, falls Sie Ihren Server verlegt haben.
• Ä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 modifizierte und eigene Anwendungen auf beliebigen TCP- oder UDP-Ports, also auch für Nukkit, PocketMine-MP oder eine Geyser-Instanz auf einem selbst gewählten Port.

Die beiden Stufen im Vergleich

Für die meisten Bedrock-Projekte reicht der inkludierte Dauerschutz zusammen mit einer sauberen Serverkonfiguration. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt. Wer seinen Server 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

"Ich habe den Port auf 19140 geändert, 19132 ist trotzdem offen": Das ist enable-lan-visibility=true. Der Bedrock Dedicated Server bindet dann zusätzlich auf 19132 und 19133, egal was in server-port steht. Auf false setzen, Server neu starten, mit ss -lnup gegenprüfen.

"Ich habe die allowlist.json bearbeitet und komme selbst nicht mehr rein": Zwei Ursachen sind häufig. Es liegt noch eine alte whitelist.json im Verzeichnis, die der Server stattdessen liest, oder der XUID-Eintrag fehlt beziehungsweise ist falsch. Der Name allein genügt bei aktiver Xbox-Live-Authentifizierung nicht zuverlässig.

"Mein Hoster hat meinen Server gesperrt, obwohl ich der Angegriffene war": Prüfen Sie, ob Ihr Server selbst Pakete ausgesendet hat. Genau das passierte beim RakNet-Verstärkungsfehler von 2024: Die betroffenen Server schickten tausende Pakete an fremde Adressen, und in den Abuse-Meldungen stand Port 19132 als Quelle. Mit tcpdump -ni eth0 'udp src port 19132' -c 200 -q sehen Sie, wohin Ihr Server antwortet. Ein aktueller Build beseitigt die Ursache.

"Meine iptables-Regeln greifen nicht": Drei Ursachen sind häufig. Die Regeln stehen hinter den UFW-Ketten und werden nie erreicht, sie waren nach dem letzten Neustart weg (dann helfen netfilter-persistent save oder ein Eintrag in /etc/ufw/before.rules), oder der Angriff ist volumetrisch und die Regel arbeitet korrekt an einer Leitung, die schon voll ist. Prüfen Sie mit iptables -L INPUT -n -v, ob die Trefferzähler steigen. Bleiben sie bei null, wird die Regel nicht erreicht.

"Der Server steht in der Liste, aber niemand kommt rein": Wenn der Eintrag Name und Spielerzahl anzeigt, funktioniert der Unconnected Pong, also ist der Port grundsätzlich erreichbar. Scheitert der Beitritt trotzdem, hängt es meist an der Xbox-Live-Anmeldung oder an der Allowlist. Kommen umgekehrt nur IPv6-Spieler nicht rein, fehlt die Freigabe für 19133 UDP.

"Der Server läuft, aber alle haben Lag-Spitzen": Das ist häufiger ein Plugin als ein Angriff. Sehen Sie zuerst nach, ob Recv-Q auf dem UDP-Socket wächst und ob UdpRcvbufErrors steigt. Bleiben beide ruhig und sar -n DEV 1 10 unauffällig, war es kein DDoS-Angriff, sondern der Serverprozess selbst. Beim Bedrock Dedicated Server helfen dann die Skript-Wachhunde weiter, deren Schwellen in der server.properties unter script-watchdog-hang-threshold und script-watchdog-slow-threshold stehen.

"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. Fragen Sie im Zweifel nach, ob gefiltert oder nullgeroutet wird. Die Antwort entscheidet mehr über Ihre Verfügbarkeit als jede Hardwareangabe.

"Im tcpdump sehe ich nichts Auffälliges": Wenn der Verkehr schon im Netz davor gefiltert wird, kommt auf dem Server erwartungsgemäß nichts an. Das ist der Normalfall bei funktionierender Filterung. Umgekehrt gilt: Ist die Leitung 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-Bedrock-Server braucht genau einen offenen Port nach außen: 19132 UDP, dazu 19133 UDP nur für IPv6-Spieler. Query, RCON, der Skript-Debugger auf 19144 TCP und ein Java-Server hinter Geyser auf 25565 TCP gehören nicht ins offene Netz.
• Wer den Port verlegt, muss enable-lan-visibility=false setzen, sonst bindet der Bedrock Dedicated Server zusätzlich weiter auf 19132 und 19133.
• Xbox-Live-Authentifizierung und Allowlist greifen erst im Login-Paket, also nach dem vollständigen RakNet-Verbindungsaufbau. Sie schützen Ihre Spiellogik und Ihre Plätze, nicht Ihre Leitung.
• Der Unconnected Ping wird mit 33 Byte angefragt und mit rund 131 Byte beantwortet, ein Verstärkungsfaktor von etwa vier. Ein kurzer Servername hält diesen Faktor klein.
• Bei UDP hilft hashlimit statt connlimit, und die Verbindungsverfolgung des Kernels läuft bei gefälschten Absenderadressen als Erstes voll. Beides sollten Sie vor dem ersten Angriff gemessen haben.
• 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. 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 selbst verwaltbare Regeln je Port.

Läuft Ihr Projekt 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.