We need to cover for https://github.com/SpiderLabs/ModSecurity/issues/1797
Here is the plan as discussed in the community chat on slack last night:
The plan is thus
UPDATE (dune73): No longer sure this works. Given it's a parser thing, we might fail to load the config despite the condition.
URLENCODE: Need to confirm the bad news. It's the parser at startup time.
ModSec nginx: [emerg] "modsecurity_rules_file" directive Rules error. File: /tmp/crs-3.1-RC1/rules/REQUEST-901-INITIALIZATION.conf. Line: 289. Column: 119. Expecting an action, got: ctl:requestBodyProcessor=URLENCODED" in /opt/nginx-1.13.12/conf/nginx.conf:21
I've shot a few e-mails to Joe at Trustwave about how the CRS now breaks on newest ModSec 3. So far TW has not committed to a ModSec 3 release.
Thanks @lifeforms.
You can lead a horse to water, you can't make it drink.
That's sad, it is one big hole in a default install, maybe ModSec 3 is for use in servers where clients are well behaved and always stick to RFC's.
ModSecurity 3.0.3 has been released (much thanks @zimmerle :D ) which should resolve this problem!
Thank you for the work in convincing the ModSecurity team for a new release to fix compatibility with the CRS. Really appreciate your work @lifeforms @dune73
@Cryptophobia well sure but don't forget to thank the ModSec development team who are doing the work :P
You are most welcome @Cryptophobia. The biggest benefactor was probably us not being ready for a release far too long so TW was quicker with their planned release.
Most helpful comment
@Cryptophobia well sure but don't forget to thank the ModSec development team who are doing the work :P