This is a really complicated feature to implement, but I wonder if it might be useful.
I needed to report a false positive today. To my surprise the GUI prevented it saying my rules weren't up to date. OK, fair enough. I *was* one step behind on my rules updates.
But here's where it went wrong:
I updated using asl -u then went back to the same event I had tried to report previously, and of course I was allowed to report the FP, even though the event had happened when I previous ruleset has been used.
What I'd like is a feature in the GUI that lets me test a previously logged event against the current ruleset.
By this I mean a button in the GUI that's visible when I've clicked on an event shown in event log in the GUI that allows me to see if that event would or would not trigger a mod_sec/ossec reaction with the ruleset currently loaded.
In this way, when I've reported an FP for an event in the past, I can test that exact same event against the new ruleset to know if that ruleset has fixed my FP or not.
But more importantly, having been gently rebuked by the GUI for attempting to report an FP when my rules were not up to date, I could update the rules and then use the same feature to test the event against the new rules - if I still get an indication that mod_sec or ossec would take action as a result of the event, I know it is sensible to report it as an FP. If not, then I know I'd be wasting everybody's time by reporting it as an FP.
This would only work for events where enough data is captured, e.g. an html post/get, of course. I can also see serious danger potential. For example, we don't want any possibility at all of a remote file inclusion or similar horrible thing accidentally working when doing a GUI-based event test like this.
[DARN IT. Sorry. Posted in the wrong section. I'm sure Mike/Scott will move this thread to the right place for me though
]
Login
Register
FAQ
Search
