13 marca do roboczej grupy RIPE ds. przeciwdziałania nadużyciom rozważenia BGP hijacking (hjjack) jako naruszenia polityki RIPE. W przypadku akceptacji propozycji, dostawca internetowy, który padł ofiarą przejęcia ruchu, miałby możliwość złożenia specjalnego wniosku o ujawnienie przestępcy. Jeśli grupa ekspertów zgromadziłaby wystarczającą ilość dowodów, taki LIR, będący źródłem BGP hijackingu, byłby uważany za naruszyciela i mógłby zostać pozbawiony statusu LIR. Pojawiły się także niektóre argumenty zmianie.
W tej publikacji chcemy pokazać przykład ataku, w którym nie tylko rzeczywisty przestępca był wątpliwy, ale także cała lista poszkodowanych prefiksów. Co więcej, taki atak ponownie stawia pytania dotyczące motywów przyszłych przejęć ruchu tego typu.
W ciągu ostatnich kilku lat w mediach jako BGP hijackingi relacjonowane były tylko konflikty typu MOAS (Multiple Origin Autonomous System). MOAS jest szczególnym przypadkiem, w którym dwa różne systemy autonomiczne ogłaszają sprzeczne prefiksy z odpowiednimi numerami ASN w AS_PATH (pierwszy ASN w AS_PATH, dalej w tekście — origin ASN). Jednak możemy wymienić co najmniej przejęcia ruchu, pozwalające przestępcy manipulować atrybutem AS_PATH w różnych celach, w tym w celu obejścia nowoczesnych metod filtracji i monitoringu. Znany typ ataku — to ostatni typ takiego przejęcia, ale nie mniej istotny. Jest całkowicie możliwe, że właśnie taki atak obserwowaliśmy przez ostatnie tygodnie. To zdarzenie ma zrozumiały charakter i dość poważne konsekwencje.
Ci, którzy szukają wersji TL;DR, mogą przewinąć do podtytułu „Idealny atak”.
Tło sieciowe
(aby lepiej zrozumieć procesy zaangażowane w ten incydent)
Jeśli chcesz wysłać pakiet i masz kilka prefiksów w tablicy routingu zawierających adres IP docelowy, użyjesz trasy dla prefiksu o maksymalnej długości. Jeśli jednak w tablicy routingu istnieje kilka różnych tras dla jednego prefiksu, wybierzesz najlepszą (zgodnie z mechanizmem wyboru najlepszej trasy).
Istniejące podejścia do filtrowania i monitorowania próbują analizować trasy i podejmować decyzje na podstawie atrybutu AS_PATH. Router może zmienić ten atrybut na dowolną wartość podczas ogłaszania. Proste dodanie ASN właściciela na początku AS_PATH (jako ASN pochodzenia) może wystarczyć, aby obejść obecne mechanizmy weryfikacji źródła. Co więcej, jeśli istnieje trasa od zaatakowanego ASN do ciebie, pojawia się możliwość wyciągnięcia i użycia AS_PATH tej trasy w innych twoich ogłoszeniach. Każda weryfikacja wiarygodności tylko AS_PATH dla twoich stworzonych ogłoszeń w końcu będzie pozytywna.
Istnieje również kilka zasługujących na uwagę ograniczeń. Po pierwsze, w przypadku filtrowania prefiksów przez wyższego dostawcę, twoja trasa może być nadal odfiltrowana (nawet z poprawnym AS_PATH), jeśli prefiks nie należy do twojego klienta skonfigurowanego u dostawcy upstream. Po drugie, poprawny AS_PATH może stać się niepoprawny, jeśli utworzona trasa jest ogłaszana w nieprawidłowych kierunkach, naruszając tym samym politykę routingu. I ostatnia rzecz — każda trasa z prefiksem naruszającym długość ROA może być uznana za niepoprawną.
Incydent
Kilka tygodni temu otrzymaliśmy skargę od jednego z użytkowników. Widzieliśmy trasy z jego ASN pochodzenia i prefiksami /25, podczas gdy użytkownik twierdził, że ich nie ogłaszał.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
Przykłady ogłoszeń na początek kwietnia 2019
NTT w drodze dla prefiksu /25 czyni go szczególnie podejrzanym. Podczas incydentu LG NTT nie wiedział nic o tej trasie. Więc tak, jakiś operator tworzy cały AS_PATH dla tych prefiksów! Sprawdzając na innych routerach, można wyróżnić jeden szczególny ASN: AS263444. Spoglądając na inne trasy z tego systemu autonomicznego, napotkaliśmy następującą sytuację:
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
Spróbuj zgadnąć, co jest nie tak
Wygląda na to, że ktoś wziął prefiks z trasy, podzielił go na dwie części i ogłosił trasę z tym samym AS_PATH dla tych dwóch prefiksów.
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
Przykłady tras dla jednej z par podzielonych prefiksów
Pojawia się kilka pytań. Czy rzeczywiście ktoś próbował w praktyce tego typu przechwytywania? Czy ktoś zaakceptował te trasy? Jakie prefiksy zostały dotknięte?
Tutaj zaczyna się nasza seria niepowodzeń i kolejna runda rozczarowania obecnym stanem zdrowia Internetu.
Ścieżka niepowodzeń
Zacznijmy od początku. Jak możemy określić, które routery przyjęły takie przechwycone trasy i który ruch może być przekierowywany już dziś? Zdecydowaliśmy się zacząć od prefiksów /25, ponieważ "nie mogą one mieć globalnego zasięgu". Jak możesz się domyślić — bardzo się pomyliliśmy. Ta metryka okazała się zbyt zaszumiona, a trasy z takimi prefiksami mogą być nawet od operatorów Tier-1. Na przykład NTT posiada około 50 takich prefiksów, które rozprowadza wśród swoich klientów. Z drugiej strony, ta metryka jest kiepska, ponieważ takie prefiksy mogą być filtrowane, jeśli operator stosuje , we wszystkich kierunkach. Dlatego ta metoda nie nadaje się do wyszukiwania wszystkich operatorów, którego ruch został przekierowany w wyniku podobnego incydentu.
Jeszcze jednym dobrym pomysłem wydawało nam się przyjrzenie się . W szczególności trasom naruszającym zasady maxLength odpowiedniego ROA. W ten sposób moglibyśmy znaleźć liczbę różnych origin ASN ze statusem Invalid, które były widoczne dla danej AS. Niemniej jednak istnieje "niewielki" problem. Średnia wartość (mediana i moda) tej liczby (liczby różnych origin ASN) wynosi około 150 i, nawet jeśli przefiltrujemy małe prefiksy, wciąż pozostanie powyżej 70. Taka sytuacja ma dość proste wytłumaczenie: jest tylko kilku operatorów, którzy już stosują filtry ROA z polityką „resetowania Invalid tras” na punktach wejściowych, więc gdziekolwiek na świecie pojawi się trasa naruszająca ROA, może ona być rozprowadzana we wszystkich kierunkach.
Ostatnie dwa podejścia pozwalają znaleźć operatorów, którzy dostrzegli nasz incydent (ponieważ był on dość duży), ale ogólnie są one niepraktyczne. Dobrze, ale czy możemy znaleźć sprawcę? Jakie są ogólne cechy takiej manipulacji AS_PATH? Istnieje kilka podstawowych założeń:
- Prefiks nie był wcześniej nigdzie zauważony;
- Origin ASN (przypomnienie: pierwszy ASN w AS_PATH) jest ważny;
- Ostatni ASN w AS_PATH to ASN atakującego (jeśli jego sąsiad sprawdza ASN sąsiada we wszystkich przychodzących trasach);
- Atak pochodzi od jednego dostawcy.
Jeśli wszystkie założenia są prawdziwe, to na wszystkich niepoprawnych trasach będzie widoczny ASN przestępcy (oprócz origin ASN) i dlatego jest to „punkt krytyczny”. Wśród prawdziwych uprowadzaczy znalazł się AS263444, mimo że były też inne. Nawet gdy odrzuciliśmy trasy incydentu z rozważań. Dlaczego? Punkt krytyczny może pozostać krytyczny nawet dla poprawnych tras. Może być wynikiem słabej łączności w danym regionie lub ograniczeń naszej własnej widoczności.
W rezultacie: istnieje sposób na wykrycie przestępcy, ale tylko w przypadku spełnienia wszystkich wyżej wymienionych warunków i tylko wtedy, gdy przechwycenie jest wystarczająco duże, aby przekroczyć progi monitorowania. Jeśli jednak jakiś z tych czynników nie jest spełniony, czy możemy wyróżnić prefiksy, które ucierpiały z powodu podobnego przechwycenia? Dla niektórych operatorów – tak.
Kiedy atakujący tworzy more specific trasę, taki prefiks nie jest ogłaszany przez prawowitego właściciela. W przypadku, gdy masz od niego dynamiczną listę wszystkich jego prefiksów, istnieje możliwość przeprowadzenia porównania i znalezienia zniekształconych more specific tras. Zbieramy tę listę prefiksów za pomocą naszych sesji BGP, gdyż przekazywane są nam nie tylko pełne listy tras widocznych dla operatora w danym momencie, ale również lista wszystkich prefiksów, które chce ogłosić światu. Niestety, obecnie jest kilka dziesiątek użytkowników Radar, którzy nie wykonują ostatniej części tego zadania do końca poprawnie. Wkrótce ich poinformujemy i postaramy się rozwiązać ten problem. Wszyscy inni mogą dołączyć do naszego systemu monitorowania już teraz.
Wracając do pierwotnego incydentu, zarówno przestępca, jak i obszar zasięgu zostały przez nas wykryte przy pomocy wyszukiwania punktów krytycznych. Co ciekawe, AS263444 nie rozsyłał sfałszowanych tras do wszystkich swoich klientów. Chociaż występuje również bardziej dziwny aspekt.
BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
Niedawny przykład próby przechwycenia naszej przestrzeni adresowej
Kiedy stworzono bardziej szczegółowe informacje dla naszych prefiksów, użyto specjalnie opracowanego AS_PATH. Jednak ten AS_PATH nie mógł zostać wzięty z żadnej z naszych wcześniejszych tras. Nie mamy nawet połączenia z AS6762. Przyjrzyjmy się innym trasom w incydencie: niektóre z nich miały rzeczywisty AS_PATH, który był używany wcześniej, a inne – nie, nawet jeśli wydają się rzeczywiste. Dodatkowa zmiana AS_PATH nie ma sensu praktycznego, ponieważ w każdym przypadku ruch zostanie przekierowany do cyberprzestępcy, ale trasy z "złym" AS_PATH mogą zostać odfiltrowane przez ASPA lub jakikolwiek inny mechanizm weryfikacji. Tutaj zastanawialiśmy się nad motywacją napastnika. Obecnie brakuje nam danych, aby stwierdzić, że ten incydent był zaplanowanym atakiem. Niemniej jednak – jest to możliwe. Spróbujmy przedstawić choć hipotetyczną, ale potencjalnie bardzo realną sytuację.
Idealny atak
Co mamy? Załóżmy, że jesteś dostawcą tranzytowym, który transmituje trasy dla swoich klientów. Jeśli twoi klienci mają wiele punktów obecności (multihome), otrzymasz tylko część ich ruchu. Ale im więcej ruchu – tym większy twój dochód. Dlatego, jeśli zaczniesz ogłaszać prefiksy podsieci tych samych tras z tym samym AS_PATH, otrzymasz pozostałą część ich ruchu. W konsekwencji, pozostającym częścią pieniędzy.
Czy ROA może tu pomóc? Może, jeśli zdecydujesz się całkowicie zaprzestać korzystania z . Ponadto w tej sytuacji zdecydowanie niepożądane jest posiadanie rekordów ROA z nakładającymi się prefiksami. Dla niektórych operatorów takie ograniczenia są nie do przyjęcia.
Biorąc pod uwagę inne mechanizmy zapewnienia bezpieczeństwa routingu, w tym przypadku ASPA również nie pomoże (ponieważ używany jest AS_PATH od dozwolonej trasy). BGPSec nadal nie jest optymalnym rozwiązaniem z powodu niskiego wskaźnika akceptacji oraz istniejącej możliwości ataków downgrade.
W ten sposób mamy wyraźny zysk dla atakującego i brak bezpieczeństwa. Doskonała mieszanka!
Co należy robić?
Oczywistym i najbardziej radykalnym krokiem jest przemyślenie swojej aktualnej polityki routingu. Podziel swoje adresy na jak najmniejsze fragmenty (bez nakładania się), które chcesz ogłaszać. Podpisz ROA tylko dla nich, nie używając parametru maxLength. W takim przypadku bieżący POV może uratować cię przed tym rodzajem ataku. Jednakże, znowu, dla niektórych operatorów takie podejście nie jest rozsądne z powodu wyjątkowego korzystania z bardziej szczegółowych tras. Wszystkie problemy z bieżącym stanem ROA i obiektów tras będą opisane w jednym z naszych przyszłych materiałów.
Oprócz tego można próbować monitorować takie przechwycenia. W tym celu potrzebujemy wiarygodnych informacji o twoich prefiksach. W ten sposób, jeśli ustanowisz sesję BGP z naszym kolektorem i przekażesz nam informacje o swojej widoczności w Internecie — możemy znaleźć obszar rozprzestrzenienia i dla innych incydentów. Dla tych, którzy jeszcze nie są podłączeni do naszego systemu monitorowania — na początek wystarczy lista tras tylko z twoimi prefiksami. Jeśli masz już sesję z nami, prosimy, upewnij się, że wszystkie twoje trasy zostały wysłane. Niestety, warto o tym przypomnieć, ponieważ część operatorów zapomina o jednym lub dwóch prefiksach, co stwarza zakłócenia w naszych metodach wyszukiwania. Jeśli wszystko zostanie zrobione poprawnie, będziemy mieć niezawodne dane o twoich prefiksach, które w przyszłości pomogą automatycznie określać i wykrywać tego (i inne) typy przechwycenia ruchu w twojej przestrzeni adresowej.
Jeśli w czasie rzeczywistym dowiesz się o takim przechwyceniu swojego ruchu, możesz spróbować przeciwdziałać samodzielnie. Pierwsze podejście — ogłoś trasy z tymi bardziej szczegółowymi prefiksami samodzielnie. W przypadku nowego ataku na te prefiksy — powtórz.
Drugie podejście — ukarać sprawcę i tych, dla których jest on punktem krytycznym (dla dobrych tras), odcinając dostęp twoich tras do sprawcy. Można to zrobić, dodając ASN sprawcy do AS_PATH twoich starych tras i w ten sposób zmusić je do unikania tego AS, korzystając z wbudowanego mechanizmu wykrywania cykli w BGP. .
Źródło: habr.com
