Anti-DDoS VDS gerçekten çalışır mı? Net test ve seçim rehberi
Anti-DDoS VDS vaatleri pratikte nasıl işler? Gerçek korumayı ölçmek için net test senaryoları, metrikler ve sağlayıcı kontrol listesi.
DDoS saldırıları “sunucu yavaşladı” seviyesinde kalmayıp servis kesintisine kadar gidebildiği için, Anti-DDoS VDS satın alırken dikkat edilmesi gereken nokta pazarlama metinleri değil; ölçülebilir koruma davranışıdır. Bu rehberde, Anti-DDoS’un gerçekten çalışıp çalışmadığını anlamak için VDS tarafında ve sağlayıcı tarafında neleri doğrulaman gerektiğini adım adım anlatıyorum. Ayrıca hangi metrikleri izlemen gerektiğini, hangi testlerin güvenilir olduğunu ve hangi eksik beyanların risk oluşturduğunu netleştiriyorum.
Anti-DDoS VDS neyi korur, neyi korumaz?
Anti-DDoS genellikle iki katmanda çalışır: - Ağ/katman 3-4 koruması: (Layer 3/4) IP, port, protokol bazlı filtreleme ve trafik dengeleme. SYN flood, UDP flood, port tarama yoğunluğu gibi saldırılarda işe yarar. - Uygulama/katman 7 koruması: (Layer 7) HTTP isteklerini anomaliye göre filtreleme. Cookie/JS tabanlı bot yönetimi, hız limitleme, kurala dayalı engelleme gibi mekanizmalar içerir.
Burada kritik nokta şu: “Anti-DDoS” etiketi, tek bir teknolojiyi garanti etmez. Aynı ürün adı altında sadece layer 3-4 filtreleme yapılabilir; layer 7 (WAF tarzı) yoksa HTTP flood saldırılarında beklenen etki görülmeyebilir.
Net ayrım: DDoS tipi ile beklenen sonuç
Aşağıdaki tabloda, yaygın saldırı tipleri ile Anti-DDoS’un sağlayabileceği sonuçları karşılaştırdım:
| Saldırı tipi | Tipik belirti | Anti-DDoS’un beklenen davranışı | Kontrol edeceğin metrik/işaret |
|---|---|---|---|
| SYN flood (TCP) | Yeni bağlantılar artar, uygulama yanıt vermez | SYN trafiği filtrelenir, yarım açık bağlantı (SYN backlog) düşer | conntrack/TCP backlog, firewall/drop istatistikleri |
| UDP flood | Bant hızlanır, uygulama servisi etkilenebilir | UDP bant genişliği korunur, servis trafiği stabil kalır | Network inbound pps, interface utilization |
| HTTP/GET flood | CPU spike, worker’lar dolar, 502/504 artar | Rate limit / bot kontrol / challenge varsa istekler temizlenir | Web server access log anomalisi, 4xx/5xx oranı |
| Cache bypass flood | Cache hit düşer, DB yüklenir | Cache koruması veya WAF kurallarıyla azaltım | CDN/cache hit oranı, DB sorgu sayısı |
Bu ayrım, “Anti-DDoS VDS var” iddiasının tek başına yeterli olmadığını net gösterir.
Anti-DDoS VDS gerçekten çalışır mı? Kanıt nasıl aranır?
Anti-DDoS’u kanıtlamak için iki şey gerekir: (1) saldırıdan önce normal davranış ve (2) saldırı sırasında korumanın etkisi. Bu yüzden testleri planlı yapmalısın.
1) Saldırı öncesi baz değerleri çıkar (baseline)
Saldırı denemeden önce 30-60 dakika normal yük altında şu metrikleri topla:
- Sunucu CPU: top/htop veya Prometheus/Grafana varsa grafikleri
- Bellek: OOM (Out of Memory) var mı?
- Disk I/O: iostat/vmstat
- Ağ: interface inbound/outbound hız ve paket sayısı
- Uygulama: hata oranı (5xx), yanıt süreleri (p95/p99)
Bu veriler olmadan “anti-DDoS çalıştı” demek imkânsız; çünkü saldırı öncesi zaten bozuluyor olabilir.
2) Saldırı sırasında izlemen gereken 7 net gösterge
Saldırı sırasında aynı metrikleri eş zamanlı izle: 1. 5xx oranı: nginx/apache/app hataları 2. Yanıt süreleri p95/p99: artış var mı, ne kadar düzeliyor 3. CPU spike süresi: koruma çalışıyorsa spike kalıcı olmaz 4. Network interface utilization: çizgiye kadar çıkar mı, sonra düşer mi 5. Drop/deny istatistikleri: iptables/nftables counters (sağlayıcı tarafı ayrıca olabilir) 6. Yeni bağlantı oranı: SYN sayısı veya HTTP istek sayısı 7. Gerçek kullanıcı trafiği etkisi: test scripti değil, gerçek URL’lere gelen normal istekler
Önemli: Anti-DDoS varsa genellikle trafiğin saldırı kaynağı tarafından sunucuya ulaşmadan filtrelenmesi hedeflenir. Bu durumda sunucu CPU ve hata oranı daha kontrollü kalır.
3) Testleri “güvenli ve ölçülebilir” yap
Gerçek saldırıyı taklit eden agresif denemeler hukuki/etik sorun çıkarabilir. Bu yüzden ölçüm için şu pratik yaklaşımı kullan: - İzinli ortamda (kendi alan adın/izinli test sayfaların) - Düşük-orta yoğunluk ile önce kırılma noktasını tespit et - Sonra sağlayıcının anti-DDoS’unun devreye girdiği anı gözlemle
Örnek bir HTTP saldırı simülasyonu yaklaşımı için (yalnızca izinli testlerde):
- hey veya wrk ile istek yoğunluğunu artır
- Aynı anda CPU/memory ve nginx access log’u izle
Kod gerektiren bir örnek vermem gerekirse, bu tip bir yük testi kabaca şöyle kurgulanır:
hey -z 60s -q 200 -c 50 https://example.com/test
Bu komut saldırı değildir; basit yoğunluk üretir. Anti-DDoS’un katman 7 davranışını görmek için istek yoğunluğu ile yanıt sürelerini ve 4xx/5xx oranını birlikte değerlendirmelisin.
Sağlayıcıdan isteyeceğin net bilgiler (sözleşmeye yazdırılacak maddeler)
Anti-DDoS VDS satın almadan önce aşağıdaki sorulara yazılı yanıt iste. Burada hedef, “var” demesini değil; “nasıl çalışır ve sınırları nedir” bilgisini almak.
Sağlayıcıya sorulacak kontrol listesi
- Katman 3-4 mü, katman 7 de var mı? (Layer 3/4 vs Layer 7)
- Mitigasyon kapasitesi nedir? (bps, pps, RPS gibi sayılar)
- Trafik hangi noktada filtreleniyor? Veri merkezinde mi edge’de mi?
- Mitigasyon etkisi hangi metrikle doğrulanır?
- Whitelist/allowlist var mı? DNS/health check IP’leri nasıl etkileniyor?
- “Blackhole routing” kullanılıyor mu? Kullanılıyorsa servis etkisi ne?
- Konfigürasyon esnekliği var mı? Özel rate limit/WAF kuralı var mı?
- Olay anında log erişimi sağlanıyor mu? Panelde rapor veya ticket ile rapor
Bu soruların cevabı “Sınırlar belirsiz, detay yok” şeklinde geliyorsa risk yüksektir. Anti-DDoS’un işe yaradığı senaryolar genellikle ölçülebilir ve limitleri konuşulabilir olandır.
Anti-DDoS VDS ile WAF / CDN birlikte değerlendirme
Anti-DDoS tek başına her şeyi çözmez. Uygulama saldırılarında çoğu zaman şu tamamlayıcı katmanlar devreye girer: - WAF (Web Application Firewall): HTTP kuralları, imza/anomali, temel bot koruması - CDN: Cache + edge’de trafik azaltma - Rate limiting: belirli endpoint’lerde istek sınırı
Net senaryo örneği: HTTP flood
Anti-DDoS sadece layer 3-4 koruyorsa, HTTP istekleri hâlâ sunucuya ulaşabilir. Sonuç olarak CPU ve worker’lar dolar. Bu durumda WAF/CDN yoksa anti-DDoS’un “çalışmadığı” gibi görünmesi normaldir.
Overselling, kaynak paylaşımı ve anti-DDoS etkisi
Anti-DDoS’un etkisini yanlış okumaya neden olan başka bir durum da VDS üzerinde kaynak paylaşımı ve overselling ile ilgilidir. Sağlayıcı overselling yapıyorsa, saldırı gelmese bile CPU payı daralabilir.
Bu yüzden kontrol planı şunu içermeli: - Normal yükte CPU steal time / performans sapması var mı? (hypervisor kaynak payı) - Disk I/O ve network limitleri kiradan bağımsız şekilde stabil mi? - Anti-DDoS devreye girdikten sonra “hızlı toparlanma” var mı?
Gerçek hayatta “anti-DDoS çalışıyor” nasıl anlaşılır?
Aşağıdaki karar mantığı, test sırasında net bir fikir verir.
Karar matrisi
- Durum A: Saldırı sırasında sunucu CPU ve 5xx düşük kalıyor, yanıt süreleri sınırlı artıyor, interface utilization toparlıyor.
- Sonuç: Anti-DDoS ağ/edge filtrelemesi etkili.
- Durum B: Sunucu CPU spike ve 5xx artıyor, fakat sağlayıcı panelinde/yanıt süresinde kısa bir toparlanma yok.
- Sonuç: Saldırı layer 7 ise veya WAF/CDN yoksa mitigasyon eksik olabilir.
- Durum C: Sunucu tamamen erişilemez oluyor, kernel/servis loglarında zaman aşımı görülüyor.
- Sonuç: Blackhole/route değişimi veya kapasite aşımı olabilir; sağlayıcı limitlerini netleştirmek gerekir.
Bu matriste “panel gördüm” tek başına yeterli değildir; sunucu tarafı davranışı (CPU, 5xx, p95/p99) ile doğrulamak gerekir.
Net öneriler: Anti-DDoS VDS seçerken teknik gereksinim listesi
Anti-DDoS VDS değerlendirmesini tek bir parametreyle bitirme. Aşağıdaki teknik kriterler kararını somutlaştırır:
1) Trafik ve kapasite sınırları
- BPS/PPS veya RPS gibi değerler net yazılmalı.
- “Sınırsız” ifadesi teknik olarak kontrol edilebilir değil; performans hedefi yerine hukuki/operasyonel bir muğlaklık getirebilir.
2) Mitigasyon türü
- Layer 3-4 koruma var mı?
- Layer 7 koruma (WAF) var mı?
- Bot/HTTP flood senaryolarında rate limit veya challenge var mı?
3) Log ve raporlama
- Olay sırasında istemci bazlı bant/istek istatistiği, bloklanan trafik raporu sunuluyor mu?
- VDS panelinde rapor yoksa en azından ticket ile olay özeti raporlanıyor mu?
4) Failover ve kurtarma süresi
- Filtreleme devreye girdikten sonra uygulama toparlanma süresi nedir?
- Sağlayıcı “otomatik kurtarma” yapıyor mu, yoksa müdahale gerekir mi?
5) Network tarafı limitler
- VDS’in network throughput limiti nedir?
- Anti-DDoS devreye gelse bile VDS tarafında NIC/IO bottleneck oluşuyorsa uygulama yine etkilenebilir.
Sık yapılan hatalar (anti-DDoS’u yanlış yorumlama)
- Sadece sağlayıcı açıklamasına güvenmek: Sunucu metrikleri ile doğrulama yoksa “çalıştı” iddiası kanıtlanmaz.
- Yanlış saldırı tipi denemek: Layer 7 yokken sadece HTTP flood test etmek yanıltıcı olur.
- Baseline almadan ölçmek: Önceden zaten sorun varsa koruma etkisini ayırt edemezsin.
- Yalnızca tek metrik izlemek: CPU izlenip 5xx/p95/p99 göz ardı ediliyorsa gerçek kullanıcı etkisi kaçabilir.
Sonuç: Anti-DDoS VDS işe yarar, ama kanıtı sen koymalısın
Anti-DDoS VDS, doğru katmanlarda doğru kapasiteyle devreye girdiğinde servis kesintisini ciddi biçimde azaltır; ancak “anti-DDoS var” cümlesi tek başına karar ölçütü değildir. Satın almadan önce katman (3-4 mü 7 mi), kapasite sınırı, filtreleme noktası ve olay raporlamasını yazılı iste; aldıktan sonra saldırı denemelerinde CPU/5xx/p95/p99 ve network davranışını baseline ile birlikte karşılaştır. En kısa aksiyon olarak: sağlayıcıdan kontrol listesine yanıt al, VDS üzerinde izleme kur (en azından nginx/app 5xx + p95/p99 + CPU/network) ve izinli düşük-orta yoğunluklu testle koruma davranışını doğrula.
Bu doğrulamalar bittikten sonra, anti-DDoS’un senin uygulama tipin için gerçekten “işe yaradığı” net biçimde ortaya çıkar.
Hosting karşılaştırması yapmaya hazır mısın?
100+ firmanın fiyatlarını tek tıkla karşılaştır, en uygun paketi bul.
Hosting Karşılaştır →İlgili Yazılar
Cloudflare alternatifi CDN: Ne zaman ne seçilmeli?
Cloudflare yerine alternatif CDN ne zaman mantıklı? Riskler, maliyet/performans kıyasları ve doğru seçim kontrol listesiyle karar verin.
DirectAdmin nedir? Kimlere uygun: VDS için kontrol panel rehberi
DirectAdmin; hafif, hızlı ve pratik bir kontrol panelidir. Özellikler, sınırlamalar ve kimlerin kullanması gerektiğini net şekilde öğrenin.
Hostinger vs Bluehost vs SiteGround: Başlangıç Hosting Rehberi
Hostinger, Bluehost ve SiteGround’un başlangıç WordPress/web hosting performansı, hız, güvenlik, destek ve maliyet farklarını net karşılaştırın.
Kendi Sunucuna cPanel Kurmak: Maliyet Analizi (2026)
Kendi sunucuna cPanel kurmanın gerçek maliyet kalemleri: lisans, donanım, işletim gideri, yedekleme ve bakım. Net hesaplama rehberi.