Threat Hunting Linux dengan auditd + journald untuk Tim Kecil (Praktis, Bukan Teori)

Kebanyakan tim kecil baru bergerak kalau server sudah “berasa aneh”: CPU naik tanpa alasan, SSH login jam 3 pagi, atau ada koneksi keluar ke IP yang gak dikenal.

Masalahnya, kalau nunggu sampai kejadian, kamu selalu telat satu langkah.

Itu kenapa topik threat hunting Linux penting. Bukan berarti kamu harus punya SOC besar atau beli tool mahal. Dengan kombinasi yang tepat dari auditd + journald, kamu sudah bisa bikin sistem deteksi dini yang realistis buat production.

Di artikel ini kita bahas pendekatan yang bisa langsung dipakai untuk:

• ngumpulin jejak keamanan yang relevan,
• nemuin anomali lebih cepat,
• dan nyambungin hasil investigasi ke basic incident response Linux.

Artikel ini bagian dari cluster keyword bulanan: linux security hardening, basic incident response linux, dan secure shell scripting.

Kalau kamu belum setup fondasi SSH/firewall, baca dulu:

• UFW vs Fail2Ban vs SSH Hardening: Kombinasi Wajib Keamanan Server Linux
• Linux Security Baseline Audit Checklist for Small Teams

Threat hunting itu apa, dan kenapa beda dari monitoring biasa?

Monitoring biasa jawab pertanyaan: “Service hidup atau mati?”

Threat hunting jawab pertanyaan yang lebih penting: “Ada perilaku yang gak normal gak?”

Contoh:

• User yang biasanya login jam kerja, tiba-tiba login dini hari dari IP baru.
• Process bash jalan dari /tmp dengan parent process aneh.
• Ada perubahan file sensitif tanpa change ticket.

Jadi, hunting itu bukan nunggu alert merah. Hunting itu kebiasaan mencari sinyal kecil sebelum jadi insiden besar.

Kenapa auditd + journald cocok buat tim kecil?

Karena dua tool ini sudah dekat dengan sistem Linux:

• journald: sumber log service, kernel, dan banyak event runtime.
• auditd: pencatatan event keamanan level OS (syscall/file/access) dengan granularitas tinggi.

Keuntungannya:

1. Tidak perlu stack observability kompleks dari hari pertama.
2. Bisa mulai dari rule minimal, lalu naik bertahap.
3. Lebih murah operasional untuk tim kecil.

Kekurangannya: kamu harus disiplin bikin baseline dan review rutin. Tanpa itu, log cuma jadi “data numpuk”.

Arsitektur sederhana yang disarankan

Buat tahap awal, cukup pakai alur ini:

1. Event masuk ke journald + auditd.
2. Simpan retention yang cukup (jangan cuma 1–2 hari).
3. Buat query rutin untuk sinyal risiko tinggi.
4. Saat anomali muncul, jalankan mini playbook investigasi.

Nanti kalau tim makin matang, kamu bisa kirim log ke central store/ELK/Loki/SIEM.

Step 1 — Setup baseline logging yang bener dulu

Sebelum hunting, pastikan log kamu layak dipakai investigasi.

Cek journald retention

journalctl --disk-usage
sudo grep -E 'SystemMaxUse|MaxRetentionSec' /etc/systemd/journald.conf

Kalau belum ada setting retention, pertimbangkan set batas yang realistis (misalnya beberapa GB, tergantung disk).

Pastikan sinkron waktu

Waktu log yang berantakan bikin korelasi insiden jadi mimpi buruk.

timedatectl status

Pastikan NTP aktif dan timezone server konsisten.

Cek kesehatan auditd

sudo systemctl status auditd --no-pager
sudo auditctl -s

Kalau auditd belum aktif, pasang dulu:

sudo apt update
sudo apt install auditd audispd-plugins -y
sudo systemctl enable --now auditd

Step 2 — Pasang rule auditd minimal tapi berdampak

