Apa yang Perlu Dilakukan Apabila Laman Web Anda Digodam, Mengikut Susunan yang Betul

Tahan Dorongan untuk Terus Membersihkannya

Naluri apabila anda mendapati laman web telah digodam ialah membaikinya secepat mungkin — padam fail-fail pelik yang anda nampak, pasang semula WordPress core, jadikan laman itu kelihatan normal semula sebelum sesiapa perasan. Jika diikuti dalam susunan itu, naluri itu adalah satu kesilapan. Memadam dahulu memusnahkan bukti yang anda perlukan untuk mengetahui bagaimana penyerang masuk, yang bermakna anda mungkin akhirnya membersihkan laman yang sama dua kali, berselang seminggu atau sebulan, kerana titik masuk sebenar tidak pernah ditutup. Ada susunan yang betul untuk ini, dan ia bermula dengan melambatkan langkah, bukan mempercepatkannya.

Langkah 1: Asingkan Laman Tanpa Memadam Apa-apa

Keluarkan laman itu daripada pandangan awam dahulu — maintenance mode, menyekat akses pada peringkat server, atau menudingkan domain ke tempat lain buat sementara waktu — tetapi jangan mula membuang fail lagi. Matlamat pada peringkat ini ialah menghentikan kerosakan daripada merebak atau menjadi lebih teruk (lebih banyak halaman spam diindeks, lebih ramai pelawat dihidangkan malware, lebih banyak reputasi server anda terbakar dengan host dan blocklist), bukan untuk membersihkan apa-apa. Isolasi dan pembersihan adalah dua langkah yang berbeza, dan langkah kedua hanya berfungsi dengan betul sebaik sahaja anda selesai langkah di bawah.

Langkah 2: Ambil Snapshot Penuh Sebelum Menyentuh Apa-apa

Salin keseluruhan laman — setiap fail dan database penuh — tepat seperti keadaannya semasa compromise, dan simpan salinan itu di tempat yang berasingan daripada server live. Ini adalah bukti anda. Inilah yang membolehkan anda membandingkan "sebelum" dan "selepas" apabila anda mula membersihkan, dan inilah yang anda perlukan jika anda perlu mengetahui dengan tepat apa yang telah dicapai. Bersama salinan fail, ambil apa-apa sahaja log akses server dan error log yang host anda berikan. Ini selalunya menunjukkan mekanik sebenar pencerobohan — corak request yang luar biasa, lonjakan percubaan log masuk yang gagal, satu upload fail pada waktu yang ganjil — yang hilang sebaik sahaja anda mula memadam benda. Panduan pembersihan Sucuri sendiri dibina berdasarkan susunan yang sama ini: backup keadaan yang compromised, kemudian kenal pasti apa yang berubah, sebelum membuang apa-apa.

Langkah 3: Tukar Semua Credential yang Anda Ada

Sebaik sahaja seseorang mempunyai akses peringkat fail atau peringkat database ke server anda, anggap setiap credential yang tersimpan di mana-mana sahaja pada laman itu sebagai telah dibaca. Itu bermaksud: password admin WordPress, password database, credential hosting control panel dan SFTP/SSH, dan mana-mana API key yang berada dalam wp-config.php atau dalam setting plugin. Tukar (rotate) kesemuanya, bukan sekadar password admin WordPress sahaja — reset password wp-admin sahaja tidak berguna jika penyerang turut mempunyai credential database anda atau login SFTP anda. Jika mana-mana perkhidmatan pihak ketiga disambungkan (payment gateway, email provider, marketing tool), batalkan dan keluarkan semula token tersebut juga.

Langkah 4: Cari Titik Masuk Sebelum Membersihkan

Ini adalah langkah yang paling kerap dilangkau, dan ia adalah langkah yang sebenarnya menghalang pengulangan berlaku. Bandingkan timestamp pengubahsuaian fail dengan backup terakhir yang diketahui baik (known-good) atau sejarah deployment anda untuk melihat apa yang berubah, dan bila. Rujuk silang tarikh itu dengan changelog plugin dan theme anda — banyak compromise boleh dikesan kembali kepada satu vulnerability tertentu yang telah didedahkan pada versi plugin tertentu. Semak apa-apa yang kelihatan seperti persistence: akaun Administrator yang tidak dikenali, scheduled task atau cron job yang tidak dijangka, plugin yang anda tidak ingat pernah pasang. Panduan Google sendiri untuk laman yang digodam menunjukkan arah yang sama, mengesyorkan semakan log server untuk anomali seperti corak log masuk gagal yang luar biasa dan akaun pengguna yang tidak dikenali sebagai sebahagian daripada memahami apa yang berlaku sebelum membersihkan.

