Չափազանց վատ է կամ նոր տրաֆիկի գողացումի տեսակ

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

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

Վերջին couple տարիների ընթացքում մամուլում որպես BGP-կրող հաղորդվել էին միայն MOAS (Քանի բազմակի աղբյուրի ինքնավար համակարգ): MOAS-ն առանձնահատուկ դեպք է, երբ երկու տարբեր ինքնավար համակարգեր հայտարարում են հակասական նախակետեր համապատասխան ASN համարներով AS_PATH-ում (առաջին ASN AS_PATH-ում, ապա՝ առաջատար ASN): Այնուամենայնիվ, մենք կարող ենք նշել ինչպես նվազագույնը 3 լրացուցիչ տեսակներ տրաֆիկի կրող ներխուժումների, որոնք թույլ են տալիս չարագործին հարստացնել AS_PATH-ը տարբեր նպատակներով, այդ թվում՝ ժամանակակից ֆիլտրելու և վերահսկելու մոտեցումները շրջանցելու համար: Սովորություն ունեցող ապակառուցողական հարձակում Պիլոսովա-Կապելա - վերջին տեսակն այդպիսի ներխուժման, բայց ոչ նշանակությամբ: Ելնելով հնարավոր է, որ հենց այսպիսի հարձակումն ենք դիտել անցած շաբաթների ընթացքում: Այս իրողությունը բացատրելի է և բավական լուրջ հետևանքներ ունի:

Այն մարդիկ, ովքեր TL;DR տարբերակը փնտրում են, կարող են գլուխը թերթել «Իդեալ հարձակում» ենթադրված վերնագրից:

Հաղորդակցային բեքգրաունդ

(որովհետեւ դուք ավելի լավ կիմանաք այս инцидzende զուգորդված պրոցեսները)

Եթե ցանկանում եք փոխանցել փաթեթ և ունեք մի քանի նախակետեր маршрутизացիայի աղյուսակում, որոնք պարունակում են հասցեն նախատեսված, ապա կառաջարկեք маршрут նախակետի մաքսիմալ երկարությամբ: Սակայն եթե маршрутизացիայի աղյուսակում մի քանի տարբեր маршруտներ կան նույն նախակետի համար, դուք կընտրեք լավագույնը (լավագույն ճանապարհի ընտրելու մեխանիզմի համաձայն):

Կիրառվող մոտեցումներն իրականացնում են երթուղիների ֆիլտրում և դիտարկման փորձեր՝ վերլուծելով 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|ԱՎԵԼԱԿԱՆ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|ԱՎԵԼԱԿԱՆ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|ԱՎԵԼԱԿԱՆ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|ԱՎԵԼԱԿԱՆ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|ԱՎԵԼԱԿԱՆ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|ԱՎԵԼԱԿԱՆ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|ԱՎԵԼԱԿԱՆ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|ԱՎԵԼԱԿԱՆ|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||

Երթուղիների օրինակներ մեկ բաժին բաժանված նախապաշարների համար

Միանգամից մի քանի հարց է առաջանում: Արդյոք ինչ-որ մեկը փորձել է այսպիսի բռնագանձման տեսակային պրակտիկայում? Ով ընդունել է այս երթուղիները? Ո cuáles նախապաշարները տուժել են:

Այնդտեղ սկսվում է մեր ձախողումների շարքը և ևս մեկ ռաունդ անհամալիրության ներկայիս վիճակով Ինտերնետի:

Ձախողումների ճանապարհ

Ամբողջքի մասին հերթով: ինչպես կարող ենք որոշել, որ quais ուղղ/router'ներ ընդունել են այդպիսի խաբած ուղիներ և ում տրաֆիկը կարող է արդեն այսօր հրապարակված լինել: Մենք մտածեցինք սկսել /25 նախածանցերից, քանի որ դրանք «հնարավոր է, որ չունեն global տարածում»: Ինչպես կարող եք ենթադրել՝ մենք շատ սխալվեցինք: Այս մետրիքը առանձնապես աղմկոտ էր, և նման նախածանցերը կարող են հայտնվել նույնիսկ Tier-1 օպերատորներից։ Օրինակ, NTT-ի մոտ կա մոտ 50 նախածանց, որոնք նա տարածում է իր հաճախորդներին։ Մյուս կողմից, այս մետրիքը վատն է, քանի որ նման նախածանցեր կարող են զտվել, եթե օպերատորը կիրառում է փոքր նախածանցերի զտում, ամեն կողմերից։ Այդ պատճառով այս մեթոդը չի կարող օգտագործվել բոլոր օպերատորների որոնման համար, ում տրաֆիկը ուղղվել է նման դեպքի արդյունքում։

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

Եվս երկու մոտեցումները թույլ են տալիս գտնել օպերատորներին, որ չեն տեսել մեր դեպքը (քանի որ նա բավականին մեծ է), բայց ընդհանուր առմամբ նրանք չեն կիրառելի: Լավ, բայց հնարավո՞ր է գտնել վնասատուն։ Ինչ են ընդհանուր հատկանիշները այդպիսի AS_PATH-ի մանիպուլյացիայի։ Արևելյան հանրային մի քանի հիմնական ենթադրերում՝

  • Նախածանցը երբևէ նկատված չի եղել՝ նախորդում;
  • Origin ASN (հիշեցում՝ AS_PATH-ում առաջին ASN) օրինական է;
  • AS_PATH-ում վերջին ASN-ն է հարձակվողի ASN-ը (եթե նրա հարևանը ստուգում է հարևանի ASN-ը բոլոր եկած ուղիներում);
  • Հարձակումը գալիս է մեկ մատակարարից։

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

