📑 Daftar Isi
Skip basa-basi. Kamu punya server production, dan di dalamnya ada file-file yang nggak boleh berubah tanpa kamu tahu. /etc/passwd, /etc/ssh/sshd_config, cron job, config aplikasi. Semuanya penting, dan pertanyaannya cuma satu: gimana caranya kamu tahu kalau ada yang ngutak-atik file itu? Jawaban jangka pendeknya: auditd.
Dan tenang, ini bukan Linux Security Module kaya SELinux atau AppArmor yang ribet itu. Auditd itu daemon audit dari kernel yang kerjanya sederhana banget: merekam. Siapa yang akses file apa, lewat program apa, jam berapa, dari session login mana. Ibaratnya CCTV, tapi versi CLI.
Masalah utamanya simpel: Linux secara default nggak ngerekam akses file. Kernel-nya sebenernya mampu, tapi fitur audit-nya mati dari pabrik. Jadi pas ada attacker (atau admin yang lagi salah ketik) ngubah file penting, sistem cuma diem aja. Nggak ada jejak, nggak ada timestamp, nggak ada log. Kamu baru sadar pas seminggu kemudian ada yang aneh, dan pas itu udah susah banget buat nge-rekonstruksi apa yang kejadian dan kapan. Ini juga bukan cuma soal keamanan sih. Kalau kamu jalan di environment yang pake compliance kayak PCI-DSS atau ISO 27001, file integrity monitoring itu bukan pilihan, tapi kewajiban. Waktu auditor external nanya ‘buktikan kalau /etc/shadow nggak pernah diubah tanpa izin’ dan kamu nggak bisa, selamat, itu diskusi panjang yang nggak enak.
Symptom-nya sendiri sering halus: service tiba-tiba jalan dengan config yang nggak kamu kenal, ada user SSH baru yang nggak pernah kamu bikin, atau load server naik di jam-jam yang nggak wajar. Nah, kalau auditd udah jalan dari awal, kamu tinggal tanya ke log: siapa yang nyentuh file ini terakhir? Kapan? Dari mana? Semuanya ada di situ. Bener-bener nyimpen waktu.
Oke, daripada teori mulu, yuk langsung praktek. Semua yang aku tulis di bawah ini berdasarkan setup yang beneran aku pasang di beberapa server client, dari Ubuntu 22.04 sampe AlmaLinux 9. Command-nya aman di-copy, dan kalau kamu cuma pengen baseline yang solid kelar hari ini, ikutin aja urutannya dari awal sampe akhir. Jangan ada yang kelewat, terutama bagian immutable-nya.
1. Install Paket Audit
Di Debian/Ubuntu, install dua paket sekaligus: auditd sama audispd-plugins (yang kedua ini buat notifikasi kalau nanti kamu butuhin).
sudo apt update
sudo apt install auditd audispd-pluginsBuat keluarga RHEL (Rocky, AlmaLinux, CentOS):
sudo dnf install audit audispd-plugins2. Aktifkan dan Verifikasi Service
sudo systemctl enable auditd
sudo systemctl start auditd
sudo systemctl status auditdKalau status-nya active (running), bagus. Tapi hati-hati: daemon jalan nggak otomatis berarti ada rules yang aktif. Banyak orang berhenti di sini dan ngerasa udah aman. Padahal auditd tanpa rules itu kayak CCTV yang nyala tapi kameranya nggak kepasang.
3. Pahami Dua Tipe Rules
| Tipe Rules | Contoh | Kegunaan |
|---|---|---|
| File watch (-w) | auditctl -w /etc/passwd -p wa -k passwd_changes | Pantau file spesifik yang nggak boleh berubah isinya |
| Syscall filter (-a) | auditctl -a always,exit -F arch=b64 -S openat -F dir=/etc -k etc_open | Pantau pola akses level rendah, cocok buat direktori |
Buat kebutuhan file integrity, tipe pertama (file watch) itu andalan kamu. Ringan, dan nyambung persis sama yang kamu mau: ‘bilangin aku kalau file ini ke-write atau ke-append’. Huruf di belakang -p itu permission: r=read, w=write, a=append, x=execute. Kombinasi wa artinya write + append. Kalau kamu mau tau akses baca juga, tambahin r, tapi siap-siap log-nya jadi jauh lebih rame, jadi pakai buat file yang paling sensitif aja.
4. Tulis Rules File Integrity
Aturan mainnya gini: tulis rules kamu di /etc/audit/rules.d/audit.rules biar persisten. Kalau nambah pake auditctl langsung di CLI, rules-nya ilang pas reboot. Ini daftar yang aku biasa pasang:
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/group -p wa -k group_changes
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/ssh/sshd_config -p wa -k sshd_config_changes
-w /etc/crontab -p wa -k cron_changes
-w /etc/cron.d/ -p wa -k cron_changes
-w /etc/hosts -p wa -k hosts_changes
-w /etc/ld.so.preload -p wa -k preload_changes
-w /root/.bashrc -p wa -k root_shell_changes
-w /root/.ssh/authorized_keys -p wa -k root_ssh_keysNih, perhatiin /etc/ld.so.preload di daftar itu. File ini juara favoritnya rootkit. Kalau attacker masuk dan nulis path shared object di sana, semua proses yang jalan bakal nge-load payload dia diam-diam. File sekecil ini, dampaknya gede banget. Wajib dipantau.
Terus, perhatiin trailing slash di /etc/cron.d/. Watch direktori itu rekursif, jadi semua file di dalamnya ikut ke-rekam. Trik yang sama juga kepake kalau nanti kamu mau pantau direktori aplikasi.
5. Load Rules dan Set Immutable
sudo augenrules --load
sudo auditctl -laugenrules itu yang ngumpulin semua file .rules di /etc/audit/rules.d, digabung, terus dimuat ke kernel. Setelah itu cek auditctl -l buat mastiin rules-nya kebaca semua. Kalau ada yang typo, baris itu nggak bakal muncul di output. Jadi selalu verifikasi.
Terakhir, tambahin satu baris di paling bawah file rules: -e 2. Ini yang namanya immutable mode. Begitu ke-load, rules-nya nggak bisa diubah, ditambah, atau dihapus sampe reboot. Fungsinya biar attacker (atau admin yang lagi panik) nggak bisa matiin jejak audit di tengah insiden. Tapi kamu wajib paham trade-off-nya: kalau mau ganti rules nanti, harus reboot dulu. Jadi finalkan dulu daftar rules kamu, baru -e 2 dipasang paling terakhir.
6. Tes: Ubah File, Lalu Baca Lognya
Bikin perubahan yang nggak berbahaya ke file yang ke-watch. Misalnya append satu baris ke /etc/hosts terus hapus lagi. Tunggu sebentar, terus query:
sudo ausearch -k hosts_changes -iIni contoh output yang bakal kamu lihat (identitas udah disamarin):
----
time->Mon Jul 20 03:12:44 2026
type=PATH msg=audit(1752963164.412:1234): item=1 name="/etc/hosts" inode=12345 dev=08:01 mode=file,640 ouid=root ogid=root rdev=00:00 nametype=NORMAL
type=PATH msg=audit(1752963164.412:1234): item=0 name="/etc" inode=12344 dev=08:01 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=PARENT
type=CWD msg=audit(1752963164.412:1234): cwd="/root"
type=SYSCALL msg=audit(1752963164.412:1234): arch=c000003e syscall=257 success=yes exit=12 a0=ffffff9c a1=55d41e2f5f20 a2=1 a3=1 items=2 ppid=1721 pid=2073 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="tee" exe="/usr/bin/tee" subj==unconfined key="hosts_changes"
type=PROCTITLE msg=audit(1752963164.412:1234): proctitle=7465653A202F6574632F686F737473Yang wajib kamu baca dari log ini:
- time: 03:12:44, jam berapa perubahan kejadian. Kalau jam 3 pagi padahal kamu nggak lagi ngapa-ngapain, itu red flag pertama.
- comm dan exe: tee (atau vim, nano, dll), program apa yang nyentuh file-nya.
- auid=1000: login user asli. Ini beda sama uid. Auid itu ‘original user id’, ngerepresentasikan siapa yang login dari terminal. Jadi walau attacker su (root) dari user biasa, auid-nya tetep ketauan.
- ppid dan pid: process tree-nya. Buat nge-trace proses mana yang manggil apa.
- key: hosts_changes, group rules yang barusan kamu buat. Ini yang bikin filtering gampang banget.
Perhatiin juga proctitle itu. Isinya hex dari command line yang jalan. Kalau di-decode, proctitle di atas jadi tee: /etc/hosts. Jadi kamu tau persis perintah apa yang dieksekusi.
7. Setup Rotasi Log
Log audit bisa cepet gede kalau rules-nya banyak. Makanya set rotasi di /etc/audit/auditd.conf biar disk nggak ikut penuh:
max_log_file = 8
num_logs = 5
max_log_file_action = ROTATE
space_left = 512
space_left_action = SYSLOG
admin_space_left = 256
action_mail_acct = rootPenjelasan singkatnya: max_log_file 8 artinya 8 MB per file. Setelah nyampe 8 MB, file lama di-rotate (max_log_file_action = ROTATE), dan num_logs 5 berarti nyimpen 5 generasi file (audit.log, audit.log.1, dst). space_left 512 artinya waktu sisa disk tinggal 512 MB, kirim peringatan ke syslog. Kalau udah di 256 MB (admin_space_left), auditd brenti nulis buat ngehindarin disk full total.
Setelah edit konfigurasi, reload daemon-nya: sudo systemctl restart auditd. Eh, di beberapa versi RHEL yang lawas, restart auditd lewat systemctl itu suka bermasalah. Kalau ketemu gitu, pake sudo service auditd restart. Yang penting pastikan service-nya aktif lagi setelahnya.
8. Baca Log dengan aureport
Kalau ausearch buat cari event spesifik, aureport buat liat ringkasan statistik:
sudo aureport --summary
sudo aureport -f --success
sudo aureport -au- –summary: ringkasan semua tipe event dari yang paling sering muncul.
- -f –success: file access yang berhasil, berguna buat audit siapa aja yang buka file sensitif.
- -au: autentikasi, liat pola login sukses dan gagal.
Buat monitoring harian, aku biasanya jalanin command-command di atas manual pas ada incident, atau dikirim summary-nya ke email/telegram lewat script. Kalau pengen tau caranya, nanti bisa lanjut ke artikel monitoring yang aku link di bawah.
9. Performa: Jangan Asal Watch
Ini yang sering bikin orang nyerah di tengah jalan: server terasa berat, terus auditd yang disalahin. Padahal biasanya bukan auditd-nya, tapi rules-nya yang nggak masuk akal. Kesalahan yang umum banget:
- Watch /var rekursif, semua akses aplikasi ke file cache ke-rekam, log full dalam hitungan jam.
- Watch /usr/bin dengan -p x, tiap eksekusi program ke-log. Di server yang rame, ini resep buat bikin disk penuh.
- Lupa ngecek backlog, kalau auditd kebanjiran event, event yang nggak sempet di-proses bakal dibuang (lost). Dan kamu nggak akan sadar kalau nggak rajin cek auditctl -s.
Cek kesehatan auditd kapan aja dengan: sudo auditctl -s
Perhatiin baris backlog sama lost di output-nya. Kalau backlog terus ngedeketin backlog_limit dan lost mulai naik, itu tanda rules kamu terlalu boros dan harus disempitkan. Di environment yang sehat, lost harusnya 0.
Troubleshooting Umum
| Gejala | Kemungkinan Penyebab | Solusi |
|---|---|---|
| ausearch kosong padahal rules ada | Rules ke-load tapi nggak ada event | Tes tulis file terus cek lagi; pastikan daemon aktif |
| auditd aktif tapi nggak ada rules | Rules cuma nambah pake auditctl / file rules kosong | Tulis di /etc/audit/rules.d, jalankan augenrules –load |
| Lost events naik terus | Buffer kebanjiran / rules kebanyakan | Kurangi watch, atau tambah buffer di aturan (misal -b 8192) |
| Disk /var/log/audit penuh | Rotasi belum diset | Set max_log_file_action = ROTATE + num_logs |
| systemctl restart auditd gagal | Versi RHEL lawas | Pakai service auditd restart |
| auid = 4294967295 | Login pake SSH key / tanpa loginuid | Normal buat sesi tertentu; comm dan exe tetap ke-rekam |
| Ingin ubah rules tapi nggak bisa | Immutable (-e 2) aktif | Reboot, atau jadwalin maintenance window |
Buat yang mau lanjut, ini beberapa artikel yang nyambung: cara baca log journalctl buat ngebandingin jejak audit sama system log, troubleshoot high load server kalau tiba-tiba load naik tanpa sebab jelas, dan monitoring dasar VPS buat nyusun pola monitoring yang lengkap. Kalau butuh referensi command yang lebih dalem, dokumentasi resminya ada di man page auditd.
Q: Apakah auditd bisa ngedetect rootkit?
Nggak persis. Auditd itu alat perekam, bukan scanner. Dia nggak bakal bilang ‘ini rootkit’. Tapi hampir semua rootkit ngeubah file sistem (ld.so.preload, crontab, binary), dan perubahan itu pasti ke-rekam. Jadi dia nggak nangkep malware-nya, tapi nangkep jejak perubahannya. Kombinasi auditd + AIDE (checksum file) + EDR/antivirus itu pola yang paling sehat.
Q: Bedanya auditd sama AIDE apa sih?
AIDE ngitung hash file terus ngebandingin sama baseline, biasanya dijadwalin tiap malam. Auditd real-time. Analoginya: AIDE bilang ‘ini file udah berubah sejak kemarin malam’, auditd bilang ‘ini file keubah jam segini sama proses ini’. Dua-duanya saling melengkapi, bukan pengganti.
Q: -e 2 immutable itu, gimana caranya mau diubah kalau kepepet?
Tanpa reboot, satu-satunya jalan adalah boot ke single-user mode atau inject init=/bin/bash lewat bootloader. Makanya selalu pasang -e 2 di paling akhir setelah rules final. Jangan eksperimen di production yang lagi jalan.
Q: Seberapa gede sih impact performa auditd?
Kalau rules-nya waras (cuma watch file sensitif, nggak watch direktori gede), impact-nya nggak kerasa, di bawah 1% CPU. Yang bikin berat itu rules yang nge-log semua eksekusi atau semua akses baca. Mulai dari kecil, pantau auditctl -s, tambah pelan-pelan.
Sebelum nutup artikel ini, pastiin kamu udah kelar lima hal: install dan enable auditd, tulis rules integrity di /etc/audit/rules.d/audit.rules, load pake augenrules terus verifikasi dengan auditctl -l, set rotasi di auditd.conf, dan tes satu perubahan file terus pastiin muncul di ausearch. Lima-lima hijau? Case closed. Done.