F5 ASM war-room — support ID, then the violation

1. Why a green pool is not a WAF verdict

LTM health answers “did a monitor reach a member.” ASM / Advanced WAF answers “did this HTTP request violate the security policy, and was that violation allowed to block?” Those are different owners. Mixing them is how a checkout Sev-2 becomes a 02:00 policy-off change.

This desk is the war-room for one transaction. You lock the user, the URL, the UTC minute, and the Support ID. Then you walk three layers: the request log, the policy enforcement settings, and the virtual-server stats that prove traffic even arrived.

Hero · allow path vs block path

2. Mental model — five objects on the desk

Memorise five named objects before you click. Each is allowed to prove one thing. Over-claiming a field is how you ship a bad Accept at 02:00.

3. Decision flow — ticket → first click

Flowchart first. Do not open Learning and Blocking Settings until a diamond says so.

Path · prove before you change

4. How to choose — first tool + proof field

Print this next to TMUI. If you cannot recite the proof field, you are not ready to Apply Policy.

5. Runbook Side A → B → C

Side A finds the transaction. Side B proves the policy was allowed to block it. Side C proves the virtual is the one that received it. On a messy Sev-2, do them in this order until a field lights up.

Side A — Support ID and the request / violation

1. Take the Support ID off the page, not off Slack memory

   The default response pages include <%TS.request.ID()%>. The system replaces that variable with the Support ID when it issues the page. Official iRule ASM::support_id returns the same identifier for the present HTTP transaction, whether or not a violation was found. Paste the full number. Partial last-4 filters exist; use them only when the user cropped the screenshot.

2. Open Application Requests, not the policy editor

   Path: Security > Event Logs > Application > Requests. Click Show Filter Details. Locate the Support ID section and filter. Source: my.f5.com K50320144. If the list is empty, do not widen to “all policies, last 30 days” until you have tried Bot Defense with the same ID.

3. Click the row. Separate request from violation

   The Requests List is the transaction. The detail pane is the verdict. Quote: date/time, client IP, virtual server, policy name, request status (illegal / legal), HTTP method, URI, and every violation with its Attack Signature ID if one fired. Sensitive parameters display as asterisks when marked sensitive — that is official, not a logging failure.

4. If the ID is still missing, change log store — then stop guessing

   Path: Security > Event Logs > Bot Defense > Bot Requests. Official notes: some Support IDs are never written to ASM event logs because the request was not processed by ASM and no violation occurred (K64034374). That is a listener / profile / HTTP-class attach problem, not a false-positive problem.

Side B — Enforcement Mode, then Learn / Alarm / Block

1. Read Enforcement Mode on the named policy

   Path: Security > Application Security > Security Policies > Policies List. Open checkout_awaf. Official: Blocking — traffic is blocked if it causes a violation configured for blocking. Transparent — traffic is not blocked even if a violation is triggered; the system reviews and logs. A blocking page in the user’s browser already tells you this policy (or a parent that enforces) is not Transparent for that action.

2. Open Learning and Blocking Settings for that violation

   Path: Security > Application Security > Policy Building > Learning and Blocking Settings. Find the violation from Side A (Illegal parameter value, Illegal meta character, Attack signature detected, Illegal file type, Illegal method, HTTP protocol compliance). Quote Learn, Alarm, and Block independently. Official lab note: a Blocking policy can still only alarm if Block is unchecked on that element.

3. Check staging before you call it a false positive

   Attack signature staging is designed to reduce false-positive blocks. A signature in staging does not block even when Enforcement Mode is Blocking. Official: staging-period matches generate learning suggestions; some staging hits are reported as legal / Attack Signature Staging. Do not “enable Block on the whole set” from one checkout POST.

4. Traffic Learning is the suggestion queue, not the RCA

   Path: Security > Application Security > Policy Building > Traffic Learning. You may Accept, Delete, Ignore, or Export. Official: review whether the listed request is a legitimate violation or a false positive before you Accept. The Accept Request button on an event-log row only changes the policy when that request generated a learning suggestion (K11730196). Always Apply Policy (tmsh: publish policy checkout_awaf) after an accepted change — the editor is not the running policy until you publish.

Side C — tmsh and virtual-server stats

1. Prove the listener before you blame the policy

   Official: show virtual [name] displays statistics and status. Paste Availability, State, Destination, and the incrementing connection / request counters on vip_checkout_443. A virtual with zero requests in the incident window never produced an ASM row. That ticket belongs on the F5 evidence desk (pool, persist, tcpdump).

