Protecting a Minecraft Bedrock server from DDoS attacks

A Minecraft Bedrock server that disappears from the server list for a few minutes every evening and then comes back rarely has a hardware problem. Usually an attack is running, and it runs exactly when the most players are online. This article shows how to protect a Minecraft Bedrock server from DDoS attacks: first what you can secure yourself at no extra cost, then the point where those measures physically end, and finally what has to happen in the network in front of the server.

Everything here refers to a Bedrock Dedicated Server, PocketMine-MP or Nukkit 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 you run the Java Edition instead, the protocol-level attacks typical there are covered in Minecraft DDoS protection and nullping protection. The plain installation of a Bedrock server is described in Install a Minecraft Bedrock server with Nukkit.

If the attack is running right now: do not change anything in the configuration and do not restart the server. Capture the measurements first (see the section "Collect measurements before it happens"), because once the attack is over they are gone for good.

Why Minecraft Bedrock servers are such frequent DDoS targets

The Bedrock Edition is the version that runs on consoles, phones, tablets and Windows, and it carries the largest Minecraft player base of all. Where many servers stand, the incentive to attack is largest too: competing networks, banned players, internal conflicts. An attack costs whoever orders it neither skill nor any serious amount of money, because a server booter is sold as a subscription.

The technical reason goes deeper. A Bedrock server speaks UDP, not TCP, and it answers anyone who asks long before any login has taken place. Those two properties are what make port 19132 UDP such a rewarding target. For the details of what a DDoS attack actually is, read What is a DDoS attack?.

RakNet: a UDP protocol that answers before anyone has logged in

RakNet is the UDP networking library through which the Minecraft Bedrock Edition carries all of its game traffic. UDP has no connection setup a server could insist on, and source addresses can therefore be spoofed. RakNet builds its own reliability layer on top: sequence numbers, acknowledgements (ACK) and negative acknowledgements (NAK) with which a client can request lost packets again.

The connection setup consists of seven packets, four from the client and three from the server:

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

Only after this does the client send the Login packet with its Xbox Live credentials. That is the decisive sentence for anyone who wants to secure a Bedrock server: the server has processed seven packets, spent processing time and memory and answered several times before it even learns who is knocking. Every measure that hooks into the login therefore only takes effect after the load has already been created.

On top of that comes a second, even earlier entry point. So that a server shows up in a player's server list with its name, version and player count, it answers the Unconnected Ping (packet ID 0x01) with an Unconnected Pong (packet ID 0x1C). This exchange happens before the actual connection setup, requires no proof of any kind, and cannot be switched off on the Bedrock Dedicated Server without removing the server from every server list.

Unconnected Ping as an amplification vector: the numbers

An amplification attack is an attack in which the attacker sends small requests with a spoofed source address to third-party servers so that their larger answers land on the victim. The Bedrock server is not attacked in that case, it is used. For the Unconnected Ping the math looks like this:

Two things follow from this immediately. First: a long server name enlarges the answer and therefore the amplification factor you make available to strangers. A short name is not cosmetics, it is a protective measure. Second: the factor of 4 in a default setup is small enough that your server stays uninteresting as a reflector, but large enough that a ping flood loads your own outbound line with four times what comes in.

The amplification bug of 2024 shows how bad it can get when the reliability layer itself is abused. In the RakNet library used at the time, the Connection Request Accepted packet was marked as reliable. An attacker could play through the connection setup up to that point with a spoofed source address and then send a single negative acknowledgement covering the range 0 to 8191. The server then sent thousands of packets to the spoofed address without the attacker having to do anything further. The fix consisted of marking that packet as unreliable, of sending a cookie in Open Connection Reply 1 that a genuine client mirrors back, and of introducing packet limits: 120 packets per source address per 10 millisecond tick, and 1,000 packets in total per tick.

Bedrock Edition or Java Edition: what is different about DDoS protection

Anyone who has secured a Java server before will carry almost everything over incorrectly. The two editions share the name, but not the network protocol:

The row about SYN cookies is the most important one. On the Java Edition the Linux kernel fends off a SYN flood without the Minecraft process ever noticing. On the Bedrock Edition that help does not exist: every single UDP packet is handed all the way up into the server process and evaluated there. A Bedrock server has no built-in operating system protection against a flood on port 19132, because UDP has none.

The row about the missing SRV record has a practical consequence that surprises many operators: you cannot hide the port behind a DNS record on the Bedrock Edition. Players enter address and port by hand. Whoever moves the port has to tell every single player the new one.

The ports that actually matter

A Bedrock Dedicated Server binds to exactly two ports, and it does so over UDP on both. In server.properties:

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

Those are the defaults shipped by Microsoft, documented in the Bedrock Dedicated Server reference. Around these two ports sit further services that run along depending on the server software:

The third and fourth rows are the most common avoidable mistakes on Bedrock servers. On Nukkit and PocketMine-MP, enable-query is on out of the box, and on Nukkit an accidentally enabled RCON lands on 19132 TCP, meaning the same port number as the game. Anyone who only checks "19132 is open, that is fine" will miss it.

One peculiarity of the official Bedrock Dedicated Server belongs here as well: it has no server-ip directive. PocketMine-MP and Nukkit do have one (server-ip, and on PocketMine additionally server-ipv6), the official server does not. It therefore always listens on every address of the system, and the firewall is your only way to narrow that down.

What you can do yourself before spending money

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

1. Take stock: what is listening on 19132 at all?

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

ss -lntup
ss -lnup sport = :19132

The interesting column is the local address. 0.0.0.0:19132 and [::]:19133 mean "reachable from the entire internet". If a TCP entry with the same port number shows up next to it, RCON is running. A port scan from outside gives you the attacker's view, using -sU for UDP:

nmap -Pn -sU -p 19132,19133 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. Leave only 19132 UDP open and close the rest

A Bedrock server needs a single rule facing the outside, two with IPv6. 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 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

If you have no IPv6 players, drop the line for 19133 and additionally set enable-ipv6=false on PocketMine-MP. Every port you do not open is a port you do not have to defend. The full guide including the escape route is in Setting up the UFW firewall without locking yourself out.

3. Turn off LAN visibility, otherwise 19132 stays open

This is the trap almost everyone walks into when moving the port. The enable-lan-visibility directive is set to true out of the box and makes the server answer clients looking for servers on the local network. Microsoft explicitly documents that this causes the server to bind to the default ports 19132 and 19133 as well, even when server-port and server-portv6 have non-default values.

So anyone who moves the port to 19140 and feels safe is still listening on 19132. For a server on the internet, server.properties therefore needs:

enable-lan-visibility=false

Afterwards verify with ss -lnup that 19132 has really disappeared. As a side effect the same setting solves the problem of two Bedrock servers on the same host fighting over the port.

4. Switch off query and RCON

PocketMine-MP and Nukkit ship the GS4 query, a UDP server lookup modeled on the UT3 protocol, and they answer those lookups on the very same port 19132 the game runs on. The detailed answer contains the server name, the version, the level name, the state of the whitelist, address and port, the player count, the names of all connected players and, on PocketMine-MP, optionally the full plugin list. That is handy for status pages and Discord bots, but it tells an attacker exactly when an attack is worth the effort, and it costs processing time per lookup.

enable-query=off
enable-rcon=off

On PocketMine-MP the values read false instead of off, and the plugin list is disabled in pocketmine.yml with settings.query-plugins: false. One point that is rarely mentioned: the GS4 query on PocketMine-MP checks a token salted with the requesting address. The large answer therefore cannot be reflected to a spoofed address. It still costs processing time, and the published data still helps an attacker pick a target. The official Bedrock Dedicated Server has neither query nor RCON, so this step does not apply there.

If you genuinely need RCON, set rcon.port on Nukkit to a value of its own and open it only for your own address. Otherwise the fallback to server-port means that a remote console for your server is listening on 19132 TCP, meaning the same number you have written down everywhere as "open".

5. Enforce Xbox Live authentication

Xbox Live authentication is the check of whether a joining player holds a genuine account signed by Microsoft. On the Bedrock Dedicated Server the directive is called online-mode, on PocketMine-MP and Nukkit it is called xbox-auth. In both cases true is the factory setting and the correct value:

online-mode=true
xbox-auth=true

Microsoft adds an important qualification: clients connecting to remote servers outside the local network always require Xbox Live authentication anyway, regardless of this setting. The proof is carried as a signed token chain inside the Login packet, together with the Xbox user ID (XUID) and the display name.

And now the part that prevents a common misunderstanding: Xbox Live authentication protects your game logic, not your uplink. It happens inside the Login packet, which means after the complete RakNet connection setup. 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. Allowlist and player limit, and what they do not achieve

The allowlist (formerly the whitelist) is the list of players permitted to join. On the Bedrock Dedicated Server you enable it with allow-list=true, and the entries live in allowlist.json with name, XUID and the ignoresPlayerLimit field. On Nukkit and PocketMine-MP the directive is still called white-list.

