DDoS Korumalı Sunucu Seçerken Nelere Bakılmalı? Rehber

DDoS korumalı sunucu seçerken en önemli ölçüt, tanıtımda yazan kapasite rakamı değil, filtrenin meşru trafiği bozmadan saldırıyı ne kadar doğru ayıkladığıdır. Doğru seçim için korumanın hangi katmanları (L3/L4/L7) kapsadığına, her zaman açık (always-on) çalışıp çalışmadığına, sunucunuzun iş yüküne uygun olup olmadığına bakın ve satın almadan önce kendi trafiğinizle ölçün.

Neden "Gbps" rakamı tek başına yanıltıcıdır?

Kapasite rakamı, bir ağın hattı doldurmadan ne kadar trafiği taşıyabileceğini anlatır. Önemli ama yetersiz bir bilgidir. Gerçek hayatta şu senaryolar sık görülür:

• Saldırı hacmi küçüktür ama uygulamaya özel hazırlanmıştır (ör. oyun sunucunuzun sorgu paketini taklit eden UDP trafiği). Genel amaçlı filtre bunu "normal" sayıp geçirir.
• Filtre agresif ayarlıdır. Saldırı durur ama gerçek oyuncular veya müşteriler de düşer (false positive).
• Koruma devreye girmesi için dakikalar sürer. O sürede servis zaten kesilmiştir.

Bu yüzden sorulması gereken soru "kaç Gbps?" değil; "hangi trafiği, nasıl ayırt ediyorsunuz, yanlış engellemeyi nasıl yönetiyorsunuz?" olmalıdır. Sağlayıcıdan bunun yanıtını teknik düzeyde alamıyorsanız bu başlı başına bir işarettir.

L3, L4 ve L7 koruma: Ne farkı var?

DDoS saldırıları OSI katmanına göre farklı davranır ve farklı savunma gerektirir.

Önemli nokta şudur: Birçok "DDoS korumalı sunucu" teklifi aslında yalnızca L3/L4 kapsar. Şifreli HTTPS trafiği üzerinden gelen L7 saldırısını ağ katmanında ayırt etmek zordur; bunun için TLS'i sonlandıran bir katman veya uygulama tarafında ek önlem gerekir. Sağlayıcıya şunu açıkça sorun: "L7 koruma dahil mi, yoksa ayrı bir ürün mü? Hangi trafikte devreye giriyor?"

Always-on mı, on-demand mı?

• Always-on: Trafik sürekli filtre altından geçer. Saldırı başladığında devreye girme gecikmesi yoktur; ama filtre her zaman yolda olduğu için gecikmeye ve yanlış pozitife dikkat etmek gerekir.
• On-demand (tespit sonrası devreye giren): Normal zamanda trafik doğrudan akar, saldırı algılanınca yönlendirme yapılır. Gecikme düşük kalır, fakat tespit ve yönlendirme süresi boyunca kesinti yaşanabilir.

Kısa süreli kesintinin bile kabul edilemediği oyun sunucuları ve ödeme/e-ticaret altyapıları için genellikle always-on mantığı daha güvenlidir. Hangisini seçerseniz seçin, tespit süresi, devreye giriş süresi ve otomasyon düzeyini yazılı olarak sorun.

Oyun sunucusu ile web sunucusu aynı korumayı istemez

Oyun sunucuları

• Trafik ağırlıklı olarak UDP'dir ve protokol özeldir (Source query, oyun içi paketler, Minecraft'ta TCP+UDP karışımı vb.).
• Gecikme ve jitter hassasiyeti yüksektir. Saldırı sırasında bile ek 10-20 ms fark oyuncu şikâyetine dönüşebilir.
• Filtrenin oyuna özgü paket formatlarını tanıyıp tanımadığı kritik. Genel bir "UDP'yi sınırla" kuralı gerçek oyuncuları da keser.
• Rota kalitesi önemlidir: Oyuncularınız Türkiye'deyse Türkiye lokasyonlu ve yerel bağlantısı iyi bir ağ, filtreleme kadar önemlidir.

