Hardcoded Game IPs Under a 220 Gbps UDP Flood
Northwind Interactive runs six game servers on the leased /24 198.51.100.0/24, currently originated by its ISP. The game client connects directly to those IPs over UDP 27015–27030 and hardcodes them; average latency is 38 ms and the studio SLA promises under 60 ms. On Friday a 220 Gbps UDP amplification attack and a 9 Mpps carpet-bombing wave hit all six IPs. The website is proxied by Cloudflare, but game traffic is not. The ISP can scrub only 20 Gbps and will not announce a more specific route. Northwind owns the /24 and has two data centers, each with 10 Gbps transit and a hardware firewall rated at 2 Mpps. They need to keep the same IPs and add no more than 10 ms. The security team is considering Spectrum versus Magic Transit and has a maintenance window in 48 hours.
1. Which Cloudflare service should terminate the attack: Spectrum or Magic Transit? Explain the deciding constraint and the BGP/tunnel design.
Read the worked answer
Magic Transit is the fit. The deciding constraint is that the game client hardcodes IP addresses. Spectrum is an L4 reverse proxy: clients must reach Cloudflare anycast addresses, normally via DNS, and Cloudflare forwards to the origin. Hardcoded client IPs would bypass it. Magic Transit instead lets Northwind advertise its own /24 to Cloudflare over BGP; Cloudflare attracts the attack, cleans it, and forwards legitimate packets through GRE or IPsec tunnels to the two data centers.
The design should be: establish two tunnels per data center for redundancy; verify latency from the nearest Cloudflare PoP to each data center; then announce the /24 to Cloudflare and have the ISP withdraw its announcement. Test with a less critical /24 first if possible. Rollback is to re-announce via the ISP and withdraw from Cloudflare. Confirm that the added tunnel path stays inside the 10 ms budget before cutover.
2. Write the Magic Firewall policy in intent form and explain how it handles the amplification traffic that uses allowed game ports.
Read the worked answer
Intent policy: default deny inbound; allow UDP 27015–27030 to the six game IPs; allow TCP 22 only from the operations bastion; allow ICMP echo from monitoring; deny everything else. Add explicit drops for common amplification vectors that should never hit game servers, such as UDP source ports 53, 123, 389, 1900, and 11211, plus fragmented or oversized UDP where the game protocol does not need it.
Crucially, Magic Firewall is policy enforcement, not the volumetric scrubber. If the attack packets use destination port 27015, a port allow rule cannot separate them from legitimate game packets. Cloudflare's L3/L4 DDoS mitigation handles the 220 Gbps and 9 Mpps volume before Magic Firewall. Magic Firewall should enforce the narrow service surface and block reflection-source patterns; the game server should also add per-connection rate limits and protocol authentication because Magic Transit does not understand game semantics.
3. What residual risk remains after Magic Transit is live, and what should Northwind do next?
Read the worked answer
Residual risk: Magic Transit cleans floods but does not validate game protocol behavior, so cheats, exploit packets, and low-volume application attacks still reach the servers. The hardcoded-IP design also prevents fast IP rotation and makes the BGP cutover fragile. Magic Firewall cannot distinguish legitimate UDP 27015 traffic from attack traffic on the same port.
Next steps: instrument game-server connection rates and add per-IP and per-account limits; publish a client update that connects to a hostname instead of literal IPs. Once clients use DNS, Northwind can use Spectrum or Cloudflare DNS for faster failover and can change origin IPs without a client release. Keep the /24 in Magic Transit for the hardcoded legacy clients during the transition, then retire that constraint.