Atak BGP Hijacking

Z takim typem ataku mamy do czynienia w momencie, kiedy obcy system autonomiczny (ASN) rozgłosi w globalnej sieci cały nasz prefiks lub jego część (jako more specific route). Ataki tego typu są niezwykle groźne, gdyż są trudne do wykrycia dla inżynierów sieciowych. W odróżnieniu od np. ataków DDoS nie dotykają naszej infrastruktury w sposób bezpośredni.

Routery BGP i sam protokół BGP w swojej naturze nie mają zaimplementowanych żadnych mechanizmów weryfikujących to, czy rozgłoszona informacja jest poprawna. Oczywiście nie chodzi tutaj o poprawność w kontekście semantyki samego protokołu i komunikatów UPDATE wymienianych między sąsiadami BGP.

Tak błędnie rozgłoszony prefiks może spowodować trudne do zdiagnozowania problemy w komunikacji sieciowej i tym samym trudności w osiągnięciu odpowiedniego poziomu SLA.

Przydział adresacji IP i ASN

Każda organizacja, która chce rozgłaszać swoje prefiksy pod swoim ASN powinna zgłosić się do RIR (ang. Regional Internet Registry). W przypadku Europy i zachodniej części Azji tą organizacją jest RIPE NCC. RIPE NCC nie jest oczywiście jedynym RIR działającym na świecie. Warto w tym miejscu wspomnieć o ARIN (Ameryka Północna) czy AFNIC (Afryka). Każda z tych organizacji utrzymuje w ramach własnej infrastruktury bazę danych, w której każdy prefiks i ASN ma przyporządkowanego właściciela. Taka organizacja i podział pozwalają zachować porządek w globalnej sieci.

Prefiks listy lekiem na całe zło?

Globalną sieć powinniśmy zawsze traktować w charakterze zupełnie nie zaufanej sieci. Również, a może nawet szczególnie, z uwzględnieniem sesji eBGP między różnymi systemami autonomicznymi. Operatorzy telekomunikacyjni zestawiając sesje eBGP ze swoimi klientami definiują w politykach importu prefiks listy. Prefiks listy są najczęściej generowane na podstawie obiektów route i route6 w RIR (w przypadku RIPE NCC). Najwięksi gracze na rynku proces ten automatyzują, minimalizując tym samym ilość możliwych do powstania błędów popełnionych przez człowieka. Oczywiście tworzenie prefiks list ma sens dla sieci posiadającą skończoną ilość prefiksów. W przypadku usługi typu IP tranzyt gdzie wymieniana jest cała tablica routingu stosowanie statycznych prefiks list nie jest technicznie możliwe do zrealizowania. Wystarczy tylko w tym miejscu wspomnieć, że globalna tablica routingu dla IPv4 ma już przeszło ponad 800k prefiksów, a IPv6 już ponad 100k prefiksów. Liczby te cały czas rosną.

Mechanizm RPKI

Remedium na wcześniej opisane problemy jest technologia RPKI (ang. Resource Public Key Infrastructure), która cała jest tak naprawdę zbiorem kilku różnych technologii. Korzysta ona z kryptografii asymetrycznej i architektury klucza publicznego (PKI). RIR, jakim może być np. RIPE NCC, udostępnia gotową platformę. Za jej pomocą administrator danego systemu autonomicznego definiuje obiekty ROA (ang. Route Origin Authorisations), w których zawarte są informacje takie jak prefiks, maksymalna długość maski podsieci oraz ASN, który może rozgłosić wskazany prefiks. RIPE NCC udostępnia wygodny i prosty w obsłudze portal za pomocą którego można utworzyć obiekty ROA. 

Podpisanie kryptograficzne naszych prefiksów (utworzenie obiektów ROA) jest pierwszym etapem w implementacji RPKI w naszej sieci. Drugim etapem jest uruchomienie w naszej sieci instancji serwera RPKI walidatora. Wartym tutaj uwagi jest gotowy obraz w dokerze, który został przygotowany przez Cloudflare (https://hub.docker.com/r/cloudflare/octorpki). Stanowi to bardzo wygodną i szybką do wdrożenia platformę, którą można podłączyć pod nasze szkieletowe routery.

Operatorzy telekomunikacyjni, którzy wdrożą w swojej sieci RPKI mają możliwość, poprzez odpowiednią konstrukcję polityk BGP definiowania akcji, jaka powinna zostać podjęta w przypadku otrzymania od drugiej strony prefiksu z niedozwolonego ASN lub o nieprawidłowej długości maski. W zależności od przyjętej przez operatora polityki, taki prefiks jest najczęściej odrzucany lub oznaczony odpowiednim atrybutem BGP community. W efekcie nasza sieć jest mniej podatna na BGP Hijacking.

Wady RPKI

Żadna technologia nie jest pozbawiona wad, podobnie jest w przypadku RPKI. O ile sam proces tworzenia obiektów ROA nie jest skomplikowany i nie powinien zająć więcej niż kilkadziesiąt minut, o tyle implementacja RPKI w naszych routerach szkieletowych wymaga już znacznej mocy obliczeniowej. Nasze routery oprócz standardowej tablicy routingu będą musiały również dokonać analizy obiektów ROA i nawet dla dużych jednostek takich jak Juniper MX960 stanowi to wyzwanie.

Podsumowanie

Technologia RPKI w istotny sposób pozwala zwiększyć ogólny poziom bezpieczeństwa naszej sieci. Niestety jej poziom globalnej implementacji i świadomość samych administratorów nadal jest dość niska. W konsekwencji poziom wdrożenia tej technologii daleki jest od zadowalającego. Jeśli jesteś administratorem systemu autonomicznego, to gorąco zachęcam Cię do przynajmniej utworzenia obiektów ROA.

Podobne wpisy