A Deep Dive into File Access Monitoring
One of the powerful tools at the disposal of system administrators is auditd, a robust utility that provides comprehensive file access monitoring and auditing capabilities. With auditd, the capability to monitor file access becomes not only a possibility but a necessity for every vigilant system administrator.
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.
Installing 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.
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.
$ nano /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.
$ 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.
$ 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/cyberpunk" 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/cyberpunk" 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 this example audit configuration 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
- Lordfrancis3 is a member of PinoyLinux since its establishment in 2011. With a wealth of experience spanning numerous years, he possesses a profound understanding of managing and deploying intricate infrastructure. His contributions have undoubtedly played a pivotal role in shaping the community's growth and success. His expertise and dedication reflect in every aspect of the journey, as PinoyLinux continues to champion the ideals of Linux and open-source technology. LordFrancis3's extensive experience remains an invaluable asset, and his commitment inspires fellow members to reach new heights. His enduring dedication to PinoyLinux's evolution is truly commendable.
- Software and TechnologySeptember 18, 2023Nginx Reverse Proxy with Redis for Rate Limiting and Queues for Performance Optimization
- System AdminstrationAugust 27, 2023Automating Yourself Out of Your Job
- Privacy and SecurityAugust 22, 2023Security Alert: Privilege Escalation Vulnerability Impacts Over 10,000 Charitable WordPress Sites
- ServersAugust 14, 2023Why Red Hat Abandoned CentOS 7 and the Best Alternatives