F5 L7 DoS Protection — TPS, Stress-Based & Behavioral DoS

① Where L7 DoS lives — the DoS profile, not the network

Picture a stadium turnstile. A naive guard counts heads per minute and slams the gate when the count spikes — but a sold-out match looks exactly like a stampede to a head-counter. A wiser guard watches whether the gate itself is buckling, and learns what a normal Saturday rush feels like. That difference — counting vs sensing strain — is the whole story of F5 L7 DoS.

First, scope. This lesson is strictly Layer-7 application DoS — HTTP/HTTPS request floods, slow-and-low attacks, and resource-exhausting requests. It is configured in the DoS profile under its Application Security settings, and the profile is attached to a virtual server. Network/transport DDoS (SYN floods, UDP amplification) lives in a different place (the AFM/device DoS profile) and is out of scope here.

The DoS profile's Application Security tab gives you three detection methods: TPS-based, Stress-based, and Behavioral DoS (BADoS). You can run them together. The art is knowing which one decides, and in which mode.

② TPS-based detection — counting the turnstile

The simplest detector is the turnstile counter. TPS-based detection watches the transaction rate and fires when it spikes. It is the most intuitive method — and the one with the most false positives if you misuse it.

The clever part is that it doesn't use a single fixed number. It compares two moving averages:

• Detection interval — a short-term average of recent requests per second, updated about every 10 seconds. This is "what's happening right now".
• History interval — a long-term average over roughly the past hour. This is your normal baseline.

An attack is flagged when the short interval jumps sharply over the long baseline. You express that with two thresholds, per scope:

• "TPS increased by" — a percentage ratio of detection-interval TPS to history-interval TPS (e.g. fire when current rate is 500% of baseline). This is the relative trigger.
• "TPS reached" — an absolute ceiling (e.g. fire at 200 TPS regardless of history). This catches a cold-start flood before any baseline exists.

You can apply detection by Source IP, by Device ID, by Geolocation, by URL, or Site-Wide — so you can catch "one IP hammering one URL" separately from "the whole site is flooded".

Analogy: a head-counter at a turnstile. It knows a normal Monday is ~50 people/min (history). When it suddenly sees 800/min (detection), it shouts "attack!". The flaw is obvious — a real festival crowd also pushes 800/min, and the counter can't tell the difference. That's the false-positive trap, and it's exactly why stress-based detection exists.

③ Stress-based & Behavioral DoS — sensing strain, then learning normal

TPS counts. The smarter methods sense and learn.

Stress-based detection — wait for the server to actually buckle

Stress-based detection watches server latency. Critically, it does not mitigate on latency alone — F5's own rule is that it takes a latency increase and at least one suspicious source IP, device ID, URL, heavy URL, geolocation, or site-wide entry for the activity to be considered an attack. Two conditions, not one.

That second condition is the whole point. A genuine Flipkart sale raises rate but the well-provisioned backend stays fast — latency is flat — so stress-based stays quiet. A real flood drives latency up and concentrates on a suspicious entity, so it fires. You can run thresholds in Automatic (BIG-IP self-tunes from observed latency) or Manual mode.

Analogy: instead of counting people at the turnstile, the guard watches whether the gate is bending. A packed-but-orderly crowd doesn't bend the gate; a crush does.

Behavioral DoS (BADoS) — auto-learn normal, build dynamic signatures

Behavioral DoS is the machine-learning method, enabled within the stress-based settings. It continuously learns the typical behavior of normal traffic, then combines that learned baseline with server stress to spot anomalies — "what changed, and who caused the congestion?".

It has two engines you toggle:

• Bad Actors Behavior Detection — identifies which source IPs are generating the malicious traffic and what share each contributes, then slows / rate-limits those anomalous IPs based on confidence and server health.
• Request Signatures Detection — generates dynamic request signatures that match only the attack traffic, so legitimate users sailing through the same URLs aren't blocked.

