WAF nedir, ne işe yarar? Web sitenizi nasıl korur?

WAF (Web Application Firewall), web uygulamalarını internetten gelen saldırı denemelerine karşı koruyan bir güvenlik katmanıdır. Sunucu güvenliği (OS hardening) ve ağ güvenliği (firewall) genelde daha geniş kapsar; WAF ise özellikle uygulama katmanındaki istekleri (HTTP) değerlendirir. Bu yazıda WAF’nin ne olduğunu, hangi saldırıları durdurduğunu, hangi performans/ayar etkileriyle geldiğini ve doğru WAF seçimi için net kontrol listesini öğreneceksiniz.

WAF (Web Application Firewall) nedir?

WAF, kullanıcıdan gelen HTTP/HTTPS isteklerini inceleyip zararlı olabilecek desenleri, davranışları ve anormallikleri engelleyen veya yönetilen bir güvenlik sistemidir. Temel farkı şudur: Klasik ağ firewall’ı çoğu zaman “hangi porta/kimliğe izin var” sorusuna odaklanır; WAF ise “bu isteğin içinde ne var ve uygulama bunu nasıl yorumlar” kısmına müdahale eder.

WAF’in tipik işleyişi şu şekildedir: - Tarayıcı veya bot uygulamanıza istek gönderir. - İstek WAF üzerinden geçer (reverse proxy katmanı gibi). - WAF istek başlıkları, URL, query parametreleri, cookie değerleri ve gövde (body) dahil olmak üzere içeriği kurallara göre analiz eder. - Sonuç “allow / block / challenge (captcha veya tarayıcı doğrulama) / log” gibi aksiyonlara dönüşür.

WAF çoğu kurulumda tek bir “ürün” değil, bir kural motoru (signature/regex, anomali tespiti, JSON/XML kontrolü gibi) ve bir aksiyon politikası kombinasyonudur. Bazı çözümler managed (yönetimli) gelir; bazıları kendi kural setinizi tasarlamanızı ister.

WAF nerede konumlanır?

WAF’in konumu uygulamanın mimarisine göre değişir: - DNS tabanlı veya edge tabanlı: Trafik sağlayıcı tarafında WAF üzerinden geçer. Sunucunuza ek bir servis koymadan korunma alırsınız. - Reverse proxy üzerinde: Nginx/Apache önünde veya uygulama gateway’inde çalışır. - Uygulama içinde (uygulama katmanı): Daha sınırlı senaryolarda geliştirme seviyesinde rol alır.

Net karar için şunu kontrol etmek gerekir: WAF, gerçek istek içeriğini (body dahil) görebiliyor mu? Bu, özellikle POST istekleriyle gelen saldırılarda kritik fark yaratır.

WAF ne işe yarar? Hangi saldırıları azaltır?

WAF’in amacı “tüm siber saldırıları bitirmek” değil; web uygulamasına özel riskleri azaltmaktır. Aşağıdaki saldırı sınıflarında WAF belirgin şekilde fayda sağlar:

1) OWASP Top 10 saldırı yüzeyi

WAF, sık görülen uygulama zafiyetlerini hedefleyen denemeleri yakalamada etkilidir. Örnekler: - SQL Injection (SQLi): URL parametresi veya body içindeki sorgu enjeksiyonu desenleri - Cross-Site Scripting (XSS): HTML/JS enjekte etmeye çalışan payload desenleri - Path Traversal: ../ gibi dizin atlama denemeleri - Command Injection / Script injection: Uygulama komutlarını manipüle etmeye yönelik istekler - File inclusion denemeleri: Şablon/endpoint üzerinden dosya okuma kurguları

WAF bu saldırıları genellikle “imza/kurala göre” yakalar; bazı modern WAF’ler davranış/anomali sinyallerini de kullanır.

2) Bot trafiği ve kaba denemeler

WAF, tek başına DDoS (dağıtık hizmet engelleme) cihazı değildir; fakat uygulama katmanındaki aşırı yüklenmeyi tetikleyen istek örüntülerini (ör. login endpoint’inde tekrar tekrar deneme) azaltabilir. Managed WAF’lerde: - hız sınırlama (rate limiting) - challenge (örn. tarayıcı doğrulama) - kötü niyetli imza/ülke/ASN bazlı kontroller

