URL:
Reporter RHNID:
Section: -
Language: en-US (English)
Workaround:

Description: Some quick tips on how to analyze the audit log when investigating AIDE results (ch07s03).  We may want to integrate some of these into the general discussion in the SG at a later date.

Try setting everything up on a test system, and then deliberately trigger an expected "unexpected" file change.  You should see the change reflected in the AIDE check report (you could even run that manually outside the usual schedule to make sure of that).  More usefully, this should log audit events.

Since you know when the audit events happened and what command was used to cause them, you should be able to rapidly find the event or events by timestamp.  Then you can use that to figure out what the typical pattern of that sort of change is.  For example, you'll see that a mv command will use rename(2) to move the file.  Likewise, vi or vipw will trigger multiple events as it creates scratch files and moves them into place over the original file.  So, this will also reveal things about application and command behavior.  But since you already know something about what "really" happened, you can compare that to the audit events to see what that looks like in reality.

It can be really helpful to have (or develop) a basic understanding of the theory of Linux/Unix system programming to interpret the audit logs.  You don't have to have enough skill here to be an actual programmer.  But if you understand the basics of how files and inodes work, how a program uses directories to look up a file's inode to access it, and the typical system call patterns used for file I/O, this can help a lot.  Section 2 man pages can be useful to provide supplementary information for figuring out flags and so on in SYSCALL records. 

The audit system is actually a really useful tool for someone trying to learn more about how userspace talks to the kernel, but that's a whole different story....