Recommendations on Configuring the Filter Node for Separated Environments¶
Initial WAF Protection Deployment Process¶
If you perform the initial rollout of WAF protection for environments, it is recommended you use the following approach (you are welcome to adjust it as needed):
Learn about available WAF node deployment options here.
If necessary, learn about available options to separately manage the WAF node configuration for your environments. You can find this information here.
Deploy WAF nodes in your non-production environments with the filtering mode set to
Learn about how to operate, scale, and monitor the WAF solution; confirm the stability of the new network component.
Deploy WAF nodes in your production environment with the filtering mode set to
Implement proper configuration management and monitoring processes for the new WAF component.
Keep the traffic flowing via the WAF nodes in all your environments, including testing and production, for 7-14 days to give the WAF cloud‑based backend some time to learn about your application.
blockingfiltering mode in all your non-production environments and use automated or manual tests to confirm the protected application is working as expected.
blockingfiltering mode in the production environment. Using available methods, confirm that the application is working as expected.
To set up the filtering mode, please use these instructions.
Gradual Rollout of New WAF Changes¶
From time to time changes might be needed in your existing Wallarm WAF infrastructure. Depending on your organization's change management policy, you might be required to test all potentially risky changes in a non-production environment, and then apply the changes in your production environment.
The following approaches are recommended to test and gradually change the configuration of different Wallarm WAF components and features:
Low-level Сonfiguration of Wallarm WAF Filtering Nodes in All Form-factors¶
Low-level configuration of filtering nodes is performed via Docker environment variables, provided NGINX configuration file, Kubernetes Ingress controller parameters, etc. The way of configuration depends on the deployment option.
Low-level configuration can easily be seperately managed for different customer environments using your existing change management processes for infrastructure resources.
Configuration of Wallarm WAF Node Rules¶
Since each rule record can be associated with a different set of application instance IDs or
HOST request headers, the following options are recommended:
First apply a new configuration to a test or development environment, verify the functionality, and then apply the change for the production environment.
Define a request as an attack based on a regular expression WAFrule in the
Experimentalmode. This mode allows the rule to be deployed directly in the production environment without the risk of mistakenly blocking valid end user requests.
Set traffic filtration moderule to control the WAF filtering mode for specific environments and requests. This rule provides additional flexibility in the way WAF protection can be gradually rolled out to protect new end-points and other resources in different environments. By default, the
wallarm_modevalue is used depending on the