DDoS konuşurken en büyük yanılgı şu: “Bir cihaz/servis alırız, saldırıda açarız.” Üretimde gerçek tablo farklıdır. Saldırı anında çalışması gereken şey bir ürün değil; yönlendirme, tünel, kapasite, gözlem ve iletişim birleşimidir.
Scrubbing center tasarımının hedefi şudur:
- Trafiği saldırı altında bile servis uçlarına ulaştırmak
- Temizleme (mitigation) devreye girerken kırılma üretmemek
- Devreden çıkarken eski dengeye güvenli dönmek
Bu yazıda, kurumsal yapıda en pratik desenlerden birini ele alıyorum: BGP ile yönlendirme + GRE ile temizlenmiş trafiği geri taşıma.
1) Mimari: “Yönlendir, temizlet, geri taşı”
En sade model:
- Saldırı trafiği internetten edge’e gelir
- Edge, “bu prefix’i scrubbing’e ver” sinyali üretir (BGP)
- Scrubbing center trafiği temizler
- Temiz trafik GRE tünel üzerinden edge’e/servis VLAN’ına geri döner
Bu modelin artıları:
- Uygulama tarafına minimum dokunuş
- Trafiği “tek bir yerde” temizleme (merkezi kontrol)
- Runbook ile yönetilebilir bir devreye alma/çıkarma akışı
Eksileri:
- Tünel ve MTU yönetimi (parça parça kırılma riski)
- Asimetri ve dönüş yolunu yanlış kurma riski
- Scrubbing kapasitesi “görünmez tek nokta” hâline gelebilir
2) Tasarım kararları: Operasyonel sorularla başla
Scrubbing tasarımı, aşağıdaki sorular cevaplanmadan bitmiş sayılmaz:
- Hangi servisler scrubbing’e girecek? (tümü mü, kritik prefix’ler mi?)
- “Devreye alma” eşiği nedir? (pps/bps/latency/5xx?)
- Failover planı nedir? (scrubbing down → ne olacak?)
- En kritik ölçüm nedir? (temiz trafik ulaşıyor mu, yoksa sadece saldırıyı mı görüyoruz?)
3) GRE tünel tasarımı: Kırılma noktaları
3.1 MTU ve fragment riski
GRE overhead yüzünden efektif MTU düşer. Pratik öneri:
- Tünel uçlarında MTU’yu bilinçli ayarlayın (ör. 1476/1450 gibi, ortama göre)
- PMTUD kırılıyorsa “bazı istemciler çalışıyor bazıları çalışmıyor” semptomu çıkabilir
- UDP servislerde fragment daha görünmez kırılır; test edin
3.2 Asimetrik yol
En sık hata: inbound scrubbing’den geliyor ama outbound farklı yerden gidiyor (ve stateful cihazlar bunu sevmiyor).
Bu yüzden:
- State tutan güvenlik cihazları varsa (FW/IDS), dönüş yolunu önceden tasarlayın
- “Scrubbing devredeyken” state table davranışını ölçün
3.3 Tünel sayısı ve ölçek
Çok POP’lu yapılarda tek tünel “kolay” görünür ama risk taşır. Daha iyi yaklaşım:
- POP başına ayrı tünel veya en azından bölgesel tünel çiftleri
- Tek POP down olduğunda diğer POP’ların scrubbing kapasitesiyle boğulmaması
4) BGP sinyali: Ne ile yönlendireceksin?
Scrubbing’e trafik yönlendirme için iki yaygın yöntem:
- Upstream community (tercihen)
- Prefix announce değişimi (prepend/withdraw/route-map ile)
Community varsa, runbook çok daha temiz olur: saldırı anında “tek satır” ile diversion yapılır, geri dönüş de tek satırdır.
5) Runbook: Devreye alma (engage) / devreden çıkarma (disengage)
5.1 Engage (saldırı anı)
- Etkiyi doğrula: servis SLI’ları bozuldu mu? (timeout, 5xx, latency)
- Trafik tipini ayır: volumetrik mi, L7 mi, mixed mi?
- Scrubbing kapasite teyidi: mevcut pps/bps + headroom
- Divert uygula: community veya politika değişikliği
- Temiz trafik doğrulaması: edge’de ve servis VLAN’ında paket/flow gör
- İletişim: incident kanalında “mitigation aktif, doğrulama metrikleri” paylaş
5.2 Disengage (sakinleşme)
Disengage’i “saldırı bitti” diye değil, sinyal stabilize oldu diye yapın:
- 15–30 dk boyunca SLI stabil
- Scrubbing’de drop oranı normal seviyede
- Edge kapasitesi ve state tabloları normal
- Geri dönüş planı hazır (tekrar engage gerekirse hızlı)
6) Gözlem: Sadece saldırıyı değil, temiz trafiği ölç
Minimum dashboard:
- İnternetten gelen bps/pps
- Scrubbing’e giden bps/pps
- Scrubbing’den çıkan “clean” bps/pps
- Edge’de servis tarafına giren bps/pps (asıl gerçek)
- Servis SLI: latency/timeout/5xx
Scrubbing center tasarımında başarı; tünel kurmakla değil, engage/disengage disiplinini işletmekle gelir. Kurumlar saldırıyı her zaman engelleyemez; ama doğru tasarımla saldırı altında bile servis davranışını yönetilebilir hâle getirebilir.