Saluton, mia nomo estas Aleksandro Azimov. Ĉe Yandex, mi disvolvas diversajn monitorajn sistemojn, kaj ankaŭ transportan retan arkitekturon. Sed hodiaŭ ni parolos pri la protokolo BGP.
Antaŭ unu semajno, Yandex ebligis ROV (Route Origin Validation) ĉe la interfacoj kun ĉiuj samnivelaj partneroj, same kiel trafikinterŝanĝajn punktojn. Legu sube pri kial tio estis farita kaj kiel ĝi influos interagadon kun telekomunikaj telefonistoj.
BGP kaj kio estas malbona kun ĝi
Vi verŝajne scias, ke BGP estis desegnita kiel interdomajna vojprotokolo. Tamen, survoje, la nombro da uzkazoj sukcesis kreski: hodiaŭ, BGP, danke al multaj etendaĵoj, fariĝis mesaĝo buso, kovrante taskojn de operatoro VPN ĝis la nun moda SD-WAN, kaj eĉ trovis aplikon kiel transporto por SDN-simila regilo, turnante distancvektoron BGP en io simila al la ligiloj sidis protokolo.
Fig. 1.
Kial BGP ricevis (kaj daŭre ricevas) tiom da uzoj? Estas du ĉefaj kialoj:
- BGP estas la nura protokolo kiu funkcias inter aŭtonomaj sistemoj (AS);
- BGP subtenas atributojn en formato TLV (tipo-longo-valoro). Jes, la protokolo ne estas sola en ĉi tio, sed ĉar estas nenio por anstataŭigi ĝin ĉe la krucvojoj inter telekomunikaj telefonistoj, ĉiam rezultas pli profite ligi alian funkcian elementon al ĝi ol subteni aldonan enrutigan protokolon.
Kio estas al li? Resume, la protokolo ne havas enkonstruitajn mekanismojn por kontroli la ĝustecon de la ricevitaj informoj. Tio estas, BGP estas apriora fidinda protokolo: se vi volas diri al la mondo, ke vi nun posedas la reton de Rostelecom, MTS aŭ Yandex, bonvolu!
Filtrilo bazita en IRRDB - la plej bona el la plej malbona
Estiĝas la demando: kial interreto ankoraŭ funkcias en tia situacio? Jes, ĝi funkcias plejofte, sed samtempe ĝi periode eksplodas, igante tutajn naciajn segmentojn nealireblaj. Kvankam hacker-agado en BGP ankaŭ pliiĝas, plej multaj anomalioj ankoraŭ estas kaŭzitaj de cimoj. La ĉi-jara ekzemplo estas en Belorusio, kiu faris signifan parton de la Interreto nealirebla por MegaFon-uzantoj dum duonhoro. Alia ekzemplo - rompis unu el la plej grandaj CDN-retoj en la mondo.
Rizo. 2. Interkapto de trafiko Cloudflare
Sed tamen, kial tiaj anomalioj okazas unufoje ĉiujn ses monatojn, kaj ne ĉiutage? Ĉar portantoj uzas eksterajn datumbazojn de vojaj informoj por kontroli kion ili ricevas de BGP-najbaroj. Estas multaj tiaj datumbazoj, kelkaj el ili estas administritaj de registriloj (RIPE, APNIC, ARIN, AFRINIC), kelkaj estas sendependaj ludantoj (la plej fama estas RADB), kaj ekzistas ankaŭ tuta aro da registriloj posedataj de grandaj kompanioj (Nivelo3). , NTT, ktp.). Estas danke al ĉi tiuj datumbazoj, ke inter-domajna vojigo konservas la relativan stabilecon de sia funkciado.
Tamen, estas nuancoj. Vojaj informoj estas kontrolitaj surbaze de ROUTE-OBJECTS kaj AS-SET objektoj. Kaj se la unua implicas rajtigon por parto de la IRRDB, tiam por la dua klaso ne ekzistas rajtigo kiel klaso. Tio estas, ĉiu povas aldoni iun ajn al siaj aroj kaj per tio preteriri la filtrilojn de kontraŭfluaj provizantoj. Krome, la unikeco de la AS-SET-nomado inter malsamaj IRR-bazoj ne estas garantiita, kio povas konduki al surprizaj efikoj kun subita perdo de konektebleco por la telekomunika operatoro, kiu, siaflanke, nenion ŝanĝis.
Plia defio estas la uzpadrono de AS-SET. Estas du punktoj ĉi tie:
- Kiam operatoro ricevas novan klienton, ĝi aldonas ĝin al sia AS-SET, sed preskaŭ neniam forigas ĝin;
- La filtriloj mem estas agorditaj nur ĉe la interfacoj kun klientoj.
Kiel rezulto, la moderna formato de BGP-filtriloj konsistas el iom post iom degradado de filtriloj ĉe la interfacoj kun klientoj kaj apriore fido je kio venas de peering partneroj kaj IP-transitaj provizantoj.
Kio anstataŭigas prefiksajn filtrilojn bazitajn sur AS-SET? La plej interesa afero estas, ke baldaŭ - nenio. Sed aldonaj mekanismoj aperas, kiuj kompletigas la laboron de filtriloj bazitaj en IRRDB, kaj antaŭ ĉio, ĉi tio estas, kompreneble, RPKI.
RPKI
En simpligita maniero, la RPKI-arkitekturo povas esti opiniita de kiel distribuita datumbazo kies rekordoj povas esti kriptografie kontrolitaj. En la kazo de ROA (Route Object Authorization), la subskribinto estas la posedanto de la adresspaco, kaj la rekordo mem estas triopo (prefikso, asn, max_length). Esence, ĉi tiu eniro postulas la jenon: la posedanto de la $prefiksa adresspaco rajtigis la AS-numeron $asn reklami prefiksojn kun longo ne pli granda ol $max_length. Kaj enkursigiloj, uzante la kaŝmemoron RPKI, povas kontroli la paron por konformeco prefikso - unua parolanto survoje.
Figuro 3. RPKI-arkitekturo
ROA-objektoj estas normigitaj dum sufiĉe longa tempo, sed ĝis antaŭ nelonge ili fakte restis nur papere en la revuo de IETF. Laŭ mi, la kialo de tio sonas timiga - malbona merkatado. Post kiam normigado estis kompletigita, la instigo estis ke ROA protektita kontraŭ BGP-kapero - kio ne estis vera. Atakantoj povas facile preterpasi ROA-bazitajn filtrilojn enmetante la ĝustan AC-numeron komence de la vojo. Kaj tuj kiam ĉi tiu konstato venis, la sekva logika paŝo estis forlasi la uzon de ROA. Kaj vere, kial ni bezonas teknologion se ĝi ne funkcias?
Kial estas tempo ŝanĝi vian opinion? Ĉar ĉi tio ne estas la tuta vero. ROA ne protektas kontraŭ hacker-agado en BGP, sed protektas kontraŭ hazardaj trafikkaperoj, ekzemple de senmovaj likoj en BGP, kiu iĝas pli ofta. Ankaŭ, male al IRR-bazitaj filtriloj, ROV povas esti uzata ne nur ĉe la interfacoj kun klientoj, sed ankaŭ ĉe la interfacoj kun kunuloj kaj kontraŭfluaj provizantoj. Tio estas, kune kun la enkonduko de RPKI, apriora fido iom post iom malaperas de BGP.
Nun ROA-bazita itinerkontrolado estas iom post iom efektivigita de ŝlosilaj ludantoj: la plej granda eŭropa IX jam forĵetas malĝustajn itinerojn; inter Tier-1-funkciigistoj, indas reliefigi AT&T, kiu ebligis filtrilojn ĉe la interfacoj kun siaj samnivelaj partneroj. La plej grandaj enhavprovizantoj ankaŭ alproksimiĝas al la projekto. Kaj dekoj da mezgrandaj transportistoj jam trankvile efektivigis ĝin, sen diri al iu ajn pri ĝi. Kial ĉiuj ĉi tiuj telefonistoj efektivigas RPKI? La respondo estas simpla: protekti vian elirantan trafikon de la eraroj de aliaj homoj. Tial Yandex estas unu el la unuaj en la Rusa Federacio, kiu inkluzivas ROV ĉe la rando de sia reto.
Kio okazos poste?
Ni nun ebligis kontroli informojn pri vojigo ĉe la interfacoj kun trafikinterŝanĝaj punktoj kaj privataj kunigoj. Baldaŭ, konfirmo ankaŭ estos ebligita kun kontraŭfluaj trafikaj provizantoj.
Kian diferencon ĉi tio faras por vi? Se vi volas pliigi la sekurecon de trafikvojigo inter via reto kaj Yandex, ni rekomendas:
- Subskribu vian adresspacon - ĝi estas simpla, daŭras 5-10 minutojn averaĝe. Ĉi tio protektos nian konekteblecon en la okazo, ke iu senintence ŝtelas vian adresspacon (kaj tio certe okazos baldaŭ aŭ malfrue);
- Instalu unu el la malfermfontaj RPKI-kaŝmemoroj (, ) kaj ebligu itineran kontrolon ĉe la retolimo - tio daŭros pli da tempo, sed denove, ĝi ne kaŭzos teknikajn malfacilaĵojn.
Yandex ankaŭ subtenas la disvolviĝon de filtra sistemo bazita sur la nova objekto RPKI - (Autonomous System Provider Authorization). Filtriloj bazitaj sur ASPA kaj ROA-objektoj povas ne nur anstataŭigi "likaj" AS-SET-ojn, sed ankaŭ fermi la aferojn de MiTM-atakoj uzante BGP.
Mi detale parolos pri ASPA post monato ĉe la Konferenco de Next Hop. Tie parolos ankaŭ kolegoj de Netflix, Facebook, Dropbox, Juniper, Mellanox kaj Yandex. Se vi interesiĝas pri la reto-stako kaj ĝia evoluo estontece, venu .
fonto: www.habr.com