The Pterodactyl DDoS Problem
Pterodactyl Panel is the most popular open-source game server management platform. It runs game servers inside Docker containers on Wings nodes. The problem is that game servers are the most frequently DDoS-targeted service on the internet, and Pterodactyl's architecture creates a specific vulnerability: when one game server on a Wings node gets attacked, the entire node's network link saturates, and every server on that node goes down.
A typical Wings node hosts 20-50 game servers. An attack on one server affects all of them. Without monitoring, you do not know an attack is happening until players start complaining and tickets pile up.
Setting Up Per-Node Monitoring
Install ftagent directly on each Wings node. The agent runs alongside the Wings daemon and monitors all traffic hitting the machine at the kernel level.
Step 1: Install on the Wings node
ssh root@wings-node-01 pip install ftagent sudo ftagent --setup
The setup wizard prompts for your Flowtriq deploy token. Get it from the Flowtriq dashboard under Settings > API. Alternatively, use the one-liner installer:
curl -sL https://get.flowtriq.com | sudo bash
Step 2: Configure service ports
If you are using the Pterodactyl addon, service ports sync automatically from your panel. Without the addon, configure them manually in the Flowtriq dashboard or via API:
# Example: register game server ports as service traffic
curl -X POST https://flowtriq.com/api/v1/nodes/{node_id}/service-ports \
-H "Authorization: Bearer {token}" \
-d '{
"ports": [
{"port": 25565, "protocol": "tcp", "label": "Minecraft Java"},
{"port": 19132, "protocol": "udp", "label": "Minecraft Bedrock"},
{"port": 30120, "protocol": "both", "label": "FiveM"},
{"port": 28015, "protocol": "udp", "label": "Rust"}
]
}'
Service port configuration tells the agent which traffic is legitimate game traffic. Everything else becomes the anomaly baseline. This is what makes detection accurate for game server environments where normal traffic is already high-PPS and bursty.
Step 3: Verify monitoring
sudo ftagent --status Agent Status: Running Node ID: node_a1b2c3d4 Uptime: 2m 34s Current PPS: 12,847 Current BPS: 48.2 Mbps Service Ports: 4 configured Baseline: Learning (needs 5 min of data)
The agent needs about 5 minutes of traffic data to build an initial baseline. After that, detection is active and will trigger on deviations from normal patterns.
What Gets Detected
Game servers face specific attack patterns:
- UDP floods: The most common attack against game servers. Massive volumes of UDP packets targeting game ports or random ports on the node.
- SYN floods: TCP SYN packet floods targeting Minecraft Java servers, the Wings daemon (port 8080), or SFTP (port 2022).
- DNS/NTP amplification: Reflected traffic from open resolvers and NTP servers. The source IPs are spoofed, so blocking by IP is useless.
- GRE floods: Less common but growing. GRE protocol packets that bypass simple UDP/TCP firewall rules.
- Application-layer floods: Query floods targeting specific game protocols. These look like legitimate player connections but at abnormal rates.
The agent classifies each attack by type, calculates confidence, and logs the target IP and port. This tells you exactly which game server is being targeted, not just which node.
Automated Response
Detection without response just gives you a front-row seat to the outage. Configure automated mitigation on each Wings node:
On-node firewall rules
ftagent deploys iptables rules in the DOCKER-USER chain. This is critical for Pterodactyl because Docker manages its own iptables chains, and standard INPUT rules do not apply to traffic routed to containers.
# ftagent automatically adds rules like: iptables -I DOCKER-USER -p udp --dport 28015 \ -m hashlimit --hashlimit-above 50000/sec \ --hashlimit-mode srcip --hashlimit-name rust_flood \ -j DROP
Rules are added when an attack starts and removed when it ends. The agent manages its own chain and never touches existing Docker or system rules.
Alert routing
Send attack notifications to Discord (most game server operators live in Discord), Slack, PagerDuty, or any webhook endpoint. The alerts include the game server name, port, attack type, and severity so you know immediately which server is targeted.
Upstream escalation
For volumetric attacks that exceed what on-node rules can handle, configure auto-escalation to BGP FlowSpec or cloud scrubbing. The escalation chain goes: local firewall rules first, then FlowSpec, then RTBH or cloud scrubbing. Each level activates only if the previous one is insufficient.
Multi-Node Deployment
If you run multiple Wings nodes, install ftagent on each one. The Flowtriq dashboard shows all nodes in a single view with per-node metrics, incidents, and health status. You can see at a glance which nodes are under attack, which are healthy, and how many game servers are on each node.
This fleet-wide visibility is what turns reactive firefighting into proactive monitoring. You see attack patterns across your infrastructure: which nodes get targeted most, what times of day attacks peak, and which game types attract the most attacks.
FAQ
Does ftagent affect game server performance?
No. The agent reads kernel-level counters from /proc and /sys. It does not inspect individual packets during normal operation. CPU usage is under 1% on a typical Wings node. PCAP capture only activates during detected incidents.
Do I need a separate Flowtriq node for each Wings node?
Recommended but not required. Per-node deployment gives you per-node detection and per-node firewall rules. You can also run a single agent in central mode if you have a small setup.
Does this work with Pelican (Pterodactyl fork)?
ftagent runs at the OS level, so it works with any panel that uses Docker containers. The Pterodactyl addon specifically hooks into Panel events, but the core monitoring works regardless of what panel you use.
Protect your Wings nodes. Install ftagent in 2 minutes, get sub-second DDoS detection with automated response. Start your free 14-day trial. Also available on BuiltByBit.