Belajar Seccomp - Audit & Monitoring Syscall

#Pendahuluan

Di episode 14 kalian belajar bahwa filter yang tampak kuat bisa lemah — dan bahwa update serta review berkala adalah satu-satunya obat. Tetapi ada asumsi yang menggelitik di sepanjang diskusi itu: bahwa kalian bisa melihat apa yang terjadi pada filter. Kenyataannya, bagi kebanyakan tim, seccomp adalah kotak hitam. Filter terpasang, denial terjadi, tetapi tidak ada yang tahu kapan, mengapa, dan syscall mana yang diserang.

Inilah episode yang membuka kotak itu. Audit & monitoring syscall mengubah seccomp dari fitur pasif menjadi lapisan pertahanan yang terobservasi — seperti memasang kamera di gedung yang sudah dikunci. Dua manfaat langsungnya: kalian bisa membuktikan filter bekerja, dan kalian bisa mendeteksi percobaan serangan sebelum berhasil.

Pada episode ini kita akan membahas tiga hal: audit framework Linux untuk mencatat syscall yang terjadi, mekanisme logging seccomp lewat SECCOMP_RET_LOG dan journald, serta telemetri — denial rate, alerting, dan profiling syscall workload dengan strace -c dan bpftrace. Mari mulai.

#Pembahasan Utama

#Tiga Alasan Mengamati Syscall

Sebelum membahas tool-nya, mari tetapkan tujuan observasi. Ada tiga hal berbeda yang bisa diamati, dan masing-masing menjawab pertanyaan berbeda:

1. Verifikasi — apakah filter yang terpasang menegakkan apa yang tertulis? Observasi denial memberi bukti bahwa syscall tertentu benar-benar diblokir.
2. Deteksi — apakah ada yang mencoba memanggil syscall yang diblokir? Burst denial dari sebuah proses adalah alarm awal percobaan serangan.
3. Profiling — syscall apa yang sebenarnya dipanggil workload? Data ini menjadi bahan utama mendesain filter yang tepat (episode 17).

Ketiga tujuan ini membutuhkan alat yang berbeda — audit framework untuk dua tujuan pertama, strace/bpftrace untuk tujuan ketiga.

#Audit Framework Linux

Linux memiliki framework audit bawaan: daemon auditd mencatat kejadian sistem, dan auditctl mengatur aturannya. Syscall bisa diaudit dengan aturan berbasis syscall name — misalnya mencatat setiap open dan execve:

sudo auditctl -a always,exit -F arch=b64 -S open,execve
sudo auditctl -l

Perhatikan bagian perintah -a always,exit: artinya selalu catat pada saat syscall selesai. -F arch=b64 membatasi pada arsitektur 64-bit agar aturan tidak ganda dieksekusi, dan -S open,execve memilih syscall yang dipantau. Output auditctl -l memperlihatkan daftar aturan aktif.

Membaca hasilnya memakai ausearch untuk menyaring dan aureport untuk ringkasan:

sudo ausearch -sc execve -ts today
sudo aureport --syscall --summary

ausearch -sc execve menampilkan seluruh catatan execve sejak hari ini — berguna untuk melihat program apa saja yang dijalankan. aureport --syscall --summary menghitung frekuensi tiap syscall, memberi gambaran profil syscall sistem dalam satu layar.

#SECCOMP_RET_LOG: Mencatat Tanpa Menolak

Seccomp punya return action yang dirancang khusus untuk observasi: SCMP_ACT_LOG. Berbeda dengan SCMP_ACT_ERRNO yang menolak syscall, LOG mencatat syscall ke kernel log dan tetap mengizinkannya berjalan. Ini adalah mode uji yang sempurna: kalian bisa melihat apa yang akan diblokir sebelum benar-benar memblokir.

{
  "defaultAction": "SCMP_ACT_LOG",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["mount", "ptrace", "kexec_load"],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 1
    }
  ]
}

Pola di atas menarik: defaultnya LOG — semua syscall dicatat; syscall yang benar-benar berbahaya tetap ERRNO — diblokir langsung. Dengan begitu, ketika kalian memindahkan filter ke production, seluruh deny-list sudah teruji selama fase LOG berjalan.

Sistem juga menyediakan kontrol global: /proc/sys/kernel/seccomp/actions_logged menentukan aksi mana yang menghasilkan catatan kernel log. Menambahkan errno ke daftar membuat setiap penolakan tercatat:

echo "kill-process,kill-thread,errno" > /proc/sys/kernel/seccomp/actions_logged
journalctl -k | grep -i seccomp

Setelah itu, setiap deny muncul di journald — journalctl -k | grep -i seccomp — lengkap dengan konteks proses yang mencoba memanggil syscall terlarang.

#Deteksi Penolakan: Membaca Tanda Serangan

Denial adalah sinyal paling menarik bagi tim keamanan. Ketika filter bekerja normal, deny jarang terjadi. Ketika deny tiba-tiba melonjak — atau muncul dari proses yang biasanya bersih — itu tanda sesuatu: aplikasi yang berubah perilaku, atau penyerang yang sedang menguji filter.

sudo ausearch -m SECCOMP --start today -i

Setiap denial menghasilkan audit record bertipe SECCOMP yang memuat proses, syscall, dan aksi yang dikembalikan. Pola yang patut dicurigai: deny berulang pada syscall yang sama dari proses yang sama dalam waktu singkat — persis pola "menggoyang pintu untuk mencari celah".

#Telemetri: Denial Rate, Metrik, dan Alerting

Observasi per insiden tidak cukup di skala produksi. Kalian butuh telemetri: deny rate per proses, deny count per syscall, dan alerting ketika angka melonjak melewati baseline. Fondasinya bisa dibangun sederhana dengan mem-parsing audit log:

sudo ausearch -m SECCOMP --start today -i \
  | grep -o 'syscall=[a-z0-9_]*' \
  | sort | uniq -c | sort -rn

Pipeline ini mengubah ribuan baris log menjadi satu baris per syscall dengan jumlah penolakannya — data yang bisa diekspor sebagai metrik (misalnya lewat node exporter textfile) dan di-alert ketika naik drastis. Prinsip alerting-nya sama dengan metrik lain: tetapkan baseline dulu saat sistem sehat, lalu alert ketika deny rate menyimpang jauh dari baseline — bukan saat deny rate sama dengan nol, karena alert yang tidak pernah berbunyi adalah alarm yang mati.

#Profiling Workload: strace -c dan bpftrace

Tujuan ketiga observasi adalah memahami profil syscall workload — bahan baku desain filter di episode 17. Dua alat utama:

strace -c menghitung jumlah dan waktu per syscall selama workload berjalan. Ia memakai ptrace, jadi cocok untuk sesi debugging dan staging:

strace -c -f /usr/sbin/nginx -g 'daemon off;'

Outputnya berupa tabel syscall dengan kolom calls (jumlah panggilan), errors, dan time — gambaran langsung syscall mana yang dominan. Data inilah yang kelak menjadi allow-list.

bpftrace memberi hasil yang sama tanpa mengubah aplikasi sama sekali — bekerja di level tracepoint kernel, sehingga aman dipakai di production:

bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm, syscall] = count(); }'

Perintah bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm, syscall] = count(); }' mengumpulkan hitungan syscall per nama proses. Menekan Ctrl-C mencetak histogram yang menunjukkan syscall apa yang dipanggil workload di lingkungan nyata.

#Kesalahan Umum

1. Aturan audit terlalu lebar. Mengaudit semua syscall tanpa filter membuat log membengkak dan sistem melambat. Scope aturan pada syscall yang ingin kalian amati.

2. Memblokir tanpa memantau. Filter tanpa observasi adalah kepercayaan buta — denial pertama yang kalian lihat bisa jadi setelah serangan berhasil. Pasang monitoring bersamaan dengan filter.

3. Mengaktifkan LOG di mana-mana. SCMP_ACT_LOG pada workload yang memanggil jutaan syscall per detik membanjiri log. Batasi LOG pada syscall yang memang dicurigai, dan matikan setelah fase uji selesai.

4. Alert tanpa baseline. Alert yang dipicu oleh deny rate normal membuat tim mati rasa. Bangun baseline di kondisi sehat, lalu alert pada penyimpangan.

#Penutup

Pada episode 15 ini kalian mengubah seccomp dari kotak hitam menjadi lapisan yang terobservasi. Audit framework mencatat syscall lewat auditctl dan dibaca dengan ausearch; SECCOMP_RET_LOG memungkinkan observasi tanpa memblokir, dan /proc/sys/kernel/seccomp/actions_logged membuat denial tercatat di journald; telemetri denial rate memberi sinyal alarm; dan strace -c plus bpftrace membuka profil syscall workload.

Poin kunci yang perlu kalian bawa:

• Observasi seccomp melayani tiga tujuan: verifikasi, deteksi, dan profiling.
• SECCOMP_RET_LOG adalah jembatan aman antara uji dan produksi.
• Burst denial adalah alarm percobaan serangan — tapi butuh baseline untuk membacanya.
• Profiling syscall adalah bahan baku desain filter yang baik.

Sejauh ini kita selalu menyebut filter "dipasang" tanpa pernah membahas bagaimana tepatnya filter itu sampai ke kernel. Di episode 16 berikutnya kita akan menyelam ke kernel interface & prctl — perbedaan prctl dengan syscall seccomp, prasyarat no_new_privs, sifat filter yang aditif dan diwariskan pada fork serta exec, hingga interaksinya dengan user namespaces. Sampai jumpa!