Blocklists dynamisk genereret fra IRR

Jeg er træt af altid at skulle brokke mig, så idag vil jeg forsøge mig med et konstruktivt indlæg - ikke at det er et nytråsfortsæt udelukkende at være konstruktiv!

Sagen er at jeg idag i noget netværk stødte på et skrækkeligt forsøg på at lave en positivliste for Google - som eksempelvis kunne bruges for at sikre at Google botterne altid kan indeksere. Problemet var at vedkommende havde brugt en søgemaskine som havde givet et link til en ahhheeemm "ældre" liste. Den var sidst opdateret Januar 2014, ihvertfald var den fyldt med fejl og havde formentlig ikke deres nyeste IP ranges med.

Godt, nedenstående er mit bud på hvordan man laver en bedre liste over de netværk som en netværksudbyder bruger, med Google AS15169 som eksempel. Se også RIPEstat hvis du blot er lidt nysgerrig AS15169 routing information

Først lidt terminologi. Internet er vores allesammen verdensomspændende netværk som via den dynamiske BGP routing protokol tillader netværk identificeret med AS numre (ASN) at annoncere deres og deres kunder/samarbejdspartneres netværk. Det sikres ved hjælp af routing policies, import policies som i bedste fald kun accepterer de prefixes som de pågældende netværk har lov til at annoncere. Arbejdet med disse policies lettes ved at man i Internet Routing Registries skriver sine oplysninger ind med Routing Policy Specification Language (RPSL).

Kort fortalt er det netværket selv som opdaterer, eksempelvis Censurfridns objekterne og udvalgte af mine objekter:

aut-num:        AS198794
as-name:        CENSURFRIDNS
descr:          Thomas Steen Rasmussen
remarks:        Censurfridns.dk
org:            ORG-TYK1-RIPE
import:         from AS59469 accept ANY
import:         from AS9167 accept ANY
export:         to AS59469 announce AS198794
export:         to AS9167 announce AS198794
 
route:          91.239.100.0/24
descr:          CENSURFRIDNS
origin:         AS198794
mnt-by:         MNT-SOLIDO
source:         RIPE # Filtered
 
aut-num:        AS59469
as-name:        SOLIDO-NETWORKS
descr:          Solido Networks ApS
org:            ORG-SNA30-RIPE
import:         from AS174 action pref=110; accept ANY
export:         to AS174 announce AS-SOLIDO
...
import:         from AS198794 accept { 91.239.100.0/24 }
export:         to AS198794 announce ANY
 
as-set:         AS-SOLIDO
descr:          Solido Hosting A/S
members:        AS12617
members:        AS20144
...
members:        AS59469
...
members:        AS198794

Hvilket gør at man kan bruge programmer der er lavet til det formål at generere routing policies - der kan loades direkte ind i eksempelvis Cisco eller Juniper routere. De kan så passende køres en gang i døgnet, hvad udbydere typisk gør. Et kort eksempelvis er således - i Cisco format:

$ bgpq3 AS198794
no ip prefix-list NN
ip prefix-list NN permit 91.239.100.0/24

Et lidt længere eksempel med mit ASN:

$ bgpq3 AS59469
no ip prefix-list NN
ip prefix-list NN permit 94.126.176.0/21
ip prefix-list NN permit 185.27.112.0/22
...

NB: hvis man ser nøje efter er det kun de 2 første prefixes som tilhører min organisation, dem jeg har fjernet tilhører kunder som ikke har eget ASN. En slutkunde eller et større netværk som Google vil dog oftest kun annoncere sine egne netværk, og derfor kan man nemt lave listen med Googles ASN:

$ bgpq3 AS15169 | head -7
no ip prefix-list NN
ip prefix-list NN permit 1.0.0.0/24
ip prefix-list NN permit 1.1.1.0/24
ip prefix-list NN permit 1.2.3.0/24
ip prefix-list NN permit 8.8.4.0/24
ip prefix-list NN permit 8.8.8.0/24
ip prefix-list NN permit 8.15.202.0/24

Listen var omkring 6700 - men man kan aggregere listen med -A og får så en lidt kortere liste som man kan arbejde videre med. Så inden for nogle minutter har man et script i det format man ønsker - her flad tekstfil der kan bruges med PF firewallen som jeg bruger. Ialt endte den dags dato på 83 linier i output. Det kan min PF firewall snildt håndtere.

$ bgpq3 -A AS15169 | cut -f 5 -d ' ' | sort -n -t . -k 1,1n | uniq  > pf-tables/google.list
 
# Expected output approx:
# 1.0.0.0/24
# 8.8.4.0/24
# 23.236.48.0/20
# 64.15.112.0/20

og en tilsvarende eksempel regel i firewallen:

    table <GOOGLE>                 persist file '/etc/pf/google.list'
...
    pass in quick on egress inet proto { tcp } from <GOOGLE>  to blah port 80

Konklusion

Kort fortalt har vi nu genereret en liste med følgende karakteristika:

  • Data kommer fra Google så direkte som muligt
  • Data er opdateret - for ellers vil de pågældende netværk ikke være fuldt synlige på internet
  • Opdatering går meget hurtigt, opslag hos mig tog et par sekunder

Det er klart at anbefale fremfor diverse 2-hånds websites som helt sikkert indeholder fejl.

