AizuDemy

Tutorial Audit Keamanan Runtime Server Linux Pakai eBPF dan Tracee

Tutorial Audit Keamanan Runtime Server Linux Pakai eBPF dan Tracee
๐ŸŽง
Dengarkan Artikel Ini
Suara AI Otomatis โ€ข 9 mnt baca baca
โšก TL;DR

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.
๐Ÿ“‹ Daftar Isi Materi Tutup โ–ด

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 auditd bekerja 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 EvaluasiSyslog / Auditd TradisionaleBPF (Tracee)
Ruang Eksekusi AuditUser Space (Melalui Interrupt/Syscall)Kernel Space (Sandboxed VM)
Dampak Performa SistemTinggi (Bottleneck I/O & Context Switch)Sangat Rendah (JIT Compiled, Zero Copy)
Dukungan Konteks ContainerTerbatas (Perlu Pemetaan Host PID Manual)Native (Container ID, Namespace, Pod)
Resistensi Peretasan RootRendah (Dapat Dimatikan oleh Root User)Tinggi (Terisolasi di Tingkat Kernel)
Tingkat Presisi LogTeks Terstruktur / File Log FlatEvent 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_ADMIN dan CAP_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/vmlinux

Kehadiran 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,ptrace

Penjelasan 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/shadow

Fungsi 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_open dengan kriteria pathname=/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/shadow

Secara 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_RDONLY

3. 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 tracee

Skrip 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.py

4. 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 HardeningTindakan KonfigurasiTujuan Keamanan & Performa
Kernel BTF SupportOpsi CONFIG_DEBUG_INFO_BTF=yMemastikan kernel mendukung portabilitas CO-RE eBPF tanpa kompiler.
Akses Subsistem BPFsysctl kernel.unprivileged_bpf_disabled=1Mencegah pengguna non-root memuat program BPF arbitrer ke kernel.
Pengerasan BPF JITsysctl net.core.bpf_jit_harden=2Melindungi JIT compiler dari eksploitasi peretasan Spectre dan JIT spraying.
Filtrasi Syscall TargetBatasi pemantauan read/writeMenghindari kejenuhan ring buffer memori eBPF dan lonjakan beban CPU.
Batas Sumber DayaOpsi Docker --memory & --cpusMencegah 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, atau fstat) 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 seperti execve, ptrace, connect, init_module, dan memfd_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.

๐Ÿ“– Artikel Terkait