Skydda Mordhau-servern mot DDoS-attacker

En Mordhau-server som mitt i en Frontline-omgång tappar alla spelare på en gång, sedan ligger nere i ett par minuter och inte längre syns i serverlistan, har sällan ett hårdvaruproblem. I de allra flesta fall pågår en attack mot en av de fyra UDP-portar som en dedikerad Mordhau-server måste hålla öppna utåt. Den här artikeln visar först vad du själv kan göra för DDoS-skyddet på din Mordhau-server utan extra kostnad, därefter var dessa åtgärder tar slut rent fysiskt, och till sist vad som måste hända i nätet framför servern.

Alla uppgifter gäller den officiella dedikerade Mordhau-servern (Steam-app-ID 629800, Unreal Engine 4) under Debian 12, Debian 13, Ubuntu 22.04 LTS eller Ubuntu 24.04 LTS. Kommandona är skrivna för root, som vanlig användare sätter du sudo framför. Pågår attacken just nu: ändra först ingenting i konfigurationen och starta inte om servern, utan säkra mätvärdena (avsnitt 9), för efter attacken är de borta. Hos Mordhau tillkommer ett andra skäl som många operatörer lär sig den hårda vägen: serverprocessen skriver vid avslut tillbaka sitt tillstånd från arbetsminnet till Game.ini. Den som redigerar filen medan servern kör förlorar sina ändringar vid nästa stopp.

Varför Mordhau-servrar behöver DDoS-skydd och vem som attackerar dem

Mordhau-servrar attackeras för att deras adress är offentlig, för att hela speltrafiken går över UDP och för att ett avbrott omedelbart syns för alla. Posten i serverlistan innehåller IP-adress och spelport i klartext, annars skulle spelarna inte hitta servern. Offentliga serverlistor och trackrar hämtar samma uppgifter via Steams query-port och publicerar dem en andra gång. Din adress är därmed ingen hemlighet, utan en produktuppgift.

Till det kommer spelets teknik. Unreal Engine 4 överför rörelser, träffar och parader över UDP. UDP känner inte till någon uppkoppling som man skulle kunna kräva, och avsändaradressen i ett UDP-paket går att förfalska. En angripare behöver alltså varken gå in på din server eller tilltala den korrekt för att skapa belastning. Hos Mordhau väger det tyngre än i många andra spel: ett utbyte av hugg avgörs inom några tiondels sekunder, och redan 200 millisekunders extra fördröjning gör närstriden ospelbar, långt innan servern faktiskt slutar svara. Just därför räcker en liten attack för att förstöra en omgång. Vad en DDoS-attack är i detalj förklarar artikeln Vad är en DDoS-attack?.

De typiska utlösarna är odramatiska: konkurrens mellan communities, bannade spelare, förlorade dueller, gräl i Discord. En attack kostar beställaren varken kunnande eller nämnvärda pengar, eftersom hyrda bootertjänster gör jobbet. Operatörer rapporterar regelbundet att attackerna startar precis när servern är full och upphör så snart den är tom. Det är ingen slump, utan ett tecken på att någon bevakar din post i serverlistan och använder spelarantalet som avtryckare.

Portarna som det faktiskt handlar om hos Mordhau

En dedikerad Mordhau-server behöver exakt fyra UDP-portar utåt: 7777, 7778, 15000 och 27015. Allt annat är antingen valfritt eller hör inte hemma på det öppna nätet. Portarna skickas med som parametrar vid start:

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

Två saker missförstås regelbundet. För det första: beacon-porten 15000 är inget bihang. Beaconen reserverar platsen i samma ögonblick som en spelare ansluter, så att spelaren inte kastas ut igen efter att kartan har laddats. Är 15000 blockerad eller överbelastad kommer spelare inte längre in, trots att port 7777 svarar. För det andra: RCON är inte förkonfigurerat hos Mordhau. Det blir aktivt först när du sätter RconPassword och RconPort, och går då över TCP, inte över UDP.

De viktigaste nyckeltalen för en Mordhau-server i korthet:

