Protecting an Arma 3 server from DDoS attacks

If you want to protect an Arma 3 server from DDoS attacks, you are dealing with exactly five UDP ports: 2302 through 2306. A dedicated server that drops out for every player at once in the middle of an operation rarely has a hardware problem. Usually an attack is running against exactly that port block, and it runs when the server list shows the highest player count. 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 in the network in front of the server.

Everything here refers to a dedicated Arma 3 server (SteamCMD application 233780) 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 anything in the configuration and do not restart the server, capture the measurements from the "Logging" section first. Once the attack is over they are gone.

Why Arma 3 servers get attacked and when DDoS protection becomes necessary

Arma 3 combines several traits that make a server a convenient target. First, the server publishes its own address: it registers with the Steam master server on port 2304 UDP and answers queries on port 2303 UDP with name, map, player count and mod list. Without those two ports nobody finds you, and with them your IP address sits in every server browser and on every status page that reads the server browser.

Second, the player base is tied to fixed hours. Life roleplay projects on Altis and Tanoa, Exile, Antistasi and King of the Hill fill up in the evenings and on weekends, so an outage at 8 pm is as visible as it gets. Third, there is competition between projects, there are banned players and internal conflicts, and an attack costs whoever orders it neither skill nor any serious amount of money.

On top of that comes the decisive technical detail: Arma 3 runs entirely over UDP, and the game itself needs no TCP for play. 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. Add to that the fact that the core simulation loop of an Arma 3 server runs on a single CPU core: whoever sends enough packets costs that one core processing time, no matter how many cores the machine has otherwise. For the details of what a DDoS attack actually is, read What is a DDoS attack?.

The ports that actually matter

An Arma 3 server occupies the block 2302 to 2306 UDP out of the box. The startup parameter -port=2302 only sets the first port, the other four follow from it as the game port plus 1 through plus 4. If you run several instances on the same machine, leave at least 100 ports between them (2302, 2402, 2502), otherwise the instances take each other's follow-up ports.

Of these eight rows, exactly three belong on the open internet: 2302, 2303 and 2304 UDP. Everything else is administration, and exposed administration ports are the most common avoidable mistake on Arma 3 servers.

What you can do yourself before spending money

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

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

Before you write a single 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:2302 means "reachable from the entire internet", 127.0.0.1:3306 means "local only" and needs no firewall rule. Next to the game, a Life server regularly also shows MariaDB, a web server for the faction site, a TeamSpeak or voice service and a forgotten panel. A port scan from outside gives you the attacker's view:

nmap -Pn -sU -p 2300-2320 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

The first command shows the UDP block of the game, the second one everything that is open on TCP. An Arma 3 server needs no open TCP port at all for gameplay.

2. Leave open only the ports Arma 3 really needs

Three UDP ports facing the outside are enough, everything else gets restricted. With UFW it looks like this, and in exactly this order so that you do not lock yourself out:

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH'
ufw allow 2302:2304/udp comment 'Arma 3 game, Steam query, Steam master'
ufw allow from 203.0.113.10 to any port 2306 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. Port 2305 stays closed because Bohemia documents it as reserved and currently unused. The line ufw default allow outgoing matters: BattlEye opens a connection from the server to arma31.battleye.com and needs outbound 2344 on TCP and UDP plus 2345 on TCP for it. Anyone who blocks outbound traffic wholesale blocks their own anti-cheat. After the change, verify with a real join that BattlEye still lets your players through. The full guide including the escape route is in Setting up the UFW firewall without locking yourself out.

The database has no business on the open internet under any circumstances. Altis Life and the other Life frameworks talk to a MySQL database through the extDB3 extension, and the credentials sit in plain text in @extDB3/extdb3-conf.ini. Check in /etc/mysql/mariadb.conf.d/50-server.cnf that it says:

bind-address = 127.0.0.1

3. Defuse the Steam query port without dropping out of the server browser

Port 2303 UDP is the most sensitive point of a public Arma 3 server. It answers A2S requests, the standard query of the Steam server browser: A2S_INFO returns name, map and player count, A2S_PLAYERS returns the player list, A2S_RULES returns the mod and signature list. A query is a small UDP packet, the answer is a multiple of it. US-CERT lists the Steam protocol in alert TA14-017A with a bandwidth amplification factor of 5.5, and with Arma 3 the answer is unusually large because the full mod list ships with it.

Two things follow from that. First, your server can be abused as an amplifier against third parties when an attacker sends queries with a spoofed source address. Second, and more important for you, every query costs processing time on the one core that carries the simulation. Bohemia has tracked this since 2015 in ticket T83469: spoofed UDP packets sent to the game port or the Steam query port pushed the CPU to 100 percent and froze the server, and 4 Mbps was already enough for a successful attack through the query port. That is why the packet rate is more dangerous than the bandwidth with Arma 3.