2. Prove the policy is attached to that virtual

   Official display option: list /asm policy checkout_awaf virtual-servers — “Displays the name of the protected virtual server, or virtual servers, which have attached to them the security policy via L7 policies.” TMUI twin: Local Traffic > Virtual Servers > vip_checkout_443 > Security > Policies — Application Security Policy enabled, logging profile in Selected (lab uses Log all requests when you must see legal traffic too).

3. Use list for config, show for stats, publish for apply

   list is configuration. show is statistics and runtime status. publish policy checkout_awaf applies the active policy — the CLI name for Apply Policy. Do not modify policy … blocking-mode disabled from the war-room until Side A named the violation and change-control owns the blast radius.

# Listener stats + status  (official: show virtual [name])
tmsh show /ltm virtual vip_checkout_443
tmsh show /ltm virtual vip_checkout_443 detail

# Config: pool, profiles, policies  (official: list virtual)
tmsh list /ltm virtual vip_checkout_443 destination pool profiles policies

# Which virtuals this ASM policy protects
tmsh list /asm policy checkout_awaf virtual-servers
tmsh list /asm policy checkout_awaf all-properties

# Apply Policy, only after change-control
# tmsh publish policy checkout_awaf

6. Runtime path of one checkout POST

Follow one POST. Do not skip a box. The pool can stay Available the entire time.

7. Traps + close-the-ticket proof

These five land every release week. Each trap has one contradicting field. Times and identities below are lab-only.

Proof · close only after the original POST is legal

Sources

• my.f5.com K50320144 — Using the BIG-IP ASM system to search request event logs (Security > Event Logs > Application > Requests · Show Filter Details · Support ID)
• my.f5.com K000152255 — Support ID shown in both ASM and Bot Defense event logs (Support ID is the primary key of the request log table)
• my.f5.com K02120103 — Unable to find the Support ID displayed in the response (ASM request logs and Bot request logs; both up to 20 digits)
• my.f5.com K64034374 — BIG-IP ASM unable to find Support ID in Event Logs (ID not logged when ASM did not process the request)
• my.f5.com K62833065 — ASM Event Logs / Support IDs are missing (local request-logging limitation)
• my.f5.com K39522452 — Configuring the security policy enforcement mode (Policies List · Blocking / Transparent)
• my.f5.com K000138908 — Creating a security policy automatically (17.x) (Enforcement Mode Transparent or Blocking)
• my.f5.com K13050156 — Policy tuning and enhancement (ASM operations guide) (Traffic Learning review; Transparent → Blocking)
• my.f5.com K70544352 — Reducing false positive violations (staging-period matches generate learning suggestions)
• my.f5.com K12911 — Attack signature staging violations reported as legal
• my.f5.com K11730196 — Accept Request button may not modify the policy (only when a learning suggestion exists)
• my.f5.com K000157013 — Unexpected blocking in BIG-IP Advanced WAF (stage Illegal meta character / parameter value length when they false-positive)
• clouddocs.f5.com — tmsh asm policy (blocking-mode enabled/disabled = block vs transparent log-only; list … virtual-servers; publish policy applies)
• clouddocs.f5.com — tmsh ltm virtual (show virtual [name] statistics and status; list virtual configuration)
• clouddocs.f5.com — Declarative WAF v17.1 schema (enforcementMode blocking | transparent; <%TS.request.ID()%> on default response pages; sensitive parameters)
• clouddocs.f5.com — ASM::support_id (unique identifier whether or not violations were found; correlates request log and blocking page)
• clouddocs.f5.com — WAF 201 Lab 2 · Positive security (Event Logs > Application > Requests; Traffic Learning; Learn/Alarm/Block; Apply Policy; Log all requests)
• clouddocs.f5.com — WAF 102 Exercise 4.1 · Transparent policy (Traffic Learning Accept/Delete/Ignore; alarmed requests while Transparent)
• clouddocs.f5.com — WAF 102 Exercise 2.1 · Bot Defense (Security > Event Logs > Bot Defense > Bot Requests)
• clouddocs.f5.com — WAF 302 Lab 1.2 (Blocking vs Transparent enforcement wording)

Related: F5 evidence desk · F5 session factory · Command ladder cheatsheet · LTM troubleshooting scenarios · F5 practice dashboard

Every output block is fictional lab data. Confirm live syntax, permissions and privacy rules on the production release before you type anything on a live system. Request logs can contain payloads — redact and retain per your organisation’s rules.