WordPress brute force koruması: bir eklenti nelere engel olur

Bir güvenlik eklentisi parola denemelerini yavaşlatmakta iyidir. Trafik seline karşı ise yapabileceği bir şey yoktur. WordPress brute force koruması ile DDoS koruması farklı sorunlardır ve her biri ayrı bir katmanda çözülür: hesaplarınızda, WordPress'in kendisinde, web sunucusunda ve önünüzdeki ağ kenarında (edge).

Bu yazı, günlüklerinizde karşılaşma ihtimaliniz yüksek olan saldırıları tek tek ele alıyor: wp-login.php üzerindeki başarısız girişler, xmlrpc.php'ye gelen istek yağmuru, REST API üzerinden kullanıcı sıralama (user enumeration) ve trafik patlamaları. Her biri için onu gerçekten durdurabilecek katmanı belirtiyoruz. Her önlemin neyi yapmadığı de bir cümleyle not edilmiştir.

WordPress brute force koruması katmanlarla çalışır

Trafik internetten gelir ve verilerinize ulaşmadan önce birkaç katmandan geçer. Bir istek ne kadar dışarıda durdurulursa size maliyeti o kadar düşer. CDN'de reddedilen bir istek sunucunuza hiç dokunmaz. Bir WordPress eklentisinin reddettiği istek ise bir ağ bağlantısını, bir web sunucusu sürecini ve bir PHP işçisini (worker) çoktan kullanmıştır.

Kabaca bir eşleştirme:

Giriş kısıtlama: wp-login.php üzerindeki parola denemelerini yavaşlatmak

Giriş kısıtlama (login throttling) başarısız denemeleri sayar ve buna artan gecikmeler eklemek, kaynağı geçici olarak engellemek ya da bir doğrulama sınavı (challenge) istemek gibi yanıtlar verir. WordPress varsayılan olarak hiçbir sınır uygulamaz. Bir saldırgan wp-login.php'ye sunucunuz yanıt verebildiği kadar hızlı parola deneyebilir.

IP başına sınırlar, tek bir gürültülü kaynağa karşı iyi çalışır. Tahminlerini binlerce adrese yayan ve her biri sınırın altında kalan bir botnet'e karşı ise o kadar etkili değildir. Bu yüzden kullanıcı adı başına sınırlar da gerekir. "admin" hesabına yirmi farklı IP'den gelen yirmi başarısız deneme yine de bir örüntüdür.

Kullanıcı adı başına sınırların kendine özgü bir tuzağı var. Sert bir kilitleme, birinin kasten başarısız giriş yaparak gerçek yöneticinizi dışarıda bırakmasına izin verir. Artan gecikmeler ya da bir doğrulama sınavı, tam engellemeden daha ılımlı bir çözümdür.

Kısıtlamanın işe yarayıp yaramayacağını iki şey belirler:

• İstemci IP'si. Bir CDN ya da ters vekil (reverse proxy) arkasında her istek vekilin adresinden geliyormuş gibi görünebilir. Yalnızca bu adresi gören bir eklenti tüm ziyaretçilerinizi bir anda kısıtlar. Tersi de en az o kadar kötüdür: eklenti X-Forwarded-For başlığına herkesten gelse de güvenirse, saldırganlar her istekte sahte bir IP üretebilir ve hiç engellenmez. Eklentiyi ya da web sunucusunun real-IP modülünü, iletilen başlıkları yalnızca vekilinizin IP aralıklarından kabul edecek şekilde yapılandırın.
• Kendi geri dönüş yolunuz. Sabit bir IP kullanıyorsanız ofis IP'nizi izin listesine ekleyin ve ihtiyaç duymadan önce kurtarma yolunuzu bilin.

Kısıtlamanın yapmadığı şey: zayıf ya da başka yerlerde de kullanılan bir parolayı güvenli hale getirmez. Sızıntı listelerinde yer alan bir parola ilk denemede işe yarayabilir. Asıl çözüm, yükseltilmiş yetkisi olan her hesap için ikinci bir faktördür; kurulumu WordPress yöneticileri için iki faktörlü kimlik doğrulama yazısında anlatılıyor.

XML-RPC: system.multicall neden tek isteği çok sayıda tahmine çevirir

xmlrpc.php, WordPress'te varsayılan olarak açıktır. Eski bir uzaktan yayın arayüzüdür ve yöntemlerinden biri olan system.multicall, tek bir HTTP isteği içinde çok sayıda yöntem çağrısı çalıştırır. Bir saldırgan uzun bir kullanıcı adı/parola deneme listesini tek bir POST'a sığdırabilir.

Bu, yalnızca wp-login.php'yi izleyen veya istek sayan giriş korumalarını atlatır. Günlüğünüzdeki tek bir istek yüzlerce tahmin anlamına gelebilir. Kısıtlamanızın XML-RPC kimlik doğrulama hatalarını da saydığından emin olun ya da saldırı yüzeyini tümüyle kaldırın.

XML-RPC pingback'leri de sitenizin üçüncü taraflara istek göndermesi için kötüye kullanılabilir. Hiçbir şey onlara ihtiyaç duymuyorsa kapatmak için bir neden daha.

XML-RPC'yi kapatmadan önce: hâlâ neyin kullandığını kontrol edin

Bazı meşru araçlar hâlâ xmlrpc.php ile konuşur. Eski masaüstü blog yazma ve uzaktan yayın araçları, eski mobil uygulama kurulumları, bazı bağlayıcı eklentiler ve yıllar önce yazılmış entegrasyonlar bunların arasındadır. Jetpack'in bağlantısı tarihsel olarak XML-RPC'ye dayandı; kullanıyorsanız güncel dokümantasyonuna bakın.

Önce erişim günlüklerinize bakın. Combined günlük biçimini kullanan tipik bir Apache veya nginx sunucusunda:

# Which IPs send POST requests to xmlrpc.php?
grep "POST /xmlrpc.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Which user agents?
awk -F'"' '/POST \/xmlrpc.php/ {print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Yolu kendi sunucunuza göre değiştirin (örneğin /var/log/apache2/access.log) ve döndürülmüş (rotated) günlükleri de dahil edin. Sürekli değişen IP'lerden ve genel user agent'lardan gelen binlerce istek saldırıdır. Tek bir bilinen servis IP'sinden gelen bir avuç istek büyük olasılıkla bir entegrasyona aittir; kesmeden önce ajansınıza ya da yazılımın satıcısına sorun.

İki seçeneğiniz var:

1. **xmlrpc_enabled filtresi.** Kimlik doğrulama gerektiren XML-RPC yöntemlerini devre dışı bırakır ve böylece XML-RPC üzerinden parola tahminini durdurur. Pingback gibi kimlik doğrulamasız yöntemler çalışmaya devam eder. Bkz. WordPress geliştirici referansı.
2. Dosyayı sunucu düzeyinde engellemek. Her şeyi durdurur ve bu istekler için PHP hiç çalışmaz.

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

location = /xmlrpc.php {
    deny all;
}

Değişiklikten sonra yayın yapmayı, uygulamanızı ve bağlı tüm servisleri test edin. Neyi neden değiştirdiğinizi not edin ki bir sonraki kişi onu geri "düzeltmesin".

REST API ile kullanıcı sıralama ve anonim istekleri sınırlama

/wp-json/wp/v2/users, içerik yayımlamış kullanıcıları slug'larıyla birlikte listeler. /?author=1 ise slug'ı URL'de gösteren bir yazar arşivine yönlendirir. Slug'lar çoğu zaman giriş adıyla aynıdır; bu da saldırgana kimlik bilgilerinin yarısını vermek demektir.

Kullanıcılar uç noktasını anonim ziyaretçilere kısıtlamak ve yazar taramalarını engellemek, keşif gürültüsünü azaltır. Yine de kullanıcı adları sır değildir. Onları gizlemek tek başına bir kontrol sayılmaz.

Anonim REST isteklerini sınırlamak, scraping ve otomatik yoklamalara karşı yardımcı olur. Yalnızca anonim trafiğe uygulayın ve sonrasında test edin. Blok editörü, oturum açmış kullanıcılar için REST API'yi kullanır; entegrasyonlar ise Uygulama Parolaları (Application Passwords) ile kimlik doğrular (WordPress 5.6'dan beri çekirdekte). Bunlara takılan bir sınır, izini sürmesi zor biçimlerde düzenlemeyi ya da bir senkronizasyon işini bozar.

Yapmadığı şey: hız sınırlaması, bir eklentideki savunmasız REST uç noktasını düzeltmez. Yalnızca onu kullanma girişimlerini yavaşlatır.

Bir eklenti DDoS saldırısını neden durduramaz

Bir eklenti PHP kodudur. Ancak bir istek ağı geçtikten, web sunucusu tarafından kabul edildikten ve bir PHP işçisine devredildikten sonra çalışır. Hacimsel bir sel, bant genişliğinizi, bağlantı sınırlarınızı ya da PHP işçi havuzunuzu bu noktaya varmadan çok önce doldurur. Eklenti her isteği bir milisaniyede reddetse bile her ret bir işçiyi meşgul eder ve bir sunucunun yalnızca belli sayıda işçisi vardır.

Uygulama katmanı selleri farklıdır. Bunlar, arama sorguları ya da önbelleğe alınmamış sayfalar gibi pahalı ama geçerli görünen çok sayıda istektir. Burada uygulamaya daha yakın hız sınırlaması bir ölçüde yardımcı olur, ama yalnızca sunucunun kapasitesine kadar.

Bir eklentinin trafik artışı uyarısı, bir şeylerin olduğunu söylediği için işe yarar. Hiçbir şeyi emmez. Bir WordPress eklentisine "DDoS koruması" diyen her ürün, olduğundan fazlasını vaat ediyor demektir.

CDN veya uç güvenlik duvarı bunun yerine ne yapar ve web sunucusu neler ekleyebilir

CDN ya da uç güvenlik duvarı, hosting'inizin önünde, sizinkinden çok daha büyük bir ağda durur. Selleri emip filtreleyebilir, trafik size ulaşmadan hız sınırları ve bot kuralları uygulayabilir, sunucunuz zorlandığında önbellekteki sayfaları sunabilir ve wp-login.php ile xmlrpc.php isteklerine doğrulama sınavı uygulayabilir. Devreye girdikten sonra kaynağı kilitleyin: sunucu güvenlik duvarınızda yalnızca CDN'in IP aralıklarına izin verin. Aksi halde saldırganlar CDN'i atlayıp doğrudan sunucunuzun gerçek adresine gidebilir.

Web sunucusu tarafında, nginx'in [limit_req modülü](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html) PHP başlamadan önce giriş denemelerini sınırlayabilir. CDN ya da ters vekil arkasındayken önce real-IP modülünü yapılandırın (yalnızca vekilinizin aralıklarına güvenerek); aksi halde $binary_remote_addr vekilin adresi olur ve tüm ziyaretçiler tek bir sınırı paylaşır:

# http context
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=5r/m;

# server context
location = /wp-login.php {
    limit_req zone=wplogin burst=5 nodelay;
    # keep your existing fastcgi_pass / include lines here
}

fail2ban farklı bir yol izler. Günlüklerinizi okur ve tekrar eden saldırganları güvenlik duvarı düzeyinde yasaklar; bu, onlara PHP'de yanıt vermekten daha ucuzdur. Bir CDN arkasında bu olduğu gibi çalışmaz: sunucu güvenlik duvarı yalnızca CDN'in adreslerini görür, dolayısıyla yasaklamaların CDN'de (ya da API'si üzerinden) yapılması gerekir. Yönetilen hosting kullanıyorsanız sağlayıcınızın zaten hangi ağ korumasını sunduğunu sorun.

Buradaki sınırlar da geçerli. Uç güvenlik duvarı zayıf parolaları ya da savunmasız eklentileri düzeltmez. Bir saldırganın giriş yaptıktan sonra neler yapabileceğine de çare olmaz; bu konu WordPress dosya düzenleyicisini devre dışı bırakma yazısının işi.

Küçük AB işletmeleri için kurulum sırası

1. Her yönetici ve editör için güçlü, benzersiz parolalar ve 2FA.
2. IP başına ve kullanıcı adı başına sınırlarla giriş kısıtlama, doğru istemci IP tespiti ve test edilmiş bir kurtarma yolu.
3. XML-RPC kararı: önce günlüklere bakın, sonra filtreyi ya da sunucu düzeyinde engellemeyi kullanın.
4. Kullanıcı sıralamaya kısıtlamalar ve anonim REST isteklerine sınırlar.
5. Kesinti maliyetli olan siteler için kaynağı kilitlenmiş bir CDN veya uç güvenlik duvarı.

Bunun uyumluluk boyutu da var. GDPR (AB Genel Veri Koruma Tüzüğü) Madde 32(1)(b), sistemlerin gizliliğinin, bütünlüğünün, erişilebilirliğinin ve dayanıklılığının sürekli sağlanmasını şart koşar (EUR-Lex'te GDPR). NIS2 Direktifi kapsamındaki kuruluşlar için Madde 21(2)(j), çok faktörlü kimlik doğrulamayı asgari önlemler arasında sayar (EUR-Lex'te NIS2). Ayrıntılar için ülkenizin ulusal NIS2 mevzuatına bakın.

secaudit.eu'nun Security Audit & Compliance eklentisi giriş kısıtlama, XML-RPC'yi devre dışı bırakma, anonim REST istekleri için hız sınırlaması ve trafik artışı uyarıları sunar. DDoS koruması değildir; bunun için CDN ya da uç güvenlik duvarı kullanın. → secaudit.eu

Sıradaki adım: WordPress güvenlik kontrol listesinin geri kalanını tamamlayın. Günlüklerinizde tanımadığınız başarılı girişler zaten görünüyorsa bunun yerine hacklenmiş sitenin belirtileri yazısına geçin.

SSS

XML-RPC'yi kapatmak Jetpack'i ya da uygulamamı bozar mı?

Bozabilir. Günlüklerinizde meşru XML-RPC istemcileri olup olmadığına bakın ve satıcının güncel dokümantasyonunu kontrol edin. xmlrpc_enabled filtresi daha yumuşak seçenektir, sunucu düzeyinde engelleme ise daha katı olanı. Hangisini seçerseniz seçin sonrasında test edin.

wp-login.php'nin adını değiştirmek brute force'u durdurur mu?

Basit botlardan gelen gürültüyü azaltır, ama bir güvenlik kontrolü değildir. Saldırganlar giriş sayfasını yine bulabilir ya da XML-RPC'yi kullanabilir. Kısıtlamayı ve 2FA'yı da kullanın.

DDoS sırasında güvenlik eklentim yeterli mi?

Hayır. Hosting sağlayıcınızla ya da CDN sağlayıcınızla iletişime geçin. Siteyi erişilebilir tutan şey, uçta filtreleme ve önbelleklemedir.

Kısıtlama beni dışarıda bırakır mı?

İstemci IP'si yanlış tespit edilirse ya da parolanızı art arda yanlış girerseniz bırakabilir. IP'nizi izin listesine ekleyin ve eklentiyi devre dışı bırakmak için WP-CLI veya SFTP erişimini hazır tutun.

Dieser Artikel ist eine allgemeine Information und keine Rechtsberatung.