Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility with ModSecurity version 2.9.1 #34

Closed
zimmerle opened this issue Mar 10, 2016 · 9 comments
Closed

Compatibility with ModSecurity version 2.9.1 #34

zimmerle opened this issue Mar 10, 2016 · 9 comments

Comments

@zimmerle
Copy link

Hi Guys,

I am following the project for a while, congrats!

Yesterday we have released ModSecurity version 2.9.1. There was a modification in the logs that might affect you. The issue owasp-modsecurity/ModSecurity#840 contains more details about it.

Also, in v2.9.1 there is this possibility to save the audit logs in JSON format, not sure if the format is structured in the shape that you need for elasticsearch, but may be useful.

@bitsofinfo
Copy link
Owner

Does this affect the audit logs?

@bitsofinfo
Copy link
Owner

I just don't have the time to look at this now @zimmerie, thanks for bringing it to the projects attention though! Perhaps yourself or some prior contributors @MWilkinson @breml could take a look?

@breml
Copy link
Contributor

breml commented Mar 16, 2016

I quickly scrolled through owasp-modsecurity/ModSecurity#840 and as far as I understand, this affects mainly error.log and not audit.log format. @zimmerle can you confirm?

@zimmerle
Copy link
Author

Hi @breml,

The only change that seems relevant to you is the fact that now we have this new line:

Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client %s] ModSecurity: %s%s [uri "%s"]%s

This happens to appear on the "section H" of the audit logs.

@Alex-Kw
Copy link
Contributor

Alex-Kw commented Oct 3, 2017

I believe I'm seeing this issue. I'm noticing this issue with section H parsing above 2.9.0. Field names like auditLogTrailer.Action are normal but there is a field name called "
auditLogTrailer. [line 271] [level 3] [client $IPADDR] ModSecurity" with data starting as the log continues, "Access denied with code ....."

This results in a bunch of new unique field names, which logstash/elastic didn't like. for now I've edited my elastic template to allow more field names as I look at the regex, but I figure you would be able to fix this much easier than I could. If I figure it out I will update.

Edit, it appears this is happening due to the "ModSecurity:" section of the Apache-Error line having a colon. The section H is split on value_split => ":" so that section of the audit log trailer seems to create the unwanted behavior with the parsing thereof.

@bitsofinfo
Copy link
Owner

Please submit a PR if you have a patch

@Alex-Kw
Copy link
Contributor

Alex-Kw commented Oct 4, 2017

If I figure out a good way to handle it, I will. Thank you.

@Alex-Kw
Copy link
Contributor

Alex-Kw commented Oct 4, 2017

I've submitted a pull request that works well enough for me. I will not be offended if you do not like it :) I opted to go with dropping that line from the raw section H, prior to splitting that section. I did this because the valuable data in that one line, as far as I could tell, was already extracted otherwise.

I haven't been able to find a better way to contact you, but wanted to thank you for this project. I use it with mlogc and logstash http input plugin (behind nginx https) to ship logs to an elk stack from several remote sensors. It's been an awesome replacement to auditconsole so far. Cheers.

@bitsofinfo
Copy link
Owner

Should be addressed by 1.2.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants