Why Game Hosting Is a Hard Detection Problem
Game servers are among the most frequently attacked infrastructure on the internet, and they are also among the hardest to protect without false alarms. The reason is that legitimate game traffic and attack traffic share a lot of the same properties: small UDP packets, high packet rates, and bursty arrival patterns.
A busy Minecraft server on port 25565 might sustain 15,000–40,000 PPS during peak hours as players load chunks and sync entity positions. A Counter-Strike 2 server on port 27015 with 64 players runs at roughly 64 tickrate, sending and receiving a combined 8,000–12,000 packets per second per match. A Valheim dedicated server on ports 2456–2457 sits lower, typically 2,000–6,000 PPS, but spikes hard when players enter portal transitions or large raids spawn. Set a flat 50,000 PPS alert threshold and you will miss a focused UDP flood against a half-empty CS2 server. Set it at 10,000 PPS and you will get paged during every Minecraft rush hour.
The second complication is attack duration. Game server floods are often extremely short: 30–90 second bursts designed to lag out a match and disconnect players without sustaining traffic long enough to trigger upstream abuse detection. By the time a human responds to a standard alert, the attack may already be over and the damage done. Detection needs to be sub-second, and alerting needs to fire within the first few seconds of the anomaly.
Per-Game-Type Threshold Tuning
The first step is to stop treating your 50 servers as a homogeneous group. A Valheim node and a CS2 node have completely different traffic profiles and need separate detection policies. In Flowtriq, you assign each node to a detection policy that controls the baseline multipliers and severity mapping.
Minecraft (port 25565)
Minecraft Java Edition communicates over TCP, which sets it apart from most other game servers. The legitimate traffic pattern is moderate PPS (5,000–40,000 depending on player count and world activity) with large variance. Chunk loading can cause 3–4x spikes that last 5–10 seconds when many players teleport simultaneously. Configure Flowtriq's fast-window multiplier at 4x for these nodes and set the anomaly duration requirement to 8 seconds before escalating to Warning. This absorbs teleport spikes without suppressing genuine attacks.
# Recommended policy for Minecraft nodes fast_multiplier: 4.0 slow_multiplier: 6.0 min_duration_warning: 8s min_duration_high: 15s watched_ports: [25565] protocol_filter: tcp
SYN floods against Minecraft are common because it uses TCP. Watch for a sudden spike in new connections per second alongside PPS. A legitimate player connection surge (server whitelist dropped, viral video posted) will show gradual ramp-up; a SYN flood hits full intensity within one or two seconds.
Counter-Strike 2 (port 27015)
CS2 uses UDP for game traffic and has a very predictable traffic envelope. At 64-tick with a full 10-player server, expect roughly 10,000–14,000 PPS inbound and 8,000–12,000 PPS outbound. The pattern is extremely regular — nearly metronomic — which actually makes attack detection easier. Any sudden deviation from the steady tick-rate pattern is suspicious.
# Recommended policy for CS2 nodes fast_multiplier: 3.0 slow_multiplier: 5.0 min_duration_warning: 5s min_duration_high: 10s watched_ports: [27015, 27020] protocol_filter: udp
UDP floods against CS2 servers are the most common attack type. Attackers send oversized UDP packets (900–1200 bytes) to port 27015 at rates of 200,000–500,000 PPS. The PPS-to-BPS ratio is a reliable discriminator: legitimate CS2 packets average 80–120 bytes; flood packets average 900+ bytes. Flowtriq's attack classification will flag this as a UDP flood with high confidence.
Valheim (ports 2456–2457)
Valheim uses port 2456 for the game server and 2457 for Steam query traffic. The low baseline PPS (2,000–6,000) means attacks stand out more clearly, but the server is also more sensitive to even modest floods — a 50,000 PPS flood against a Valheim server is catastrophic because the game engine is not designed to absorb that kind of packet pressure.
# Recommended policy for Valheim nodes fast_multiplier: 3.0 slow_multiplier: 4.0 min_duration_warning: 4s min_duration_high: 8s watched_ports: [2456, 2457] protocol_filter: udp
Per-node alerting for every game type
Flowtriq detects attacks like this in under 2 seconds, classifies them automatically, and alerts your team instantly. 7-day free trial.
Start Free Trial →Deploying ftagent Across 50 Nodes
At 50 servers, manual agent installation is not practical. Use a configuration management tool. The following Ansible snippet installs the Flowtriq agent and drops the correct policy configuration for each node based on its group membership.
- name: Install ftagent
hosts: game_servers
tasks:
- name: Install ftagent
pip:
name: ftagent
extra_args: --break-system-packages
- name: Write ftagent config
template:
src: ftagent.conf.j2
dest: /etc/ftagent/ftagent.conf
notify: Restart ftagent
- name: Enable and start ftagent
systemd:
name: ftagent
enabled: true
state: started
In your inventory, assign nodes to groups (minecraft_servers, cs2_servers, valheim_servers) and use group variables to set the detection policy name that maps to the policies you created in the Flowtriq dashboard. Each node's API key is stored in your secrets manager and injected at deploy time.
Discord Webhook Alerting
Discord is the natural choice for game hosting operations — your team is already there. In the Flowtriq dashboard, navigate to Channels and add a Discord webhook. The webhook URL comes from your Discord server under Server Settings → Integrations → Webhooks.
Flowtriq sends a formatted embed for each alert that includes the node name, attack type, current PPS and Mbps, severity, and a direct link to the incident page. A typical Critical alert embed looks like this in Discord:
[CRITICAL] node: cs2-dal-03 Attack type: UDP Flood Inbound PPS: 287,441 pps (+2,480% baseline) Inbound BPS: 312 Mbps Duration: 00:00:14 Severity: Critical → https://flowtriq.com/dashboard/incident/...
For a 50-server operation, consider creating separate Discord channels for different severity levels: #ddos-info for low-severity events that do not require action, and #ddos-critical that pages the on-call role with @on-call mentions. Configure Flowtriq to send Info and Warning events to the first channel and High and Critical to the second. This keeps noise out of the critical channel so mentions are always meaningful.
Escalation Policies for Multi-Person Ops Teams
With a multi-person team, not every flood needs every engineer. A 30-second, 80,000 PPS flood against a single CS2 server is a nuisance but it is not an all-hands situation. A 300,000 PPS sustained attack targeting a dozen nodes simultaneously is. Escalation policies let you route these differently.
In Flowtriq, create escalation tiers based on severity and scope:
- Tier 1 — Single node, Warning/High: Notify the node owner or the junior ops engineer. Discord push notification only. No overnight pages.
- Tier 2 — Single node, Critical: Page the on-call network engineer. Discord notification with @on-call mention. Escalate to team lead if unacknowledged after 5 minutes.
- Tier 3 — Multiple nodes simultaneously (3+), any severity: Page the on-call and the team lead immediately. This pattern often indicates a coordinated attack against a specific customer or ASN.
- Tier 4 — 10+ nodes, Critical: Full incident response. Page all senior engineers, open a war room channel in Discord, notify the NOC.
The multi-node correlation in Tier 3 and Tier 4 is something static threshold systems cannot do. Flowtriq's dashboard surfaces cluster-wide attack views so you can see immediately when an attack is spreading across nodes rather than being isolated.
One thing that catches teams off guard: a single attacker will often probe with a 30-second burst against one node, then pause, then repeat against a different node. The individual events look like Warning-level nuisances. The pattern is a coordinated stress test. Reviewing your Flowtriq incident timeline at the end of the day often reveals campaigns that no single alert would have flagged.
Distinguishing Player Spikes from Attacks
The most common false positive in game hosting is confusing a player count spike with an attack. A popular streamer joins your Minecraft network and brings 300 viewers with them. PPS climbs from 18,000 to 95,000 in under a minute. That looks like an attack on a graph.
Two indicators reliably distinguish legitimate player spikes from floods. First, a genuine player surge shows gradual ramp-up over 2–5 minutes as players join sequentially. A UDP flood hits full intensity within 1–3 seconds. Flowtriq's attack classification uses this ramp-rate characteristic as a strong signal. Second, legitimate players produce a diverse source IP distribution — each new connection comes from a different residential IP. A flood typically comes from a small number of source IPs (booter services) or a very large number of spoofed IPs. The source diversity metric in Flowtriq's attack report distinguishes these cases.
Protect your infrastructure with Flowtriq
Per-second DDoS detection, automatic attack classification, PCAP forensics, and instant multi-channel alerts. $9.99/node/month.
Start your free 7-day trial →