DDoS Protection Guide

A distributed denial of service (DDoS) attack can take a website, API, DNS service or network link offline without touching your data, and most organisations cannot absorb a large one on their own infrastructure. The UK NCSC defines denial of service as "an attempt to overload a website or network, with the aim of degrading its performance or even making it completely inaccessible." DDoS-for-hire services and volunteer hacktivist networks have made attacks cheap to launch, while the defences sit largely with upstream providers you must contract and rehearse with in advance. This guide is for network, platform and SRE teams, security operations and service owners. It explains attack types at concept level only, then covers upstream scrubbing, CDN and WAF, anycast, rate limiting, scaling costs, DNS resilience, runbooks and testing.

Key takeaways

• Plan for three attack layers. Volumetric floods saturate links, protocol attacks exhaust state in firewalls and servers, and application-layer attacks look like real users; each needs a different control.
• Capacity lives upstream. ISP scrubbing, CDNs and DDoS mitigation services absorb volumes no single data centre can, so the contract, routing and contacts must be in place before an attack.
• Hide and lock the origin. A CDN or scrubbing service only helps if attackers cannot reach the origin directly; accept traffic only from the provider.
• Autoscaling is not a defence on its own. The NCSC warns "Scaling up can be costly"; set spending limits and a graceful degradation threshold in advance.
• Rehearse the runbook. Attacks come in waves and change tactics. Named provider contacts, out-of-band admin access and a tested degraded mode decide how long you stay down.

How DDoS attacks work

The joint CISA, FBI and MS-ISAC guide (version 2.0, March 2024) sorts attacks into three categories and notes that "These categories are not mutually exclusive": attackers often combine them or switch between them mid-attack. MITRE ATT&CK places DoS under the Impact tactic (TA0040) as Network Denial of Service (T1498) and Endpoint Denial of Service (T1499).

Reflection and amplification

In a reflection attack the attacker spoofs the victim's IP address as the source of small requests to public servers, which send larger responses to the victim. As the CISA guide puts it, reflection attacks "typically originate from legitimate public servers", so blocking by source reputation is of limited use. Commonly abused UDP services include DNS (53), NTP (123), SNMP (161), CLDAP (389), SSDP (1900) and memcached (11211). Two defensive consequences follow:

• Do not be a reflector: close or restrict these services on your internet-facing hosts, run authoritative DNS with response rate limiting (RRL), and never expose open resolvers or memcached to the internet. See the Network Ports and Protocols Security Guide.
• Stop spoofing at source: NIST SP 800-189 notes that "technologies recommended for mitigating DoS/DDoS attacks focus on prevention of IP address spoofing", through source address validation (SAV) with ACLs and unicast Reverse Path Forwarding (uRPF), the practice known as BCP 38. If you run your own autonomous system, apply it at every customer and peering edge.

Application-layer attacks and protocol flaws

Layer 7 attacks use complete, often encrypted requests that resemble real users, so they pass network scrubbing that cannot see inside HTTPS. Protocol implementation flaws can amplify them: CISA reported that the HTTP/2 "Rapid Reset" flaw (CVE-2023-44487) was "exploited in the wild in August 2023 through October 2023" and advised operators to apply patches and consider configuration changes. Keep web servers, load balancers and reverse proxies patched, because a DDoS can exploit a single implementation bug as effectively as raw volume.

Who launches DDoS attacks

• DDoS-for-hire (booter or stresser) services: paid platforms that let people with little skill launch attacks. In April 2026 Europol's Operation PowerOFF action, involving 21 countries, took down 53 domains, made four arrests and sent 75,000 warnings to users; Europol called DDoS-for-hire "one of the most prolific and easily accessible trends in cybercrime."
• Hacktivist campaigns: politically timed attacks on government, transport, banking and energy sites. Operation Eastwood, coordinated by Europol and Eurojust on 15 July 2025, disrupted more than 100 servers used by the pro-Russian group NoName057(16), which crowdsourced attacks through volunteers running its DDoSia tool. Its targets included around 230 German organisations, Swedish sites during the European elections and Dutch sites around the June 2025 NATO summit. Reporting noted that with core members in Russia the disruption may be short-lived.
• Botnets: compromised routers, IoT devices and servers provide distributed capacity. In 2025 Trend Micro found the Flodrix botnet spreading through vulnerable AI workflow servers; once connected it "can receive commands over TCP to launch various distributed denial-of-service (DDoS) attacks". See the Langflow CVE-2025-3248 exploitation.
• Extortion and distraction: ransom demands backed by a demonstration attack, or floods timed to distract responders. Treat a demand as an incident, involve law enforcement, and do not assume paying stops attacks.

Upstream defences: scrubbing, CDN and anycast

