Suatu pagi Anda buka situs sendiri dan mendapati halaman depan berisi teks aneh atau dialihkan ke domain lain. Situs kecil sering jadi sasaran bukan karena isinya berharga, tapi karena sistemnya lemah. Audit keamanan WordPress membantu Anda menemukan celah itu sebelum orang lain memakainya.
Anda bisa memulainya dengan memeriksa hal-hal yang paling sering jadi pintu masuk, lalu memperbaikinya satu per satu.
1. Periksa versi inti, tema, dan plugin
Sebagian besar serangan WordPress masuk lewat komponen yang tertinggal versinya. Buka dasbor, lihat menu Pembaruan, dan catat apa saja yang belum diperbarui. Plugin yang tidak lagi dirawat pengembangnya sebaiknya diganti, bukan sekadar dibiarkan karena masih tampak berfungsi.
Untuk situs dengan banyak plugin, pembaruan satu per satu lewat dasbor bisa melelahkan. Anda bisa memakai WP-CLI agar prosesnya lebih cepat dan mudah dicatat. Panduan cara menggunakan WP-CLI untuk mengelola WordPress membahas perintah dasar yang berguna untuk keperluan ini.
Sebelum memperbarui apa pun, pastikan Anda punya cadangan terbaru. Pembaruan yang gagal di tengah jalan lebih mudah dipulihkan kalau backup tersedia.
2. Rapikan akun dengan hak akses administrator
Hitung berapa banyak akun administrator di situs Anda. Kalau ada nama seperti “admin” atau akun lama milik mantan rekan kerja, itu celah yang tidak perlu dipertahankan. Setiap akun administrator adalah kunci penuh ke situs, termasuk akses ke pengaturan dan file.
- Turunkan peran akun yang tidak benar-benar butuh akses penuh.
- Hapus akun yang tidak pernah dipakai.
- Pastikan setiap pengguna punya kata sandi sendiri dan tidak dipakai ulang di layanan lain.
- Aktifkan autentikasi dua faktor untuk akun administrator.
Perubahan peran pengguna sebaiknya dilakukan dari dasbor, bukan langsung di basis data, agar tidak ada data yang tertinggal setengah jalan.
3. Tinjau pengaturan di wp-config.php
File konfigurasi menyimpan kunci keamanan, kredensial basis data, dan beberapa pengaturan yang memengaruhi perilaku situs. Periksa apakah kunci keamanan sudah diganti dari nilai bawaan. Kalau belum, buat ulang agar token sesi lama tidak berlaku lagi.
Anda juga bisa menambahkan pengaturan untuk membatasi pengeditan file dari dasbor, terutama kalau situs Anda sudah stabil dan jarang diubah dari panel. Penjelasan lebih rinci soal isi dan fungsi file ini ada di panduan cara kerja wp-config.php dan pengaturan penting di dalamnya.
Pastikan file tersebut tidak bisa diakses langsung lewat browser. Kalau server Anda memakai Apache, aturan pemblokiran sederhana di .htaccess sudah cukup untuk menutupnya.
4. Cek izin file dan folder
Izin yang terlalu longgar membuat file bisa diubah dari luar. Sebagai gambaran umum, folder biasanya cukup dengan izin 755 dan file 644. File konfigurasi sering disarankan lebih ketat lagi, misalnya 600, tergantung cara server menjalankan PHP.
Anda bisa memeriksa izin lewat panel hosting atau perintah SSH. Kalau menemukan file dengan izin 777, curigai itu sebagai sisa percobaan yang tidak selesai atau tanda ada yang tidak beres.
find . -type d -perm 777
find . -type f -perm 777Dua perintah di atas hanya menampilkan daftar, tidak mengubah apa pun. Jalankan dari direktori instalasi WordPress, lalu perbaiki satu per satu setelah Anda tahu file mana yang bermasalah.
5. Bersihkan plugin dan tema yang tidak terpakai
Plugin nonaktif tetap ada di server. Kalau punya celah, file-nya masih bisa diakses meski tidak aktif. Hapus, bukan hanya nonaktifkan, plugin yang sudah tidak dipakai. Hal yang sama berlaku untuk tema lama yang hanya tersimpan sebagai cadangan.
Sebelum menghapus, pastikan tidak ada fungsi penting yang bergantung padanya. Cara mudahnya, cari nama plugin di file tema aktif atau di pengaturan yang mungkin masih merujuk ke plugin tersebut.
6. Aktifkan pencatatan dan pemantauan dasar
Anda tidak bisa memperbaiki sesuatu yang tidak terlihat. Aktifkan log akses di hosting, lalu perhatikan pola percobaan login yang gagal berulang dari alamat IP yang sama. Banyak plugin keamanan menyediakan pembatasan percobaan login dan notifikasi perubahan file, dan untuk situs kecil fitur itu sudah memadai.
Kalau Anda memilih menulis sendiri pengaturannya, pahami dulu cara kerja permintaan HTTP di WordPress. Pembahasan soal pola arsitektur seperti perbandingan singleton, dependency injection, dan service locator berguna ketika Anda mulai membungkus logika keamanan ke dalam kelas sendiri, terutama untuk proyek yang tumbuh lebih besar dari sekadar situs profil.
7. Uji pemulihan dari cadangan
Backup yang tidak pernah diuji belum bisa disebut backup. Buat salinan situs di lingkungan lokal atau subdomain, lalu coba pulihkan. Perhatikan apakah basis data ikut kembali utuh, termasuk pengguna, pengaturan, dan tautan permanen.
Simpan salinan di tempat yang tidak bisa dihapus dari dalam WordPress. Kalau penyerang sudah punya akses ke dasbor, backup yang tersimpan di folder yang sama akan ikut hilang.
Untuk situs yang mulai menerima lalu lintas lebih besar, pilihan hosting ikut menentukan seberapa mudah Anda mengatur backup dan pemantauan. Ulasan cara memilih hosting WordPress untuk pemula membahas hal yang perlu dicek sebelum memindahkan situs.
Kebiasaan kecil yang menutup banyak celah
Sebagian besar insiden di situs kecil berasal dari hal yang berulang: plugin usang, akun administrator berlebih, dan backup yang tidak pernah diuji. Tiga hal itu bisa dibereskan dalam satu sore. Sisanya, seperti pencatatan log dan pembaruan berkala, cukup dijadwalkan sebulan sekali.
Kalau situs Anda menangani data pengguna atau transaksi, pertimbangkan melibatkan konsultan keamanan untuk peninjauan menyeluruh. Informasi di sini bersifat umum dan tidak menggantikan pemeriksaan oleh profesional.
Pertanyaan yang Sering Diajukan
Seberapa sering audit keamanan WordPress sebaiknya dilakukan?
Untuk situs kecil, sebulan sekali sudah memadai. Lakukan audit tambahan setelah memasang plugin baru, mengubah tema, atau menerima laporan aneh dari pengunjung.
Apakah plugin keamanan sudah cukup tanpa audit manual?
Belum. Plugin membantu memantau dan membatasi percobaan masuk, tapi tidak tahu akun administrator mana yang sudah tidak dipakai atau izin file mana yang terlalu longgar. Pemeriksaan manual tetap perlu.
Apa yang harus dilakukan pertama kali kalau situs sudah terlanjur disusupi?
Ambil cadangan kondisi saat ini untuk bahan penyelidikan, ganti semua kata sandi, lalu pulihkan dari backup bersih yang dibuat sebelum insiden. Setelah situs pulih, telusuri bagaimana akses bisa terjadi agar celah yang sama tidak terulang.
