Jak wdrożyć RPKI we własnej sieci?
W poprzednim artykule omówiłem problematykę ataku BGP Hijacking i technologii, która potrafi skutecznie przeciwdziałać temu atakowi, jaką jest RPKI.
Michał Gliński
Inżynier sieciowy z 4 letnim doświadczeniem w zarządzaniu infrastrukturą sieciową Data Center klasy TIER 3. Propagator dobrych praktyk w zarządzaniu protokołem BGP oraz maniak wszelkich sieciowych nowinek.
Skupiłem się głównie na omówieniu tego, czym ta technologia jest i jak ogólnie działa. Na sam koniec zachęciłem Cię do podpisania (utworzenie obiektów ROA) swoich prefiksów w RIPE NCC. Utworzenie obiektów ROA w istotny sposób może podnieść bezpieczeństwo naszej sieci (inni operatorzy będą w stanie dokonywać weryfikacji i podejmować działania zgodnie z lokalną polityką routingu). Pełne wdrożenie RPKI w naszej sieci będzie również wymagało uruchomienia RPKI walidatorów, podłączenia do naszych routerów i dokonywania stosownych akcji. W tym artykule chciałbym przedstawić Ci jeden z możliwych sposób implementacji RPKI walidatorów w sieci pracującej pod kontrolą routerów Juniper Networks. Przykłady polityk importu na sesji eBGP dotyczą urządzeń pracujących pod kontrolą systemu JunOS, lecz ogólną koncepcję można z powodzeniem stosować też u innych vendorów takich jak np. Cisco Systems.
Uruchomienie RPKI walidatorów na platformie Docker Swarm
RPKI walidatory są niczym innym jak oprogramowaniem, które pobiera obiekty ROA z RIR (ang. Regional Internet Registry) takiego jak np. RIPE NCC. Posiadają one interfejs, który umożliwia podłączenie ich do naszych routerów. W dobie orkiestryzacji i wszechobecnej konteneryzacji takie oprogramowanie możemy z powodzeniem uruchomić jako kontenery w pojedynczej instancji Dockera lub jako usługę w Docker Swarm. Oczywiście nic nie stoi na przeszkodzie, aby takie oprogramowanie uruchomić na zwykłej maszynie wirtualnej z dostarczonej przez dostawcę binarki czy, będąc już bardzo klasycznym, na bare metalu np. serwerze dedykowanym.
Poniżej zamieszczam listing kodu, który może być wdrożony na klastrze Docker Swarm. Tak wdrożona usługa uruchomi nam dwa kontenery.
version: '3.7' services: rtr_rpki_server_1: image: cloudflare/gortr deploy: mode: global resources: limits: cpus: "4" memory: "4g" restart_policy: condition: on-failure ports: - "8282:8282" networks: - rtr_rpki_server_network rtr_rpki_server_2: image: nlnetlabs/routinator volumes: - rtr_rpki_server_2_data:/home/routinator/.rpki-cache/tals deploy: mode: global resources: limits: cpus: "4" memory: "4g" restart_policy: condition: on-failure ports: - "3323:3323" networks: - rtr_rpki_server_network networks: rtr_rpki_server_network: driver: overlay attachable: true volumes: rtr_rpki_server_2_data: driver: local driver_opts: o: bind type: none device: /storage/nfs/docker-volumes/rtr_rpki_server_2_data
Na uwagę zasługuje tutaj fakt uruchomienia dwóch kontenerów od dwóch różnych dostawców tj. cloudflare oraz nlnetlabs. Awaria lub nieprawidłowe działanie RPKI walidatora może potencjalnie mieć bardzo zgubne skutki dla naszej sieci. Wysoce zalecam w produkcyjnych środowiskach stosowanie minimum dwóch RPKI walidatorów od zupełnie różnych dostawców. Pewną alternatywą dla nich może być skorzystanie z https://openrpki.net/ w modelu usługowym. Jednak podchodziłbym do tego typu rozwiązań z dużą rezerwą, gdyż zagadnienia te dotykają bardzo newralgicznej części naszej infrastruktury.
Podłączenie RPKI walidatorów w JunOS
Poniższy listing kodu uruchomi nam dwie sesje do RPKI walidatorów w JunOS.
set routing-options validation group rpki-validator session 10.10.10.10 refresh-time 120 set routing-options validation group rpki-validator session 10.10.10.10 hold-time 240 set routing-options validation group rpki-validator session 10.10.10.10 record-lifetime 86400 set routing-options validation group rpki-validator session 10.10.10.10 port 8282 set routing-options validation group rpki-validator session 10.10.10.10 local-address 192.168.200.1 set routing-options validation group rpki-validator session 10.10.10.11 refresh-time 120 set routing-options validation group rpki-validator session 10.10.10.11 hold-time 240 set routing-options validation group rpki-validator session 10.10.10.11 record-lifetime 86400 set routing-options validation group rpki-validator session 10.10.10.11 port 8282 set routing-options validation group rpki-validator session 10.10.10.11 local-address 192.168.200.1
Parametry związane z czasem należy dostosowywać pod kątem własnych potrzeb.
Implementacja polityk w JunOS
Na tym etapie mamy już uruchomione instancje RPKI walidatorów wraz z podłączeniem ich do naszych routerów. Kolejnym krokiem będzie przygotowanie odpowiedniej polityki importu na sesji eBGP. Przykładowa polityka znajduje się w poniższym listingu. W zależności od przyjętej konwencji polityka ta może stać się elementem już istniejącej polityki lub też zostać dołączona do łańcucha polityk importu na sesji eBGP.
set policy-options policy-statement ps-RPKI-eBGP-import term valid from protocol bgp set policy-options policy-statement ps-RPKI-eBGP-import term valid from validation-database valid set policy-options policy-statement ps-RPKI-eBGP-import term valid then validation-state valid set policy-options policy-statement ps-RPKI-eBGP-import term valid then accept set policy-options policy-statement ps-RPKI-eBGP-import term invalid from protocol bgp set policy-options policy-statement ps-RPKI-eBGP-import term invalid from validation-database invalid set policy-options policy-statement ps-RPKI-eBGP-import term invalid then validation-state invalid set policy-options policy-statement ps-RPKI-eBGP-import term invalid then reject set policy-options policy-statement ps-RPKI-eBGP-import term unknown from protocol bgp set policy-options policy-statement ps-RPKI-eBGP-import term unknown from validation-database unknown set policy-options policy-statement ps-RPKI-eBGP-import term unknown then validation-state unknown set policy-options policy-statement ps-RPKI-eBGP-import term unknown then accept set protocols bgp group eBGP-peer neighbor 192.168.15.45 import ps-RPKI-eBGP-import
Polityka składa się z trzech term. W każdej z nich na podstawie uzyskanych z RPKI walidatorów danych ustalamy status tego prefiksu.
Prefiks może mieć jeden z trzech poniższych stanów.
valid – prefiks posiada zgodny obiekt ROA
unknown – prefiks nie posiada obiektu ROA
invalid – prefiks jest nieprawidłowy (rozgłasza go niedozwolony system autonomiczny lub też maska podsieci ma nieprawidłową długość)
Prefiksy posiadające flagę invalid powinny być z natury odrzucane. Zalecam jednak w tym miejscu ostrożność i weryfikację tego co zostało złapane przez konkretne termy.
Weryfikacja
Po poprawnie przeprowadzonym procesie konfiguracji nasz router odbiera prefiksy i dokonuje ich weryfikacji na podstawie obiektów ROA. Przykładowy wynik będzie widoczny pod poleceniem show route showroute.pl. Pole o nazwie“validation state” zawiera wartość valid. Oznacza to, że prefiks 104.21.0.0/24 (Cloudflare) posiada prawidłowy obiekt ROA, a sam prefiks został załadowany przez RE do RIB, a następnie do PFE.
Jeśli zastanawiałeś się, jak dużym problemem są nieprawidłowo rozgłoszone prefiksy, to poniżej zamieszczam zrzut ekranu z listą odrzuconych prefiksów na jednej z sesji eBGP. Na sesji tej operator wysyła całą tablicę routingu. Z chwilą pisania tego artykułu istniało ponad 2,5k nieprawidłowych prefiksów.
Obecność sporej części tych wpisów wynika z przeprowadzonej przez administratora danego systemu autonomicznego deagracji, np. został wcześniej utworzony obiekt ROA z prefiksem 10.10.0.0/22, a rozgłoszony zostaje prefiks 10.10.0.0/24.
Uwaga
Z uruchomieniem tej technologii wiążą się pewne ograniczenia. Nasz router oprócz standardowych działań takich jak obliczenia związane z przeliczaniem tras będzie również musiał dokonywać obliczeń związanych z RPKI. Uruchomienie RPKI na sesji eBGP lub też jej awaria w przypadku kiedy odpowiednia polityka była już zaimplementowana, powoduje wyraźnie większe obciążenie CPU naszego RE. Należy z dużą dozą ostrożności podchodzić do wdrożenia tej technologii szczególnie na mniejszych jednostkach Junipera takich jak np. MX80.
Słowo końcowe
Poradnik ten z całą pewnością nie wyczerpuje całego tematu. Uważam jednak, że jest dobrym punktem wyjścia do dalszej pracy nad poprawieniem bezpieczeństwa własnej sieci. Wartym zaznaczenia tutaj faktem jest to, że RPKI w tym roku znalazło się w dokumencie dobrych praktyk w zakresie przeciwdziałaniu atakom DDoS przygotowanym przez Komisję Nadzoru Finansowego
Zachęcam Cię do implementacji RPKI w swojej sieci lub do przynajmniej podpisania swoich prefiksów w RIPE NCC. Każde takie działanie w istotny sposób polepsza poziom bezpieczeństwa globalnej sieci Internet.
Podobne wpisy
Błędy w konfiguracji sieci a podatność na ataki DDoS
Pętle w sieci pojawiały się i będą sie pojawiać. Często jest to błąd z konfiguracji. Pętle mogą zostać wykorzystane do ataku DDoS. Michał w tym wpisie wprowadzi Cię w temat.Inżynier sieciowy z 4 letnim doświadczeniem w zarządzaniu infrastrukturą sieciową Data Center...
AS-path – atrybut BGP
Dzisiaj zajmiemy się jednym z atrybutów BGP i jego wpływem na wybór ścieżki przez algorytm BGP - AS-PATH.Inżynier sieciowy lubiący dzielić się wiedzą i pomagać innym zrozumieć zawiłości działania sieci i Internetu.AS-path - co to jest? AS-PATH jest atrybutem well-know...
IS-IS protokół IGP – wprowadzenie
W dzisiejszym wpisie wejdziemy w świat IGP. Zaczniemy od Intermediate System-to-Intermediate System w skrócie IS-IS.Inżynier sieciowy lubiący dzielić się wiedzą i pomagać innym zrozumieć zawiłości działania sieci i Internetu.Protokół dokładniej Intermediate...