Web sunucuları

• Trafik TCP/HTTP(S) ağırlıklıdır; L7 koruma ön plandadır.
• Gerçek istemci IP'sini uygulamaya doğru aktarmak gerekir; aksi halde loglarda ve hız sınırlamada tüm trafik tek IP gibi görünür.
• Statik içerik için önbellekleme, dinamik uç noktalar (login, arama, API) için ayrı hız sınırı çok işe yarar.
• Sunucunun gerçek IP'sinin gizli kalması ve yalnızca koruma katmanından gelen trafiğe açık olması gerekir (aşağıda).

Satın almadan önce sağlayıcıya sorulacak kontrol listesi

1. L3, L4 ve L7 kapsamı ayrı ayrı nedir?
2. Always-on mu, tespit sonrası mı devreye giriyor?
3. Yanlış pozitif olursa nasıl müdahale ediliyor? Kendi kuralımı (port, protokol, izinli IP) ekleyebiliyor muyum?
4. Saldırı sırasında ve sonrasında trafik grafikleri/logları görebiliyor muyum?
5. Kendi ASN'im ve IP bloğum varsa BGP ile korumalı anons seçeneği var mı?
6. Ağın rota yapısı ve çıkış noktaları görünür mü (ör. herkese açık looking glass)?
7. Destek ekibine saldırı anında ulaşabiliyor muyum?

Nixcon tarafında kendi ağımız (AS40368) üzerinden İzmir, Frankfurt ve Fremont noktalarını kullanıyoruz; rota ve gecikmeyi lg.nixcon.com.tr adresindeki herkese açık looking glass ile kendiniz de sorgulayabilirsiniz. Sağlayıcınızda benzer şeffaflık arayın.

Korumayı test etme: Güvenli ve işe yarar yöntemler

Önemli uyarı: Başkasına ait veya izin almadığınız bir hedefe asla yük/saldırı testi yapmayın. Kendi sunucunuzda dahi, gerçek yük testi için önce sağlayıcınızla yazılı olarak anlaşın; aksi halde hesabınız askıya alınabilir. İzinsiz test yapmadan da değerli bilgi toplayabilirsiniz.

1. Taban çizgisini ölçün

Koruma açıkken normal koşullardaki gecikme ve yol bilgisini kaydedin:

# Rota ve paket kaybı (192.0.2.10 örnek adrestir)
mtr -rwzbc 100 192.0.2.10

# HTTP zamanlamaları
curl -o /dev/null -s -w "connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://example.com/

Bu değerleri günün farklı saatlerinde ve farklı lokasyonlardan tekrarlayın. Koruma katmanı eklenince bu değerler belirgin kötüleşiyorsa, saldırı hiç gelmeden bile bir bedel ödüyorsunuz demektir.

2. Oyun/UDP servisleri için düşük hızlı sondalama

Yük oluşturmayan, makul hızda bir UDP probu ile filtrenin meşru paketleri geçirip geçirmediğini görebilirsiniz:

# Düşük hızda UDP paketi (örnek port 27015, düşük pps)
nping --udp -p 27015 --data-length 32 --rate 20 -c 200 192.0.2.10

Sunucu tarafında tcpdump -ni eth0 udp port 27015 ile paketlerin ulaşıp ulaşmadığını karşılaştırın. Gerçek oyuncu istemcisiyle bağlantı denemek, sentetik testten daha anlamlıdır.

3. Sunucu tarafında SYN ve kuyruk sayaçlarını izleyin

Koruma katmanı arkasında sunucuya hâlâ bozuk/fazla TCP trafiği ulaşıyor mu, bakın:

ss -s
nstat -az | grep -E 'Syncookies|ListenDrops|ListenOverflows'
sysctl net.ipv4.tcp_syncookies

