A new type of integration is available in the Wallarm Console - Webhook. Webhook is a widespread technology for integrating web services with each other based on callback technology.

The modern approach in information security is the use of specialized tools that are closely integrated with one another. Therefore, one of Wallarm’s priority areas is the support of modern security tools.

You can now send Wallarm WAF events to Webhook or configure conditions and filters for the Trigger to send a particular message to Webhook when conditions are met.

For setting up Webhook integration, only the API URL is required. You can find more details in our documentation.

With the growing complexity of new applications, technology stacks, and evolving attack techniques, we can implement regular improvements in how the Wallarm WAF detects attacks. This month we have added new Scanner rules to detect:

• Open access to the Consul UI web interface. Read the details on our blog
• Server-Side Template Injection in SEOmatic plugin for Craft CMS - CVE-2020-9757
• Reflected Code Injection in Citrix ADC and NetScaler Gateway - СVE-2020-8194
• Remote code execution in WebLogic Server - CVE-2020-14882
• Remote code execution in Liferay CE Portal - CVE-2019-11444

We have also improved the detection of Bash command injection and path traversal attacks in Wallarm WAF.

Wallarm extends deployment support for the Wallarm filtering node to more platforms. We consistently monitor new application architectures and the latest trends in application deployment. Additionally, as current platforms evolve and release new versions, we adapt the software and test compatibility to support the latest releases.

In the new 2.16 version of WAF nodes, our clients have access to:

• Updated packages for installing WAF on CentOS 8.

Updated packages are already available in our repositories!

Next in line is support for the Ubuntu 20.04 LTS (Focal Fossa) release!

With the growing complexity of new applications, technology stacks, and evolving attack techniques, we can implement regular improvements in how the Wallarm WAF detects attacks. This month we have added new Scanner rules to detect:

• Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Web Interface Vulnerability — CVE-2020-3452
• Open web interfaces for VMware ESXi, vCenter, and vSphere.

We've also added new rules for detecting attacks in the Wallarm WAF:

• RCE in MobileIron Core & Connector, Sentry and Monitor and Reporting Database (RDB) — CVE-2020-15505
• RCE on some NGINX + PHP-FPM installation configurations — CVE-2019-11043

In addition, Bitrix 0-day LFI detection is available within our WAF and Scanner. We sent notifications and created virtual patches for all clients that have this vulnerability in their applications.

You have probably already noticed that new blocks have appeared in the WAF node card in the Wallarm Console with information about the versions of the LOM file and proton.db used.

Starting from version 2.16 of the WAF node, these sections will display information about the versions of installed components and indicators of available updates.

The latest versions of the Wallarm WAF node uses new technologies and capabilities to protect applications and APIs from hacker attacks. We recommend that you always keep WAF nodes up to date.

We remind you that we only support the last two versions of the Wallarm WAF node. You can find more information on versioning in the versioning policy documentation.

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

Highlights

• New WAF node component — Libdetection, a second-generation attack detection library
• Expanded options for custom block pages and response code
• Added display of WAF node component versions in the Wallarm Console
• Added new statistical parameters for the WAF node
• A few improvements have been made to the monitoring and other system components
• Support for CentOS 8 operating system has been added

How to upgrade

The installation and update packages for all supported platforms are already available in the repositories. AWS AMI and GCP VM Image have been updated. The migration guide is available in the docs portal.

A frequently asked question from customers is, "Why didn't FAST find a vulnerability when it definitely exists in the application?" We began to explore the logs and look for the reasons for this behavior. In most cases, the answer is simple: FAST failed to path authentication.

And we took the first steps in solving this problem.

The first move was to highlight the problems of authentication themselves. Now, the Wallarm Console displays the new "Auth failed" status if FAST was unable to test due to an authentication error.

The second move was to add a simple authentication method. What does that mean? Now, you can provide the FAST node with the test client credentials and specify the query parameters they need to substitute. These credentials will be used when executing test queries. Such a mechanism will avoid the use of an expired token, QA credentials, etc.

Read more about the FAST authentication process on our docs portal

Additional information about the IP address from which malicious requests were sent always helps when investigating attacks and incidents.

Previously, we independently determined whether the IP address belonged to the Tor exit nodes, or AWS, GCP, or Azure data centers. We also independently determined whether the IP address belongs to a specific country.

Now, we use the IP2Location databases, and on the Wallarm Console display additional information about whether the IP address is included in:

• The database of addresses of public web proxies
• The database of addresses of public VPN services

Our next steps are filtering by attack source on the Wallarm Console pages and blocking requests by country or by attack source.

You may have already noticed the new Triggers section in the Wallarm Console and may have already configured several triggers. Let's take a deeper look into what triggers are and how you can use them.

Triggers allow you to set up an automatic reaction of the system to an event. Each trigger consists of a trigger condition and an action to be executed.

In the first version, we taught Triggers to analyze attacks, incidents, and user creations and programmed them to send you notifications. For example:

• If more than 100 attacks have been performed on your application in the last minute, then Sumo Logic will instantly receive a notification about the attack that has begun
• If someone created a new user as the Administrator Role within the Wallarm Console, then a message about the new user would be sent to the Slack channel.

But that's not all - we have big plans for the development of triggers. The set of conditions and reactions will continuously expand. You can already configure automatic sending of IP addresses to the blacklist when the threshold of attack vectors is exceeded. In the coming month, triggers will be able to configure protection against brute-force attacks.

You can find detailed instructions on working with Triggers in our documentation.

Do you have any questions or ideas for product development? Tell us!

The first integration with the SOAR system is now available in the Wallarm Console. It’s the native integration with Rapid7 InsightConnect! SOAR systems are tools for complete automation of information security management, from prioritizing tasks to reacting to incidents.

The modern approach in information security is the use of specialized tools that are closely integrated with one another. Therefore, one of Wallarm’s priority areas is the support of modern security tools.

Now, you can send Wallarm WAF events to InsightConnect or configure conditions and filters for the Trigger to send a particular message to InsightConnect when conditions are met.

For setting up InsightConnect integration, only the API URL and X-Api-Key are required. You can find more details in our documentation.