allow-list=true
max-players=60
player-idle-timeout=15

A short idle timeout through player-idle-timeout is effective against slot exhaustion: players who only occupy a seat are kicked after the given number of minutes. A value of 0 means nobody is ever disconnected for being idle, and that is exactly what an attacker exploits when blocking your seats with real accounts.

The limit from the previous section applies here as well, and it is the most frequently overlooked point of all: the allowlist is only checked once the Login packet has been processed. It prevents joins, not packets.

7. Limit packet rates per source address

Against small attacks and sloppy bots, an upper limit per source address helps. For UDP you work with hashlimit, not with connlimit, because UDP has no connections:

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

The rule drops UDP packets once the same source address sustains more than 400 packets per second. That number is a starting point, not a truth: a full server with 60 players and a large view distance produces far more packets than an empty one, and setting the limit too tight throws out your own players. Measure a week of normal operation first.

You may set a considerably tighter limit on the Unconnected Ping, because a real client only asks for the server status while the server list is open, and then about once per second. With nftables you can match exactly that one packet, because the packet ID is the first byte behind the UDP header:

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

The expression @th,64,8 reads eight bits starting at bit 64 of the transport header, which is the first byte of the UDP payload. The value 0x01 is the packet ID of the Unconnected Ping. You can use the same offset to observe before you drop anything:

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

The first line counts incoming status lookups, the second one counts your own answers. If both run into the thousands per second while hardly anybody is playing, you are looking at a ping flood and not at your players.

Two notes on durability. 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.

8. Take load off the connection tracking of the kernel

Here is a bottleneck that hits UDP games far earlier than TCP ones: the kernel creates an entry in the connection tracking table for every UDP packet pair. During a flood with spoofed source addresses, every packet is a new source address and therefore a new entry. Once the table fills up, the server drops legitimate packets as well, and the log says "nf_conntrack: table full, dropping packet".

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

If the counter sits permanently close to the limit, you can exempt the game traffic from tracking. That is effective, but not without consequences, so do it in both directions and with a connection test afterwards:

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

After this, stateful rules no longer apply to that traffic. Your allow rule for 19132 UDP must therefore be a real port rule and must not rely on the ESTABLISHED state. Once the rules are in place, check with conntrack -L | grep 19132 that no entries are created any more, and connect with the game once before you save the rules permanently.

9. Run Geyser and Floodgate cleanly

Geyser is a bridge that lets Bedrock clients play on a Java Edition server: it accepts Bedrock connections on 19132 UDP, translates the protocol and talks to the Java server on 25565 TCP on the other side. Floodgate is the companion that lets those Bedrock players join without a Java account. For DDoS protection that means three things.

First: keep Geyser up to date. This very bridge was twice the reason for documented attacks. In March 2024 the amplification bug in the RakNet library described above was exploited on a large scale, fixed from build 478 onwards. In July 2025 a second case followed: a repeatedly sent resource pack response packet created multiple sessions per player, and disconnected clients could keep sending packets because the network channel was never closed. Fixed from build 897 onwards. Both cases were published by the project itself, with timelines.

Second: the Java server does not belong on the open internet. In the Geyser configuration, remote.address points to auto or 127.0.0.1 and remote.port to 25565. Bind the Java server locally accordingly and do not open 25565 TCP to the outside. Otherwise you have two attack surfaces instead of one, and the second is the one you never wrote rules for.

Third: the key.pem file is a secret. It is the key with which Floodgate skips Java Edition authentication for Bedrock accounts. Whoever puts it in a public repository, pastes it into a support ticket or shows it on a screenshot has given away the login of their server. The project warns about this explicitly.

10. Collect measurements before it happens

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 conntrack the measurement runs permanently in the background.

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

Three of these values are particularly telling on a Bedrock server. A permanently non-zero Recv-Q on the UDP socket of 19132 means the server process no longer picks up incoming packets fast enough. UdpRcvbufErrors counts exactly the packets that were dropped for that reason and is the hardest evidence that the bottleneck is the process, not the uplink. UdpNoPorts rises when somebody hits ports where nothing is listening at all, a typical picture during a broad port scan ahead of the actual attack.

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: 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. Your uplink is full as soon as somebody sends more than 125 megabytes per second. An attack of 5 to 50 Gbps is five to fifty times that. Whether your hashlimit 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 a Bedrock server it almost always hits first. All of the game traffic consists of many small UDP packets, and that is precisely the discipline in which an attacker operates most cheaply. An attack that does not even fill a third of your uplink can still take your server down, because the processing time goes into evaluating and dropping. Operators experience this as "the utilization was not even high, and yet everybody was thrown out". Inside the game the same thing appears as lag spikes, rubber-banding and connections dropping in the middle of building.

