How do I edit the matching rule from a log with "Edit Corresponding Rule"?
Short answer
On the WAF Event Logs screen, the record is opened, the attack is selected in the Attacks tab of the preview and Edit Corresponding Rule above the detail block is clicked. The form opens to the page type rule written in the Corresponding Rule row and to the same host group. If the attack was caught on the path, the rule's own edit form (allowed methods, path length and depth, the OWASP Check and OWASP Exclusions settings of the path) opens, and if it was caught in another field, the inspection form of that field (the common rule or the argument rule of the parameter) opens. If the rule has no definition for that field yet, the add form comes with the field of the attack selected; the parameter is not carried into the form, and the form covers all the parameters in the field. In the form, OWASP Check, OWASP Exclusions, the length and count limits, the value pattern, and the allowed and required lists are set manually, and the form is saved with Edit (Add in a new definition); the change is applied without a separate deployment step. Its difference from Allow / Teach is that the change to be written is determined by the user: for example, while teaching removes a value pattern entirely, the pattern can be corrected in this form. Since manual editing leaves no learning record, it is not reverted with Revert Learning. In an attack for which a teaching suggestion cannot be produced, the button is disabled.
Problem: The Teaching Suggestion Is Not the Desired Change
Learning Suggestion suggests removing a value pattern entirely or widening a limit more than necessary (Which rule changes in the background when I Allow / Teach (Learning Suggestion)?). The rule needs to be edited manually and in a controlled way, based on the information in the record.
Solution
Edit Corresponding Rule
- How it works The form of the rule that the attack in the record matched is opened directly; the same form is also reached via WAF Management → N page types → rule → detail panel.
- Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → Event Logs tab → record → Attacks → Edit Corresponding Rule
- Requirement Modify permission in the WAF area
- vService type HTTP
Step-by-Step Configuration
The Left Monitor Panel → WAF-Protected vServices → vService → Event Logs tab is opened.
In the server filter, Date Range is selected; if the record is known, the ID of the request is written in the Request Unique ID field, and Save & Get Logs is clicked.
The row of the record is clicked; the preview opens on the right.
In the Attacks tab of the preview, the attack row is clicked. Description shows the matched section, Corresponding Rule the path of the rule (with an Argument row below it if it is an argument rule), and Learning Suggestion the change the teaching operation will write.
Edit Corresponding Rule above the detail block is clicked. In a path attack, the edit form of the rule opens, and in the other fields, the inspection form of the field opens. If the rule has no definition for the field yet, the add form that opens comes filled with the values in the Any Paths rule and is locked to the common rule that covers all the parameters in the field; the parameter name cannot be entered in this form. If the change is wanted only for a single parameter, the form is closed and the argument rule of the parameter is added with Add Argument Rule for <field> in the detail panel of the rule (argument rules).
The field is edited as needed:
| Learning Suggestion | Correction to be made in the form |
|---|---|
<signature> will be marked as OWASP exclusion | OWASP Check is left checked and the signature is selected in the OWASP Exclusions list |
<field> will be disabled (value pattern) | Instead of being removed, the value pattern (regex) is corrected so that it also covers the legitimate value |
<field> is <old> now and will be <new> | The limit is set to the desired value |
<field>: <name> will be added | The name is added to the allowed list |
The form is saved with Edit (Add in the add form); the button becomes active when no error remains in the form. There is no additional confirmation or deployment step. In a cluster, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent manually with Synchronize.
Verification
The Attacks column of the record that triggered the edited rule is checked; the column shows how many attacks the same request would produce with today's rules.
The first number falls · attack name greenWAF Management → N page types → rule → the tab of the related field is checked.
The entered value · OWASP Check ✓ (number of exclusions)Common Mistakes
- Thinking that the change will be reverted with Revert Learning. Manual editing leaves no learning record; the old value is written back manually from the same form.
- Thinking that the form carries the parameter. The add form comes locked for all the parameters in the field; for a single parameter, the argument rule is added from the detail panel with Add Argument Rule for <field>.
- Forgetting the effect when editing the Any Paths rule. If Corresponding Rule is Any Paths, the change affects all the paths that do not have their own rule for this field; for only one page, the rule of that path is added first (How do I add a new page type manually?).
- Thinking that the values of the common rule will continue when adding an argument rule. A value inspection left empty in the argument rule is removed for that parameter; it does not fall back to the value in the common rule.
- Looking for a rule on a blacklist hit. A blacklist hit has no matching page type rule; the exclusion is written to the Frontend Blacklist Exclusions list in the Whitelist & Blacklist window.
How it is done in the documentation