The first lever is the response size. The directive steamProtocolMaxDataSize in server.cfg defines how many bytes the server may put into its query response. Operators of large mod lists raise it to 2048 or more, because otherwise the warning "Query data overflow, Mods/Signatures will not be correctly received by clients" shows up in the log. Every increase enlarges exactly the response an attacker amplifies. So keep the value as low as your mod list still allows, and remove unused mods from the startup command:

steamProtocolMaxDataSize = 2048;

The second lever is a rate limit per source address that only hits the query port. Do not block 2303 UDP outright: without a query answer your server disappears from the server browser and from every status page and Discord bot, and new players stop finding it. A legitimate server browser queries a few times per minute, not hundreds of times per second.

4. Take BattlEye RCon off the open internet

BattlEye is the anti-cheat of Arma 3 and is enabled in server.cfg with BattlEye = 1;. Its remote control, BattlEye RCon, is a separate UDP protocol and is configured in BattlEye/beserver_x64.cfg (the file with the _x64 suffix applies to arma3server_x64, the server binary used today):

RConPassword YourAlphanumericPassword
RConPort 2306
RConIP 127.0.0.1
MaxPing 350
RestrictRCon 0

Three points are decisive. The RCon password has to be purely alphanumeric, because special characters break the BattlEye protocol parser silently, and an RCon access that fails silently is one you do not have when it counts. RConIP defines which address RCon listens on: with 127.0.0.1 the interface is reachable locally only, and your RCon tool reaches it through an SSH port forward. And RConPort has to sit above the game block, commonly the game port plus 4, so 2306. If you have to expose RCon, open the port only for the fixed address of your admin team.

One thing should be clear: BattlEye is an anti-cheat, not DDoS protection. It checks players who are connected. An attacker who floods your server does not want to join at all.

5. Bind the headless client tightly

A headless client is a second Arma 3 instance without graphics that connects to the server like a player and takes the AI calculation off its hands. On large missions this is the single biggest performance gain available, because otherwise the AI sits on the same core as the simulation. You enable it in server.cfg:

headlessClients[] = {"127.0.0.1"};
localClient[] = {"127.0.0.1"};

Without those entries the server allows no headless client connection at all, which is the good news. The bad news: localClient[] grants the listed address unlimited bandwidth and practically no latency checks. Put only 127.0.0.1 or the fixed address of your own headless client machine in there, never a whole address range. The client is started with -client -connect=127.0.0.1 -port=2302 -password=..., and it occupies a slot from maxPlayers. Account for that, or your players will find a full server.

6. Harden joining, signatures and voting

These settings do not protect your uplink, but they close everything that comes in through the regular join path: manipulated clients, in-game script execution and vote abuse. The following lines belong in the server.cfg of every public server:

verifySignatures = 2;
BattlEye = 1;
kickDuplicate = 1;
allowedFilePatching = 0;
maxPlayers = 64;
disconnectTimeout = 30;
maxPing = 200;
maxDesync = 150;
maxPacketLoss = 50;
kickClientsOnSlowNetwork[] = {1, 1, 1, 1};
voteThreshold = 1.5;
voteMissionPlayers = 100;
onUnsignedData = "kick (_this select 0)";
onHackedData = "kick (_this select 0)";

verifySignatures = 2 enforces signature verification version 2 for all addons and is the minimum requirement for any public server running mods. allowedFilePatching = 0 refuses the join to clients started with -filePatching (value 1 allows it for headless clients only, value 2 for everyone). kickDuplicate = 1 throws out the second connection using the same identifier. kickClientsOnSlowNetwork[] decides per entry whether the four thresholds from maxPing, maxPacketLoss, maxDesync and disconnectTimeout are only logged (0) or enforced (1). disconnectTimeout accepts values from 5 to 90 seconds. A voteThreshold above 1 makes votes unreachable and thereby ends the most popular way of disrupting a server without a single attack packet: the mission change by vote.

7. Limit packet and connection rates per source address

Against small attacks and sloppy bots, an upper limit per source address helps. Because Arma 3 is pure UDP you work with hashlimit, and the query port gets a far tighter limit than the game port:

iptables -I INPUT -p udp --dport 2303 -m hashlimit --hashlimit-name a3_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name a3_game --hashlimit-mode srcip --hashlimit-above 900/sec --hashlimit-burst 1200 -j DROP
iptables -I INPUT -p udp --dport 2302:2306 -m length --length 0:27 -j DROP

The first rule drops queries from the same source once they sustain more than ten per second, the second drops game packets once they sustain more than 900 per second, the third drops UDP packets with no usable payload. All three numbers are starting points, not truths: a full Life server with 80 players produces far more packets than a six-player Antistasi round, and setting the limits too tight throws out your own players. Measure a week of normal operation first.

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. Another bottleneck that is often overlooked is the connection tracking of the kernel: UDP creates entries there as well, and a query flood from many spoofed addresses fills the table within 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

