İSS'ler ve Hosting Firmaları için Scrubbing Merkezi Kurulumu: Adım Adım

Bir temizleme merkezi kurmak, bir cihaz satın alıp rafa takmak değildir. Cihaz, projenin tahmin edilebilir ve en kolay kısmıdır. Zor kısım, o cihaza trafiği nasıl getireceğiniz, temizlenmiş trafiği müşteriye nasıl geri vereceğiniz, kimin ne zaman devretme kararı vereceği ve bütün bunları kaç müşteri için aynı anda yapabileceğinizdir.

Bu makale, Türkiye’de bir İSS, hosting sağlayıcısı ya da veri merkezi işletmecisi olarak kendi temizleme merkezini kuracak ekipler için yazıldı. Yatırım kararının kendisi, yani hangi adımların sermaye gerektirmeden yapılabileceği ve cihaz almanın hangi noktada anlamlı hale geldiği, bütçesi kısıtlı operatörler için ayrı bir rehberde ele alınıyor. Sıra, gerçek bir kurulumun sırasıdır: önce topoloji, sonra tespit, sonra devretme ve geri dönüş, sonra kapasite, sonra çok kiracılılık, en sonunda da bunu bir hizmete çeviren ticari ve operasyonel katman.

Adım 1: Topoloji Kararı

Bütün diğer kararlar bu kararın altında şekillenir, o yüzden önce burada net olmak gerekir.

Sürekli hat üstü (inline) tasarımda temizleme donanımı trafik yolunun içindedir. Kenar yönlendirici ile toplama katmanı arasına, ya da müşteri toplama noktasına yerleştirilir. Her paket her zaman oradan geçer. Kazandığınız şey sadeliktir: devretme diye bir adım yoktur, duyurulacak bir ön ek, yakınsayacak bir yönlendirme tablosu, çözülecek bir geri dönüş sorunu yoktur. Saldırı başladığı anda azaltma zaten yürürlüktedir.

Ödediğiniz bedel de aynı ölçüde nettir. İşleme kapasitesini, o noktadan geçen tüm trafiğe göre satın alırsınız. Fiyatı belirleyen büyüklük, günlük hattınızın toplamıdır. Eşzamanlı saldırı yükü bu hesabın dışında kalır. Cihaz artık gündelik trafiğinizin arıza noktalarından biridir. Optik baypas ya da yazılım baypası kurmak, baypasın devreye girme koşullarını tanımlamak ve bunu test etmek zorunludur. Yazılım yükseltmesi artık bir bakım penceresi olmaktan çıkar, tüm müşterilerinizi etkileyen bir değişiklik olur. Kenar kapasitesi büyüdükçe bu modelin maliyeti doğrusal olarak büyür.

Hat dışı (out-of-path) tasarımda temizleme merkezi normalde trafik yolunun dışındadır. Kenar yönlendiricilerden gelen akış telemetrisiyle saldırı tespit edilir, yalnızca hedef müşterinin ön eki temizleme merkezine devredilir, temizlenen trafik müşteriye geri verilir. Kazandığınız şey ekonomidir. Kapasiteyi, aynı anda taşımayı göze aldığınız saldırı yüküne göre boyutlandırırsınız. Maliyeti belirleyen rakam budur. Toplam trafiğiniz bu hesaba girmediği için donanım küçük kalır. Temizleme kümesinin arızası da gündelik trafiği etkilemez.

Ödediğiniz bedel üç kalemdir. Birincisi süredir: tespit, karar, duyuru ve yakınsama adımları toplamı sıfır olmayan bir devretme süresi üretir. İkincisi geri dönüş yolunun karmaşıklığıdır ve bu makalenin en uzun bölümü ona ayrılmıştır. Üçüncüsü asimetridir: devretme sırasında gelen trafik temizleme merkezinden, giden trafik normal yoldan akar.

Pratikte operatörlerin çoğu hat dışı tasarımla başlar, çünkü kenar kapasitesi kadar temizleme kapasitesi satın almak ilk günden savunulabilir bir yatırım değildir. Hat üstü tasarım genellikle ikinci aşamada ve seçici olarak gelir: en yüksek değerli birkaç müşterinin toplandığı noktaya, ya da tek bir barındırma bloğunun önüne konur.

Adım 2: Tespit

Hat dışı bir tasarımda tespit, sistemin geri kalanının üzerine kurulduğu temeldir. Göremediğiniz saldırıyı devredemezsiniz.

Akış telemetrisi ve örneklemenin bedeli

Kenar yönlendiricilerden üç tür telemetri alırsınız. NetFlow ve onun standartlaşmış halefi IPFIX, yönlendiricide akışları toplar ve kaydı akış bittiğinde ya da aktif akış zaman aşımı dolduğunda dışa aktarır. sFlow ise akış tutmaz. Paketleri belirli bir oranda örnekler, örneklenen paketin başlığını arayüz sayaçlarıyla birlikte hemen gönderir.

