Playbook Deteksi Intrusi Linux: Investigasi Cepat dari Log, Proses, ke Network

Kalau kamu ngelola server Linux yang exposed ke internet, satu hal ini hampir pasti kejadian cepat atau lambat: anomali.

Bisa dari login SSH jam aneh, CPU naik padahal traffic normal, ada process asing, atau koneksi outbound ke IP yang nggak kamu kenal. Di titik ini, reaksi paling berbahaya adalah panik lalu nembak semua service sekaligus.

Artikel ini fokus ke pendekatan yang lebih aman dan realistis: investigasi bertahap. Kita pakai keyword cluster Cyber Security bulan ini juga, yaitu:

• basic incident response linux
• linux security hardening
• secure shell scripting

Targetnya bukan bikin kamu jadi digital forensics expert dalam sehari, tapi punya playbook praktis yang bisa dipakai saat insiden beneran.

Kalau kamu belum setup proteksi dasar, baca juga UFW vs Fail2Ban vs SSH Hardening: Kombinasi Wajib Keamanan Server Linux sebagai fondasi.

Kapan kamu harus mulai curiga ada intrusi?

Beberapa sinyal awal yang layak diselidiki:

• Login SSH gagal meningkat tajam.
• Ada user baru yang kamu nggak kenal.
• CPU / network spike tanpa deploy baru.
• Crontab berubah sendiri.
• Ada binary baru di path sensitif (/usr/local/bin, /tmp, /var/tmp).

Satu sinyal belum tentu berarti kompromi. Tapi beberapa sinyal sekaligus itu red flag.

Prinsip playbook: identifikasi → containment → eradication → recovery

Supaya rapi, kita pakai alur incident response standar, tapi versi ringan:

1. Identifikasi: kumpulkan bukti dulu.
2. Containment: batasi dampak tanpa merusak evidence.
3. Eradication: bersihkan akar masalah.
4. Recovery: pulihkan layanan dengan aman.

Di artikel ini, fokus utama ada di fase 1–2 karena itu yang paling krusial di jam awal insiden.

Step 1 — Snapshot cepat kondisi server (tanpa ngubah banyak hal)

Mulai dari command read-only. Jangan install tool random dulu kalau belum perlu.

date
hostnamectl
uptime
who
last -n 20

Lalu simpan snapshot proses dan koneksi:

ps aux --sort=-%cpu | head -n 25
ss -tulpen
lsof -i -P -n | head -n 50

Kenapa ini penting? Karena saat proses jahat mati/restart, jejak bisa hilang. Snapshot awal bikin kamu punya baseline untuk dibandingkan.

Step 2 — Audit login SSH dan auth log

Sebagian besar insiden di server publik berawal dari kredensial lemah atau kebocoran key.

Ubuntu/Debian umumnya cek:

sudo journalctl -u ssh -n 200 --no-pager
sudo grep -Ei "Failed password|Accepted|Invalid user" /var/log/auth.log | tail -n 100

Yang dicari:

• Banyak Failed password dari IP yang sama.
• Login sukses dari IP/lokasi yang nggak biasa.
• Login ke akun service yang seharusnya non-interaktif.

Kalau kamu pakai alert login, proses triage lebih cepat. Referensi: Mail notification when SSH login.

Step 3 — Cek proses mencurigakan

Process berbahaya sering menyamar dengan nama yang “normal” (mis. kworkerx, sysupdater, dsb).

Checklist proses:

ps -eo pid,ppid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 40

Perhatikan:

• process yang jalan dari direktori aneh (/tmp, /dev/shm),
• process parent-child yang tidak wajar,
• command dengan encoded payload (base64 panjang, curl | bash, dll).

Untuk PID yang mencurigakan:

sudo ls -l /proc/<PID>/exe
sudo cat /proc/<PID>/cmdline | tr '\0' ' '
sudo strings /proc/<PID>/environ | head

Jangan langsung kill -9 kalau belum catat detailnya. Evidence bisa hilang sebelum kamu paham root cause.

Step 4 — Investigasi koneksi network keluar

Banyak kompromi modern bikin server kamu “phone home” ke C2 (command-and-control).

ss -tpn state established
sudo lsof -iTCP -sTCP:ESTABLISHED -P -n

Kalau nemu koneksi aneh:

1. catat remote IP + port,
2. map ke PID/process,
3. cek reputasi IP (Threat Intel/manual lookup),
4. masukkan ke daftar blokir sementara kalau perlu.

Untuk containment cepat, kamu bisa sementara drop outbound ke IP tertentu (sesuaikan dengan policy jaringanmu).

Step 5 — Audit persistence: cron, systemd, startup scripts

Attacker yang “berhasil masuk” biasanya pasang mekanisme biar tetap hidup setelah reboot.

Cek cron:

sudo crontab -l
for u in $(cut -f1 -d: /etc/passwd); do sudo crontab -u "$u" -l 2>/dev/null; done
ls -la /etc/cron.*

Cek systemd unit aneh:

systemctl list-unit-files --type=service | grep enabled
systemctl list-timers --all

Cek autorun shell profile:

cat ~/.bashrc ~/.profile 2>/dev/null
sudo grep -R "curl\|wget\|nc\|bash -c" /etc/profile /etc/bash.bashrc /etc/profile.d 2>/dev/null

Ini nyambung banget dengan praktik secure shell scripting: script startup harus jelas sumbernya dan idempotent.

Step 6 — Containment aman (tanpa bikin downtime brutal)

Begitu kamu cukup yakin ada aktivitas jahat, lakukan containment bertahap:

1. Batasi akses masuk
   • lock down port non-esensial,
   • batasi SSH hanya dari IP admin/VPN.
2. Isolasi akun berisiko
   • nonaktifkan user sementara,
   • rotate credential/API key.
3. Bekukan artefak penting
   • salin log, config, dan binary mencurigakan untuk analisis.

Contoh disable user sementara:

sudo usermod -L suspicious_user
sudo passwd -l suspicious_user

Containment itu trade-off. Tujuannya membatasi kerusakan sambil tetap menjaga layanan inti tetap hidup.

Step 7 — Eradication dan hardening ulang

Setelah containment, baru bersihin akar masalah:

• hapus user/backdoor yang tidak valid,
• patch OS + package,
• reset secret (SSH keys, token CI/CD, API keys),
• review file permission sensitif.

Lalu hardening ulang baseline:

• enforce SSH key auth,
• review UFW rules,
• tuning Fail2Ban,
• minimalkan service yang expose public.

Kalau kamu butuh command dasar untuk audit cepat, referensi praktis: Linux shell command yang sering dipakai developer modern.

Contoh mini runbook 15 menit pertama (realistis)

Kalau kamu on-call dan harus gerak cepat:

Menit 0–5

• Snapshot: uptime, who, last, ps, ss, auth log.
• Identifikasi akun/process paling mencurigakan.

Menit 5–10

• Batasi akses SSH by IP.
• Blokir IP brute force paling aktif.
• Lock akun yang jelas-jelas aneh.

Menit 10–15

• Simpan artefak (log, cmdline, hash binary).
• Brief tim: status awal + keputusan containment.
• Putuskan eskalasi: full maintenance mode atau lanjut observasi ketat.

Model ini sengaja sederhana supaya bisa dieksekusi meski kamu lagi sendirian.

Kesalahan yang sering bikin investigasi berantakan

1) Langsung reinstall server

Rebuild cepat kadang perlu, tapi kalau terlalu cepat kamu kehilangan jejak root cause. Efeknya: insiden bisa berulang.

2) Semua process langsung dimatikan

Ini bisa merusak layanan kritikal sekaligus menghapus konteks investigasi.

3) Nggak ada timeline kejadian

Tanpa timeline, postmortem jadi spekulasi. Catat timestamp tiap keputusan.

4) Nggak sinkron dengan tim aplikasi

Kadang anomali ternyata job valid dari pipeline. Cross-check sebelum mengambil tindakan besar.

Checklist hardening pasca-insiden

• Semua key/token berisiko sudah di-rotate
• User dan grup tidak dikenal sudah dihapus/dinonaktifkan
• Rule firewall disederhanakan dan didokumentasikan
• SSH config diverifikasi (PermitRootLogin no, key-only auth)
• Monitoring login, process, dan network outbound aktif
• Runbook insiden diperbarui dari pelajaran kasus ini

Penutup

Di dunia nyata, incident response Linux bukan soal “tool paling canggih”, tapi disiplin eksekusi.

Dengan playbook sederhana—cek log, audit proses, telusuri koneksi, lalu containment bertahap—kamu bisa menurunkan risiko kerusakan besar secara signifikan. Setelah keadaan stabil, baru lanjut ke eradication dan hardening mendalam.

Kalau kamu konsisten dokumentasi + review rutin, kualitas respons tim bakal naik jauh, bahkan sebelum kamu adopsi stack security yang lebih kompleks.

---

FAQ

1) Kapan insiden harus langsung eskalasi ke full maintenance mode?

Eskalasi penuh kalau ada indikasi data sensitif bocor, privilege escalation aktif, atau service inti sudah dimanipulasi. Kalau belum jelas, containment bertahap sering lebih aman sambil kumpulkan evidence.

2) Apakah Fail2Ban cukup untuk mencegah intrusi SSH?

Belum. Fail2Ban efektif menekan brute force, tapi tetap harus dipadukan dengan hardening SSH dan firewall. Kombinasi berlapis lebih kuat daripada satu tool saja.

3) Perlu pasang EDR/agent keamanan di semua server kecil?

Idealnya iya, tapi kalau resource terbatas, mulai dari baseline dulu: logging rapi, hardening SSH, firewall, dan alert anomali. Itu sudah memberi dampak besar.

4) Kalau ketemu proses mencurigakan, kill sekarang atau tunggu?

Catat dulu detail penting (PID, cmdline, parent, koneksi, file path). Setelah evidence minimum aman, baru lakukan containment sesuai tingkat risiko.

5) Seberapa sering runbook incident response harus dites?

Minimal kuartalan, atau setiap ada perubahan arsitektur penting. Simulasi tabletop sederhana sangat membantu supaya tim tidak panik saat kejadian nyata.