Tutorial Hardening Linux Server: Custom AppArmor Profile & Seccomp Filter

1. Threat Model: Vulnerabilitas Zero-Day RCE dan Batasan Access Control DAC

Celah keamanan Remote Code Execution (RCE) pada aplikasi web dan layanan backend merupakan ancaman tertinggi bagi infrastruktur server Linux. Saat penyerang berhasil mengompromikan aplikasi yang berjalan tanpa mekanisme isolasi proses, instruksi arbitrary akan dieksekusi dengan tingkat hak akses (privilege) dari user pengelola daemon tersebut.

Keterbatasan Discretionary Access Control (DAC)

Sistem operasi Linux secara default mengandalkan Discretionary Access Control (DAC) untuk mengatur izin akses berkas dan proses berdasarkan atribut kepemilikan User ID (UID), Group ID (GID), dan mode permission (seperti rwxr-xr-x via chmod atau chown). Meskipun DAC berguna untuk manajemen akses dasar, model ini tidak dirancang untuk menahan eksploitasi tingkat lanjut:

• Akses Filesystem Terlalu Luas: Proses yang berjalan di bawah user non-root seperti www-data atau nobody secara default tetap memiliki izin baca terhadap sebagian besar hierarki berkas sistem. Penyerang dapat membaca berkas sensitif seperti /etc/passwd, konfigurasi environment .env, kunci privat TLS, token autentikasi, serta struktur memori pada /proc.
• Eksploitasi Binari SUID/SGID: Penyerang yang memperoleh akses shell interaktif dapat memindai berkas dengan atribut SUID (Set User ID) seperti pkexec, sudo, atau newgrp untuk mengeksekusi kerentanan eskalasi hak akses lokal (Local Privilege Escalation / LPE) menuju akses root penuh.
• Eksekusi Arbitrary System Calls: DAC tidak membatasi jenis system call (syscall) yang dapat dikirimkan oleh suatu proses ke kernel Linux. Proses unconfined dapat memanggil syscall berisiko tinggi seperti ptrace (untuk melakukan proses injection pada PID lain), unshare / clone (untuk manipulasi user namespace), atau bpf (untuk mengeksploitasi celah kernel eBPF).

Untuk menutup celah sistemik ini, arsitektur keamanan modern menerapkan prinsip defense-in-depth dengan menggabungkan Mandatory Access Control (MAC) berbasis AppArmor dan penyaringan system call berbasis Seccomp (Secure Computing Mode).

2. Analisis Syscall, Pembuatan Custom AppArmor Profile, dan Seccomp Filter

Langkah 1: Profiling Perilaku Aplikasi Menggunakan strace

Sebelum mengunci proses dengan profil keamanan, Anda harus mengidentifikasi seluruh kebutuhan akses berkas, koneksi jaringan, dan system call yang dipanggil oleh aplikasi selama operasi normal.

# Memantau pemanggilan file, proses, dan network oleh biner aplikasi
strace -f -e trace=file,process,network -o /tmp/app_strace.log /usr/local/bin/api-server

# Rekapitulasi frekuensi system call yang dipanggil selama beban kerja normal
strace -c -f /usr/local/bin/api-server

Hasil analisis dari strace akan menjadi acuan utama saat menyusun daftar putih (allowlist) pada profil AppArmor dan aturan penyaringan Seccomp.

Langkah 2: Menulis dan Menerapkan Custom AppArmor Profile

AppArmor membatasi kapabilitas proses pada level kernel dengan melarang akses yang tidak secara eksplisit diizinkan dalam profil. Buat profil baru pada jalur berkas /etc/apparmor.d/usr.local.bin.api-server.

abi <abi/4.0>,
include <tunables/global>

