How Auditd Logs Help Secure Linux Environments

If you manage a Linux server and notice something unusual, auditd logs can help you track exactly what’s happening. This built-in audit system records who accessed the system and what actions they performed.

In this guide, we’ll cover setting up auditd, reading the logs, and using them to detect potential security issues early.

What Are Auditd Logs?

Auditd (audit daemon) is Linux’s built-in auditing framework that tracks system calls, file access, network activity, and user actions. Whenever a user logs in, opens a file, or executes a command, auditd records the event in structured log files.

These logs serve several key purposes: they support security investigations, help meet compliance standards like PCI-DSS and HIPAA, assist in debugging system problems, and monitor user behavior. Unlike typical system logs that focus on applications, auditd captures kernel-level events that often go unnoticed by other logging tools.

The audit system is made up of three main components:

• Kernel audit subsystem: Embedded in the Linux kernel, this component captures events at the kernel level and cannot be bypassed by user applications.
• Auditd daemon: This service manages the audit system by writing logs to disk and handling log rotation. It runs as a system service and starts early during boot.
• Audit rules: These define what events to record. You can configure rules to monitor specific files, system calls, users, or processes based on your security and compliance requirements.

Log Formats and Fields

Auditd logs use a specific format that packs lots of information into each line. Here's how to decode the most common fields:

Timestamp fields like msg=audit(1640995200.123:456) contain the Unix timestamp and a sequence number. The sequence number helps order events that occur within the same second.

User identification appears in multiple forms: auid (audit user ID) shows who originally logged in, uid shows the current user ID, and euid shows the effective user ID for privilege operations.

Process information includes pid (process ID), ppid (parent process ID), comm (command name), and exe (executable path). These fields help you trace process relationships and identify suspicious programs.

System call details vary by event type but often include syscall numbers, arch (architecture), and return values. The success field quickly tells you if an operation succeeded or failed.

Here's a breakdown of a file access event:

type=PATH msg=audit(1640995200.123:456): item=0 name="/etc/passwd" inode=123456 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:passwd_file_t:s0

This shows someone accessed /etc/passwd, with file metadata including permissions (mode=0100644), owner IDs (ouid=0 ogid=0), and SELinux context information.

How Auditd Logs Work

When auditing is turned on, the Linux kernel watches system calls and other activities based on the rules you set. Whenever something matches those rules, it creates an audit record with details like the time, user ID, process info, and event specifics.

Here’s what happens step-by-step:

• The kernel catches a system call or event.
• It checks your audit rules to see if it needs to log the event.
• If it matches, the kernel makes a detailed record.
• The auditd service then saves this record in the audit log file, usually at /var/log/audit/audit.log.

Here’s an example of what an audit log entry looks like:

type=SYSCALL msg=audit(1640995200.123:456): arch=c000003e syscall=2 success=yes exit=3 a0=7fff12345678 a1=0 a2=1b6 a3=7fff87654321 items=1 ppid=1234 pid=5678 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="cat" exe="/bin/cat" key="file_access"

It might look overwhelming at first, but here’s what some key parts mean:

• syscall=2 means the open() system call.
• uid=1000 shows which user ran the command.
• comm="cat" is the name of the command used.

Step-by-Step Process for Setting Up Auditd Logs

Install Auditd and Start the Service

Getting auditd up and running is straightforward on most Linux distributions. Use your package manager to install the audit tools and then start and enable the auditd service so it runs on boot.

# Ubuntu/Debian
sudo apt update
sudo apt install auditd audispd-plugins

# RHEL/CentOS/Fedora
sudo yum install audit
sudo systemctl start auditd
sudo systemctl enable auditd

The configuration file /etc/audit/auditd.conf controls how logs are stored and rotated. You may want to adjust settings like maximum log file size and retention depending on your needs.

Define What to Monitor by Configuring Audit Rules

Audit rules control which system activities get logged. You can add rules temporarily using auditctl or save them permanently in /etc/audit/rules.d/.

For example, you can monitor critical system files, track program executions, or focus on actions by specific users. Assigning keys to rules helps organize and search the logs later.

sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -a always,exit -F arch=b64 -S execve -k program_execution
sudo auditctl -a always,exit -F uid=1001 -k user_1001_activity

Remember to save important rules in /etc/audit/rules.d/audit.rules to keep them active after reboot.

How to Search Audit Logs

