DDoS on Game Servers: Contract Terms, Attack Fingerprints, and the Configuration You Still Own

DDoS protection on a game server is sold in two incompatible ways. Some hosts market a mitigation capacity figure in terabits; others sell “always-on filtering.” Neither tells you whether your 64-tick instance survives a 90-second burst at 42 Gbps during a tournament final. This article focuses on the contractual and configuration gaps that decide the outcome, not the marketing baseline every provider already claims.

Attack fingerprints that target game servers specifically

Game servers attract a narrower attack set than web properties, and each one exploits a different layer. Knowing the fingerprint tells you which mitigation to demand and which of your own controls to tighten.

Attack type	Typical size	Layer	What stops it
UDP amplification (DNS/NTP/memcached)	20–800 Gbps	L3/L4	Upstream scrubbing capacity, BGP diversion
Source-spoofed UDP floods	5–100 Gbps	L4	Rate limiting on game port, challenge-response where supported
Query protocol reflection (Steam A2S, Source)	1–20 Gbps	L7/application	Query port rate limits, disabling public query
Connection floods (TCP handshake, slot exhaustion)	Low bandwidth, high PPS	L4	Per-IP connection caps, proxy protocol
Application-layer join floods	Low bandwidth	L7	Join rate limits, auth queue, whitelist during events

The high-PPS connection flood is the most common failure mode in practice: 2 Gbps of spoofed SYNs exhausts the connection tracking table on an unfiltered host, and legitimate players see timeouts while bandwidth graphs look almost normal. Ask your provider how many concurrent connections-per-second their edge can absorb before state exhaustion. Small-packet floods are cheap to launch and disproportionately effective against gaming infrastructure.

The five contract questions that actually matter

• Where does mitigation happen? On the host’s edge, or upstream at a transit provider after a BGP announcement? Upstream diversion adds 30–120 seconds of attack-on-target time — long enough to lose a match. In-line always-on filtering has no detection delay.
• What is the guaranteed scrubbing capacity for your specific server? A shared 1 Tbps figure is not the same as dedicated capacity for your allocation.
• Is the mitigation stateful — does it break legitimate UDP? Aggressive L4 filters drop game traffic that looks bursty. Ask for a post-mitigation packet-loss figure, not a pre-mitigation one.
• Is the mitigation logged and alertable? You need the attack source ports and vectors to tune your own firewall rules afterwards.
• What happens on a false positive? If the filter misclassifies your players as a flood, who can whitelist a subnet, and how fast? A protection system that blocks your own player base for ten minutes is an outage.

What you still configure yourself

Mitigation is an edge function; it cannot protect you from application-layer join floods or a leaked server IP. Two rules cover most residual risk. First, never expose the raw game port publicly — front it with a proxy or keep it behind a private network, and rotate the public address if it leaks. Second, apply host-level rate limits: a Linux firewall rule capping new UDP packets per source IP, plus a connection limit in your game panel, absorbs the low-bandwidth floods that slip past volumetric scrubbing.

Always-on versus on-demand, revisited for events

Always-on filtering adds a few hundred microseconds of edge latency and never misses a short burst. On-demand mitigation keeps latency marginally lower in peacetime but needs a detection window, which is exactly when a fast attack does its damage. For a competitive server where a 20-second outage is fatal, always-on is the correct default. The trade-off worth measuring is the post-mitigation packet-loss delta: ask the host for a sample of legitimate UDP flowing through the filter, and confirm loss stays under 0.1%. If a provider cannot produce that figure, you are buying a bandwidth number, not protection.

A practical hardening checklist

• Disable or rate-limit the public query port when you do not need server-browser listings.
• Set nftables or iptables limits: -m hashlimit --hashlimit-above 50/sec --hashlimit-mode srcip -j DROP for new UDP flows on game ports.
• Cap concurrent connections per source IP at 2–4 for join traffic.
• Keep a second, unpublished IP from a dedicated server allocation ready for events; DNS-swap if the primary is targeted.
• Instrument the edge: alert when inbound PPS exceeds 5x the seven-day baseline, before saturation.
• Run a scheduled tabletop drill — simulate mitigation being triggered mid-match and verify players reconnect cleanly.

Audit your setup twice a year. Provisioning a game server with always-on filtering and a documented mitigation SLA removes the largest single risk to uptime during a launch week. Check the specific mitigation terms on game server hosting before assuming a bandwidth number implies protection — capacity and filtering are separate line items, and the difference only shows up under attack.