İSS ve Operatörler için DDoS Koruma Alım Rehberi: Şartname ve Değerlendirme

Bir operatörün DDoS konusunda yazabileceği iki ayrı belge vardır ve bu ikisi birbirine benzemez. Birincisi bir kurulum belgesidir: temizleme kümesi nereye konacak, geri dönüş yolu nasıl çözülecek, tespit eşikleri nasıl ayarlanacak. İkincisi bir satın alma belgesidir: şartnameye ne yazılacak, gelen tekliflerin cevapları nasıl puanlanacak ve iş bittiğinde müşteriye ne söz verilebilecek. Elinizdeki metin ikincisidir. Bu çeyrekteki işiniz tesisi fiilen kurmaksa, temizleme merkezi kurulum rehberimiz mühendislik sırasını adım adım anlatır ve buradaki şartname maddelerinin teknik karşılığı büyük ölçüde orada durur. İşiniz ihale metnini yazmak, teklifleri değerlendirmek ve ortaya çıkan taahhüdü ticari yöneticinize karşı savunmaksa doğru yerdesiniz.

İki belge tek bir noktada keskin biçimde ayrışır. Kuran mühendis “bunu nasıl çalıştırırım” diye sorar. Satın alan mühendis “bu platform sınırlarda ne yapıyor” diye sormak zorundadır, çünkü SLA sınırlarda sınanır ve para sınırlarda kaybedilir. Bir operatörün DDoS programında yaşanan tatsız sürprizlerin neredeyse tamamının ortak bir tarifi vardır: üreticinin bildiği, şartnamede sorulmamış ve olay anında öğrenilmiş bir sınır.

Aslında ne satın alıyorsunuz

Bir operatör tek bir DDoS ürünü satın almaz. Üreticilerin tek bir isim altında paketlediği, birbirinden ayrılabilir dört şey satın alır ve şartnamenin dördünü de ayrı ayrı sorması gerekir.

Birincisi tespittir: akış telemetrisinden ya da hat üstü incelemeden yola çıkarak belirli bir müşteri ön ekinin saldırı altında olduğunu görebilmek ve bunu sözleşmeye yazabileceğiniz bir süre bütçesi içinde söyleyebilmek. İkincisi trafik yönlendirmedir: etkilenen trafiği temizlenebileceği yere yönlendiren ve temizlenmiş trafiği müşteriye geri veren makine. Üçüncüsü azaltmanın kendisidir: karşı önlemler, bunların işleme kapasitesi ve ağınızın gerçekte ürettiği trafik koşulları altındaki davranışları. Dördüncüsü, teknik değerlendirmelerde en sık atlanan katmandır: yukarıdakilerin hepsini faturada bir satıra çeviren kiracılık ve raporlama katmanı.

Yalnızca üçüncüsünü puanlayan bir ihale hızlı sonuç verir. Ama satamayacağınız bir kutu seçer. Dördünü birden puanlayan bir ihale çoğu zaman başka bir yere varır, çünkü ham azaltma kapasitesinde en güçlü üreticiler, kiracı ayrımında ve kiracı başına raporlamada çoğu zaman başka üreticilerdir. Bu bir mühendislik eleştirisi taşımaz. Ürünlerin hangi soruna göre şekillendiğini gösterir. Taşıyıcı ölçeğinde kapasiteye odaklanan bir mimari ile yüzlerce küçük kiracıyı tek şasi üzerinde ayrıştırmaya odaklanan bir mimari başka ürünlerdir.

Üç teslim modeli ve yönetim kuruluna götüreceğiniz tablo

Teknik şartnameden önce ticari bir karar gelir ve bu karar, şartnamenin ne söylemesi gerektiğini değiştirir. Temizleme kapasitesini kendiniz kurup işletebilirsiniz, bir temizleme ortağının kapasitesini beyaz etiketle kendi markanız altında sunabilirsiniz ya da kendi transit sağlayıcınızın hâlihazırda sattığı hizmeti yeniden satabilirsiniz. Üç model tavanı, hukuki çerçeveyi ve eskalasyon yolunu farklı yerlere koyar.

