Linux Audit Framework 101 – Basic Rules for Configuration
Starting with Linux auditing can be overwhelming. Fortunately, there is a great feature in the Linux kernel to watch events and log them for us. To give you a quick start to use the Linux Audit Framework, we have collected some basic rules for configuring the audit daemon and its rules.
Main Configuration
By default the configuration values in /etc/audit/audit.conf are suitable for most systems. If you know your system is very low or very high (e.g. mainframe) on resources, then you might want to adjust some file sizes or buffers.
Auditing does not equal security
The auditing framework simply monitors and logs events to an auditing log. Keep in mind running an auditing daemon does not increase security in itself. It does however create an audit trail, helping with detection (e.g. security intrusion).
Rules
The Audit daemon uses rules to monitor for specific items and create a related event log. Each rule can be provided to the daemon by using the configuration file /etc/audit/audit.rules or with the command line utility auditctl. When using the configuration file, keep in mind that just adding new rules is not enough to activate them. Reread of the configuration file is needed.
The rules file can be read with -R. It should be owned by the root user, or a “Error - /tmp/test isn’t owned by root” will show up.
The three types
The auditing framework and daemon in particular, knows 3 types of rules:
- Basic auditing settings
- File and directory watches
- Syscall monitoring
First match wins
When a rule matches, the audit daemon stops evaluating if other rules need to be checked as well. So make sure to put things in the right order of processing, or some rules will never match.
Getting the right details
When using a watch on a directory, less information will be logged in comparison with specific file watches. So when in need of all details, monitor files instead.
File needs to exist
When using templates or adding new file watches, keep in mind that the files or directories to monitor, need to exist on disk.
System architecture
Some rules might not work between systems, if their architecture is different. Where possible, specify the architecture to ensure you are monitoring the right system call.
Use keys
To simplify searching and categorizing events, use keys. Multiple keys can be used on a rule, which help in grouping events while still having a separation in place as well.
The ausearch utility can be told to search by key with the -k parameter, followed by the actual key. This way searching for specific events becomes much easier.
Keys also help in grouping the events. This way you can use it for both auditing purposes and use some specific key combinations for goals like intrusion detection. It minimizes the amount of events, which you might want to put into a SIEM (Security Incident and Event Management) solution.
Prepare before auditing
Carefully select which files or events you want to monitor. With more auditing, the load will increase. Additionally, the audit log will increase as well. Too much logging and you will be overwhelmed. The “log everything” approach is definitely not the right mindset when using Linux auditing capabilities.
Check the examples
The audit package contains some great example files. Have a look at your system at the files: capp.rules, lspp.rules, nispom.rules, and stig.rules.
Conclusion
With these rules, you should be able to get the Linux audit framework up and running. The audit framework is powerful for debugging and troubleshooting issues on your system. Additionally, it is of great help in detecting unauthorized events or system intrusion. If you like this subject, we encourage you to check out the other blog posts we have on this subject.
