Protecting a Project Zomboid server from DDoS attacks

If you want to protect a Project Zomboid server from DDoS attacks, you first have to know what an attacker is actually shooting at. A dedicated server occupies exactly two UDP ports, 16261 and 16262, and both of them have to be open to the internet, because otherwise nobody can join. This article follows the order that counts when it matters: first what you can do yourself in the next ten minutes at no extra cost, then the point where those measures technically end, and finally what has to happen in the network in front of the server.

Everything here refers to the dedicated server (Steam app 380870) on Debian 12, Debian 13, Ubuntu 22.04 LTS or Ubuntu 24.04 LTS, for Build 41 as well as Build 42. The configuration file is called servertest.ini and lives in ~/Zomboid/Server/, the world data lives in ~/Zomboid/Saves/Multiplayer/. 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 anything in servertest.ini and do not restart the server. Capture the measurements first (section 9), because once the attack is over they are gone. A restart also costs you the time the server needs to load the world, and that is exactly the time the attacker wants to take from you.

Why Project Zomboid servers become a target for DDoS attacks

Project Zomboid is a game with permanent death and a world that keeps running for months. A dropped connection in a dangerous moment costs more here than in almost any other genre: the character is gone, and the world remembers it. That is exactly what turns an outage into a weapon. An attack at 8 pm hits a fixed community, and it hits it where it has the most to lose.

On top of that, the attack itself costs nothing and requires no skill. Booked attack services, called booters or stressers in that scene, are pointed at an IP address and a port with a few clicks, and with Project Zomboid the target is always the same: 16261 UDP. Anyone in a dispute with a banned player, or running a competing community, has a tool at hand that requires neither knowledge nor any serious amount of money.

On top of that, a game server has to publish its address. With Public=true in servertest.ini the server appears in the in-game browser, and a Steam-enabled server is visible in the Steam server browser anyway. So the question is never whether an attacker will find your IP address, only what happens when he shoots at it.

The most uncomfortable part is technical: all game traffic runs over UDP. UDP has no connection setup you could insist on, every packet stands on its own, and the source address can be spoofed. So an attacker does not have to join your server, or even address it correctly, in order to create load. For the details of what a DDoS attack actually is, read What is a DDoS attack?.

Which ports a Project Zomboid server really needs

A dedicated Project Zomboid server needs exactly two open ports: 16261 UDP and 16262 UDP. The official port list of the game names no third one. In servertest.ini they are two separate directives, and the second port does not follow automatically from the first:

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

The division of labor is clear. 16261 UDP carries the game traffic and the connection setup and answers the server browser queries. 16262 UDP is the direct connection port for clients. Without the first, nobody finds the server; without the second, your players see the entry and still cannot get in. That is exactly where the best known error message of the game comes from, the one saying that port 16262 is closed.

Two points cause trouble again and again. First: every server instance needs two free UDP ports. If you run a second world on the same machine, you assign a second pair for it, for example 16274 and 16275, and write both values into the servertest.ini of the second instance. Second: SteamPort1 and SteamPort2 sit in the configuration file with 8766 and 8767, but they belong to the Steam side of the server, not to the game traffic. Open them only if your server does not show up in the Steam list without them, not as a precaution.

What you can do yourself before spending money

This section is the longest one, and that is deliberate. A cleanly configured server survives small and medium attacks under its own power, no matter who hosts it. It will not take a volumetric attack off your hands, but it makes cheap attacks useless and it makes sure you have numbers instead of guesses when it counts.

1. Take stock: what is really listening

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

ss -lntup

The interesting column is the local address. 0.0.0.0:16261 and [::]:16261 mean "reachable from the entire internet", 127.0.0.1:27015 means "local only" and needs no firewall rule. Compare the result against your configuration instead of relying on default values:

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

A port scan from outside gives you the attacker's view. Because Project Zomboid uses UDP exclusively, you need the UDP scan for it, a plain TCP scan does not show the game port at all:

nmap -Pn -sU -p 16261,16262,8766,8767 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. Leave only 16261 and 16262 open

Two rules facing the outside are enough, 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 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid direct connection"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Replace 203.0.113.10 with your own address. The order in which you arm a firewall decides whether you lock yourself out. It is described together with the escape route in Setting up the UFW firewall without locking yourself out. If it happens anyway: on KVM root servers and dedicated servers from KernelHost you reach the system through the VNC console in the customer panel, which works independently of the network of the guest system.

A word about databases and extra services: Project Zomboid needs none. Anything besides the game listening on 0.0.0.0 comes from an earlier installation or from a management panel, and it belongs either bound to 127.0.0.1 or switched off.

