How does Rule “Contains (all)” matching (one token per line; ALL must match) work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does Rule “Contains (all)” matching (one token per line; ALL must match) work in Aegisify WAF, and what should administrators verify? governs deterministic inspection of AI-facing traffic, including prompt-injection signals, sensitive-data handling, provider/model policy, agentic action controls, signed actions, and resource budgets. 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 → AI Security. 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 custom_rules.allowed_actions Allowed values: ["log","block","skip_waf"] This list is the current accepted-value set enforced by the supplied implementation. Choose only from the supported set. Narrower methods/actions reduce unintended scope; unsupported values are normalized or rejected by the current implementation. custom_rules.allowed_methods Allowed values: ["ANY","GET","POST","PUT","PATCH","DELETE","HEAD","OPTIONS"] This list is the current accepted-value set enforced by the supplied implementation. Choose only from the supported set. Narrower methods/actions reduce unintended scope; unsupported values are normalized or rejected by the current implementation. managed_rules.challenge.enabled ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. managed_rules.challenge.ttl_seconds 1800 The shipped value of 1800 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. custom_rules.action_default log “log” is the shipped baseline so administrators can collect evidence and verify normal traffic or behavior before moving to stronger enforcement where applicable. Use the shipped observation mode while establishing a baseline. Move toward enforcement only when logs show the signal is reliable. Returning to monitor/observe is preferable to disabling a control entirely during false-positive tuning. custom_rules.free_max_rows Maximum: 5 5 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. custom_rules.global_or_root_waf_exclusions_rejected Rejected The current safety logic rejects this condition to prevent an overly broad security bypass. This row documents fixed current-version behavior or a capability boundary. Change the related user-facing setting rather than attempting to tune this reference value. custom_rules.import_max_bytes Maximum: 524288 524288 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. 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 On a production WordPress site, a sudden block spike after a plugin/API deployment should first be investigated in WAF logs. Narrow the issue to the exact route, rule family, client identity, or payload characteristic. Prefer a precise exclusion/allowlist or threshold adjustment over disabling broad protection. Technical keywords Aegisify WAF, 1.20.13, all, contains, custom, line, managed, match, matching, must, one, per, rule, rules, signature, token 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.

How should Rule actions: Log / Block / Allow be configured in Aegisify WAF, and what is the current default?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How should Rule actions: Log / Block / Allow be configured in Aegisify WAF, and what is the current default? provides security telemetry and forensic context for inspected, challenged, rate-limited, blocked, and operational events. 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 → Logs. 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 logs.alert_rule.minimum_events_default 3 The shipped value of 3 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. 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. logs.alert_rule.minimum_events_max Maximum: 100 100 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. logs.alert_rule.minimum_events_min Minimum: 2 2 is the current code-enforced minimum boundary, not a recommended default. Values below it are clamped or rejected by the current save path. Do not tune below this boundary. Adjust the corresponding primary setting at or above this minimum and validate legitimate traffic/workload. logs.alert_rule.blank_recipients_use_wp_admin_email Blank → WordPress admin email This is the current recipient fallback behavior when no explicit alert email is configured. This row documents fixed current-version behavior or a capability boundary. Change the related user-facing setting rather than attempting to tune this reference value. logs.alert_rule.cooldown_seconds_default 1800 The shipped value of 1800 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. logs.alert_rule.cooldown_seconds_max Maximum: 86400 86400 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. logs.alert_rule.cooldown_seconds_min Minimum: 60 60 is the current code-enforced minimum boundary, not a recommended default. Values below it are clamped or rejected by the current save path. Do not tune below this boundary. Adjust the corresponding primary setting at or above this minimum and validate legitimate traffic/workload. logs.alert_rule.window_seconds_default 300 The shipped value of 300 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. 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 On a production WordPress site, a sudden block spike after a plugin/API deployment should first be investigated in WAF logs. Narrow the issue to the exact route, rule family, client identity, or payload characteristic. Prefer a precise exclusion/allowlist or threshold adjustment over disabling broad protection. Technical keywords Aegisify WAF, 1.20.13, actions, allow, audit, block, custom, event, events, log, logging, logs, managed, rule, rules, signature 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.

