Anti-DDoS VDS gerçekten çalışır mı? Kanıtlı kontrol rehberi

Anti-DDoS VDS ifadesi, çoğu zaman tek bir düğmeye basınca “saldırılar biter” gibi anlatılır. Oysa gerçek koruma; hangi trafik tipini (L3/L4 mi, L7 mi), hangi filtreleme yöntemleriyle, hangi hız/kapasite limitleri dahilinde yaptığınıza bağlıdır. Bu rehberde, Anti-DDoS özelliğinin gerçekten çalışıp çalışmadığını ölçmek için; VDS sağlayıcının sunduğu katmanları, doğrulanabilir kontrolleri ve olay sonrası performans etkisini net bir akışla ele alacağız.

Anti-DDoS VDS neyi korur: katman (layer) ayrımı

Anti-DDoS’un “çalışıp çalışmadığı”nı anlamanın ilk şartı, korumanın saldırı yüzeyinin hangi katmanına dokunduğunu bilmenizdir. Aynı işletme, farklı protokollerle gelen saldırılarda aynı sonucu vermez.

L3/L4 (network) koruma ne sağlar?\n- IP/Port bazlı anomali tespiti

• SYN flood, UDP flood, reflection (yansıma) gibi trafiklerde filtreleme
• Çok yüksek paket oranlarında (pps) bağlantı kurma maliyetini azaltma

Bu katman genelde “VDS’e ulaşmadan” önce, sağlayıcının upstream altyapısında temizleme (scrubbing) fikrine dayanır.

L7 (application) koruma ne sağlar?

• HTTP/HTTPS isteklerinde WAF benzeri davranışlar
• URL/host başına anomali tespiti
• Cookie ve session davranışı ile bot ayırt etme
• Rate limiting (istek hız sınırlama)

L7 korumada kritik nokta: Anti-DDoS adıyla satılan bazı sistemler, L3/L4 kadar net ölçümlenmez. Bu yüzden L7 testleri ayrıca yapılmalıdır.

Anti-DDoS her şeyi “durdurur” mu?

Hayır. En sağlıklı yorum; “hangi saldırı tipinde ne kadar kapasiteli filtreleme” sorusunun cevabıdır. Örneğin 1 Gbps etkili bir UDP flood’da, 200 Mbps temizleme kapasitesi olan bir altyapı farklı sonuç verir.

Gerçek korumayı belirleyen 6 teknik kriter

Anti-DDoS VDS’in iddia edildiği gibi çalışıp çalışmadığını anlamak için, satın almadan önce ve satın aldıktan sonra aşağıdaki kriterleri kontrol edin.

1) Hangi trafik türü kapsanıyor?

Sağlayıcının dokümanında açıkça şu ayrımlar yer almalıdır: - L3/L4 flood (UDP/TCP/SYN) - L7 HTTP flood - DNS amplification gibi özel vektörler

Dokümanda “anti-ddos” genel geçiyorsa, ölçüm yapmadan güvenmeniz gerekir.

2) Temizleme kapasitesi (scrubbing/throughput)

Sık yapılan hata şudur: Sağlayıcı “DDoS korumalı” der; ama gerçek temizleme kapasitesi ve limitleri belirsiz kalır. Şu sorular net olmalı: - Dakika bazlı en yüksek temizleme bant genişliği (ör. 1 Gbps, 10 Gbps) - Peak anomali paket oranı (pps) beklentisi

3) Koruma “VDS öncesi” mi yoksa “VDS içinde” mi?

İki farklı mimari vardır: - VDS öncesi temizleme: Trafik veri merkezinde ayrıştırılır, kötü trafik filtrelenir. - VDS içinde/host-level: Linux seviyesinde iptables/conntrack vb. mekanizmalar devreye girer.

VDS içinde koruma; yoğun saldırılarda kaynak tüketimi (CPU, conntrack tablosu, bant genişliği) nedeniyle gecikmeli kalabilir. En iyi pratik, upstream temizleme ile başlamasıdır.

4) SLA/olay müdahalesi: “ne zaman” ve “nasıl”

Anti-DDoS “çalışır” ancak müdahale süresi belirleyici olur: - Olay tespiti ne kadar sürede? - Müşteriye hangi kanaldan bildirim? - Filtreleme kuralı (rule) güncellemesi nasıl yapılıyor?

5) Log ve olay raporu erişimi

Doğrulanabilirlik için şunları isteyin/arayın: - Saldırı başlangıç-bitiş zamanları - Etkilenen protokol/portlar - Temizlenen trafik oranı - VDS’in aldığı gerçek bant genişliği ve hata oranları

6) Rate limiting/WAF ile birlikte mi?

L7 senaryolarında sadece “anti-ddos” yetmeyebilir. CDN/WAF, rate limiting ve bot yönetimi katmanlarının varlığı ve konfigürasyon imkanı kritik olur.

Anti-DDoS VDS’i test etme: güvenli ve ölçülebilir plan

Canlı ortamda gerçek saldırı simülasyonu riskli olabilir. Bu rehberde hedef; servis kesintisi yaratmadan ölçüm sinyali üretmektir. Hangi testin işe yarayacağını senaryoya göre seçin.

Testten önce kontrol listesi (dakikalar içinde)

Aşağıdaki ölçümleri alın; sonuçları karşılaştırmak için gereklidir. - VDS’te gerçek zamanlı metrikler: CPU, RAM, network in/out (bps) - Uygulama metrikleri: HTTP 4xx/5xx, ortalama yanıt süresi (p50/p95) - Sistem metrikleri: conntrack doluluk (varsa), kernel drop sayıları - Baseline: normal trafik senaryosunda 15-30 dakika ölçüm

Hedef 1: L3/L4 flood etkisini anlama

Yapmanız gereken: - UDP/TCP yoğunlukta kademeli deneme (hız bir anda yükseltilmez) - Aynı anda VDS network metriklerini izleme - Uygulama katmanı için 5xx artışı var mı bakma

Beklenen doğru davranış: - Sağlayıcı upstream filtrelemesi varsa, VDS’e düşen bant genişliği ve paket oranı belirgin şekilde sınırlanır. - VDS CPU kullanımında ani sıçrama olmaz (en azından erken safhada).

Beklenen yanlış davranış: - VDS CPU/conntrack hızla tükenir. - Paket kaybı ve yüksek drop görülebilir. - Uygulama zaman aşımı belirginleşir.

Hedef 2: L7 HTTP flood’da “anti-ddos”ün sınırını görmek

Yapmanız gereken: - Normal isteklerin dışında, belirli endpointlere yoğunlaşan istekleri kontrollü üretme - HTTP status dağılımına bakma (özellikle 429 Too Many Requests, 403 Forbidden) - Yanıt süresi ve error rate değişimini baseline ile karşılaştırma

Beklenen doğru davranış: - L7 katmanında rate limiting/WAF benzeri davranışlar görürsünüz (ör. 429/403). - p95 yanıt süresi aşırı bozulmadan bir bantta kalır.

Beklenen yanlış davranış: - Tüm istekler VDS’e kadar gelir ve uygulama kaynakları tükenir. - Yanıt süresi lineer şekilde artar, ardından 5xx patlar.

Hedef 3: DNS ile ilgili DDoS türlerinde sonuçları ayırma

Birçok kullanıcı “siteye giremiyorum” der ama sorun DNS tarafında olabilir. Bu yüzden: - DNS çözümleme (A/AAAA) sorgularında gecikme var mı test edin - DNSSEC ve DNS WAF katmanlarını ayrı değerlendirin

Beklenen doğru davranış: - Sağlayıcı DNS katmanında koruma sağlıyorsa çözümleme gecikmeleri sınırlanır.

Sağlayıcı iddiaları nasıl okunmalı: belge kontrolü

Anti-DDoS VDS satın alırken pazarlama metni yerine dokümanı okuyun. Aşağıdaki kelimeler somut sinyal verir.

Anti-DDoS VDS mi, CDN/WAF mi: mimari karar ağacı