Իրականում կա եղանակ՝ բացահայտելու հարձակվողին, բայց միայն այն դեպքում, եթե բոլոր վերոնշված պայմանները պահպանվեն, եւ միայն այն ժամանակ, երբ զետեղումը բավականաչափ մեծ է մոնիտորինգի շեմը հաղթահարելու համար։ Իսկ եթե այդ գործոններից որևէ մեկը չի պահպանում, արդյոք կարող ենք առանձնացնել այն նախածանցերը, որոնք ենթարկվել են նման զետեղման։Certain operators - yes.

Երբ հարձակվողը ստեղծում է ավելի_specific երթուղի, այս նախածանցը չի հայտարարվում իրական սեփականատերու կողմից։ Եթե դուք ունեք ստանդարտ դինמիկ ցանկ իր բոլոր նախածանցերի համար, ապա կա հնարավորությունը համեմատվելու եւ գտնելու փոփոխված ավելի_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||

Հայեցակարգի վերջերս մի օրինակ՝ մեր հասցեային տարածության ուղղակի ճնշումներ փորձեր։

Երբ մեր նախածանցերի համար ստեղծվեցին ավելի_specific’իական երթուղիներ, օգտագործվեց հատուկ ստեղծված AS_PATH։ Սակայն, այս AS_PATH-ը չի կարող եղել նախորդ երթուղիների մեկից։ Մենք նույնիսկ չունենք կապ AS6762-ի հետ։ Նայում ենք միջադեպի մյուս երթուղիներին՝ որոշները ունեցել են իրական AS_PATH, որն օգտագործվել է ֆինանսական ահաբեկման շրջանակներում, իսկ մյուսներն՝ ոչ, նույնիսկ եթե նրանք նման են իրականին։ AS_PATH-ի լրացուցիչ փոփոխությունները չունեն խոստումնալից իմաստ, քանի որ այս բոլոր դեպքում երթուղին հարձակվողին կուղղվի, բայց "վատ" AS_PATH-ով երթուղիները կարող են ֆիլտրավվել ASPA-ով կամ ցանկացած այլ ստուգման մեխանիզմի միջոցով։ Այստեղ մենք մտածեցինք նշել հարձակվողի շարժառիթն։ Այժմ մեզ պակասում են տվյալներ, որպեսզի հաստատենք, որ այս միջադեպը թե՛ ծրագրած հարձակելու գործողություն էր։ Համենայն դեպս՝ դա հնարավոր է։ Եկեք փորձենք պատկերացնել, որքանով թե ստացվում է, բայց հնարավոր մանիպուլացնող իրավիճակը։

Իդեալական հարձակումը

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

Կպաշտպանե՞ս այստեղ ROA-ն։ Հնարավոր է, այո, եթե դուք որոշեք ամբողջովին հրաժարվել օգտագործելուց maxLength. Кроме того, при этом крайне не желательно иметь записи ROA с пересекающимися префиксами. Для некоторых операторов такие ограничения неприемлемы.

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

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

Ի՞նչ պետք է անել։

Հասկանալի և առավել խիստ քայլը կլինի վերանայել ձեր ընթացիկ երթուղու քաղաքականությունը։ Վերահյացնեք ձեր հասցեի տարածքը ամենափոքր կտորներով (ոչ հատուկներ), որոնք դուք ցանկանում եք հայտարարել։ ROA-ն ստորագրեք միայն դրանց համար՝ բացառելով maxLength պարամետրը։ Այս դեպքում ընթացիկ POV-ը կարող է ձեզ փրկել նման հարձակման դեպքում։ Սակայն, կրկին ասված՝ որոշ օպերատորների համար նման մոտեցումը ոչ ռացիոնալ է՝ միտում ունենալով առավել կոնկրետ երթուղիների բացառիկ օգտագործման պատճառով։ Երթուղային ROA-ի և ճանապարհային օբյեկտների ներկայիս վիճակի բոլոր խնդիրները կописписцәՁել մեր ապագա նյութերից մեկում։

Բացի այս, կարելի է փորձել հետևել նման հարձակումներին։ Для этого нам нужна достоверная информация о ваших префиксах. Таким образом, если вы установите BGP-сессию с нашим коллектором и передадите нам информацию о вашей видимости Интернета, мы можем найти область распространения и для других инцидентов. Для тех, кто еще не подключен к нашей системе мониторинга, для начала нам будет достаточно списка маршрутов только с вашими префиксами. Если же у вас установлена сессия с нами, то, пожалуйста, проверьте, что были отправлены все ваши маршруты. К сожалению, об этом стоит напомнить, так как часть операторов забывают один или два префикса и, таким образом, создают помехи для наших методов поиска. Если все сделать правильно, то у нас будут надежные данные о ваших префиксах, которые в будущем помогут автоматически определять и детектировать такой (и другие) типы перехвата трафика для вашего адресного пространства.

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

Երկրորդ մոտեցումը՝ պատժել հանցագործին և նրանց, ովքեր նրա համար կարևոր կետ են (լավ маршруտների համար), կտրել ձեր маршруտների մուտքը հանցագործին: Սա կարելի է անել, ավելացնելով հանցագործի ASN-ը ձեր հին маршруտների AS_PATH-ում և, таким образом, ստիպելով նրանց խուսափել այս AS-ից, օգտագործելով BGP-ում встроенный механизм обнаружения циклов: իր սեփական բարօրության համար.

Ընտանիք: habr.com

Գնել հուսալի հյուրընկալում DDoS պաշտպանությամբ, VPS VDS սերվերներով 🔥 Գնել հուսալի հյուրընկալում DDoS պաշտպանությամբ, VPS VDS սերվերներով | ProHoster