Protecting a Palworld server from DDoS attacks

A Palworld server that throws every player out at once in the middle of the evening, goes offline for a few minutes and then comes back on its own rarely has a hardware problem. Usually an attack is running. This article shows how to protect a Palworld server from DDoS attacks: first what you can configure yourself 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 so that it stays reachable.

Everything here refers to the official dedicated server by Pocketpair (Steam App ID 2394010) 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, keep the order: measure first, change afterwards. A hard restart under load discards everything that has happened in the world since the last automatic save point, and the measurements of the incident are gone with it.

Why Palworld servers get targeted by DDoS attacks

A Palworld server is a small, fixed audience at a fixed address. The dedicated server is capped at 32 players, controlled by ServerPlayerMaxNum with a valid range of 1 to 32. Anyone hosting through the in-game menu instead gets four players, and only for as long as the host is online. Everything else follows from those 32 slots: the group plays at fixed evening hours, everybody knows everybody, and an outage at 8 pm does not hit a fraction of the players, it hits all of them.

The address of the server is no secret. Palworld has no lobby brokering through a vendor service: players type the IP address and the port into the direct connect field, and anyone who also wants the server listed in the community server browser starts it with -publiclobby and lets the query port answer. Everybody who has ever connected therefore knows the target. A booter service that shells that address for a few euros a month demands neither skill nor effort from whoever orders it.

On top of that, all game traffic runs over UDP. UDP has no connection setup you could insist on, and the source address of a UDP packet can be spoofed. So an attacker does not have to join your server, or even address it correctly, in order to create load. For what technically happens during such an attack, read What is a DDoS attack?.

The ports that actually matter on a Palworld server

A Palworld server needs exactly one open port: 8211 UDP. Everything else is optional, and depending on its job it is actively harmful when it sits on the open internet. That leads to a useful distinction: a DDoS attack on port 8211 always hits the game traffic itself, while an attack on port 27015 UDP only hits the server list entry.

Every switch for this lives in a single file: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, or Pal\Saved\Config\WindowsServer\PalWorldSettings.ini on Windows. It starts with the section line [/Script/Pal.PalGameWorldSettings], followed by one single OptionSettings=(...) line that holds every setting as a list. A line break inside those parentheses invalidates the entire configuration, and the server silently falls back to the default values. Do not edit the DefaultPalWorldSettings.ini template in the server directory, because it is overwritten on every update.

Palworld servers in numbers

The following values are the basis for every decision about filter rules and thresholds.

Why query port 27015 is the most sensitive point

The query port answers status requests in the Steam A2S format, the same query that Counter-Strike and ARK servers serve. An A2S_INFO request is a connectionless UDP packet of a few dozen bytes, while the reply with server name, world, player count and progress is a multiple of that. Because the source address of a UDP packet can be spoofed, an attacker can address other people's query ports and steer the larger replies at his actual target. In that case your server is not the victim, it is the amplifier, and its uplink pays the bill.

Valve therefore added a challenge step in front of A2S_INFO on 8 December 2020: the server first replies with S2C_CHALLENGE, the requester has to send the token back and thereby proves that it is not spoofing its source address. That defuses the amplification, but it does not end it, and it does nothing at all against a plain flood of identical queries from real addresses.

For Palworld this produces an important advantage over the Source engine: game traffic and server query sit on separate ports. On Counter-Strike 2 both share port 27015, so a coarse rate limit throws your own players out along with the attack. On Palworld you can rate limit 27015 UDP hard, or close it completely, without touching a single live game session on 8211 UDP. If you do not need the list entry, drop -publiclobby and the query port entirely and remove a whole attack surface from the network.

What you can do yourself before spending money

The steps below will not stop a volumetric attack, no software on the server can do that. They do clear away everything underneath it: port scans, query floods, takeover attempts on the administration ports, and strangers occupying all 32 slots. That is the bulk of what disturbs a Palworld server day to day, and it costs half an hour.

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:8211 means "reachable from the entire internet", 127.0.0.1:8212 means "local only" and needs no firewall rule. Next to the game process, a server that has grown over time often also shows a management panel, a web server for a map view and a database. A port scan from outside gives you the attacker's view:

nmap -Pn -sU -p 8211,27015 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. Leave open only what Palworld really needs