Anti-DDoS VDS tek başına her senaryoyu çözmez. En doğru karar, saldırıların nereden geldiği ve hangi maliyetlerin kabul edilebilir olduğu ile ilgilidir.

Eğer saldırı ağırlıklı UDP/TCP flood ise

• VDS’in upstream temizleme kapasitesi kritik
• Ek olarak kernel/tuning ancak ikincil rol oynar

Eğer saldırı ağırlıklı HTTP/HTTPS flood/bot ise

• CDN + WAF + rate limiting kombinasyonu daha sık sonuç verir
• Anti-DDoS VDS varlığını “L7’de de davranış görüyor muyum?” ile doğrulayın

Eğer saldırı katmanı karışık ise

• Katmanlı yaklaşım tercih edilir: upstream + CDN/WAF + uygulama tarafında time-out ve circuit breaker

Doğrulama için pratik metrikler (raporlayın)

Sadece “erişim var/yok” yeterli olmaz. Koruma gerçekten çalıştı mı sorusunu sayılarla yanıtlayın.

Aşağıdaki metrikleri baseline ile kıyaslayın: - Network in (bps): Düşüş var mı? - CPU steal/CPU utilization: ani artış var mı? - HTTP 5xx oranı: artış frenleniyor mu? - p95/p99 latency: tek seferlik sıçrama mı, kalıcı mı? - TCP reset/timeout: bağlantı kurma kalitesi - DNS tarafı: NXDOMAIN oranı ve çözümleme gecikmesi

Yaygın yanlış anlaşılmalar (Anti-DDoS VDS neden “geçti” gibi görünür?)

1) Deneme trafiği saldırı seviyesinde değildir

Kullanıcı 5-10 dk yoğun trafik üretir; ama sağlayıcının filtre kapasitesi altında kalır. Sonuç “çalışıyor” gibi görünür.

Çözüm: Kademeli test ile sınır noktasını bulun; aynı metriklerle kıyaslayın.

2) Koruma var ama L7’de değil

Anti-DDoS sadece L3/L4 açıklanır; HTTP flood’da uygulama yine tükenir.

Çözüm: HTTP endpoint bazlı test ve 429/403 sinyalini arayın.

3) Trafik temizleniyor ama CDN olmadan kullanıcıya gecikiyor

Sertçe filtreleme yerine “geç boşaltma” varsa, kullanıcı tarafında latency artar.

Çözüm: p95 ve p99 latency ile doğrulayın.

4) Olay anında failover/yedek planı yoktur

Anti-DDoS işe yaramış olsa bile uygulama katmanı tek noktada kalır. Örneğin veritabanı bağlantıları tükenirse sayfalar yine düşer.

Çözüm: Uygulama ölçekleme, bağlantı havuzu (connection pooling), queue gibi savunma katmanları ekleyin.

Sonuç: Anti-DDoS VDS “çalışıyor” demeden önce aksiyon planı

Anti-DDoS VDS’in gerçekten çalıştığını anlamak için önce katmanı tanımlayın (L3/L4 mi, L7 mi), sonra sağlayıcı dokümanından kapasite/SLA/log sinyallerini çıkarın. Ardından VDS’te baseline alıp kademeli L3/L4 ve endpoint bazlı L7 testleriyle network ve uygulama metriklerini karşılaştırın.

Aksiyon olarak şu sırayı uygulayın: 1) Dokümanda “upstream filtering/scrubbing” ve L7 varsa doğrulayın. 2) Baseline (15-30 dk) toplayın: CPU, network bps, HTTP 5xx, p95 latency. 3) Kademeli testle L3/L4 etkisini ölçün, VDS’te ani tükenme var mı bakın. 4) Endpoint bazlı kademeli L7 test yapın; 429/403 ve p95 kontrolünü kontrol edin. 5) Sonuçlar hedefe uymuyorsa çözümü tek noktada aramayın: CDN/WAF + rate limiting + uygulama tarafı korumalarıyla katmanlayın.

Bu yaklaşım, “anti-ddos var mı?” sorusunu sayılara bağlar ve hangi senaryoda gerçekten koruma sunduğunu netleştirir.