What Is a DDoS Attack? Types, Protection & Mitigation
Learn how distributed denial-of-service attacks overwhelm networks and applications, how the three major attack classes differ, and how layered defenses keep legitimate users connected.
In This Lesson
Move from the basic DDoS traffic model to attack classification, layered controls, solution selection and a response plan your team can rehearse.
Quick Learning Map
A resilient design separates capacity, traffic decisions and recovery instead of expecting one device to solve every attack.
Absorb
Use upstream capacity, anycast or scrubbing infrastructure so a flood does not saturate the origin link.
Differentiate
Combine protocol validation, rate controls, bot signals and WAF logic to separate abusive traffic from real users.
Recover
Follow a tested runbook, protect essential services, communicate clearly and tune controls from captured evidence.
DDoS Protection at a Glance
The cheat sheet connects the attack path, three attack categories, matching controls and the strengths and limits of common mitigation options.
What Is a DDoS Attack and How Does It Work?
DDoS stands for Distributed Denial of Service. It is a malicious attempt to exhaust a server, network, website or API so legitimate users experience severe delay or complete unavailability.
A denial-of-service attack typically originates from one system. A distributed attack uses many sources, often compromised devices controlled as a botnet. The distribution increases available traffic and makes simple source blocking less effective.
Attacker
Chooses a target and directs compromised devices or distributed infrastructure to generate traffic.
Botnet or Traffic Sources
Send packets or requests from many addresses, networks and locations, sometimes with spoofed source information.
Target Service
Runs out of bandwidth, connection state, compute, memory, worker threads or another finite resource.
Three Main Types of DDoS Attacks
Real campaigns can combine multiple techniques, but these three categories help teams identify the exhausted resource and select an effective control.
1. Volume-Based Attacks
Large traffic volumes consume internet bandwidth or packet-processing capacity before requests reach the application.
- UDP floods
- ICMP floods
- Reflection or amplification traffic
- Spoofed-packet floods
Primary defense: upstream filtering, high-capacity scrubbing and routing controls that can handle the attack before the origin link fills.
2. Protocol Attacks
Crafted traffic abuses network or transport behavior and exhausts state tables, packet-processing resources or intermediary devices.
- SYN floods
- Fragmented-packet attacks
- Ping of Death variants
- Connection-state exhaustion
Primary defense: protocol validation, SYN protections, sane connection limits and filtering before traffic reaches constrained devices.
3. Application-Layer Attacks
Requests imitate normal users but repeatedly trigger expensive work in a website, API, database or software service.
- HTTP GET or POST floods
- Low-and-slow requests
- API endpoint abuse
- Requests aimed at expensive application paths
Primary defense: WAF rules, bot management, caching, behavioral analysis, request challenges and endpoint-specific rate controls.
Common DDoS Warning Signs
- An unexpected traffic jump that cannot be explained by a campaign, release or normal growth.
- Many requests share a suspicious pattern, target one resource or arrive from unusual networks or locations.
- Connection tables, CPU, memory, workers or bandwidth saturate while legitimate transactions fall.
- Users report intermittent timeouts, very high latency, 5xx responses or failures across multiple regions.
- Monitoring shows a sudden change in protocol mix, packet size, request rate or cache-miss behavior.
A single symptom does not prove an attack. Compare current behavior with a known baseline and check provider, routing, DNS, application and capacity telemetry before declaring the incident.
DDoS Protection Techniques: Match the Control to the Layer
| Attack pressure | Protection technique | Why it helps |
|---|---|---|
| Bandwidth exhaustion | Cloud scrubbing, anycast distribution, upstream ACLs and provider diversion | Moves filtering to infrastructure with enough capacity to absorb and clean a large flood. |
| Packet or protocol abuse | Protocol validation, SYN cookies or proxies, connection limits and IPS/IDS signals | Rejects malformed or abusive behavior before stateful resources become exhausted. |
| HTTP and API request floods | WAF, bot management, rate controls, caching and JavaScript or cookie challenges | Uses application context and client behavior to protect costly endpoints while retaining real users. |
| Origin exposure | Restrict origin access to trusted proxy ranges and protect DNS and management paths separately | Stops attackers from bypassing the mitigation layer and attacking the origin directly. |
| Operational confusion | Baselines, alerts, runbooks, provider contacts and exercises | Shortens detection and decision time while reducing risky, improvised changes during an incident. |
Anti-DDoS Solutions Compared
The right design depends on attack size, service criticality, traffic patterns, budget, deployment model and the time your team can tolerate before mitigation starts.
| Option | Strengths | Limits and best fit |
|---|---|---|
| Anti-DDoS software | Runs on existing platforms, can filter known behavior and is usually easy to deploy. | Local resources and the access link can still be overwhelmed. Best as one host or application control, not the entire defense. |
| Traditional firewall | Provides access control, protocol policy and blocking for known sources or signatures. | State tables and throughput are finite. It can become a bottleneck during large or legitimate-looking floods. |
| Web application firewall | Understands HTTP, APIs, paths, sessions and request behavior; can challenge suspicious clients. | Primarily protects the application layer and needs tuning. It cannot restore a saturated upstream link by itself. |
| Dedicated hardware appliance | Offers on-premises detection and fast local controls for attacks within appliance and circuit capacity. | Requires capital, skilled operation and upgrades; attacks can exceed appliance or circuit capacity, and off-path services such as DNS still need protection. |
| DDoS-ready hosting | Provides prebuilt capacity and operational support without owning the infrastructure. | Protection varies by provider and plan. Capacity alone does not guarantee intelligent application-layer mitigation. |
| Cloud DDoS mitigation | Scales across distributed scrubbing capacity and keeps malicious traffic away from the origin. | Requires correct routing or proxy integration, protected DNS and locked-down origins. Validate service scope, activation model and SLA. |
Traditional Firewall vs WAF for DDoS Protection
Traditional Firewall
Enforces network access and protocol policy. It is valuable for segmentation and known unwanted traffic, but high packet rates or connection counts can exhaust its state and throughput.
Web Application Firewall
Evaluates web requests with application context. A WAF can rate-limit, block bad bots and challenge uncertain clients before requests reach expensive application code.
Combined Design
Place high-capacity filtering upstream, use network controls at the edge and add WAF or API protection for Layer 7. Each control handles the signals and scale it understands best.
For a deployable application-security example, see the Haltdos Community WAF deployment guide. A WAF remains one layer and should not be presented as a substitute for upstream DDoS capacity.
Cloud-Based DDoS Mitigation and the Imperva Example
Cloud mitigation places detection and filtering outside the customer network so cleaner traffic reaches the protected hosts. A provider may combine global scrubbing, protocol defenses, bot detection, WAF controls and threat intelligence across websites, networks, individual public IPs and DNS infrastructure.
The supplied source describes Imperva cloud-based DDoS mitigation as an example of this model: traffic can be diverted through distributed scrubbing infrastructure, network and protocol attacks can be filtered before the origin, and application requests can be evaluated with bot and challenge mechanisms.
Environments That Need Separate Coverage
- Websites and APIs: protect application endpoints, sessions, authentication and expensive requests.
- Networks and subnets: defend public address space and network services against volumetric and protocol attacks.
- Individual public IPs: cover exposed on-premises or cloud services that do not sit behind a web proxy.
- Authoritative DNS: keep name resolution available so users can still locate protected services.
DDoS Prevention and Incident Response Checklist
1. Inventory Critical Services and Dependencies
List public applications, APIs, DNS zones, origin addresses, circuits, upstream providers and third-party dependencies. Define which service must remain available first.
Outcome: the response team knows what to protect and which hidden dependency could still take the service offline.
2. Establish Normal Traffic Baselines
Record ordinary bandwidth, packets per second, connections, requests per second, geographic mix, protocols, status codes and resource consumption.
Outcome: alert thresholds reflect real service behavior instead of one generic number.
3. Deploy Layered Controls
Combine upstream scrubbing or provider protection with edge policy, origin restrictions, WAF or API controls, bot management, caching and rate limits.
Outcome: an attacker must defeat multiple controls, and no single device carries the entire mitigation load.
4. Define Activation and Escalation
Document provider contacts, routing or DNS changes, required approvals, safe emergency thresholds, communications owners and rollback steps.
Outcome: the team can activate mitigation quickly without inventing the process during an outage.
5. Exercise, Observe and Improve
Run tabletop and technical tests, confirm logs and dashboards, measure time to detect and mitigate, then tune rules with false-positive and customer-impact evidence.
Outcome: the plan becomes a practiced operational capability rather than an unread document.
During an event, use an independent check such as the Website Down Checker to compare external reachability with internal monitoring. After recovery, preserve flow, firewall, WAF, application and provider telemetry for analysis.
DDoS Attack and Protection Frequently Asked Questions
What does DDoS stand for?
DDoS stands for Distributed Denial of Service. It describes a coordinated attempt to exhaust a service or network resource with traffic from many systems, making the service slow or unavailable to legitimate users.
What is the difference between DoS and DDoS?
A DoS attack is generally launched from one source, while a DDoS attack distributes traffic across many devices or connections, often a botnet. Distribution makes filtering and source blocking more difficult.
What are the three main types of DDoS attacks?
The three broad categories are volume-based attacks that consume bandwidth, protocol attacks that exhaust network or state-table resources, and application-layer attacks that overwhelm a website, API or software service with expensive requests.
Can a firewall stop a DDoS attack?
A firewall can block known unwanted traffic, but a traditional on-premises firewall may itself become a bottleneck during a large flood. Effective protection usually combines upstream capacity, scrubbing, rate controls, protocol defenses and application-layer filtering.
What is DDoS scrubbing?
DDoS scrubbing diverts traffic through high-capacity infrastructure that identifies and discards malicious packets, then forwards cleaner traffic to the protected service.
How should an organization prepare for a DDoS attack?
Inventory critical services, establish traffic baselines, deploy layered controls, confirm provider contacts and diversion procedures, define decision owners, test the response plan and preserve telemetry for tuning and investigation.