How does Rule methods: ANY / GET / POST / PUT / PATCH / DELETE / HEAD / OPTIONS work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does Rule methods: ANY / GET / POST / PUT / PATCH / DELETE / HEAD / OPTIONS work in Aegisify WAF, and what should administrators verify? controls deterministic request inspection and matching for common web-attack techniques, custom rules, managed signatures, and heuristics. 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 custom_rules.allowed_methods Allowed values: ["ANY","GET","POST","PUT","PATCH","DELETE","HEAD","OPTIONS"] This list is the current accepted-value set enforced by the supplied implementation. Choose only from the supported set. Narrower methods/actions reduce unintended scope; unsupported values are normalized or rejected by the current implementation. managed_rules.inspect_headers ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. custom_rules.action_default log “log” is the shipped baseline so administrators can collect evidence and verify normal traffic or behavior before moving to stronger enforcement where applicable. Use the shipped observation mode while establishing a baseline. Move toward enforcement only when logs show the signal is reliable. Returning to monitor/observe is preferable to disabling a control entirely during false-positive tuning. custom_rules.allowed_actions Allowed values: ["log","block","skip_waf"] This list is the current accepted-value set enforced by the supplied implementation. Choose only from the supported set. Narrower methods/actions reduce unintended scope; unsupported values are normalized or rejected by the current implementation. custom_rules.free_max_rows Maximum: 5 5 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. custom_rules.global_or_root_waf_exclusions_rejected Rejected The current safety logic rejects this condition to prevent an overly broad security bypass. This row documents fixed current-version behavior or a capability boundary. Change the related user-facing setting rather than attempting to tune this reference value. custom_rules.import_max_bytes Maximum: 524288 524288 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. custom_rules.import_max_rules Maximum: 100 100 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. 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 On a production WordPress site, a sudden block spike after a plugin/API deployment should first be investigated in WAF logs. Narrow the issue to the exact route, rule family, client identity, or payload characteristic. Prefer a precise exclusion/allowlist or threshold adjustment over disabling broad protection. Technical keywords Aegisify WAF, 1.20.13, any, custom, delete, get, head, managed, methods, options, patch, post, put, rule, rules, signature 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.

How does Custom Rules engine (path pattern matching with wildcards * and ?) work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does Custom Rules engine (path pattern matching with wildcards * and ?) work in Aegisify WAF, and what should administrators verify? controls deterministic request inspection and matching for common web-attack techniques, custom rules, managed signatures, and heuristics. 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. Custom-rule mechanics and limits Custom rules use explicit numeric priority; lower values run first. The current UI accepts priorities from 1 through 9,999 and uses 100 as the base/default when a priority is absent. HTTP method defaults to ANY and can be narrowed to GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS. The safe action default is Log; Block terminates validated matches, while Skip Core WAF inspection is a narrow compatibility exclusion that bypasses the remaining Core WAF layers for that matching request. Regex conditions are Pro-only in the current editor; invalid regular expressions prevent the ruleset from being saved/imported. Root-wide or global Core WAF exclusions are rejected. Free save is bounded to 5 rows; Pro save to 50 rows. Pro JSON import is bounded to 512 KB and the first 100 rows. 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 custom_rules.action_default log “log” is the shipped baseline so administrators can collect evidence and verify normal traffic or behavior before moving to stronger enforcement where applicable. Use the shipped observation mode while establishing a baseline. Move toward enforcement only when logs show the signal is reliable. Returning to monitor/observe is preferable to disabling a control entirely during false-positive tuning. custom_rules.allowed_actions Allowed values: ["log","block","skip_waf"] This list is the current accepted-value set enforced by the supplied implementation. Choose only from the supported set. Narrower methods/actions reduce unintended scope; unsupported values are normalized or rejected by the current implementation. custom_rules.allowed_methods Allowed values: ["ANY","GET","POST","PUT","PATCH","DELETE","HEAD","OPTIONS"] This list is the current accepted-value set enforced by the supplied implementation. Choose only from the supported set. Narrower methods/actions reduce unintended scope; unsupported values are normalized or rejected by the current implementation. custom_rules.free_max_rows Maximum: 5 5 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. custom_rules.global_or_root_waf_exclusions_rejected Rejected The current safety logic rejects this condition to prevent an overly broad security bypass. This row documents fixed current-version behavior or a capability boundary. Change the related user-facing setting rather than attempting to tune this reference value. custom_rules.import_max_bytes Maximum: 524288 524288 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. custom_rules.import_max_rules Maximum: 100 100 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. custom_rules.import_requires_pro PRO required The current UI/save path makes this capability license-gated rather than a site-tuning default. This row documents fixed current-version behavior or a capability boundary. Change the related user-facing setting rather than attempting to tune this reference value. 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 On a production WordPress site, a sudden block spike after a plugin/API deployment should first be investigated in WAF logs. Narrow the issue to the exact route, rule family, client identity, or payload characteristic. Prefer a precise exclusion/allowlist or threshold adjustment over disabling broad protection. Technical keywords Aegisify WAF, 1.20.13, custom, engine, managed, matching, path, pattern, rule, rules, signature, wildcards, custom_rules, action_default, allowed_actions, allowed_methods 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.

