Website Diretas Tidak Selalu Terlihat: Cara Menata Log dan Audit Trail yang Berguna

Website yang diretas tidak selalu langsung berubah menjadi halaman penuh pesan aneh. Kadang serangannya lebih tenang: satu akun admin baru dibuat, satu plugin diganti, satu file PHP disisipkan, atau beberapa percobaan login dilakukan berulang kali pada dini hari. Dari sisi pengunjung, semuanya bisa terlihat normal.

Di sinilah log dan audit trail menjadi penting. Log adalah catatan aktivitas sistem, sedangkan audit trail adalah riwayat tindakan yang membantu kita menjawab pertanyaan seperti: siapa melakukan apa, kapan, dari mana, dan terhadap bagian mana dari website. Keduanya bukan hanya kebutuhan administrator server. Pemilik website kecil, toko online, dan pengelola WordPress juga bisa mendapat manfaat besar darinya.

Log bukan sekadar file teknis

Log sering dianggap sebagai tumpukan baris teks yang hanya berguna bagi developer. Padahal, log yang dirancang dengan baik dapat menjadi rekaman kamera keamanan digital. Ia mungkin tidak selalu menunjukkan identitas pelaku secara lengkap, tetapi bisa memperlihatkan alamat IP, waktu kejadian, endpoint yang diakses, respons server, akun yang digunakan, dan perubahan yang terjadi.

OWASP merekomendasikan agar aplikasi mencatat peristiwa keamanan penting, bukan hanya error teknis. Contohnya adalah login berhasil dan gagal, perubahan hak akses, pembuatan akun baru, perubahan konfigurasi, penggunaan fitur sensitif, serta aktivitas yang melanggar aturan input.

Untuk WordPress, dokumentasi resmi juga menempatkan logging dan monitoring sebagai bagian dari proses hardening. Log dapat membantu menemukan percobaan brute force, perubahan file, penggunaan editor plugin atau tema, hingga penambahan konten yang tidak sah.

Bedakan tiga jenis catatan

Sebelum memasang plugin atau mengaktifkan semua fitur logging, bedakan dulu sumber informasinya. Setiap jenis catatan menjawab pertanyaan yang berbeda.

• Access log web server: mencatat permintaan HTTP, seperti URL, waktu, kode status, alamat IP, dan user agent. Ini berguna untuk melihat pola scanning, brute force, atau permintaan mencurigakan.
• Error log: mencatat kesalahan PHP, konfigurasi server, dan kegagalan aplikasi. Catatan ini membantu menemukan kode rusak, tetapi jangan ditampilkan ke pengunjung karena bisa membocorkan informasi sensitif.
• Application audit log: mencatat tindakan di dalam aplikasi, misalnya admin mengubah email pengguna, memasang plugin, menghapus pesanan, atau mengubah pengaturan pembayaran.

Access log mungkin menunjukkan bahwa halaman pengaturan dibuka, tetapi hanya audit log aplikasi yang dapat menjelaskan apakah pengaturan itu benar-benar berubah dan akun mana yang melakukannya.

Apa saja yang layak dicatat?

Prinsipnya sederhana: catat peristiwa yang membantu mendeteksi penyalahgunaan atau menyelidiki insiden. Untuk website biasa, mulai dari daftar berikut:

• Login berhasil, login gagal berulang, logout, dan reset password.
• Pembuatan, penghapusan, atau perubahan peran pengguna.
• Perubahan plugin, tema, konfigurasi, dan file penting.
• Perubahan alamat email admin, metode pembayaran, atau webhook.
• Penghapusan konten, pesanan, pelanggan, atau data penting.
• Permintaan yang menghasilkan banyak kode status 401, 403, atau 404.
• Aktivitas dari lokasi, perangkat, atau jam yang tidak biasa.

