Protecting a DayZ server from DDoS attacks

A DayZ server that throws every player out mid-session and then vanishes from the server browser for minutes rarely has a hardware problem. Usually an attack is running, and it runs exactly when the most players are online or when the scheduled restart is due. Anyone who wants to protect a DayZ server from DDoS attacks therefore needs both: a clean set of port rules on the server and filtering in the network in front of it. This article starts with what you can secure yourself at no extra cost, then shows where those measures technically end, and finally explains what has to happen upstream.

Everything here refers to a self-hosted DayZ dedicated server with a serverDZ.cfg, whether it runs on Windows Server or on Debian and Ubuntu through a compatibility layer. Bohemia Interactive does not ship a production-grade native Linux server binary for the stable branch, and the experimental Linux build accepts experimental clients only. The Linux 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 serverDZ.cfg and do not restart the server. A DayZ restart reloads the mods and the central economy and costs you several minutes in which the server is guaranteed to be offline. Capture the measurements first (see the section "Logging"), because once the attack is over they are gone.

Why DayZ servers are such frequent DDoS targets

DayZ combines several traits that make a server a convenient target. First, a community server publishes its address all by itself: to show up in the in-game server browser and in the DZSA Launcher it has to answer Steam queries, and that answer contains the IP address and the port in plain text. An attacker does not have to find out anything, he only has to read a list.

Second, the daily routine of a DayZ server is public. Practically every project restarts automatically every three to four hours, announces it in chat and writes the schedule into its Discord. An attack that lands in that window works twice over: the server is unreachable anyway, and the players stuck in the waiting screen go somewhere else.

Third, the stakes for the players are high. An outage at the wrong minute in DayZ means more than frustration, it means lost gear, aborted raids and a base standing unguarded in the world. That is exactly why banned players, rival groups and competing projects are the most common instigators. An attack through one of the usual booter services costs whoever orders it neither skill nor any serious amount of money.

Fourth, all DayZ traffic runs over UDP. UDP has no connection setup you could insist on, and source addresses can be spoofed. So an attacker does not have to join your server, or even address it correctly, in order to create load. That even the developer is exposed to this was shown in February 2025: Bohemia Interactive's online services for DayZ and Arma Reforger were under DDoS fire for over a week, acknowledged on 3 February 2025 and still unresolved on 6 February 2025, and community servers were affected as well. For the details of what a DDoS attack actually is, read What is a DDoS attack?.

DayZ server ports: the fact table

A DayZ server speaks UDP only. There is no TCP game port. The single value that is genuinely fixed in DayZ is 2302/UDP as the game port; everything else is configurable and differs from host to host. So look at your own start line and your own serverDZ.cfg instead of relying on a default value.

Two values cause confusion again and again, so here is the resolution. The Steam query port: the sample configuration shipped by Bohemia sets steamQueryPort = 2305;, while a large share of hosts use 27016/UDP. Both values are valid, and the only one that counts is the one in your file. The BattlEye RCon port: there is no binding standard at all. The widespread rule of thumb is game port plus three, so 2305, while other hosts use 2310. Since DayZ 1.13, BattlEye reads the RConPort parameter in BEServer_x64.cfg reliably; before that the port was hard to predict.

That leads to a trap many operators walk into: never set steamQueryPort and RConPort to the same value. If your configuration uses 2305 for the Steam query, RCon belongs on a different port, 2310 for example.

Why the Steam query port is the most sensitive port

The Steam query port answers three queries: A2S_INFO, A2S_PLAYERS and A2S_RULES. A2S_INFO returns the server name, map, player count and version, A2S_PLAYERS the names of the connected players, A2S_RULES the server variables that are set. Every one of those answers is considerably larger than the request that triggered it, and that is what makes the port dangerous in two directions at once.

For you as the target it means an attacker can keep your query port busy with a few bytes per request while your server assembles and sends a full reply every time. For third parties it means an attacker can query your server with a spoofed source address and steer the answers at his actual target. Your server is then not only a victim but an amplifier. Valve added a challenge step to A2S_INFO in December 2020 for exactly this reason: the server first replies with a random number that the requester has to echo back. That defuses the amplification, but it does not end it, because by no means every query takes that route.

