Incident Response Langkah Pertama — Panduan 101 Saat Server Kena Serangan Siber

Jam 02:17 pagi. Hape saya bergetar. Bukan sekali, tapi empat kali berturut-turut. Saya lihat layar — missed call dari CTO salah satu klien startup fintech. Terus WhatsApp: “Kak, server kita kena hack! Tolong! Semua layanan down!” Jantung saya langsung dag-dig-dug. Ini bukan drill. Ini bukan latihan meja. Tapi saya udah cukup pengalaman untuk tahu satu hal: incident response langkah pertama yang kamu ambil di momen kayak gini bisa menentukan apakah ini jadi bencana besar atau insiden yang bisa dikendalikan. Dan percaya deh, setelah 8 tahun lebih nanganin puluhan kasus serangan siber — mulai dari ransomware, defacement, sampai data breach yang nilainya miliaran — saya bisa bilang bahwa kebanyakan kesalahan fatal justru terjadi di 30 menit pertama.

Kenapa? Karena panik. Karena tekanan. Karena semua orang teriak-teriak dan nggak ada yang punya rencana jelas. Nah, makanya di artikel ini saya mau sharing pengalaman nyata tentang incident response langkah pertama — apa yang harus kamu lakukan (dan yang lebih penting: apa yang nggak boleh kamu lakukan) saat server kena serangan. Anggap ini survival guide versi saya. Siap? Tarik napas dulu. Kita mulai.

Pukul 2 Pagi dan Telepon yang Nggak Pernah Kamu Inginkan

Cerita lanjutan dari telepon jam 2 pagi tadi ya. Jadi setelah saya bangunin diri sepenuhnya (sambil nyuci muka pake air dingin — ini ritual wajib saya sebelum nanganin insiden), saya langsung kontak engineer on-call klien via video call. Di layar laptop saya keliatan dashboard monitoring mereka: semua grafik merah. CPU usage server production 100%. Network traffic spike luar biasa. Database server nggak bisa diakses. Website utama nge-serve halaman deface — tulisan gede “Hacked by…” lengkap sama gambar tengkorak. Panik? Pasti. Tapi ini momen di mana pengalaman bicara.

Hal pertama yang saya tanyakan ke engineer mereka: “Ada yang udah ngapa-ngapain ke server? Ada yang restart? Ada yang login? Ada yang matiin?” Jawabannya bikin saya lega sekaligus ngeri: “Belum, cuma ngecek aja. Tapi tadi si Budi hampir restart server-nya…” Hampir. Untungnya kata kuncinya “hampir”. Karena restart server yang kena serangan adalah salah satu kesalahan paling fatal dalam incident response — dan kita bakal bahas kenapa nanti.

Framework NIST — Cetak Biru Incident Response yang Dipake di Mana-Mana

Sebelum kita bahas langkah teknisnya, ada baiknya kamu kenalan dulu sama framework incident response yang paling banyak dipake di industri: NIST SP 800-61. Framework ini ngasih kita cetak biru sistematis buat nanganin insiden keamanan, dan terdiri dari enam fase. Ini bukan teori textbook doang — saya sendiri pake framework ini sebagai acuan di setiap insiden yang saya tangani.

Preparation — Siapkan Payung Sebelum Hujan

Fase ini terjadi sebelum insiden terjadi. Isinya: bikin incident response plan yang jelas (siapa ngapain, siapa kontak siapa, apa eskalasinya), siapin toolkit (laptop investigasi, tools forensik, write blocker), latihan tabletop exercise secara berkala, dan pastiin logging dan monitoring udah berjalan dengan baik. Saran saya: jangan nunggu kena serangan dulu baru bikin IR plan. Percuma beli helm setelah jatuh dari motor.

Detection & Analysis — Kenali Musuhmu

Ini fase di mana kamu pertama kali sadar ada yang nggak beres — bisa dari alert SIEM, laporan user, atau (skenario terburuk) dari tweet orang lain yang ngasih tahu kalau website kamu di-deface. Di fase ini tugas kamu adalah: verifikasi apakah ini beneran insiden atau cuma false positive, tentukan scope dan impact-nya (server mana aja yang kena, data apa yang mungkin bocor, berapa banyak user yang terdampak), dan dokumentasikan semua temuan awal.

Containment — Stop Pendarahannya Dulu

