Ամեն ինչ շատ վատ է կամ նոր տեսակի երթևեկության խափանում

մարտի 13-ը՝ RIPE-ի չարաշահումների դեմ պայքարի աշխատանքային խմբին առաջարկ է ստացվել համարել BGP առևանգումը (hjjack) որպես RIPE քաղաքականության խախտում: Եթե ​​առաջարկն ընդունվեր, թրաֆիկի գաղտնալսման միջոցով հարձակման ենթարկված ինտերնետ մատակարարը հնարավորություն կունենար հատուկ հարցում ուղարկել հարձակվողին բացահայտելու համար: Եթե ​​վերանայման թիմը հավաքեր բավարար հիմնավոր ապացույցներ, LIR-ը, որը BGP-ի խափանման աղբյուրն էր, կհամարվեր ներխուժող և կարող էր զրկվել իր LIR կարգավիճակից: Եղան նաև որոշ փաստարկներ սրա դեմ փոփոխությունները։

Այս հրապարակման մեջ մենք ցանկանում ենք ցույց տալ հարձակման օրինակ, որտեղ ոչ միայն իրական հարձակվողի մասին էր խոսքը, այլ նաև ազդակիր նախածանցների ամբողջ ցանկը: Ավելին, նման հարձակումը կրկին հարցեր է առաջացնում այս տեսակի երթևեկության հետագա գաղտնալսման դրդապատճառների վերաբերյալ:

Վերջին մի քանի տարիների ընթացքում մամուլում լուսաբանվել են միայն այնպիսի կոնֆլիկտներ, ինչպիսիք են MOAS-ը (Բազմակի ծագման ինքնավար համակարգ): MOAS-ը հատուկ դեպք է, երբ երկու տարբեր ինքնավար համակարգեր գովազդում են հակասական նախածանցներ AS_PATH-ում համապատասխան ASN-ների հետ (առաջին ASN-ը AS_PATH-ում, այսուհետ՝ սկզբնաղբյուր ASN): Այնուամենայնիվ, մենք կարող ենք առնվազն անվանել 3 լրացուցիչ տեսակ երթևեկության խափանում, որը հարձակվողին թույլ է տալիս շահարկել AS_PATH հատկանիշը տարբեր նպատակներով, ներառյալ շրջանցելով ֆիլտրման և մոնիտորինգի ժամանակակից մոտեցումները: Հայտնի հարձակման տեսակ Փիլոսովա-Կապելի - նման գաղտնալսման վերջին տեսակը, բայց բոլորովին ոչ կարևոր: Միանգամայն հնարավոր է, որ սա հենց այն հարձակումն է, որը մենք տեսել ենք վերջին շաբաթների ընթացքում: Նման իրադարձությունն ունի հասկանալի բնույթ և բավականին լուրջ հետևանքներ։

Նրանք, ովքեր փնտրում են TL;DR տարբերակը, կարող են ոլորել դեպի «Perfect Attack» ենթագրերը:

Ցանցային ֆոն

(օգնելու ձեզ ավելի լավ հասկանալ այս միջադեպի հետ կապված գործընթացները)

Եթե ​​ցանկանում եք ուղարկել փաթեթ և ունեք մի քանի նախածանցներ երթուղային աղյուսակում, որը պարունակում է նպատակակետ IP հասցեն, ապա դուք կօգտագործեք ամենաերկար երկարությամբ նախածանցի երթուղին: Եթե ​​երթուղային աղյուսակում միևնույն նախածանցի համար կան մի քանի տարբեր երթուղիներ, դուք կընտրեք լավագույնը (ըստ լավագույն ուղու ընտրության մեխանիզմի):

Զտման և մոնիտորինգի գոյություն ունեցող մոտեցումները փորձում են վերլուծել երթուղիները և որոշումներ կայացնել՝ վերլուծելով AS_PATH հատկանիշը: Գովազդի ժամանակ երթուղիչը կարող է փոխել այս հատկանիշը ցանկացած արժեքի: Պարզապես սեփականատիրոջ ASN-ի ավելացումը AS_PATH-ի սկզբում (որպես սկզբնաղբյուր ASN) կարող է բավական լինել՝ շրջանցելու ընթացիկ ծագման ստուգման մեխանիզմները: Ավելին, եթե կա երթուղի հարձակման ենթարկված ASN-ից դեպի ձեզ, հնարավոր է դառնում հանել և օգտագործել այս երթուղու AS_PATH-ը ձեր մյուս գովազդներում։ Ձեր պատրաստված հայտարարությունների համար միայն AS_PATH-ի վավերացման ցանկացած ստուգում, ի վերջո, կանցնի:

Դեռևս կան մի քանի սահմանափակումներ, որոնք արժե նշել: Նախ, հոսանքին հակառակ մատակարարի կողմից նախածանցի զտման դեպքում, ձեր երթուղին դեռ կարող է զտվել (նույնիսկ ճիշտ AS_PATH-ով), եթե նախածանցը չի պատկանում ձեր հաճախորդի կոնին, որը կազմաձևված է վերևում: Երկրորդ, վավեր AS_PATH-ը կարող է անվավեր դառնալ, եթե ստեղծված երթուղին գովազդվում է սխալ ուղղություններով և, հետևաբար, խախտում է երթուղային քաղաքականությունը: Վերջապես, նախածանցով ցանկացած երթուղի, որը խախտում է ROA երկարությունը, կարող է անվավեր համարվել:

Միջադեպ

Մի քանի շաբաթ առաջ մենք բողոք ստացանք մեր օգտատերերից մեկից։ Մենք տեսանք երթուղիներ իր ծագման 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 նման նախածանց, որոնք բաժանում է իր հաճախորդներին։ Մյուս կողմից, այս չափանիշը վատ է, քանի որ նման նախածանցները կարող են զտվել, եթե օպերատորն օգտագործում է փոքր նախածանցների զտում, բոլոր ուղղություններով։ Հետևաբար, այս մեթոդը հարմար չէ բոլոր օպերատորներին գտնելու համար, որոնց տրաֆիկը վերահղվել է նման միջադեպի հետևանքով:

Մեկ այլ լավ գաղափար, որը մենք մտածեցինք, որ պետք է նայենք POV. Հատկապես երթուղիների համար, որոնք խախտում են համապատասխան ROA-ի maxLength կանոնը: Այս կերպ մենք կարող էինք գտնել անվավեր կարգավիճակ ունեցող տարբեր ծագման ASN-ների թիվը, որոնք տեսանելի էին տվյալ AS-ի համար: Այնուամենայնիվ, կա մի «փոքր» խնդիր. Այս թվի միջինը (միջին և ռեժիմը) (տարբեր ծագման ASN-ների թիվը) մոտ 150 է, և, եթե նույնիսկ զտենք փոքր նախածանցները, այն մնում է 70-ից բարձր: Իրերի այս վիճակը շատ պարզ բացատրություն ունի. կան միայն. մի քանի օպերատորներ, որոնք արդեն օգտագործում են ROA- զտիչներ «վերակայված Անվավեր երթուղիներ» քաղաքականությամբ մուտքի կետերում, այնպես որ, որտեղ էլ որ ROA խախտումով երթուղին հայտնվի իրական աշխարհում, այն կարող է տարածվել բոլոր ուղղություններով:

Վերջին երկու մոտեցումները թույլ են տալիս գտնել օպերատորների, ովքեր տեսել են մեր միջադեպը (քանի որ այն բավականին մեծ էր), բայց ընդհանուր առմամբ դրանք կիրառելի չեն։ Լավ, բայց կարո՞ղ ենք գտնել ներխուժողին: Որո՞նք են այս AS_PATH մանիպուլյացիայի ընդհանուր առանձնահատկությունները: Կան մի քանի հիմնական ենթադրություններ.

• Նախածանցը նախկինում ոչ մի տեղ չէր տեսել.
• Ծագման ASN-ը (հիշեցում. առաջին ASN-ը AS_PATH-ում) վավեր է.
• AS_PATH-ում վերջին ASN-ը հարձակվողի ASN-ն է (եթե նրա հարևանը ստուգում է հարևանի ASN-ը բոլոր մուտքային երթուղիներում);
• Հարձակումը ծագում է մեկ մատակարարից:

Եթե ​​բոլոր ենթադրությունները ճիշտ են, ապա բոլոր սխալ երթուղիները կներկայացնեն հարձակվողի ASN-ը (բացի ծագման ASN-ից) և, հետևաբար, սա «կրիտիկական» կետ է: Իսկական առևանգողների թվում էր AS263444-ը, թեև կային ուրիշներ: Նույնիսկ այն ժամանակ, երբ մենք ուշադրությունից հանեցինք միջադեպի երթուղիները: Ինչո՞ւ։ Կրիտիկական կետը կարող է կրիտիկական մնալ նույնիսկ ճիշտ երթուղիների համար: Դա կարող է լինել կամ տարածաշրջանում վատ կապի կամ մեր տեսանելիության սահմանափակումների արդյունք:

Արդյունքում, կա հարձակվողին հայտնաբերելու միջոց, բայց միայն այն դեպքում, եթե առկա են վերը նշված բոլոր պայմանները և միայն այն դեպքում, երբ խափանումը բավականաչափ մեծ է մոնիտորինգի շեմերը հաղթահարելու համար: Եթե ​​այս գործոններից մի քանիսը բավարարված չեն, ապա կարո՞ղ ենք բացահայտել այն նախածանցները, որոնք տուժել են նման գաղտնալսումից: Որոշ օպերատորների համար՝ այո:

Երբ հարձակվողը ստեղծում է ավելի կոնկրետ երթուղի, այդպիսի նախածանցը չի գովազդվում իրական սեփականատիրոջ կողմից: Եթե ​​դրանից ունեք նրա բոլոր նախածանցների դինամիկ ցանկը, ապա հնարավոր է դառնում համեմատություն կատարել և գտնել խեղաթյուրված ավելի կոնկրետ երթուղիներ։ Մենք հավաքում ենք նախածանցների այս ցուցակը՝ օգտագործելով մեր 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||
Մեր հասցեների տարածքը գաղտնալսելու փորձի վերջին օրինակ

Երբ ավելի կոնկրետ ստեղծվեցին մեր նախածանցների համար, օգտագործվեց հատուկ ստեղծված AS_PATH: Այնուամենայնիվ, այս AS_PATH-ը չէր կարող վերցվել մեր նախորդ երթուղիներից որևէ մեկից: Մենք նույնիսկ կապ չունենք AS6762-ի հետ: Դիտելով միջադեպի մյուս երթուղիները՝ դրանցից մի քանիսն ունեին իրական AS_PATH, որը նախկինում օգտագործվել է, իսկ մյուսները՝ ոչ, նույնիսկ եթե այն իրականին է թվում: AS_PATH-ի լրացուցիչ փոփոխությունը գործնական իմաստ չունի, քանի որ երթևեկությունը, այնուամենայնիվ, կուղղվի հարձակվողին, սակայն «վատ» AS_PATH երթուղիները կարող են զտվել ASPA-ի կամ որևէ այլ ստուգման մեխանիզմի միջոցով: Այստեղ մենք մտածում ենք առևանգողի մոտիվացիայի մասին։ Ներկայումս մենք չունենք բավարար տեղեկատվություն՝ հաստատելու, որ այս միջադեպը պլանավորված հարձակում է եղել։ Այնուամենայնիվ, դա հնարավոր է։ Փորձենք պատկերացնել, թեև դեռ հիպոթետիկ, բայց պոտենցիալ միանգամայն իրական իրավիճակ։

Կատարյալ հարձակում

Ի՞նչ ունենք։ Ենթադրենք, դուք տարանցիկ մատակարար եք ձեր հաճախորդների համար հեռարձակման երթուղիներ: Եթե ​​ձեր հաճախորդները բազմակի ներկայություն ունեն (բազմաբնակարան), ապա դուք կստանաք նրանց տրաֆիկի միայն մի մասը: Բայց որքան շատ տրաֆիկ, այնքան ավելի շատ է ձեր եկամուտը: Այսպիսով, եթե դուք սկսեք գովազդել այս նույն երթուղիների ենթացանցերի նախածանցները նույն AS_PATH-ով, դուք կստանաք դրանց տրաֆիկի մնացած մասը: Արդյունքում՝ մնացած գումարը։

