Ultimate WAF Guide  - How to patch WordPress vulnerabilities and block web attacks
Jacint Lazok

Ultimate WAF Guide - How to patch WordPress vulnerabilities and block web attacks

An exploited CMS vulnerability or vulnerabilities to web-based attacks is a big security issue as one well-aimed attack can cause a data leak, data loss or make your server unavailable. These attacks need to be stopped before they even reach your server and the WAF 2.0 module can do that for you. This powerful defense tool can protect you from these attacks without slowing down your server’s response time or increasing the load.

In this guide, I will show you how you can use it to maximize your server’s protection by fine-tuning this module.

Spoiler: not by turning on every WAF rule ;) 

In this article, I will answer the most important WAF-related questions:

  1. What is WAF?
  2. Why is it 2.0?
  3. How do I set up the WAF 2.0 module?
  4. How do rulesets work?
  5. How do I apply rules on domains and on pages/paths?
  6. How do I avoid false positives?


What is WAF?

WAF Stands for Web Application Firewall. This powerful module blocks attacks that target websites by patching your CMS’ vulnerabilities, such as WordPress, Drupal or Joomla. The WAF 2.0 module can block attacks that would potentially cause serious issues with only one successful attempt. Well-targeted code injections or cross-site scripting attacks need only one successful attack to damage your server. The WAF module’s reverse proxy filters all requests before they reach your server, so these attacks will be blocked. While the other BitNinja modules block attacks that need multiple trials, like DoS or brute force attacks, SQL injections or Hexa botnet attacks need to be stopped before they can reach your server and the WAF 2.0 module is perfect for that.

In this article, I will show you how you can utilize this powerful module and how you can use its full potential with some fine-tuning.

The BitNinja WAF 2.0 module protects your server from:


Why is it 2.0?

The current WAF 2.0 module was first introduced in the 1.17.0 version in the BitNinja agent’s source code as WAFManager. The 1.0 version of our Web Application Firewall was PHP-based and required a lot of resources to run and adding a new rule usually increased the resource demand of the old WAF module. So, we replaced it with an Nginx reverse proxy-based modsec (v3) framework which uses the OWASP core ruleset. This way, the WAF 2.0 module is fast and uses minimal resources and it is easy to add rules from the ruleset without anything slowing down or increasing the server’s load. No other WAF module has pattern-based rule management, only the BitNinja WAF 2.0 module.


WAF 1.0
WAF 2.0
PHP-based
Nginx reverse proxy-based
Causes slower response
Has no effect on the speed of your website
Increases the server’s load
Uses minimal resources
Hard to add rules
We can add new rules to patch new kinds of vulnerabilities
Rules can be applied on server-level only
Rules can be applied on domain/page-level via the domain pattern system


This module is disabled by default because the necessary configurations vary based on your setup and infrastructure. To use BitNinja’s WAF 2.0 module, you will need to make sure the pre-configurations are done based on how you use your servers. If you use any CDN services, for example, or any proxy service, you will need a different configuration than if you use no proxy or CDN. But don’t worry, I will guide you through how to execute these simple configurations. In this article, I am going to explain which setup requires what configuration. I will also tell you how to minimize the false positive rate with this module.


How do I set up the WAF 2.0 module?

As the BitNinja WAF 2.0 is a reverse proxy, every HTTP(S) connection comes through it.  So, in order to see the real IP (and not the server’s IP) in the access logs, you need to enable the X-Forwarded-For header or enable the Transparent proxy module depending on your set up.

The required settings vary if you use any CDN or proxy service or if your server has private IP addresses only and the web server (Apache, Nginx) that you use to host your domains also affects the required configurations.

How do I know if I am behind proxy or CDN?

You can check if your server is behind Proxy by pinging the server’s hostname.

1. If you see the server’s IP address* or one of the IP addresses of your server, then your server is not behind any proxy. 

2. If you don’t see the IP address* of your server, you are behind a proxy and you will need to enable the Trusted proxy module and set up the X-Forwarded-For header.


