Halı Bombardımanı DDoS Saldırıları: Tespit, FlowSpec ve Test Tasarımı

DDoS tespitinin büyük bölümü, nadiren yüksek sesle söylenen bir varsayımın etrafında tasarlanmıştır: saldırının bir hedefi vardır ve o hedef bir sunucudur. Sayaçlar hedef adres başına tutulur, temel çizgiler hedef adres başına öğrenilir, uyarılar bir hedef adres adına üretilir ve azaltma bir hedef adrese uygulanır. Halı bombardımanı (carpet bombing), bu varsayımı söken saldırı biçimidir. Üstelik bunu yeni bir vektöre, yeni bir amplifikasyon kaynağına veya olağandışı bir hacme hiç ihtiyaç duymadan yapar.

Bu makale mekanizmayla ilgilidir. Saldırının bir tespit hattına fiilen ne yaptığı, saldırıyı görüp görmeyeceğinizi neden örnekleme oranının değil toplama düzeyinin belirlediği, işletmecilerin ilk uzandığı yönlendirme aracının neden mümkün olan en kötü cevap olduğu ve bir üreticinin “evet, halı bombardımanını karşılıyoruz” cümlesinin anlam kazanması için deneme kurulumunun neleri içermesi gerektiği burada ele alınıyor.

Halı bombardımanı tam olarak nedir

Saldırgan yönlendirilen bir prefix seçer. Bu bir /24, bir /22 ya da bir barındırma sağlayıcısının tahsisi olabilir. Trafiği bu bloğun içindeki adreslere dağıtır: ya bloğun tamamına ya da zaman içinde dönen bir alt kümesine. Vektörler sıradandır: bloğa yönelen yansıtma ve amplifikasyon, yaygın portlara SYN selleri, parçalanmış trafik, karışık protokoller. Tek bir paketin içinde olağandışı hiçbir şey yoktur. Tek bir adrese ulaşan hızda da olağandışı hiçbir şey yoktur. Olağandışı olan yalnızca dağılımdır ve mesele de zaten dağılımdır. Teknik, enerjinin tek noktada yoğunlaşmak yerine adres alanına yayılması sebebiyle yayılı spektrum benzetmesiyle de anılır.

Bundan iki sonuç doğar ve ikisi ters yönlerde ilerler.

Birincisi, hedef başına sinyalin kaybolmasıdır. Her adresi ayrı ayrı izleyen bir tespit motoru orta seviyede, dikkat çekmeyen bir trafik görür. Hiçbir tetik aşılmaz. Dolayısıyla hiçbir alarm üretilmez, hiçbir devretme başlamaz ve hiçbir azaltma devreye girmez.

İkincisi, hasarın tümüyle paylaşılan kaynaklara binmesidir: erişim hattı, sınır yönlendiricinin iletim ve kontrol düzlemi, durum tutan sınırın oturum tablosu, azaltma cihazının kendi izleme tabloları ve bunların hepsinin arkasındaki olay hattı. Bunlar tam olarak, hiç kimsenin hedef başına eşik tutmadığı kaynaklardır, çünkü bu kaynaklar için hedef başına eşik zaten anlamsızdır.

Aşağıdaki hesap yalnızca çarpma işleminin nasıl çalıştığını göstermek içindir ve gerçek saldırılara ilişkin hiçbir iddia taşımaz. Bir /22 bloğu 1.024 adres içerir. Her adres bir miktar trafik alsın, hiçbir barındırma sağlayıcısının anormal saymayacağı kadar mütevazı bir miktar. Sınıra ulaşan toplam, o mütevazı miktarın bin katıdır. Adres başına hızı yarıya indirip blok büyüklüğünü ikiye katladığınızda toplam değişmez, hedef başına rakam ise daha da sıradanlaşır. Saldırganın elinde serbest bir parametre vardır ve tespit motorunuzun izlediği büyüklük tam olarak o parametredir.

İşletim açısından önemli bir ayrıntı daha var. Saldırganın bloğun içinde hangi adreslerin canlı olduğunu bilmesine gerek yoktur. Bütün prefix’i taramak hem daha basittir hem de aynı işi görür, çünkü kapsayıcı prefix’i duyuran taraf sizin yönlendiricinizdir. Yukarı akış sağlayıcınız o prefix’in içindeki her adres için gelen trafiği size teslim eder, arkasında hiçbir sunucu bulunmayan adresler dahil. Bu trafik, hiçbir yere gitmediğine karar verilmeden önce erişim hattınızı geçmiş ve sınırınıza ulaşmış olur. Karanlık adresler size bant genişliği ve iletim kapasitesi olarak tam olarak canlı adresler kadar pahalıya mal olur.

Hedef başına eşikler neden ince ayarla düzeltilemez

İçgüdüsel tepki eşikleri düşürmektir. İşe yaramaz ve neden yaramadığını tam olarak anlamak, sonrasında gelen her şeyin gerekçesidir.