Attackmönstren som förekommer hos Mordhau

Fyra mönster täcker praktiskt taget allt som körs mot en Mordhau-server, och varje mönster träffar en egen port.

• UDP-flod mot spelporten 7777. Det är en booters standardattack: så många förfalskade paket som möjligt mot den port som står i serverlistan. Den siktar på bandbredd och paketfrekvens, inte på en sårbarhet, och visar sig först som laggspikar, långt innan någon tappar anslutningen.
• Förfrågningsflod mot query-porten 27015. En A2S_INFO-förfrågan är 25 byte stor, svaret med servernamn, karta, spelläge och spelarantal många gånger större. Angriparen investerar alltså lite och framtvingar hos dig både beräkningsarbete och utgående trafik.
• Reflection via din egen query-port. Här är din server inte målet, utan verktyget: angriparen skickar förfrågningar med förfalskad avsändaradress, och din server svarar offret. Du märker det som oförklarligt hög utgående trafik på 27015 och som en abuse-anmälan från din leverantör.
• Anslutnings- och platsutmattning via beacon-porten 15000. I stället för att bränna bandbredd upptar automatiserade anslutningar de reserverade platserna. Servern kör vidare, men är full, och riktiga spelare kommer inte längre in.

Till det kommer ett femte mönster så snart RCON står öppet på nätet: inloggningsförsök i sekundtakt mot RCON-porten. Det är sällan volymetriskt, men kostar beräkningstid, och det är det enda av de fem fallen där en träff tar servern helt ur dina händer.

Vad du själv kan göra innan du lägger ut pengar

Det här avsnittet är det längsta, och det med avsikt. En rent konfigurerad Mordhau-server klarar små och medelstora attacker av egen kraft, oavsett var den står.

1. Inventering: vad lyssnar överhuvudtaget på servern?

Innan du skriver en enda brandväggsregel: se efter vad din server erbjuder utåt. Inte gissa, titta efter:

ss -lntup

Intressant är kolumnen med den lokala adressen. 0.0.0.0:7777 och [::]:7777 betyder "nåbar från hela internet", 127.0.0.1:27020 betyder "bara lokalt" och behöver ingen brandväggsregel. Vid sidan av spelet dyker där ofta upp en webbpanel, en databastjänst och en sedan länge bortglömd rösttjänst. Angriparens vy ger en skanning utifrån, för UDP med en kort portlista, eftersom en fullständig UDP-skanning är mycket långsam:

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

2. Håll bara de fyra portar öppna som Mordhau verkligen behöver

För Mordhau räcker fyra UDP-öppningar utåt, allt annat begränsas eller publiceras inte alls. Med UFW ser det ut så här, och i exakt den här ordningen, så att du inte låser ute dig själv:

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

Ersätt 203.0.113.10 med din egen adress. Viktigt är vad som inte står här: ingen öppning för en webbpanel, ingen för en databas, ingen för en filserver. Varje ytterligare öppen port är ett ytterligare mål som inte har med spelet att göra. Den fullständiga anvisningen inklusive räddningsvägen hittar du under Sätt upp UFW-brandväggen utan att låsa ute dig själv.

3. Begränsa query-porten 27015 utan att åka ur serverlistan

Query-porten får du begränsa, men inte stänga. Stängs 27015 UDP försvinner din server ur serverlistan, eftersom spelarantal, kartnamn och servernamn läses ut just via den porten. En övre gräns per källadress löser problemet utan att kosta synligheten:

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

En vanlig serverlista frågar din server några gånger per minut, inte några gånger per sekund. Tio förfrågningar per sekund och källadress är därmed generöst för varje spelare och trångt för varje bot. Kontrollera därefter på träffräknaren om regeln överhuvudtaget används:

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

Här ligger också svaret på reflection-frågan. Vid en reflection attackeras inte din server, utan missbrukas som förstärkare: förfrågningarna kommer med förfalskad avsändaradress, och dina svar träffar ett främmande offer. En hastighetsbegränsning per källadress är däremot den mest verkningsfulla lokala åtgärden, eftersom en förfalskad avsändaradress bara är till nytta så länge din server svarar villigt och obegränsat.

4. Ta bort RCON från det öppna nätet

RCON hör hos Mordhau under inga omständigheter hemma obegränsat på internet. Åtkomsten slås på i Game.ini, i avsnittet [/Script/Mordhau.MordhauGameSession]:

[/Script/Mordhau.MordhauGameSession]
ServerName=Min Mordhau-server
MaxSlots=64
ServerPassword=
AdminPassword=EttLångtSlumpmässigtLösenord
RconPassword=EttAnnatLångtSlumpmässigtLösenord
RconPort=27020

Mordhau talar Source-RCON-protokollet, alltså TCP, och fungerar därför med alla gängse RCON-verktyg. Precis det utnyttjar även skripten som provar inloggningsuppgifter. Tre regler täcker fallet. För det första: RconPassword och AdminPassword är två olika, långa, slumpmässiga lösenord och inga varianter av servernamnet. För det andra: öppningen för RCON-porten begränsar du till din egen adress, precis som i UFW-blocket ovan. För det tredje, om du inte har en fast adress: håll porten stängd utifrån och nå den via en SSH-portvidarebefordran, därefter ansluter du lokalt till 127.0.0.1:27020:

ssh -N -L 27020:127.0.0.1:27020 root@DIN.SERVER.IP.ADRESS

Måste RCON ändå förbli öppet: begränsa åtminstone de samtidiga anslutningarna per källadress. Ett RCON-verktyg behöver en anslutning, ett skript för lösenordsknäckning hundratals:

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

5. Säkra beacon-porten 15000 mot anslutningsfloder

Beacon-porten är den underskattade angreppspunkten på en Mordhau-server. Via den reserverar spelet platsen för en anslutande spelare så länge denne fortfarande laddar. En bot som i snabb följd startar anslutningar upptar därmed platser utan att någonsin komma in i spelet. Servern förblir uppe och verkar ändå full. En övre gräns per källadress fångar upp det, eftersom en riktig spelare skickar exakt en beacon per anslutning och inte tjugo per sekund:

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

Den andra regeln gäller spelporten och kräver omdöme. Vid en tickrate på 60 utbyter servern i storleksordningen 60 paket per sekund och riktning med varje ansluten spelare. Ett gränsvärde på 400 paket per sekund och källadress ger därmed varje riktig spelare gott om luft och träffar ändå varje källa som uppenbart flodar. Mät först en vecka i normal drift innan du drar åt: den som ställer för trångt kastar ut sina egna spelare och tror sedan att det var en attack.

Rena iptables-regler är borta efter en omstart. Under Debian och Ubuntu sparar man dem så här:

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

Under UFW hör sådana regler hemma i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload.

6. Game.ini och Engine.ini: vad som verkligen ger effekt

Mordhau har två konfigurationsfiler, och båda ligger under Linux i Mordhau/Saved/Config/LinuxServer/, under Windows i Mordhau\Saved\Config\WindowsServer\. Game.ini styr servernamn, platser, lösenord, adminlista, kartrotation och mod-identifierarna från mod.io, Engine.ini styr nätbeteendet. Redigera båda uteslutande med servern stoppad, annars skriver serverprocessen vid avslut över dina ändringar med tillståndet från arbetsminnet.

Tre inställningar är verkligen relevanta för angreppsytan. För det första ett ServerPassword: det håller borta alla som inte är inbjudna, men kostar den offentliga synligheten och hjälper inte alls mot en flod mot port 7777, eftersom angriparen inte alls vill ansluta. För det andra ett realistiskt värde för MaxSlots: Mordhau är byggt för upp till 64 spelare, och varje ytterligare plats är en ytterligare paketkälla som din CPU måste betjäna. För det tredje tickraten i Engine.ini:

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

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