If you are hosting multiple domains and you are not sure if any of the domains use CDN services, you need to check the domains to see if they are behind Cloudflare, for example.

  • If you host only a few domains on a server, you can check if you use CDN by pinging the hosted domains one by one and checking if the IP address belongs to your server or not.
  • If you host many domains, you should look up all the domains hosted and check if the IP addresses belong to your server. Which is really complicated to do manually. Also, this configuration might vary by server.

 

*You can check your server’s IP addresses with the ifconfig command.


If you have private IP addresses only

How can I tell if I have private IP addresses only?

The output of the ifconfig command contains IP addresses that look like:

  • 10.x.x.x
  • 192.168.x.x
  • 127.x.x.x
  • 127.0.0.1 (this is the localhost)

As you can see, the NinjaUni server has only private IP addresses.


  • Then you will need to open the /etc/bitninja/WAFManager/config.ini file in a text editor.
  • Add the name of the network interface like this if the eth1 interface is connected to the Internet.
  • Please don’t forget to remove the semicolon from the beginning of the interface[]=’eth0’ line in order to take effect.


  • Restart BitNinja with the service bitninja restart command


If you don’t use a proxy or CDN service

If you only host domains without Cloudflare or any other CDN service and not use the Trusted Proxy Module, all you need to do is enable the Transparent proxy module.

You can enable the Transparent Proxy module without modifying anything in the web server application that you are using, whether it be Apache, Nginx, Litespeed, or EasyApache.

All you need to do is:

  1. Open up your server terminal
  2. Open the /etc/bitninja/WAFManager/config.ini file in your preferred text editor
    • If you use nano, then use nano  /etc/bitninja/WAFManager/config.ini command to edit the file
  3. Then navigate to the ";redirection_mode = 'transparent'" line
    • this can be done with the Ctrl+W hot keys then type in redirection_mode and you will be directed to the line
  4. Delete the semicolon from the beginning of the redirection_mode = 'transparent' line
  5. Exit and save the changes
  6. Enable the BitNinja WAF 2.0 module from the dashboard if it is disabled
  7. Finally, restart the BitNinja agent with the service bitninja restart command

After that is done, we can test if our WAF module is working properly.

You just need to add /?test=/etc/passwd to one of the hosted domains' URL. This will trigger the WAF module as we are trying to access a file from the operating system.

If everything is okay, you should see our CAPTCHA page. Please delist your IP address from the greylist by solving the reCAPTCHA and clicking on the delist my IP address button.

Done, I enabled the Transparent Proxy. Let's see how I can manage the WAF rules.


If you use CDN or proxy services

To enable BitNinja to see the real IP addresses of users that visit a domain that is behind Cloudflare, for example, you will need to enable the Trusted proxy module. This is also the case if you use any other CDN service or proxy. Enabling the Trusted proxy module:

 

It might be necessary to regenerate and reload the SSL Terminating module after enabling the Trusted Proxy.

You can do that by running these commands with 1 minute in between to make sure that both commands went through:

bitninjacli --module=SslTerminating --regenerate
bitninjacli --module=SslTerminating --reload

Done, I set up the X-Forwarded-For header. Let's see how I can manage the WAF rules.


If you use control panel (cPanel/Whm, Plesk)

If you use any CDN or proxy services, you need to enable the Trusted proxy module from the Dashboard.

You will need to set up the X-Forwarded-For header in your web server application since the CDN servers do not have the Transparent proxy feature yet, they only have the X-Forwarded-For. BitNinja will only see the real IP addresses of the users with the Trusted proxy module on.

If you use any control panel (such as cPanel ) that generates the web server application's config file, it will overwrite the config file if you modify anything in the configuration file directly.

In Plesk, the X-Forwarded-For header is set up by default. If remoteip is not enabled somehow, you need to enable remoteip from the control panel. In the corresponding part, I will show you where you can find this setting.

You need to use the config editor provided by the control panel. You can usually find it by typing the name of the web server into a search field.

Please note that if the web server's config file was generated by the control panel, you will see comments about this in the config file saying something like " DO NOT EDIT. AUTOMATICALLY GENERATED".

So, if there are no such comments in the config file, you will need to access the Apache web server's config file.

Done, I set up the X-Forwarded-For header. Let's see how I can manage the WAF rules.


Apache with Plesk

In Plesk, this configuration is not necessary as the X-Forwarded-For header is already included with all IP addresses of the server in the configuration files of all web server applications. If remoteip is not enabled yet, you need to enable remoteip from Plesk.

  • Go to tools and settings -> Apache Web Server
  • Tick remoteip’s checkbox under Apache modules

Done, I enabled the remoteip. Let's see how I can manage the WAF rules.


Apache with cPanel control panel

If you see the comments about this config are being generated by cPanel or another control panel, you will need to edit the config file from the control panel's config editor

  • In cPanel, you will need to set up X-Forwarded-For in the Apache config editor.
  • Home-> Service Configuration-> Apache Configuration-> Include Editor-> Pre Main Include (Here, choose all versions)
  • Please enter the following text into the text field:
    RemoteIPHeader X-Forwarded-For
    RemoteIPInternalProxy INSERT YOUR IP ADDRESS(ES) HERE
  • Then finally click on the Update button and restart the Apache web server.

Done, I set up the X-Forwarded-For header. Let's see how I can manage the WAF rules.


If you use Nginx

The other most popular web server is Nginx. In Nginx's case, the cPanel plugin Engintron basically gives you an editor for the config files.

If you use CDN or Proxy services, enabling the Transparent proxy is not sufficient and you will need to set up the X-Forwarded-For header and enable the Trusted proxy module.

  • The file you need is nginx.conf, you can select this file from the plugin's UI or you can locate the file the same way as we did with Apache
  • You can use the find / -name 'nginx.conf' -print command to find the location of the file if you edit the file from the terminal
  • Please insert these lines in the file:
set_real_ip_from ;
real_ip_recursive on;
  • Then all you need to do is restart Nginx
  •  With the service nginx restart command from the terminal
  • or by clicking on the “Update /etc/nginx/nginx.conf” button in the control panel

Done, I set up the X-Forwarded-For header. Let's see how I can manage the WAF rules.


If you use Apache without any control panel

In this case, you just need to open a terminal on the server and configure the web-server manually and set up the X-Forwarded-For header as shown below.

In CentOS, it is usually located at: /etc/httpd/conf/httpd.conf.  In other distributions, it might be called apache2.conf. In Debian, it is usually located at /etc/apache2/apache2.conf. The location of this file is set at compile-time, so it may vary.

You can use the find / -name 'apache2.conf' -print or with find / -name 'httpd.conf' -print command to find the location of the file.

  • Please open the httpd.conf file in your preferred text editor 
  • Please insert this in your config file:
    RemoteIPHeader X-Forwarded-For
    RemoteIPInternalProxy INSERT YOUR IP ADDRESS(ES) HERE
  • Here, you can get your server's IP address from the ifconfig command's output.
  • If your server has multiple IP addresses, you need to add all the IP addresses. You can also add IP ranges too, you just need to separate them with a colon and space
  • Please check the Log format of the web server application. It needs to look like this:"%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
  • You can find this part in nano with ctrl+w and then type Log format
  • And then you need to save the changes and exit the editor
  • Restart the web server application. You can do that with service apache2 restart or with service httpd restart
  • Then you can enable the WAF module from the Dashboard

Done, I set up the X-Forwarded-For header. Let's see how I can manage the WAF rules.



When you have finished the configurations: The full potential of the WAF 2.0 module

After the WAF module is set up, it provides great protection with the default settings but there is so much more potential in this module

In this part, I will explain how the WAF module works and how can you get the most out of the WAF module while minimizing the false positives with some fine-tuning.


How do rulesets work?

