Mordhau-server beschermen tegen DDoS-aanvallen

Een Mordhau-server die midden in de Frontline-ronde al zijn spelers tegelijk verliest, daarna een paar minuten offline is en niet meer in de serverlijst opduikt, heeft zelden een hardwareprobleem. In verreweg de meeste gevallen loopt er een aanval op een van de vier UDP-poorten die een dedicated Mordhau-server naar buiten open moet houden. Dit artikel laat eerst zien wat u bij de Mordhau-DDoS-bescherming zonder extra kosten zelf kunt afhandelen, daarna waar die maatregelen fysiek ophouden, en tot slot wat er in het netwerk vóór de server moet gebeuren.

Alle gegevens hebben betrekking op de officiële dedicated Mordhau-server (Steam-app-ID 629800, Unreal Engine 4) onder Debian 12, Debian 13, Ubuntu 22.04 LTS of Ubuntu 24.04 LTS. De commando's zijn voor root geschreven; als gewone gebruiker zet u er sudo voor. Loopt de aanval op dit moment, verander dan eerst niets aan de configuratie en start de server niet opnieuw op, maar leg de meetwaarden vast (paragraaf 9), want na de aanval zijn ze weg. Bij Mordhau komt daar een tweede reden bij die veel beheerders pijnlijk leren: het serverproces schrijft bij het afsluiten zijn stand uit het werkgeheugen terug naar de Game.ini. Wie het bestand bewerkt terwijl de server draait, verliest zijn wijzigingen bij de volgende stop.

Waarom Mordhau-servers DDoS-bescherming nodig hebben en wie ze aanvalt

Mordhau-servers worden aangevallen omdat hun adres openbaar is, al het spelverkeer over UDP loopt en een uitval meteen voor iedereen zichtbaar wordt. De vermelding in de serverbrowser bevat het IP-adres en de spelpoort leesbaar, omdat spelers de server anders niet zouden kunnen vinden. Openbare serverlijsten en trackers halen dezelfde gegevens via de Steam-querypoort op en publiceren ze een tweede keer. Uw adres is daarmee geen geheim, maar een productgegeven.

Daar komt de techniek van het spel bij. Unreal Engine 4 draagt bewegingen, treffers en pareringen over UDP over. UDP kent geen verbindingsopbouw die u zou kunnen eisen, en het afzenderadres van een UDP-pakket laat zich vervalsen. Een aanvaller hoeft uw server dus niet te betreden en hoeft hem ook niet correct aan te spreken om belasting te veroorzaken. Bij Mordhau weegt dat zwaarder dan bij veel andere spellen: een slagenwisseling wordt in enkele tienden van een seconde beslist, en al 200 milliseconden extra vertraging maken het nabijgevecht onspeelbaar, ruim voordat de server daadwerkelijk uitvalt. Precies daarom is een kleine aanval genoeg om een ronde te verwoesten. Wat een DDoS-aanval in detail is, legt het artikel Wat is een DDoS-aanval? uit.

De typische aanleidingen zijn weinig spectaculair: concurrentie tussen communities, verbannen spelers, verloren duels, ruzie in Discord. Een aanval kost de opdrachtgever kunde noch noemenswaardig geld, omdat gehuurde booterdiensten het werk doen. Beheerders melden regelmatig dat de aanvallen precies dan beginnen wanneer de server vol is, en ophouden zodra hij leeg is. Dat is geen toeval, maar een aanwijzing dat iemand uw vermelding in de serverbrowser in de gaten houdt en het spelersaantal als aanleiding gebruikt.

De poorten waar het bij Mordhau werkelijk om gaat

Een dedicated Mordhau-server heeft naar buiten precies vier UDP-poorten nodig: 7777, 7778, 15000 en 27015. Al het overige is of optioneel, of het hoort niet op het open netwerk. De poorten worden bij de start als parameter meegegeven:

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