Two allow rules are enough, and the second one is optional. 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 8211/udp comment 'Palworld game traffic'
ufw allow 27015/udp comment 'Palworld Steam query'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Leave out the third line if your server is not meant to appear in the community server browser. Your players still connect through the IP address and port 8211, the server merely disappears from the public list. The full guide including the escape route is in Setting up the UFW firewall without locking yourself out.

3. Take RCON on 25575 and the REST API on 8212 off the internet

Both ports are administration interfaces with full control over the server, and both ship disabled: RCONEnabled=False and RESTAPIEnabled=False. Whoever switches them on should know what that publishes.

The REST API on 8212 TCP authenticates through HTTP Basic Auth with the fixed user name admin and the value of AdminPassword, over unencrypted HTTP. Your administration password therefore travels the wire in reversible form on every single request. RCON on 25575 TCP is an equally unencrypted text protocol, and Pocketpair has marked it deprecated in favor of the REST API. For new installations the REST API is the right choice, and for both the same rule applies: not on the open internet.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="a long random value"

Make the interface reachable through SSH port forwarding, then work locally against 127.0.0.1:8212:

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

Never leave AdminPassword empty, because empty is the default. A value from openssl rand -base64 32 is enough. The same goes for ServerPassword, more on that below.

4. Rate limit query port 27015 without losing the list entry

Connectionless Steam packets start with four set bytes (0xffffffff), regular game traffic does not carry that header. You can put a per source rate limit on exactly that, which slows queries down and keeps the list entry alive. With nftables, loaded through nft -f:

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

Priority -10 makes sure the rule takes effect before the UFW filter chain, and @th,64,32 reads the first four bytes behind the UDP header. With classic iptables, a match on the A2S_INFO signature achieves the same separation:

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Ten queries per second and address is generous: a listing service asks every few minutes, not several times per second. The only thing that matters is that this rule sits on 27015 and not on 8211, otherwise you hit your own players.

5. Limit packet rates on 8211 UDP

On the game port itself, an upper limit per source address helps against small floods from few sources. On Palworld that limit is comparatively safe to set, because at most 32 players are connected at the same time and each of them occupies exactly one source address:

iptables -I INPUT -p udp --dport 8211 \
  -m hashlimit --hashlimit-name palworld_udp --hashlimit-mode srcip \
  --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

The number is a starting point, not a truth. A full server with 32 players and many bases produces far more packets than a round of four, and setting the limit too tight throws out your own players. Measure a week of normal operation first, then set the limit to twice the measured peak.

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 additionally belong in /etc/ufw/before.rules, because otherwise they disappear with the next ufw reload. Whether a rule is reached at all is shown by iptables -L INPUT -n -v: if the hit counters stay at zero, it never applies.

6. Server password, ban list and the 32 slots against slot exhaustion

Slot exhaustion is the cheapest attack on a Palworld server and needs no bandwidth at all. A dedicated server has at most 32 slots, so 32 concurrent connections are enough to lock out the entire community. A volumetric attack costs whoever orders it money, 32 sessions cost nothing. That makes this route more attractive against small servers than any flood.

Palworld has no built-in whitelist. The moderation tools are kick, ban and a server password, and that server password is the single most effective measure against slot exhaustion:

ServerPassword="a value only your group knows"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword is empty by default, so anyone with the IP address and the port gets in. BanListURL points at the list maintained by Pocketpair by default and can be redirected to your own text file if you keep project specific bans. Do not set ServerPlayerMaxNum above 32: higher values are unsupported and will bite you at the next update at the latest. And one thing has to be clear: a server password protects your slots, not your uplink. An attacker who floods your server does not want to join at all.

7. Relieve connection tracking and enlarge the buffers

This point explains outages that look like a volumetric attack but are not one. The kernel creates connection tracking (conntrack) entries for UDP traffic, and with spoofed source addresses every address means a new entry. Once the table is full, the kernel drops packets without distinction, the attack and your players fly out together, 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 most effective step is to not track the game traffic in the first place, because Palworld manages its own sessions:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

With iptables the equivalent is iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK plus the same line for OUTPUT with --sport. Afterwards the ports need an explicit allow rule, because without tracking no rule that checks an existing state applies any more. If packets arrive faster than the server process picks them up, the receive buffer overflows on top of that. To the players it looks like packet loss although the uplink is free. An addition under /etc/sysctl.d/, activated with sysctl -p:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Whether those values are needed is something the kernel tells you itself: if UdpRcvbufErrors in nstat -az climbs, they apply. If the counter stays at zero, the adjustment changes nothing.

