Protecting a Call of Duty server from DDoS attacks

Protecting a Call of Duty server from DDoS attacks is a refreshingly concrete task on the classic titles: it comes down to exactly one UDP port, a handful of dvars in server.cfg, and one amplification vector the engine has carried since 2003. A server that loses every player at once in the middle of a round rarely has a hardware problem. Usually an attack is running, and it runs exactly when the server is full.

This article starts with which titles it applies to at all, then covers what you can secure yourself at no extra cost, then where those measures technically end, and finally what has to happen in the network in front of the server. The commands are written for Debian 12, Debian 13, Ubuntu 22.04 LTS and Ubuntu 24.04 LTS and assume root. As a normal user, put sudo in front of them.

If the attack is running right now: do not change anything in server.cfg and do not restart the server. Capture the measurements first (see the section "Logging"), because once the attack is over they are gone.

Which Call of Duty titles let you protect a server from DDoS

You can protect a Call of Duty server from DDoS only on the titles that allow your own dedicated servers. Those are the original releases of Call of Duty (2003), Call of Duty United Offensive, Call of Duty 2, Call of Duty 4 Modern Warfare and Call of Duty World at War, plus the community platforms Plutonium (World at War, Black Ops, Black Ops II, Modern Warfare 3), IW4x (Modern Warfare 2) and CoD4X (Call of Duty 4). All of them follow the same pattern: a server.cfg, one open UDP port, and an entry in a public server list.

This article explicitly does not apply to the modern titles. Warzone, Modern Warfare (2019), Black Ops Cold War, Vanguard, Modern Warfare II, Modern Warfare III and Black Ops 6 have no rentable dedicated servers: matches run on Activision's matchmaking infrastructure, there is no server.cfg, no server browser and no port you could open or secure. The port lists Activision publishes for those titles (among others TCP 3074 and 27014 to 27050, plus UDP 3074, 3478 and 27000 to 27031) describe client and platform ports, not server ports. If you get disconnects in Warzone, the problem sits on your own line or at Activision, and renting a server would not fix it.

Why Call of Duty servers in particular get attacked

Call of Duty servers combine four traits that make them a convenient target. First, every listed server publishes its own address: the server list entry contains the IP address and the port in plain text, because otherwise nobody could join. Second, all traffic runs over UDP, and UDP has no connection setup you could insist on, while source addresses can be spoofed. Third, the engine answers status queries from anyone, without that person having to start the game. Fourth, the RCON remote control sits on the very same port as the game.

On top of that comes the social part: banned players, competition between clans, arguments inside a community that has known each other for years. An attack costs whoever orders it neither skill nor any serious amount of money, so-called booters and stressers are sold as a subscription for a few euros a month, and amplification through game servers is part of their standard catalog. For the details of what a DDoS attack actually is, read What is a DDoS attack?.

The ports that actually matter

A classic Call of Duty server occupies exactly one UDP port, and that port is 28960. Three things run on that single port at the same time: the game traffic, the status queries from the server list, and the RCON remote control. There is no separate query port and no separate RCON port. The startup line of a dedicated server looks the same across all titles, only the name of the executable differs:

+set dedicated 2 +set net_ip 0.0.0.0 +set net_port 28960 +set sv_maxclients 32 +exec server.cfg +map_rotate

The master server ports do not belong in your firewall rules. 20810 and 20800 are destination ports on the other side, not listening ports on your machine: your server contacts the list on its own. Many port forwarding guides still recommend opening them inbound. That enlarges the attack surface for no benefit at all.

The numbers you should know for Call of Duty

The second table is the more important one if you want to judge whether you can still handle this yourself. It puts the normal load of a full server next to the figures an attack works with.

Why game, query and RCON share one port

This is the decisive peculiarity of Call of Duty. The id Tech 3 engine that all classic Call of Duty titles build on has no separate ports for game, query and remote control. Everything runs as so-called connectionless packets on that one UDP port. A connectionless packet is a UDP packet that starts with four 0xFF bytes and then carries the command name in plain text: getstatus, getinfo, getchallenge, connect or rcon.

The practical consequence is inconvenient: you cannot separate RCON from the game with a firewall without locking out the game as well. A rule on port 28960 always hits everything. Anyone who wants to sort out query floods and RCON attacks specifically has to look into the packet payload, not just at the port number. That is exactly why port-based firewall rules reach their limit earlier on Call of Duty than on games with a separate query port.

What is getstatus reflection on Call of Duty?

Getstatus reflection is an amplification attack in which an attacker sends small status queries with a spoofed source address to many game servers, so that their much larger responses land on the actual victim. The game servers are not the target, they are the amplifier. This vector has been documented for the id Tech 3 engine for more than a decade and affects Call of Duty just as much as Quake 3 and its other descendants.

