In this post I will install and configure Libmodsecurity which is a complete rewrite of the ModSecurity platform (aka ModSecurity v2.x) and functions as an Open Source Web Application Firewall (WAF).

Libmodsecurity is a complete rewrite of the ModSecurity platform. When it was first devised the ModSecurity project started as just an Apache module. Over time the project has been extended, due to popular demand, to support other platforms including (but not limited to) Nginx and IIS. In order to provide for the growing demand for additional platform support, it has became necessary to remove the Apache dependencies underlying this project, making it more platform independent.

As a result of this goal we have rearchitected Libmodsecurity such that it is no longer dependent on the Apache web server (both at compilation and during runtime). One side effect of this is that across all platforms users can expect increased performance. Additionally, we have taken this opportunity to lay the groundwork for some new features that users have been long seeking. For example we are looking to natively support auditlogs in the JSON format, along with a host of other functionality in future versions.

Source: https://github.com/SpiderLabs/ModSecurity


Install ModSecurity

# on Ubuntu
$ sudo apt-get install libapache2-mod-security2
$ sudo systemctl restart apache2

# on Debian
$ sudo apt install libapache2-modsecurity
$ sudo systemctl restart apache2


Configure ModSecurity

Rename the default ModSecurity file:

$ sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf


By default, ModSecurity comes with core rule set (security rules) located under /usr/share/modsecurity-crs. But it is recommended to download the OWASP ModSecurity CRS from GitHub repository.


Download the OWASP ModSecurity CRS from Github:

$ cd ~
$ git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git


Move and rename crs-setup.conf.example to crs-setup.conf. Then move rules/ directory as well.

$ cd ~/owasp-modsecurity-crs
$ sudo mv crs-setup.conf.example /etc/modsecurity/crs-setup.conf
$ sudo mv rules/ /etc/modsecurity/


Adjust your Apache security2.conf file to ensure the ModSecurity rules will be loaded.

$ sudo nano etc/apache2/mods-available/security2.conf

