Chapter 2. ModSecurity Configuration
2.1. RHEL Configuration
2.1.1. Dependencies
ModSecurity has several dependencies to function. Some of these are already included as a part of Red Hat JBoss Core Services. A full listing is provided below:
| Dependency | Part of JBCS |
|---|---|
| Apache Portable Runtimes | Y |
| APR-Util | Y |
| mod_unique_id | Y |
| libcurl | Y |
| PCRE | Y |
| libxml2 | N |
| Lua5.x | N |
Red Hat JBoss Core Services for windows contains libxml2 and Lua5.x
2.1.2. Installation with Red Hat JBoss Core Services
ModSecurity comes as a part of the Red Hat JBoss Core Services package. For complete instructions on installing Red Hat JBoss Core Services, please refer to the installation guide for JBCS
2.1.3. Initial Configuration
ModSecurity is contained as a part of the Red Hat JBoss Core Services. This means that ModSecurity comes preconfigured and you will NOT have to use the apxs tool to build and install the module. In order to further configure Mod_sec, we must load the module into HTTPD.
2.1.3.1. Starting ModSecurity
You must load the libxml2 and lua5.1 libraries before loading the ModSecurity module. Use the following commands to load the libraries:
LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so
Then, load the ModSecurity module using the following:
LoadModule security2_module modules/mod_security2.so
2.1.3.2. Configuring the rules folder
The backbone of ModSecurities' functionality is the creation of rules that the system uses. However, we must know where to store rules in order to use them. JBCS comes with a preconfigured folder located at HTTPD_HOME/modsecurity.d. You can store rules in this folder or the activated_rules folder located underneath it.
Additionally, to use these rules we must setup the mod_security.conf.sample file to our specifications. Most importantly you MUST change the file name to mod_security.conf. This can be done with the following command:
mv mod_security.conf.sample ./mod_security.conf
In the file itself, you can set parameters for all of the configuration directives you will use with ModSecurity rules.
2.1.3.3. PCRE Warning
You want to avoid Apache using the bundled PCRE library and ModSecurity linking against the one provided by the operating system. The easiest way to do this is to compile Apache against the PCRE library provided by the operating system (or you can compile it against the latest PCRE version you downloaded from the main PCRE distribution site). You can do this at configure time using the --with-pcre switch. If you are not in a position to recompile Apache, then, to compile ModSecurity successfully, you’d still need to have access to the bundled PCRE headers (they are available only in the Apache source code) and change the include path for ModSecurity (as you did in step 7 above) to point to them (via the --with-pcre ModSecurity configure option). Do note that if your Apache is using an external PCRE library you can compile ModSecurity with WITH_PCRE_STUDY defined,which would possibly give you a slight performance edge in regular expression processing. Non-gcc compilers may have problems running out-of-the-box as the current build system was designed around the gcc compiler and some compiler/linker flags may differ. To use a non-gcc compiler you may need some manual Makefile tweaks if issues cannot be solved by exporting custom CFLAGS and CPPFLAGS environment variables.
2.1.3.4. Key Configuration Options
enable-pcre-jit: Enables JIT support from pcre >= 8.20 that can improve regex performance.
enable-lua-cache: Enables lua vm caching that can improve lua script performance. Difference just appears if ModSecurity must run more than one script per transaction.
enable-request-early: On ModSecurity 2.6 phase one has been moved to phase 2 hook, if you want to play around it use this option.
enable-htaccess-config: It will allow the follow directives to be used into .htaccess files when AllowOverride Options is set
2.2. Windows Configuration
2.2.1. Windows Dependencies
ModSecurity has several dependencies to function on Windows. Some of these are already included as a part of Red Hat JBoss Core Services. A full listing is provided below:
| Dependency | Part of JBCS on Windows |
|---|---|
| Apache Portable Runtimes | Y |
| APR-Util | Y |
| mod_unique_id | Y |
| libcurl | Y |
| PCRE | Y |
| libxml2 | Y |
| Lua5.x | Y |
2.2.2. Windows Installation
Many of the items required to run ModSecurity on windows are already contained in the JBCS package. However, for ModSecurity to function properly certain criteria must be met. Ensure the directory where you build software from source contains the Apache source you used to build the Apache web server and the ModSecurity source. For example:
-
Apache source is in
C:\ sourceDirectory\httpd-2.4.37 -
Apache has been installed to
C:\Apache2437 -
ModSecurity source is in
C:\ sourceDirectory\mod_security
In this case sourceDirectory is a generic directory used in conjunction with the project.
Additonally, ensure your build environment has the correct setup. The PATH environment variable must include the Visual Studio variables as set by vsvars32.bat AND also the CMAKE bin\ directory. Lastly, set and environment variable to the Apache source code directory: C:\ sourceDirectory\httpd-2.4.37
Once you are certain you have met the above criteria, you can install JBCS to the appropriate location on your C: drive.
ModSecurity comes as a part of the Red Hat JBoss Core Services package. For complete instructions on installing Red Hat JBoss Core Services, please refer to the installation guide for JBCS
2.2.3. Windows Configuration
2.2.3.1. Starting ModSecurity
You must load the libxml2 and lua5.1 libraries before loading the ModSecurity module. Use the following commands to load the libraries:
LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so
Then, load the ModSecurity module using the following:
LoadModule security2_module modules/mod_security2.so
2.2.3.2. Configuring Rules Directory
The backbone of ModSecurities' functionality is the creation of rules that the system uses. However, we must know where to store rules in order to use them. JBCS comes with a preconfigured directory located at HTTPD_HOME/modsecurity.d. You can store rules in this directory or the activated_rules directory located underneath it.
Additionally, to use these rules we must setup the mod_security.conf.sample file to our specifications. Most importantly you MUST change the file name to mod_security.conf.
2.2.3.3. Key Configuration Options
enable-pcre-jit: Enables JIT support from pcre >= 8.20 that can improve regex performance.
enable-lua-cache: Enables lua vm caching that can improve lua script performance. Difference just appears if ModSecurity must run more than one script per transaction.
enable-request-early: On ModSecurity 2.6 phase one has been moved to phase 2 hook, if you want to play around it use this option.
enable-htaccess-config: It will allow the follow directives to be used into .htaccess files when AllowOverride Options is set
