Memilih Cek Dangling DNS atau Celah CMS Saat Subdomain Kena Deface

Saat menerima tiket pengaduan bahwa salah satu subdomain menampilkan halaman judi online atau pesan peretasan, reaksi pertama kebanyakan staf teknis adalah membuka terminal server, mengecek daftar proses, dan menyisir folder webroot dengan pemindai malware. Langkah ini wajar karena sebagian besar kasus defacement memang berakar dari file upload yang bocor atau plugin lama yang dieksploitasi. Namun, tidak jarang kita mendapati file server bersih tanpa jejak modifikasi sama sekali, sementara saat dibuka di browser publik tampilannya nyata-nyata telah dibobol. Kondisi membingungkan tersebut biasanya terjadi karena kita melompati satu tahap mendasar dalam triase awal, yaitu memastikan di server mana request tersebut sebenarnya mendarat. Ada perbedaan besar antara peretasan pada level aplikasi web lokal dan pembajakan record DNS yang terbengkalai atau dangling DNS. Memahami perbedaan keduanya dalam lima menit pertama penyelidikan akan menghemat waktu berjam-jam dari memeriksa server yang sebenarnya tidak bersalah.

Analogi Sederhana: Pintu Rumah Dibobol vs Papan Petunjuk Diubah

Bayangkan kamu memiliki gedung kantor utama dan sebuah papan petunjuk jalan kayu di depan gang yang mengarahkan tamu ke paviliun sewaan di seberang jalan untuk urusan acara pameran tahun lalu. Ketika acara tersebut selesai, kamu berhenti menyewa paviliun tersebut dan pemilik tanah merobohkannya. Namun, kamu lupa mencabut papan petunjuk di depan gang yang masih tertulis mengarahkan orang ke alamat paviliun lama. Beberapa bulan kemudian, sekelompok orang menyewa tanah kosong bekas paviliun tersebut dan mendirikan lapak ilegal. Siapa pun tamu yang datang mengikuti papan petunjuk resmi milik kantormu akan sampai ke lapak ilegal itu dan mengira itu adalah bagian dari kantormu. Menghabiskan waktu memeriksa CCTV dan mengganti gembok pintu di gedung kantor utamamu tidak akan mengubah fakta bahwa lapak liar tersebut tetap berdiri di seberang jalan. Papan petunjuknyalah yang bermasalah. Dalam dunia hosting, gedung utama adalah server produksimu sendiri tempat CMS terpasang. Paviliun sewaan adalah layanan cloud pihak ketiga, seperti platform hosting statis, penyimpanan file eksternal, atau VPS sementara untuk kegiatan jangka pendek. Ketika proyek selesai dan layanan pihak ketiga ditutup tanpa menghapus record DNS (biasanya CNAME atau A record) yang mengarah ke sana, record tersebut menjadi dangling alias bergelantungan tanpa pemilik. Siapa pun yang kemudian mendaftar di layanan pihak ketiga tersebut dan mengklaim identitas atau nama bucket yang sama dapat mengambil alih subdomain tanpa pernah menyentuh server utamamu.

Membedakan Dua Mekanisme Pembobolan

Untuk menentukan arah investigasi, kita perlu melihat bagaimana kedua model insiden ini bekerja secara teknis di balik layar. Kasus pertama adalah kompromi pada level CMS. Pada skenario ini, subdomain memang mengarah langsung ke IP server web milik kita. Penyerang memanfaatkan celah keamanan perangkat lunak, seperti plugin usang, kelemahan sanitasi input form unggah file, atau kredensial admin yang bocor. Penyerang menulis file baru di direktori publik server kita (misalnya menaruh file index.html bajakan atau webshell tersembunyi) atau memodifikasi entri database. Jalur pencegahan untuk kasus semacam ini pernah kita bahas dalam panduan seputar mencegah web defacement judi online lewat arsitektur read-only filesystem. Tandanya jelas: file di server berubah, timestamp file baru mencurigakan, dan log akses server mencatat request POST berbahaya ke file endpoint aplikasi. Kasus kedua adalah dangling DNS atau subdomain hijacking. Pada skenario ini, integritas server milik kita sebetulnya 100 persen aman. Subdomain yang terkena defacement umumnya merupakan subdomain lawas, misalnya subdomain untuk kegiatan tahunan kampus, kampanye produk yang sudah lewat, atau dokumentasi lama. Di panel DNS utama, subdomain tersebut dihubungkan melalui CNAME ke layanan eksternal. Begitu langganan atau akun di layanan eksternal itu kedaluwarsa atau dihapus oleh pemilik aslinya, rute DNS masih aktif menunjuk ke sana. Penyerang cukup membuat akun baru di penyedia layanan eksternal tersebut, lalu mendaftarkan nama workspace atau bucket yang sama persis dengan tujuan CNAME tadi. Server penyeranglah yang merespons trafik pengunjung, bukan server kita.

Triase Cepat: Baca Header Respons Sebelum Buka SSH

Daripada langsung menjalankan perintah pemindaian malware yang memakan beban I/O server tinggi, triase paling efisien adalah memeriksa respons HTTP awal melalui command line dari komputer lokal kita menggunakan perintah curl.

BASH

curl -ILs -o /dev/null -w 'HTTP Status : %{http_code}
IP Remote   : %{remote_ip}
' https://subdomain.contoh.id

Perintah di atas meminta header dari subdomain dan mencetak alamat IP tujuan yang sebenarnya melayani trafik tersebut. Ambil alamat IP tersebut lalu bandingkan dengan IP server hosting milikmu. Bila IP yang muncul bukan IP server web lokalmu, melainkan deretan IP milik penyedia cloud publik atau CDN yang akunnya sudah tidak kamu kelola, kamu sudah pasti berhadapan dengan dangling DNS. Selain memeriksa IP, perhatikan pula baris header Server: atau header penanda platform yang dikembalikan. Jika server produksimu menjalankan LiteSpeed atau Apache di Linux CentOS/Ubuntu, tetapi respons curl -I mengembalikan header web server proprietary milik penyedia hosting statis global, maka membedah file PHP di cPanel atau VPS tidak ada gunanya. Konten yang tampil di browser disajikan langsung dari infrastruktur penyedia luar tersebut. Penjelasan mendalam mengenai siklus pembersihan record DNS saat mematikan infrastruktur cloud juga dapat kamu pelajari lebih lanjut di artikel tentang menghapus dangling CNAME pada arsitektur cloud.

Kesalahan Umum Saat Menangani Tiket Subdomain Deface

Dalam alur penanganan insiden di meja support, ada beberapa kekeliruan yang berulang kali dilakukan oleh staf teknis karena panik atau terburu-buru:

Memulihkan file cadangan (restore backup) tanpa cek DNS terlebih dahulu. Begitu melihat subdomain menampilkan konten slot online, teknisi langsung melakukan full restore direktori webroot dari cadangan minggu lalu. Tindakan ini membuang waktu unduh dan ekstrak puluhan gigabyte data, padahal konten deface tersebut sama sekali tidak berasal dari file server lokal.
Menghapus folder subdomain di server tetapi membiarkan DNS aktif. Karena mengira subdomain sudah tidak dipakai, teknisi menghapus folder virtual host di cPanel atau Nginx. Jika masalah aslinya adalah dangling DNS, menghapus folder lokal tidak menyelesaikan apa pun karena penyerang tetap menyajikan konten lewat rute DNS yang mengarah ke server luar.
Lupa memeriksa recursive CNAME. Sering kali subdomain A menunjuk ke subdomain B (misalnya event.domain.id CNAME ke event-archive.domain.id), dan subdomain B inilah yang mengarah ke layanan pihak ketiga yang mati. Memeriksa hanya record tingkat pertama kadang mengecoh pandangan kita jika tidak ditelusuri sampai ke IP target paling ujung.
Mengira sertifikat SSL yang valid berarti server lokal aman. Saat ini banyak penyedia cloud pihak ketiga otomatis menerbitkan sertifikat SSL gratis (seperti Let's Encrypt) begitu sebuah domain berhasil diarahkan ke platform mereka. Gembok hijau atau sertifikat HTTPS yang valid pada subdomain yang terbajak bukan bukti bahwa request diproses oleh server kita sendiri.

Langkah Tindakan yang Tepat Berdasarkan Hasil Triase

Setelah melakukan pengecekan ringkas dan mengetahui sumber masalahnya, barulah kita mengambil tindakan perbaikan yang terarah. Jika hasil investigasi membuktikan IP mengarah ke server lokal dan header cocok dengan konfigurasi web server internal kita, fokuskan penanganan pada level CMS. Karantina file yang terinfeksi, audit log akses HTTP pada jam terjadinya perubahan file untuk menemukan titik injeksi, perbarui core CMS dan seluruh plugin, lalu pastikan hak akses folder upload tidak mengizinkan eksekusi script. Sebaliknya, jika hasil menunjukkan bahwa IP mengarah ke layanan pihak ketiga yang sudah ditinggalkan, penanganannya murni berada di level DNS manager. Kamu tidak perlu pusing memeriksa log server lokal. Cukup masuk ke zona DNS otoritatif domain utama, hapus record A atau CNAME yang terbengkalai tersebut, atau arahkan record tersebut kembali ke IP server parkir internal jika subdomain tersebut masih ingin dipertahankan namanya. Setelah TTL (Time To Live) record DNS kedaluwarsa di tingkat resolver, halaman deface akan hilang dengan sendirinya karena penyerang kehilangan rute lalu lintas trafik dari domain utamamu. Menjadikan pengecekan IP tujuan dan respons header sebagai langkah pertama akan mengubah proses penanganan defacement dari tebak-tebakan yang melelahkan menjadi keputusan teknis yang tenang dan presisi.