DayZ has a peculiarity here that other games do not: two separate server lists query you, the built-in community server browser and the widely used DZSA Launcher. Simply closing the query port is therefore not an option, because your project then disappears from both lists even though direct connect still works. Rate-limiting instead of closing is the right answer.

What you can do yourself before spending money

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

1. Take stock: which ports your DayZ server actually opens

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

ss -lnup
ss -lntup

On Windows Server the command prompt gives you the same picture:

netstat -ano -p UDP | findstr "2302 2303 2304 2305 27016"

The interesting column is the local address. 0.0.0.0:2302 means "reachable from the entire internet", 127.0.0.1:2310 means "local only" and needs no rule. After that, read the actual values straight out of your configuration files instead of trusting a tutorial:

grep -iE "steamQueryPort|maxPlayers|password|enableWhitelist|verifySignatures" serverDZ.cfg
grep -iE "RConPort|RestrictRCon" battleye/BEServer_x64.cfg

A UDP port scan from the outside, run from a different machine, gives you the attacker's view:

nmap -Pn -sU -p 2302-2310,27015-27020 YOUR.SERVER.IP.ADDRESS

2. Open only what the start line and serverDZ.cfg really need

Two rules facing the outside are enough for DayZ: the game port block and the query port. Everything else is restricted to your own address or never published at all. 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 2302:2305/udp comment 'DayZ game port'
ufw allow 27016/udp comment 'DayZ Steam query'
ufw allow from 203.0.113.10 to any port 2310 proto udp comment 'BattlEye RCon'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Replace 203.0.113.10 with your own address and 27016 with the value that actually appears in your steamQueryPort line. The full guide including the escape route is in Setting up the UFW firewall without locking yourself out. The same principle applies on a Windows server: one inbound rule per port group, Remote Desktop restricted to your own address, everything else blocked.

3. Rate-limit the Steam query port instead of closing it

An upper limit per source address separates real server lists from query floods. A server browser queries you once every few seconds, an attacker every few milliseconds:

iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name dayz_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name dayz_game --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

The first rule drops Steam queries once a source sustains more than ten per second, the second one drops game packets above 600 per second. Both numbers are starting points, not truths. A full server with 60 players produces far more packets than an empty one, and setting the limits too tight throws out your own players or drops you off the server list. Measure a week of normal operation first.

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. On top of that, the Steam game server library has a brake of its own for connectionless packets: the environment variable STEAM_GAMESERVER_RATE_LIMIT_200MS drops all A2S packets from an address once more than the configured number arrive within a 200 millisecond window.

The third measure costs nothing at all: if your Discord bot or your project website shows the player count, do not query the server from the visitor's browser, but cache the result at fixed intervals instead. That way a busy status page produces one query per interval instead of one per visitor.

4. Take BattlEye RCon off the open internet

BattlEye is the anti-cheat component of DayZ and is switched on in serverDZ.cfg with BattlEye = 1;. Remote administration, by contrast, lives in a file of its own: BEServer_x64.cfg in the BattlEye directory next to BEServer_x64.dll, which the start line points at with -BEpath=:

RConPassword ALongRandomPassword
RConPort 2310
RestrictRCon 0

Three rules go with it. First: the RCon port is UDP, not TCP. A firewall rule that accidentally says proto tcp filters nothing and leaves your admin tools running into a wall at the same time. Second: restrict the port to the addresses of your administrators. If you have no static address, keep the port closed to the outside entirely and run the admin tool on the server itself, reached over SSH or Remote Desktop. Third: RestrictRCon 1 limits which commands can be issued over RCon and is the right setting as soon as more than one person has access.

An open RCon port is two things at once: an invitation to try passwords and one more UDP port that can be flooded. Both go away as soon as the rule only applies to a handful of addresses.

5. Login queue, whitelist and slot exhaustion