The NCSC's guidance on upstream defences starts from a plain fact: attackers can often send more traffic than an organisation can absorb, so you will need providers.

• RTBH in detail: RFC 5635 describes destination-based RTBH, which discards everything addressed to the target prefix, and source-based RTBH, which combines BGP discard routes with uRPF to drop traffic from attacking sources. The RFC warns that source-based filtering "will drop all traffic to/from the address, and not just the traffic to the victim." NIST SP 800-189 also recommends Flowspec, which pushes finer-grained filters (protocol, port, packet length) to routers.
• Protect the origin: NCSC advises making sure the CDN "masks or 'cloaks' your site so that an attacker cannot discover the true origin", and considering ISP-level allow listing so only CDN traffic reaches your servers. Rotate origin IP addresses after onboarding, because old DNS records and certificates can reveal them.
• Trust the edge provider: a CDN that terminates TLS holds keys or certificates for your domains. The Imperva breach, in which a stolen AWS API key exposed Cloud WAF customers' keys and certificates, shows why that trust must be assessed.
• Watch for shared dependencies: multiple providers improve resilience only if they do not share the same backbone, data centre or cloud underneath.

Rate limiting, application hardening and scaling

Rate limiting and filtering

• At the edge: per-client request limits on expensive endpoints (login, search, checkout, report generation, GraphQL) rather than one global limit; NCSC notes CDNs can rate-limit specific URLs to protect back-end databases.
• Challenges, not just blocks: JavaScript or CAPTCHA challenges for suspicious clients during an attack, which the CISA guide lists among preparatory measures. See the Bot Management Guide.
• Protocol limits: enable SYN cookies on Linux servers and load balancers (net.ipv4.tcp_syncookies), set header and body timeouts that defeat slow requests, cap request and XML body sizes, and limit concurrent streams per HTTP/2 connection.
• Network ACLs: drop traffic to ports and protocols you do not serve at the upstream edge, and ask your ISP for port and packet size filtering, as MS-ISAC recommends during an attack. See the Firewall Management Guide.
• Cache aggressively: every request served from cache is one the origin never sees.

Autoscaling limits and cost

Scaling absorbs application-layer load that edge filtering misses, but the NCSC is explicit that "Scaling up can be costly" and that cloud services "can appear to have infinite capacity, they don't." It notes instance quotas that need manual increase requests, regional capacity differences, and providers who may throttle or terminate a service that affects others.

• Set maximum instance counts and budget alerts for internet-facing services, and decide in advance the threshold at which you degrade rather than scale.
• Check whether your provider credits scaling costs caused by an attack. AWS, for example, offers Shield Advanced customers "a limited refund of scaling-related costs", and does not charge for requests rejected at its CDN or WAF.
• Scale stateful tiers too: an elastic web tier in front of a fixed-size database simply moves the bottleneck.

Graceful degradation

The NCSC response plan guidance suggests prioritising access by source (for example by country), switching off resource-heavy dynamic features such as site search or recommendations, and restricting dynamic content to signed-in users, so the service "can continue to operate, albeit in a degraded fashion." Build these switches as feature flags and test them before you need them.

DNS resilience

DNS is both a common target and a single point of failure: if your authoritative DNS fails, every service behind it disappears.

• Use anycast authoritative DNS from a provider built to absorb floods, and consider a second provider on a separate network for critical zones, keeping zone data synchronised.
• Set TTLs deliberately: moderate TTLs let resolvers keep serving cached answers through a short outage, while short TTLs make emergency changes faster. Pre-stage records for scrubbing or failover so you are not editing zones under pressure.
• Keep admin access off the public zone: the NCSC warns that public DNS zones "are also likely to be targeted", so management access should not depend on them.
• Back up zone configuration held by third-party DNS providers. See the DNS Security Guide.

Where identity fits

The controls that stop a DDoS are run from provider consoles and APIs: CDN, DNS, registrar, scrubbing and cloud accounts. Whoever controls those accounts can disable protection or redirect traffic, which is worse than any flood.

• Protect provider admin accounts with phishing-resistant MFA through your SSO, and keep at least one tested emergency account per provider in case the identity provider itself is unreachable. See the Break-Glass Account Guide.
• Treat provider API tokens used by automation and infrastructure-as-code as privileged secrets: scope, vault and rotate them. See the API Key Management Guide.

Detection, response and the runbook

Detection and measurement

The CISA guide lists symptoms including service unavailability, network congestion, unusual traffic patterns, high resource use and alerts from a DDoS protection service. Baseline normal traffic so you can recognise them quickly.

• Telemetry: NetFlow or IPFIX at the edge (packets and bits per second by protocol and port), load balancer and CDN request rates and status codes, origin latency, connection table use on firewalls, and synthetic availability checks from outside your network.
• Metrics: time to detect (attack start to alert); time to mitigate (alert to traffic under control); availability of critical services during attacks against the target set in your business continuity plan; percentage of internet-facing services behind a CDN or scrubbing service; origins reachable directly from the internet (target: zero); and runbook test frequency.