Catat konteks secukupnya: waktu dalam zona yang konsisten, nama event, ID pengguna, alamat IP, ID permintaan, hasil tindakan, dan objek yang terkena dampak. Request ID adalah tanda pengenal unik untuk satu permintaan. Ia membantu menghubungkan catatan dari aplikasi, server, dan layanan pihak ketiga.

Jangan memasukkan rahasia ke dalam log

Log yang terlalu detail juga bisa menjadi masalah baru. Jangan mencatat password, token sesi, API key, nomor kartu pembayaran, atau isi lengkap data pribadi jika tidak diperlukan. URL yang mengandung token juga harus disensor sebelum disimpan.

Contoh yang buruk:

password=rahasia123&token=abc-xyz-123

Contoh yang lebih aman:

event=login_failed user_id=184 ip=203.0.113.10 reason=invalid_password

Dalam contoh kedua, kita masih bisa menyelidiki kejadian tanpa menyimpan rahasia pengguna. Log juga perlu diberi pembatasan akses. Orang yang bisa membaca log berpotensi melihat pola aktivitas, alamat IP, atau informasi internal website.

WordPress: mulai dari hal yang tersedia

Jika menggunakan WordPress, buka Tools > Site Health > Info untuk memahami konfigurasi website, versi PHP, plugin aktif, tema, dan kondisi sistem. Periksa juga apakah mode debug menulis error ke file yang dapat diakses publik. File debug yang terbuka bisa membocorkan path server, query, atau detail konfigurasi.

Untuk audit aktivitas admin, gunakan solusi yang mencatat perubahan pengguna, plugin, tema, dan pengaturan. Pilih plugin dari sumber tepercaya, periksa kapan terakhir diperbarui, dan hindari memasang beberapa plugin logging dengan fungsi yang sama. Terlalu banyak catatan tanpa sistem penyaringan hanya membuat sinyal penting tenggelam dalam kebisingan.

Jika memiliki akses ke server, simpan salinan log di lokasi terpisah dari website utama. Alasannya sederhana: penyerang yang sudah mendapatkan akses ke server mungkin mencoba menghapus jejak. CISA juga menyarankan sentralisasi log, perlindungan dari penghapusan tanpa izin, serta kebijakan retensi yang jelas.

Yang bisa dilakukan sekarang

1. Tentukan tiga peristiwa berisiko tinggi. Misalnya login admin, perubahan hak akses, dan perubahan plugin.
2. Pastikan waktu sistem konsisten. Perbedaan zona waktu membuat urutan kejadian sulit dibaca.
3. Buat peringatan sederhana. Contohnya, beri notifikasi jika ada 10 login gagal dalam lima menit atau akun admin baru dibuat.
4. Simpan log di tempat terpisah. Jangan hanya mengandalkan file di server website.
5. Uji pencarian log. Simulasikan login gagal atau perubahan pengaturan, lalu pastikan catatannya bisa ditemukan.
6. Tentukan siapa yang memeriksa. Log yang tidak pernah dibaca belum menjadi sistem monitoring.

Saat menemukan aktivitas mencurigakan

Jangan langsung menghapus file atau melakukan instalasi ulang tanpa menyimpan bukti. Catat waktu pertama kali masalah terlihat, simpan salinan log yang relevan, dan batasi perubahan baru pada website. Setelah itu, cabut sesi aktif, reset kredensial penting, periksa akun admin, dan cari perubahan file atau plugin.

Tujuan log bukan membuat kita bisa mengetahui segala sesuatu. Tujuannya adalah memperpendek jarak antara kejadian dan pemahaman. Website yang memiliki pencegahan, pencatatan, dan rencana respons akan lebih siap menghadapi masalah dibanding website yang hanya berharap tidak pernah diserang.

Sumber & bacaan lebih lanjut

• OWASP Logging Cheat Sheet
• Hardening WordPress – Advanced Administration Handbook
• Use Logging on Business Systems – CISA
• Site Health screen – WordPress.org Documentation

– Rio Yotto @rioyotto