Twee dingen worden daarbij regelmatig verkeerd begrepen. Ten eerste: de beacon-poort 15000 is geen bijzaak. De beacon reserveert het slot op het moment dat een speler toetreedt, zodat deze na het laden van de map er niet weer uit vliegt. Is 15000 geblokkeerd of overbelast, dan komen spelers niet meer binnen, hoewel poort 7777 antwoordt. Ten tweede: RCON is bij Mordhau niet voorgeconfigureerd. Het wordt pas actief wanneer u RconPassword en RconPort instelt, en loopt dan over TCP, niet over UDP.

De belangrijkste kerngegevens van een Mordhau-server in één overzicht:

De aanvalspatronen die bij Mordhau voorkomen

Vier patronen dekken praktisch alles af wat tegen een Mordhau-server wordt ingezet, en elk daarvan raakt een andere poort.

• UDP-flood op de spelpoort 7777. Dat is de standaardaanval van een booter: zoveel mogelijk vervalste pakketten naar de poort die in de serverbrowser staat. Hij mikt op bandbreedte en pakketsnelheid, niet op een kwetsbaarheid, en uit zich eerst als lag-spikes, lang voordat iemand de verbinding verliest.
• Queryflood op de querypoort 27015. Een A2S_INFO-opvraging is 25 byte groot, het antwoord met servernaam, map, spelmodus en spelersaantal een veelvoud daarvan. De aanvaller investeert dus weinig en dwingt bij u rekenwerk en uitgaand verkeer af.
• Reflectie via uw eigen querypoort. Hier is uw server niet het doelwit, maar het werktuig: de aanvaller stuurt opvragingen met een vervalst afzenderadres, en uw server antwoordt het slachtoffer. U merkt dat als onverklaarbaar hoog uitgaand verkeer op 27015 en als misbruikmelding van uw aanbieder.
• Joinflood en slotuitputting via de beacon-poort 15000. In plaats van bandbreedte te verstoken bezetten geautomatiseerde toetredingen de gereserveerde sloten. De server draait door, is echter vol, en echte spelers komen niet meer binnen.

Daar komt een vijfde patroon bij zodra RCON open in het netwerk staat: aanmeldpogingen in secondetempo tegen de RCON-poort. Dat is zelden volumetrisch, kost wel rekentijd, en het is het enige van de vijf gevallen waarin een treffer u de server volledig uit handen neemt.

Wat u zelf kunt doen voordat u geld uitgeeft

Dit hoofdstuk is het langste, en dat met opzet. Een netjes geconfigureerde Mordhau-server houdt kleine en middelgrote aanvallen op eigen kracht uit, ongeacht bij wie hij staat.

1. Inventarisatie: wat luistert er eigenlijk op de server?

Voordat u ook maar één firewallregel schrijft, kijkt u na wat uw server naar buiten aanbiedt. Niet gokken, maar kijken:

ss -lntup

Interessant is de kolom met het lokale adres. 0.0.0.0:7777 en [::]:7777 betekenen "vanaf het hele internet bereikbaar", 127.0.0.1:27020 betekent "alleen lokaal" en heeft geen firewallregel nodig. Naast het spel duiken daar vaak nog een webpaneel, een databasedienst en een allang vergeten voicedienst op. Het beeld van de aanvaller levert een scan van buitenaf, voor UDP met een korte poortlijst, omdat een volledige UDP-scan zeer langzaam is:

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

2. Alleen de vier poorten openlaten die Mordhau werkelijk nodig heeft

Voor Mordhau volstaan vier UDP-vrijgaven naar buiten, al het overige wordt beperkt of helemaal niet gepubliceerd. Met UFW ziet dat er zo uit, en wel precies in deze volgorde, zodat u zichzelf niet buitensluit:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'Mordhau spel'
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

