WordPress digodam: cara periksa dan pulihkan laman tanpa kehilangan kandungan

Laman ini tidak menggunakan WordPress. Namun dalam log nginx yang disimpan sejak 24 September 2026, saya menjumpai 569 permintaan ke laluan khas WordPress seperti wp-login.php, xmlrpc.php dan fail di dalam wp-content. Semuanya dijawab dengan 404, kerana fail itu memang tidak ada di sini. Alamat IP paling aktif dalam senarai itu ialah 168.144.99.251 dengan sepuluh cubaan. Ini bukan serangan yang disasarkan kepada laman saya. Ini mesin yang menyapu seluruh internet, mencuba setiap alamat, setiap hari, tanpa henti.

Kalau anda memiliki laman WordPress, sapuan yang sama berhenti menjadi gangguan dan menjadi risiko sebenar. WordPress menjalankan sekitar 43 peratus laman web di dunia, jadi ia sasaran paling berbaloi untuk penyerang. Wordfence mencatat 2,738 kelemahan baharu dalam sistem itu pada suku pertama 2026, naik 23.7 peratus daripada suku sebelumnya, dan 16 bilion cubaan serangan brute force disekat dalam tempoh yang sama. Berikut ialah urutan kerja yang saya gunakan apabila laman pelanggan digodam, daripada dokumen bukti sampai ke langkah yang menghalang ulangan.

Tanda laman anda sudah digodam

Sebahagian kes jelas kelihatan. Sebahagian lagi senyap, dan yang senyap itu lebih berbahaya.

• ▸ Google atau Microsoft menandakan laman sebagai tidak selamat, dan pelawat melihat amaran merah sebelum sempat membuka halaman.
• ▸ Pautan judi atau farmasi muncul dalam hasil carian untuk nama laman anda, sedangkan anda tidak pernah menulis apa-apa tentangnya.
• ▸ Ada pengguna pentadbir yang anda tidak kenal dalam senarai pengguna WordPress.
• ▸ Pelawat menghantar mesej memberitahu antivirus mereka menyekat laman anda.
• ▸ E-mel keluar dari pelayan anda tanpa anda hantar, dan reputasi penghantaran domain jatuh.
• ▸ Laman menjadi perlahan tiba-tiba kerana skrip penyerang menggunakan kuasa pemproses pelayan.

Kes yang paling sukar dikesan ialah backdoor yang cuma menunggu. Fail PHP kecil di dalam folder muat naik tidak mengubah apa-apa pada halaman hadapan. Ia hanya memberikan penyerang jalan masuk semula selepas anda membersihkan perkara pertama. Kalau anda hanya membaik pulih apa yang kelihatan, laman itu boleh digodam semula dalam beberapa hari.

Langkah satu: dokumen dahulu, jangan padam

Reaksi pertama kebanyakan orang ialah memadam fail yang mencurigakan. Itu menghapuskan bukti yang paling berguna. Sebelum mengubah apa-apa, ambil salinan keadaan semasa, termasuk log pelayan dan pangkalan data, dan simpan salinan itu di luar laman.

# Ambil bukti dahulu, jangan ubah apa-apa
mkdir -p /root/bukti
cp -a /var/log/nginx /root/bukti/log-nginx
tar -czf /root/bukti/fail-$(date +%F).tar.gz /var/www/laman/wp-content
mysqldump -u root laman_wordpress > /root/bukti/db-$(date +%F).sql

Tarikh dan masa penting. Catat bila anda mula perasan, apa yang anda ubah sebelum itu, dan plugin apa yang dipasang dalam minggu sebelumnya. Kalau laman itu milik pelanggan, catatan ini yang membezakan kerja yang kemas daripada tekaan. Ia juga menjadi asas laporan insiden kalau perkara itu berakhir di meja peguam atau di hadapan pengawal selia.

Langkah dua: cari pintu masuk

Selepas bukti disimpan, cari jalan penyerang masuk. Dalam pengalaman saya, puncanya jarang misteri dan hampir selalu salah satu daripada lima perkara ini.

• ▸ Plugin atau tema yang tidak dikemas kini. Ini punca paling kerap, dan biasanya plugin yang sudah lama ditinggalkan pembangunnya.
• ▸ Kata laluan pentadbir yang lemah. Serangan brute force tidak berhenti, dan had cubaan log masuk selalunya tiada langsung.
• ▸ xmlrpc.php yang dibiarkan terbuka. Ia membenarkan beribu cubaan kata laluan dihantar dalam satu permintaan sahaja.
• ▸ Tema atau plugin nulled yang dimuat turun percuma dari laman tidak rasmi. Kod penyerang biasanya sudah dimasukkan sebelum anda pasang.
• ▸ Kredensial yang dikongsi. Akaun panel hosting yang digunakan oleh lima orang, atau kata laluan yang sama digunakan di tempat lain.