Cihaz	Kendi kapasitenizi kurmak	Bir temizleme ortağını beyaz etiketle sunmak	Transit sağlayıcınızın hizmetini yeniden satmak
İlk faturaya kadar geçen süre	En uzun; tasarım, tedarik, entegrasyon ve tatbikat ilk faturadan önce gelir	Orta; süreyi ticari sözleşme ve panel entegrasyonu belirler	En kısa; çoğu zaman bir sözleşme eki ve bir fiyat listesi yeterlidir
Koruyabileceğiniz tavan	Kendi peering ve transit kenarınız, taşıma kapasiteniz ve paket oranı bütçeniz	Ortağın kapasitesi, daha önce sattığı kadarı düşüldükten sonra	Sağlayıcının kapasitesi, koşullarını sizin belirlemediğiniz bir çerçevede
Kiracı başına politika kontrolü	Tam; temel çizgileri ve karşı önlem sırasını siz yazarsınız	Kısmi; genellikle serbest yapılandırma değil, hazır politika şablonu menüsü	Asgari; diğer müşteriler gibi kayıt açarsınız
Müşteri trafiğinin incelendiği yer	Kümeyi nereye koyarsanız orası; kendi hukuki çerçeveniz ve kendi sözleşmeleriniz altında	Ortağın altyapısında, ortağın tabi olduğu hukuk altında	Sağlayıcının altyapısında, sağlayıcının tabi olduğu hukuk altında
Müşteri başına raporlama	Ya kendiniz geliştirirsiniz ya da ürün özelliği olarak satın alırsınız	Ortağın beyaz etiketli panel ve API sunmasına bağlıdır	Çoğu zaman yoktur ya da markasızdır; ticari olarak kapatılması en zor boşluk
Marj yapısı	Önden yatırım ve işletme gideri; marj kiracı sayısıyla birlikte düzelir	Toptan ile perakende arasındaki fark; öngörülebilir ama tavanı belli	İnce bir yeniden satış marjı ve müşteri ilişkisinin sağlayıcıda kalması
Düzenin tipik kırılma biçimi	Gerçek kenarın üstünde kapasite satılır ve taahhüdü fizik bozar	Ortakta yaşanan kesinti ya da kapasite çekişmesi, siz teşhis edemezsiniz	Olay anında eskalasyon yolunun üçüncü bir taraftan geçmesi

Üç model birbirini dışlamaz ve operatörlerin çoğu sonunda bunları birleştirir: soğurabildiği hacimler için kendi kapasitesi, o eşiğin üstü için sözleşmeye bağlanmış bir taşma yolu. Belirleyici soru gigabit başına maliyet yerine, hangi modelin size gerçekten kontrol edebildiğiniz bir müşteri raporu ve bir eskalasyon yolu bıraktığıdır.

En büyük pazarların dışındaki operatörlerin çoğu melez bir konumda son bulur: kendi kapasiteleri müşteri tabanına karşı gerçekten sık görülen saldırı hacimlerini karşılar, sözleşmeye bağlanmış bir taşma yolu da üstünü alır. Bu savunulabilir bir tasarımdır ve bulut ile yerinde korumanın birlikte kurgulandığı hibrit modelin operatör tarafındaki karşılığıdır. Savunulamayan şey, iki katman arasındaki eşiğin belgesiz bırakılmasıdır. Müşterinin parasını verdiği şey tam olarak o eşiktir.

Kapasite: şartnameyi kendi kenarınıza göre yazın

Operatör satın almalarındaki en yaygın boyutlandırma hatası budur ve iki yönde birden pahalıdır: ya gereğinden fazlasını satın alırsınız ya da teslim edebileceğinizden fazlasını satarsınız.

Bir kurum, azaltma kapasitesini kendi erişim hattına göre boyutlandırır, çünkü hat ona ulaşabilecek trafiğin fiziksel sınırıdır. Operatörün elinde böyle rahat bir rakam yoktur. Sizi bağlayan rakam, peering ve transit portlarınızın toplamı üzerinden ağınıza fiziksel olarak kaç bit ve kaç paket girebileceğidir. Soğurmanız istenebilecek saldırının gerçek üst sınırı budur ve genellikle herhangi bir müşterinin hattından kat kat büyüktür.

Bu başlık rakamın altında üç tavan daha durur ve bunları sormayan bir şartname, kendi veri sayfasını dahi karşılayamayan bir platform üretir.

Temizleme kümesine giden taşıma kapasitesi. Devredilen trafik, kenar yönlendiricilerden temizlemenin yapıldığı yere kadar taşınmak zorundadır. Kümenin etiket değeri ne olursa olsun, omurganın oraya taşıyabildiğinden fazlasını devredemezsiniz. Pek çok tasarımda gerçek darboğaz buradadır. Bütçede en kolay unutulan kalem de budur, çünkü bir taşıma gideri kalemine düşer ve bir güvenlik harcaması gibi görünmez.

Paket oranı. Bit hızı tek başına her platformu olduğundan iyi gösterir. Küçük paketlerden kurulu saldırılar, ilan edilen bit hızına yaklaşmadan çok önce paket işleme sınırına çarpar; dolayısıyla yalnızca saniyede gigabit cinsinden ifade edilmiş bir veri sayfası en kolay durumu anlatır. Saniyedeki paket rakamını yazılı isteyin, bu rakamı üretimde açık tutmayı planladığınız karşı önlem setiyle birlikte isteyin ve kabul testlerini platformun gerçekte karşılaşacağı en küçük paket boyuyla yapın.

Eşzamanlılık. Hayal edebileceğiniz en büyük tekil saldırıya göre boyutlandırmak iyimserdir. Saldırılar kampanyalar halinde gelir ve aynı kampanyanın aynı saat içinde birden çok müşterinizi hedeflemesi son derece olağandır. Aynı anda kaç kiracının azaltma altında olabileceğine dair açık bir varsayım yazın ve kapasiteyi tekil bir olaya göre değil bu varsayıma göre planlayın.

