Protecting a Mordhau server from DDoS attacks

A Mordhau server that drops every player at once in the middle of a Frontline round and then goes offline and disappears from the server list for a few minutes rarely has a hardware problem. In the vast majority of cases an attack is running against one of the four UDP ports a Mordhau dedicated server has to keep open to the outside. This article first covers the parts of Mordhau DDoS protection you can handle yourself at no extra cost, then shows where those measures physically end, and finally explains what has to happen in the network in front of the server.

Everything here refers to the official Mordhau dedicated server (Steam App ID 629800, Unreal Engine 4) on Debian 12, Debian 13, Ubuntu 22.04 LTS or Ubuntu 24.04 LTS. The commands are written for root. As a normal user, put sudo in front of them. If the attack is running right now, do not change the configuration and do not restart the server. Capture the measurements first (section 9), because once the attack is over they are gone. With Mordhau there is a second reason, one many operators learn the hard way: on shutdown the server process writes its in-memory state back into Game.ini. Edit that file while the server is running and your changes are lost at the next stop.

Why Mordhau servers need DDoS protection and who attacks them

Mordhau servers get attacked because their address is public, because all game traffic runs over UDP, and because an outage is immediately visible to everybody. The server browser entry contains the IP address and the game port in plain text, otherwise players could never find the server. Public server lists and trackers pull the same data through the Steam query port and publish it a second time. Your address is therefore not a secret, it is a product specification.

On top of that comes the technology of the game. Unreal Engine 4 transports movement, hits and parries over UDP. UDP has no connection setup you could insist on, and the source address of a UDP packet can be spoofed. So an attacker does not have to join your server, or even address it correctly, in order to create load. With Mordhau this weighs heavier than with many other games: an exchange of blows is decided within a few tenths of a second, and 200 milliseconds of added delay already make melee unplayable, long before the server actually fails. That is exactly why a small attack is enough to ruin a round. For the details of what a DDoS attack actually is, read What is a DDoS attack?.

The usual triggers are unspectacular: competition between communities, banned players, lost duels, an argument on Discord. An attack costs whoever orders it neither skill nor any serious amount of money, because rented booter services do the work. Operators regularly report that the attacks start exactly when the server is full and stop once it is empty. That is not a coincidence, it is a sign that somebody is watching your server browser entry and using the player count as a trigger.

The ports that actually matter for Mordhau

A Mordhau dedicated server needs exactly four UDP ports facing the outside: 7777, 7778, 15000 and 27015. Everything else is either optional or has no business on the open internet. The ports are passed as startup parameters:

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

Two things are regularly misunderstood here. First, the beacon port 15000 is not an accessory. The beacon reserves the slot the moment a player joins, so that the player does not get thrown out again after loading the map. If 15000 is blocked or overloaded, players stop getting in even though port 7777 answers. Second, RCON is not preconfigured on Mordhau. It only becomes active once you set RconPassword and RconPort, and it then runs over TCP, not over UDP.

The key numbers of a Mordhau server at a glance:

The attack patterns that actually occur against Mordhau

Four patterns cover practically everything that gets fired at a Mordhau server, and each one hits a different port.

• UDP flood against the game port 7777. This is the standard booter attack: as many spoofed packets as possible against the port listed in the server browser. It targets bandwidth and packet rate, not a vulnerability, and it shows up as lag spikes long before anybody loses the connection.
• Query flood against the query port 27015. An A2S_INFO query is 25 bytes, the response with server name, map, game mode and player count is a multiple of that. The attacker invests very little and forces processing work and outbound traffic on your side.
• Reflection through your own query port. Here your server is not the target but the tool: the attacker sends queries with a spoofed source address and your server answers the victim. You notice it as inexplicably high outbound traffic on 27015 and as an abuse report from your provider.
• Join and slot exhaustion through the beacon port 15000. Instead of burning bandwidth, automated joins occupy the reserved slots. The server keeps running, but it is full, and real players stop getting in.

A fifth pattern is added as soon as RCON sits openly on the internet: login attempts every second against the RCON port. That is rarely volumetric, but it costs processing time, and it is the only one of the five cases where a single hit takes the server out of your hands entirely.

What you can do yourself before spending money

This section is the longest one, and that is deliberate. A cleanly configured Mordhau server survives small and medium attacks under its own power, no matter who hosts it.

1. Take stock: what is listening on the server at all?

Before you write a single firewall rule, check what your server actually offers to the outside. Do not guess, look:

ss -lntup

The interesting column is the local address. 0.0.0.0:7777 and [::]:7777 mean "reachable from the entire internet", 127.0.0.1:27020 means "local only" and needs no firewall rule. Next to the game you will often find a web panel, a database service and some long forgotten voice service in that list. A scan from outside gives you the attacker's view, for UDP with a short port list because a full UDP scan is very slow:

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

