What are the rule layers (built-in library, global layer, vService layer); which one takes precedence?
Short answer
There are three layers (rule layers). The built-in library contains the signatures that come with TR7, the structural inspection records and the IP Reputation record, and it is read-only. The global layer holds the device-wide state, score and scope changes made on the Signature & Rule Library screen and the global custom rules (ID 1,000,000–4,999,999). The vService layer holds the changes made on the OWASP Rules screen of that vService and the rules specific to the vService (ID 5,000,000–9,999,999). Precedence lies with the most specific layer and is applied field by field: State, Score and Inspection Scopes are each determined separately in the order "the value in the vService layer if it is defined there; if not, the one in the global layer; and if that is not present either, the built-in value". On the vService screen, the state of a global custom rule can be changed with Change State only for that vService; no change in the vService layer is reflected in the global layer or in another vService.
How Does It Work?
| Layer | Content | Where it is edited | Effect | Write permission |
|---|---|---|---|---|
| Built-in library | Signatures (including their pattern, name and classification), structural inspection records, the IP Reputation record | Not edited; changes are defined on top of it | - | - |
| Global layer | Changes on the built-in signatures, global custom rules | Signature & Rule Library | All vServices with WAF protection on | Full permission in the WAF area |
| vService layer | Changes on the built-in signatures, state changes for global custom rules, rules specific to the vService | The OWASP rules screen of the vService | Only that vService | Modify permission in the WAF area; in an account with a vService restriction, only on its own vServices |
Example: if the score of a signature has been set to High in the global layer and the state of the same signature has been set to Monitor in the vService layer, the signature works on that vService with the High score and the Monitor state; on the other vServices, it works with the High score and its built-in state.
- A custom rule name is unique within a layer; two rules with the same name can exist in the global layer and in a vService layer, and they are listed as separate rows.
- No change from another layer is defined on top of the rules specific to a vService; they are edited directly with the Edit Custom Rule form.
- When a global custom rule is deleted, the changes defined for that rule in the vService layers are cleaned up automatically at the next configuration verification.
- Restore to Default deletes only the change in the current layer; on the vService screen, the rule returns not to the built-in value but to the value of the global layer (How do I revert my changes to the default (Restore to Default)?).
- In a cluster setup, the layers are transferred to the peer device together with the configuration: automatically with the default auto-sync, manually if Manual Sync Mode is on. The signature database is compiled separately on each device.
- Which layer a row comes from is not shown with a label in the list; only the rows added or changed in the current layer appear in italic and in color. The way to tell them apart is the ID column (What is the difference between the vService's OWASP Rules screen and the global Signature & Rule Library screen?).
- Inheritance in page types (Rule Source) is a different mechanism from this: How do inheritance and "Rule Source" work in rules?
Common Misconceptions
- "A global change overrides a vService change." The most specific layer wins; if the same field has been changed in both layers, the value in the vService layer is valid.
- "When the vService layer changes one field, all fields come from that layer." The layers merge field by field; if the vService has changed only the score, the state and the scopes continue to come from the upper layer.
- "A change made on a vService spreads to the other vServices." It is valid only on that vService and does not appear in Signature & Rule Library.
How it is done in the documentation
