DDoS: L3/L4/L7 saldırı tipleri ve mitigation katmanları

Hacim, durum tüketme ve uygulama katmanı saldırıları; firewall'un neden tek başına DDoS çözümü olmadığı ve ISS'ten origin'e kadar katmanlı savunma.

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.
Saldırgan açık DNS açık NTP memcached Hedef 203.0.113.10 ince ok: küçük istek, kaynak adresi hedefin IP'si olarak sahtelenmiş kalın ok: istekten kat kat büyük cevap, hedefe gider
Saldırgan hedefle hiç doğrudan konuşmaz. Sahte kaynak adresi yüzünden cevaplar hedefe gider ve her cevap istekten büyük olduğu için küçük bir trafik büyük bir hacme dönüşür. IP adresi örnektir.

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.

meşrusaldırı ISS / transit Scrubbing merkezi CDN / WAF / bot On-prem DDoS cihazı Firewall Origin sunucu RTBH, BGP FlowSpec hacim ve durum tüketme yalnızca web trafiği, L7 session tutmadan analiz DoS politikası, SYN koruması yalnızca CDN IP'lerine açık KURUMUN İNTERNET HATTI hat dolarsa alttakiler yetmez
Saldırı trafiği her katmanda incelir, meşru trafik hepsinden geçer. Kesikli çizginin üstündeki katmanlar kurumun hattına ulaşmadan çalışır; hacim saldırıları ancak orada durdurulabilir. Firewall bu zincirin bir halkasıdır, tamamı değil.

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.

  1. ISS ile konuş. RTBH ve FlowSpec desteği var mı? Saldırı anında kimi arayacaksın?
  2. Scrubbing/CDN hazır olsun. İsteğe bağlı (on-demand) koruma kullanıyorsan yönlendirmeyi önceden test et.
  3. 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.
  4. Tabanı çıkar. NetFlow/sFlow toplayıcı ve alarm eşikleri hazır olsun.
  5. Runbook yaz. Kim karar verir, hangi eşikte hangi adım atılır, iletişim kime yapılır?
  6. 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.

  1. Tespit: Alarmı doğrula. Trafik gerçekten saldırı mı, yoksa planlı bir iş mi?
  2. Sınıflandır: Hangi sınıf? Burada hacim saldırısı; kaynak port ve protokol belli.
  3. 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.
  4. 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.
  5. Servisi doğrula: Meşru kullanıcılar siteye ulaşabiliyor mu? Sadece grafiğin düşmesine değil, hizmetin kendisine bak.
  6. 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

#ddos#mitigation#bgp#netflow#waf

Kemal Keleş

Network & Security Engineer · CCNA · HCSA · NSE 3

Switching, routing, firewall ve kampüs ağlarında presales ve saha deneyimimi, teknik araştırmalarımı ve üretici dokümantasyonlarını bir araya getirerek pratik, üreticiden bağımsız içerikler hazırlıyorum.

Aynı konudan