gibi mekanizmalar bulunur.

3) Yetki aşımı ve yanlış istek kalıpları

Her yetki hatası WAF ile çözülmez; çünkü yetki (authorization) doğru şekilde uygulama kodunda da kontrol edilmelidir. Ancak WAF, açık biçimde anormal veya beklenmeyen parametre kombinasyonlarını bloklayarak saldırı denemelerinin önünü kesebilir.

WAF nasıl çalışır? Kurallar, imzalar ve false positive dengesi

WAF’in iki temel yaklaşımı vardır: - Signature-based (imza/düzen tabanlı): Bilinen kötü niyetli kalıpların URL/parametre/body içinde yakalanması. - Anomali/heuristic: Beklenen davranışa uymayan isteklerin tespit edilmesi (ör. olağandışı karakter oranı, anormal içerik türleri).

Signature WAF ne zaman daha güçlüdür?

• Daha bilinen saldırı sınıflarında (Sqli/Xss gibi) hızlı fayda sağlar.
• OTPlar veya belirli endpoint’ler üzerinden tekrarlayan saldırılar yakalanır.

Anomali WAF ne zaman daha güçlüdür?

• Yeni/çeşitlenmiş payload’larda imzalar yetmediğinde ek katman görevi görür.
• Ancak yanlış pozitif üretme riski signature tabanlı çözümlere göre daha değişken olabilir.

False positive (yanlış engelleme) neden olur?

Yanlış pozitif; meşru bir isteğin saldırı gibi algılanmasıdır. Bunun en sık nedenleri: - Yanlış veya aşırı geniş WAF kural seti - Uygulama davranışının (ör. çok özel query parametreleri) WAF’in “normal” olarak kabul ettiklerinden farklı olması - API isteklerinde farklı Content-Type (ör. JSON) ve body formatı

Net pratik: WAF’i ilk bağladığınızda “logla” modunda gözlem yapıp ardından kademeli bloklama uygulamak en kontrollü yoldur.

Managed WAF mi, kendi yönettiğiniz WAF mi?

Bu karar, teknik ekibinizin olgunluğuna ve trafik/uygulama kritikliği seviyesine bağlıdır. Aşağıdaki tablo, net bir çerçeve verir:

Hangi durumda managed WAF daha mantıklı?

• Ek güvenlik ekibi yoksa
• Hızlı koruma hedefleniyorsa
• WAF kurallarını yazmak yerine sağlayıcının deneyiminden faydalanmak isteniyorsa

Hangi durumda kendi yönettiğiniz WAF daha mantıklı?

• Çok özel endpoint davranışları varsa ve ince kontrol gerekiyorsa
• Özel kural yazımı/izleme süreçleri kurabilecek bir ekip varsa
• Mevcut mimaride edge sağlayıcısı yerine uygulama önünde WAF gereksinimi doğduysa

WAF seçerken net kontrol listesi

WAF satın alma veya devreye alma aşamasında “var/yok” sorusu yetmez. Aşağıdaki maddeler, kararınızı somutlaştırır.

1) İnceleme kapsamı: URL + query + body görünüyor mu?

Saldırılar sadece URL’de olmaz. Özellikle login, kayıt, ödeme, arama gibi endpoint’lerde saldırı payload’ları gövde (body) içinde gelir. Şu kontrol edin: - WAF, POST/PUT body içeriğini analiz edebiliyor mu? - JSON/XML isteklerinde doğru ayrıştırma yapabiliyor mu? - Dosya yükleme (multipart/form-data) senaryolarında nasıl davranıyor?

2) Loglar ve aksiyon türleri (allow / block / challenge)

Aşağıdakiler yoksa yönetim zorlaşır: - WAF olaylarının detaylı loglanması - Hangi kuralın tetiklendiğinin görünmesi (kural ID gibi) - Bloklama dışında challenge veya geçici izin gibi aksiyonların bulunması

3) Performans etkisi ve cache stratejisi

