L7 DDoS Protection: Why Application-Layer Defense Is Now Essential

On this page

1. L7 attacks stop a service by method, not volume
2. What L3/L4 defense does well, and what it misses
3. Why the obvious responses do not work
4. PacketStream's criterion: not how much is sent, but what is requested
5. Where L7 sits in four-stage filtering
6. To inspect content, traffic has to pass through
7. Supported L7 protocols
8. If attacks target the application

Sometimes the bandwidth graph looks perfectly normal, yet the login API stops responding. On a game server, the player count holds steady while server threads stall one by one. The link is not full. The application has simply run out of breath first.

DDoS used to mean pouring in enough traffic to fill the pipe. Today, more attacks target the way an application works, without needing much volume at all. Below, we look at why L3/L4 defense runs into limits against these attacks, and what a defense should judge traffic by instead.

L7 attacks stop a service by method, not volume

L7 attacks arrive looking like normal requests and hit only the points that are expensive to process. Each packet may be small, but the cost of handling the request is large.

• HTTP authentication and search floods: force repeated heavy work such as database queries and password checks until application resources run out.
• TLS handshake abuse: keep starting encrypted connections so the server CPU is drained first.
• Forged game protocols: imitate the connection sequence of game protocols such as Minecraft, FiveM and RakNet to tie up server threads.
• Repeated incomplete sessions: send session requests to VPN or SIP that never finish, holding on to connection resources.

They share one trait: by volume alone, they cannot be told apart from legitimate users. So the defense has to change what it looks at.

What L3/L4 defense does well, and what it misses

L3/L4 defense is still the foundation. It quickly filters large UDP/TCP floods and applies simple policies at the infrastructure level based on source and packet shape. The problem is that the information it judges by stays on the surface of the packet.

Neither replaces the other. The earlier stages reduce the volume, and the later stage inspects the content of what is left.

Why the obvious responses do not work

When an L7 attack arrives, two responses come to mind first.

1. Tighten the rate limit → legitimate users are blocked along with the attack. Right after an event rush or a game update, the damage is even greater.
2. Add bandwidth and servers → the attack consumes application resources, not bandwidth, so whatever you add gets used up again. Only the cost grows.

Neither is acceptable. Think of the entrance to a concert hall: the first option lets fewer people in, and the second opens more doors. Neither catches a forged ticket. What is needed is checking each ticket at the door.

PacketStream's criterion: not how much is sent, but what is requested

PacketStream identifies attacks by what is being requested. That judgment rests on two principles.

1. 01Stateful Session TrackingEvery connection is tracked as a session, and legitimacy is judged from patterns and state changes over time.
2. 02Payload-Level ValidationPayloads are inspected directly for each application and authenticated at the protocol level.

Tracking sessions reveals patterns a single packet cannot show, such as connections that never complete the handshake or sessions that repeat the same heavy request. Validating payloads makes it possible to check that non-HTTP traffic, such as game protocols, follows the rules of its own protocol.

Where L7 sits in four-stage filtering

L7 validation does not work alone. Traffic passes through four stages in order, from upstream to the application, and each stage removes its share of the attack.

1. 01Upstream pre-filteringLarge volumetric attacks are filtered upstream before they reach the PacketStream network.
2. 02Stateless filteringTraffic is blocked or allowed by Geo/ASN, and malformed packets are dropped quickly.
3. 03Stateful filteringAdaptive rate limiting and challenges are applied to TCP and UDP floods on a per-session basis.
4. 04Application filteringApplication traffic is authenticated per packet to stop application-layer DDoS and exploit attacks.

The order is deliberate. The more a check looks into content, the more it costs, so attacks that can be filtered by volume are removed first. Only traffic that looks legitimate reaches the last stage, and resources go into validating its content.

One point needs attention here. Session and behavioral analysis must see both inbound and outbound traffic, so it is available with symmetric routing. With asymmetric routing, detection is based on inbound traffic. If you keep an existing line for outbound traffic, check your uRPF settings in advance.

To inspect content, traffic has to pass through

To validate request content, traffic has to pass through PacketStream. That is why the deployment mode also affects L7 defense. It is like the difference between a security checkpoint that is always staffed and one that opens only when an alarm goes off.

With On-Demand, the path changes only after an attack is detected, so traffic before that point does not pass through PacketStream. This is why PacketStream recommends Always-On for most services.

Supported L7 protocols

Application filtering validates the protocol itself, from general HTTP/TLS to real-time game, communication and VPN protocols. Examples include:

Services that run their own protocol not on the list can build a custom protocol filter with our technical team. The full list is on the DDoS Mitigation product page.

If attacks target the application

Back to where we started: a service stops while the bandwidth graph stays quiet because the attack aims at processing cost, not volume. Tightening rate limits or adding resources cannot stop it while still protecting legitimate users.

That is why defense needs L3/L4 to reduce volume and, on top of it, validation of sessions and request content. If attacks target the application, the defense has to understand the application.

View DDoS Mitigation