Panduan auditd: Linux Audit Framework untuk Forensik & Kepatuhan 2026

Diperbarui: 27 Mei 2026

auditd adalah daemon user-space dari Linux Audit Framework yang mencatat kejadian keamanan kernel (seperti panggilan sistem, akses file, dan perubahan konfigurasi) ke dalam log /var/log/audit/audit.log untuk keperluan forensik, deteksi anomali, dan kepatuhan (PCI-DSS, HIPAA, ISO 27001). Bekerja melalui subsistem kauditd di kernel (sejak Linux 2.6.6), auditd menerima event via netlink dan menyimpannya dengan format yang dapat dicari menggunakan ausearch atau diringkas dengan aureport. Pada Linux kernel 6.6 LTS dan paket audit-3.1.x, kita akhirnya dapat dukungan io_uring auditing dan filter syscall yang lebih granular.

• auditd mencatat syscall, akses file, dan eksekusi binary level kernel via subsistem audit (sejak kernel 2.6.6, diperluas untuk io_uring di 6.6).
• Tiga utilitas inti: auditctl untuk mengelola rule, ausearch untuk query log, dan aureport untuk laporan ringkas.
• Rule disimpan di /etc/audit/rules.d/*.rules dan dimuat saat boot. Gunakan flag -e 2 untuk membuat ruleset immutable hingga reboot berikutnya.
• Profil siap pakai untuk PCI-DSS, STIG, GDPR, dan HIPAA tersedia di /usr/share/audit/sample-rules/ pada paket audit 3.1+.
• auditd berbeda dengan journald: ia memantau perilaku kernel-level, bukan output aplikasi user-space.
• Untuk volume tinggi, forward event via audisp-remote atau plugin audisp-syslog ke SIEM seperti Wazuh atau Elastic.

Apa itu auditd di Linux?

auditd adalah komponen user-space dari Linux Audit Framework, sebuah subsistem audit kernel yang awalnya dikembangkan oleh Red Hat untuk memenuhi kebutuhan sertifikasi Common Criteria EAL4+. Daemon ini berkomunikasi dengan kernel melalui socket NETLINK_AUDIT (family 9), menerima record yang dipancarkan oleh thread kauditd, lalu menulisnya ke disk dalam format teks yang dapat di-parse.

Jujur saja, dalam praktik saya menangani insiden di lingkungan produksi, auditd menjawab pertanyaan-pertanyaan yang tidak bisa dijawab oleh logging aplikasi: siapa yang membaca file /etc/shadow, kapan binary /usr/bin/curl dieksekusi oleh akun layanan, dan proses mana yang mengubah aturan iptables. Karena event di-trap di level syscall, root pun tidak bisa menyembunyikan jejaknya tanpa memanipulasi log file secara langsung. Itulah alasan kami biasanya mem-forward log dalam waktu hampir-realtime.

Tiga komponen yang harus dipahami:

• kauditd: kernel thread yang melakukan event filtering berdasarkan rule yang dimuat. Sejak kernel 5.10, ia mendukung filter berbasis cgroup dan container ID.
• auditd: daemon user-space yang menulis event ke disk dan mengelola rotasi log.
• audispd / audisp: multiplexer event yang mendistribusikan record ke plugin (syslog, remote, prelude, dll). Pada audit 3.x, fungsinya diintegrasikan ke dalam auditd sendiri.

Instalasi dan Konfigurasi Awal auditd

Pada distribusi berbasis Debian/Ubuntu, instalasi membutuhkan paket auditd dan utilitas pendukungnya. Mari mulai dari yang paling umum.

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

# RHEL 9 / Rocky Linux 9 / AlmaLinux 9
sudo dnf install -y audit audit-libs

# Aktifkan dan jalankan saat boot
sudo systemctl enable --now auditd

# Verifikasi status dan versi
sudo systemctl status auditd
auditctl -v
# auditctl version 3.1.2

File konfigurasi utama berada di /etc/audit/auditd.conf. Beberapa parameter yang biasanya saya ubah dari default pada server produksi:

# /etc/audit/auditd.conf - bagian penting
log_file = /var/log/audit/audit.log
log_format = ENRICHED         # tambahkan UID->nama user dan path resolusi
max_log_file = 100            # MB, rotasi setelah 100 MB
num_logs = 10                 # simpan 10 file rotasi
max_log_file_action = ROTATE  # alternatif: KEEP_LOGS, SUSPEND
space_left = 500              # MB tersisa sebelum action
space_left_action = EMAIL
admin_space_left = 100
admin_space_left_action = HALT  # paranoid mode: matikan sistem jika disk penuh
disk_full_action = HALT
disk_error_action = HALT

Format ENRICHED (default di audit 3.x) menyertakan field tambahan seperti UID="yuki" dan EXE="/usr/bin/sudo", yang sangat memudahkan korelasi tanpa harus melakukan lookup terpisah. Untuk environment yang mengikuti CIS Benchmark, admin_space_left_action = HALT sebenarnya wajib, namun pertimbangkan dampaknya: server akan benar-benar mati saat disk audit penuh. Saya pernah kena masalah ini di shift weekend, dan percayalah, Anda tidak ingin mengulanginya.

Menulis Audit Rules dengan auditctl

Audit rules dibagi tiga kategori: control rules (mengatur subsistem audit itu sendiri), file system rules (memantau path atau watch), dan system call rules (memantau syscall spesifik). Rule yang ditambahkan via auditctl bersifat sementara, jadi untuk persistensi simpan ke /etc/audit/rules.d/.

Contoh rule yang sering saya pakai di awal hardening:

# /etc/audit/rules.d/50-hardening.rules

## Control rules
-D                              # hapus semua rule yang ada
-b 8192                         # buffer size (event sebelum drop)
-f 1                            # failure mode: 0=silent, 1=printk, 2=panic
--backlog_wait_time 60000

## File watches - file sensitif
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-w /etc/sudoers.d/ -p wa -k privilege
-w /etc/ssh/sshd_config -p wa -k sshd

## Syscall rules - eksekusi binary oleh user normal
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_exec

## Modifikasi waktu sistem (CVE-relevant: NTP attacks)
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_change

## Modifikasi network configuration
-a always,exit -F arch=b64 -S sethostname,setdomainname -k network_modify

## Mount/unmount filesystem
-a always,exit -F arch=b64 -S mount,umount2 -F auid>=1000 -F auid!=4294967295 -k mount

## Make config immutable - HARUS jadi rule terakhir
-e 2

Penjelasan singkat sintaks: -w memantau path dengan flag -p (r=read, w=write, x=execute, a=attribute change), sedangkan -a always,exit -S syscall mencatat syscall saat exit. Field -F auid>=1000 membatasi pada user "asli" (di atas UID minimum non-sistem). Nilai 4294967295 adalah -1 dalam unsigned 32-bit, menandakan auid belum di-set (misalnya thread kernel).

Setelah menyimpan file, muat ulang rule:

sudo augenrules --load
sudo auditctl -l         # lihat rule aktif
sudo auditctl -s         # status: enabled, backlog, lost

Membaca Log: ausearch dan aureport

Log auditd ditulis dalam format key-value per baris. Berikut contohnya:

type=SYSCALL msg=audit(1716800000.123:4567): arch=c000003e syscall=59
success=yes exit=0 a0=7fff... ppid=1234 pid=5678 auid=1001 uid=1001
gid=1001 euid=0 suid=0 fsuid=0 egid=1001 sgid=1001 fsgid=1001 tty=pts0
ses=3 comm="cat" exe="/usr/bin/cat" key="user_exec"

Membaca raw seperti ini tidak scalable. Gunakan ausearch untuk query terstruktur:

# Cari semua event dengan key "identity" (modifikasi /etc/passwd, dll)
sudo ausearch -k identity -i

# Cari aktivitas user tertentu dalam 24 jam terakhir
sudo ausearch -ua yuki --start yesterday -i

# Cari syscall execve yang gagal (potensi reconnaissance)
sudo ausearch -sc execve --success no -i

# Cari berdasarkan PID dan timestamp
sudo ausearch -p 5678 --start "05/27/2026 08:00:00" -i

# Cari berdasarkan key sshd_config setelah waktu tertentu
sudo ausearch -k sshd -ts today -i

Flag -i meminta ausearch untuk "interpret": mengubah UID jadi nama user, syscall number jadi nama, dan timestamp epoch jadi human-readable. Untuk ringkasan agregat, gunakan aureport:

# Ringkasan event yang gagal
sudo aureport --failed

# Top user yang menjalankan sudo
sudo aureport -u --summary -i

# Daftar binary yang dieksekusi hari ini
sudo aureport -x --start today -i

# Laporan anomali login
sudo aureport -au --summary -i

Untuk membahas analisis log lebih dalam, lihat juga panduan kami tentang Fail2ban untuk proteksi SSH brute force yang melengkapi monitoring auditd dengan respons aktif.

Perbedaan auditd dengan journald dan rsyslog

Pertanyaan yang sering muncul: "kalau sudah ada journald/rsyslog, kenapa butuh auditd?" Ketiganya beroperasi di lapisan berbeda. Tabel berikut merangkum perbedaannya:

Aspek	auditd	journald	rsyslog
Sumber event	Kernel (syscall, watch)	systemd unit, stdin/stdout	Aplikasi user-space
Granularitas	Syscall & file access	Service-level log	Application-level log
Format	Key-value terstruktur	Binary indexed	Free-form text
Filter	Kernel-side, sangat efisien	Unit, priority	Selector facility.severity
Use case utama	Forensik, kepatuhan	Operasional, debugging	Aggregasi log
Bypass oleh root	Sulit (kernel-trapped)	Mudah (delete + restart)	Mudah (file overwrite)

Dalam audit perilaku berbahaya, journald hanya melihat aplikasi yang mau menulis log. auditd, di sisi lain, mencatat setiap panggilan kernel yang cocok dengan rule, termasuk dari binary statis yang sengaja dibawa attacker. Ini bukan berarti journald tidak penting; keduanya saling melengkapi. Lihat juga panduan SELinux dan AppArmor untuk MAC hardening, karena auditd biasanya mencatat AVC denial dari MAC, dan saya merekomendasikan keduanya berjalan bersama.

Konfigurasi auditd untuk Kepatuhan (PCI-DSS, HIPAA)

Salah satu nilai jual auditd adalah ekosistem rule template yang sudah dikurasi untuk berbagai framework kepatuhan. Paket audit menyertakan /usr/share/audit/sample-rules/ dengan contoh untuk:

• 30-pci-dss-v31.rules: PCI-DSS v3.1 (cardholder data environment)
• 30-stig.rules: DISA STIG (federal US)
• 30-nispom.rules: NISPOM (Department of Defense)
• 30-ospp-v42.rules: Common Criteria OSPP v4.2
• 40-local.rules: template untuk customization

Untuk menerapkan baseline PCI-DSS, salin template dan muat:

sudo cp /usr/share/audit/sample-rules/30-pci-dss-v31.rules /etc/audit/rules.d/
sudo cp /usr/share/audit/sample-rules/40-local.rules /etc/audit/rules.d/

# Validasi syntax sebelum apply
sudo augenrules --check
sudo augenrules --load

# Verifikasi rule loaded
sudo auditctl -l | wc -l

Selain itu, untuk HIPAA (US healthcare) dan GDPR (Uni Eropa), prinsipnya sama: pantau akses ke data sensitif, perubahan privilege, dan event autentikasi. Tambahan yang biasanya saya rekomendasikan:

# Akses ke data PHI (sesuaikan path)
-w /var/lib/phi-records/ -p rwa -k phi_access

# Semua eksekusi binary setuid/setgid
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid_exec
-a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid_exec

# Kernel module load/unload (rootkit detection)
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k modules
-w /etc/modprobe.conf -p wa -k modules
-w /etc/modprobe.d/ -p wa -k modules

Referensi resmi untuk pengaturan dapat dilihat di dokumentasi linux-audit/audit-userspace di GitHub, yang merupakan upstream resmi proyek audit, serta panduan auditing Red Hat Enterprise Linux 9 untuk konteks yang lebih luas.

Forwarding Event ke SIEM dan Wazuh

Log audit lokal hanya berguna sampai server dikompromikan. Untuk lingkungan produksi, forward event ke SIEM eksternal. Paket audispd-plugins menyertakan beberapa plugin yang relevan:

ls /etc/audit/plugins.d/
# af_unix.conf  audispd-syslog.conf  syslog.conf  au-remote.conf

Untuk forward ke rsyslog (paling sederhana):

# /etc/audit/plugins.d/syslog.conf
active = yes
direction = out
path = /sbin/audisp-syslog
type = always
args = LOG_LOCAL6
format = string

Lalu di rsyslog, route local6 ke remote SIEM:

# /etc/rsyslog.d/30-audit-forward.conf
local6.* @@siem.internal.example.com:6514;RSYSLOG_SyslogProtocol23Format

Untuk integrasi dengan Wazuh agent dan auditd, agent membaca /var/log/audit/audit.log secara langsung dan tidak memerlukan plugin terpisah. Wazuh kemudian melakukan parsing dan korelasi server-side.

Tuning Performa dan Pertimbangan Produksi

Audit yang terlalu agresif bisa berdampak ke performa, terutama pada workload I/O berat. Beberapa metrik yang harus dipantau:

sudo auditctl -s
# enabled 1
# failure 1
# pid 1234
# rate_limit 0
# backlog_limit 8192
# lost 0           # <-- harus 0; selain itu event di-drop
# backlog 12
# backlog_wait_time 60000
# backlog_wait_time_actual 0

Jika lost non-zero, naikkan backlog_limit. Pada server dengan rate event tinggi (database server, container host), saya biasanya set -b 32768 atau lebih besar. Selain itu:

1. Hindari watch pada direktori dengan banyak file. Misal -w /var/log/ akan men-trigger ribuan event per detik. Lebih baik watch file spesifik.
2. Gunakan field filter untuk membatasi syscall rule. Contoh: -F auid>=1000 mengecualikan thread sistem.
3. Jangan audit operasi internal auditd. Gunakan -F exe!=/usr/sbin/auditd untuk menghindari feedback loop.
4. Tuning kauditd priority: pada kernel ≥5.16, parameter audit_backlog_limit bisa di-set via boot parameter (audit_backlog_limit=16384 di kernel command line).
5. Rotasi log agresif. Pada SAN/NFS-backed storage, set max_log_file = 50 dengan num_logs = 20 untuk menghindari file besar.

Salah satu pertimbangan kontainer: auditd di host akan mencatat syscall seluruh container karena syscall melalui kernel yang sama. Sejak kernel 5.7, ada field contid yang bisa difilter, namun belum semua tooling mendukungnya. Untuk audit per-container, biasanya saya kombinasikan dengan Falco runtime security berbasis eBPF, yang punya konteks container native.

Pendekatan defense-in-depth: gabungkan auditd untuk forensik kernel-level dengan pemindaian kerentanan Trivy untuk container di sisi build, sehingga risiko di pre-runtime dan runtime sama-sama tercakup.

Pertanyaan yang Sering Diajukan

Apakah auditd memengaruhi performa server secara signifikan?

Dengan rule yang fokus dan backlog_limit yang cukup, overhead biasanya di bawah 2-3% CPU. Performa terdampak hanya jika Anda men-audit syscall yang sangat sering (misalnya read tanpa filter), atau watch direktori dengan ribuan file. Tuning rule dan filtering auid mengurangi noise drastis.

Bagaimana cara melihat log auditd secara realtime?

Gunakan sudo tail -f /var/log/audit/audit.log untuk raw output, atau sudo ausearch --start recent --raw | aureport -i untuk laporan terus-menerus. Untuk dashboard realtime, forward ke Wazuh, Elastic, atau Splunk via audisp-syslog.

Apa perbedaan auditctl, ausearch, dan aureport?

auditctl mengelola rule (tambah, hapus, list); ausearch melakukan query terhadap log historis dengan filter spesifik (key, user, syscall); aureport membuat ringkasan agregat (top user, executable, event yang gagal). Ketiganya bekerja terhadap log file yang sama.

Bisakah auditd mendeteksi rootkit?

auditd dapat mendeteksi indikator rootkit seperti load kernel module yang tidak diharapkan, modifikasi /etc/ld.so.preload, atau eksekusi binary di lokasi non-standar, selama rule yang relevan aktif. Namun ia bukan anti-rootkit. Gunakan bersama chkrootkit, rkhunter, atau AIDE untuk file integrity monitoring.

Apakah auditd cocok untuk lingkungan kontainer?

auditd berjalan di host dan mencatat syscall dari seluruh kontainer karena semuanya berbagi kernel. Sejak kernel 5.7 ada field contid untuk identifikasi kontainer, tetapi untuk visibility runtime per-container yang lebih baik, kombinasikan dengan Falco berbasis eBPF.

Bagaimana cara membuat audit rule menjadi permanen?

Simpan rule di file .rules di dalam direktori /etc/audit/rules.d/, lalu jalankan sudo augenrules --load atau restart auditd. File-file di rules.d akan digabungkan ke /etc/audit/audit.rules berdasarkan urutan abjad nama file. Gunakan prefix angka (mis. 30-, 50-) untuk mengontrol urutan.