Back to home

Using mod_security with nine-manage-vhosts

  1. What is mod_security?
  2. What options are available?
  3. How can i use mod_security?
  4. How can i check if mod_security is working?
  5. Are there any potential disadvantages using mod_security?

What is mod_security?

mod_security is the implementation of the OWASP rule set for the apache webserver. mod_security acts as an application firewall and can filter requests that aim for XSS, SQL injections and similar harmful requests.

We are using the mod_security ““core rule set” on our servers.

What options are available?

All managed servers that are running Ubuntu Xenial or Bionic do have the required module installed. To not disrupt any services we decided to deactivate mod_security by default. This applies to creating new vhosts and changing existing ones.

To activate the filtering you can use nine-manage-vhosts. There are three options for mod_security you can choose from:

  • Off
    mod_security is disabled for this vhost. There is no filtering taking place

  • DetectionOnly
    mod_security is in detection state, which means any potential violations will be logged in the domains logfile. This mode is highly recommended when the effects of enabling mod_security are unknown and before finally enabling mod_security

  • On
    mod_security is enabled and will start blocking requests that do match the core rule set

How can i use mod_security?

mod_security is implemented in nine-manage-vhosts and can be managed on your own, following the specific needs for your websites or vhosts.

To enable mod_security via nine-manage-vhosts you need to pass the template variable “MODSEC”:
--template-variable=MODSEC=.

Let´s activate mod_security for an example vhost named nine.ch. We start by listing the existing vhosts and checking the current state of mod_security.

$ sudo nine-manage-vhosts virtual-host list
nine.ch
=======
              DOMAIN: nine.ch
                USER: www-data
             WEBROOT: /home/www-data/ninech
            TEMPLATE: default
  TEMPLATE VARIABLES: MODSEC
                      Off
                      PHP_VERSION
                      7.3
             ALIASES: www.nine.ch

We can see that mod_security is currently set to “Off”.

Let´s activate the mode “DetectionOnly”:

$ sudo nine-manage-vhosts virtual-host update nine.ch --template-variable=MODSEC=DetectionOnly

Virtual Host updated: nine.ch
nine.ch
=======
              DOMAIN: nine.ch
                USER: www-data
             WEBROOT: /home/www-data/ninech
            TEMPLATE: default
  TEMPLATE VARIABLES: MODSEC
                      DetectionOnly
                      PHP_VERSION
                      7.3
             ALIASES: www.nine.ch

The synopsis for enabling and blocking requests is how you already guess:

$ sudo nine-manage-vhosts virtual-host update nine.ch --template-variable=MODSEC=On

Virtual Host updated: nine.ch
nine.ch
===========
              DOMAIN: nine.ch
                USER: www-data
             WEBROOT: /home/www-data/ninech
            TEMPLATE: default
  TEMPLATE VARIABLES: MODSEC
                      On
                      PHP_VERSION
                      7.3
             ALIASES: www.nine.ch

Of course you can also combine mod_security with the existing Let´s Encrypt implementation:

$ sudo nine-manage-vhosts virtual-host update nine.ch --template=default_letsencrypt_https --template-variable=MODSEC=On

Virtual Host updated: nine.ch
nine.ch
=================
              DOMAIN: nine.ch
                USER: www-data
             WEBROOT: /home/www-data/ninech
            TEMPLATE: default_letsencrypt_https
  TEMPLATE VARIABLES: MODSEC
                      On
                      PHP_VERSION
                      7.3
             ALIASES: www.nine.ch

How can i check if mod_security is working?

If mod_security wasn´t deactivated (“Off”), every action will be logged in the domains error log.

/home/<User>/logs/<Domain>.error.log

Here are two log examples of the same requests, but with different settings for mod_security.

DetectionOnly

ModSecurity: Warning. Operator GE matched 5 at TX:anomaly_score. [file "/etc/apache2/modsecurity.d/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "57"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 8)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "nine.ch"] [uri "/test.php"] [unique_id "Xa-73MmCIluUzjqCJdRfuQAAAI0"]

mod_security is logging a warning, but not proactively intervening. The request will hit the application.

On

ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/etc/apache2/modsecurity.d/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "57"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 8)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "nine.ch"] [uri "/test.php"] [unique_id "Xa-7M7JyjGSEZvBliDDm7gAAAFA"]

If activated, mod_security will actively block the request and not forward it to the application.

The id is reflecting the rule mod_security is applying.

Are there any potential disadvantages using mod_security?

mod_security is a complex solution that has to parse every single request and analyse it for potential harmful content or payload. This brings two main potential disadvantages.

False positives

There is always the chance that legitimate requests are detected as harmful and do match a rule and therefore will blocked. If you are for example using a self maintained version of phpMyAdmin it is very likely that there will be blocked requests.

As mentioned earlier you should always start by using the mode “DetectionOnly” and only then fully activate mod_security.

mod_security messages are logged in the domains error log file:

/home/<User>/logs/<Domain>.error.log

We do have the option to deactivate single rules of mod_security server wide to mitigate false positives, but keep in mind this should be the last option. The proper option would be to modify requests and payloads in a way that they don´t match the mod_security rules anymore.

Performance implications

When we tested the mod_security feature we observed a performance penalty of about 10%. This means 10% less possible requests, 10% slower average and 90 percentile response time and bandwith. Please keep in mind that these values might vary heavily depending on the application. Again, always start by using the mode “DetectionOnly” to see the effects on your application.

Didn't find what you were looking for?

Contact our support:

+41 44 637 40 40 Support Portal support@nine.ch