ASM Logging & iRules Events: Support IDs & ASM_REQUEST_DONE

① Logging profiles — the WAF's recorder settings

Think of a CCTV system. The camera (the WAF) sees everything, but whether anything is recorded, and where the tape is stored, is a separate setting. In Advanced WAF that setting is the logging profile. It answers two questions: which requests to log, and where to store them.

You build it at Security ▸ Event Logs ▸ Logging Profiles ▸ Create, enable Application Security, and then choose the destination. The two big choices:

• Local Storage — events stay on the BIG-IP and you read them in the GUI Event Logs. Fine for a lab or low traffic; on a busy box it competes for disk and is lost on reboot.
• Remote Storage — events are forwarded off-box over high-speed logging to a syslog server or SIEM pool. This is the production answer.

For remote storage you also pick the format so the receiving system can parse the fields. There are three you must know for the 303 exam: CSV for a generic syslog server, key-value pairs for a reporting server like Splunk, and CEF for an ArcSight server. Finally, Request Type decides volume: Illegal requests only (the default — just the blocks/alarms) or All Requests (everything, huge volume, use only while tuning).

② Trace a block by its support ID

This is the skill that makes you the person the team calls during an incident. A user is blocked. Instead of guessing, you ask them one thing: "what's the support ID on the block page?"

Every blocking response page Advanced WAF returns prints a support ID — a long unique number. You take it to Security ▸ Event Logs ▸ Application ▸ Requests, paste it into the search, and the WAF opens that exact request: the violations it triggered, the matched attack signature, the parameter and value, the source IP, and the full request data. No log-diving, no time filters — one number, one request.

From there the decision is the same tuning judgement you already know: if it's a legitimate request wrongly blocked, you accept the suggestion or relax the entity; if it's a real attack, you confirm the block is correct and move on. The support ID is what turns "somewhere in millions of log lines" into "this one row".

The four log surfaces — tap to flip

③ ASM iRule events — ASM_REQUEST_DONE and friends

Reading the WAF is half the power. The other half is scripting it. iRules let you run custom logic at specific moments in a transaction. ASM adds its own set of events — moments that fire when the security policy has something to say.

There are three ASM events you must know:

• ASM_REQUEST_DONE — fires after ASM finishes processing every request, whether it had a violation or not. This is the modern, all-purpose hook. F5's own guidance: if you're writing new iRules, use this — it replaces ASM_REQUEST_VIOLATION.
• ASM_REQUEST_VIOLATION — the legacy event, fired only when a request violated the policy. Kept for backward compatibility only. Don't reach for it in new work.
• ASM_RESPONSE_VIOLATION — fires when a response (server → client) violates the policy, e.g. data-leakage / DataGuard matches on the way out.

The reason ASM_REQUEST_DONE won is that it runs once, predictably, at the end of request processing — so inside it you can read ASM::status (did it block?), ASM::violation (what fired?) and ASM::support_id (which transaction?) in one place, for every request, and decide what to do. The old violation-only event couldn't see the clean requests at all.

The iRule (real, copy-pasteable)

when ASM_REQUEST_DONE {
    # runs after EVERY request — clean or violating
    set sid [ASM::support_id]
    set st  [ASM::status]
    if { $st ne "" } {
        # a violation fired — record what and from where
        log local0. "WAF status=$st support_id=$sid \
client=[ASM::client_ip] severity=[ASM::severity] \
violations=[ASM::violation names]"
    }
    # stash for the response stage
    set ::sid_for_resp $sid
}
when HTTP_RESPONSE {
    HTTP::header insert "X-WAF-Support-ID" $::sid_for_resp
}

Jun  2 14:07:31 bigip1 info tmm[12044]: Rule /Common/irule_asm_supportid :
  WAF status=blocked support_id=18446744073709551607
  client=203.0.113.7 severity=critical
  violations=VIOL_ATTACK_SIGNATURE
# and on the app side, the response now carries:
X-WAF-Support-ID: 18446744073709551607

④ ASM iRule commands — read, allow, raise (and the disable trap)

Inside those events you call ASM commands. Here are the ones the 303 exam and real production both lean on:

• ASM::support_id — the transaction's support ID (the same one on the block page).
• ASM::violation — the list of violations on the current request/response, with details. ASM::violation_data exposes the same via multiple buffers.
• ASM::severity — the overall severity of the transaction's violations.
• ASM::client_ip — the end client's real IP for the current request.
• ASM::status — the current status of the request/response (did it block?).
• ASM::unblock — overrides the blocking action for a request that had a blocking violation (surgical allow).
• ASM::raise — issues a user-defined violation on the present request.
• ASM::disable / ASM::enable — turn WAF plugin processing off / on for the connection.