Belajar AppArmor - Auditing & Monitoring

#Pendahuluan

Di episode 14 kalian menyadari bahwa AppArmor bisa rapuh — bug di kernel dan parser adalah ancaman nyata. Pertanyaannya sekarang: bagaimana kalian tahu jika konfinasi mulai rusak? Denial yang tidak pernah dibaca, profile yang diam-diam berhenti dimuat, atau pola serangan yang sedang mencoba membobol aplikasi — semua itu hanya bisa terlihat jika ada mata.

Episode ini membangun mata tersebut. Kita akan membaca log denial dari berbagai sumber, mengagregasinya menjadi sinyal yang bisa dipahami, memasang alerting, dan menutup dengan sisi compliance: dokumentasi coverage profile per service dan baseline security review.

#Mengapa Monitoring adalah Bagian dari Konfinasi

Konfinasi tanpa monitoring adalah alarm tanpa suara. Sebuah deny rule yang bekerja berarti ada proses yang mencoba melakukan sesuatu yang dilarang — dan mencoba itu bisa jadi menandakan eksploitasi yang sedang berlangsung. Jika kalian tidak membaca denial, kalian kehilangan sinyal keamanan paling berharga yang dimiliki AppArmor.

Ada tiga tingkat kesadaran yang perlu dibangun:

• Reaktif — membaca log saat ada insiden. Terlambat untuk mencegah, tapi tetap perlu dikuasai.
• Terjadwal — ringkasan denial berkala, misalnya harian. Menangkap tren dan anomali.
• Proaktif — alerting otomatis saat sesuatu yang mencurigakan muncul. Inilah tujuan akhirnya.

#Sumber Log Denial

Denial AppArmor bisa muncul di beberapa tempat, tergantung konfigurasi sistem:

• Kernel ring buffer / journald — journalctl -k menampilkan pesan audit AppArmor dari kernel; cara tercepat di sistem tanpa auditd.
• Syslog — /var/log/syslog atau /var/log/kern.log pada sistem yang memakai rsyslog.
• auditd — /var/log/audit/audit.log jika daemon audit aktif; formatnya paling lengkap untuk kebutuhan compliance.

Semua sumber menyimpan event yang sama, hanya format dan tempatnya berbeda. Mulailah dari journald — ia tersedia di hampir semua sistem modern:

sudo journalctl -k --since "1 hour ago" --grep=apparmor

Perhatikan pola event-nya: apparmor="DENIED" diikuti nama profile, operasi, path, dan nama proses. Pola inilah yang akan kita parse untuk agregasi.

#aa-notify: Ringkasan Denial

aa-notify adalah tool dari apparmor-utils yang menyajikan ringkasan denial tanpa harus membaca log mentah. Ia membaca log, menghitung jumlah denial per profile, dan menampilkan daftar — sempurna untuk laporan berkala.

sudo aa-notify -s 86400

Flag -s mengambil denial dalam rentang detik tertentu. Dengan -v kalian mendapat rincian lebih, dan dengan -f kalian bisa mengarahkannya ke file log tertentu jika ingin memproses sumber non-default. Untuk sistem dengan auditd, aa-notify secara otomatis memakai /var/log/audit/audit.log; untuk sistem lain ia membaca syslog atau journald.

#Agregasi Denial

Log mentah berisi ribuan baris yang berulang. Nilai sebenarnya baru muncul setelah diagregasi: profile mana yang paling sering di-deny, path mana yang paling sering diburu, dan apakah ada profil baru yang tiba-tiba muncul. Satu baris shell sudah cukup untuk menggambarkan gambaran besarnya:

sudo journalctl -k --since "24 hours ago" \
  | grep 'apparmor="DENIED"' \
  | sed -E 's/.*profile="([^"]+)".*/\1/' \
  | sort | uniq -c | sort -rn | head -20

Baca hasilnya dengan pertanyaan kritis: mengapa profile ini menghasilkan banyak denial? Apakah ada deny noise yang seharusnya ditangani dengan aturan deny eksplisit (episode 12)? Atau apakah ada path sensitif yang sedang dicoba diakses — sebuah tanda serangan? Untuk agregasi lebih dalam, bangun pipeline yang mengelompokkan per kombinasi profile, operasi, dan path, lalu simpan hasilnya sebagai metrik.