Bu fark, tespit gecikmesi açısından belirleyicidir ve tasarımlarda sıkça atlanır. NetFlow veya IPFIX kullanıyorsanız, gecikmenizin alt sınırını, örnekleme oranı değil yönlendiricinin aktif akış zaman aşımı belirler: kayıt o süre dolmadan koleksiyona ulaşmaz. Zaman aşımını kısaltmak dışa aktarım hacmini, koleksiyon yükünü ve yönlendiricinin kontrol düzlemi üzerindeki baskıyı artırır. sFlow’da bu bekleme yoktur, ama elinizde akış kaydı değil paket örneği vardır. Akış benzeri bir görünüm istiyorsanız onu koleksiyon tarafında siz kurarsınız.

Örnekleme oranının etkisi ise başka bir eksende ortaya çıkar. Yüksek hızlı arayüzlerde örnekleme kaçınılmazdır. Sorun, oranın büyüdükçe küçük hacimli saldırıları görünmez kılmasıdır. Yüz gigabitlik bir kenarda seyrek örneklemeyle çalışıyorsanız, tek bir müşteriye yönelen birkaç yüz megabitlik bir saldırı, istatistiksel olarak anlamlı bir sinyal üretecek kadar örneklenmeyebilir. Ürettiğinde de bu, uzun bir gözlem penceresinin sonunda olur. Sonuç şudur: örnekleme oranı aynı anda hem yönlendirici yükünü hem de tespit edebileceğiniz en küçük saldırının büyüklüğünü belirler.

Buradan iki pratik sonuç çıkar. Birincisi, tek bir örnekleme oranı tüm ağ için doğru cevap değildir. Müşteri toplama noktalarında daha yoğun, saf transit taşıyan çekirdek arayüzlerde daha seyrek örnekleme makul bir dengedir. İkincisi, uygulama katmanı saldırıları ve düşük hızlı tükenme saldırıları akış telemetrisiyle pratikte tespit edilemez. Bunlar için ya hat üstü inceleme ya da müşteri tarafındaki sunucu telemetrisi gerekir. Akış tabanlı bir sisteme bu yeteneği vadetmek yanlış olur.

Temel çizgi öğrenimi

Eşiklerin anlamlı olması için önce normalin ne olduğunu bilmek gerekir. Temel çizgi öğrenimi, her korunan ön ek için protokol, port ve yön kırılımında bit hızı, paket hızı ve akış sayısı profillerinin zaman içinde çıkarılmasıdır. İşe yarar bir temel çizginin haftanın gününü ve günün saatini içermesi gerekir. Salı öğleden sonrasının normali ile pazar gecesinin normali aynı değildir.

Üç pratik uyarı. Birincisi, öğrenme penceresi bir saldırı dönemine denk gelirse saldırıyı normal olarak öğrenirsiniz. Öğrenmeye alınan verinin temizliğini denetleyebilmelisiniz. İkincisi, temel çizgi büyümeyi takip etmelidir, aksi halde büyüyen müşteri her ay yanlış pozitif üretir. Üçüncüsü ve en önemlisi, temel çizgi kiracı başına olmalıdır. Ağ genelinde tek bir temel çizgi, büyük bir müşterinin gündelik dalgalanmasının küçük bir müşteriye yönelen saldırıyı tamamen örtmesi anlamına gelir.

Eşik tabanlı mı, davranışsal mı

İki tetikleme yaklaşımı vardır ve birini seçmek zorunda değilsiniz.

Eşik tabanlı tetikleme basittir: ön ek başına bit hızı, paket hızı ya da yeni akış sayısı belirli bir değeri aşarsa devret. Öngörülebilir, denetlenebilir ve bir olay sonrasında savunulabilir. Zayıflığı, müşteri başına ayarlanmak zorunda olması ve zamanla eskimesidir.

Davranışsal tetikleme, öğrenilmiş temel çizgiden sapmaya bakar. Mutlak olarak küçük ama o müşteri için anormal olan saldırıları yakalar ve yeni vektörlere karşı daha dayanıklıdır. Zayıflığı, meşru ama olağandışı olayları saldırı sanmasıdır: bir kampanya, bir oyun sürümü, bir canlı yayın, bir yedekleme penceresi ya da bir CDN’in önbellek doldurması.

Sahada işe yarayan kurgu ikisinin birleşimidir. Davranışsal tetik orta bölgeyi yakalar. Mutlak bir üst eşik, temel çizgi ne derse desin devretmeyi zorlar. Mutlak bir alt taban ise çok küçük müşterilerin sürekli tetiklemesini engeller. Buna bir de doğrulama adımı ekleyin: tetik oluştuğunda birkaç saniyelik ikinci bir pencerede sinyalin sürüp sürmediğine bakın. Anlık bir sıçrama için devretmek, saldırıdan daha çok zarar verebilir.

Adım 3: Devretme Mekaniği

Daha uzun ön ekin duyurulması

Devretmenin temel mekanizması en uzun ön ek eşleşmesidir. Müşterinizin ön ekini, temizleme merkezinden daha uzun bir ön ek olarak iç yönlendirmenize duyurursunuz. Ağınızdaki yönlendiriciler o ön eke ait trafiği artık temizleme merkezine gönderir. Kendi AS’inizin içinde bunu istediğiniz uzunlukta yapabilirsiniz, çünkü duyuruyu kimseye dışa vermezsiniz.

