WordPress XML-RPC Kapatma: Brute Force Saldırılarından Kurtulmanın En Kısa Yolu

WordPress XML-RPC kapatma, sitenizdeki xmlrpc.php dosyasının uzaktan istek almasını engelleyerek brute force denemelerini, pingback istismarlarını ve gereksiz bot trafiğini hızlıca azaltma işlemidir. Eğer Jetpack, WordPress mobil uygulaması, eski uzaktan yayınlama araçları veya XML-RPC kullanan özel bir entegrasyon kullanmıyorsanız, XML-RPC’yi kapatmak çoğu WordPress sitesi için güvenli ve pratik bir sertleştirme adımıdır. En etkili yöntem, isteği WordPress çalışmadan önce sunucu seviyesinde engellemektir; yani Apache, LiteSpeed, Nginx veya WAF kuralı ile xmlrpc.php erişimini kesmek, eklentiyle kapatmaktan genellikle daha performanslıdır.

Bu rehberde WordPress XML-RPC kapatma işlemini neden yapmanız gerektiğini, hangi durumda kapatmamanız gerektiğini ve farklı sunucu ortamlarında nasıl güvenle uygulayacağınızı adım adım bulacaksınız. Hostragons altyapısında veya başka bir barındırma ortamında çalışıyor olmanız fark etmez; amaç, sitenizi kırmadan saldırı yüzeyini küçültmek, gereksiz kaynak tüketimini azaltmak ve yönetilebilir bir güvenlik standardı oluşturmaktır. WordPress sitenizi barındırırken hızlı ve güvenli bir temel arıyorsanız WordPress hosting seçimi de bu sürecin önemli parçalarından biridir.

XML-RPC Nedir ve WordPress’te Ne İşe Yarar?

XML-RPC, farklı sistemlerin HTTP üzerinden XML formatında veri göndererek birbiriyle konuşmasını sağlayan eski bir uzaktan iletişim protokolüdür. WordPress tarafında bu işlev genellikle kök dizindeki xmlrpc.php dosyası üzerinden yürür. Tarihsel olarak bu dosya, WordPress mobil uygulamasından yazı yayınlama, uzaktan yorum yönetimi, pingback ve bazı üçüncü taraf servislerin siteyle etkileşim kurması için kullanıldı.

Modern WordPress ekosisteminde REST API çok daha yaygın hale geldiği için XML-RPC’nin önemi azaldı. Ancak dosya hâlâ birçok kurulumda erişilebilir durumdadır. Bu da saldırganlar için kolay keşfedilebilir, standart yolu belli ve otomasyonla hedeflenebilir bir uç nokta anlamına gelir. Özellikle rastgele IP aralıklarını tarayan botlar, alan adınız yeni kurulmuş olsa bile xmlrpc.php adresini dakikalar içinde deneyebilir. Bu yüzden domain sorgulama ile yeni aldığınız alan adını yayına açarken güvenlik temelini en baştan düşünmek önemlidir.

XML-RPC Hangi Durumlarda Gerekli Olabilir?

XML-RPC her site için gereksiz değildir. Jetpack’in bazı eski özellikleri, WordPress mobil uygulamasının belirli işlemleri, bazı otomasyon servisleri veya eski masaüstü blog editörleri XML-RPC’ye ihtiyaç duyabilir. Ayrıca özel geliştirilmiş entegrasyonlar, içerik gönderimi ya da uzaktan veri alma için xmlrpc.php kullanıyor olabilir. Bu nedenle kapatmadan önce sitenizin iş akışını kontrol etmek gerekir.

Pratik kontrol şudur: Sitenize içerikleri yalnızca wp-admin panelinden giriyorsanız, Jetpack kullanmıyorsanız, mobil uygulamadan yayın yapmıyorsanız ve geliştiriciniz özel XML-RPC entegrasyonu kurmadıysa büyük olasılıkla XML-RPC’ye ihtiyacınız yoktur. Kurumsal siteler, bloglar, katalog siteleri, küçük işletme web siteleri ve WooCommerce mağazalarının önemli bir bölümü XML-RPC kapalıyken sorunsuz çalışır. Yine de WooCommerce, ödeme altyapısı ve kargo entegrasyonları gibi kritik süreçleriniz varsa değişikliği yoğun olmayan saatlerde test etmeniz en sağlıklı yaklaşımdır.

WordPress XML-RPC Neden Brute Force İçin Risklidir?

Brute force saldırısı, saldırganın kullanıcı adı ve şifre kombinasyonlarını otomatik araçlarla tekrar tekrar denemesidir. WordPress’te bu denemeler genellikle wp-login.php üzerinden yapılır; ancak XML-RPC, saldırgana daha avantajlı bir yol sunabilir. Çünkü bazı XML-RPC metodları tek bir HTTP isteği içinde birden fazla giriş denemesi yapılmasına izin verebilir. Özellikle system.multicall özelliği, zayıf yapılandırılmış sistemlerde yüzlerce denemenin daha az görünür istekle yapılmasına yardımcı olabilir.

Örneğin wp-login.php üzerinden 500 şifre denemesi yapmak 500 ayrı istek gibi görünürken, XML-RPC üzerinden aynı denemeler daha az sayıda paketlenmiş istekle gönderilebilir. Bu, güvenlik eklentilerinin ve basit log takiplerinin saldırıyı geç fark etmesine yol açabilir. Sonuçta CPU kullanımı artar, PHP worker’ları meşgul olur, veritabanı gereksiz sorgularla yorulur ve gerçek ziyaretçiler daha yavaş cevap alır. Paylaşımlı hosting ortamlarında bu durum yalnızca güvenlik riski değil, performans ve kaynak kullanımı sorunudur.

XML-RPC’nin bir diğer riskli alanı pingback istismarıdır. Pingback mekanizması, başka bir sitenin sizin içeriğinize link verdiğini bildirmek için tasarlanmıştır; fakat kötüye kullanımda DDoS benzeri trafik üretmek veya üçüncü taraf siteleri hedef göstermek için kullanılabilir. Bu nedenle XML-RPC kapatma, yalnızca giriş denemelerini azaltmaz; aynı zamanda pingback kaynaklı kötüye kullanım ihtimalini de düşürür.

XML-RPC Kapatma Kararı: Hızlı Karşılaştırma Tablosu

Tablodan da görüleceği gibi en kısa ve güçlü yol, XML-RPC’ye ihtiyacınız yoksa sunucu veya WAF seviyesinde kapatmaktır. Eklenti kullanmak kolaydır; fakat saldırı isteği PHP’ye kadar ulaşırsa kaynak tüketimi devam edebilir. Bu nedenle yüksek trafikli, e-ticaret odaklı veya saldırı alan sitelerde öncelik web sunucusu kuralı olmalıdır.

Başlamadan Önce Kontrol Listesi

Güvenlik ayarı yaparken temel prensip, önce ölçmek ve geri dönüş planı hazırlamaktır. XML-RPC kapatma işlemi genellikle risksizdir; ancak canlı sitede hiçbir değişiklik körlemesine yapılmamalıdır. Aşağıdaki kontrol listesi, uygulama sırasında hata yaşama ihtimalinizi azaltır.

• Son 24 saat içinde alınmış çalışan bir dosya ve veritabanı yedeğiniz olsun. WordPress güncellemesi, güvenlik düzenlemesi ve eklenti değişikliği öncesi yedek zorunlu kabul edilmelidir.
• Jetpack, WordPress mobil uygulaması, uzaktan yayınlama aracı veya özel entegrasyon kullanıp kullanmadığınızı kontrol edin.
• Erişim loglarında xmlrpc.php istek sayısını inceleyin. Dakikada onlarca veya yüzlerce istek görüyorsanız saldırı altında olabilirsiniz.
• Değişikliği düşük trafik saatinde yapın. Özellikle WooCommerce mağazalarında sepet, ödeme ve üyelik akışını sonradan test edin.
• Bir geri alma yöntemi belirleyin. Eklediğiniz kuralı yorum satırına almak veya silmek için dosya yöneticisi, FTP ya da SSH erişiminiz hazır olsun.

Profesyonel bir barındırma ortamında düzenli yedek, güncel PHP sürümü, izole hesap yapısı ve güvenlik duvarı desteği büyük fark yaratır. Bu konularda altyapı seçimi için güvenli web hosting ve site genel güvenliği için SSL sertifikası içeriklerine de bağlantı verilebilir.

Yöntem 1: Apache veya LiteSpeed Üzerinde .htaccess ile XML-RPC Kapatma

Apache ve LiteSpeed kullanan WordPress sitelerinde en yaygın yöntem, sitenin kök dizinindeki .htaccess dosyasına xmlrpc.php erişimini engelleyen bir kural eklemektir. LiteSpeed, Apache uyumlu .htaccess kurallarını desteklediği için bu yöntem birçok hosting ortamında doğrudan uygulanabilir. En büyük avantaj, isteğin WordPress çekirdeği çalışmadan reddedilmesidir.

Adım Adım Uygulama

• Hosting kontrol panelinizden dosya yöneticisini açın veya FTP ile public_html dizinine bağlanın.
• .htaccess dosyasını bulun ve bilgisayarınıza yedekleyin. Dosya görünmüyorsa gizli dosyaları göster seçeneğini aktif edin.
• WordPress tarafından oluşturulan kuralları silmeden, dosyanın üst kısmına XML-RPC engelleme kuralını ekleyin.
• Kural mantığı şu olmalıdır: xmlrpc.php dosyasına gelen tüm erişimleri reddet.
• Kaydedin ve tarayıcıdan alanadiniz.com/xmlrpc.php adresini kontrol edin.

Apache 2.4 ve LiteSpeed ortamlarında kullanacağınız mantık şu şekildedir: xmlrpc.php dosyası için Require all denied tanımı yapılır. Eski Apache 2.2 ortamlarında ise Deny from all yaklaşımı görülebilir; ancak 2026 standardında güncel sunucu yazılımı kullanmanız önerilir. Eğer hâlâ eski Apache sürümüyle çalışıyorsanız bu, yalnızca XML-RPC değil genel güvenlik açısından da iyileştirilmesi gereken bir konudur.

Başarılı bir engellemede xmlrpc.php adresi 403 Forbidden, 404 Not Found veya sunucu yapılandırmanıza göre benzer bir erişim reddi cevabı dönebilir. Önemli olan, sayfanın XML-RPC server accepts POST requests benzeri bir yanıt vermemesidir. Bu ifade görünüyorsa dosya hâlâ erişilebilir demektir.

Yöntem 2: Nginx Üzerinde XML-RPC Erişimini Engelleme

Nginx ortamlarında .htaccess çalışmaz; çünkü Nginx dizin bazlı .htaccess okumaz. Bu nedenle kural, siteye ait server block yapılandırmasına eklenmelidir. Yönetimli hosting kullanıyorsanız bu alan doğrudan size açık olmayabilir; bu durumda hosting destek ekibinizden xmlrpc.php erişiminin kapatılmasını isteyebilirsiniz.

Nginx tarafında temel yaklaşım, location = /xmlrpc.php bloğu ile isteği reddetmek veya 404 döndürmektir. Güvenlik açısından 403 ile açıkça yasaklamak da, 404 ile dosya yokmuş gibi göstermek de kullanılabilir. 404 yaklaşımı botlara daha az bilgi vermek isteyen yöneticiler tarafından tercih edilir. Kural eklendikten sonra Nginx yapılandırması test edilmeli ve servis yeniden yüklenmelidir. Hatalı bir karakter tüm sitenin açılmamasına neden olabileceği için bu işlem mutlaka dikkatle yapılmalıdır.

Nginx kullanan VPS veya dedicated sunucularda değişiklikten sonra erişim loglarını takip etmek faydalıdır. xmlrpc.php isteklerinin artık 403 veya 404 ile sonuçlandığını görmelisiniz. Aynı IP’lerden yoğun denemeler devam ediyorsa fail2ban, rate limit veya WAF kuralı ile ikinci katman savunma eklenebilir. Sunucu yönetimi tarafında daha kapsamlı rehberler için VPS sunucu güvenliği bağlantısı değerlendirilebilir.

Yöntem 3: Güvenlik Eklentisi ile XML-RPC Kapatma

Teknik dosya düzenlemek istemeyen kullanıcılar için güvenlik eklentileri pratik bir çözümdür. Wordfence, Solid Security, All-In-One Security benzeri eklentilerde XML-RPC devre dışı bırakma, pingback kapatma veya XML-RPC login denemelerini engelleme seçenekleri bulunabilir. Bu yöntem özellikle küçük bloglar ve temel kurumsal siteler için hızlı başlangıç sağlar.

Ancak eklenti yaklaşımının sınırını bilmek gerekir. Eğer eklenti WordPress çalıştıktan sonra isteği engelliyorsa, saldırganın isteği yine PHP sürecini tetikleyebilir. Bu, yoğun saldırılarda CPU ve bellek tüketiminin tamamen kesilmediği anlamına gelir. Bu nedenle eklenti ile kapatma, hiç önlem almamaktan çok daha iyidir; fakat saldırı altındaki sitelerde sunucu veya WAF katmanı ile desteklenmelidir.

Eklenti Kullanırken Dikkat Edilecekler

• Güvenlik eklentisini yalnızca resmi WordPress eklenti dizininden veya üreticinin resmi sitesinden indirin.
• Uzun süredir güncellenmeyen eklentileri tercih etmeyin. 2026’da aktif bakım ve uyumluluk önemli bir güven sinyalidir.
• Birden fazla güvenlik eklentisini aynı iş için üst üste kullanmayın. Çakışmalar giriş, önbellek ve dosya erişim sorunları oluşturabilir.
• XML-RPC ayarını yaptıktan sonra site sağlık ekranını, formları, üyelik girişini ve ödeme akışını test edin.
• Eklenti loglarını düzenli inceleyin. Sürekli saldırı varsa IP bazlı engelleme veya WAF kuralı ekleyin.

Yöntem 4: WAF, CDN ve Hosting Güvenlik Duvarı ile Engelleme

Web Application Firewall, yani WAF, zararlı istekleri uygulamaya ulaşmadan süzmek için en etkili katmanlardan biridir. Cloudflare gibi CDN tabanlı çözümler, sunucu önünde xmlrpc.php isteklerini engelleyebilir. Hosting sağlayıcınızın sunduğu ModSecurity veya özel WAF kuralları da benzer şekilde çalışır. Bu katman, özellikle çok sayıda bot isteğini WordPress’e hiç ulaştırmadan kesmek için değerlidir.

WAF kuralında hedef net olmalıdır: URI yolu xmlrpc.php içeriyorsa isteği blokla veya challenge uygula. Eğer XML-RPC’ye tamamen ihtiyacınız yoksa blok daha nettir. Kısmen ihtiyaç varsa yalnızca belirli IP adreslerine izin verme yaklaşımı kullanılabilir. Örneğin bir otomasyon servisiniz sabit IP’den geliyorsa, bu IP beyaz listeye alınır ve diğer tüm xmlrpc.php istekleri reddedilir. Bu yöntem, güvenlik ile iş sürekliliği arasında dengeli bir çözümdür.

WAF katmanı, SSL ile birlikte daha anlamlıdır. HTTPS kullanmayan sitelerde giriş bilgileri ve oturum güvenliği ayrıca risk altındadır. Bu nedenle XML-RPC kapatma yanında tüm siteyi HTTPS üzerinden çalıştırmak, HSTS gibi başlıkları değerlendirmek ve sertifika süresini takip etmek gerekir. Bu noktada SSL sertifikası ve ücretsiz SSL kurulumu konuları doğal destek içerikleri olarak kullanılabilir.

XML-RPC Kapatma Sonrası Test Nasıl Yapılır?

Değişiklikten sonra tek bakılacak nokta sitenin açılması değildir. XML-RPC kapalı mı, giriş sistemi sorunsuz mu, gerçek kullanıcı işlemleri etkilenmiş mi, loglarda beklenen sonuç var mı gibi kontroller yapılmalıdır. Aşağıdaki test akışı, pratik ve yeterli bir doğrulama sağlar.

• Tarayıcıdan alanadiniz.com/xmlrpc.php adresini açın. Erişim reddi, 404 veya boş cevap almanız beklenir. XML-RPC server accepts POST requests metni görünmemelidir.
• WordPress yönetim paneline normal kullanıcı bilgilerinizle giriş yapın. Giriş sayfasının XML-RPC’den bağımsız olarak çalıştığını doğrulayın.
• İletişim formu, yorum formu, üyelik ve WooCommerce ödeme adımlarını test edin.
• Sunucu erişim loglarında xmlrpc.php isteklerinin hangi durum koduyla döndüğünü kontrol edin. 403 veya 404 yanıtları doğru kuralın çalıştığını gösterir.
• Güvenlik eklentiniz varsa olay günlüklerini inceleyin. Eski bot denemelerinin azaldığını veya engellendiğini görmelisiniz.

Daha teknik bir test için terminalden POST isteği gönderilebilir; ancak çoğu site sahibi için tarayıcı ve log kontrolü yeterlidir. Eğer değişiklikten sonra Jetpack bağlantısı koparsa, mobil uygulama yayın yapamazsa veya bir entegrasyon hata verirse XML-RPC’ye gerçekten ihtiyaç olduğu anlaşılır. Bu durumda tam kapatma yerine IP bazlı izin verme veya rate limit stratejisi düşünülmelidir.

XML-RPC’yi Kapatmak Yeterli mi? Ek Güvenlik Önlemleri

XML-RPC kapatma, brute force saldırılarına karşı hızlı ve etkili bir adımdır; fakat tek başına tam güvenlik sağlamaz. Saldırgan wp-login.php, REST API, zayıf eklentiler, eski temalar veya sızdırılmış şifreler üzerinden de deneme yapabilir. Bu nedenle XML-RPC’yi kapattıktan sonra WordPress güvenliğini katmanlı düşünmek gerekir.

Uygulanması Gereken Temel Önlemler

• Güçlü şifre ve benzersiz kullanıcı adı kullanın. admin kullanıcı adını kullanmamak hâlâ basit ama etkili bir önlemdir.
• İki faktörlü kimlik doğrulama ekleyin. Yönetici hesaplarında 2FA, şifre sızıntısı riskini ciddi şekilde azaltır.
• Giriş denemesi sınırı uygulayın. wp-login.php için rate limit veya güvenlik eklentisi kullanın.
• WordPress çekirdeğini, eklentileri ve temaları güncel tutun. Eski eklentiler gerçek dünyadaki ihlallerin en sık nedenlerindendir.
• Kullanmadığınız eklenti ve temaları silin. Pasif ama eski eklentiler de dosya sistemi üzerinde risk oluşturabilir.
• Dosya izinlerini kontrol edin. Gereksiz yazma izinleri, zararlı dosya yükleme riskini artırır.
• Düzenli yedek alın ve geri yükleme testi yapın. Yedek, test edilmediği sürece varsayımdır.
• Güvenilir hosting altyapısı kullanın. İzolasyon, güncel PHP, WAF ve yedekleme desteği saldırı etkisini azaltır.

Örneğin yalnızca XML-RPC’yi kapatıp yönetici şifresini 123456 gibi zayıf bırakırsanız güvenlik zincirinin en zayıf halkası hâlâ açıktır. Tersine güçlü şifre, 2FA, güncel yazılım, WAF ve güvenli hosting birlikte kullanıldığında sıradan bot saldırılarının önemli bölümü etkisiz hale gelir. Bu yaklaşım, 2026 SEO tarafında da önemlidir; çünkü güvenliği zayıf siteler zararlı yönlendirme, spam sayfa üretimi ve indeks kirliliği yaşayarak organik görünürlüğünü kaybedebilir.

Performans ve SEO Açısından XML-RPC Kapatmanın Etkisi

XML-RPC saldırıları doğrudan sıralama faktörü değildir; ancak dolaylı etkileri güçlüdür. Yoğun bot trafiği sunucu kaynaklarını tüketirse sayfa yanıt süreleri artar, Core Web Vitals değerleri bozulabilir ve gerçek kullanıcı deneyimi düşebilir. Ayrıca sık sık kaynak limitine takılan sitelerde 500 hataları, zaman aşımı problemleri ve kesintiler görülebilir. Googlebot da yavaş veya hata veren sayfaları daha temkinli tarayabilir.

Bir örnek üzerinden düşünelim: Normalde ana sayfanız 300 ms sunucu yanıt süresiyle açılıyor; ancak xmlrpc.php’ye dakikada 1000 istek geldiğinde PHP worker’lar doluyor ve yanıt süresi 2 saniyeyi geçiyor. Kullanıcı tarafında sayfa yavaşlar, dönüşüm oranı düşer, Google Search Console’da tarama istatistikleri dalgalanabilir. XML-RPC’yi sunucu seviyesinde kapatmak, bu gereksiz yükü uygulama katmanına gelmeden keserek performans istikrarına katkı sağlar.

SEO bakımından güvenli ve hızlı bir site, içerik kalitesi kadar teknik altyapıya da dayanır. HTTPS, güncel PHP, hızlı disk, doğru önbellekleme, temiz tema yapısı ve saldırı yüzeyinin azaltılması birlikte değerlendirilmelidir. Bu nedenle WordPress güvenlik ayarları, yalnızca sistem yöneticilerinin değil SEO ve içerik ekiplerinin de gündeminde olmalıdır. Hostragons blog içinde bu konu WordPress hız optimizasyonu ve teknik SEO kontrol listesi içerikleriyle desteklenebilir.

XML-RPC’yi Tam Kapatamıyorsanız Alternatif Stratejiler

Bazı projelerde XML-RPC tamamen kapatılamaz. Örneğin belirli bir mobil yayın akışı, kurumsal otomasyon veya eski entegrasyon hâlâ bu protokole bağlı olabilir. Bu durumda hedef, tüm kapıyı açık bırakmak değil, erişimi kontrollü hale getirmektir. İlk seçenek IP beyaz listelemedir. XML-RPC’ye yalnızca güvenilen servislerin IP adreslerinden erişim verilir, diğer tüm istekler engellenir.

İkinci seçenek rate limit uygulamaktır. Belirli bir IP’nin kısa sürede çok fazla xmlrpc.php isteği göndermesi engellenir. Bu yöntem tam kapatma kadar kesin değildir; ancak iş ihtiyacı olan sitelerde saldırı hacmini düşürür. Üçüncü seçenek pingback metodlarını devre dışı bırakıp yalnızca gerekli metodlara izin vermektir. Bu daha gelişmiş bir yapılandırma gerektirir ve geliştirici kontrolünde uygulanmalıdır.

Dördüncü seçenek, XML-RPC erişimini ayrı bir güvenlik katmanına bağlamaktır. Örneğin HTTP basic auth, VPN, kurumsal IP kısıtı veya WAF challenge ile ek doğrulama istenebilir. Bu yaklaşımlar, halka açık uç nokta riskini azaltır. Yine de mümkünse uzun vadeli çözüm, eski entegrasyonları REST API gibi daha modern ve kontrol edilebilir yöntemlere taşımaktır.

Hostragons Kullanıcıları İçin Pratik Yol Haritası

Hostragons üzerinde WordPress barındıran bir site sahibiyseniz XML-RPC güvenliği için önce ihtiyaç analizini yapın, ardından en az karmaşık yöntemi seçin. Paylaşımlı hosting veya WordPress hosting paketlerinde dosya yöneticisi üzerinden .htaccess düzenlemek çoğu kullanıcı için yeterli olabilir. VPS veya özel sunucu kullanıyorsanız Nginx, Apache, LiteSpeed ve WAF katmanlarını birlikte planlayabilirsiniz.

Uygulama sırası şöyle olabilir: Önce yedek alın, sonra XML-RPC kullanan servisleri kontrol edin, ardından sunucu seviyesinde engelleme yapın, testleri tamamlayın ve logları 24 saat izleyin. Eğer saldırı denemeleri devam ediyorsa WAF kuralı, IP engelleme ve giriş denemesi limiti ekleyin. En son aşamada 2FA, güncelleme politikası, düzenli yedek ve SSL gibi genel güvenlik ayarlarını tamamlayın.

Bu işlem satış odaklı bir yükseltme değil, temel hijyen adımıdır. Yine de altyapınız eski PHP sürümleri, yetersiz kaynaklar veya güvenlik duvarı eksikliği nedeniyle sürekli sorun çıkarıyorsa daha güncel bir hosting planı değerlendirmek mantıklı olabilir. WordPress için optimize edilmiş, güvenlik katmanları bulunan bir ortam hem saldırı anında dayanıklılık sağlar hem de günlük performansı iyileştirir. Bu bağlamda WordPress hosting, bulut sunucu ve SSL sertifikası sayfaları okuyucuya doğal yönlendirme sunar.

Sıkça Sorulan Sorular

WordPress XML-RPC kapatma sitemi bozar mı?

Çoğu standart WordPress sitesinde XML-RPC kapatma siteyi bozmaz. Yönetim paneli, tema, içerik, formlar ve ziyaretçi tarafı genellikle etkilenmez. Ancak Jetpack, WordPress mobil uygulaması veya XML-RPC kullanan özel entegrasyonlar varsa bağlantı sorunları yaşanabilir. Bu yüzden kapatmadan önce kullanım ihtiyacını kontrol etmek ve sonrasında temel işlevleri test etmek gerekir.

XML-RPC kapalı mı nasıl anlarım?

Tarayıcıdan alanadiniz.com/xmlrpc.php adresini açın. XML-RPC server accepts POST requests benzeri bir mesaj görüyorsanız dosya erişilebilir durumdadır. 403, 404 veya erişim reddi alıyorsanız kapatma kuralı büyük olasılıkla çalışıyordur. Daha kesin kontrol için sunucu erişim loglarında xmlrpc.php isteklerinin hangi durum koduyla döndüğünü inceleyebilirsiniz.

XML-RPC kapatmak brute force saldırılarını tamamen durdurur mu?

XML-RPC kaynaklı brute force denemelerini büyük ölçüde durdurur; fakat tüm brute force riskini bitirmez. Saldırganlar wp-login.php üzerinden deneme yapmaya devam edebilir. Bu nedenle XML-RPC kapatma yanında güçlü şifre, iki faktörlü kimlik doğrulama, giriş denemesi limiti, WAF ve güncel eklenti politikası birlikte uygulanmalıdır.

Jetpack kullanıyorsam XML-RPC’yi kapatmalı mıyım?

Jetpack’in bazı özellikleri XML-RPC bağlantısına ihtiyaç duyabilir. Jetpack kullanıyorsanız XML-RPC’yi tamamen kapatmadan önce hangi modülleri kullandığınızı kontrol edin. Alternatif olarak yalnızca Jetpack servislerinin IP adreslerine izin vermek, diğer tüm xmlrpc.php isteklerini engellemek veya WAF üzerinde kontrollü erişim tanımlamak daha uygun olabilir.

Eklenti ile kapatmak mı, sunucudan kapatmak mı daha iyi?

En iyi performans ve güvenlik için sunucu veya WAF seviyesinde kapatma daha etkilidir; çünkü istek WordPress ve PHP çalışmadan reddedilir. Eklenti ile kapatma teknik bilgisi az olan kullanıcılar için kolaydır, ancak yoğun saldırılarda kaynak tüketimini tamamen önlemeyebilir. Mümkünse sunucu kuralı, değilse güvenilir bir eklenti ve WAF desteği tercih edilmelidir.

Kısa Özet ve Sonraki Adım

WordPress XML-RPC kapatma, XML-RPC’ye ihtiyaç duymayan sitelerde brute force, pingback istismarı ve gereksiz bot trafiğini azaltmanın en hızlı yollarından biridir. En sağlam yaklaşım, xmlrpc.php erişimini sunucu veya WAF katmanında engellemek, ardından giriş güvenliği, 2FA, güncellemeler, SSL ve düzenli yedeklerle katmanlı koruma oluşturmaktır. Sitenizin altyapısını gözden geçirmek isterseniz Hostragons’un WordPress odaklı hosting ve güvenlik çözümlerini inceleyebilir; mevcut siteniz için küçük bir kontrol listesiyle bugün ilk adımı atabilirsiniz.