Blog

Web sitenizi korumak için bir güvenlik duvarına ihtiyacınız olduğu kesin. Peki, satın aldığınız hosting paketi bu korumayı varsayılan olarak sunuyor mu? 2026 yılında neredeyse her hosting planı “firewall” ibaresini içeriyor, ancak bu terim arkasında çok farklı ürünler saklıyor. Çoğu kullanıcı, web uygulama güvenlik duvarı (WAF) dediğimiz, HTTP isteklerini tek tek inceleyen ve uygulama katmanında koruma sağlayan sistemi kastediyor. Ancak sağlayıcıların büyük bölümü yalnızca ağ katmanında çalışan basit paket filtreleme veya sunucu güvenlik paketleri sunuyor. Bu yazıda hosting ile birlikte gelen güvenlik duvarlarının gerçekte ne olduğunu, hangi katmanda çalıştığını, varsayılan kurulumların neden çoğu zaman yetersiz kaldığını ve gerçek anlamda koruma için hangi adımları atmanız gerektiğini detaylı şekilde ele alıyoruz.

Hosting Paketlerinde “Firewall” İbaresi Ne Anlama Geliyor?

Günümüzde neredeyse tüm hosting şirketleri planlarında “firewall” kelimesini kullanıyor. Bu kelime, birbirinden tamamen farklı üç ürünü tanımlamak için kullanılıyor:

• Ağ katmanı (Layer 3/4) paket filtreleme: Trafiğin sunucuya ulaşıp ulaşamayacağına karar verir. IP adresleri ve portlar üzerinden çalışır; HTTP isteğinin içeriğini görmez.
• Sunucu güvenlik paketleri: Imunify360 gibi araçlar, sunucuda çalışan betiklerin davranışını izler ve şüpheli işlemleri engeller. Bu, uygulamayı değil sunucu ortamını korur.
• Web uygulama güvenlik duvarı (WAF): Ters vekil (reverse proxy) olarak çalışır, her HTTP isteğini başlığından gövdesine kadar ayrıştırır ve uygulama seviyesinde saldırıları tespit eder.

Bir kullanıcı “hosting’de güvenlik duvarı var mı?” diye sorduğunda çoğunlukla üçüncü ürünü kasteder ve çoğu zaman yalnızca birinci ürünü bulur. Bu karmaşayı çözmek için iki kritik soru gerekir: Hangi kural seti (ruleset) uygulanıyor ve bu set hangi modda çalışıyor? Çoğu sağlayıcı bu sorulara net bir cevap vermez.

2. Ağ Güvenlik Duvarı ile Web Uygulama Güvenlik Duvarı Arasındaki Fark

Bir saldırı isteğini düşünün: Normal bir POST isteği ile bir istismar (exploit) POST isteği aynı URL’ye gönderildiğinde, ağ güvenlik duvarı ikisini deaynı görür. Çünkü OSI katman 3 ve 4’te çalışır; yalnızca IP ve port bilgisine bakar, bağlantı içindeki konuşmayı anlamaz. Sunucu taraflı yazılımlar (örneğin ConfigServer Security Firewall) bu katmanda çalışır. Web uygulama güvenlik duvarı ise katman 7’de çalışır; HTTP metodunu, yolu, başlıkları, parametreleri ve gövdeyi ayrıştırır. Bir sorgu parametresine enjekte edilen SQL ifadesi, WAF tarafından açıkça görülür ve engellenebilir.

WAF’lerin çalışma modelleri de farklılık gösterir. Yerel bir cihaz (appliance) en düşük gecikmeyi verir ancak maliyeti yüksektir. Web sunucusuna derlenen bir motor, site bazlı ince ayar yapma imkanı sunar ancak sunucu kaynağı tüketir. Bulut tabanlı WAF hizmeti ise yalnızca bir DNS değişikliğiyle devreye alınır; kural seti sağlayıcıya ait olduğu için içeriğini tam olarak göremezsiniz.

3. Paylaşımlı Hosting Planlarında Güvenlik Duvarı İddiaları (2026)

