Skip to content

Wallarm solution deployment and maintenance best practices

This article formulates best practices for deployment and maintenance of the Wallarm solution.

Understand the power of NGINX

The majority of Wallarm filtering node deployment options use NGINX as the reverse proxy server (the foundation for the Wallarm module), which provides a large range of functionality, modules, and performance/security guides. The following is a collection of helpful Internet articles:

  1. Learn about available Wallarm node deployment options.

  2. Learn about available options to separately manage the Wallarm node configuration for your environments (if necessary).

  3. Deploy Wallarm filtering nodes in your non-production environments with the operation mode set to monitoring.

  4. Learn about how to operate, scale and monitor the Wallarm solution, and confirm the stability of the new network component.

  5. Deploy Wallarm filtering nodes in your production environment with the operation mode set to monitoring.

  6. Implement proper configuration management and monitoring processes for the new Wallarm component.

  7. Keep the traffic flowing via the filtering nodes in all your environments (including testing and production) for 7‑14 days to give the Wallarm cloud-based backend some time to learn about your application.

  8. Enable Wallarm block mode in all your non-production environments and use automated or manual tests to confirm that the protected application is working as expected.

  9. Enable Wallarm block mode in the production environment and use available methods to confirm that the application is working as expected.

Deploy the filtering nodes not just in the production environment but also in testing and staging

The majority of Wallarm service contracts do not limit the number of Wallarm nodes deployed by the customer, so there is no reason to not deploy the filtering nodes across all your environments, including development, testing, staging, etc.

By deploying and using the filtering nodes in all stages of your software development and/or service operation activities you have a better chance of properly testing the whole data flow and minimizing the risk of any unexpected situations in your critical production environment.

Enable the libdetection library

Analyzing requests with the libdetection library significantly improves the filtering node ability to detect SQLi attacks. It is highly recommended for all Wallarm customers to upgrade to the latest version of the filtering node software and keep the libdetection library enabled.

  • In the filtering node version 4.4 and higher libdetection is enabled by default.

  • In the lower versions it is recommended to enable it using the approach for your deployment option.

Configure proper reporting of end-user IP addresses

For Wallarm filtering nodes located behind a load balancer or CDN please make sure to configure your filtering nodes to properly report end-user IP addresses (otherwise the IP list functionality, Active threat verification, and some other features will not work):

Enable proper monitoring of the filtering nodes

It is highly recommended to enable proper monitoring of Wallarm filtering nodes. The collectd service installed with every Wallarm filtering node collects the metrics listed within the link.

The method for setting up the filtering node monitoring depends on its deployment option:

Implement proper redundancy and automatic failover functionality

Like with every other critical component in your production environment, Wallarm nodes should be architected, deployed, and operated with the proper level of redundancy and automatic failover. You should have at least two active Wallarm filtering nodes handling critical end-user requests. The following articles provide relevant information about the topic:

Learn how to use IP address allowlist, denylist, and graylist

In addition to blocking individual malicious requests, Wallarm filtering nodes can also block individual end-user IP addresses. Rules for IPs blocking are configured using allowlists, denylists and graylists.

More details on using IP lists →

Learn how to perform gradual rollout of Wallarm configuration changes

  • Use standard DevOps change management and gradual rollout policies for low-level configuration changes for Wallarm filtering nodes in all form-factors.

  • For traffic filtration rules, use a different set of application IDs or Host request headers.

  • For the Create regexp-based attack indicator rule, in addition to the above‑mentioned ability to be associated with a specific application ID, it can be enabled in monitoring mode (Experimental checkbox) even when the Wallarm node is running in blocking mode.

  • The Set filtration mode rule allows the control of the Wallarm node operation mode (monitoring, safe_blocking or block) from Wallarm Console, similar to the wallarm_mode setting in the NGINX configuration (depending on the wallarm_mode_allow_override setting).

Configure available integrations to receive notifications from the system

Wallarm provides convenient native integrations with Slack, Telegram, PagerDuty, Opsgenie and other systems to quickly send you different security notifications generated by the platform, for example:

  • Newly discovered security vulnerabilities

  • Changes in the company network perimeter

  • Users newly added to the company account via Wallarm Console, etc

You can also use the Triggers functionality to set up custom alerts about different events happening in the system.

Learn the power of the Triggers functionality

Depending on your specific environment we recommend you configure the following triggers:

To optimize traffic processing and attack uploading, Wallarm pre-configures some triggers.

Enable SAML SSO for your account in Wallarm Console

You can use a SAML SSO provider like G Suite, Okta, or OneLogin to centralize the authentication of users in your Wallarm Console account.

Please reach out to your Wallarm account manager or the technical support team to enable SAML SSO for your account, and after that follow these instructions to perform the SAML SSO configuration.

Use the Wallarm Terraform provider for Wallarm Cloud configuration management

Wallarm's official Terraform provider allows you to manage your Wallarm Cloud configuration (users, applications, rules, integrations, etc) using the modern Infrastructure as Code (IaC) approach.

Have a plan to promptly update to newly released Wallarm node versions

Wallarm is constantly working to improve the filtering node software, with new releases available about once a quarter. Please read this document for information about the recommended approach to perform the upgrades, with associated risks and relevant upgrade procedures.

Learn known caveats

  • All Wallarm nodes connected to the same Wallarm account will receive the same set of default and custom rules for traffic filtering. You still can apply different rules for different applications by using proper application IDs or unique HTTP request parameters like headers, query string parameters, etc.

  • If you have the trigger configured to automatically block an IP address (trigger example), the system will block the IP for all applications in a Wallarm account.

Follow the best practices for Active threat verification

One method Wallarm uses to detect vulnerabilities is Active threat verification.

Active threat verification lets you turn attackers into penetration testers and discover possible security issues from their activity as they probe your apps/APIs for vulnerabilities. This module finds possible vulnerabilities by probing application endpoints using real attack data from the traffic. By default this method is disabled.

Learn the best practices for the Active threat verification module configuration →