How to monitor file access on Linux with auditd

If you are running a mission critical web server, or maintaining a storage server loaded with sensitive data, you probably want to closely monitor file access activities within the server. For example, you want to track any unauthorized change in system configuration files such as /etc/passwd.

To monitor who changed or accessed files or directories on Linux, you can use the Linux Audit System which provides system call auditing and monitoring. In the Linux Audit System, a daemon called auditd is responsible for monitoring individual system calls, and logging them for inspection.

In this tutorial, I will describe how to monitor file access on Linux by using auditd.

To install auditd on Debian, Ubuntu or Linux Mint:

$ sudo apt-get install auditd

Once installed by apt-get, auditd will be set to start automatically upon boot.

To install auditd on Fedora, CentOS or RHEL:

$ sudo yum install audit

If you want to start auditd automatically upon boot on Fedora, CentOS or RHEL, you need to run the following.

$ sudo chkconfig auditd on

Once you installed auditd, you can configure it by two methods. One is to use a command-line utility called auditctl. The other method is to edit the audit configuration file located at /etc/audit/audit.rules. In this tutorial, I will use the audit configuration file.

The following is an example auditd configuration file.

$ sudo vi /etc/audit/audit.rules
# First rule - delete all
-D

# increase the buffers to survive stress events. make this bigger for busy systems.
-b 1024

# monitor unlink() and rmdir() system calls.
-a exit,always -S unlink -S rmdir

# monitor open() system call by Linux UID 1001.
-a exit,always -S open -F loginuid=1001

# monitor write-access and change in file properties (read/write/execute) of the following files.
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa

# monitor read-access of the following directory.
-w /etc/secret_directory -p r

# lock the audit configuration to prevent any modification of this file.
-e 2

Once you finish editing the audit configuration, restart auditd.

$ sudo service auditd restart

Once auditd starts running, it will start generating an audit daemon log in /var/log/audit/audit.log as auditing is in progress.

A command-line tool called ausearch allows you to query audit daemon logs for specific violations.

To check if a specific file (e.g., /etc/passwd) has been accessed by anyone, run the following. As shown in the above example audit configuration, auditd checks if /etc/passwd is modified or tampered with using chmod.

$ sudo ausearch -f /etc/passwd
time->Sun May 12 19:22:31 2013
type=PATH msg=audit(1368411751.734:94): item=0 name="/etc/passwd" inode=655761 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1368411751.734:94):  cwd="/home/xmodulo"
type=SYSCALL msg=audit(1368411751.734:94): arch=40000003 syscall=306 success=yes exit=0 a0=ffffff9c a1=8624900 a2=1a6 a3=8000 items=1 ppid=14971 pid=14972 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=19 comm="chmod" exe="/bin/chmod" key=(null)

The ausearch output above shows that chmod has been applied to /etc/passwd by the root once.

To check if a specific directory (e.g., /etc/secret_directory) has been accessed by anyone, run the following.

$ sudo ausearch -f /etc/secret_directory
time->Sun May 12 19:59:58 2013
type=PATH msg=audit(1368413998.927:108): item=0 name="/etc/secret_directory/" inode=686341 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1368413998.927:108):  cwd="/home/xmodulo"
type=SYSCALL msg=audit(1368413998.927:108): arch=40000003 syscall=230 success=no exit=-61 a0=bfcdc4e4 a1=b76f0fa9 a2=8c65c70 a3=ff items=1 ppid=2792 pid=11300 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=pts1 ses=2 comm="ls" exe="/bin/ls" key=(null)

The output shows that /etc/secret_directory was looked into by Linux UID 1001.

In our example audit configuration, auditd was placed in immutable mode, which means that if you attempt to modify /etc/audit/audit.rules, and restart auditd, you will get the following error.

$ sudo /etc/init.d/auditd restart
Error deleting rule (Operation not permitted)
The audit system is in immutable mode, no rules loaded

If you want to be able to modify the audit rules again after auditd is put in immutable mode, you need to reboot your machine after changing the rules in /etc/audit/audit.rules.

If you want to enable daily log rotation for the audit log generated in /var/log/audit directory, use the following command in a daily cronjob.

$ sudo service auditd rotate

Subscribe to Xmodulo

Do you want to receive Linux FAQs, detailed tutorials and tips published at Xmodulo? Enter your email address below, and we will deliver our Linux posts straight to your email box, for free. Delivery powered by Google Feedburner.

The following two tabs change content below.
Dan Nanni is the founder and also a regular contributor of Xmodulo.com. He is a Linux/FOSS enthusiast who loves to get his hands dirty with his Linux box. He likes to procrastinate when he is supposed to be busy and productive. When he is otherwise free, he likes to watch movies and shop for the coolest gadgets.
Your name can also be listed here. Write for us as a freelancer.

5 thoughts on “How to monitor file access on Linux with auditd

  1. To rotate logs on Fedora with systemctl:
    systemctl kill --signal=SIGUSR1 auditd

    Also check out the example audit rules that come with your package
    /usr/share/doc/audit-2.3.2/capp.rules
    /usr/share/doc/audit-2.3.2/lspp.rules
    /usr/share/doc/audit-2.3.2/nispom.rules
    /usr/share/doc/audit-2.3.2/stig.rules

    And finally, check out all the nice utilities that come with this suite

  2. Nice, but I prefer the file integrity monitor in OSSEC. Plus I get the complete HIDS (host intrusion detection system) along with it. :-)

    • Thanks for posting this alternative. I have used auditd in the past and found the logs it generates to be nearly impossible to translate into something useful. Correlation is something I currently handle via 3rd party software, but looking at OSSEC it might be even better than what I'm paying for!

Leave a comment

Your email address will not be published. Required fields are marked *

Current ye@r *