2026 Temmuz ayında yayınlanan 11 farklı hosting sayfası incelendiğinde, 10 firmanın “güvenlik duvarı” kelimesini 5 farklı anlamda kullandığı görülüyor. Kimileri sunucu güvenlik paketlerini (örneğin Imunify360) WAF olarak tanıtıyor; kimileri “Web Application Firewall” ifadesini plan özelliği olarak listeliyor ancak hangi teknolojiyi kullandığını açıklamıyor. Bazıları ise yalnızca ağ düzeyinde DDoS korumasından bahsediyor, WAF kelimesini hiç kullanmıyor.

İşletmelerin en büyük eksikliği, kullanılan kural setinin, sürümün ve paranoia seviyesinin açıklanmamasıdır. En yüksek sesle WAF savundusunu yapan firmalar bile bu bilgileri paylaşmıyor. Bu durum, aynı ticari ürünü kullanan farklı firmaların tutarsız sonuçlar almasına neden oluyor. Bazı sağlayıcılar yalnızca bileşenlerin bir kısmını etkinleştiriyor; bu da güvenlik duvarının tam kapasite çalışmadığını gösteriyor.

4. ModSecurity Varsayılan Olarak Açık mı?

cPanel tabanlı bir sunucuda ModSecurity’nin çalışabilmesi için önce Apache web sunucusuna mod_security2 modülünün kurulması ve WHM’de ModSecurity Domain Manager özelliğinin etkinleştirilmesi gerekir. Kural seti ise ayrı bir karardır; ModSecurity Vendors arayüzünden bir kural sağlayıcısı yüklenmedikçe hiçbir kural çalışmaz. Yani modül etkin ancak kural yüklü değilse, koruma sıfırdır.

ModSecurity ile dağıtılan önerilen yapılandırma dosyası, varsayılan olarak SecRuleEngine DetectionOnly modunda başlar. Bu, tüm isteklerin kaydedildiği ancak hiçbir şeyin engellenmediği anlamına gelir. Bir operatörün, SQL enjeksiyon denemelerinin sunucuya sorunsuz ulaştığını fark etmesinin en yaygın nedeni bu modun değiştirilmemiş olmasıdır.

ModSecurity projesi ölmedi. Trustwave’in ticari sponsorluğu Temmuz 2024’te sona erdi ve bakım OWASP’a geçti. Proje aktif olarak geliştiriliyor; v3.0.16 ve v2.9.14 sürümleri güncel. Ancak kural seti konusunda daha acil bir durum var: OWASP Core Rule Set (CRS) sürüm 4.28.0’a yükseldi ve çoğu entegrasyonun hâlâ kullandığı 3.3 hattının desteği bu çeyrekte sona erecek. Sağlayıcıların kural setlerini güncel tutmaması, güvenlik duvarının etkinliğini ciddi şekilde azaltıyor.

5. Bulut Tabanlı WAF: Ücretsiz ve Ücretli Planların Kapsamı

Bulut sağlayıcıların WAF hizmetleri katmanlara göre farklılık gösterir. Örneğin, ücretsiz bir plan genellikle yalnızca sağlayıcının kendi yönetilen kural setinin küçük bir alt kümesini içerir; bu set yüksek etkili ve yaygın istismar edilen güvenlik açıklarını kapsar. Ücretli planlara geçtiğinizde daha kapsamlı kural setleri ve OWASP Core Rule Set gibi ek kaynaklar kullanılabilir. Ancak, ücretsiz ve ücretli planlar arasındaki fark, kural setlerinin kapsamı ve güncellenme sıklığıdır. Ücretsiz sürüm, düşük yanlış pozitif oranı için bilinçli olarak küçük seçilmiştir. Bir kullanıcının, ücretsiz bir DNS düzeyi korumasını, ücretli bir hosting sağlayıcının isimsiz WAF’ı ile karşılaştırması, bir tarafta açıklanmış dar bir kural seti ile diğer tarafta açıklanmamış bilinmeyen bir yapının karşılaştırmasıdır.

6. Eklenti Tabanlı Güvenlik Duvarları: Nerede ve Nasıl Çalışır?