Aritmetiği somutlaştırmak için bir örnek verelim. Bu yalnızca temsilî bir hesaptır ve kendi telemetrinizle baştan yapmanız gerekir: bir operatörün peering ve transit toplamında 200 Gbps dış kenarı, tek bir temizleme sahasına 2 × 100 Gbps taşıması ve kendi testlerinizin 64 baytlık trafikte yaklaşık 60 Gbps civarında ulaşıldığını gösterdiği bir paket oranı sınırı olsun. Dürüstçe ilan edebileceğiniz koruma seviyesi, beklediğiniz trafik karışımı altında bu üç kısıtın en küçüğünden türetilir. En büyük rakama göre boyutlandırmak sizi yanıltır. Aynı anda iki kiracıyı korumayı taahhüt ediyorsanız, ikisinin toplamı da aynı çizginin altında kalmak zorundadır. Yukarıdaki sayıların hiçbiri bir norm değildir; hepsi sizinkilerin yerini tutan boş kutulardır.

Bunun ticari sonucunu açıkça söylemek gerekir. Gerçek kenar kapasitenizin üzerinde bir koruma seviyesi satarsanız, o büyüklükte bir saldırı temizleme kümesine hiç ulaşmadan transit portlarınızı doldurur. Zarar da yalnızca saldırı altındaki müşteriyle sınırlı kalmaz: aynı portların arkasındaki bütün müşteriler etkilenir, kendi yukarı akış sağlayıcınıza taahhüt ettiğiniz trafik profilinin dışına çıkarsınız ve transitin yüzde 95’lik dilim üzerinden faturalandığı yerlerde saldırı trafiği doğrudan sizin maliyetinize dönüşür. İlan edilmiş bir blackhole eşiği bir teklifte zayıflık sayılmaz. Tam tersine, aritmetiği yapmış bir operatörün işaretidir.

Devretme sinyalleşmesi: BGP entegrasyonundan ne istemelisiniz

Trafiği devretmek kavram olarak basittir, çünkü temizleme sahasından daha uzun bir ön ek duyurmanız yeterlidir ve gerisini en uzun ön ek eşleşmesi halleder. Buna karşılık işletme tarafı keskin kenarlarla doludur. Şartname sonucu değil mekaniği tarif etmelidir.

Oturum tasarımı. Azaltma platformunun rotaları nasıl enjekte edeceğini yazın: rota yansıtıcılarınıza ya da belirli kenar yönlendiricilere kurulan ayrı bir eBGP oturumu, oturum kimlik doğrulamasıyla ve sizin tarafınızda katı bir giriş politikasıyla birlikte. Kontrolcü, tasarımı gereği üretim trafiğini yönlendirebilen bir cihazdır; dolayısıyla konuştuğu oturumun diğer dış oturumlarla aynı korumalara ihtiyacı vardır. Azami ön ek sınırı, ön ek uzunluğu filtresi, duyurmasına izin verilen ön eklerin beyaz listesi ve devretme rotalarının ağın her yerinde tanınmasını sağlayan community etiketlemesi asgari settir. BGP işletim güvenliği için şartnamede atıf verilecek doğru temel metin RFC 7454’tür (BCP 194).

Geri çekme davranışı. Kontrolcü yönetim bağlantısını kaybederse, süreç yeniden başlarsa ya da operatör unutursa duyurulmuş devretme rotalarına ne olduğunu sorun. Rotaların yenilenmedikçe süresi dolacak şekilde tasarlanması ile açıkça kaldırılana kadar ayakta kalması, birbirinden esaslı biçimde farklı iki güvenlik duruşudur. İkisi de savunulabilir, ama yalnızca biri sizin koşu kitabınıza uyar ve hangisini satın aldığınızı imzadan önce bilmelisiniz.

AS sınırının dışındaki ön ek uzunluğu. Kendi AS’inizin içinde istediğiniz uzunlukta daha uzun bir ön ek duyurabilirsiniz, çünkü duyuru dışarı çıkmaz. Devretmeyi AS sınırının ötesine sinyallemek gerektiği anda, IPv4’te /24’ten ve IPv6’da /48’den uzun ön eklerin filtrelenmesi yönündeki yaygın işletme pratiği bağlayıcı hale gelir. Bu yazılı bir standart olmasa da, yerleşik bir gelenektir ve sizi fiilen kısıtlar. Müşterilerine tek tek adres tahsis eden bir hosting sağlayıcısı için sonucu şudur: adres planının en baştan koruma birimi düşünülerek yapılması gerekir.

RPKI ve en çok ihtiyaç duyduğunuz duyuru. Devretme duyurusu AS’inizin dışında görülecekse, o ön ekleri kapsayan ROA kayıtlarındaki maxLength değeri, duyurmayı planladığınız daha uzun ön eke izin vermek zorundadır. İzin vermiyorsa, duyuru köken doğrulaması yapan her ağda geçersiz sayılır ve düşürülür; üstelik tam da ona ihtiyaç duyduğunuz anda. Bu gereksinim, maxLength değerlerini dar tutmayı öneren RFC 9319 (BCP 185) tavsiyesiyle doğrudan gerilim içindedir ve iki gereksinim birlikte planlanmalıdır, iki ayrı ekip tarafından değil. Kabul testi planına “devretme duyurusu dışarıdan geçerli görünüyor ve kabul ediliyor” maddesini koyun. Köken doğrulamasının kendisi RFC 6811’de tanımlıdır.