#Alerting Berbasis journald dan auditd

Ringkasan harian menangkap masalah setelah terjadi. Untuk masalah yang membutuhkan reaksi cepat — misalnya profile baru mulai diblokir secara massal, atau deny muncul untuk path sensitif — pasang alerting otomatis. Pendekatan paling sederhana: unit systemd yang menjalankan aa-notify setiap hari, dikombinasikan dengan service untuk mengirim hasilnya:

Unit systemd digest harian AppArmor

# /etc/systemd/system/aa-deny-digest.service
[Unit]
Description=AppArmor daily denial digest
 
[Service]
Type=oneshot
ExecStart=/usr/bin/aa-notify -s 86400 -f /var/log/audit/audit.log

Timer untuk menjadwalkan digest

# /etc/systemd/system/aa-deny-digest.timer
[Unit]
Description=Run AppArmor digest daily
 
[Timer]
OnCalendar=daily
 
[Install]
WantedBy=timers.target

Untuk alerting real-time, aktifkan daemon audit (auditd) dan kombinasikan dengan tool yang membaca audit.log secara kontinu — misalnya memfilter event AUDIT_APPARMOR_DENIED dengan ausearch atau meneruskannya ke pipeline log dan SIEM. Ambang alert yang baik biasanya kombinasi dua sinyal: kemunculan deny pada path sensitif, atau lonjakan volume denial yang tiba-tiba pada satu profile.

sudo ausearch -m 1400 -ts today

#Compliance: Dokumentasi Coverage per Service

Bagian yang sering diabaikan hingga audit datang: dokumentasi. Regulatory framework dan kebijakan internal hampir selalu menanyakan "service mana yang terkonfinasi, dengan profile apa, dan dalam mode apa?". Tanpa catatan, jawabannya adalah pekerjaan rekonstruksi di tengah tekanan.

Bangun tabel coverage sederhana yang diperbarui setiap ada perubahan:

Dokumentasi ini bukan sekadar kepatuhan — ia adalah peta yang memberitahu kalian di mana konfinasi lemah (mode complain), di mana pengujian belum selesai, dan service mana yang masih belum punya profile sama sekali.

#Baseline Security Review

Baseline adalah snapshot kondisi sistem pada titik waktu tertentu, yang dijadikan pembanding di masa depan. Untuk AppArmor, snapshot paling berguna adalah output aa-status — daftar profile, mode, dan proses yang terkonfinasi:

sudo aa-status > /var/lib/apparmor/aa-status-baseline.txt
sudo aa-status > /tmp/aa-status-now.txt
diff /var/lib/apparmor/aa-status-baseline.txt /tmp/aa-status-now.txt

Jadikan snapshot ini bagian dari review berkala. Perubahan yang perlu ditanyakan: ada profile baru? Ada profile yang berubah mode dari enforce ke complain? Ada proses yang tadinya terkonfinasi kini berjalan unconfined? Ketiganya adalah penanda bahwa sesuatu berubah — dan perubahan tanpa keputusan adalah awal dari regresi keamanan.

#Penutup

Pada episode ini kalian telah membangun pengawasan penuh terhadap konfinasi: membaca log denial dari journald, syslog, dan auditd; mengagregasinya menjadi sinyal dengan aa-notify dan satu baris pipeline; memasang alerting berbasis systemd timer dan auditd; serta menetapkan baseline compliance berupa tabel coverage per service dan snapshot aa-status yang di-diff secara berkala.

Inti yang harus kalian bawa:

• Denial adalah sinyal keamanan, bukan hanya sampah log — baca dan pahami.
• aa-notify memberi ringkasan; agregasi memberi gambaran besar; alerting memberi reaksi cepat.
• Alert untuk anomali, bukan untuk volume normal.
• Dokumentasikan coverage per service — ini jawaban untuk audit sekaligus peta kelemahan kalian.
• Baseline aa-status yang di-diff secara rutin mendeteksi regresi sejak dini.

Di episode 16 berikutnya kita zoom out dari perangkat lunak ke kernel: di mana posisi AppArmor dalam Linux Security Module stack, bagaimana ia berinteraksi dengan Yama dan Landlock, konfigurasi CONFIG_SECURITY_APPARMOR, serta lapisan-lapisan berbeda yang diisi seccomp, capabilities, dan LSM. Sampai jumpa di episode 16!