How does Visual Intelligence: 8 charts across WAF, API Shield, Bot, DDoS, Attack Story work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does Visual Intelligence: 8 charts across WAF, API Shield, Bot, DDoS, Attack Story work in Aegisify WAF, and what should administrators verify? provides security telemetry and forensic context for inspected, logged, challenged, rate-limited, blocked, and operational events across WAF subsystems. 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 → Logs. 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 api_security.identity_rate_basis adaptive “adaptive” is the shipped baseline and is the closest current code-defined baseline/medium operating point. Use stricter behavior only after reviewing site-specific evidence. Treat the shipped value as the baseline/medium operating point. A stricter profile generally increases sensitivity and may increase false positives or workload; a more permissive profile generally reduces intervention but can allow more unwanted activity. api_security.identity_rate_limit 0 Disabled in the shipped baseline because enabling it can change live request handling, indexing behavior, automation, enforcement, or integration traffic and should be reviewed for the specific site first. OFF leaves the behavior inactive. Turn it ON only after checking prerequisites and expected traffic/content because this setting can introduce enforcement, automation, indexing, outbound integration, or additional processing depending on the feature. api_security.identity_rate_window 60 The shipped value of 60 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. 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.rest.challenge 160 The shipped value of 160 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.rest.rate_limit 220 The shipped value of 220 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.rest.block 320 The shipped value of 320 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. api_security.ajax_enforcement_enabled OFF / false Disabled in the shipped baseline because enabling it can change live request handling, indexing behavior, automation, enforcement, or integration traffic and should be reviewed for the specific site first. OFF leaves the behavior inactive. Turn it ON only after checking prerequisites and expected traffic/content because this setting can introduce enforcement, automation, indexing, outbound integration, or additional processing depending on the feature. api_security.ajax_monitoring_enabled OFF / false Disabled in the shipped baseline because enabling it can change live request handling, indexing behavior, automation, enforcement, or integration traffic and should be reviewed for the specific site first. OFF leaves the behavior inactive. Turn it ON only after checking prerequisites and expected traffic/content because this setting can introduce enforcement, automation, indexing, outbound integration, or additional processing depending on the feature. 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 On a production WordPress site, a sudden block spike after a plugin/API deployment should first be investigated in WAF logs. Narrow the issue to the exact route, rule family, client identity, or payload characteristic. Prefer a precise exclusion/allowlist or threshold adjustment over disabling broad protection. Technical keywords Aegisify WAF, 1.20.13, abuse, across, agent, ajax, api, attack, automation, bot, challenge, charts, crawler, ddos, endpoint, graphql 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.

