Labs · Cyber Security

Lab: Watch Your Own Login and File Events with auditd: Write Watch Rules for Key Files and Search Them with ausearch

By Ravindra Bagale · Last updated: 8 October 2026

Suppose we are…

Suppose we are a security engineer at Mphasis, and a client wants alerts when anyone changes user accounts or SSH settings on their Linux servers. A full SIEM such as Wazuh is the long-term plan, but it needs a dedicated server with lots of RAM. Today we set up the building block every SIEM agent relies on: auditd, the Linux audit system, on our own VM.

Goal of this lab

By the end you will have:

• auditd running with permanent watch rules on /etc/passwd, /etc/group, /etc/sudoers, /etc/sudoers.d/ and /etc/ssh/sshd_config.
• Test events you created yourself, found with ausearch by key, user and command.
• A short report from aureport of logins and key-based events.

What you need (all free)

• Your own Ubuntu Server VM with sudo. About 35 minutes, 1 GB RAM is enough.

Steps

1. Install and start the audit system:

   sudo apt update && sudo apt install -y auditd
   sudo systemctl enable --now auditd
   sudo auditctl -s
   

   👁 What you should see: enabled 1 in the status output.

2. Write permanent watch rules. -w is the path, -p wa means write and attribute changes, -k is a key (a tag to search by):

   sudo tee /etc/audit/rules.d/lab.rules > /dev/null <<'RULES'
   -w /etc/passwd -p wa -k identity
   -w /etc/group -p wa -k identity
   -w /etc/sudoers -p wa -k sudoers
   -w /etc/sudoers.d/ -p wa -k sudoers
   -w /etc/ssh/sshd_config -p wa -k sshd_config
   RULES
   sudo augenrules --load
   sudo auditctl -l
   

   👁 What you should see: your five rules listed, for example -w /etc/passwd -p wa -k identity.

3. Create safe test events, like the attacker in Lab 31 but on purpose:

   sudo adduser --gecos "" --disabled-password audittest
   sudo usermod -aG sudo audittest
   sudo touch /etc/ssh/sshd_config
   

4. Search by key:

   sudo ausearch -k identity -i | tail -n 20
   

   👁 What you should see: records with type=SYSCALL, comm=useradd or comm=usermod, exe=/usr/sbin/useradd, auid=youruser (the real person behind sudo) and a readable time.

5. Find the SSH config change:

   sudo ausearch -k sshd_config -i | grep -E "type=SYSCALL" | tail -n 3
   

   👁 What you should see: comm=touch with your username as auid.

6. Look at logins and a summary by key:

   sudo aureport -au -i | tail -n 10
   sudo aureport -k -i --summary
   

   👁 What you should see: your sudo and SSH authentications with success or failure, and a count per key (identity, sshd_config).

7. Write one "alert rule" in plain words that a SIEM would use, for example: "Alert HIGH when key identity shows useradd or usermod adding to sudo, outside a change window."

8. Clean up the test user: sudo deluser --remove-home audittest. Then search again: the deletion is recorded too.

Common mistakes

Self-check checklist

Try-at-home challenge

Add a rule that records every command run as root by a logged-in human user, then find the commands you ran in the last 10 minutes.

Samjla ka? Watch the few files that matter, tag them, search by key, read auid. Aata pudhe jaauya: Chapter 37 reduces what your machines share on the network.