Volumetric, protocol and application DDoS: where each is stopped

Can a firewall stop a DDoS attack? It depends on which kind. Some fill the internet link before a single packet reaches the firewall. Some fill a connection table. Some send perfectly valid requests until the application can't keep up. Each kind runs out a different resource, so each one has to be stopped somewhere different.

This post follows the three-way split in the CISA, FBI and MS-ISAC guide Understanding and Responding to Distributed Denial-of-Service Attacks (March 2024), and uses the RFCs and advisories behind each mechanism to explain how it works.

                ISP/scrub       firewall       WAF              
                    ┆               ┆           ┆       ┌──────┐
                    ┆               ┆           ┆       │server│
 UDP :123 replies   ┆               ┆           ┆       │      │
 ●≈─────≈─≈─≈──────≈✕───────────────────────────────────│      │
                    ┆               ┆           ┆       │      │
 volumetric: fills the link         ┆           ┆       │      │
                    ┆               ┆           ┆       │      │
 SYN, never ACK     ┆               ┆           ┆       │      │
 ──────s───s─────s───s─────s──s─────✕───────────────────│      │
                    ┆               ┆           ┆       │      │
 protocol: fills the SYN backlog    ┆           ┆       │      │
                    ┆               ┆           ┆       │      │
 GET /login x1000   ┆               ┆           ┆       │      │
 ─g─g────────────gg───────g──────────────────g──✕───────│      │
                    ┆               ┆           ┆       │   ●  │
 application: fills app CPU         ┆           ┆       └──────┘
 drop each flood before the resource it fills                   

How is DDoS different from DoS?

By the number of sources. CISA defines a DoS attack as using a single source, typically one computer or a small number of computers. A DDoS attack uses many, often a botnet of compromised machines all sending at once.

The goal is the same: make the system unavailable. A DDoS can generate far more traffic, and because it comes from so many addresses, it's difficult to trace and effectively block the attacking IP addresses, more so when IP spoofing is added.

What are the types of DDoS?

CISA uses three (CISA, 2024):

The guide adds that the categories are not mutually exclusive; one attack can mix them.

How does a volumetric attack work?

It sends more traffic than the link or system can carry. The aim is to saturate the network or exhaust the target's resources, so legitimate requests can't get through.

Here is the part that matters for defenders. Say the link from your ISP is 1 Gbps (an example figure) and 5 Gbps arrives. The excess is dropped on the ISP side, before it reaches anything you own. Your firewall can drop every packet that does make it through, but it can't give you back link capacity: those packets have already used it.

Most volumetric attacks today rely on reflection and amplification, covered next.

What are reflection and amplification?

Reflection means sending requests to someone else's server with the source IP forged to be the victim's, so the server's replies go to the victim. Amplification means choosing requests whose replies are much larger than the requests. Combined, a small amount of attacker traffic becomes a large amount at the victim.

It works over UDP because UDP is a connection-less protocol that does not validate source IP addresses (CISA Alert TA14-017A). Here is one made-up exchange, using the documentation ranges from RFC 5737:

attacker sends: src 203.0.113.10:443  ->  dst 198.51.100.7:123   UDP  NTP request   (source forged to the victim)
NTP server:     src 198.51.100.7:123  ->  dst 203.0.113.10:443   UDP  large reply   (goes to the victim)

The size gain is the bandwidth amplification factor (BAF): the UDP payload bytes an amplifier sends in reply, compared with the UDP payload bytes of the request. Some values from the TA14-017A table:

By that definition, a 50-byte request payload sent to an NTP server with a BAF of 556.9 produces about 27,845 bytes at the victim (the 50 bytes is just a number to work with). MITRE ATT&CK lists the technique as T1498.002 Reflection Amplification and calls the abused server a reflector.

How does a SYN flood stop new connections?

It sends a stream of SYNs that will never be followed by an ACK, until the backlog of half-open connections is full and real connections are refused. RFC 4987 is specific: the attack does not attempt to overload the network's resources or the end host's memory, but merely attempts to exhaust the backlog of half-open connections for a port.

On the server it looks like this:

client (spoofed IP)               server (port 443, LISTEN)
SYN  ---------------------------> moves to SYN-RECEIVED, allocates a TCB
     <--------------------------- SYN-ACK  (to the spoofed address; nobody answers)
     (no ACK ever comes)            TCB sits in the backlog until it times out

RFC 4987 gives typical default backlogs as a half-dozen to several dozen, and a reclaim timer of 75 seconds as one example. So the attacker only has to send SYNs faster than the host frees slots. The RFC also notes the attack does not impact outgoing connection requests, nor previously established connections; only new inbound connections to that port suffer.