Vervang 203.0.113.10 door uw eigen adres. Belangrijk is wat hier niet staat: geen vrijgave voor een webpaneel, geen voor een database, geen voor een bestandsserver. Elke extra open poort is een extra doelwit dat niets met het spel te maken heeft. De volledige handleiding inclusief reddingsweg vindt u onder UFW-firewall instellen zonder uzelf buiten te sluiten.

3. De querypoort 27015 begrenzen zonder uit de serverlijst te vallen

De querypoort mag u begrenzen, maar niet sluiten. Wordt 27015 UDP dichtgezet, dan verdwijnt uw server uit de serverbrowser, omdat spelersaantal, mapnaam en servernaam juist via deze poort worden opgevraagd. Een bovengrens per bronadres lost dat op zonder de zichtbaarheid te 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

Een reguliere serverbrowser vraagt uw server een paar keer per minuut op, niet een paar keer per seconde. Tien opvragingen per seconde en bronadres zijn daarmee ruim voor elke speler en krap voor elke bot. Controleer daarna aan de tellerstand of de regel überhaupt aanslaat:

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

Hier ligt ook het antwoord op de reflectievraag. Bij een reflectie wordt uw server niet aangevallen, maar als versterker misbruikt: de opvragingen komen met een vervalst afzenderadres, en uw antwoorden treffen een onbekend slachtoffer. Een snelheidsbegrenzing per bronadres is daartegen de effectiefste lokale maatregel, omdat een vervalst afzenderadres alleen nut heeft zolang uw server gewillig en onbeperkt antwoordt.

4. RCON uit het open netwerk halen

RCON hoort bij Mordhau in geen geval onbeperkt op het internet. De toegang wordt in de Game.ini ingeschakeld, in de sectie [/Script/Mordhau.MordhauGameSession]:

[/Script/Mordhau.MordhauGameSession]
ServerName=Mijn Mordhau-server
MaxSlots=64
ServerPassword=
AdminPassword=EenLangWillekeurigWachtwoord
RconPassword=EenAnderLangWillekeurigWachtwoord
RconPort=27020

Mordhau spreekt het Source-RCON-protocol, dus TCP, en werkt daarmee samen met elk gangbaar RCON-hulpmiddel. Precies daarvan maken ook de scripts gebruik die aanmeldgegevens uitproberen. Drie regels dekken dit geval af. Ten eerste: RconPassword en AdminPassword zijn twee verschillende, lange, willekeurige wachtwoorden en geen variaties op de servernaam. Ten tweede: de vrijgave voor de RCON-poort beperkt u tot uw eigen adres, zoals hierboven in het UFW-blok. Ten derde, als u geen vast adres hebt: laat de poort van buitenaf dicht en bereik hem via een SSH-poortdoorverwijzing, daarna verbindt u lokaal op 127.0.0.1:27020:

ssh -N -L 27020:127.0.0.1:27020 root@UW.SERVER.IP.ADRES

Moet RCON toch open blijven, begrens dan op zijn minst de gelijktijdige verbindingen per bronadres. Een RCON-hulpmiddel heeft één verbinding nodig, een bruteforcescript honderden:

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

5. De beacon-poort 15000 tegen joinfloods afschermen

De beacon-poort is het onderschatte aanvalspunt van een Mordhau-server. Via die poort reserveert het spel het slot van een toetredende speler zolang deze nog laadt. Een bot die in snelle opeenvolging toetredingen aanstoot, bezet daarmee sloten zonder ooit in het spel aan te komen. De server blijft online en lijkt toch vol. Een bovengrens per bronadres vangt dat af, omdat een echte speler per toetreding precies één keer beacont en niet twintig keer per seconde:

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

De tweede regel geldt de spelpoort en vraagt om maatgevoel. Bij een tickrate van 60 wisselt de server met elke verbonden speler in de orde van grootte van 60 pakketten per seconde per richting uit. Een grenswaarde van 400 pakketten per seconde en bronadres laat daarmee elke echte speler ruimschoots lucht en treft toch elke bron die zichtbaar vloedt. Meet eerst een week in normaal bedrijf voordat u krapper instelt: wie te krap instelt, gooit zijn eigen spelers eruit en houdt dat vervolgens voor een aanval.