Kadangkala puncanya bukan apa yang anda pasang, tetapi teras WordPress sendiri. Pada 17 Julai 2026, pasukan keselamatan WordPress mengeluarkan tampalan untuk dua kelemahan yang boleh digabungkan penyerang tanpa perlu log masuk. Yang pertama, CVE-2026-60137, suntikan SQL tanpa pengesahan. Yang kedua, CVE-2026-63030, kekeliruan laluan dalam permintaan kelompok REST API. Digabungkan, kedua-duanya membenarkan penyerang mencipta akaun pentadbir sendiri, kemudian memasang plugin yang mengandungi kodnya.

Versi terjejas ialah 6.8 hingga 6.8.5, 6.9 hingga 6.9.4, dan 7.0 hingga 7.0.1. Versi yang telah ditampal ialah 6.8.6, 6.9.5 dan 7.0.2. Wordfence menyatakan ia menyekat lebih 11 juta cubaan eksploitasi terhadap kelemahan ini. WordPress mengeluarkan kemas kini automatik paksa untuk kes ini, jadi kalau laman anda membenarkan kemas kini automatik, kemungkinan besar ia sudah selamat. Kalau kemas kini automatik dimatikan, sekarang masa untuk memeriksanya.

Langkah tiga: semak fail teras dengan checksum

Fail teras WordPress sepatutnya sama seperti yang dikeluarkan pasukan WordPress. Kalau ada perbezaan, itu fail yang telah diubah orang lain. Ada dua cara memeriksanya, satu dengan alat baris arahan WordPress, satu lagi dengan membandingkan terus dengan repositori rasmi.

# Cara satu, dengan WP-CLI
wp core verify-checksums --version=7.0.2

# Cara dua, bandingkan dengan repositori rasmi
svn diff https://core.svn.wordpress.org/tags/7.0.2/ /var/www/laman

Apa yang alat ini tidak beritahu. Ia tidak memeriksa plugin dan tema pihak ketiga, kerana setiap satu mempunyai kod sendiri. Ia juga tidak memeriksa apa-apa di dalam wp-content, iaitu tempat kebanyakan backdoor disimpan. Jadi checksum yang bersih bukan bukti laman bersih. Ia hanya bermakna teras WordPress tidak disentuh.

Langkah empat: tempat backdoor biasa bersembunyi

• ▸ Fail .php di dalam wp-content/uploads. Folder muat naik sepatutnya mengandungi gambar dan dokumen sahaja.
• ▸ Folder mu-plugins, kerana plugin di situ berjalan tanpa muncul dalam senarai plugin di panel.
• ▸ Baris tambahan pada hujung wp-config.php, atau fail baharu dengan nama seperti wp-config-temp.php.
• ▸ Fail .htaccess yang menyalurkan trafik daripada enjin carian atau telefon tertentu ke laman lain.
• ▸ Jadual wp_options dan wp_cron yang menyimpan tugas berjadual untuk menghantar semula maklumat kepada penyerang.
• ▸ functions.php di dalam tema kanak-kanak yang anda tidak pernah tulis sendiri.

# Fail PHP yang diubah suai dalam tujuh hari terakhir
find /var/www/laman -name "*.php" -mtime -7 -type f

# Fail PHP di dalam folder muat naik
find /var/www/laman/wp-content/uploads -name "*.php" -type f

Senarai di atas bukan senarai lengkap, tetapi ia menangkap sebahagian besar kes yang saya jumpa. Kalau laman anda menggunakan plugin keselamatan, ia boleh melakukan sebahagian kerja ini untuk anda, tetapi jangan bergantung pada satu alat sahaja. Backdoor yang paling degil biasanya yang ditulis khusus untuk laman anda, dan ia tidak ada dalam mana-mana pangkalan data tanda tangan.

Langkah lima: bersihkan atau bina semula

Soalan sebenarnya bukan sama ada anda boleh membersihkan, tetapi berapa lama. Kalau yang rosak cuma beberapa fail teras dan satu akaun pentadbir, pembersihan mengambil masa dua hingga empat jam. Kalau pangkalan data juga telah disuntik, membersihkan satu per satu menjadi kerja yang tidak ada penghujung, dan ketidakpastian kekal pada setiap baris yang anda tidak periksa.

Untuk kes yang lebih teruk, membina semula lebih pantas daripada membersihkan. Urutannya begini. Pasang WordPress baharu daripada muat turun rasmi. Pasang tema dan plugin daripada direktori rasmi sahaja. Salin semula folder muat naik, tetapi tapis keluar setiap fail .php daripadanya. Import kandungan daripada fail eksport yang bersih, bukan daripada pangkalan data lama. Kalau tiada eksport bersih, pulihkan pangkalan data daripada sandaran sebelum tarikh jangkitan pertama, dan inilah sebabnya tarikh masuk itu penting.