Bir WordPress eklentisi olarak kurulan güvenlik duvarı, yalnızca web sunucusu bağlantıyı kabul edip isteği PHP’ye yönlendirdikten sonra devreye girer. Yani doğrudan bir eklenti dosyasına veya tema dosyasına yönlendirilen bir istek, eklenti güvenlik duvarını hiç yüklemez. Temel koruma modunda, eklenti diğer eklentiler gibi yüklenir ve çekirdek veya başka bir eklentideki savunmasız kod, güvenlik duvarından önce çalışabilir.

Genişletilmiş koruma için PHP’nin auto_prepend_file yönergesini ayarlayarak eklentinin WordPress’ten önce yüklenmesi sağlanır. Bu ayar, bazı hosting panellerinde gömülü ve zor bulunur; yanlış bir yol girdiğinizde site hiç yüklenmeyebilir. Ayrıca, eklenti tabanlı güvenlik duvarı, uygulama seviyesinde kullanıcı kimliğini ve yetkilerini bilir; DNS düzeyindeki bir hizmet bu bağlamı bilemez ve doğrudan kaynak IP’ye istek göndererek tamamen devre dışı bırakılabilir.

7. Temmuz 2026 WordPress Çekirdek WAF Bypass Olayı

WordPress 7.0.2 sürümü yayınlanmadan yaklaşık 90 dakika önce çekirdek koduna bir düzeltme gönderildi ve bu, olayın duyurulmasıyla aynı zamana denk geldi. Güvenlik araştırmacıları, bu düzeltmeyi inceleyerek iki açığı zincirleme kullanmayı başardı: WP_Query içindeki author_exclude parametresinden SQL enjeksiyonu ve REST API toplu uç noktasında rota karışıklığı. İlk istismar denemeleri, sürüm yayınlandıktan yaklaşık 90 dakika sonra başladı. Hazırlanan kuraların neredeyse tamamı, URL’de batch/v1 ifadesini arayan kuralardı. Ancak WordPress, rest_route değişkenini genel sorgu değişkeni olarak kaydediyor ve bu değişkenleri sorgu dizesinden önce POST gövdesinden okuyor. Basit bir POST isteği ile form gövdesine rest_route eklenerek toplu uç noktaya ulaşmak mümkün oldu; URL’de hiçbir iz bulunmadığı için URL’yi inceleyen güvenlik duvarı bu isteği engelleyemedi.

Bu olay, güvenlik duvarı kuralarının yalnızca URL’ye değil, istek gövdesine ve yöntemine de bakması gerektiğini bir kez daha gösterdi. Saldırı kampanyası yüksek hacimli ve düşük hassasiyetliydi; 1.500’den fazla benzersiz IP’den 65.000’den fazla istismar denemesi yapıldı. Engellemenin %99,9’u, bu iki belirli açık için yazılmış dar kuralar tarafından sağlandı; genel kuralar yalnızca %0,1 oranında katkı sağladı.

8. Hosting Sağlayıcıları Ne Kadar İstismar Engelliyor?

Dolaşan iki farklı istatistik var: Ağustos 2025’te yapılan bir testte, 5 sağlayıcı, 11 WordPress’e özgü ve bilinen açıklara karşı test edildi ve saldırıların %87,8’i hosting savunmasını tamamen aştı. Ocak 2026’da yapılan daha geniş bir test ise 18 sağlayıcı ve 30 açık içeriyordu ve sağlayıcılar ortalama %25,89 engelleme oranı elde etti. Ancak ikinci testteki açıkların çoğu genel türdeydi ve WordPress bağlantısı yoktu; bu durum genel kural setlerinin daha kolay yakalamasını sağlar. Bu nedenle ikinci sayıyı ilk sayının iyileşmesi olarak okumak yanıltıcıdır. Test koşulları sağlayıcıların lehineydi: Tüm güvenlik özellikleri açıktı, istismar örnekleri basit ve obfuscation içermiyordu. Buna rağmen engelleme oranları düşük kaldı. CSRF (siteler arası istek sahtekarlığı) ise hiçbir sağlayıcı ve güvenlik satıcısı tarafından engellenemedi; çünkü normal site işlevselliğini bozmayan bir kural yazmak neredeyse imkansız.