WAF analiz yaptıkça gecikme artabilir. Net test için: - Aynı endpoint’e (ör. /api/search) WAF aç/kapa karşılaştırması yapın - Özellikle yüksek trafikte (Peak saat) P95/P99 gecikme artışını ölçün

4) Rate limiting ve bot yönetimi yetenekleri

WAF’in DDoS yerine geçtiği düşünülmemelidir; ancak uygulama katmanında aşırı istekler için rate limiting kritik olabilir. Kontrol edin: - IP bazlı mı, session bazlı mı? - Login endpoint’i için ayrı politika tanımlanabiliyor mu? - Yanlış engellemeye sebep olmayacak şekilde whitelist desteği var mı?

5) Kural seti ve istisnalar (exceptions)

Her uygulama farklıdır. Şu yetenekler karar verdirir: - Belirli URL/parametre için kural kapatma veya seviyelendirme - Kuralların “logla” modunda test edilebilmesi - İstisnaların versiyonlanabilmesi

6) TLS (HTTPS) ile birlikte çalışma

WAF genelde TLS trafiğini yönetebilir ya da edge’de konumlanır. Net gereksinim: - WAF’in sertifika ve TLS sonlandırma (TLS termination) ile ilişkisi - Mevcut TLS kurulumunuzda kırılma riski olup olmadığı

ModSecurity ile WAF ilişkisi: Paylaşımlı hostingde durum nasıl olur?

ModSecurity (WAF bileşeni olarak bilinir) birçok altyapıda “WAF yaklaşımı” olarak kullanılır. Önemli nokta şudur: Aynı isim geçse bile paylaşımlı hostingde sunucu seviyesi konfigürasyonlara erişiminiz kısıtlı olabilir.

Net beklenti için şunları sorun/ kontrol edin: - ModSecurity aktif mi ve hangi rule set kullanılıyor? - Kuralların seviyeleri değiştirilebiliyor mu? - Log erişimi var mı (en azından engellenen isteklerin özeti)? - Özel endpoint’lerde istisna ekleme yapılabiliyor mu?

Bu bilgi net değilse, “WAF var” demek tek başına yeterli olmaz; uygulamanızın gerçekten doğru analiz edilip edilmediği anlaşılmaz.

Uygulamada WAF’i doğru bağlama: Riskleri azaltan adımlar

WAF’i devreye alırken en sık yapılan hata, doğrudan “tam engelleme” moduna geçmektir. Daha kontrollü bir sıra şöyledir:

1) Ön analiz: Hangi endpoint’ler riskli?

• Login/kayıt
• Arama ve filtreleme
• Admin panel (varsa)
• Form gönderimi ve ödeme akışı
• API endpoint’leri (REST/GraphQL dahil)

2) Log modunda 24-48 saat gözlem

• Engellenen isteklerin raporunu inceleyin
• Yanlış pozitif şüphesi olanları işaretleyin

3) Kural seviyelerini kademeli artırın

• En kritik kurallardan başlayın
• Önce block yerine challenge/log seçeneklerini deneyin

4) Uygulama uyum testi yapın

Örneğin bir e-ticaret sitesinde: - ürün arama parametreleri - kupon kodu (özel karakterler içerebilir) - tarayıcı kimliği ve cookie kullanımı

WAF’in bu davranışları “normal” kabul etmesi gerekir. Aksi halde satış akışında kesinti yaşanır.

Sonuç: WAF’i “ek güvenlik” değil, ölçülebilir kontrol olarak ele alın

WAF, web uygulamanızı uygulama katmanındaki saldırı denemelerine karşı koruyan ve trafik içinde zararlı kalıpları yönetmenizi sağlayan bir güvenlik bileşenidir. Doğru kurulumda SQLi ve XSS gibi saldırı sınıflarında belirgin risk azalır; yanlış kurulumda ise false positive nedeniyle kullanıcı akışı bozulabilir. Bu yüzden ilk adım olarak WAF’in URL + query + body analizini, log/aksiyon detaylarını ve kademeli devreye alma kabiliyetini netleştirin; ardından kısa test penceresiyle performans (P95/P99) etkisini ölçün. En güvenli yaklaşım, WAF’i log modunda izleyip sonra kural seviyelerini adım adım artırmaktır.