It hits you from two directions. As the target, you get a flood of getstatus requests that eats processing time and outbound bandwidth, and your players notice it as lag spikes. As an unwilling amplifier, you send responses to somebody else's victim, and the abuse complaint lands on your desk. Both happen on the same port, with the same packets, and both look harmless in a utilization graph at first.

What a getstatus packet looks like

The request consists of four 0xFF bytes and the word getstatus, which is 13 bytes of payload. With the IP and UDP headers that is 41 bytes on the wire. That is exactly what the length match in the firewall rules targets, the ones that have been passed around in Call of Duty forums for years:

iptables -A INPUT -p udp -m length --length 41:45 -m recent --set --name getstatus_cod
iptables -A INPUT -p udp -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

The response is far larger. A statusResponse contains the entire server configuration as one string plus a line per connected player, which is several kilobytes on a full server. CISA lists the Quake network protocol in its overview of UDP-based amplification attacks (TA14-017A) with an amplification factor of 63.9 and names the abused command explicitly as server info exchange. That turns 1 Mbps of spoofed requests into roughly 64 Mbps at the victim. For comparison: DNS sits at 28 to 54 in the same table, NTP at 556.9.

The built-in brake: sv_queryIgnoreTime and sv_queryIgnoreMegs

Call of Duty 4 has had a built-in query brake since server version 1.7. It remembers every address that sent a status query and ignores further queries from that address for a configurable time. Four dvars control it, with these defaults:

sv_queryIgnoreMegs        1
sv_queryIgnoreTime        2000
sv_queryBounceIgnoreTime  12000
sv_queryIgnoreDebug       0

sv_queryIgnoreMegs determines how much memory the ignore list may occupy. One megabyte holds around 65,000 addresses, each additional megabyte roughly 87,000 more. The value 0 turns the brake off completely, and that is the state on many servers, because the configuration came from an old template. sv_queryIgnoreTime is the block time in milliseconds. sv_queryBounceIgnoreTime applies when a response comes back with an ICMP Port Unreachable notice, which is exactly the case when your server is being abused as an amplifier against somebody else. sv_queryIgnoreDebug 1 writes the hits to the log so that you can see whether anything happens at all.

If you run CoD4X, you additionally get hard limits in the server code: at most 20 getstatus responses per 20 seconds, at most 100 getinfo responses per 100 seconds, and at most one RCON error reply per 100 milliseconds. The comment in the source states the intent plainly: the server may well be flooded, but it must not waste outbound bandwidth while it happens. That is the right priority, but it does not replace filtering in front of the server.

Why RCON has always been a problem on Call of Duty

RCON is the remote control of the server, and on Call of Duty it is an unencrypted UDP packet on the game port. An RCON command looks like this on the wire: four 0xFF bytes, then the word rcon, then the password in plain text, then the actual command. There is no encryption, no session, no user account and no second factor. Three problems follow from that, and all three are real:

• Reading along. Anyone who sees the traffic at any point on the path reads your RCON password in plain text. That applies to every network between you and the server, and to every tool you hand the password to.
• Guessing. There is no login that could be locked and no account lockout after ten failed attempts. An attacker tries passwords at any speed. The stock server does not slow this down at all, CoD4X only limits the reply to one error message per 100 milliseconds and logs the attempt as "Bad rcon".
• Reflection. An RCON error message is also a response to a spoofed packet. Anyone who hits your server with spoofed RCON packets is using it as a small amplifier, and your server fills up its own log along the way.

The practical consequence: set rcon_password only if you genuinely need RCON. If you do, make it long and random. CoD4X requires at least eight characters, which is a floor and not a recommendation. Do your day-to-day administration over SSH and the server console instead of over RCON from the open internet. And if you run a management tool such as IW4MAdmin, which talks RCON itself, its web interface on port 1624 has no business on the open internet.

What you can do yourself before spending money

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

1. Take stock: what is listening at all?

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:28960 and [::]:28960 mean "reachable from the entire internet", 127.0.0.1:3306 means "local only" and needs no firewall rule. Next to the game you will often find IW4MAdmin, a web server for fast download, a database for statistics and a forgotten second game instance. A port scan from outside gives you the attacker's view:

nmap -Pn -sU -p 28960-28970,4976,27016 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. Leave open only what the game really needs

A single Call of Duty server needs exactly one rule facing the outside, 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 28960/udp comment 'Call of Duty'
ufw allow from 203.0.113.10 to any port 1624 proto tcp comment 'IW4MAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Replace 203.0.113.10 with your own address. On Plutonium T6, 4976/udp takes the place of 28960/udp, on Plutonium IW5 it is 27016/udp. If you run several instances, open only the range you actually use, for example 28960:28962/udp instead of blanket 28960 to 28970. A port with nothing listening on it is not an entry point, but under attack it still costs the kernel work. The full guide including the escape route is in Setting up the UFW firewall without locking yourself out.

