7 Days to Die server: how to absorb a SYN flood without crashing?

SYN flood mitigation is critical when your 7 Days to Die server crashes under waves of half-open TCP connections that exhaust kernel resources and deny legitimate players access. This attack vector—formally documented in RFC 4987—remains one of the most common Layer 4 threats facing game servers in 2026, capable of overwhelming even well-provisioned hardware within seconds. This article walks through the technical mechanisms of SYN floods, why 7 Days to Die is particularly vulnerable, and how kernel-level protection using XDP and nftables stops the attack before it reaches your application.

Understanding the root cause, recognizing the symptoms in real time, and deploying stateless packet filtering at the lowest possible layer will restore stability and protect your community from repeat attacks.

Why SYN Floods Crash 7 Days to Die Servers

A SYN flood exploits the three-way TCP handshake by sending thousands of SYN packets per second with spoofed source IP addresses. The server allocates a connection tracking entry for each inbound SYN, waits for the corresponding ACK that never arrives, and eventually exhausts the net.ipv4.tcp_max_syn_backlog kernel parameter. Once the backlog queue is full, new legitimate connection attempts—including player logins on TCP port 26900 and Steam query traffic on UDP port 26900–26903—are dropped or delayed.

7 Days to Die runs on the Unity engine with a custom networking stack that expects stable, low-latency TCP connections for player synchronization. The game server process itself has no insight into half-open connections; by the time a SYN packet reaches userspace, kernel memory is already committed. Restarting the server clears the backlog temporarily but does nothing to stop the next wave.

Common Symptoms

• Players timing out during login while the server console shows no errors.
• High CPU iowait as the kernel context-switches between thousands of incomplete sockets.
• Rapidly growing conntrack table visible via cat /proc/net/nf_conntrack | wc -l.
• Unresponsive SSH or panel access, because the attack saturates connection tracking globally.

Traditional application-layer mitigations—rate-limiting in the game config, increasing the SYN backlog, enabling SYN cookies—reduce impact but do not eliminate the root problem: every malicious packet still traverses the full network stack, consuming CPU cycles and memory.

Kernel-Level SYN Flood Mitigation with XDP

XDP (eXpress Data Path) attaches an eBPF program to the network interface driver, inspecting and filtering packets before the kernel allocates an sk_buff structure. This stateless, per-packet decision happens in nanoseconds, allowing the server to drop malicious SYN floods at line rate without involving conntrack, iptables chains, or the TCP stack.

How XDP Stops SYN Floods

An XDP program parses the Ethernet, IP, and TCP headers in a single pass. For TCP packets with the SYN flag set and no corresponding ACK, the program can:

• Rate-limit per source IP using a BPF hash map that tracks packet timestamps and enforces a maximum packets-per-second threshold.
• Drop packets from blacklisted prefixes instantly, before any kernel data structure is allocated.
• Allow only SYNs destined for legitimate game ports (26900 TCP, 26900–26903 UDP), dropping everything else at L2.

The PAKKT Engine runs as a single XDP program per interface, managing up to 256 concurrent rules driven by BPF maps. Each rule specifies a port range, protocol, and action type (block, rate_limit, allow_only). For SYN flood mitigation, a typical rule looks like:

{
  "port_start": 26900,
  "port_end": 26900,
  "protocol": "TCP",
  "rule_type": "rate_limit",
  "max_port_pps": 500
}

This configuration permits 500 packets per second on TCP port 26900, dropping any excess. Because XDP operates before conntrack, spoofed SYNs never create half-open sockets. Legitimate players experience no added latency; the eBPF verifier guarantees the program completes in bounded time, typically under one microsecond per packet.

XDP Limitations and Complementary Stateful Filtering

XDP is stateless: it cannot track connection state (SYN, SYN-ACK, ACK) or distinguish a legitimate three-way handshake from a flood. For that reason, XDP rate-limiting alone may still permit low-rate SYN floods that stay under the per-port threshold. The solution is layering XDP with stateful nftables rules.

Stateful SYN Protection with nftables Conntrack

nftables provides connection tracking (conntrack) and stateful inspection at Layer 3/4. By combining XDP's high-speed pre-filter with nftables' ability to track TCP state, you achieve defense in depth: XDP drops the bulk attack traffic, and nftables enforces per-connection and per-source rate limits on the remaining packets.

Example nftables Rule for SYN Rate-Limiting

table inet pakkt {
  set syn_ratelimit {
    type ipv4_addr
    flags dynamic, timeout
    timeout 60s
  }

  chain input {
    type filter hook input priority filter; policy accept;

    # Allow established/related
    ct state established,related accept

    # Rate-limit new SYN packets per source IP
    tcp flags syn ct state new \
      update @syn_ratelimit { ip saddr limit rate 10/second burst 20 packets } \
      accept

    tcp flags syn ct state new drop
  }
}

This rule permits each source IP to open at most 10 new TCP connections per second, with a burst allowance of 20. Any additional SYNs are dropped. Because this chain runs in the inet pakkt table—isolated from Docker, fail2ban, and iptables-persistent—there is zero risk of rule conflicts or accidental policy overwrites.

TCP Flag Validation

Attackers often send malformed packets (SYN+FIN, SYN+RST, or no flags) to bypass naive filters. nftables can enforce strict flag combinations:

tcp flags & (fin|syn|rst|ack) == syn ct state new accept
tcp flags & (fin|syn|rst|ack) != syn ct state new drop

Only packets with the SYN flag set and no other conflicting flags are permitted for new connections. This stops common evasion techniques documented in MITRE ATT&CK T1499.001.

