yoel caspersen blog bloghoved

Weekendprojekt: Bedre sikkerhed med RPKI

Gennem længere tid har jeg haft implementering af Resource Public Key Infrastructure (RPKI) på min to-do-liste.

Ansporet af debatten under det seneste indlæg om vores indtog på de jyske fibernet besluttede jeg mig sidste weekend for at gøre noget ved det.

Filtrering af routes

Nu bliver det en smule langhåret, så vi starter med en lille, forsimplet opsummering af, hvordan internettet fungerer.

Grundlæggende set er internettet en lang række af interconnected networks - heraf betegnelsen internet.

Et netværk er i denne sammenhæng defineret som et Autonomous System (AS), som har en række IP-adresseranges (prefixes) tilknyttet.

Hvert AS-nummers prefixes kommer fra den pulje af IP-adresser, det enkelte AS-nummer har fået tildelt af IANA via det regionale registry (RIR).

Alle disse prefixes ligger i den globale route-tabel, som udveksles mellem de deltagende netværk via Border Gateway Protocol (BGP).

Route-tabellen er enorm - lige nu er der ca. 830.000 IPv4-prefixes i tabellen, og den bliver konstant ændret af de BGP-routere, som udgør rygraden i internettet.

Hver eneste gang en route bliver annonceret eller fjernet fra et AS-nummer, bliver ændringen propageret ud til samtlige BGP-routere i verden i løbet af få sekunder.

Når en BGP-router modtager en route fra en anden BGP-router, vil den indeholde et prefix og en AS path.

Sidstnævnte er en liste over de AS-numre, routen har været igennem, før den nåede frem, og den er en vigtig brik i den måde, internettet fungerer på. Når en router skal tage en beslutning om, hvilken vej en udgående pakke skal sendes for at nå hen til sin destination, vil længden af AS path i mange tilfælde være afgørende: Jo kortere vej, jo bedre.

show route 8.8.8.8 table kviknet.inet.0     
 
kviknet.inet.0: 800724 destinations, 1710187 routes (796901 active, 0 holddown, 3899 hidden)
+ = Active Route, - = Last Active, * = Both
 
8.8.8.0/24         *[BGP/170] 6d 22:28:43, MED 0, localpref 100, from 193.239.116.255
                      AS path: 15169 I, validation-state: unknown
                    > to 193.239.117.141 via ae0.7
                    [BGP/170] 6d 22:28:43, MED 0, localpref 100, from 193.239.117.0
                      AS path: 15169 I, validation-state: unknown
                    > to 193.239.117.141 via ae0.7
                    [BGP/170] 6d 22:27:23, localpref 100
                      AS path: 42525 15169 I, validation-state: unknown
                    > to 212.98.69.138 via ae1.760

Ovenfor ser vi et eksempel på en route til Google DNS-service 8.8.8.8: Routeren kan vælge mellem tre routes med i alt 2 unikke next-hops:

  • 193.239.117.141 (peering med Google på NL-ix)
  • 212.98.69.138 (IP transit - GlobalConnect)

Den direkte peering vinder, fordi AS path kun indeholder 1 AS-nummer, mens IP transit-routens AS path indeholder 2 AS-numre.

Hvordan ved vi, at 8.8.8.0/24 tilhører AS15169 (Google)?

Fordi AS15169 selv siger det - og her har vi hele årsagen til RPKI. BGP er by default usikkert, fordi ethvert AS-nummer kan annoncere vilkårlige IP scopes - det åbner for de såkaldte BGP hijack-angreb, hvor et rogue AS-nummer annoncerer et IP scope, som tilhører et andet AS-nummer.

Det kan føre til, at trafikken til det pågældende IP scope på dele af internettet ledes det forkerte sted hen, indtil nogen opdager problemet og får blokeret eller fjernet de falske routes.

Ofte skyldes BGP hijack simple miskonfigurationer, hvor en systemadministrator ved et uheld har tastet forkert - men det kan også bruges aktivt til spionage og svindel af kriminelle og efterretningstjenester.

Det er således et problem, der skal løses, selv om det dog forekommer noget sjældnere end simple DoS-angreb og anden IT-kriminalitet, da man er nødt til at have adgang til en BGP-router, der er koblet op på den globale route-tabel.