Duyuruyu AS sınırının dışına taşımak gerektiğinde tablo değişir. Diğer operatörlerin ön ek filtreleri yaygın olarak IPv4’te /24’ten, IPv6’da /48’den uzun ön ekleri kabul etmez. Bu bir standart olmaktan çok yerleşmiş bir işletme pratiğidir, ama sizin açınızdan sonucu bağlayıcıdır. Dışarıya devretme yapacaksanız, korumak istediğiniz adresleri bu sınırın izin verdiği bloklara göre planlamanız gerekir. Müşterilerine tek tek IP adresi veren bir hosting sağlayıcısı için bu, adres planının en baştan koruma birimi düşünülerek yapılması demektir.

Yukarı akışa community ile sinyalleşme

Yukarı akış katmanına söyleyebileceğiniz şeyler, sağlayıcının kabul ettiği community kümesiyle sınırlıdır. Her yerde bulunan tek ilkel araç RTBH’dir: bir ön eki blackhole community’siyle duyurursunuz ve sağlayıcı o hedefe giden tüm trafiği kendi kenarında düşürür. RFC 7999 bunun için iyi bilinen bir community tanımlar. Hedef tabanlı yöntemin kendisi RFC 3882’de, kaynak tabanlı varyantı uRPF ile birlikte RFC 5635’te anlatılır.

RTBH’nin ne olduğu konusunda dürüst olmak gerekir: bu bir koruma sağlamaz, bir feragattir. Saldırıyı durdurmak için hedefi kapatırsınız. Ağınızın geri kalanını ve diğer müşterilerinizi korur, saldırıya uğrayan müşteriyi korumaz. Buna rağmen her operatörün cebinde olması gereken araçtır, çünkü kenar kapasitenizi aşan bir saldırıda elinizde kalan tek gerçek seçenektir.

Bunun ötesindeki her şey sağlayıcıya özgüdür. Bazı transit sağlayıcılar coğrafi filtreleme, protokol bazlı sınırlama ya da kendi temizleme hizmetlerine yönlendirme için community tanımlar. Bunların listesini, hangi ön ek uzunluklarında çalıştıklarını ve tepki sürelerini sözleşme aşamasında isteyin. Olay anında öğrenilecek bir konu değildir.

Geri dönüş yolu: çoğu tasarımın hata yaptığı yer

Şimdi asıl mesele. Müşterinin ön ekini daha uzun bir ön ek olarak temizleme merkezinden duyurdunuz. Ağınızdaki her yönlendirici artık o trafiği temizleme merkezine gönderiyor. Temizleme merkezinin kendisi de temizlediği trafiği müşteriye ulaştırmak için bir sonraki adımı arayacak ve aynı yönlendirme tablosuna bakacak. Sonuç, temizleme merkezinden çıkan temiz trafiğin tekrar temizleme merkezine dönmesidir: bir yönlendirme döngüsü.

Bu, egzotik bir uç durum sayılmaz. Hat dışı her tasarımın varsayılan davranışıdır. Çözüm her zaman aynı fikirdir: geri dönüş rotasını devretme duyurusundan yalıtmak. Uygulamada üç yol vardır.

GRE tüneli. Temizleme merkezinden müşterinin yönlendiricisine ya da müşteriyi taşıyan PE yönlendiricisine bir GRE tüneli kurarsınız ve temiz trafiği bu tünelden gönderirsiniz. Tünelin içindeki trafik, dışarıdaki yönlendirme kararından etkilenmez. En büyük avantajı bağımsızlığıdır: müşteri sizin ağınızda olmasa bile çalışır, üreticiden ve omurga teknolojisinden görece bağımsızdır, hızlı devreye alınır. Bedeli üç yerden çıkar. Kapsülleme başlığı MTU’yu düşürür, bu da parçalanma ve PMTUD’ye bağımlılık demektir. Kapsüllemenin donanımda mı yazılımda mı yapıldığını yönlendirici modeline göre doğrulamanız gerekir, çünkü yazılımda yapılıyorsa tünel kapasitesi arayüz kapasitesiyle ilgisiz bir yerde tıkanır. Müşteri sayısı arttıkça tünel sayısı da artar. En sık yapılan hata ise şudur: tünelin uzak uç adresi, devrettiğiniz ön ekin içinde kalırsa döngüyü ortadan kaldırmamış, sadece bir katman derine taşımış olursunuz. Tünel uç noktaları, devretme kapsamı dışında kalan ayrı bir adres alanından seçilmelidir.

VRF ve MPLS ile geri dönüş. MPLS omurgası olan operatörlerde daha temiz olan yol budur. Devretme duyurusu global yönlendirme tablosunda yaşar. Temiz trafik ise ayrı bir “temiz” VRF’e konur ve bu VRF’in tablosunda müşterinin devredilmemiş rotası vardır. Temizleme merkezi trafiği bu VRF’e verir, MPLS omurgası müşteriyi taşıyan PE’ye taşır, PE de müşteri arayüzünden çıkarır. Kapsülleme kaynaklı MTU sorunu yoktur, mevcut L3VPN makinesini kullandığı için ölçeklenir ve kiracı ayrımı zaten yerleşiktir. Bedeli, yalnızca kendi MPLS alanınızda çalışması ve yapılandırmanın rota içe/dışa aktarma politikalarına bağlı olmasıdır. Hataların büyük bölümü de tam olarak orada, yanlış yazılmış bir import/export kuralında ortaya çıkar.

