The 3 Main Types of DDoS Attacks
A distributed denial of service (DDoS) attack floods a target system with traffic or requests from multiple sources, making services unavailable to legitimate users. Unlike a simple denial of service (DoS) attack that originates from a single source, DDoS attacks coordinate traffic from hundreds or thousands of distributed sources (typically compromised devices forming a botnet) making them far harder to block by filtering individual IP addresses.
DDoS attacks are commonly categorized using the OSI model, which is a framework that describes how data moves through networks in seven layers. Based on which layer they target, DDoS attacks fall into three main categories:
Layer 3/4 (Network/Transport): Volumetric attacks that saturate bandwidth capacity
Layer 3/4 (Network/Transport): Protocol/state-exhaustion attacks that deplete connection-handling resources
Layer 7 (Application): Attacks that drain application and workload resources
| Category | OSI Layer | Goal | Common Examples | Detection Signals | First-Line Mitigations |
|---|---|---|---|---|---|
| Volumetric | L3/L4 | Saturate bandwidth | UDP flood, DNS amplification, ICMP flood | Gbps spike, traffic from spoofed IPs | Anycast CDN, upstream scrubbing, rate limiting |
| Protocol/State-Exhaustion | L3/L4 | Exhaust connection tables | SYN flood, fragmentation attacks | PPS spike, half-open connections | SYN cookies, connection timeouts, stateful firewall tuning |
| Application-Layer | L7 | Drain application resources | HTTP flood, Slowloris, ReDoS | RPS spike, thread exhaustion, CPU anomalies | WAF rules, request rate limiting, behavioral analysis |
Each category impacts different resources, triggers different failure modes, and requires different detection and mitigation strategies. A volumetric attack might saturate your network pipe, while an application-layer attack could exhaust your web server threads without generating unusual bandwidth metrics. Modern attackers frequently combine multiple types into multi-vector attacks that overwhelm defenses at more than one layer simultaneously.
Understanding these distinctions matters because the defense that stops a UDP flood won't help against a Slowloris attack. Security teams need visibility across all three layers to detect and respond effectively.
Watch 5-minute demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
Watch now
Volumetric DDoS Attacks (Layer 3)
Volumetric attacks aim to saturate available network bandwidth, preventing legitimate traffic from reaching the target. These attacks work by flooding the network connection with so much data that nothing else can get through. Think of it like trying to drink from a fire hose: the sheer volume makes normal use impossible.
Security teams measure volumetric attacks in gigabits per second (Gbps). These attacks are typically the easiest to detect because traffic spikes are obvious in monitoring dashboards. They remain common because botnets (networks of compromised computers) are widely available for rent on underground markets.
While loud and visible, volumetric attacks may cause less availability impact against well-fronted cloud services, but actual protection depends on service tier, regional capacity, and architecture design. Attacks now reach unprecedented scales like the 31.4 Tbps attack recorded in late 2025. Even when availability holds, cost escalation and downstream saturation often become the primary failure modes, especially when auto-scaling or pay-per-request services activate during an attack.
UDP Flood Attacks
A UDP flood attack exploits the connectionless design of the User Datagram Protocol (UDP). Unlike TCP, UDP doesn't require a handshake before sending data, which means attackers can send massive volumes of packets without establishing connections first. The attacker sends UDP packets to random ports on the target, forcing the server to check for listening applications and respond with "destination unreachable" messages.
Common targets include DNS services, gaming servers, and streaming platforms because these services legitimately use UDP. Detection relies on identifying sudden spikes in UDP traffic, packets sent to unused ports, and spoofed or randomized source IP addresses. When your monitoring shows thousands of UDP packets hitting closed ports from IPs that don't respond to verification, you're likely seeing an attack rather than legitimate traffic.
ICMP Flood Attacks
ICMP flood attacks, often called ping floods, overwhelm targets with ICMP echo request packets. ICMP (Internet Control Message Protocol) is the protocol behind the "ping" command used to test network connectivity. Attackers abuse this by sending echo requests faster than the target can process them.
Some variants include fragmented packets to increase processing cost on the receiving end. Reassembling packet fragments consumes CPU and memory resources. While basic ICMP floods are relatively simple, they remain effective against poorly protected endpoints that don't rate-limit ICMP traffic.
DNS Amplification Attacks
DNS amplification attacks use reflection and amplification to multiply traffic volume dramatically. The attacker sends small DNS queries to open DNS resolvers, but spoofs the source IP address to match the victim's address. The DNS servers then send their responses, which are much larger than the queries, to the victim.
A 60-byte query can generate a 4,000-byte response, creating a 70x amplification factor. Open DNS resolvers on the internet remain a persistent risk because they respond to queries from any source. Defenders combat DNS amplification by advocating for BCP38 (network ingress filtering) adoption at upstream ISPs and hosting providers to reduce IP spoofing, and by coordinating with network operators to identify and close open DNS resolvers that attackers exploit for amplification.
Typical Mitigations for Volumetric Attacks:
Deploy Anycast-based CDN (Cloudflare, AWS CloudFront, Akamai) to distribute traffic globally
Enable upstream scrubbing services (AWS Shield Advanced, Azure DDoS Protection Standard)
Configure rate limiting at network edge before traffic reaches origin servers
Implement geographic filtering if legitimate traffic patterns are regionally predictable
Set up cost alerts and scaling limits to prevent runaway cloud bills during attacks
Protocol DDoS Attacks (Layer 4)
Protocol attacks focus on exhausting connection-handling resources rather than bandwidth. These attacks target the mechanisms that servers, firewalls, and load balancers use to manage network connections. Security teams measure protocol attacks in packets per second (PPS) because the goal is overwhelming connection tables, not saturating bandwidth.
Protocol attacks can cause outages with relatively modest traffic volumes. A server that handles 10 Gbps of legitimate traffic might crash from a 500 Mbps SYN flood because its connection table fills up before bandwidth becomes the limiting factor. This makes protocol attacks particularly dangerous for organizations that focus solely on bandwidth-based DDoS mitigation.
SYN Flood Attacks
SYN flood attacks abuse the TCP three-way handshake that establishes connections between clients and servers. Normally, a client sends a SYN packet, the server responds with SYN-ACK, and the client completes the handshake with an ACK. Attackers send massive numbers of SYN packets but never send the final ACK, leaving connections half-open.
Each half-open connection consumes server memory until it times out. Servers have limited space for tracking pending connections, and once that fills up, they can't accept new legitimate connections. Common mitigation includes SYN cookies, a technique where servers encode connection state in the response rather than storing it locally. However, attackers continue adapting with techniques like randomizing source ports and using legitimate-looking IP addresses.
Ping of Death and Fragmentation Attacks (Legacy L3/L4)
Ping of Death attacks use malformed or oversized packets that exceed the maximum allowed IP packet size of 65,535 bytes. When the target system attempts to reassemble these oversized fragmented packets, buffer overflows or crashes can occur. These attacks exploit implementation flaws rather than protocol design issues.
Most modern operating systems have patched the original Ping of Death vulnerability, but variants still appear targeting specific applications or network equipment. Fragmentation attacks more broadly exploit how systems handle packet reassembly, consuming memory and CPU resources even when they don't cause crashes.
Smurf and Fraggle Attacks (Legacy Reflection/Amplification)
Smurf attacks use broadcast addresses for reflection, sending ICMP echo requests to a network's broadcast address with the victim's spoofed source IP. Every device on that network responds to the victim simultaneously, amplifying the attack. Fraggle attacks work similarly but use UDP echo services instead of ICMP.
These attacks were historically common but are largely mitigated today because network administrators disable directed broadcast forwarding. However, the reflection and amplification principles live on in modern attacks that use other protocols like NTP, SSDP, and memcached for similar effects.
Typical Mitigations for Protocol Attacks:
Enable SYN cookies on web servers and load balancers to handle half-open connections without state exhaustion
Configure aggressive connection timeouts (reduce TCP TIME_WAIT, lower SYN-RECEIVED timeout)
Deploy stateful firewalls with connection table limits and automatic cleanup
Use cloud-native load balancers that handle connection state at scale (AWS NLB, Azure Load Balancer)
Monitor packets-per-second (PPS) metrics alongside bandwidth to catch state-exhaustion attacks
Application-Layer DDoS Attacks (Layer 7)
Application-layer attacks aim to exhaust application or workload resources using traffic that appears legitimate. Instead of flooding networks with garbage packets, these attacks send valid HTTP requests, API calls, or database queries that consume server processing power, memory, or application threads.
Security teams measure application-layer attacks in requests per second (RPS). These attacks are the hardest to detect using network-only tools because the traffic looks normal at layers 3 and 4, requiring application-layer detection capabilities. A single HTTP GET request is indistinguishable from a legitimate user visit when examined at the packet level. Application-layer attacks are increasingly favored as network defenses improve because they bypass traditional DDoS mitigation focused on volumetric and protocol attacks, with L7 attacks rising 74% year-over-year in Q2 2025.
L7 DDoS becomes most dangerous when it combines with other risk factors: a public endpoint (exposure), backend service account privileges (access), and reachable sensitive data (impact). An HTTP flood against a public marketing page differs fundamentally from the same attack against an authenticated API that queries customer databases with elevated permissions. Understanding these combinations helps security teams prioritize which endpoints need the strongest L7 protections.
HTTP Flood Attacks
HTTP flood attacks overwhelm web servers with valid GET or POST requests. The attacker's goal is consuming server resources like CPU, memory, and backend database connections rather than network bandwidth. Each request triggers legitimate processing: the server parses the request, queries databases, generates dynamic content, and sends responses.
These attacks bypass volumetric defenses by mimicking normal user behavior. An HTTP flood might generate only a few hundred megabits of traffic while bringing down servers designed to handle gigabits. Detection requires behavioral analysis to distinguish attack traffic, such as identifying clients that request pages far faster than humans could browse or patterns of requests that don't match typical user journeys.
Slowloris and Slow-Rate Attacks
Slowloris attacks hold connections open using incomplete HTTP requests. The attacker opens multiple connections to a web server and sends partial HTTP headers, then periodically sends additional header data to keep connections alive but never completes the requests. The server keeps each connection open waiting for the request to finish.
Because web servers have limited concurrent connection pools, Slowloris can exhaust available connections with minimal bandwidth. A single attacking machine can take down a vulnerable server because the attack consumes server threads rather than network capacity. These "low and slow" attacks are particularly dangerous because they often fly under detection thresholds designed for high-volume attacks.
ReDoS (Regular Expression Denial of Service)
ReDoS attacks exploit inefficient regular expression processing in application code. Regular expressions (regex) are patterns used to match text, and certain regex patterns have exponential worst-case processing time. An attacker who identifies vulnerable regex can craft input that triggers this worst-case behavior.
A single malicious request containing specially crafted input can consume excessive CPU time, potentially hanging the application thread for minutes. This represents a code-level DoS vulnerability rather than a network attack. Defenders must audit application code for regex patterns with nested quantifiers or alternation that create backtracking vulnerabilities.
Typical Mitigations for Application-Layer Attacks:
Deploy Web Application Firewall (WAF) with rate limiting rules (AWS WAF, Azure WAF, Cloudflare)
Implement request rate limiting per IP, per session, and per API endpoint
Use CAPTCHA challenges for suspicious traffic patterns
Configure connection limits and request timeouts at the application layer
Enable behavioral analysis to distinguish bot traffic from legitimate users
Audit application code for ReDoS-vulnerable regex patterns using static analysis tools
How Wiz Helps Detect and Respond to DDoS-Related Threats
Wiz strengthens cloud resilience against DoS and DDoS attacks by combining workload-level detection with proactive attack surface reduction. While WAFs, CDNs, and native cloud DDoS services such as AWS Shield, Azure DDoS Protection, and Google Cloud Armor handle network-layer traffic filtering, Wiz complements them by detecting the impact and payload of DoS activity inside cloud workloads.
Wiz Defend, powered by Wiz Sensor, identifies high-severity System Health Issues such as resource exhaustion, connectivity loss, and anomalous runtime behavior that may indicate a DoS attack. Its Detection Engine uses threat detection rules and behavioral baselines to surface suspicious activity, and teams can create custom runtime rules to detect specific DoS-related payload patterns before they escalate.
At the same time, Wiz Attack Surface Management (ASM) helps prevent DDoS exposure by identifying exploitable misconfigurations, weak credentials, and vulnerabilities in internet-facing assets. By reducing exposed entry points and detecting workload-level impact, Wiz adds critical visibility and context that strengthens your overall DDoS defense strategy.
Get a demo to see how Wiz connects cloud configuration, workload behavior, and runtime context to investigate DDoS activity, identify what's actually at risk, and prioritize what to fix first.