With security as a primary focus this year, we are happy to bring ModSecurity and OWASP CRS for your Web Application Firewall (WAF) in RunCloud.

This feature helps protect your website from many types of attacks against your web application.

You can easily enable or disable ModSecurity WAF to each web application in your RunCloud servers and adjust Paranoia Level and Anomaly Threshold parameters.

Our ModSecurity WAF comes with OWASP ModSecurity Core Rule Set (CRS) and allows you to add Rule Modification easily from the RunCloud dashboard.

What is ModSecurity

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx that is developed by Trustwave’s SpiderLabs.

WAF can be enabled in your website to provide an external security layer that increases security, detects, and prevents attacks before they reach web applications, because over 70% of all attacks are now carried out over the web application level.

It can help detect and prevent many attacks against your web application by checking all HTTP(s) requests you are willing to allow or block (e.g., request methods, request headers, content types, etc.) against its set of rules.

If the check fails, the visitor will not see the content of your website, predefined actions are performed, usually the visitor will get 403 Forbidden screen.

What is OWASP CRS

ModSecurity only is not enough to protect your website. You need to configure an additional rule set to make web protection work.

The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls.

The CRS aims to protect web applications from a wide range of attacks, with a minimum of false alerts, including:

  • SQL Injection (SQLi)
  • Cross Site Scripting (XSS)
  • Local File Inclusion (LFI)
  • Remote File Inclusion (RFI)
  • PHP Code Injection
  • Java Code Injection
  • HTTPoxy
  • Shellshock
  • Unix/Windows Shell Injection
  • Session Fixation
  • Scripting/Scanner/Bot Detection
  • Metadata/Error Leakages

How To Install ModSecurity and OWASP CRS

If you are very familiar with Linux and want to do it by yourself, you can check Netnea Apache / Modsecurity Tutorial to install ModSecurity & OWASP in your Apache server. Please do so at your own risk, because there will be no support when you have issues on this manual setup.

In RunCloud, we want to make it very easy for everyone, from beginner to expert, to enable or disable ModSecurity and OWASP CRS in each of your web applications on your servers easily, instead of having to log into the linux terminal to do it.

Please login to your RunCloud Dashboard, choose your server, go to Web Applications menu and click one of your web applications, and you will see the Firewall menu.

Click “Enable” to to enable Web Application Firewall (WAF) to your current web application, and click “Save Changes”.

That’s all. It is very easy!

You can customize WAF Settings by configuring paranoia level, anomaly threshold, and common rule exclusion.

Paranoia Level

Using paranoia level, you can choose the desired level of rule check to protect your web application.

Higher paranoia levels will strengthen web security, but will also increase the possibility of blocking some legitimate traffic due to false alarms (also named false positives or FPs).

From OWASP CRS website, there is a detailed explanation about the difference of paranoia levels.

A paranoia level of 1 (PL1) is default. At this level, most core rules are enabled. PL1 is advised for beginners, installations covering many different sites and applications, and for setups with standard security requirements.

Paranoia level 2 (PL2) includes many extra rules, for instance, enabling many regexp-based SQL and XSS injection protections, and adding extra keywords checked for code injections.

PL2 is advised for moderate to experienced users who desire more complete coverage, and for all installations with elevated security requirements.

Paranoia level 3 (PL3) enables more rules and keyword lists that cover less common attacks. PL3 also tweaks limits on all special characters used, which provides high coverage against unknown attack types, obfuscated attacks, and attempted WAF bypasses.

PL3 is aimed at users who are experienced at the handling of FPs and at installations with high security requirements.

Paranoia level 4 (PL4) further restricts special characters.

PL4 is advised for experienced users protecting installations with very high security requirements.

Recommended level for most use cases is 1 (default) or 2.

Anomaly Threshold

ModSecurity assigns a score for each security risk found in a request (Critical: 5, Error: 4, Warning: 3, Notice: 2).

Anomaly threshold determines the accumulated score for a request to be blocked.

Recommended level for production website is 5-10.

Common Rule Exclusion

OWASP CRS provides common rule exclusions for some popular Content Management System (CMS), including WordPress, Drupal, NextCloud, DocuWiki, and Xenforo.

If your current web application uses any of those CMS, please tick in the checkbox to reduce false positives and it will be automatically applied to your firewall.

Bonus: Custom Firewall Rule Modification

We also bring firewall rule modification to allow you to have more control on allow or block some traffic, or disable any ModSecurity rule ID.

Note: This special custom firewall rule modification feature is available only for Business plan users.

Using this feature, you can control incoming traffic by filtering requests based on Cookie, Country, Hostname, IP Address, URI and more.

First example, you can use custom firewall rules to block traffic from any country.

Second example, you can use a custom firewall rule to disable a rule when you see any legitimate traffic get blocked in your server (false positive). You can get CRS Rule ID from Nginx Error Log or ModSec Audit Log.

You can create multiple custom firewall rule and enable/disable it by toggling ON/OFF button, without having to delete this rule.

How To Test ModSecurity In Your Website?

After enabling Web Application Firewall (WAF) in your website, you probably want to know if this firewall works for your website or not.

You can try to visit this link on your website.

http://yourawesomedomain/?abc=../../

Visit this page twice, and you will see 403 Forbidden screen page.

It means that this visit is blocked by ModSecurity successfully.

If you use a higher paranoia level and get a lot of 403 Forbidden screen, please change Paranoia Level to 1.

Nginx Error Log and ModSec Audit Log

ModSecurity will log any blocked traffic in your website.

You can check it on Nginx Error Log and ModSec Audit Log in your server.

In RunCloud, you do not need to login to your server via terminal to check these logs.

You can simply go to the Web Server Log menu under your Web Application in RunCloud dashboard.

All blocked traffics will get listed on Nginx Error Log.

You can check ModSec Audit Log to see the details

Developer Tips: Custom Nginx Config

If you are an experienced developer and want to see the custom Nginx config that is applied on your web application when enabling Web Application Firewall, you can go to Nginx Config menu under your web application in RunCloud.

RunCloud adds two custom Nginx config for Web Application Firewall.

You can click it to see the configs, but you cannot edit or delete it. It will be automatically deleted when you disable WAF for this web application.

Summary

At RunCloud, we are all about making your dev life easier, delivering a fast service, and ensuring your server is managed properly.

Whether beginner or expert developer, we’ve made enabling or disabling Web Application Firewall (WAF) using ModSecurity and OWASP CRS easy for you.

ModSecurity and OWASP CRS helps protect your website from many types of attacks against your web application.

This feature is available to all paid plans (Basic, Pro, Business) for a limited time, and only available for Business plan after.

This feature has been a requested feature that we knew would be useful to you. Never hesitate to suggest new features that you want to see, and we will make it happen.