As mentioned, our WAF 2.0 module uses the OWASP rules. We have 3 different predefined collections of rules to help you minimize the number of false positives.

  • Recommended (Lowest false positive rate)
  • Medium Risk (False positives expected)
  • High Risk (High false positive rate expected)

These rulesets can be set up based on patterns. By default, the Recommended ruleset is active on the / pattern, which means the Recommended ruleset takes effect on the whole server, on every domain. If you add any additional rule or disable any rule on the domain, the change will take effect on the domain pattern that you added or disabled the rule on.

For example, if one of the rules causes too many false positives on example.domain.com/admin-page, then you can disable the rule for that pattern only, so you don’t have to compromise the security of other domains where this rule caused no false positives. Managing WAF rules based on domains is unmatched in the security solution’s market.

You can also make your own custom WAF rulesets if you click on the Manage ruleset templates in the WAF 2.0 menu.

You can select one of the predefined rulesets, then you can select which rules to remove or add to the predefined ruleset. After clicking on the Add New button, you can use this custom ruleset on any of your servers under the account that you are logged in.

From the Recommended to the High Risk ruleset, there are more and more rules that are enabled while the expected number of false positives increases. While switching on all the WAF rules might seem like a good idea to maximize your server’s security, enabling too many WAF rules causes your customers to be blocked for perfectly harmless things like editing their WordPress site or trying to edit something in their admin interface. So, turning on a bunch of rules in the WAF 2.0 module will lead to a lot of frustration from your customers, which will lead to an increase in the number of tickets, which consumes a lot of resources and precious time.

We advise you to use the Recommended ruleset because it contains all the rules that are necessary and rarely causes any false positive. If you would like to enable a rule on a domain that is not included in the recommended ruleset, please use the rule in “log only” mode to see how each rule performs, so you can decide which rules will work for you and which won’t. This way, if a user triggers the rule, they won’t be blocked but you can check the logs regarding the WAF rule if it was triggered false positively.

As the default pattern, “/” takes effect on the whole server, only use the Recommended ruleset. Using the Medium Risk ruleset or the High Risk ruleset is not recommended as it will increase the false positive rate generated by the WAF 2.0 module a whole lot.

If you click on the Advanced Settings button, you can select which rules to enable or disable. You can expand the BitNinja Ruleset or the OWASP Core Ruleset to turn on or off rules. The rules are grouped in collections. You can enable and disable WAF rules by groups. I will explain this feature in detail here .

We only recommend this setting if you know what you are doing and you are confident about what rule you would like to enable. If you are not sure or you have questions, please don’t hesitate to contact us via chat or via email and we will be more than happy to help you.


How to patch CMS vulnerabilities with the BitNinja WAF ruleset

In the BitNinja WAF ruleset, 6 out of 9 rules of this ruleset are enabled by default.
Our tech ninjas made these rules to patch CMS vulnerabilities and zero-day vulnerabilities and they are working continuously to make this rule collection bigger and patch even more vulnerabilities with the WAF module.

The Virtual Honeypot rule group enables you to make any backdoor or page to a honeypot without any coding whatsoever. All you need to do is set this rule to the path you find a backdoor or the page where it was uploaded from or where the hackers tried to upload it. You can read more about this ruleset in our previous blog article.

The BitNinja ruleset contains the following rules:

Of course, the OWASP Core Ruleset patches a lot of CMS vulnerabilities as well, for example, as you can read in one of our recent articles.

  • vBulletin RCE vulnerability
  • Rusty Joomla RCE

If you would like to read about our WAF 2.0 modules’ ruleset, please check out this article. Also, you can read more about the rules by expanding the rule categories. There will be a short description of the rules. Some rules also have a link with references in their descriptions.


How do I apply rules on domains and on pages/paths?

Our WAF module is the only one where you can manage rules by domains or even pages.

Pattern-based WAF rule management is useful because you can avoid false positives much more easily without risking other pages or domains where this rule caused no false positives, or you can protect pages and domains with additional rules where it is necessary without risking an increase of false positives and tickets.

By default, the Recommended ruleset is active on the “/” pattern. This means that the recommended ruleset is active on every domain and every page hosted on the server.