Արդյո՞ք ROA-ն կօգնի այստեղ: Թերևս այո, եթե որոշեք ամբողջությամբ դադարեցնել դրա օգտագործումը առավելագույն երկարություն. Բացի այդ, շատ անցանկալի է ունենալ ROA գրառումներ՝ հատվող նախածանցներով: Որոշ օպերատորների համար նման սահմանափակումներն անընդունելի են:

Հաշվի առնելով երթուղային անվտանգության այլ մեխանիզմները՝ ASPA-ն այս դեպքում նույնպես չի օգնի (քանի որ այն օգտագործում է AS_PATH վավեր երթուղուց): BGPSec-ը դեռ օպտիմալ տարբերակ չէ ընդունման ցածր տեմպերի և նվազման գրոհների հնարավորության պատճառով:

Այսպիսով, մենք ունենք հստակ շահ հարձակվողի համար և անվտանգության պակաս: Հիանալի խառնուրդ!

Ինչ պետք է անեմ:

Ակնհայտ և ամենակտրուկ քայլը ձեր ընթացիկ երթուղային քաղաքականության վերանայումն է: Ձեր հասցեների տարածքը բաժանեք ամենափոքր մասերի (առանց համընկնումների), որոնք ցանկանում եք գովազդել: Նշեք ROA միայն նրանց համար՝ առանց maxLength պարամետրի օգտագործման: Այս դեպքում ձեր ներկայիս POV-ն կարող է ձեզ փրկել նման հարձակումից: Այնուամենայնիվ, կրկին, որոշ օպերատորների համար այս մոտեցումը ողջամիտ չէ ավելի կոնկրետ երթուղիների բացառիկ օգտագործման պատճառով: ROA-ի և երթուղու օբյեկտների ներկայիս վիճակի հետ կապված բոլոր խնդիրները կնկարագրվեն մեր ապագա նյութերից մեկում:

Բացի այդ, դուք կարող եք փորձել վերահսկել նման գաղտնալսումները: Դա անելու համար մեզ անհրաժեշտ է հավաստի տեղեկատվություն ձեր նախածանցների մասին: Այսպիսով, եթե դուք BGP նիստ հաստատեք մեր կոլեկցիոների հետ և տրամադրեք մեզ տեղեկատվություն ձեր ինտերնետի տեսանելիության մասին, մենք կարող ենք գտնել այլ միջադեպերի շրջանակ: Նրանց համար, ովքեր դեռ միացված չեն մեր մոնիտորինգի համակարգին, սկզբից, բավական կլինի միայն ձեր նախածանցներով երթուղիների ցանկը: Եթե ​​դուք նստաշրջան ունեք մեզ հետ, խնդրում ենք ստուգել, ​​որ ձեր բոլոր երթուղիներն ուղարկված են: Ցավոք, սա արժե հիշել, քանի որ որոշ օպերատորներ մոռանում են մեկ կամ երկու նախածանց և այդպիսով խանգարում են մեր որոնման մեթոդներին: Եթե ​​ճիշտ արվի, մենք վստահելի տվյալներ կունենանք ձեր նախածանցների մասին, որոնք ապագայում մեզ կօգնեն ավտոմատ կերպով բացահայտել և հայտնաբերել ձեր հասցեների տարածքի երթևեկության գաղտնալսման այս (և այլ) տեսակները:

Եթե ​​դուք իրական ժամանակում տեղյակ լինեք ձեր տրաֆիկի նման ընդհատման մասին, կարող եք ինքներդ փորձել հակազդել դրան: Առաջին մոտեցումն այն է, որ ինքներդ գովազդեք երթուղիները այս ավելի կոնկրետ նախածանցներով: Այս նախածանցների վրա նոր հարձակման դեպքում կրկնեք.

Երկրորդ մոտեցումն է՝ պատժել հարձակվողին և նրանց, ում համար նա կրիտիկական կետ է (լավ երթուղիների համար)՝ կտրելով ձեր երթուղիների մուտքը հարձակվողին: Դա կարելի է անել՝ ավելացնելով հարձակվողի ASN-ը ձեր հին երթուղիների AS_PATH-ին և այդպիսով ստիպելով նրանց խուսափել այդ AS-ից՝ օգտագործելով BGP-ում ներկառուցված հանգույցի հայտնաբերման մեխանիզմը: ձեր բարիքի համար.

Source: www.habr.com