Eşik tabanlı tespit, hedef adres başına bir sayaç tutar ve hız yapılandırılmış bir değeri ya da öğrenilmiş bir temel çizgiyi aştığında olay üretir. Saldırganın hedef başına hızı ise serbest bir parametredir. Seçtiğiniz her tetik değeri için trafik o değerin altında gönderilebilir ve eksik kalan miktar daha fazla adres kullanılarak telafi edilebilir. Hem bunu yakalayan hem de üretim ortamıyla temasa dayanan bir değer yoktur, çünkü bilinçli olarak alçakta duran trafiği yakalamak için tetiği meşru sunucuların normal dalgalanmasının altına koymanız gerekir. Yedekleme pencerelerinin, içerik yayınlarının, çoğaltma işlerinin, yoğun çalışan bir sanal sunucunun ve bir müşterinin kendi yük testinin altına. Tespit motoru kesintisiz alarm üretmeye başlar.

Barındırma ve servis sağlayıcı bloklarında durumu ağırlaştıran ikinci bir dinamik vardır. Böyle bir bloktaki adreslerin çoğu zamanın çoğunda boştadır veya çok az kullanılır; dolayısıyla öğrenilmiş temel çizgileri hem çok düşük hem de istatistiksel olarak gürültülüdür. Herhangi bir trafik, oransal olarak büyük bir sapma gibi görünür. İşletmeciler beklenen tepkiyi verir: konsolun anlamsız olaylarla dolmasını engellemek için altında hiçbir alarm üretilmeyen mutlak bir taban koyarlar. O taban, saldırganla yapılmış yayımlanmış bir sözleşmedir. Görünmez olması garanti edilen adres başına hızı tanımlar ve saldırı, o tabanın altındaki boşlukta yaşar.

Yani sorun eşiklerin yanlış ayarlanmış olması değildir. Tespit motoru, saldırı altında olmayan bir büyüklüğü ölçmektedir. Saldırı altındaki büyüklük toplamdır.

Yapısal cevap toplamadır, ama hangi düzeyde

Cevap, trafiğin size fiilen zarar verebildiği her toplama düzeyinde sayaç ve temel çizgi tutmak ve tespiti bunların hepsinde eşzamanlı çalıştırmaktır: sunucu, /24 veya muadili alt blok, yönlendirilen prefix, müşteri tahsisi ve fiziksel arayüz ya da hattın kendisi. Birinci düzeyde görünmez olan bir halı bombardımanı üçüncü düzeyde apaçıktır, çünkü üçüncü düzeydeki sayaç hattın ölçtüğü şeyin aynısını ölçmektedir.

Bunu söylemek kolaydır ve kurulumların çoğunun fiilen başarısız olduğu yer de burasıdır; çünkü toplama hiyerarşisi bir yapılandırma kararıdır ve genellikle bir kez, erken bir aşamada, ağı önemli servislerin listesi olarak modelleyen biri tarafından verilir. Bir tespit motorunun bildiği en küçük ve en büyük nesne tek tek sanal sunucularsa, prefix sayılabilir bir nesne olarak var değildir ve hiçbir ürün yeteneği bunu telafi etmez.

Hiyerarşiyi süs olmaktan çıkarıp işe yarar hâle getiren iki tasarım kuralı vardır.

Müdahale edebildiğiniz düzeyde tespit edin. Dışarıdaki prefix uzunluğu filtreleri sebebiyle kendi otonom sisteminizin dışına devredebileceğiniz en küçük birim bir /24 ise, /32 düzeyinde kusursuz tespit yapmak size uygulayabileceğiniz hiçbir şey kazandırmaz. Tersine, müdahale aracınız hedef prefix’i eşleşmesinin parçası olarak alan bir FlowSpec kuralıysa, prefix düzeyindeki tespit doğrudan prefix düzeyindeki müdahaleye karşılık gelir ve ikisi baskı altında hizada kalır.

Adres sınırının yanı sıra kiracı sınırını da izleyin. Çok kiracılı bir işletmecide bir /22 iki yüz müşteri taşıyor olabilir. Prefix düzeyindeki bir alarm doğrudur ve gereklidir, ama hepsini aynı anda adlandırır. Hiyerarşinin hem baskı altındaki toplamı hem de o toplamın içinde duran kiracıları ifade edebilmesi gerekir. Aksi hâlde alarm üzerine iş yapılamaz ve olay sonrası raporlama kullanılamaz hâle gelir.

Telemetrinin taşıyabildiği ve taşıyamadığı sinyal

Tespiti trafik yolunun dışında çalıştıran herkes için sıradaki soru, tespit motorunu besleyen telemetrinin sinyali taşımaya elverişli olup olmadığıdır. Burada birbirine sık karıştırılan üç ayrı etki vardır.

Dışa aktarma gecikmesi. NetFlow ve IPFIX, akışları yönlendirici üzerindeki bir önbellekte biriktirir ve kaydı akış bittiğinde ya da etkin akış zaman aşımı dolduğunda dışarı gönderir. Sürekli bir saldırının toplayıcınızda ne kadar hızlı görünebileceğinin alt sınırını bu zaman aşımı belirler, örnekleme oranı değil. Kısaltmak dışa aktarma hacmini ve kontrol düzlemi yükünü artırır. sFlow’da böyle bir bekleme yoktur, çünkü paket örneklerini aldıkça gönderir. Ama ulaşan şey bir akış kaydı değil bir paket örneğidir ve akışa benzer her görünüm toplayıcıda yeniden kurulmak zorundadır.

Örnekleme ve sanıldığından neden daha az önemli olduğu, tabii toplama yapıyorsanız. Kesin konuşulması gereken kısım budur. Paket örneklemesi küçük kutuların doğruluğunu büyük kutulara göre çok daha fazla bozar, çünkü bir kutuya düşen örnek sayısı, o kutudaki trafikle orantılıdır. Halı bombardımanı senaryosunda tek bir hedef adresi tutan bir kutu, işe yarar bir pencere içinde ya çok az örnek toplar ya da hiç toplamaz. Oradan kurulan her hedef başına tahmin istatistiksel olarak değersizdir. Bütün prefix’i tutan bir kutu ise bu hedeflerin hepsinden örnek toplar ve gayet kullanılabilir bir toplam tahmini üretir. Aynı telemetri beslemesi aynı anda hem işe yaramaz hem de yeterlidir. Hangisi olduğunu tümüyle nasıl topladığınız belirler. Bu saldırıyı yol dışından tespit etmek konusunda anlaşılması gereken en yararlı şey budur: görüyü belirleyen toplama tercihidir, örnekleme oranı değil.

Akış çeşitliliği. Halı bombardımanı olağandışı sayıda farklı akış anahtarı üretir: çok kaynak, çok hedef ve çoğu zaman rastgeleleştirilmiş portlar. Yönlendiricilerdeki akış önbellekleri sonludur, toplayıcıların alım yolları da öyle. Platformun normalde gördüğünden çok daha fazla eşzamanlı akış anahtarı üreten bir iş yükü her ikisine de baskı yapar ve baskı altındaki davranış platforma özgüdür; kendi hat kartlarınız için bunu önceden bilmekte fayda vardır. Rahatsız edici sonuç şudur: bu saldırı biçimi, kendisini tespit etmek için dayandığınız telemetrinin kalitesini bozar. Bu da akış başına muhasebenin sağlam kalmasına bağlı olmayan toplam sayaçları tutmak için ayrı bir gerekçedir.

Buraya ait bir etki daha var. Tespit motorları hızları bir gözlem penceresi üzerinden hesaplar. Saldırgan etkin hedef alt kümesini bu pencereden daha hızlı döndürürse, hiçbir hedef başına sayaç anlamlı bir birikime ulaşamaz. Prefix düzeyindeki sayaç ise bundan hiç etkilenmez, çünkü trafik aynı toplamın satırları arasında yer değiştirmiş olur. Dönen bir halı bombardımanı, hedef başına saymanın yanlış ölçü aleti olduğunun en temiz gösterimidir.

Farklı hedef sayısı birinci sınıf bir sinyaldir

Toplam hacim bariz sinyaldir. Bu saldırı biçimine daha özgü ve kazara taklit edilmesi çok daha zor olan ikinci bir sinyal vardır: bir pencere içinde bir prefix’in içinde trafik alan farklı hedef adres sayısı ve trafiğin bu adresler arasındaki dağılımının biçimi.

Bir servis sağlayıcı bloğuna gelen normal trafik ağır biçimde çarpıktır. Adreslerin azınlığı trafiğin çoğunu taşır, etkin adres kümesi pencereden pencereye oldukça kararlıdır ve arkasında hiçbir şey olmayan adresler sıfıra yakın trafik alır. Halı bombardımanı bu dağılımı hem düzleştirir hem de genişletir: etkin hedef sayısı keskin biçimde yükselir, çarpıklık çöker ve daha önce karanlık olan adreslerde trafik belirir.

Karanlık adreslere giden trafik ayrıca ele alınmayı hak eder, çünkü elde bulunan en temiz sinyaldir. Tartışılacak meşru bir temel çizgi yoktur ve üzerinde hiçbir servis çalışmayan bir adrese doğru sürekli bir hızın makul bir iş gerekçesi bulunmaz. Korunan bir bloğun içinde hangi adreslerin fiilen kullanımda olduğunu bilen bir tespit motoru, geri kalanına yönelen trafikteki artışı neredeyse tartışmasız bir işaret olarak değerlendirebilir. Üstelik bunu, hıza dayalı herhangi bir kuralın ihtiyaç duyacağı hacmin çok altında yapar.

Bir ürün değerlendirmesi için buradan iki soru çıkar. Sistem, prefix başına ve pencere başına farklı hedef sayısını hesaplıyor mu ve bunun üzerinden hacimden bağımsız alarm üretebiliyor mu? Ve bir bloğun içinde hangi adreslerin hizmette olduğu kendisine söylenebiliyor mu ki geri kalanına giden trafiği farklı ele alsın?

