Mordhau-Server vor DDoS-Angriffen schützen

Ein Mordhau-Server, der mitten in der Frontline-Runde alle Spieler auf einmal verliert und danach für ein paar Minuten offline ist und nicht mehr in der Serverliste auftaucht, hat selten ein Hardwareproblem. In den allermeisten Fällen läuft ein Angriff auf einen der vier UDP-Ports, die ein Mordhau-Dedicated-Server nach außen offen halten muss. Dieser Beitrag zeigt zuerst, was Sie beim Mordhau-DDoS-Schutz ohne Zusatzkosten selbst erledigen können, danach, wo diese Maßnahmen physikalisch aufhören, und zum Schluss, was im Netz vor dem Server passieren muss.

Alle Angaben beziehen sich auf den offiziellen Mordhau-Dedicated-Server (Steam-App-ID 629800, Unreal Engine 4) 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. Läuft der Angriff gerade, ändern Sie zuerst nichts an der Konfiguration und starten Sie den Server nicht neu, sondern sichern Sie die Messwerte (Abschnitt 9), denn nach dem Angriff sind sie weg. Bei Mordhau kommt ein zweiter Grund dazu, den viele Betreiber schmerzhaft lernen: Der Serverprozess schreibt beim Beenden seinen Stand aus dem Arbeitsspeicher zurück in die Game.ini. Wer die Datei bei laufendem Server bearbeitet, verliert seine Änderungen beim nächsten Stopp.

Warum Mordhau-Server DDoS-Schutz brauchen und wer sie angreift

Mordhau-Server werden angegriffen, weil ihre Adresse öffentlich ist, der gesamte Spielverkehr über UDP läuft und ein Ausfall sofort für alle sichtbar wird. Der Eintrag im Serverbrowser enthält IP-Adresse und Spielport im Klartext, weil Spieler den Server sonst nicht finden könnten. Öffentliche Serverlisten und Tracker greifen dieselben Daten über den Steam-Abfrageport ab und veröffentlichen sie ein zweites Mal. Ihre Adresse ist damit kein Geheimnis, sondern eine Produktangabe.

Dazu kommt die Technik des Spiels. Unreal Engine 4 überträgt Bewegungen, Treffer und Paraden über UDP. UDP kennt keinen Verbindungsaufbau, den man verlangen könnte, und die Absenderadresse eines UDP-Pakets lässt sich fälschen. Ein Angreifer muss Ihren Server also weder betreten noch korrekt ansprechen, um Last zu erzeugen. Bei Mordhau wiegt das schwerer als bei vielen anderen Spielen: Ein Schlagabtausch entscheidet sich im Bereich weniger Zehntelsekunden, und schon 200 Millisekunden zusätzliche Verzögerung machen den Nahkampf unspielbar, lange bevor der Server tatsächlich ausfällt. Genau deshalb reicht ein kleiner Angriff, um eine Runde zu zerstören. Was ein DDoS-Angriff im Detail ist, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Die typischen Auslöser sind unspektakulär: Konkurrenz zwischen Communities, gebannte Spieler, verlorene Duelle, Streit im Discord. Ein Angriff kostet den Auftraggeber weder Können noch nennenswertes Geld, weil gemietete Booter-Dienste die Arbeit erledigen. Betreiber berichten regelmäßig, dass die Angriffe genau dann starten, wenn der Server voll ist, und aufhören, sobald er leer ist. Das ist kein Zufall, sondern ein Hinweis darauf, dass jemand Ihren Serverbrowser-Eintrag beobachtet und die Spielerzahl als Auslöser benutzt.

Die Ports, um die es bei Mordhau tatsächlich geht

Ein Mordhau-Dedicated-Server braucht genau vier UDP-Ports nach außen: 7777, 7778, 15000 und 27015. Alles andere ist entweder optional oder gehört nicht ins offene Netz. Die Ports werden beim Start als Parameter übergeben:

./MordhauServer.sh FFA_ThePit -log -Port=7777 -QueryPort=27015 -BeaconPort=15000 -RconPort=27020