Jangan langsung pasang ratusan rule. Mulai dari event bernilai tinggi.

Contoh rule awal (Debian/Ubuntu), simpan di /etc/audit/rules.d/hardening.rules:

# Monitor perubahan file akun penting
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege

# Monitor konfigurasi SSH
-w /etc/ssh/sshd_config -p wa -k ssh_config

# Monitor eksekusi perintah privilege escalation
-w /usr/bin/sudo -p x -k privilege_exec

# Monitor direktori rawan abuse
-w /tmp -p wa -k tmp_watch
-w /var/tmp -p wa -k tmp_watch

Apply rule:

sudo augenrules --load
sudo auditctl -l

Tujuan rule di atas bukan bikin sempurna, tapi menangkap perubahan paling sensitif dulu.

Step 3 — Buat “hunting query” mingguan yang konsisten

Ini bagian weekly intent rotation: bukan cuma teori hardening, tapi troubleshooting dan investigasi terstruktur.

Query A: perubahan user/privilege

sudo ausearch -k identity -ts this-week
sudo ausearch -k privilege -ts this-week

Tanya ke diri sendiri:

• Perubahan ini expected atau tidak?
• Ada tiket/perubahan resmi?
• Dilakukan oleh user siapa dan kapan?

Query B: aktivitas SSH yang aneh

sudo journalctl -u ssh --since "7 days ago" --no-pager | \
  grep -Ei "Failed password|Accepted|Invalid user" | tail -n 200

Kombinasikan dengan konteks dari artikel ini: Playbook Deteksi Intrusi Linux: Investigasi Cepat dari Log, Proses, ke Network

Query C: akses mencurigakan ke /tmp dan /var/tmp

sudo ausearch -k tmp_watch -ts this-week

Banyak malware sederhana drop payload di lokasi ini karena writeable.

Step 4 — Deteksi pola anomali, bukan event tunggal

Satu event jarang cukup untuk menyimpulkan kompromi. Cari pola gabungan seperti ini:

1. Ada Invalid user berulang di SSH,
2. lalu muncul proses asing dari /tmp,
3. lalu ada outbound connection ke IP tidak dikenal.

Kalau tiga sinyal ini kejadian berdekatan, itu prioritas tinggi.

Untuk command investigasi cepat, kamu bisa pakai toolkit dasar dari: Linux Shell Command yang Sering Dipakai Developer Modern

Step 5 — Mini runbook respon saat anomali ketemu

Begitu hunting nemu hal mencurigakan, jangan panik. Ikuti urutan:

1) Preserve evidence ringan

date
hostnamectl
uptime
ps aux --sort=-%cpu | head -n 30
ss -tulpen

Simpan output ke file timestamped.

2) Batasi akses berisiko

• Sementara allow SSH hanya dari IP admin/VPN.
• Lock akun mencurigakan.
• Blok koneksi outbound ke IP yang jelas malicious (sesuai kebijakan tim).

3) Verifikasi persistence

Cek cron, systemd timer/service, dan shell profile.

sudo systemctl list-timers --all
sudo crontab -l
ls -la /etc/cron.*

4) Eradikasi bertahap

• Hapus artefak berbahaya setelah diinventaris.
• Patch package rentan.
• Rotate credential yang mungkin terdampak.

Step 6 — Automasi ringan biar hunting gak cuma niat

Kalau hunting masih manual total, biasanya mandek di minggu ketiga. Solusinya: automasi minimum yang aman.

Misalnya script harian untuk ringkasan audit key:

#!/usr/bin/env bash
set -Eeuo pipefail
IFS=$'\n\t'

OUT_DIR="/var/log/security-digest"
mkdir -p "$OUT_DIR"
NOW="$(date +%F-%H%M)"
OUT_FILE="$OUT_DIR/digest-$NOW.log"

