DDoS Koruması Nasıl Çalışır? Bilmeniz Gereken 5 Kavram

DDoS (Distributed Denial of Service) saldırıları, sunucunun kaynaklarını hedefleyerek sitenin yanıt veremez hale gelmesine yol açar. Bu yazıda “koruma var/yok” tartışmasına girmeden, kullanıcı tarafında anlaşılır şekilde DDoS korumasının nasıl çalıştığını belirleyen 5 temel kavramı ele alacağız. Her kavram için pratik sonuçları, kontrol edilmesi gereken noktaları ve VDS/VPS/dedicated kullanım senaryolarındaki farkları netleştireceksiniz.

1) DDoS trafiği: volumetrik, protokol ve uygulama (layer) ayrımı

DDoS savunması için ilk ayrım, saldırının hangi seviyeyi hedeflediğidir. Sağlayıcılar genellikle trafiği şu sınıflara göre analiz eder:

• Volumetrik DDoS (L3/L4 band genişliği): En yüksek bant genişliği tüketimi hedeflenir. Trafik “sayısal olarak” büyüktür; amaç linki doldurmaktır.
• Protokol DDoS (L3/L4 kaynak/oturum): SYN flood, UDP reflection gibi yöntemlerle durum tablosu (state table) veya oturum kaynakları zorlanır.
• Uygulama DDoS (L7 HTTP): Aynı sayfaya yoğun istek, yavaş istek (slow HTTP), bot benzeri örüntüler gibi yollarla web sunucusu (Apache/Nginx/LiteSpeed), uygulama (PHP/Node) ve veritabanı zorlanır.

Neyi kontrol etmelisiniz?

• Sağlayıcınız “DDoS koruma” derken hangi layer’ı yönettiğini açık yazıyor mu? Volumetrik garanti vermeden uygulama DDoS’u çözmek mümkün değildir.
• Plan sayfasında “Giriş seviyesi: L3/L4”, “İleri seviye: L7” gibi net ayrımlar var mı?
• Koruma, sadece belirli portlar/protokoller için mi aktif? (Örn: 80/443 dışındaki trafiğe farklı yaklaşım.)

Pratik örnek: Siteniz Cloudflare benzeri bir CDN/WAF arkasında değilse ve yalnızca sunucu tarafında L7 filtreleme bekliyorsanız, volumetrik bir saldırıda önce bant genişliği/link seviyesinde tıkanma yaşanabilir. Bu nedenle layer ayrımı, doğru beklenti kurmanızı sağlar.

2) Scrubbing (temizleme merkezi) ve yönlendirme modeli

DDoS korumasının “motoru” çoğu zaman scrubbing (temizleme) mantığıdır. Sağlayıcı, saldırı trafiğini doğrudan hedef sunucuya yığmak yerine, bir ara aşamadan geçirir.

Scrubbing nasıl çalışır? - Trafik, hedefe ulaşmadan önce bir “inceleme alanına” yönlendirilir. - İstatistiksel ve davranışsal kurallarla zararlı örüntüler ayıklanır. - Temizlenen trafik hedefe aktarılır; atılan trafik hedefi yormaz.

Bu modelin iki yaygın yönlendirme yolu vardır: - Anycast tabanlı dağıtım (genelde scrubbing’e giden yol): Trafik, coğrafi olarak en yakın scrubbing noktasına yönlenir. - Daha “manuel/kurallı” yönlendirme: Sağlayıcı, saldırı tespitine göre trafiği farklı havuza alır.

Neyi kontrol etmelisiniz?

• Sağlayıcı, scrubbing’in “tam otomatik” mi yoksa “aksiyon için müdahale” mi gerektirdiğini netleştiriyor mu?
• Temizleme sonrası hedef sunucuya dönen trafik için bir hız/latency etkisi var mı? (Özellikle L7’de.)
• Hangi trafik akışında koruma sağlanıyor: DNS ile mi, proxy ile mi, yoksa veri yolu (routing) ile mi?

Pratik sonuç: Scrubbing varsa, saldırı esnasında sunucu CPU/RAM tüketiminiz “ham saldırı” kadar yükselmez. Bu fark, loglarda da görülür: sunucu erişim kayıtları azalır; ancak temiz istekler gelmeye devam eder.

3) Rate limiting (istek hız sınırı) ve “doğru eşik” problemi

Rate limiting, belirli bir süre içinde gelen istek sayısını veya yoğunluk parametrelerini sınırlamayı amaçlar. Bu kavram DDoS’a karşı etkili olabilir; fakat yanlış eşik kuralları normal kullanıcı trafiğini de kilitleyebilir.

Rate limiting şunları yapar: - Aynı IP/ASN’den gelen istekleri sınırlayabilir. - URL bazlı limit (örn: /login endpoint’ine özel sınır) uygulayabilir. - Oturum/çerez/kimlik doğrulama durumuna göre farklı kurallar kullanabilir. - Bazı sistemler “burst” (ani pik) toleransı ekler; ardından kademeli düşürür.

Neyi kontrol etmelisiniz?

• Limitler IP bazlı mı yoksa “kimlik/oturum bazlı” mı? Botlar IP dağıtarak (IP rotation) gelir; yalnızca IP bazlı limit her senaryoda yeterli olmaz.
• “Limit aşıldığında ne olur?” sorusunun cevabı: 429 döndürmek mi, captcha/JavaScript challenge mi, yoksa sessiz drop mu?
• Uygulamanız için kritik endpoint’ler (login, cart checkout, arama) ayrı mı tanımlanmış?

Aşağıdaki tablo, rate limiting’in nerede işe yaradığına ve nerede zorlandığına dair hızlı bir çerçeve verir:

Pratik öneri: Rate limit’i sadece “maks istek sayısı” olarak değil, endpoint bazlı ve uygulama davranışına uygun tasarlayın. NetKıyas’ta karşılaştırma yaparken “WAF/ACL var mı?” sorusunu rate limiting’le birlikte düşünün.

4) WAF ve ACL (Access Control List): saldırıyı kalıp üzerinden durdurma

DDoS koruması yalnızca bant genişliği değildir. Uygulama katmanında, saldırılar genellikle “istek kalıpları” taşır. Bu noktada WAF (Web Application Firewall) ve ACL (Access Control List) devreye girer.

• WAF: HTTP isteklerini normal örüntülerle karşılaştırır; zararlı olabilecek imzaları, anomali davranışlarını ve şüpheli istekleri filtreler.
• ACL: Daha deterministik kurallar uygular. Örneğin belirli IP aralıklarını engellemek/izin vermek, ülke bazlı kısıt, belirli path’lere erişimi sınırlandırmak gibi.

Neyi kontrol etmelisiniz?

• Sağlayıcı “WAF var” diyorsa, bunun L7 DDoS için aktif kullanım senaryosu var mı? (Sadece SQL enjeksiyonu için değil.)
• Kuralların ne kadar şeffaf olduğu: loglar, olay raporları ve kural yönetimi sunuluyor mu?
• Challenge mekanizması var mı? (Örn: bot şüphesi durumunda kullanıcıyı doğrulama.)

Önemli ayrım: WAF tek başına volumetrik DDoS’a karşı genellikle yeterli değildir; link kapasitesi zaten dolmuştur. Volumetrik/Protokol DDoS’u scrubbing ile söndürmeden WAF’ı “tek savunma” yapmak yanlış beklentidir.

5) Anycast ve kapasite ölçekleme: en yakın scrubbing noktası mantığı

Anycast, trafiğin aynı IP’den farklı coğrafyalardaki birden çok nod’a yönlenebilmesini sağlayan yönlendirme yaklaşımıdır. DDoS korumada anycast, yükün coğrafi olarak dağıtılmasını ve “yakın scrubbing noktasında” temizliğin yapılmasını hedefler.

Anycast’in iki pratik etkisi vardır: - Kullanıcıya giden trafik, saldırı esnasında daha stabil kalabilir çünkü rota değişimi yönetilebilir. - Saldırı yükü tek bir merkezde toplanmak yerine birden fazla noktaya yayılabilir.

Neyi kontrol etmelisiniz?

• Sağlayıcı, anycast ağını hangi bölgelerde çalıştırıyor? Türkiye’den erişimde, en yakın noktanın varlığı gecikmeyi ve iyileşme süresini etkiler.
• Kapasite modeli: “Toplam garanti” mi var, “anlık kapasite/birikimli kapasite” mi var? Burada net tanım görmek gerekir.
• Koruma seviyesi sadece “aktif” mi, yoksa periyodik yük altında test edilmiş doğrulama var mı?

NetKıyas’ta karşılaştırırken kullanacağınız 10 maddelik kontrol listesi

DDoS korumasını teknik olarak kıyaslamak için şu kriterleri kullanın:

1. Hangi layer’larda koruma var? (L3/L4 ve L7 ayrı belirtilmiş mi?)
2. Scrubbing otomatik mi? Müdahale gerektiriyor mu?
3. Anycast kullanımı var mı, Türkiye/MEA bölgeleri için yönlendirme nasıl?
4. Rate limiting var mı? Endpoint/IP/ASN/ülke bazlı seçenekler açık mı?
5. WAF/ACL bulunuyor mu ve L7 DDoS’a dönük kullanım örnekleri var mı?
6. Challenge/captcha gibi doğrulama mekanizması var mı?
7. Temizleme sonrası hedef sunucuda beklenen etki (latency) hangi senaryolarda artıyor?
8. Koruma kapsamı hangi protokoller/portlar için geçerli? (80/443, UDP, vb.)
9. Loglar ve raporlama sunuluyor mu? (Olay sayısı, bloklanan istek yüzdesi, bant tüketimi.)
10. Rate limit/waf kural yönetimi için kontrol paneli erişimi var mı?

Kısa karar rehberi: Hangi özellik hangi senaryoda kritiktir?

Aşağıdaki eşleştirme, “sitenin tipi” ile “korumanın davranışı” arasındaki bağı kurar:

• Küçük ama sık HTTP istekleri (login/checkout) ve bot trafiği → WAF + ACL + endpoint bazlı rate limiting.
• Bant genişliği tüketen saldırı (volumetrik) → scrubbing + anycast + upstream kapasite.
• Bağlantı/oturum şişiren protokol saldırıları → L3/L4 koruma, state table yönetimi, SYN/UDP pattern filtreleri.
• Uygulamanız CPU’yu sömüren dinamik sayfalar (L7 yavaşlık/süre uzatma) → WAF + L7 timeout ayarları + session kontrol.

Sonuç: Aksiyon planınız (kurulumu değil beklentiyi doğru kurun)

DDoS koruması; layer ayrımı, scrubbing, rate limiting, WAF/ACL ve anycast/kapsite ölçekleme kavramlarının birlikte çalışmasıyla anlam kazanır. İlk adım olarak kullandığınız hizmetin hangi layer’ları yönettiğini ve scrubbing/anycast modelini kontrol edin. Sonra log ve raporlama üzerinden rate limit ve WAF kurallarının nasıl uygulandığını doğrulayın.

Aksiyona dönük önerim: NetKıyas’ta karşılaştırma yaparken yukarıdaki 10 maddelik kontrol listesini aynı sayfada not alın; “sadece 24/7 DDoS koruma” ifadesi yerine scrubbing + L7 netliği + raporlama sunan sağlayıcıları öne alın. Böylece saldırı anında neyin çalıştığını anlayarak doğru planlama yaparsınız.