Begitu terkonfirmasi bahwa ini adalah insiden beneran, prioritas utama adalah containment — menghentikan penyebaran dan membatasi kerusakan. Ini bukan saatnya analisis mendalam. Ini saatnya bertindak. Tapi containment ada dua strategi: short-term (langsung isolate server dari network, blokir IP attacker, disable compromised accounts) dan long-term (patch vulnerability, rebuild sistem dari clean image, perkuat security controls).

Eradication — Bersihin Sampai ke Akar

Setelah serangan berhasil di-contain, saatnya menghilangkan penyebabnya. Ini bisa berarti: menghapus malware dan backdoor yang ditinggalin attacker, menutup vulnerability yang dieksploitasi, reset semua password dan credential yang mungkin udah dicuri, dan hardening sistem biar nggak gampang kena lagi. Di tahap ini saya biasanya kerja bareng sama tim forensik buat mastiin nggak ada artifact attacker yang tersisa.

Recovery — Kembali ke Normal dengan Hati-Hati

Ini fase mengembalikan sistem ke operasi normal. Tapi jangan buru-buru! Pastiin semua backdoor udah dibersihin, semua vulnerability udah ditambal, dan monitoring udah diperketat sebelum sistem dinyalakan lagi. Recovery harus dilakukan secara bertahap dan dimonitor ketat. Beberapa kali saya ngalamin kasus di mana sistem dinyalakan lagi terlalu cepat, dan attacker ternyata masih punya akses — sehingga mereka tinggal masuk lagi dan bikin kerusakan yang lebih parah.

Lessons Learned — Jangan Ulangi Kesalahan yang Sama

Fase terakhir yang sering banget diskip. Setelah semua reda, duduklah bareng tim. Evaluasi apa yang berjalan baik dan apa yang nggak. Update incident response plan berdasarkan pengalaman. Identifikasi root cause dan pastiin itu nggak akan terjadi lagi. Fase ini yang membedakan organisasi yang mature dari yang immature dalam hal keamanan.

30 Menit Pertama — Checklist Survival Kamu

Oke, sekarang kita masuk ke bagian yang paling praktis. Kamu baru dapet notifikasi bahwa server kena serangan. Apa yang harus kamu lakukan dalam 30 menit pertama? Ini checklist versi saya — hasil kompilasi dari puluhan insiden yang udah saya tangani:

Menit 0-5: JANGAN PANIK — dan Jangan Sentuh Apa pun

Serius. Ini langkah yang paling penting. Panik adalah musuh terbesar di incident response. Begitu panik, kamu bakal ngambil keputusan buru-buru yang seringkali bikin keadaan makin parah. Tarik napas dalam-dalam. Tenangin diri sendiri dulu. Lalu: JANGAN SENTUH SERVER. Jangan restart. Jangan shutdown. Jangan login buat “ngecek-ngecek”. Jangan hapus file yang mencurigakan. Jangan matiin network interface. Jangan ngapa-ngapain dulu.

Kenapa? Karena setiap tindakan yang kamu lakukan di server itu menghancurkan bukti digital. Restart server = RAM hilang. Login dan jalankan command = timestamps berubah, log files termodifikasi. Hapus file mencurigakan = bukti utama hilang. Intinya: di tahap awal, server yang kena serangan adalah crime scene. Perlakukan seperti itu.

Menit 5-15: Kumpulin Bukti Volatil Sambil Ngopi

Nah, setelah tenang, sekarang saatnya ngumpulin bukti yang sifatnya volatile — data yang bakal hilang begitu sistem mati atau restart. Prioritas utama:

1. Memory dump (RAM). Pakai LiME di Linux atau winpmem/DumpIt di Windows. RAM adalah tambang emas bukti forensik.
2. Daftar proses yang sedang berjalan (ps aux, tasklist). Catat semua.
3. Network connections yang aktif (netstat -ano, ss -tlnp). Siapa yang terkoneksi ke mana?
4. User yang sedang login (who, w, qwinsta).
5. Scheduled tasks dan cron jobs (crontab -l, schtasks).
6. File yang baru dimodifikasi dalam 24 jam terakhir (find / -mtime -1).
7. Log files yang relevan — copy dulu, jangan cuma baca. Copy ke external storage yang aman.

Tools yang saya biasanya pakai buat ngumpulin data volatil dengan cepat: script custom (saya punya bash script untuk Linux dan batch script untuk Windows), atau tools kayak FastIR Collector, CyLR, atau KAPE (buat Windows).

Menit 15-25: Isolasi — Tapi Jangan Putuskan Semua Koneksi