How does Attack Story Narrative analysis generation (incident-style explanation) work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does Attack Story Narrative analysis generation (incident-style explanation) work in Aegisify WAF, and what should administrators verify? provides security telemetry and forensic context for inspected, logged, challenged, rate-limited, blocked, and operational events across WAF subsystems. 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 → Logs. 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 logs.attack_story_top_items 10 The shipped value of 10 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. 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. logs.attack_story_window_hours 24 The shipped value of 24 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. app_monitoring.alert_history_limit 50 The shipped value of 50 is the current storage/forensics baseline, balancing historical visibility against database or filesystem growth. Increase for longer forensic/compliance history at the cost of more storage; decrease to control growth, understanding that older evidence will be unavailable sooner. common_attacks.block_known_sensitive_paths ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. common_attacks.credential_block_seconds 900 The shipped value of 900 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. common_attacks.credential_distinct_ip_limit 8 The shipped value of 8 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. common_attacks.credential_distinct_user_limit 6 The shipped value of 6 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. common_attacks.credential_distributed_source_min Minimum: 3 3 is the current code-enforced minimum boundary, not a recommended default. Values below it are clamped or rejected by the current save path. Do not tune below this boundary. Adjust the corresponding primary setting at or above this minimum and validate legitimate traffic/workload. 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, analysis, attack, explanation, generation, incident, narrative, story, style, logs, attack_story_top_items, attack_story_window_hours, app_monitoring, alert_history_limit, common_attacks 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.

How does Attack Story Deep Dive Reports work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does Attack Story Deep Dive Reports work in Aegisify WAF, and what should administrators verify? provides security telemetry and forensic context for inspected, logged, challenged, rate-limited, blocked, and operational events across WAF subsystems. 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 → Logs. 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 logs.attack_story_top_items 10 The shipped value of 10 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. 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. logs.attack_story_window_hours 24 The shipped value of 24 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. app_monitoring.alert_history_limit 50 The shipped value of 50 is the current storage/forensics baseline, balancing historical visibility against database or filesystem growth. Increase for longer forensic/compliance history at the cost of more storage; decrease to control growth, understanding that older evidence will be unavailable sooner. common_attacks.block_known_sensitive_paths ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. common_attacks.credential_block_seconds 900 The shipped value of 900 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. common_attacks.credential_distinct_ip_limit 8 The shipped value of 8 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. common_attacks.credential_distinct_user_limit 6 The shipped value of 6 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. common_attacks.credential_distributed_source_min Minimum: 3 3 is the current code-enforced minimum boundary, not a recommended default. Values below it are clamped or rejected by the current save path. Do not tune below this boundary. Adjust the corresponding primary setting at or above this minimum and validate legitimate traffic/workload. 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, attack, deep, dive, reports, story, logs, attack_story_top_items, attack_story_window_hours, app_monitoring, alert_history_limit, common_attacks, block_known_sensitive_paths, credential_block_seconds, credential_distinct_ip_limit 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.

How does Attack Story (Last 24h): inspected requests, events, unique IPs/routes, top detected types/rules) work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does Attack Story (Last 24h): inspected requests, events, unique IPs/routes, top detected types/rules) work in Aegisify WAF, and what should administrators verify? provides security telemetry and forensic context for inspected, logged, challenged, rate-limited, blocked, and operational events across WAF subsystems. 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 → Logs. 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 logs.alert_rule.minimum_events_default 3 The shipped value of 3 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. 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. logs.alert_rule.minimum_events_max Maximum: 100 100 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. logs.alert_rule.minimum_events_min Minimum: 2 2 is the current code-enforced minimum boundary, not a recommended default. Values below it are clamped or rejected by the current save path. Do not tune below this boundary. Adjust the corresponding primary setting at or above this minimum and validate legitimate traffic/workload. logs.alert_rule.blank_recipients_use_wp_admin_email Blank → WordPress admin email This is the current recipient fallback behavior when no explicit alert email is configured. This row documents fixed current-version behavior or a capability boundary. Change the related user-facing setting rather than attempting to tune this reference value. logs.alert_rule.cooldown_seconds_default 1800 The shipped value of 1800 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. logs.alert_rule.cooldown_seconds_max Maximum: 86400 86400 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. logs.alert_rule.cooldown_seconds_min Minimum: 60 60 is the current code-enforced minimum boundary, not a recommended default. Values below it are clamped or rejected by the current save path. Do not tune below this boundary. Adjust the corresponding primary setting at or above this minimum and validate legitimate traffic/workload. logs.alert_rule.window_seconds_default 300 The shipped value of 300 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. 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 On a production WordPress site, a sudden block spike after a plugin/API deployment should first be investigated in WAF logs. Narrow the issue to the exact route, rule family, client identity, or payload characteristic. Prefer a precise exclusion/allowlist or threshold adjustment over disabling broad protection. Technical keywords Aegisify WAF, 1.20.13, 24h, attack, custom, detected, events, inspected, ips, last, managed, requests, routes, rule, rules, signature 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.