Politika tabanlı yönlendirme. Geri verme yönlendiricisinde, temizleme merkezinden gelen trafiği kaynak arayüze ya da bir işarete göre eşleştirip normal yönlendirme kararını atlayarak doğrudan müşteri arayüzünden çıkarırsınız. Kurulumu en hızlı, anlaşılması en kolay yoldur. Ölçeklenmez: her geri verme noktasında elle yazılmış kurallar birikir, donanım filtre kaynağı sınırlıdır, ECMP ve yedeklilik davranışı bozulabilir ve bir kuralın unutulması geri dönüşten sonra trafiğin yanlış yoldan akmasına yol açar. Tek noktadan hizmet veren küçük bir kurulum ya da laboratuvar için makul, satılabilir bir hizmetin temeli olarak değil.

Cihaz	GRE tüneli	VRF / MPLS geri dönüş	Politika tabanlı yönlendirme
Nerede çalışır	Kendi ağınızda da, üçüncü taraf ağların üzerinden de	Yalnızca kendi MPLS alanınızın içinde	Yalnızca tek bir geri verme yönlendiricisinde
MTU ve parçalanma	Kapsülleme başlığı kadar MTU kaybı, PMTUD'ye bağımlılık	MPLS MTU doğru ayarlanmışsa sorun çıkarmaz	Kapsülleme yok, MTU değişmez
Ölçeklenme	Kiracı başına tünel; sayı arttıkça durum ve yönetim yükü büyür	L3VPN makinesi zaten ölçekli; içe/dışa aktarma politikasıyla büyür	Ölçeklenmez; birkaç müşteriden sonra elle sürdürülemez
Donanım bağımlılığı	Kapsülleme donanımda mı yazılımda mı yapılıyor, kontrol edin	MPLS'in uçtan uca kesintisiz olması gerekir	Donanım filtre kaynağı sınırlıdır, ECMP'yi bozabilir
Tipik hata modu	Tünel uç noktası devretmiş ön ekin içinde kalır ve döngü oluşur	Rota sızdırma politikası yanlış yazılır, temiz trafik global tabloya döner	Kural bir yönlendiricide unutulur, geri dönüşten sonra trafik yanlış yoldan akar
Ne zaman doğru seçim	Müşteri sizin ağınızda değilse ya da hızlı devreye almanız gerekiyorsa	MPLS omurgası olan operatörlerde varsayılan tercih	Tek noktadan hizmet veren küçük kurulumlarda ve laboratuvarda

Üç mekanizma birbirinin alternatifi sayılmaz; çoğu operatör MPLS omurgasında VRF geri dönüşünü varsayılan yapar ve ağının dışındaki müşteriler için GRE'yi elde tutar. Belirleyici soru, geri dönüş rotasının devretme duyurusundan nasıl yalıtıldığıdır; performans değil.

RPKI ve ön ek uzunluğu: devretmenin sessiz engeli

Devretme duyurusunu AS sınırının dışına taşıyacaksanız, çoğu tasarımın kurulum sırasında fark etmediği bir engel daha var. Ön ekleriniz için yayımladığınız ROA kayıtlarında maxLength değeri, devretme sırasında duyurmayı planladığınız daha uzun ön eki kapsamıyorsa, o duyuru köken doğrulaması yapan operatörlerde geçersiz sayılır ve düşürülür. Yani tam da saldırı anında, en çok ihtiyaç duyduğunuz duyuru internet tarafından kabul edilmez.

Bu, RFC 9319’un maxLength değerlerini asgaride tutma tavsiyesiyle doğrudan gerilim içindedir. İki gereksinim birlikte planlanmak zorundadır: hangi ön ekleri hangi uzunlukta duyurmayı planlıyorsanız ROA’larınız buna göre yazılmalı ve bu karar, yönlendirme güvenliği tarafıyla mutabık kalınarak verilmelidir. Kurulum kabul testlerinize “devretme duyurusu dış dünyada geçerli görünüyor mu” maddesini koyun.

Adım 4: BGP FlowSpec

FlowSpec, BGP üzerinden n-tuple eşleşme kuralları dağıtmanızı sağlar: hedef ve kaynak ön eki, protokol, port aralıkları, paket uzunluğu, parça bilgisi, 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 açıktır. Bir yansıtma saldırısını, tüm trafiği temizleme merkezine taşımadan, doğrudan kenar yönlendiricide ve donanım hızında kesebilirsiniz. Temizleme merkezinize giden taşıma kapasitesini korumuş olursunuz. Bu, kapasite planlamasının en pahalı kalemlerinden birini rahatlatır.

Temkinin sebepleri de aynı ölçüde somuttur:

• Hatalı kural anında yayılır. Yanlış yazılmış bir eşleşme, saniyeler içinde tüm kenara dağılır ve meşru trafiği ağ genelinde düşürür. Geri almak da aynı hızda olur, ama zarar çoktan gerçekleşmiştir.
• Donanım kural kapasitesi sınırlıdır. Kural sayısı hat kartının filtre kaynağını aştığında davranış üretici ve platforma göre değişir. Öngörülemezlik başlı başına bir risktir. Kaç kuralın gerçekten donanımda çalıştığını kendi platformunuzda ölçmeden üst sınır belirlemeyin.
• AS’ler arası işletme kırılgandır. RFC 8955’teki doğrulama yordamı, kuralın hedef ön ekine ait en iyi unicast rotanın geldiği komşuyla ilişkilendirilmesini gerektirir. 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 farkları vardır. Hangi eşleşme ve eylem bileşimlerinin desteklendiği üreticiden üreticiye değişir. Laboratuvarınızın üretimdeki hat kartı çeşitliliğini yansıtması gerekir.
• Transit sağlayıcıların çoğu müşteriden kural kabul etmez. Kabul edenler de dar bir alt küme sunar. Yukarı akışa karşı evrensel araç hâlâ RTBH’dir.

Pratik kurgu şudur: FlowSpec’i önce ve öncelikle kendi AS’inizin içinde işletin. Kural sayısına sert bir üst sınır koyun, her kurala otomatik süre dolumu tanımlayın, üretim kuralları için iki kişilik onay şartı getirin ve yürürlükteki kural setini raporlanabilir hale getirin. Yukarı akışa karşı FlowSpec’i bir bonus olarak planlayın, temel tasarımın taşıyıcı unsuru olarak değil.

Adım 5: Kapasite planlaması

Kendi kenarınıza göre, müşteri hattına değil

Kurulumların en yaygın boyutlandırma hatası, temizleme kapasitesini müşterilerin hat büyüklüklerine bakarak belirlemektir. Müşterinin hattı, saldırının ne kadarının ona ulaşacağını sınırlar; size ne kadarının ulaşacağını değil. Sizin ilgilendiğiniz rakam, peering ve transit portlarınızın toplamı üzerinden ağınıza fiziksel olarak girebilecek trafiktir.

Bunun yanında, sık atlanan üç sınır daha vardır.

Temizleme merkezine giden taşıma kapasitesi. Devrettiğiniz trafik kenar yönlendiricilerden temizleme merkezine omurga üzerinden taşınır. Temizleme kümesinin etiket değerinden bağımsız olarak, oraya taşıyabildiğinizden fazlasını devredemezsiniz. Bu bağlantı çoğu tasarımda gerçek darboğazdır ve bütçede en kolay unutulan kalemdir.

Eşzamanlılık. Tek bir saldırının en büyük halini karşılayacak şekilde boyutlandırmak iyimserdir. Aynı anda kaç müşterinin saldırı altında olabileceğine dair bir varsayım yapın, bu varsayımı yazın ve kapasiteyi ona göre planlayın. Aynı kampanyanın birden çok müşterinizi aynı saatte hedeflemesi olağan dışı değildir.

Paket oranı. Bit hızı tek başına yanıltıcıdır. Küçük paketli saldırılar, bit hızı sınırına yaklaşmadan çok önce paket işleme sınırına çarpar. Kabul testlerini en küçük paket boyuyla yapın ve üreticiden paket oranı değerini yazılı isteyin, bit hızı değerini değil.

Sayısal bir örnek verelim. Bu temsilî bir hesaptır, kendi telemetrinizle yeniden yapmanız gerekir: kenarınızda toplam 200 Gbps dış kapasite, temizleme merkezine 2×100 Gbps taşıma ve tek bir temizleme kümesi varsa, ilan edebileceğiniz koruma seviyesinin üst sınırı bu üç rakamın en küçüğüdür, en büyüğü değil. Aynı anda iki müşteriyi korumayı taahhüt ediyorsanız, ikisinin toplamı da bu sınırın altında kalmalıdır.

Asimetrik trafik ve durum tutan incelemenin sınırı

Bu, operatör ölçeğinde en çok yanlış anlaşılan konudur. Birden çok transit ve peering noktası olan bir ağda, aynı oturumun gelen ve giden yönü farklı kenar yönlendiricilerden geçebilir; hot-potato yönlendirme bunu kural haline getirir, istisna değil. Hat dışı devretmede ise asimetri zaten tasarımın parçasıdır: yalnızca gelen yönü devredersiniz, giden yön normal yoldan akar.

Sonucu şudur: yalnızca tek yönü gören bir inceleme motoru gerçek anlamda durum 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ü fiilen kapatır.

Yapılabilecekler sırayla şunlardır:

1. Tek yönlü kanıtla çalışan yöntemleri temel alın. Cevabı cihazın kendisinin ürettiği doğrulama yöntemleri geri yönü görmeye ihtiyaç duymaz, çünkü cevabı cihaz kendisi verir ve meşru istemcinin tekrar denemesini bekler. Bu yöntemler arasında SYN cookie benzeri mekanizmalar, yeniden deneme davranışına dayalı kaynak doğrulama, protokol uyum kontrolleri ve hız sınırlama vardır.
2. Katı durum takibi gerektiren özellikleri sınırlayın. Bu özellikleri yalnızca trafiğin iki yönünün de aynı noktadan geçtiği yerleşimlerde, yani hat üstü kurulumlarda ya da trafiği tek bir noktaya sabitlediğiniz müşterilerde açın.
3. Simetriyi zorlamayı bilinçli bir maliyet kalemi olarak değerlendirin. Müşteriyi tek bir kenar noktasına sabitlemek ya da giden yönü de temizleme merkezinden geçirmek mümkündür, ama kapasite ve gecikme maliyeti yaratır. Bunu yalnızca gerektiren müşteriler için yapın, hepsine birden değil.
4. Kümenin içinde akış tutarlılığını koruyun. Temizleme kümesinde yük dağıtımı akış bazlı olmalıdır. Paket bazlı dağıtım, durum ve parça birleştirmeyi tek başına bozar.
5. Hizmet tanımında yazın. Hangi özelliklerin asimetrik trafikte devre dışı kaldığı, müşteriye satış öncesinde söylenmesi gereken bir bilgidir.