ListenOverflows ve ListenDrops sayaçları artıyorsa, bu uygulamanızın veya sunucunuzun kuyruğunun yetmediğinin göstergesidir; filtreleme ile birlikte somaxconn ve uygulama backlog değerlerini gözden geçirin.

4. Web için gerçek IP ve kaynak kilidi

Proxy tabanlı bir L7 koruma kullanıyorsanız, Nginx'te gerçek istemci IP'sini geri almak için (adresler örnektir, sağlayıcınızın yayınladığı aralıkları kullanın):

set_real_ip_from 203.0.113.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Ayrıca sunucunuzun doğrudan IP üzerinden saldırıya açık kalmaması için 443'ü yalnızca koruma katmanından gelen aralığa açın:

iptables -A INPUT -p tcp --dport 443 -s 198.51.100.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

Kurallarınızı uygulamadan önce kendi SSH bağlantınızı kilitlememek için ayrı bir izin kuralı eklemeyi unutmayın.

Sık yapılan hatalar ve çözümleri

• Hata: Sadece kapasite rakamına göre seçmek. Çözüm: Katman kapsamı, yanlış pozitif yönetimi ve tespit süresini sorun.
• Hata: Gerçek sunucu IP'sinin açık kalması (DNS geçmişi, mail başlıkları, alt alan adları). Çözüm: IP'yi değiştirin, gelen trafiği yalnızca koruma katmanına açın, mail gönderimini ayrı IP'den yapın.
• Hata: Oyun sunucusunda genel UDP hız sınırı koymak. Çözüm: Port ve protokol bazlı, oyun paket yapısına uygun kurallar kullanın; kendi izin listenizi yönetebilin.
• Hata: Loglardaki tüm isteklerin aynı IP'den gelmesi. Çözüm: real_ip veya PROXY protocol ile gerçek istemci IP'sini aktarın.
• Hata: Korumayı hiç test etmeden saldırı gününü beklemek. Çözüm: Taban ölçümünü şimdiden alın, sağlayıcıyla planlı ve izinli test yapın.
• Hata: Saldırıyı sadece "kesildi mi, kesilmedi mi" diye izlemek. Çözüm: Akış (flow) tabanlı izleme ile trafiğin kaynağını, protokolünü ve zamanını görün.

Kendi ASN'iniz varsa farklı bir seçenek

Kendi ASN'i ve IP bloğu olan ağlar için koruma, sunucu bazlı değil IP bloğu bazlı da kurgulanabilir: Trafik GRE tüneli içinde kurulan BGP oturumuyla temizlenip size ulaştırılır. Nixcon'da bu yapı NixGuard Edge / BGP tünel olarak sunuluyor. Sunucu veya VDS tarafında ise BGP oturumuyla DDoS korumalı ya da korumasız anons seçeneklerini kullanabilirsiniz. Ayrıntılar için DDoS koruma ve firewall sayfamıza göz atabilirsiniz.

Koruma kadar görünürlük de önemlidir. Saldırının ne zaman başladığını, hangi protokol ve kaynaklardan geldiğini bilmeden doğru kural yazamazsınız. Flow tabanlı izleme ve DDoS tespiti için NixMon gibi bir araç, koruma katmanıyla birlikte düşünülmelidir.

Özet

1. Gbps rakamına değil filtre kalitesine, yanlış pozitif yönetimine ve tespit süresine bakın.
2. L3, L4 ve L7 kapsamını ayrı ayrı doğrulayın; HTTPS saldırıları için uygulama katmanı çözümü olduğundan emin olun.
3. Kesintiye toleransınız düşükse always-on mantığını tercih edin.
4. Oyun için UDP/protokol farkındalığı ve düşük gecikme, web için L7 koruma ve gerçek IP yönetimi öne çıkar.
5. Satın almadan önce taban ölçümü alın, izinli ve kontrollü testlerle doğrulayın.