There is no local setting for that. Volumetric attacks have to end in the network in front of the server.

What KernelHost puts up against DDoS attacks on Bedrock servers

The always-on protection included with every server

DDoS protection at KernelHost is built in two layers and permanently active, with nothing for you to switch on, order or configure:

• Layer 1: 17 Tbps of mitigation capacity in the global scrubbing network. Volumetric attacks are scrubbed close to their source, before they reach the datacenter.
• Layer 2: Arbor real-time filtering with 3.2 Tbps in Frankfurt am Main. Directly in front of the server, protocol-specific patterns are detected and dropped, packet by packet. That includes UDP patterns on 19132 that show no RakNet behavior.

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. The location is Frankfurt am Main. 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 EUR 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 19132 UDP, what is allowed on 19133 UDP, and what applies to a non-default port if you have moved your server.
• 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 that matches the game. There are ready-made profiles for Minecraft, and there are profiles for modified and custom applications on any TCP or UDP port, which covers Nukkit, PocketMine-MP or a Geyser instance on a port of your choosing.

The two tiers compared

For most Bedrock 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 server elsewhere, the cleanest fix is to move it: the filtering works in the network in front of the server, and that network has to be ours.

Common mistakes and how to fix them

"I changed the port to 19140 and 19132 is still open": that is enable-lan-visibility=true. The Bedrock Dedicated Server then binds to 19132 and 19133 as well, no matter what server-port says. Set it to false, restart the server and verify with ss -lnup.

"I edited allowlist.json and now I cannot get in myself": two causes are common. There is still an old whitelist.json in the directory that the server reads instead, or the XUID entry is missing or wrong. With Xbox Live authentication active, the name alone is not reliably sufficient.

"My host suspended my server even though I was the one being attacked": check whether your server itself sent packets out. That is exactly what happened during the RakNet amplification bug of 2024: the affected servers sent thousands of packets to third-party addresses, and the abuse notices listed port 19132 as the source. With tcpdump -ni eth0 'udp src port 19132' -c 200 -q you can see where your server is answering. An up-to-date build removes 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.

"The server shows up in the list, but nobody can join": if the entry displays the name and player count, the Unconnected Pong is working, so the port is reachable in principle. If joining still fails, it is usually the Xbox Live login or the allowlist. If instead only IPv6 players cannot get in, the rule for 19133 UDP is missing.

"The server is running, but everybody has lag spikes": that is more often a plugin than an attack. First check whether Recv-Q on the UDP socket is growing and whether UdpRcvbufErrors is rising. If both stay calm and sar -n DEV 1 10 is unremarkable, it was not a DDoS attack but the server process itself. On the Bedrock Dedicated Server the script watchdogs help from there, and their thresholds live in server.properties under script-watchdog-hang-threshold and script-watchdog-slow-threshold.

"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 Minecraft Bedrock server needs exactly one open port facing the outside: 19132 UDP, plus 19133 UDP for IPv6 players only. Query, RCON, the script debugger on 19144 TCP and a Java server behind Geyser on 25565 TCP have no business on the open internet.
• Anyone who moves the port has to set enable-lan-visibility=false, otherwise the Bedrock Dedicated Server keeps binding to 19132 and 19133 in addition.
• Xbox Live authentication and the allowlist only take effect inside the Login packet, which means after the complete RakNet connection setup. They protect your game logic and your seats, not your uplink.
• The Unconnected Ping is requested with 33 bytes and answered with around 131 bytes, an amplification factor of roughly four. A short server name keeps that factor small.
• For UDP you use hashlimit rather than connlimit, and the connection tracking of the kernel is the first thing to fill up during a flood with spoofed source addresses. Both should be measured before the first attack, not during it.
• At around 1 Gbps your uplink is full, and at 64 bytes per packet roughly 1.49 million packets per second fit into it. Beyond that, only the filtering in the network in front of the server decides the outcome.
• At KernelHost the two-layer always-on protection is included with every server package, active from provisioning onwards and without null-routing. Advanced DDoS Protection adds a dedicated protected IP and self-managed rules per port.

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.