9. WAF’ın Durdurulamayacağı Saldırılar

İstek incelemesi, iyi biçimlendirilmiş bir istek üreten saldırılara karşı yardımcı olamaz. Bu kategorilerin çoğu, WordPress kullanıcılarının en çok endişe duyduğu saldırı türlerini içerir:

• Doğru kullanıcı adı ve şifreyle yapılan oturum açma denemeleri (credential stuffing) HTTP katmanında gerçek bir girişten ayırt edilemez.
• Erişim kontrolü ihlalleri ve ayrıcalık yükseltme saldırıları — istek, yetki kontrolünden geçmeye yetkili görünür.
• İş mantığı kötüye kullanımı — her istek meşru, ancak sıralama kötü niyetli.
• Tedarik zinciri saldırıları — eklenti veya betik güvenliğinin aşılması.

Bunun güncel bir örneği 15 Haziran’da yaşandı. Bir CDN API anahtarının ele geçirilmesiyle OptinMonster, TrustPulse ve PushEngage içerik dağıtım ağlarından değiştirilmiş JavaScript kodu sunuldu. Hiçbir eklentiye güncelleme gönderilmeden, tüm eklentileri güncel olan sitelerde bile oturum açmış yöneticilerin tarayıcılarında kötü amaçlı kod çalıştı. Bu kod, yöneticinin oturumunu kullanarak gizli yönetici hesapları oluşturdu ve arka kapı eklentisi kurdu. Sunucu günlüğünde yapılan her istek, meşru bir yöneticinin kullanıcı eklemesiyle birebir aynı görünüyordu çünkü geçerli kimlik bilgileri ve nonce değerleri kullanılıyordu. 1,2 milyon site potansiyel olarak açıkta kaldı. Bu saldırı için yazılan bir azaltma kuralı, yaklaşık 36 saatte 271 saldırıyı engelledi.

10. Hangi Güvenlik Duvarı Katmanı Aktifleştirmeye Değer?

Kamuya açık bir açıklama ile ilk istismar arasındaki ağırlıklı medyan süre 5 saat. Yüksek etkili açıkların yaklaşık yarısı 24 saat içinde istismar ediliyor. Bu nedenle, adlandırılmış bir açıklığa karşı yazılmış dar bir kuralın, açığın yayınlanmasından saatler içinde devreye alınması, WAF’ın maliyetini haklı çıkaran ilk durumdur. Bu dar kuralar, Temmuz kampanyasının %99,9’unu engelledi. Sanal yama (virtual patching) olarak da adlandırılan bu yaklaşım, genel kural setlerinin savunulabildiği bir durumdur.

İkinci değerli durum ise hız sınırlama ve bot filtrelemedir. Forum kazıma amaçlı sıkılaştırılmış kurallar, gerçek ziyaretçileri etkilemeden robot trafiğinin %99’undan fazlasını durdurur. Ölçülebilir bir faydası vardır ve istismarlarla doğrudan ilgisi yoktur.

Sonuç olarak, bir hosting sağlayıcısı sorusuna “güvenlik duvarı var mı?” sorusuna herkes “evet” cevabını verebilir. Bu yüzden satın alma kararı vermeden önce şu üç soruyu sormak gerekir:

1. Hangi kural seti uygulanıyor?
2. Bu set engelleme modunda mı çalışıyor?
3. Bir WordPress güvenlik açığı yayınlandıktan sonra kural ne kadar hızlı ekleniyor?

Bu üç soruya net cevap veren bir sağlayıcı, doğrulanabilir bir iddiada bulunuyor demektir. Hiçbir teknoloji adı içermeyen bir plan özelliği ise büyük olasılıkla yalnızca pazarlama amaçlıdır.

SSS – Sık Sorulan Sorular

WAF ile IPS (Saldırı Önleme Sistemi) arasındaki fark nedir?

IPS, ağ trafiğini genel saldırı imzalarıyla eşleştirir ve uygulama bağlamı hakkında çok az bilgiye sahiptir. WAF ise kurallarını HTTP konuşmasının kendisine uygular; isteğin içeriğini ve amacını anlayabilir.

ModSecurity 2026’da hâlâ destekleniyor mu?