Response runbook

1. Confirm and classify: distinguish an attack from a deployment fault or legitimate surge; identify layer, target and vector from flow and request data.
2. Activate the plan: open the incident, assign a lead, and start the communications plan for staff, customers and partners.
3. Call providers: contact the ISP, hosting, CDN or scrubbing provider on pre-agreed numbers; provide attacking addresses and ask about port and packet size filtering, as MS-ISAC advises.
4. Mitigate in layers: enable or divert to scrubbing, tighten rate limits and WAF rules, turn on challenges, and switch on degraded mode for expensive features. Use RTBH only to protect the wider network when one address cannot be saved.
5. Preserve evidence: timestamps, packet captures, flow records and logs, which the CISA guide lists for later analysis and reporting.
6. Watch for the next wave: NCSC warns attacks come in waves with new methods, so rotate staff rather than exhausting everyone on the first.
7. Report and review: in the US, report to the local FBI field office and CISA; in the UK, to the NCSC and Action Fraud as appropriate. Run a post-incident review and update the runbook. See the Incident Response Guide.

Rolling out DDoS protection

1. Understand your service: list internet-facing services, their dependencies (DNS, upstream links, third-party APIs, payment providers) and their acceptable downtime. NCSC's first practice is "understand your service" for this reason.
2. Assess current provider coverage: ask each ISP, hosting and cloud provider what is included, what costs extra, and the NCSC's questions: is mitigation automatic, will they throttle, bill for excess, sinkhole or terminate, and how quickly can service be restored?
3. Close the easy gaps: remove reflectors, apply BCP 38 if you run your own network, enable SYN cookies, patch web servers and proxies, and add caching.
4. Onboard web services to a CDN and WAF: start rate limits and new WAF rules in log-only or count mode, review for false positives for one to two weeks, then enforce. Roll back by returning a rule to count mode rather than deleting it.
5. Lock down origins: accept only provider address ranges or authenticated tunnels, then rotate origin addresses.
6. Contract network scrubbing for non-web services and prefixes, test the diversion path and confirm return routing.
7. Write and rehearse the runbook with providers on the call, including degraded mode switches and out-of-band admin access.
8. Test under agreement: run DDoS simulations only with written approval from every provider in the path, at agreed times, using a reputable testing service; many providers publish testing policies. Repeat after major architecture changes.

Framework mapping

Common failure patterns

• Origin left exposed: the CDN is in place but the origin still answers on its public address, so attackers simply go around it.
• Protection bought, never tested: on-demand scrubbing that has never been activated fails on the day because of routing, prefix size or return path problems.
• Unbounded autoscaling: a long Layer 7 attack becomes a large cloud bill, or hits an instance quota at the worst moment.
• Single DNS provider with no fallback: an attack on the provider or the zone takes down every service, including the admin portals needed to respond.
• Provider contacts in the attacked system: numbers and escalation paths stored only on the intranet or in email that is unreachable during the incident.
• Running reflectors: open resolvers, NTP or memcached on your own address space that attackers use against others, and which upstream providers may block.

Practitioner checklist

• Inventory internet-facing services, dependencies and acceptable downtime.
• Confirm with each ISP and provider what DDoS mitigation is included, its triggers, costs and contacts.
• Put web and API services behind a CDN with WAF and per-endpoint rate limits, and lock the origin to the provider.
• Contract network scrubbing for non-web services and test the diversion path.
• Run authoritative DNS on anycast, with a second provider for critical zones.
• Set autoscaling maximums, budget alerts and a graceful degradation threshold.
• Remove reflectors from your address space and apply source address validation.
• Protect CDN, DNS and registrar accounts with phishing-resistant MFA and emergency access.
• Maintain an offline runbook with provider numbers and rehearse it at least annually.

Standards and references

• CISA, FBI and MS-ISAC: Understanding and Responding to Distributed Denial-of-Service Attacks
• NCSC: Denial of Service (DoS) Guidance
• NIST SP 800-189: Resilient Interdomain Traffic Exchange, BGP Security and DDoS Mitigation
• IETF RFC 5635: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)
• MITRE ATT&CK: Network Denial of Service (T1498)
• MITRE ATT&CK: Endpoint Denial of Service (T1499)
• CISA: HTTP/2 Rapid Reset Vulnerability, CVE-2023-44487
• AWS: Best Practices for DDoS Resiliency, Mitigation Techniques

Related NHI Mgmt Group resources: DNS Security Guide · Bot Management Guide · Business Continuity and Disaster Recovery Guide · Incident Response Guide