DDoS Attack Types: L3, L4 and L7 Differences and Defense

At which layers do DDoS attacks happen?

A DDoS (Distributed Denial of Service) attack tries to make a service unreachable with traffic from many sources. Classifying the attack correctly is the first step toward the right defense, because each class exhausts a different resource.

We classify with the OSI model. L3 is the network layer (IP), L4 the transport layer (TCP/UDP) and L7 the application layer (HTTP). The target is one of three things: bandwidth, tables that hold connection state, or the application's processing power.

The three attack classes

Volumetric attacks (L3/L4)

The goal is to fill the line. The attacker sends an enormous volume of packets, and legitimate traffic cannot get through because the target's internet connection is full. UDP floods and reflection/amplification belong here: the attacker spoofs the source IP as the target's address, an open DNS or NTP server answers a small request with a large reply, and the reply goes to the target.

Network providers can limit source spoofing by filtering at egress, a practice described in BCP 38 (RFC 2827). But that is a measure for the network the traffic leaves, not for the victim.

Protocol attacks (L4)

The goal is to exhaust the connection-state tables of the server or of devices in between. The classic one is the SYN flood. TCP connects through a three-step handshake: the client sends SYN, the server answers SYN-ACK, the client finishes with ACK. The moment the server sends SYN-ACK, it reserves memory for a half-open connection. The attacker sends many SYNs and never sends the final ACK; the half-open queue fills and new legitimate connections get refused.

Application-layer attacks (L7)

The goal is to wear the application down until it stops answering. Traffic volume can be small; each request is expensive.

• HTTP flood: many GET or POST requests that look valid. They usually target paths that run database work, such as search, login or cart.
• Slowloris-style attacks: the attacker holds connections open and sends headers or the body very slowly. The server waits on each one, tying up a worker or slot; the slots run out and new requests cannot get in. Volume stays low, so an alarm that watches bandwidth stays quiet.
• Cache-busting requests: adding a random query parameter to every request defeats the cache and sends each request down to the origin.

Comparison table

SYN floods and SYN cookies

RFC 4987 describes the SYN flood and common mitigations. The classic one is SYN cookies: when a SYN arrives, the server allocates no memory for a half-open connection. Instead it derives a verifiable value from the connection details and embeds it in the initial sequence number of the SYN-ACK. If the client really answers, it returns that value in the ACK, and the server builds the connection at that moment. SYNs with spoofed sources get no reply, so they accumulate no state.

The cost: while using SYN cookies, the server cannot fully store some TCP options (window scaling, for example), so systems like Linux usually turn them on only once the queue is full. SYN cookies also do not protect against very fast completed handshakes from a single real source; that takes a per-IP rate limit.

How does a reverse proxy mitigate an attack?

In the reverse-proxy model, clients connect to the proxy, not to your server. That has three consequences:

1. The surface shrinks. The proxy's web ports (80 and 443) are what the outside world sees. If you open ports 80 and 443 on your origin only to proxy addresses, an attacker cannot hit your server directly. For detail, see origin IP hiding and Origin Lock.
2. The proxy absorbs connections. The proxy handles the TCP handshake, TLS and slow clients. A slowloris-style connection does not hold a slot on your origin.
3. Requests get filtered before the origin. Rate limits, verification puzzles and WAF rules stop illegitimate requests in front of the origin.

Timing is part of the defense. The proxy should tighten when an attack starts and relax when it ends. When to turn on Under Attack mode explains when to make that switch by hand.

Honest limits of a single-region service

A volumetric attack is not something a reverse proxy can solve. Traffic that fills the line does its damage at the provider connection before it reaches the server. Capacity spread across many points upstream solves that problem.

Nexren Shield does not offer that structure:

• One region, one virtual server (Turkey).
• No anycast, no upstream scrubbing.
• No Gbps or Tbps capacity promise; we publish no capacity figure.
• No percentage SLA.

In practice: against application-layer and connection-based attacks, Nexren Shield adds a real layer; against a large volumetric attack that fills the line, it gives no guarantee. If your threat model includes volumetric attacks, talk to us before you buy. For an overview of the product, read what is Nexren Shield.

Sources

• RFC 4987: TCP SYN Flooding Attacks and Common Mitigations
• RFC 2827 (BCP 38): Network Ingress Filtering
• RFC 9293: Transmission Control Protocol (TCP)

Related product pages:Technology