ModSecurity / Coraza → F5 BIG-IP ASM
ModSecurity / Coraza ↔ F5 BIG-IP ASM: integration to migration path.
The WAF is load-bearing — get a cutover wrong and either attacks sail through or legitimate traffic is blocked en masse. So Coraza deploys behind F5 ASM first, in detection-only, scoring real traffic while ASM stays the decision-of-record. Only once it has demonstrated parity over weeks does the blocking decision move, one reversible phase at a time — no flag day, no re-credentialing of any policy.
Partial retirement is a real, honest end state: many estates stop with ASM gone but BIG-IP retained for L4 and TLS. We tell you which case you are in before Phase 1.
The idea
Become a second engine first. Take the decision last.
What makes this zero-outage: a Coraza reverse proxy sits behind the F5 at the L7 perimeter, running OWASP CRS in detection-only. It scores every request and produces a second, SIEM-native audit log without ever blocking, so we build prod-grade CRS exclusions from real traffic while ASM keeps making every blocking decision. Once Coraza has matched ASM's coverage, we invert the tiers, then unprovision ASM, then — only if the cloud-native case justifies it — retire BIG-IP entirely. Each layer is independent and reversible; you are never betting the perimeter on one big cutover.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We export every virtual-server ASM policy XML, count the enabled-and-blocking signatures per category, and pull 30 days of BIG-IQ logs into your SIEM to baseline rule-firing volume. Read-only — nothing in path changes.
Coraza goes live in DETECT behind ASM
A Coraza tier (Caddy or nginx) stands up on at least two HA nodes behind BIG-IP, running CRS at paranoia level 1 in detection-only. It scores real traffic and streams a second audit log; F5 ASM still makes every blocking decision.
Tune Coraza to parity; both block
We translate ASM's allowed-URL and parameter exclusions into CRS exclusions, hand-write SecRules for ASM-only signatures, then turn Coraza to block. Both tiers now enforce — defence in depth, with drift detection comparing the two.
Invert: ASM to transparent, Coraza decides
F5 ASM is moved to transparent/passive enforcement and Coraza becomes the only WAF making blocking decisions. ASM logs keep flowing as evidence. Coraza has already blocked the same request shapes for weeks.
Migrate WAF function off F5
ASM is unprovisioned from the BIG-IP module list and the SKU returned; BIG-IP keeps L4 LB, TLS termination, and its iRule estate. The behavioural-DDoS profile is re-homed to a cloud-LB native or dedicated service first.
Optional: full F5 retirement
A cloud L4 LB is stood up in parallel and per-app DNS is migrated in waves to a Caddy/nginx + Coraza tier owning L4, TLS, and WAF. iRule logic is re-implemented as proxy config, Envoy filters, or app code. F5 contract terminated.
Partial retirement is a valid end state
Many estates stop at Phase 4 — ASM gone, BIG-IP retained for LTM. The WAF SKU savings are realised, the iRule estate stays untouched, and the L3/L4 capability stays where it is. We say honestly when Phase 5 is not worth the iRule re-platform cost.
Feature parity
Where Coraza matches ASM, and where it does not.
| Capability | ModSecurity / Coraza | F5 BIG-IP ASM | Parity |
|---|---|---|---|
| Rule engine | SecRule grammar (ModSec v3; Coraza ~95%, no Lua, SecRemoteRules, or XML) | F5 ASM attack signatures plus Security Policy XML | Partial |
| Managed ruleset | OWASP CRS v4.x (~250 rules at PL1-PL2, community-maintained) | ~9000 vendor-curated signatures with an SLA feed | Partial |
| Anomaly scoring | CRS inbound score >=5 / outbound >=4 | ASM violation rating 0-10 plus blocking mask | Partial |
| Learning-mode baselining | CRS detection-only plus SIEM log analysis (manual) | ASM learning mode (automatic policy suggestions) | Partial |
| Bot detection / ML | None (CrowdSec or external bot tier) | F5 Advanced WAF bot defence plus Anti-Bot Mobile SDK | SaaS only |
| DDoS absorption | nginx limit_req plus CrowdSec (volumetric only) | ASM behavioural-DDoS dynamic baseline | SaaS only |
| IP reputation | CrowdSec Community Blocklist (CTI), 15s pull | F5 threat-feed iRules | At parity |
| Body inspection | SecRequestBodyLimit, 13 MB default | Maximum HTTP Request Length, 10 MB default | At parity |
| TLS / L4 integration | nginx/Caddy TLS termination plus reverse proxy | F5 TLS termination plus L4 LB plus hardware SSL offload | Partial |
| Programmability | Caddyfile / nginx directives plus Envoy Lua/Wasm | F5 iRule estate (ASM::*, SSL::extensions) | Partial |
| Logging / SIEM | SecAuditLogFormat JSON, native SIEM-friendly | syslog-CEF / DB, queryable in BIG-IQ | At parity |
| Cost model | Compute plus ops on commodity hardware | BIG-IP hardware plus ASM SKU plus support contract | Partial |
| Vendor support | Self-support or paid third party | F5 TAC 24/7 with SLA | SaaS only |
| Compliance (PCI 6.4.2 / SOC 2) | Self-owned CRS pinning plus log custody (>=12mo retention) | Vendor control evidence plus brand attestation | Partial |
What we're honest about
The caveats most vendors leave out.
Behavioural DDoS has no OSS parity
F5 ASM's dynamic behavioural-DDoS baseline catches slow-rate and behavioural attacks that nginx limit_req plus CrowdSec — volumetric only — do not. We keep the F5 profile until a cloud-LB native option (Shield Advanced, Cloud Armor adaptive) or a dedicated DDoS service is in place before Phase 4, and we exercise it against a synthetic attack before you trust it.
The Advanced WAF bot stack does not reproduce
F5's bot-defence stack — proactive bot defence, CAPTCHA challenge, and the Anti-Bot Mobile SDK — has no OSS equivalent. CrowdSec and JA3/JA4 catch script-kiddies; the network-effect bot dataset is SaaS-only. If you rely on it, that is a separate bot-defence workstream, and we scope the gap honestly rather than pretend it is covered.
Community CRS, no vendor signature SLA
F5 ships ~9000 vendor-curated signatures with a signed-update SLA; OWASP CRS is ~250 rules at PL1-PL2, community-maintained, no SLA. We pin a CRS version per release, subscribe to the CRS announce list, and run a documented response process for high-severity releases. Where a contractual SLA is required, that is a paid third-party support decision.
Self-hosting means you own uptime and the iRule estate
Once the WAF is Coraza, it being down means requests fail-open or fail-closed — there is no managed backstop. We run it HA across nodes with a tested DR runbook. And years of iRule logic does not translate cleanly: we inventory every iRule in Phase 0, and some will need app-code changes rather than a config port.
Why this beats a flag day
Reversible per phase. Soaked before you cancel.
Every per-phase change rolls back inside the documented window — under 5 minutes to drain the Coraza tier, under 2 minutes to flip ASM enforcement back to blocking, about 30 minutes to re-provision ASM from the version-controlled policy XML. And we never cut the F5 SKU on optimism: Coraza must be the sole decision-of-record for at least 30 consecutive days, with rule-firing volume within plus-or-minus 20 percent of the ASM baseline and zero coverage incidents, before the contract is touched.
See whether your WAF migrates off ASM cleanly.
A call with a senior security engineer. We export your ASM policy, map every blocking signature to a CRS category, identify the bot-defence and behavioural-DDoS gaps that stay on F5, and tell you honestly whether you stop at partial retirement or go all the way — before you commit.
Map my migration →