DDoS Resource Center
Learn and Mitigate DDoS Attacks
A distributed denial-of-service attack attempts to make a website, API, network, or online service unavailable by overwhelming bandwidth, network state, or application resources. This guide explains how attacks work, what to prepare before an incident, and how to respond when traffic turns hostile.
Fast Readiness Snapshot
- Main attack classes
- Volumetric, protocol, application layer
- Best first control
- Upstream or edge filtering before origin
- Common weak point
- Exposed origin IPs and expensive app routes
How DDoS attacks work
DDoS attacks work by coordinating many traffic sources or reflected services against one target. The goal is not usually to break in, but to make legitimate use impossible by exhausting capacity somewhere in the delivery path.
Volumetric attacks
Flood links, transit, CDN capacity, or upstream bandwidth with traffic volume. UDP floods, DNS amplification, NTP amplification, SSDP amplification, and reflection attacks fit here.
Signals: Bandwidth spikes, packet-per-second surges, upstream saturation, many spoofed or reflected sources.
Protocol attacks
Exploit behavior in network and transport protocols to exhaust firewalls, load balancers, connection tables, or server networking stacks.
Signals: SYN floods, fragmented packets, abnormal TCP state, high connection setup rates, device CPU spikes.
Application-layer attacks
Target expensive application paths such as login, search, checkout, APIs, cache misses, file generation, or database-heavy requests.
Signals: HTTP request bursts, low bandwidth but high origin load, abnormal user agents, cache bypasses, slow requests, API abuse.
DDoS mitigation layers
The strongest DDoS programs use layered controls. No single firewall rule protects every service, and mitigation works best when traffic is filtered before it reaches a fragile origin.
Anycast CDN or edge network
Put public websites and APIs behind a provider that can absorb traffic globally before it reaches your origin.
Always-on DDoS protection
Use always-on protection for critical services so detection and filtering begin immediately instead of during a manual escalation.
Origin shielding
Restrict origin access to trusted CDN, WAF, load balancer, VPN, or provider IP ranges so attackers cannot bypass the edge.
WAF and rate limiting
Protect application paths with rate limits, bot controls, managed rules, positive security models, and route-specific thresholds.
Capacity and redundancy
Use load balancing, autoscaling, queueing, caching, failover DNS, and multi-region architecture where business risk justifies it.
Network hardening
Close unused services, disable unnecessary UDP exposure, tune connection limits, and keep firewalls/load balancers sized for attack conditions.
Pre-attack readiness checklist
- Inventory public IPs, DNS records, exposed ports, cloud load balancers, CDN zones, APIs, VPN endpoints, mail services, and third-party dependencies.
- Confirm which provider owns mitigation for each layer: ISP, cloud, CDN, DNS, WAF, hosting provider, application team, and incident response lead.
- Keep emergency contacts, escalation paths, support-plan details, portal access, and provider runbooks available outside the affected network.
- Baseline normal traffic by bandwidth, packets per second, requests per second, status codes, top URLs, countries, ASNs, user agents, and cache hit ratio.
- Pre-stage rate limiting, WAF custom rules, bot controls, maintenance pages, cache rules, origin allowlists, and emergency DNS or routing changes.
- Practice decision points: when to challenge traffic, block regions, disable expensive features, fail over, contact the ISP, or invoke emergency mitigation.
Active DDoS response playbook
1. Confirm scope
Identify impacted hostnames, IPs, protocols, regions, user journeys, and whether the bottleneck is upstream bandwidth, edge, firewall, origin, app, database, or dependency.
2. Classify the attack
Separate volumetric, protocol, and application-layer symptoms. The mitigation path changes depending on whether traffic is saturating links, state tables, or application resources.
3. Engage providers early
Open high-priority tickets with CDN, cloud, ISP, hosting, DNS, and DDoS mitigation vendors. Share timestamps, targets, traffic graphs, sample logs, and business impact.
4. Protect the origin
Ensure traffic reaches the origin only through approved edge or provider networks. Rotate exposed origin IPs if they have been directly targeted and cannot be safely filtered.
5. Reduce expensive work
Cache static and anonymous pages, block cache-busting patterns, disable costly search/export/report routes, lower timeout values, and queue noncritical tasks.
6. Apply narrow controls
Use rate limits, challenges, ACLs, ASN/country filters, bot rules, and route-specific WAF rules. Prefer narrow controls that preserve legitimate users where possible.
7. Communicate status
Update internal stakeholders and customers with impact, mitigations, and expected next updates. Keep incident notes with exact times and rule changes.
8. Recover and review
Remove emergency blocks carefully, compare post-attack baselines, preserve logs, review costs, update runbooks, and close gaps before the next event.
What to monitor during an attack
- Traffic volume: bandwidth, packets per second, requests per second, and connection attempts.
- HTTP health: status codes, origin latency, cache hit ratio, top URLs, top methods, and user-agent concentration.
- Network health: SYN rates, UDP flows, fragmented packets, firewall drops, load balancer saturation, and connection table usage.
- Source patterns: country, ASN, IP reputation, hosting networks, open resolvers, proxies, user agents, and request fingerprints.
- Application pressure: CPU, memory, workers, queue depth, database connections, slow queries, lock contention, and error budgets.
- Business impact: checkout failures, login failures, API error rate, support tickets, abandoned transactions, and SLA/SLO burn rate.
Choosing a DDoS protection provider
Evaluate providers against the services you actually operate. A CDN-only plan may protect websites but not DNS, mail, VPN, game servers, custom TCP/UDP services, or exposed origin IPs.
Hardening by layer
DNS
Use resilient authoritative DNS, short documented failover procedures, DNSSEC where appropriate, and avoid exposing origin records in historical DNS.
CDN and cache
Cache static assets aggressively, cache anonymous pages when safe, protect cache keys, and prevent query-string cache bypass from expensive routes.
Application
Add route-specific rate limits, request body limits, authentication throttles, idempotency, queue backpressure, and circuit breakers for costly dependencies.
Network
Restrict management ports, remove unused services, apply provider security groups, tune SYN protection, and ensure load balancers are not single bottlenecks.
Operations
Store runbooks, credentials, provider contacts, and communication templates where responders can reach them even when the main site is down.
Legal and reporting
Preserve logs, attack timelines, support case numbers, and traffic evidence for insurance, law enforcement, customer reporting, and lessons learned.
Trusted DDoS learning resources
DDoS FAQs
What is a DDoS attack?
A distributed denial-of-service attack uses many sources to overwhelm a server, service, application, network, or supporting provider so legitimate users cannot reach it reliably.
What is the difference between DoS and DDoS?
A denial-of-service attack may come from one source. A distributed denial-of-service attack uses many machines, networks, or reflected sources, which makes filtering and attribution harder.
Can a firewall stop DDoS attacks?
A firewall can help with some protocol and application controls, but a large volumetric attack can saturate the connection before traffic reaches the firewall. Upstream or edge mitigation is often required.
Should small websites use DDoS protection?
Yes, if downtime matters. Even small sites can use a CDN, WAF, caching, rate limiting, and origin access restrictions to reduce risk at relatively low cost.
How do I know if traffic is a DDoS attack?
Look for abnormal traffic spikes, unavailable services, high error rates, unusual source concentration, repeated expensive requests, saturated links, and exhausted application or network resources.
What should I do during an active DDoS attack?
Confirm scope, classify the attack type, contact providers, protect the origin, apply narrow edge controls, reduce expensive application work, communicate status, and preserve evidence.