Kale iptables-regels zijn na een herstart verdwenen. Onder Debian en Ubuntu bewaart u ze zo:

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

Onder UFW horen zulke regels in /etc/ufw/before.rules, omdat ze anders bij de volgende ufw reload verdwijnen.

6. Game.ini en Engine.ini: wat werkelijk iets oplevert

Mordhau heeft twee configuratiebestanden, en beide liggen onder Linux in Mordhau/Saved/Config/LinuxServer/, onder Windows in Mordhau\Saved\Config\WindowsServer\. De Game.ini regelt servernaam, sloten, wachtwoorden, adminlijst, maprotatie en de mod-kenmerken uit mod.io, de Engine.ini het netwerkgedrag. Bewerk beide uitsluitend bij een gestopte server, anders overschrijft het serverproces bij het afsluiten uw wijzigingen met de stand uit het werkgeheugen.

Drie instellingen zijn voor het aanvalsoppervlak werkelijk relevant. Ten eerste een ServerPassword: het houdt iedereen weg die niet is uitgenodigd, kost echter de openbare vindbaarheid en helpt tegen een vloed op poort 7777 helemaal niet, omdat de aanvaller helemaal niet wil toetreden. Ten tweede een realistisch aantal in MaxSlots: Mordhau is op maximaal 64 spelers gebouwd, en elk extra slot is een extra pakketbron die uw CPU moet bedienen. Ten derde de tickrate in de Engine.ini:

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

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

De standaard tickrate van een Mordhau-server is 60. Een verhoging naar 120 verdubbelt de pakketsnelheid per speler en de CPU-belasting en is daarmee precies wat u onder een aanval niet kunt gebruiken. Een server met 64 sloten en tickrate 120 produceert in normaal bedrijf al in de orde van grootte van 8.000 pakketten per seconde per richting. Wie permanent onder vuur ligt, draait met 60 merkbaar stabieler dan met 120.

7. De verbindingsregistratie en de ontvangstbuffers ontlasten

Een vaak over het hoofd gezien knelpunt is de verbindingsregistratie van de kernel. Zij houdt voor elke UDP-stroom een eigen vermelding bij, en een vloed uit tienduizenden vervalste afzenderadressen vult de tabel in seconden. Loopt zij vol, dan verwerpt de server ook legitieme pakketten, en in het logboek staat "nf_conntrack: table full". Stand en bovengrens toont:

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

Daartegen helpt tweeërlei. U verhoogt de bovengrens, of u neemt de spelpoorten helemaal van de registratie uit. Dat laatste is bij een gameserver meestal de betere weg, omdat UDP sowieso geen status kent die gevolgd zou moeten worden:

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

Eveneens zinvol zijn grotere ontvangstbuffers en een diepere wachtrij van de netwerkkaart, zodat korte pieken niet meteen tot verwerping leiden:

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

Blijvend horen deze waarden in een bestand onder /etc/sysctl.d/, bijvoorbeeld 99-gameserver.conf. Belangrijk om te begrijpen: grotere buffers verhogen uw weerbaarheid tegen een grote aanval niet, ze voorkomen alleen dat een korte uitschieter al pakketten kost.

8. Uw adres staat in de serverlijst, en daar valt niets aan te veranderen

Hier loont eerlijkheid meer dan wensdenken: het IP-adres van een openbare Mordhau-server laat zich niet geheimhouden. Het staat in de vermelding in de serverbrowser, het staat in de openbare serverlijsten van derden die de querypoort regelmatig uitlezen, en iedere speler die ooit verbonden is geweest, kent het. Een adreswissel levert daarom uren op, zelden dagen, omdat de aanvaller het nieuwe adres langs dezelfde weg vindt als het oude.

