The BitNinja WAF is a really great tool for security - when used properly. And to use it, you’ll need to understand the terminology that we’re using. So let’s start with the basics, shall we? 🙂
Rules are the building blocks of protection. Let’s think about firewall rules. If you enable a firewall without rules, it will do very little to protect the server or computer, because it won’t know what to look for in the incoming requests. By applying rules, we tell the BitNinja WAF to watch out for certain patterns in the incoming requests, and to act on them if they find a match.
In the BitNinja WAF, we’re using the well-known rules from the OWASP ModSecurity Core Rule Set, along with our own rules, that are created by our development team.
A couple of example rules look like this on the Dashboard:
The ID is the unique identifier, or number of the rule. It can come in handy when you’d like to identify which WAF rule caught a malicious request on your server. Next to the ID you’ll find the name of the rule, and a short description about it.
You can find a detailed description about the various sections of the WAF configuration on the Dashboard, just on the right side of the page. Please read it carefully and contact us if any questions come to your mind about it.
Take the rule number 930120, which is called OS File Access.
You can find a link in the description, and following it you’ll find those files that are considered OS files on *NIX or Windows systems, among others. Examples are:
/proc/meminfo
/etc/passwd
/var/log/syslog, and so on.
These are files that we - usually - won’t access from a browser, and don’t want to provide access to them over HTTP or HTTPS.
Knowing the number and/or the name of a rule, you can more easily understand incidents. Let’s take a look at this example incident (the URL and host are changed intentionally for privacy purposes):
You can find the rule’s ID in the section called ModSecurity id, and the rule’s name in the section called msg, in the incident details. You can see here that an incident can be triggered by more than one WAF rule.
Rules are categorized in rulesets
The OS File Access rule is part of the Local File Inclusion group, and it belongs to the OWASP Core Ruleset. This ruleset contains 16 different rule categories or groups, and all of these groups contain rules that are similar to each other, because they belong to the same threat category. For example: Local File Inclusion, SQL Injection, Remote Code Execution and so on.
The Local File Inclusion group contains 4 rules, but only 2 of them are part of the BitNinja Safe Minimum ruleset templates.
When we designed the BitNinja WAF, we didn’t want to leave all the hard work of selecting and testing every different rule to our customers. That’s why we designed the following ruleset templates:
BitNinja Safe Minimum
BitNinja Medium
BitNinja Strict
These ruleset templates contain those rules - categorized in groups by threat type (Local File Inclusion), and in rulesets (either the OWASP Core ruleset, or the BitNinja ruleset, as of now) - that we carefully tested and analyzed for you to use safely, depending on the level of strictness in security that you’d like to achieve, and depending on the services that you’re hosting on your server.
Because every server is different, and the usage of the BitNinja WAF depends on what processes are running on it, what you’re using it for: in your case, hosting WordPress websites.
So, since you are in the WordPress hosting business, I advise you to only enable the BitNinja Safe Minimum ruleset template for all incoming requests (domain pattern: /) to maintain a very low false positive rate. The Medium and Strict rulesets for the root domain pattern, or any */wp-admin/* domain pattern will generate a lot of false positives - and a lot of headaches for you, and we absolutely don’t want that!
But that’s a story for another article, so stay tuned - and safe!
Also, check out the other parts:
-Part 2: for domain patterns
-Part 3: for the safe minimum ruleset
