Tutorial Audit Keamanan Runtime Server Linux Pakai eBPF dan Tracee
Poin Kunci Artikel Ini:
- Kernel Linux versi 5.4 atau versi yang lebih baru (direkomendasikan versi 5.8+ yang mendukung fungsi BTF / BPF Type Format).
- Arsitektur perangkat keras x86_64 atau aarch64 (ARM64).
- Container runtime seperti Docker, Containerd, atau CRI-O yang sudah terkonfigurasi.
1. Vektor Serangan Runtime Linux dan Keterbatasan Sistem Log Tradisional
Lanskap ancaman keamanan pada server Linux telah bergeser dari sekadar eksploitasi layanan publik statis menjadi teknik pasca-eksploitasi (post-exploitation) yang canggih dan sulit terdeteksi. Penyerang modern beroperasi tanpa menyentuh piringan (disk) untuk menghindari sistem antivirus konvensional. Mereka memanfaatkan teknik fileless malware melalui sistem pemanggilan kernel memfd_create, melakukan pembacaan memori anonim, melancarkan eksploitasi injeksi proses lewat ptrace, serta mengeksekusi teknik eskalasi hak akses pada namespace container.
Sistem pengawasan dan audit tradisional seperti syslog, rsyslog, maupun auditd memiliki kelemahan struktural mendasar saat dihadapkan pada skenario serangan runtime real-time ini:
- Overhead Performa dan Latensi Eksekusi: Daemon
auditdbekerja secara sinkron di user space. Setiap kali syscall dicatat, terjadi perpindahan konteks (context switching) dari kernel space ke user space. Pada server berbeban I/O atau CPU tinggi, mekanisme ini menimbulkan hambatan (bottleneck) performa serta peningkatan latensi aplikasi yang amat signifikan. - Kerentanan Terhadap Manipulasi (Tampering): Penyerang yang berhasil mendapatkan akses akun root dapat mematikan layanan
auditd, mengosongkan aturan audit (audit rules), atau menghapus log lokal sebelum mekanisme forwarding sempat mengunggah data ke log collector terpusat. - Kebutaan Konteks Kontainer (Container-Unaware): Sub-sistem audit konvensional mencatat event hanya berbasis Process ID (PID) host. Ketika aplikasi berjalan di dalam container Docker atau pod Kubernetes, log tradisional gagal mengidentifikasi secara otomatis nama container, ID container, namespace, maupun metadata namespace terkait tanpa pengolahan skrip tambahan yang rumit.
- Latensi Deteksi (Batch Logging Delay): Log berbasis berkas umumnya ditulis dan dibaca secara berkala (batch). Jeda waktu beberapa detik antara eksekusi perintah berbahaya dan pemrosesan log oleh sistem SIEM memberikan ruang bagi penyerang untuk merusak sistem atau menghapus jejak audit.
Teknologi eBPF (Extended Berkeley Packet Filter) memecahkan keterbatasan ini secara fundamental. eBPF memungkinkan program khusus dieksekusi secara aman di dalam kernel Linux tanpa perlu mengubah kode sumber kernel atau memuat modul kernel eksternal (Loadable Kernel Module / LKM) yang berisiko menyebabkan kegagalan sistem (kernel panic). eBPF bertindak sebagai virtual machine sandboxed di tingkat kernel yang menyajikan event runtime berlatensi rendah, berkinerja tinggi, dan tahan terhadap manipulasi dari user space.
| Kriteria Evaluasi | Syslog / Auditd Tradisional | eBPF (Tracee) |
|---|---|---|
| Ruang Eksekusi Audit | User Space (Melalui Interrupt/Syscall) | Kernel Space (Sandboxed VM) |
| Dampak Performa Sistem | Tinggi (Bottleneck I/O & Context Switch) | Sangat Rendah (JIT Compiled, Zero Copy) |
| Dukungan Konteks Container | Terbatas (Perlu Pemetaan Host PID Manual) | Native (Container ID, Namespace, Pod) |
| Resistensi Peretasan Root | Rendah (Dapat Dimatikan oleh Root User) | Tinggi (Terisolasi di Tingkat Kernel) |
| Tingkat Presisi Log | Teks Terstruktur / File Log Flat | Event Real-Time Terstruktur JSON / Binary |
2. Arsitektur Tracee eBPF dan Konfigurasi Deteksi Syscall
Tracee merupakan perangkat lunak keamanan runtime berbasis eBPF open-source yang dikembangkan oleh Aqua Security. Perangkat ini mencegat (intercept) event sistem dan syscall pada kernel Linux secara real-time, lalu memenrich data mentah tersebut dengan metadata container sebelum meneruskannya ke mesin analisis.
Prasyarat Lingkungan Server
Sebelum memasang Tracee, pastikan server Linux Anda memenuhi persyaratan teknis berikut:
- Kernel Linux versi 5.4 atau versi yang lebih baru (direkomendasikan versi 5.8+ yang mendukung fungsi BTF / BPF Type Format).
- Arsitektur perangkat keras x86_64 atau aarch64 (ARM64).
- Hak akses administrasi berupa izin root atau kepemilikan capability
CAP_SYS_ADMINdanCAP_BPF. - Container runtime seperti Docker, Containerd, atau CRI-O yang sudah terkonfigurasi.
Untuk memverifikasi apakah kernel server Anda mendukung fitur BTF (BPF Type Format), jalankan perintah berikut pada terminal:
ls -l /sys/kernel/btf/vmlinuxKehadiran file vmlinux menunjukkan bahwa kernel mendukung arsitektur CO-RE (Compile Once โ Run Everywhere). Ini memungkinkan Tracee langsung beroperasi menggunakan pustaka eBPF pre-compiled tanpa memerlukan instalasi kompiler lokal seperti Clang atau LLVM dan header kernel yang berat.
Panduan Menjalankan Tracee Menggunakan Container Docker
Metode pemasangan paling bersih dan efisien untuk lingkungan audit adalah menggunakan image container resmi Aqua Security:
docker run --name tracee --rm -it \
--privileged \
-v /proc:/proc:ro \
-v /boot:/boot:ro \
-v /lib/modules:/lib/modules:ro \
-v /sys/kernel/debug:/sys/kernel/debug:ro \
-v /etc/os-release:/etc/os-release:ro \
-v /var/run/docker.sock:/var/run/docker.sock \
aquasec/tracee:latest \
--trace event=execve,memfd_create,ptracePenjelasan opsi pemetaan mount di atas:
-v /proc:/proc:ro: Memberikan akses pembacaan tabel proses host agar Tracee dapat mengaitkan PID host dengan proses terkait.-v /sys/kernel/debug:/sys/kernel/debug:ro: Mengizinkan akses ke debugfs untuk memasang kprobe dan tracepoint eBPF.-v /var/run/docker.sock:/var/run/docker.sock: Menghubungkan Tracee ke daemon Docker guna mengambil metadata nama dan ID container secara langsung.
Pemantauan Syscall Kritis Berisiko Tinggi
Penyerang umumnya mengandalkan syscall spesifik untuk menembus dan mengeksploitasi sistem. Berikut perintah Tracee untuk mengisolasi dan mendeteksi syscall kritis secara rinci:
docker run --name tracee-audit --rm -it \
--privileged \
-v /proc:/proc:ro \
-v /sys/kernel/debug:/sys/kernel/debug:ro \
-v /var/run/docker.sock:/var/run/docker.sock \
aquasec/tracee:latest \
--trace event=memfd_create,ptrace,security_file_open \
--trace security_file_open.args.pathname=/etc/shadowFungsi pemantauan pada contoh perintah di atas mencakup tiga indikator utama:
memfd_create: Menangkap pemanggilan alokasi blok memori anonim. Syscall ini sering disalahgunakan oleh fileless malware untuk menyimpan dan mengeksekusi payload biner langsung dari RAM tanpa menyentuh disk.ptrace: Memantau percobaan suatu proses untuk mengamati atau mengontrol proses lain. Teknik ini lazim digunakan dalam serangan pembacaan memori credential (credential dumping) dan process injection.security_file_opendengan kriteriapathname=/etc/shadow: Mendeteksi setiap akses pembacaan atau penulisan ke berkas sensitif yang menyimpan hash kata sandi pengguna sistem.
Simulasi Serangan dan Verifikasi Output Real-Time
Buka sesi terminal sekunder pada server, lalu jalankan perintah pembacaan file kata sandi rahasia untuk memicu event:
cat /etc/shadowSecara instan, layar terminal yang menjalankan Tracee akan menampilkan output terstruktur yang mencatat rincian eksekusi:
TIME UID COMM PID TID EVENT ARGS
14:22:01.104211 0 cat 41203 41203 security_file_open pathname: /etc/shadow, flags: O_RDONLY3. Pengolahan Log JSON, Signatur Ancaman, dan Otomatisasi Respons Mitigasi
Tampilan teks pada terminal tidak dapat memfasilitasi kebutuhan respon insiden otomatis pada infrastruktur skala besar. Log audit harus dialirkan dalam format terstruktur seperti JSON ke dalam saluran pengolahan terpusat.
Pengaliran Log Terstruktur Format JSON
Untuk mengarahkan output Tracee ke berkas log terpusat atau saluran pipa (pipe), gunakan argumen keluaran format JSON:
docker run --name tracee-json --rm \
--privileged \
-v /proc:/proc:ro \
-v /sys/kernel/debug:/sys/kernel/debug:ro \
aquasec/tracee:latest \
--output format:json \
--output option:stack-addresses \
--trace scope:comm!=tracee \
> /var/log/tracee_events.json &Pemanfaatan Mesin Aturan Deteksi (Tracee Signatures)
Tracee dilengkapi dengan mesin aturan (Rules Engine) berkinerja tinggi yang mampu mencocokkan serangkaian event syscall mentah dengan pola perilaku ancaman berisiko tinggi. Beberapa indikator bawaan yang didukung antara lain:
- Standard Elevation of Privilege Detected: Mendeteksi eksploitasi privilege escalation pada atribut kredo proses.
- Fileless Execution Detected via memfd_create: Menandai pembuatan eksekusi biner yang terisolasi sepenuhnya di dalam RAM.
- Container Escape Attempt Detected via cgroups: Mencegat percobaan pembongkaran isolasi cgroup oleh aplikasi dalam container.
- Kernel Module Loading Detected: Mengawasi pemasangan modul kernel eksternal (LKM) yang berpotensi merupakan rootkit.
Untuk mengarahkan deteksi khusus pada aturan signatur ini, jalankan perintah berikut:
docker run --name tracee-rules --rm -it \
--privileged \
-v /proc:/proc:ro \
-v /sys/kernel/debug:/sys/kernel/debug:ro \
-v /var/run/docker.sock:/var/run/docker.sock \
aquasec/tracee:latest \
--trace traceeSkrip Daemon Automasi Mitigasi Ancaman (Auto-Kill Process)
Pengamanan runtime dapat ditingkatkan dengan membuat skrip respons otomatis yang mendengarkan keluaran JSON Tracee dan menghentikan proses jahat secara instan (SIGKILL) begitu ancaman terverifikasi terdeteksi.
Buat berkas Python bernama response_daemon.py dengan konten kode berikut:
import json
import os
import signal
import sys
def handle_event(line):
try:
data = json.loads(line)
event_name = data.get("eventName")
process_id = data.get("processId")
process_name = data.get("processName")
# Deteksi serangan fileless malware via memfd_create
if event_name == "memfd_create" and process_name != "authorized_app":
print(f"[ALERT] Ancaman Terdeteksi: {event_name} oleh PID {process_id} ({process_name})")
# Pengiriman sinyal SIGKILL untuk terminasi instan
os.kill(process_id, signal.SIGKILL)
print(f"[MITIGASI] Proses {process_id} berhasil diterminasi secara otomatis.")
except Exception as e:
pass
if __name__ == "__main__":
for line in sys.stdin:
if line.strip():
handle_event(line)Buka alur pemrosesan data real-time dengan menggabungkan pembacaan log stream dan skrip Python tersebut:
tail -f /var/log/tracee_events.json | python3 response_daemon.py4. Checklist Pengerasan (Hardening) dan Praktik Terbaik Deployment eBPF Production
Mengimplementasikan audit eBPF di lingkungan produksi memerlukan penyesuaian khusus agar pemantauan tidak memicu penurunan performa atau menciptakan celah keamanan baru.
Tabel Panduan Hardening Runtime Linux
| Komponen Hardening | Tindakan Konfigurasi | Tujuan Keamanan & Performa |
|---|---|---|
| Kernel BTF Support | Opsi CONFIG_DEBUG_INFO_BTF=y | Memastikan kernel mendukung portabilitas CO-RE eBPF tanpa kompiler. |
| Akses Subsistem BPF | sysctl kernel.unprivileged_bpf_disabled=1 | Mencegah pengguna non-root memuat program BPF arbitrer ke kernel. |
| Pengerasan BPF JIT | sysctl net.core.bpf_jit_harden=2 | Melindungi JIT compiler dari eksploitasi peretasan Spectre dan JIT spraying. |
| Filtrasi Syscall Target | Batasi pemantauan read/write | Menghindari kejenuhan ring buffer memori eBPF dan lonjakan beban CPU. |
| Batas Sumber Daya | Opsi Docker --memory & --cpus | Mencegah pemakaian resource tak terbatas oleh container auditor. |
Panduan Implementasi Produksi Detailed
- Membatasi Akses Subsistem eBPF: Pastikan pengisian program BPF dibatasi ketat hanya untuk akun privileged. Eksekusi perintah hardening berikut pada server:
sysctl -w kernel.unprivileged_bpf_disabled=1 - Mengaktifkan BPF JIT Hardening: Lindungi instrumen kompilasi JIT di dalam kernel dari manipulasi memori dan teknik JIT spraying:
sysctl -w net.core.bpf_jit_harden=2 - Strategi Filtrasi Event Syscall: Jangan pernah mengamati seluruh event I/O umum (seperti
read,write, ataufstat) secara global tanpa filter domain spesifik. Frekuensi tinggi event tersebut akan meluap pada eBPF ring buffer dan menyebabkan pembacaan event lain terdrop (dropped events). Prioritaskan pemantauan syscall berkategori perubah status sepertiexecve,ptrace,connect,init_module, danmemfd_create. - Arsitektur Log Forwarding Dedicated: Hindari penulisan log JSON Tracee ke disk lokal secara terus-menerus pada server berskala besar. Gunakan perantara log collector berkinerja tinggi seperti Fluentbit atau Vector yang membaca stream langsung dari Unix Domain Socket atau stdout container, lalu teruskan log ke platform SIEM eksternal (Wazuh, Elasticsearch, atau Splunk).
- Isolasi Limit Alokasi Resource Container Tracee: Selalu terapkan kuota alokasi memori dan batas penggunaan CPU pada container Tracee saat mengeksekusi di produksi. Hal ini menjamin bahwa jika terjadi lonjakan event sistem yang ekstrem, container audit tidak akan mengganggu ketersediaan aplikasi bisnis utama:
docker run --memory="512m" --cpus="0.5" ... aquasec/tracee:latest
Kesimpulan
Pendekatan audit log tradisional pada ruang pengguna (user space) sudah tidak memadai lagi untuk mengimbangi kompleksitas serangan runtime Linux modern. Pengintegrasian eBPF bersama Tracee memberikan visibilitas penuh hingga ke lapisan terdalam kernel tanpa mengorbankan stabilitas maupun performa server.
Melalui penerapan pemantauan syscall real-time, pengolahan event terstruktur JSON, serta automasi skrip mitigasi, tim Sysadmin, Security Engineer, dan DevOps dapat mendeteksi serta menghentikan ancaman fileless malware, eskalasi hak akses, dan pelarian container secara instan. Terapkan eBPF sebagai fondasi utama strategi pertahanan berlapis (defense-in-depth) di seluruh lingkungan server Linux Anda.


