WordPress’te xmlrpc.php Saldırılarından Korunma: Net Rehber

WordPress’te xmlrpc.php dosyası, uzaktan yayınlama (XML-RPC) gibi meşru senaryolarda kullanılsa da saldırganların hedeflediği bir giriş noktası haline gelebilir. Son yıllarda brute force (şifre denemesi), yavaşlatma (latency) ve çeşitli kötüye kullanım denemeleri xmlrpc trafiği üzerinden yürütülüyor. Bu rehberde, loglardan başlayarak riskin nereden geldiğini netleştirecek; ardından kapatma, kısıtlama ve hız/erişim kontrollerini adım adım uygulayacaksınız. Hedefimiz “güvenlik önemli” demek değil; uygulamaya geçirilebilir bir koruma planı oluşturmaktır.

xmlrpc.php neden hedef olur? (Saldırı türleri ve net etkiler)

WordPress’in XML-RPC arayüzü, uygulamalardan gönderi yayınlamaya ve eski istemcilerle iletişime hizmet eder. Ancak saldırganlar, bu endpoint üzerinden genellikle şu denemeleri yapar:

• Brute force: Aynı kullanıcı adları üzerinden şifre denemesi. Sunucu CPU’su ve WordPress PHP süreci sürekli tetiklenir.
• Pingback / trackback ile istismar: Wordpress’in bazı yapılandırmalarında istekler gereksiz çalıştırmalara yol açabilir.
• DDoS öncülleri ve l7 zorlaması: Tek bir endpoint’e yoğun istek gelmesi, özellikle paylaşımlı altyapıda kaynak tüketimini artırır.
• Boşluk taraması ve zafiyet denemeleri: Her saldırı doğrudan exploit değildir; “tavşan deliği” bulma amacıyla deneme yapılır.

Net etki genellikle şunlarda görülür: - Web sunucusunda (Nginx/Apache) 4xx/5xx artışı - PHP-FPM proses sayısında yükselme - WordPress tarafında admin-ajax / login ile eş zamanlı yavaşlama - Sunucu erişim loglarında xmlrpc.php’ye odaklı tekrarlı istekler

Hangi kurum/kurulumlar daha çok risk altındadır?

• Şifreyi zayıf olan kullanıcılar veya admin kullanıcı adı bilinen siteler
• XML-RPC’i gerçekten kullanmayan (çoğu kişide durum budur)
• Paylaşımlı hosting (shared) üzerinde aynı IP’yi kullanan çok sayıda site varsa, tarama trafiği daha görünür hale gelir
• WAF/CDN olmayan veya yetersiz kurallarla korunan ortamlar

Önce tespit: xmlrpc saldırısı gerçekten var mı? (Log kontrol planı)

Koruma yöntemine geçmeden önce, sorunun xmlrpc’den gelip gelmediğini netleştirin. Aşağıdaki kontrol adımları, “tahmin yürütmek” yerine kanıt toplamayı sağlar.

1) Web sunucusu erişim loglarında desen arayın

• GET /xmlrpc.php
• POST /xmlrpc.php
• Kısa aralıklarla aynı IP’den tekrarlı istek
• 404/403 değil de özellikle 200/401/405 karışımı

Bu noktada hedef, saldırı olduğunu “hissetmek” değil, şu sorulara cevap bulmaktır: - Kaç farklı IP deniyor? - Günde/saatte kaç istek var? - İsteklerin çoğu POST mu GET mi?

2) WordPress activity/servis logları

WordPress çekirdeğinde ve eklenti tarafında detaylar her planda aynı olmayabilir. Yine de şu kontroller faydalıdır: - Login denemeleriyle aynı zamanlarda xmlrpc trafiği artıyor mu? - Güvenlik eklentilerinde (fail2ban türevleri veya WAF raporları) xmlrpc’den gelen brute force kayıtları var mı?

3) Kaynak etkisini ölçün

Saldırı sadece “log” değil, performans sorunu da yaratır. Şunları kontrol edin: - CPU kullanımı ve load average - PHP-FPM aktif process sayısı - Nginx/Apache worker sayısı - Ortalama response süresi

Eğer kaynak artışı, xmlrpc yoğunluğuyla aynı zaman aralığında görülüyorsa, öncelik xmlrpc erişimini kontrol etmektir.

Koruma stratejisi: xmlrpc’i kapat, gerekiyorsa kısıtla

XML-RPC’i kullanan az sayıda senaryo vardır. Bu nedenle en net ve en etkili yaklaşım, ihtiyacınız yoksa xmlrpc’i kapatmaktır. İhtiyacınız varsa ikinci seçenek: endpoint’i kısıtlamaktır.

Karar tablosu: “Kapat mı kısıtla mı?”

Aşağıdaki tablo, uygulama seçimini netleştirir.

Kapsam: Sadece WordPress eklentisine güvenmeyin

Ek güvenlik eklentileri faydalıdır; ancak xmlrpc endpoint’i doğrudan web sunucusu katmanında veya WAF/CDN seviyesinde sınırlamak genellikle daha net ve daha hızlı sonuç verir.

Uygulama 1: xmlrpc.php’yi devre dışı bırakma (en net adım)

XML-RPC’i kullanmıyorsanız, en basit güvenlik kazanımı endpoint’i kapatmaktır. Aşağıdaki yöntemlerin her biri tek başına çalışabilir; ancak WordPress sürümünüz ve altyapınız kısıtlayıcı olabilir.

Yöntem A: Sunucu seviyesinde erişimi engelleme

Nginx veya Apache kullanmanıza göre kural yazarsınız. Bu yaklaşımın avantajı, istek WordPress’e hiç ulaşmadan kesilir.

Nginx örneği (hedef: /xmlrpc.php)

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

Apache örneği (hedef: /xmlrpc.php)

<Files "xmlrpc.php">
    Require all denied
</Files>

Not: Bu blokları uyguladıktan sonra, gerçekten xmlrpc’e ihtiyaç olmadığından emin olun. Bazı entegrasyonlar bu endpoint’i kullanabilir.

Yöntem B: WordPress düzeyiyle fonksiyonel kapatma

WordPress’te eklentiler veya küçük kod değişiklikleriyle XML-RPC fonksiyonalitesi devre dışı bırakılabilir. Bu yöntem, server katmanı kadar “hemen kesme” sağlamayabilir; yine de saldırı trafiğini WordPress işleminden uzaklaştırır.

Hangi sonucu beklemelisiniz?

• xmlrpc’e gelen isteklerin çoğu 403/404 döner
• PHP-FPM proseslerinde anlık azalma gözlersiniz
• Güvenlik raporlarında saldırı şiddeti düşer

Uygulama 2: xmlrpc’e ihtiyaç varsa kısıtlama (IP allowlist + rate limit)

XML-RPC’i belirli istemcilerle kullanıyorsanız “tam kapat” yerine “kontrollü erişim” uygulayın.

1) IP allowlist (izinli IP listesi)

Kullanılan istemcilerin (ör. kurumsal cihazlar, ofis IP aralığı, VPN egress IP) sabit IP’sini belirleyin. Sonra sadece bu kaynaklara izin verin.

• İzinli IP aralığı yoksa “kısıtla” hedefini tutturmak zorlaşır.
• Dinamik mobil IP’ler kullanıyorsanız allowlist yerine WAF ile rate limit daha mantıklı olur.

2) Rate limit (istek hız sınırı)

Rate limit, brute force’un ilerlemesini engeller. Nginx’te limit_req veya CDN/WAF tarafında kural uygulanır.

Net hedef örnekleri: - Basit senaryoda dakikada birkaç deneme (ör. 10-20) gibi bir limit - Daha agresif senaryoda 1-5 deneme/dk

Buradaki sayı, normal trafiğinizle çelişmemelidir. Bu yüzden önce tespit aşamasında gördüğünüz istek hacmine göre ayarlayın.

3) 2 aşamalı doğrulama (brute force’a karşı)

XML-RPC kapalı olsa bile WordPress login sayfaları hedef olur. Bu nedenle: - Yönetici hesaplarda 2FA (iki faktörlü kimlik doğrulama) etkinleştirin - Zayıf şifreyi değiştirin - Kullanıcı adı tahmini mümkün olan admin kurulumlarını güncelleyin

Bu adım xmlrpc’den bağımsız bir kazanımdır; fakat pratikte saldırganlar farklı giriş yüzeyleri arasında gezinir.

Uygulama 3: WAF/CDN ile katmanlı koruma (origin’i yormayın)

Özellikle VDS/VPS üzerinde, yoğun tarama geldiğinde WordPress PHP süreci yorulabilir. CDN/WAF, saldırıyı daha erken keser.

Net bir katman planı

• CDN/WAF: Rate limit + bot rule + “XML-RPC endpoint” kuralı
• Web sunucusu (Nginx/Apache): /xmlrpc.php için deny/403 veya kısıt
• WordPress: XML-RPC devre dışı veya ek güvenlik ayarları

Bu üç katman, saldırı başarısını düşürürken sistem performansını korur.

Başarı kriteri (ölçülebilir)

• xmlrpc endpoint’inde istek sayısı belirgin düşmeli
• Uygulama gecikmesi (response time) normal seviyeye dönmeli
• Sunucu CPU ve PHP-FPM process sayısı saldırı saatlerinde stabilleşmeli

Güvenlik eklentileri ve fail2ban: “ek önlem” olarak doğru konum

Güvenlik eklentileri (WAF/anti-bruteforce modülleri) ek koruma sağlar. Ancak xmlrpc’nin kapatılması/kısıtlanması yerine eklentiye tamamen güvenmek doğru değildir.

Net yaklaşım: - Eklentiyi “ikinci savunma hattı” yapın. - Sunucu/WAF tarafındaki kuralı birincil savunma kabul edin. - Fail2ban gibi mekanizmalar varsa, xmlrpc loglarını takip edip otomatik engelleme yaptırın.

Fail2ban için net hedef

• Aynı IP’den kısa aralıklarla xmlrpc istekleri
• Başarısız login / XML-RPC hata desenleri

Eklenti düzeyi engellerin, log kalıbına bağlı çalıştığını unutmayın; bu yüzden doğru log kaynağı ve filtre şarttır.

Performans ve barındırma perspektifi: Neden VDS/VPS planı fark yaratır?

xmlrpc saldırısı yalnızca “güvenlik” değildir; kaynak tüketir. Paylaşımlı hosting’de aynı sunucuda çok site olduğundan, saldırı anında başka sitelerin de etkilenme ihtimali artar. VDS/VPS gibi daha izole kaynaklarda ise: - CPU/RAM kontrolü daha net olur - WAF kuralları ve rate limit gibi ayarlar daha tutarlı uygulanır - Erişim logları ve metrikler daha rahat incelenir

Bu nedenle, WordPress’inize düzenli saldırı denemeleri geliyorsa altyapı izolasyonunu da (VDS/VPS) güvenlik planına dahil edin.

Son kontrol listesi: 10 dakikada net kapanış

Aşağıdaki kontrol listesi, uygulamadan sonra “tamamlandı mı?” sorusunu hızlı yanıtlar:

1. xmlrpc.php gerçekten 403/404 dönüyor mu? (Tarayıcı ve curl ile kontrol)
2. Loglarda xmlrpc istekleri azaldı mı?
3. CPU ve PHP-FPM process sayıları saldırı saatinde normale dönüyor mu?
4. XML-RPC’e ihtiyaç varsa allowlist ve rate limit doğru çalışıyor mu?
5. Yönetici hesaplarda 2FA aktif mi ve güçlü şifre politikası var mı?
6. WAF/CDN kullanıyorsanız XML-RPC endpoint için kural aktif mi?

Sonuç: Net bir aksiyon planı uygulayın

xmlrpc.php saldırılarına karşı en net kazanım, XML-RPC’i gerçekten kullanmıyorsanız endpoint’i kapatmak; kullanıyorsanız allowlist ve rate limit ile kontrol altına almaktır. Ardından WAF/CDN + sunucu kuralı + WordPress düzeyi katmanlı yaklaşımı kurun ve log/performans metrikleriyle doğrulayın. Bugün önce loglardan xmlrpc etkisini ölçün, sonra “kapat ya da kısıtla” kararını netleştirip 1-2 saat içinde kalıcı koruma sağlayın.