Kendi ASN'inizle DDoS koruması: LOA, IRR ve RPKI adımları

Satılan DDoS korumasının büyük kısmı tek bir varsayım üzerine kuruludur: sunucular sağlayıcının ağındadır, koruma da o ağın girişindedir. Kendi otonom sistem numarası (ASN) ve kendi IP bloğu olan kurumlar için ikinci bir model var. Blok, koruma sağlayıcısının ağı üzerinden duyurulur; kirli trafik orada durur, temiz trafik size iletilir. Sunucularınızın fiziksel olarak nerede durduğu belirleyici değildir.

Bu modelin teknik kısmı aslında kolaydır. Zor kısmı kayıtlardır — ve yanlış bir kayıt bloğunuzu korumasız bırakmaz, küresel olarak ulaşılamaz yapar. Aşağıda sıranın kendisi ve insanların tam olarak nerede tökezlediği var.

Model ne yapıyor

Bloğunuzun duyurusu Datafex ağı üzerinden yapıldığı andan itibaren, o bloğa yönelen bütün trafik önce bizim filtreleme katmanımıza ulaşır. Hacimsel saldırılar — DNS, NTP ve TCP yansıtma/yükseltme türleri — router seviyesinde kesilir. Sahte kaynak adresli paketler, botnet kaynaklı istek selleri ve projenize özel tanımladığınız kurallar Fexwall katmanında işlenir. Geriye kalan meşru trafik GRE tüneli ya da doğrudan bağlantı üzerinden altyapınıza iner.

Asıl kazanç filtrenin nerede durduğudur: saldırı sırasında hattınız dolmaz, çünkü kirli trafik hattınıza hiç gelmez. Kendi kenarınıza kurduğunuz bir güvenlik duvarı ne kadar iyi olursa olsun bunu yapamaz, paket o noktaya geldiğinde hattı zaten tüketmiştir. Katman ayrımını hiç düşünmediyseniz DDoS koruması nedir yazısındaki L3/L4 ile L7 farkı buradan öncesidir; bu yazı o ayrımı bildiğinizi varsayıyor.

Ön koşul: ASN ve en az /24

İki şeye birden ihtiyacınız var — kendi otonom sistem numaranız ve en az /24 büyüklüğünde bir IPv4 bloğu. İkincisi pazarlık konusu değil: küresel yönlendirme tablosunda /24'ten uzun prefix'ler operatörlerin büyük kısmı tarafından filtrelenir, yani /25 duyurmak pratikte duyurmamakla aynı sonucu verir. IPv6 tarafında yaygın kabul sınırı /48'dir.

Bu ikisinden biri eksikse model uygulanamaz. O durumda IP kiralama ya da hizmetleri doğrudan bizim altyapımızda çalıştırmak daha doğru sonuç verir; ASN'siz bir "BGP koruma" satan varsa satılan şey başka bir şeydir.

Dört kayıt, bu sırayla

Duyuru gününden önce bitmesi gereken iş listesi şudur:

1. ASN ve prefix doğrulaması. Bloğun büyüklüğü ve şu anda nereden duyurulduğu teyit edilir. Mevcut sağlayıcınızla olan bağlantı düzeni, geçişin nasıl kurgulanacağını belirler.
2. LOA (yetki belgesi). Bloğu kullanma ve duyurma yetkisinin sizde olduğunu gösteren belge hazırlanır. Bu belge teknik bir ayar değil, sağlayıcı tarafında filtre açılmasının dayanağıdır.
3. IRR kaydı. Bloğun route (IPv6 için route6) nesnesi, duyuruyu yapacak ASN'i gösterecek şekilde güncellenir. Bugün birçok operatör kabul ettiği duyuruları IRR kayıtlarından üretilen filtrelerle sınırlıyor; kaydı güncellenmemiş bir prefix bu filtrelere takılır.
4. RPKI ROA kaydı. Bloğunuz için tanımlı ROA'nın origin ASN'i ve maxLength değeri yeni duyuruyla birebir uyumlu hale getirilir.

Bu kayıtların yayılması saatler alabilir. Hepsinin duyuru gününden önce tamamlanmasının sebebi budur: kayıt güncellemesi ile duyuru aynı güne sıkıştırıldığında, ortaya çıkan sorunun kaynağını ayıklamak da imkânsızlaşır.

