Auditing Linux: what to audit?
In this article we answer the big question on Linux systems “what to audit?”. Where do you start and what is useful to audit? We apply our three C’s in this article to determine what we should look for when auditing a Linux system.
Current state
What is the current state of the system and how does it compare to previous time?
Ideal situation: compare current state of the system with a predefined baseline or previous scan
Running an audit on a Linux system might reveal flaws in its configuration. While this is useful information to know, it’s even more valuable to know since when this flaw is present (past) and how to act upon it (future). Therefore companies should have a security policy defining appropriate measures and actions. In addition it should be accompanied by the right (technical) procedures, to define how systems should be configured.
Baselines
To audit a Linux system one might start by auditing configuration files first. Most of these can be found under the /etc directory and its sub-directories. Finding changes is easy by comparing the full directory and determine what lines are changed in each file. Saving a baseline might give especially useful insights when changes are found, but can not be explained (e.g. loading a new kernel module).
Another important item is to save earlier performed audits, to check the state of systems in the past and what measures are taken on a particular system. Especially when dealing with exceptions to the security policy, the documentation should be carefully updated. It should also include the appropriate permission and bookkeeping why this exception is tolerated and for how long.
Automation
For Linux and Unix based systems we created our open source (GPLv3) tool Lynis. It can be configured to perform tests from some categories, or all of them. To allow exceptions, particular tests can be excluded. The tools allows to create a report file, making it easier to determine the state of the system and comparing it with other scans.
Changes to the system
What changes occurred to the system?
Ideal situation: no changes, or only authorized and well-documented changes
Tracking changes over time is a challenging exercise on most systems. That’s why continuous audits are needed to discover (unauthorized) changes quickly. Usually it’s easier to act upon a recent change, compared to change in a configuration file from two years ago.
Changes should be monitored and also properly documented. For Linux systems this could be done in the configuration file itself, or in the central repository of a configuration management solution. Another common method for companies using ITIL is in the change management tooling.
On Linux changes to critical configuration files could be easily detected by implementing the Linux audit framework. We have already written some articles about this subject in the past and are worth reading as well. The framework is powerful and can detect authorized changes, but also security intrusions.
Control access
What access do users have and to what?
Ideal situation: clear matrix on which users can access the system and what access they have
Similar to having baselines on a system configuration, it is very useful to have an access matrix. This list of people and their type of access to the system, can be used for easily auditing permissions at a later stage. Unfortunately it’s not common yet that this information is properly documented (and updated!).
Regular audit of the passwd file and changes to it, will provide insights to whom can access the system. To discover what data can be actually accesses, a file system scan should be performed.