A great benefit of the domain-based rule management is that you don’t have to specify rulesets for every domain if you would like to protect a URI that is available in many domains. If you would like to get rules to every WordPress admin page on the server, you don’t have to go through every domain like domain-one.com/wp-admin/ and domain-two.com/wp-admin/ and set the same rules for them one by one. You can get the job done by setting up the rules on a domain pattern that looks like this:

*/wp-admin/*

A pattern is basically a regular expression. The * character is a wildcard, so it means any number of any character. It’s important that before the first /, there is the domain information and after the first /, you can type the URI.  Here are some examples of the different kinds of domain patterns:


Pattern
Exact subdomain
Exact domain
Exact URI
1
*ninjas.com/*



2
*.ninjas.com/*
 (but applies only on subdomains)


3
*cool.ninjas.com/*



4
*cool.*/*



5
*cool.ninjas.com/wp-admin/*



6
*ninjas.com/wp-admin/*



7
*phpmyadmin*.ninjas.com/*



8
*/wp-admin/*





If you would like to disable or enable a rule on a domain or just one page of the hosted domain, you can do it from the WAF 2.0 menu point of the Dashboard.

  1. Select the server where the domain is hosted at the top of the page.
  2. Add the pattern based on the domain and the page where you would like to add or disable the rule
  3. Click on the Add button.
    • The default Recommended ruleset will be active on the path you set.
  4. Click on the gear icon to set the ruleset and the actions taken when the rules are triggered.
  5. At the Action field, select the Log only mode if you would like to enable a rule in addition to the recommended ruleset. If you would like to disable a rule, this step can be skipped
    • If the results show that the additional rule does not increase the false positives, don’t forget to set the Action to Challenge and greylist IP mode
  6. Click on the Advanced Settings button
  7. Select the rule to disable or enable, you will need to open the rule groups to find the rule that you are looking for.

1. In the “Action” field, you can select if the WAF module is in Log only or Challenge and greylist IP mode

  • The Log only mode is a great tool to test what would happen if you add rules to your current ruleset. By setting up a custom ruleset on a domain and setting “Action” to “Log only” mode, you can make sure that enabling a rule causes no false positives.
  • The default action mode is “Challenge and Greylist IP”. In this action mode, the WAF 2.0 module greylists an IP address if there was a request coming from the IP that triggered the WAF module. If the request was launched by a person, they will be challenged to solve a CAPTCHA to prove that they are not robots.

2. With the Lock down mode enabled, the WAF 2.0 module blocks every POST request on the page where it is set up. If you send a POST request like commenting, you won’t be greylisted, the POST request will be ignored and only GET requests will be processed. That is a useful tool if a user account is hacked, for example, someone has the password and the username of a client. You do not have to suspend your customer’s account, you can just use this mode to:

  • The rules set on the domain pattern are still active, meaning that requests that trigger the WAF rules will be blocked and the IP address that sent the request will be greylisted.

3. The Disable WAF mode can be used if you want to make sure no request will trigger the WAF module on a domain pattern. For example, if you don’t want the WAF module to be triggered by any request on the WordPress admin pages of a specific hosted domain, you can just add a pattern that looks like this: *example.domain.com/wp-admin/* or if you would like to do that on all the hosted WordPress admin pages, you can use */*/wp-admin/*. Then you can just tick the Disable WAF checkbox. This way, no WAF rule will be triggered here.

  1. Click on the gear icon to set the ruleset and the actions taken when the rules are triggered.
  2. At the Action field, select the Log only mode if you would like to enable a rule in addition to the recommended ruleset. If you would like to disable a rule, this step can be skipped
    • If the results show that the additional rule does not increase the false positives, don’t forget to set the Action to Challenge and greylist IP mode
  3. Click on the Advanced Settings button
  4. Select the rule to disable or enable, additionally, you will need to open the rule groups to find the rule that you are looking for.

When adding rules on a domain or a page, we recommend setting the action on the pattern to Log only mode at first so you can check if the increase in the false positive rate is acceptable. In Log only mode, BitNinja only logs what request and from what IP address triggered the WAF module on the domain pattern, so the users that cause false positives won’t be blocked.

In Log only mode, since triggering a WAF rule won’t present CAPTCHA and the user won’t delist the IP, the false positives won’t show under the WAF 2.0 module’s menu point. This means you will need to check the logs and validate if the rule causes false positives.

If you decide to enforce the rules of your ruleset, you can just select the Domain pattern and click on the gear icon on the right and at the Action field, select Challenge and greylist IP.


Here, you can see how many times the WAF 2.0 module was triggered, how many of these were false positive and how many rules were added and if the rule is in Log only mode.


1. The number of false positives is indicated next to “False”. This counts how many requests came in regarding the domain pattern which triggered the WAF 2.0 module but it was delisted right after via the CAPTCHA module. We count this as a false positive because the rule was triggered by a request that was launched by a human user.

2. The “Triggered” number shows how many times there was a request that contained something that is forbidden by a rule.

3. The little fork icon shows how many rules were enabled in addition to the ruleset that was selected. If you open the rule category groups, you will see which rule group contains the rule you added. There will be a + or a - symbol next to the name of the rule. Here, you can also read some information about each rule.

4. The Log only mode is indicated by this icon. If there is nothing here, the Challenge and greylist IP action is active

The switch icon at the rule groups’ name indicates the state of the rules in the group. If the color of the switch icon is grey, then there is no active rule in the rule group. If it is orange, then there is at least one active rule in the group. If all rules are enabled, the group’s switch icon will be green.


How to avoid false positives

A false positive is when a user triggers the WAF 2.0 module with a harmless request. In the WAF module that is counted on every domain pattern that is set up under “False ”. False positives make your customers frustrated and unsatisfied with the service they get.

The number one cause of false positives that are generated by the WAF module is too many enabled rules.

In general, the acceptable false positive rate is a maximum of 2%. To minimize the false positives, we recommend using the Recommended ruleset on the “/” pattern. And if you would like to add rules, only add them on domains or pages, never to the whole server. And always enable the Log only mode to the domain pattern for a longer time period and check the logs about the domain WAF incidents under the Network Attacks menu point. If the number of false positives is acceptable, only then enable the Challenge and greylist IP mode on the Domain pattern.


Use the WAF module

You have the ultimate WAF 2.0 guide to use this powerful and flexible module, so with your newly acquired knowledge, use it to protect your server from hackers. 

If you want to use the WAF module to protect your server, don’t hesitate to register and try the WAF 2.0 module and all the other BitNinja modules during the 7-day free trial period FOR FREE.

Sign up for a free trial

If you have questions or need help with something, our support ninjas are more than happy to help you. You can contact us via chat or via email.

Share your ideas with us about this article

Previous posts

Case Study - The Best Security Solution for Valicom Net Cloud Services
Valicom Net is a Cloud Hosting Company in Cyprus with more than 15 years of experience specializing in Business Web Hosting, Cloud Services, Virtual Private Servers, Dedicated Servers, Hosted Exchange, Web Development with Content Management System, Network Security, Antispam Services, Online Storage Email & Remote Backup. Challenges „As we offer managed and unmanaged services, the challenge for us was to protect both services. For the managed servers all security updates were done on time which was not the case with the unmanaged servers as customers usually don’t update them. We w...
Case Study - DDoS Problems Solved at ISO Certified IT Company
Aitire is a small MSP (Managed Service Provider) company located in Spain. They have more than 10 years of experience in computer consulting, Free Software, Open Source, GNU / Linux, etc… They aspire every day to maximize their technology and provide the best tools to their clients. Challenges „We usually work with rpm based Linux distributions and we used to face a lot of problems on them. Before using BitNinja we experienced a huge amount of attacks, mostly DDoS.” - Alejandro Escobar Like many others, Aitire also tried different kinds of solutions against cybercrimes....