Minecraft server under DDoS attack: how to react in an emergency?

A Minecraft DDoS attack can bring your server to its knees in seconds, overwhelming network resources and leaving legitimate players unable to connect. Whether you operate a small survival realm or a large multi-world network, understanding how to identify, mitigate, and prevent volumetric attacks at the kernel level is essential for maintaining uptime and player trust in 2026. This emergency guide walks you through immediate response steps and long-term hardening strategies using XDP/eBPF and nftables.

Distributed Denial of Service attacks targeting Minecraft servers have evolved significantly. Modern botnets can generate millions of packets per second, exploiting the stateless nature of initial connection handshakes and the relatively low bandwidth required to saturate a typical game server's network interface. The key to survival lies in filtering malicious traffic as close to the hardware as possible—before it consumes CPU cycles or saturates your application layer.

Recognizing a Minecraft DDoS Attack in Progress

The first step in stopping an attack is confirming you're actually under one. Minecraft servers can experience performance degradation for many reasons—chunk generation lag, plugin conflicts, or database bottlenecks. A true DDoS attack exhibits specific network-layer symptoms:

• Sudden connection timeouts: Players report inability to join or immediate disconnects despite the server process appearing healthy in logs.
• Bandwidth saturation: Your network interface shows inbound traffic spiking to line rate (1 Gbps, 10 Gbps, etc.) with minimal legitimate activity.
• Packet flood patterns: Tools like iftop, nethogs, or tcpdump reveal thousands of connections from disparate source IPs, often with malformed or incomplete TCP handshakes.
• Amplification signatures: High volumes of UDP traffic to port 25565 (Java Edition) or 19132 (Bedrock Edition), frequently with spoofed source addresses.

Run a quick packet capture to confirm suspicions:

tcpdump -i eth0 -n port 25565 -c 1000 | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -nr | head -20

If you see hundreds of unique IPs each sending only a handful of packets, you're likely facing a distributed attack. Traditional application-layer defenses (Bukkit/Spigot plugins, BungeeCord filters) are irrelevant at this stage—the packets never reach your Java process because the kernel's network stack is already drowning.

Immediate Emergency Response Steps

When you detect an active attack, every second counts. Your goal is to restore service for legitimate players while mitigating the flood. Follow this triage sequence:

1. Enable Temporary Rate-Limiting with nftables

If you don't yet have a dedicated XDP program deployed, nftables can provide immediate relief. Create an isolated table to avoid conflicts with existing rules (Docker, fail2ban, etc.):

nft add table inet pakkt
nft add chain inet pakkt input { type filter hook input priority 0 \; policy accept \; }
nft add rule inet pakkt input tcp dport 25565 ct state new limit rate 100/second accept
nft add rule inet pakkt input tcp dport 25565 drop

This limits new TCP connections to 100 per second on port 25565, dropping excess attempts. Adjust the rate based on your server's typical join rate. For UDP-based Bedrock servers, use:

nft add rule inet pakkt input udp dport 19132 limit rate 500/second accept
nft add rule inet pakkt input udp dport 19132 drop

Note that nftables operates in the kernel's netfilter hooks—faster than userspace, but still after the NIC driver has processed the packet. For multi-million PPS attacks, you need XDP.

2. Deploy XDP for Line-Rate Filtering

XDP (eXpress Data Path) processes packets in the driver layer, achieving sub-microsecond per-packet latency. A minimal XDP program can drop traffic before it reaches the network stack. If you have PAKKT.io deployed, activate an emergency block rule:

• Protocol: TCP or UDP (match your server type)
• Port range: 25565-25565 (Java) or 19132-19132 (Bedrock)
• Rule type: rate_limit
• Max PPS: 50000 (tune based on your NIC capacity)

PAKKT's single XDP program per interface can manage up to 256 simultaneous rules via BPF maps, allowing you to layer port-specific, protocol-specific, and packet-size filters without recompiling or reloading the BPF object. Changes propagate in real time through the lightweight Go agent.

3. Populate IP Blacklists Dynamically

While volumetric filtering buys you breathing room, precision blocking of known-bad sources reduces noise. PAKKT synchronizes IP blacklists between the XDP BPF map and nftables rules, ensuring both stateless (XDP) and stateful (conntrack) layers enforce the same policy. Add offending subnets manually or via API:

curl -X POST https://api.pakkt.io/v1/agents/YOUR_AGENT_ID/blacklist \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"ip": "203.0.113.0/24", "reason": "DDoS source", "expires_at": null}'

The agent receives the update within 30 seconds (heartbeat interval) and inserts the entry into both the pakkt_blacklist BPF map and the inet pakkt nftables set. Packets from blacklisted IPs are dropped at XDP, never consuming CPU for conntrack or ruleset evaluation.

Long-Term Hardening: Building a Resilient Architecture

Once the immediate crisis is resolved, implement a defense-in-depth strategy that prevents future attacks from causing downtime. Minecraft servers face unique challenges—publicly advertised IPs, predictable ports, and a young player base prone to "stressing" services they dislike. Your architecture must assume attacks will happen and ensure they fail gracefully.

Layer 1: XDP Stateless Pre-Filtering

The PAKKT Engine runs as a single XDP program per network interface, offering several advantages over traditional iptables/nftables-only stacks:

• Sub-microsecond latency: Packets are evaluated in eBPF bytecode before the kernel allocates socket buffers, reducing CPU overhead by orders of magnitude.
• Stateless efficiency: No per-connection memory, no hashtable lookups—just map-based rule evaluation. Ideal for SYN floods and UDP amplification.
• Configurable policies: Set global max_pps, per-port max_port_pps, and packet size ranges (drop < 64 bytes to mitigate fragmentation attacks, or > 1500 bytes to block jumbogram abuse).
• Action versatility: XDP_DROP (discard silently), XDP_PASS (allow to netfilter), or XDP_TX (reflect packet—use cautiously to avoid becoming an amplifier yourself).

Example rule configuration for a Java Edition server with 200 average concurrent players:

Parameter	Value	Rationale
Port range	25565-25565	Java Edition default
Protocol	TCP	Java uses TCP for all traffic
Rule type	rate_limit	Allow legitimate bursts, cap floods
Max PPS	100000	Headroom for join spikes + keep-alives
Min packet size	40	TCP header minimum (20 IP + 20 TCP)
Max packet size	1500	Standard MTU, blocks jumbograms

Monitor the PAKKT dashboard's per-rule metrics (stored in TimescaleDB) to observe drop rates, adjust thresholds, and identify attack patterns over time. GeoIP visualization helps spot geographic clustering—if 80% of malicious traffic originates from a single AS, consider blocking the entire range during peak hours.

Layer 2: Stateful nftables with Conntrack

XDP's stateless nature is a strength for volumetric floods but a limitation for sophisticated attacks (SYN-ACK reflection, slowloris-style partial handshakes). The PAKKT agent deploys a complementary nftables ruleset in the inet pakkt table, isolated from Docker's nat table, fail2ban's filter table, and iptables-persistent rules. Key features:

• Connection tracking: Only ct state new packets are subject to rate-limits; established,related flows pass freely, ensuring legitimate players aren't penalized after joining.
• TCP flag validation: Drop packets with invalid flag combinations (SYN+FIN, RST+ACK without prior SYN) that indicate spoofing or scanner activity.
• Per-IP rate-limiting: Use nftables meters to enforce per-source limits, e.g., max 5 new connections per second per IP:

nft add rule inet pakkt input tcp dport 25565 ct state new \
  meter ratelimit { ip saddr limit rate 5/second burst 10 packets } accept
nft add rule inet pakkt input tcp dport 25565 ct state new drop

This prevents a single botnet node from monopolizing connection slots, while the global XDP rate-limit caps aggregate traffic. The two layers work in concert: XDP sheds the bulk of the flood at line rate, nftables enforces stateful policies on the reduced traffic that passes through.

Layer 3: Application-Layer Intelligence

Even with kernel-level protection, your Minecraft server software should implement basic hygiene:

• Connection throttling: Configure connection-throttle in server.properties (Java) or equivalent in your BungeeCord/Velocity proxy to limit logins per IP per interval.
• Whitelist mode during attacks: Temporarily enable white-list=true to allow only known players, then re-open once the attack subsides.
• Reverse proxy (BungeeCord/Velocity): Never expose your backend servers' IPs publicly. Route all traffic through a hardened proxy with PAKKT Integrations (Pterodactyl, public API) managing the proxy's network rules.
• Geofencing: If your player base is regional, use PAKKT's GeoIP data to allow-only traffic from specific countries at the XDP layer, dropping intercontinental floods outright.

Monitoring, Forensics, and Continuous Improvement

Post-incident analysis is critical. PAKKT's centralized panel retains per-port metrics, audit logs of rule changes, and internal agent logs (kernel messages, XDP program load events, nftables ruleset diffs). After mitigating an attack, review:

• Peak PPS and bandwidth: Did you approach your NIC's theoretical maximum? If so, consider upstream scrubbing (CloudFlare, OVH VAC) as a complementary layer—PAKKT protects the server kernel, but cannot magically increase your 1 Gbps uplink to 10 Gbps.
• Top source IPs and ASNs: Are the same networks repeatedly involved? Proactively blacklist them or contact their abuse desks.
• Packet size distribution: If attackers used uniformly small packets (e.g., 64 bytes), tighten your XDP min_packet_size filter to raise the bar for future attempts.
• Rule efficacy: Compare drop counts across XDP and nftables. If nftables is dropping significantly more than XDP, your XDP rules may be too permissive—tune thresholds accordingly.

For organizations managing multiple Minecraft servers (networks, hosting providers), PAKKT's public API enables automation. Integrate attack telemetry into your monitoring stack (Prometheus, Grafana) and trigger dynamic blacklist updates via webhooks. The community-shared XDP/nft template marketplace (accessible at PAKKT Blog) offers pre-built configurations for common attack vectors, reducing response time from hours to minutes.

Cost-Benefit Reality Check

Kernel-level protection is not a silver bullet. If an attacker saturates your upstream ISP's peering capacity (terabit-scale attacks), no amount of on-server filtering helps—the pipe is full before packets reach your NIC. In such scenarios, PAKKT's role is to maximize the efficacy of the bandwidth you do have, ensuring legitimate traffic is prioritized and malicious traffic is dropped at the earliest possible point. For context, PAKKT's lightweight Go agent consumes less than 1% CPU and under 5 MB RAM, leaving maximum resources for your Minecraft server process. At €3/agent/month, the cost is negligible compared to downtime-induced player churn or the expense of over-provisioning bandwidth.

Conclusion

Stopping a Minecraft DDoS attack in 2026 requires a kernel-first approach: XDP for stateless line-rate filtering, nftables for stateful connection tracking, and centralized orchestration to adapt policies in real time. By deploying rules at the eBPF and netfilter layers, you intercept malicious packets before they consume application-layer resources, maintaining sub-millisecond latency for legitimate players even under sustained assault. Regular monitoring, forensic analysis, and iterative tuning transform reactive firefighting into proactive resilience, ensuring your server remains online when it matters most.

FAQ

Can I use XDP-based DDoS protection alongside Docker and fail2ban on the same server?

Yes. PAKKT's XDP program operates in the driver layer and its nftables rules reside in an isolated inet pakkt table with a defined priority. Docker manipulates the nat table for container networking, and fail2ban typically modifies the default filter table. Because nftables supports multiple tables with independent chains and priorities, all three coexist without conflict. Ensure your inet pakkt input chain has priority 0 (default filter priority) or lower to evaluate rules before application-specific hooks.

What packet rates can a single XDP program realistically handle on commodity hardware?

On a modern server with a 10 Gbps NIC and a mid-range CPU (e.g., Intel Xeon Silver, AMD EPYC 7002 series), a well-optimized XDP program can process several million packets per second per core. The PAKKT Engine's map-driven architecture avoids expensive per-packet operations like string matching or cryptographic hashing, focusing on integer comparisons for port, protocol, and IP lookups. Real-world performance depends on rule complexity and NIC driver support (native XDP vs. generic XDP), but expect sub-microsecond per-packet processing in the fast path. For reference, dropping 5 million PPS of 64-byte packets consumes approximately 2.5 Gbps of bandwidth—well within a 10 Gbps link's capacity.

Should I block all international traffic if my Minecraft server only serves local players?

Geofencing can be highly effective if your player base is geographically constrained. Configure an XDP allow_only rule specifying your country or region, and PAKKT will drop all packets from other GeoIP locations at line rate. However, consider edge cases: players traveling abroad, VPN users, and cloud services (e.g., monitoring probes, API integrations) that may originate from foreign IPs. A safer approach is to combine geofencing with IP whitelisting—block unknown international sources by default, but explicitly allow trusted IPs (your own monitoring infrastructure, partner networks, etc.) in the whitelist BPF map. This balances security and accessibility without locking out legitimate use cases.