Evet, kesinlikle. Trustwave’in ticari desteği Temmuz 2024’te sona erdi ve bakım OWASP’a geçti, ancak geliştirme devam ediyor. ModSecurity’nin en son sürümleri v3.0.16 ve v2.9.14’tür.

OWASP Core Rule Set (CRS) nedir?

OWASP tarafından bakımı yapılan, ModSecurity ve uyumlu motorlar için ücretsiz, genel bir saldırı tespit kural setidir. Güncel sürüm v4.28.0 olup SQL enjeksiyonu, XSS, dosya içerme, kod enjeksiyonu ve tarayıcı tespiti gibi konuları kapsar.

OWASP paranoia seviyeleri nelerdir?

Düzey 1’den 4’e kadar yükselen kural katmanlarıdır. Her seviye, kendinden öncekini içerir. Seviye 1 minimum ayar gerektirirken, seviye 4 çok sayıda yanlış pozitif üretir ve ayarlanması haftalar alabilir.

Ücretsiz bir bulut planında WAF var mı?

Evet, ancak yalnızca bir yönetim kural seti içerir. Ücretsiz plan, genellikle sağlayıcının ücretsiz yönetim kural setini içerir; daha kapsamlı kural setleri ve OWASP CRS ücretli planlarda sunulur.

Bulut tabanlı WAF ile eklenti tabanlı WAF arasındaki fark nedir?

Bulut tabanlı WAF, sitenin önünde DNS düzeyinde çalışır ve trafik sunucuya ulaşmadan önce inceler. Eklenti tabanlı WAF, uygulamanın içinde çalışır ve yalnızca istek sunucuya ulaştıktan sonra devreye girer.

Yeni bir güvenlik açığı ne kadar hızlı istismar edilir?

Kamuya açıklanma ile ilk istismar arasında ortanca süre 5 saattir. Temmuz 2026 WordPress çekirdek olayında ilk denemeler, sürüm etiketlendikten yaklaşık 90 dakika sonra başladı.

Güvenlik duvarım neden kendi web sitemi engelliyor?

Genel kural setleri, niyetleri okuyamaz ve normal içerik sürekli olarak bu kalıplara uyar. OWASP Core Rule Set, WordPress tema düzenleyicisinde kaydetme işlemi sırasında 403 hatası döndürebilir; bu en sık bildirilen durumdur.

Siteğim güvenliyse WAF’ya ihtiyacım var mı?

Topluluk görüşü, derinlemesine savunma ilkesi gereği evet yönündedir; çünkü çoğu site sahibi denetleyemeyeceği üçüncü taraf kodlar çalıştırıyor. Karşıt görüş ise güvenlik duvarın ek saldırı yüzeyi oluşturduğu yönündedir.

Cloudflare ve eklenti tabanlı güvenlik duvarını birlikte kullanmalı mıyım?

Katmanlı yaklaşım genel olarak önerilir. Bulut hizmeti bot trafiğini ve DDoS saldırılarını durdururken, uygulama seviyesindeki güvenlik duvarı kimin kimliğini bilmeyi gerektiren istismar girişimlerine karşı korunur.

WAF gerçekten güvenlik sağlıyor mu?

Genel amaçlı kural setleri, uyumluluk gerekçesiyle kullanılabilir; ancak asıl değer, dar kapsamlı sanal yama ve hız sınırlama gibi ölçülebilir durumlarda ortaya çıkar. Tartışmalı olan, genel kural setlerinin kendisidir.

Güvenlik duvarı koruması, hosting paketinin kendisinden çok sizin yapılandırmanıza bağlıdır. Hosting sağlayıcınızın hangi katmanda neyi koruduğunu bilmek, doğru ek güvenlik önlemlerini almanızı sağlar. Unutmayın: Hiçbir güvenlik duvarı, güncel yazılım ve doğru yapılandırma kadar önemli değildir. Hosting güvenliği için 2FA kullanımı gibi temel adımları da atarak web sitenizi koruma altına alabilirsiniz. Ancak web hosting terimleri konusunda bilgili olmak ve doğru hosting seçimi yapmak bu sürecin ilk adımıdır.