Red Hat JBoss Core Services ModSecurity Guide

ModSecurity has several dependencies to function successfully. Some of these dependencies are already included as a part of Red Hat JBoss Core Services.

The following table provides a list of ModSecurity dependencies:

The ModSecurity module is included as part of a Red Hat JBoss Core Services installation.

You can follow the procedures in the Red Hat JBoss Core Services Apache HTTP Server Installation Guide to download and install the Apache HTTP Server for your operating system.

You can load the ModSecurity module by using the LoadModule command.

ModSecurity functionality requires that you create rules that the system uses. Apache HTTP Server provides a preconfigured mod_security.conf.sample file in the HTTPD_HOME/modsecurity.d directory. To use ModSecurity rules, you must modify the mod_security.conf.sample file with settings that are appropriate for your environment. You can store the ModSecurity rules in the modsecurity.d directory or the modsecurity.d/activated_rules subdirectory.

You can use key ModSecurity configuration options to improve the performance of regular expressions, investigate ModSecurity 2.6 phase one moving to phase two hook, and allow use of certain directives in .htaccess files.

ModSecurity has several dependencies to function successfully. Some of these dependencies are already included as a part of Red Hat JBoss Core Services.

The following table provides a list of ModSecurity dependencies:

The ModSecurity module is included as part of a Red Hat JBoss Core Services installation. Apache HTTP Server provides many of the items that are required to run ModSecurity on Windows Server. However, you must ensure that your system complies with certain criteria to allow ModSecurity to function correctly.

ModSecurity functionality requires that you create rules that the system uses. Apache HTTP Server provides a preconfigured mod_security.conf.sample file in the HTTPD_HOME\modsecurity.d folder. To use ModSecurity rules, you must modify the mod_security.conf.sample file with settings that are appropriate for your environment. You can store the ModSecurity rules in the modsecurity.d folder or the modsecurity.d\activated_rules subfolder.

You can use key ModSecurity configuration options to improve the performance of regular expressions, investigate ModSecurity 2.6 phase one moving to phase two hook, and allow use of certain directives in .htaccess files.

You can apply rules to any of the five ModSecurity processing phases of the Apache request cycle:

A ModSecurity rule typically consists of four main parts:

A ModSecurity rule starts with a configuration directive. The configuration directives for ModSecurity are similar to the Apache HTTP Server directives. You can use most ModSecurity directives within the various Apache scope directives. However, you may only use some ModSecurity directives once in the main configuration file.

You must store these rules and the core rule files outside of the httpd.conf file. You can use Apache Include directives to call these rules. This facilitates the upgrade and migration of the rules.

You can define the following simple ModSecurity rule, for example, to check if the URI portion of a request equals a specific lowercase value:

SecRule REQUEST_URI "@streq /index.php" "id:1,phase:1,t:lowercase,deny"

The preceding ModSecurity rule consists of the following compoonents:

Based on the preceding example, during phase 1 of the Apache request cycle, the rule obtains the URI portion of the HTTP request and transforms the value to lowercase. The rule then checks if the transformed value equals /index.php. If the value does equal /index.php, ModSecurity denies the request and does not process any further rules.

You can define the following complex ModSecurity rule, for example, to check if a request has changed history:

SecRule REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS "history.pushstate|history.replacestate" "phase:4,deny,log,msg:'history-based attacks detected'"

The preceding ModSecurity rule consists of the following components:

Based on the preceding example, during phase 4 of the Apache request cycle, the rule checks different parts of the request cycle for history.pushstate() and history.replacestate() methods. If the rule finds these methods in the request URL string, request body, request header names, or request headers, the rule performs the following actions: