DDoS koruması nasıl çalışır? Bilmeniz gereken 5 kavram

DDoS koruması, sunucunuzun sadece “daha güçlü” olmasını değil, saldırı trafiğini doğru şekilde tespit edip filtreleyebilmesini hedefler. Aksi durumda kaynaklar (CPU, RAM, ağ bant genişliği) dolar ve gerçek kullanıcılar gecikme yaşar ya da erişemez. Bu rehberde DDoS korumasının çalışma mantığını, pratikte karar vermeyi kolaylaştıran 5 kavram üzerinden anlatıyorum: saldırı türleri, tespit/eyleme geçiş, filtreleme, trafik yönlendirme ve doğrulama (challenge).

1) DDoS saldırısı “tür” olarak düşünülmeli (Layer 3/4/7)

DDoS koruması, saldırının hangi seviyede geldiğine göre farklı yöntemler kullanır. Bu yüzden ilk kavram “hangi katmanda” saldırı olduğudur.

Katman 3-4: Ağ ve taşıma katmanı

• Layer 3 (IP): Sahte kaynak IP’leri, botnet kaynakları, anormal paket akışı.
• Layer 4 (TCP/UDP): Bağlantı kurulması (SYN), UDP taşması, bağlantı tablolarını şişirme.

Bu katmanlarda tipik hedef; bant genişliği tüketimi veya bağlantı/oturum kaynaklarını doldurmaktır. Koruma genelde oran sınırlama (rate limiting), anomali tespiti ve paket/akış bazlı filtreleme ile yürütülür.

Katman 7: Uygulama katmanı (HTTP)

• Layer 7 (HTTP/HTTPS): Aynı endpoint’e yoğun istek, yavaş istek (slow), sahte tarayıcı davranışları, form/arama yoğunluğu.

Burada amaç sadece “trafik miktarı” değil; uygulama katmanında CPU/RAM tüketmek ve aynı zamanda farklı URL desenleriyle filtre atlatmaktır. Bu seviyede WAF (Web Application Firewall), imza tabanlı kurallar ve davranışsal analizler devreye girer.

Karar için net soru

Sağlayıcının korumayı anlatırken hangi katmanlara odaklandığını net görün. Örneğin “saldırıların hepsine karşı otomatik koruma” ifadesi yerine şu tarz teknik kapsamlar yazılmalıdır: - “Layer 3/4 akış analizi ve filtreleme var” - “Layer 7 HTTP istek filtreleme / WAF özellikleri var”

2) Tespit (detection) olmadan koruma yok: anomali + istatistik + eşik

DDoS koruması tek hamlede çalışmaz. Önce trafik içindeki anormallik tespit edilir; sonra eşik (threshold) aşıldığında korumaya geçilir.

Eşik mantığı nasıl işler?

Genellikle şu akış izlenir: 1. Trafik profili çıkarılır (normal kullanım kalıbı) 2. Anormal sapma tespit edilir (ör. aynı kaynaktan/dalga halinde yoğun istek) 3. Eşik aşılınca otomatik aksiyon tetiklenir

Bu noktada iki risk vardır: - Yanlış pozitif (false positive): Gerçek kullanıcı trafiği saldırı sanılır, erişim bozulur. - Yanlış negatif (false negative): Saldırı tespit edilmez, servis etkilenir.

“Aktif otomasyon” neyi sağlar?

İyi kurgu şu soruyu yanıtlar: “Tespit edilen anomaliye ne kadar hızlı aksiyon alınıyor?” - Saniyeler içinde devreye giren sistemler, özellikle Layer 4/7’de hasarı azaltır. - Daha yavaş reaksiyonlarda kaynaklar şişer ve web uygulaması zaten çökme noktasına gelir.

Sağlayıcıyı değerlendirirken bakılacak teknik sinyaller

Net ölçüm olmasa bile, şu ifadeler genellikle olgun bir tespiti işaret eder: - “Anomali temelli trafik analizi” - “Otomatik mitigasyon (otomatik engelleme/koruma)” - “Eşik değerleri ve kural ayarlarının yönetilebilir olması”

3) Filtreleme (mitigation) nasıl yapılır? Rate limit, siyah/beyaz liste ve karıştırma

Korumanın ikinci büyük bölümü filtreleme ve hafifletme (mitigation) adımıdır. Bu adımda saldırı trafiği ya tamamen engellenir ya da “zararsız seviyeye” düşürülür.

Rate limiting: “Limit” neden işe yarar?

Örneğin aynı IP’den veya aynı imza/oturum deseninden gelen istek sayısı aşırıya çıkarsa, sistem o akışı yavaşlatır. - Layer 7’de endpoint bazlı (ör. /login, /search) rate limit görülebilir. - Layer 4’te belirli port/protokol akışında oran sınırlama yapılır.

Net fayda: Gerçek kullanıcılar için kapasite korunur. Net risk: Yanlış limit ayarı, normal kullanıcıları da etkiler.

Siyah/beyaz liste (black/white list) ve imza eşleştirme

• Black list: Bilinen zararlı kaynaklar/kalıplar otomatik engellenir.
• White list: Güvenilir kaynaklara daha esnek kurallar uygulanabilir.
• İmza tabanlı eşleştirme: Belirli saldırı desenleri (URL paterni, header kalıbı, paket davranışı) tespit edilir.

Bu yöntemler tek başına “her şeyi çözer” değildir; ama tespit aşamasının çıktısını güçlendirir.

Scrubbing ve trafik temizliği

Bazı mimarilerde saldırı trafiği önce “temizleme” havuzuna alınır. Temiz filtrelenmiş trafik uygulamaya geri gönderilir. - Özellikle bant genişliği taşmalarında, sağlayıcı tarafındaki temizleme katmanı kritik olur. - Scrubbing (temizleme) kapasitesi, net olarak saldırıdan etkilenip etkilenmeyeceğini belirler.

Uygulama tarafı için mutlaka plan yapın

Filtreleme doğru olsa bile, web uygulamanızın kapasite sınırları vardır. Bu yüzden DDoS koruması tek başına “her zaman çözüm” değildir. Özellikle şu güvenlik katmanlarını birlikte düşünün: - Cache (object cache dahil): Aynı sorgular tekrar tekrar işlenmez. - Connection limit / thread limit: Uygulama kuyruk taşmasını kontrol eder. - Fail2ban tarzı otomasyon: Belirli brute-force veya anomali desenlerinde ek koruma sağlayabilir.

4) Trafik yönlendirme (routing) olmadan “koruma” çalışmaz

DDoS trafiği her zaman doğrudan sunucunuza gelmez. İyi tasarım, saldırı trafiğini daha erken bir noktada yakalamayı hedefler.

Proxy / reverse proxy / edge yaklaşımı

Genelde kullanılan mimariler: - Trafik sağlayıcının “edge” katmanına gider. - Orada tespit/filtreleme yapılır. - Temiz trafik hedef VDS/VPS/dedicated sunucuya iletilir.

Bu yaklaşımın kritik sonucu şudur: - Sunucunuzun ağ bant genişliği saldırı tarafından tüketilse bile, edge katmanı temizlenmiş akışı gönderir.

DNS tabanlı yönlendirme (GSLB/Anycast) mantığı

Bazı çözümler DNS ile trafiği yakın/uygun koruma merkezine yönlendirir. Bu, gecikmeyi düşürebilir ve dağıtık saldırılarda daha hızlı mitigasyon sağlayabilir.

“Müşteri sunucusu ne zaman risk altında kalır?”

Net bir kontrol sorusu: - Koruma ne zaman devreye giriyor? - Saldırı trafiği sunucuya hiç ulaşmadan temizleniyor mu? - Yoksa önce sunucunun performansı düşüyor, sonra mı engelleniyor?

Layer 3/4 taşmalarda, “hedefe ulaşmadan” temizleme yapan mimariler daha etkilidir.

5) Doğrulama (challenge) kullanıcıyı ayırır: Bot ile gerçek trafiği ayırma

Trafik filtrelemede asıl zor konu şudur: Saldırganlar gerçek tarayıcı gibi davranabilir. Bu noktada challenge (doğrulama) mekanizmaları devreye girer.

Challenge nasıl çalışır?

Kural basit görünebilir: Uygulama veya edge katmanı, şüpheli isteklere ekstra doğrulama ister. - JavaScript tabanlı doğrulama - Cookie/oturum temelli doğrulama - CAPTCHA benzeri adımlar (her çözüm aynı değildir)

