DDoS olaylarında en büyük hata, teknik çözümü “tek hamle” sanmaktır. Gerçekte iyi bir müdahale; karar ağacı, doğrulama ve geri dönüş adımlarının birlikte çalışmasıdır. RTBH (Remote Triggered Black Hole) ve BGP FlowSpec, doğru tasarlanırsa olay anında çok hızlı etki eder; yanlış tasarlanırsa da yanlış trafiği keserek ikinci bir incident üretir.
Bu yazı, ISP seviyesinde “büyük anlatı” yerine; kurumsal ağlarda ve edge katmanında sahada uygulanan pratik bir runbook yaklaşımını anlatır.
Ön şart: topoloji ve sorumluluk sınırı net olmalı
RTBH ve FlowSpec’i konuşmadan önce şu üç sorunun cevabı yazılı olmalı:
- BGP’yi kim konuşuyor? (Edge router mı, transit/peering cihazı mı, cloud router mı?)
- Kara delik nereye? (Null route cihaz içinde mi, scrubbing center mı, upstream blackhole mu?)
- Kim karar veriyor? (NOC, NetOps, SecOps, Incident Commander?)
Bu sorular net değilse, olay anında “komutu kim atacak?” tartışması süreyi öldürür.
Karar ağacı: RTBH mi, FlowSpec mi?
Sahada en pratik ayrım şu:
- Hedef servis tamamen batıyorsa ve “kapat daha iyi” noktasına geldiyse → RTBH
- Trafiğin bir kısmı kötü ve filtreyle ayıklanabiliyorsa → FlowSpec
Bu karar için hızlı metrikler:
| Sinyal | RTBH lehine | FlowSpec lehine |
|---|---|---|
| L7 tamamen çökük | Evet | Hayır |
| Saldırı tek hedef IP | Evet | Evet |
| Saldırı belirli port/proto | Kısmen | Evet |
| Yanlış pozitif riski | Düşük | Orta/Yüksek |
| Uygulama toleransı | “Kapat” kabul | “Devam” hedef |
RTBH: minimum güvenli uygulama şablonu
RTBH’de amaç, hedef prefix’e özel bir route’u “blackhole next-hop” ile yayıp trafiği upstream’de düşürmektir. Üç kontrol öneriyorum:
- Sadece belirli community ile tetikle
- Sadece belirli prefix boyutlarını kabul et (/32 gibi dar hedefler)
- TTL (süre) gibi operasyonel geri dönüş standardı koy
Doğrulama adımları
RTBH sonrası doğrulama, sadece “trafik düştü” değil:
- Edge router’da ilgili prefix’in blackhole’a gittiğini doğrula
- Upstream/IX tarafında route’un yayıldığını doğrula (varsa looking glass)
- Hedef serviste CPU/conntrack/interrupt baskısının gerçekten düştüğünü ölç
- Monitoring’de alarm fırtınasını “beklenen” hale getir (susturma değil, etiketleme)
FlowSpec: cerrahi filtreleme, cerrahi risk
FlowSpec çok güçlüdür çünkü “port/proto/flags” gibi alanlara göre filtre yazarsın. Ama risk şudur: yanlış kural yazarsan üretim trafiğini de kesersin.
Sahadaki iki güvenli kullanım biçimi:
- Rate-limit (drop yerine “yavaşlat”)
- Sadece dar bir eşleşme (tek hedef IP + tek port + kısa süre)
Doğrulama adımları
FlowSpec uyguladıktan sonra aşağıdaki iki metriği birlikte izle:
- Hizmet metrikleri: hata oranı, latency, saturasyon
- Ağ metrikleri: PPS/BPS düşüşü, drop counters, policer counters
Sadece ağ metriği düşüp hizmet metriği düzelmiyorsa, yanlış yerde müdahale ediyorsun demektir (ör. L7 saldırı, application layer).
Operasyonel runbook: adım adım
Olay anında “kimin ne yapacağı” kısa ve net olmalı:
- Triage (5 dk): saldırı vektörü, hedef(ler), etkilenme (SLO), karar (RTBH/FlowSpec/diğer)
- Change kaydı (2 dk): kim, ne zaman, hangi kural/prefix, hedef süre
- Uygulama (1–3 dk): kural/prefix push
- Doğrulama (5 dk): hizmet + ağ metrikleri
- Geri dönüş (planlı): süre dolunca kaldır, postmortem için delil topla
Postmortem: DDoS sonrası gerçek iyileştirme listesi
RTBH/FlowSpec başarılı olsa bile olaydan sonra yapılacaklar çok nettir:
- Edge kapasitesi: PPS/BPS, conntrack, interrupt tuning
- Uygulama dayanıklılığı: caching, queue, circuit breaker
- Gözlemlenebilirlik: netflow/sflow, WAF log’ları, upstream telemetry
- Proses: kural şablonları, on-call yetki matrisi, tatbikat
Sonuç
RTBH ve FlowSpec, doğru tasarlandığında DDoS olaylarında zaman kazandırır; yanlış tasarlandığında ise üretim trafiğine zarar verir. Bu yüzden teknik komutlar kadar, karar ağacı ve geri dönüş standardı da runbook’un parçası olmalıdır. Operasyonel liderlik tarafında en büyük kazanım, panik anında “hangi aracı seçelim?” sorusunu değil, “hangi koşulda hangi aracı devreye alırız?” kararını önceden vermektir.