Прывітанне, мяне клічуць Аляксандр Азімаў. У Яндэксе я займаюся распрацоўкай розных сістэм маніторынгу, а таксама транспартнай сеткавай архітэктурай. Але сёння размова пойдзе аб пратаколе BGP.
Тыдзень таму Яндэкс уключыў ROV (Route Origin Validation) на стыках з усімі пірынг-партнёрамі, а таксама з кропкамі абмену трафіку. Аб тым, навошта гэта было зроблена і як гэта паўплывае на ўзаемадзеянне з аператарамі сувязі, чытайце ніжэй.
BGP і што з ім не так
Вы напэўна ведаеце, што BGP задумваўся як пратакол міждаменнай маршрутызацыі. Аднак за час шляху лік юз-кейсаў паспела падрасці: сёння BGP, дзякуючы шматлікім пашырэнням, ператварыўся ў message bus, які пакрывае задачы ад аператарскага VPN да моднага сягоння SD-WAN, і нават знайшоў ужыванне ў якасці транспарта для SDN-like-кантролера, які ператварае distance vector BGP у нешта падобнае на links sate-пратакол.
Мал. 1.
Чаму BGP атрымаў (і працягвае атрымліваць) столькі ўжыванняў? Ёсць дзве асноўныя прычыны:
- BGP - адзіны пратакол, які працуе паміж аўтаномнымі сістэмамі (АС);
- BGP падтрымлівае атрыбуты ў фармаце TLV (type-length-value). Так, у гэтым пратакол не самотны, але бо яго няма чым замяніць на стыках паміж аператарамі сувязі, тое заўсёды апыняецца выгодней прымайстраваць да яго яшчэ адзін функцыянальны элемент, чым падтрымліваць дадатковы пратакол маршрутызацыі.
Што ж з ім не так? Калі сцісла, у пратаколе адсутнічаюць убудаваныя механізмы праверкі карэктнасці атрымоўванай інфармацыі. Гэта значыць BGP - гэта пратакол апрыёрнага даверу: хочаце паведаміць свету, што зараз вам належыць сетка Растэлекама, МТС або Яндэкса, - калі ласка!
Фільтр на аснове IRRDB - лепшы з горшых
Узнікае пытанне - чаму ў такой сітуацыі інтэрнэт да гэтага часу працуе? Так, працуе большую частку часу, але пры гэтым перыядычна выбухаючы, робячы цэлыя нацыянальныя сегменты недаступнымі. Нягледзячы на тое, што хакерская актыўнасць у BGP таксама расце, большая частка анамалій па-ранейшаму ўзнікаюць дзякуючы памылкам. Прыклад гэтага года - у Беларусі, які на паўгадзіны зрабіў недаступнымі значную частку Інтэрнэту для карыстальнікаў Мегафона. Іншы прыклад - зламаў адну з найбуйнейшых CDN-сетак у свеце.
Мал. 2. Перахоп трафіку Cloudflare
Але ўсё ж такі чаму такія анамаліі ўзнікаюць раз на паўгода, а не кожны дзень? Таму што аператары сувязі выкарыстоўваюць вонкавыя базы дадзеных маршрутнай інфармацыі для праверкі таго, што атрымліваюць ад BGP суседзяў. Такіх баз дадзеных шмат, частка з іх кіруюцца рэгістратарамі (RIPE, APNIC, ARIN, AFRINIC), частка з'яўляюцца незалежнымі гульцамі (самы вядомы - RADB), а таксама ёсць цэлы набор рэгістратараў, якія належаць буйным кампаніям (Level3, NTT і інш.). Менавіта дзякуючы гэтым базам дадзеных міждаменная маршрутызацыя захоўвае адносную стабільнасць сваёй працы.
Аднак ёсць нюансы. Праверка маршрутнай інфармацыі ажыццяўляецца на аснове аб'ектаў ROUTE-OBJECTS і AS-SET. І калі першыя маюць на ўвазе аўтарызацыю ў часткі IRRDB, то для другога класа аўтарызацыя адсутнічае як клас. Гэта значыць хто заўгодна можна дадаць у свае сэты каго заўгодна і тым самым абыйсці фільтры вышэйстаячых пастаўшчыкоў. І больш за тое, унікальнасць наймення AS-SET паміж рознымі базамі IRR не гарантуецца, што можа прыводзіць да дзіўных эфектаў з раптоўным знікненнем складнасці ў аператара сувязі, які са свайго боку нічога не мяняў.
Дадатковая праблема - гэта мадэль выкарыстання AS-SET. Тут два моманты:
- Калі ў аператара з'яўляецца новы кліент, ён дадае яго ў свой AS-SET, але практычна ніколі яго не выдаляе;
- Самі фільтры наладжваюцца толькі на стыках з кліентамі.
У выніку сучасны фармат BGP-фільтраў - гэта паступова якія дэградуюць фільтры на стыках з кліентамі і апрыёрны давер таму, што прыходзіць ад пірынг-партнёраў і пастаўшчыкоў IP-транзіту.
Што ж ідзе на змену прэфікс-фільтрам на аснове AS-SET? Самае цікавае, што ў кароткатэрміновай перспектыве - нічога. Але з'яўляюцца дадатковыя механізмы, якія дапаўняюць працу фільтраў на аснове IRRDB, і ў першую чаргу гэта, вядома, RPKI.
RPKI
Спрошчана можна ўявіць архітэктуру RPKI як размеркаваную базу дадзеных, запісы якой можна крыптаграфічна праверыць. У выпадку ROA (Route Object Authorization) падпісантам выступае ўладальнік адраснай прасторы, а сам запіс уяўляе сабой тройку (prefix, asn, max_length). Па сутнасці, гэты запіс пастулюе наступнае - уладальнік адраснай прасторы $prefix дазволіў АС з нумарам $asn анансаваць прэфіксы з даўжынёй не больш чым $max_length. І маршрутызатары, выкарыстоўваючы RPKI-кэш, здольныя правяраць на адпаведнасць пары прэфікс-першая АС у шляху.
Рыс 3. Архітэктура RPKI
ROA-аб'екты былі стандартызаваны ўжо дастаткова даўно, але да апошняга часу фактычна заставаліся толькі на паперы IETF-часопіса. На мой погляд, прычына гэтага гучыць страшна - bad marketing. Пасля завяршэння стандартызацыі ў якасці стымулу сцвярджалася, што ROA абараняюць ад угонаў BGP – і гэта было няпраўдай. Зламыснікі могуць лёгка абыйсці фільтры на аснове ROA, уставіўшы карэктны нумар АС у пачатку шляху. І як толькі гэтае ўсведамленне прыходзіла, наступным заканамерным крокам станавіўся адмова ад выкарыстання ROA. І праўда, навошта нам тэхналогія, калі яна не працуе?
Чаму ж час змяніць сваё меркаванне? Бо гэта не ўся праўда. ROA не абараняе ад хакерскай актыўнасці ў BGP, але абараняе ад выпадковых згонаў трафіку, Напрыклад ад уцечак статыкі ў BGP, якая сустракаецца ўсё часцей. Таксама, у адрозненне ад фільтраў на аснове IRR, ROV можа прымяняцца не толькі на стыках з кліентамі, але і на стыках з банкетамі і вышэйстаячымі пастаўшчыкамі. Гэта значыць разам з укараненнем RPKI з BGP паступова сыходзіць апрыёрны давер.
Цяпер праверка маршрутаў на аснове ROA паступова ўкараняецца ключавымі гульцамі: найбуйнае еўрапейскія IX ужо адкідаюць некарэктныя маршруты, з Tier-1-аператараў варта вылучыць AT&T, які ўлучыў фільтры на стыках са сваімі пірынг-партнёрамі. Таксама да снарада падыходзяць і найбуйныя пастаўшчыкі кантэнту. А дзясяткі транзітных аператараў сярэдняга памеру ўжо яго ціха ўкаранілі, нікому пра гэта не сказаўшы. Навошта ўсе гэтыя аператары ўкараняюць RPKI? Адказ просты: каб абараніць свой выходны трафік ад чужых памылак. Менавіта таму Яндэкс адным з першых у РФ уключае ROV на мяжы сваёй сеткі.
Што будзе далей?
Цяпер мы ўключылі праверку маршрутнай інфармацыі на стыках з кропкамі абмену трафіку і прыватнымі пірынгамі. У найбліжэйшай будучыні праверка будзе таксама ўключана з вышэйстаячымі пастаўшчыкамі трафіку.
Што гэта мяняе для вас? Калі вы хочаце павысіць абароненасць маршрутызацыі трафіку паміж вашай сеткай і Яндэксам, мы рэкамендуем:
- Падпісаць сваю адрасную прастору - Гэта проста, у сярэднім займае 5-10 хвілін. Гэта абароніць нашу з вамі складнасць у выпадку, калі хтосьці мімаволі здзейсніць згон вашай адраснай прасторы (а гэта абавязкова здарыцца рана ці позна);
- Паставіць адзін з open source RPKI-кэшаў (, ) і ўключыць праверку маршрутаў на мяжы сеткі - гэта запатрабуе больш часу, але таксама тэхнічных складанасцяў, зноў-такі, не выкліча.
Яндэкс таксама падтрымлівае распрацоўку сістэмы фільтрацыі на аснове новага RPKI-аб'екта. (Autonomous System Provider Authorization). Фільтры на аснове аб'ектаў ASPA і ROA здольныя не толькі замяніць "дзіравыя" AS-SET, але і закрыць пытанні MiTM-нападаў з выкарыстаннем BGP.
Я буду падрабязна расказваць пра ASPA праз месяц на канферэнцыі Next Hop. Яшчэ тамака будуць выступаць калегі з Netflix, Facebook, Dropbox, Juniper, Mellanox і Яндэкса. Калі вам цікавы сеткавы стэк і яго развіццё ў будучыні - прыходзьце, .
Крыніца: habr.com