fbpx

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

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.

    invalid hidden

    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...

    czytaj dalej

    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...

    czytaj dalej

    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...

    czytaj dalej