2. Leave open only the four ports Mordhau really needs

Four UDP rules facing the outside are enough for Mordhau, everything else gets restricted or is never published in the first place. With UFW it looks like this, and in exactly this order so that you do not lock yourself out:

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

Replace 203.0.113.10 with your own address. What matters is what is not in that list: no rule for a web panel, none for a database, none for a file server. Every additional open port is an additional target that has nothing to do with the game. The full guide including the escape route is in Setting up the UFW firewall without locking yourself out.

3. Rate-limit query port 27015 without falling out of the server list

You may rate-limit the query port, but you must not close it. If 27015 UDP is shut, your server disappears from the server browser, because the player count, the map name and the server name are all requested through exactly that port. An upper limit per source address solves the problem without costing you visibility:

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

A regular server browser queries your server a few times per minute, not a few times per second. Ten queries per second and source address are therefore generous for any player and tight for any bot. Afterwards use the hit counter to check whether the rule is reached at all:

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

This is also the answer to the reflection question. In a reflection your server is not attacked but abused as an amplifier: the queries arrive with a spoofed source address and your answers hit a stranger. A rate limit per source address is the most effective local countermeasure, because a spoofed source address only pays off for as long as your server answers willingly and without a limit.

4. Take RCON off the open internet

On Mordhau, RCON has no business sitting unrestricted on the internet. The access is enabled in Game.ini, in the section [/Script/Mordhau.MordhauGameSession]:

[/Script/Mordhau.MordhauGameSession]
ServerName=My Mordhau Server
MaxSlots=64
ServerPassword=
AdminPassword=ALongRandomPassword
RconPassword=ADifferentLongRandomPassword
RconPort=27020

Mordhau speaks the Source RCON protocol, which means TCP, and therefore works with every common RCON tool. That is exactly what the scripts that try credentials use as well. Three rules cover the case. First, RconPassword and AdminPassword are two different, long, random passwords and not variations of the server name. Second, restrict the rule for the RCON port to your own address, as in the UFW block above. Third, if you have no static address: keep the port closed to the outside and reach it through an SSH port forward, then connect locally to 127.0.0.1:27020:

ssh -N -L 27020:127.0.0.1:27020 root@YOUR.SERVER.IP.ADDRESS

If RCON has to stay open anyway, at least limit the simultaneous connections per source address. An RCON tool needs one connection, a brute force script needs hundreds:

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

5. Protect beacon port 15000 against join floods

The beacon port is the underestimated attack surface of a Mordhau server. Through it the game reserves the slot of a joining player while that player is still loading. A bot that triggers joins in quick succession occupies slots without ever arriving in the game. The server stays online and still looks full. An upper limit per source address catches that, because a real player beacons exactly once per join and not twenty times per second:

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

The second rule applies to the game port and needs a sense of proportion. At a tick rate of 60 the server exchanges on the order of 60 packets per second per direction with every connected player. A threshold of 400 packets per second per source address therefore leaves every real player plenty of room and still catches every source that is obviously flooding. Measure a week of normal operation before you tighten it: setting the limits too tight throws out your own players, and operators then mistake that for an attack.

Plain iptables rules are gone after a reboot. On Debian and Ubuntu you save them like this:

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

Under UFW, such rules belong in /etc/ufw/before.rules, because otherwise they disappear with the next ufw reload.

6. Game.ini and Engine.ini: what actually makes a difference

Mordhau has two configuration files, and on Linux both live in Mordhau/Saved/Config/LinuxServer/, on Windows in Mordhau\Saved\Config\WindowsServer\. Game.ini governs server name, slots, passwords, admin list, map rotation and the mod IDs from mod.io, Engine.ini governs the network behavior. Edit both only while the server is stopped, otherwise the server process overwrites your changes with its in-memory state on shutdown.

Three settings really matter for the attack surface. First a ServerPassword: it keeps out everyone who is not invited, but it costs public discoverability and does nothing against a flood on port 7777, because the attacker does not want to join in the first place. Second a realistic MaxSlots value: Mordhau is designed for up to 64 players, and every additional slot is an additional packet source your CPU has to serve. Third the tick rate in Engine.ini:

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

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

The default tick rate of a Mordhau server is 60. Raising it to 120 doubles the packet rate per player and the CPU load, which is exactly what you do not want while under attack. A 64 slot server at tick rate 120 already produces on the order of 8,000 packets per second per direction in normal operation. If you are being shot at continuously, you run noticeably more stable at 60 than at 120.

