13 марта в рабочую группу RIPE по борьбе со злоупотреблениями поступило предложение рассматривать BGP-перехват (hijack) в качестве нарушения политики RIPE. В случае принятия предложения интернет-провайдер, атакованный с помощью перехвата трафика, получал бы возможность отправить специальный запрос для вывода злоумышленника на чистую воду. Если экспертная группа соберет достаточно подтверждающих доказательств, то такой LIR, являющийся источником BGP-перехвата, считался бы нарушителем и мог быть лишен статуса LIR. Были и некоторые аргументы против такого изменения.
В данной публикации мы хотим показать пример атаки, когда не только настоящий злоумышленник был под вопросом, но и весь список пострадавших префиксов. Более того, такая атака вновь поднимает вопросы по поводу мотивов будущих перехватов трафика такого типа.
Последние пару лет в прессе в качестве BGP-перехватов освещались только конфликты типа MOAS (Multiple Origin Autonomous System). MOAS — это частный случай, когда две разные автономные системы анонсируют конфликтующие префиксы с соответствующими номерами ASN в AS_PATH (первый ASN в AS_PATH, далее по тексту — origin ASN). Однако мы можем назвать как минимум 3 дополнительных типа перехвата трафика, позволяющих злоумышленнику манипулировать атрибутом 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, в то время как пользователь утверждал, что их не анонсировал.
Примеры анонсов на начало апреля 2019
NTT в пути для префикса /25 делает его особенно подозрительным. Во время инцидента LG NTT ничего не знал об этом маршруте. Так что да, какой-то оператор создает целый AS_PATH для этих префиксов! Проверка на других маршрутизаторах позволяет выделить один особенный ASN: AS263444. Посмотрев на другие маршруты с этой автономной системой, мы столкнулись со следующей ситуацией:
Попробуйте догадаться, что здесь не так
Кажется, что кто-то взял префикс из маршрута, разделил его на две части и анонсировал маршрут с тем же самым AS_PATH для этих двух префиксов.
Примеры маршрутов для одной из пар разделенных префиксов
Возникает сразу несколько вопросов. Действительно ли кто-то пробовал на практике такой тип перехвата? Кто-нибудь принимал эти маршруты? Какие префиксы были затронуты?
Здесь и начинается наша череда неудач и еще один раунд разочарования в текущем состоянии здоровья Интернета.
Обо всем по порядку. Как мы можем определить, какие маршрутизаторы приняли такие перехваченные маршруты и чей трафик может быть перенаправлен уже сегодня? Мы подумали начать с префиксов /25, потому что они «просто не могут иметь глобального распространения». Как вы можете догадаться — мы сильно ошибались. Эта метрика оказалась черезчур зашумлена и маршруты с такими префиксами могут появляться даже от Tier-1 операторов. К примеру, у NTT есть около 50 таких префиксов, которые он распространяет среди собственных клиентов. С другой стороны, данная метрика плоха, потому что такие префиксы могут быть отфильтрованы в том случае, если оператор применяет фильтрацию маленьких префиксов, во всех направлениях. Поэтому такой метод не годится для поиска всех операторов, чей трафик был перенаправлен в результате подобного инцидента.
Еще одной хорошей идеей нам показалось посмотреть на POV. В особенности на маршруты с нарушением правила maxLength соответствующего ROA. Таким образом, мы могли бы найти количество различных origin ASN со статусом Invalid, которые были видны данной AS. Тем не менее, есть «небольшая» проблема. Среднее значение (медиана и мода) этого числа (количества различных origin ASN) составляет около 150 и, даже если мы отфильтруем малые префиксы, оно останется выше 70. Такое положение дел имеет вполне простое объяснение: есть лишь несколько операторов, которые уже применяют ROA-фильтры с политикой “сбрасывать Invalid маршруты” на входных точках, поэтому, где бы в реальном мире ни появился маршрут с нарушением ROA, он может распространяться во всех направлениях.
Последние два подхода позволяют найти операторов, увидевших наш инцидент (так как он был достаточно большим), но в целом они неприменимы. Хорошо, но можем ли мы найти злоумышленника? Каковы общие особенности такой манипуляции AS_PATH? Есть несколько базовых предположений:
Если все предположения верны, то на всех некорректных маршрутах будет представлен ASN злоумышленника (кроме origin ASN) и, таким образом, это является «критической» точкой. Среди истинных угонщиков оказался и AS263444, хотя были и другие. Даже когда мы отбросили маршруты инцидента из рассмотрения. Почему? Критическая точка может оставаться критической даже для корректных маршрутов. Она может являться либо результатом плохой связности в каком-либо регионе, либо ограничений нашей собственной видимости.
Как результат: есть способ обнаружить злоумышленника, но лишь в случае соответствия всем перечисленным выше условиям и только когда перехват достаточно велик для прохождения порогов мониторинга. Если же какие-то из этих факторов не соблюдаются, то можем ли мы выделить префиксы, пострадавшие от подобного перехвата? Для определенных операторов — да.
Когда атакующий создает more specific маршрут, такой префикс не анонсируется истинным владельцем. В случае, если у вас есть от него динамический список всех его префиксов, то появляется возможность провести сравнение и найти искаженные more specific маршруты. Мы собираем этот список префиксов при помощи наших BGP-сессий, так как нам передают не только полный список маршрутов, видимых оператором прямо сейчас, но и список всех префиксов, которые он хочет анонсировать в мир. К сожалению, сейчас существует несколько десятков пользователей Radar, которые последнюю часть выполняют не до конца корректно. В ближайшее время мы оповестим их и постараемся решить эту проблему. Все остальные же могут присоединиться к нашей системе мониторинга прямо сейчас.
Если вернуться к первоначальному инциденту, то и злоумышленник, и область распространения были обнаружены нами при помощи поиска критических точек. Удивительно, но AS263444 рассылал сфабрикованные маршруты не всем своим клиентам. Хотя есть и более странный момент.
Недавний пример попытки перехвата нашего адресного пространства
Когда были созданы more specific’и для наших префиксов, то использовался специально созданный AS_PATH. Однако, этот AS_PATH не мог быть взят ни из одного из наших предыдущих маршрутов. У нас даже нет связи с AS6762. Смотрим на другие маршруты в инциденте: у некоторых из них был настоящий AS_PATH, который использовался ранее, а у других — нет, даже если он и выглядят как настоящий. Дополнительное изменение AS_PATH не имеет никакого практического смысла, так как в любом случае трафик будет перенаправлен злоумышленнику, но маршруты с «плохим» AS_PATH могут быть отфильтрованы ASPA или любым другим механизмом проверки. Здесь мы задумались о мотивации угонщика. Сейчас нам не хватает данных для того, чтобы утверждать, что данный инцидент был спланированной атакой. Тем не менее — это возможно. Давайте попробуем представить хоть пока и гипотетическую, но потенциально вполне реальную ситуацию.
Что мы имеем? Предположим, вы являетесь транзитным провайдером, транслирующим маршруты для своих клиентов. Если ваши клиенты имеют множественное присутствие (multihome), то вы получите лишь часть их трафика. Но чем больше трафика — тем больше ваш доход. Поэтому, если вы начнете анонсировать префиксы подсетей этих же маршрутов с тем же AS_PATH, вы получите остальную часть их трафика. Как следствие, оставшуюся часть денег.
Поможет ли здесь ROA? Возможно, да, если вы решите полностью отказаться от использования maxLength. Кроме того, при этом крайне не желательно иметь записи ROA с пересекающимися префиксами. Для некоторых операторов такие ограничения неприемлемы.
Рассматривая другие механизмы обеспечения безопасности маршрутизации, в данном случае ASPA тоже не поможет (потому что используется AS_PATH от допустимого маршрута). BGPSec по-прежнему не оптимальный вариант из-за низкого процента принятия и остающейся возможности downgrade-атак.
Таким образом, у нас есть явная прибыль для атакующего и нехватка безопасности. Отличная смесь!
Очевидный и наиболее радикальный шаг — пересмотр вашей текущей политики маршрутизации. Разбейте ваше адресное пространство на самые маленькие куски (без пересечений), которые вы только захотите проанонсировать. Подпишите ROA только для них, не используя параметр maxLength. В этом случае текущий POV может вас спасти от подобной атаки. Однако, опять же, для некоторых операторов такой подход не разумен из-за исключительного использования more specific маршрутов. Все проблемы текущего состояния ROA и route объектов будут описаны в одном из наших будущих материалов.
Кроме этого, можно пытаться мониторить подобные перехваты. Для этого нам нужна достоверная информация о ваших префиксах. Таким образом, если вы установите BGP-сессию с нашим коллектором и передадите нам информацию о вашей видимости Интернета — мы можем найти область распространения и для других инцидентов. Для тех, кто еще не подключен к нашей системе мониторинга — для начала нам будет достаточно списка маршрутов только с вашими префиксами. Если же у вас установлена сессия с нами, то, пожалуйста, проверьте, что были отправлены все ваши маршруты. К сожалению, об этом стоит напомнить, так как часть операторов забывают один или два префикса и, таким образом, создают помехи для наших методов поиска. Если все сделать правильно, то у нас будут надежные данные о ваших префиксах, которые в будущем помогут автоматически определять и детектировать такой (и другие) типы перехвата трафика для вашего адресного пространства.
Если вы в режиме реального времени узнали о таком перехвате вашего трафика, вы можете попытаться противодействовать самостоятельно. Первый подход — анонсировать маршруты с этими more specific префиксами самостоятельно. В случае новой атаки на эти префиксы — повторить.
Второй подход — наказать злоумышленника и тех, для кого он является критической точкой (для хороших маршрутов), отрезав доступ ваших маршрутов к злоумышленнику. Это можно сделать, добавив ASN злоумышленника в AS_PATH ваших старых маршрутов и, таким образом, заставить их избегать эту AS, используя встроенный механизм обнаружения циклов в BGP для собственного блага.
В данной публикации мы хотим показать пример атаки, когда не только настоящий злоумышленник был под вопросом, но и весь список пострадавших префиксов. Более того, такая атака вновь поднимает вопросы по поводу мотивов будущих перехватов трафика такого типа.
Последние пару лет в прессе в качестве BGP-перехватов освещались только конфликты типа MOAS (Multiple Origin Autonomous System). MOAS — это частный случай, когда две разные автономные системы анонсируют конфликтующие префиксы с соответствующими номерами ASN в AS_PATH (первый ASN в AS_PATH, далее по тексту — origin ASN). Однако мы можем назвать как минимум 3 дополнительных типа перехвата трафика, позволяющих злоумышленнику манипулировать атрибутом 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 таких префиксов, которые он распространяет среди собственных клиентов. С другой стороны, данная метрика плоха, потому что такие префиксы могут быть отфильтрованы в том случае, если оператор применяет фильтрацию маленьких префиксов, во всех направлениях. Поэтому такой метод не годится для поиска всех операторов, чей трафик был перенаправлен в результате подобного инцидента.
Еще одной хорошей идеей нам показалось посмотреть на POV. В особенности на маршруты с нарушением правила 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? Возможно, да, если вы решите полностью отказаться от использования maxLength. Кроме того, при этом крайне не желательно иметь записи ROA с пересекающимися префиксами. Для некоторых операторов такие ограничения неприемлемы.
Рассматривая другие механизмы обеспечения безопасности маршрутизации, в данном случае ASPA тоже не поможет (потому что используется AS_PATH от допустимого маршрута). BGPSec по-прежнему не оптимальный вариант из-за низкого процента принятия и остающейся возможности downgrade-атак.
Таким образом, у нас есть явная прибыль для атакующего и нехватка безопасности. Отличная смесь!
Что нужно делать?
Очевидный и наиболее радикальный шаг — пересмотр вашей текущей политики маршрутизации. Разбейте ваше адресное пространство на самые маленькие куски (без пересечений), которые вы только захотите проанонсировать. Подпишите ROA только для них, не используя параметр maxLength. В этом случае текущий POV может вас спасти от подобной атаки. Однако, опять же, для некоторых операторов такой подход не разумен из-за исключительного использования more specific маршрутов. Все проблемы текущего состояния ROA и route объектов будут описаны в одном из наших будущих материалов.
Кроме этого, можно пытаться мониторить подобные перехваты. Для этого нам нужна достоверная информация о ваших префиксах. Таким образом, если вы установите BGP-сессию с нашим коллектором и передадите нам информацию о вашей видимости Интернета — мы можем найти область распространения и для других инцидентов. Для тех, кто еще не подключен к нашей системе мониторинга — для начала нам будет достаточно списка маршрутов только с вашими префиксами. Если же у вас установлена сессия с нами, то, пожалуйста, проверьте, что были отправлены все ваши маршруты. К сожалению, об этом стоит напомнить, так как часть операторов забывают один или два префикса и, таким образом, создают помехи для наших методов поиска. Если все сделать правильно, то у нас будут надежные данные о ваших префиксах, которые в будущем помогут автоматически определять и детектировать такой (и другие) типы перехвата трафика для вашего адресного пространства.
Если вы в режиме реального времени узнали о таком перехвате вашего трафика, вы можете попытаться противодействовать самостоятельно. Первый подход — анонсировать маршруты с этими more specific префиксами самостоятельно. В случае новой атаки на эти префиксы — повторить.
Второй подход — наказать злоумышленника и тех, для кого он является критической точкой (для хороших маршрутов), отрезав доступ ваших маршрутов к злоумышленнику. Это можно сделать, добавив ASN злоумышленника в AS_PATH ваших старых маршрутов и, таким образом, заставить их избегать эту AS, используя встроенный механизм обнаружения циклов в BGP для собственного блага.
Комментарии (5)
Zalechi
12.04.2019 21:52А ребята из спец служб таким занимаются?
FYR
12.04.2019 22:50+1зачем им это? у них и так есть полная копия трафика в точке съёма, в пассивном режиме. Вот только если захотят как то организовать "разрыв" и сделать MitM атаку с подменой сертификата без технического разрыва сети. Но уж больно палево.
in_heb
14.04.2019 00:18"Захватив" чужие ip адреса, теоретически и в некоторых случаях практически, можно выписать себе валидный сертификат и воровать пароли и прочее. Но по факту есть ограничения на такие атаки. Если интересно, то можете почитать у меня в статейке https://habr.com/ru/post/442784/
dvmedvedev
Я правильно понимаю, что суть атаки заключается в том, что анонсируя неверные маршруты, злоумышленник заворачивает трафик к себе? Т.е. помимо того, что он может зарабатывать непосредственно на стоимости трафика, он может просматривать нешифрованный трафик, которого будет тем больше, чем больше трафика он на себя завернет?
in_heb
Прослушивать трафик таким образом вы не сможете, т.е. вы не увидите трафик между клиентом и настоящим сервером. Просто часть клиентов будут ходить на ваш поддельный сервер.
Вы можете из своего поддельного сервера сделать реверс-прокси и писать трафик.
Т. е. один лишь hijacking не даёт возможности "просматривать"