wp-login.php. Masalah umum yang membingungkan banyak pengelola web adalah mengapa server tetap kolaps padahal mereka sudah memasang plugin keamanan populer untuk membatasi percobaan login.
Memahami perbedaan titik eksekusi antara plugin WordPress dan edge network seperti Cloudflare adalah kunci untuk menjaga server tetap bernapas tanpa harus terus menambah kapasitas RAM atau CPU.
Beban Tersembunyi di Balik Proteksi Plugin WordPress
wp-login.php, alur proses di server origin sudah berjalan jauh sebelum plugin memutuskan untuk menolak bot tersebut.
Pertama, web server (seperti Nginx, Apache, atau LiteSpeed) harus menerima koneksi TCP dan melakukan negosiasi SSL/TLS. Setelah itu, web server menyerahkan request tersebut ke PHP handler, baik melalui PHP-FPM maupun modul bawaan server. PHP kemudian mengalokasikan satu PHP worker—yaitu proses komputasi yang bertugas mengeksekusi kode script PHP—untuk memuat file wp-config.php, inisialisasi basis data, memuat file inti WordPress, dan menjalankan seluruh plugin aktif hingga mencapai script plugin keamanan.
Baru pada tahap inilah plugin memeriksa apakah IP pengirim telah melampaui batas percobaan login. Jika ya, plugin akan mengembalikan respons HTTP 403 atau pesan penolakan. Meskipun bot berhasil digagalkan untuk menebak kata sandi, satu siklus PHP worker dan koneksi database MySQL sudah terpakai habis selama puluhan hingga ratusan milidetik.
Jika ada 50 bot menyerang bersamaan dan server hanya memiliki 20 alokasi PHP worker yang tersedia, antrean worker akan penuh seketika. Pengunjung manusia yang ingin membuka halaman beranda atau menyelesaikan checkout toko online akan tertahan dalam antrean sampai waktu request habis (timeout). Plugin keamanan berhasil menjaga keamanan kredensial, tetapi gagal menjaga ketersediaan layanan.
Pola serangan ini tidak hanya menargetkan form login standar. Bot modern sering memanfaatkan berkas XML-RPC untuk mencoba ratusan kombinasi sandi sekaligus dalam satu request, seperti yang diulas dalam panduan Spotting XML-RPC Multicall Attacks in Web Server Access Logs.
Cara Kerja Blokir di Level Edge Cloudflare
wp-login.php, request bot tiba di server Cloudflare terdekat, bukan di server hosting milikmu. Jika kamu mengatur aturan keamanan (WAF Rule) di Cloudflare, filter langsung dievaluasi di edge network.
Cloudflare dapat langsung menyajikan tantangan (Managed Challenge atau Cloudflare Turnstile) atau memblokir IP tersebut dengan respons HTTP 403 langsung dari server edge. Request jahat tersebut dihentikan sepenuhnya di luar infrastruktur hosting. Server web milikmu tidak pernah menerima paket TCP, tidak pernah meluncurkan PHP worker, dan tidak ada query basis data yang dijalankan. CPU dan RAM server origin tetap berada pada kondisi normal seolah serangan tersebut tidak pernah terjadi.
Selain itu, menghentikan bot di level edge juga mencegah penumpukan file log akses dan log error di server lokal. Pada serangan yang berlangsung berhari-hari, lonjakan pencatatan log di level lokal bisa memicu konsumsi storage berlebih dan berisiko menghabiskan kapasitas disk maupun alokasi inode server.
Parameter Perbandingan: Kapan Memilih Edge, Kapan Memilih Plugin?
| Parameter | Plugin WordPress (Lokal) | Cloudflare WAF (Edge) | Keterangan | Catatan Praktis |
|---|---|---|---|---|
| Konsumsi Resource Server | Sangat tinggi saat diserang | Nol di sisi server origin | Plugin membebani alokasi worker PHP | Edge memblokir trafik sebelum masuk hosting |
| Konteks Data Pengguna | Sangat tinggi | Rendah / Terbatas | Plugin mengenali role admin, editor, pembeli | Edge hanya membaca header HTTP dan IP |
| Kebutuhan Akses DNS | Tidak butuh akses DNS | Wajib mengubah nameserver/DNS | Plugin aktif langsung dari wp-admin | Cloudflare butuh kontrol domain penuh |
| Pencegahan False Positive | Mudah direset via database | Perlu bypass rule via dashboard WAF | Plugin mudah dinonaktifkan via FTP/SSH | WAF salah konfigurasi bisa mengunci admin |
1. Kapasitas dan Batasan Server
2. Kebutuhan Autentikasi dan Konteks Akun
3. Batasan Anggaran dan Fitur Gratis
Contoh Aturan Efektif di Level Cloudflare
Managed Challenge khusus pada URI login.
Dengan cara ini, bot otomatis akan tereliminasi karena tidak bisa menyelesaikan tantangan JavaScript atau CAPTCHA di level edge, sementara pengguna manusia asli hanya akan melihat layar verifikasi sejenak sebelum form login muncul.
Berikut contoh ekspresi aturan yang umum diterapkan pada menu WAF Custom Rules di Cloudflare:
TEXT
(http.request.uri.path eq "/wp-login.php") and not (ip.src in {192.0.2.1}) and (http.request.method eq "POST")192.0.2.1 dengan IP statis kantormu atau IP rumah jika kamu memiliki IP tetap untuk pengecualian).
Dengan aturan tersebut, Cloudflare hanya akan memicu aksi terhadap request POST yang ditujukan ke endpoint login bagi IP di luar daftar putih. Halaman login tetap bisa dibuka, tetapi upaya submit kredensial dari bot asing akan langsung ditahan di edge network.
Strategi Berlapis yang Seimbang
/wp-login.php agar ribuan bot acak yang memindai internet gugur sebelum sempat menyentuh Nginx atau Apache. Ini menjaga PHP worker tetap senggang dan siap melayani pengunjung nyata.
Di saat yang sama, tetap pasang perlindungan ringan di level WordPress—seperti penerapan Autentikasi Dua Faktor (2FA) atau penggantian alur login administrator—untuk menjaga pintu tetap aman seandainya ada penyerang bertarget yang berhasil melewati filter edge. Dengan pembagian tugas ini, server hosting tidak lagi kehabisan resource, dan keamanan akun WordPress tetap terjaga secara menyeluruh.