DayZ does not process connections all at once, it uses a queue. Five values in serverDZ.cfg control it:

maxPlayers = 60;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 100;
guaranteedSlots = 10;
maxPing = 200;

loginQueueConcurrentPlayers defines how many players are let in simultaneously (default 5), loginQueueMaxPlayers caps the queue itself (common values between 100 and 500). Slot exhaustion attacks exactly this: an attacker needs no bandwidth at all, only enough accounts or connection attempts to occupy the queue. Real players then no longer get through even though the server is running perfectly. guaranteedSlots reserves places for your team so that you can still get onto the server in exactly that situation.

The built-in whitelist is the countermeasure. It is enabled with enableWhitelist = 1; and then reads the file profiles/whitelist.txt, one Steam64 ID per line. Any ID not listed is refused at connection time. The file is read at server start, so changes need a restart. An additional password in serverDZ.cfg works similarly but is weaker, because a password gets passed around and a Steam64 ID does not.

One thing has to be clear: a whitelist protects your player slots, 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.

6. Mods, signature verification and the window after a restart

In DayZ, mods are not only a comfort topic, they are part of the attack surface. Four settings in serverDZ.cfg should be in place in any case:

verifySignatures = 2;
forceSameBuild = 1;
allowFilePatching = 0;
BattlEye = 1;

verifySignatures = 2 checks every PBO file against its matching .bisign signature and needs the corresponding .bikey files in the keys folder. forceSameBuild = 1 requires exactly the same game version as the server runs. allowFilePatching = 0 rejects clients that start with modified game files. None of these settings stops a volumetric attack, but all three close the path on which a manipulated client knocks your server off balance.

The second point is the more important one and is almost always overlooked: the startup phase. On start, a DayZ server first loads the mod list from the start line and after that the central economy with all its loot tables. On a heavily modded server that easily takes several minutes, during which the server answers not a single Steam query:

./DayZServer -config=serverDZ.cfg -port=2302 -profiles=./profiles -BEpath=./battleye -mod=@CF;@YourMod;@AnotherMod -cpuCount=4 -dologs -adminlog -netlog -freezecheck

Because practically every project restarts every three to four hours and announces that schedule on top, the window is trivial for an attacker to hit. Three countermeasures are effective and cost nothing. Keep the mod list as short as possible, since every extra mod stretches exactly that window. Put the restart times on odd values instead of the full hour. And measure once how long your startup really takes instead of estimating: with timeStampFormat = "Full"; and a logFile set, the duration is right there in the log afterwards.

7. Connection tracking, receive buffers and kernel parameters

One bottleneck that is often overlooked is the connection tracking of the kernel. UDP has no connections, but the kernel still creates an entry for every pair of source and destination address. Once the table fills up, 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

For a pure game server the clean solution is not to track the game traffic in the first place, and to enlarge the receive buffers and the queue of the network card as well:

iptables -t raw -A PREROUTING -p udp --dport 2302 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 2302 -j NOTRACK
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=1048576
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.netfilter.nf_conntrack_max=524288

One warning: NOTRACK and stateful rules are mutually exclusive. If you exempt the game port from tracking, you must not use any rule with -m conntrack --ctstate for that port any more, otherwise the allow rule stops working. To make the sysctl values permanent, put them in /etc/sysctl.d/, otherwise they are gone after the next reboot.

8. Your IP address is in the server browser

Honesty beats wishful thinking here: the IP address of a public DayZ server cannot be kept secret. Every player who has connected once knows it, the server browser publishes it, and the DZSA Launcher caches it. Changing the address buys you hours, rarely days.

Two habits are more effective. Never publish the raw IP address anywhere on top of that, so neither in the pinned Discord post nor on the project website. And clean up your DNS records: a forgotten A record pointing at the previous address makes any change pointless, and that is exactly where most address changes fail. Anyone still running a status service on the old server gives away the new address along with it.

9. Logging, so you are not guessing during an attack

The most important step is the one almost nobody takes beforehand: build a baseline while everything is still normal. Without a normal value you cannot say after an incident whether 40,000 packets per second was a lot or simply a Saturday evening. On the server side, switch on the built-in logs for that:

timeStampFormat = "Short";
logAverageFps = 300;
logPlayers = 300;
logFile = "server_console.log";

logAverageFps is the most honest value DayZ gives you. If the server frame rate collapses while the player count stays the same, it is a mod or economy problem. If the frame rate stays stable while players get dropped, it is the network. On the system side, apt-get install -y vnstat sysstat keeps the measurement running permanently, and 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 2302 -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. How to read the numbers is covered in Detecting a DDoS attack on your server.

Where self-protection stops: 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.

With DayZ the packet rate often hits earlier than the bandwidth does, and the reason is simple: the game traffic consists of many small UDP packets, not a few large ones. So an attack that does not even fill a third of your uplink can still take your server down, because the processing time goes into the dropping. Operators experience this as "the utilization was not even high, and yet everybody had lag spikes and got dropped one after another".

Volumetric attacks have to end in the network in front of the server. That is not a product claim, it is physics.

DayZ DDoS protection: what KernelHost puts up against it

The always-on protection that runs on 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 and with no minimum term. 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 2302/UDP, what is allowed on the query port and what is allowed on the RCon port. That separation is the real lever in DayZ, because game traffic and query traffic look nothing alike.
• Changes take effect in real time, so you can fine-tune while an attack is running instead of waiting on a ticket.
• A protection profile matched to the game, including heavily modded servers and custom applications on any TCP or UDP port.

The two tiers compared

For most DayZ projects the included always-on protection together with a clean server configuration is enough. Advanced DDoS Protection is the answer to somebody taking it personally. If you currently run your DayZ server elsewhere, the protection cannot be retrofitted: it is part of the network and applies to servers hosted at KernelHost. The route to it is a migration, not an add-on product.

Common mistakes and how to fix them

"My server has disappeared from the DZSA Launcher and the server browser, but direct connect still works": in most cases this is not an attack, it is the query port. Either steamQueryPort holds a different value than your firewall does, or a rate limit that is set too tight is dropping the queries of the server list. Check both values against each other before you assume an attack.

"RCon stopped connecting after I started filtering the ports": BattlEye RCon runs over UDP. An allow rule with proto tcp on the same port does nothing. Also check whether RConPort and steamQueryPort accidentally hold the same value.

"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 server browser, a Discord status bot or an old DNS record. Changing the address buys time, it is not a solution.

"The attack comes every day exactly at the restart": that is no coincidence. The restart schedule is in your Discord and is announced in game, and while mods and the economy load, the server does not answer anyway. A shorter mod list, restart times on odd values and filtering that runs permanently instead of reacting to an attack take the effect out of that pattern.

"Every player has lag spikes, but the network is quiet": then it was not a DDoS attack. First check logAverageFps for a collapse of the server frame rate, then look at the central economy and the mod list. If sar -n DEV 1 10 stays unremarkable, the network is not the cause.

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

"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 DayZ server needs exactly two things facing the outside: the game port block starting at 2302/UDP and the Steam query port from your steamQueryPort line. Everything else should be restricted or closed.
• The BattlEye RCon port has no binding default, runs over UDP and is set with RConPort in BEServer_x64.cfg. It never belongs on the open internet and never on the same value as the query port.
• Rate-limit the query port instead of closing it: closing it makes you disappear from the server browser and the DZSA Launcher even though direct connect still works.
• The whitelist, guaranteedSlots and the login queue protect your player slots against slot exhaustion, but not your uplink against bandwidth.
• The most dangerous window of a DayZ server is the scheduled restart every three to four hours, because mods and the central economy load for minutes and the timing is public knowledge.
• From roughly 1 Gbps of attack volume or a few hundred thousand packets per second onwards, only the network in front of the server decides the outcome, not your firewall.
• At KernelHost the two-layer always-on protection is included with every server package, at no surcharge and with no null-routing. Advanced DDoS Protection from €50.00 per month comes on top when you want to steer the per-port rules yourself.

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