Recently we announced the first release candidate for libModSecurity (also as known as ModSecurity version 3). The goal was to turn ModSecurity into a mature library that could be used seamlessly regardless of web server or platform. The motivations for ModSecurity version 3 were summarized in details in a previous blog post.
This release candidate may not affect the majority of the users from version 2.x as they may want to keep using the version that they currently use for Apache web servers while testing the bleeding-edge version of ModSecurity. That said, we highly recommend that Nginx users do the switch to libModSecurity due to known issues with version 2.x.
It's worth mentioning that in version 3, the web server components were detached from the main repository and are now called connectors, each with its own release and development cycle. We are starting with two major connectors: Nginx and Apache, detailed below.
The Nginx connector was the first connector to be coded. Its development started in parallel with libModSecurity development in a complementary approach. Because of this, the Nnginx connector is the best option if you want to try the libModSecurity for now. It has been used by the community for quite some time. Over that time it has been demonstrated to be much more stable than version 2.x while also getting the benefit of the new architecture and new features of libModSecurity.
The image below shows the active development of the Nginx-Connector since the first development release back in 2015:
The compilation instructions along with further details of the Nginx connector can be found at its GitHub home: https://github.com/SpiderLabs/ModSecurity-nginx
The Apache connector development started as a Google Summer of Code project by the student Tahir Ramzan [https://github.com/tahirramzan] and the supervision of the SpiderLabs team. In the past months the component was refactored to support new features from libModSecurity. It's also been developed to gain its own set of regression tests and with compatibility to be tested using the version 2.x regression test.
Although functional, the Apache connector is not meant to be used in production yet. One of the missing pieces is the capability to load the rules 1:1 from the version 2.x to version 3.x. Currently, the ModSecurity rules need to be written in a special configuration segment. The plan is to have a compatibility layer that allows the loading of configuration without needing to change anything. This is discussed more here: https://sourceforge.net/p/mod-security/mailman/message/35961658/
The Apache connector is also hosted at GitHub here: https://github.com/SpiderLabs/ModSecurity-apache
The core ModSecurity team at SpiderLabs will be holding a training session at AppSec USA. The training is tailored for web application defenders who are charged with protecting live web applications. It will cover significant updates, improvements and new features which have been added to this bleeding-edge version of the open-source libModSecurity (aka v3) WAF. We've created this training for anyone who's interested in sharpening their web security defensive skills to detect and stop web attacks as well as mastering the latest version ModSecurity. More information is available here: https://appsecusa2017.sched.com/event/B2VV
Even if you don't attend the training but want to hang out and talk about ModSecurity, come by and say "Hi!" to us at AppSec USA. We will be there for the entire event. =)
