Website Kena Hack: Langkah Pertama Dalam 60 Minit

Pemilik laman yang menaip website kena hack ke dalam enjin carian biasanya tidak berada dalam keadaan tenang. Dia baru perasan halaman yang tidak pernah ditulis muncul dalam hasil carian, atau pelawat menghantar mesej bertanya mengapa laman memaparkan iklan pelik. Naluri pertama ialah memadam sesuatu. Naluri itu selalunya memusnahkan bukti yang paling berguna.

Artikel ini menyusun tindakan untuk sejam pertama. Ia bukan panduan forensik penuh dan bukan janji bahawa laman pulih dalam 60 minit. Ia satu urutan yang menghalang tiga kesilapan mahal: memadam bukti, memutuskan sambungan yang masih diperlukan, dan memberitahu pelanggan sebelum tahu apa yang sebenarnya berlaku.

Satu perkara perlu jelas di depan. Laman yang diceroboh bukan masalah teknikal semata-mata, ia masalah kepercayaan. Setiap jam yang berlalu tanpa rekod yang kemas menjadikan pemulihan lebih mahal, dan menjadikan penjelasan kepada pelanggan lebih sukar.

Enam tanda laman sudah diceroboh

Kebanyakan pemilik laman tidak menemui pencerobohan melalui alat keselamatan. Mereka menemuinya melalui sesuatu yang pelik. Semak enam perkara di bawah satu per satu, dan catat apa yang dijumpai berserta tarikh dan masa. Catatan itu menjadi asas kepada semua langkah selepas ini.

• ▸ Hasil carian memaparkan halaman yang tidak pernah dibuat. Judul pelik, pautan ke laman kasino, farmasi atau pinjaman, dan kadang-kadang dalam bahasa yang tidak digunakan pada laman anda.
• ▸ Pelawat dialihkan ke domain lain, atau laman memaparkan kandungan kosong hanya untuk pengunjung dari enjin carian. Pengalihan mengikut ejen pengguna ialah teknik biasa untuk menyembunyikan suntikan daripada pemilik laman.
• ▸ Amaran dalam Google Search Console atau amaran merah dalam pelayar. Ini bermakna Google sudah mengesan kandungan berbahaya, bukan sekadar mengesyaki.
• ▸ Fail baharu dalam folder muat naik atau folder cache, terutamanya fail .php, .phtml atau .js yang tidak sepatutnya berada di situ. Semak tarikh ubah suai, bukan nama fail, kerana nama fail sering ditukar supaya kelihatan biasa.
• ▸ Akaun pentadbir baharu, alamat e-mel pentadbir yang berubah, atau tetapan laman yang berubah sendiri seperti URL laman dan zon waktu.
• ▸ E-mel keluar dari domain anda yang tidak anda hantar, atau trafik keluar yang luar biasa. Server yang digunakan untuk menghantar spam biasanya dikesan oleh penyedia hosting sebelum pemilik laman tahu apa-apa.

Jika dua tanda atau lebih muncul serentak, anggap ia pencerobohan yang disahkan sehingga dibuktikan sebaliknya. Jangan tunggu tanda ketujuh.

Tiga perkara yang jangan dibuat dalam sepuluh minit pertama

Tindakan panik memusnahkan bukti lebih kerap daripada ia menyelesaikan masalah. Empat larangan di bawah bukan soal adat, ia soal bahawa setiap satunya menutup jalan pemulihan yang lebih murah.

• ▸ Jangan padam fail atau direktori. Fail yang disuntik ialah bukti, dan tarikh ubah suainya menunjukkan bila pencerobohan bermula. Salin dahulu, kemudian baharu buang.
• ▸ Jangan terus muat semula CMS dan memasang semula semua plugin. Jika punca sebenar ialah akaun pengguna yang dicuri atau pangkalan data yang disuntik, pemasangan semula hanya menyembunyikan gejala selama beberapa hari.
• ▸ Jangan hantar pengumuman kepada semua pelanggan sebelum skop diketahui. Mesej yang menyebut keseluruhan laman digodam, sedangkan hanya satu folder terjejas, mencipta krisis yang lebih besar daripada masalah asal.
• ▸ Jangan hubungi nombor telefon dalam tetingkap amaran yang muncul pada laman anda sendiri. Tetingkap yang menyuruh anda menelefon pihak sokongan hampir selalu sebahagian daripada penipuan, bukan amaran sebenar.

Urutan 60 minit: sahkan, sandar, asingkan, bersih, kuatkan

Urutan ini boleh disiapkan oleh pemilik laman bersama penyedia hosting dalam masa sejam jika keputusan dibuat awal. Setiap langkah menghasilkan sesuatu yang boleh ditunjukkan kepada pelanggan, dan itu mengurangkan tekanan semasa kerja berjalan.

• ▸ Minit 0 hingga 10, sahkan dan catat. Buka log akses, ambil tangkapan skrin amaran Google, dan senaraikan fail yang mencurigakan. Jangan buat apa-apa lagi.
• ▸ Minit 10 hingga 20, sandarkan. Salin semua fail dan eksport pangkalan data ke komputer di luar pelayan. Jangan gantikan sandaran lama, simpan sebagai salinan baharu bertarikh. Salinan ini ialah bukti, bukan untuk dipulihkan terus pada pelayan yang sudah diceroboh.
• ▸ Minit 20 hingga 30, asingkan. Tukar kata laluan pentadbir CMS, panel hosting, FTP dan e-mel. Batalkan semua sesi aktif, buang kunci API yang terdedah, dan tutup pendaftaran pengguna awam jika ada.
• ▸ Minit 30 hingga 50, cari punca. Bandingkan fail dengan salinan asal, semak log untuk permintaan POST berulang ke halaman log masuk, dan cari fail yang dimuat naik melalui borang, bukan melalui FTP.
• ▸ Minit 50 hingga 60, bersihkan yang disahkan dan kuatkan asas. Buang kod yang disuntik, kemas kini CMS dan plugin, hidupkan pengesahan dua langkah, dan pasang sekatan percubaan log masuk.

Log akses menjawab soalan yang paling penting: bagaimana mereka masuk. Contoh di bawah menunjukkan bentuk yang perlu dicari. Alamat IP yang digunakan ialah alamat contoh untuk dokumentasi, bukan log sebenar.

198.51.100.24 - - [12/10/2026:03:14:22 +0800] "POST /wp-login.php HTTP/1.1" 200 4213 "-" "python-requests/2.31"
198.51.100.24 - - [12/10/2026:03:14:25 +0800] "POST /wp-login.php HTTP/1.1" 200 4213 "-" "python-requests/2.31"
203.0.113.77 - - [12/10/2026:03:15:02 +0800] "GET /wp-content/uploads/2026/10/cache.php HTTP/1.1" 200 512 "-" "Mozilla/5.0"

Dua baris pertama menunjukkan cubaan log masuk berulang dari satu alamat dalam jarak tiga saat, dengan ejen pengguna skrip dan bukan pelayar biasa. Baris ketiga menunjukkan fail .php yang diminta terus dari folder muat naik. Gabungan kedua-duanya menerangkan urutan yang kerap berlaku: tekaan kata laluan berjaya, kemudian shell dimuat naik, kemudian ia dipanggil terus melalui pelayar.

Pola yang sama kelihatan pada pelayan nginx dan Apache, hanya bentuk barisnya berbeza. Yang penting bukan format, tetapi tiga medan: masa, laluan, dan kod jawapan. Permintaan POST berulang dengan kod 200 pada halaman log masuk sudah cukup untuk mencurigakan seorang pemilik laman tanpa alat khas.

Bila patut matikan laman dan bila tidak

Keputusan menutup laman ialah keputusan perniagaan, bukan keputusan teknikal. Menutupnya melindungi pelawat, tetapi ia juga menghentikan jualan dan boleh menjejaskan kedudukan carian untuk beberapa minggu selepas pulih.

• ▸ Tutup jika laman menyebarkan malware kepada pelawat, memproses bayaran, atau digunakan untuk menghantar spam dalam jumlah besar. Dalam kes ini setiap jam tambahan ialah risiko kepada orang lain, bukan hanya kepada anda.
• ▸ Jangan tutup sepenuhnya jika hanya satu bahagian terjejas. Halaman ralat 503 pada laluan tertentu, sementara halaman produk kekal hidup, biasanya cukup dan lebih murah dari segi jualan.
• ▸ Jika data peribadi pelanggan terjejas, ia isu undang-undang, bukan sekadar isu laman. Pindaan Akta Perlindungan Data Peribadi 2010 yang diluluskan pada 2024 memperkenalkan kewajipan pemberitahuan pelanggaran data bagi kes tertentu. Semak laman rasmi Jabatan Perlindungan Data Peribadi untuk keperluan yang berkuat kuasa, dan dapatkan nasihat sebelum membuat kenyataan awam.

Selepas pembersihan, Google perlu menyemak semula laman sebelum amaran dibuang. Masa semakan bukan di tangan anda. Janji tarikh kepada pelanggan sepatutnya dibuat secara berhati-hati, dan lebih baik dinyatakan sebagai jangkaan daripada tarikh.

Bukti yang perlu dikumpul sebelum membersihkan

Bukti yang dikumpul awal menjimatkan wang kemudian. Ia juga membezakan pembersihan yang benar-benar selesai daripada pembersihan yang hanya menutup gejala.

• ▸ Log akses mentah sekurang-kurangnya 30 hari, termasuk log ralat pelayan web. Ini menjawab bila dan bagaimana.
• ▸ Senarai fail yang diubah suai dalam tempoh 14 hari sebelum tanda pertama, berserta saiz dan tarikh ubah suai.
• ▸ Eksport senarai pengguna CMS berserta tarikh log masuk terakhir, dan senarai alamat IP pentadbir.
• ▸ Tangkapan skrin amaran Google Search Console dan contoh URL yang ditandakan.
• ▸ Salinan pangkalan data sebelum dibersihkan, disimpan di luar pelayan.

Simpan semua ini dalam satu folder bertarikh di komputer luar. Jika laman membabitkan data pelanggan, bukti yang sama diperlukan untuk laporan kepada Pesuruhjaya Perlindungan Data Peribadi dan untuk tuntutan insurans jika ada. Menyimpannya dalam pelayan yang sama bermakna ia hilang bersama masalah yang cuba anda selesaikan.

Apa yang perlu diberitahu kepada pelanggan, dan bila

Pemberitahuan yang baik dibuat selepas pengesahan, bukan selepas andaian. Ia menjawab empat soalan mengikut urutan itu: apa yang berlaku, apa yang terjejas, apa yang tidak terjejas, dan apa yang sedang dilakukan.

• ▸ Beritahu sebaik sahaja disahkan, bukan selepas pembersihan selesai. Pelanggan yang tahu lebih awal boleh menukar kata laluan mereka sendiri dan memantau akaun.
• ▸ Nyatakan apa yang tidak terjejas jika anda benar-benar tahu. Ayat yang menyelamatkan kepercayaan ialah ayat yang tepat, bukan ayat yang menenangkan.
• ▸ Jangan janji tarikh pulih yang belum disahkan oleh penyedia hosting atau oleh Google.
• ▸ Jika laman menerima bayaran, beritahu pembekal gerbang bayaran dan tukar kunci API segera. Kunci yang terdedah ialah risiko kepada pelanggan, bukan hanya kepada anda.

Selepas pulih: lapan kawalan supaya tidak berulang

Pembersihan tanpa perubahan amalan hanya membeli masa. Lapan kawalan di bawah ialah asas yang menjadikan pencerobohan seterusnya lebih sukar dan, yang lebih penting, lebih mudah dikesan pada hari pertama.

• ▸ Kemas kini CMS, plugin dan tema, dan buang yang tidak digunakan. Plugin yang tidak diaktifkan tetapi masih ada dalam pelayan masih boleh dieksploitasi.
• ▸ Pengesahan dua langkah untuk semua akaun pentadbir, termasuk panel hosting dan e-mel.
• ▸ Kata laluan unik yang disimpan dalam pengurus kata laluan, bukan dikongsi melalui aplikasi pesanan.
• ▸ Hadkan percubaan log masuk dan sekat alamat IP yang berulang gagal.
• ▸ Kebenaran fail yang betul: fail 644, direktori 755, dan tiada 777 dalam mana-mana folder.
• ▸ Sandaran automatik di luar pelayan, dengan satu ujian pemulihan sebenar setiap suku tahun.
• ▸ Pemantauan integriti fail, supaya perubahan pada fail teras dilaporkan dalam masa sejam, bukan selepas pelawat mengadu.
• ▸ Semakan bulanan Search Console dan pemberitahuan penyedia hosting, supaya amaran awal tidak tersembunyi dalam e-mel yang tidak dibaca.

Bila perlu melibatkan orang luar

Sebahagian kes boleh diselesaikan oleh pemilik laman bersama penyedia hosting dalam satu petang. Kes lain memerlukan orang yang biasa membaca log dan membersihkan pangkalan data yang disuntik: laman e-dagang, laman yang menyimpan data pelanggan, atau laman yang sudah dibersihkan dua kali dan kembali terjangkit.

Kos pembersihan bergantung pada skop, dan skop hanya diketahui selepas log dibaca. Untuk kerja pembangunan dan pemulihan laman, RM1,000 ialah titik mula projek dan selebihnya ditentukan oleh skop. Untuk pemantauan bulanan, pakej SEO Panel ialah RM39 sebulan. Angka lain tidak sepatutnya disebut sebelum siasatan selesai, dan sesiapa yang memberi harga tetap sebelum melihat log sedang meneka.

Kalau laman anda sekarang menunjukkan tanda-tanda dalam senarai di atas, hantar URL dan tangkapan skrin sebelum memadam apa-apa. Butiran awal itu menjimatkan berjam-jam kerja kemudian, dan ia sering membezakan antara pembersihan sehari dengan pemulihan seminggu.