Audit logs in Linux track every system event, from user logins to file access, making them vital for security analysis. Understanding how to read audit logs in linux is essential for any system administrator or security professional who needs to monitor activity and detect anomalies. These logs provide a detailed record of what happened, when it happened, and who was responsible, giving you a clear picture of your system’s behavior.
When you first open an audit log, it can look like a jumble of numbers and codes. But once you learn the structure, each log entry tells a complete story. The key is knowing which tools to use and how to interpret the fields. This guide will walk you through everything from basic commands to advanced filtering techniques.
Let’s start with the basics. Audit logs are typically stored in /var/log/audit/audit.log. You can view them with standard Linux commands like cat or less, but specialized tools make the job much easier. The main utility you’ll use is ausearch, which searches through audit records based on specific criteria.
What Are Audit Logs In Linux
Audit logs are generated by the Linux Audit Daemon (auditd). This daemon captures system calls and events based on rules you define. Every time a user logs in, a file is accessed, or a system configuration changes, an audit record is created. These records are stored in a binary format for efficiency but can be viewed as plain text.
The audit system is separate from other logging systems like syslog. While syslog records general system messages, audit logs focus on security-relevant events. This makes them invaluable for compliance requirements like PCI DSS or HIPAA, where you need to prove who accessed what and when.
Each audit record contains several key fields:
- type: The event category (e.g., USER_LOGIN, SYSCALL)
- msg: Timestamp and event ID
- arch: System architecture
- syscall: The system call number
- success: Whether the call succeeded or failed
- auid: The audit user ID (original login user)
- uid: The effective user ID
- pid: Process ID
- comm: Command name
- exe: Full path to the executable
How To Read Audit Logs In Linux
Now we get to the core of this guide. The command ausearch is your primary tool for querying audit logs. It allows you to filter by time, user, event type, and many other parameters. Let’s look at some practical examples.
To see all recent audit events, simply run:
sudo ausearch -ts recent
This shows events from the last few minutes. For a specific time range, use -ts (start time) and -te (end time):
sudo ausearch -ts 09:00:00 -te 17:00:00
You can also use date formats like MM/DD/YYYY HH:MM:SS. If you want to see events for a specific user, add the -ua flag:
sudo ausearch -ua johndoe
This shows all events where the user “johndoe” was involved. For events related to a specific file, use -f:
sudo ausearch -f /etc/shadow
This is extremly useful for monitoring sensitive files. You can also search by process ID:
sudo ausearch -p 1234
When you run these commands, the output can be verbose. Each event may span multiple lines. To make it more readable, use aureport which summarizes the data:
sudo aureport --summary
This gives you a high-level overview of event types and counts. For a detailed breakdown by user:
sudo aureport --user
Understanding Audit Event Types
Audit logs contain different event types, each with a specific meaning. The most common ones include:
- USER_LOGIN: User login events
- USER_END: User logout events
- SYSCALL: System call events
- PATH: File access events
- EXECVE: Program execution events
- CONFIG_CHANGE: Audit configuration changes
Each type has its own set of fields. For example, a SYSCALL record includes the system call number and arguments, while a PATH record shows the file path and access mode. When you search for specific events, knowing the type helps you narrow down results.
To see only login events, use:
sudo ausearch -m USER_LOGIN
For failed login attempts, add --success no:
sudo ausearch -m USER_LOGIN --success no
This is a great way to detect brute force attacks. Similarly, you can monitor file access by combining the -f flag with event types.
Reading Audit Log Entries Manually
Sometimes you need to read the raw log file directly. Open /var/log/audit/audit.log with less or tail:
sudo tail -f /var/log/audit/audit.log
This shows new events in real time. Each entry starts with a timestamp and event ID. Here’s an example of a typical record:
type=USER_LOGIN msg=audit(1633024800.123:456): pid=789 uid=0 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=success'
Let’s break this down:
- type=USER_LOGIN: This is a login event
- msg=audit(1633024800.123:456): Timestamp and event ID
- pid=789: Process ID of the SSH daemon
- uid=0: Root user (the SSH daemon runs as root)
- auid=1000: The original login user (user ID 1000)
- ses=1: Session ID
- subj=…: SELinux context
- msg=’op=login id=1000 …’: The actual message with details
Notice the auid field. This is the audit user ID, which tracks the original user even after they switch users with su or sudo. This is crucial for accountability.
If you see res=failed instead of res=success, that indicates a failed login attempt. The addr field shows the IP address of the remote host.
Using Ausearch With Advanced Filters
Beyond basic searches, ausearch supports complex queries. You can combine multiple conditions to pinpoint specific events. For example, to find all failed file access attempts by a specific user:
sudo ausearch -ua johndoe -f /etc/shadow --success no
This shows every time johndoe tried to access /etc/shadow and failed. You can also filter by system call number. To see all open system calls (syscall number 2 on x86_64):
sudo ausearch -sc open
For network-related events, use -sc connect or -sc bind. The ausearch man page lists all available filters. Some useful ones include:
-i: Interpret numeric fields as human-readable names-c: Filter by command name-x: Filter by executable path-sv: Filter by success or failure (yes/no)-tm: Filter by terminal type
Using the -i flag is especially helpful because it converts user IDs to usernames and group IDs to group names. Without it, you’ll see numbers instead of names.
Generating Reports With Aureport
While ausearch gives you raw records, aureport creates summaries. This is useful for daily reviews or compliance reports. To see a summary of all events in the last hour:
sudo aureport --start 1 hour ago --end now
For a report on failed events:
sudo aureport --failed
You can also generate reports by user, file, or process. For example, to see which files were accessed most often:
sudo aureport --file
This lists files sorted by access count. To see a timeline of events:
sudo aureport --time
This shows event frequency over time, which can help identify patterns like brute force attacks.
Monitoring Audit Logs In Real Time
For live monitoring, you can use tail with ausearch or aureport. The watch command also works well:
sudo watch -n 5 'ausearch -ts recent'
This refreshes every 5 seconds, showing recent events. For a more sophisticated approach, use auditctl to set up real-time alerts. You can configure the audit daemon to send events to a remote syslog server or trigger scripts on specific events.
Another option is to use systemd-journald which can integrate audit logs. With journalctl, you can filter audit events:
sudo journalctl _TRANSPORT=audit
This shows all audit events captured by journald. You can combine this with other filters like --since and --until.
Common Audit Log Analysis Scenarios
Let’s walk through some real-world scenarios. First, detecting brute force attacks. Search for failed login attempts:
sudo ausearch -m USER_LOGIN --success no -i
If you see many attempts from the same IP address, that’s a clear sign of an attack. You can then block that IP with iptables or fail2ban.
Second, monitoring file access. To track who accessed a confidential file:
sudo ausearch -f /var/www/html/config.php -i
This shows every access to that file, including the user and process. If you see unauthorized access, investigate immediately.
Third, tracking privilege escalation. When a user runs sudo, it generates a record. Search for sudo events:
sudo ausearch -m USER_CMD -i
This shows all commands run with sudo. Look for unusual commands like sudo su or sudo visudo.
Fourth, investigating system changes. To see when configuration files were modified:
sudo ausearch -f /etc/ssh/sshd_config -i
This tells you who changed the SSH configuration and when. This is critical for security audits.
Using Audit Logs For Compliance
Many compliance frameworks require audit log reviews. For PCI DSS, you need to monitor access to cardholder data. For HIPAA, you need to track access to protected health information. Audit logs provide the evidence you need.
To generate a compliance report, use aureport with specific filters. For example, to show all events related to a specific user over the past month:
sudo aureport --user --start 1 month ago --end now
You can export this to a file for your auditor. The aureport output is plain text, so it’s easy to import into spreadsheets or other tools.
Remember to store audit logs securely. They contain sensitive information about user activity. Consider encrypting them or sending them to a centralized log server.
Troubleshooting Audit Log Issues
Sometimes you might not see expected events. First, check if the audit daemon is running:
sudo systemctl status auditd
If it’s not running, start it with sudo systemctl start auditd. Next, check your audit rules:
sudo auditctl -l
This lists all active rules. If no rules are defined, no events will be logged. You need to add rules for specific events. For example, to log all file access to /etc/passwd:
sudo auditctl -w /etc/passwd -p rwxa -k password_file
This watches the file for read, write, execute, and attribute changes. The -k flag adds a key for easier searching.
Another common issue is log rotation. Audit logs can grow quickly, so they’re rotated automatically. Check /etc/audit/auditd.conf for rotation settings. If logs are rotated before you review them, you might miss events. Adjust the max_log_file and num_logs parameters to suit your needs.
Advanced Techniques For Reading Audit Logs
For power users, you can write scripts to parse audit logs. The ausearch output is structured, making it easy to parse with tools like awk or grep. For example, to extract all unique IP addresses from login attempts:
sudo ausearch -m USER_LOGIN -i | grep -oP 'addr=\K[0-9.]+' | sort -u
This gives you a list of all IP addresses that attempted to log in. You can also use jq if you convert the logs to JSON. The aureport command supports XML output with --format xml.
For large environments, consider using a SIEM system like Splunk or ELK Stack. These tools can ingest audit logs and provide dashboards and alerts. But even without them, the command-line tools are powerful enough for most needs.
Another tip: use the --debug flag with ausearch to see the raw search parameters. This helps when you’re troubleshooting complex queries.
Best Practices For Audit Log Management
To get the most out of audit logs, follow these practices:
- Define clear audit rules for critical files and commands
- Review logs daily, especially for failed events
- Store logs in a centralized location for analysis
- Set up alerts for suspicious activity
- Regularly test your audit configuration
- Ensure logs are timestamped correctly with NTP
- Protect log files from tampering with permissions
Audit logs are only useful if you review them consistently. Automate the process as much as possible. Use scripts to generate daily summaries and send them via email.
Also, be mindful of log volume. Too many rules can generate gigabytes of logs per day, making analysis difficult. Start with critical events and add rules gradually.
Frequently Asked Questions
What Is The Difference Between Ausearch And Aureport?
ausearch searches for specific audit records based on criteria, showing raw event details. aureport summarizes audit data into reports