How to Monitor System Usage With Auditd

One of the key system monitoring tasks of server management is monitoring the changes made to the system. There are a number of ways to monitor the use of your system, and one popular method is to use auditd. Auditd runs as a system process in kernel space which means that it is difficult for nefarious users or software to circumvent. It also comes with a comprehensive reporting tool, enabling you to gain access to the information that auditd builds up.

How To Install Auditd

Installation is relatively simple as auditd is included in most Linux repositories. For Debian and Ubuntu systems you can install it with the following command:

sudo apt-get install auditd

For Red Hat and CentOS systems, installation can be performed with:

sudo yum install audit

On modern systems that run systemd, which pretty much covers all recently released Red Hat/CentOS based distributions and Debian based distributions from the last few years, auditd can be started using the following command:

sudo systemctl start auditd.service

Once it is up and running, auditd will use a default configuration that monitors your system configuration for changes, user and group changes, commands run and executables launched, among a host of other statistics. General configuration for auditd is contained within the /etc/audit directory with core configuration in the auditd.conf file. Unless you require some specialist custom monitoring, you shouldn’t need to change anything here for now.

Rules can be temporarily added or removed using the auditctl command so that they can be tested without stopping or starting the auditd service. The rules will then need to be added to the /etc/audit/rules.d/audit.rules file when you are satisfied with your testing to ensure that they are restored to auditd’s ruleset when the system restarts.There are many options for creating custom rules, certainly too many to cover in this post.

Aureport: A Comprehensive Report Of Monitoring

Instead, in this article we’ll be looking at aureport. The aureport command provides reporting into the various things that auditd monitors on your system. Due to the secure nature of what auditd is using, even the aureport tool requires superuser access, so you’ll need to be root or use sudo to check the audit reports:

sudo aureport

This command provides an overall listing of the changes that auditd has detected on your system with headings followed by the number of changes. Each of the sections is capable of providing more detail into the changes; this is done using one of the many available flags. The first flag to note is — help which gives you a listing of the options, shown below:

sudo aureport --help

Let’s look at a handful of the useful ones:

-au This shows details of the authentication attempts that auditd has logged. This includes remote and local connections, as well as whether the attempt succeeded or failed.

-l This shows details of system logins, and thus tends to look a lot like the above.

-u Similarly related in that is shows user related events.

— comm Reports about commands run.

-c This provides a report about config changes.

-f Provides a report about file changes.

-m Reports about account modifications.

As you can imagine, a number of these reports can get very very long, so piping the output through grep can be very helpful in order to gain some clarity. For example:

sudo aureport -au | grep no

This command will show lines from the authentication report where the authentication failed. A large quantity of these are a good indication of a server that is under a brute force login attack. The seventh column here is very helpful, and gives an indication of how these authentication attempts are being made, /usr/bin/login shows a local login to the server, /usr/sbin/sshd shows a login attempt via SSH and /usr/bin/su shows a logged in user using the su command to change to another user. The fourth column shows the user account attempting to be authenticated.

With a small amount of scripting work, it can be possible to transform from reports being awkward and long to being a tool that can actively alert you to potential problems with your server, making it a very handy monitoring tool indeed.

Never miss another post. Sign up for the weekly 100TB newsletter and follow us on Facebook and Twitter.


Originally published at blog.100tb.com.

Like what you read? Give 100TB.com a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.