7. Relieve connection tracking and the receive buffers

A bottleneck that is often overlooked is the connection tracking of the kernel. It keeps an entry for every UDP flow, and a flood from tens of thousands of spoofed source addresses fills the table within seconds. Once it is full, the server drops legitimate packets as well, and the log says "nf_conntrack: table full". The current value and the limit are shown by:

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

Two things help against it. You raise the limit, or you exempt the game ports from tracking entirely. The latter is usually the better route on a game server, because UDP has no state that would need tracking anyway:

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

Larger receive buffers and a deeper queue on the network card make sense as well, so that short spikes do not immediately turn into drops:

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

To make these values permanent, put them into a file under /etc/sysctl.d/, for example 99-gameserver.conf. One thing to understand: larger buffers do not raise your resilience against a large attack, they only prevent a short spike from costing packets.

8. Your address is in the server list, and that cannot be changed

Honesty beats wishful thinking here: the IP address of a public Mordhau server cannot be kept secret. It is in the server browser entry, it is in the public third-party server lists that read the query port regularly, and every player who has connected once knows it. Changing the address therefore buys hours, rarely days, because the attacker finds the new address through the same route as the old one.

Three habits are effective instead. Never publish the raw IP address yourself, so neither in the Discord channel nor on the project website. Connect your players through a hostname, so that changing the address does not break every reference when it comes to that. And clean up old DNS records, because a forgotten A record pointing at the previous address makes any change pointless. The same applies to test servers: every publicly reachable second server on the same machine gives away the address of the main server.

9. Measure while everything is still normal

The most important step is the one almost nobody takes beforehand: build a baseline while the server is still quiet. Without a normal value you cannot say after an incident whether 40,000 packets per second was a lot or simply a Saturday evening. With apt-get install -y vnstat sysstat the measurement runs permanently in the background. During an incident four commands are enough:

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

One rule for tcpdump: always cap it with -c, because a capture under full load puts extra strain on a server that is already overloaded. Pay particular attention to the drop counters from ip -s link. Rising dropped values together with a quiet CPU are the clearest sign that the packet rate and not the processing power is the problem. How to read the numbers is covered in Detecting a DDoS attack. How to install and update the server cleanly with SteamCMD is covered in Installing a game server with SteamCMD.

Where these measures stop: bandwidth and packet rate

Now the part that no configuration file can solve. Everything so far runs on your server, which means at the far end of the uplink. A firewall rule decides about a packet that has already traveled down the wire. You can drop it, but you cannot un-send it.

Do the math once. A typical game server sits on 1 Gbps, which is 125 megabytes per second, and the uplink is full as soon as somebody sends more. A full Mordhau server with 64 slots uses only a fraction of that: at tick rate 60 the game traffic is on the order of 4,000 packets per second per direction. A rented booter, by contrast, easily delivers 5 to 50 Gbps, so five to fifty times your uplink. Whether your iptables rule behind it is any good no longer matters, because the packets of your players stop getting through before that.

The second figure is the packet rate, and it often hits earlier than the bandwidth does. With small packets of 64 bytes, around 1.49 million packets per second fit into an uplink of 1 Gbps. Depending on CPU and network card, a normal server kernel handles a few hundred thousand of them before it starts dropping. So an attack that does not even fill a third of your uplink can still take your Mordhau server down, because the processing time goes into the dropping. Operators experience this as "the utilization was not even high, and yet everything was gone".

For a sense of the magnitudes that really occur: on KernelHost servers we have filtered, among others, an attack of over 473.4 Gbps at over 41.5 million packets per second against a voice server, and a UDP flood of over 112.2 Gbps against a game server. There is no local setting for that. Volumetric attacks have to end in the network in front of the server.

What KernelHost puts up against it

The always-on protection included with every server

DDoS protection at KernelHost is built in two layers and permanently active, with nothing for you to switch on, order or configure:

• Layer 1: 17 Tbps of mitigation capacity in the global scrubbing network. Volumetric attacks are scrubbed close to their source, before they reach the datacenter.
• Layer 2: Arbor real-time filtering with 3.2 Tbps in Frankfurt am Main. Directly in front of the server, protocol-specific patterns are detected and dropped, packet by packet.

Two properties make the difference. The protection runs permanently and does not have to react to an attack first, so there are no opening minutes in which the server is gone. And no null-routing is used: your IP address stays on the network, only the malicious packets are dropped. Whoever takes the IP address off the network achieves the same result for you as the attacker does. The location is Frankfurt am Main. Which games and protocols are covered is listed in Game server DDoS protection with real-time filtering.

Advanced DDoS Protection for Mordhau servers under constant fire