Langkah enam: tukar semua kunci, bukan sebahagian

Selepas laman bersih, semua kredensial yang mungkin telah dibaca penyerang mesti dianggap bocor.

• ▸ Kata laluan WordPress untuk setiap pengguna, terutama akaun pentadbir.
• ▸ Kata laluan panel hosting dan akses FTP atau SFTP.
• ▸ Kunci garam dalam wp-config.php. Menggantikannya membatalkan semua sesi log masuk yang sedang aktif.
• ▸ Kata laluan pangkalan data dan kredensial API yang disimpan di dalam plugin.
• ▸ Kunci SSH dan kata laluan peti mel. Kalau penyerang menyimpan backdoor dalam bentuk alias e-mel, dia masih menerima surat.
• ▸ Kalau e-mel pelanggan atau maklumat peribadi terjejas, sediakan kenyataan sebelum orang mula bertanya.

Selepas bersih: apa yang menghalang ulangan

• ▸ Benarkan kemas kini automatik untuk teras, dan kemas kini plugin setiap minggu. Kemas kini automatik paksa yang menyelamatkan berjuta laman pada Julai 2026 hanya berfungsi kalau ia tidak dimatikan.
• ▸ Pengesahan dua faktor untuk semua akaun pentadbir.
• ▸ Had cubaan log masuk di peringkat pelayan, bukan hanya di peringkat plugin. Plugin keselamatan boleh menghadkan cubaan di dalam aplikasi, tetapi ia tidak mengurangkan beban yang sampai ke pelayan.
• ▸ Matikan xmlrpc.php kalau tiada aplikasi mudah alih yang bergantung padanya.
• ▸ Simpan bilangan plugin pada tahap yang kecil. Setiap plugin tambahan ialah kod orang lain yang berjalan di dalam pelayan anda.
• ▸ Sandaran yang disimpan di luar pelayan dan pernah diuji pulih, bukan sekadar wujud.

72 jam dan PDPA

Kalau laman anda menyimpan maklumat pelanggan, godaman bukan lagi hanya isu teknikal. Mulai 1 Jun 2025, pindaan Akta Perlindungan Data Peribadi mewajibkan pengawal data memberitahu Pesuruhjaya Perlindungan Data Peribadi secepat mungkin dan tidak lewat daripada 72 jam selepas kes itu berlaku, kalau ia menyebabkan atau mungkin menyebabkan kemudaratan ketara. Pengguna terjejas pula mesti dimaklumkan tidak lewat daripada tujuh hari selepas laporan kepada Pesuruhjaya. Rekod insiden juga perlu disimpan sekurang-kurangnya dua tahun, termasuk kes yang tidak melepasi ambang itu.

Yang sering berlaku ialah pemilik laman menunggu siasatan dalaman selesai sebelum melaporkan. Tempoh 72 jam itu dikira daripada masa anda mempunyai sebab untuk percaya berlaku pelanggaran, bukan daripada masa anda selesai menyiasat. Kalau anda mula memeriksa pada hari ketiga, tarikh akhir itu sudah hampir.

Kos dan bila patut panggil orang lain

Kerja pembersihan sendiri biasanya mengambil masa enam hingga dua belas jam untuk laman kecil, dan sebahagian besar masa itu habis pada langkah mencari backdoor kedua dan ketiga. Kalau anda mengupah, kadar pada 2026 berada dalam lingkungan RM800 hingga RM3,000 bergantung kepada jumlah fail dan sama ada pangkalan data terjejas. Bina semula selalunya jatuh di hujung bawah julat itu, kerana ia kerja yang jelas penghujungnya.

Panggil orang lain kalau laman itu menjana pendapatan harian, kalau ia menyimpan data pelanggan, atau kalau anda sudah membersihkannya sekali dan ia digodam semula. Kes ketiga itu tanda ada sesuatu yang tertinggal.

Apa yang masih tidak dapat dipastikan

Saya tidak boleh memberitahu anda tarikh sebenar penyerang masuk, dan tiada siapa boleh, tanpa log yang lengkap pada masa itu. Saya juga tidak boleh memastikan apa yang telah dibaca atau disalin. Malah selepas laman bersih dan berjalan semula, satu kemungkinan kekal, iaitu senarai pelanggan dan kandungan anda sudah berada dalam tangan orang lain. Yang boleh dipastikan ialah keadaan semasa, iaitu fail, akaun, tugas berjadual dan tetapan. Itu yang diperiksa, dan itu yang boleh dijamin semula.