Ini bagian yang tricky. Kamu perlu meng-isolasi sistem yang kena supaya serangan nggak menyebar — tapi kamu juga nggak mau memutuskan koneksi sepenuhnya karena bisa jadi attacker sadar dan menghapus jejak mereka. Strategi yang saya rekomendasikan:

Untuk server yang jelas-jelas kena: lakukan network isolation di level switch atau firewall. Block semua traffic inbound dan outbound KECUALI traffic yang kamu perlukan untuk investigasi. Jangan shutdown server-nya — biarkan nyala supaya memory dump dan data volatil masih bisa diambil. Kalau memungkinkan, bikin snapshot atau forensic image dulu sebelum melakukan tindakan containment agresif.

Untuk sistem lain dalam network yang sama: segera periksa apakah ada indikasi lateral movement. Cek log dari SIEM, IDS/IPS, dan EDR. Kalau ada indikasi bahwa attacker udah pindah ke sistem lain, isolasi juga sistem-sistem tersebut.

Menit 25-30: Dokumentasi dan Eskalasi

Dokumentasikan semuanya. Bikin timeline kasar: jam berapa dapat notifikasi, dari mana, apa yang udah kamu lakukan sejauh ini, apa temuan sementara. Ini penting bukan cuma buat laporan nanti, tapi juga buat memastikan nggak ada langkah yang kelewat. Di dunia nyata, incident response itu chaotic — banyak banget yang terjadi dalam waktu singkat. Tanpa dokumentasi yang baik, kamu bakal lupa apa yang udah dan belum kamu lakukan.

Lalu: eskalasi. Siapa yang perlu tahu tentang insiden ini? IT manager? CTO? CEO? Legal team? PR team? Tergantung seberapa parah insidennya, tapi pastiin komunikasi berjalan dengan baik. Satu kesalahan klasik: tim teknis sibuk nanganin insiden sendirian, sementara management nggak tahu apa-apa sampai akhirnya baca di berita.

Kesalahan Fatal yang Sering Saya Temui di Lapangan

Setelah bertahun-tahun nanganin insiden, ini daftar kesalahan paling umum yang saya lihat — dan hampir selalu berakibat fatal:

Merestart atau Mematikan Server yang Kena Serangan

Ini juara satu. Hampir 70% kasus yang saya tangani, reaksi pertama dari sysadmin adalah: “sudah saya restart tuh server”. Dan tiap kali denger kalimat itu, hati saya rasanya mau copot. Kenapa restart itu buruk? Karena begitu server restart, semua bukti di RAM hilang. Proses malware yang berjalan hilang. Network connections hilang. Timeline kejadian jadi kacau karena semua log restart. Dan yang paling parah: beberapa malware justru punya persistence mechanism yang di-trigger saat boot — jadi restart malah mengaktifkan kembali malware yang tadinya mungkin bisa dideteksi.

Login Pakai Akun yang Sama

Attacker bisa jadi udah punya akses ke credential admin. Kalau kamu login pake akun yang sama, attacker bisa ngeliat aktivitas kamu — atau lebih parah lagi, pake session kamu buat melakukan hal-hal yang menjerat kamu. Selalu pakai akun investigasi terpisah yang dibuat khusus untuk incident response.

Menghapus File Mencurigakan Tanpa Dokumentasi

“Ada file aneh nih, saya hapus aja ya.” NO. JANGAN. File yang mencurigakan adalah bukti. Hapus file = hancurkan bukti. Kalau kamu nggak sengaja menghapus malware yang jadi kunci buat memahami attack vector-nya, investigasi kamu bakal mentok. Kalau kamu harus menghapus file (misalnya untuk menghentikan malware yang sedang aktif), lakukan dengan sangat hati-hati: copy dulu ke storage terpisah, hitung hash-nya, dokumentasikan lokasi aslinya, baru hapus.

Tidak Mengamankan Log Server

Server yang kena serangan masih nyala. Log masih nulis ke disk yang sama. Attacker masih bisa menghapus atau memodifikasi log. Kalau kamu nggak segera mengamankan log (copy ke server terpisah atau forward ke SIEM), kamu berisiko kehilangan bukti paling krusial. Saya selalu rekomendasikan: begitu insiden terdeteksi, prioritas kedua setelah memory dump adalah mengamankan log files.

Langsung Patching Tanpa Investigasi

“Kayaknya vulnerability dari plugin X nih, langsung di-patch aja.” Hati-hati. Patching sebelum investigasi selesai bisa menghilangkan jejak bagaimana attacker masuk. Kalau ada kerentanan, attacker mungkin ninggalin artifact spesifik yang cuma bisa ditemukan dengan menganalisis sistem yang belum di-patch. Patch boleh — tapi setelah bukti cukup terkumpul.

