13 marca grupie roboczej RIPE ds. zwalczania nadużyć uważaj przejęcie BGP (hjjack) za naruszenie polityki RIPE. Gdyby propozycja została zaakceptowana, dostawca Internetu zaatakowany przez przechwytywanie ruchu miałby możliwość wysłania specjalnego żądania w celu zdemaskowania atakującego. Jeżeli zespół przeprowadzający przegląd zebrał wystarczające dowody potwierdzające, LIR będący źródłem przechwycenia protokołu BGP zostałby uznany za intruza i mógłby zostać pozbawiony statusu LIR. Nie zabrakło też argumentów zmiany.
W tej publikacji chcemy pokazać przykład ataku, w którym kwestionowano nie tylko prawdziwego atakującego, ale także całą listę przedrostków, których to dotyczy. Co więcej, taki atak ponownie rodzi pytania o motywy przyszłego przechwytywania tego typu ruchu.
W ciągu ostatnich kilku lat prasa jako przechwytywanie BGP opisywała jedynie konflikty takie jak MOAS (multiple origin autonomiczny system). MOAS jest szczególnym przypadkiem, w którym dwa różne systemy autonomiczne ogłaszają sprzeczne przedrostki z odpowiadającymi im numerami ASN w AS_PATH (pierwszy ASN w AS_PATH, zwany dalej początkowym ASN). Możemy jednak przynajmniej wymienić przechwytywanie ruchu, umożliwiając atakującemu manipulowanie atrybutem AS_PATH do różnych celów, w tym do ominięcia nowoczesnych podejść do filtrowania i monitorowania. Znany typ ataku - ostatni rodzaj takiego przechwytywania, ale wcale nie mający znaczenia. Jest całkiem możliwe, że właśnie tego rodzaju atak widzieliśmy w ciągu ostatnich tygodni. Takie zdarzenie ma zrozumiały charakter i dość poważne konsekwencje.
Ci, którzy szukają wersji TL; DR, mogą przewinąć do podtytułu „Perfect Attack”.
Tło sieci
(aby pomóc Ci lepiej zrozumieć procesy związane z tym incydentem)
Jeśli chcesz wysłać pakiet i masz wiele prefiksów w tablicy routingu zawierającej docelowy adres IP, użyjesz trasy dla prefiksu o najdłuższej długości. Jeśli w tablicy routingu istnieje kilka różnych tras dla tego samego prefiksu, wybierzesz najlepszą (zgodnie z mechanizmem wyboru najlepszej ścieżki).
Istniejące podejścia do filtrowania i monitorowania próbują analizować trasy i podejmować decyzje na podstawie analizy atrybutu AS_PATH. Router może zmienić ten atrybut na dowolną wartość podczas ogłaszania. Samo dodanie numeru ASN właściciela na początku AS_PATH (jako początkowego numeru ASN) może wystarczyć, aby ominąć obecne mechanizmy sprawdzania pochodzenia. Co więcej, jeśli istnieje trasa z zaatakowanego ASN do Ciebie, możliwe staje się wyodrębnienie i wykorzystanie AS_PATH tej trasy w innych Twoich ogłoszeniach. Każda weryfikacja spreparowanych ogłoszeń, przeprowadzana wyłącznie w trybie AS_PATH, w końcu zakończy się pomyślnie.
Istnieje jeszcze kilka ograniczeń, o których warto wspomnieć. Po pierwsze, w przypadku filtrowania prefiksów przez dostawcę nadrzędnego, Twoja trasa może nadal być filtrowana (nawet z poprawną AS_PATH), jeśli prefiks nie należy do stożka klienta skonfigurowanego na upstream. Po drugie, prawidłowa AS_PATH może stać się nieważna, jeśli utworzona trasa będzie ogłaszana w nieprawidłowych kierunkach, a tym samym narusza zasady routingu. Wreszcie każda trasa z prefiksem naruszającym długość ROA może zostać uznana za nieprawidłową.
Incydent
Kilka tygodni temu otrzymaliśmy skargę od jednego z naszych użytkowników. Widzieliśmy trasy z prefiksami ASN pochodzenia i /25, podczas gdy użytkownik twierdził, że ich nie reklamował.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
Przykładowe zapowiedzi na początek kwietnia 2019
NTT w ścieżce przedrostka /25 czyni to szczególnie podejrzanym. W momencie zdarzenia firma LG NTT nie była świadoma istnienia tej trasy. Więc tak, jakiś operator tworzy całą ścieżkę AS_PATH dla tych przedrostków! Sprawdzanie na innych routerach ujawnia jeden konkretny numer ASN: AS263444. Po przyjrzeniu się innym trasom z tym autonomicznym systemem 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 tu jest nie tak
Wygląda na to, że ktoś wziął przedrostek z trasy, podzielił go na dwie części i zareklamował trasę z tą samą wartością AS_PATH dla tych dwóch przedrostkó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ładowe trasy dla jednej z rozdzielonych par prefiksów
Nasuwa się kilka pytań na raz. Czy ktoś rzeczywiście próbował tego typu przechwytywania w praktyce? Czy ktoś jechał tymi trasami? Jakie przedrostki zostały dotknięte?
W tym miejscu rozpoczyna się pasmo niepowodzeń i kolejna fala rozczarowań obecnym stanem Internetu.
Droga porażki
Najpierw najważniejsze rzeczy. Jak możemy ustalić, które routery zaakceptowały takie przechwycone trasy i czyj ruch można obecnie przekierować? Pomyśleliśmy, że zaczniemy od przedrostków /25, ponieważ „po prostu nie mogą mieć globalnej dystrybucji”. Jak można się domyślić, bardzo się myliliśmy. Ta metryka okazała się zbyt zaszumiona i trasy z takimi prefiksami mogą pojawiać się nawet od operatorów poziomu 1. Na przykład NTT ma około 50 takich prefiksów, które dystrybuuje wśród swoich klientów. Z drugiej strony ta metryka jest zła, ponieważ takie prefiksy można odfiltrować, jeśli operator ich użyje , we wszystkich kierunkach. Dlatego też metoda ta nie nadaje się do znalezienia wszystkich operatorów, których ruch został przekierowany w wyniku takiego zdarzenia.
Kolejnym dobrym pomysłem, który pomyśleliśmy, było przyjrzenie się temu . Zwłaszcza w przypadku tras, które naruszają zasadę maxLength odpowiedniego ROA. W ten sposób mogliśmy znaleźć liczbę różnych numerów ASN pochodzenia ze statusem Invalid, które były widoczne dla danego AS. Jest jednak „mały” problem. Średnia (mediana i tryb) tej liczby (liczba ASNów o różnym pochodzeniu) wynosi około 150 i nawet jeśli odfiltrujemy małe przedrostki, pozostaje ona powyżej 70. Ten stan rzeczy ma bardzo proste wyjaśnienie: istnieją tylko niewielu operatorów, którzy już korzystają z filtrów ROA z polityką „resetuj nieprawidłowe trasy” w punktach wejścia, dzięki czemu wszędzie tam, gdzie w świecie rzeczywistym pojawia się trasa naruszająca ROA, może ona rozprzestrzeniać się we wszystkich kierunkach.
Dwa ostatnie podejścia pozwalają nam znaleźć operatorów, którzy widzieli nasz incydent (ponieważ był dość duży), ale generalnie nie mają zastosowania. OK, ale czy uda nam się znaleźć intruza? Jakie są ogólne cechy tej manipulacji AS_PATH? Istnieje kilka podstawowych założeń:
- Przedrostka nie widziano nigdzie wcześniej;
- ASN pochodzenia (przypomnienie: pierwszy ASN w AS_PATH) jest ważny;
- Ostatni numer ASN w AS_PATH jest numerem ASN atakującego (w przypadku, gdy jego sąsiad sprawdza numer ASN sąsiada na wszystkich trasach przychodzących);
- Atak pochodzi od jednego dostawcy.
Jeśli wszystkie założenia są prawidłowe, wówczas wszystkie nieprawidłowe trasy będą przedstawiać numer ASN atakującego (z wyjątkiem początkowego numeru ASN), a zatem jest to punkt „krytyczny”. Wśród prawdziwych porywaczy był AS263444, chociaż były też inne. Nawet jeśli odrzuciliśmy z rozważań trasy incydentów. Dlaczego? Punkt krytyczny może pozostać krytyczny nawet dla prawidłowych tras. Może to być wynikiem słabej łączności w regionie lub ograniczeń naszej własnej widoczności.
Dzięki temu istnieje sposób na wykrycie atakującego, ale tylko wtedy, gdy zostaną spełnione wszystkie powyższe warunki i tylko wtedy, gdy przechwycenie będzie na tyle duże, że przekroczy progi monitorowania. Jeśli niektóre z tych czynników nie zostaną spełnione, czy możemy zidentyfikować przedrostki, które ucierpiały w wyniku takiego przechwycenia? Dla niektórych operatorów - tak.
Kiedy atakujący tworzy bardziej konkretną trasę, taki prefiks nie jest reklamowany przez prawdziwego właściciela. Jeśli masz dynamiczną listę wszystkich jego przedrostków, możliwe staje się dokonanie porównania i znalezienie zniekształconych, bardziej szczegółowych tras. Tę listę prefiksów zbieramy za pomocą naszych sesji BGP, ponieważ dostajemy nie tylko pełną listę tras widocznych w danej chwili dla operatora, ale także listę wszystkich prefiksów, które chce on rozgłosić światu. Niestety, obecnie kilkudziesięciu użytkowników Radaru nie wykonuje poprawnie ostatniej części. Wkrótce ich powiadomimy i spróbujemy rozwiązać ten problem. Wszyscy inni mogą już teraz dołączyć do naszego systemu monitorowania.
Jeśli wrócimy do pierwotnego zdarzenia, zarówno osoba atakująca, jak i obszar dystrybucji zostały przez nas wykryte poprzez wyszukiwanie punktów krytycznych. Co zaskakujące, AS263444 nie wysłał sfabrykowanych tras do wszystkich swoich klientów. Chociaż jest dziwniejszy moment.
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
Gdy dla naszych prefiksów utworzono bardziej szczegółowe, użyto specjalnie utworzonej ścieżki AS_PATH. Jednak tej ścieżki AS_PATH nie można było pobrać z żadnej z naszych poprzednich tras. Nie mamy nawet komunikacji z AS6762. Patrząc na inne trasy biorące udział w incydencie, niektóre z nich miały rzeczywistą ścieżkę AS_PATH, która była wcześniej używana, podczas gdy inne nie, nawet jeśli wyglądała jak prawdziwa. Dodatkowa zmiana AS_PATH nie ma praktycznego sensu, ponieważ ruch i tak zostanie przekierowany do atakującego, ale trasy ze „złą” AS_PATH można filtrować przez ASPA lub inny mechanizm inspekcji. Tutaj myślimy o motywacji porywacza. Obecnie nie mamy wystarczających informacji, aby potwierdzić, że ten incydent był zaplanowanym atakiem. Niemniej jednak jest to możliwe. Spróbujmy wyobrazić sobie, choć wciąż hipotetyczną, ale potencjalnie całkiem realną, sytuację.
Idealny atak
Co mamy? Załóżmy, że jesteś dostawcą usług transportu publicznego i udostępniasz trasy swoim klientom. Jeśli Twoi klienci mają wiele obecności (multihome), będziesz otrzymywać tylko część ich ruchu. Ale im większy ruch, tym większy dochód. Jeśli więc zaczniesz reklamować prefiksy podsieci tych samych tras z tą samą AS_PATH, otrzymasz resztę ich ruchu. W rezultacie reszta pieniędzy.
Czy ROA tu pomoże? Być może tak, jeśli zdecydujesz się całkowicie zaprzestać jego używania . Ponadto wysoce niepożądane jest posiadanie rekordów ROA z przecinającymi się przedrostkami. Dla niektórych operatorów takie ograniczenia są nie do przyjęcia.
Biorąc pod uwagę inne mechanizmy bezpieczeństwa routingu, ASPA również w tym przypadku nie pomoże (ponieważ używa AS_PATH z prawidłowej trasy). BGPSec w dalszym ciągu nie jest optymalną opcją ze względu na niski współczynnik wykorzystania i utrzymującą się możliwość ataków na niższą wersję.
Mamy więc wyraźny zysk dla atakującego i brak bezpieczeństwa. Świetna mieszanka!
Co powinienem zrobić?
Oczywistym i najbardziej drastycznym krokiem jest przejrzenie aktualnej polityki routingu. Podziel przestrzeń adresową na najmniejsze części (bez nakładania się), które chcesz reklamować. Zarejestruj ROA tylko dla nich, bez użycia parametru maxLength. W tym przypadku Twój aktualny POV może Cię uchronić przed takim atakiem. Jednak ponownie dla niektórych operatorów takie podejście nie jest uzasadnione ze względu na korzystanie wyłącznie z bardziej szczegółowych tras. Wszystkie problemy z aktualnym stanem ROA i obiektów tras zostaną opisane w jednym z naszych przyszłych materiałów.
Ponadto możesz spróbować monitorować takie przechwycenia. Aby to zrobić, potrzebujemy wiarygodnych informacji o Twoich prefiksach. Tym samym, jeśli nawiążesz sesję BGP z naszym zbieraczem i przekażesz nam informacje o Twojej widoczności w Internecie, będziemy mogli znaleźć pole do dalszych zdarzeń. Tym, którzy nie są jeszcze podłączeni do naszego systemu monitoringu, na początek wystarczy lista tras zawierająca wyłącznie Twoje prefiksy. Jeśli masz u nas sesję, sprawdź, czy wszystkie trasy zostały wysłane. Niestety warto o tym pamiętać, ponieważ niektórzy operatorzy zapominają jeden lub dwa prefiksy i w ten sposób zakłócają nasze metody wyszukiwania. Jeśli zrobisz to poprawnie, będziemy dysponować wiarygodnymi danymi o Twoich prefiksach, co w przyszłości pomoże nam automatycznie identyfikować i wykrywać ten (i inne) rodzaje przechwytywania ruchu w Twojej przestrzeni adresowej.
Jeśli w czasie rzeczywistym dowiesz się o takim przechwyceniu Twojego ruchu, możesz spróbować samodzielnie temu przeciwdziałać. Pierwsza metoda polega na samodzielnym reklamowaniu tras za pomocą bardziej szczegółowych przedrostków. W przypadku nowego ataku na te przedrostki powtórz operację.
Drugie podejście polega na ukaraniu atakującego oraz tych, dla których jest on punktem krytycznym (dla dobrych tras) poprzez odcięcie dostępu do swoich tras atakującemu. Można tego dokonać, dodając numer ASN atakującego do AS_PATH starych tras i w ten sposób zmuszając go do unikania tego AS, korzystając z wbudowanego mechanizmu wykrywania pętli w BGP .
Źródło: www.habr.com