{
  echo "=== Security Digest $NOW ==="
  echo
  echo "[identity changes]"
  ausearch -k identity -ts yesterday 2>/dev/null || true
  echo
  echo "[privilege changes]"
  ausearch -k privilege -ts yesterday 2>/dev/null || true
  echo
  echo "[ssh anomalies]"
  journalctl -u ssh --since yesterday --no-pager | \
    grep -Ei "Failed password|Invalid user|Accepted" | tail -n 120 || true
} >> "$OUT_FILE"

Poin penting: pakai prinsip secure shell scripting.

Kalau kamu mau referensi pola script aman, baca:

• Bash Strict Mode and Safe Automation Checklist for Linux Servers
• Debug Shell Script di Linux Production

Step 7 — Metrik yang harus dilacak tiap minggu

Biar threat hunting jadi kebiasaan yang bisa diukur, track metrik sederhana:

1. Jumlah failed SSH login per minggu.
2. Jumlah perubahan file sensitif (/etc/passwd, sshd_config, dsb).
3. Jumlah event privilege escalation.
4. Mean Time to Investigate (MTTI) anomali prioritas tinggi.

Kalau angkanya makin baik, berarti prosesmu matang. Kalau stagnan, berarti rule/query perlu dituning.

Kesalahan umum yang bikin hunting gagal total

1) Semua event dianggap critical

Hasilnya: alert fatigue. Tim capek, sinyal penting kelewat.

2) Tidak punya baseline normal

Tanpa baseline, kamu gak bisa bedain “normal tapi ramai” vs “benar-benar anomali”.

3) Rule terlalu banyak sejak awal

Audit log jadi berat, query lambat, tim bingung sendiri.

4) Gak ada tindak lanjut

Threat hunting tanpa runbook respon itu cuma hobi baca log.

Rekomendasi implementasi 30 hari (versi realistis)

Minggu 1

• Aktifkan auditd + journald retention.
• Pasang rule minimal high-impact.

Minggu 2

• Susun query hunting mingguan.
• Definisikan ambang anomali prioritas tinggi.

Minggu 3

• Automasi ringkasan harian/mingguan.
• Uji mini incident drill 1 skenario.

Minggu 4

• Review false positive.
• Rapikan dokumentasi dan checklist tim.

Dengan cara ini, kamu gak perlu menunggu “insiden besar” untuk mulai disiplin keamanan.

Penutup

Threat hunting Linux bukan eksklusif buat perusahaan besar. Tim kecil juga bisa jalan, asal fokus ke hal yang berdampak:

• log yang rapi,
• rule audit yang tepat,
• query rutin yang konsisten,
• dan respon insiden yang gak panik.

Mulai dari sederhana. Stabilkan proses. Baru tingkatkan kompleksitas.

Kalau pondasi ini konsisten, kamu bakal jauh lebih siap saat anomali beneran datang.

---

FAQ

1) Apa auditd wajib di semua server Linux?

Tidak selalu wajib, tapi sangat disarankan untuk server production yang internet-facing atau menyimpan data penting. Untuk server internal low-risk, kamu bisa mulai dari journald dulu lalu naik ke auditd.

2) Bedanya journald dan auditd apa?

Journald fokus ke log service/runtime sistem. Auditd fokus ke event keamanan level OS (akses file sensitif, syscall terkait privilege, dll). Keduanya saling melengkapi.

3) Apakah auditd bikin server jadi berat?

Bisa, kalau rule terlalu banyak atau terlalu luas. Makanya mulai dari rule minimum high-value, ukur dampaknya, lalu tambah bertahap.

4) Seberapa sering threat hunting dilakukan?

Untuk tim kecil, ritme realistis adalah review mingguan + ringkasan harian otomatis untuk event prioritas tinggi.

5) Kalau sudah pakai Fail2Ban, masih perlu threat hunting?

Masih perlu. Fail2Ban bagus untuk brute force, tapi tidak cukup untuk mendeteksi pola kompromi yang lebih kompleks seperti persistence, perubahan privilege, atau abuse process.