DDoS saldırısının amacı içeri girmek değil, hizmeti durdurmaktır. Bu yüzden klasik güvenlik araçlarının çoğu DDoS karşısında yanlış yerde durur. Bu yazıda saldırıları hedefledikleri kaynağa göre sınıflandırıp, savunmanın hangi katmanda yapılması gerektiğine bakacağız.
Üç saldırı sınıfı
DDoS saldırılarını en kullanışlı şekilde neyi tükettiklerine göre ayırabiliriz.
1. Hacim saldırıları (L3/L4): bant genişliğini tüketmek
Amaç, hedefin internet bağlantısını trafikle doldurmak. Bağlantı dolduğunda arkadaki firewall’un ya da sunucunun ne kadar güçlü olduğunun önemi kalmaz; meşru trafik hattan geçemez.
- UDP flood: Rastgele portlara yoğun UDP trafiği.
- Yansıtma ve büyütme (reflection/amplification): Saldırgan, kaynak adresi hedefin IP’si olacak şekilde sahte istekleri internetteki açık servislere (DNS, NTP, memcached, CLDAP gibi) gönderir. Servisler cevabı hedefe yollar ve cevap, istekten çok daha büyüktür. Saldırgan küçük bir trafikle hedefe çok büyük bir hacim yönlendirir.
Bu sınıfın kritik noktası: kendi hattının üzerindeki trafiği kendi tarafında temizleyemezsin. Hat dolduysa savunma hattın öncesinde, yani yukarı akışta (upstream) yapılmalı.
2. Durum tüketme saldırıları (L4): tabloları doldurmak
Amaç bant genişliği değil, cihazların durum tablolarını doldurmak.
- SYN flood: Sahte kaynaklardan yoğun SYN gönderilir. SYN cookie ya da SYN proxy gibi bir koruma devrede değilse, hedef sunucu ve yoldaki stateful cihazlar her biri için yarı açık bağlantı kaydı tutar ve kaynaklar tükenir. Saldırı session tablosundan önce cihazın saniyede işleyebildiği paket sayısını da tüketebilir.
- ACK ve RST flood: Var olan bir bağlantıya aitmiş gibi görünen paketler. Stateful bir cihaz bu paketler için genellikle yeni session açmaz, düşürür. Ama her paketi tabloda aramak ve düşürmek yine işlemci yükü getirir; etkisi cihazın bu paketleri ne kadar verimli işlediğine bağlıdır.
- Bağlantı tüketme: Tam kurulmuş ama boşta bekletilen bağlantılarla bağlantı sınırlarını doldurmak.
Burada önemli bir gerçek ortaya çıkıyor: stateful firewall bu saldırılarda yalnızca koruyucu değil, hedef de olabilir. SYN koruması yoksa ya da saldırının boyutuna yetmiyorsa her yeni bağlantı girişimi session tablosunda yer tutar. Tablo dolunca firewall meşru bağlantıları da kabul edemez. Yani sunucuyu korumak için konan firewall, saldırıda ilk düşen cihaz olabilir.
Savunmanın araçları: SYN cookie ve SYN proxy (bağlantıyı doğrulamadan tabloya yazmamak), kaynak başına bağlantı sınırları ve bu işi session tablosu tutmadan yapabilen, önde duran özel DDoS cihazları.
3. Uygulama katmanı saldırıları (L7): sunucuyu yormak
Amaç, uygulamanın kendisini meşru görünen isteklerle yormak.
- HTTP flood: Çok sayıda kaynaktan geçerli görünen istekler. Özellikle pahalı işlemler hedeflenir: arama, rapor, giriş sayfası.
- Önbelleği atlatma: Her istekte farklı parametre kullanarak CDN önbelleğini işe yaramaz hale getirmek, isteklerin hepsini origin sunucuya düşürmek.
- Yavaş saldırılar (Slowloris benzeri): Bağlantıları çok yavaş göndererek açık tutmak ve sunucunun bağlantı havuzunu doldurmak.
Bu sınıfın zorluğu: trafik hacim olarak küçük olabilir ve tek tek istekler meşru görünür. Ayırt etmek için davranışa bakmak gerekir: istek oranı, oturum tutarlılığı, istemcinin tarayıcı gibi davranıp davranmadığı. Bu, WAF’ın ve bot yönetiminin alanıdır.
Saldırıyı ölçmek: Gbps tek başına yetmez
DDoS genelde bant genişliğiyle anılır, ama her saldırı farklı bir kapasiteyi tüketir. Geniş bir hat, küçük paketlerden oluşan bir saldırıda cihazın paket işleme sınırına yine takılabilir.
| Metrik | Neyi ölçer | Hangi kapasiteyi zorlar |
|---|---|---|
| Gbps | Trafik hacmi | İnternet hattı |
| Mpps | Saniyedeki paket sayısı | Router ve firewall’un paket işleme kapasitesi |
| CPS | Saniyedeki yeni bağlantı | Session oluşturma kapasitesi |
| Eşzamanlı session | Açık bağlantı sayısı | Session tablosu |
| RPS | Saniyedeki uygulama isteği | Web sunucusu ve API |
Cihaz seçerken ve kapasite planlarken bu beş metriğin her birine ayrı bakmak gerekir.
Savunma katmanları
DDoS savunması tek bir cihaz değil, katmanlı bir yapıdır. Her katman farklı bir sınıfı karşılar.
Yukarı akışta
- RTBH (Remotely Triggered Black Hole): Saldırı altındaki IP’ye giden trafiği ISS’in ağında düşürmek. Hattı kurtarır ama hedef IP ya da prefix için hizmet kaybı yaratır. Bu yüzden aynı hattı paylaşan diğer sistemleri korumak için bilinçli verilen, kontrollü bir savunma kararıdır.
- BGP FlowSpec: Yalnızca belirli trafik desenini (ör. belirli porta gelen UDP) yukarı akışta düşürmek. RTBH’den çok daha hassas ama ISS desteği gerektirir. Hassasiyetin bir bedeli de var: yanlış tanımlanmış bir filtre meşru trafiği de keser. Kurallar dağıtılmadan önce doğrulanmalı.
Scrubbing merkezi
Korunan prefix, saldırı anında ya da sürekli olarak temizleme sağlayıcısı tarafından BGP ile duyurulur ve trafik scrubbing merkezine çekilir. Temizlenen trafik GRE tüneli ya da doğrudan bağlantıyla kurumun ağına iletilir. Kapasitesi tek bir kurumun hattından kat kat büyük olduğu için hacim saldırılarına karşı en etkili yoldur. Her zaman açık (always-on) ve saldırı anında devreye alınan (on-demand) modelleri vardır.
CDN, WAF ve bot yönetimi
Web trafiği için ayrı bir katman: istekler bir ters proxy ağından geçer. CDN önbellekle origin’in yükünü azaltır, WAF ve bot yönetimi L7 saldırılarını davranışa göre ayıklar. Bu katman yalnızca proxy’lenen web trafiğini korur; aynı ağdaki VPN ya da e-posta gibi servisler için scrubbing gerekir.
Kritik bir ayrıntı: origin IP gizli kalmalı. Saldırgan sunucunun gerçek IP’sini bulursa CDN’i atlayıp doğrudan saldırır. Origin yalnızca CDN’in IP aralıklarından gelen trafiği kabul etmeli.
On-prem
Hat dolmadan önceki saldırılar (durum tüketme, düşük hacimli saldırılar) ve hızlı tepki için hattın girişinde, firewall’un önünde konumlanan özel cihazlar. Firewall’dan farkı, saldırı trafiğini session oluşturmadan analiz edip düşürebilmesidir.
Tespit: normali bilmeden anormali göremezsin
DDoS’u erken fark etmenin yolu, normal trafiğin profilini bilmektir. NetFlow/sFlow verisiyle trafik tabanı (baseline) çıkarılır: hangi saatte, hangi hedefe, hangi protokolde ne kadar trafik normal? Sapma eşiği aşıldığında alarm üretilir. Tespit ne kadar erkense yönlendirme ve müdahale kararı o kadar hızlı verilir.
Saldırıdan önce yapılması gerekenler
DDoS müdahalesi saldırı anında planlanmaz; o an yalnızca uygulanır.
- ISS ile konuş. RTBH ve FlowSpec desteği var mı? Saldırı anında kimi arayacaksın?
- Scrubbing/CDN hazır olsun. İsteğe bağlı (on-demand) koruma kullanıyorsan yönlendirmeyi önceden test et.
- Origin’i gizle. Gerçek IP’ler DNS kayıtlarında, e-posta başlıklarında ya da eski alt alan adlarında sızmasın.
- Tabanı çıkar. NetFlow/sFlow toplayıcı ve alarm eşikleri hazır olsun.
- Runbook yaz. Kim karar verir, hangi eşikte hangi adım atılır, iletişim kime yapılır?
- Kendi ağını yansıtıcı yapma. İnternete hizmet veren yetkili (authoritative) DNS sunucusunun herkese cevap vermesi normaldir; orada yanıt hız sınırlaması (RRL) gibi önlemler kullanılır. Asıl risk, recursive DNS çözümleyicinin yalnızca kendi istemcilerine değil herkese açık olmasıdır. NTP gibi servislerde de büyütmeye açık komutları kapat. Kaynak adres doğrulaması (BCP 38) yaparak kendi ağından sahte kaynaklı trafik çıkmasını engelle.
Örnek saha senaryosu: saldırı anında karar akışı
Gece 02:10’da NetFlow alarmı geliyor: kaynak portu UDP 123 olan trafik, web sunucusunun adresine normalin yirmi katı hızla akıyor ve hat kapasitesinin yüzde 40’ına ulaşmış. Bu bir NTP büyütme saldırısı. Hat henüz dolmadı; karar için zaman var.
- Tespit: Alarmı doğrula. Trafik gerçekten saldırı mı, yoksa planlı bir iş mi?
- Sınıflandır: Hangi sınıf? Burada hacim saldırısı; kaynak port ve protokol belli.
- Sağlayıcıyı bilgilendir: Runbook’taki ISS ya da scrubbing iletişim kanalını kullan. Hat dolmadan aramak, dolduktan sonra aramaktan çok daha kolaydır.
- Mitigation’ı devreye al: Desen netse FlowSpec kuralını dar tut: hedef adresi saldırı altındaki sunucuyla, protokolü UDP ve kaynak portu 123 ile sınırla. Bu sunucu saatini dışarıdaki NTP sunucularından alıyorsa, onun meşru NTP yanıtları da bu filtreye takılır. Bu durumda tamamen düşürmek yerine hız sınırlama (FlowSpec
traffic-rate) kullan ya da sunucuya iç NTP kaynağı ver. Hız sınırlamanın da bedeli var: sınırın altında kalan meşru yanıtlar da saldırı trafiğiyle aynı kuyruğa girer ve kaybolabilir. Ayrıca ISS’in FlowSpec’i ve hangi eylemleri (düşürme, hız sınırlama) desteklediği saldırıdan önce doğrulanmış olmalı. Hacim büyürse scrubbing yönlendirmesini başlat. RTBH son çaredir, çünkü hedef IP’nin hizmetini de keser. - Servisi doğrula: Meşru kullanıcılar siteye ulaşabiliyor mu? Sadece grafiğin düşmesine değil, hizmetin kendisine bak.
- Olay sonrası değerlendir: Hangi eşik ne kadar erken uyardı, hangi adım gecikti? Runbook’u buna göre güncelle.
Üretici yaklaşımları
- Huawei: AntiDDoS serisi, hat girişinde firewall’dan ayrı bir temizleme katmanı olarak konumlanır.
- Cisco: Hacim tespiti için NetFlow; RTBH ve FlowSpec gibi BGP tabanlı yöntemler router tarafında uygulanır (ör. IOS XR’da FlowSpec desteği).
- Fortinet: FortiDDoS ayrı bir DDoS cihaz ailesidir. FortiGate’teki DoS politikaları ise eşik tabanlıdır ve firewall’un kendisini korumaya yöneliktir; ayrı bir DDoS cihazının yerini tutmaz.
- Diğerleri: On-prem tarafta NETSCOUT Arbor, A10 Thunder TPS ve Radware; bulut tarafında Cloudflare ve Akamai gibi sağlayıcılar yaygındır.
Sonuç
DDoS’a karşı tek bir kutu yoktur. Hacim saldırıları yukarı akışta, durum tüketme saldırıları hattın girişinde, uygulama katmanı saldırıları uygulamanın önünde karşılanır. Firewall bu zincirin bir parçası olabilir: DoS politikaları, SYN koruması ve bağlantı sınırları işe yarar. Ama tek başına kapsamlı bir DDoS çözümü değildir; hat dolduğunda trafik firewall’a ulaşmadan temizlenmelidir. En iyi DDoS savunması da saldırıdan önce yazılmış bir runbook ve önceden test edilmiş bir yönlendirmedir.
Kaynaklar
- RFC 4987: TCP SYN Flooding Attacks and Common Mitigations
- RFC 2827 (BCP 38): Network Ingress Filtering
- RFC 5635: Remote Triggered Black Hole Filtering
- RFC 7999: BLACKHOLE Community
- RFC 8955: BGP Flow Specification
- NIST SP 800-81 Rev. 3: Secure Domain Name System (DNS) Deployment Guide
- Cloudflare: Allow Cloudflare IP Addresses (origin koruması)
- Huawei: AntiDDoS8000 DDoS Protection System
- Cisco: Configure BGP FlowSpec VRF to VRF Redirection (IOS XR)
- Fortinet: FortiDDoS-F Handbook
- Fortinet: FortiGate DoS Protection