Menonaktifkan XML-RPC WordPress: Cara Tercepat untuk Menghindari Serangan Brute Force

Menonaktifkan XML-RPC WordPress adalah proses yang mencegah file xmlrpc.php di situs Anda menerima permintaan dari jarak jauh, dengan cepat mengurangi percobaan brute force, penyalahgunaan pingback, dan lalu lintas bot yang tidak perlu. Jika Anda tidak menggunakan Jetpack, aplikasi mobile WordPress, alat penerbitan jarak jauh yang lama, atau integrasi khusus yang menggunakan XML-RPC, menonaktifkan XML-RPC adalah langkah pengamanan yang aman dan praktis untuk sebagian besar situs WordPress. Metode yang paling efektif adalah memblokir permintaan di tingkat server sebelum WordPress berjalan; yaitu, memutuskan akses ke xmlrpc.php melalui Apache, LiteSpeed, Nginx, atau aturan WAF biasanya lebih efisien dibandingkan dengan menonaktifkan melalui plugin.

Dalam panduan ini, Anda akan menemukan langkah demi langkah mengapa Anda perlu menonaktifkan XML-RPC WordPress, dalam situasi apa Anda harus tetap mengaktifkannya, dan bagaimana menerapkannya dengan aman di berbagai lingkungan server. Tidak masalah apakah Anda menggunakan infrastruktur Hostragons atau lingkungan hosting lainnya; tujuannya adalah untuk mengurangi permukaan serangan tanpa merusak situs Anda, mengurangi konsumsi sumber daya yang tidak perlu, dan menciptakan standar keamanan yang dapat dikelola. Jika Anda mencari dasar yang cepat dan aman saat meng-host situs WordPress Anda, pilihan Hosting WordPress juga merupakan bagian penting dari proses ini.

Apa Itu XML-RPC dan Apa Fungsinya di WordPress?

XML-RPC adalah protokol komunikasi jarak jauh yang sudah usang yang memungkinkan sistem yang berbeda berkomunikasi satu sama lain dengan mengirimkan data dalam format XML melalui HTTP. Di sisi WordPress, fungsi ini biasanya dijalankan melalui file xmlrpc.php di direktori root. Secara historis, file ini digunakan untuk menerbitkan pos dari aplikasi mobile WordPress, mengelola komentar jarak jauh, pingback, dan interaksi dengan beberapa layanan pihak ketiga.

Namun, dengan meningkatnya popularitas REST API di ekosistem WordPress modern, pentingnya XML-RPC telah berkurang. Meskipun begitu, file ini masih dapat diakses di banyak instalasi. Ini berarti bahwa bagi para penyerang, ini adalah titik akhir yang mudah ditemukan, dengan jalur yang jelas dan dapat ditargetkan melalui otomatisasi. Terutama bot yang memindai rentang IP acak, bahkan jika domain Anda baru saja didirikan, dapat mencoba mengakses xmlrpc.php dalam hitungan menit. Oleh karena itu, penting untuk mempertimbangkan fondasi keamanan saat meluncurkan domain baru Anda dengan Pemeriksaan Domain.

Kapan XML-RPC Mungkin Diperlukan?

XML-RPC tidak selalu diperlukan untuk setiap situs. Beberapa fitur lama dari Jetpack, aplikasi mobile WordPress untuk tindakan tertentu, beberapa layanan otomatisasi, atau editor blog desktop yang lebih tua mungkin memerlukan XML-RPC. Selain itu, integrasi yang dikembangkan khusus mungkin juga menggunakan xmlrpc.php untuk pengiriman konten atau pengambilan data jarak jauh. Oleh karena itu, penting untuk memeriksa alur kerja situs Anda sebelum menonaktifkannya.

Kontrol praktisnya adalah: Jika Anda hanya memasukkan konten di situs Anda melalui panel wp-admin, tidak menggunakan Jetpack, tidak menerbitkan dari aplikasi mobile, dan pengembang Anda tidak menginstal integrasi XML-RPC khusus, kemungkinan besar Anda tidak memerlukan XML-RPC. Banyak situs perusahaan, blog, situs katalog, situs bisnis kecil, dan toko WooCommerce dapat berfungsi dengan baik tanpa XML-RPC. Namun, jika Anda memiliki proses kritis seperti infrastruktur pembayaran dan integrasi pengiriman, sebaiknya lakukan pengujian perubahan ini pada jam-jam dengan lalu lintas rendah.

Mengapa XML-RPC Berisiko untuk Serangan Brute Force?

Serangan brute force adalah saat penyerang mencoba kombinasi nama pengguna dan kata sandi berulang kali menggunakan alat otomatis. Di WordPress, upaya ini biasanya dilakukan melalui wp-login.php; namun, XML-RPC dapat memberikan cara yang lebih menguntungkan bagi penyerang. Beberapa metode XML-RPC memungkinkan beberapa upaya login dilakukan dalam satu permintaan HTTP. Terutama fitur system.multicall, dapat membantu melakukan ratusan percobaan dengan lebih sedikit permintaan terlihat pada sistem yang dikonfigurasi dengan buruk.

Misalnya, melakukan 500 percobaan kata sandi melalui wp-login.php akan terlihat seperti 500 permintaan terpisah, sementara percobaan yang sama melalui XML-RPC dapat dikirim dalam jumlah paket yang lebih sedikit. Ini dapat menyebabkan plugin keamanan dan pemantauan log sederhana mendeteksi serangan terlambat. Akibatnya, penggunaan CPU meningkat, pekerja PHP menjadi sibuk, database terbebani dengan kueri yang tidak perlu, dan pengunjung nyata mendapatkan respons yang lebih lambat. Dalam lingkungan hosting bersama, situasi ini bukan hanya risiko keamanan, tetapi juga masalah kinerja dan penggunaan sumber daya.

Area berisiko lainnya dari XML-RPC adalah penyalahgunaan pingback. Mekanisme pingback dirancang untuk memberi tahu bahwa situs lain telah memberikan tautan ke konten Anda; namun, dalam penyalahgunaan, ini dapat digunakan untuk menghasilkan lalu lintas mirip DDoS atau menargetkan situs pihak ketiga. Oleh karena itu, menonaktifkan XML-RPC tidak hanya mengurangi upaya login; tetapi juga mengurangi kemungkinan penyalahgunaan yang berasal dari pingback.

Keputusan Menonaktifkan XML-RPC: Tabel Perbandingan Cepat

Seperti yang terlihat dari tabel, cara tercepat dan paling kuat adalah menonaktifkan XML-RPC di tingkat server atau WAF jika Anda tidak membutuhkannya. Menggunakan plugin itu mudah; namun, jika permintaan serangan mencapai PHP, konsumsi sumber daya dapat terus berlanjut. Oleh karena itu, untuk situs dengan lalu lintas tinggi, yang berfokus pada e-commerce, atau yang sering diserang, prioritas harus pada aturan server web.

Daftar Periksa Sebelum Memulai

Saat mengatur keamanan, prinsip dasar adalah mengukur terlebih dahulu dan menyiapkan rencana pemulihan. Proses menonaktifkan XML-RPC biasanya tidak berisiko; tetapi tidak ada perubahan yang boleh dilakukan secara membabi buta di situs live. Berikut adalah daftar periksa yang dapat mengurangi kemungkinan kesalahan selama penerapan.

• Pastikan Anda memiliki cadangan file dan database yang berfungsi yang diambil dalam 24 jam terakhir. Cadangan sebelum pembaruan WordPress, pengaturan keamanan, dan perubahan plugin harus dianggap wajib.
• Periksa apakah Anda menggunakan Jetpack, aplikasi mobile WordPress, alat penerbitan jarak jauh, atau integrasi khusus.
• Periksa jumlah permintaan xmlrpc.php di log akses. Jika Anda melihat puluhan atau ratusan permintaan per menit, Anda mungkin sedang diserang.
• Lakukan perubahan pada jam dengan lalu lintas rendah. Uji alur keranjang, pembayaran, dan keanggotaan terutama di toko WooCommerce setelahnya.
• Tentukan metode pemulihan. Pastikan Anda memiliki akses ke manajer file, FTP, atau SSH untuk mengomentari atau menghapus aturan yang Anda tambahkan.

