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:
Follow recommended onboarding steps¶
Learn about available Wallarm node deployment options.
Learn about available options to separately manage the Wallarm node configuration for your environments (if necessary).
Deploy Wallarm filtering nodes in your non-production environments with the operation mode set to
Learn about how to operate, scale and monitor the Wallarm API Security solution, and confirm the stability of the new network component.
Deploy Wallarm filtering nodes in your production environment with the operation mode set to
Implement proper configuration management and monitoring processes for the new Wallarm component.
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.
blockmode in all your non-production environments and use automated or manual tests to confirm that the protected application is working as expected.
blockmode 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):
Instructions for NGINX-based Wallarm nodes (including AWS / GCP images and Docker node container)
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:
Instructions for NGINX-based Wallarm nodes (including AWS / GCP images and Kubernetes sidecars)
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:
Instructions for NGINX-based Wallarm nodes (including AWS / GCP images, Docker node container, and Kubernetes sidecars)
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.
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 IDs or
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 (
block) from Wallarm Console, similar to the
wallarm_modesetting in the NGINX configuration (depending on the
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 denylisting trigger active but still receive alerts about an increased level of attacks, then the alert may signal that the trigger is not working as expected.
Notify that a new user was added to your company account in Wallarm Console
Mark the requests as the brute-force or forced browsing attack and block the IP addresses the requests were originated from
Notify that new IP addresses were blocked
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 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.