How should Retention days setting (auto-delete older logs) + manual cleanup button be configured in Aegisify WAF, and what is the current default?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How should Retention days setting (auto-delete older logs) + manual cleanup button be configured in Aegisify WAF, and what is the current default? provides security telemetry and forensic context for inspected, logged, challenged, rate-limited, blocked, and operational events across WAF subsystems. 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 → Logs. 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 logs.flat_file_retention_days 7 The shipped value of 7 is the current storage/forensics baseline, balancing historical visibility against database or filesystem growth. Increase for longer forensic/compliance history at the cost of more storage; decrease to control growth, understanding that older evidence will be unavailable sooner. logs.retention_days 30 The shipped value of 30 is the current storage/forensics baseline, balancing historical visibility against database or filesystem growth. Increase for longer forensic/compliance history at the cost of more storage; decrease to control growth, understanding that older evidence will be unavailable sooner. logs.dashboard_window_days 7 The shipped value of 7 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. logs.alert_rule.minimum_events_default 3 The shipped value of 3 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. 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. logs.alert_rule.minimum_events_max Maximum: 100 100 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. logs.alert_rule.minimum_events_min Minimum: 2 2 is the current code-enforced minimum boundary, not a recommended default. Values below it are clamped or rejected by the current save path. Do not tune below this boundary. Adjust the corresponding primary setting at or above this minimum and validate legitimate traffic/workload. logs.include_operational_events ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. api_security.audit_log_level metadata “metadata” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. 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, archive, audit, auto, button, cleanup, days, delete, event, events, history, log, logging, logs, manual 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.

How does “Alerts only” filtering work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does “Alerts only” filtering work in Aegisify WAF, and what should administrators verify? 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 → Logs. 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 api_security.monitor_alerts_enabled OFF / false Disabled in the shipped baseline because enabling it can change live request handling, indexing behavior, automation, enforcement, or integration traffic and should be reviewed for the specific site first. OFF leaves the behavior inactive. Turn it ON only after checking prerequisites and expected traffic/content because this setting can introduce enforcement, automation, indexing, outbound integration, or additional processing depending on the feature. app_monitoring.alerts_enabled ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. logs.alerts [] Blank or empty by default because this value depends on the site, organization, route, identity source, recipient, API credential, or exception policy. Configure it only with verified site-specific data. Supply only validated site-specific values. Leaving it blank/empty means no custom value, exception, recipient, credential, route, or policy has been asserted by default. wp_protect.rest_only_unauth ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. 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, alerts, filtering, only, api_security, monitor_alerts_enabled, app_monitoring, alerts_enabled, logs, wp_protect, rest_only_unauth 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.

Archives: FAQs | Aegisify - WordPress Tools, Security…

Categories: AegisWAF
How does Rule “Contains (all)” matching (one token per line; ALL must match) work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How should Rule actions: Log / Block / Allow be configured in Aegisify WAF, and what is the current default?
read more
Categories: AegisWAF
How does Rule methods: ANY / GET / POST / PUT / PATCH / DELETE / HEAD / OPTIONS work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How does Custom Rules engine (path pattern matching with wildcards * and ?) work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How does Visual Intelligence: 8 charts across WAF, API Shield, Bot, DDoS, Attack Story work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How does Attack Story Narrative analysis generation (incident-style explanation) work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How does Attack Story Deep Dive Reports work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How does Attack Story (Last 24h): inspected requests, events, unique IPs/routes, top detected types/rules) work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How should Retention days setting (auto-delete older logs) + manual cleanup button be configured in Aegisify WAF, and what is the current default?
read more
Categories: AegisWAF
How does “Alerts only” filtering work in Aegisify WAF, and what should administrators verify?
read more

What’s New At Aegisify