3. Take the RCON port 27015 off the internet

RCON is the remote control of the server and runs on 27015 TCP in Project Zomboid. The shipped servertest.ini contains RCONPassword= with no value. If you use RCON, set a long random password, because the protocol transmits in clear text, and a reachable RCON port with a weak password hands over the entire server without a single attack packet being necessary.

The safe route is not to open the port to the outside at all and to reach it through SSH port forwarding instead. After that you talk to 127.0.0.1:27015 locally:

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

If you do not need RCON, leave the password field empty and the port closed. A service that cannot be reached can neither be brute forced nor flooded.

4. Limit packet rates per source address

Against small attacks and sloppy bots, an upper limit per source address helps. Because both game ports sit next to each other, one rule for the range is enough:

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

The rule drops UDP packets once the same source address sustains more than 400 packets per second. That number is a starting point, not a truth: a server with 30 players in the same town produces far more traffic than one with four players spread across the map, and setting the limit too tight throws out your own players. Measure a week of normal operation first, then set the limit to a multiple of the peak value.

Two notes on this. Plain iptables rules are gone after a reboot, and 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. Use the hit counters from iptables -L INPUT -n -v to check whether the rule is reached at all. If the counters stay at zero, it sits in the wrong place.

5. Relieve the connection tracking of the kernel

An often overlooked bottleneck sits in the kernel. Connection tracking creates an entry per source address and port for UDP as well, and a flood with spoofed senders fills that table in seconds. Once it is full, the server drops legitimate packets too, 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

The game traffic of Project Zomboid does not need state tracking, because UDP has no state. You can therefore keep both game ports out of that table:

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

That relieves the kernel noticeably. One caveat: the rule only fits as long as the server receives the packets directly. If address translation happens in front of it, for example in a container setup with published ports, do not set it, because the return path can no longer be matched.

6. Secure the join path and the slots

The next lines cost nothing and work against everything that comes in through the regular join path:

Password=A-LONG-RANDOM-PASSWORD
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password is the shared server password and is separate from the account of the individual player. Open=false means that only accounts an administrator created beforehand may join, which is the whitelist of the game. MaxAccountsPerUser limits how many accounts a single Steam user may create on your server, and the default of 0 means unlimited. MaxPlayers ships at 32, and above that the documentation explicitly warns about poor map streaming and desync.

PingLimit is the trap in this section. The directive kicks players above a latency in milliseconds and ships at 0, which means off. Under an attack the latency of your own players rises first, so a tight value kicks exactly the people you want to keep. Leave the limit off or set it generously.

And one thing has to be clear: a whitelist protects your game logic, not your uplink. An attacker who floods your server does not want to join at all. His packets get rejected, but they have arrived all the same, and that is exactly the point.

7. The mod check on connect is the most expensive second of your server

Project Zomboid checks more than a password on connect. The mod list of the server sits in two lines of servertest.ini: WorkshopItems holds the numeric Workshop IDs, Mods holds the loading IDs of the mods, both separated by semicolons. On join, the client compares that list, downloads missing Workshop content automatically through Steam, and only then does it get the world data streamed. In addition, with DoLuaChecksum=true the server compares the checksums of the game files and kicks clients whose files do not match its own.

That is exactly what makes it interesting for an attacker, because the work happens before anyone is actually playing. Every connection attempt costs the server processing time for version, checksum, mod list and map data, including the attempt that gets rejected in the end. A long mod list makes every one of those attempts more expensive. A join flood is therefore more effective against a heavily modded server than against a vanilla one, and it needs a fraction of the bandwidth of a volumetric attack. The game brings two built-in brakes against it:

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer rejects new logins while the server is overloaded instead of tearing down the running session as well. LoginQueueEnabled puts joining players into a queue instead of processing them all at once, and LoginQueueConnectTimeout defines how long a join may take, 60 seconds by default, with 20 to 1200 allowed.

One detail belongs here because it is often solved the wrong way: on Linux servers there is a documented bug in which DoLuaChecksum raises false alarms and keeps players out. Operators switch the check off because of it. That is understandable, but it removes a control that keeps clients with modified game files away. If you have to switch it off, set the server password, the whitelist and the account limit all the more strictly.

8. Server list, UPnP and your own address

Honesty beats wishful thinking here: your IP address cannot be kept secret. Public=true shows the server in the in-game browser, and according to the documentation a Steam-enabled server is visible in the Steam server browser anyway. So Public=false costs you visibility for new players without making you invisible.

Public=true
PublicName=My Zomboid Server
UPnP=false
server_browser_announced_ip=