Kapan Kamu Harus Memanggil Bantuan Profesional

Ini keputusan yang berat, tapi penting. Ada situasi di mana lebih baik mengakui keterbatasan dan memanggil bantuan profesional, daripada nekad nanganin sendiri dan bikin keadaan makin parah. Indikator bahwa kamu perlu bantuan eksternal:

1. Kamu nggak yakin apa yang terjadi atau gimana cara nanganinya. Nggak ada salahnya mengakui ini.
2. Serangannya kompleks — melibatkan banyak sistem, ada indikasi data breach besar, atau melibatkan ransomware.
3. Ada potensi implikasi hukum — pelanggaran regulasi (UU PDP, GDPR), potensi tuntutan dari pihak ketiga, atau kemungkinan kasus akan masuk ke ranah hukum.
4. Kamu nggak punya resource atau expertise internal yang cukup. Incident response yang efektif butuh tim yang dedicated — bukan sysadmin yang ngerjain ini sambil ngerjain tugas harian.

Kalau kamu mutusin untuk manggil bantuan profesional, pilih tim yang punya track record jelas. Banyak yang ngaku-ngaku bisa incident response tapi sebenernya cuma jago ngomong. Tanya: udah berapa kasus yang pernah ditangani? Ada referensi? Pake metodologi apa? Punya sertifikasi yang relevan (GCFA, GNFA, CISSP)?

Basic Incident Response Toolkit — Yang Harus Ada di Laptop Kamu

Buat kamu yang serius pengen belajar incident response, ini toolkit dasar yang saya rekomendasikan untuk disiapin di laptop investigasi kamu:

1. Laptop investigasi terpisah — jangan pakai laptop sehari-hari. Laptop ini harus bersih, minimal install, dan nggak dipakai buat kegiatan lain.
2. Write blocker — hardware (rekomendasi: Tableau) atau software. Wajib buat ngakses disk bukti.
3. Forensic imaging tools — FTK Imager (gratis, GUI-friendly), Guymager (Linux), dd/dcfldd (built-in Linux).
4. Memory capture tools — LiME (Linux), winpmem/DumpIt (Windows), Magnet RAM Capture (gratis).
5. Live response scripts — siapin script yang bisa ngumpulin data volatil dengan cepat. Bisa bikin sendiri atau pakai yang udah ada kayak FastIR Collector, CyLR, atau KAPE.
6. Log analysis tools — grep/awk/sed (built-in), LogParser (Windows), jq (buat JSON logs).
7. Network capture tools — Wireshark, tcpdump, NetworkMiner.
8. USB drive yang udah diformat bersih — buat nyimpen hasil capture sementara, pastiin udah di-wipe dan diformat sebelum dipakai.
9. Checklist dan template dokumentasi — jangan ngandelin ingatan. Punya checklist tertulis buat setiap fase IR.
10. Power bank dan kabel-kabel — karena insiden sering terjadi di saat yang nggak nyaman, dan baterai laptop habis adalah musuh.

Penutup — Tenang adalah Senjata Utama

Incident response langkah pertama yang kamu ambil saat server kena serangan itu benar-benar bisa jadi pembeda antara insiden kecil yang bisa di-handle dalam hitungan jam, atau bencana besar yang jadi headline berita nasional. Setelah 8 tahun lebih di dunia ini, pelajaran paling berharga yang saya dapet bukan tentang tools canggih atau teknik mutakhir — tapi tentang pentingnya tetap tenang di bawah tekanan. Tetap sistematis di tengah chaos. Dan tetap rendah hati untuk mengakui kalau kita butuh bantuan.

Ingat: server yang kena serangan adalah crime scene. Perlakukan dengan hormat. Setiap bit data di dalamnya mungkin adalah saksi bisu yang bisa mengungkap apa yang sebenarnya terjadi. Tugas kamu bukan cuma membenahi sistem — tapi juga mengumpulkan dan menjaga bukti, supaya kalau nanti kasusnya sampai ke pengadilan, apa yang kamu lakukan di 30 menit pertama itu nggak jadi bumerang yang malah menjerat diri sendiri.

Dan kalau suatu saat kamu dapet telepon jam 2 pagi yang bikin jantung copot — ingat pesan saya ini: tarik napas, cuci muka pake air dingin, jangan sentuh server dulu, dan mulai dengan tenang. Kamu pasti bisa.