For defence, RFC 4987 concludes that the SYN cache and SYN cookie approaches seem to be the only viable techniques found so far. SYN cookies keep no state when the SYN arrives; they encode what's needed into the SYN-ACK sequence number and rebuild it from the returning ACK. On Linux, net.ipv4.tcp_syncookies defaults to 1, which means send out syncookies when the syn backlog queue of a socket overflows. A firewall can also help: RFC 4987 describes how to offload the connection establishment procedures onto a firewall that screens connection attempts (section 3.8).

CISA's DDoS Quick Guide puts SYN floods at Layer 4 and ICMP floods at Layer 3, where it recommends rate-limiting ICMP.

How is an application-layer attack different?

It sends requests that are valid at the protocol level, either in large numbers or chosen to be expensive, until the server's CPU or the application gives out. CISA puts it this way: instead of overwhelming the network or system resources, application layer attacks exploit weaknesses in the targeted application.

The DDoS Quick Guide lists HTTP GET and POST floods, such as repeated login or upload form submissions. It also notes that for HTTPS GET and POST floods it is necessary to decrypt the requests in order to mitigate the flood. A device that doesn't decrypt only sees many TLS connections, not what's inside them.

A recent example is HTTP/2 Rapid Reset (CVE-2023-44487), which CISA says was exploited in the wild in August 2023 through October 2023. Google's write-up explains the mechanism: the client sends a request and immediately cancels it with RST_STREAM. The server has already started work, but cancelled streams don't count against the concurrent stream limit, so the attacker never exceeds the limit on the number of concurrent open streams while sending requests nonstop. Google's advice is to close the whole TCP connection when this abuse is detected, since blocking single requests isn't enough, and to patch HTTP/2 implementations.

Where is each type stopped?

Before the resource it exhausts. A summary from the CISA documents and RFC 4987:

One caveat on blackholing: the Quick Guide notes it makes the site in question completely inaccessible to all traffic, both malicious attack traffic and legitimate user traffic. ISPs use it to protect their other customers. The targeted site stays down; the damage just doesn't spread.

My view: a DDoS plan needs all three layers, and the conversation with your ISP or mitigation provider has to happen before the day you need it. A volumetric attack can't be solved from inside your own network.

What should you do during an attack?

Start the incident response plan and call your ISP or hosting provider. CISA's response steps, in order (CISA):

1. Confirm it's a DDoS with network monitoring and traffic analysis.
2. Activate the incident response plan.
3. Notify the ISP or hosting provider.
4. Gather evidence: timestamps, IP addresses, packet captures, logs.
5. Filter at firewalls or IPS with rate limits or ACLs.
6. Turn on DDoS mitigation services if you have them.
7. Scale up bandwidth and resources if you can.
8. Use a CDN.

The guide also repeats three MS-ISAC tips that matter for reflection: give the attacking IPs to your ISP; remember that reflection attacks typically originate from legitimate public servers; and ask the ISP for port and packet-size filtering. The middle one is easy to miss. During a reflection attack, the source IPs in your logs belong to other people's DNS or NTP servers, and blocking them permanently can cut off services you depend on.

How do you keep your network from being used as a reflector or a spoofing source?

Turn off UDP services you don't need, and don't let packets with source addresses that aren't yours leave your network. TA14-017A recommends that operators disable and remove unwanted services, or deny access to local services over the internet, keep software and configuration updated to limit abuse (DNS response rate limiting, for example), and apply ingress filtering per BCP 38.

BCP 38 is RFC 2827 (May 2000). Its example is an ISP router that allows only traffic originating from source addresses within the 204.69.207.0/24 prefix, the prefix assigned to the network behind it. Anything else is dropped. If every network did this, spoofed packets couldn't leave their origin network, and reflection depends on spoofed packets. RFC 4987 calls this kind of filtering perfectly effective but warns end hosts not to rely on it, because nothing guarantees every network deploys it.

Sources

• CISA, FBI, MS-ISAC: Understanding and Responding to Distributed Denial-of-Service Attacks (March 2024)
• CISA: DDoS Quick Guide (October 2020)
• CISA Alert TA14-017A: UDP-Based Amplification Attacks
• RFC 4987: TCP SYN Flooding Attacks and Common Mitigations
• RFC 2827 (BCP 38): Network Ingress Filtering
• RFC 5737: IPv4 Address Blocks Reserved for Documentation
• Linux kernel documentation: IP Sysctl
• MITRE ATT&CK v18: Reflection Amplification (T1498.002)
• CISA: HTTP/2 Rapid Reset Vulnerability, CVE-2023-44487
• Google Cloud: How it works: The novel HTTP/2 'Rapid Reset' DDoS attack