Yukarı akışa sinyalleşme. Kendi sağlayıcılarınızdan isteyebilecekleriniz, onların yayımladığı community kümesiyle sınırlıdır. Neredeyse her yerde bulunan tek ilkel araç uzaktan tetiklenen blackhole’dur: RFC 7999 iyi bilinen BLACKHOLE community’sini tanımlar, uRPF ile kaynak tabanlı varyant ise RFC 5635’te anlatılır. Bunun ne olduğu konusunda kurum içinde dürüst olun. Blackhole, geri kalan her şeyi kurtarmak için hedeften feragat etme işlemidir; bir koruma biçimi olarak sunulmamalıdır. Her yukarı akış sağlayıcısının kabul ettiği community listesini, kabul ettiği ön ek uzunluklarını ve taahhüt ettiği tepki sürelerini sözleşme aşamasında toplayın, olay anında değil.

Müşterilerle standart tabanlı sinyalleşme. Müşterilerinizin bir bölümü kendi yerinde cihazlarını işletiyorsa, aranızdaki azaltma talebi sinyalleşmesinin tescilli bir arayüz olması gerekmez. Bakılacak yer DOTS’tur: mimari için RFC 8811, sinyal kanalı için RFC 9132 ve veri kanalı için RFC 8783. Bunu şartnameye koymanın size bir maliyeti yoktur ve müşterinin cihazıyla sizin katmanınızın, iki taraftan hiçbiri diğerinin arayüzünü sahiplenmeden birlikte çalıştığı kurguyu açık tutar. Bu kurgunun mimari gerekçesi iki katmanın iki ayrı markadan kurulduğu tasarımlarda daha ayrıntılı ele alınıyor.

Asimetrik yönlendirme ve durum tutan incelemenin sınırı

Operatör ölçeğindeki değerlendirmenin kurumsal değerlendirmeden en keskin ayrıldığı ve üretici veri sayfalarının en az işe yaradığı teknik alan burasıdır.

Birden çok transit ve peering noktası olan bir ağda, aynı oturumun iki yönü rutin olarak farklı kenar yönlendiricilerden geçer. En yakın çıkış yönlendirmesi bunu istisna olmaktan çıkarıp normal duruma dönüştürür. Hat dışı devretme ise asimetriyi arızi olmaktan çıkarıp yapısal hale getirir, çünkü azaltma sırasında yalnızca gelen yönü devredersiniz ve giden yön olağan yolunu izlemeye devam eder. Bunun ötesinde, temizleme kümesinin içinde trafiğin üye cihazlara dağıtılma biçimi bile tek bir inceleme motorunun gördüğünü bölebilir.

Sonuç doğrudandır: yalnızca tek yönü gözlemleyen bir inceleme motoru gerçek anlamda bağlantı durumu tutamaz. TCP el sıkışmasının tamamlandığını doğrulayamaz, sıra numarası ilerlemesini takip edemez, oturumun kapandığını göremez. Bu koşulda katı bir durum makinesi çalıştıran bir cihaz iki şeyden birini yapar: meşru trafiği düşürür ya da durum kontrolünü sessizce kapatır. İki davranış da kabul edilebilir olabilir, ama hangisini satın aldığınızı önceden bilmeniz gerekir.

Tek yönlü bir yolda gerçekten çalışan şey, cevabı cihazın kendisinin ürettiği ve istemcinin tepkisini değerlendirdiği karşı önlem ailesidir: SYN cookie benzeri doğrulamalar, yeniden gönderim davranışına dayalı kaynak doğrulama, protokol uyum kontrolleri ve hız sınırlama. Bunlar geri yönü görmeye ihtiyaç duymaz, çünkü geri yönü cihaz kendisi üretir. Gelen yöndeki imza ve örüntü eşleşmesi de asimetriden sağ çıkar. Sağ çıkmayan şey, sunucunun cevabını gözlemlemeyi gerektiren her şeydir.

Bunu şartname sorularına çevirin:

1. Hangi karşı önlemler iki yönün de aynı noktadan görülmesini gerektiriyor? Güvence değil açık bir liste isteyin. O listedeki her yetenek, hizmet tanımınızda yalnızca iki yönün de aynı noktadan geçtiği garanti edilen kurulumlarla sınırlandırılmalıdır.
2. El sıkışma hiç görülmediğinde varsayılan davranış nedir? Düşürmek mi, geçirmek mi, bir doğrulama adımına geri çekilmek mi? Cevap, her devretme sırasındaki yanlış pozitif riskinizi belirler.
3. Küme üyeleri arasındaki yük dağıtımı akış bazlı mı? Paket bazlı dağıtım, tek başına durum takibini ve parça birleştirmeyi bozar.
4. Parçalar küme üyeleri arasında nasıl ele alınıyor? İlk olmayan parçalar taşıma katmanı port numaralarını taşımaz; dolayısıyla portları içeren bir hash bunları ilk parçayla aynı üyeye göndermez. Platformun bunları nasıl birleştirdiğini ya da yönlendirdiğini sorun ve deneme kurulumunda test edin. Parçalanmaya dayalı saldırılar tam da bu zor olduğu için vardır.
5. Durum modeli nedir ve tüketilebilir mi? Akış başına durum ayıran bir cihazın bir oturum tablosu vardır ve bu tablo başlı başına bir saldırı yüzeyidir. Dolduğunda ne olduğunu ve kiracı başına sınır uygulanıp uygulanamadığını sorun.
6. Hizmet tanımı ne diyor? Asimetrik trafikte hangi özellikler devre dışı kalıyorsa, bunu satış ekibinin sözleşmeden önce bilmesi gerekir; operasyon ekibinin sözleşmeden sonra değil.