Audit logs can be a bit complex to understand, but tools like ausearch let you filter logs by time, user, or rule key, so you focus on relevant events.

sudo ausearch -ts recent                  # last hour
sudo ausearch -k passwd_changes           # by key
sudo ausearch -ui 1000                    # by user ID

Use aureport to generate summaries that help spot trends and anomalies:

sudo aureport                             # summary report
sudo aureport -l --failed                 # failed login attempts
sudo aureport -x --summary                # executed programs summary

Piping ausearch output into aureport improves readability:

sudo ausearch -k passwd_changes | aureport -f

Auditd Log Patterns You’ll See Often

When you start working with auditd logs, it helps to know what “normal” looks like so you can spot when something feels off.

Certain patterns come up repeatedly, and understanding these can make your investigations faster and more effective.

First, file access logs show when users or processes read, write, or execute files. These help you keep track of who’s touching sensitive data and can highlight suspicious attempts to copy or move files.

Next, authentication events capture things like login attempts, use of sudo, and privilege changes. If you see lots of failed logins, it could mean someone’s trying to break in or there’s a misconfiguration.

Then, process execution logs tell you what programs are starting up. This is especially useful for catching malware or unauthorized software before it causes trouble.

Finally, network activity logs record socket creation and connections, which can reveal unusual communication patterns that might indicate data exfiltration or lateral movement.

Putting It All Together: How to Investigate Using Auditd Logs

Here’s a simple example of how these patterns come into play during an investigation:

• Start by checking for recent failed logins to spot possible attack attempts:

sudo aureport -l --failed --start recent

• Then, look for any unexpected or suspicious process executions:

sudo ausearch -k process_execution -ts recent

• Next, examine changes to critical files that might be targeted or altered:

sudo ausearch -k process_execution -ts recent

• Finally, follow the trail of a suspicious process by correlating all its events using its process ID:

sudo ausearch -p 5678

Best Practices for Auditd Performance and Storage

Auditd can produce a lot of data, and if it’s not set up carefully, it might impact your system’s performance. Here’s how to keep things efficient without sacrificing important security coverage:

• Be Specific with Your Rules: Monitoring every system call or all activities can quickly overwhelm your system and create huge log files. Instead, focus your rules on critical files, specific users, or key processes relevant to your security needs.
• Plan for Storage: Audit logs grow fast, especially on busy servers. Keep an eye on the size of /var/log/audit/ and set up log rotation in /etc/audit/auditd.conf to prevent your disk from filling up.
• Be Careful with Network Auditing: Tracking network events can generate thousands of logs per second on busy servers, which might overload your system. Use network auditing selectively.
• Manage Buffers to Avoid Data Loss: The kernel uses buffers to handle large bursts of audit events. If these buffers fill up, audit data can be lost. Adjust buffer settings and log rotation policies like this:

# In /etc/audit/auditd.conf
max_log_file = 50
num_logs = 10
max_log_file_action = rotate

How to Bring Auditd Logs into Your Observability Setup

Integrating auditd logs with your observability platform can give you a unified view of security events alongside application metrics and traces. Here's how to get started:

Send Auditd Logs Directly with Auditbeat

One way to integrate audit data is to replace auditd with Auditbeat, a lightweight shipper that captures audit events and sends them directly to platforms like Elasticsearch.

Here’s an example configuration that watches critical files and tracks process executions:

auditbeat.modules:
- module: auditd
  audit_rules: |
    -w /etc/passwd -p wa -k passwd_changes
    -w /etc/shadow -p wa -k shadow_changes
    -a always,exit -F arch=b64 -S execve -k process_execution

output.elasticsearch:
  hosts: ["your-elasticsearch-endpoint:9200"]
  index: "auditbeat-%{+yyyy.MM.dd}"

Before running Auditbeat, you’ll want to stop and disable the auditd service to avoid conflicts:

sudo systemctl stop auditd
sudo systemctl disable auditd
sudo systemctl start auditbeat
sudo systemctl enable auditbeat

Forward Auditd Logs While Keeping Local Storage

If you need to retain local audit logs and still forward them for centralized analysis, you can use log forwarders like Fluentd.

Here’s a sample Fluentd setup that tails the audit log and forwards entries to your observability platform:

<source>
  @type tail
  path /var/log/audit/audit.log
  pos_file /var/log/fluentd/audit.log.pos
  tag audit
  format /^type=(?<type>[^ ]*) msg=audit\((?<timestamp>[^)]*)\): (?<message>.*)$/
</source>

<match audit>
  @type forward
  <server>
    host your-observability-platform.com
    port 24224
  </server>
</match>

Enhance Your Monitoring with Alerts and Correlation

Once audit logs are integrated, you can set up real-time alerts for critical events like failed logins or privilege escalations. Combining auditd data with metrics and traces allows for deeper correlation analysis, giving you context on how security events affect overall system health.

How Auditd Logs Help You Meet Compliance

Many regulatory frameworks mandate detailed audit logging to ensure security and accountability. Auditd logs provide a solid foundation for meeting these compliance needs by capturing key system and user activities.

• PCI-DSS: Requires monitoring access to cardholder data and tracking administrative actions. Auditd logs record file accesses, user authentications, and privilege changes that auditors expect to see.
• HIPAA: Demands audit logs for systems handling protected health information. Configuring auditd to monitor database access, file modifications, and user activities supports compliance in healthcare environments.
• SOX: Focuses on tracking changes to financial systems and data. Audit rules covering configuration files, database access, and administrative tasks help fulfill these requirements.
• GDPR: While GDPR doesn’t specify technical controls, audit logs are essential evidence demonstrating your efforts to protect personal data by monitoring who accesses it and when.

How to Fix Common Auditd Problems

Here are some common problems and how to fix them:

• Audit logs not generating: First, make sure the auditd service is running and your audit rules are loaded correctly. Use sudo auditctl -l to list active rules and sudo systemctl status auditd to check the service status.
• High disk usage: Audit logs can grow quickly and fill up disk space. Adjust log rotation settings in /etc/audit/auditd.conf to manage this, or consider forwarding logs to a central system with more storage.
• Performance slowdowns: Too many audit rules or overly broad rules can degrade system performance. Review your rules regularly and focus on monitoring the most important security events instead of logging everything.
• Missing events: If expected events aren’t showing up, double-check your rule syntax and review the audit logs for error messages. Running auditctl -s gives you the audit system’s current status and statistics.
• Log parsing issues: Auditd log formats can change between kernel versions. When you upgrade systems, update your log parsing configurations and test them with sample logs to avoid errors.

Wrapping Up

Auditd logs give you a detailed view of what’s happening on your Linux systems, which is crucial for security, compliance, and troubleshooting. Getting your auditd setup right and using focused rules lets you cut through the noise and find the important stuff.

Integrating these logs with tools like Last9 takes it a step further—combining logs, metrics, and traces in one place so you can quickly spot issues and understand their impact without juggling multiple tools. If you’re looking for a clearer picture of your system’s health, our platform makes that easier. Get started for free today!

FAQs

How much disk space do auditd logs typically use?

This depends entirely on your audit rules and system activity. A basic configuration monitoring, authentication, and file changes might generate 10-50 MB per day on a typical server. However, monitoring network activity or system calls can generate gigabytes daily. Start with conservative rules and monitor disk usage to find the right balance.

Can auditd logs impact system performance?

Yes, but the impact is usually minimal with proper configuration. Each monitored event adds slight overhead, so avoid overly broad rules like monitoring all system calls. Focus on specific files, users, or processes that matter for your security goals. Most systems handle hundreds of audit events per second without noticeable performance degradation.

How long should I retain audit logs?

Retention requirements vary by industry and compliance needs. Many organizations keep audit logs for 90 days to one year locally, with longer-term storage in compressed archives. Consider your incident response needs, compliance requirements, and storage costs when setting retention policies.

What's the difference between auditd and other Linux logging systems?

Auditd operates at the kernel level and captures system calls and kernel events that other logging systems miss. Syslog captures application and service messages, while auditd focuses on security-relevant system activities. They complement each other rather than overlap.

Can I monitor Docker containers with auditd?

Yes, but it requires careful configuration. Auditd sees container activities as regular processes, so you can monitor container file systems, process execution, and network activity. However, you'll need to account for container-specific paths and namespaces in your audit rules.

How do I handle audit log rotation and archival?

Configure rotation in /etc/audit/auditd.conf using parameters like max_log_file, num_logs, and max_log_file_action. For long-term archival, consider forwarding logs to a central system or using external log management tools that can compress and archive older data automatically.