Load Balancers

How do you run OWASP CRS on LoadMaster

The OWASP CRS are more generic in nature than a commercial ruleset and cover a much larger set of applications from a broader attack surface. This means that the CRS protects you from generic attacks rather than individual specific known exploits. For example, there are not rules for all known SQL injections attacks but a small set of rules protecting your application from any attack that looks like an SQL injection attack. This provides significantly enhanced coverage for Zero Day and other unknown attacks.

Once the WAF is enabled on the LoadMaster, we can check it working immediately using:

curl http://<<Virtual Services IP Address>>/index.html?exec=/bin/bash

The query string contains an attempt to exploit an imaginary backend. This exploit won’t work of course, but it is enough to trigger CRS. The request is not blocked immediately though. Don’t worry, in this blog, we’ll explain both the settings and how to get that request to block.

The LoadMaster logs of most interest here is the WAF Event Log File under System Configuration – Logging Options -System Log Files. The log generated from this access attempt is shown here:

2021-04-18T21:40:43+00:00 lb100 wafd: [client 10.0.31.231] ModSecurity: Warning. Matched phrase "bin/bash" at ARGS:exec. [file "/tmp/waf/3/REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [line "500"] [id "932160"] [msg "Remote Command Execution: Unix Shell Code Found"] [data "Matched Data: bin/bash found within ARGS:exec: /bin/bash"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-shell"] [tag "platform-unix"] [tag "attack-rce"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/248/88"] [tag "PCI/6.5.2"] [hostname "10.35.56.58"] [uri "/index.html"] [unique_id "e8035fe4-c980-49e8-b87a-6360afe9c44b"]

We are looking at several entries in this log

So, what we’ve learned is that rule set is active, and it is logging attacks, even if, for the moment, it is allowing those attacks to occur.

Before we dive into blocking this attack, let’s run through the WAF settings on the LoadMaster and their meanings.

The main settings are shown in Figure 1 above and includes the following:

What is specifically logged to these files is controlled under Advanced Settings – Audit Parts which is described below.

Almost all rule groups are enabled by default. Yet, when you scroll down Manage Rules, you come across a section titled Workloads.  These are groups that facilitate working with these well-known applications.  What they do is they anticipate the behavior of the software and prevent certain rules from being applied, since they would trigger a false positive.

Take Drupal for example: Drupal submits a lot of parameters with square brackets in the parameter name (e.g., id [0]). Once a certain number of square brackets is encountered in a parameter, CRS triggers an alarm.  Enabling the Drupal workload in this menu, makes these false alarms disappear without the need to tune them individually.

More information on the CRS rules is available here

Next, let’s look at the Advanced Settings, as shown in Figure 2 below.

These are advanced settings and should be treated with care:

When you raise the Paranoia Level, it’s usually good enough to raise the so-called Blocking Paranoia Level. Setting this to Paranoia Level 2 enables the rules from Paranoia Level 2. They will now contribute to the scoring of the request and the WAF will then use that score to decide whether the request ought to be blocked or not.

Please note that the user interface prevents you from setting a Blocking Paranoia Level that is higher than the Executing Paranoia Level. It’s obvious you cannot block on a higher level if you do not execute its rules.

Audit Parts: The checkboxes allow you control  the level of detail in the Audit mode log files. These settings are fully detailed here.

Coming full circle to the initial test, I set the Anomaly Scoring Threshold to 5 and repeat the test. I get the following where the WAF blocks the request with a 403 error.

Request

curl http://<<Virtual Service IP Address>>/index.html\?exec\=/bin/bash

Response

<html><head><title>403 Forbidden</title></head><body>Access denied</body>

Logs

The LoadMaster logs of most interest here is the WAF Event Log File under System Configuration – Logging Options –System Log Files. The logs generated from this access attempt is shown here:

2021-04-18T22:46:28+00:00 lb100 wafd: [client 10.0.31.231] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/tmp/waf/3/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "93"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 8)"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "10.35.56.58"] [uri "/index.html"] [unique_id "5a9a2689-8e75-4cff-baef-6245cff57c67"]

We are looking at several entries in this log

Summary

Now that we have introduced the basic elements of configuring the Core Rule Set on LoadMaster, next week we will demonstrate a practical example of using custom rules to create / customize your WAF configuration within LoadMaster for a specific application.

If you are currently looking at utilizing Web Application Firewall (WAF), make sure to check out the Kemp WAF here…

Read the rest of the OWASP CRS Series

Part 1: Introduction to OWASP CRS
Part 2: How do you run OWASP CRS on load master
Part 3: Deploying custom rules
Part 4: False Positive Analysis
Part 5: Reporting

Exit mobile version