3. Turn on the query brake in server.cfg

These four lines belong in every server.cfg of a Call of Duty 4 server and cost nothing but a few megabytes of memory:

set sv_queryIgnoreMegs "4"
set sv_queryIgnoreTime "2000"
set sv_queryBounceIgnoreTime "12000"
set sv_queryIgnoreDebug "0"

Four megabytes hold around 326,000 addresses, which is enough even for a serious flood. Raise sv_queryIgnoreTime above the default of 2000 milliseconds only carefully: the server list and every server browser query your server through the same mechanism, so setting the block time too high makes you disappear from the list. Set sv_queryIgnoreDebug to 1 temporarily if you want to know whether the brake engages at all, then back to 0 so the log does not fill your disk.

4. Sort out query floods in the firewall

The brake inside the engine only acts after the packet has reached the game process. A firewall rule decides earlier and costs less. These two lines limit getstatus per source address:

iptables -A INPUT -p udp --dport 28960 -m length --length 41:45 -m recent --set --name cod_query --rsource
iptables -A INPUT -p udp --dport 28960 -m string --algo bm --string "getstatus" -m recent --update --seconds 2 --hitcount 4 --name cod_query --rsource -j DROP

The first line remembers every source address that sends a packet in the typical length of a status query. The second drops every further getstatus request once the same address has sent more than four of them within two seconds. Four requests per two seconds are plenty for any server browser. Forums also circulate variants with 20 requests per second, which are far more generous and work better against crude bots than against a clean reflection wave.

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. Afterwards use iptables -L INPUT -n -v to check whether the hit counters are rising. If they stay at zero, the rule is never reached.

5. Switch RCON off or keep it on a short leash

The safest RCON access is the one that does not exist. An empty rcon_password rejects every RCON packet:

set rcon_password ""

Note one subtlety: the server still answers, namely with an error message, and therefore remains a small amplifier. If you want to rule that out and only need RCON from one fixed address, drop the packets before they get there:

iptables -A INPUT -p udp --dport 28960 ! -s 203.0.113.10 -m string --algo bm --string "rcon " -j DROP

This rule has a side effect you should know about: the string rcon can in theory also appear in a chat packet from a connected player, and that packet would be dropped as well. In practice that is tolerable. If you do not want the side effect, leave the rule out and work with an empty or very long password instead.

6. Defend against join floods and slot exhaustion

A join flood does not aim at the uplink, it aims at the game logic: the attacker sends getchallenge and connect packets in rapid succession until every slot is occupied by a half-finished connection. Real players then get "Server is full" while nobody is actually in the game. These settings work against it:

set sv_maxclients "32"
set sv_reconnectLimit "3"
set sv_floodProtect "1"
set sv_connectTimeout "30"
set sv_timeout "120"

sv_reconnectLimit limits how often the same player may reconnect in a row. sv_floodProtect limits how many client commands the server processes per player and stops a single client from bogging the server down with commands. sv_connectTimeout and sv_timeout determine how long a half-finished or a silent connection blocks a slot: leaving generous values from an old template in place makes slot exhaustion easy for the attacker.

On CoD4X you also get sv_authorizemode. The value 1 only lets players with a legitimate copy in, 0 only players without one, and -1 both. Setting it to 1 locks out a large share of throwaway clients, but it also loses you genuine players without an original copy. The hardest measure is a server password through g_password, which works against everything that uses the regular join path. And one thing has to be clear: a password 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 server list entry and your own address

Honesty beats wishful thinking here: your IP address cannot be kept secret. Every player who has connected once knows it, and the list entry publishes it anyway, port included. You can switch the entry off by not setting a master server in server.cfg (the dvars are called sv_master1, sv_master2 and so on). That costs you all visibility for new players, though, and it only helps against the laziest kind of attacker.

One note on the state of the lists: the original Activision master servers (codmaster.activision.com on 20510, cod2master.activision.com on 20710, cod4master.activision.com on 20810) no longer answer for the old titles. Anyone who wants to be listed today uses the community lists: CoD4X runs its own and requires a token in sv_authtoken, Plutonium brings its own server list. That changes nothing about the underlying issue, because your address sits there in plain text just the same.

Two habits are still worth having. Never publish the raw IP address yourself, so neither in the Discord channel nor on the clan website. And connect your players through a hostname so that you can change the address if it comes to that without breaking every reference. The classic pitfall is a forgotten A record pointing at the old address: it makes any change pointless.

8. Take web interfaces, the database and fast download off the open internet

