DDoS Against a Public Network API Gateway
A communications service provider exposes 5G network APIs (SIM swap status, device location, QoS on demand) through a public API gateway. During a marketing campaign, a 300 Gbps UDP reflection flood and a 2.5 Mpps SYN flood hit the gateway’s /24. The provider has a 500 Gbps scrubbing center but diverts traffic by announcing a more specific /24 over BGP. The backbone link to the internet is 2×100G, and the gateway also serves enterprise VPN customers. When the /24 is diverted, collateral damage appears: DNS for other services in the same /24 fails, and API latency rises to 4 s. The security team proposes RTBH for the gateway IPs. You must keep the API available and avoid taking down neighboring services.
1. Why is RTBH a poor first action here, and what mitigation sequence would you use?
Read the worked answer
RTBH drops all traffic to the target IPs, including legitimate API customers and enterprise VPN users. It converts a volumetric attack into a self-inflicted outage and does not distinguish attack traffic from valid sessions. Because the gateway shares a /24 with other services, a broad RTBH or prefix announcement can also affect DNS and neighboring customers.
My sequence is: (1) confirm the attack vector and affected destination ports with flow telemetry; (2) apply upstream BGP Flowspec or ACLs to rate-limit or drop the UDP reflection and SYN patterns at the border; (3) divert only the affected service prefixes to the scrubbing center, not the whole /24; (4) enable SYN cookies and API gateway rate limits; (5) keep legitimate traffic on a separate announcement or anycast path if available. RTBH is a last resort for a single host that is already beyond saving, not the first move for a revenue API.
2. How would you use BGP Flowspec and more-specific announcements to protect the API without collateral damage?
Read the worked answer
Use Flowspec to match the attack’s actual five-tuple behavior: UDP reflection source ports and destination port, packet length, fragment flags, and the SYN flood’s destination port and TCP flags. Set actions to drop or rate-limit at the border, or redirect the matching traffic to a scrubbing VRF. Keep the rule as narrow as possible so normal API and VPN traffic is not caught.
For diversion, announce more-specific prefixes for the API gateway addresses or service VIPs, not the entire /24. If the gateway uses separate IPs for API and DNS/VPN, move only the API VIPs. Ensure the more-specific is authorized in IRR/RPKI and that the scrubbing center returns clean traffic over a separate path. Monitor clean traffic and collateral prefixes; if DNS in the same /24 is affected, split the service addressing or use a separate prefix before the next campaign. This preserves nearby services and keeps the API reachable through scrubbing.
3. What architectural changes reduce recurrence and improve resilience?
Read the worked answer
Separate public API endpoints from shared enterprise and DNS prefixes, so a future diversion or blackhole cannot take down unrelated services. Put the API behind an anycast front end with distributed DDoS scrubbing and a CDN/WAF layer for application-layer attacks. Enforce per-customer and per-token rate limits, mTLS, and quotas at the gateway so a SYN or request flood is absorbed before it reaches origin.
Operationally, pre-provision Flowspec templates, scrubbing announcements, and runbooks with the upstream provider; test them in a game day. Add always-on telemetry for pps, bandwidth, new-connection rate, and API error rate, with automatic thresholds that trigger only the narrow mitigation. Finally, review the API exposure model: SIM swap and location APIs should have strong authorization and consent controls, because availability is not the only risk.