Belajar SELinux - Audit, Monitoring & Incident Response

#Pendahuluan

Di episode 14 kalian mengunci sistem: domain dikonfinasi, boolean dipangkas, baseline CIS dipasang. Kini muncul paradoks yang sering diremehkan: semakin ketat policy, semakin banyak denial yang dihasilkan — dan jika denial itu tidak dipantau, kalian tidak akan pernah tahu mana yang bug konfigurasi dan mana yang serangan. Seorang attacker yang dibatasi SELinux meninggalkan jejak; deny yang tidak tercatat adalah jejak yang hilang.

Episode ini mengubah log SELinux dari sekadar file menjadi sistem observasi dan respons. Kita konfigurasi auditd, baca jejak dengan ausearch dan aureport, bangun alert denial real-time, lalu kita turun ke skenario incident response: menganalisis rantai denial, forensik konteks yang berubah, dan mitigasi cepat yang tidak mematikan produksi — dari permissive berskala sampai fix policy permanen.

#Pembahasan Utama

#AuditD dan Jalur Denial SELinux

Semua keputusan SELinux — termasuk setiap denied — diteruskan ke Linux Audit subsystem, yang dikelola oleh daemon auditd. Denial AVC tidak ditulis langsung oleh kernel ke file biasa; ia dikirim sebagai event audit, dan auditd menuliskannya ke /var/log/audit/audit.log. Inilah alasan auditd menjadi komponen wajib dalam stack SELinux produksi.

Pastikan daemonnya aktif:

systemctl enable --now auditd
auditctl -s

enabled 1
failure 1
pid 1827
rate_limit 0
backlog_limit 64
lost 0

Perhatikan baris failure 1 — audit dikonfigurasi agar panik saat gagal menulis, bukan diam-diam membuang event. Ini bukan kebetulan; dalam incident response, kehilangan log lebih buruk daripada downtime.

#Konfigurasi dan Rules auditctl

Dua hal yang perlu kalian atur: kapasitas (di /etc/audit/auditd.conf — max_log_file, num_logs, flush) dan rules (apa yang di-audit). Rules AVC tidak perlu ditulis manual — kernel selalu mencatat semua keputusan SELinux. Yang perlu kalian tambahkan adalah rules untuk objek sensitif non-SELinux, misalnya file konfigurasi kritikal:

auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config
auditctl -w /etc/passwd -p wa -k user_accounts
auditctl -l