UPnP ships as true and makes the server try to set up a port forwarding rule on an internet gateway by itself. On a rented server there is no such gateway, the attempt leads nowhere and belongs switched off. server_browser_announced_ip stays empty unless your server has several addresses and is supposed to be announced under one specific address. You will need exactly that field again when you switch to a dedicated protected IP.

Two habits help more than any setting. Never publish the raw IP address yourself, so neither in the Discord channel nor on the project website, and give your players a hostname. The classic pitfall when changing an address is old DNS records: a forgotten A record pointing at the previous address makes any change pointless.

9. Measure while everything is still normal

The most important step is the one almost nobody takes beforehand: build a baseline while everything is 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
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

The first two show the packet rate and the drop counters of the interface, the third a short sample of the traffic, the fourth the messages of the server if it runs as a systemd service (adjust the service name). 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. How to read the numbers is covered in Detecting a DDoS attack on your server.

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. 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 1 Gbps, while a normal server kernel handles only a few hundred thousand of them, depending on CPU and network card, before it starts dropping. So an attack that does not even fill a third of your uplink can still take your server down. Operators experience this as "the utilization was not even high, and yet everything was gone".

Usual attacks against game server communities range between 5 and 50 Gbps, so five to fifty times a normal uplink. 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 DDoS attacks on game servers

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. Which games and protocols are covered is listed in Game server DDoS protection with real-time filtering.

Advanced DDoS Protection for projects under constant fire

Some projects 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, you only enter the new address where your players find the server.
• Self-managed protection rules per port and protocol in the customer panel: you define what is allowed on 16261 and 16262 UDP, and everything else stays closed, without writing a ticket for it.
• Changes take effect in real time, so you can fine-tune while an attack is still running.
• A matching protection profile. There are ready-made profiles for common games, and for modified or custom applications you set the rules per port and protocol yourself. Project Zomboid can be fenced in particularly precisely, because all of its game traffic runs over two adjacent UDP ports.

The two tiers compared

For most Project Zomboid 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

"My players get the message that port 16262 is closed": that is not an attack, it is a missing rule. The server needs both ports, 16261 UDP and 16262 UDP, and they have to be UDP rules. A TCP rule on the same numbers does nothing. Check with ufw status verbose and a UDP scan from outside whether both are really open.

"I changed the IP address and was offline again two hours later": the attacker got the new address from the same source as the old one, usually the list entry, a Discord bot with a status display or an old DNS record. In Project Zomboid the change costs you extra on top: clients store the map data locally under address and port, in a folder following the pattern 123.45.0.12_16261_... under Zomboid/Saves. After a change, every player downloads the explored map from the server again. So changing the address buys time at a price, it is not a solution.

"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.

"Players get thrown out on join while the server keeps running normally": that is almost always the check, not an attack. The causes are a version difference between client and server, a missing or outdated Workshop entry, or a checksum that does not match. The client usually names the mods that do not match. Compare WorkshopItems and Mods line by line.

"Lag spikes every few minutes, then it runs again": that is the usual pattern of short attacks, which only run until the players give up in frustration. Look at the network counters first, not at the CPU load. If sar -n DEV 1 10 and the drop counters stay unremarkable, it was not an attack but load: too many players in the same cell, an expensive mod, or too little memory for the Java instance.

"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.

In short

• A dedicated Project Zomboid server needs exactly two open ports: 16261 UDP (DefaultPort) and 16262 UDP (UDPPort). Both are separate directives in servertest.ini.
• RCON runs on 27015 TCP and ships without a password. That port has no business on the open internet, it belongs restricted to your own address or closed.
• The mod check on connect is the most expensive spot: version, checksum, Workshop list and map data cost processing time, including on every rejected attempt. DenyLoginOnOverloadedServer and the login queue are the built-in brakes against it.
• A server password, Open=false and MaxAccountsPerUser=1 protect the game logic. None of those settings does anything against a saturated uplink.
• The physical limit is fixed: 1 Gbps is 125 megabytes per second, and with packets of 64 bytes around 1.49 million packets per second. Usual attacks against game servers range between 5 and 50 Gbps.
• Volumetric attacks have to end in the network in front of the server. At KernelHost that means 17 Tbps of mitigation capacity in the global scrubbing network plus Arbor real-time filtering with 3.2 Tbps in Frankfurt am Main, at no surcharge and without null-routing.
• Anyone under constant fire steers the filtering themselves with Advanced DDoS Protection: a dedicated protected IP, rules per port and protocol, changes in real time, from €50.00 per month.

If your 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.