0

Hello I'm using libmodsecurity (4e6e4243|v3.0.3) on nginx(1.15.12) with the connector being the current master (d7101e13685) and OWASP CRS on (ab24a20faf28156f0|v3.1.0).

I am trying to log the POST request body (C part in modsecurity) on a specific URL with something akin to the following rule:

SecRule REQUEST_URI "/some_url/processor.php" \
  "id:66600001,\
  phase:2,\
  t:none,\
  log,\
  ctl:auditLogParts=ABCIJDEFHZ,\
  pass"

which results on nginx not starting with the following error:

Expecting an action, got: ctl:auditLogParts=ABCIJDEFHZ,\

I've tried multiple variations of the ctl, including ctl:auditLogParts=ABCFHZ and ctl:auditLogParts=AC. All throwing the same error.

Curiously doing it with ctl:auditLogParts=+C allows nginx to start but unfortunately the audit log does not show the request body of the POST, actually it shows nothing.

Of course changing the SecAuditLogParts config in modsecurity.conf from ABIJDEFHZ (default) to ABCIJDEFHZ changes the logging but makes us non compliant on a shitload of rules.

ateam
  • 1
  • 2
  • I presume you have SecRequestBodyAccess set to on? If not add `ctl:requestBodyAccess=On` to your config. Also I don’t understand how adding a part SecAuditLogParts causes rules to fail - that directive should only control what’s logged, not what’s seen by the rules (which is controlled by SecRequestBodyAccess). – Barry Pollard May 07 '19 at 21:26
  • Yes, there is `SecRequestBodyAccess On` in modsecurity.conf. I agree with you, `ctl:auditLogParts` should not be crashing the config... – ateam May 08 '19 at 17:39
  • Give an example of a rule which is flagging when you add this, but not flagging when you don’t. Something else must be going on. – Barry Pollard May 09 '19 at 20:24
  • By flagging you mean that nginx refuses to start? – ateam May 13 '19 at 18:05
  • "Of course changing the SecAuditLogParts... changes the logging but makes us non compliant on a shitload of rules." Give an example of a rule which did not block before, but does block after you turn that on. – Barry Pollard May 13 '19 at 18:08
  • Sorry, by compliance I meant things like "don't log user passwords". – ateam May 13 '19 at 18:18
  • Well that's why I think the OWASP CRS should have some default rules: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1073. That's what I do and always log part I (which is a better option than C: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#SecAuditLogParts ). However as per the comment on that issue that won't work in ModSecurity 3.0.3. I suggest you raise an issue at https://github.com/SpiderLabs/ModSecurity/issues - it may be you have a bug in Nginx version of ModSecurity. – Barry Pollard May 13 '19 at 18:30
  • Roger. As an addendum, we do log part I, the thing is, the specific POST request that sends a CRS warning `920240 URL Encoding Abuse Attack Attempt`, that we are trying to explain and correct, does not send into the audit log any part I (looks empty) so we where wondering what was happening by also logging part C... – ateam May 14 '19 at 00:14

0 Answers0