Standardvärdet för tickrate på en Mordhau-server är 60. En höjning till 120 fördubblar paketfrekvensen per spelare och CPU-lasten och är därmed precis det du inte kan använda under attack. En server med 64 platser och tickrate 120 skapar redan i normal drift i storleksordningen 8 000 paket per sekund och riktning. Den som beskjuts varaktigt kör märkbart stabilare med 60 än med 120.

7. Avlasta anslutningsspårningen och mottagningsbuffertarna

En ofta förbisedd flaskhals är kärnans anslutningsspårning. Den för en egen post för varje UDP-ström, och en flod från tiotusentals förfalskade avsändaradresser fyller tabellen på sekunder. Blir den full förkastar servern även legitima paket, och i loggen står "nf_conntrack: table full". Läge och övre gräns visas av:

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

Mot det hjälper två saker. Du höjer den övre gränsen, eller så undantar du spelportarna helt från spårningen. Det senare är hos en spelserver oftast den bättre vägen, eftersom UDP ändå inte har något tillstånd som behöver spåras:

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

Lika vettigt är större mottagningsbuffertar och en djupare kö på nätverkskortet, så att korta toppar inte omedelbart leder till förkastade paket:

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

Varaktigt hör de här värdena hemma i en fil under /etc/sysctl.d/, till exempel 99-gameserver.conf. Viktigt att förstå: större buffertar höjer inte din tålighet mot en stor attack, de förhindrar bara att ett kort utslag redan kostar paket.

8. Din adress står i serverlistan, och det går inte att ändra

Här lönar sig ärlighet i stället för önsketänkande: IP-adressen till en offentlig Mordhau-server går inte att hålla hemlig. Den står i posten i serverlistan, den står i tredjeparts offentliga serverlistor som regelbundet läser ut query-porten, och varje spelare som en gång varit ansluten känner till den. Ett adressbyte ger därför timmar, sällan dagar, eftersom angriparen hittar den nya adressen på samma väg som den gamla.

Verkningsfulla är tre vanor. Publicera aldrig själv den råa IP-adressen, alltså inte i Discord-kanalen och inte på projektsidan. Låt dina spelare ansluta via ett värdnamn, så att ett adressbyte i skarpt läge inte bryter samtliga hänvisningar. Och rensa bort gamla DNS-poster, för en bortglömd A-post till den tidigare adressen gör varje byte verkningslöst. Detsamma gäller testservrar: varje offentligt nåbar andraserver på samma maskin avslöjar huvudserverns adress.

9. Mät medan allt går normalt

Det viktigaste steget är det som nästan ingen tar i förväg: att lägga upp en jämförelsegrund medan servern går lugnt. Utan ett normalvärde kan du efter en incident inte säga om 40 000 paket per sekund var mycket eller helt enkelt lördagskväll. Med apt-get install -y vnstat sysstat löper mätningen varaktigt med. Under en incident räcker fyra kommandon:

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

För tcpdump gäller: begränsa alltid med -c, för en inspelning under full last belastar en redan överbelastad server ytterligare. Var särskilt uppmärksam på räknarna för förkastade paket ur ip -s link. Stigande dropped-värden vid samtidigt lugn CPU är det tydligaste tecknet på att paketfrekvensen och inte beräkningskraften är problemet. Hur du tolkar värdena står i Känn igen en DDoS-attack. Hur du sätter upp servern rent via SteamCMD och håller den uppdaterad beskriver Installera spelserver med SteamCMD.

Var dessa åtgärder tar slut: bandbredd och paketfrekvens

Nu den del som ingen konfigurationsfil kan lösa. Alla åtgärder hittills körs på din server, alltså i änden av ledningen. En brandväggsregel avgör om ett paket som redan har färdats genom kabeln. Du kan förkasta det, men inte göra det osänt.