Zwei Dinge werden dabei regelmäßig falsch verstanden. Erstens: Der Beacon-Port 15000 ist kein Beiwerk. Der Beacon reserviert den Slot in dem Moment, in dem ein Spieler beitritt, damit dieser nach dem Laden der Karte nicht wieder hinausfliegt. Ist 15000 blockiert oder überlastet, kommen Spieler nicht mehr herein, obwohl Port 7777 antwortet. Zweitens: RCON ist bei Mordhau nicht vorkonfiguriert. Es wird erst aktiv, wenn Sie RconPassword und RconPort setzen, und läuft dann über TCP, nicht über UDP.

Die wichtigsten Kennzahlen eines Mordhau-Servers auf einen Blick:

Die Angriffsmuster, die bei Mordhau vorkommen

Vier Muster decken praktisch alles ab, was gegen einen Mordhau-Server gefahren wird, und jedes trifft einen anderen Port.

• UDP-Flood auf den Spielport 7777. Das ist der Standardangriff eines Booters: möglichst viele gefälschte Pakete auf den Port, der im Serverbrowser steht. Er zielt auf Bandbreite und Paketrate, nicht auf eine Schwachstelle, und äußert sich zuerst als Lag-Spikes, lange bevor jemand die Verbindung verliert.
• Abfrage-Flood auf den Query-Port 27015. Eine A2S_INFO-Abfrage ist 25 Byte groß, die Antwort mit Servername, Karte, Spielmodus und Spielerzahl ein Vielfaches davon. Der Angreifer investiert also wenig und erzwingt bei Ihnen Rechenarbeit und ausgehenden Verkehr.
• Reflection über Ihren eigenen Query-Port. Hier ist Ihr Server nicht das Ziel, sondern das Werkzeug: Der Angreifer schickt Abfragen mit gefälschter Absenderadresse, und Ihr Server antwortet dem Opfer. Sie bemerken das als unerklärlich hohen ausgehenden Verkehr auf 27015 und als Missbrauchsmeldung Ihres Anbieters.
• Beitritts- und Slot-Erschöpfung über den Beacon-Port 15000. Statt Bandbreite zu verbrennen, belegen automatisierte Beitritte die reservierten Slots. Der Server läuft weiter, ist aber voll, und echte Spieler kommen nicht mehr herein.

Dazu kommt ein fünftes Muster, sobald RCON offen im Netz steht: Anmeldeversuche im Sekundentakt gegen den RCON-Port. Das ist selten volumetrisch, kostet aber Rechenzeit, und es ist der einzige der fünf Fälle, bei dem ein Treffer Ihnen den Server ganz aus der Hand nimmt.

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

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

1. Bestandsaufnahme: was lauscht überhaupt auf dem Server?

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

ss -lntup

Interessant ist die Spalte mit der lokalen Adresse. 0.0.0.0:7777 und [::]:7777 bedeuten "aus dem ganzen Internet erreichbar", 127.0.0.1:27020 bedeutet "nur lokal" und braucht keine Firewall-Regel. Neben dem Spiel tauchen dort oft noch ein Webpanel, ein Datenbankdienst und ein längst vergessener Voice-Dienst auf. Die Sicht des Angreifers liefert ein Scan von außen, für UDP mit einer kurzen Portliste, weil ein vollständiger UDP-Scan sehr langsam ist:

nmap -Pn -sU -p 7777,7778,15000,27015 IHRE.SERVER.IP.ADRESSE
nmap -Pn -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

2. Nur die vier Ports offen lassen, die Mordhau wirklich braucht

Für Mordhau reichen vier UDP-Freigaben nach außen, alles andere wird eingeschränkt oder gar nicht erst veröffentlicht. 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 7777/udp comment 'Mordhau Spiel'
ufw allow 7778/udp comment 'Mordhau Steam'
ufw allow 15000/udp comment 'Mordhau Beacon'
ufw allow 27015/udp comment 'Mordhau Query'
ufw allow from 203.0.113.10 to any port 27020 proto tcp comment 'Mordhau RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Ersetzen Sie 203.0.113.10 durch Ihre eigene Adresse. Wichtig ist, was hier nicht steht: keine Freigabe für ein Webpanel, keine für eine Datenbank, keine für einen Dateiserver. Jeder zusätzlich offene Port ist ein zusätzliches Ziel, das nichts mit dem Spiel zu tun hat. Die vollständige Anleitung samt Rettungsweg finden Sie unter UFW-Firewall einrichten, ohne sich selbst auszusperren.

