F5 ASM (BIG-IP WAF) Scenario Interview & Master Dashboard

When traffic hits an ASM-enabled Virtual Server, the connection is handled by the tmm (Traffic Management Microkernel) daemon. The HTTP Profile parses the HTTP stream and hands off payload buffers to the bd (BIG-IP Daemon) via internal TMM plugin interfaces. The bd process performs normalization, decodes double URL/Base64 encoding, checks positive security constraints (URLs, parameters, file types), and evaluates negative security attack signature sets.

A robust ASM policy uses Hybrid Security. Negative Security is enforced by assigning the API Security Signature Set (checking SQLi, Command Injection, JSON parser exploits). Positive Security is enforced by importing the OpenAPI (Swagger) v3 JSON Spec into ASM under Security -> Application Security -> Content Profiles -> JSON Profiles, explicitly defining allowed JSON data types, max lengths, and enforcing strict JSON schema validation.

Staging places entities (URLs, parameters, attack signatures) in a non-blocking evaluation mode. If a staged signature matches traffic, ASM logs the violation but does NOT block the request. The Enforcement Readiness Period (default 7 days) requires that an entity receive traffic from multiple unique IP addresses for 7 days without triggering false positives before it is flagged as "Ready to Enforce". Disabling staging prematurely causes un-tuned signatures to immediately block valid production payload formats.

The Support ID is a unique decimal string generated for every logged violation. To investigate: 1) In GUI: Navigate to Security -> Event Logs -> Application -> Requests, paste the Support ID in the search filter. 2) In CLI: Inspect syslog / remote SIEM or search /var/log/asm for the Support ID. 3) Analyze the exact violation (e.g. VIOLATION_ATTACK_SIGNATURE_DETECTED on parameter user_bio). 4) Fix by creating a targeted parameter exception or disabling the specific false-positive signature ID ONLY on that parameter, keeping global protection intact.

1) Download the latest Live Update file (ASM-AttackSignatures-*.user) from F5 Downloads or perform automated Live Update. 2) Update the Signature File under Security -> Options -> Application Security -> Attack Signatures -> Live Update. 3) Newly updated signatures enter Staging by default. 4) Filter the Attack Signature list by CVE-2021-44228 or Signature Names (Log4j rce). 5) Select the specific Log4j signature IDs, click Enforce Selected, apply the policy, and verify enforcement using a non-destructive curl payload.

F5 Advanced WAF Bot Defense uses a multi-layered classification engine: 1) Benign Bot Verification: Verifies search crawlers (Googlebot/Bingbot) via reverse DNS lookup and cryptographic verification. 2) Proactive Bot Defense (JS Challenge): Injects an asynchronous JavaScript payload into initial HTTP responses. Real browsers execute JS and solve mathematical proof-of-work, setting a browser cookie. Simple headless scripts fail the JS challenge. 3) Device Fingerprinting: Collects DOM attributes, canvas rendering hints, TLS client hello ciphers, and browser API signatures to identify botnet clusters even across changing IP addresses.

Standard volumetric rate-limiting fails because 15 Mbps looks normal. Behavioral DoS (BDoS) continuously builds machine-learning baselines of two key metrics: Transaction Per Second (TPS) and Server Latency (Response Time). When backend latency spikes while TPS exceeds baseline, BDoS calculates Stress Score. It automatically analyzes anomalous request parameters (e.g. specific URI combinations or header order), dynamically generates a temporary mitigation signature, and enforces it at TMM speed without requiring manual engineer intervention.

DataGuard inspects HTTP response payloads. Under Security -> Application Security -> Data Protection -> DataGuard, we enable Credit Card Numbers (using Luhn algorithm verification) and Social Security Numbers (SSN regex). - Masking in Response: Replaces credit card digits with XXXX-XXXX-XXXX-1234 before the packet leaves F5 to the client. - Masking in Log: Ensures sensitive parameter values in request logs are masked with asterisks in SIEM/syslog output. Custom regex patterns (e.g. employee ID EMP-[0-9]{6}) are added under Custom Patterns.

1) File Type Enforcement: In ASM, configure explicit Allowed File Types (pdf, jpg, png) with length limits. Disallow dangerous extensions (php, exe, jsp, asp). 2) Disallow Disallowed File Types & Double Extensions: Enable HTTP Protocol Compliance check for URL/File Name metacharacters and null byte injections (%00). 3) Multipart Body & ICAP Integration: Set parameter type to File Upload. For full malware prevention, route multipart payloads via ASM Internal ICAP Profile to an external Antivirus engine (e.g. ICAP server) for deep payload scanning before saving to disk.

We use the ASM_REQUEST_VIOLATION iRule event hook. When a violation is triggered, ASM passes control to the iRule. We extract violation details using ASM::violation_data, check if the request header Content-Type or URI path contains /api/, and send a customized JSON payload using HTTP::respond 403 containing the exact Support ID.

Unlike standard LTM objects synchronized via CMI (Control Plane Management Infrastructure), ASM policies consist of compiled binary files, XML structures, and MySQL/SQLite database tables. Dual un-synchronized edits create a Policy Version Conflict. To resolve: 1) Identify the authoritative unit containing the correct security policy. 2) In GUI: Go to Device Management -> Overview -> Sync, select the authoritative device, and select Overwrite Sync (Push Device to Group). 3) If database sync stalls, restart the sync daemon: bigstart restart asm_config_server.

ASM performs Input Normalization inside the bd engine BEFORE running any signature matching: 1) Decoding Pass: Performs recursive URL decoding, HTML entity decoding, and Unicode normalization. Double-encoded bytes are reduced to canonical ASCII form before signature evaluation. 2) Protocol Compliance: Enforces HTTP Protocol Compliance Checks (e.g. blocking Null Bytes %00, multiple Content-Length headers, or mismatched Transfer-Encoding and Content-Length to prevent HTTP Request Smuggling). 3) Parameter Pollution: Standardizes duplicate parameter names (?user=admin&user=guest) according to configured policy rules.

1) Import OpenAPI YAML/JSON under Security -> Application Security -> API Security -> OpenAPI Files. 2) ASM automatically constructs Allowed URLs, Allowed Methods (GET/POST/PUT/DELETE), Parameter Data Types, and JSON Schemas based on the spec. 3) Schema Drift Resolution: If developers deploy new endpoints without updating the WAF spec, ASM triggers Illegal URL / Illegal Parameter. To automate this in DevOps environments, integrate F5 AS3 (Application Services 3 Extension) or declarative REST API calls (/mgmt/tm/asm/tasks/import-openapi) directly into the GitLab/GitHub Actions CI/CD pipeline so schema updates publish synchronously with code deployments.

Local logging to disk is rate-limited to protect F5 management CPU and storage. 1) High-Speed Logging (HSL): Configure a Pool of remote SIEM syslog servers in LTM. Create a Logging Profile under Security -> Event Logs -> Application -> Logging Profiles. Select Remote Storage = High Speed Logging, assign the HSL Pool, format using Key-Value pairs or CEF (Common Event Format). 2) HSL Performance: HSL bypasses management Linux syslog and streams logs directly from TMM microkernel via hardware/network interfaces, handling 100,000+ EPS with negligible CPU impact.

A Senior F5 ASM Engineer relies on these critical CLI tools: - /var/log/ts/bd.log: Main ASM engine daemon log (debug violation evaluation, policy compilation errors). - /var/log/asm: System & administrative events (policy changes, sync failures, Live Updates). - asm_start / asm_stop: Emergency restart of ASM subsystem without restarting full LTM TMM. - tmsh show asm policy-status: View active policy enforcement state across Virtual Servers.