Di lingkungan hosting profesional, cadangan rutin, versi PHP yang diperbarui, struktur akun yang terisolasi, dan dukungan firewall membuat perbedaan besar. Anda juga dapat merujuk ke konten Hosting Web yang Aman untuk pemilihan infrastruktur dan sertifikat SSL untuk keamanan umum situs.

Metode 1: Menonaktifkan XML-RPC di Apache atau LiteSpeed melalui .htaccess

Metode paling umum di situs WordPress yang menggunakan Apache dan LiteSpeed adalah menambahkan aturan yang memblokir akses ke xmlrpc.php di file .htaccess di direktori root situs. LiteSpeed mendukung aturan .htaccess yang kompatibel dengan Apache, sehingga metode ini dapat diterapkan secara langsung di banyak lingkungan hosting. Keuntungan terbesar adalah permintaan ditolak sebelum inti WordPress berjalan.

Penerapan Langkah demi Langkah

• Buka manajer file dari panel kontrol hosting Anda atau sambungkan ke direktori public_html melalui FTP.
• Cari file .htaccess dan cadangkan ke komputer Anda. Jika file tidak terlihat, aktifkan opsi untuk menampilkan file tersembunyi.
• Tanpa menghapus aturan yang dibuat oleh WordPress, tambahkan aturan pemblokiran XML-RPC di bagian atas file.
• Logika aturan harus: Tolak semua akses ke file xmlrpc.php.
• Simpan dan periksa dari browser di alamat domainanda.com/xmlrpc.php.

Logika yang akan Anda gunakan di lingkungan Apache 2.4 dan LiteSpeed adalah: definisi Require all denied untuk file xmlrpc.php. Pada lingkungan Apache 2.2 yang lebih lama, pendekatan Deny from all mungkin terlihat; namun, disarankan untuk menggunakan perangkat lunak server yang diperbarui sesuai standar 2026. Jika Anda masih beroperasi dengan versi Apache yang lebih lama, ini adalah masalah yang perlu diperbaiki tidak hanya untuk XML-RPC, tetapi juga dari segi keamanan secara umum.

Pada pemblokiran yang berhasil, alamat xmlrpc.php dapat mengembalikan 403 Forbidden, 404 Not Found, atau respons penolakan akses serupa tergantung pada konfigurasi server Anda. Yang penting adalah halaman tidak memberikan respons seperti XML-RPC server accepts POST requests. Jika pernyataan ini muncul, berarti file masih dapat diakses.

Metode 2: Memblokir Akses XML-RPC di Nginx

Di lingkungan Nginx, .htaccess tidak berfungsi; karena Nginx tidak membaca .htaccess berbasis direktori. Oleh karena itu, aturan harus ditambahkan ke konfigurasi blok server yang dimiliki situs. Jika Anda menggunakan hosting terkelola, bidang ini mungkin tidak langsung terbuka untuk Anda; dalam hal ini, Anda dapat meminta tim dukungan hosting Anda untuk menonaktifkan akses ke xmlrpc.php.

Pendekatan dasar di Nginx adalah menolak permintaan dengan blok location = /xmlrpc.php atau mengembalikan 404. Dari sudut pandang keamanan, menolak secara eksplisit dengan 403 atau menunjukkan bahwa file tidak ada dengan 404 juga dapat digunakan. Pendekatan 404 lebih disukai oleh administrator yang ingin memberikan informasi lebih sedikit kepada bot. Setelah aturan ditambahkan, konfigurasi Nginx harus diuji dan layanan harus dimuat ulang. Karena karakter yang salah dapat menyebabkan seluruh situs tidak dapat diakses, proses ini harus dilakukan dengan hati-hati.

Di VPS atau server dedicated yang menggunakan Nginx, bermanfaat untuk memantau log akses setelah perubahan. Anda harus melihat bahwa permintaan xmlrpc.php sekarang mengembalikan 403 atau 404. Jika percobaan intensif dari IP yang sama berlanjut, pertahanan lapisan kedua dapat ditambahkan dengan fail2ban, batasan laju, atau aturan WAF. Untuk panduan yang lebih komprehensif tentang manajemen server, Anda dapat mempertimbangkan keamanan server VPS.

Metode 3: Menonaktifkan XML-RPC dengan Plugin Keamanan

