WordPress'te XML-RPC Nasil Kapatilir ve Neden Onemlidir

WordPress kurulumunuzun kök dizininde sessizce duran xmlrpc.php adında bir dosya var. Onu hiç açmamış, adını bile duymamış olabilirsiniz; ama sunucunuzun erişim kayıtlarına bakarsanız botların bu tek dosyaya günde yüzlerce, bazen binlerce istek attığını görürsünüz. XML-RPC, WordPress'in dış dünyayla konuşmasını sağlayan eski bir arayüzdür ve yıllarca masaüstü blog istemcileri, mobil uygulama ve Jetpack gibi araçlar için vazgeçilmezdi. Bugün ise durum değişti: modern WordPress bunun yerine REST API'yi kullanıyor, buna karşılık xmlrpc.php çoğu sitede hiç kullanılmadan açık kalmaya devam ediyor.

Sorun tam da burada başlıyor. Kullanmadığınız ama açık bıraktığınız her uç nokta, saldırganlar için bir kapıdır. XML-RPC özellikle iki tür saldırıda kötüye kullanılır: tek istekte yüzlerce parola denemesine izin veren "yükseltilmiş" (amplified) kaba kuvvet saldırıları ve sitenizi başka sitelere yönelik bir saldırı aracına çeviren pingback DDoS'u. Bu rehberde XML-RPC'nin ne olduğunu, neden bir risk oluşturduğunu ve onu güvenle nasıl kapatacağınızı; kapatmadan önce hangi araçların hâlâ ona ihtiyaç duyduğunu kontrol etmeniz gerektiğini adım adım göreceğiz.

XML-RPC Nedir ve Ne İşe Yarar?#

XML-RPC, adını "XML tabanlı Uzaktan Prosedür Çağrısı" (XML Remote Procedure Call) ifadesinden alır. Basitçe söylemek gerekirse, bir istemcinin sitenize XML biçiminde bir komut göndererek belirli işlemleri uzaktan yaptırmasını sağlayan bir protokoldür. WordPress'te bu protokolün tüm çağrıları kök dizindeki tek bir dosyaya, xmlrpc.php dosyasına gelir.

Bu arayüz sayesinde bir masaüstü uygulamasından yazı yayımlayabilir, mobil uygulamadan yorumları yönetebilir ya da iki WordPress sitesi birbirine bağlantı verdiğinde otomatik "pingback" bildirimi gönderebilirsiniz. Yıllar önce, henüz WordPress mobil uygulaması ve REST API bu kadar olgun değilken, bu özellikler gerçekten değerliydi.

Bir XML-RPC isteği kabaca şöyle görünür — istemci system.multicall gibi bir metodu, parametreleriyle birlikte XML gövdesinde gönderir:

<?xml version="1.0"?>
<methodCall>
  <methodName>wp.getUsersBlogs</methodName>
  <params>
    <param><value>kullanici_adi</value></param>
    <param><value>parola</value></param>
  </params>
</methodCall>

Görüldüğü gibi kimlik doğrulama, isteğin gövdesine gömülü kullanıcı adı ve parola ile yapılır. İşte bu tasarım, birazdan göreceğimiz saldırıların temelini oluşturur. WordPress 4.4 sürümünden bu yana yeni geliştirmeler REST API üzerinden yürüdüğü için xmlrpc.php artık çoğu site için gereksiz bir kalıntıdır; ama varsayılan olarak hâlâ etkin gelir.

XML-RPC Neden Bir Güvenlik Riski Oluşturur?#

XML-RPC'nin kötü niyetli kullanımının iki klasik biçimi vardır ve ikisi de protokolün kendi özelliklerinden doğar.

Birincisi yükseltilmiş kaba kuvvet saldırısıdır. Normal bir giriş sayfasında (wp-login.php) her parola denemesi ayrı bir HTTP isteği gerektirir; bu da sınırlama koymanızı ve şüpheli trafiği fark etmenizi kolaylaştırır. Oysa XML-RPC'deki system.multicall metodu, tek bir HTTP isteğinin içine yüzlerce hatta binlerce ayrı komut sığdırmaya izin verir. Yani saldırgan, tek bir istekte 500 farklı parolayı deneyebilir. Bu, sunucuya binen yükü ve yakalanma ihtimalini dramatik biçimde düşürürken saldırının hızını katlar. Sıradan bir "limit login" eklentisi tek tek istekleri sayar; ama tek istekte gelen 500 denemeyi çoğu zaman göremez.

İkincisi pingback DDoS saldırısıdır. XML-RPC'nin pingback.ping metodu, sitenizin belirtilen bir adrese HTTP isteği göndermesine yol açar. Saldırgan bu metodu binlerce farklı WordPress sitesine, hedef olarak tek bir kurban adresini vererek gönderirse, tüm o siteler aynı anda kurbana istek yağdırır. Böylece sizin siteniz, farkında olmadan başka birine yönelik dağıtık bir saldırının parçası hâline gelir. Sunucunuzun IP'si kötü şöhret listelerine düşebilir, kaynaklarınız tükenebilir ve barındırma sağlayıcınızdan uyarı alabilirsiniz.

Aşağıdaki tablo iki saldırı biçimini özetliyor:

Bu riskler soyut değildir. xmlrpc.php internetteki botların rutin olarak taradığı bir hedeftir; siteniz ne kadar küçük olursa olsun bu trafikten payını alır. XML-RPC'yi hiç kullanmıyorsanız, onu açık bırakmak yalnızca saldırı yüzeyinizi genişletmekten başka bir işe yaramaz. Konunun bütününü WordPress güvenliği rehberimizdeki diğer sertleştirme adımlarıyla birlikte değerlendirmenizi öneririz.

Kapatmadan Önce XML-RPC'ye İhtiyacınız Var mı?#

XML-RPC'yi kapatmak neredeyse her zaman doğru karardır, ama körü körüne yapılacak bir işlem değildir. Bazı araçlar hâlâ bu arayüze bağımlıdır ve onu kapattığınızda sessizce çalışmayı bırakabilirler. Kapatmadan önce şu kontrol listesini gözden geçirin.

• Jetpack: Jetpack eklentisinin bazı eski özellikleri (özellikle site istatistikleri ve uzaktan yönetim) XML-RPC üzerinden çalışır. Güncel sürümler büyük ölçüde REST API'ye geçmiş olsa da, bazı işlevler hâlâ xmlrpc.php gerektirebilir. Jetpack kullanıyorsanız, kapatma sonrası özelliklerin çalıştığını doğrulayın.
• Resmi WordPress mobil uygulaması: Uygulamanın eski sürümleri XML-RPC ile bağlanır. Güncel sürümler REST API'yi tercih eder; ama site adresini XML-RPC ile ekleyen kullanıcılar bağlantı hatası yaşayabilir.
• Masaüstü blog istemcileri: Windows Live Writer, MarsEdit ya da Open Live Writer gibi masaüstü yayın araçları yazıları XML-RPC ile gönderir. Bunları kullanıyorsanız XML-RPC'ye ihtiyacınız vardır.
• IFTTT, Zapier ve bazı otomasyon servisleri: Bir kısım üçüncü taraf entegrasyon XML-RPC üzerinden yazı yayımlar.

Bu araçlardan hiçbirini kullanmıyorsanız — ki çoğu tekil site sahibi kullanmaz — XML-RPC'yi tamamen kapatabilirsiniz. Jetpack ya da mobil uygulama kullanıyorsanız, birazdan göstereceğimiz yöntemler arasında yalnızca pingback.ping metodunu devre dışı bırakan, ama arayüzü tümüyle kapatmayan seçeneği tercih edebilirsiniz. Böylece pingback DDoS riskini ortadan kaldırır, ama gerekli entegrasyonları çalışır tutarsınız.

Kararı netleştirmek için hızlı bir özet:

Yöntem 1: Eklenti ile Kapatma (En Kolay)#

Sunucu dosyalarına dokunmak istemeyen çoğu kullanıcı için en pratik yol bir eklentidir. Bu yöntem kod bilgisi gerektirmez, tek tıkla geri alınabilir ve panelden yönetilir.

En yaygın seçenek Disable XML-RPC adlı hafif eklentidir. WordPress panelinizde "Eklentiler > Yeni Ekle" yolunu izleyip aratın, kurup etkinleştirin. Bu kadarı yeterlidir; eklenti xmlrpc_enabled filtresini false yaparak arayüzü kapatır. Ayrı bir ayar sayfası bile yoktur.

Daha kapsamlı bir güvenlik eklentisi zaten kullanıyorsanız, XML-RPC'yi kapatma seçeneği büyük olasılıkla onun içinde vardır:

• Wordfence: "Firewall > All Firewall Options" altında XML-RPC ile ilgili kuralları bulabilirsiniz.
• Solid Security (eski adıyla iThemes Security): "WordPress Tweaks" bölümünde "Disable XML-RPC" seçeneği vardır ve burada "tümüyle kapat" ile "yalnızca pingback'i kapat" arasında seçim yapabilirsiniz.
• All In One WP Security: "Firewall" sekmesinde tek onay kutusuyla kapatılır.

Eklenti yönteminin tek dezavantajı, isteğin yine de PHP çalıştırılarak (yani WordPress yüklenerek) engellenmesidir. Yani bot xmlrpc.php dosyasına ulaşır, WordPress çalışır ve ancak o noktada istek reddedilir. Yoğun bot trafiğinde bu, bir miktar sunucu kaynağı harcar. Sunucu düzeyinde engelleme (Yöntem 2 ve 3) isteği PHP'ye hiç ulaştırmadan keser; bu yüzden performans açısından daha üstündür. Yine de yönetim kolaylığı sizin için önceliyse eklenti tamamen yeterli bir çözümdür.

Yöntem 2: .htaccess ile Engelleme (Apache / cPanel)#

Apache tabanlı bir sunucuda ya da cPanel barındırmada çalışıyorsanız — Clou.TR paylaşımlı hosting paketlerinin büyük kısmı bu yapıdadır — en verimli yol .htaccess dosyasıyla engellemektir. Bu yöntem isteği daha WordPress yüklenmeden, doğrudan web sunucusu katmanında reddeder; böylece hem güvenlik hem performans kazanılır.

Sitenizin kök dizinindeki .htaccess dosyasını açın ve aşağıdaki bloğu ekleyin. Modern Apache 2.4 sözdizimi şöyledir:

# xmlrpc.php erişimini tümüyle engelle
<Files xmlrpc.php>
    Require all denied
</Files>

Daha eski Apache 2.2 sürümlerinde sözdizimi farklıdır:

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

Bu değişikliği yaptıktan sonra dosyayı kaydedin. Değişiklik anında etkindir; sunucuyu yeniden başlatmanız gerekmez. .htaccess dosyasının nasıl çalıştığı ve yönlendirme kuralları hakkında daha fazla ayrıntı için htaccess yönlendirme rehberimize göz atabilirsiniz.

Eğer XML-RPC'yi tümüyle kapatmak yerine yalnızca belirli bir IP'den (örneğin kendi ofisinizden ya da bir otomasyon servisinden) erişime izin vermek isterseniz, bloğu şöyle yazabilirsiniz:

<Files xmlrpc.php>
    Require all denied
    Require ip 203.0.113.10
</Files>

Burada 203.0.113.10 yerine izin vermek istediğiniz IP adresini yazın. Bu yaklaşım, Jetpack'in bağlandığı Automattic sunucularının IP aralıklarını beyaz listeye almanız gereken durumlar için de kullanışlıdır; ancak bu aralıklar zamanla değişebileceğinden, Jetpack kullanıcıları için genelde "yalnızca pingback kapat" yöntemi daha bakımsızdır.

Yöntem 3: Nginx ile Engelleme (VDS / Sanal Sunucu)#

Sitenizi bir sanal sunucu ya da VDS üzerinde Nginx ile çalıştırıyorsanız .htaccess işe yaramaz; çünkü Nginx bu dosyayı okumaz. Bunun yerine site yapılandırma dosyanıza (genellikle /etc/nginx/sites-available/ altında) bir location bloğu eklemeniz gerekir.

Sunucu bloğunuzun (server { ... }) içine şu kuralı yerleştirin:

# xmlrpc.php isteklerini reddet
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 403;
}

access_log off satırı, bot trafiğinin erişim günlüğünüzü şişirmesini önler; sürekli gelen bu isteklerin her birini kaydetmenin bir anlamı yoktur. Yapılandırmayı kaydettikten sonra önce sözdizimini test edin, ardından Nginx'i yeniden yükleyin:

sudo nginx -t
sudo systemctl reload nginx

nginx -t çıktısı syntax is ok ve test is successful diyorsa değişikliğiniz güvenle uygulanmıştır. Belirli bir IP'ye izin vermek isterseniz deny all yerine önce allow kuralını yazın:

location = /xmlrpc.php {
    allow 203.0.113.10;
    deny all;
    return 403;
}

Nginx kuralları yukarıdan aşağıya değerlendirilir; bu yüzden allow satırı mutlaka deny all satırından önce gelmelidir. Sunucu yönetimini kendiniz üstlenmek istemiyorsanız, bu tür yapılandırmaları sizin adınıza sunucu yönetimi hizmetimiz kapsamında yapabiliriz.

Yöntem 4: functions.php ve Filtre ile Devre Dışı Bırakma#

Sunucu dosyalarına erişiminiz yoksa ve eklenti de kurmak istemiyorsanız, temanızın (tercihen bir alt temanın) functions.php dosyasına birkaç satır kod ekleyerek XML-RPC'yi devre dışı bırakabilirsiniz. Bu yöntem WordPress katmanında çalışır ve esnek olması sayesinde ince ayar yapmaya olanak tanır.

Arayüzü tümüyle kapatmak için:

// XML-RPC'yi tamamen devre dışı bırak
add_filter( 'xmlrpc_enabled', '__return_false' );

Eğer XML-RPC'yi çalışır tutup yalnızca pingback riskini ortadan kaldırmak isterseniz — Jetpack ya da mobil uygulama kullananlar için ideal seçenek budur — arayüzü kapatmak yerine yalnızca pingback metotlarını kaldırın:

// Pingback metotlarını XML-RPC listesinden çıkar
add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

// Giden HTTP başlıklarındaki X-Pingback satırını da temizle
add_filter( 'wp_headers', function ( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
} );

İlk blok gelen pingback saldırılarını, ikinci blok ise sitenizin X-Pingback başlığını ilan etmesini engeller. Böylece botlar sitenizin pingback desteklediğini keşfetmekte de zorlanır.

Bu yöntemi kullanırken dikkat edilmesi gereken bir nokta var: Kod, temanın functions.php dosyasında durduğu için tema güncellendiğinde ya da değiştirildiğinde kaybolabilir. Bu yüzden değişikliği mutlaka bir alt temada (child theme) ya da siteye özel küçük bir eklentide tutun. Aksi halde tema güncellemesinin ardından koruma sessizce ortadan kalkar.

Kapattığınızı Nasıl Doğrularsınız?#

Herhangi bir yöntemi uyguladıktan sonra XML-RPC'nin gerçekten kapandığını test etmek önemlidir. Aksi halde koruma sağladığınızı sanıp aslında dosyayı açık bırakmış olabilirsiniz. En hızlı doğrulama yolu komut satırından bir curl isteğidir.

Terminalden şu komutu çalıştırın (adresi kendi alan adınızla değiştirin):

curl -s -o /dev/null -w "%{http_code}\n" https://alanadiniz.com/xmlrpc.php

Aldığınız yanıt kodu koruma durumunuzu gösterir. Aşağıdaki tabloda dönebilecek kodların anlamları var:

Eklenti ya da functions.php yöntemini kullandıysanız xmlrpc.php dosyası bir POST isteğine yanıt olarak genellikle 200 döndürür ama gövdede "XML-RPC services are disabled on this site" benzeri bir hata mesajı bulunur. Bunu görmek için gerçek bir metot çağrısı gönderebilirsiniz:

curl -s -X POST https://alanadiniz.com/xmlrpc.php \
  -d '<methodCall><methodName>demo.sayHello</methodName></methodCall>'

Yanıtta "disabled" ya da "faultString" ifadesi geçiyorsa arayüz devre dışıdır. Sunucu düzeyinde (403) engelleme en kesin sonucu verir, çünkü bu durumda WordPress'e istek hiç ulaşmaz. Değişikliğin ardından tarayıcınızın ve varsa CDN'inizin önbelleğini temizleyip testi tekrarlamayı unutmayın.

XML-RPC'yi Kapattıktan Sonra Ne Yapmalısınız?#

XML-RPC'yi kapatmak önemli bir adımdır, ama tek başına sitenizi güvenli kılmaz; sadece bir saldırı vektörünü kapatır. Botlar bu kapının kapandığını görünce enerjilerini başka noktalara, en çok da wp-login.php giriş sayfasına yöneltir. Bu yüzden kapatmayı bir dizi sertleştirme adımının parçası olarak düşünmek gerekir.

XML-RPC engellemesini şu önlemlerle tamamlayın:

• Giriş denemelerini sınırlayın: Bir "limit login" eklentisiyle art arda başarısız girişlerden sonra IP'yi geçici olarak engelleyin. XML-RPC kapalıyken saldırganların tek seçeneği normal giriş sayfası olur ve orada bu sınır işe yarar.
• İki adımlı doğrulama (2FA) açın: Yönetici hesaplarında 2FA, parola ele geçirilse bile girişi engeller.
• WAF kullanın: Bir web uygulama güvenlik duvarı, zararlı istekleri sitenize ulaşmadan filtreler. Clou.TR WAF hizmeti bu türden saldırı desenlerini otomatik yakalar.
• DDoS koruması alın: Pingback ya da yoğun bot trafiği kaynak tüketimine yol açıyorsa, DDoS koruma katmanı trafiği sunucu sınırından önce süzer.
• Düzenli yedek alın: En kötü senaryoda temiz bir yedekten dönebilmek, her güvenlik planının olmazsa olmazıdır.

Bu önlemlerin çoğunu tek tek üstlenmek istemiyorsanız, güncelleme, izleme ve sertleştirmeyi düzenli olarak sizin yerinize yapan WordPress bakım hizmetimiz bütün bu adımları bir arada yürütür. Optimize edilmiş bir altyapıda başlamak isteyenler için ise WordPress hosting paketlerimiz, bu güvenlik katmanlarının bir kısmını sunucu düzeyinde hazır sunar.

Sıkça Sorulan Sorular#

XML-RPC'yi kapatmak sitemi bozar mı?#

Hayır, tekil bir site kullanıyorsanız ve Jetpack, masaüstü blog istemcisi ya da eski mobil uygulama bağlantısı kullanmıyorsanız XML-RPC'yi kapatmak sitenizin görünen işleyişini hiçbir şekilde etkilemez. Modern WordPress zaten yeni işlemleri REST API üzerinden yürütür; xmlrpc.php çoğu sitede tümüyle atıl durur. Yalnızca yukarıda saydığımız özel araçları kullanıyorsanız kapatmadan önce test etmeniz yeterlidir.

Jetpack kullanıyorum, XML-RPC'yi yine de kapatabilir miyim?#

Jetpack'in bazı işlevleri XML-RPC'ye bağlı olabileceği için arayüzü tümüyle kapatmak yerine yalnızca pingback.ping metodunu devre dışı bırakmanızı öneririz. Yöntem 4'te gösterdiğimiz filtreli yaklaşım tam da bunun içindir; pingback saldırısı riskini ortadan kaldırırken Jetpack'in ihtiyaç duyduğu diğer metotları çalışır bırakır. Kapattıktan sonra Jetpack panelinden istatistik ve bağlantı durumunu kontrol edin.

xmlrpc.php dosyasını tamamen silmek daha güvenli olmaz mı?#

Dosyayı elle silmek pratik bir çözüm değildir, çünkü WordPress'in her güncellemesinde xmlrpc.php yeniden oluşturulur; bu da silme işleminizi bir sonraki güncellemede geçersiz kılar. Ayrıca dosyayı silmek beklenmedik hatalara yol açabilir. Bunun yerine dosyayı yerinde bırakıp .htaccess, Nginx kuralı ya da filtre ile erişimi engellemek hem kalıcı hem de güncellemelere dayanıklı olan doğru yaklaşımdır.

Kapattıktan sonra günlüklerde hâlâ xmlrpc.php istekleri görüyorum, normal mi?#

Evet, bu tamamen normaldir. Botlar sitenizin XML-RPC'yi kapatıp kapatmadığını bilmeden istek göndermeye devam eder; önemli olan bu isteklerin artık başarısız olmasıdır. Sunucu düzeyinde engelleme kullandıysanız günlükte bu isteklerin yanında 403 kodunu görürsünüz, bu da korumanın çalıştığını doğrular. İsterseniz Nginx örneğindeki gibi access_log off ile bu istekleri kayıtlardan tümüyle çıkarabilirsiniz.

Paylaşımlı hosting kullanıyorum, hangi yöntemi seçmeliyim?#

Paylaşımlı hosting ve cPanel ortamlarında en uygun yöntem .htaccess ile engellemedir; çünkü sunucu yapılandırmasına erişiminiz olmasa da kendi kök dizininizdeki .htaccess dosyasını düzenleyebilirsiniz. Bu yöntem isteği PHP'ye ulaştırmadan keser ve kaynak açısından en verimli seçenektir. Dosya düzenlemek istemiyorsanız Disable XML-RPC gibi hafif bir eklenti de tamamen yeterli bir alternatiftir.

Sadece pingback'i kapatmak brute force saldırısını da engeller mi?#

Hayır. Yalnızca pingback.ping metodunu kaldırmak pingback DDoS riskini ortadan kaldırır, ancak system.multicall üzerinden yürütülen yükseltilmiş kaba kuvvet saldırısı hâlâ mümkün olabilir. İki riskin ikisini birden ortadan kaldırmak istiyorsanız XML-RPC'yi tümüyle kapatmanız gerekir. Jetpack gibi bir aracı çalışır tutmak zorundaysanız, pingback'i kapatıp giriş güvenliğini 2FA ve giriş sınırlaması ile ayrıca güçlendirin.

Kapanış#

XML-RPC, bir zamanlar WordPress'in dış dünyayla konuşmasını sağlayan değerli bir köprüydü; bugün ise çoğu site için yalnızca açık bırakılmış, kullanılmayan bir kapıdır. Bu kapıyı kapatmak, yükseltilmiş kaba kuvvet ve pingback DDoS gibi iki yaygın saldırı vektörünü tek hamlede etkisiz hâle getirir. Hangi yöntemi seçeceğiniz ortamınıza bağlıdır: paylaşımlı hosting ve cPanel için .htaccess, VDS ve sanal sunucu için Nginx kuralı, dosyalara dokunmak istemeyenler için eklenti ya da filtre. Jetpack veya mobil uygulama kullanıyorsanız arayüzü tümüyle kapatmak yerine yalnızca pingback'i devre dışı bırakın; kapatmanın ardından curl ile mutlaka doğrulayın.

Unutmayın ki XML-RPC'yi kapatmak, güvenliğin bütünü değil bir parçasıdır. Gerçek koruma; güncel yazılım, güçlü parola, 2FA, giriş sınırlaması ve bir güvenlik duvarının bir araya gelmesiyle oluşur. Sitenizi baştan sağlam bir altyapıda kurmak isterseniz WordPress hosting paketlerimize, güvenlik ve bakımı düzenli olarak bize bırakmak isterseniz WordPress bakım hizmetimize göz atabilir; saldırıları daha sunucuya ulaşmadan süzmek için WAF çözümümüzü değerlendirebilirsiniz. Doğru yapılandırılmış küçük bir önlem, ileride yaşanacak büyük bir baş ağrısını en baştan engeller.