Simetriyi zorlamak mümkündür. Müşteriyi tek bir kenar noktasına sabitleyebilir ya da giden yönü de temizleme yolundan geçirebilirsiniz. Ancak bu, kapasite ve gecikme cinsinden bilinçli bir maliyettir. Bunu ağ genelinde bir varsayılan olarak değil fiyatı olan bir müşteri seçeneği olarak kurgulayın.

FlowSpec: keskin bir araç, dikkatli yazılması gereken bir madde

BGP FlowSpec, n-tuple eşleşme kurallarını BGP üzerinden dağıtır: hedef ve kaynak ön eki, protokol, port aralıkları, paket uzunluğu, parça bitleri, TCP bayrakları. Eylem tarafında trafik hızı sınırlama (hız sıfır verildiğinde tam düşürme), bir VRF’e yönlendirme ve işaretleme vardır. IPv4 için RFC 8955, IPv6 için RFC 8956 geçerlidir.

Bir operatör için çekiciliği çok somuttur. Bir yansıtma saldırısı, trafiği temizleme kümesine hiç taşımadan, doğrudan kenar yönlendiricide ve donanım hızında kesilebilir. Bu da yukarıda anlatılan taşıma kapasitesini korur ve taşıma kapasitesi, kapasite modelinin en pahalı kalemlerinden biridir.

Temkinin gerekçeleri de aynı ölçüde somuttur ve şartname bunları yansıtmalıdır. Hatalı yazılmış bir kural saniyeler içinde tüm kenara yayılır. Hat kartlarındaki donanım filtre kaynağı sınırlıdır ve kural sayısı bu kaynağı aştığında davranış platformdan platforma değişir; öngörülemezliğin kendisi başlı başına bir risktir. RFC 8955’teki doğrulama yordamı, kuralı hedef ön eki için en iyi unicast rotanın öğrenildiği komşuyla ilişkilendirir; bu güvenlik açısından doğru bir kısıttır ama çok sağlayıcılı ortamlarda ifade edebileceklerinizi daraltır. Uygulama kapsamı da farklılaşır: hangi eşleşme ve eylem bileşimlerinin desteklendiği ve bunlardan hangilerinin kontrol düzlemine düşmeden donanımda çalıştığı, her platform için ayrı bir sorudur.

Yazılmaya değer şartname maddeleri şunlardır: RFC 8955 ve RFC 8956 desteği; sizin hat kartı envanterinizde donanımda çalıştığı üretici tarafından teyit edilmiş eşleşme ve eylem bileşimlerinin belgeli listesi; üretilen kural sayısına yapılandırılabilir sert bir üst sınır; her kuralda otomatik süre dolumu; üretilen kuralları kiracı başına kapsamlandırabilme; neyin, kim ya da ne tarafından ve ne zaman üretildiğini gösteren tam bir denetim izi; ve her şeyi geri çeken, test edilmiş tek bir acil durdurma anahtarı. FlowSpec’i önce kendi AS’inizin içinde işletin ve yukarı akışın kural kabul etmesini bir bonus olarak planlayın, tasarımın taşıyıcı unsuru olarak değil.

Çok kiracılılık: maliyet merkezini ürüne çeviren ölçüt

Yukarıdakilerin hepsini kurup bunu atlarsanız, elinizde iyi bir ağ hijyeni aracı olur; fatura kesebileceğiniz bir şey olmaz. İkisini ayıran üç yetenek vardır.

Kiracı başına politika. Her müşterinin normali başkadır. Oyun sunucusu barındıran bir kiracının UDP profili, trafiği ağırlıklı olarak TCP/443 üzerinden akan bir bankayla aynı eşiklerle yönetilemez. Paylaşılan donanım üzerinde müşteri başına ayrı öğrenilmiş temel çizgi, ayrı eşik seti, ayrı karşı önlem sırası ve ayrı beyaz liste tutabilmeniz gerekir. Politika şablonları da şarttır, aksi halde elli müşteri, kimsenin sürdüremeyeceği elli ayrı elle yazılmış yapılandırmaya dönüşür.

Kiracılar arası yalıtım. Bir kiracıya yönelen saldırı, paylaşılan kaynakları tüketerek başka bir kiracının korumasını zayıflatmamalıdır. Bu, oturum tablosu, kural kapasitesi ve işleme bütçesi düzeyinde kiracı başına sınır demektir. İstekliye sorulacak soru “kaç kiracı destekliyor” değildir, çünkü o rakam pazarlamadır. Soru “bir kiracı diğerini nasıl etkileyebilir” sorusudur ve cevabın hangi kaynakların bölümlendiği, hangilerinin paylaşıldığı konusunda somut olması gerekir.

