13 сакавіка ў рабочую групу RIPE па барацьбе са злоўжываннямі разглядаць BGP-перахоп (hjjack) у якасці парушэння палітыкі RIPE. У выпадку прыняцця прапановы інтэрнэт-правайдэр, атакаваны з дапамогай перахопу трафіку, атрымліваў бы магчымасць адправіць спецыяльны запыт для вываду зламысніка на чыстую ваду. Калі экспертная група збярэ дастаткова доказаў, то такі LIR, які з'яўляецца крыніцай BGP-перахопу, лічыўся б парушальнікам і мог быць пазбаўлены статусу LIR. Былі і некаторыя аргументы змены.
У дадзенай публікацыі мы жадаем паказаць прыклад нападу, калі не толькі сапраўдны зламыснік быў пад пытаннем, але і ўвесь спіс пацярпелых прэфіксаў. Больш за тое, такі напад ізноў паднімае пытанні з нагоды матываў будучых перахопаў трафіку такога тыпу.
Апошнія некалькі гадоў у прэсе ў якасці BGP-перахопаў асвятляліся толькі канфлікты тыпу MOAS (Multiple Origin Autonomous System). MOAS – гэта прыватны выпадак, калі дзве розныя аўтаномныя сістэмы анансуюць канфліктуючыя прэфіксы з адпаведнымі нумарамі ASN у AS_PATH (першы ASN у AS_PATH, далей па тэксце – origin ASN). Аднак мы можам назваць як мінімум перахопу трафіку, якія дазваляюць зламысніку маніпуляваць атрыбутам AS_PATH з рознымі мэтамі, у тым ліку і дзеля абыходу сучасных падыходаў да фільтрацыі і маніторынгу. Вядомы тып нападу - Апошні тып такога перахопу, але зусім не па значнасці. Цалкам магчыма, што менавіта такі напад мы і назіралі на працягу апошніх тыдняў. Такая падзея мае вытлумачальны характар і дастаткова сур'ёзныя наступствы.
Тыя, хто шукае TL;DR версію, могуць пракруціць да падзагалоўка "Ідэальная атака".
Сеткавы бэкграўнд
(каб вы лепш разумелі працэсы, задзейнічаныя ў дадзеным інцыдэнце)
Калі вы жадаеце адправіць пакет і ў вас ёсць некалькі прэфіксаў у табліцы маршрутызацыі, якія змяшчаюць IP-адрас прызначэння, то вы будзеце выкарыстоўваць маршрут для прэфікса з максімальнай даўжынёй. Калі ж у табліцы маршрутызацыі існуе некалькі розных маршрутаў для аднаго прэфікса, вы вылучыце лепшы (у адпаведнасці з механізмам выбару лепшага шляху).
Існуючыя падыходы да фільтрацыі і маніторынгу спрабуюць аналізаваць маршруты і прымаць рашэнні, аналізуючы атрыбут AS_PATH. Маршрутызатар можа змяніць гэты атрыбут на любое значэнне падчас анансавання. Простага дадання ASN уладальніка ў пачатку AS_PATH (як origin ASN) можа быць дастаткова для абыходу бягучых механізмаў праверкі крыніцы. Больш за тое, калі існуе маршрут ад атакаванага ASN да вас, з'яўляецца магчымасць выняць і выкарыстоўваць AS_PATH гэтага маршруту ў іншых вашых анонсах. Любая праверка дакладнасці толькі AS_PATH для вашых скрафчаных анонсаў у выніку будзе пройдзеная.
Яшчэ існуе некалькі вартых згадкі абмежаванняў. Па-першае, у выпадку фільтрацыі прэфіксаў вышэйстаячым правайдэрам ваш маршрут усё роўна можа быць адфільтраваны (нават з карэктным AS_PATH), калі прэфікс не прыналежыць вашаму кліенцкаму конусу, наладжанаму ў апстрыму. Другое - валідны AS_PATH можа стаць невалідным, калі створаны маршрут анансаваны ў некарэктных напрамках і, такім чынам, парушае палітыку маршрутызацыі. І апошняе - любы маршрут з прэфіксам, парушаючым ROA length, можа лічыцца несапраўдным.
інцыдэнт
Некалькі тыдняў таму мы атрымалі скаргу ад аднаго карыстальніка. Мы бачылі маршруты з яго origin ASN і прэфіксамі /25, у той час як карыстач сцвярджаў, што іх не анансаваў.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
Прыклады анонсаў на пачатак красавіка 2019 г.
NTT у шляхі для прэфікса /25 робіць яго асабліва падазроным. Падчас інцыдэнту LG NTT нічога не ведаў аб гэтым маршруце. Так што так, які аператар стварае цэлы AS_PATH для гэтых прэфіксаў! Праверка на іншых маршрутызатарах дазваляе вылучыць адзін адмысловы ASN: AS263444. Паглядзеўшы на іншыя маршруты з гэтай аўтаномнай сістэмай, мы сутыкнуліся з наступнай сітуацыяй:
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
Паспрабуйце здагадацца, што тут ня так
Здаецца, што нехта ўзяў прэфікс з маршруту, падзяліў яго на дзве часткі і анансаваў маршрут з тым жа самым AS_PATH для гэтых двух прэфіксаў.
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
Прыклады маршрутаў для адной з пар падзеленых прэфіксаў
Узнікае адразу некалькі пытанняў. Ці сапраўды нехта спрабаваў на практыцы такі тып перахопу? Хто-небудзь прымаў гэтыя маршруты? Якія прэфіксы былі закрануты?
Тут і пачынаецца наша чарада няўдач і яшчэ адзін раунд расчаравання ў бягучым стане здароўя Інтэрнэту.
Шлях няўдач
Аб усім па парадку. Як мы можам вызначыць, якія маршрутызатары прынялі такія перахопленыя маршруты і чый трафік можа быць перанакіраваны ўжо сёньня? Мы падумалі пачаць з прэфіксаў /25, таму што яны "проста не могуць мець глабальнага распаўсюджвання". Як вы можаце здагадацца - мы моцна памыляліся. Гэтая метрыка апынулася занадта зашумлена і маршруты з такімі прэфіксамі могуць з'яўляцца нават ад Tier-1 аператараў. Напрыклад, у NTT ёсць каля 50 такіх прэфіксаў, якія ён распаўсюджвае сярод сваіх кліентаў. З іншага боку, дадзеная метрыка дрэнная, таму што такія прэфіксы могуць быць адфільтраваны ў тым выпадку, калі аператар ужывае , ва ўсіх напрамках. Таму такі метад не падыходзіць для пошуку ўсіх аператараў, чый трафік быў перанакіраваны ў выніку падобнага інцыдэнту.
Яшчэ адной добрай ідэяй нам падалося паглядзець на . У асаблівасці на маршруты з парушэннем правіла maxLength адпаведнага ROA. Такім чынам, мы маглі б знайсці колькасць розных origin ASN са статусам Invalid, якія былі бачныя дадзенай AS. Тым не менш, ёсць "невялікая" праблема. Сярэдняе значэнне (медыяна і мода) гэтага ліку (колькасці розных origin ASN) складае каля 150 і, нават калі мы адфільтруем малыя прэфіксы, яно застанецца вышэй за 70. Такое становішча спраў мае цалкам простае тлумачэнне: ёсць толькі некалькі аператараў, якія ўжо ўжываюць ROA- фільтры з палітыкай "скідаць Invalid маршруты" на ўваходных кропках, таму, дзе б у рэальным свеце ні з'явіўся маршрут з парушэннем ROA, ён можа распаўсюджвацца ва ўсіх кірунках.
Апошнія два падыходы дазваляюць знайдзі аператараў, якія ўбачылі наш інцыдэнт (бо ён быў дастаткова вялікім), але ў цэлым яны непрымяняльныя. Добра, але ці можам мы знайсці зламысніка? Якія агульныя асаблівасці такой маніпуляцыі AS_PATH? Ёсць некалькі базавых здагадак:
- Прэфікс нідзе раней заўважаны не быў;
- Origin ASN (напамін: першы ASN у AS_PATH) з'яўляецца валідным;
- Апошні ASN у AS_PATH - гэта ASN атакавалага (у выпадку, калі яго сусед правярае ASN суседа на ўсіх уваходных маршрутах);
- Атака зыходзіць ад аднаго правайдэра.
Калі ўсе здагадкі дакладныя, то на ўсіх некарэктных маршрутах будзе прадстаўлены ASN зламысніка (акрамя origin ASN) і, такім чынам, гэта з'яўляецца "крытычнай" кропкай. Сярод сапраўдных згоншчыкаў аказаўся і AS263444, хоць былі і іншыя. Нават калі мы адкінулі маршрут інцыдэнту з разгляду. Чаму? Крытычная кропка можа заставацца крытычнай нават для карэктных маршрутаў. Яна можа з'яўляцца або вынікам дрэннай складнасці ў якім-небудзь рэгіёне, або абмежаванняў нашай уласнай бачнасці.
Як вынік: ёсць спосаб выявіць зламысніка, але толькі ў выпадку адпаведнасці ўсім пералічаным вышэй умовам і толькі калі перахоп дастаткова вялікі для праходжання парогаў маніторынгу. Калі ж нейкія з гэтых фактараў не выконваюцца, то ці можам мы вылучыць прэфіксы, якія пацярпелі ад падобнага перахопу? Для пэўных аператараў – так.
Калі атакавалы стварае more specific маршрут, такі прэфікс не анансуецца сапраўдным уладальнікам. У выпадку, калі ў вас ёсць ад яго дынамічны спіс усіх яго прэфіксаў, то з'яўляецца магчымасць правесці параўнанне і знайсці скажоныя more specific маршруты. Мы збіраем гэты спіс прэфіксаў пры дапамозе нашых BGP-сесій, бо нам перадаюць не толькі поўны спіс маршрутаў, бачных аператарам зараз, але і спіс усіх прэфіксаў, якія ён хоча анансаваць у свет. Нажаль, цяпер існуе некалькі дзясяткаў карыстачоў Radar, якія апошнюю частку выконваюць не да канца карэктна. У бліжэйшы час мы апавясцім іх і пастараемся вырашыць гэтую праблему. Усе астатнія ж могуць далучыцца да нашай сістэмы маніторынгу зараз.
Калі вярнуцца да першапачатковага інцыдэнту, то і зламыснік, і вобласць распаўсюджвання былі выяўленыя намі пры дапамозе пошуку крытычных кропак. Дзіўна, але AS263444 рассылаў сфабрыкаваныя маршруты не ўсім сваім кліентам. Хаця ёсць і больш дзіўны момант.
BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
Нядаўні прыклад спробы перахопу нашай адраснай прасторы
Калі былі створаны more specific'і для нашых прэфіксаў, то выкарыстоўваўся спецыяльна створаны AS_PATH. Аднак гэты AS_PATH не мог быць узяты ні з аднаго з нашых папярэдніх маршрутаў. У нас нават няма сувязі з AS6762. Глядзім на іншыя маршруты ў інцыдэнце: у некаторых з іх быў сапраўдны AS_PATH, які выкарыстоўваўся раней, а ў іншых - не, нават калі ён і выглядаюць як сапраўдны. Дадатковая змена AS_PATH не мае ніякага практычнага сэнсу, бо ў любым выпадку трафік будзе перанакіраваны зламысніку, але маршруты з "дрэнным" AS_PATH могуць быць адфільтраваны ASPA або любым іншым механізмам праверкі. Тут мы задумаліся аб матывацыі згоншчыка. Цяпер нам не хапае дадзеных для таго, каб сцвярджаць, што дадзены інцыдэнт быў спланаваным нападам. Тым не менш - гэта магчыма. Давайце паспрабуем уявіць хоць пакуль і гіпатэтычную, але патэнцыйна цалкам рэальную сітуацыю.
Ідэальная атака
Што мы маем? Выкажам здагадку, вы з'яўляецеся транзітным правайдэрам, якія транслююць маршруты для сваіх кліентаў. Калі вашы кліенты маюць множную прысутнасць (multihome), то вы атрымаеце толькі частку іх трафіку. Але чым больш трафіку - тым больш ваш даход. Таму, калі вы пачняце анансаваць прэфіксы падсетак гэтых жа маршрутаў з тым жа AS_PATH, вы атрымаеце астатнюю частку іх трафіку. Як следства, астатнюю частку грошай.
Ці дапаможа тут ROA? Магчыма, так, калі вы вырашыце цалкам адмовіцца ад выкарыстання . Акрамя таго, пры гэтым вельмі не пажадана мець запісы ROA з перасякальнымі прэфіксамі. Для некаторых аператараў такія абмежаванні непрымальныя.
Разглядаючы іншыя механізмы забеспячэння бяспекі маршрутызацыі, у дадзеным выпадку ASPA таксама не дапаможа (таму што выкарыстоўваецца AS_PATH ад дапушчальнага маршруту). BGPSec па-ранейшаму не аптымальны варыянт з-за нізкага працэнта прыняцця і магчымасці, якая застаецца downgrade-нападаў.
Такім чынам, у нас ёсць відавочны прыбытак для атакавалага і недахоп бяспекі. Выдатная сумесь!
Што трэба рабіць?
Відавочны і найбольш радыкальны крок - перагляд вашай бягучай палітыкі маршрутызацыі. Разбіце вашу адрасную прастору на самыя маленькія кавалкі (без скрыжаванняў), якія вы толькі захочаце праанансаваць. Падпішыце ROA толькі для іх, не выкарыстоўваючы параметр maxLength. У гэтым выпадку бягучы POV можа вас выратаваць ад падобнага нападу. Аднак, зноў жа, для некаторых аператараў такі падыход не зразумелы з-за выключнага выкарыстання more specific маршрутаў. Усе праблемы бягучага стану ROA і route аб'ектаў будуць апісаны ў адным з нашых будучых матэрыялаў.
Акрамя гэтага, можна спрабаваць маніторыць такія перахопы. Для гэтага нам патрэбна дакладная інфармацыя аб вашых прэфіксах. Такім чынам, калі вы ўсталюеце BGP-сесію з нашым калектарам і перадасце нам інфармацыю аб вашай бачнасці Інтэрнэту - мы можам знайсці вобласць распаўсюджвання і для іншых інцыдэнтаў. Для тых, хто яшчэ не падключаны да нашай сістэмы маніторынгу - для пачатку нам будзе дастаткова спісу маршрутаў толькі з вашымі прэфіксамі. Калі ж у вас устаноўлена сесія з намі, то, калі ласка, праверце, што былі адпраўлены ўсе вашыя маршруты. Нажаль, аб гэтым варта нагадаць, бо частка аператараў забываюць адзін ці два прэфікса і, такім чынам, ствараюць перашкоды для нашых метадаў пошуку. Калі ўсё зрабіць правільна, то ў нас будуць надзейныя дадзеныя аб вашых прэфіксах, якія ў будучыні дапамогуць аўтаматычна вызначаць і дэтэктаваць такі (і іншыя) тыпы перахопу трафіку для вашай адраснай прасторы.
Калі вы ў рэжыме рэальнага часу даведаліся аб такім перахопе вашага трафіку, вы можаце паспрабаваць супрацьдзейнічаць самастойна. Першы падыход - анансаваць маршруты з гэтымі more specific прэфіксамі самастойна. У выпадку новага нападу на гэтыя прэфіксы - паўтарыць.
Другі падыход - пакараць зламысніка і тых, для каго ён з'яўляецца крытычнай кропкай (для добрых маршрутаў), адрэзаўшы доступ вашых маршрутаў да зламысніку. Гэта можна зрабіць, дадаўшы ASN зламысніка ў AS_PATH вашых старых маршрутаў і, такім чынам, прымусіць іх пазбягаць гэтую AS, выкарыстоўваючы ўбудаваны механізм выяўлення цыклаў у BGP .
Крыніца: habr.com