WAF in Roxy-WI 9.2

A WAF inspects HTTP requests and applies rules to detect or block unwanted traffic. Roxy-WI manages a separate WAF agent for HAProxy and the ModSecurity module for NGINX. Select the correct service and server before changing rules.

The overview uses server cards with search, status filters and cluster information. Open the status details for diagnostics; use Manage rules for the rule catalog and Logs for events and audit transactions.

Roxy-WI installs ModSecurity with OWASP Core Rule Set (CRS) rules. Review the rules against your application's traffic before enabling blocking. The Configured WAF mode selector saves On, Off or DetectionOnly in the selected server's modsecurity.conf.

Changing the mode saves it on that server only and does not restart or reload the service. Set the intended mode on each node, then use the apply workflow. Rule synchronization does not copy this mode setting.

Rule paths use the current group's haproxy_dir or nginx_dir, followed by waf/rules. The default directories are /etc/haproxy/waf/rules/ and /etc/nginx/waf/rules/; custom service directories are supported.

1. Open HAProxy → WAF, find the server and click Install WAF if required. Verify SSH/sudo access and the configured service or container paths.
2. Inspect the card's diagnostics. The Actions menu starts or stops the WAF agent; Restart WAF applies saved rules and confirms agent readiness.
3. Select the configured mode, open Manage rules, and edit or create the required rules.
4. Use Save to store an edit, or Save and restart to apply it. A save alone does not check HAProxy WAF rule syntax. Application checks that the agent responds, including its SPOA protocol.
5. Inspect the apply status and WAF logs. Enable the Metrics checkbox if WAF connection collection is required and the Metrics service is available.

The HAProxy WAF agent requires a restart rather than a reload. Installation also checks the complete active HAProxy configuration. For Docker, verify persistent WAF mounts and the configured startup paths when diagnostics report a preparation error.

Open Manage rules. The Enabled checkbox changes the saved Include state. Under Actions, use View/Edit for a manual rule, WAF Config Wizard for a generated rule, or Delete to remove a rule. These changes require confirmed application.

To create a text rule, choose Add → Manual rule editor, supply a name, description and a filename such as custom-rule.conf, then edit its content. Use a filename without directory separators. Creation, toggling and deletion also affect the Master's linked Slaves; see synchronization and recovery.

1. Open NGINX → WAF and use Install WAF on the selected server. Installation prepares ModSecurity, CRS and the service's WAF configuration.
2. Use Actions → Enable or Disable to switch the NGINX ModSecurity integration. This is separate from the saved Configured WAF mode.
3. Set the configured mode and edit rules. Save validates the full NGINX configuration and stores the file without reloading.
4. Use Save and reload in the editor or Reload NGINX on the WAF page to apply saved changes. Check the confirmation and service diagnostics.

NGINX WAF runs inside NGINX, so applying rules reloads NGINX rather than restarting a separate WAF agent. Failed validation restores the previous edited file; failed reload triggers a recovery attempt. Read any recovery error before trying another change.

For virtual-host scoping and paths, see the NGINX WAF reference.

Use Manage rules on the NGINX card. Manual rules, generated rules, the Enabled checkbox and deletion follow the same catalog workflow as HAProxy, with Reload NGINX as the apply action. Includes are managed through nginx_dir/waf/waf.conf.

Do not create duplicate rules manually on Slaves. Roxy-WI creates the matching catalog entries during synchronization. Review the target named in a conflict or failure message.

WAF Config Wizard requires an active Enterprise plan or higher. See plans and availability. It creates rules and CRS exclusions for both HAProxy and NGINX.

1. From Manage rules, choose Add → WAF Config Wizard. Select the server and enter the rule name, description and .conf filename.
2. Keep Choose a free ID automatically enabled or choose an unused ID from 1 to 99999. IDs are checked on the Master and linked Slaves again when saving.
3. Choose Rule or CRS rule exclusion. Combine up to ten conditions with All conditions (AND) or Any condition (OR).
4. Inspect URL path, client IP/network, HTTP method, header or request parameter. Text matching supports Equals, Starts with and Contains; values are literal. IP matching accepts comma-separated addresses or CIDR networks.
5. For a rule, choose Block (403) or Log only. For an exclusion, specify the CRS rule ID and optionally a request parameter. Exclusions run before CRS: conditions may use path, IP, method or headers, but not request parameters. Select All requests only for an intentionally global exclusion.
6. Click Generate config and review the preview. OR conditions allocate consecutive IDs; the preview shows them. The excluded CRS rule must exist on every target.
7. Click Save or the service's Save and restart/Save and reload action, then inspect the apply state.

Generated files contain wizard metadata and must be edited through the wizard. Manual rules retain the text editor. If a generated file's metadata was changed or lost, restore the generated file before editing it. An existing generated rule's name, filename and description identify it and remain read-only.

Saving a file, changing its Enabled state or choosing a mode does not by itself confirm that the running service uses it. Apply the saved configuration with Restart WAF for HAProxy or Reload NGINX for NGINX. These are the service-specific labels shown by the 9.2 interface.

The indicator tracks WAF actions made through Roxy-WI. It does not detect manual SSH edits or service actions performed elsewhere. A confirmed state is not an independent test of your application's protection rules.

Rule operations on a Master synchronize to its directly linked Slaves in the same group. The requested service must be enabled and accessible on each target. Roxy-WI synchronizes rule files, matching catalog entries and Include state for creation, edits, enable/disable actions and deletion. It does not recursively traverse another level of Slaves.

Matching entries are created automatically; an unrelated rule or ambiguous Include with the same identity causes a conflict. Do not overwrite such a file to bypass the error. Inspect its ownership and the configuration on the named target first.

A multi-server operation can fail after some servers have changed. Roxy-WI reports the failed target and leaves changes pending; it does not promise an all-server rollback. Restore connectivity or resolve the conflict, then repeat the original operation. The apply action reconciles the saved rule catalog before applying, which also retries incomplete synchronization. Retry a failed deletion as a deletion.

When an editor apply fails, the local file/service recovery attempt can also fail. Inspect the WAF or NGINX status and the Roxy-WI logs, including any reported backup location. Confirm every target before considering recovery complete.

Open a server card's status details for the detected process/module state, explanation and recovery guidance. Check SSH credentials, noninteractive sudo, service/container paths and mounts when status is unavailable. For an invalid saved mode, check that modsecurity.conf has exactly one active global SecRuleEngine directive.

Use Logs and choose WAF events or WAF audit. Events show service errors and WAF messages; Audit shows complete ModSecurity transactions. See the WAF log guide for search, Live mode, rotation and reader limits.