RTBH neden burada yanlış araçtır

RFC 5635’te tarif edilen kara delik yönlendirme, her işletmecinin ilk uzandığı ve yukarı akışta en evrensel biçimde kabul edilen ilkeldir. Aynı zamanda bu saldırıya karşı işe yaramaya çok yakındır ve refleks hâline geldiğinde fiilen zararlıdır.

Sorun anlambilimindedir. Hedef tabanlı RTBH, duyurulan prefix’e giden bütün trafiği düşürür. Tek bir adrese yoğunlaşmış bir saldırıda bu takas hem okunaklı hem de çoğu zaman doğrudur: ağı ve diğer bütün müşterileri ayakta tutmak için tek bir sunucudan vazgeçersiniz. Halı bombardımanında feda edilecek tek bir hedef yoktur. Dolayısıyla elinizde iki seçenek kalır ve ikisi de kötüdür.

Çok sayıda tekil adres rotası duyurursanız hareketli bir hedefi tek tek sayıyorsunuz demektir. Saldırı altındaki adres kümesi değişir, duyurularınız onu kovalar, duyurabileceğiniz prefix sayısı hem oturumun sınırlarıyla hem de sağlayıcınızın politikasıyla sınırlıdır ve saldırı sürdüğü sürece saldırganın gerisinde kalırsınız.

Kapsayıcı prefix’i duyurursanız, saldırganın amacını kendi yönlendirme politikanızla uygulamış olursunuz. Bloktaki her adres kararır, saldırıya hiç uğramamış her kiracı dahil. Tuhaf bir konumdur: müdahale, saldırıyı tamamlar.

Aynı belgede geçen ve tersine yol iletimiyle uygulanan kaynak tabanlı türev de durumu kurtarmaz. Yansıtma ve amplifikasyon trafiği, toptan karartma hakkınız olmayan meşru üçüncü taraf sunucularından gelir; sahte kaynaklar ise sayılabilir sonlu bir küme değildir.

Bunların hiçbiri RTBH’nin yordamdan çıkarılması gerektiği anlamına gelmez. Sınırınızın fiziksel olarak alabileceğini aşan bir toplam için hâlâ doğru ve çoğu zaman tek araçtır; çünkü o çizginin altında ayırt edecek bir şey kalmamıştır, hat zaten doludur. Disiplin, aracı doğru yere koymaktır: RTBH, önceden mutabık kalınmış ve müşteriye dönük hizmet tanımına yazılmış bir eşiği olan bir kapasite emniyet supabıdır. Halı bombardımanına karşı bir tedbir değildir. O eşiğin altındaki her şey, trafiği birbirinden ayırabilen bir araçla ele alınmalıdır.

FlowSpec ve ince taneli filtreleme

IPv4 için RFC 8955’te, IPv6 için RFC 8956’da tanımlanan BGP FlowSpec, saldırının yapısına gerçekten uyan yönlendirme katmanı aracıdır. Sebebi özeldir: hedef prefix, kaynak prefix, protokol, port aralıkları, paket uzunluğu, parça bitleri ve TCP bayraklarıyla birlikte eşleşme demetinin bir parçasıdır. Dolayısıyla tek bir kural, “şu protokol ve kaynak port bileşimini şu /22’ye doğru düşür ya da hız sınırına al” ifadesini kurabilir. Prefix, kuralın tarifinin bir parçasıdır ve adres başına tekrarlanmaz. Kural sayısı vektör sayısıyla ölçeklenir, hedef sayısıyla değil.

RTBH ile karşıtlık argümanın tamamıdır. RTBH hedefe giden her şeyi düşürür. FlowSpec yalnızca eşleşeni düşürür; bloktaki her adres, kuralın adlandırmadığı her protokol ve port için erişilebilir kalır. Hız sınırı eylemi de burada önemlidir. İçinde bir miktar meşru trafik taşıyan bir vektöre karşı, prefix boyunca uygulanan bir hız sınırı o trafiğin bir bölümünü korur. Doğrudan düşürme bunu yapmaz.

Uyarılar kavramsal değil pratiktir ve her FlowSpec kurulumunda geçerli olanların aynısıdır:

• Donanımdaki filtre kapasitesi sonludur. Kaç kuralın gerçekten donanıma yerleştiği platforma ve hat kartına bağlıdır. Bir üst sınır belirlemeden önce bunu kendi ekipmanınızda ölçün ve kaynak tükendiğinde platformun ne yaptığını öğrenin.
• Dönen vektörler kuralları çoğaltır. Prefix kuralları çoğaltmaz, ama protokol ve port değiştiren çok vektörlü bir saldırı çoğaltır. Etkin kural sayısına sert bir tavan koyun ve her kurala otomatik bir süre sonu verin; böylece bir olay ardında kalıcı bir tortu bırakamaz.
• Otonom sistemler arası kullanım kısıtlıdır. RFC 8955’teki doğrulama yordamı, bir akış tanımını hedef prefix’i için en iyi tekil rotanın alındığı komşuyla ilişkilendirir. Bu, güvenlik açısından doğru kısıttır ve çok sağlayıcılı ortamlarda ifade edebileceklerinizi daraltır.
• Transit sağlayıcıların çoğu müşteriden kural kabul etmez; kabul edenler de dar bir eşleşme ve eylem alt kümesiyle sınırlar. Yukarı akışa karşı evrensel olarak kullanılabilir ilkel hâlâ RTBH’dir.