8. basic.cfg: bandwidth, packet sizes and extra files

The second configuration file of an Arma 3 server is called basic.cfg and is loaded with -cfg=, while -config= loads server.cfg. It controls the network behavior and contains exactly one value that is directly security relevant:

MaxMsgSend = 1024;
MaxSizeGuaranteed = 512;
MaxSizeNonguaranteed = 256;
MinBandwidth = 15000000;
MaxBandwidth = 100000000;
MinErrorToSend = 0.001;
MinErrorToSendNear = 0.01;
MaxCustomFileSize = 0;
class sockets { maxPacketSize = 1400; };

MaxCustomFileSize is the maximum size in bytes for custom face and sound files that players bring along and that the server distributes to everyone else. The value 0 switches that distribution off. This removes one route on which a single client occupies your server's bandwidth without any attack infrastructure at all. MinBandwidth is the bandwidth the server assumes as guaranteed, and the rule of thumb is the player count times 256 kbps, so roughly 16 Mbps for 64 slots. Values that are too optimistic increase load and desync, because the server produces messages it then discards. MaxMsgSend caps the packets per simulation cycle and is the first lever against desync, with the default of 128 being set too low for modern servers.

9. Logging, so that you do not have to guess 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. With apt-get install -y vnstat sysstat the measurement runs permanently in the background, and logFile = "arma3server.log"; in server.cfg gives you the server's own view alongside it. 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 portrange 2302-2306 -c 200 -q

What tells you the most is the comparison between the ports. If the load sits almost entirely on 2303, it is a query flood, and that one hits processing time. If it spreads evenly across 2302 to 2306 with ever-changing source addresses, it is a spoofed UDP flood, and that one hits the uplink. 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. How to install and update the server cleanly in the first place is covered in Installing a game server with SteamCMD.

Where these measures stop

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 with Arma 3 it almost always hits first. 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, and the Arma 3 simulation additionally hangs on a single core.

The row with the 4 Mbps is the uncomfortable one. An attack on Arma 3 does not have to be big to work: it only has to send enough packets to the right port. Operators experience this as "the utilization was not even high, and yet everything was gone". For volumetric attacks the plain physics applies the other way round: at 473.4 Gbps every local setting is meaningless, because the packets of your players stop getting through before 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. 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. A Life server with a fixed player base and a competing scene is the rule here, not the exception. For those there is Advanced DDoS Protection from EUR 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 2302 UDP and what is allowed on 2303 UDP, which lets you run the query port far tighter than the game port.
• 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 matched to the game, and profiles for modified and custom applications on any TCP or UDP port.

The two tiers compared

For most Arma 3 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.

Common mistakes and how to fix them

"I moved the port from 2302 to 2402 and the attack kept running": that is to be expected. The server registers its new port with the Steam master server itself, and the server list republishes it immediately. Changing the port only helps against somebody using an old address from an old screenshot.

"I blocked 2303 completely and now nobody finds us": that is exactly what happens. Without an answer on the Steam query port the server list entry is missing, and every status page and every Discord bot shows the server as offline. The correct move is a rate limit per source address, not a block.

"The log says NetServer::SendMsg: cannot find channel": this message appears when the server wants to write to a connection that no longer exists. As a rule it accompanies dropping player connections and performance drops (Bohemia tracks it under T83936), not necessarily an attack. Check first whether the packet rate of the interface is unusual at all.

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

"BattlEye kicks every player since the new firewall": the server no longer reaches arma31.battleye.com. The outbound ports 2344 on TCP and UDP plus 2345 on TCP have to stay open, otherwise the anti-cheat connection of the server breaks away.

"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

• An Arma 3 server needs exactly three UDP ports facing the outside: 2302 for game and voice, 2303 for the Steam query and 2304 for the registration with the Steam master server. The game needs no TCP.
• Port 2306 UDP carries BattlEye and the RCon interface and belongs exclusively on your own admin addresses, set through RConPort and RConIP in beserver_x64.cfg.
• The Steam query port 2303 is the most sensitive point: the Steam protocol has an amplification factor of 5.5 according to US-CERT TA14-017A, and every query costs processing time on the core that carries the simulation. Rate limit it, do not block it.
• Keep steamProtocolMaxDataSize as small as your mod list allows and set MaxCustomFileSize = 0; in basic.cfg: both shrink the amount of data your server hands out unasked.
• With Arma 3 the packet rate decides, not the bandwidth. Bohemia has documented since 2015 under T83469 that 4 Mbps against the query port was already enough to freeze a server.
• Local measures end at the uplink. From 1 Gbps of attack volume or a few hundred thousand packets per second onwards, only the filtering in the network in front of the server decides the outcome.
• At KernelHost the two-layer always-on protection is included in every server package at no surcharge and active from provisioning onwards, with no null-routing. Advanced DDoS Protection adds a dedicated protected IP and self-managed rules per port from EUR 50.00 per month.

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.