Next to the game, most Call of Duty servers run more than that: IW4MAdmin with its web interface on port 1624, a web server for the fast download of maps, sometimes a database for statistics. Each of these services is an attack surface of its own, and none of them belongs on the open internet without limits.

Restrict 1624 to your own address, or reach the interface through an SSH forward and then open http://127.0.0.1:1624 locally:

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

Bind the database to 127.0.0.1, it has no business on the open internet under any circumstances. And put the fast download on a separate web server instead of into the game process: a web server under load otherwise takes exactly the processing time the game needs for its simulation.

9. Logging, so that you have data when it counts

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 Friday 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 28960 -c 200 -q

For Call of Duty there is a fifth one that answers the decisive question. This capture shows only the connectionless packets, which means exactly getstatus, getinfo, getchallenge, connect and rcon:

tcpdump -ni eth0 'udp port 28960 and udp[8:4] = 0xffffffff' -c 200 -A

If getstatus shows up hundreds of times from ever-changing addresses, you have a query flood. If rcon shows up, somebody is guessing your password. If you see only getchallenge and connect, it is a join flood. 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.

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 full 32-slot server produces around 6.4 Mbps outbound, which is less than one percent of a gigabit uplink. The same uplink is full as soon as somebody sends 125 megabytes per second, and that is exactly what the attacks you can order for ten euros a month are built for. 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 on Call of Duty it regularly 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. A getstatus request is smaller still at 41 bytes: an attack that does not even fill a third of your uplink still takes your server down, because all the processing time goes into the dropping. Operators experience this as "the utilization was not even high, and yet everything was gone".

Call of Duty adds a peculiarity that makes the math worse. Because game, query and RCON share one port, you cannot close 28960 as a last resort: that would be the same as switching the server off. And because the engine answers every status query with a multiple of the request size, an attacker needs less bandwidth of his own for the same effect than he would on other games.

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. 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 clans and communities 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 what is allowed on 28960 UDP without writing a ticket for it, and you define it separately per port if you run several instances.
• Changes take effect in real time, so you can fine-tune while an attack is still running.
• A protection profile that matches the game, including modified and custom applications on any TCP or UDP port. That is the relevant point for Plutonium and CoD4X, whose ports can differ from the defaults.

Advanced DDoS Protection is meant for servers hosted at KernelHost. If your Call of Duty server currently runs elsewhere and keeps getting taken off the network there, moving it to KernelHost is the step that changes something.

The two tiers compared

For most Call of Duty servers the included always-on protection together with a clean server.cfg is enough. Advanced DDoS Protection is the answer to somebody taking it personally.

Common mistakes and how to fix them

"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. Changing the address buys time, it is not a solution.

"My provider sends me an abuse notice although I am the victim": then your server is not the target, it is the amplifier. Somebody sends spoofed getstatus requests and your server dutifully answers somebody else's victim. Check first whether sv_queryIgnoreMegs is at 0, then set the four query dvars and add the firewall rule from section 4.

"The server shows as full in the list but it is empty": that is a join flood, and it hits the game logic, not the uplink. sv_reconnectLimit, shorter values for sv_connectTimeout and sv_timeout and, if in doubt, a server password work against it.

"The server disappears from the server list during the attack": that is the consequence, not the cause. The server list checks whether your server is alive through the very same status queries. If the answers do not get through, or if your own brake dropped them, the server counts as offline. Check whether sv_queryIgnoreTime is set too high before you suspect the firewall.

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

"The server is running, but every player has lag spikes": look at the packet rate of the interface first, not at the CPU load. If sar -n DEV 1 10 stays unremarkable and it still stutters, the cause is usually a mod, an excessive sv_maxRate or simply too many bots in the round.

"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 classic Call of Duty server needs exactly one open port: 28960 UDP. On Plutonium T6 it is 4976 UDP, on Plutonium IW5 it is 27016 UDP.
• Game, status query and RCON share one port on Call of Duty. You cannot separate RCON from the game with a port rule, you need a rule that looks into the packet payload.
• Getstatus reflection is the game-specific amplification vector: a 41 byte request, factor 63.9 for the Quake network protocol per CISA alert TA14-017A, which works out to around 2,600 bytes of response.
• Turn the query brake on: sv_queryIgnoreMegs 4, sv_queryIgnoreTime 2000, sv_queryBounceIgnoreTime 12000. On many servers it sits at 0 and is therefore off.
• Set rcon_password only if you genuinely need RCON: the password travels unencrypted over UDP and can be guessed any number of times without an account lockout.
• The master server ports 20810 and 20800 are outbound destination ports and do not belong in your inbound rules.
• From roughly 1 Gbps or a few hundred thousand packets per second onwards, only the network in front of the server decides the outcome, not your configuration.

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.