Adım 6: Çok Kiracılılık

Buraya kadar anlatılanların hepsini kurup çok kiracılılığı atlarsanız, elinizde iyi bir ağ hijyeni aracı olur. Fatura kesebileceğiniz bir hizmet olmaz. Farkı yaratan üç yetenek var.

Kiracı başına politika. Her müşterinin normali başkadır. Bir oyun sunucusu barındıran müşterinin UDP profili ile bir bankanın ağırlıklı olarak TCP/443 üzerinden akan profili aynı eşiklerle yönetilemez. Aynı donanım üzerinde müşteri başına ayrı temel çizgi, ayrı eşik seti, ayrı karşı önlem sırası ve ayrı beyaz liste tutabilmeniz gerekir. Politika şablonları üzerinden çalışmak, elli müşteriyi elli ayrı elle yazılmış yapılandırmaya dönüştürmeden bunu sürdürülebilir kılar.

Kiracılar arası yalıtım. Bir kiracıya yönelen saldırının, paylaşılan kaynakları tüketerek diğer kiracıların korumasını zayıflatmaması gerekir. Bu, oturum tablosu, kural kapasitesi ve işleme kaynağı düzeyinde kiracı başına sınır tanımlayabilmek demektir. Satın alma değerlendirmesinde sorulması gereken soru “bir kiracı diğerlerini nasıl etkileyebilir” sorusudur; “kaç kiracı destekliyor” değil.

Kiracı başına görü. Müşteri yalnızca kendi ön eklerini görebilmeli; saldırı zaman çizelgesini, vektör dağılımını, düşürülen ve geçirilen trafiği kendi panelinden izleyebilmeli; raporu dışa aktarabilmeli ve rol tabanlı yetkilendirmeyle ekibine açabilmelidir. Bir API, müşterinin kendi izleme sistemine bağlanmasını sağlar ve teknik müşteriler için satın alma kriteridir.

Bu üçüncü madde, ticari olarak en çok küçümsenen ve en çok fark yaratan maddedir. Müşteri temizleme motorunuzu görmez. Panelinizi görür. Saldırının durdurulduğunu gösteren okunaklı bir rapor, yenileme görüşmesinde motorun teknik üstünlüğünden daha ikna edicidir. Aynı rapor, müşterinin kendi denetimlerinde ve kendi regülatörüne karşı da kullanacağı belgedir.

Donanım seçiminde aranacak ölçüt buradan çıkar: paylaşılan donanım üzerinde kiracı başına ayrı koruma profili ve kiracı başına ayrı raporlama. Bu ölçütü karşılayan ürünler de vardır, karşılamayanlar da. Kriteri karşılamayan bir ürünle hizmet satmaya çalışmak, müşteri sayısı arttıkça işletilemez hale gelen bir yapılandırma yığını üretir.

Adım 7: Ticari Katman

Paketleme ve fiyat ekseni

İki eksen kullanılır ve ikisinin de bir zayıflığı vardır.

Temiz bant genişliğine göre kademelendirme, yani müşteriye teslim edilen temizlenmiş trafiğe göre fiyatlama, sizin maliyet yapınıza en yakın eksendir. Zayıflığı, müşterinin öngörmesinin zor olması ve saldırı anında faturanın büyümesidir. Bu da satış görüşmesinde itiraz üretir.

Korunan ön ek veya IP sayısına göre kademelendirme müşteri için öngörülebilir ve satılması kolaydır. Zayıflığı, fiyatı sizin maliyetinizden koparmasıdır: on adres için ödeme yapan bir müşteri, tek bir adrese gelen büyük bir saldırıyla maliyetinizin tamamını üretebilir.

Sahada işleyen kurgu genellikle ikisinin birleşimidir: giriş ekseni ön ek sayısı, üst sınır ise temiz bant genişliği. Buna ikinci bir kademe ekseni daha eklenir ve bu eksen çoğu zaman asıl marjı taşır: sürekli koruma mı, talebe bağlı koruma mı? Sürekli korumada müşterinin ön eki kalıcı olarak temizleme yolundan akar, devretme süresi ortadan kalkar. Bu, kapasiteyi sürekli meşgul ettiği için haklı olarak daha pahalıdır.

Dürüstçe taahhüt edilebilecek SLA maddeleri

Bir SLA’in değeri, kapsadığı şeylerden çok kapsamadığını açıkça söylemesindedir.

Taahhüt edilebilecekler, ölçtüğünüz ve kontrol ettiğiniz şeylerdir:

• Devretme süresi. Tespit olayının oluşmasından devretme duyurusunun yapılmasına 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. Bildirim geldiğinde kaç dakika içinde bir mühendisin politikaya bakacağı 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 hizmetinin erişilebilirliğinden farklı bir şeydir. İkisini ayrı ayrı yazın.