Werkzaam zijn daarvoor drie gewoonten. Publiceer het kale IP-adres nergens zelf, dus niet in het Discord-kanaal en niet op de projectpagina. Laat uw spelers via een hostnaam verbinden, zodat een adreswissel in geval van nood niet alle verwijzingen breekt. En ruim oude DNS-records op, want een vergeten A-record naar het vorige adres maakt elke wissel zinloos. Hetzelfde geldt voor testservers: elke openbaar bereikbare tweede server op dezelfde machine verraadt het adres van de hoofdserver.

9. Meten zolang alles normaal draait

De belangrijkste stap is die welke bijna niemand vooraf zet: een vergelijkingsbasis aanleggen zolang de server rustig draait. Zonder normaalwaarde kunt u na een incident niet zeggen of 40.000 pakketten per seconde veel was of gewoon zaterdagavond. Met apt-get install -y vnstat sysstat loopt de meting permanent mee. Tijdens een incident volstaan vier commando's:

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

Voor tcpdump geldt: begrens hem altijd met -c, want een opname onder volle belasting belast een toch al overbelaste server nog extra. Let vooral op de verwerpingstellers uit ip -s link. Stijgende dropped-waarden bij een tegelijk rustige CPU zijn de duidelijkste aanwijzing dat de pakketsnelheid en niet de rekenkracht het probleem is. Hoe u de waarden uitleest, staat in DDoS-aanval herkennen. Hoe u de server netjes via SteamCMD opzet en actueel houdt, beschrijft Gameserver met SteamCMD installeren.

Waar deze maatregelen ophouden: bandbreedte en pakketsnelheid

Nu het deel dat geen enkel configuratiebestand kan oplossen. Alle maatregelen tot hier draaien op uw server, dus aan het einde van de lijn. Een firewallregel beslist over een pakket dat al over de kabel is gekomen. U kunt het verwerpen, maar u kunt niet terugdraaien dat het verstuurd is.

Rekent u even mee. Een typische gameserver hangt aan 1 Gbit/s, dat is 125 megabyte per seconde, en de lijn zit vol zodra iemand meer stuurt. Een volle Mordhau-server met 64 sloten heeft daarvan maar een fractie nodig: bij tickrate 60 ligt het spelverkeer in de orde van grootte van 4.000 pakketten per seconde per richting. Een gehuurde booter levert daarentegen moeiteloos 5 tot 50 Gbit/s, dus het vijf- tot vijftigvoudige van uw lijn. Of uw iptables-regel daarachter goed is, doet dan niet meer ter zake, want de pakketten van uw spelers komen al eerder niet door.

De tweede grootheid is de pakketsnelheid, en die slaat vaak eerder toe dan de bandbreedte. Bij kleine pakketten van 64 byte passen er in een lijn van 1 Gbit/s ongeveer 1,49 miljoen pakketten per seconde. Een gewone serverkernel verwerkt daarvan, afhankelijk van CPU en netwerkkaart, enkele honderdduizenden voordat hij begint te verwerpen. Een aanval die uw lijn nog niet eens voor een derde vult, kan uw Mordhau-server dus toch platleggen, omdat de rekentijd opgaat aan het verwerpen. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch was alles weg".

Ter oriëntatie, welke ordes van grootte werkelijk voorkomen: op KernelHost-servers zijn onder meer een aanval met meer dan 473,4 Gbit/s bij meer dan 41,5 miljoen pakketten per seconde op een voiceserver en een UDP-flood met meer dan 112,2 Gbit/s op een gameserver weggefilterd. Daarvoor bestaat geen lokale instelling. Volumetrische aanvallen moeten in het netwerk vóór de server eindigen.

Wat KernelHost daartegenover zet

De permanente bescherming die bij elke server inbegrepen is