The mitigation is phased: BADoS first applies a global rate limit just to protect the server, then — once it has computed dynamic signatures — narrows to block only traffic matching those signatures. As the server recovers, the thresholds re-calculate against current health. It gets more accurate the longer it runs.

Analogy: BADoS is the veteran guard who has worked every match for years. They know exactly what a normal Saturday crowd feels like, so when something is off they can describe the troublemaker precisely ("hoodie, gate 4, pushing") — that description is the dynamic signature.

The detection methods & key controls — tap each card

Each card front names the control; the back gives you the "so what" — when to reach for it.

④ Operation Mode & mitigation — see it, then stop it

Detection decides whether something is an attack. The Operation Mode decides what BIG-IP does about it. This is the single most misunderstood toggle on the profile.

• Transparent — BIG-IP detects, logs and reports the attack but does not drop or challenge any traffic. This is your safe baseline mode — run here first to learn what would have happened.
• Blocking — mitigation actions actually take effect. Until you set Blocking, a beautifully tuned profile changes nothing on the wire.

Mitigation actions — escalate gently

When a detection method fires in Blocking mode, BIG-IP doesn't just hard-drop everyone. It escalates:

• Client-Side Integrity Defense — a silent JavaScript challenge. Real browsers solve it transparently; scripted floods can't run JS, so they're filtered without a user ever noticing.
• CAPTCHA Challenge — a human-verification step for clients that look suspicious but might be real.
• Request Blocking — either Rate Limit (cap requests) or Block All for the offending scope.

Each is scoped by Source IP, Device ID, Geolocation, URL, or Site-Wide, so you pin the attacker without punishing the whole site. This is why client-side integrity is such a powerful first step — most volumetric L7 floods are bots that fail it instantly.

Behavioral DoS mitigation levels — and where the signatures live

Behavioral DoS adds its own Mitigation setting on top of the mode:

• No Mitigation — learns and monitors only (your BADoS "Transparent"). Start here.
• Conservative — slows/rate-limits anomalous IPs based on confidence + server health; blocks requests matching behavioral signatures.
• Standard — adds concurrent-connection limits and, if needed, rate-limits all requests based on server health.
• Aggressive — does everything Standard does plus proactively applies protections even before an attack and increases the impact of blocking matched requests.

The auto-generated dynamic signatures appear under Security ▸ DoS Protection ▸ Signatures (tick the Dynamic box). Each can be in Mitigate, Detect Only, Learn Only, or Disabled — so you can watch a signature form before you let it block.

tmsh — the same profile from the CLI

The GUI is the day-job, but the same settings exist in tmsh. Useful for review, automation, and the 303 exam.

root@(bigip-flipkart)(cfg-sync)(tmos)# list ltm virtual vs_checkout_443 profiles
root@(bigip-flipkart)(cfg-sync)(tmos)# list security dos profile dos-flipkart-app application

ltm virtual vs_checkout_443 {
    profiles { dos-flipkart-app { } http { } websecurity { } }
}
security dos profile dos-flipkart-app {
    application {
        flipkart-app {
            mode blocking
            tps-based { mode blocking }
            stress-based { mode blocking }
            behavioral { mitigation standard }
        }
    }
}

root@(bigip-flipkart)(tmos)# show security dos virtual name vs_checkout_443
root@(bigip-flipkart)(tmos)# show security dos application-attack

Security::DoS Application Attack
  Profile: dos-flipkart-app   VS: vs_checkout_443
  Attack ID: 9f3c-2026   State: Mitigating
  Detection: Stress-based + Behavioral   Trigger: latency↑ + Source IP 203.0.113.0/24
  Mitigation: Client-Side Integrity → Rate-limit (Source IP)
  Dynamic signature: dosl7_sig_4471  matched 98.6% of attack traffic
# Detection but no mitigation row → Operation Mode is Transparent. No attack row at all → profile not bound to the VS.