Taahhüt edilemeyecekler de aynı netlikte yazılmalıdır: saldırıların tamamı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ğı. Buna ek olarak ölçümün mekaniğini de tanımlayın: 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 kaynaklı yapılandırma hataları, ilan edilmiş eşiğin üzerindeki olaylar) ve ihlal halinde tazminatın biçimi nedir. Tazminat pratikte hizmet kredisidir ve aylık bedelle sınırlanır.

Kendi kapasitenizin üzerinde koruma vaat etme tuzağı

Bu, operatörlerin bu işe girerken yaptığı en pahalı hatadır. Pazarlama malzemesinde temizleme kümesinin etiket kapasitesini yazmak caziptir. Ama kenar kapasiteniz o rakamın altındaysa, o büyüklükte bir saldırı temizleme merkezine hiç ulaşmadan transit portlarınızı doldurur.

Zarar tek bir müşteriyle sınırlı kalmaz. Aynı portlardan geçen bütün müşterileriniz etkilenir, transit sağlayıcınıza karşı taahhüt ettiğiniz trafik profilinin dışına çıkarsınız ve pek çok transit sözleşmesindeki yüzde 95’lik dilim faturalamasında saldırı trafiği doğrudan maliyet olarak size döner. Yani kapasitenizin üzerinde vaat etmek yalnızca bir SLA ihlali olmakla kalmaz, aynı zamanda kendi maliyet tabanınıza açtığınız bir deliktir.

Doğru kurgu üç parçalıdır. İlan ettiğiniz koruma seviyesini gerçek kenar ve taşıma kapasitenizden türetin. Bu eşiğin üzerinde ne yapacağınızı önceden karara bağlayın: yukarı akışa RTBH, bir ortak temizleme sağlayıcısına taşma ya da FlowSpec ile kenarda dökme. Ve bu eşiği sözleşmeye yazın. İlan edilmiş bir blackhole eşiği zayıflık değil, olgunluk işaretidir. Müşteri hangi noktada ne olacağını bilerek satın alır ve olay anında sürpriz yaşamaz.

Adım 8: Operasyon

Koşu kitabı

Yazılı bir koşu kitabı olmadan bu hizmet satılamaz. Asgari içeriği şudur: tanımlı durumlar (izleme, doğrulama, devretme, azaltma, geri dönüş), her durum için kimin karar verme yetkisi olduğu, hangi adımların otomatik hangilerinin insan onaylı olduğu, her adım için hedef süre ve her adımda toplanacak kanıt. Kanıt maddesi süs değildir: müşteriye sunacağınız raporun ve bir uyuşmazlık halinde savunmanızın kaynağıdır.

Koşu kitabına politika değişikliği yönetimini de ekleyin. Olay sırasında yapılan ayar değişiklikleri sürüm kontrolü altında olmalı ve her müşteri için geri dönülebilecek bir “bilinen iyi” profil bulunmalıdır. Olayın ortasında yapılmış ve kimsenin geri almadığı bir değişiklik, bir sonraki olayın sebebidir.

Yukarı akışa hat dışı eskalasyon

Sağlayıcınıza ulaşmanın tek yolu saldırı altındaki hattın üzerinden geçiyorsa, elinizde bir eskalasyon prosedürü yoktur. Olay öncesinde kurulması gerekenler:

• Her yukarı akış sağlayıcısı için 7/24 ulaşılabilir bir NOC iletişim yolu ve hattan bağımsız ikinci bir kanal.
• Kimliğinizin nasıl doğrulanacağına dair önceden mutabık kalınmış bir yöntem. Saldırı anında telefonda kimlik doğrulaması yapmaya çalışmak dakikalar kaybettirir.
• Her sağlayıcının kabul ettiği community listesi, kabul edilen en uzun ön ek ve taahhüt edilen tepki süresi. Yazılı, güncel ve koşu kitabının ekinde.
• İletişim kayıtlarınızın kamuya açık kaynaklarda güncel olması: RIR nesnelerindeki iletişim bilgileri ve PeeringDB kaydınız. Size saldırıyı haber vermek isteyen başka bir operatörün ulaşabileceği tek yer burasıdır.

Geri dönüş ölçütleri

Devretmek işin kolay yarısıdır. Geri dönüş, tanımlı ölçütlere bağlanmadığında iki hata üretir: erken dönüp saldırıyı yeniden yemek ya da geç dönüp kapasiteyi ve gecikmeyi gereksiz yere taşımak.

Yazılı ölçüt seti şöyle kurulur: saldırı göstergesi belirlenmiş eşiğin altında kesintisiz belirli bir süre kaldıysa, aynı ön ek için o pencerede yeni bir tetik oluşmadıysa ve nöbetçi mühendis onay verdiyse geri dönülür. Geri dönüş kademeli olmalıdır: önce daha uzun ön ek duyurusu çekilir, yakınsama beklenir, azaltma politikası bir süre daha hazırda tutulur ve ancak ondan sonra normal duruma geçilir. Tetiklerin salınmasını önlemek için devretme ve geri dönüş eşikleri arasına histerezis koyun; aynı eşikle hem devreden hem geri dönen bir sistem, sınırdaki bir saldırıda dakikada bir devretmeye başlar.