I andre tilfælde vil man kunne hente data direkte fra det pågældende netværk via en URL, som for eksempel fra Spamhaus:

#!/bin/sh
# Andreas
curl -s http://www.spamhaus.org/drop/drop.lasso | cut -d";" -f1 | grep -e '^$' -v > /etc/pf/spamhaus_drop.list

Er det noget I andre bruger? og husk det er bedre at lave positivlister - hvem der må komme ind, end negativlister der konstant skal opdateres.

Evil stuff

Ja, det vil også være nemt at sige, "Ha! Gider ikke data fra dette ASN" - og det er blandt andet det jeg også skal bruge det til, når der kommer spam fra et netværk - væk med HELE det netværk.

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Baldur Norddahl

Er der ikke et problem med datakvaliteten? Det er ikke korrekt at whois data skal være opdateret (RIPE eller RADB) for at man er fuldt synlig. Mit indtryk er at det tværtimod står ret ringe til med at få de ting opdateret.

Uden for RIPE er der end ikke et fuldt officielt system til det. Amerikanerne kan bruge RADB men det er frivilligt og koster penge. Dertil er der ingen sikkerhed, så hvem som helst kan opdatere RADB. Spammere bruger at indsætte offeret i RADB hvis det ikke er der i forvejen. På den måde kommer spammeren før de rigtige annonceringer hos dem der blindt bygger filtre bygget på RADB.

Der har været en del debat omkring forældede registreringer, hvor trediepart referer til dit AS-nummer uden at de længere har nogen kontakt med dig. I nogle tilfælde har de aldrig været i kontakt fordi der er tale om genbrugte resourcer. Det kan også bare være en fejl. Men du har ingen måde at tvinge dem til at stoppe.

I dit eksempel bruger du Google og det er fint nok hvis man kan stole på at Google har styr på deres sager. Det kan man bare ikke generelt, så man må på anden vis undersøge om dette er folk der faktisk opdaterer whois korrekt.

En mere pålidelige metode kunne være at bruge BGP direkte. Hvis du ser et prefix med AS15169 som origin i den globale routing tabel, så er det så godt som 100% at det er en IP range der tilhører Google. Du kan eventuelt validere med RPKI. Bemærk dette er ikke det samme som at tage det fra whois. Der er ingen direkte kobling fra BGP til whois.

  • 0
  • 0
Henrik Kramshøj Blogger

Tak for dine gode kommantarer

Datakvaliteten for whois er langt bedre end tilfældige 3. part som lægger en liste til download på HTTP et sted, og ikke opdaterer et helt år - som var udgangspunktet. Dernæst kan du med manuelle whois-opslag slå eksempelvis maintainer op på diverse objekter. Det giver en vis grad af sikkerhed for at du får de rigtige data. Ja, der kan være både fejl og spammere kan måske indsætte falske objekter for gamle netværk som de hijacker. YMMV - men for eksempelvis google objekter ser det rimeligt ud.

Mht. korrektheden at man skal have whois for at være synlig. Det er et krav fra mange transitleverandører - du skal fortælle hvad AS numre og prefixes du påtænker at annoncere. Det kan gøres ved en statisk liste i et skrækkeligt format, ofte Excel dokumenter og resulterer i en lang behandlingstid ved ændringer. Hvorimod du kan angive et AS-set og dermed sker opdateringer automatisk. Så de-facto jo - du skal have Whois objekterne under egen kontrol og din udbyder ændrer så automatisk filtrene.

Brugen af netop bgpq3 er også fra RIPE kursus, og man kan hente deres materialer hos dem:
http://www.ripe.net/lir-services/training/material

Mht. at bruge BGP direkte vil det for mig være nemt at tilføje en probe ind i mit netværk med OpenBGP og dermed lave det direkte - men vil jo ikke løse problemet ... for så vil en spammers annonceringer jo dermed automagisk blive tilføjet til netop de lister der skulle forhindre adgang for andre end de rigtige. Så man slipper ikke udenom at man skal have nogle importfiltre - medmindre vi vil tillade alting ind.

Det er også for de fleste et problem at finde et BGP feed, hvorimod Whois altid er lige ved hånden.

Det pålidelige ville være at bruge RPKI og jeg følger interesseret med når Alexander Band, @alexander_band på twitter skriver og taler om RPKI. Der går nok noget tid før det vinder større indpas generelt. Jeg glæder mig til at høre status 11.-15. maj hvor der er RIPE70 https://ripe70.ripe.net/ - forventer jeg skal afsted. Jeg glæder mig til om et par år at kunne sige ting som "Vi er under angreb, dem som kommer fra netværk uden RPKI får max 10% af båndbredden, mens dem fra RPKI får resten"

RPKI for dem som ikke genkender forkortelse er public key infrastruktur på routing

Resource Public Key Infrastructure (RPKI), also known as Resource Certification, is a specialized public key infrastructure (PKI) framework designed to secure the Internet's routing infrastructure.

Kilde: https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure

  • 0
  • 0
Baldur Norddahl

Anekdote fra vores to IP transit leverandører: TDC kræver route objekter i IRR, de er 100% ligeglade med RPSL. CogentCo er 100% ligeglade med alt, jeg kan annoncere dit netværk hvis jeg lyster.

Faktisk var vores RPSL fucked up på et tidspunkt. Jeg bemærkede ikke nogen forskel.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize