WordPress WAF Nedir? Kurulum ve Yapılandırma Rehberi 2026

WordPress WAF nedir? WAF, HTTP isteklerini inceleyerek belirli saldırı kalıplarını engelleyen bir güvenlik katmanıdır. Bulut WAF isteği origin sunucuya ulaşmadan süzebilir; eklenti tabanlı WAF ise genellikle sunucuda ve PHP seviyesinde çalışır. Koruma yeri, kural kapsamı ve istek gövdesi sınırları ürüne göre değişir.

WAF, güncellemeler ve erişim güvenliğiyle birlikte değerlendirilen bir savunma katmanıdır. Kodlama araçlarının eklenti tedarik zincirini etkileyen Plugin4Shell, WordPress HTTP trafiğini filtreleyen bir WAF’ın doğrudan çözebileceği bir açık değildir. Sanal yama yalnızca WAF’ın uygun bir kuralı bulunduğunda ilgili saldırı yolunu azaltır.

WordPress WAF Nedir, Nasıl Çalışır?

Bir WAF, gelen her isteği önceden tanımlı kural setleriyle karşılaştırır: “bu istekte bir SQL sorgusu parçası var mı”, “bu form alanına script etiketi enjekte edilmeye mi çalışılıyor”, “bu istek bilinen bir zafiyetin exploit imzasına mı benziyor” gibi sorulara gerçek zamanlı yanıt üretir. Şüpheli görülen istekler; engellenir, meydan okuma (challenge/CAPTCHA) ile karşılanır veya sadece loglanır.

Uygulama Seviyesi vs Ağ Seviyesi Filtreleme

Bir ağ güvenlik duvarı (network firewall), “bu IP’den gelen trafiğe 443 portunda izin ver” gibi kararlar alır; isteğin içeriğiyle ilgilenmez. WAF ise tam tersine, bağlantıya izin verildikten sonra isteğin içeriğini didik didik inceler. Bu nedenle iki katman birbirinin yerine geçmez; birlikte kullanıldığında daha güçlü bir savunma hattı oluşturur.

WAF Türleri: Bulut, Eklenti ve Sunucu Seviyesi Karşılaştırması

Paylaşımlı hostinglerde genellikle sunucu seviyesi WAF’a doğrudan erişiminiz olmaz; bu durumda bulut tabanlı veya eklenti tabanlı seçenekler daha pratik bir başlangıç noktası olur. Yönetilen (managed) WordPress hostingi kullanıyorsanız, sağlayıcının zaten bir ModSecurity veya benzeri katman sunup sunmadığını kontrol etmek, gereksiz katman eklemenizi önler; aynı işlevi gören iki WAF’ı üst üste çalıştırmak, ek fayda sağlamadan sadece gecikmeyi artırabilir ve hata ayıklamayı zorlaştırabilir.

Üç yaklaşımı da birbirinin rakibi değil, farklı senaryolara uygun araçlar olarak görmek daha doğru. Örneğin bir ajans, düşük bütçeli müşteri siteleri için bulut tabanlı ücretsiz katmanı tercih ederken, yüksek trafikli bir e-ticaret müşterisi için hem bulut tabanlı WAF hem de sunucu seviyesinde ek bir ModSecurity katmanını birlikte çalıştırmayı tercih edebilir.

Neden Şimdi Bu Kadar Kritik?

WordPress, internetteki içerik yönetim sistemi pazarının büyük bir bölümünü oluşturduğu için, saldırganların otomatik tarama araçlarının birincil hedefi durumunda. Daha önce ele aldığımız WooCommerce Güvenliği 2026 rehberimizde de benzer bir örüntüye değinmiştik: bir eklentide bulunan tek bir kritik açık, o eklentiyi kullanan yüz binlerce siteyi aynı anda risk altına sokabiliyor.

Bir WAF’ın buradaki rolü şu: eklenti geliştiricisi resmî yamayı yayınlayana kadar geçen sürede (genelde saatler, bazen günler), bilinen exploit imzasını taşıyan istekleri sitenize ulaşmadan engelleyebilir. Bu, “sanal yama” (virtual patching) olarak adlandırılan ve özellikle sıfır gün açıklarında hayat kurtaran bir yaklaşım.