3. Den Query-Port 27015 begrenzen, ohne aus der Serverliste zu fliegen

Den Abfrageport dürfen Sie begrenzen, aber nicht schließen. Wird 27015 UDP dichtgemacht, verschwindet Ihr Server aus dem Serverbrowser, weil Spielerzahl, Kartenname und Servername genau über diesen Port abgefragt werden. Eine Obergrenze je Quelladresse löst das Problem, ohne die Sichtbarkeit zu kosten:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name mh_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Ein regulärer Serverbrowser fragt Ihren Server ein paar Mal pro Minute ab, nicht ein paar Mal pro Sekunde. Zehn Abfragen pro Sekunde und Quelladresse sind damit großzügig für jeden Spieler und eng für jeden Bot. Prüfen Sie danach am Trefferzähler, ob die Regel überhaupt greift:

iptables -L INPUT -n -v | head -20
tcpdump -ni eth0 udp port 27015 -c 200 -q

Hier liegt auch die Antwort auf die Reflection-Frage. Bei einer Reflection wird Ihr Server nicht angegriffen, sondern als Verstärker missbraucht: Die Abfragen kommen mit gefälschter Absenderadresse, und Ihre Antworten treffen ein fremdes Opfer. Eine Ratenbegrenzung je Quelladresse ist dagegen die wirksamste lokale Maßnahme, weil eine gefälschte Absenderadresse nur so lange nützt, wie Ihr Server bereitwillig und unbegrenzt antwortet.

4. RCON aus dem offenen Netz nehmen

RCON gehört bei Mordhau in keinem Fall unbeschränkt ins Internet. Der Zugang wird in der Game.ini eingeschaltet, im Abschnitt [/Script/Mordhau.MordhauGameSession]:

[/Script/Mordhau.MordhauGameSession]
ServerName=Mein Mordhau-Server
MaxSlots=64
ServerPassword=
AdminPassword=EinLangesZufallspasswort
RconPassword=EinAnderesLangesZufallspasswort
RconPort=27020

Mordhau spricht das Source-RCON-Protokoll, also TCP, und arbeitet deshalb mit jedem gängigen RCON-Werkzeug zusammen. Genau das nutzen auch die Skripte, die Anmeldedaten durchprobieren. Drei Regeln decken den Fall ab. Erstens: RconPassword und AdminPassword sind zwei verschiedene, lange, zufällige Passwörter und keine Variationen des Servernamens. Zweitens: Die Freigabe für den RCON-Port beschränken Sie auf Ihre eigene Adresse, so wie oben im UFW-Block. Drittens, wenn Sie keine feste Adresse haben: Lassen Sie den Port von außen zu und erreichen Sie ihn über eine SSH-Portweiterleitung, danach verbinden Sie sich lokal auf 127.0.0.1:27020:

ssh -N -L 27020:127.0.0.1:27020 root@IHRE.SERVER.IP.ADRESSE

Muss RCON trotzdem offen bleiben, begrenzen Sie wenigstens die gleichzeitigen Verbindungen je Quelladresse. Ein RCON-Werkzeug braucht eine Verbindung, ein Bruteforce-Skript hunderte:

iptables -I INPUT -p tcp --dport 27020 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

5. Den Beacon-Port 15000 gegen Beitritts-Fluten absichern

Der Beacon-Port ist der unterschätzte Angriffspunkt eines Mordhau-Servers. Über ihn reserviert das Spiel den Slot eines beitretenden Spielers, solange dieser noch lädt. Ein Bot, der in schneller Folge Beitritte anstößt, belegt damit Slots, ohne je im Spiel anzukommen. Der Server bleibt online und wirkt trotzdem voll. Eine Obergrenze je Quelladresse fängt das ab, weil ein echter Spieler pro Beitritt genau einmal beacont und nicht zwanzigmal pro Sekunde:

iptables -I INPUT -p udp --dport 15000 -m hashlimit --hashlimit-name mh_beacon --hashlimit-mode srcip --hashlimit-above 20/sec --hashlimit-burst 40 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name mh_game --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

Die zweite Regel gilt dem Spielport und braucht Augenmaß. Bei einer Tickrate von 60 tauscht der Server mit jedem verbundenen Spieler in der Größenordnung von 60 Paketen pro Sekunde je Richtung aus. Ein Grenzwert von 400 Paketen pro Sekunde je Quelladresse lässt damit jedem echten Spieler reichlich Luft und trifft trotzdem jede Quelle, die offensichtlich flutet. Messen Sie erst eine Woche im Normalbetrieb, bevor Sie enger stellen: Wer zu eng einstellt, wirft die eigenen Spieler heraus und hält das anschließend für einen Angriff.

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

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

6. Game.ini und Engine.ini: was wirklich etwas bringt

Mordhau hat zwei Konfigurationsdateien, und beide liegen unter Linux in Mordhau/Saved/Config/LinuxServer/, unter Windows in Mordhau\Saved\Config\WindowsServer\. Die Game.ini regelt Servername, Slots, Passwörter, Adminliste, Kartenrotation und die Mod-Kennungen aus mod.io, die Engine.ini das Netzverhalten. Bearbeiten Sie beide ausschließlich bei gestopptem Server, sonst überschreibt der Serverprozess beim Beenden Ihre Änderungen mit dem Stand aus dem Arbeitsspeicher.

Drei Einstellungen sind für die Angriffsfläche wirklich relevant. Erstens ein ServerPassword: Es hält jeden fern, der nicht eingeladen ist, kostet aber die öffentliche Auffindbarkeit und hilft gegen eine Flut auf Port 7777 überhaupt nicht, weil der Angreifer gar nicht beitreten will. Zweitens eine realistische MaxSlots-Zahl: Mordhau ist auf bis zu 64 Spieler ausgelegt, und jeder zusätzliche Slot ist eine zusätzliche Paketquelle, die Ihre CPU bedienen muss. Drittens die Tickrate in der Engine.ini:

[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=60
LanServerMaxTickRate=60

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

Die Standard-Tickrate eines Mordhau-Servers ist 60. Eine Erhöhung auf 120 verdoppelt die Paketrate je Spieler und die CPU-Last und ist damit genau das, was Sie unter Angriff nicht gebrauchen können. Ein 64-Slot-Server mit Tickrate 120 erzeugt im Normalbetrieb bereits in der Größenordnung von 8.000 Paketen pro Sekunde je Richtung. Wer dauerhaft beschossen wird, fährt mit 60 spürbar stabiler als mit 120.

7. Die Verbindungsverfolgung und die Empfangspuffer entlasten

Ein oft übersehener Engpass ist die Verbindungsverfolgung des Kernels. Sie führt für jeden UDP-Strom einen eigenen Eintrag, und eine Flut aus zigtausend gefälschten Absenderadressen füllt die Tabelle in Sekunden. Läuft sie voll, verwirft der Server auch legitime Pakete, und im Protokoll steht "nf_conntrack: table full". Stand und Obergrenze zeigt:

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

Dagegen hilft zweierlei. Sie erhöhen die Obergrenze, oder Sie nehmen die Spielports von der Verfolgung ganz aus. Letzteres ist bei einem Gameserver meist der bessere Weg, weil UDP ohnehin keinen Zustand hat, den man verfolgen müsste:

iptables -t raw -I PREROUTING -p udp --dport 7777 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 15000 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 27015 -j NOTRACK

Ebenfalls sinnvoll sind größere Empfangspuffer und eine tiefere Warteschlange der Netzwerkkarte, damit kurze Spitzen nicht sofort zu Verwürfen führen:

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=4194304
sysctl -w net.core.netdev_max_backlog=5000

Dauerhaft gehören diese Werte in eine Datei unter /etc/sysctl.d/, zum Beispiel 99-gameserver.conf. Wichtig zum Verständnis: Größere Puffer erhöhen nicht Ihre Belastbarkeit gegen einen großen Angriff, sie verhindern nur, dass ein kurzer Ausschlag bereits Pakete kostet.

8. Ihre Adresse steht in der Serverliste, und das lässt sich nicht ändern

Hier lohnt sich Ehrlichkeit statt Wunschdenken: Die IP-Adresse eines öffentlichen Mordhau-Servers lässt sich nicht geheim halten. Sie steht im Serverbrowser-Eintrag, sie steht in den öffentlichen Serverlisten Dritter, die den Abfrageport regelmäßig auslesen, und jeder Spieler, der einmal verbunden war, kennt sie. Ein Adresswechsel verschafft deshalb Stunden, selten Tage, weil der Angreifer die neue Adresse über denselben Weg findet wie die alte.

Wirksam sind dafür drei Gewohnheiten. Veröffentlichen Sie die rohe IP-Adresse nirgends selbst, also nicht im Discord-Kanal und nicht auf der Projektseite. Verbinden Sie Ihre Spieler über einen Hostnamen, damit ein Adresswechsel im Ernstfall nicht sämtliche Verweise bricht. Und räumen Sie alte DNS-Einträge weg, denn ein vergessener A-Eintrag auf die vorherige Adresse macht jeden Wechsel wirkungslos. Dasselbe gilt für Testserver: Jeder öffentlich erreichbare Zweitserver auf derselben Maschine verrät die Adresse des Hauptservers.

9. Messen, solange alles normal läuft

Der wichtigste Schritt ist der, den fast niemand vorher macht: eine Vergleichsbasis anlegen, solange der Server ruhig 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 läuft die Messung dauerhaft mit. Während eines Vorfalls genügen vier Befehle:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 'udp port 7777 or udp port 15000 or udp port 27015' -c 200 -q

Bei tcpdump gilt: immer mit -c begrenzen, denn ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Achten Sie besonders auf die Verwurfszähler aus ip -s link. Steigende dropped-Werte bei gleichzeitig ruhiger CPU sind der deutlichste Hinweis darauf, dass die Paketrate und nicht die Rechenleistung das Problem ist. Wie Sie die Werte auswerten, steht in DDoS-Angriff erkennen. Wie Sie den Server sauber per SteamCMD aufsetzen und aktuell halten, beschreibt Gameserver mit SteamCMD installieren.

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. Ein typischer Gameserver hängt an 1 Gbit/s, das sind 125 Megabyte pro Sekunde, und die Leitung ist voll, sobald jemand mehr schickt. Ein voller Mordhau-Server mit 64 Slots braucht davon nur einen Bruchteil: Bei Tickrate 60 liegt der Spielverkehr in der Größenordnung von 4.000 Paketen pro Sekunde je Richtung. Ein gemieteter Booter liefert dagegen ohne Weiteres 5 bis 50 Gbit/s, also das Fünf- bis Fünfzigfache Ihrer Leitung. Ob Ihre iptables-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 sie schlägt oft früher zu als die Bandbreite. Bei kleinen Paketen von 64 Byte passen in eine Leitung mit 1 Gbit/s rund 1,49 Millionen Pakete pro Sekunde. Ein normaler Serverkernel verarbeitet je nach CPU und Netzwerkkarte einige hunderttausend davon, bevor er anfängt zu verwerfen. Ein Angriff, der Ihre Leitung nicht einmal zu einem Drittel füllt, kann Ihren Mordhau-Server also trotzdem lahmlegen, weil die Rechenzeit fürs Verwerfen draufgeht. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem war alles weg".

Zur Einordnung, welche Größenordnungen real vorkommen: Auf KernelHost-Servern wurden unter anderem ein Angriff mit über 473,4 Gbit/s bei über 41,5 Millionen Paketen pro Sekunde auf einen Voice-Server und ein UDP-Flood mit über 112,2 Gbit/s auf einen Gameserver gefiltert. Dafür gibt es keine lokale Einstellung. Volumetrische Angriffe müssen im Netz vor dem Server enden.

Was KernelHost dagegen 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.

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 Mordhau-Server

Manche Server werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen. Dafür gibt es die Advanced DDoS Protection ab 50,00 € im Monat, PrePaid, ohne Mindestlaufzeit und ohne Einrichtungsgebühr. 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 legen getrennt fest, was auf 7777 UDP erlaubt ist, was auf 15000 UDP und was auf 27015 UDP, ohne dafür ein Ticket zu schreiben.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, statt auf ein Wartungsfenster zu warten.
• Schutzprofil passend zum Spiel. Für Unreal-Engine-Gameserver auf UDP und für Steam-Abfrageports gibt es fertige Profile, ebenso für modifizierte und eigene Anwendungen auf beliebigen TCP- oder UDP-Ports.

Die Advanced DDoS Protection richtet sich an Server, die bei KernelHost laufen. Steht Ihr Mordhau-Server aktuell woanders und wird regelmäßig aus dem Netz geschossen, ist der Umzug der Weg zu dieser Filterung.

Die beiden Stufen im Vergleich

Für die meisten Mordhau-Server reicht der inkludierte Dauerschutz zusammen mit einer sauberen Konfiguration. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt.

Häufige Fehler und Lösungen

"Ich habe Port 27015 dichtgemacht, jetzt steht mein Server nicht mehr in der Liste": Das ist die erwartbare Folge. Der Steam-Abfrageport liefert Name, Karte und Spielerzahl an den Serverbrowser. Ohne ihn erscheint Ihr Server nicht mehr oder wird als nicht erreichbar geführt. Richtig ist eine Ratenbegrenzung je Quelladresse statt einer Sperre.

"Spieler kommen nicht herein, obwohl der Server läuft": Prüfen Sie zuerst Port 15000 UDP. Der Beacon reserviert den Slot während des Ladens. Ist er gesperrt, zu eng gefiltert oder überlastet, bleibt der Beitritt hängen, obwohl Port 7777 antwortet und der Server im Browser steht.

"Meine Änderungen in der Game.ini sind nach dem Neustart wieder weg": Sie haben die Datei bei laufendem Server bearbeitet. Der Mordhau-Serverprozess schreibt beim Beenden seinen Stand aus dem Arbeitsspeicher zurück und überschreibt dabei Ihre Version. Server stoppen, bearbeiten, starten, in dieser Reihenfolge.

"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 längst 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 läuft, aber alle haben Lag-Spikes und Treffer kommen zu spät an": Sehen Sie zuerst nach, ob die Eingangspaketrate steigt, während die CPU ruhig bleibt. Genau das ist das Muster eines Angriffs. Bleibt die Paketrate normal und steht die CPU bei 100 Prozent, ist es kein DDoS-Angriff, sondern meist eine zu hohe Tickrate, zu viele Slots oder ein Mod.

"Mein Anbieter meldet ausgehenden Missbrauch von Port 27015": Ihr Server wurde als Verstärker für eine Reflection missbraucht. Die Abfragen kamen mit gefälschter Absenderadresse, geantwortet hat Ihr Server an ein fremdes Opfer. Eine Ratenbegrenzung auf 27015 UDP je Quelladresse beendet das.

"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 Mordhau-Dedicated-Server braucht genau vier UDP-Ports nach außen: 7777 (Spiel), 7778 (Steam), 15000 (Beacon) und 27015 (Steam-Abfrage). Alles andere gehört zu.
• RCON läuft bei Mordhau über TCP nach dem Source-RCON-Protokoll und wird erst durch RconPassword und RconPort in der Game.ini aktiv. Beschränken Sie den Port auf Ihre eigene Adresse.
• Port 27015 UDP dürfen Sie begrenzen, aber nicht schließen: Ohne ihn verschwindet Ihr Server aus dem Serverbrowser, weil Spielerzahl, Karte und Name über diesen Port abgefragt werden.
• Port 15000 UDP ist der Beacon-Port und reserviert den Slot während des Ladens. Ist er blockiert oder überlastet, kommen Spieler nicht herein, obwohl der Server läuft.
• Bearbeiten Sie Game.ini und Engine.ini nur bei gestopptem Server, weil der Serverprozess beim Beenden den Stand aus dem Arbeitsspeicher zurückschreibt.
• Lokale Firewall-Regeln enden an der Bandbreite: 1 Gbit/s sind 125 Megabyte pro Sekunde und bei 64-Byte-Paketen rund 1,49 Millionen Pakete pro Sekunde. Darüber entscheidet ausschließlich das Netz vor dem Server.
• Bei KernelHost ist der zweistufige Dauerschutz in jedem Serverpaket ohne Aufpreis enthalten und ab Bereitstellung aktiv, ohne Nullrouting. Wer die Filterung selbst steuern will, bekommt sie mit der Advanced DDoS Protection ab 50,00 € im Monat.

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