Tatbikat

Test edilmemiş bir devretme prosedürü, bir prosedür değil bir varsayımdır. Düzenli tatbikatın kapsaması gerekenler:

1. Uçtan uca devretme ve geri dönüş, süre tutularak, gerçek geri dönüş mekanizmasıyla.
2. Temizleme merkezinin saldırı sırasında arızalanması senaryosu: baypas mı, blackhole mı, kim karar veriyor?
3. Hat dışı eskalasyon kanalının gerçekten çalıştığının doğrulanması; sağlayıcı tarafında telefonu kimin açtığı dâhil.
4. Müşteri panelinin ve raporlamanın olay sırasında beklendiği gibi çalışması. Müşterinin gördüğü tek şey budur.
5. Devretme duyurusunun dış dünyada geçerli görünüp görünmediği; özellikle ROA yapılandırmanız değiştiyse.

Tatbikatları müşterilerinizden en az biriyle birlikte yapın. Kendi ekibinizle yaptığınız tatbikat teknik yolu doğrular; müşteriyle yaptığınız tatbikat iletişim yolunu da doğrular ve gerçek olayda kaybedilen dakikaların çoğu iletişim yolunda kaybedilir.

Kurulum sırası, tek listede

1. Topolojiyi seçin ve gerekçesini yazın: hat dışı devretme ya da seçici hat üstü.
2. Telemetriyi kurun; örnekleme oranını ve dışa aktarım zamanlayıcılarını tespit hedefinize göre ayarlayın, ikisinin de bir maliyeti olduğunu bilerek.
3. En az birkaç hafta temel çizgi toplayın; öğrenmeye giren verinin temizliğini denetleyin.
4. Devretme mekanizmasını kurun ve önce geri dönüş yolunu çözün; GRE, VRF/MPLS ve PBR arasındaki seçimi bilinçli yapın, tünel uç noktalarını devretme kapsamı dışında tutun.
5. ROA’larınızı devretme sırasında duyuracağınız ön ek uzunluğuna göre gözden geçirin.
6. Yukarı akış sinyalleşmesini kurun: her sağlayıcı için RTBH, varsa ek community’ler, yazılı liste.
7. FlowSpec’i kendi AS’iniz içinde, kural üst sınırı ve otomatik süre dolumuyla devreye alın.
8. Kapasiteyi kenar, taşıma ve paket oranı sınırlarının en küçüğünden türetin; eşzamanlılık varsayımınızı yazın.
9. Kiracı başına politika, yalıtım ve raporlamayı kurun; hizmetin satılabilirliği buradan gelir.
10. Paketi, fiyat eksenini ve SLA’i yazın; ilan edilmiş bir üst eşik ve onun üzerinde ne yapılacağı dâhil.
11. Koşu kitabını yazın, hat dışı eskalasyon yollarını kurun, geri dönüş ölçütlerini tanımlayın.
12. Tatbikat yapın, sonuçlara göre koşu kitabını güncelleyin ve tatbikatı takvime bağlayın.

Kaynaklar ve ileri okuma

Aşağıdaki liste, kurulum sırasında masada bulunması gereken standart ve rehber metinlerdir. Rakam atfetmiyoruz; bu makaledeki tek sayısal örnek temsilîdir ve kendi telemetrinizle yeniden hesaplanmalıdır.

Akış telemetrisi. IPFIX protokolü için RFC 7011 ve bilgi modeli için RFC 7012; NetFlow sürüm 9 için bilgilendirme amaçlı RFC 3954; paket seçme ve örnekleme teknikleri için RFC 5475, PSAMP protokolü için RFC 5476. sFlow’un güncel sürümü bir IETF standardı değil sFlow.org spesifikasyonudur; RFC 3176 yalnızca daha eski bir sürümü bilgilendirme amacıyla belgeler.

Yönlendirme ve devretme. BGP işletim ve güvenliği için RFC 7454 (BCP 194); hedef tabanlı uzaktan tetiklenen blackhole için RFC 3882; uRPF ile kaynak tabanlı varyant için RFC 5635; BLACKHOLE community için RFC 7999. GRE için RFC 2784 ve anahtar/sıra numarası uzantıları için RFC 2890. MPLS tabanlı L3VPN ve VRF mimarisi için RFC 4364.

FlowSpec. IPv4 için RFC 8955, IPv6 için RFC 8956. Kural doğrulama yordamı ve desteklenen 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. RPKI mimarisi için RFC 6480, ROA formatı için RFC 6482, 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). Kurumsal bir çerçeve isteyen ekipler için NIST SP 800-189. MANRS, bu maddelerin operatör taahhüdüne dönüştürülmüş halidir.

Standart sinyalleşme. Kendi cihazı olan müşterilerle aranızdaki azaltma talebi sinyalleşmesini tescilli bir arayüze bağlamak istemiyorsanız bakılacak yer DOTS’tur: mimari için RFC 8811, sinyal kanalı için RFC 9132 ve veri kanalı için RFC 8783. Müşteri tarafında yerinde bir cihaz, sizin katmanınızla birlikte çalıştığında hibrit mimarinin operatör tarafındaki ayağını siz sağlamış olursunuz.