Kiracı başına görü. Müşteri yalnızca kendi ön eklerini görmelidir. Saldırı zaman çizelgesini, vektör dağılımını, düşürülen ile geçirilen hacmi kendi panelinden takip edebilmeli; raporu dışa aktarabilmeli ve rol tabanlı yetkilendirmeyle kendi ekibine açabilmelidir. API de önemlidir, çünkü teknik müşteriler veriyi kendi izleme sistemlerinde ister ve onlar için API’nin yokluğu başka bir yerden satın alma gerekçesidir.

Üçüncü madde ticari olarak en çok küçümsenendir. Müşteriniz tespit motorunuzu hiç görmez. Paneli görür. Saldırının durdurulduğunu gösteren okunaklı bir rapor, yenileme görüşmesinde motorun inceliğine dair her iddiadan daha ikna edicidir; aynı rapor müşterinin kendi denetçilerine ve kendi düzenleyicisine sunduğu belgedir. Bu tarafın kayıt ve saklama yükümlülükleriyle nasıl kesiştiği log yükümlülükleri rehberinde ayrıca ele alınıyor.

Donanım ölçütü doğrudan buradan çıkar: paylaşılan donanım üzerinde kiracı başına ayrı koruma profili ve kiracı başına ayrı raporlama. Bu maddeye tek cihaz üzerinden verilen bir cevabın üç ayağı olur: L3–L7 kapsamının tek cihazda toplanması, tespitin bir üretici istihbarat bulutuna bağlı olmadan tümüyle sizin altyapınızda çalışması ve ticari ilişkinin yukarı akış katmanınızdan ayrı durması, yani koruma katmanınızı transit sözleşmenizden bağımsız olarak değiştirebilmeniz. Buna karşılık çok kiracılılık, deneme kurulumunda kanıtlanacak bir davranıştır; veri sayfasından okunup kabul edilecek bir satır olarak görülmemelidir: aynı şasi üzerinde iki kiracı tanımlayın, birinde agresif bir profil çalışırken diğerinin trafiğini ölçün ve iki kiracının raporunu ayrı ayrı dışa aktarın. Bu iki raporu tek gövdeden üretemeyen bir kurulum, teklifte ne yazarsa yazsın o maddeyi karşılamıyordur. Aynı testi listenizdeki her ürüne uygulayın; kriteri karşılayan başka ürünler de vardır ve mesele markanın adı değil, şartnamenin biçimidir.

SLA’de dürüstçe taahhüt edilebilecekler

Bir SLA’in değeri, vaat ettikleri kadar kapsam dışı bıraktıklarında da yatar. Ölçtüğünüz ve kontrol ettiğiniz şeyleri taahhüt edin:

• Devretme süresi. Tespit olayından devretme duyurusuna kadar geçen süre. Otomatikleştirilmişse taahhüt edilebilir bir büyüklüktür.
• Azaltmaya geçiş süresi. Devretmeden azaltma politikasının uygulanmasına kadar geçen süre. Ölçüm noktasının nerede olduğunu sözleşmeye yazın.
• Yanlış pozitif bildirimine ilk müdahale süresi. Yanlış pozitif oranı taahhüt edilemez; bir mühendisin politikaya bakmasına kadar geçen dakika sayısı taahhüt edilebilir. Kimin bildirim yapmaya yetkili olduğunu ve kimliğinin nasıl doğrulanacağını da tanımlayın.
• Hizmetin kendi erişilebilirliği. Temizleme platformunun ve panelin erişilebilirliği, müşterinin kendi hizmetinin erişilebilirliğinden farklı bir şeydir. İkisini ayrı ayrı yazın.

Taahhüt edilemeyecekler de aynı netlikte yazılmalıdır: her saldırının durdurulacağı, hiçbir meşru isteğin etkilenmeyeceği, son kullanıcı deneyiminin bozulmayacağı ve kenar kapasitenizin üzerindeki bir saldırının azaltılacağı. Bunların yanına ölçümün mekaniğini de koyun: hangi saat ne zaman başlar, hangi tarafın telemetrisi esas alınır, hangi durumlar kapsam dışıdır (bakım pencereleri, müşteri tarafındaki yapılandırma hataları, ilan edilmiş eşiğin üzerindeki olaylar) ve ihlal halinde ne uygulanır. Pratikte uygulanan şey aylık bedelle sınırlı bir hizmet kredisidir; bunu baştan söylemek, belirsizliği bir uyuşmazlık sırasında keşfetmekten iyidir.

Tedarik, bağımlılık ve yaşam döngüsü ölçütleri

Bir azaltma platformu uzun ömürlü bir varlıktır ve üretici ilişkisinin ürünle hiç ilgisi olmayan nedenlerle kesilebildiği bir pazarda çalışır. Bu, dipnota değil puanlama matrisine ait bir konudur.

Şartnameye yazılacak somut sorular:

• Çekirdek tespit, üretici bulutuna erişim olmadan çalışıyor mu? Cevap hayırsa, aslında bir hizmet bağımlılığı satın almışsınızdır; elinizde bağımsız çalışan bir cihaz yoktur. Fiyatlaması da risk değerlendirmesi de buna göre yapılmalıdır.
• Lisans süresi dolduğunda tam olarak ne kapanıyor? Azaltmanın kendisi mi, yoksa yalnızca özellik güncellemeleri mi? Davranışı yazılı isteyin, niyeti değil.
• İhracat lisansı ve yaptırım riski. Bu ürünün tedarikini, desteğini ya da ödemesini hangi hukuk düzenleri kesintiye uğratabilir ve üreticinin sizin pazarınızda desteği sürdürmeye ilişkin belgelenmiş tutumu nedir?
• Bölgenizdeki yedek parça, RMA ve temin süreleri. Yedek parça deposu nerede, değişim taahhüdü nedir ve bir sevkiyat kesintisinde ayakta kalır mı?
• Destek dili, saat dilimi ve eskalasyon. Yerel saatle gecenin üçünde yaşanan bir olayda telefonu kim açıyor, hangi dilde açıyor ve kayıt açmakla yetinmeyip davranışı değiştirebilecek bir mühendise kaç dakikada ulaşılıyor?
• Zaten işlettiğiniz arayüzler. Hangi akış telemetrisi sürümleri tüketiliyor, hangi BGP özellikleri destekleniyor, API var mı, mevcut kimlik doğrulamanızla bütünleşiyor mu ve mevcut log ile izleme sisteminize aktarım yapıyor mu?

Bu maddelerin toplam maliyet üzerindeki etkisi cihaz fiyatından daha büyük olabilir; kalem kalem hesabı yerinde bir DDoS cihazının toplam sahip olma maliyeti rehberinde duruyor.

Teklifleri puanlamak

İyi seçen bir ihaleyi, en iyi yazılmış teklifi seçen bir ihaleden iki alışkanlık ayırır.

Birincisi, kabul testlerinin üreticinin gösterimiyle değil kendi trafik profilinizle yapılmasıdır. Gerçek üretim trafiğinin temsili bir dilimini aynalayın, saldırı testlerini en küçük paket boyuyla çalıştırın, asgari bir set yerine üretimde çalıştırmayı planladığınız karşı önlem setini etkinleştirin ve hem azaltma davranışını hem de aynadaki meşru trafik üzerindeki yanlış pozitif etkisini birlikte ölçün. Bir platformun her şey açıkken verdiği rakamlar, satın aldığınız şeyi tarif eden tek rakamlardır.

İkincisi, ölçütlerin ağırlıklarının teklifler gelmeden önce belirlenmesidir. Ağırlıklar sonradan belirlenirse, onları teklifler belirler. Bir operatör için savunulabilir bir ağırlık dağılımı kiracılık ve raporlama katmanına, asimetri cevaplarına, devretme ve geri çekme mekaniğine ve tedarik ile bağımlılık sorularına gerçek bir ağırlık verir; başlıktaki işleme kapasitesini ise geçilmesi gereken bir eşik olarak ele alır, en yüksek puanı toplamaya çalışılacak bir eksen olarak değil. Kendi kenar kapasitenizin üstündeki bir kapasite size hiçbir şey kazandırmaz.

Son olarak, benzer büyüklükte ve benzer düzenleyici koşullarda çalışan iki operatörden referans isteyin ve onlara tekliflerin hiçbir zaman cevaplamadığı tek soruyu sorun: platform ilk ciddi yanlış pozitifini ürettiğinde ne yaptı ve düzeltmek ne kadar sürdü?

İhale metnine aktarılacak şartname listesi

Aşağıdaki maddeleri şartnameye kopyalayın ve her birine yazılı cevap isteyin.

Kapasite ve performans

1. Saniyede bit ve saniyede paket cinsinden azaltma kapasitesi, operatörün üretimde çalıştırmayı planladığı karşı önlem seti açıkken.
2. Paket oranı sınırına ulaşıldığında davranış ve bozulma biçimi.
3. Kenar yönlendiricilerden azaltma platformuna gereken taşıma kapasitesi.
4. Aynı anda azaltma altında tutulabilecek kiracı sayısı ve bu sayının arkasındaki kaynak modeli.
5. Operatörün kendi aynalanmış trafiğiyle, gerçekçi en küçük paket boyunda yapılan kabul testleriyle doğrulanmış performans rakamları.

Yönlendirme ve devretme

6. Rota enjeksiyonu için BGP oturum modeli: kimlik doğrulama, azami ön ek sınırı, ön ek uzunluğu filtreleri ve devretme rotalarının community ile etiketlenmesi dâhil.
7. Kontrolcü arızası, yeniden başlaması ya da yönetim bağlantısını kaybetmesi durumunda duyurulmuş devretme rotalarının davranışı; rotaların otomatik olarak süresinin dolup dolmadığı.
8. Desteklenen geri dönüş yolu mekanizmaları ve kapsüllemenin donanımda yapılıp yapılmadığı.
9. Planlanan devretme duyurusunun RPKI köken doğrulaması altında geçerli kaldığının teyidi ve ROA maxLength sonuçlarının belgelenmesi.
10. RTBH sinyalleşmesi desteği; her yukarı akış sağlayıcısının kabul ettiği community listesi, kabul edilen ön ek uzunlukları ve taahhüt edilen tepki süreleri.
11. RFC 8955 ve RFC 8956 desteği; operatörün hat kartı envanterinde donanımda çalıştığı üretici tarafından teyit edilmiş eşleşme ve eylem bileşimlerinin listesi.
12. FlowSpec kural üst sınırı, otomatik süre dolumu, kiracı başına kapsamlandırma, denetim izi ve acil durdurma anahtarı.
13. Kendi yerinde cihazı olan müşterilere doğru DOTS sinyalleşmesi desteği (RFC 8811, RFC 9132, RFC 8783).

