Witam, nazywam się Aleksander Azimow. W Yandex opracowuję różne systemy monitorowania, a także architekturę sieci transportowej. Ale dzisiaj porozmawiamy o protokole BGP.
Tydzień temu Yandex włączył funkcję ROV (Route Origin Validation) na interfejsach ze wszystkimi partnerami peeringowymi, a także w punktach wymiany ruchu. Przeczytaj poniżej, dlaczego tak zrobiono i jak wpłynie to na interakcję z operatorami telekomunikacyjnymi.
BGP i co jest z nim nie tak
Prawdopodobnie wiesz, że BGP został zaprojektowany jako protokół routingu międzydomenowego. Jednak po drodze liczba przypadków użycia wzrosła: dziś BGP, dzięki licznym rozszerzeniom, zamienił się w magistralę komunikatów, obejmującą zadania od operatora VPN po modne obecnie SD-WAN, a nawet znalazł zastosowanie jako transport dla kontrolera podobnego do SDN, zmieniający wektor odległości BGP w coś podobnego do protokołu łącza sat.
Rys.. 1.
Dlaczego BGP otrzymał (i nadal otrzymuje) tak wiele zastosowań? Istnieją dwa główne powody:
- BGP to jedyny protokół działający pomiędzy systemami autonomicznymi (AS);
- BGP obsługuje atrybuty w formacie TLV (typ-długość-wartość). Tak, protokół nie jest w tym osamotniony, ale ponieważ nie ma go czym zastąpić na skrzyżowaniach między operatorami telekomunikacyjnymi, zawsze bardziej opłacalne jest dołączenie do niego kolejnego elementu funkcjonalnego niż obsługa dodatkowego protokołu routingu.
Co z nim nie tak? Krótko mówiąc, protokół nie posiada wbudowanych mechanizmów sprawdzających poprawność otrzymywanych informacji. Oznacza to, że BGP jest protokołem zaufania apriorycznego: jeśli chcesz powiedzieć światu, że jesteś teraz właścicielem sieci Rostelecom, MTS lub Yandex, proszę!
Filtr oparty na IRRDB - najlepszy z najgorszych
Powstaje pytanie: dlaczego w takiej sytuacji Internet nadal działa? Tak, to działa przez większość czasu, ale jednocześnie okresowo eksploduje, uniemożliwiając dostęp do całych segmentów krajowych. Chociaż aktywność hakerów w BGP również rośnie, większość anomalii nadal jest spowodowana błędami. Tegoroczny przykład to na Białorusi, co spowodowało, że znaczna część Internetu była niedostępna dla użytkowników MegaFon na pół godziny. Inny przykład - złamał jedną z największych sieci CDN na świecie.
Ryż. 2. Przechwytywanie ruchu Cloudflare
Ale dlaczego takie anomalie zdarzają się raz na sześć miesięcy, a nie codziennie? Ponieważ przewoźnicy korzystają z zewnętrznych baz danych informacji o routingu, aby zweryfikować, co otrzymują od sąsiadów BGP. Takich baz jest wiele, część z nich jest zarządzana przez rejestratorów (RIPE, APNIC, ARIN, AFRINIC), część to niezależni gracze (najbardziej znany to RADB), a jest też cała gama rejestratorów będących własnością dużych firm (Poziom 3 , NTT itp.). To dzięki tym bazom danych routing międzydomenowy utrzymuje względną stabilność swojego działania.
Istnieją jednak niuanse. Informacje o routingu sprawdzane są na podstawie obiektów ROUTE-OBJECTS i AS-SET. A jeśli pierwsza oznacza autoryzację dla części IRRDB, to dla drugiej klasy nie ma autoryzacji jako klasy. Oznacza to, że każdy może dodać dowolną osobę do swoich zestawów i w ten sposób ominąć filtry dostawców zewnętrznych. Co więcej, nie jest gwarantowana unikalność nazewnictwa AS-SET pomiędzy różnymi bazami IRR, co może prowadzić do zaskakujących efektów w postaci nagłej utraty łączności dla operatora telekomunikacyjnego, który ze swojej strony nic nie zmienił.
Dodatkowym wyzwaniem jest sposób wykorzystania AS-SET. Są tu dwa punkty:
- Kiedy operator otrzymuje nowego klienta, dodaje go do swojego AS-SET, ale prawie nigdy go nie usuwa;
- Same filtry konfigurowane są jedynie na interfejsach z klientami.
W rezultacie nowoczesny format filtrów BGP polega na stopniowej degradacji filtrów na interfejsach z klientami i apriorycznym zaufaniu do tego, co pochodzi od partnerów peeringowych i dostawców tranzytu IP.
Co zastępuje filtry prefiksów oparte na AS-SET? Najciekawsze jest to, że w krótkim okresie – nic. Ale pojawiają się dodatkowe mechanizmy, które uzupełniają pracę filtrów opartych na IRRDB, a przede wszystkim jest to oczywiście RPKI.
RPKI
W uproszczeniu architekturę RPKI można traktować jako rozproszoną bazę danych, której zapisy można weryfikować kryptograficznie. W przypadku ROA (Route Object Authorization) podpisujący jest właścicielem przestrzeni adresowej, a sam rekord jest potrójny (prefix, asn, max_length). Zasadniczo wpis ten postuluje, co następuje: właściciel przestrzeni adresowej $prefix upoważnił numer AS $asn do ogłaszania prefiksów o długości nie większej niż $max_length. Routery, korzystając z pamięci podręcznej RPKI, są w stanie sprawdzić parę pod kątem zgodności przedrostek - pierwszy mówca w drodze.
Rysunek 3. Architektura RPKI
Obiekty ROA są już od dawna standaryzowane, ale do niedawna właściwie pozostawały jedynie na papierze w czasopiśmie IETF. Moim zdaniem powód tego brzmi przerażająco – zły marketing. Po zakończeniu standaryzacji zachętą było zabezpieczenie ROA przed przejęciem BGP – co nie było prawdą. Atakujący mogą łatwo ominąć filtry oparte na ROA, wstawiając prawidłowy numer AC na początku ścieżki. Gdy tylko sobie to uświadomiono, kolejnym logicznym krokiem była rezygnacja ze stosowania ROA. I naprawdę, po co nam technologia, jeśli nie działa?
Dlaczego nadszedł czas, aby zmienić zdanie? Bo to nie jest cała prawda. ROA nie chroni przed działalnością hakerów w BGP, ale chroni przed przypadkowymi przejęciami ruchu, na przykład z powodu statycznych wycieków w BGP, które stają się coraz częstsze. Ponadto, w przeciwieństwie do filtrów opartych na IRR, ROV może być używany nie tylko na interfejsach z klientami, ale także na interfejsach z urządzeniami równorzędnymi i dostawcami wyższego szczebla. Oznacza to, że wraz z wprowadzeniem RPKI z BGP stopniowo zanika zaufanie aprioryczne.
Teraz sprawdzanie tras w oparciu o ROA jest stopniowo wdrażane przez kluczowych graczy: największy europejski IX już odrzuca nieprawidłowe trasy, wśród operatorów Tier-1 na uwagę zasługuje AT&T, który włączył filtry na interfejsach z partnerami peeringowymi. Do projektu zbliżają się także najwięksi dostawcy treści. A kilkudziesięciu średnich operatorów tranzytowych już to po cichu wdrożyło, nikomu o tym nie mówiąc. Dlaczego wszyscy ci operatorzy wdrażają RPKI? Odpowiedź jest prosta: chronić swój ruch wychodzący przed błędami innych osób. Dlatego Yandex jako jeden z pierwszych w Federacji Rosyjskiej umieścił ROV na obrzeżach swojej sieci.
Co się później stanie?
Umożliwiliśmy teraz sprawdzanie informacji o routingu na interfejsach z punktami wymiany ruchu i prywatnymi peeringami. W najbliższej przyszłości weryfikacja zostanie włączona także u dostawców ruchu upstream.
Jakie to robi dla ciebie różnicę? Jeśli chcesz zwiększyć bezpieczeństwo routingu ruchu pomiędzy swoją siecią a Yandex, zalecamy:
- Podpisz swoją przestrzeń adresową - to proste, zajmuje średnio 5-10 minut. To ochroni naszą łączność w przypadku, gdy ktoś nieświadomie ukradnie Twoją przestrzeń adresową (a to na pewno wcześniej czy później nastąpi);
- Zainstaluj jedną z pamięci podręcznych RPKI typu open source (, ) i umożliwić kontrolę trasy na granicy sieci – zajmie to więcej czasu, ale znowu nie spowoduje żadnych problemów technicznych.
Yandex wspiera także rozwój systemu filtrującego opartego na nowym obiekcie RPKI - (Autoryzacja dostawcy systemu autonomicznego). Filtry oparte na obiektach ASPA i ROA mogą nie tylko zastąpić „nieszczelne” AS-SET, ale także zamknąć problemy ataków MiTM przy użyciu BGP.
O ASPA będę szczegółowo mówił już za miesiąc na konferencji Next Hop. Wypowiedzą się tam także koledzy z Netflix, Facebook, Dropbox, Juniper, Mellanox i Yandex. Jeśli interesuje Cię stos sieciowy i jego rozwój w przyszłości, przyjdź .
Źródło: www.habr.com