Løsningen finder vi i RPKI, hvor vi både kan sikre os mod, at andre annoncerer vores IP-adresser, samt filtrere indgående routes, så vi ikke uforvarende kommer til at sende trafik til andre netværk det forkerte sted hen.

RPKI-opsætning i praksis

Hos Kviknet har vi bla. følgende IP scope: 185.233.252.0/22, og vores AS-nummer er 204151.

Da vi er en dansk udbyder, hører vi under RIPE NCC, der er RIR for Europa og Mellemøsten.

For at beskytte vores IP-adresser skal vi have oprettet en Route Origin Authorisation for 185.233.252.0/22 - og til det formål skal vi bruge en Certificate Authority (CA).

Vi kan vælge mellem at lade RIPE være CA for vores IP-adresser, eller vi kan være det selv.

Vi har valgt at lade RIPE stå for det, da det er svært at få øje på gevinsten ved at skulle drive vores egen CA.

I RIPE's RPKI Dashboard opretter vi en ROA for hvert prefix, vi annoncerer fra vores AS-nummer, herunder også 185.233.252.0/22.

Illustration: Yoel Caspersen

Dashboardet kan gøre det for os, hvis vi sætter kryds i de pågældende prefixes og trykker på "Create ROAs for selected BGP Announcements".

Herefter klikker vi på "Review and publish changes", og hvis alt ser fint ud, trykker vi på "Publish!".

Illustration: Yoel Caspersen

Nu er ROA'en offentligt tilgængelig, og i løbet af den næste times tid vil den blive hentet af RPKI-validators over hele verden - og så vil samtlige BGP-routere, som har implementeret RPKI, blokere for routes til 185.233.252.0/22, som ikke annonceres af AS204151.

Det var den nemme del - nu skal vi opsætte vores egen filtrering af indgående routes, så vi kan blokere for hijack af andres routes.

Til det formål skal vi bruge en RPKI-validator og en RPKI-RTR-server, som begge er software, der installeres på en server.

Validatoren henter ROAs fra de forskellige RIRs med jævne mellemrum og vedligeholder et lokalt repository over disse. BGP-routeren, der skal filtrere indgående routes, kobles op på RTR-serveren, som kigger ned i det lokale repository, når en indgående route skal valideres.

Hvis routen er OK, får den state "validated" - men hvis routen indeholder det forkerte AS-nummer eller den forkerte prefix-længde, får den state "invalid". Hvis RTR-serveren ikke kan nås, eller routen ikke findes, fordi den ikke er beskyttet af RPKI, får den status "unknown".

Det er herefter op administratoren af BGP-routeren at lave et route-map, der bortfiltrerer routes, hvor status er "invalid".

Vi starter med at finde en Linux-server, vi kan installere en RPKI-validator og RPKI-RTR-server på.

RIPE foreslår en af følgende:

  • Routinator (by NLnetLabs)
  • The RPKI Validator (by the RIPE NCC)
  • OctoRPKI (by Cloudflare)
  • FORT (by NIC México)

RIPE's egen RPKI Validator er et tungt og bloated stykke Java-software (bruger ca. 1,5 GB RAM), så vi har valgt at køre med Routinator, som til sammenligning nøjes med lidt over 300 MB RAM.

Samtidig er Routinator en kombineret validator og RPKI-RTR-server, hvilket gør vores opsætningen nemmere.

Installationsprocessen er ret simpel på en server med Ubuntu 18.04 LTS:

# Install Rust from repo
apt install rustc
 
# Add non-privileged user
adduser routinator
 
# Shift to non-privileged user
su routinator
cd
 
# Install Routinator
cargo install routinator
 
# First time, accept ARIN's legaleze:
.cargo/bin/routinator init --accept-arin-rpa 
 
# Fetch repos
.cargo/bin/routinator -v vrps 

Herefter definerer vi routinator som en service i /etc/systemd/system/routinator.service:

[Unit]
After=network.target
 
[Service]
User=routinator
Group=routinator
ExecStart=/home/routinator/.cargo/bin/routinator server --rtr 10.128.5.150:3323
 
[Install]
WantedBy=default.target

