Skip to content

Wallarm API Security deployment and maintenance best practices

This article formulates best practices for deployment and maintenance of the Wallarm API Security service.

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 API Security 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 API Security 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 API Security 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 (available starting from Wallarm node version 2.16) 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 enable the libdetection library as follows:

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 blocking functionality, Active threat verification, and some other features will not work):

Enable the allowlisting of the Wallarm Scanner IPs

This configuration is required for the Attack rechecker and Vulnerability scanner modules to reach the tested application without getting their requests blocked by the filtering nodes.

The Active threat verification feature will not work if the scanner's IP addresses are not properly white-listed.

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:

Enable the IP blocking functionality

In addition to blocking individual malicious requests, Wallarm filtering nodes can also block individual end-user IP addresses. The feature is not enabled by default.

It is recommended to enable the feature after completing the application profile learning stage and switching the Wallarm node from monitoring to blocking mode.

Use the following guides to enable the blocking of IP addresses:

After enabling the IP blocking functionality on the filtering nodes you can use the following triggers to control the API Security behavior:

Learn how to perform gradual rollout of Wallarm API Security 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 instance 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 instance 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 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:

  • Monitoring for the increased level of malicious requests detected by the Wallarm nodes. This trigger may signal one of the following potential problems:

    • You are under attack and the Wallarm node is successfully blocking malicious requests. You may consider reviewing the detected attacks and manually denylist (block) reported attacker IP addresses.
    • You have an increased level of false positive attacks detected by the Wallarm nodes. You may consider escalating this to the Wallarm technical support team or manually mark the requests as false positives.
    • If you have the IP blocking functionality enabled on your Wallarm nodes and have the default trigger active but still receive alerts about an increased level of attacks, then the alert may signal that the IP blocking functionality or the trigger is not working as expected.

    See the configured trigger example →

  • Notify that a new user was added to your company account in Wallarm Console

    See the configured trigger example →

  • Mark the requests as the brute-force or forced browsing attack and block the IP addresses the requests were originated from

    Instructions on configuring brute force protection →

  • Notify that new IP addresses were blocked

    See the configured trigger example →

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 instance IDs or unique HTTP request parameters like headers, query string parameters, etc.

  • If you have the trigger configured to automatically block an IP address (for example, default trigger), the system will block the IP for all application instances in a Wallarm account. The IP blocking (denylisting) functionality is controlled by the customer per filtering node and web/API resource using a local configuration setting.

Follow the best practices for the Active threat verification feature

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 →