DDoS saldırısı sırasında en pahalı kaynak zamandır. Kimi arayacağınızı, hangi community'yi kullanacağınızı ya da normal trafiğin neye benzediğini saldırı anında öğrenmeye çalışmak, kesintiyi dakikalardan saatlere uzatır. Bu yazı hazırlığı üç aşamaya ayırıyor: saldırıdan önce, saldırı sırasında ve sonrasında.
Saldırıdan önce
Trafik tabanını ölçün
"Anormal" demek için önce "normal"i bilmeniz gerekir. Kenar router'larınızda NetFlow, sFlow veya IPFIX'i açın ve bir toplayıcıya (pmacct, Akvorado, ntopng, ElastiFlow vb.) gönderin. En az birkaç hafta boyunca şunları kaydedin:
- Arayüz başına bps ve pps, gün ve hafta içi döngüleriyle
- Hedef IP başına en yüksek trafik alan ilk 20 adres
- Protokol dağılımı (TCP, UDP, ICMP) ve en sık kaynak portlar
- Yeni oturum sayısı (TCP SYN oranı)
pps değeri sık atlanır ama önemlidir. Küçük paketlerle yapılan saldırılar bant genişliğini doldurmadan router'ın ya da firewall'un paket işleme kapasitesini tüketebilir. Örneğin 64 baytlık paketlerle 10 Gbit/s hat yaklaşık 14,88 milyon pps demektir; bu, birçok yazılım tabanlı firewall'un sınırının çok üzerindedir.
Taban çizgisi oluştuktan sonra eşik tabanlı uyarılar tanımlayın. Basit bir başlangıç: bir hedef IP'ye giden trafik, son dört haftanın aynı saatteki medyanının 5 katını geçerse uyarı.
İletişim listesini hazırlayın
Saldırı başladığında aranacak herkesin adı, telefonu ve e-postası tek bir yerde olmalı ve bu yer saldırı altındaki altyapıya bağımlı olmamalı (çevrimdışı bir kopya veya farklı bir sağlayıcıdaki doküman). Listede en azından şunlar bulunsun:
- Her upstream sağlayıcının NOC'u ve DDoS ekibi (7/24 telefon numarası)
- Varsa DDoS temizleme (scrubbing) hizmeti sağlayıcınız
- İç ekipte karar yetkisi olan kişi (hangi servisin feda edilebileceğine kim karar veriyor?)
- Müşterilere durum bildirimi yapacak kişi
Netlojik tarafında bu adresler [email protected] ve [email protected]'dur; kendi sağlayıcılarınızın karşılıklarını da önceden doğrulayın.
RTBH hazırlığı
Remote Triggered Black Hole (RTBH), saldırı altındaki tek bir IP'yi upstream'in sınırında düşürmenizi sağlar. Hedef ulaşılamaz hale gelir, ama geri kalan her şey ayakta kalır. Çoğu sağlayıcı RFC 7999'da tanımlanan BLACKHOLE community'sini (65535:666) destekler; bazıları kendi community değerini kullanır.
Önceden yapılması gerekenler:
- Her upstream'in blackhole community'sini ve kabul ettiği en küçük prefix'i (genellikle IPv4'te
/32, IPv6'da/128) belgeleyin. - Dışa duyuru filtrenizin bu
/32'leri geçirdiğinden emin olun; normalde/24'ten spesifik prefix'leri reddeden filtre, blackhole community'li olanlara istisna tanımalı. - Bir test IP'si ile (örneğin
203.0.113.250/32) prosedürü sakin bir zamanda deneyin ve looking glass'lardan yayıldığını doğrulayın.
FRR ile tetikleyici statik rota örneği:
ip route 203.0.113.45/32 Null0 tag 666
!
route-map RTBH permit 10
match tag 666
set community 65535:666 additive
set local-preference 0
Flowspec hazırlığı
RTBH kaba bir araçtır: hedefi tamamen düşürür. BGP Flowspec (RFC 8955) ise "şu hedefe, UDP kaynak portu 123'ten gelen trafiği düşür" gibi daha ince kurallar dağıtmanızı sağlar. Hem kendi router'larınızda hem upstream'inizde desteklenip desteklenmediğini, kural sayısı limitlerini ve hangi eylemlere (drop, rate-limit) izin verildiğini önceden öğrenin. Flowspec'i sadece kendi ağınızda kullanabiliyorsanız bile, uplink doymadığı sürece bu değerli bir katmandır.
Saldırı anında
Sakin kalmayı kolaylaştıran şey, sırası önceden belli bir akıştır:
- Doğrulayın. Trafik artışı gerçek bir saldırı mı, yoksa meşru bir yoğunluk ya da yapılandırma hatası mı? Flow verisinden hedef IP, protokol ve kaynak port dağılımına bakın.
- Sınıflandırın. Hacimsel (UDP amplification: DNS, NTP, memcached, CLDAP), protokol (SYN flood, fragment) veya uygulama katmanı (HTTP flood) mı? Müdahale yöntemi buna göre değişir.
- Uplink doluyor mu? Doluyorsa kendi ağınızda yapacağınız filtreleme işe yaramaz; müdahale upstream'de veya scrubbing merkezinde olmalı.
- En dar müdahaleyi seçin. Önce Flowspec veya ACL ile belirli trafiği hedefleyin; olmazsa tek IP için RTBH; o da yetmezse trafiği scrubbing hizmetine yönlendirin.
- Kayıt tutun. Her adımı saat bilgisiyle bir yere yazın. Sonraki analizin temeli bu notlardır.
- İletişim kurun. Etkilenen müşterilere kısa, net bir durum bildirimi gönderin; tahmini süre vermek yerine bir sonraki güncelleme saatini söyleyin.
Amplification saldırılarında basit bir ilk adım, ilgili kaynak portundan gelen UDP'yi rate-limit etmektir. Örneğin NTP monlist yansıması için udp src port 123 ve paket boyutu 468 bayt civarı olan trafik iyi bir imzadır.
Saldırıdan sonra
Saldırı bittiğinde yapılacak iş bitmiş değildir:
- Blackhole'ları kaldırın. Unutulan bir RTBH rotası, hedefi günlerce erişilemez bırakabilir. Kaldırmayı da kontrol listesine yazın.
- Zaman çizelgesi çıkarın. Tespit ne kadar sürdü? İlk müdahale ne zaman yapıldı? Hangi adım gecikti ve neden?
- Veriyi saklayın. Flow kayıtlarını ve varsa pcap örneklerini arşivleyin. Tekrarlayan saldırılarda karşılaştırma için gerekir.
- Eşikleri güncelleyin. Uyarı geç geldiyse eşikler fazla gevşektir; yanlış alarm çoksa fazla sıkıdır.
- Sağlayıcılarla konuşun. Upstream'in müdahale süresi yeterli miydi? Flowspec veya ek community desteği mümkün mü?
Her saldırının sonunda kontrol listesinde en az bir şeyin değişmesi, sürecin işlediğinin iyi bir göstergesidir. Sürekli koruma katmanı düşünüyorsanız DDoS koruma sayfamızda nasıl çalıştığını anlattık.
Toparlarken
DDoS'a hazırlık, saldırıyı tamamen engellemekten çok müdahale süresini kısaltmakla ilgilidir. Normal trafiği bilen, kimi arayacağını ve hangi community'yi kullanacağını önceden test etmiş bir ekip, aynı saldırıyı çok daha kısa bir kesintiyle atlatır. Hazırlığın büyük kısmı sıkıcı işlerdir: ölçüm, belgeleme ve tatbikat.
