I suppose it might be silly of me to recommend you disable OSSEC prior to the puppet apply, and enable it following successful application.
If this sets your devops into a tailspin, perhaps you can identify the most frequently offending alerts and reload OSSEC using a pared-down configuration which omits the noisiest ones while still monitoring for serious indications of threatening behavior. Then, likewise, revert to the full OSSEC configurations post-application. We're implementing puppet soon, so this will be a much more visceral problem for me in a few months, at which point I might have less sophomoric insight. On Tuesday, June 21, 2016 at 9:09:46 AM UTC-4, Tahir Hafiz wrote: > > Thing is how does one write a rule that covers all the events due to a > Puppet apply. > > A Puppet run instigates so many changes across an environment and various > system files, how can you write a rule that covers so much? > Is there a way to ignore a series of events by time alone and have that > ignore automated? > > > > On Friday, 17 June 2016 20:22:29 UTC+1, JDS wrote: >> >> The impression I get is that the answer is "tune your system to ignore or >> supress alerts from known OK system events" >> >> So, a rule that suppresses the Puppet apply events. >> >> I'm not saying it's gonna be easy, but that's the approach I'm starting >> to take atm. >> >> I've had this same basic question about Snort and OSSIM (a project that >> incorporates OSSEC) and that's the gist of the responses I've gotten. >> >> -JDS >> >> On Wednesday, June 15, 2016 at 6:19:19 AM UTC-4, Tahir Hafiz wrote: >>> >>> We are tuning our OSSEC server/agent environment. >>> We have multiple environments and use Puppet for configuration >>> management and AWS for our cloud based systems. >>> >>> We baseline (run OSSEC) at the start of an environment build, and then >>> do a Puppet apply. >>> We seem to have thousands of alerts coming in (many to do with syscheck >>> on subsequent Puppet applys). >>> >>> How do you guys deal with so many alerts - do you try and whitelist all >>> of them in the local_rules.xml file or just let them all go in to the >>> alerts file? >>> How do you know if an intruder has compromised a system if you >>> constantly have login sessions opened and closed by system users and have >>> level 7 syscheck alerts by Puppet applys happening as part of the normal >>> running of your environment? >>> How do you have warning systems based on alerts set-up (e.g. a script >>> that triggers to Nagios ? or something else?). >>> >>> Cheers >>> >>> -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