Bentuk -w (watch) -p (permission) -k (key) ini adalah bahasa audit standar: setiap akses write atau attribute berubah ke file yang diawasi tercatat dengan label sshd_config. Untuk persistensi di seluruh reboot, rules tersebut ditulis ke file /etc/audit/rules.d/*.rules — bukan hanya dieksekusi live seperti di atas.

#Mencari Jejak dengan ausearch

Denial SELinux bisa dibaca langsung dari log audit. Perintah intinya adalah ausearch — penelusur event audit dengan filter yang sangat ekspresif:

ausearch -m avc -ts recent

time->Fri Aug  7 14:03:11 2026
type=AVC msg=audit(1754586191.123:4567): avc:  denied  { read } for
pid=5210 comm="httpd" name="index.php"
scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:home_root_t:s0 tclass=file

Variasi yang paling sering dipakai dalam investigasi:

• ausearch -m avc -ts today — seluruh denial hari ini.
• ausearch -m avc -i -ts today — -i menginterpretasi nilai numerik menjadi teks (UID, nama).
• ausearch -m avc -ui 1001 -ts today — denial milik user tertentu.
• ausearch -m avc -c nginx -ts today — denial milik proses dengan nama tertentu.

Jika kalian tidak yakin sebuah denial penting atau sekadar noise, audit2why memberi penjelasan berbahasa manusia tentang kenapa ditolak dan langkah perbaikannya:

ausearch -m avc -ts recent | audit2why

#Ringkasan dengan aureport

ausearch menjawab "detail apa", aureport menjawab "gambaran besar apa" — ringkasan agregat. Dalam peran incident responder, ini langkah pertama untuk membangun konteks sebelum menyelam ke detail:

aureport -a -ts today

Number of AVC denials: 142
Number of MAC events: 142
Number of failed syscalls: 31

Pola 142 denial yang semuanya berasal dari satu domain di jam yang sama biasanya menandakan satu akar masalah (misal label salah), bukan serangan terdistribusi. aureport mengubah tumpukan 142 baris log menjadi satu baris kesimpulan — itulah nilainya di momen tekanan tinggi.

#Alert Real-time: dari Journal ke SIEM

Denial yang baru terlihat saat kalian buka file bukanlah monitoring. Ada dua jalur alerting yang praktis:

Jalur 1 — journald. Event audit juga diteruskan ke systemd journal. Ini cara paling cepat untuk alert berbasis sistem:

journalctl _TRANSPORT=audit -f | grep -i 'avc:  denied'

Jalur 2 — SIEM/aggregator. Untuk produksi, kirim event audit ke platform log terpusat (misal Elasticsearch, Loki, atau log aggregator tim kalian). Filter di sisi penerima: type=AVC dan result=denied adalah sinyal default yang layak masuk pipeline alert. Satu baris log avc: denied adalah signal; seratus baris dalam satu menit dari satu source adalah indikator.

#Incident Response: Menganalisis Rantai Denial

Sekarang skenario: tim kalian menerima alert — puluhan avc: denied dalam 2 menit dari proses httpd, user ID yang tidak biasa. Jangan langsung men-allow. Susun pertanyaan dalam urutan:

1. Siapa dan apa — ausearch -m avc -ts today -ui 48 menunjukkan denial dari UID 48 (akun apache). Tapi ada yang janggal: proses itu meminta execve dari direktori /tmp.
2. Kapan dan seberapa sering — aureport -a -ts today menunjukkan lonjakan denial dimulai pukul 14:00, bersamaan dengan spike CPU.
3. Apa konteks target — scontext=...:httpd_t:s0, tcontext=...:home_root_t:s0. Sebuah proses httpd_t mencoba membaca file di direktori home — tidak normal untuk workload web.

Rantai denial ini adalah narasi: attacker sudah mengeksekusi sesuatu di dalam proses web server (via kerentanan aplikasi), dan upayanya untuk menyentuh file user diblokir SELinux. Itu bukan bug — itu garis pertahanan yang bekerja. Langkah berikutnya adalah forensik konteks, bukan menulis aturan.

#Forensik: Konteks yang Berubah

Bagian paling penting dari investigasi SELinux adalah memeriksa apakah ada yang mengubah labeling — karena konteks yang diubah adalah jejak tangan attacker. Periksa dalam urutan ini:

ls -lZ /var/www/html
semanage boolean -l -C
semanage permissive -l

semanage permissive -l
httpd_t

Perhatikan temuan terakhir: ada domain httpd_t yang dijadikan permissive — sebelumnya, di episode 14, tidak ada. Ada yang mengeksekusi semanage permissive -a httpd_t di mesin ini, atau attacker mengubahnya. Ditambah restorecon -n -R -v /var/www yang menunjukkan banyak file di luar label seharusnya, gambaran forensik menjadi jelas: label diubah, permissive diaktifkan, denial mereda — pola klasik penyerang yang ingin mematikan alarm.

#Mitigasi Cepat: Permissive Berskala, lalu Fix Policy

Saat produksi turun dan tim butuh akses segera, godaan terbesarnya adalah setenforce 0 — matikan SELinux seluruhnya. Jangan. Mitigasi yang benar adalah permissive berskala: matikan enforcement hanya untuk domain yang bermasalah, biarkan sisanya terkunci:

semanage permissive -a httpd_t

Service langsung berjalan, tapi semua domain lain tetap enforcing. Sekarang ada waktu untuk menyelesaikan akar masalah dengan tenang:

1. Identifikasi — ausearch -m avc -ts recent | audit2why untuk memahami aturan yang hilang.
2. Bangun fix — ausearch -m avc -ts recent | audit2allow -M httpd_fix menghasilkan modul httpd_fix.te; review setiap baris sebelum dipakai.
3. Uji — pasang modul semodule -i httpd_fix.pp saat domain masih permissive; pastikan app berjalan dan tidak ada denial baru.
4. Kunci lagi — semanage permissive -d httpd_t mengembalikan enforcement penuh.

Urutan ini memastikan setiap langkah reversible dan diaudit. Dan catat aturan emas incident response SELinux: permissive adalah triase, bukan obat. Jika triase dibiarkan permanen, garis pertahanan terakhir kalian mati diam-diam — dan persis itu yang dicari attacker.

#Penutup

Pada episode 15 ini kalian telah membangun seluruh jalur observasi dan respons: mengaktifkan dan mengonfigurasi auditd (auditctl -s, auditctl -w -p -k), menelusuri denial dengan ausearch -m avc dalam berbagai filter, merangkum gambaran dengan aureport -a, membangun alert real-time lewat journald atau SIEM, menganalisis rantai denial sebagai narasi serangan, melakukan forensik pada konteks yang berubah (semanage permissive -l, semanage boolean -l -C), dan menjalankan mitigasi cepat dengan permissive berskala sebelum memasang fix policy permanen.

Inti yang harus kalian bawa:

• Denial SELinux adalah sinyal — buat pipeline agar tidak pernah terlewat.
• ausearch untuk detail, aureport untuk gambaran; gunakan keduanya berurutan.
• Rantai denial yang runtut adalah narasi serangan, bukan kumpulan baris random.
• Periksa konteks yang berubah dan permissive yang mengendap — itu jejak tangan.
• Permissive berskala adalah triase; fix policy adalah obat; jangan balik urutannya.

Observasi dan respons sekarang menyala. Tapi ada satu lapisan yang selama ini kita pakai tanpa melihat cara kerjanya: bagaimana sebenarnya SELinux mengomunikasikan keputusan antara kernel dan userspace? Di episode 16 berikutnya kita membuka kap mesin — selinuxfs & Runtime Inspection: membedah /sys/fs/selinux, interaksi userspace-kernel, verifikasi runtime dengan matchpathcon, dan inspeksi live dengan seinfo serta semanage. Sampai jumpa di episode 16!