Which protection level should I choose (Elementary, Normal, Tight, Very Tight and Aggressive)?
Short answer
For general production traffic, the default Very Tight (4) is the starting level: a single signature hit of Medium and above reaches the threshold, and the card shows the odds of blocking clean traffic as low. Since Aggressive (2) also brings signatures with a Low score into play, the odds are high; it is selected only for services whose rule set has been learned well and tried in Monitor mode. Tight (8), Normal (16) and Elementary (24) are loose levels at which a single Medium or High hit does not reach the threshold, and active signature hits that stay below the threshold are not written to Event Logs. False positives are resolved, instead of by lowering the level, by putting the signature into the Monitor state, adding it to OWASP Exclusions or teaching the record with Allow / Teach; blocks caused by structural violations (24) do not decrease at any level. The level is changed from the OWASP Protection Level card in WAF Management and saved with Edit; Sync with Default WAF Rules is checked only if the Any Paths rule is to be returned to the default.
Level Selection
| Level | Threshold | When | Caution |
|---|---|---|---|
| Aggressive | 2 | High-risk services whose rule set has been learned well and tried in Monitor mode | Low signatures start to be scanned; odds on the card high |
| Very Tight (default) | 4 | General production traffic | A single Medium, High or Very High hit reaches the threshold; odds on the card low |
| Tight | 8 | When only Very High hits should reach the threshold on their own | A single Medium or High hit passes and is not recorded; two Medium hits (4 + 4) reach the threshold |
| Normal | 16 | When more than one high-risk hit should have to accumulate | No signature reaches the threshold on its own |
| Elementary | 24 | The loosest level | Signature hits reach the threshold only if they accumulate to 24 points |
- Active signature hits of a request whose attack score stays below the threshold are not written to Event Logs; at a loose level, these requests do not appear as attacks on any screen.
- A structural violation (24) and a blacklist hit (100) reach the threshold at every level; lowering the level does not change the blocks caused by them.
- The level is common to all the Virtual Host Groups in the vService (Can I set the protection level separately for each domain / host group?).
- If the new level is tried while one of the groups is in Monitor mode, its effect is seen without blocking: requests that reach the threshold are recorded in Event Logs as
Not blocked — Monitor mode(How do I use Monitor mode to weed out false positives?).
How Is the Level Changed?
From the Interface
The Left Monitor Panel is opened; WAF-Protected vServices is selected from the category tabs, the vService is clicked and the WAF Management tab is opened.
In the Inspection & Blocking section, the pencil icon at the top right of the OWASP Protection Level card is clicked; the window titled OWASP protection level opens (Edit screen).
The level is selected from the OWASP Protection Level list; the list is ordered from Elementary to Aggressive. The line below the list instantly shows the Odds of blocking clean traffic according to the selection (Elementary, Normal and Tight very low, Very tight low, Aggressive high).
Edit is clicked. No separate confirmation is asked for the level change; the new level is applied without a separate deployment step. In a cluster setup, with the default auto-sync, the change is also sent to the peer device automatically; if Manual Sync Mode is on, it is sent to the peer device manually.
With WEB-CLI
In WEB-CLI, the level is changed by writing 24, 16, 8, 4 or 2 in the --owaspProtectionLevel field (basic inspections). --syncWithDefaultFwRules is not a stored setting but a write trigger: only when true is written is the Any paths rule set up again with its default definition; if it is not written in the command, the rule set is not touched. The false in the command states this explicitly:
waf options update poolId <vService> --owaspProtectionLevel 8 --syncWithDefaultFwRules falseFor the same level on more than one vService, the bulk command is used; the command opens the selection list and asks for confirmation. The bulk command does not accept the --syncWithDefaultFwRules field and does not touch the Any paths rules (bulk update):
waf options update-many target selected --owaspProtectionLevel 8Verification
- Card: The OWASP Protection Level card writes the new level (e.g. Tight — Odds of blocking clean traffic: very low).
- List: The OWASP protection level column on the WAF-Protected vService List screen shows the new level.
- WEB-CLI: In the
waf options show poolId <vService>command,owaspProtectionLevelcarries the new value. - Traffic: The Blocked and Monitor series on the WAF Inspection Distribution panel of the vService Dashboard and the Action values of the new records in Event Logs are followed.
Common Misconceptions
- "Raising the level means making the number bigger." Tightening makes the number smaller: Elementary 24, Aggressive 2.
- "Sync with default WAF rules is required to save the level." It is not required; if Sync with Default WAF Rules is checked, the learned inspections in the Any paths rule are deleted. In WEB-CLI as well,
--syncWithDefaultFwRulessets up the Any paths rule again only whentrueis written; if the field is not written, the rule set is not touched. - "At Aggressive, Sync with default WAF rules only narrows the limits." The tight set fully blocks JSON, XML and form bodies in the Any paths rule, leaves the allowed MIME type lists empty and does not allow methods with a body such as POST; if Argument Checks is on, since the allowed parameter lists start empty every parameter is counted as a violation, and the Host and User-Agent headers also become mandatory; requests with a body that come to paths not learned as a Page Type are blocked in Blocking mode. The same tight set is also set up on a vService at the Aggressive level with the WEB-CLI command
waf host-groups reset-rules. In such a case, the related blocking inspections are turned off on the Check Fields tabs (JSON, Xml, Form, Raw) of the Any paths rule, or the rule set is extended with learned Page types. - "False positives are resolved by lowering the level." Blocks caused by structural violations continue at every level, and a loose level also lets real attacks pass without a record; they are resolved on a signature or field basis (Is it better to disable a signature entirely or to add an OWASP exclusion?).
- "The effect of a level change is seen in a group in Learning mode." In Learning mode, since signature hits are not added to the score and no blocking decision is made, the effect is seen only in Monitor or Blocking mode.
How it is done in the documentation