Pratik duruş şudur: FlowSpec’i önce kendi otonom sisteminizin içinde çalıştırın. Kural tavanı, otomatik süre sonu ve üretim kuralları için iki kişilik onay koyun. Yukarı akıştaki FlowSpec’i ise varsa değerlendirilecek bir kolaylık olarak görün, tasarımın taşıyıcı bir unsuru olarak değil.

Cihaz	Hedef tabanlı RTBH	BGP FlowSpec	Temizleme katmanına devretme	Sürekli inline cihaz
Eylemin dayandığı anahtar	Bir hedef prefix, çoğu zaman tek adreslik bir rota	Hedef prefix'i de içeren çok alanlı bir eşleşme	Temizleme merkezinden duyurulan yönlendirilebilir bir prefix	Cihaz hangi nesnede toplama yapacak biçimde yapılandırıldıysa o nesne
Meşru trafiğe ne olur	Saldırıyla birlikte düşürülür	Yalnızca kurala uyan trafiğe dokunulur	Temizleme yolundan geçirilir ve geri verilir	Yerinde incelenir, yönlendirme hiç değişmez
Hedef sayısıyla ölçekleniyor mu	Hayır: ya hedef başına bir duyuru ya da bütün blok için tek duyuru	Evet: prefix eşleşmenin parçasıdır, tekrarlanan bir alan değil	Evet, ama kapsayıcı prefix'in tamamını devredersiniz	Evet, sayaçlar ve politikalar prefix kapsamlı tutuluyorsa
Yukarı akış sağlayıcınıza karşı kullanılabilir mi	Evet; evrensel olarak kabul edilen tek ilkel budur	Nadiren ve genellikle yalnızca dar bir alt küme için	Evet, katman erişim hattınızın yukarısındaysa	Hayır; cihaz hattınızın altında durur
Halı bombardımanı altındaki arıza biçimi	Saldırganın amacını kendi yönlendirme politikanızla tamamlarsınız	Donanım filtre kapasitesi ve vektör değiştikçe kural çoğalması	Temizleme ve taşıma tek bir hedefe göre boyutlanmışsa yetmemesi	Cihazın içinde hedef başına durum ya da hedef başına eşik tutulması

Bunlar birbirinin alternatifi değildir. Her biri diğerinin bir katmanıdır. Pratik sıra şudur: sınır kapasitenizin altında inline ya da devredilmiş azaltma, yönlendiricide temiz biçimde ifade edebildiğiniz vektörler için FlowSpec ve yalnızca toplamın sınırınızın fiziksel olarak alabileceğini aştığı durum için ayrılmış RTBH.

Durum tutan cihazlara ne yapar

Bant genişliği grafikleri bu saldırıyı olduğundan hafif gösterir; sebebi de tükettiği kaynakların saniyedeki bit sayısıyla ölçülmemesidir.

Durum tutan cihazlar, yani güvenlik duvarları, yeni nesil güvenlik duvarları, yük dengeleyiciler ve adres çeviriciler, bağlantı başına durum ayırır. Binlerce hedefe dağıtılmış trafik çok yüksek bir farklı akış hızı üretir ve bağlayıcı kısıt aktarım hızı olmaktan çıkıp oturum tablosu doluluğu ile yeni bağlantı hızı hâline gelir. İş zirvesindeki bant genişliğine göre doğru boyutlanmış bir sınır, o akış hızına göre boyutlanmış olmaktan çok uzak olabilir ve bu fark, bant genişliği üzerine kurulmuş hiçbir kapasite planında görünmez.

Durumu ağırlaştıran üç ikincil etki vardır.

Politika bazlı koruma profilleri hiç devreye girmez. Durum tutan platformlarda hizmet dışı bırakma koruması genellikle bir politikaya, bir sanal sunucuya ya da bir bölgeye bağlıdır. Çok sayıda hedefe yayılmış trafik pek çok farklı politikaya ya da hiçbir politikaya, yani varsayılan reddetmeye düşer. Hiçbir profil tek başına bir yoğunlaşma görmez. Dolayısıyla hiçbir profilin tetiği çalışmaz, buna karşılık hepsinin altındaki ortak oturum tablosu dolar.

Hiçbir yere gitmeyen trafik de maliyet çıkarır. Canlı bir sunucudaki kapalı bir porta ya da arkasında hiçbir şey olmayan bir adrese giden paket yine bir rota araması, bir politika değerlendirmesi, çoğu zaman bir durum kaydı ve bir log satırı maliyeti üretir. Bu maliyet, dinleyen bir şey olup olmamasından bağımsız olarak ödenir; bütün bloğu taramayı savurgan değil verimli bir taktik yapan da budur.

