Pterodactyl Panel DDoS protection guide

Back to Blog

What Is Pterodactyl Panel?

Pterodactyl Panel is an open-source game server management platform built on Docker. It is used by thousands of game hosting companies, Minecraft networks, FiveM communities, and hobbyist server operators to provision, manage, and monitor game servers through a clean web interface.

The architecture has two main components:

• Panel: The web application (built on Laravel/PHP) that provides the admin and user interface. Operators and customers use the Panel to create servers, manage files, view console output, and configure allocations. It typically runs on its own dedicated server or VPS.
• Wings: The node daemon that runs on each physical or virtual server hosting game containers. Wings communicates with the Panel over HTTPS, manages Docker containers, handles file transfers via SFTP (port 2022), and exposes a management API on port 8080. Each Wings node can host dozens or hundreds of game server containers.

Every game server runs inside a Docker container with port allocations mapped from the host. A single Wings node might run 30 Minecraft servers, 10 FiveM servers, and 5 Rust servers, all sharing the same physical hardware and network interface. This density is what makes Pterodactyl efficient for hosting companies, and it is also what makes DDoS attacks so devastating.

Why Pterodactyl Hosts Are Prime DDoS Targets

Game servers are the single most targeted category of infrastructure for DDoS attacks. Players attack servers over bans, lost matches, rivalries, and sometimes just for entertainment. DDoS-for-hire services (booters) cost as little as $10/month and require zero technical knowledge to operate.

Pterodactyl environments face amplified risk because of how they consolidate workloads:

• Shared infrastructure. A single Wings node may host 20-50 game servers. When one server is targeted, the entire node absorbs the attack traffic. Every customer on that node experiences packet loss, latency spikes, or complete disconnection.
• Shared IP addresses. Many hosting operators assign multiple game servers to the same IP address on different ports. An attacker targeting one server's IP also hits every other server sharing that IP.
• Public port information. Game server ports are inherently public. Players need the IP and port to connect, and server list APIs (Minecraft's SLP, Source engine's A2S_INFO) expose this information to anyone who queries.
• Docker networking complexity. Pterodactyl uses Docker's bridge networking, which means standard iptables INPUT chain rules do not apply to container traffic. Many operators set up firewall rules that look correct but do nothing because they are in the wrong chain.

The combination of dense multi-tenant workloads, publicly exposed endpoints, and a user base that includes people motivated to attack makes Pterodactyl hosting one of the highest-risk environments for DDoS.

The Pterodactyl Attack Surface

Understanding what an attacker can target on a Pterodactyl setup is the first step to building effective protection. There are four distinct attack surfaces.

Panel web interface (ports 80/443)

The Panel is a standard web application. It is the least commonly attacked component because taking it offline does not affect running game servers. Players can still connect and play even if the Panel is down. However, a sustained attack on the Panel prevents operators from managing servers, viewing console output, or responding to incidents. Protecting the Panel is straightforward because it is a web application that can sit behind a CDN/reverse proxy.

Wings daemon (port 8080 and SFTP on 2022)

Wings exposes an HTTPS API on port 8080 that the Panel uses to communicate with nodes. It also runs an SFTP server on port 2022 for file management. Attackers who discover the Wings port can flood it to disrupt management operations, prevent new server deployments, and block file uploads. If Wings becomes unresponsive, the Panel shows the node as "offline" and operators lose visibility into all servers on that node.

Game server ports (the primary target)

This is where the vast majority of attacks land. Common game server ports include:

Game              Default Port    Protocol    Notes
──────────────────────────────────────────────────────────────
Minecraft Java    25565           TCP         SLP query on same port
Minecraft Bedrock 19132           UDP         Raknet protocol
FiveM             30120           TCP + UDP   cfx.re protocol
Source games      27015           UDP         A2S_INFO query flood common
Rust              28015           UDP + TCP   RakNet + RCON
ARK               7777            UDP         Unreal Engine
Garry's Mod       27015           UDP         Source engine
Valheim           2456-2458       UDP         3 ports per server