Jika anda melangkau langkah ini dan terus ke pembersihan, anda sebenarnya membuang gejala sahaja sambil membiarkan vulnerability sebenar itu kekal — dan satu automated scan berkemungkinan besar akan menjumpainya semula.

Langkah 5: Bersihkan atau Bina Semula — Kini Anda Tahu Apa yang Sedang Dibaiki

Terdapat dua laluan yang realistik, dan yang mana satu anda ambil bergantung kepada apa yang anda ada. Jika anda mempunyai backup yang diambil sebelum compromise dan anda yakin ia lebih awal daripada jangkitan itu, me-restore daripadanya biasanya pilihan yang paling cepat dan paling bersih. Jika tidak, atau anda perlu mengekalkan data yang dicipta sejak itu, laluan manual bermaksud membandingkan fail core WordPress anda dengan muat turun rasmi yang baharu, dan menyemak fail custom atau premium satu demi satu untuk membuang kod yang disuntik (injected) — proses yang sama seperti yang diterangkan secara terperinci dalam panduan Sucuri. Walau apa pun, langkah ini hanya berlaku selepas Langkah 4: tutup vulnerability tertentu yang anda temui sebelum membawa laman itu kembali online, bukan selepasnya.

Langkah 6: Mohon Semakan — Tanpa Garis Masa yang Terjamin

Jika laman anda menunjukkan laporan Security Issues dalam Google Search Console, atau amaran Safe Browsing kepada pelawat, mohon semakan hanya sebaik sahaja laman itu benar-benar bersih di semua halaman yang terjejas dan vulnerability itu telah ditutup. Panduan Search Console sendiri jelas menyatakan bahawa "membaiki isu itu pada sebahagian halaman sahaja tidak akan memberikan anda pemulangan separa ke dalam hasil carian," dan menghantar semula permintaan semasa satu lagi masih pending boleh melambatkan keseluruhan proses berbanding mempercepatkannya.

Tentang masa: tiada turnaround tetap yang Google komited kepadanya. Sesetengah laporan menerangkan kes yang mudah dan disahkan bersih selesai dalam kira-kira 72 jam; dokumentasi Google Search Console sendiri menyatakan kebanyakan semakan reconsideration mengambil masa beberapa hari hingga beberapa minggu, dan kes yang lebih kompleks atau berulang boleh mengambil masa lebih lama lagi. Jangan janjikan pelanggan — atau diri sendiri — satu tarikh tertentu. Rancang berdasarkan "sebaik sahaja ia benar-benar bersih," bukan "menjelang Jumaat."

Kenapa Susunan Lebih Penting Berbanding Kelajuan

Setiap langkah di atas wujud untuk melindungi maklumat yang anda perlukan untuk langkah selepasnya. Padam dahulu, dan anda kehilangan log yang sepatutnya memberitahu anda titik masuk. Langkau langkah titik masuk, dan anda membersihkan laman yang masih terdedah kepada serangan yang sama persis. Mohon semakan sebelum anda benar-benar selesai, dan anda membazir masa menunggu semakan yang memang tidak akan lulus. Mengikut susunan ini lebih perlahan pada hari pertama tetapi jauh lebih cepat secara keseluruhan.

---

Sebaik sahaja laman itu kembali online dan kebakaran segera itu telah dipadam, ia berbaloi untuk satu pandangan kedua yang lebih tenang bagi mengesahkan vulnerability itu benar-benar telah ditutup dan tiada apa yang tertinggal — itulah tujuan Essential System Review kami: RM1,500 (RM999 sehingga 16 September 2026), satu audit teknikal harga tetap dengan laporan bertulis. Jika anda lebih suka monitoring berterusan supaya isu seterusnya dapat dikesan sebelum ia menjadi insiden penuh, JagaWeb Care bermula dari RM450 sebulan.