Räkna med en gång. En typisk spelserver hänger på 1 Gbit/s, det är 125 megabyte per sekund, och ledningen är full så snart någon skickar mer. En full Mordhau-server med 64 platser behöver bara en bråkdel av det: vid tickrate 60 ligger speltrafiken i storleksordningen 4 000 paket per sekund och riktning. En hyrd booter levererar däremot utan vidare 5 till 50 Gbit/s, alltså fem till femtio gånger din ledning. Om din iptables-regel bakom den är bra spelar då ingen roll längre, för dina spelares paket kommer redan innan dess inte fram.

Den andra storheten är paketfrekvensen, och den slår ofta till tidigare än bandbredden. Vid små paket på 64 byte ryms cirka 1,49 miljoner paket per sekund i en ledning med 1 Gbit/s. En vanlig serverkärna hanterar beroende på CPU och nätverkskort några hundratusen av dem innan den börjar förkasta. En attack som inte ens fyller en tredjedel av din ledning kan alltså ändå lamslå din Mordhau-server, eftersom beräkningstiden går åt till att förkasta. Operatörer upplever det som "belastningen var ju inte ens hög, ändå var allt borta".

För att sätta storleksordningarna i perspektiv, sådant som verkligen förekommer: på KernelHost-servrar har bland annat en attack med över 473,4 Gbit/s vid över 41,5 miljoner paket per sekund mot en röstserver och en UDP-flod med över 112,2 Gbit/s mot en spelserver filtrerats bort. För det finns ingen lokal inställning. Volymetriska attacker måste sluta i nätet framför servern.

Vad KernelHost ställer mot detta

Det permanenta skyddet som ingår på varje server

DDoS-skyddet hos KernelHost är uppbyggt i två steg och permanent aktivt, utan att du behöver slå på, beställa eller konfigurera något:

• Steg 1: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket. Volymetriska attacker renas nära sin källa, innan de når datacentret.
• Steg 2: Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main. Direkt framför servern känns protokollspecifika mönster igen och förkastas, paket för paket.

Två egenskaper är avgörande. Skyddet löper permanent och behöver inte först reagera på en attack, det finns alltså inga minuter i början då servern är borta. Och ingen nullrouting används: din IP-adress förblir i nätet, förkastade blir bara de skadliga paketen. Den som tar IP-adressen ur nätet uppnår för dig samma resultat som angriparen. Platsen är Frankfurt am Main. Vilka spel och protokoll som täcks listar DDoS-skydd för spelservrar i realtid.

Advanced DDoS Protection för varaktigt beskjutna Mordhau-servrar

Vissa servrar attackeras inte tillfälligt, utan riktat och över flera veckor. För det finns Advanced DDoS Protection från 50,00 € i månaden, PrePaid, utan bindningstid och utan startavgift. Skillnaden ligger inte i mer kapacitet, utan i kontrollen:

• Dedikerad skydds-IP ur Frankfurt-kärnan, som din server ställs om till inom det egna nätet. På din sida behövs ingen ombyggnad.
• Egenadministrerade skyddsregler per port och protokoll i kundportalen: du bestämmer separat vad som är tillåtet på 7777 UDP, vad på 15000 UDP och vad på 27015 UDP, utan att skriva ett ärende för det.
• Ändringar slår igenom i realtid, du kan alltså justera efterhand under en pågående attack i stället för att vänta på ett underhållsfönster.
• Skyddsprofil som passar spelet. För spelservrar på Unreal Engine över UDP och för Steams query-portar finns färdiga profiler, likaså för modifierade och egna applikationer på valfria TCP- eller UDP-portar.

Advanced DDoS Protection riktar sig till servrar som körs hos KernelHost. Står din Mordhau-server för närvarande någon annanstans och skjuts regelbundet av nätet, är flytten vägen till den här filtreringen.

De två stegen i jämförelse

För de flesta Mordhau-servrar räcker det inkluderade permanenta skyddet tillsammans med en ren konfiguration. Advanced DDoS Protection är svaret på att någon tar det personligt.

Vanliga fel och lösningar

"Jag stängde port 27015, nu står min server inte längre i listan": Det är den väntade följden. Steams query-port levererar namn, karta och spelarantal till serverlistan. Utan den syns din server inte längre eller listas som onåbar. Rätt åtgärd är en hastighetsbegränsning per källadress i stället för en spärr.