Integration with XDP

When PAKKT.io provisions both XDP and nftables rules, the data path becomes:

1. XDP (PAKKT Engine): drops packets exceeding global or per-port PPS limits, blocks blacklisted IPs.
2. nftables (inet pakkt table): applies conntrack, TCP flag validation, per-source SYN rate-limit.
3. Application (7 Days to Die): receives only clean, validated traffic.

This dual-layer architecture handles multi-vector attacks: volumetric floods are absorbed by XDP, while low-and-slow or protocol-abuse attacks are caught by nftables.

Monitoring and Real-Time Response

Effective SYN flood mitigation requires visibility into attack patterns and the ability to update rules without server downtime. The PAKKT platform provides:

• Per-port metrics: packets accepted, dropped, rate-limited, stored in TimescaleDB with one-second granularity.
• GeoIP dashboard: world map and top source IPs, highlighting attack origins in real time.
• Audit log: every rule change, blacklist update, and agent configuration event.
• Automatic blacklist synchronization: when an IP exceeds the rate-limit threshold repeatedly, it is added to both the XDP BPF map and the nftables set, blocking all packets from that source.

Zero-Downtime Rule Updates

BPF maps are updated atomically via the bpf() syscall. When you modify a rate-limit threshold or add a port range in the PAKKT panel, the agent pushes the new map entries without detaching or recompiling the XDP program. The same applies to nftables: adding an IP to a named set is a single nft command that takes effect immediately.

nft add element inet pakkt blacklist_v4 { 203.0.113.42 }

This operational flexibility means you can respond to an ongoing attack in seconds, adjusting thresholds or blacklisting entire ASNs without restarting the game server or SSH daemon.

Public API and Template Marketplace

For advanced users, PAKKT Integrations include a public API (API key authentication) and a community-shared template marketplace. You can script automatic blacklist updates triggered by external threat intelligence feeds, or import pre-configured XDP/nft rulesets optimized for 7 Days to Die. The API supports JSON payloads for bulk rule creation:

POST /api/v1/agents/{agent_id}/rules
{
  "rules": [
    {
      "port_start": 26900,
      "port_end": 26903,
      "protocol": "any",
      "rule_type": "rate_limit",
      "max_port_pps": 1000
    }
  ]
}

This enables infrastructure-as-code workflows and seamless integration with existing monitoring stacks (Prometheus, Grafana, Zabbix).

Deployment Considerations and Performance Impact

XDP requires a Linux kernel version 5.x or higher with CONFIG_XDP_SOCKETS and a network driver that supports native XDP mode (most modern drivers: ixgbe, i40e, mlx5, virtio_net). The PAKKT agent is a lightweight Go binary (mTLS, 30-second heartbeat, SHA256 self-update, garble obfuscation) with a runtime footprint of under 1% CPU and less than 5 MB RAM.

Hardware and Network Considerations

• NIC offload: ensure that Generic Receive Offload (GRO) and Large Receive Offload (LRO) are enabled for maximum XDP throughput.
• CPU pinning: for extreme performance, pin XDP processing to dedicated cores using ethtool -L and IRQ affinity.
• MTU and packet size: PAKKT rules support min/max packet size filters, useful for dropping unusually large or fragmented SYN packets.

Compatibility with Existing Firewall Rules

Because PAKKT provisions nftables rules in a dedicated inet pakkt table, there is no conflict with Docker's DOCKER chain, fail2ban's INPUT modifications, or iptables-persistent saved rules. Each table operates independently; packet traversal order is controlled by hook priorities. The PAKKT input chain runs at priority filter, after mangle and before any application-specific rules.

For detailed kernel documentation on XDP and nftables hooks, refer to the official kernel.org XDP guide.

Conclusion

Stopping SYN floods that crash your 7 Days to Die server demands kernel-level intervention: XDP filters malicious packets at line rate before conntrack allocation, while stateful nftables rules enforce per-connection rate limits and TCP flag validation. This dual-layer architecture eliminates the performance penalty of userspace filtering, preserves SSH and panel access during attacks, and integrates seamlessly with existing firewall policies. By monitoring per-port metrics and maintaining synchronized IP blacklists across both layers, you gain real-time visibility and zero-downtime response capabilities that keep your community online.

FAQ

Can I increase the kernel SYN backlog instead of deploying XDP?

Increasing net.ipv4.tcp_max_syn_backlog and enabling SYN cookies (net.ipv4.tcp_syncookies=1) reduces the immediate crash risk but does not prevent resource exhaustion. Every SYN packet still allocates memory and CPU cycles in the kernel TCP stack. XDP drops malicious SYNs before any allocation occurs, achieving orders of magnitude better efficiency under high packet rates.

Will XDP rate-limiting affect legitimate players during peak login times?

Properly tuned rate limits (e.g., 500–1000 PPS per port) far exceed the connection rate of legitimate players. A single player generates one SYN per connection attempt; even a coordinated login of 100 players over 10 seconds averages 10 PPS. XDP rate limits target flood volumes (tens of thousands PPS), not normal gameplay traffic. Additionally, whitelisting trusted IP ranges in the XDP map ensures VIP or staff access is never throttled.

How do I verify that XDP is actually running and blocking packets?

Use ip link show dev eth0 to confirm the XDP program is attached (look for xdp in the output). Then run bpftool prog show to list active eBPF programs and bpftool map dump name pakkt_rules to inspect rule entries. For per-rule statistics, check the PAKKT dashboard or query the agent's metrics endpoint. You can also observe drop counters with ethtool -S eth0 | grep xdp if your driver exposes XDP statistics.