profile api-server /usr/local/bin/api-server flags=(attach_disconnected) {
  include <abstractions/base>
  include <abstractions/nameservice>

  # Pembatasan Kapabilitas POSIX
  capability net_bind_service,
  deny capability sys_admin,
  deny capability sys_ptrace,
  deny capability sys_rawio,
  deny capability sys_module,

  # Aturan Jaringan
  network inet tcp,
  network inet6 tcp,
  deny network raw,

  # Akses Binari & Library (Read & Execute / Memory Map)
  /usr/local/bin/api-server mr,
  /lib/x86_64-linux-gnu/*.so* mr,
  /usr/lib/x86_64-linux-gnu/*.so* mr,

  # Akses Berkas Konfigurasi & Log Aplikasi
  /etc/api-server/config.yaml r,
  /var/log/api-server/*.log rw,
  /tmp/ rw,
  /tmp/* rw,

  # Aturan Deny Eksplisit untuk Jalur Sensitif
  deny /etc/shadow r,
  deny /etc/sudoers r,
  deny /root/** rwklx,
  deny /bin/sh rx,
  deny /bin/bash rx,
  deny /usr/bin/python3 rx,
}

Gunakan perintah apparmor_parser untuk memvalidasi dan memuat profil ke dalam kernel:

# Validasi sintaks dan muat profil dalam mode audit/complain
sudo apparmor_parser -r -C /etc/apparmor.d/usr.local.bin.api-server

# Pindahkan profil ke mode pembatasan aktif (enforce mode)
sudo aa-enforce /etc/apparmor.d/usr.local.bin.api-server

Langkah 3: Penerapan Seccomp Syscall Filtering via Systemd Unit

Seccomp bekerja di level kernel BPF (Berkeley Packet Filter) untuk mengevaluasi dan memblokir panggilan system call sebelum instruksi tersebut sempat diproses oleh CPU. Cara paling bersih dan mudah dikelola untuk menerapkan filter Seccomp pada server produksi adalah memanfaatkan integrasi bawaan pada Systemd unit file.

Sunting berkas service pada /etc/systemd/system/api-server.service:

[Unit]
Description=API Server Production Daemon
After=network.target

[Service]
Type=simple
User=www-data
Group=www-data
ExecStart=/usr/local/bin/api-server
Restart=always

# Pengerasan Lingkungan Eksekusi Systemd
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true
ProtectKernelTunables=true
ProtectControlGroups=true
MemoryDenyWriteExecute=true

# Pemblokiran Grup System Call Berbahaya
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @privilege @raw-io @reboot @swap

# Blacklist System Call Spesifik untuk Menghindari LPE
SystemCallFilter=~ptrace ptrace_scope unshare kcmp bpf process_vm_writev
SystemCallArchitectures=native

[Install]
WantedBy=multi-user.target

Terapkan perubahan konfigurasi service dengan menginstruksikan Systemd untuk memuat ulang berkas unit:

sudo systemctl daemon-reload
sudo systemctl restart api-server

3. Monitoring Log, Troubleshooting Denied Access, dan Tuning Profil

Penerapan profil keamanan yang terlalu ketat tanpa pengujian menyeluruh dapat menyebabkan aplikasi crash atau kehilangan fungsi tertentu. Pemantauan log audit secara real-time diperlukan untuk mendeteksi penolakan akses yang valid (false positive).

Menganalisis Event Blokir AppArmor dan Seccomp

Setiap penolakan akses oleh AppArmor atau Seccomp dicatat oleh kernel ke dalam subsystem auditd. Anda dapat menyaring pesan penolakan menggunakan journalctl atau utilitas aa-notify:

# Pemantauan log AppArmor secara real-time melalui journalctl
sudo journalctl -k -f | grep -i apparmor

# Memeriksa ringkasan penolakan akses menggunakan aa-notify
sudo aa-notify -p -s 1 -v

Berikut adalah struktur entitas log penolakan AppArmor saat aplikasi mencoba mengakses berkas terlarang:

type=APPARMOR_DENIED operation="open" profile="api-server" name="/etc/shadow" pid=14205 comm="api-server" requested_mask="r" denied_mask="r"

Tuning Profil Otomatis Menggunakan aa-logprof

Apabila log audit menunjukkan penolakan terhadap operasi legitimate aplikasi, Anda dapat memperbarui berkas profil secara interaktif menggunakan utilitas aa-logprof:

sudo aa-logprof

Utilitas ini akan membaca log kejadian terbaru, menampilkan rekomendasi penambahan aturan (Allow / Deny), dan memperbarui berkas profil di /etc/apparmor.d/ secara otomatis tanpa memicu kesalahan sintaks manual.

4. Integrasi Pipeline CI/CD dan Server Hardening Architecture Checklist

Otomatisasi Deployment Profiles dalam Pipeline CI/CD

Untuk memastikan kebijakan pengerasan sistem selalu selaras dengan perubahan kode aplikasi, integrasikan pengujian profil AppArmor dan konfigurasi Systemd ke dalam alur kerja pembaruan otomatis (CI/CD pipeline).

# Contoh langkah validasi profil pada GitHub Actions / GitLab CI
- name: Validate AppArmor Profile Syntax
  run: |
    sudo apt-get install -y apparmor-utils
    apparmor_parser -a --dry-run ./security/apparmor/usr.local.bin.api-server

- name: Deploy Profiles via Ansible
  run: |
    ansible-playbook -i inventory/production deploy-security-profiles.yml

Checklist Arsitektur Hardening Linux Server Production

Gunakan daftar periksa berikut sebagai acuan standar dalam menerapkan isolasi aplikasi berbasis Linux:

• Enforce Mode AppArmor: Terapkan profil spesifik berstatus enforce untuk seluruh aplikasi publik seperti web server (Nginx/Apache), runtime (Node.js/Python/Go), dan database (PostgreSQL/MySQL).
• Mandatory Systemd Hardening: Wajibkan parameter NoNewPrivileges=true, ProtectSystem=strict, dan ProtectHome=true di setiap unit berkas layanan.
• Restriksi Kernel Syscall: Blokir system call berisiko tinggi (seperti ptrace, unshare, bpf, process_vm_writev) menggunakan SystemCallFilter bawaan Systemd.
• Deaktivasi Unprivileged User Namespaces: Matikan fitur pengkloningan namespace pengguna tanpa hak akses untuk mencegah teknik eksploitasi container escape: sysctl -w kernel.unprivileged_userns_clone=0.
• Pengerasan Parameter Sysctl Kernel: Aktifkan pembatasan pointer kernel dan log dmesg dengan menyunting sysctl: kernel.kptr_restrict=2 dan kernel.dmesg_restrict=1.
• Sentralisasi Audit System: Hubungkan layanan auditd dengan pengumpul log sentral (SIEM) untuk mengorelasikan event APPARMOR_DENIED dan penolakan SECCOMP secara real-time.

5. Kesimpulan

Keamanan server Linux produksi tidak cukup hanya mengandalkan pembatasan port firewall dan pembaruan patch berkala. Kombinasi antara profil kustom AppArmor yang presisi dan penyaringan system call Seccomp membentuk batas pertahanan mikro (micro-segmentation) pada tingkat proses kernel. Bahkan jika peretas menemukan celah zero-day RCE pada kode aplikasi, dampak serangan dapat dilokalisasi secara total karena penyerang tidak memiliki akses filesystem universal maupun izin panggil system call untuk mengeksekusi privilege escalation.