"Spelare kommer inte in, trots att servern kör": Kontrollera först port 15000 UDP. Beaconen reserverar platsen under laddningen. Är den spärrad, för snävt filtrerad eller överbelastad hänger anslutningen sig, trots att port 7777 svarar och servern står i listan.

"Mina ändringar i Game.ini är borta igen efter omstarten": Du har redigerat filen medan servern kör. Mordhaus serverprocess skriver vid avslut tillbaka sitt tillstånd från arbetsminnet och skriver därmed över din version. Stoppa servern, redigera, starta, i den ordningen.

"Mina iptables-regler biter inte": Tre orsaker är vanliga. Reglerna står bakom UFW-kedjorna och nås aldrig, de var borta efter den senaste omstarten (då hjälper netfilter-persistent save eller en post i /etc/ufw/before.rules), eller så är attacken volymetrisk och regeln arbetar korrekt vid en ledning som sedan länge är full. Kontrollera med iptables -L INPUT -n -v om träffräknarna stiger. Står de kvar på noll nås regeln inte.

"Servern kör, men alla har laggspikar och träffar kommer fram för sent": Se först efter om den inkommande paketfrekvensen stiger medan CPU:n förblir lugn. Precis det är mönstret för en attack. Förblir paketfrekvensen normal och CPU:n står på 100 procent är det ingen DDoS-attack, utan oftast en för hög tickrate, för många platser eller en mod.

"Min leverantör rapporterar utgående missbruk från port 27015": Din server har missbrukats som förstärkare för en reflection. Förfrågningarna kom med förfalskad avsändaradress, svarat har din server till ett främmande offer. En hastighetsbegränsning på 27015 UDP per källadress avslutar det.

"Min tidigare leverantör har spärrat min IP-adress": Det är nullrouting. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i timmar därefter. Fråga vid tveksamhet om det filtreras eller nullroutas. Svaret avgör mer om din tillgänglighet än varje hårdvaruuppgift.

"I tcpdump ser jag inget anmärkningsvärt": Filtreras trafiken redan i nätet framför kommer som väntat ingenting fram till servern. Det är normalfallet vid fungerande filtrering. Omvänt gäller: är ledningen mättad når under vissa omständigheter inte ens SSH-sessionen fram som du ville mäta med. Använd då VNC-konsolen i kundportalen, som fungerar oberoende av gästsystemets nätverk.

Kort sammanfattat

• En dedikerad Mordhau-server behöver exakt fyra UDP-portar utåt: 7777 (spel), 7778 (Steam), 15000 (beacon) och 27015 (Steams query-port). Allt annat hör stängt.
• RCON går hos Mordhau över TCP enligt Source-RCON-protokollet och blir aktivt först genom RconPassword och RconPort i Game.ini. Begränsa porten till din egen adress.
• Port 27015 UDP får du begränsa, men inte stänga: utan den försvinner din server ur serverlistan, eftersom spelarantal, karta och namn hämtas via den porten.
• Port 15000 UDP är beacon-porten och reserverar platsen under laddningen. Är den blockerad eller överbelastad kommer spelare inte in, trots att servern kör.
• Redigera Game.ini och Engine.ini bara med servern stoppad, eftersom serverprocessen vid avslut skriver tillbaka tillståndet från arbetsminnet.
• Lokala brandväggsregler tar slut vid bandbredden: 1 Gbit/s är 125 megabyte per sekund och vid 64 byte stora paket cirka 1,49 miljoner paket per sekund. Däröver avgör uteslutande nätet framför servern.
• Hos KernelHost ingår det permanenta skyddet i två steg i varje serverpaket utan pristillägg och är aktivt från leverans, utan nullrouting. Den som vill styra filtreringen själv får det med Advanced DDoS Protection från 50,00 € i månaden.

Kör din Mordhau-server redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå avvikelser: öppna ett supportärende, så att filterreglerna för din IP-adress justeras efterhand. Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883.