The path for configuration files *.conf in the IncludeOptional directive should match the path we copied above the modsecurity files which is correct with /etc/modsecurity/*.conf


Add another Include directive pointing to the ruleset:

Include /etc/modsecurity/rules/*.conf



After adding the rule above, I tried to restart the Apache web server and was running into an error as shown below.

$ sudo systemctl restart apache2


ModSecurity: Found another rule with the same id


Here you can see the crs-setup.conf file.

ModSecurity: Found another rule with the same id

To solve the problem, I had to comment out the existing Include directive as follows, the default configuration of the OWASP ModSecurity CRS and this Include directive, will import two times the crs-setup.conf file as seen below.


If we do not comment out this Include directive, we had two times included the crs-setup.conf file, one time /etc/modsecurity/crs-setup.conf and one time /etc/modsecurity/crs/crs-setup.conf and both of them include the id:900990.


Test ModSecurity

You can first check the installed version by using

apt-cache show libapache2-mod-security2



By default the engine will be in DetectionOnly mode.

The following modes are available:
SecRule Engine On -> processing rules and block traffic if an attack is detected
SecRule Engine Off -> do not process rules
SecRule Engine DetectionOnly -> process rules but only log them

To enable the modsecurity rule engine we need to change it to:

SecRuleEngine on

After that we need to restart Apache

$ sudo systemctl restart apache2



You can also use the virtual host configuration file to override settings for a specific site from the global settings in /etc/modsecurity/modsecurity.conf

Here I will change the SecRuleEngine to DetectionOnly for the virtual host wiki.domain.tld

<VirtualHost *:80>
	ServerName wiki.domain.tld
	ServerAdmin admin@domain.tld

        
        SecRuleEngine DetectionOnly


	DocumentRoot /var/www/mediawiki/html

        <Directory /var/www/mediawiki/html>
   	AllowOverride All
 	</Directory>

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>


You can also exclude specific modsecurity rules by using the SecRuleRemoveById directive in the virtual host configuration file as follows. You can list here multiple rules by a space between them.

You can exclude here rules for the whole site, specific pages or specific subfolders.

For WordPress I have to exclude the security rule 951240, 949110 and 951220 in order to work.

For OwnCloud I have to exclude the security rule 949110.

For MediaWiki I have to exclude the security rules 951240 949110 951220 980140 959100 in order everything is working fine here.

<VirtualHost *:80>
	ServerName wiki.domain.tld
	ServerAdmin admin@domain.tld

        
        SecRuleEngine On


	DocumentRoot /var/www/mediawiki/html

        <Directory /var/www/mediawiki/html>
   	AllowOverride All
 	</Directory>



        # for the root folder 
        <LocationMatch "/">
  		SecRuleRemoveById 951240 949110 951220 980140 959100
	</LocationMatch>


        # only for a specific subfolder
        <LocationMatch "/wp-admin">
  		SecRuleRemoveById 949110 951240
	</LocationMatch>


        # only for a specific page
        <LocationMatch "/wp-admin/edit.php">
  		SecRuleRemoveById 949110 951240
	</LocationMatch>




	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>



In case some rule will kick in, the user will see the following HTTP/1.1 403 Forbidden Message.




Analyze Logs

The path of the log files from modsecurity can be configured in the /etc/modsecurity/modsecurity.conf file.


/var/log/apache2/modsec_audit.log

–8afeeb16-A– to –8afeeb16-Z– for example is one log entry.






More Information about ModSecurity

modsecurity (Libmodsecurity)
Open Source Web Application Firewall (WAF)

Libmodsecurity is one component of the ModSecurity v3 project. The library codebase serves as an interface to ModSecurity Connectors taking in web traffic and applying traditional ModSecurity processing. In general, it provides the capability to load/interpret rules written in the ModSecurity SecRules format and apply them to HTTP content provided by your application via Connectors.

If you are looking for ModSecurity for Apache (aka ModSecurity v2.x), it is still under maintenance and available: here.

What is the difference between this project and the old ModSecurity (v2.x.x)?

  • All Apache dependencies have been removed
  • Higher performance
  • New features
  • New architecture


Libmodsecurity is a complete rewrite of the ModSecurity platform. When it was first devised the ModSecurity project started as just an Apache module. Over time the project has been extended, due to popular demand, to support other platforms including (but not limited to) Nginx and IIS. In order to provide for the growing demand for additional platform support, it has became necessary to remove the Apache dependencies underlying this project, making it more platform independent.

As a result of this goal we have rearchitected Libmodsecurity such that it is no longer dependent on the Apache web server (both at compilation and during runtime). One side effect of this is that across all platforms users can expect increased performance. Additionally, we have taken this opportunity to lay the groundwork for some new features that users have been long seeking. For example we are looking to natively support auditlogs in the JSON format, along with a host of other functionality in future versions.

It is no longer just a module.

The ‘ModSecurity’ branch no longer contains the traditional module logic (for Nginx, Apache, and IIS) that has traditionally been packaged all together. Instead, this branch only contains the library portion (libmodsecurity) for this project. This library is consumed by what we have termed ‘Connectors’ these connectors will interface with your webserver and provide the library with a common format that it understands. Each of these connectors is maintained as a separate GitHub project. For instance, the Nginx connector is supplied by the ModSecurity-nginx project (https://github.com/SpiderLabs/ModSecurity-nginx).

Keeping these connectors separated allows each project to have different release cycles, issues and development trees. Additionally, it means that when you install ModSecurity v3 you only get exactly what you need, no extras you won’t be using.

Read more on … https://github.com/SpiderLabs/ModSecurity


Secure Apache using ModSecurity on Ubuntu 18/19/20
https://www.techsupportpk.com/2020/04/secure-apache-web-server-content-using-modsecurity-ubuntu-debian.html

Mod Security is an open-source, cross-platform web application firewall (WAF) module. Known as the “Swiss Army Knife” of WAFs, it enables web application defenders to gain visibility into HTTP(S) traffic and provides a power rules language and API to implement advanced protections. ModSecurity is a toolkit for real-time web application monitoring, logging, and access control.

ModSecurity
https://en.wikipedia.org/wiki/ModSecurity
Being originally an Apache module, porting ModSecurity to other platforms was time-consuming and had high maintenance costs. As a result of this, a complete rewrite was started in December 2015. This new iteration, libmodsecurity, changes the underlying architecture, separating ModSecurity into a standalone engine that communicates with the web server via an API. This modular architecture-based WAF, which was announced for public use in January 2018, became libmodsecurity (ModSecurity version 3.0) and has supported connectors for Nginx and Apache.

Trustwave is announcing the End-of-Life (EOL) of our support for ModSecurity effective July 1, 2024. We will then hand over the maintenance of ModSecurity code back to the open-source community. 
Source: https://www.trustwave.com/en-us/resources/security-resources/software-updates/end-of-sale-and-trustwave-support-for-modsecurity-web-application-firewall/








Links

ModSecurity (Libmodsecurity)
https://github.com/SpiderLabs/ModSecurity

ModSecurity
https://en.wikipedia.org/wiki/ModSecurity

Open Web Application Security Project (OWASP)
https://owasp.org/
https://en.wikipedia.org/wiki/OWASP

How to disable ModSecurity rules that cause 403 errors
https://anto.online/guides/how-to-disable-modsecurity-rules-that-cause-403-errors/