AWAF-DOS protection profile

Hi ashu2280,

You can't get different per-URL TPS thresholds out of a *single* DoS profile — the "By URL" detection criterion under TPS-based Detection is heuristic/automatic (the system decides which URL is "under attack" against its own baseline), it doesn't let you pin a manual absolute TPS to a specific URI pattern. The only manually-configurable, per-source-IP absolute TPS lives under "By Source IP" (plus "Site Wide" for the overall total), and both apply to the *whole* object covered by that profile — not per-path.

So to get:

- /api/customer/* → 50 tps/client IP

- /api/contracts/* → 100 tps/client IP

- /api/search/* → 20 tps/client IP

- site-wide → 200 tps/client IP

you need **4 DoS profiles** (one per threshold) and something outside the profile itself that picks the right one based on the URI. There are two supported ways to do that:

• **Option A — Local Traffic Policy ("DoS Policy Switching")**

This is F5's own documented mechanism, no iRule needed:

https://techdocs.f5.com/en-us/bigip-17-0-0/big-ip-asm-implementations/configuring-dos-policy-switching.html

Local Traffic > Policies > Create (strategy = First match), then one rule per API:

- `HTTP URI path starts with /api/customer/` → Enable L7 DoS from profile `dos_api_customer`

- `HTTP URI path starts with /api/contracts/` → `dos_api_contracts`

- `HTTP URI path starts with /api/search/` → `dos_api_search`

- default rule (no condition, mandatory) → `dos_default_sitewide`

Publish it, attach it to the VS, and *also* attach `dos_default_sitewide` as the DoS profile directly on the virtual server / Protected Object — the docs explicitly require a default rule and a default VS-level profile as fallback.

⚠️ Caveat straight from the manual: the policy action "applies not only to the request that matched the condition, but also to the following requests in the same TCP connection" — with keep-alive, if a client hits /api/search/ then /api/customer/ on the same connection, it can stay under the 20 tps profile until the connection closes. Worth testing if your clients reuse connections across those endpoints.

• **Option B — iRule with `DOSL7::enable <profile-name>`**

This is the actual command to invoke a specific DoS profile from an iRule (not `DOSL7::profile`, which is read-only):

https://clouddocs.f5.com/api/irules/DOSL7__enable.html

when HTTP_REQUEST {
  switch -glob [string tolower [HTTP::path]] {
    "/api/customer/*" { DOSL7::enable dos_api_customer }
    "/api/contracts/*" { DOSL7::enable dos_api_contracts }
    "/api/search/*" { DOSL7::enable dos_api_search }
    default { DOSL7::enable dos_default_sitewide }
   }
}

Since `HTTP_REQUEST` fires on every request — even within the same keep-alive connection — this re-evaluates per request, which sidesteps the "sticky to the connection" issue that Option A has. You still need each of the 4 profiles to exist with Application Security enabled and TPS-based Detection configured, and you still need a default DoS profile attached at the virtual server / Protected Object level as the baseline before the iRule runs.

Either way, each profile is configured under Security > DoS Protection > Protection Profiles > [name] > Application Security > TPS-based Detection, Thresholds Mode = Manual, "By Source IP" checked, with:

- Minimum/Maximum TPS = your absolute value (50 / 100 / 20 / 200)

- TPS increased by = your percentage value

Reference for TPS-based Detection fields: https://techdocs.f5.com/en-us/bigip-17-0-0/big-ip-asm-implementations/preventing-dos-attacks-on-applications.html

Both mechanisms (LTM Policy switching and `DOSL7::enable`) exist unchanged across the currently supported branches (17.1, 17.5, 21.1).

Sources:

DoS Policy Switching

Preventing DoS Attacks on Applications / TPS-based Detection

DOSL7::enable

DOSL7::profile (read-only)

DOSL7 command/event list

tmsh reference, security dos profile