Net fayda: Gerçek kullanıcıların doğrulama süreçlerini tamamlaması beklenir; botların ise tamamlayamaması hedeflenir.

Yan etki: Mobil ağlar ve tarayıcı uyumluluğu

Challenge mekanizmaları doğru tasarlanmadığında şu etkiler görülebilir: - Bazı tarayıcılar/eklentiler doğrulamayı zorlaştırabilir. - Mobil operatör NAT’leri nedeniyle aynı çıkış IP’si birçok kullanıcıya ait olabilir; bu da yanlış pozitif üretir.

Bu yüzden sağlayıcının challenge eşiği ve istisnaları (ör. belirli path’ler, bot istisnaları) yönetilebilir olmalıdır.

WAF ile challenge ilişkisi

• WAF (Layer 7 güvenliği): Zararlı payload desenlerini, şüpheli header/URL kalıplarını hedefler.
• Challenge: Botları daha davranış/oturum temelli ayrıştırır. İdeal senaryoda ikisi birlikte çalışır: WAF şüpheyi tespit eder, challenge doğrular.

NetKıyas’ta kontrol edilecek kriterler: “koruma var” yerine “koruma nasıl”

Aşağıdaki liste, teknik karar vermeyi kolaylaştırır. Hosting karşılaştırması yaparken kutucuk gibi düşünmeyin; her maddede sağlayıcının ne sunduğunu somutlaştırın.

Karşılaştırma kontrol listesi

• Hangi katmanlar kapsanıyor? (Layer 3/4 mi, Layer 7/WAF mı?)
• Tespit ve otomatik mitigasyon var mı? (eşik + hızlı aksiyon)
• Mitigasyon yöntemleri neler? (rate limit, scrubbing, blacklist/whitelist)
• Trafik sunucuya ulaşmadan mı temizleniyor? (edge/hosting öncesi filtreleme)
• Challenge mekanizması var mı? (bot ayırma) ve yönetilebilir mi?
• Log ve raporlama sunuluyor mu? (hangi IP/URL desenleri tespit edildi?)
• Yönetim seçenekleri var mı? (kural ayarları, whitelist, path istisnaları)
• SLA veya kapasite beyanı var mı? (özellikle bant genişliği/peak değer)

Beklenen yanıtı somutlaştıran mini tablo

Uygulama senaryoları: Hangi koruma tasarımı hangi siteye daha uygun?

DDoS korumasını “tek beden” olarak düşünmeyin. Site trafiği ve uygulama türü, hangi yaklaşımın daha kritik olacağını belirler.

E-ticaret (login, checkout, arama)

• Layer 7 saldırılar sık görülür: özellikle arama ve ürün listeleme endpoint’leri.
• WAF + endpoint bazlı rate limiting + challenge birlikte daha tutarlı sonuç verir.

Kurumsal web siteleri (az değişen içerik)

• Cache ve WAF/edge filtreleme önem kazanır.
• Düşük TTFB hedefleyen optimizasyonlar, DDoS anında uygulama çökmesini geciktirir.

API servisleri (çok sayıda istek)

• Oran sınırlama (rate limit) ve anahtar/kimlik doğrulama mantığı kritik olur.
• Challenge her endpoint’e uygulanmak yerine, şüpheli desenlerde devreye sokulmalıdır.

Sonuç: Hızlı aksiyon için şimdi 3 adım uygulayın

DDoS koruması; saldırı türünü doğru katmanla eşleştirmek, anomaliyi tespit edip otomatik mitigasyon başlatmak, trafiği erken noktada temizlemek ve bot- gerçek ayrımını challenge/WAF ile yapmak üzerine kurulur. Karar vermek için bugün yapmanız gereken en net 3 kontrol şunlar: (1) sağlayıcının Layer 3/4 ve Layer 7 kapsamını doğrulayın, (2) mitigasyon yöntemlerini (rate limit/scrubbing/challenge) somut olarak isteyin, (3) log/raporlama ve kural yönetimi olup olmadığını kontrol edin. Bu maddeleri yerine getirmeden “koruma var” beyanına güvenmeyin.