It's now easier to configure protection against API abuse, bruteforce or dirbusting attacks. Use an updated interface of Triggers:

• The Bruteforce trigger defines classic bruteforce attack protection against specific URI based on the number of incoming requests.
• The Forced browsing trigger forced browsing attacks allows to protect your apps against dirbusting (based on application 404 response codes)

In the simplest case, it is enough to enter the URI when creating the trigger. Wallarm will collect statistics from all the distributed Wallarm nodes deployed across your whole infrastructure.

When required, you can also use regular expressions (for example. wildcard URLs) or specify specific request headers (such as cookies) using the advanced view. Read more in our documentation.

Note: There is no need to edit your existing rules. However, previous rules “Add forced browsing attack tag to requests”, “Add brute force attacks tag to requests” will no longer be visible in the Rules section.

The new version of Wallarm Node is released. We recommend planning an upgrade soon.

The main changes for Node 3.4:

• Added support for CloudLinux OS 6.x
• Version of Envoy used in the Wallarm Envoy-based Docker image has been increased to 1.18.4

Wallarm Node 2.18 and lower are no longer supported. Note: Existing nodes will continue to operate as usual. However, we won't provide hotfixes and will limit support requests.

Before upgrading the agents, please carefully review the list of changes and general recommendations. Should you have any questions, feel free to contact our support team at support@wallarm.com.

We are happy to share recent work on the quality of attack and vulnerability detection!

We have added the support for new attack type detection: SSTI, SSI and Email Injection.

The rule set for detection of other attack types (SQLi, XSS, Path Traversal, Scanner, RCE) is now wider and more accurate.

We have also added the rules for Wallarm Scanner to detect new vulnerabilities in applications:

• Remote Code Execution in Confluence Server and Data Center — CVE‑2021‑26084
• Path Traversal and Remote Code Execution in Apache HTTP Server 2.4.49 — CVE‑2021‑41773
• Remote Code Execution in Microsoft Exchange Server — CVE‑2021‑26855
• Remote Code Execution in Apache Druid Embedded — CVE‑2021‑25646
• Remote Code Execution in Laravel Debug Mode — CVE‑2021‑3129
• Directory Traversal in ffay lanproxy 0.1 — CVE‑2021‑3019
• NoSQL injection in Agentejo Cockpit before 0.11.2 via the Controller/Auth.php resetpassword function — CVE‑2020‑35847

The changes are already supported by the Wallarm components. Additional product configuration to apply the changes is not required.

Notifications to your Microsoft Teams channel are now available.
Get updates for security and system events:

• Vulnerabilities detected
• Scope changed: updates in hosts, services, and domains
• Exceeded threshold of attack, hit, or incident number
• Newly added users
• Deleted or disabled integration

Read more about setting up the integration with Microsoft Teams on our documentation portal.

Now rule conditions can be configured faster. It is enough to specify a request address in the newly added URI constructor form, and we will automatically convert it to a variety of conditions for each request point. The conversion result can be extended in the advanced edit form you used before.

The URI constructor accepts regular expressions and several other formats. For more information, check our documentation.

Reduce the number of false positives by using the following rules:

• Disable base64 parser for parameters with unencoded values
• Allow file upload and binary data transfer in parameters
• Disable search some attack types for specific endpoints, such as SQL injection, in posts on the DBA forum

With other rule types, you can also add headers to the server response or control the mode of the Active threat verification module. For the detailed description of the new rules, check our
 documentation.

P.S. If our support team has already created these rules, they will be displayed in the Rules section.

Should your customers come from data centers? Not typically. It could be helpful to exclude some of the traffic sources to improve the security of applications and APIs.

With Wallarm, you can block traffic originated from a specific country based on compliance requirements ,or block Tor exit nodes and popular proxy servers frequently generating a lot of malicious requests.

Wallarm also identifies and displays in the Wallarm Console the IP address sources, i.e countries, data centers, VPN, and residential proxies.

Read more about the new blocking features on our documentation portal.

We rely on the data from 3rd party providers including IP2Location which is a partner of Wallarm.

We are pleased to announce the general availability of the Wallarm Node 3.2. This is a major update recommended to install.

Highlights

• Support for new filtration mode, safe blocking
• Management of IP address whitelist via the Wallarm Console
• Ability to whitelist, blacklist, or greylist a subnet, Tor network IPs, VPN IPs, a group of IP addresses registered in a specific country or data center
• Ability to whitelist, blacklist, or greylist request sources for specific applications
• New module API Discovery that automatically identifies the application API structure based on real traffic analysis
• The number of requests originated from blacklisted IPs is now displayed in the statistic service output, in the new parameter blockedbyacl and in the existing parameters requests, blocked

How to upgrade

Upgraded packages of Wallarm node are already available for installation from the repositories, AWS AMI and GCP VM images. The migration guide is available on the docs portal.

What do you know about your APIs? Why are the vulnerable v2 and v3 still exposed if they are deprecated for almost a year? What else is exposed, and you don’t even know? Are Swagger specs up to date? (Teaser: Surely not). A lot of questions, right? Meet Wallarm’s latest feature for API Discovery and Observability to better understand and protect your APIs.

Wallarm API Discovery identifies all APIs including shadow and zombie APIs and gives you up-to-date specs — based on the actual API usage.

So how where exactly can API Discovery help? There are two major ways:

• Firstly, API inventory. The larger the company, the fewer the people that actually know what you have exposed. Different endpoints are owned by different teams. Add here multiple versions of APIs — some that are already deprecated and some still maintained — and this very soon becomes a total mess. You can easily have some outdated (and vulnerable) version of the API method exposed — and nobody will even know! It’s called a Shadow API. The only way to get full visibility is to see what APIs are actually used and how they are used, based on the traffic.
• Secondly, up-to-date API specs. We bet you wouldn’t be surprised that specs are very often behind. It’s a life after all and docs are rarely properly updated. But you would be amazed by how significant the difference between docs and reality can be. For some APIs, you can have no Swagger at all. Or, you can have docs that clearly say that /checkout method has five parameters. Meanwhile, real traffic can show that there are plenty of requests that actually have six parameters, with one of them optional. Think of it as Swagger / OpenAPI specs generated based on the traffic.

Join the early access program by sending a note to request@wallarm.com and read a blog post for more details.

Now we have a Wallarm service status page available at https://status.wallarm.com. The page displays live and historical data on the availability of the Wallarm Console and Wallarm API services for each Wallarm Cloud.

You can use Subscribe to updates to receive a notification when a service status changes via Email, Slack, SMS, Webhooks, and other methods.

On this page, we also post planned maintenance announcements and a description of which parts of the service may not be available during maintenance.