Otomatik tarama botları da bu resmi doğruluyor: bir WordPress sitesi yayına alındığı andan itibaren, xmlrpc.php, wp-login.php ve yaygın eklenti uç noktalarına yönelik otomatik tarama trafiği almaya başlıyor. Bu trafiğin büyük kısmı hedefli bir saldırı değil, geniş çaplı, otomatikleştirilmiş bir “kapı yoklaması”; ama tarama sırasında bilinen bir açık bulunursa, istismar da genellikle dakikalar içinde otomatik olarak devreye giriyor. Bu yüzden “küçük bir site, kimse ilgilenmez” varsayımı, pratikte doğru değil; botlar site büyüklüğüne değil, kullanılan yazılım imzasına bakıyor.

Cloudflare ile WAF Kurulumu: Adım Adım

1. Cloudflare hesabınıza siteyi ekleyin ve alan adınızın DNS kayıtlarını Cloudflare’in verdiği nameserver’larla değiştirin.
2. SSL/TLS modunu “Full (Strict)” olarak ayarlayın; böylece Cloudflare ile sunucunuz arasındaki trafik de şifrelenmiş kalır.
3. Güvenlik > WAF bölümünden Planınızda kullanılabilen yönetilen kural setini kontrol edin. Free Managed Ruleset ile ücretli Cloudflare Managed Ruleset aynı kapsamda değildir.
4. WordPress’e özel özel kurallar (custom rules) ekleyin: örneğin /wp-login.php adresine dakikada belirli bir istek sayısından fazla erişimi zorlayıcı bir CAPTCHA ile karşılayın.
5. wp-admin dizinine erişimi, mümkünse sabit IP aralıklarıyla veya en azından ülke bazlı kurallarla sınırlandırın.
6. Planınızda Log eylemi varsa önce gözlemleyin; yoksa test ortamında veya sınırlı bir koşulda deneyin. Giriş, REST API, ödeme ve webhook akışlarını doğrulamadan geniş engelleme kuralı açmayın.

Kod Örneği: Cloudflare Custom Rule (İfade Söz Dizimi)

(http.request.uri.path eq "/wp-login.php")

Bu ifade yalnızca giriş yolunu eşleştirir; tek başına hız sınırı uygulamaz. Ayrı Rate Limiting kuralında sayaç, süre, eşik ve eylem tanımlayın. Dakikada 5 istek ve 1 saat engel bütün planlarda kullanılamaz; eşiği gerçek trafiğe göre seçin. Eski cf.threat_score alanı artık sıfır döndürdüğünden gt 10 koşulu çalışmaz. XML-RPC kullanan makine istemcilerine CAPTCHA uygulamak entegrasyonu bozabilir.

Eklenti Tabanlı WAF ve wp-config.php Sertleştirmesi

Bulut tabanlı bir WAF kullanmıyor veya ek bir katman istiyorsanız, eklenti tabanlı bir WAF (Wordfence gibi) çalışma zamanı kurallarını doğrudan PHP seviyesinde uygular. Bu yaklaşımın performans maliyeti daha yüksek olsa da, sunucuya doğrudan erişimi olmayan paylaşımlı hosting kullanıcıları için pratik bir seçenek.

Kod Örneği: wp-config.php Sertleştirme Ayarları

// Mevcut tanımları düzenleyin; aynı sabiti iki kez tanımlamayın.
define('DISALLOW_FILE_EDIT', true);
define('WP_AUTO_UPDATE_CORE', 'minor');
// Canlı site için varsayılan: debug kapalı.
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

DISALLOW_FILE_MODS otomatik güncellemeleri de engelleyebilir. Alternatif bir yama dağıtım süreci olmadan etkinleştirmeyin. Hata ayıklamayı yalnızca gerektiğinde açın, günlükleri webden erişilemeyen bir yerde tutun ve sonra kapatın. Bu ayarlar WAF kuralı değildir.

Kod Örneği: .htaccess ile xmlrpc.php Erişimini Kısıtlama

# xmlrpc.php artık çoğu site için gerekli değil; brute force ve
# DDoS amplifikasyon saldırılarının klasik hedeflerinden biridir.
<Files xmlrpc.php>
    Require all denied