8. Collect measurements before it gets serious

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. During an incident, four commands are enough:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 -c 200 "udp port 8211 or udp port 27015"

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. Palworld adds a measurement that no other tool gives you. With the REST API enabled, the metrics endpoint returns the frame rate of the server, the current player count and the uptime, among other values:

curl -s -u admin:YOUR_ADMIN_PASSWORD http://127.0.0.1:8212/v1/api/metrics

That single number separates the two most common causes cleanly. If the server frame rate collapses while the packet rates stay unremarkable, it is load, not an attack. If the frame rate stays stable while inbound packets climb far above the normal value, it is an attack. How to read the network figures in detail 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. Attacks against game server projects usually range between 5 and 50 Gbps, so five to fifty times your uplink. Whether your iptables rule behind it is any good no longer matters, because the packets of your players stop getting through before that.

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

A Palworld server adds an unfavorable ratio on top. A fully occupied server with 32 players uses only a fraction of an uplink of 1 Gbps. The attack therefore does not have to be large to reach a multiple of normal operation, and that is exactly why attacks that would go unnoticed on a large platform are enough here.

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 package

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. Palworld is one of the games with its own protection profile, and which further titles and protocols are covered is listed in Game server DDoS protection with real-time filtering.

Advanced DDoS Protection for Palworld 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 EUR 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 8211 UDP and what is allowed on 27015 UDP, without writing a ticket for it.
• Changes take effect in real time, so you can fine-tune while an attack is running, for example by temporarily tightening the query port while leaving the game port untouched.
• A protection profile matched to the game, for Palworld as well as for custom applications on any TCP or UDP port.

Advanced DDoS Protection is meant for servers hosted at KernelHost. If you currently run your Palworld project elsewhere and are attacked continuously, move it to KernelHost, and both layers apply from provisioning onwards.

The two tiers compared

For most Palworld servers 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 on Palworld servers and how to fix them

"I blocked 27015 and now the server is gone from the community list": that is the expected behavior, because the query port carries the list entry. Do not block it wholesale, rate limit the connectionless packets per source address as shown in step 4. If you do not need the list entry anyway, leave the port closed, drop -publiclobby and give your players the IP address and port 8211 for a direct connection.

"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. On Palworld that is almost always one of three routes: a player who has the address sitting in the direct connect field anyway, a Discord bot with a status display that republishes it, or an old A record in DNS pointing at the previous address. Changing the address buys time, it is not a solution.

"The server has lag spikes, but the uplink is quiet": on Palworld that is load more often than an attack. The server process steadily claims more memory over its uptime, which is why a scheduled restart is part of normal operation and not an emergency workaround. Check the server frame rate through the metrics endpoint and the memory usage of the process. If sar -n DEV 1 10 stays unremarkable, it was not a DDoS attack.

"All 32 slots are taken, but nobody is visible in the game": that is slot exhaustion, and it hits the game logic, not the uplink. Set a ServerPassword, ban the suspicious accounts through the ban list, and limit packets per source address on 8211 UDP.

"The REST API was reachable from outside for a few days": then your administration password is compromised, because HTTP Basic Auth over unencrypted HTTP transmits it in reversible form on every request. Change AdminPassword, close 8212 TCP to the outside and reach the interface only through SSH port forwarding from now on.

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

"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 Palworld server needs exactly one open port: 8211 UDP. Query port 27015 UDP is only required for the entry in the community server browser.
• RCON on 25575 TCP and the REST API on 8212 TCP never belong on the open internet, because both transmit their credentials unencrypted. RCON is additionally marked deprecated by Pocketpair.
• Because game traffic and server query sit on separate ports on Palworld, 27015 UDP can be rate limited hard without touching live game traffic on 8211 UDP.
• The dedicated server is capped at 32 slots, which makes slot exhaustion the cheapest attack. A configured ServerPassword is the single most effective countermeasure, because Palworld has no built-in whitelist.
• Local measures end at the uplink: 1 Gbps is 125 megabytes per second, and at 64 bytes per packet around 1.49 million packets per second fit into it. Everything above that has to end in the network in front of the server.
• At KernelHost the two-layer always-on protection is included with every server package at no surcharge and active from provisioning onwards, with no null-routing. Advanced DDoS Protection with a dedicated protected IP and self-managed rules per port starts at 50.00 EUR per month.

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