Some servers are attacked not occasionally, but deliberately and for weeks on end. For those there is Advanced DDoS Protection from €50.00 per month, PrePaid, with no minimum term and no setup fee. The difference is not more capacity, it is control:

• A dedicated protected IP from the Frankfurt core, which your server is switched over to inside our own network. Nothing has to be rebuilt on your side.
• Self-managed protection rules per port and protocol in the customer panel: you define separately what is allowed on 7777 UDP, what on 15000 UDP and what on 27015 UDP, without writing a ticket for it.
• Changes take effect in real time, so you can fine-tune while an attack is still running instead of waiting for a maintenance window.
• A protection profile that matches the game. There are ready-made profiles for Unreal Engine game servers on UDP and for Steam query ports, and there are profiles for modified and custom applications on any TCP or UDP port.

Advanced DDoS Protection is aimed at servers running at KernelHost. If your Mordhau server currently sits somewhere else and keeps getting shot off the network, moving it here is the route to this filtering.

The two tiers compared

For most Mordhau servers the included always-on protection together with a clean configuration is enough. Advanced DDoS Protection is the answer to somebody taking it personally.

Common mistakes and how to fix them

"I closed port 27015 and now my server is no longer in the list": that is the expected consequence. The Steam query port delivers name, map and player count to the server browser. Without it your server no longer appears, or it is listed as unreachable. The correct move is a rate limit per source address instead of a block.

"Players cannot get in even though the server is running": check port 15000 UDP first. The beacon reserves the slot during loading. If it is blocked, filtered too tightly or overloaded, the join hangs even though port 7777 answers and the server shows up in the browser.

"My changes in Game.ini are gone after a restart": you edited the file while the server was running. On shutdown the Mordhau server process writes its in-memory state back and overwrites your version in the process. Stop the server, edit, start, in that order.

"My iptables rules have no effect": three causes are common. The rules sit behind the UFW chains and are never reached, they were gone after the last reboot (then netfilter-persistent save or an entry in /etc/ufw/before.rules helps), or the attack is volumetric and the rule works correctly on an uplink that is already full. Use iptables -L INPUT -n -v to check whether the hit counters are rising. If they stay at zero, the rule is never reached.

"The server is running, but everybody has lag spikes and hits register too late": first check whether the inbound packet rate is rising while the CPU stays quiet. That is exactly the pattern of an attack. If the packet rate stays normal and the CPU sits at 100 percent, it is not a DDoS attack but usually too high a tick rate, too many slots or a mod.

"My provider reports outbound abuse from port 27015": your server was abused as an amplifier for a reflection. The queries arrived with a spoofed source address, and your server answered a stranger. A rate limit on 27015 UDP per source address ends it.

"My previous provider blocked my IP address": that is null-routing. The provider protects its own network with it, and for you the result is identical to a successful attack, usually for hours afterwards. If in doubt, ask whether traffic is filtered or null-routed. The answer says more about your availability than any hardware spec.

"I do not see anything unusual in tcpdump": if the traffic is already filtered in the network upstream, nothing arrives on the server, exactly as expected. That is the normal case when the filtering works. The other way round applies as well: once the uplink is saturated, even the SSH session you wanted to measure with may no longer reach you. Use the VNC console in the customer panel then, which works independently of the network of the guest system.

In short

• A Mordhau dedicated server needs exactly four UDP ports facing the outside: 7777 (game), 7778 (Steam), 15000 (beacon) and 27015 (Steam query). Everything else stays closed.
• RCON on Mordhau runs over TCP using the Source RCON protocol and only becomes active through RconPassword and RconPort in Game.ini. Restrict that port to your own address.
• You may rate-limit port 27015 UDP, but you must not close it: without it your server disappears from the server browser, because player count, map and name are requested through that port.
• Port 15000 UDP is the beacon port and reserves the slot during loading. If it is blocked or overloaded, players cannot get in even though the server is running.
• Edit Game.ini and Engine.ini only while the server is stopped, because the server process writes its in-memory state back on shutdown.
• Local firewall rules end at the bandwidth: 1 Gbps is 125 megabytes per second and, with 64 byte packets, around 1.49 million packets per second. Beyond that, only the network in front of the server decides the outcome.
• At KernelHost the two-layer always-on protection is included with every server package at no surcharge and active from provisioning onwards, with no null-routing. If you want to steer the filtering yourself, Advanced DDoS Protection starts at €50.00 per month.

If your Mordhau server already runs at KernelHost, the filtering is active without you having to do anything. If you still notice something unusual, open a support ticket so that we can fine-tune the filter rules for your IP address. During an ongoing attack you can also reach us through the WhatsApp emergency chat at +43 650 8209883.