Kumusta, ang pangalan ko ay Alexander Azimov. Sa Yandex, bumuo ako ng iba't ibang mga sistema ng pagsubaybay, pati na rin ang arkitektura ng network ng transportasyon. Ngunit ngayon ay pag-uusapan natin ang tungkol sa BGP protocol.
Isang linggo ang nakalipas, pinagana ng Yandex ang ROV (Route Origin Validation) sa mga interface kasama ang lahat ng peering partner, gayundin ang mga traffic exchange point. Basahin sa ibaba ang tungkol sa kung bakit ito ginawa at kung paano ito makakaapekto sa pakikipag-ugnayan sa mga operator ng telecom.
BGP at kung ano ang mali dito
Malamang alam mo na ang BGP ay idinisenyo bilang isang interdomain routing protocol. Gayunpaman, sa kahabaan ng paraan, ang bilang ng mga kaso ng paggamit ay pinamamahalaang lumaki: ngayon, ang BGP, salamat sa maraming mga extension, ay naging isang bus ng mensahe, na sumasaklaw sa mga gawain mula sa operator VPN hanggang sa ngayon ay naka-istilong SD-WAN, at nakahanap pa nga ng aplikasyon bilang isang transport para sa isang SDN-like controller, ginagawang distance vector BGP sa isang bagay na katulad ng mga link sat protocol.
Fig. 1.
Bakit nakatanggap ang BGP (at patuloy na tumatanggap) ng napakaraming gamit? Mayroong dalawang pangunahing dahilan:
- Ang BGP ay ang tanging protocol na gumagana sa pagitan ng mga autonomous system (AS);
- Sinusuportahan ng BGP ang mga katangian sa format na TLV (type-length-value). Oo, ang protocol ay hindi nag-iisa dito, ngunit dahil walang mapapalitan ito sa mga junction sa pagitan ng mga operator ng telecom, palaging lumalabas na mas kumikita ang pag-attach ng isa pang functional na elemento dito kaysa sa pagsuporta sa isang karagdagang routing protocol.
Anong meron sa kanya? Sa madaling salita, ang protocol ay walang built-in na mekanismo para sa pagsuri sa kawastuhan ng impormasyong natanggap. Ibig sabihin, ang BGP ay isang priori trust protocol: kung gusto mong sabihin sa mundo na pagmamay-ari mo na ngayon ang network ng Rostelecom, MTS o Yandex, mangyaring!
IRRDB based na filter - ang pinakamahusay sa pinakamasama
Ang tanong ay lumitaw: bakit gumagana pa rin ang Internet sa ganoong sitwasyon? Oo, ito ay gumagana sa halos lahat ng oras, ngunit sa parehong oras ito ay pana-panahong sumasabog, na ginagawang hindi naa-access ang buong pambansang mga segment. Bagama't tumataas din ang aktibidad ng hacker sa BGP, karamihan sa mga anomalya ay sanhi pa rin ng mga bug. Ang halimbawa sa taong ito ay sa Belarus, na gumawa ng isang makabuluhang bahagi ng Internet na hindi naa-access ng mga gumagamit ng MegaFon sa loob ng kalahating oras. Isa pang halimbawa - sinira ang isa sa pinakamalaking CDN network sa mundo.
kanin. 2. Cloudflare traffic interception
Ngunit gayon pa man, bakit nangyayari ang gayong mga anomalya isang beses bawat anim na buwan, at hindi araw-araw? Dahil gumagamit ang mga carrier ng mga panlabas na database ng impormasyon sa pagruruta upang i-verify kung ano ang natatanggap nila mula sa mga kapitbahay ng BGP. Mayroong maraming mga naturang database, ang ilan sa mga ito ay pinamamahalaan ng mga registrar (RIPE, APNIC, ARIN, AFRINIC), ang ilan ay mga independiyenteng manlalaro (ang pinakasikat ay RADB), at mayroon ding isang buong hanay ng mga registrar na pag-aari ng malalaking kumpanya (Level3 , NTT, atbp.). Salamat sa mga database na ito na pinapanatili ng inter-domain routing ang relatibong katatagan ng operasyon nito.
Gayunpaman, may mga nuances. Sinusuri ang impormasyon sa pagruruta batay sa ROUTE-OBJECTS at AS-SET na mga bagay. At kung ang una ay nagpapahiwatig ng awtorisasyon para sa bahagi ng IRRDB, kung gayon para sa pangalawang klase ay walang awtorisasyon bilang isang klase. Iyon ay, kahit sino ay maaaring magdagdag ng sinuman sa kanilang mga hanay at sa gayon ay i-bypass ang mga filter ng upstream provider. Bukod dito, ang pagiging natatangi ng AS-SET na pagpapangalan sa pagitan ng iba't ibang mga base ng IRR ay hindi ginagarantiyahan, na maaaring humantong sa mga nakakagulat na epekto na may biglaang pagkawala ng koneksyon para sa operator ng telecom, na, sa kanyang bahagi, ay hindi nagbago ng anuman.
Ang isang karagdagang hamon ay ang pattern ng paggamit ng AS-SET. Mayroong dalawang puntos dito:
- Kapag nakakuha ng bagong kliyente ang operator, idinaragdag nito ito sa AS-SET nito, ngunit halos hindi ito inaalis;
- Ang mga filter mismo ay na-configure lamang sa mga interface sa mga kliyente.
Bilang resulta, ang modernong format ng mga filter ng BGP ay binubuo ng unti-unting nagpapababa ng mga filter sa mga interface sa mga kliyente at isang priori na pagtitiwala sa kung ano ang nagmumula sa mga kasosyo sa peering at mga provider ng IP transit.
Ano ang pagpapalit ng mga filter ng prefix batay sa AS-SET? Ang pinaka-kagiliw-giliw na bagay ay na sa maikling termino - wala. Ngunit ang mga karagdagang mekanismo ay umuusbong na umakma sa gawain ng mga filter na nakabatay sa IRRDB, at una sa lahat, ito ay, siyempre, RPKI.
RPKI
Sa isang pinasimpleng paraan, ang arkitektura ng RPKI ay maaaring isipin bilang isang distributed database na ang mga tala ay maaaring ma-verify sa cryptographically. Sa kaso ng ROA (Route Object Authorization), ang lumagda ay ang may-ari ng address space, at ang record mismo ay isang triple (prefix, asn, max_length). Sa esensya, ang entry na ito ay nagpopostulate ng sumusunod: pinahintulutan ng may-ari ng $prefix address space ang AS number na $asn na mag-advertise ng mga prefix na may haba na hindi hihigit sa $max_length. At ang mga router, gamit ang RPKI cache, ay nagagawang suriin ang pares para sa pagsunod prefix - unang tagapagsalita sa daan.
Larawan 3. Arkitektura ng RPKI
Ang mga bagay sa ROA ay na-standardize sa loob ng mahabang panahon, ngunit hanggang kamakailan lamang ay nanatili lamang sila sa papel sa IETF journal. Sa aking opinyon, ang dahilan para dito ay nakakatakot - masamang marketing. Pagkatapos makumpleto ang standardisasyon, ang insentibo ay ang ROA ay nagpoprotekta laban sa BGP hijacking - na hindi totoo. Madaling ma-bypass ng mga attacker ang mga filter na nakabatay sa ROA sa pamamagitan ng paglalagay ng tamang AC number sa simula ng path. At sa sandaling dumating ang pagsasakatuparan na ito, ang susunod na lohikal na hakbang ay ang pag-abandona sa paggamit ng ROA. Sa katunayan, bakit kailangan natin ng teknolohiya kung hindi ito gumagana?
Bakit oras na para magbago ang isip mo? Dahil hindi ito ang buong katotohanan. Ang ROA ay hindi nagpoprotekta laban sa aktibidad ng hacker sa BGP, ngunit pinoprotektahan laban sa aksidenteng pag-hijack ng trapiko, halimbawa mula sa mga static na pagtagas sa BGP, na nagiging mas karaniwan. Gayundin, hindi tulad ng mga filter na nakabatay sa IRR, maaaring gamitin ang ROV hindi lamang sa mga interface sa mga kliyente, kundi pati na rin sa mga interface sa mga kapantay at upstream na provider. Ibig sabihin, kasabay ng pagpapakilala ng RPKI, ang isang priori trust ay unti-unting nawawala sa BGP.
Ngayon, ang pagsusuri sa mga ruta batay sa ROA ay unti-unting ipinapatupad ng mga pangunahing manlalaro: ang pinakamalaking European IX ay nagtatapon na ng mga maling ruta sa mga Tier-1 na mga operator, ito ay nagkakahalaga ng pag-highlight sa AT&T, na pinagana ang mga filter sa mga interface kasama ang mga kasosyo nito. Ang pinakamalaking provider ng nilalaman ay lumalapit din sa proyekto. At tahimik na ipinatupad ito ng dose-dosenang mga medium-sized na operator ng transit, nang hindi sinasabi sa sinuman ang tungkol dito. Bakit lahat ng mga operator na ito ay nagpapatupad ng RPKI? Ang sagot ay simple: upang protektahan ang iyong papalabas na trapiko mula sa mga pagkakamali ng ibang tao. Iyon ang dahilan kung bakit ang Yandex ay isa sa mga una sa Russian Federation na isama ang ROV sa gilid ng network nito.
Anong sunod na mangyayari?
Pinagana na namin ngayon ang pagsuri sa impormasyon sa pagruruta sa mga interface na may mga traffic exchange point at pribadong peering. Sa malapit na hinaharap, ie-enable din ang pag-verify sa mga upstream na traffic provider.
Ano ang pagkakaiba nito para sa iyo? Kung gusto mong pataasin ang seguridad ng pagruruta ng trapiko sa pagitan ng iyong network at Yandex, inirerekomenda namin ang:
- Lagdaan ang iyong address space - ito ay simple, tumatagal ng 5-10 minuto sa karaniwan. Poprotektahan nito ang aming pagkakakonekta kung sakaling may magnakaw ng iyong address space nang hindi sinasadya (at tiyak na mangyayari ito maaga o huli);
- I-install ang isa sa mga open source na cache ng RPKI (, ) at paganahin ang pagsuri ng ruta sa hangganan ng network - ito ay magtatagal ng mas maraming oras, ngunit muli, hindi ito magdudulot ng anumang mga teknikal na problema.
Sinusuportahan din ng Yandex ang pagbuo ng isang sistema ng pag-filter batay sa bagong bagay na RPKI - (Autonomous System Provider Authorization). Ang mga filter na nakabatay sa mga bagay na ASPA at ROA ay hindi lamang maaaring palitan ang mga "leaky" na AS-SET, ngunit isara din ang mga isyu ng mga pag-atake ng MiTM gamit ang BGP.
Magsasalita ako nang detalyado tungkol sa ASPA sa isang buwan sa Next Hop conference. Magsasalita din doon ang mga kasamahan mula sa Netflix, Facebook, Dropbox, Juniper, Mellanox at Yandex. Kung interesado ka sa network stack at sa pag-unlad nito sa hinaharap, halika .
Pinagmulan: www.habr.com