Lion Cipher Lab

Tune the OWASP Core Rule Set and actually cut your WAF's false positives

• AppSec / DevSecOps
• Advanced
• ~75 min
• Free · no account required

Why it matters

Almost every organization that ships a web app puts a WAF -- a Web Application Firewall -- in front of it, and almost all of those WAFs run the OWASP Core Rule Set underneath, whether that is self-hosted ModSecurity or a cloud WAF that licensed the same rules. Standing one up is the easy part (the beginner lab does exactly that). The hard part, the part that decides whether the WAF survives contact with production, is TUNING it: a WAF straight out of the box blocks real attacks AND a steady trickle of legitimate traffic -- a customer whose name is O'Brien, a search for 'DROP TABLE tutorial',…

What you'll learn

• what a WAF, ModSecurity, and the OWASP Core Rule Set (CRS) actually are and how they fit together
• how CRS ANOMALY SCORING works: matched rules add points; a request blocks only when the inbound score crosses the threshold
• reading a ModSecurity audit log to find the exact rule id, the matched VARIABLE, and the anomaly score for a request
• firing a real SQLi-looking request and confirming it is blocked with the score recorded in the audit log
• recognizing a FALSE POSITIVE: a legitimate request blocked because a benign field looks like an attack
• running DetectionOnly (log-but-don't-block) first so you can observe before you enforce
• writing a SCOPED exclusion (ctl:ruleRemoveTargetById / SecRuleUpdateTargetById) that excludes ONE parameter, not the whole rule
• measuring false positives before vs after a tuning change while proving the true-positive attack is still blocked
• understanding PARANOIA LEVELS (PL1-PL4) as a coverage-vs-false-positive tradeoff, and raising PL to watch new FPs appear
• the judgment: learn-before-enforce, per-parameter over rule-nuking, and why a WAF is defense-in-depth, never a fix for the bug

Steps in this lab

1. What a WAF, ModSecurity, and the OWASP CRS actually are
2. Stand up ModSecurity + CRS in front of an app with Docker
3. The core idea: anomaly scoring and the blocking threshold
4. Fire a real attack and watch it blocked -- with the score in the audit log
5. Now trigger a FALSE POSITIVE: a legitimate request the WAF wrongly blocks
6. Tune it the RIGHT way: DetectionOnly, then a SCOPED per-parameter exclusion
7. Measure it: false positive gone, real attack STILL blocked
8. Raise the paranoia level and watch new false positives appear
9. The judgment: tune surgically, learn before you enforce, and never mistake a WAF for a fix

Open the full interactive lab →