Всичко е много лошо или нов тип прихващане на трафика

13 март до работната група на RIPE за борба със злоупотребите е получена оферта считайте отвличането на BGP (hjjack) за нарушение на политиката на RIPE. Ако предложението бъде прието, интернет доставчикът, атакуван от прихващане на трафик, ще има възможност да изпрати специална заявка за разкриване на нападателя. Ако екипът за проверка събере достатъчно подкрепящи доказателства, LIR, който е бил източникът на прихващане на BGP, ще се счита за нарушител и може да бъде лишен от LIR статус. Имаше и някои аргументи срещу това промени.

В тази публикация искаме да покажем пример за атака, при която става въпрос не само за истинския нападател, но и за целия списък от засегнати префикси. Освен това подобна атака отново повдига въпроси за мотивите за бъдещи прихващания на този вид трафик.

През последните няколко години само конфликти като MOAS (Multiple Origin Autonomous System) са отразявани в пресата като прихващане на BGP. MOAS е специален случай, при който две различни автономни системи обявяват конфликтни префикси със съответните ASN в AS_PATH (първият 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. Особено за маршрути, които нарушават правилото за maxLength на съответния ROA. По този начин бихме могли да намерим броя на различните източници на ASN със статус Невалиден, които са били видими за дадена AS. Има обаче един "малък" проблем. Средната стойност (медиана и режим) на това число (броят на ASN с различен произход) е около 150 и дори ако филтрираме малки префикси, остава над 70. Това състояние на нещата има много просто обяснение: има само малко оператори, които вече използват ROA-филтри с политика за „нулиране на невалидни маршрути“ във входните точки, така че където и да се появи маршрут с нарушение на ROA в реалния свят, той може да се разпространява във всички посоки.

Последните два подхода ни позволяват да намерим оператори, които са видели нашия инцидент (тъй като беше доста голям), но като цяло те не са приложими. Добре, но можем ли да намерим натрапника? Какви са общите характеристики на тази манипулация AS_PATH? Има няколко основни допускания:

• Префиксът не беше виждан никъде преди;
• Произходен ASN (напомняне: първият ASN в AS_PATH) е валиден;
• Последният ASN в AS_PATH е 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 за твое добро.

Източник: www.habr.com