Bagi pengguna yang tidak ingin mengedit file teknis, plugin keamanan adalah solusi praktis. Plugin seperti Wordfence, Solid Security, dan All-In-One Security mungkin memiliki opsi untuk menonaktifkan XML-RPC, mematikan pingback, atau mencegah percobaan login XML-RPC. Metode ini terutama memberikan awal yang cepat untuk blog kecil dan situs korporat dasar.

Namun, penting untuk mengetahui batasan pendekatan plugin. Jika plugin menolak permintaan setelah WordPress berjalan, penyerang masih dapat memicu proses PHP. Ini berarti bahwa dalam serangan intensif, konsumsi CPU dan memori tidak sepenuhnya terhenti. Oleh karena itu, menonaktifkan dengan plugin jauh lebih baik daripada tidak mengambil tindakan sama sekali; tetapi situs yang diserang harus didukung oleh lapisan server atau WAF.

Hal-Hal yang Perlu Diperhatikan saat Menggunakan Plugin

• Unduh plugin keamanan hanya dari direktori plugin resmi WordPress atau situs resmi produsen.
• Hindari memilih plugin yang sudah lama tidak diperbarui. Pemeliharaan aktif dan kompatibilitas di tahun 2026 adalah sinyal keamanan yang penting.
• Jangan menggunakan beberapa plugin keamanan secara bersamaan untuk tugas yang sama. Konflik dapat menyebabkan masalah akses login, caching, dan file.
• Setelah mengatur opsi XML-RPC, uji kesehatan situs, formulir, akses keanggotaan, dan proses pembayaran.
• Secara rutin tinjau log plugin. Jika ada serangan yang terus menerus, tambahkan pemblokiran berbasis IP atau aturan WAF.

Metode 4: Memblokir dengan WAF, CDN, dan Firewall Hosting

Web Application Firewall, atau WAF, adalah salah satu lapisan paling efektif untuk menyaring permintaan berbahaya sebelum mencapai aplikasi. Solusi berbasis CDN seperti Cloudflare dapat memblokir permintaan xmlrpc.php sebelum sampai ke server. ModSecurity atau aturan WAF khusus yang ditawarkan oleh penyedia hosting Anda juga berfungsi dengan cara yang sama. Lapisan ini sangat berharga untuk memblokir banyak permintaan bot sebelum mereka mencapai WordPress.

Aturan WAF harus jelas: jika URI mengandung jalur xmlrpc.php, blokir permintaan atau terapkan tantangan. Jika Anda tidak benar-benar memerlukan XML-RPC, pemblokiran lebih jelas. Jika ada kebutuhan sebagian, pendekatan hanya mengizinkan alamat IP tertentu dapat digunakan. Misalnya, jika layanan otomatisasi Anda berasal dari IP tetap, IP ini dapat dimasukkan ke dalam daftar putih dan semua permintaan xmlrpc.php lainnya ditolak. Metode ini menawarkan keseimbangan antara keamanan dan keberlanjutan bisnis.

Lapisan WAF menjadi lebih berarti dengan SSL. Situs yang tidak menggunakan HTTPS memiliki risiko tambahan terhadap keamanan informasi login dan sesi. Oleh karena itu, selain menonaktifkan XML-RPC, penting untuk menjalankan seluruh situs melalui HTTPS, mempertimbangkan header seperti HSTS, dan memantau masa berlaku sertifikat. Pada titik ini, topik sertifikat SSL dan Instalasi SSL Gratis dapat digunakan sebagai konten dukungan yang relevan.

Bagaimana Cara Menguji Setelah Menonaktifkan XML-RPC?

Setelah perubahan, satu-satunya hal yang perlu diperiksa bukanlah apakah situs terbuka. Anda juga harus memeriksa apakah XML-RPC dinonaktifkan, apakah sistem login berfungsi dengan baik, apakah tindakan pengguna nyata terpengaruh, dan apakah ada hasil yang diharapkan di log. Alur uji berikut memberikan verifikasi yang praktis dan memadai.