Tespit ve inceleme

14. Tüketilen akış telemetrisi sürümleri ve tespit gecikmesinin alt sınırını belirleyen dışa aktarım zamanlayıcısı varsayımları.
15. Kiracı başına temel çizgi öğrenimi ve öğrenmeye giren verinin denetlenip ayıklanabilmesi.
16. İki yönün de aynı noktadan görülmesini gerektiren karşı önlemlerin açık listesi.
17. El sıkışma hiç gözlemlenmediğinde varsayılan davranış.
18. Küme içindeki yük dağıtım modeli (akış bazlı olmalıdır) ve küme üyeleri arasında parça işleme davranışı.
19. Durum modeli, oturum tablosu kapasitesi, tükenme davranışı ve kiracı başına durum sınırları.

Çok kiracılılık ve raporlama

20. Paylaşılan donanım üzerinde kiracı başına ayrı temel çizgi, ayrı eşik seti, ayrı karşı önlem sırası ve ayrı beyaz liste.
21. Politika şablonları; kiracı sayısının elle yazılmış yapılandırma sayısına dönüşmemesi.
22. Kiracılar arasında kaynak bölümlemesinin belgelenmesi: durum, kural ve işleme bütçesi.
23. Yalnızca o kiracının ön eklerine kapsamlanmış kiracı paneli; saldırı zaman çizelgesi, vektör dağılımı, düşürülen ve geçirilen hacim, dışa aktarım ve rol tabanlı yetkilendirme.
24. Kiracı tarafındaki entegrasyon için API ve panelle raporların beyaz etiketlenebilmesi.

Ticari, tedarik ve yaşam döngüsü

25. Çekirdek tespitin üretici bulutuna erişim olmadan çalışıp çalışmadığı.
26. Lisans süresi dolduğunda tam olarak hangi yeteneklerin kapandığı.
27. Tedariki, desteği ya da ödemeyi etkileyen ihracat lisansı ve yaptırım riski.
28. Operatörün bölgesi için yedek parça konumu, RMA taahhüdü ve temin süreleri.
29. Destek dili, çalışma saatleri, eskalasyon yolu ve davranışı değiştirme yetkisi olan bir mühendise ulaşma süresi.
30. Operatörün ilan ettiği koruma eşiği, bu eşiğin üzerinde ne yapılacağı ve bunun müşteri sözleşmesine nasıl yansıdığı.

Kaynaklar ve ileri okuma

Aşağıdaki metinlerin hepsi ihale sırasında masada bulunmaya değer gerçek standart ve rehber belgelerdir. Bu makaledeki hiçbir rakam bunlardan alınmamıştır; yukarıdaki tek sayısal örnek açıkça temsilîdir ve kendi telemetrinizle yeniden hesaplanmalıdır.

Akış telemetrisi. IPFIX protokolü için RFC 7011 ve bilgi modeli için RFC 7012. sFlow’un güncel sürümü bir IETF standardı değil sFlow.org spesifikasyonudur; şartnamede sürüm ve davranış beyanını üreticiden ayrıca isteyin.

Yönlendirme ve devretme. BGP işletim ve güvenliği için RFC 7454 (BCP 194); uRPF ile kaynak tabanlı uzaktan tetiklenen blackhole için RFC 5635; BLACKHOLE community için RFC 7999.

FlowSpec. IPv4 için RFC 8955, IPv6 için RFC 8956. Kural doğrulama yordamı ve tanımlı eylem kümesi bu metinlerdedir; kendi platformunuzun hangi alt kümeyi donanımda desteklediğini üreticinizden ayrıca teyit edin.

Yönlendirme güvenliği. Ön ek köken doğrulaması için RFC 6811 ve maxLength kullanımı için RFC 9319 (BCP 185). Kaynak adres doğrulaması için RFC 2827 (BCP 38) ve çok bağlantılı ağlarda giriş filtreleme için RFC 3704 (BCP 84). MANRS, bu maddelerin operatör taahhüdüne dönüştürülmüş halidir.

Standart tabanlı azaltma sinyalleşmesi. DOTS mimarisi için RFC 8811, sinyal kanalı için RFC 9132 ve veri kanalı için RFC 8783.

Analist raporları. Satın alma süreciniz üçüncü taraf doğrulaması gerektiriyorsa, güncel ağ güvenliği ve DDoS azaltma değerlendirmelerini analiz kuruluşlarından doğrudan isteyin ve yukarıdaki ölçütlere göre okuyun. Görmediğiniz bir raporun üretici tarafından yapılmış özetini kabul etmeyin.