Tükenme ayrım gözetmez. Sınıfın ne kadar ciddiye alınması gerektiğini belirleyen nokta budur. Bir oturum tablosu dolduğunda cihaz, koruduğu her şey için yeni oturum kabul etmeyi bırakır. Kesinti saldırı altındaki adreslerle sınırlı değildir; cihazın arkasındaki bütün varlıkları kapsar. Hattınızı hiç tehdit etmemiş bir saldırı, hiç hedef alınmamış servisleri kapatabilir.

Tasarım sonucu tanıdıktır: azaltma katmanı durum tutan katmanın önüne konur ve akış başına ayırdığı kaynak ya durumsuz ya da sınırlı olmalıdır. Ama halı bombardımanı, sormayı kolayca unutturan özel bir soru ekler ve bu soru güvenlik duvarıyla değil azaltma cihazıyla ilgilidir: cihazın kendisi hedef adres başına ne ayırıyor? Hedef başına bir izleme kaydı, bir sayaç kümesi ya da bir temel çizgi nesnesi oluşturuyorsa, saldırının hedef çeşitliliği azaltma cihazına yönelen bir saldırıya dönüşür ve cihaz, önlemek için alındığı tükenme arızasını kendisi devralır. Sınırı bir sayı olarak isteyin ve sınırda ne olduğunu sorun: tahliye mi, bozulan muhasebe mi, açık kalma mı, kapanma mı? Dördü de savunulabilir cevaptır. Bilmemek savunulabilir değildir.

Log ve olay hacmine ne yapar

Olay hatları, tespit motorlarıyla aynı sunucu merkezli varsayım üzerine kuruludur. Uyarılar saldırıya uğrayan kaynağa göre anahtarlanır, yinelenen kayıtlar hedefe göre gruplanır, kayıt otomasyonu etkilenen servis başına bir kayıt açar ve kiracı bildirimi etkilenen müşteri başına bir mesaj gönderir. Halı bombardımanı tek bir olayı, bunların hepsinin binlerce eşzamanlı örneğine dönüştürür.

Hacim aynı anda iki yönden gelir. Tespit katmanı, etkilenmiş saydığı her hedef nesnesi için bir olay üretir. Bundan bağımsız olarak, yolun üzerindeki trafiğe dokunan her cihaz kendi kaydını yazar.

Sonuçlar sıradan işletim sonuçlarıdır; zarar verici olmalarının sebebi de tam olarak budur. Olay başına ya da alınan gigabayt başına lisanslanan bir SIEM kademesinde alım ve lisans maliyeti, saklama süresi boyunca taşınan hacim, içinde tek işe yarar sinyalin binlerce benzer kardeşinin altında kaybolduğu bir uyarı kuyruğu ve çok kiracılı ortamlarda bloktaki bütün müşterilere aynı anda ulaşan otomatik bir bildirim dalgası.

Değerlendirmeye yazılacak gereklilik bu yüzden hem özel hem de sınanması kolaydır: tespit motoru, hedef başına bir olay yerine prefix için tek bir olay üretebilmeli ve etkilenen hedef sayısı ile vektör dağılımını o olayın öznitelikleri olarak taşıyabilmelidir. Test koşusu sırasında olay akışını görmek isteyin; dakikadaki olay sayısını ve log hattına gönderilen bayt miktarını açık test çıktıları olarak ölçün. Bu ölçülebilir bir özelliktir ve ürünler bu konuda birbirinden hatırı sayılır biçimde ayrılır.

Devretme, temizleme ve sinyalleşme

Müdahaleniz yerinde filtreleme değil de bir temizleme katmanına devretmekse, halı bombardımanı boyutlandırma hesabını üç noktada değiştirir.

Devrettiğiniz birim, saldırı altındaki bütün hedefleri kapsamak zorundadır; pratikte bu, kapsayıcı prefix demektir. Dolayısıyla bloğun bütün meşru trafiğini de saldırıyla birlikte devrediyorsunuz ve temizleme yolunun ikisini birden taşıması gerekiyor. Tek bir müşterinin adreslerini devretmeye göre yapılmış bir boyutlandırma bunu kaldıramaz. Temizleme kurgusunun kendi iç tasarımı scrubbing merkezi kurulumu makalesinde ayrıca ele alınmıştır.

Prefix uzunluğu filtreleri, kendi ağınızın dışında ne kadar ince devredebileceğinizi sınırlar. Diğer işletmeciler yaygın olarak IPv4’te /24’ten, IPv6’da /48’den uzun duyuruları kabul etmez. Bu bir standart değil yerleşik işletim pratiğidir, ama sizin üzerinizdeki etkisi bağlayıcıdır: dış devretmenin en küçük birimini ve dolayısıyla adres planınızın hangi tanecikte tasarlanmış olması gerektiğini belirler.

Eşzamanlılık varsayımları kurgu gereği bozulur. Paylaşılan bir blok üzerindeki halı bombardımanı, aynı dakika içinde çok sayıda kiracıyı saldırı altına sokar. “Aynı anda tek müşteri” varsayımıyla kurulmuş kapasite modelleri burada ihtiyatlı değildir; yalnızca başka bir saldırıyı tarif etmektedir.

Dönüş yolu her zamanki dikkati hak eder. Devredilen prefix, temizlenmiş trafiğin teslim edileceği adresleri de içerdiğinden, dönüş rotasının devretme duyurusundan yalıtılması gerekir. Bu yalıtım bir tunnel, ayrı bir yönlendirme örneği ya da teslim yönlendiricisinde politika tabanlı yönlendirmeyle kurulur ve tunnel uçları devredilen aralığın dışında kalmalıdır.

Azaltma talebi kurumsal bir sınırı geçiyorsa, kapsam sorusu sinyalleşmede de karşınıza çıkar. RFC 8811’deki DOTS mimarisi ve RFC 9132’deki sinyal kanalı, bir azaltma talebinin tek bir adres yerine hedef prefix ve port aralığıyla kapsamlandırılmasına izin verir; bu saldırının ihtiyaç duyduğu ifade gücü tam olarak budur. Yalnızca bir sunucu adlandırabilen bir sinyalleşme, olan biteni tarif edemez. İki katmanın arasındaki arayüzün tescilli değil standart tabanlı olmasının gerekçesi iki katman, iki marka makalesinde ayrıca kurulmuştur.

Ürün kriterleri ve deneme kurulumunda istenecekler

Yukarıdakilerin tamamı kısa bir özellik listesine iner. Bu özelliklere sahip bir ürün bu saldırı biçimini karşılar. Sahip olmayan bir ürün, veri sayfası ne iddia ederse etsin, karşılamaz.

1. Sayaçlar ve temel çizgiler hiyerarşik tutulmalı; alt blok, yönlendirilen prefix ve kiracı türetilmiş görünümler değil birinci sınıf nesneler olmalıdır.
2. Alarm hacmin yanı sıra farklı hedef sayısıyla ve kullanılmayan adreslere giden trafikle de üretilebilmelidir.
3. Azaltma, bir prefix üzerinde tek bir politika olarak ifade edilebilmelidir; çok sayıda adres üzerinde çok sayıda ayrı politika olarak değil.
4. Hedef çeşitliliği arttıkça tüketilen kaynak sınırlı ve öngörülebilir olmalı; sınır beyan edilmeli ve sınırdaki davranış tanımlı olmalıdır.
5. Olay çıktısı olay başına toplanmalı ve etkilenen hedef sayısını öznitelik olarak taşımalıdır.
6. Paylaşılan altyapıda aynı donanım üzerinde kiracı başına politika ve kiracı başına raporlama bulunmalı; böylece prefix düzeyindeki bir olay her müşteriye ayrı ayrı anlatılabilsin.

Son iki kriter, çok kiracılı işletmecilerin gerçek farkları bulduğu yerdir ve kısa listedeki her üreticiye soru olarak değil gösterim olarak yöneltilmelidir. Ortak donanım üzerinde müşteri başına ayrı koruma profili tutabilmek ve tespit kararını bir üretici istihbarat bulutuna sormadan kurumun kendi altyapısında verebilmek, bir cihazı bu kısa listenin içinde tutan iki özelliktir. Buna karşılık sayaçların hangi nesnede tutulduğu sorusu bütün adaylara aynı sertlikte sorulmalı ve cevabı çalışan yapılandırma üzerinde gösterilmelidir. Çünkü bu makalenin savunduğu ölçüt ürünün adına değil, sayacın kendisine bakar. Şartnameye de aynı ölçüt yazılmalıdır, ürün adı değil. Aday cihazların ölçüt ölçüt karşılaştırması yerinde DDoS cihazları karşılaştırmasında ayrıca yapılmıştır.

Testin kendisi

Aşağıdakileri yapmayan bir deneme kurulumu halı bombardımanını test etmiş sayılmaz.

• Testi kendi adres planınız üzerine kurun; fiilen işlettiğiniz ve yönlendirdiğiniz prefix uzunluğunu kullanın, kullanışlı bir laboratuvar /29’unu değil.
• Hedef başına hızı cihazın yapılandırmasındaki sunucu başına tetiğin altına sabitleyin ve koşu başlamadan önce üreticiden o tetiğin çalışan yapılandırmadaki değerini teyit ettirin. İki sayıyı da test kaydına yazın.
• Toplamı iki seviyede çalıştırın: cihazın beyan edilen kapasitesinde ve gerçek hat hızınızda. İkisi farklı şeyleri sınar.
• Vektörün izin verdiği en küçük paket boyutunu kullanın ve saniyedeki paket sayısını saniyedeki bit sayısıyla birlikte kaydedin. Küçük paketli saldırılar bit hızı sınırlarına ulaşmadan çok önce işleme sınırlarına ulaşır.
• Hedef alt kümesini tespit motorunun gözlem penceresinden hızlı döndürün. Ürünleri ayıran varyant budur ve üreticinin yürüttüğü bir gösterimde en çok atlanan da budur.
• Arkasında hiçbir servis olmayan adresleri de dahil edin ve sistemin bunları sayıp raporladığını doğrulayın.
• İlk saldırı paketinden itibaren tespit süresini, azaltmaya geçiş süresini ve hangi sayacın hangi toplama düzeyinde tetiklendiğini kaydedin. Asıl bulgu sonuncusudur; hat düzeyinde tesadüfen tespit eden bir ürün prefix düzeyinde tespit göstermemiştir.
• Oluşturulan azaltma nesnelerini sayın. Prefix için bir tane mi, yoksa hedef başına bir tane mi?
• Dakikadaki olay sayısını ve log hattına gönderilen bayt miktarını ölçün.
• Koşu boyunca aynı prefix’e meşru trafik akıtın ve bu trafiğin tamamlanma oranıyla gecikmesini ölçün. Yanlış pozitif ölçümü olmayan bir “saldırı engellendi” cümlesi bir sonuç değildir.
• Yol dışı tasarımlarda tespit motorunu üretimdeki örnekleme oranınız ve dışa aktarma zamanlayıcılarınızla besleyin; örneklenmemiş bir laboratuvar beslemesiyle değil. Sonra iki durumdaki tespit sürelerini karşılaştırın. Aradaki fark sizin gerçek tespit gecikmenizdir.
• Aynı saldırıyı durum tutan sınırınızdan bir kez azaltma cihazı önündeyken bir kez önünde değilken geçirin ve iki durumda da güvenlik duvarının oturum tablosu doluluğunu kaydedin. Bu ölçüm genellikle çalışmanın ürettiği en ikna edici belgedir.
• Beyan edilen hedef izleme sınırını bilerek aşın ve cihazın ne yaptığını kaydedin.
• Toparlanmayı test edin: saldırıyı geri çekin, azaltmanın kalktığını doğrulayın, sonra aynı bloğun farklı bir alt kümesinde yeniden başlatın ve elle müdahale olmadan yeniden devreye girdiğini doğrulayın.

Ortaya çıkan her rakamı, test edilen belirli model ve yazılım sürümüne bağlanmış biçimde yazılı isteyin ve tekrarlayabildiklerinizi kendi laboratuvarınızda tekrarlayın. Düzgün toplama yapan bir ürünle yapmayan bir ürün arasındaki fark ince değildir; bu biçimde kurulmuş bir test farkı bir öğleden sonrada görünür kılar. Bu katmanın hibrit bir mimarideki yeri bulut, yerinde ve hibrit DDoS koruması makalesinde ele alınmıştır.

Kaynaklar ve ileri okuma

Aşağıdakiler, yukarıda tartışılan mekanizmaların birincil kaynaklarıdır. Makaledeki tek sayısal örnek açıkça gösterim amaçlı bir çarpma işlemi olarak işaretlenmiştir ve kendi adres planınızla ve kendi telemetrinizle yeniden hesaplanmalıdır.

Yönlendirme katmanındaki müdahaleler. IPv4 için BGP FlowSpec RFC 8955, IPv6 için RFC 8956’dır; doğrulama yordamı ile desteklenen eşleşme ve eylem kümeleri orada tanımlıdır, platformunuzun donanımda desteklediği alt küme ise üreticinizle ayrıca teyit edilmelidir. Kara delik yönlendirme, kaynak tabanlı türevi ve tersine yol iletimiyle uygulanışı dahil, RFC 5635’te tarif edilmiştir.

Sınır ötesi azaltma sinyalleşmesi. DOTS mimarisi RFC 8811, sinyal kanalı RFC 9132’dir. Buradaki ilgili kısım kapsam öznitelikleridir: bir talebin tek bir adres yerine hedef prefix ve port aralığı adlandırmasına izin verirler.

Akış telemetrisi. NetFlow, IPFIX ve sFlow arasındaki fark bu saldırıda akademik değildir; etkin akış zaman aşımı, örnekleme yöntemi ve akış önbelleği davranışı için kendi platformunuzun belgelerini okuyun ve hat kartı bazında doğrulayın.

Üreticiden yazılı istenecek belgeler. Kısa listedeki her ürün için şunları yazılı isteyin: sistem başına ve korunan nesne başına izlenebilen azami hedef sayısı, bu sınır aşıldığındaki davranış, sayaç ve temel çizgilerin tutulduğu toplama düzeyleri, işlettiğiniz hat kartlarında donanıma yerleşebilen azami filtre kuralı sayısı ve çok hedefli bir olay sırasındaki olay birleştirme davranışı. Bu saldırı altındaki davranışı öngören sayılar bunlardır ve veri sayfasında nadiren bulunurlar.