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.
- 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
ch::nevis::nevisproxy::filter::modsecurity::ModsecurityFilter
libModsecurityFilter.so.1
+NEEDS_SWITCHING_PROTOCOLS
+RESET_PARAMS
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
Unit: byte
Range: min: 1024, max: unlimited
Usage Constraints: optional
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
Syntax: <request_attribute>:<TX_attribute>
Usage Constraints: optional
This parameter describes a newline-separated list of TX attributes that can be saved to the current request.
The <TX_attribute>
is the name used in the ModSecurity rule. For example here the <TX_attribute>
is "reqbody":
SecRule REQUEST_BODY ".*deny.*" "deny,phase:2,id:3,setvar:TX.reqbody=denied"
The <request_attribute>
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 <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.
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:
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
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.pipeStart 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
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.