-
Notifications
You must be signed in to change notification settings - Fork 291
[Question]How to best tune audit/debug log so they ONLY are produced when tx's would be blocked by ModSecurity? #190
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
Comments
@victorhora @zimmerle @martinhsv Looking to your guidance here if you have a spare 20 mins, related to this git issue partially as well. Trying to productionalize the v3 ModSecurity WAF w NGINX but I keep coming back to a few main pain points around how I will accomplish getting proper insights in My biggest concerns are currently this in the WAF design:
ex:
In DetectOnly mode I feel I need something like this to be adequately prepared to handle evaluations in non-blocking mode, right now there are no logs for DetectionOnly mode: ex:
Note the small change in wording to account for the non-blocking mode as well as the change in error log level (error) to (notice). Is there a simple snippit I could add either in the connector here or in the https://github.com/SpiderLabs/ModSecurity source to accomplish this when in non-blocking mode? I would be happy to PR it if you think its a simple one liner and could point me where it goes and the snippit to test with? EDIT - PART 1 SOLVED
I owe a beer to the one that helps me out with these headaches, they are the major last points of issue we have with the WAF solution currently. I suck at C code too 😆 . If this was some Java or Lua I think I could likely handle it myself. Edit - Observed behavior is that when running in DetectionOnly mode I get no stdout/stderror logs of the event to view in my docker container pod. IF I run audit log mode set to On to grab everything I do see section H exclusively in the audit log files populated with the blocks, so I know modsec has saved the data it could expose more helpfully in multiple places: Ex:
Looks like for these that don't get exposed to stdout/err it adds cc @airween I know I talked to you on slack about this from the logging side since you know C much better than me and you had hacked together some C files that let you do some of the audit logging to be specifically only blocked tx's with an extra rule id made around it as well. Will re-review our convo too to see if some of the custom src you wrote up makes sense as a PR. |
Trying to follow the code around and finding where messages are generated is here: https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/rule_message.cc#L66 Seems then this is the meat of what decides what goes just to a copy saved for audit logging or also to server logging if its an error potentially: Althought I am a bit hazy trying to follow the point of if(lastlog) {..} else {...} bit. But otherwise seems like if I wanted the DetectionOnly(which just produces the warning message) to also go to the server error log logic of nxinx or apache. Then I could remove the if() checks and let:
Becomes:
Within this file... but idk if I should just do it at the lastlog bit or every single spot I see this... code is hard to follow for a newb unfamiliar to the project xD . I also see a serverLog call here, but no conditionals or rule messages around here so I don't view this as a place to modify it: |
Hmm did try editing this method to be like this, but my NGINX logs did not print the warning statements when in DetectionOnly mode :/ :
Was really hoping that would do the trick of printing the warning messages out to webserver log. |
Update, airween made the point to see the Warning logs I must run NGX in debug mode, then they will appear with INFO level. This is true. Now my goal for part 1. is to change ModSecurities behavior from logging them as INFO to rather logging them as NOTICE or ERROR. Makes no sense but its how I run in production and I need these logs to not get lost. AH HA, can be done here by setting to _ERR or whatever I want. Part 1 solved. |
Last part 2 is how to elegantly force ModSecurity or the ModSecurity-Nginx connector to ONLY Audit log file when a TX was blocked by the WAF, OR if a TX WOULD have been blocked by the WAF(when in DetectionOnly mode). Any easy snippits in the src I can edit to achieve this? |
Actually part 2 works fine it seems when I remove the status options associated with audit logging. closing this. |
One Idea I had was replacing here:
https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/src/ngx_http_modsecurity_log.c#L72
This should allow only audit/debug logging to run on transactions that were intervened. This is very close to what I would want I think, but I would lose logs I think if I were running the WAF in non-blocking mode because no interventions occur right? Is there a difference reference I can lock in on here that accomplishes "only log when WAF rules have been violated"?
Note I tried to set relevancy to HTTP 400/403(the statuses that cause blocking by WAF), but problem there is my backend API's my NGINX reverse proxy too can sometimes throw 400/403 and I want to prevent those from being logged.
Also Audit log set to relevant only vs on etc. didn't make a difference either.
The text was updated successfully, but these errors were encountered: