Deteksi Proses Suspicious Linux: Panduan Lengkap 2026

Pas itu tahun 2021, aku masih NOC junior dan gak sengaja dikasih trust pegang satu server production dari client. Jam 3 pagi, HP meledak. Bukan alarm bangun tidur, tapi notifikasi monitoring yang bunyi terus karena CPU udah nempel di 95% selama hampir 15 menit. Mata masih lengket, aku buka laptop, cek top, dan… jantung langsung deg-degan. Ada proses aneh dengan nama yang kelihatan resmi, tapi aku gak pernah install. Nah, dari malam itu, aku belajar cara deteksi proses suspicious linux dengan cara yang ternyata gak serumit yang dikira.

Sekarang, setiap ada server yang ngadat, refleks pertamaku bukan restart langsung. Aku justru seneng kalo ada “tanda-tanda” gitu muncul, karena biasanya itu gerbang buat nemuin sesuatu yang lebih dalam. Tapi malam itu, aku masih nol besar. Yang aku tahu cuma restart, dan yakin deh, restart itu cuma nyuri waktu. Proses jahatnya bakal muncul lagi begitu server nyala, malah bisa tambah parah. Dari situ aku mulai rajin belajar, dan artikel ini adalah rangkuman lengkap dari pengalaman itu.

Kenapa Proses Suspicious Sering Luput dari Mata

Nah, ini yang dulu bikin aku bertanya-tanya. Kok bisa ya server udah disusupi, tapi kita gak ngerasa ada apa-apa dalam hitungan hari? Jawabannya sederhana: attacker jaman sekarang gak asal pasang malware yang ngebut. Mereka mikirin stealth. Nama proses dibuat mirip banget sama proses sistem — misalnya kworker atau systemd diganti jadi systmed dengan huruf s dan m ketuker, atau kdevtmpfs diganti jadi /dev/shm/kdevtmpfs biar lolos mata yang cek sekilas. Kecepatannya juga diatur, gak langsung makan CPU 100%, tapi pelan-pelan, bikin alert threshold kita gak kena.

Ini yang paling bikin aku kapok waktu itu: malware crypto miner yang nyerang server client ternyata udah jalan hampir tiga minggu sebelum ketahuan. Impact-nya? Tagihan listrik gak relevan buat server sih, tapi yang jelas CPU selalu capek, aplikasi mulai lambat, dan client mulai komplen karena API-nya sering timeout. Pas dicek, ternyata miner itu jalan sebagai proses anak dari cron job yang disisipin ke user www-data. Kalau aku aja yang monitor-nya ngecek “proses gede doang”, ya gak bakal ketahuan. Padahal kan harusnya cek seluruh rantai: proses, cron, socket, file yang kebuka.

Nah, karena itu, pendekatan deteksi proses suspicious linux itu gak bisa cuma ngecek satu titik. Harus menyeluruh, dari atas ke bawah: lihat proses yang makan resource, bandingin sama baseline, cek koneksi jaringan keluar yang gak wajar, telusuri file yang kebuka, sisir crontab, dan terakhir pelajari log. Tiap lapisan punya sinyalnya masing-masing, dan satu sinyal aja kadang udah cukup buat nemu pola yang aneh. Gak usah pusing dulu, kita bahas pelan-pelan per langkah, biar pas kamu lagi oncall jam 2 pagi, langkahnya udah kebayang di kepala.

Oh iya, satu lagi yang penting aku tekankan. Jangan cuma belajar cara menemukannya, tapi juga latih intuisi. Nanti di bagian FAQ ada aku jawab soal “gimana bedain proses normal sama yang mencurigakan”, karena pertanyaan ini paling sering muncul dari tim junior. Pada dasarnya, setiap proses yang gak bisa kamu jelaskan fungsinya, itu udah red flag. Simpel, tapi dari yang simpel inilah deteksi dimulai.

Persiapan Sebelum Mulai Deteksi

Sebelum eksekusi command-command di bawah, ada satu aturan yang gak boleh kamu lewat: catat dulu kondisi normal server kamu. Ibaratnya kayak kamu tahu rumah kamu gak, kalau tiba-tiba ada orang asing duduk di teras, kamu bakal curiga karena tahu penghuni rumahnya siapa aja. Baseline itu bentuknya simpel banget — misalnya: “proses Java dari application server biasanya makan 60% RAM, cron backup jalan jam 2 pagi, dan SSH cuma kebuka dari IP kantor”. Nanti, tiap yang gak cocok sama daftar itu, langsung ketauan.

Kedua, pastikan akses SSH kamu pake key, bukan password. Percaya deh, mayoritas kasus kompromi yang aku handle awalnya dari password lemah yang kebobolan brute force. Kalau mau, baca dulu artikel tentang panduan amankan SSH dengan key ini sebelum lanjut, karena deteksi gak akan ada artinya kalau backdoor-nya kebuka terus. Dan yang gak kalah penting, siapin terminal yang nyaman. Gak perlu install aplikasi tambahan dulu, command bawaan Linux udah cukup buat 90% kebutuhan.

Langkah 1 — Mulai dari top atau htop

Langkah paling pertama, dan ini yang paling sering diskip orang: top. Banyak yang langsung lompat ke ps atau ss tanpa lihat gambaran besar dulu. Padahal top itu kayak peta awal — dari sini kamu bisa lihat proses mana yang paling boros CPU dan memory dalam format real-time.

top -c -o %CPU -n 1

Flag -c buat nampilin full command path, bukan cuma nama singkatnya. Ini penting banget, karena nama proses bisa dipalsuin tapi command path-nya kadang lupa dipalsuin. Contohnya, kalau kamu lihat proses bernama kswapd0 tapi command path-nya /var/tmp/.tmp/kswapd0 — nah itu udah mencurigakan banget, karena kswapd0 asli itu proses kernel yang gak punya path. Dari top juga kamu bisa langsung lihat berapa persen CPU yang kebakar. Kalau ada satu proses doang makan 90%+ terus-menerus tanpa tau kerjanya apa, langsung tulis PID-nya.

Kalau kamu pengen versi yang lebih enak dibaca, bisa install htop. Di Debian/Ubuntu tinggal apt install htop, di AlmaLinux/Rocky pakai dnf install htop. Tapi inget, buat forensik, top sama htop cuma alat awal, bukan kesimpulan. Ini yang aku maksud tadi: top itu cuma peta, bukan jawaban final.

Langkah 2 — ps aux dan Cara Membacanya

Setelah nemu kandidat dari top, sekarang saatnya bedah lebih dalam. Command andalan semua sysadmin: ps aux. Tapi jangan buru-buru scroll, karena output-nya panjang banget di server yang rame. Pakai filter dulu biar fokus.

ps aux --sort=-%cpu | head -20
ps aux --sort=-%mem | head -20

Dua command di atas nampilin 20 proses teratas yang paling boros CPU dan memory. Dari sini, perhatiin beberapa hal: user yang menjalankan prosesnya (kalau proses dijalanin sebagai root tapi kamu gak pernah setup, itu aneh), dan command line-nya (cari pola aneh kayak base64 decode, curl | sh, wget, atau referensi ke /tmp atau /dev/shm).

Contoh pola yang harus langsung bikin otak kamu alarm:

root 12345 0.0 0.1 16224 1032 ? S 03:11 0:00 [kworker/u256:4]
www-data 24680 2.0 1.2 481224 9088 ? S 00:12 0:03 ./xkcd -a -o stratum+tcp://xmr.pool:443 -u wallet_address -p x

Baris kedua itu contoh classic XMRig miner yang dijalanin sebagai user www-data — biasanya nyusup lewat exploit aplikasi web. Kalau kamu lihat nama proses seperti xmrig, miner, zgrab, atau kdevtmpfs yang gak masuk akal, itu bukan kebetulan. Itu tanda kompromi. Catat PID-nya dan lanjut ke langkah berikutnya.

Langkah 3 — Cek Koneksi Jaringan yang Keluar

Nah, ini step yang paling sering kelewat dan justru paling gampang nangkep proses jahat. Malware gak akan kemana-mana kalau gak ngobrol ke luar. Cek socket TCP yang lagi aktif, terutama yang koneksinya keluar (ESTABLISHED ke IP remote):

ss -tunap | grep ESTAB

Perhatiin kolom peer address-nya. Ada IP yang gak kamu kenal? Port yang aneh kayak 4444, 6666, 8080, 3333, atau port-port yang sering dipake C2 dan mining pool? Bandingin sama baseline kamu tadi. Kalau server kamu cuma serve web di port 80/443, kenapa harus ada koneksi keluar ke IP datacenter random pukul 4 pagi? Pertanyaan itu aja udah cukup buat narik kesimpulan sementara.

Kalau kamu mau tau proses mana yang megang koneksi tertentu, tinggal catat PID dari kolom terakhir command ss tadi, terus sambungin ke hasil ps. Sebaliknya, kalau kamu mau mulai dari proses, pakai lsof:

lsof -p PID_NUMBER -i

Ada satu kasus yang sampai sekarang masih aku inget: proses-nya sendiri kecil, cuma 0.5% CPU, tapi dia nyimpen socket ke IP yang connect-nya putus-nyambung setiap 5 menit. Kalau cuma ngeliat top, gak bakal ketauan. Tapi pas di-ss, langsung keliatan komunikasinya. Jadi jangan pernah skip step ini.

Langkah 4 — lsof dan File yang Sudah Di-delete

Ini trik senior yang dulu aku pelajari dari mentor dan sering banget nyelamatin hari-hariku. Malware itu biasanya jalan dari file di /tmp atau /var/tmp, terus file-nya langsung didelete biar gak ketauan. Nah, kuncinya: proses yang masih jalan tapi file-nya udah gak ada itu red flag besar.

lsof +L1 | grep -i deleted

Output-nya bakal nampilin proses-proses yang lagi megang file yang udah didelete. Bandingin sama /proc:

ls -la /proc/PID/exe

