WordPress’te xmlrpc.php Nasıl Etkinleştirilir ve Devre Dışı Bırakılır (Ve Neden Önemlidir)

xmlrpc.php dosyası, uzak uygulamaların kimlik doğrulaması yapmasına ve sunucu tarafı işlemleri gerçekleştirmesine olanak tanıyan bir XML-RPC API uç noktası sunan temel bir WordPress bileşenidir; gönderi yayımlama, yorum yönetimi, pingback tetikleme ve daha fazlası. Varsayılan olarak kimlik doğrulamasız POST isteklerini kabul ettiğinden ve çoğu güvenlik katmanı etkinleşmeden önce bunları işlediğinden, herhangi bir WordPress kurulumundaki en sık istismar edilen saldırı yüzeylerinden biridir.

WordPress mobil uygulamasını, Jetpack’i veya XML-RPC gerektiren herhangi bir üçüncü taraf hizmetini kullanmıyorsanız, xmlrpc.php dosyasını devre dışı bırakmak doğru varsayılan güvenlik tutumudur. Bu entegrasyonlara bağımlıysanız, uç noktayı tamamen kaldırmak yerine güçlendirebilirsiniz.

xmlrpc.php Nedir ve Nasıl Çalışır

XML-RPC (Extensible Markup Language Remote Procedure Call), fonksiyon çağrılarını XML ile kodlayan ve bunları HTTP üzerinden ileten bir protokoldür. WordPress, xmlrpc.php dosyasında uygulanan tam bir XML-RPC sunucusunu 3.5 sürümünden bu yana sunmaktadır; bu dosya WordPress kök dizininde yer almaktadır.

Uzak bir istemci — bir mobil uygulama, masaüstü blog istemcisi veya otomasyon betiği — https://yourdomain.com/xmlrpc.php adresine bir POST isteği gönderdiğinde, WordPress XML yükünü ayrıştırır, istek gövdesine gömülü kimlik bilgilerini doğrular ve istenen yöntemi çalıştırır. Tüm bu işlem tek bir HTTP gidiş-dönüşünde gerçekleşir; bu durum hem gücü hem de güvenlik açısından temel zayıflığıdır.

WordPress Tarafından Sunulan Temel XML-RPC Yöntemleri

• wp.newPost / wp.editPost — gönderileri uzaktan oluşturma ve güncelleme
• wp.getComments / wp.deleteComment — yorum yönetimi
• wp.uploadFile — sunucuya medya yükleme
• pingback.ping — uzak bir siteye bağlantı verildiğini bildirme
• system.multicall — birden fazla yöntem çağrısını tek bir HTTP isteğinde toplama

system.multicall yöntemi özellikle tehlikelidir. Tek bir HTTP isteği, her biri farklı bir parolayı deneyen yüzlerce wp.getUsersBlogs çağrısını bir arada barındırabilir. Bu, bir saldırganın yalnızca bir sunucu günlük kaydı oluştururken binlerce kimlik doğrulama denemesi yapmasına olanak tanır ve bireysel istekleri sayan hız sınırlama araçlarını devre dışı bırakır.

xmlrpc.php’yi Etkin Bırakmanın Güvenlik Riskleri

system.multicall Üzerinden Kaba Kuvvet Amplifikasyonu

Geleneksel kaba kuvvet saldırıları, HTTP isteği başına bir kimlik bilgisi çifti gönderir. XML-RPC ile bir saldırgan, tek bir system.multicall yüküne 500 oturum açma denemesi yerleştirebilir. Standart bir fail2ban kuralı veya oturum açma girişimi sayacı yalnızca bir istek görür; saldırgan ise 500 tahmin hakkı elde eder. Bu teorik bir risk değildir — pratikte gözlemlenen en yaygın XML-RPC istismarıdır.

Pingback ile Güçlendirilmiş DDoS

WordPress, gelen pingback isteklerini xmlrpc.php aracılığıyla otomatik olarak işler. Bir saldırgan, binlerce WordPress sitesine özel hazırlanmış bir pingback.ping isteği göndererek her birinin tek bir hedef URL’ye HTTP isteği göndermesini sağlayabilir. Hedef, meşru WordPress sunucularından kaynaklanan yoğun bir istek seli alır ve bu durum IP tabanlı engellemeyi etkisiz kılar. Sunucunuz aynı anda hem kurban (kaynak tükenmesi) hem de istemeden saldırı amplifikatörü haline gelir.

Pingback Üzerinden SSRF

Pingback mekanizması, Sunucu Tarafı İstek Sahteciliği (SSRF) için kötüye kullanılabilir. Bir saldırgan, kaynak URL’nin dahili bir ağ kaynağına — örneğin http://192.168.1.1/admin — işaret ettiği bir pingback.ping isteği gönderir. WordPress sunucusu bu URL’yi ağ çevresi içinden getirir ve bu durum, kamuya açık olmayan dahili hizmetleri potansiyel olarak açığa çıkarır.

İletim Sırasında Kimlik Bilgisi İfşası

XML-RPC, kimlik bilgilerini XML zarfı içinde düz metin olarak POST gövdesinde iletir. Siteniz HTTPS’yi zorunlu kılmıyorsa, kimlik bilgileri ağı izleyen herhangi birine açık hale gelir. TLS ile bile kimlik bilgileri her istekte gömülü olarak bulunur — ifşa penceresini sınırlayacak bir oturum belirteci veya OAuth akışı yoktur.

xmlrpc.php’yi Etkin Tutmanız Gereken Durumlar

Varsayılan olarak devre dışı bırakın, ancak iş akışınız gerçekten aşağıdakilerden herhangi birine bağımlıysa etkin tutun:

• WordPress mobil uygulaması (iOS/Android): Resmi uygulama, kendi barındırılan WordPress kurulumlarındaki tüm site yönetimi işlemleri için XML-RPC kullanır.
• Jetpack eklentisi: Publicize, mobil anlık bildirimler ve bazı istatistik özellikleri dahil olmak üzere çeşitli Jetpack modülleri, WordPress.com sunucularıyla XML-RPC üzerinden iletişim kurar.
• Masaüstü blog istemcileri: MarsEdit, Windows Live Writer ve benzeri araçlar yalnızca XML-RPC API’sine dayanır.
• Otomatik yayımlama ardışık düzenleri: WordPress’e içerik ileten IFTTT, Zapier ve özel betikler, REST API yapılandırılmamışsa genellikle XML-RPC kullanır.
• WordPress siteleri arasında pingback/trackback: Siteler arası pingback bildirimleri editoryal iş akışınızın bir parçasıysa, xmlrpc.php dosyasını devre dışı bırakmak bunları susturur.

Bunların hiçbiri geçerli değilse, uç noktayı açık bırakmak için operasyonel bir neden yoktur.

xmlrpc.php ile WordPress REST API Karşılaştırması

WordPress, XML-RPC’nin modern, token tabanlı bir alternatifi olarak 4.7 sürümünde REST API’yi tanıttı. Farklılıkları anlamak, XML-RPC’yi devre dışı bırakmanın kritik bir şeyi bozup bozmadığına karar vermenize yardımcı olur.

Yeni bir entegrasyon oluşturuyorsanız veya mevcut birini taşıyorsanız, REST API’yi kullanın. Kimlik doğrulama modeli çok daha güvenlidir ve uç nokta, altyapı düzeyinde denetlemek ve hız sınırlamak için çok daha kolaydır.

WordPress’te xmlrpc.php Nasıl Devre Dışı Bırakılır

Sunucu erişim düzeyinize ve risk toleransınıza uygun yöntemi seçin. Yöntemler, en düşükten en yüksek sunucu düzeyinde uygulamaya doğru sıralanmıştır.

Yöntem 1: Eklenti ile Devre Dışı Bırakma (En Hızlı, Sunucu Erişimi Gerektirmez)

Paylaşımlı barındırma ortamları veya sunucu yapılandırma dosyalarını düzenlemeyi tercih etmediğiniz siteler için eklenti en erişilebilir seçenektir.

Önerilen eklentiler:

• Disable XML-RPC-API — tek amaçlı, minimal ayak izi, anında etkinleşir
• All In One WP Security and Firewall — ayrıntılı XML-RPC kontrolleri içeren kapsamlı güvenlik paketi

Disable XML-RPC-API için adımlar:

1. WordPress kontrol panelinizde Eklentiler > Yeni Ekle bölümüne gidin.
2. “Disable XML-RPC-API” araması yapın ve Şimdi Yükle‘ye, ardından Etkinleştir‘e tıklayın.
3. Başka bir yapılandırma gerekmez — eklenti xmlrpc_enabled kancasına bağlanır ve etkinleştirme üzerine hemen false döndürür.

All In One WP Security and Firewall için adımlar:

1. Eklentiyi etkinleştirdikten sonra WP Security > Güvenlik Duvarı‘na gidin.
2. XML-RPC bölümünü bulun.
3. XML-RPC isteklerini tamamen engellemek için seçeneği etkinleştirin.
4. Ayarları kaydedin.

Sınırlama: Eklenti tabanlı engelleme, WordPress PHP yürütme bağlamı içinde tetiklenir. Sunucu yine de PHP’yi başlatır, WordPress’i yükler ve isteği reddetmeden önce işler. Yoğun bir saldırı altında bu durum CPU ve bellek tüketir. Aktif saldırı altındaki yüksek trafikli siteler için bunun yerine .htaccess veya Nginx yöntemini kullanın.

Yöntem 2: .htaccess ile Devre Dışı Bırakma (Apache — Sunucu Düzeyinde Engelleme)

.htaccess düzeyinde engelleme, xmlrpc.php hedefleyen istekler için PHP’nin hiç çalışmamasını sağlar. Bu durum, yük altında çok daha verimlidir.

1. FTP, SFTP veya barındırma dosya yöneticiniz aracılığıyla sunucunuza bağlanın ve WordPress kök dizinindeki .htaccess dosyasını açın (genellikle public_html/.htaccess).
2. Aşağıdaki bloğu ekleyin. Standart WordPress yeniden yazma kurallarından önce yerleştirin:

# Block all access to xmlrpc.php
<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
</Files>

1. Dosyayı kaydedin.

Bloğun etkin olduğunu doğrulamak için yerel makinenizden bir test çalıştırın:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Bir 403 yanıtı almanız gerekir. 200 veya 405 yanıtı, bloğun henüz etkin olmadığı anlamına gelir.

Uç durum — belirli güvenilir IP’lerden gelen pingback’lere hâlâ ihtiyaç duyuyorsanız, bunları beyaz listeye ekleyebilirsiniz:

<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
    Allow from 192.0.2.10
</Files>

Yöntem 3: Nginx Yapılandırması ile Devre Dışı Bırakma

Sunucunuz Nginx çalıştırıyorsa (VPS Hosting ortamlarında yaygındır), .htaccess dosyalarının hiçbir etkisi yoktur. Bloğu doğrudan sitenizin sunucu bloğu yapılandırmasına ekleyin.

# Block xmlrpc.php at the Nginx level
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

return 444 yönergesi, HTTP yanıtı göndermeden TCP bağlantısını kapatır; bu durum, saldırganın istemcisinin herhangi bir geri bildirim almasını engellediğinden 403 yanıtından daha verimlidir. Düzenledikten sonra Nginx’i yeniden yükleyin:

sudo nginx -t && sudo systemctl reload nginx

Bu location bloğunu, server {} bloğunuzun içine, herhangi bir try_files veya PHP işleme yönergesinden önce yerleştirin.

Yöntem 4: functions.php ile Devre Dışı Bırakma (WordPress Filtre Kancası)

Bu yöntem, XML-RPC’yi uygulama katmanında devre dışı bırakmak için bir WordPress filtresi kullanır. Sunucu düzeyinde engellemeden daha az verimlidir, ancak doğrudan sunucu erişiminiz olmadığında ve eklenti bağımlılığı olmadan kod tabanlı bir çözüm istediğinizde kullanışlıdır.

1. WordPress kontrol panelinizde Görünüm > Tema Düzenleyici‘ye gidin veya dosyaya doğrudan SFTP üzerinden wp-content/themes/your-theme/functions.php adresinden erişin.
2. Dosyanın sonuna aşağıdakini ekleyin:

// Disable XML-RPC completely
add_filter( 'xmlrpc_enabled', '__return_false' );

1. Dosyayı kaydedin.

Önemli uyarı: Bu filtre, kimlik doğrulamalı XML-RPC yöntemlerini devre dışı bırakır, ancak pingback.ping yöntemini engellemez veya dosyaya erişilmesini önlemez. Sunucu, WordPress’in filtreyi değerlendirdiği noktaya kadar isteği işlemeye devam eder. Tam koruma için bunu .htaccess veya Nginx bloğuyla birleştirin.

Alt tema kullanıyorsanız, özel kodu her zaman üst tema değil, alt temanın functions.php dosyasına ekleyin. Üst tema güncellemeleri değişikliklerinizin üzerine yazar.

Yöntem 5: Seçici Devre Dışı Bırakma — Yalnızca Pingback’leri Engelleme

Jetpack veya mobil yayımlama için XML-RPC’ye ihtiyaç duyuyorsanız ancak DDoS amplifikasyon vektörünü ortadan kaldırmak istiyorsanız, API’nin geri kalanını işlevsel tutarken yalnızca pingback yöntemini devre dışı bırakabilirsiniz.

// Disable only the pingback method, keep XML-RPC otherwise functional
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Bunu alt temanızın functions.php dosyasına veya siteye özgü bir eklentiye ekleyin. Bu, Jetpack çalıştıran ancak pingback almaya ihtiyaç duymayan siteler için önerilen yapılandırmadır.

xmlrpc.php Nasıl Yeniden Etkinleştirilir

Yukarıdaki yöntemlerden herhangi birini geri almak, XML-RPC erişimini yeniden sağlar:

• Eklenti yöntemi: Engelleme eklentisini Eklentiler > Yüklü Eklentiler bölümünden devre dışı bırakın veya silin.
• .htaccess yöntemi: <Files "xmlrpc.php"> bloğunu .htaccess dosyasından kaldırın ve kaydedin.
• Nginx yöntemi: location = /xmlrpc.php bloğunu sunucu yapılandırmanızdan kaldırın ve sudo systemctl reload nginx komutuyla Nginx’i yeniden yükleyin.
• functions.php yöntemi: add_filter( 'xmlrpc_enabled', '__return_false' ) satırını kaldırın ve kaydedin.

Yeniden etkinleştirdikten sonra uç noktanın doğru yanıt verdiğini doğrulayın:

curl -s -X POST https://yourdomain.com/xmlrpc.php 
  -H "Content-Type: text/xml" 
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

Mevcut yöntemleri listeleyen geçerli bir XML yanıtı, uç noktanın etkin olduğunu doğrular.

xmlrpc.php’yi Devre Dışı Bırakmadan Güçlendirme

Devre dışı bırakma bir seçenek değilse, saldırı yüzeyini azaltmak için şu önlemleri uygulayın:

HTTPS’yi zorunlu kılın: Sitenizin geçerli bir TLS sertifikası kullandığından emin olun. Henüz yapmadıysanız, barındırma sağlayıcınız aracılığıyla bir tane yapılandırın — SSL Sertifikaları, iletim sırasında kimlik bilgisi ele geçirilmesini önler.

Güvenlik duvarı veya CDN düzeyinde hız sınırlaması uygulayın: WAF’ınızı (Cloudflare, ModSecurity) xmlrpc.php adresine yönelik POST isteklerini IP başına dakikada en fazla 5–10 ile sınırlayacak şekilde yapılandırın.

system.multicall’ı özellikle engelleyin:

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['system.multicall'] );
    return $methods;
} );

Bu, diğer tüm XML-RPC işlevselliğini korurken kaba kuvvet amplifikasyon vektörünü ortadan kaldırır.

IP’ye göre kısıtlayın: XML-RPC’ye yalnızca bilinen IP adreslerinden erişiyorsanız (mobil uygulamanızın operatör IP aralığı veya statik bir ofis IP’si), bu adresleri .htaccess veya Nginx’te beyaz listeye ekleyin ve diğerlerini reddedin.

Erişim günlüklerini izleyin: xmlrpc.php adresine yönelik tekrarlanan POST istekleri için sunucu günlüklerinizi düzenli olarak denetleyin. Bu dosyaya yönelik 200 durum kodlu POST isteklerinde ani bir artış, devam eden bir kaba kuvvet kampanyasının güvenilir bir göstergesidir.

cPanel ile VPS veya diğer yönetilen panel ortamlarında, manuel dosya düzenlemesi yapmadan bu kısıtlamaları uygulamak için ModSecurity kurallarını doğrudan kontrol panelinden yapılandırabilirsiniz.

Doğru Yöntemi Seçme: Karar Matrisi

Dedicated Sunucular üzerinde barındırılan üretim siteleri için Nginx veya Apache sunucu düzeyinde blok, her zaman eklenti tabanlı çözüme tercih edilir; çünkü kötü amaçlı istekler için PHP yürütmesini tamamen engeller ve sürekli saldırı altında eklenti tabanlı engellemenin neden olduğu CPU yükünü ortadan kaldırır.

Pratik Temel Kontrol Listesi

• Devre dışı bırakmadan önce, yığınınızdaki herhangi bir etkin eklenti veya hizmetin gerçekten XML-RPC gerektirip gerektirmediğini denetleyin — Jetpack, mobil uygulamalar ve yayımlama otomasyon araçlarını kontrol edin.
• Bağımlılık yoksa, eklenti yerine sunucu düzeyinde bloğu (.htaccess veya Nginx) uygulayın — daha verimlidir ve eklenti devre dışı bırakıldığında da geçerliliğini korur.
• XML-RPC’yi etkin tutmanız gerekiyorsa, xmlrpc_methods filtresi aracılığıyla system.multicall ve pingback.ping yöntemlerini koşulsuz olarak kaldırın — bu iki yöntem, XML-RPC kötüye kullanımının büyük çoğunluğunu oluşturur.
• Kimlik doğrulamalı istekleri kabul eden her WordPress sitesinde, XML-RPC dahil, her zaman HTTPS’yi zorunlu kılın.
• Herhangi bir blok uyguladıktan sonra, uç noktanın 403 döndürdüğünü veya bağlantıyı kestiğini curl ile doğrulayın — yapılandırmanın doğru olduğunu test etmeden varsaymayın.
• Nginx tabanlı VPS veya dedicated sunucu ortamlarında, saldırganlara HTTP düzeyinde geri bildirim vermemek için deny all yerine return 444 kullanın.
• xmlrpc.php adresine yönelik POST isteklerini günlüğe kaydedin ve izleyin — ani bir artış, kimlik bilgisi doldurma veya DDoS amplifikasyon kampanyasının erken uyarısıdır.
• Birden fazla WordPress sitesi yönetiyorsanız, site başına eklenti kuralları uygulamak yerine bu yapılandırmayı sunucu veya CDN düzeyinde merkezileştirmeyi düşünün.

XML-RPC risk yüzeyi olmadan güçlü uzaktan yönetim gerektiren siteler için, entegrasyonları uygulama parolalarıyla WordPress REST API’sine taşımak doğru uzun vadeli yoldur. REST API, güvenliği ve denetimi çok daha kolay olan token başına iptal, kapsamlı izinler ve standart HTTP semantiği sağlar.

Yeni bir WordPress ortamı kuruyorsanız ve baştan temiz, güvenli bir temel istiyorsanız, ModSecurity önceden yapılandırılmış VPS Kontrol Panelleri, manuel kural yazımı gerektirmeden sunucu düzeyinde WAF koruması sağlar.

—

Sıkça Sorulan Sorular

xmlrpc.php’yi devre dışı bırakmak WordPress REST API’sini bozar mı?

Hayır. REST API (/wp-json/), kendi kimlik doğrulaması ve yönlendirmesiyle tamamen ayrı bir uç noktadır. xmlrpc.php dosyasını engellemek, REST API işlevselliği üzerinde hiçbir etkiye sahip değildir. İki sistem mimari olarak birbirinden bağımsızdır.

xmlrpc.php’yi devre dışı bırakmak Jetpack’i bozar mı?

Kullandığınız Jetpack modüllerine bağlıdır. Jetpack, özellikleri aşamalı olarak REST API’ye taşımıştır, ancak belirli publicize ve bildirim özellikleri dahil bazı eski modüller hâlâ XML-RPC üzerinden iletişim kurar. Devre dışı bırakmadan önce XML-RPC bağlantısının bir gereksinim olarak listelenip listelenmediğini görmek için Jetpack > Kontrol Paneli > Hata Ayıklama sayfasını kontrol edin.

.htaccess yöntemi mi yoksa functions.php yöntemi mi daha güvenlidir?

.htaccess yöntemi, saldırı koşullarında çok daha güvenlidir. İsteği PHP yüklenmeden önce web sunucusu katmanında engeller ve minimum kaynak tüketir. functions.php filtresi, WordPress’in PHP yürütme bağlamı içinde tetiklenir; bu da sunucunun engellenen her istek için WordPress’i başlatması anlamına gelir — yüksek hacimli bir saldırı altında bu durum maliyetlidir.

Bir saldırgan, yalnızca WordPress filtresi aracılığıyla devre dışı bırakırsam xmlrpc.php’yi hâlâ istismar edebilir mi?

Kısmen. xmlrpc_enabled filtresi, kimlik doğrulamalı yöntem çağrılarını engeller, ancak dosya kamuya açık erişilebilir olmaya devam eder ve sunucu gelen istekleri işlemeyi sürdürür. WordPress sürümüne bağlı olarak pingback uç noktası kısmen işlevsel kalabilir. Tam koruma için filtreyi sunucu düzeyinde bir blokla birleştirin.

xmlrpc.php’nin sitemde şu anda erişilebilir olup olmadığını nasıl kontrol edebilirim?

Aşağıdaki komutu yerel terminalinizden çalıştırın ve alan adını kendinizinkiyle değiştirin:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

200 yanıtı, uç noktanın açık olduğu anlamına gelir. 403 veya bağlantı kesilmesi (000), engellendiğini doğrular. Özellikle pingback açığını test etmek için xmlrpc.eritreo.it adresindeki çevrimiçi aracı da kullanabilirsiniz.