In a previous article, we’ve discussed the BitNinja safe minimum ruleset for the BitNinja WAF, that consists of 15 rules from the OWASP Core Ruleset, along with 6 rules from the BitNinja rules category. These rules can be safely enabled on the root location pattern on your server.
In the BitNinja Ruleset, there are 5 categories:
These rules are custom made ModSecurity rules, which were developed and tested by us, the BitNinja team, reacting to the needs of the server owners and the emerging threats and cyber attacks.
When you first enable the BitNinja WAF module and start it, a default configuration will be generated, and that means that the BitNinja safe minimum rules will be automatically enabled on the “/” location pattern on your server in Challenge and greylist mode.
The following BitNinja rules are enabled by default:
Let’s talk about what these rules mean a little bit more in detail.
All BitNinja rules start with the number 4, to differentiate them from the OWASP CRS ruleset’s rules, which start with the number 9.
You could also see rule numbers starting with the number 1, for example like this:
You don’t need to look for rule number 1010035 on the Dashboard, because it can’t be enabled or disabled from the website. This rule is a so-called evaluation rule, so it decides if the request will be blocked or not.
So if you see this rule in an incident, you can be sure that one of the custom BitNinja WAF rules caught the malicious request.
Now, let’s take a look at the Virtual Honeypot category. We have two very strict rules in the BitNinja Ruleset, called Virtual Honeypot rules: rule number 400112 and 400113. These rules are very useful for creating virtual honeypot locations on your server when an account has been compromised.
Rule 400112 will block any POST request that will target the domain pattern.
Let’s look at an example:
You’re hosting a domain on your server with the name: loremipsum.com, and it’s a WordPress website.
You experience that this site has been compromised, and an attacker successfully uploaded a malicious file or backdoor into a folder called malware, in the wp-uploads folder. The file’s name is webshell.php (but it can be any other filename, of course).
You decide to create a new location pattern on the WAF page, and it will look like this:
Or if you’d like to add a more general rule, you can create the following location pattern:
*/*/malware/*.php
It will be valid for every domain on your server (not just loremipsum.com) because the * is a wildcard character. The second * refers to every folder under every domain, and if any of them contains a folder named “malware”, the BitNinja WAF rules you enable for this domain pattern will trigger on all requests that target any PHP files in this “malware” folder.
So if the hacker “returns” and tries to access his webshell, the WAF rule will be triggered.
This rule looks like this on the Dashboard:There’s another Virtual honeypot rule for the GET requests. It’s basically the same as the POST one, but it will block every GET request targeting the location pattern. The rule number is 400113.
There’s another Virtual honeypot rule for the GET requests. It’s basically the same as the POST one, but it will block every GET request targeting the location pattern. The rule number is 400113.
These rules are disabled on your server by default because they are really strict: if you enable them in Challenge and greylist mode on a healthy domain, these rules will block every POST and GET request to the website, and users won’t be able to register, login to the site, write comments, create posts, order products, and so on. So be sure to think about it first!
Let’s see what rules belong to this category, what are they good for and are they enabled by default or not?
401001 - Themes General Backdoor Access Protection
WordPress Backdoor Protection. Block HTTP POST method php calls for the themes directory (*/themes/*.php)
This rule was created against HTTP requests that target files in the WordPress themes directory. Generally it’s not good practice to call these files directly, however, some plugins are operating in this way, and that’s why this rule is disabled by default when you activate our WAF module.
401002 - Wp-includes General Backdoor Access Protection
WordPress Backdoor Protection. Block HTTP POST method php calls for the wp-includes directory (*/wp-includes/*.php)
Similarly, this rule triggers on requests to files in the wp-includes directory. It’s a folder that’s basically the territory of the WordPress core functionality. HTTP requests should not call files in this folder directly, so if they do, it is very likely that they are calling a backdoor.
401003 - Uploads General Backdoor Access Protection
WordPress Backdoor Protection. Block HTTP POST method php calls for the wp-content/uploads directory (*/wp-content/uploads/*.php)
The wp-content folder is for user-supplied content: WordPress themes and plugins are stored in this directory. And of course, the files uploaded by users can also be found here. This folder can also be a target for a hacker, and a potential place for a backdoor.
Let’s look at an incident that the 401003 rule has caught on one of the BitNinja protected servers (the domain is changed for privacy purposes):
If you have a Drupal website or are hosting some of them, or are a frequent reader of our blog, you surely heard about the Drupalgeddon and the latest vulnerabilities found in the popular CMS. The following 3 rules have been born in response to these vulnerabilities:
402001 - Drupal Remote Code Execution - SA-CORE-2018-002
Drupal Remote Code Execution - SA-CORE-2018-002: Block specific #submit #validate #process #pre_render #post_render #element_validate #after_build #value_callback parameters
402002 - Drupal Remote Code Execution - SA-CORE-2018-002
Drupal Remote Code Execution - SA-CORE-2018-002: Block all parameters starting with #
402003 - Drupal Remote Code Execution - SA-CORE-2018-004
Drupal Remote Code Execution - SA-CORE-2018-004: Block all destination q[#
By exploiting the SA-CORE-2018-002 and/or SA-CORE-2018-004 vulnerabilities, attackers could upload malicious backdoors to the server. These vulnerabilities affect Drupal 7 and 8 websites that are not patched.
You can find more details about these security flaws in our articles about the first two Drupal vulnerabilities, about the 3rd Drupalgeddon alert, and in our retrospective about Drupalgeddon 3.
403001 - Modx Revolution < 2.6.4 - Remote Code Execution - CVE-2018-1000207
This rule affects the Modx Revolution CMS version 2.6.4 and older, because an incorrect access control vulnerability has been found regarding the filtering of the user parameters in the phpthumb class.
404001 and 404002 rules: Scanner protection based on Hello Peppa botnet
These rules have been created to protect your servers against the botnet which uses the Hello Peppa payload and proved very aggressive in the last few days. You can read more about them in our article about the botnet and the WAF rule created to stop it.
Let me show you a little statistics about the incidents the BitNinja rules caught in one month (from 1st of June 2018 to 1st of July 2018).
The 400112 POST Virtual Honeypot rule triggered 45,567 incidents: 87% of them were log type, 13% were production type (so the IPs got greylisted).
The 400113 GET Virtual Honeypot rule caught 194,384 requests: 100% of the incidents were log only
The 401001 WordPress Themes General Backdoor Access Protection rule caught 1199 incidents, and 89,2% of them were log only.
The 401002 Wp-includes General Backdoor Access Protection rule caught 2448 incidents in one month, and 91,8% of the attacker IPs were greylisted.
The 401003 Wp-uploads General Backdoor Access Protection rule created 120 incidents, 88,3% were production type.
The 402001 first Drupal Remote Code Execution - SA-CORE-2018-002 rule triggered on 1387 requests, 87,2% of the IPs got greylisted.
The 402002 second Drupal Remote Code Execution - SA-CORE-2018-002 rule caught 327 incidents, 76,8% of the IPs got greylisted.
The 402003 - Drupal Remote Code Execution - SA-CORE-2018-004 rule caught 106 incidents, 89,6% were production type.
The 403001 Modx Revolution Remote Execution Protection rule was released on the 27th of July, so we have a little bit fewer data about it than the other rules. Since then 36 incidents have been caught, 27 incidents were production type, so the attacker IPs got greylisted.
The latest 404001 Hello Peppa rule caught 818 incidents since it was released on 2nd August until 3rd August - so it’s super effective! 60,6% of these incidents were production type.
The 404002 rule caught 547 incidents in the timeframe mentioned above, 86,6% of the IPs were greylisted.
Do you have and questions about these WAF rules? Don’t hesitate to write us!
Stay safe!