De DDoS-bescherming van KernelHost is in twee lagen opgebouwd en permanent actief, zonder dat u iets hoeft in te schakelen, te bestellen of te configureren:

• Laag 1: 17 Tbps mitigatiecapaciteit in het globale scrubbing-netwerk. Volumetrische aanvallen worden dicht bij hun bron geschoond, nog voordat ze het datacenter bereiken.
• Laag 2: Arbor realtime filtering met 3,2 Tbps in Frankfurt am Main. Direct vóór de server worden protocolspecifieke patronen herkend en verworpen, pakket voor pakket.

Twee eigenschappen zijn doorslaggevend. De bescherming loopt permanent en hoeft niet eerst op een aanval te reageren, er zijn dus geen eerste minuten waarin de server weg is. En er wordt geen null-routing toegepast: uw IP-adres blijft in het netwerk, alleen de schadelijke pakketten worden verworpen. Wie het IP-adres uit het netwerk haalt, bereikt voor u hetzelfde resultaat als de aanvaller. De locatie is Frankfurt am Main. Welke games en protocollen gedekt zijn, somt Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor Mordhau-servers die permanent onder vuur liggen

Sommige servers worden niet af en toe, maar gericht en wekenlang aangevallen. Daarvoor is er de Advanced DDoS Protection vanaf 50,00 € per maand, PrePaid, zonder minimale looptijd en zonder installatiekosten. Het verschil zit niet in meer capaciteit, maar in de controle:

• Een dedicated beschermd IP-adres uit de Frankfurtse kern, waarnaar uw server binnen ons eigen netwerk wordt omgezet. Aan uw kant is geen enkele verbouwing nodig.
• Zelf beheerbare beschermingsregels per poort en protocol in het klantenpaneel: u bepaalt afzonderlijk wat op 7777 UDP is toegestaan, wat op 15000 UDP en wat op 27015 UDP, zonder daarvoor een ticket te schrijven.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen in plaats van op een onderhoudsvenster te wachten.
• Een beschermingsprofiel dat bij het spel past. Voor Unreal-Engine-gameservers op UDP en voor Steam-querypoorten zijn er kant-en-klare profielen, net zo goed als voor aangepaste en eigen applicaties op willekeurige TCP- of UDP-poorten.

De Advanced DDoS Protection richt zich op servers die bij KernelHost draaien. Staat uw Mordhau-server op dit moment ergens anders en wordt hij regelmatig uit het netwerk geschoten, dan is de verhuizing de weg naar deze filtering.

De twee lagen naast elkaar

Voor de meeste Mordhau-servers volstaat de inbegrepen permanente bescherming samen met een nette configuratie. De Advanced DDoS Protection is het antwoord op iemand die het persoonlijk maakt.

Veelgemaakte fouten en oplossingen

"Ik heb poort 27015 dichtgezet, nu staat mijn server niet meer in de lijst": dat is het te verwachten gevolg. De Steam-querypoort levert naam, map en spelersaantal aan de serverbrowser. Zonder die poort verschijnt uw server niet meer of wordt hij als onbereikbaar vermeld. Juist is een snelheidsbegrenzing per bronadres in plaats van een blokkade.

"Spelers komen niet binnen, hoewel de server draait": controleer eerst poort 15000 UDP. De beacon reserveert het slot tijdens het laden. Is hij geblokkeerd, te krap gefilterd of overbelast, dan blijft de toetreding hangen, hoewel poort 7777 antwoordt en de server in de browser staat.

"Mijn wijzigingen in de Game.ini zijn na de herstart weer weg": u hebt het bestand bewerkt terwijl de server draaide. Het Mordhau-serverproces schrijft bij het afsluiten zijn stand uit het werkgeheugen terug en overschrijft daarbij uw versie. Server stoppen, bewerken, starten, in die volgorde.

