Skip to main content

Using mod_security with nine-manage-vhosts

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 (16.04) or higher 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. During the test phase, the logfile should be regularly checked for false positives.

  • On mod_security is enabled and will start blocking requests that 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. 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 syntax 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 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 is not 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, match a rule and therefore will be 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 to mitigate false positives, but keep in mind this should be the last action to take. It would be better to modify the suspicious requests. This way, 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%. In our case we experienced 10% less possible requests, 10% slower average response time.

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.