• Buka alamat domainanda.com/xmlrpc.php di browser. Anda diharapkan menerima penolakan akses, 404, atau respons kosong. Teks XML-RPC server accepts POST requests tidak boleh muncul.
• Masuk ke panel admin WordPress dengan informasi pengguna normal Anda. Verifikasi bahwa halaman login berfungsi independen dari XML-RPC.
• Uji formulir kontak, formulir komentar, keanggotaan, dan langkah pembayaran WooCommerce.
• Periksa log akses server untuk melihat kode status yang dikembalikan oleh permintaan xmlrpc.php. Respons 403 atau 404 menunjukkan bahwa aturan yang tepat berfungsi.
• Jika Anda memiliki plugin keamanan, periksa log peristiwa. Anda harus melihat penurunan atau pemblokiran upaya bot yang sebelumnya tinggi.

Untuk pengujian yang lebih teknis, permintaan POST dapat dikirim melalui terminal; namun, bagi sebagian besar pemilik situs, pemeriksaan browser dan log sudah cukup. Jika setelah perubahan sambungan Jetpack terputus, aplikasi mobile tidak dapat menerbitkan, atau integrasi mengalami kesalahan, maka jelas bahwa XML-RPC memang dibutuhkan. Dalam hal ini, pertimbangkan untuk menggunakan strategi pembatasan IP atau batasan laju daripada penutupan penuh.

Apakah Menonaktifkan XML-RPC Cukup? Tindakan Keamanan Tambahan

Menonaktifkan XML-RPC adalah langkah cepat dan efektif terhadap serangan brute force; namun, tidak memberikan keamanan penuh sendirian. Penyerang dapat terus mencoba melalui wp-login.php, REST API, plugin yang lemah, tema yang usang, atau kata sandi yang bocor. Oleh karena itu, setelah menonaktifkan XML-RPC, penting untuk memikirkan keamanan WordPress secara berlapis.

Tindakan Dasar yang Harus Diterapkan

• Gunakan kata sandi yang kuat dan nama pengguna yang unik. Tidak menggunakan nama pengguna admin tetap merupakan langkah sederhana namun efektif.
• Tambahkan autentikasi dua faktor. 2FA di akun admin secara signifikan mengurangi risiko kebocoran kata sandi.
• Terapkan batasan percobaan login. Gunakan batasan laju untuk wp-login.php atau plugin keamanan.
• Jaga agar inti WordPress, plugin, dan tema tetap mutakhir. Plugin yang usang merupakan salah satu penyebab pelanggaran yang paling umum di dunia nyata.
• Hapus plugin dan tema yang tidak digunakan. Plugin pasif namun usang juga dapat menimbulkan risiko pada sistem file.
• Periksa izin file. Izin tulis yang tidak perlu meningkatkan risiko pengunggahan file berbahaya.
• Ambil cadangan secara rutin dan uji pemulihan. Cadangan dianggap sebagai asumsi jika tidak diuji.
• Gunakan infrastruktur hosting yang tepercaya. Isolasi, PHP yang mutakhir, WAF, dan dukungan cadangan mengurangi dampak serangan.

Misalnya, jika Anda hanya menonaktifkan XML-RPC dan meninggalkan kata sandi admin menjadi 123456 yang lemah, maka tautan terlemah dalam rantai keamanan tetap terbuka. Sebaliknya, ketika kata sandi yang kuat, 2FA, perangkat lunak terbaru, WAF, dan hosting yang aman digunakan bersama-sama, sebagian besar serangan bot biasa akan menjadi tidak efektif. Pendekatan ini juga penting untuk SEO di tahun 2026; karena situs dengan keamanan yang lemah dapat mengalami pengalihan berbahaya, produksi halaman spam, dan pencemaran indeks sehingga kehilangan visibilitas organik.

Dampak Menonaktifkan XML-RPC terhadap Kinerja dan SEO

Serangan XML-RPC bukanlah faktor peringkat langsung; tetapi dampak tidak langsungnya sangat kuat. Jika lalu lintas bot yang tinggi menghabiskan sumber daya server, waktu respons halaman dapat meningkat, nilai Core Web Vitals dapat terganggu, dan pengalaman pengguna nyata dapat menurun. Selain itu, situs yang sering terjebak dalam batas sumber daya dapat mengalami kesalahan 500, masalah timeout, dan gangguan. Googlebot juga dapat lebih berhati-hati saat merayapi halaman yang lambat atau mengalami kesalahan.

