I've worked with Leigh before, he's a great guy. He implemented some fixes for me with the Irix versions of Snare and posted my sat2text script on sourceforge (http://www.intersectalliance.com/projects/SnareIrix/Download/sat2text-1 .1-beta.pl).
I haven't looked at the Snare Micro Server in a while. The last time I looked at some snapshots of its output, it was collecting logs from multiple UNIX platforms, but the messages themselves still had pieces (strings) in the more native/difficult to read format, so I never really pursued demoing the package. Lots may have changed in recent revisions, and it might be worth another look. Of the GUIs I've seen, many have similar problems, but most of the issues I have are not in the GUI developer's handling of the audit data, but in the audit data itself: the number and type of fields in each record varies greatly depending on the type of record, and this makes it very difficult to process the data in a human-understandable way. Some of the problems I've seen with older GUIs are illustrated by looking at the old snare GUI from Red Hat 9: 1. The snare guys handled the varying record field problem by showing the common fields in the top level of the GUI. If you wanted to get the event-specific details from the record though, you had to open every single one individually which is time consuming. I don't think there were any high level AI interfaces for determining if joe-user tried to break into the machine or was messing around with system confif files, I think you had to open each record and look at its specific data fields to determine that type of thing, and isn't very practical if you have a lot of audit data or a lot of systems to review. (Again, the snare microserver may have more analysis capabilities now) 2. You could only look at data from one system at a time (I know that the Snare microserver can help with this issue). 3. The old SNARE Gui would also only show you the audit file that was currently being written. If you wanted to go back and look at old audit data that you had archived, you couldn't open it with the GUI, you had to look at the audit data in its native format which is very difficult to interpret. (Leigh told me a while back that he would take a look at writing something for the next release that would allow you to open older audit files with the GUI, but I haven't checked in a while to see if that's available). I should really take a look at the Snare micro server and see what current versions can do for me. I imagine lots of cool features have been added since my last look. So, what would I want in a tool or GUI? -------------------------------------- I'm not sure I could come up with a great way to display/analyze this data, but as a user and as someone who is required to determine if someone is doing something nasty on my systems, I do know that the tools need to be easy to use. Sometimes we configure machines for a facility, but then a not-necessarily savvy facility administrator may be the one doing the weekly audit log reviews. Most wouldn't take the time to learn how to manipulate the data with aureport (or comparable tools) to really understand what's happening on their machines, so the more user-friendly the tool, the better. It's also a big help to review data from multiple systems at a time (and there don't necessarily need to be agents out there doing a central collection, I may simply have set up the log rotation to stash the rotated logs in a central place with names like audit.daterange.system1, audit.daterange.system2, etc.). The Bottom line? The basic minimum is that I'd to be able to display audit records in some sort of language-like format. It might be nice to sort/group data so we can look at big chunks of similar events at a time (makes the review process go faster). Another nice to have would be the ability to do this for multiple systems at once, and even better would be to have some analysis/filtering capability to reduce some of the noise on harmless audit records, allow us to take a closer look at the more interesting stuff, and to ultimately help determine whether someone is doing something bad on the machine. Thanks a million for listening, you have been very patient and helpful. I greatly appreciate it. Karen Wieprecht -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
