Thanks for responding!
> > 1) I played around with scripting a way to loop through all the agents > and > > zeroing out each and every one of the files (with "syscheck_control -i > $ID > > -f $FILE -z")- so at least I'd be notified of any future changes - but > it's > > not a great solution. I can't seem to hit each of the files properly, > even > > when using quotes - "-f '/sbin/iw'" matches iwspy, iwlist, iwevent, > iwpriv, > > etc., when I use "-z" it just zeroes out the first one it hits. > Any ideas on this one? Is there any way to get "syscheck_control -f" to do an exact match? > 2) I'm not totally clear on what the "-z" flag is doing, anyhow. I think it > just resets the "auto_ignore" flag so that it will keep telling me about > changes (although I can't find any hard evidence that files are being > ignored, other than the fact that I can see that some recent changes have > not been recorded - "auto_ignore" doesn't seem to exist in my ossec.conf). > > Auto ignore is enabled by default. If it's not set to no, it's active. OK, thanks - that was my suspicion, but the docs online weren't clear: http://www.ossec.net/main/manual/manual-syscheck indicates "yes" is the default, but http://www.ossec.net/doc/syntax/head_ossec_config.syscheck.html says "no" is the default. FYI - a lot of the www.ossec.net webpage links seem to be broken (or they all go to the top-level /doc page), and the wiki seems to be gone. I was only able to find the oft-referenced page regarding prelinking issues from Google's cache. > > 3) What I would REALLY like it to do is "forget" about all changes since > the > > first scan, and then (after I undo prelinking) have the next syscheck > > compare against that baseline. Is hacking up the files in > > /var/ossec/queue/syscheck/ the only way to fix this? Or am I just SOL? > > > > If you have a copy of the original you might be able to do this. Stop > the processes on the manager, move the original into place, and start > the processes back up. Not sure if it would work... Can you explain what you mean by "copy of the original"? Do you mean like a point-in-time backup/copy of the syscheck database file for each client, right after the first scan? If so... that might be challenging, given that we have over 100 servers built at different times. I have been able to (apparently successfully) combine 2 syscheck database files for a client after a new one was created after an IP address change (which I had also manually corrected in the client.keys file). Not sure if this is supported, but it seemed to work. > > 4) On a related note, is there any way in OSSEC to "check in" or > > "acknowledge" a change? I don't want to ignore the file forever - just > have > > some way of tagging that "yes, we approved that change so it's OK". > > > > Nope. That's not OSSEC's job. That seems like something the ticketing > system or whatever should handle. OSSEC doesn't care if that change is > legit or not, it just tells you a change was made. I can definitely understand that point of view. My previous experience was more with old-school tripwire or aide, where everything is compared to the "original" state (which you may choose to re-initialize after approved changes), as opposed to the most recent state. Knowing that change happened, regardless of the circumstance, is good. But, it would be a really useful management feature to be able to hide certain changes from view when running reports from the tool itself (i.e. using syscheck_control) - I envision a workflow something like this: 1) Operator/automated process runs syscheck_control and detects 15 changes 2) Operator reviews changes against change management 3) 13 out of 15 changes were expected, so operator "accepts" them by running syscheck_control with a certain flag to "hide" (maybe even with a comment) 4) Operator re-runs syscheck_control (possibly with a certain flag) to show all changes not hidden, investigates cause of the 2 remaining changes, hides them later if a legitimate cause is determined. 5) (2 weeks later) Auditor requests a report of all changes that occured in the last month, so Operator runs syscheck_control with a "show hidden" flag (or leave this as the default behavior, for backward compatibility) to show all 15 changes. Just a thought. Thanks, Christina