Pikirkan melalui contoh: Biasanya, halaman utama Anda terbuka dengan waktu respons server 300 ms; namun, saat xmlrpc.php menerima 1000 permintaan per menit, pekerja PHP akan terisi, dan waktu respons melebihi 2 detik. Di sisi pengguna, halaman melambat, rasio konversi menurun, dan statistik perayapan di Google Search Console dapat berfluktuasi. Menonaktifkan XML-RPC di tingkat server membantu memotong beban yang tidak perlu sebelum mencapai lapisan aplikasi, berkontribusi pada stabilitas kinerja.

Dari sudut pandang SEO, situs yang cepat dan aman bergantung pada kualitas konten serta infrastruktur teknis. HTTPS, PHP yang mutakhir, disk cepat, caching yang tepat, struktur tema yang bersih, dan pengurangan permukaan serangan harus dievaluasi bersama-sama. Oleh karena itu, pengaturan keamanan WordPress harus menjadi perhatian tidak hanya bagi administrator sistem, tetapi juga bagi tim SEO dan konten. Dalam blog Hostragons, topik ini dapat didukung dengan konten Optimasi kecepatan WordPress dan daftar kontrol SEO teknis.

Strategi Alternatif Jika Anda Tidak Dapat Menonaktifkan XML-RPC Sepenuhnya

Dalam beberapa proyek, XML-RPC tidak dapat sepenuhnya dinonaktifkan. Misalnya, aliran penerbitan mobile tertentu, otomatisasi perusahaan, atau integrasi lama mungkin masih bergantung pada protokol ini. Dalam kasus ini, tujuan bukanlah membiarkan semua pintu terbuka, tetapi membuat akses menjadi terkontrol. Opsi pertama adalah daftar putih IP. Hanya alamat IP dari layanan yang tepercaya yang diberikan akses ke XML-RPC, sementara semua permintaan lainnya ditolak.

Opsi kedua adalah menerapkan batasan laju. Mencegah alamat IP tertentu mengirim terlalu banyak permintaan xmlrpc.php dalam waktu singkat. Metode ini tidak seketat penutupan penuh; namun, ini mengurangi volume serangan di situs yang membutuhkannya. Opsi ketiga adalah menonaktifkan metode pingback dan hanya mengizinkan metode yang diperlukan. Ini memerlukan konfigurasi yang lebih canggih dan harus diterapkan di bawah kontrol pengembang.

Opsi keempat adalah menghubungkan akses XML-RPC dengan lapisan keamanan terpisah. Misalnya, otentikasi dasar HTTP, VPN, pembatasan IP perusahaan, atau tantangan WAF dapat diminta untuk verifikasi tambahan. Pendekatan ini mengurangi risiko titik akhir publik. Namun, jika memungkinkan, solusi jangka panjang adalah memindahkan integrasi lama ke metode yang lebih modern dan dapat dikontrol seperti REST API.

Peta Jalan Praktis untuk Pengguna Hostragons

Jika Anda adalah pemilik situs yang meng-host WordPress di Hostragons, lakukan analisis kebutuhan untuk keamanan XML-RPC, kemudian pilih metode yang paling sederhana. Mengedit .htaccess melalui manajer file di paket hosting bersama atau hosting WordPress mungkin cukup untuk sebagian besar pengguna. Jika Anda menggunakan VPS atau server khusus, Anda dapat merencanakan penggunaan Nginx, Apache, LiteSpeed, dan lapisan WAF secara bersamaan.

Urutan penerapan bisa sebagai berikut: Pertama, ambil cadangan, lalu periksa layanan yang menggunakan XML-RPC, kemudian lakukan pemblokiran di tingkat server, selesaikan pengujian, dan pantau log selama 24 jam. Jika percobaan serangan terus berlanjut, tambahkan aturan WAF, pemblokiran IP, dan batasan percobaan login. Pada tahap terakhir, selesaikan pengaturan keamanan umum seperti 2FA, kebijakan pembaruan, cadangan rutin, dan SSL.