Attackers typically target the game port directly with UDP floods, amplification attacks, or protocol-specific exploits (like Minecraft's SLP amplification or Source engine A2S query floods).

Docker bridge network

Pterodactyl creates a Docker bridge network (pterodactyl_nw) for container communication. Traffic destined for game server containers passes through Docker's network stack, which uses the FORWARD chain and its own iptables rules. This creates a critical pitfall: firewall rules in the INPUT chain do not filter traffic that Docker routes to containers. Many Pterodactyl operators discover this the hard way when their carefully crafted iptables rules have no effect during an attack.

What Happens When a Pterodactyl Node Gets DDoS'd

When a DDoS attack hits a Pterodactyl Wings node, the impact cascades across every game server on that node:

• All game servers experience packet loss. Even if the attack targets a single game server's port, the flood saturates the node's network interface. Every container on that node sees degraded connectivity.
• Wings daemon becomes unresponsive. The management API on port 8080 cannot respond when the network stack is overwhelmed. The Panel marks the node as offline.
• SFTP file transfers fail. Customers cannot upload plugins, download backups, or manage server files.
• Docker networking overhead amplifies the impact. Each packet destined for a container passes through Docker's iptables rules, bridge interface, and network namespace transitions. Under flood conditions, this overhead consumes CPU that would otherwise be available for game server processes.
• Shared IP allocation means collateral damage. If 15 game servers share one IP address (on different ports), an attack on that IP takes all 15 servers offline simultaneously. The attacker only needed to target one customer, but 15 customers are affected.

For hosting companies, this cascading failure is the worst-case scenario. One angry player attacks one Minecraft server, and your entire node goes down. Support tickets pour in from every customer on that node, and your reputation takes a hit.

Protecting the Panel

The Panel is the easiest component to protect because it is a standard web application. The recommended approach:

• Put the Panel behind Cloudflare. Point your panel domain (e.g., panel.example.com) through Cloudflare's proxy. Cloudflare absorbs L3/L4 attacks and provides WAF protection for the Laravel application. Set SSL mode to "Full (Strict)" and use Cloudflare origin certificates.
• Restrict admin routes by IP. Use Cloudflare Access or server-level firewall rules to restrict /admin routes to known admin IPs.
• Enable two-factor authentication. Pterodactyl supports TOTP-based 2FA. Require it for all admin and subuser accounts.
• Separate Panel and Wings servers. Never run the Panel on the same server as Wings. If a Wings node is attacked, the Panel remains operational, giving you visibility and management access to respond.

Protecting Wings Nodes

Wings nodes are where the real hardening work happens. These servers run game containers, handle player traffic, and are directly exposed to the internet.

Lock down Wings management ports

The Wings daemon (port 8080) and SFTP server (port 2022) should only be accessible from the Panel server and authorized admin IPs. There is no reason for the general internet to reach these ports.

# Allow Panel server to reach Wings API and SFTP
iptables -A INPUT -p tcp -s PANEL_IP --dport 8080 -j ACCEPT
iptables -A INPUT -p tcp -s PANEL_IP --dport 2022 -j ACCEPT

# Allow admin IPs for SFTP access
iptables -A INPUT -p tcp -s ADMIN_IP --dport 2022 -j ACCEPT

# Drop all other traffic to management ports
iptables -A INPUT -p tcp --dport 8080 -j DROP
iptables -A INPUT -p tcp --dport 2022 -j DROP

Separate management and game traffic

If your server has multiple IP addresses available, bind Wings management (port 8080) to a private or separate IP address that is not shared with game server allocations. This way, even if the game server IP is under attack, you retain management access to the node through the separate IP.

# In /etc/pterodactyl/config.yml
api:
  host: 10.0.0.5    # Internal/management IP
  port: 8080
  ssl:
    enabled: true
    cert: /etc/letsencrypt/live/node1.example.com/fullchain.pem
    key: /etc/letsencrypt/live/node1.example.com/privkey.pem

Rate limit new connections on game ports

Rate limiting per source IP prevents a single source from overwhelming the node with connection floods. This is effective against small-scale attacks from single IPs or small botnets:

# Rate limit new connections: 50 new connections per second per source IP
iptables -A INPUT -p udp -m conntrack --ctstate NEW -m hashlimit \
  --hashlimit-above 50/sec --hashlimit-burst 100 \
  --hashlimit-mode srcip --hashlimit-name game_udp \
  -j DROP

# Same for TCP game connections
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m hashlimit \
  --hashlimit-above 30/sec --hashlimit-burst 60 \
  --hashlimit-mode srcip --hashlimit-name game_tcp \
  -j DROP

Per-Allocation IP Strategy

One of the most impactful architectural decisions you can make for DDoS resilience is assigning separate IP addresses to different customers or groups of game servers.

In Pterodactyl, allocations are IP:port combinations assigned to game servers. By default, many operators create all allocations on a single IP address and vary only the port number. This is simple to manage but creates a single point of failure: one attack on that IP takes every server offline.

The per-allocation IP strategy works like this:

• Assign each customer (or high-risk server) a unique IP address. When that customer's server is attacked, only their IP is affected. All other customers on the node continue operating normally.
• Group low-risk servers on shared IPs. Servers that are unlikely targets (private servers, small communities) can share IPs to conserve address space.
• Reserve a "clean" IP for Wings management. The Wings API and SFTP run on an IP that is never exposed to players, ensuring you always have management access.

To implement this in Pterodactyl, add multiple IPs to the node's allocation pool through the admin panel:

# Add IP addresses to the server (example for Debian/Ubuntu)
# /etc/network/interfaces.d/game-ips
auto eth0:1
iface eth0:1 inet static
    address 203.0.113.10
    netmask 255.255.255.255

auto eth0:2
iface eth0:2 inet static
    address 203.0.113.11
    netmask 255.255.255.255

auto eth0:3
iface eth0:3 inet static
    address 203.0.113.12
    netmask 255.255.255.255

Then create allocations in the Pterodactyl admin panel for each IP. When creating a game server, assign it to an allocation on a dedicated IP. If that server gets attacked, you can null-route or blackhole just that one IP while every other server on the node stays online.

The DOCKER-USER Chain: The Critical Detail

This is the single most important section for Pterodactyl operators. If you take away one thing from this guide, let it be this: iptables rules in the INPUT chain do not apply to Docker container traffic.

When a packet arrives at the server destined for a game server container, it does not pass through the INPUT chain. Docker's networking routes it through the FORWARD chain using its own iptables rules. Docker inserts these rules automatically and they take priority over any custom rules you add to the FORWARD chain.

Docker provides the DOCKER-USER chain specifically for user-defined rules that need to filter traffic before it reaches containers. Rules in DOCKER-USER are evaluated before Docker's own rules, giving you control over what traffic reaches your game server containers.

# WRONG: This rule does NOTHING for Docker container traffic
iptables -A INPUT -p udp --dport 25565 -m hashlimit \
  --hashlimit-above 100/sec --hashlimit-mode srcip \
  --hashlimit-name mc -j DROP

# CORRECT: Use DOCKER-USER chain for container traffic
iptables -I DOCKER-USER -p udp -m conntrack --ctstate NEW -m hashlimit \
  --hashlimit-above 100/sec --hashlimit-burst 200 \
  --hashlimit-mode srcip --hashlimit-name mc_udp \
  -j DROP

Here is a complete DOCKER-USER ruleset for a Pterodactyl Wings node:

# Flush existing DOCKER-USER rules (keep the default RETURN)
iptables -F DOCKER-USER

# Allow established and related connections (critical for game traffic)
iptables -I DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j RETURN

# Drop invalid packets (common in spoofed floods)
iptables -I DOCKER-USER -m conntrack --ctstate INVALID -j DROP

# Rate limit new UDP connections per source IP
iptables -A DOCKER-USER -p udp -m conntrack --ctstate NEW -m hashlimit \
  --hashlimit-above 100/sec --hashlimit-burst 200 \
  --hashlimit-mode srcip --hashlimit-name docker_udp \
  -j DROP

# Rate limit new TCP connections per source IP
iptables -A DOCKER-USER -p tcp -m conntrack --ctstate NEW -m hashlimit \
  --hashlimit-above 50/sec --hashlimit-burst 100 \
  --hashlimit-mode srcip --hashlimit-name docker_tcp \
  -j DROP

# Drop TCP packets with bogus flags (SYN flood variants)
iptables -A DOCKER-USER -p tcp --tcp-flags ALL NONE -j DROP
iptables -A DOCKER-USER -p tcp --tcp-flags ALL ALL -j DROP
iptables -A DOCKER-USER -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
iptables -A DOCKER-USER -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

# Default: return to Docker's chain (allow traffic)
iptables -A DOCKER-USER -j RETURN

Important: Every time Docker restarts, it recreates its iptables rules. Your DOCKER-USER rules persist across Docker restarts, but you should save them with iptables-save and restore them on boot with iptables-restore or use a tool like netfilter-persistent to ensure they survive server reboots.

Hosting Provider Selection

The hosting provider you run your Wings nodes on determines your baseline DDoS protection. Some providers offer game-aware filtering that handles the majority of attacks before they reach your server.

• OVH Game DDoS Protection: The gold standard for game hosting. OVH's "Game DDoS Protection" product line includes protocol-aware filtering for Minecraft, Source engine, FiveM, and other game protocols. Their VAC (Anti-DDoS) system scrubs traffic at the edge and passes only clean packets to your server. The Game range servers include permanent mitigation that adds minimal latency. If you are starting a Pterodactyl hosting company, OVH Game is the recommended starting point.
• Hetzner: Affordable and reliable, but DDoS protection is basic. Hetzner null-routes IPs receiving more than approximately 500 Mbps of attack traffic, which takes the IP offline for up to 24 hours. Suitable for low-risk deployments but requires additional protection for serious game hosting.
• DDoS-Guard: Provides remote protection via GRE tunnels or BGP. Popular with game hosting operators who need protection on infrastructure at providers that lack native DDoS filtering.
• Path.net: Purpose-built for game hosting with low-latency UDP scrubbing. Their network is optimized for game traffic patterns and they offer BGP-based integration for automated mitigation.
• Combahton / Aurologic: German providers popular in the European Minecraft hosting market. Both offer game-aware DDoS protection with fast mitigation times.

Monitoring with Flowtriq

Firewall rules and provider-level protection are essential, but they are reactive by nature. You need real-time visibility into what is happening on your Wings nodes to detect attacks early, understand attack patterns, and verify that your protections are working.

Flowtriq is purpose-built for this. Install the agent on each Wings node and it monitors per-second PPS, BPS, and protocol distribution across all game server ports. Here is what that looks like for a Pterodactyl deployment:

Installation on a Wings node

# Install the Flowtriq agent
pip install ftagent

# Start with your API key and a descriptive node name
ftagent --api-key YOUR_API_KEY --node-name "wings-eu-01"

# Or install as a systemd service for persistence
ftagent install --api-key YOUR_API_KEY --node-name "wings-eu-01"

The agent runs alongside Wings and game server containers with minimal resource impact (less than 1% CPU, 30-50 MB memory). It monitors all traffic on the node's network interfaces, including traffic routed through Docker's bridge to game containers.

Per-port attack detection

Because Pterodactyl hosts multiple game servers on different ports, Flowtriq tracks traffic metrics per destination port. When an attacker floods port 25565 (one Minecraft server), Flowtriq identifies the specific port and server under attack. The dashboard shows you exactly which game server is being targeted, not just that "the node is receiving high traffic."

Discord alerts (what Pterodactyl operators already use)

Most Pterodactyl hosting communities already have Discord servers for customer communication and internal operations. Flowtriq sends real-time attack alerts via Discord webhooks, including the node name, attack type, targeted port, PPS volume, and mitigation status. Your team and your customers see immediately that an attack is detected and being handled.

# Example Discord webhook alert content:
#
# 🚨 DDoS Attack Detected
# Node: wings-eu-01
# Target: 203.0.113.10:25565 (Minecraft)
# Type: UDP Flood
# Volume: 450,000 PPS / 2.1 Gbps
# Status: Mitigation active
# Started: 2026-03-15 14:32:07 UTC

PCAP evidence for abuse reports

When you need to report an attack to your hosting provider's abuse team or to law enforcement, Flowtriq captures full PCAP data during detected attacks. These packet captures are downloadable from the dashboard and can be opened in Wireshark. Having timestamped packet-level evidence makes abuse reports dramatically more effective than saying "we got DDoS'd."

Dynamic baselines for game traffic

Pterodactyl nodes experience wildly variable traffic patterns. A node might host 30 active Minecraft servers during peak hours and 5 during off-peak. Wipe days, game updates, and streamer events cause massive traffic spikes that look like attacks to static-threshold detectors. Flowtriq uses rolling dynamic baselines that learn each node's normal traffic patterns and adjust detection thresholds automatically. This eliminates the false positives that plague generic monitoring tools in game hosting environments.

Complete Hardening Checklist

Here is a summary of every protection layer covered in this guide, in order of implementation priority:

1. Put the Panel behind Cloudflare with Full (Strict) SSL and 2FA enabled.
2. Restrict Wings ports (8080, 2022) to Panel IP and admin IPs only.
3. Use the DOCKER-USER chain for all firewall rules affecting game server traffic.
4. Drop invalid packets and bogus TCP flags in DOCKER-USER.
5. Rate limit new connections per source IP in DOCKER-USER.
6. Assign per-customer IP addresses for high-risk or high-value game servers.
7. Bind Wings management to a separate IP from game traffic.
8. Choose a hosting provider with game-aware DDoS protection (OVH Game, Path.net).
9. Install Flowtriq on every Wings node for per-second detection and alerting.
10. Configure Discord webhook alerts for real-time attack notifications.
11. Persist iptables rules with netfilter-persistent or iptables-save/restore.
12. Test your rules by verifying game server connectivity after applying firewall changes.

Back to Blog

Related Articles