ModsecurityFilter

The ModsecurityFilter parses ModSecurity files and checks requests against the rules described in the file. The ModsecurityFilter can be used with the following restrictions:

• No rewriting is supported. Any rewrite rule will be silently ignored.
• The ModsecurityFilter is built for users who have experience with the ModSecurity suite. Nevis only offers limited support for ModSecurity related problems.
• See the chapter ModSecurity Configuration Guide for more information on how to setup the ModSecurityFilter.

Classname

ch::nevis::nevisproxy::filter::modsecurity::ModsecurityFilter

Library

libModsecurityFilter.so.1

Configuration

ConfigFile

Type: string: filename with absolute path
Usage Constraints: required

ModSecurity inlcude file with the rules. The file will automatically be reloaded if the content changes. If other files included by this config file change, this config file has to be touched to reload it automatically. The file modification will be checked in the interval configured under periodicity in the Timer section in the file navajo.xml.

MemoryCacheSize

Type: integer, byte
Usage Constraints: optional, min: 1024, max: unlimited
Default: 102400

If the request body reaches the size configured by this parameter, the system will cache the request body into a file instead of a memory. The system will then pass this file to the ModSecurity Library.

AlertLevel

Type: enum
Possible values: ERROR, NOTICE, INFO
Default: ERROR

Configures the alert level of the log lines for blocked requests or responses in the navajo.log file. The following events are concerned: MS01, MS02, MS03, and MS04.

DelegateFromTx

Type: newline-separated list of attribute names
Usage Constraints: optional

This parameter describes a newline-separated list of TX attributes that can be saved to the current request.

Each line has the following syntax: <name of the request attribute>:<name of the TX attribute>

• <name of the TX attribute>: This is the name used in the ModSecurity rule. For example:

  SecRule REQUEST_BODY ".*deny.*" "deny,phase:2,id:3,setvar:TX.reqbody=denied"

  In this example, the <name of the TX attribute> is "reqbody".

• <name of the request attribute>: This is the name under which the value of the TX variable should be saved in the request. You can access the variable for example from a LuaFilter via req:getAttribute().

  If the <name of the request attribute> is prefixed with "environment.", then it is possible to use the attribute in the LogFormat of the Apache access log.

  For example, your DelegateFromTx parameter is set to "environment.reqheader:reqheader".

  In this case, you can trace the reqheader variable by adding "%{reqheader}e" to the LogFormat attribute in the Server section of the navajo.xml configuration file.

More information about ModSecurity and the ModSecurity CRS

• Your installed nevisProxy package includes an example on how to configure ModSecurity core rules with the ModsecurityFilter. You find the example here: /opt/nevisproxy/examples/WAF/ModsecurityFilter_with_modsecurity_core_rule_set.example
• Additionally, you find more detailed information in the ModSecurity Configuration Guide.

ModSecurity Bug

Due to a bug in ModSecurity, the ruleRemoveTargetById action may cause a segmentation fault in nevisProxy if you use a syntax similar to the following example:

SecRule REQUEST_URI "^/some/uri" "phase:1,id:001,t:none,log,ctl:ruleRemoveTargetById=0000"

To prevent the fault from happening, add a separator (;) and some ARGS at the end of the rule:

SecRule REQUEST_URI "^/some/ur" "phase:1,id:001,t:none,log,ctl:ruleRemoveTargetById=921130;ARGS:menu-name"

Log rotation of the AuditLog

Due to a missing feature in ModSecurity, AuditLog's log rotation does not work natively. A workaround for this issue is to use a named-pipe and redirect the log messages to a process that handles the log rotation:

1. Create a named-pipe that gives write access to the proxy process and read access to the logger process.

   mkfifo /var/opt/nevisproxy/test/auditlog.pipe

2. Change the AuditLog’s destination in the Proxy’s ModSecurity config to the above created named-pipe.

   SecRuleEngine On
   SecDebugLogLevel 9
   SecDefaultAction "phase:1,auditlog,pass"
   SecAuditEngine on
   SecAuditLog /var/opt/nevisproxy/test/auditlog.pipe

3. Start the logger process that does the log rotation, and configure it to read from the named-pipe.

   /opt/nevisproxy/bin/bclogmgr pidfile=/var/opt/nevisproxy/test/auditlogger.pid size=2048 archives=5 archivedir=/var/opt/nevisproxy/test/logs persistent input=/var/opt/nevisproxy/test/auditlog.pipe /var/opt/nevisproxy/test/logs/audit.log

4. Start the proxy instance.

   Note that, when accessing the named-pipe, the pipe blocks until there is at least one reader and one writer. This means that if the logger process is not running, then the Proxy process will hang in the AuditLog’s file open function until the logger process is started. The same is true the other way: the logger process will hang until the Proxy (or something else) opens the named-pipe for writing.

   To avoid Proxy hang on service start or restart, make sure that the logger process is always running.