</Files>

Eğer Jetpack veya mobil bir uygulama xmlrpc.php’ye ihtiyaç duyuyorsa, tamamen kapatmak yerine yalnızca gerekli IP aralıklarına izin verecek şekilde bu kuralı uyarlayın.

Sunucu Seviyesi WAF: ModSecurity ve OWASP Core Rule Set

Kendi sunucunuza (VPS veya özel sunucu) erişiminiz varsa, Apache veya Nginx üzerinde ModSecurity modülünü OWASP Core Rule Set (CRS) ile birlikte çalıştırmak, uygulamaya hiç ulaşmadan istekleri filtreleyen düşük gecikmeli bir seçenek sunar. LiteSpeed tabanlı hostinglerde ise yerleşik LiteSpeed WAF modülü benzer bir işlevi görür.

Kod Örneği: Apache’de ModSecurity CRS Etkinleştirme

# modsecurity.conf içinde temel mod etkinleştirme
SecRuleEngine DetectionOnly
SecRequestBodyAccess On
SecResponseBodyAccess Off

# OWASP CRS dahil etme (paket yöneticisiyle kurulduktan sonra)
IncludeOptional /etc/modsecurity/crs/crs-setup.conf
IncludeOptional /etc/modsecurity/crs/rules/*.conf

# WordPress'e özgü yanlış pozitifleri azaltmak için
# önce "DetectionOnly" modunda başlatın:
SecRuleEngine DetectionOnly

SecRuleEngine ayarını doğrudan On yapmak yerine önce DetectionOnly ile başlatıp log dosyalarını birkaç gün izlemek, WordPress’in kendi admin-ajax.php ve REST API çağrılarının yanlışlıkla engellenmesini önler; bu iki uç nokta, CRS’in genel kurallarıyla en sık çakışan WordPress bileşenleri arasında.

İzleme ve Loglama: WAF’ı “Kur Unut” Yapmayın

Bir WAF’ın gerçek değeri, yalnızca kural setinde değil, o kuralların ürettiği logların düzenli incelenmesinde ortaya çıkar. Cloudflare gibi bulut tabanlı çözümlerde güvenlik olayları paneli, hangi kuralın kaç isteği engellediğini gösterir; bu veriyi haftalık gözden geçirmek, hem saldırı eğilimlerini hem de olası yanlış pozitifleri erken fark etmenizi sağlar.

Nelere Dikkat Etmeli?

• Aynı IP’den kısa sürede çok sayıda 403 (engellenmiş) yanıtı, hedefli bir tarama girişimine işaret edebilir.
• Meşru bir kullanıcı işleminin (form gönderimi, ödeme adımı) engellenmesi, kural setinde bir yanlış pozitif olduğunu gösterir.
• Aynı exploit imzasının tekrar tekrar denenmesi, sitenizin belirli bir botnet veya tarama aracının listesinde olduğunu gösterebilir; bu durumda ilgili IP aralığını doğrudan engellemek daha etkili olabilir.
• Belirli bir ülkeden gelen isteklerin engellenme oranı diğerlerine göre çok yüksekse, o bölgeye özel ek bir kural veya CAPTCHA katmanı eklemek, gerçek kullanıcıları etkilemeden gürültüyü azaltabilir.

Bu logları haftalık olarak birkaç dakika ayırıp gözden geçirmek bile, sitenize yönelen tehdit profilinin nasıl değiştiğini zaman içinde görmenizi sağlar; bu bilgi, hangi ek önlemlere öncelik vermeniz gerektiğine karar verirken doğrudan işe yarar.

Performans Etkisi ve Yanlış Pozitifler

Bir WAF’ın en sık gözden kaçan maliyeti, yanlış pozitif (false positive) üretme riski. Özellikle agresif ayarlanmış kurallar, meşru bir form gönderimini veya bir API isteğini saldırı sanıp engelleyebilir. Bu yüzden yeni bir kural setini doğrudan “block” modunda değil, önce “log only” modunda birkaç gün çalıştırıp gerçek trafiğinizle nasıl etkileştiğini gözlemlemek önemli. Bu konuyu daha önce ele aldığımız PHP OPcache ve Redis Object Cache rehberlerimizde de vurguladığımız gibi, güvenlik katmanları eklerken performans etkisini ölçmeden üretime almak, ileride hata ayıklaması zor sorunlara yol açabilir.

Eklenti tabanlı WAF’lar, her istekte ek PHP çalıştırdığı için, düşük kaynaklı paylaşımlı hostinglerde gözle görülür bir gecikme ekleyebilir. Bulut tabanlı WAF’lar ise bu yükü sunucunuzdan tamamen alıp kendi altyapılarında işlediği için, kaynak kısıtlı ortamlarda genellikle daha avantajlıdır.

WAF ile DDoS Koruması Arasındaki İlişki

WAF ve DDoS koruması sık karıştırılan iki farklı kavram. Daha önce ele aldığımız DDoS Saldırısı Nedir yazımızda değindiğimiz gibi, DDoS koruması sitenizi aşırı hacimli trafikle boğulmaktan korurken, WAF belirli bir isteğin içeriğinin zararlı olup olmadığına bakar. Cloudflare gibi sağlayıcılar bu iki katmanı aynı panelde sunduğu için, kurulumu tek seferde yapmak mümkün; ancak bulut tabanlı bir DNS/proxy servisi kullanmadan yalnızca eklenti tabanlı bir WAF çalıştırıyorsanız, hacimli bir DDoS saldırısına karşı ek bir önlem almanız gerektiğini unutmayın; eklenti tabanlı çözümler istekleri yine de sunucunuza kadar ulaştırıp orada işler.

Hız Sınırlama (Rate Limiting) ile WAF Kurallarını Birleştirme

Saf bir WAF kuralı, “bu istek zararlı bir kalıp içeriyor mu” sorusuna odaklanır; hız sınırlama ise “bu IP çok kısa sürede çok fazla istek mi gönderiyor” sorusuna bakar. İkisi birlikte kullanıldığında, hem imza tabanlı saldırılara hem de kaba kuvvet/kaynak tüketimi saldırılarına karşı tamamlayıcı bir savunma oluşur. Pratikte önerilen yaklaşım, giriş sayfası ve arama formu gibi kaynak yoğun uç noktalara ayrı, daha sıkı hız sınırları tanımlamak.

Sık Yapılan Hatalar ve Çözümleri

1. WAF’ı kurup hiç kural gözden geçirmemek

Hata: Varsayılan ayarlarla kurup “artık güvendeyim” varsayımıyla bir daha bakmamak.
Çözüm: Yönetilen kural setlerini (managed rulesets) düzenli güncel tutun ve ayda en az bir kez WAF loglarını inceleyin. Sağlayıcılar yeni exploit imzaları ortaya çıktıkça kural setlerini günceller; bu güncellemelerin otomatik uygulanıp uygulanmadığını da ayrıca kontrol edin.

2. Tüm trafiği doğrudan “block” moduyla başlatmak

Hata: Yeni bir kuralı hiç test etmeden agresif engelleme moduna almak.
Çözüm: Önce log-only modda test edin, yanlış pozitif oranını gözlemleyin, sonra kademeli olarak sıkılaştırın.

3. WAF’ı yedek yerine tek savunma katmanı sanmak

Hata: “WAF kurdum, artık eklenti güncellemelerini erteleyebilirim” gibi bir yanılgıya düşmek.
Çözüm: WAF bir sanal yama katmanıdır, gerçek yamanın yerini almaz; eklenti ve çekirdek güncellemelerini yine de zamanında yapın.

4. Admin girişini korumadan bırakmak

Hata: WAF kurup wp-login.php’ye karşı ayrı bir hız sınırlama veya iki faktörlü doğrulama uygulamamak.
Çözüm: WAF kurallarını, daha önce ele aldığımız WordPress iki faktörlü doğrulama rehberimizdeki önlemlerle birlikte katmanlayın.

5. CDN/proxy önbelleğiyle WAF kurallarını karıştırmak

Hata: CDN önbelleğinin WAF’ı otomatik olarak atladığını varsaymak. Çözüm: Cloudflare’da WAF istek değerlendirmesi ile önbellek sunumu farklı aşamalardır. Skip/istisna kurallarını, proxy dışındaki DNS kayıtlarını ve doğrudan origin erişimini denetleyin; sadece önbelleğin açık olmasından koruma atlandığı sonucu çıkarılmaz.

Kime, Hangi Durumda Uygun?

Tek sayfalık, düşük trafikli bir kurumsal tanıtım sitesi işletiyorsanız, temel bir güvenlik eklentisi ve düzenli güncellemeler çoğu zaman yeterli olabilir; tam bir WAF kurulumu bu ölçekte gereğinden fazla mühendislik yükü getirebilir. Ancak WooCommerce ile ödeme alan, kullanıcı girişi kabul eden veya orta-yüksek trafik alan bir site işletiyorsanız, en azından ücretsiz katmanı olan bulut tabanlı bir WAF (Cloudflare gibi) kurmak, düşük maliyetle önemli bir risk azaltımı sağlar. Çok sayıda üçüncü parti eklenti kullanan, sık eklenti güncellemesi yapan siteler için ise sanal yama yeteneği olan bir WAF, resmî yama beklenirken geçen kritik süreyi güvenli hale getirir.

Ajans veya freelance geliştirici olarak birden fazla müşteri sitesi yönetiyorsanız, her site için ayrı ayrı manuel takip yapmak yerine, tüm siteleri tek bir bulut tabanlı WAF panelinden merkezi olarak izlemek zaman açısından ciddi bir avantaj sağlar; bir müşteri sitesinde tespit edilen yeni bir saldırı kalıbını, aynı panelden diğer tüm sitelere de hızla uygulayabilirsiniz. Kurumsal ölçekte, uyum (compliance) gereksinimleri olan siteler (ödeme işleme, kişisel veri toplama) için ise WAF kaydı, olası bir güvenlik denetiminde “makul önlemler alındığının” somut bir kanıtı olarak da işe yarayabilir.

Sonuç

WordPress WAF kurulumu, kullanılan altyapıda desteklenen kuralların seçilmesi, yanlış pozitiflerin ölçülmesi ve güncellemelerin sürdürülmesiyle tamamlanır. WAF bütün güvenlik açıklarını kapatmaz; özellikle HTTP dışındaki tedarik zinciri olayları için ayrı denetim gerekir.

Sık Sorulan Sorular

WordPress WAF ücretsiz olabilir mi?

Evet. Cloudflare’in ücretsiz planı temel bir yönetilen kural seti ve DDoS koruması sunar; küçük ve orta ölçekli siteler için makul bir başlangıç noktasıdır.

WAF kullanmak site hızını yavaşlatır mı?

Bulut tabanlı bir WAF genelde performansı olumsuz etkilemez, hatta CDN önbellekleme sayesinde hızlandırabilir. Eklenti tabanlı WAF’lar ise ek PHP işlem yükü getirdiği için, düşük kaynaklı hostinglerde gözle görülür bir gecikme yaratabilir.

WAF, eklenti güncellemelerinin yerini tutar mı?

Hayır. WAF, bilinen exploit kalıplarını geçici olarak engelleyen bir “sanal yama” katmanıdır; asıl güvenlik açığı, eklenti veya çekirdek güncellemesiyle kapatılmalıdır.

Hangi WAF türünü seçmeliyim?

Paylaşımlı hosting kullanıyorsanız bulut tabanlı bir WAF (Cloudflare, Sucuri) genellikle en pratik seçenek. Sunucunuza tam erişiminiz varsa, ModSecurity gibi sunucu seviyesi bir çözüm daha düşük gecikmeyle çalışabilir.

WAF kurduktan sonra siteme giremiyorum, ne yapmalıyım?

Bu genellikle bir yanlış pozitif kuralın kendi IP’nizi veya giriş isteğinizi engellemesinden kaynaklanır. WAF panelinden ilgili kuralı geçici olarak log-only moda alın veya kendi IP’nizi bir izin listesine (allowlist) ekleyin.

Teknik kaynak: Cloudflare — Rate limiting ve plan sınırları.

Teknik kaynak: Apache 2.4 — Erişim kontrolü.