13 марта в рабочей группе RIPE по борьбе со злоупотреблениями.
предложение было получено рассматривать перехват BGP как нарушение политики 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 таких префиксов, которые она раздает своим клиентам.
С другой стороны, эта метрика плоха, поскольку такие префиксы можно отфильтровать, если оператор использует фильтрация маленьких префиксов , во всех направлениях.
Поэтому этот метод не подходит для поиска всех операторов, трафик которых был перенаправлен в результате такого инцидента.
Еще одна хорошая идея, которую мы подумали, заключалась в том, чтобы посмотреть на ПОВ .
Особенно для маршрутов, нарушающих правило maxLength соответствующего ROA. Таким образом, мы могли бы найти количество ASN различного происхождения со статусом Invalid, которые были видны данной AS. Однако есть «маленькая» проблема.
Среднее (медиана и мода) этого числа (количества ASN различного происхождения) составляет около 150 и, даже если отфильтровать мелкие префиксы, оно остается выше 70. Такое положение вещей имеет очень простое объяснение: существуют только немногие операторы уже используют ROA-фильтры с политикой «сброса недействительных маршрутов» в точках входа, чтобы где бы в реальном мире ни появился маршрут с нарушением ROA, он мог распространяться во всех направлениях.
Последние два подхода позволяют найти операторов, которые видели наш инцидент (поскольку он был довольно масштабным), но в целом они неприменимы.
Хорошо, но сможем ли мы найти злоумышленника? Каковы общие особенности этой манипуляции с AS_PATH? Есть несколько основных предположений:
- Приставка ранее нигде не встречалась;
- Исходный ASN (напоминание: первый ASN в AS_PATH) действителен;
- Последний ASN в AS_PATH — это ASN злоумышленника (в случае, если его сосед проверяет ASN соседа на всех входящих маршрутах);
- Атака исходит от одного провайдера.
Среди истинных угонщиков был AS263444, хотя были и другие.
Даже когда мы исключили из рассмотрения маршруты инцидентов.
Почему? Критическая точка может оставаться критической даже для правильных маршрутов.
Это может быть либо результатом плохой связи в регионе, либо ограничений нашей видимости.
В результате есть способ обнаружить злоумышленника, но только при соблюдении всех вышеперечисленных условий и только тогда, когда объем перехвата достаточно велик, чтобы преодолеть пороги мониторинга.
Если некоторые из этих факторов не соблюдаются, то можем ли мы определить префиксы, пострадавшие от такого перехвата? Для определенных операторов - да.
Когда злоумышленник создает более конкретный маршрут, истинный владелец не объявляет такой префикс.
Если иметь из него динамический список всех его префиксов, то появляется возможность провести сравнение и найти искаженные более конкретные маршруты.
Мы собираем этот список префиксов с помощью наших BGP-сессий, потому что нам предоставляется не только полный список маршрутов, видимых оператору прямо сейчас, но и список всех префиксов, которые он хочет анонсировать миру.
К сожалению, сейчас есть несколько десятков пользователей Радара, которые неправильно заполняют последнюю часть.
Мы уведомим их в ближайшее время и постараемся решить эту проблему.
Все остальные могут присоединиться к нашей системе мониторинга прямо сейчас.
Если вернуться к исходному инциденту, то и злоумышленник, и зона распространения были обнаружены нами путем поиска критических точек.
Удивительно, но 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 или любого другого механизма проверки.
Здесь мы думаем о мотивации угонщика.
В настоящее время у нас недостаточно информации, чтобы подтвердить, что этот инцидент был спланированной атакой.
Тем не менее, это возможно.
Попробуем представить себе пусть пока гипотетическую, но потенциально вполне реальную ситуацию.
Идеальная атака
Что мы имеем? Допустим, вы являетесь транзитным провайдером, транслирующим маршруты для своих клиентов.Если у ваших клиентов множественное присутствие (multihome), то вы будете получать только часть их трафика.
Но чем больше трафика, тем больше ваш доход. Таким образом, если вы начнете рекламировать префиксы подсетей этих же маршрутов с одинаковым AS_PATH, вы получите остаток их трафика.
В итоге остаток денег.
Поможет ли здесь РОА? Возможно, да, если вы решите полностью прекратить его использование.
Кроме того, крайне нежелательно иметь записи ROA с пересекающимися префиксами.
Для некоторых операторов такие ограничения неприемлемы.
Учитывая другие механизмы безопасности маршрутизации, ASPA и в этом случае не поможет (поскольку он использует AS_PATH из действительного маршрута).
BGPSec по-прежнему не является оптимальным вариантом из-за низкой скорости внедрения и сохраняющейся возможности атак с понижением версии.
Таким образом, мы имеем явную выгоду для злоумышленника и отсутствие безопасности.
Отличный микс!
Что мы должны делать?
Очевидный и наиболее радикальный шаг — пересмотреть текущую политику маршрутизации.Разбейте адресное пространство на мельчайшие части (без перекрытия), которые вы хотите рекламировать.
Подпишите ROA только для них, не используя параметр maxLength. В этом случае ваша текущая точка зрения может спасти вас от такой атаки.
Однако, опять же, для некоторых операторов такой подход нецелесообразен из-за исключительного использования более конкретных маршрутов.
Все проблемы с текущим состоянием РОА и объектов маршрута будут описаны в одном из наших будущих материалов.
Кроме того, вы можете попробовать отслеживать подобные перехваты.
Для этого нам нужна достоверная информация о ваших префиксах.
Таким образом, если вы установите сеанс BGP с нашим сборщиком и предоставите нам информацию о вашей видимости в Интернете, мы сможем найти возможности для других инцидентов.
Тем, кто еще не подключен к нашей системе мониторинга, для начала будет достаточно списка маршрутов только с вашими префиксами.
Если у вас есть сеанс с нами, убедитесь, что все ваши маршруты отправлены.
К сожалению, об этом стоит помнить, поскольку некоторые операторы забывают один или два префикса и тем самым мешают нашим методам поиска.
Если все сделано правильно, мы будем иметь достоверные данные о ваших префиксах, что в будущем поможет нам автоматически идентифицировать и обнаруживать этот (и другие) виды перехвата трафика для вашего адресного пространства.
Если вам станет известно о таком перехвате вашего трафика в режиме реального времени, вы можете попытаться противодействовать ему самостоятельно.
Первый подход — самостоятельно рекламировать маршруты с этими более конкретными префиксами.
В случае новой атаки на эти префиксы повторите.
Второй подход — наказать злоумышленника и тех, для кого он является критической точкой (для хороших маршрутов), отрезав злоумышленнику доступ к вашим маршрутам.
Это можно сделать, добавив ASN злоумышленника к AS_PATH ваших старых маршрутов и, таким образом, заставив их избегать этой AS, используя встроенный механизм обнаружения петель в BGP. для вашего же блага .
Теги: #информационная безопасность #Сетевые технологии #маршрутизация #bgp #перехват трафика #hijack
-
Бета-Версия Skype 2.2 Выпущена Для Linux
19 Oct, 24 -
Icq X Status - Сила Статусов.
19 Oct, 24
