Hello Mike, Sorry for digging this up, but a search on google lead me to this discussion. Is there any news on this plugin idea? My 2 cent: there is a md5 whitelist database by Xavier Mertens. So it should be possible to use a local repository cache, compute the md5 sums of all the files in every package, and send them to the whitelist database. This method should work with most distros. Not tested yet, just an idea. Best regards, Joël
On Saturday, November 15, 2008 at 12:10:31 AM UTC+1 Mike Freemon wrote: > I am interested in this topic as well. In my case, I have a number of > servers that I have yum automatically installing the latest updates. Of > course, this triggers a flood of false positives. One idea I was thinking > about was to develop a yum plugin that would calculate new checksums as yum > executes and forward those new checksums to ossec without triggering an > alert. I will quickly confess that I have not yet looked at either the > design or the code of either yum or ossec to assess whether or not this is > a feasible idea or not. I look forward to this discussion. > > - Mike > > > ----- Original Message ----- > From: "Eric Hankins" <[email protected]> > To: [email protected] > Sent: Friday, November 14, 2008 2:20:33 PM GMT -06:00 US/Canada Central > Subject: [ossec-list] ossec and system updates: forcing immediate syscheck > > > All, > > Wanted to ping the group for thoughts/opinions on interactions between > file integrity checks and administrative operating system updates. > > For example, in the case of a large-scale ossec implementation where > multiple groups are tasked with updating various pieces of the system, > i.e. one group is responsible for the OS installs themselves, and > another group handles the apps/services running on them, and they > might not always know what each other are up to. The result is a > stream of alerts that are effectively false positives, because the > file checksum changes are due to purposeful maintenance taking place. > > The task to overcome this is to make ossec a functional component of > the update process, by making it play nice with scheduled system > maintenance. There are two components to this: > > 1) Be able to force an immediate syscheck to 're-baseline' the file > integrity checksum database immediately following whatever > admin-triggered action resulted in changes to things on the > filesystem. Ideally this 're-baseline' mode would ignore syscheck file > scanning throttles like syscheck.sleep and syscheck.sleep_after > because an administratively-triggered syscheck operation during a > scheduled maintenance window should probably run as fast as possible. > > 2) Be able to squelch the alerts that result from the 're-baseline' > syscheck, as everything found by this operation will likely be > purposeful and not worthy of an alert. > > So, with these objectives in mind, some questions spring to mind: > > Is there currently a way to force a syscheck? Will a simple agent > restart result in it beginning one? A potentially useful feature here > would be to send the agent a signal, say, SIGUSR1 to trigger this > special syscheck, ignoring any throttling options in the process. > > As for alerting, it gets a little complicated. The obvious, > oversimplified method would be for the agent to simply not alert when > it executes the special 're-baseline' syscheck. But this is (equally > obviously) a horrible idea, as any intruder with a clue will simply > send SIGUSR1 or whatever should trigger the immediate syscheck and > happily have his rootkit rolled into the file integrity checksum list > without being noticed. > > So, the alert squelching clearly needs to happen at the ossec server. > Extending the concept of maintenance windows, time slices in which > alerts may safely be ignored and not emailed out, to the server could > be one way to accomplish this. Preferably, this would be implemented > such that maintenance windows could be updated dynamically without > restarting the ossec server. One could do this in a custom fashion > today by writing alerts to a database, and layer some custom scripts > atop it that simply purge alerts for a host during a time period as > dictated by the maintenance window. > > Anyway, just curious what the community thinks about this. Happy to > submit feature requests based on what we come up with. > > best, > -e > -- --- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/30a483a8-50c1-4dec-a708-b5904e58f859n%40googlegroups.com.