Neden RPKI son ve en kritik adım

ROA kaydınız yeni duyuruyla uyumlu değilse duyuru invalid olarak işaretlenir ve RPKI doğrulaması yapan operatörler trafiği hiç kabul etmez. Bu "daha az korunuyorum" değil, "o ağlardan bana hiç erişilemiyor" demektir — ve belirtisi kısmi olduğu için teşhisi zordur: bir bölgeden erişilirken diğerinden erişilemez, ping'iniz kendi ofisinizden düzgün çalışır.

İkinci sık hata maxLength değerini gereğinden geniş bırakmaktır. RPKI yalnızca iki şeye bakar: duyuruyu yapan ASN ve prefix uzunluğu. maxLength'i gerçekte duyurduğunuzdan uzun tutmak, sizin origin ASN'inizle yapılan ama sizin yapmadığınız daha uzun bir duyuruya da geçerli damgası vurur — yani bloğunuzun alt parçalarının başkası tarafından duyurulmasına kapı aralar.

Bu kayıtlar sizin RIPE hesabınıza bağlı olduğu için güncellemeyi siz yaparsınız; hangi değerin ne olması gerektiğini — origin ASN, maxLength, route nesnesi — biz veririz. Ayrıntısı için RPKI ve ROA nedir yazısına bakın.

Trafiğin size dönüş yolu

Temizlenmiş trafiğin altyapınıza nasıl ulaşacağı iki yoldan biriyle çözülür. Sunucularınız zaten bizim tarafımızdaysa — co-location ya da kabin kiralama ile — doğrudan bağlantı en basit yoldur. Başka bir lokasyondaysanız trafik GRE tüneliyle taşınır ve tünelin MTU ile MSS ayarları kurulumun parçası olarak konuşulur. Bunu kuruluma bırakmayın; GRE tüneli ve MTU yazısı bu ayarın atlanmasının neye benzediğini anlatıyor.

Duyuru günü: pencere, izleme, geri dönüş

Duyuru anlık bir şey değildir. Yeni bir duyurunun küresel olarak görünür hale gelmesi genellikle dakikalarla ölçülür; kayıt tarafındaki değişiklikler saatlere yayılabilir. Bu yüzden geçiş düşük trafikli bir pencereye alınır.

Geçiş sırasında üç şeye bakılır: bloğunuzun bağımsız gözlemcilerden — RIPE RIS, looking glass hizmetleri, kamuya açık BGP izleme araçları — görünür olup olmadığı, RPKI doğrulama durumunun valid okunup okunmadığı ve gerçek kullanıcı trafiğinin beklenen yoldan gelip gelmediği. Üçü aynı anda doğrulanmadan geçiş tamamlanmış sayılmaz.

Geri dönüş planı da baştan yazılır. Duyuruyu geri çektiğinizde trafiğin eski yola dönmesi aynı yayılma süresine tabidir; yani "gerekirse anında geri alırız" gerçekçi bir cümle değildir. Kademeli geçiş için AS-path prepending gibi yöntemler kullanılabilir, hangisinin uygun olduğu mevcut sağlayıcılarınızla olan bağlantı düzeninize bağlıdır.

Sık yapılan altı hata

• RPKI kaydını güncellemeden duyuruya çıkmak.
• maxLength değerini gereğinden geniş bırakmak.
• Tünelde MSS clamping yapmamak; küçük paketler geçer, büyük paketler kaybolur.
• /24'ten uzun bir prefix duyurmayı planlamak.
• Geçişi tepe trafik saatinde yapmak.
• UDP tabanlı oyun ya da ses trafiğini HTTP önündeki bir proxy ile korumaya çalışmak — o katman bu paketleri hiç görmez.

Kendi bloğunuzla geçişi planlıyorsanız başlangıç noktası envanterdir: ASN, prefix listesi, bugünkü duyuru düzeni ve sunucularınızın nerede durduğu. Bu dördünü iletişim formundan paylaştığınızda kayıt değerlerini ve geçiş planını birlikte çıkarabiliriz; hizmetin kapsamı ise BGP koruma sayfasında duruyor.