Herefter aktiveres og startes vores nye service:

# Save and refresh service cache
systemctl daemon-reload
 
# Start service
systemctl start routinator.service
 
# Enable on startup
systemctl enable routinator.service
 
# Show status:
systemctl status routinator.service

Port 3323 åbnes i serverens firewall, og herefter er det tid til at konfigurere BGP-routeren.

Som BGP-routere anvender vi Juniper MX204 - vi starter med at konfigurere RPKI-RTR-sessionen og bygge en policy, der kan bruges til at bortfiltrere invalid routes:

set routing-options validation group rpki-validator session 10.128.5.150 port 3323
set routing-options validation notification-rib [ kviknet.inet.0 kviknet.inet6.0] 
set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2
set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1
set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0
set policy-options policy-statement RPKI-CHECK term valid from protocol bgp
set policy-options policy-statement RPKI-CHECK term valid from validation-database valid
set policy-options policy-statement RPKI-CHECK term valid then validation-state valid
set policy-options policy-statement RPKI-CHECK term valid then community add origin-validation-state-valid
set policy-options policy-statement RPKI-CHECK term invalid from protocol bgp
set policy-options policy-statement RPKI-CHECK term invalid from validation-database invalid
set policy-options policy-statement RPKI-CHECK term invalid then validation-state invalid
set policy-options policy-statement RPKI-CHECK term invalid then community add origin-validation-state-invalid
set policy-options policy-statement RPKI-CHECK term unknown from protocol bgp
set policy-options policy-statement RPKI-CHECK term unknown from validation-database unknown
set policy-options policy-statement RPKI-CHECK term unknown then validation-state unknown
set policy-options policy-statement RPKI-CHECK term unknown then community add origin-validation-state-unknown
set policy-options policy-statement REJECT-RPKI-INVALID term RPKI-CHECK from policy RPKI-CHECK
set policy-options policy-statement REJECT-RPKI-INVALID term RPKI-INVALID from community origin-validation-state-invalid
set policy-options policy-statement REJECT-RPKI-INVALID term RPKI-INVALID then reject

Denne policy kan nu inkluderes i opsætningen af vores BGP:

set routing-instances kviknet protocols bgp group nlix import REJECT-RPKI-INVALID

Filtreringen skal konfigureres på samtlige BGP-sessioner, der modtager routes fra internettet.

Herefter kan vi kontrollere, at det virker, ved at checke routes til hhv. IP-adresserne bag valid.rpki.cloudflare.com og invalid.rpki.cloudflare.com:

# Valid route - 104.16.129.7
run show route 104.16.129.7 table kviknet.inet.0 
 
kviknet.inet.0: 800817 destinations, 1710361 routes (796982 active, 0 holddown, 3911 hidden)
+ = Active Route, - = Last Active, * = Both
 
104.16.128.0/20    *[BGP/170] 07:12:08, localpref 100
                      AS path: 42525 1299 13335 I, validation-state: valid
                    > to 212.98.69.138 via ae1.760
                    [BGP/170] 20:00:43, localpref 100
                      AS path: 42525 3356 13335 I, validation-state: unverified
                    > to 185.107.12.28 via ae0.761
 
# Invalid route - 103.21.244.14
run show route 103.21.244.14 table kviknet.inet.0   
 
kviknet.inet.0: 800825 destinations, 1710403 routes (796992 active, 0 holddown, 3909 hidden)
+ = Active Route, - = Last Active, * = Both
 
0.0.0.0/0          *[Static/5] 9w1d 08:05:28
                      Discard
                    [BGP/170] 5w4d 03:57:33, localpref 100
                      AS path: I, validation-state: unverified
                    > to 185.107.12.28 via ae0.761

Det virker - der er ingen route til 103.21.244.14, og trafik til denne IP-adresse smides væk.

Virker Cloudflares Twitter-shaming?

CDN-udbyderen Cloudflare har for nylig oprettet et website på isbgpsafeyet.com.

Her kan man som bruger teste, om ens internetudbyder har implementeret RPKI - og shame sin ISP, hvis det ikke ser ud til at være tilfældet.

Illustration: Yoel Caspersen

Der er dog en ulempe ved den slags: Det forsimpler et emne, der er væsentligt mere komplekst end en simpel Twitter-besked og den gennemsnitlige Twitter-bruger kan kapere.

Korrekt implementeret RPKI hos en internetudbyder er ikke en garanti mod BGP hijacks - en bruger vil stadig kunne blive ledt ind på et falsk website, hvis netværket, der hoster det legitime website, ikke har implementeret RPKI.

Beskyttelsen bliver dog gradvist bedre i takt med udbredelsen, og da RPKI er en god idé, har vi implementeret det, uagtet at Cloudflares kampagne virker en smule aggressiv.

Men måske kunne Twitter-shaming bruges til at udbrede en anden god idé i form af IPv6:

Illustration: Yoel Caspersen

Desværre ville det også ramme de udbydere, som aktivt udbreder IPv6, men er ramt af begrænsninger i andres infrastruktur - som fx på coax-nettet, hvor vi hos Kviknet pga. en underleverandørs valg ikke kan levere IPv6 på coax-nettet, men kun på DSL og fiber.

Derfor vil jeg i al stilfærdighed nøjes med at spørge:

Har din internetudbyder implementeret RPKI - og IPv6?

God weekend.

Relateret indhold

Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Kristian Klausen

Lærerigt indlæg :)

Nu er jeg ikke netværksmand, men så vidt jeg kan forstå, så løser RPKI ikke hele problemet, da der ikke er path validation, det skulle dog være et noget mindre problem, da de fleste routere vælger den korteste vej, og det kan være svært at tilbyde en vej der er kortere.

BGPsec skulle efter sigende kunne løse problemet, men det er vist ikke særlig udbredt(?), der arbejdes dog på andre løsninger.

Jeg stødte på denne artikel ifm. min "reearch", den giver et ganske fint overblik.

Har din internetudbyder implementeret RPKI - og IPv6?

ROA er opsat på ca ~50% af min internetudbyders prefixes, filtering ser dog ikke ud til at være opsat. Ift. IPv6 så tilbyder de det vha. 6rd, jeg synes dog ikke det virker helt fantastisk altid (jeg har periodisk oplevet 100% pakketab).

  • 1
  • 0
#7 Yoel Caspersen Blogger

Den version der er i Ubuntu 18.04 arkiver er forholdsvis ny (30. januar), så det lyder lidt underligt hvis det skulle være tilfældet?

Jeg har netop gentaget installationsprocessen på en frisk server - apt install rustc ser ud til at klare opgaven. Det virker som om, kompileringen af routinator tog lidt længere tid, men jeg har ikke nogen konkret måling, så det kan være indbildning.

Blogindlægget er opdateret.

  • 2
  • 0
#8 Glenn Møller-Holst

Det var eet punkt på:

Mutually Agreed Norms for Routing Security: https://www.manrs.org/ Citat: “… How MANRS helps Network Operators MANRS outlines four simple but concrete actions that ISPs should take: Filtering Anti-Spoofing Coordination Global Validation

How MANRS helps IXPs A separate set of Actions applies explicitly to Internet Exchange Points. Prevent Propagation Promote MANRS Protect Peering Platform Facilitate ISP Communication Provide Monitoring Tools …”

What Participants Say About MANRS (der er mange sider 9+): https://www.manrs.org/about/testimonials/

MANRS Implementation Guide – Online Version: https://www.manrs.org/isps/guide/

MANRS IXP Programme. MANRS is an important step toward a globally robust and secure routing infrastructure: https://www.manrs.org/ixps/ Citat: “… The MANRS Actions were initially designed for network operators, but Internet Exchange Points (IXPs) should also play an active role in protecting the Internet. IXPs represent active communities with common operational objectives and already contribute to a more resilient and secure Internet infrastructure. MANRS can help IXPs build safe neighborhoods, leveraging the MANRS security baseline. It also demonstrates an IXP’s commitment to security and sustainability of the Internet ecosystem, and dedication to providing high quality services. …”

  • 0
  • 0
#10 Glenn Møller-Holst

Jeg har ikke kommenteret på, hvor meget I har implementeret.

Her er fire punkter:

How MANRS helps Network Operators MANRS outlines four simple but concrete actions that ISPs should take: * Filtering "4.4. Filtering – Preventing propagation of incorrect routing information" <-Dette punkt er nævn i artiklen. * Anti-Spoofing * Coordination * Global Validation

Jeg har nævnt MANRS, da der sikkert er mange i Danmark som ikke kender dem og deres engagement.

  • 0
  • 0
#11 Ivo Santos

RPKI er sikkert fint, men os dødelige står med et endnu støre problem, og det problem er svindel emails.

Svindel emails til falske dating sider, og folk som udgiver sig for at arbejde for den engelske bank, og NETS relaterede svindel notifikationer.

Mit største ønske er nok at disse svindel emails blev blokeret på ISP niveau. Alt hvad teleselskaberne skal gøre er at meddele sender om at postkassen er fuld, eller en anden lignende underlig fejl kode.

  • 0
  • 0
#12 Yoel Caspersen Blogger

Mit største ønske er nok at disse svindel emails blev blokeret på ISP niveau. Alt hvad teleselskaberne skal gøre er at meddele sender om at postkassen er fuld, eller en anden lignende underlig fejl kode.

Det ville være et skråplan af dimensioner.

Som ISP har vi intet at gøre med din e-mail, det er en sag mellem dig og din eventuelle udbyder af mailsystem, og hvis vi skulle gå ind og analysere din trafik og på egen hånd tage stilling til, hvad der er godt for dig, og hvad der ikke er, vil vi ende med at have et kinesisk internet.

Det ville starte med blokering af svindel-mails som et figenblad. Herefter ville vi tage skridtet videre og blokere uopfordret marketing, herunder især marketing fra vores konkurrenter til vores kunder. Dernæst ville myndighederne komme rendende i tide og utide og bede om at få udleveret kopier af trafikken, nu vi alligevel har snablen nede i den.

Ud over de praktiske udfordringer i at kigge ind i krypteret trafik, er det næppe en situation, nogen reelt ville ønske sig.

  • 11
  • 0
#14 Emil Mølgaard

Off topic for RPKI-snakken, men relateret til spam-mails mv.

Jeg kan anbefale OpenDNS til at holde skidt og kanel ude af ens netværk. OpenDNS er blevet en del af Cisco og de tilbyder deres Umbrella-løsning gratis til private.

  1. Opret en konto på OpenDNS.
  2. Registrer din public IP.
  3. Opsæt hvilke DNS-opslag du ønsker filtreret fra.
  4. Indsæt OpenDNS adresserne i din routers DHCP server.
  5. Hvis du har en flygtig public IP, så sæt en lille service til at opdatere din registrering hos OpenDNS.

Job done. Nu er alle DNS opslag af suspekte sider filtreret fra på hele netværket på tværs af alle dimser og devices.

Jeg bruger det selv sammen med Pi-Hole på en Raspberry Pi, som så agerer lokal DNS cache og tilføjer yderligere reklamefilter på netværket. Samtidig er det på den Pi servicen kører, som opdaterer min public IP. Det har fjernet mere end halvdelen af alle DNS-opslag på vores net.

  • 0
  • 0
#16 Jesper Nielsen

... var jeg lige ved at råbe ud i lokalet for mig selv, da jeg ved et besøg på isbgpsafeyet.com så, at der stod FAILURE efter at have trykket på "Test your ISP" (som er Kviknet).

Det kan da ikke passe, at Kviknet dumper testen, for Yoel har jo lige implementeret RPKI!

Og det gjorde det så heller ikke. Jeg sidder jo for pokker med min arbejdslaptop, der er på VPN, så det er selvfølgelig Forskningsnettet/DeiC, der dumper testen.

Uden VPN er testen dejlig grøn.

Nå, men jeg ville egentlig bare sige tak, fordi I bruger tid på (fremtids)sikring.

  • 0
  • 0
#17 Yoel Caspersen Blogger

Jeg har netop tilføjet en vigtig detalje til vores Juniper-opsætning af RPKI:

set routing-options validation notification-rib [ kviknet.inet.0 kviknet.inet6.0]

Blot til info andre derude, som måtte falde over dette indlæg og bruge det til opsætning af RPKI - og som anvender VRF på Juniper.

  • 1
  • 0
Log ind eller Opret konto for at kommentere