Technical summary
How should WP Default “Revert” snapshot behavior after applying presets be configured in Aegisify WAF, and what is the current default? is part of the WAF request-inspection, enforcement, visibility, or exception-management surface. This article is grounded in the supplied Aegisify WAF 1.20.13 plugin package. It documents current behavior and defaults rather than relying on older FAQ wording.
Where administrators configure or verify it
Primary wp-admin path: wp-admin → Aegisify WAF → WAF Rules / Settings. Exact controls can be distributed across the related tab/page when the feature is composed of multiple engines.
Current 1.20.13 defaults and related controls
The table below lists settings in the supplied current source that are directly related to this topic. The current default/bound/status shown is code-derived. Where the product does not define a named Medium preset, the shipped default is documented as the baseline operating point rather than inventing a value.
| Setting | Current default / bound / status | Why this default | How to tune safely |
|---|---|---|---|
ddos.groups.wp_admin.block |
180 | The shipped value of 180 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. | Treat this numeric value as the shipped baseline. Adjust one step at a time, document the reason, and verify the operational effect before making the setting more extreme. |
ddos.groups.wp_admin.challenge |
80 | The shipped value of 80 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. | Treat this numeric value as the shipped baseline. Adjust one step at a time, document the reason, and verify the operational effect before making the setting more extreme. |
ddos.groups.wp_admin.rate_limit |
120 | The shipped value of 120 is the current baseline threshold or capacity. It is intentionally finite so the control can provide useful protection or bounded resource use without starting at an extreme. | For abuse/rate thresholds, a lower number is generally more aggressive and can stop attacks sooner but may affect legitimate bursts; a higher number is more tolerant but allows more activity before intervention. Change incrementally and validate against logs. |
ddos.groups.wp_cron.block |
70 | The shipped value of 70 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. | Treat this numeric value as the shipped baseline. Adjust one step at a time, document the reason, and verify the operational effect before making the setting more extreme. |
ddos.groups.wp_cron.challenge |
25 | The shipped value of 25 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. | Treat this numeric value as the shipped baseline. Adjust one step at a time, document the reason, and verify the operational effect before making the setting more extreme. |
ddos.groups.wp_cron.rate_limit |
40 | The shipped value of 40 is the current baseline threshold or capacity. It is intentionally finite so the control can provide useful protection or bounded resource use without starting at an extreme. | For abuse/rate thresholds, a lower number is generally more aggressive and can stop attacks sooner but may affect legitimate bursts; a higher number is more tolerant but allows more activity before intervention. Change incrementally and validate against logs. |
ddos.groups.wp_login.block |
60 | The shipped value of 60 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. | Treat this numeric value as the shipped baseline. Adjust one step at a time, document the reason, and verify the operational effect before making the setting more extreme. |
ddos.groups.wp_login.challenge |
20 | The shipped value of 20 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. | Treat this numeric value as the shipped baseline. Adjust one step at a time, document the reason, and verify the operational effect before making the setting more extreme. |
Adjustment strategy
Change one control at a time, save it through the product UI, reproduce the legitimate and malicious/test flow, and review the product log/status surface. For enforcement controls, use Monitor/Observe first when normal behavior is uncertain; move to Block only after the signal is reliable. For thresholds, do not jump directly from the default to an extreme unless an active incident requires emergency containment and a recovery path exists.
Operational guidance
Use the feature’s logs and current request evidence as the tuning source. Compare normal traffic with the event that triggered the control, then change only the smallest setting required.
Technical keywords
Aegisify WAF, 1.20.13, after, applying, behavior, presets, revert, snapshot, wp, ddos, groups, wp_admin, block, challenge, rate_limit, wp_cron
Source baseline
Verified package: Aegisify WAF 1.20.13. Primary source files: includes/class-aegiswaf-storage.php; includes/class-aegiswaf-ai-security.php; includes/class-aegiswaf-api-security.php; includes/class-aegiswaf-managed-rules.php; includes/ddos/class-aegiswaf-ddos-storage.php; includes/admin/pages/class-aegiswaf-page-waf-rules.php; includes/admin/pages/class-aegiswaf-page-logs.php; includes/admin/pages/class-aegiswaf-page-access.php. If a future plugin version changes these settings, support should re-read the installed version rather than carry these defaults forward automatically.