Setup auditing of sensitive files and folders to aid Linux endpoint investigations or simply keep tabs on users ( * or unexpected guests >:] *)
Intro
Have sensitive files and folders on a Linux file server? YES OF COURSE!
Do you wish you could keep an audit trail of any access to a specific file or folder? DEFINITELY!
In Part 1 of Got Auditd? we will configure auditd to monitor activities performed on your sensitive files and folders!
What is Auditd?
From the manpage (man auditd):
auditd is the userspace component to the Linux Auditing System. It's responsible for writing audit records to the disk. Viewing the logs is done with the ausearch or aureport utilities. Configuring the audit system or loading rules is done with the auditctl utility. During startup, the rules in /etc/audit/audit.rules are read by auditctl and loaded into the kernel. Alternately, there is also an augenrules program that reads rules located in /etc/audit/rules.d/ and compiles them into an audit.rules file. The audit daemon itself has some configuration options that the admin may wish to customize. They are found in the auditd.conf file.
Configuration
Now let's go over a sample configuration to log any read write delete activity in a specific folder. We will be creating a file inside the /etc/audit/rules.d/ directory. We must not use the default /etc/audit/audit.rules as this file may be overwritten during an upgrade.
# /etc/audit/rules.d/data.rules## Enable ruleset-e1## Limit the rate to 120 audit entries per second-r120## Monitor /opt/_data for rwxa events-w/opt/_data-prwxa-ktoplevel_data
Below is an explanation of each parameter:
Parameter
Description
-e #
1 - enables ruleset
2 - makes config immutable. Reboot is required to change configuration settings or rulesets.
-r #
limits the rate to # of audit entries per second
-w </path/to/file>
directory or file to monitor
-p <permissions>
Permissions:
r - read of the file
w - write to the file
x - execute the file
a - change in the file's attribute
-k <keyname>
Keyname to use for the rule.
Testing
With the configuration now set, let's test it by creating a file, deleting it and listing the directory (click the image for better view):
The left pane is user activity inside /opt/_data while the right pane "tails" the /var/log/audit/audit.log file.
Logs and reporting
Now that we have our configuration tested, let's use auditd's own tools for searching and reporting instead of grepping or tailing the log for activity!
To search the audit log, use auditd's built-in tool ausearch:
Seems like a lot of information right? We can use the aureport tool to interpret this log output!
Both ausearch and aureport are able to take in raw audit logs from STDIN, below are examples for this.
Notes
Key Points to Keep in Mind About Auditd
Powerful File Activity Tracking:
Auditd excels at monitoring activity on sensitive files. It provides visibility into who is performing the activity, when the activity is happening, and what files are being accessed, modified, written, or, in the worst case, deleted.
Audit Logs for Investigation and Detection:
Audit logs and reports help track user activity and detect suspicious behavior. For example, if a sensitive file is deleted, audit logs can identify the responsible user, which is invaluable for investigations. Consider ingesting these logs into a SIEM for enhanced detection and alerting capabilities.
Configuration Testing Is Crucial:
Always test your Auditd configurations before deploying them across your network. A misconfigured setup could create gaps in your monitoring timeline, leaving your system vulnerable.
# To get a summary of the output, use the aureport tool with only the --interpreter flag
$ sudo ausearch --file _data | sudo aureport --interpret
Summary Report
======================
Range of time in logs: 01/13/2025 23:06:37.283 - 01/13/2025 23:07:02.919
Selected time for report: 01/13/2025 23:06:37 - 01/13/2025 23:07:02.919
Number of changes in configuration: 0
Number of changes to accounts, groups, or roles: 0
Number of logins: 0
Number of failed logins: 0
Number of authentications: 0
Number of failed authentications: 0
Number of users: 1
Number of terminals: 1
Number of host names: 0
Number of executables: 5
Number of commands: 5
Number of files: 4
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 0
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of integrity events: 0
Number of virt events: 0
Number of keys: 1
Number of process IDs: 5
Number of events: 5
# To get specific details of executables you can use the -x or --executable for executables
$ sudo ausearch --file _data | sudo aureport -x --interpret
Executable Report
====================================
# date time exe term host auid event
====================================
1. 01/13/2025 23:06:37 /usr/bin/ls pts1 ? tlm 288
2. 01/13/2025 23:06:41 /usr/bin/touch pts1 ? tlm 289
3. 01/13/2025 23:06:51 /usr/bin/bash pts1 ? tlm 290
4. 01/13/2025 23:06:59 /usr/bin/mv pts1 ? tlm 291
5. 01/13/2025 23:07:02 /usr/bin/rm pts1 ? tlm 292
# To get specific details of files you can use the -f or --files for files
$ sudo ausearch --file _data | sudo aureport --file --interpret
File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. 01/13/2025 23:06:37 . openat yes /usr/bin/ls tlm 288
2. 01/13/2025 23:06:41 hello openat yes /usr/bin/touch tlm 289
3. 01/13/2025 23:06:51 hello openat yes /usr/bin/bash tlm 290
4. 01/13/2025 23:06:59 hell renameat2 yes /usr/bin/mv tlm 291
5. 01/13/2025 23:07:02 hell unlinkat yes /usr/bin/rm tlm 292
