Using Web Application Firewall in production

By default, Ambassador Labs rules are configured to block malicious requests. However, when a Web Application Firewall is first deployed in a production environment, it is recommended to set it in a non-blocking mode and monitor its behavior to identify potential issues.

The following procedure can be followed to deploy Ambassador Edge Stack's Web Application Firewall in detection-only mode and customize the rules.

1. Enable Detection Only mode. Detection Only mode will run all rules, but won't execute any disruptive actions. This is configured using the directive SecRuleEngine.

   You also want to enable debug logs, which are necessary to identify false positives. You can them in the WebApplicationFirewall resource as described in the documentation.

   Optionally, Coraza debug logs can be enabled by setting the directive SecDebugLogLevel. These logs are very verbose but can help identify issues when the WebApplicationFirewall logs don't show enough information.

   The following example illustrates this:

2. Identify false positives. Ambassador Edge Stack's container logs will have one or more entries indicating which rules were applied to a request and why.

   For example, the following log entry (formatted for readability) shows that a request to https://34.123.92.3/backend/ was blocked by rule 920350 because the Host header contains an IP address.

   If you enabled Coraza debug logs, use the rule ID to identify entries that are not important as follows:

   • Rules in the range 900000 to 901999 define some Coraza behaviors and can be ignored.

   • Rules like the one below are used to skip other rules and can be ignored as well.

   Each Web Application Firewall configuration file has rules in predefined ranges as follows: Rules in the range 900000 to 900999 are in crs-setup.conf, rules IDs 901000 to 999999 are in waf-rules.conf, and all other rules are in aes-waf.conf.

Customizing Ambassador Labs rules

There are several options to configure if/when a rule runs:

1. Disable a rule completely.
2. Apply a rule to some requests.

Disabling a rule completely

To disable a rule, follow the instructions in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example, save the configuration as a ConfigMap, and load it after waf-rules.conf.

For example, let's say that we want to disable the rule with ID 913110. The first step is to create the configuration:

And then load it after waf-rules.conf:

Applying a rule to some requests

To apply a rule only to some requests, update it as described in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example and load the new settings before waf-rules.conf.

The following example shows how to disable all rules tagged attack-sqli when the URI does not start with '/api/':