Proses ini bukanlah peningkatan yang berorientasi pada penjualan, melainkan langkah dasar kebersihan. Namun, jika infrastruktur Anda terus-menerus menghadapi masalah karena versi PHP yang usang, sumber daya yang tidak memadai, atau kurangnya firewall, mempertimbangkan paket hosting yang lebih modern mungkin masuk akal. Lingkungan yang dioptimalkan untuk WordPress, dengan lapisan keamanan yang ada, tidak hanya memberikan ketahanan saat terjadinya serangan tetapi juga meningkatkan kinerja harian. Dalam konteks ini, halaman Hosting WordPress, Server Cloud, dan sertifikat SSL memberikan arahan alami kepada pembaca.

Pertanyaan yang Sering Diajukan

Apakah menonaktifkan XML-RPC WordPress akan merusak situs saya?

Menonaktifkan XML-RPC tidak merusak situs di sebagian besar situs WordPress standar. Panel admin, tema, konten, formulir, dan pihak pengunjung umumnya tidak terpengaruh. Namun, jika Anda menggunakan Jetpack, aplikasi mobile WordPress, atau integrasi khusus yang menggunakan XML-RPC, Anda mungkin mengalami masalah koneksi. Oleh karena itu, penting untuk memeriksa kebutuhan penggunaan sebelum menonaktifkannya dan menguji fungsi dasar setelahnya.

Bagaimana cara tahu jika XML-RPC sudah dinonaktifkan?

Buka alamat domainanda.com/xmlrpc.php di browser. Jika Anda melihat pesan seperti XML-RPC server accepts POST requests, berarti file masih dapat diakses. Jika Anda menerima 403, 404, atau penolakan akses, kemungkinan besar aturan penutupan berfungsi.

Apakah menonaktifkan XML-RPC menghentikan serangan brute force sepenuhnya?

Menonaktifkan XML-RPC secara signifikan mengurangi percobaan brute force yang berasal dari XML-RPC; tetapi tidak menghilangkan semua risiko brute force. Penyerang dapat terus mencoba melalui wp-login.php. Oleh karena itu, selain menonaktifkan XML-RPC, penting untuk menerapkan kata sandi yang kuat, autentikasi dua faktor, batasan percobaan login, WAF, dan kebijakan plugin yang mutakhir.

Jika saya menggunakan Jetpack, apakah saya perlu menonaktifkan XML-RPC?

Beberapa fitur dari Jetpack mungkin memerlukan koneksi XML-RPC. Jika Anda menggunakan Jetpack, periksa modul apa yang Anda gunakan sebelum sepenuhnya menonaktifkan XML-RPC. Sebagai alternatif, mengizinkan hanya alamat IP dari layanan Jetpack, memblokir semua permintaan xmlrpc.php lainnya, atau mendefinisikan akses terkontrol di WAF mungkin lebih tepat.

Mana yang lebih baik, menonaktifkan dengan plugin atau dari server?

Untuk kinerja dan keamanan terbaik, menonaktifkan di tingkat server atau WAF lebih efektif; karena permintaan ditolak sebelum WordPress dan PHP berjalan. Menonaktifkan melalui plugin lebih mudah bagi pengguna yang kurang teknis, tetapi tidak dapat sepenuhnya mencegah konsumsi sumber daya dalam serangan intensif. Jika memungkinkan, aturan server harus digunakan; jika tidak, pilih plugin yang dapat diandalkan dan dukungan WAF.

Ringkasan Singkat dan Langkah Selanjutnya

Menonaktifkan XML-RPC WordPress adalah salah satu cara tercepat untuk mengurangi serangan brute force, penyalahgunaan pingback, dan lalu lintas bot yang tidak perlu di situs yang tidak memerlukan XML-RPC. Pendekatan yang paling solid adalah memblokir akses xmlrpc.php di tingkat server atau WAF, kemudian membangun perlindungan berlapis dengan keamanan login, 2FA, pembaruan, SSL, dan cadangan rutin. Jika Anda ingin meninjau infrastruktur situs Anda, Anda dapat mengeksplorasi solusi hosting dan keamanan fokus WordPress dari Hostragons; dan Anda dapat mengambil langkah pertama hari ini dengan daftar periksa kecil untuk situs Anda yang ada.