Our detection team made recent changes that are now available to all the Wallarm customers. Here is a quick summary of the updates:

• We expanded and optimized the dictionary for the DNS Enumeration—a major technique that is used to discover exposed assets, including subdomains. As usual, you can explore the company’s network perimeter (domains, hosts, and services) / attack surface on the Scanner page.
• The detection team included changes in the attack detection to avoid some rare, but still painful, false positives while analyzing binary data (such as file or image uploads).
• The vulnerability scanner gained a few extensions to identify the following security issues:- SQL injection in vBulletin (CVE-2020-12720)
  • Unauthorized SSRF via REST API (CVE-2019-8451)
  • Detection of publicly exposed Yii2 Gii and Webmin

Each time you switch the operation mode (for example: from monitoring to blocking mode), create a custom rule, or mark the request as a false positive, the Wallarm Cloud generates a new application profile so that every Wallarm Node can use up-to-date security rules. This process is now at least 5x faster. In many cases, it is 10x faster.

How it works?

The application profile provides known information about customers’ APIs, application endpoints, and relevant security rules that should be applied to traffic processing. The rules are application-specific, so the app-profile is individually created for every customer and compiled into a special file called LOM, which is later used by Wallarm Nodes.

The compilation of the rules tree structure is complex algorithmically and requires a lot of resources and time. One of the recent tasks of our node development team was to radically optimize this operation. There is a lot of work in progress. However, one of the most efficient measures was a well known caching technique. This increased the assembly speed of LOM by at least 5-10 times. We are working on more optimizations and plan for their release to be in the near future.

A completely updated WAF documentation portal is now available at docs.wallarm.com. Switching to the new docs platform allowed us to expand the capabilities of the portal. This has made navigation across the portal more convenient. In addition, it has greatly simplified the updates of the documents.

Notable changes

• We added a "live" search widget. Moreover, search results now include a context. For example, if you search the word Docker, then you'll not only get a list of the relevant articles but also a brief context of where this keyword is used.
• For each article, a document outline is now visible on the right side of the page. This is especially useful for navigating through longer technical documents.
• Our favorite change yet allows everyone to have the opportunity to contribute and make our docs better! We are allowing everyone to edit content via pull requests in GitHub repo with the documentation content. To start editing, click the edit icon on the page you want to change, push changes to the forked repo, and create a pull request to our repo! It’s that easy.

Technical details

We know many of our customers support the documentation for their products themselves. Therefore, we want to share some technical details about the chosen platform.

Previously, we built docs with GitBook, which was outstanding. Unfortunately, open GitBook is no longer supported. While choosing a new platform, we tried a variety of options, such as Docusaurus, Vuepress, or Gatsby, and ended up choosing the remarkable MkDocs / MkDocs Material. But the details of analyzing and moving to a new platform deserve a separate post in our blog.

We are looking forward to hearing your feedback! Please email support@wallarm.com with any comments, concerns, or questions.

Recently we launched the refreshed look of our Vulnerabilities page. The page now has three sections — high risk, medium risk and low risk vulnerabilities. This helps you to focus on a certain group without using filters.

The design of a single vulnerability page has also been changed. We hope the new updates make the interface easier to use. Everything is much more readable now — the parameters, history timeline, exploit examples, etc.

If you miss any functionalities on these pages or have any other feedback, please let us know!

We are continuing to simplify security testing automation in your CI/CD pipelines. Many users have requested to have FAST work with several CI pipelines simultaneously. We’re glad to announce that such support was added in the latest version of FAST.

You no longer need to run multiple instances of the FAST node for each CI pipeline. Instead, the only instance of the FAST node can now be used in multiple pipelines. It greatly simplifies tool deployment and makes the whole testing architecture more elegant.

Just specify an additional parameter BUILD_ID in the configuration of your project in the CI/CD system. For example if you work in Jenkins, add -e BUILD_ID = $ {env.BUILD_ID} into the command that launches FAST.

The parameter should be unique for each build so that the FAST node can associate any given requests with the necessary Test Run. Note that support for parallel pipelines works with both modes: recording baselines and running security tests.

Don’t have FAST but want to try it out? Send us a note!

With the growing complexity of new applications and technology stacks, as well as evolving attack techniques, we can implement regular improvements in how the Wallarm WAF detects attacks. Here are some highlights from March 2020 that our detection team wants to share:

• Expanded list of possible NoSQLi (NoSQL Injection) vectors that can be detected;
• Improved the mechanism for detecting SSTI (Server Side Template Injection) attacks;
• Redesigned SSI (Server Side Includes) discovery mechanism;
• New rules for detecting IMAPi (Mail Injection) have been added.

This update will expand the WAF's ability to detect attacks by adding new rules and reducing the number of false positives by optimizing existing algorithms.

Do I need to update anything to apply these changes?
No, all improvements in the attack detection techniques are delivered to customers automatically.

How do you ensure that these changes will not affect my traffic flow?

For the next two weeks, the update will work in the experimental mode without any additional blocking. Changes will be activated once we make sure no additional false positives are introduced.

For questions related to the detects and updated rules, you can contact our support team.

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

Highlights

• The protection of gRPC-based APIs and microservices is now supported. gRPC/Protobuf parser has been added. Read more.
• When blocked by an IP address, it is now possible to return a custom error page and server code to the client
• A few improvements have been made to the monitoring and other system components
• Support for the following operating systems has been added:- Debian 10
  • Amazon Linux 2

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.

Support for modern stacks is where Wallarm has always stood out from its competitors. For a long time it was the only product that provided full comprehensive protection for WebSockets-based web applications, and now we are the first to add support for the gRPC protocol.

Many customers, especially among large tech companies, are adopting gRPC as a fundamental piece of tech while architecturing their new APIs and microservices. Developed by Google, gRPC is a popular framework for remote procedure which serializes data using Protobuf and relies on HTTP/2 for transport.

New improvement is a part of Intelligent Parsing technology. Every Wallarm Node runs deep request inspection, parses Protobuf messages and detects malicious payloads even if they are nested inside complex data structures. This allows you to protect your web assets against the modern-days challenges, ranging from OWASP Top10 threats to Account Takeover.

Node: you don’t need to run any additional configuration or upload any API schema or protobuf structures to protect your assets. Wallarm will automatically figure everything out based on the traffic.

This way, you can protect those APIs that use gRPC and are frequently updated as a part of CI/CD process. With no extra configuration.

Recently we’ve launched a new Dashboard widget—Attack Sources.

On its left side you can see the GeoIP map, which shows the distribution of malicious requests (hits) from different countries. The bigger the red indicator, the more requests that originated from that country. Hover over the indicator to see the exact number of hits.

On the right side of the widget you can also see the top of attack sources, such as Tor and data centers. For example, if most of your attacks came from the Tor network or from networks of cloud providers, then you would be able to see it at the top of the table and take action.

Any feedback? Let us know!

PagerDuty is an incident response platform that is very popular among the DevOps community. It empowers teams with automation capabilities that quickly and accurately orchestrate the right response, every time.

With the Wallarm/PagerDuty integration, it is possible to automate reaction and escalation policies for security incidents. PagerDuty can now pull data from Wallarm, including events on discovered vulnerabilities and changes in the network perimeter. For instance, many people set up a workflow when a critical security issue is discovered.

Unified workflows and shared tools are crucial to align DevOps and Sec teams and guarantee service SLA and its security.

We continue to expand the list of supported DevOps tools. More to come in the coming months! Tell us if anything missing.