"Mijn iptables-regels grijpen niet": drie oorzaken komen vaak voor. De regels staan achter de UFW-ketens en worden nooit bereikt, ze waren na de laatste herstart verdwenen (dan helpen netfilter-persistent save of een regel in /etc/ufw/before.rules), of de aanval is volumetrisch en de regel werkt correct aan een lijn die allang vol zit. Controleer met iptables -L INPUT -n -v of de tellers oplopen. Blijven ze op nul staan, dan wordt de regel niet bereikt.

"De server draait, maar iedereen heeft lag-spikes en treffers komen te laat aan": kijk eerst na of de inkomende pakketsnelheid stijgt terwijl de CPU rustig blijft. Precies dat is het patroon van een aanval. Blijft de pakketsnelheid normaal en staat de CPU op 100 procent, dan is het geen DDoS-aanval, maar meestal een te hoge tickrate, te veel sloten of een mod.

"Mijn aanbieder meldt uitgaand misbruik van poort 27015": uw server is als versterker voor een reflectie misbruikt. De opvragingen kwamen met een vervalst afzenderadres, geantwoord heeft uw server aan een onbekend slachtoffer. Een snelheidsbegrenzing op 27015 UDP per bronadres maakt daar een einde aan.

"Mijn vorige aanbieder heeft mijn IP-adres geblokkeerd": dat is null-routing. De aanbieder beschermt daarmee zijn eigen netwerk; voor u is het resultaat identiek aan een geslaagde aanval, meestal nog urenlang daarna. Vraag bij twijfel na of er wordt gefilterd of null-geroutet. Dat antwoord bepaalt meer over uw beschikbaarheid dan welke hardwarespecificatie ook.

"In de tcpdump zie ik niets opvallends": wordt het verkeer al in het netwerk ervoor gefilterd, dan komt er op de server zoals verwacht niets aan. Dat is het normale beeld bij een werkende filtering. Omgekeerd geldt: zit de lijn vol, dan bereikt u onder omstandigheden zelfs de SSH-sessie niet meer waarmee u wilde meten. Gebruik dan de VNC-console in het klantenpaneel, die losstaat van het netwerk van het gastsysteem.

Kort samengevat

• Een dedicated Mordhau-server heeft naar buiten precies vier UDP-poorten nodig: 7777 (spel), 7778 (Steam), 15000 (beacon) en 27015 (Steam-opvraging). Al het overige blijft dicht.
• RCON loopt bij Mordhau over TCP volgens het Source-RCON-protocol en wordt pas door RconPassword en RconPort in de Game.ini actief. Beperk de poort tot uw eigen adres.
• Poort 27015 UDP mag u begrenzen, maar niet sluiten: zonder die poort verdwijnt uw server uit de serverbrowser, omdat spelersaantal, map en naam via deze poort worden opgevraagd.
• Poort 15000 UDP is de beacon-poort en reserveert het slot tijdens het laden. Is hij geblokkeerd of overbelast, dan komen spelers niet binnen, hoewel de server draait.
• Bewerk Game.ini en Engine.ini alleen bij een gestopte server, omdat het serverproces bij het afsluiten de stand uit het werkgeheugen terugschrijft.
• Lokale firewallregels eindigen bij de bandbreedte: 1 Gbit/s is 125 megabyte per seconde en bij pakketten van 64 byte ongeveer 1,49 miljoen pakketten per seconde. Daarboven beslist uitsluitend het netwerk vóór de server.
• Bij KernelHost zit de permanente bescherming in twee lagen zonder meerprijs in elk serverpakket en is zij vanaf de oplevering actief, zonder null-routing. Wie de filtering zelf wil sturen, krijgt haar met de Advanced DDoS Protection vanaf 50,00 € per maand.

Draait uw Mordhau-server al bij KernelHost, dan is de filtering actief zonder dat u iets hoeft te doen. Merkt u toch iets ongewoons, open dan een supportticket, zodat de filterregels voor uw IP-adres worden bijgesteld. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883.