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