Kalau hasilnya nunjukin path yang udah gak ada, atau path-nya di /tmp/something (deleted), kamu lagi ngadepin proses yang sengaja disembunyiin. Command di atas juga berguna buat ngecek binary aslinya jalan dari mana, karena symlink exe itu gak bisa dibohongin semudah nama proses di top.

Langkah 5 — Sisir Crontab dan Scheduled Task

Ini bagian yang bikin aku malu-maluin pas kasus 2021 tadi, karena ternyata persistencenya lewat cron dan aku gak kepikiran buat cek situ. Attacker gak mau prosesnya mati pas server restart, jadi mereka selalu pasang “persistence”. Tempat favoritnya: crontab user, crontab root, dan /etc/cron.d.

for user in $(cut -f1 -d: /etc/passwd); do echo "== $user =="; crontab -u $user -l 2>/dev/null; done
cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/

Yang kamu cari: entry cron yang isinya wget, curl, base64 -d, atau referensi ke script di /tmp. Entry cron normal itu pendek dan jelas, misalnya backup database. Kalau ada yang panjang, di-encode, dan download sesuatu dari URL aneh, itu udah cukup buat panik (secara profesional, tentunya).

Jangan lupa juga cek systemd timer dan script di /etc/rc.local, karena beberapa malware jaman sekarang udah pinter pindah dari cron ke systemd biar susah diendus. Cek semua unit yang enabled:

systemctl list-unit-files --state=enabled | grep -E "tmp|shm|hidden|update"

Langkah 6 — Deep Dive ke /proc

Kalau top, ps, ss, lsof, dan cron udah dicek tapi masih ada yang aneh, saatnya masuk ke level forensik. Folder /proc itu jendela virtual ke kernel — tiap proses punya folder sendiri di sana. Beberapa file yang wajib kamu perhatiin:

cat /proc/PID/cmdline | tr '' ' '
cat /proc/PID/environ | tr '' 'n' | head -30
ls -la /proc/PID/fd | head -30
cat /proc/PID/status | grep -E "Name|State|PPid"

cmdline buat lihat argument asli yang kepotong di ps. environ buat lihat environment variable-nya (kadang ada konfigurasi wallet atau C2 server di sini). fd buat lihat semua file descriptor yang kebuka. Dan jangan heran kalau nanti ketemu banyak file di /dev/shm atau /tmp yang di-unlink — itu pola umum malware Linux.

Kombinasi /proc sama /proc/PID/exe tadi biasanya udah cukup buat mastiin 80% kasus. Kalau dua-duanya normal, berarti kamu cuma panik kena proses legitimate yang aneh-aneh karena salah konfigurasi. Tenang, itu juga pengalaman yang gak kalah berharga.

Langkah 7 — Verifikasi, Kill, dan Bersihkan Sampai Akar

Oke, kamu udah nemu kandidat kuat. Sekarang jangan langsung kill dulu. Verifikasi dulu, karena salah kill bisa bikin production down dan itu justru bikin kamu makin pusing. Cek dulu apakah proses itu bener-bener jahat:

grep -i "PID" /var/log/syslog /var/log/auth.log 2>/dev/null
strings /proc/PID/exe | grep -iE "miner|stratum|pool|tcp://" | head -20

Kalau udah yakin, barulah kill. Tapi ini penting: kill cuma menghapus gejalanya. Root cause-nya — cara masuknya — harus ketemu dulu, kalau gak dalam hitungan jam bakal nyusup lagi lewat jalur yang sama.

kill -9 PID
killall -9 nama_proses

Abis itu, bersihin persistencenya: hapus entry cron yang mencurigakan, hapus file di /tmp atau /dev/shm, hapus SSH key aneh dari /root/.ssh/authorized_keys dan semua user, cek /etc/ld.so.preload buat library hijack, dan ganti semua password yang sempet kepakai. Kalau bisa, matiin akses yang gak perlu: tutup port yang gak dipake, pasang fail2ban buat anti brute force, dan kunci SSH cuma dari IP tertentu.

Tabel Troubleshooting: Pola Proses Mencurigakan

FAQ

Penutup

Kalau diinget-inget lagi, kasus 2021 itu sekarang malah jadi salah satu momen favoritku, karena dari situ aku belajar hal yang paling penting di dunia NOC: jangan pernah lari dari masalah, peluk dulu, bedah, baru selesaiin. Proses suspicious di Linux itu sebenernya gak sulit ditemukan selama kamu tau mau lihat ke mana. Semua yang aku tulis di atas bisa kamu praktekin di server mana pun, dan makin sering kamu cek, makin cepat insting kamu terbentuk.

Ini bisa jadi bekal buat ngehandle kasus yang lebih berat lagi, kayak harden server secara keseluruhan. Kalau pengen lanjut, cek juga best practice hardening server Linux dan panduan troubleshooting high load biar skill-nya makin komplit. Matur nuwun udah baca sampai sini, dan semoga server kamu selalu sehat, ya. Kalau pernah ngalamin kasus serupa tapi dengan trik yang beda, share di komentar, aku selalu penasaran sama cara orang lain nangkep penyusup.