Tere, minu nimi on Aleksander Azimov. Yandexis arendan erinevaid jälgimissüsteeme, aga ka transpordivõrgu arhitektuuri. Aga täna räägime BGP protokollist.
Nädal tagasi lubas Yandex kõigi peering-partnerite liidestes ja liikluse vahetuspunktides ROV-i (Route Origin Validation). Lugege allpool, miks seda tehti ja kuidas see mõjutab suhtlust sideoperaatoritega.
BGP ja mis sellel viga on
Tõenäoliselt teate, et BGP loodi domeenidevahelise marsruutimisprotokollina. Sellegipoolest suutis kasutusjuhtude arv kasvada: tänaseks on BGP tänu arvukatele laiendustele muutunud sõnumisiiniks, mis hõlmab ülesandeid operaatori VPN-ist nüüd moeka SD-WAN-i ja on leidnud rakendust isegi SDN-laadse kontrolleri transport, mis muudab kaugusvektori BGP millekski sarnaseks linkide sat-protokolliga.
Joon. 1.
Miks on BGP saanud (ja saab jätkuvalt) nii palju kasutusi? Sellel on kaks peamist põhjust.
- BGP on ainus protokoll, mis töötab autonoomsete süsteemide (AS) vahel;
- BGP toetab atribuute TLV-vormingus (tüüp-pikkus-väärtus). Jah, protokoll ei ole selles üksi, kuid kuna telekommunikatsioonioperaatorite ristmikel pole seda millegagi asendada, osutub alati tulusamaks lisada sellele mõni muu funktsionaalne element, kui toetada täiendavat marsruutimisprotokolli.
Mis tal viga on? Lühidalt öeldes ei ole protokollis sisseehitatud mehhanisme saadud teabe õigsuse kontrollimiseks. See tähendab, et BGP on a priori usaldusprotokoll: kui soovite maailmale öelda, et teil on nüüd Rostelecomi, MTS-i või Yandexi võrk, siis palun!
IRRDB-põhine filter – halvimatest parim
Tekib küsimus: miks Internet sellises olukorras ikkagi töötab? Jah, see töötab enamiku ajast, kuid samal ajal plahvatab perioodiliselt, muutes terved riiklikud segmendid kättesaamatuks. Kuigi häkkerite tegevus BGP-s on samuti tõusuteel, on enamik kõrvalekaldeid siiski põhjustatud vigadest. Selle aasta näide on Valgevenes, mis muutis MegaFoni kasutajatele pooleks tunniks ligipääsmatuks olulise osa Internetist. Veel üks näide - purustas ühe maailma suurima CDN-võrgu.
Riis. 2. Cloudflare'i liikluse pealtkuulamine
Kuid ikkagi, miks sellised anomaaliad tekivad kord poole aasta jooksul, mitte iga päev? Kuna operaatorid kasutavad marsruutimisteabe väliseid andmebaase, et kontrollida, mida nad BGP naabritelt saavad. Selliseid andmebaase on palju, osa neist haldavad registripidajad (RIPE, APNIC, ARIN, AFRINIC), osa on sõltumatud mängijad (kuulsaim on RADB), samuti on terve hulk suurettevõtetele kuuluvaid registripidajaid (Tase3 , NTT jne). Just tänu nendele andmebaasidele säilitab domeenidevaheline marsruutimine oma töö suhtelise stabiilsuse.
Siiski on nüansse. Marsruutimisteavet kontrollitakse ROUTE-OBJECTS ja AS-SET objektide põhjal. Ja kui esimene eeldab volitust IRRDB osa jaoks, siis teise klassi jaoks klassina volitust pole. See tähendab, et igaüks saab lisada oma komplekti kedagi ja sellega mööda minna ülesvoolu pakkujate filtritest. Pealegi ei ole garanteeritud AS-SET-i nimetamise ainulaadsus erinevate IRR-i aluste vahel, mis võib kaasa tuua üllatavaid efekte koos äkilise ühenduse katkemisega sideoperaatori jaoks, kes omalt poolt midagi ei muutnud.
Täiendavaks väljakutseks on AS-SETi kasutusmuster. Siin on kaks punkti:
- Kui operaator saab uue kliendi, lisab ta selle oma AS-SET, kuid ei eemalda seda peaaegu kunagi;
- Filtrid ise konfigureeritakse ainult klientide liidestes.
Selle tulemusel koosneb BGP-filtrite kaasaegne formaat klientidega liidestes olevate filtrite järkjärguline halvenemine ja a priori usaldus selle vastu, mis tuleb koostööpartneritelt ja IP-transiiditeenuse pakkujatelt.
Mis asendab AS-SET-il põhinevaid eesliidefiltreid? Kõige huvitavam on see, et lühiajaliselt - mitte midagi. Kuid tekkivad täiendavad mehhanismid, mis täiendavad IRRDB-põhiste filtrite tööd ja esiteks on see loomulikult RPKI.
RPKI
Lihtsustatult võib RPKI arhitektuuri pidada hajutatud andmebaasiks, mille kirjeid saab krüptograafiliselt kontrollida. ROA (Route Object Authorization) puhul on allkirjastaja aadressiruumi omanik ja kirje ise on kolmik (prefiks, asn, max_length). Sisuliselt postuleerib see kirje järgmist: aadressiruumi $prefix omanik on volitanud AS-i numbrit $asn reklaamima eesliiteid, mille pikkus ei ületa $max_length. Ja ruuterid, kasutades RPKI vahemälu, saavad paari vastavust kontrollida eesliide – esimene kõneleja teel.
Joonis 3. RPKI arhitektuur
ROA-objekte on standarditud üsna pikka aega, kuid kuni viimase ajani jäid need IETF-i ajakirjas tegelikult ainult paberile. Minu meelest kõlab selle põhjus hirmutavalt – halb turundus. Pärast standardimise lõpuleviimist oli stiimul see, et ROA kaitses BGP kaaperdamise eest – mis polnud tõsi. Ründajad saavad ROA-põhistest filtritest hõlpsasti mööda minna, sisestades tee algusesse õige vahelduvvoolu numbri. Ja niipea, kui see arusaamine tuli, oli järgmine loogiline samm ROA kasutamisest loobumine. Ja tõesti, miks me vajame tehnoloogiat, kui see ei tööta?
Miks on aeg meelt muuta? Sest see pole kogu tõde. ROA ei kaitse BGP-s häkkerite tegevuse eest, vaid kaitseb liikluses juhuslike kaaperdamiste eest, näiteks BGP staatilistest leketest, mis on muutumas üha tavalisemaks. Erinevalt IRR-põhistest filtritest saab ROV-i kasutada mitte ainult liidestes klientidega, vaid ka liidestes partnerite ja ülesvoolu pakkujatega. See tähendab, et koos RPKI kasutuselevõtuga kaob BGP-st järk-järgult a priori usaldus.
Nüüd hakkavad ROA-l põhinevat marsruutide kontrollimist võtmetegijad tasapisi juurutama: Euroopa suurim IX viskab juba valed marsruudid kõrvale, Tier-1 operaatorite hulgas tasub esile tõsta AT&T, mis on lubanud oma partnerluspartneritega liidestes filtrid. Projektile on lähenemas ka suurimad sisupakkujad. Ja kümned keskmise suurusega transiidioperaatorid on selle juba vaikselt juurutanud, kellelegi sellest rääkimata. Miks kõik need operaatorid RPKI-d rakendavad? Vastus on lihtne: kaitsta oma väljuvat liiklust teiste inimeste vigade eest. Seetõttu on Yandex üks esimesi Vene Föderatsioonis, kes lisab oma võrgu servale ROV-i.
Mis saab edasi?
Oleme nüüd lubanud marsruutimisteabe kontrolli liikluse vahetuspunktide ja privaatsete ühisturgude liidestes. Lähitulevikus lubatakse kinnitamine ka ülesvoolu liikluse pakkujatega.
Mis vahet see teie jaoks teeb? Kui soovite oma võrgu ja Yandexi vahelise liikluse marsruutimise turvalisust suurendada, soovitame:
- Подписать свое адресное пространство - see on lihtne, võtab keskmiselt 5-10 minutit. See kaitseb meie ühenduvust juhul, kui keegi varastab tahtmatult teie aadressiruumi (ja see juhtub kindlasti varem või hiljem);
- Installige üks avatud lähtekoodiga RPKI vahemälu (, ) ja lubage võrgupiiril marsruudi kontrollimine - see võtab rohkem aega, kuid jällegi ei põhjusta see tehnilisi raskusi.
Yandex toetab ka uuel RPKI objektil põhineva filtreerimissüsteemi arendamist - (Autonoomse süsteemi pakkuja autoriseerimine). ASPA ja ROA objektidel põhinevad filtrid ei saa mitte ainult asendada "lekkivaid" AS-SET-e, vaid ka sulgeda BGP-d kasutades MiTM-i rünnakute probleemid.
Täpsemalt räägin ASPAst kuu aja pärast toimuval konverentsil Next Hop. Seal võtavad sõna ka kolleegid Netflixist, Facebookist, Dropboxist, Juniperist, Mellanoxist ja Yandexist. Kui tunned huvi võrgupinu ja selle arendamise vastu tulevikus, tule kohale .
Allikas: www.habr.com