The following block triggers an error in v3 (nginx):
SecRule REQUEST_FILENAME "@unconditionalMatch" \
"id:888888,\
phase:1\
chain"
SecRuleScript test.lua "nolog"
The error is:
nginx: [emerg] "modsecurity_rules_file" directive Disruptive actions can only be specified by chain starter rules. in /usr/local/nginx/conf/conf.d/npm.conf:13
nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed
To Reproduce
- Lua must be enabled for ModSecurity
- Use the rule block above
- Create a Lua script file like the following, named "test.lua":
function main()
return nil;
end
- Put the Lua script into the same directory as the rule file
- Start / reload nginx
Expected behavior
nolog is not a disruptive action in the source code and should not trigger the error. The reason we even noticed this behaviour is, that the documentation says that actions are optional for SecRuleScript but the parser cannot cope with such a rule and will throw an error while parsing the next rule, because it thinks that the end of the last rule wasn't reached.
Full discussion: coreruleset/body-decompress-plugin#4.
Server
- ModSecurity version (and connector): v3.0.12; connector v1.0.3
- WebServer: nginx 1.25.3
- OS (and distro): Debian Linux
** Additional context**
The actions list of SecRuleScript is currently mandatory, even though the documentation says it isn't. However, the parser throws an error while parsing the next rule, instead of complaining about the missing actions list. This is very confusing to users.
The following block triggers an error in v3 (nginx):
The error is:
To Reproduce
Expected behavior
nologis not a disruptive action in the source code and should not trigger the error. The reason we even noticed this behaviour is, that the documentation says that actions are optional forSecRuleScriptbut the parser cannot cope with such a rule and will throw an error while parsing the next rule, because it thinks that the end of the last rule wasn't reached.Full discussion: coreruleset/body-decompress-plugin#4.
Server
** Additional context**
The actions list of
SecRuleScriptis currently mandatory, even though the documentation says it isn't. However, the parser throws an error while parsing the next rule, instead of complaining about the missing actions list. This is very confusing to users.