Category: traffic engineering

  • С чего начинается Traffic Engineering

    С чего начинается Traffic Engineering

    Недавно ко мне обратились грамотные люди с просьбой проконсультировать по теме временного изменения маршрутизации трафика в сети одного очень крупного провайдера интернет Восточной Европы. Парни очень хотели перенаправить трафик ASIC аппаратов на их кастомный майнинговый пул. Кроме этого им ещё очень хотелось временно перенаправить весь трафик по теме крипты на свою площадку. Давайте посмотрим, какие варианты возможны для этого кейса.

    По моему предыдущему опыту перво-наперво стоит провести анализ транзитного сетевого трафика с помощью любого сетевого анализатора в “неразборчивом” режиме работы сетевой карты (promiscuous mode). В качестве сетевого анализатора для подобных целей замечательно подходит WireShark или CommView. Чтобы выполнить этот первоначальный этап, мне обычно хватает и пары часов работы. По прошествии этого времени у меня как правило накапливается достаточно много данных для проведения анализа перехваченного трафика. И в первую очередь при его анализе я обращаю внимание на следующие протоколы:

    • протоколы коммутации (STP, PVST+, CDP, DTP, VTP, и им подобные)
    • протоколы маршрутизации (LDP, BGP, EIGRP, OSPF, IS-IS и другие)
    • протоколы динамической конфигурации узла (DHCP, BOOTP)
    • открытые протоколы (telnet, rlogin и им подобные)

    Что касается открытых протоколов, – вероятность того, что они попадутся мне во время сбора пакетов проходящего мимо трафика в коммутируемой сети, достаточно мала. Однако, если такого трафика много, то в обследуемой сети явно наблюдаются проблемы в настройках сетевого оборудования.

    Во всех остальных случаях у меня присутствует возможность проведения красивых сценариев:

    • классическая MITM (Man in the middle) в случае, когда используется ARP, DHCP, RIP или LSP
    • получение роли корневого узла STP (Root Bridge), что позволяет перехватывать трафик соседних сегментов
    • перевод порта в магистральный режим с помощью DTP (enable trunking), позволяет перехватывать весь трафик своего сегмента сети

    Для реализации этих сценариев взаимодействия с сетевыми протоколами коммутации я обычно использую такой замечательный инструмент как Yersinia.

    В процессе анализа трафика я часто выявляю пролетающие мимо DTP-пакеты (смотри скриншот). Тогда отправка пакета DTP ACCESS/DESIRABLE может позволить мне перевести порт коммутатора в магистральный режим. Дальнейшее развитие этого сценария позволяет мне прослушивать весь Ethernet сегмент этой сети.

    использование Yersinia для реализации mitm сценария

    После тестирования канального уровня я обычно переключаю внимание на третий уровень модели OSI. Дошла очередь и до проведения сценария взаимодействия через ARP-poisoning. Тут все просто, я очень люблю инструмент Ettercap NG, но всё дело в том, что в случае успешной реализации сценария ARP-poisoning в отношении всего доступного сегмента сети может наступить ситуация, когда MiTM компьютер по середине не справится с потоком поступающих данных и, в конечном счете, это может стать причиной отказа в обслуживании целого сегмента сети, что обязательно заметят. Поэтому наиболее правильным будет выбрать единичные цели, например, рабочие места администраторов и/или разработчиков, какие-либо определенные серверы (возможно контроллер домена, СУБД, терминальный сервер, bgp маршрутизатор и другие важные элементы сети).

    Успешно проведенная мною ARP-poisoning позволяет получить в открытом виде пароли к различным информационным ресурсам – СУБД, каталогу домена (при понижении проверки подлинности NTLM), SNMP-community string, bgp пакеты UPDATE, пароли для сетевого оборудования с уровнем доступа level 15 и другие приятные вещи. В менее удачном случае я могу получить хеш-значения от паролей к различным системам, которые нужно будет постараться восстановить по радужным таблицам (rainbow tables), по словарю или методом “в лоб”. Перехваченные пароли могут использоваться где-то ещё на других сайтах в сети интернет, но впоследствии это также необходимо мне подтвердить или опровергнуть.

    Кроме того, мне стоит проанализировать весь перехваченный трафик на присутствие CAV2/CVC2/CVV2/CID/PIN, передаваемых в открытом виде. Для этого обычно пропускаю сохраненный .pcap файл с дампом трафика через NetResident и/или 0x4553-Intercepter. Второй, кстати, замечательно подходит для анализа накопленного трафика в целом.

    Встраивание в уже созданную BGP сессию и реализация bgp hijacking

    Сразу стоит обозначить результат — поменять маршруты движения трафика, но не управлять каким-то bgp роутером через консоль, то есть не проникая в его систему управления от слов совсем и никак, просто модифицировать данные его таблиц маршрутизации.

    Для этого я использую обычная реализацию IP Spoofing + TCP hijacking = BGP Spoofing сценария для того, чтобы перенаправить все общение между двумя bgp роутерами через свой хост, то есть осуществление полного перехвата и фильтрации BGP сессий этих роутеров. Об инструментах, которые позволяют сделать это внутри транзитной сети поговорим немного позже.

    Реализация BGP spoofing сценария через консоль роутера

    После того, как был получен доступ к bgp роутеру, конечный результат реализации сценария bgp hijacking будет зависеть от настроек его bgp соседей. Есть вероятность, что этому bgp роутеру доверяют все его bgp соседи, а им — их bgp соседи и так далее, так можно незаметно поменять пути маршрутизации и сделать bgp обход целых сетевых сегментов, манипулируя при этом огромными объемами сетевого трафика в Интернет. 

    А возможно, что через этот bgp роутер можно будет изменить пути только в сети, в которой он сам и находиться или в автономной системе этого bgp роутера, но и это на самом деле не такой уж и плохой результат, даже если сеть или Автономная Система небольшие.

    Для начала надо определить, из каких AS у нас наиболее вероятен перехват трафика, а это, как правило, соседние AS относительно той, в которой находиться BGP-роутер. Принадлежность определенного IP к AS и соседи определенной AS могут быть получены различными сервисами, например, тот же bgp.tools либо простым выполнением команды show ip bgp neighbors на роутере. 

    Еще есть интересные сервисы, такие как asnmap.com или bgplay от RIPE. Интерфейс BGP роутера — консоль с ограниченными, определенными командами для управления и конфигурирования текущего BGP демона или устройства и некоторых прилагающихся сетевых сервисов. То есть попав на этот интерфейс можно в реальном времени без каких-либо перезапусков и перезагрузок менять конфигурацию bgp процесса или всего устройства, хотя если попасть в файловую систему роутера, то можно и поменять конфигурацию с его перезапуском.

    Какой сценарий выбрать для понимания bgp в крипте?

    Эксплуатация уязвимостей протокола BGP в контексте криптовалют и блокчейнов – это довольно специфическая область, которая требует углубленного изучения. Сейчас я расскажу о том, какие сценарии могут быть наиболее востребованы в контексте процессинга крипты.

    В сети блокчейнов первого уровня маршрутизация между нодами использует протокол BGP для установления соединений между ними через Интернет, например, Bitcoin или Ethereum. Новые блоки, содержащие транзакции, также распространяются по сети Интернет при помощи BGP, и оно играет важную роль в синхронизации состояния всего блокчейна. BGP помогает поддерживать согласованность состояния блокчейна между всеми нодами. 

    Децентрализованные биржи (DEX) также осуществляют обмен ордерами при помощи BGP и стабильность его работы влияет на эффективность маршрутизации ордеров между различными DEX. BGP также может помочь в распределении ликвидности по различным пулам. 

    Так какой же сценарий выбрать?

    Выбор конкретного сценария зависит от ваших целей.  Если вы новичок и только начинаете изучать BGP в контексте криптовалют, то лучше начать с простых сценариев, таких как маршрутизация в сети Bitcoin и управление bgp роутером через консоль. Но для этого Вам предстоит сначала найти этот роутер и получить к нему доступ ранее озвученными методами. 

    Если вы уже разрабатываете блокчейн-приложения, то вам будет полезно изучить, как BGP используется для масштабирования и создания децентрализованных сетей. Тажке если вы занимаетесь администрированием блокчейн-инфраструктуры, то вам необходимо понимать, как BGP используется для обеспечения надежности и доступности сети. BGP – это сложный протокол, и его полное понимание требует времени и усилий.

    Начните с простых концепций и постепенно углубляйтесь в более сложные темы. Для воздействия на таблицу маршрутизации bgp роутера без доступа в его консоль вам понадобится специализированное программное обеспечение, например ciag-bgp-tools-1.00.tar.gz или Insinuator (ex loki).

    ARP сканирование с помощью loki

    Хотите более конкретные рекомендации? Расскажите о ваших текущих знаниях и целях мне в личном сообщении, и я смогу подобрать для вас наиболее подходящий сценарий. Какие из этих сценариев вы хотели бы изучить подробнее? Контактные данные указаны в соответствующем разделе этого сайта.

  • Перехват BGP-сессии и вброс своего маршрута в сети интернет

    Перехват BGP-сессии и вброс своего маршрута в сети интернет

    Как показывает стабильный рост числа инцидентов, система Интернет-маршрутизации не так безопасна, как мы бы того желали.

    Давайте для начала разберемся, что собственно представляет из себя интернет маршрутизация. Маршрутизация основана на автономных системах (AS), которые обмениваются префиксами (диапазоны IP адресов) используя Border Gateway Protocol (BGP). Автономные системы это первые и главные интернет провайдеры (ISP). Но некоторые организации подключены к двум или более провайдерам одновременно. IP адреса, которые ISP выдают своим клиентам, сгруппированны в относительно небольшое число префиксов, покрывающих большие адресные блоки. Эти префиксы “анонсируются” или “рекламируются” через BGP в AS. Префиксы идут от AS к AS, так что в конце концов весь Интернет знает, куда отсылать пакеты с данным адресом назначения.

    Понятие BGP (Border Gateway Protocol, протокол граничного шлюза) было более осязаемо 20 лет назад, когда слово “шлюз” использовалось для название того, что мы сегодня называем маршрутизатор. Итак BGP это протокол, используемый между пограничными маршрутизаторами – роутерами, которые находятся на периферии соседствующих автономных систем. AS представляют собой иерархию, которая выглядит примерно таким образом:

    Между поставщиками Интернет-услуг (ISP) и потребителями услуг показаны отношения сверху вниз: пользователь платит провайдеру. Пунктирные линии показывают отношения, где трафик обменивается без участия денежных операций. При такой экономической модели трафик идет вверх по иерархии, затем в сторону и в конце концов вниз. Маршруты, которые ведут в сторону, затем вниз или вверх, а потом опять в сторону возникают только тогда, когда кто-либо предоставляет бесплатные услуги, что случается довольно таки редко.

    BGP spoofing scheme

    Таким образом, AS 6 может идти к AS 5 по маршруту 6 – 3 – 1 – 2 – 5, где AS 6 платит AS 3, который в свою очередь платит AS 1, при этом AS 5 оплачивающем услуги AS 2. Получается, что все ISP получают деньги, даже несмотря на то, что AS 1 не платит AS 2. Однако маршрут 6 – 3 – 4 – 2 – 5 не действенен для доставки трафика от AS 6 к AS 5. В этом случае, AS 4 пришлось бы платить AS 2 за этот трафик, но так как AS 3 ничего не платит AS 4, получилось бы, что AS 4 предоставляет свои услуги бесплатно. С другой стороны, маршрут 6 – 3 – 4 – 8 от AS 6 к AS 8 работает нормально, так как AS 8 это клиент AS 4 и следовательно AS 8 оплачивает AS 4 входящий трафик.

    Сам по себе BGP не в курсе денежных проблем. В своем дефолтном состоянии BGP поверит всему и с радостью предоставит услуги бесплатно. Чтобы этого избежать, BGP-маршрутизаторы должны обладать фильтрами, которые удостоверяются, что только корректная информация передается по протоколу. В дополнении, “реклама” префиксов, являющаяся способом BGP привлекать входящий трафик, должна высылаться только в соответствии с бизнес отношениями.

    Зная то, как автономные системы взаимосвязаны с другими автономными системами, будь то клиент/ISP соединение или равноправный информационный обмен, можно точно узнать, как может быть достигнута искомая точка назначения из любого источника. Также, необходимо знать какой диапазон IP адресов принадлежит к какой AS. Расчеты перемаршрутатизации после неудачи несколько усложняют дело, но это не слишком большая проблема.

    Знание графа сети и отношений префиксов AS позволило бы создать фильтры, которые утверждали бы информацию, получаемую через BGP и отклоняли некорректную или ложную информацию. Есть специальные базы данных маршрутизации, где отмечается такая информация. К сожалению, не всегда удается пополнять их и информация зачастую ненадежна. IETF и региональные регистраторы, которые раздают IP адреса и AS номера, сейчас работают над базой данных и инфраструктурой сертификатов, которые как раз позволили бы это делать. Хотя пока это только разработки.

    Как бы то ни было, где же эти сервера?

    Операторы сети просто напросто сами не знаю где находится сервера CNN, в Атланте или в Пекине. И когда приходит обновление BGP, утверждая последнее, у провайдеров – точнее у их роутеров, нет другого выбора: им приходится устанавливать обновления и посылать трафик в новом направлении. 999 раз из 1000 перемаршрутизация это вполне обыденное явление. Но 1 раз это все-таки либо ошибка, либо какого-нибудь рода атака.

    В 1990 году, случился как раз такой инцидент, который послал трафик в Китай. При этом сетевые инженеры потратили часы, решая проблему. На сегодняшний день подобные случаи это обычное дело. В результате ряд систем мониторинга доступен по всему Интернету. И они постоянно контролируют ситуацию, которая не может остаться незамеченной.

    Это ведет к неприятному состоянию когнитивного диссонанса. С одной стороны, непостижимо, как Интернет-маршрутизация может быть столь наивной. С другой стороны, ведь в большинстве случаев она работает. Исправление ситуации было бы делом непростым, дорогим и окупилось бы далеко не сразу.

    (Я пошел на мое первое IETF собрание в 2002 году, когда в разработке находилась система маршрутизации inter-AS. Я помню у нас был ланч в пицеррии в Атланте. Было 20 человек из Cisco, которые все время неистово изображали топологию сетей на салфетках. К этому времени уже было два предложения для того, чтобы сделать BGP более безопасным: S-BGP от BBN и soBGP от Cisco. Вот уже почти десять лет прошло в спорах о том, какое из этих предложений лучше и вообще стоит ли что-нибудь предпринимать… Но результатов как не было так и нет…)

    Не стоит недооценивать сложности, возникающие при обеспечении безопасности Интернет маршрутизации. Что если сертификат используемый S-BGP или soBGP истечет? Если это означает, что соединение будет прервано, пожелаем успехов в скачивании нового сертификата…

    Маршрутизация это критическая система реального времени. В таких системах традиционная модель отключения не подтвержденных систем не работает. Когда система работает, важно использовать механизмы безопасности, чтобы не позволить хакерам подорвать ее работу. В то же время важно, чтобы сами механизмы безопасности не вставали на пути исправления проблемы, когда происходят сбои в системе или сбой близок. К сожалению, существующие меры безопасности не имеют такого баланса.

    Спасает маршрутизацию то, что большинство ISP тщательно фильтруют то, что клиенты им присылают. И если я настрою свой BGP-маршрутизатор сообщить моему провайдеру, что я владелец IP адреса Windows Update, то мой ISP должен проявить бдительность и игнорировать подобную BGP “рекламу”. И так как между ISP и клиентами имеют место быть бизнес-отношения, обе стороны заинтересованы быть в курсе всех последних изменений в префиксах.

    Однако как только некорректная информация перешла границу клиент/провайдер, она быстро распространится по равноправным соединениям практически не встречая никаких преград на своем пути. Это происходит потому, что на данный момент нет никакой официальной базы данных маршрутизируемой информации. Единственный способ ISP отфильтровать равноправных ISP – это постоянный обмен обновленным данным по принципу тет-а-тет. Но по причине постоянной смены клиентов и введения новых префиксов, большого количества пиров у крупных ISP – это способ просто неосуществим.

    Китайская маршрутизация

    Так что же на самом деле случилось в Китае, что повлекло перенаправление маршрутов 15% Интернет-префиксов – а не 15% трафика – на эту страну в апреле? И был ли это несчастный случай или что-то более опасное? Я не был в офисе China Telecommunications Corporation и не наблюдал за случившимся лично, поэтому не могу сказать наверняка, был ли это дьявольский и совершенный план или очень глупая ошибка сетевого инженера. Но я порассуждаю на эту тему позже, не только из-за принципа “Лезвия Хэнлона” (“Никогда не приписывайте злонамеренности тому, что вполне может быть объяснено глупостью”).

    Обычный сбой протокола BGP – утечка всей таблицы маршрутизации. В настоящее время существует 341 000 Интернет-префиксов, образующих Интернет, и чтобы работать со всеми ними BGP-маршрутизатору нужно иметь их все в таблице маршрутизации. Если по какой-либо причине BGP-маршрутизатор не имеет никаких фильтров, он просто отправляет всю копию этой таблицы всем маршрутизаторам в соседних автономных системах, к которым он подключен.

    Утечка всей таблицы – ошибка, которая случается достаточно часто, и, казалось бы, это и произошло в Китае. Но вот что могло иметь место на самом деле.

    После обновления фильтра, он может перестать функционировать. Обычно, такое случается с фильтром “максимального префикса” последней инстанции – это останавливает сессию BGP если получено большее количество префиксов нежели возможно. Но, даже не беря в расчет это, подобная утечка должна была быть не настолько разрушительной, потому что обход через (например) Китай означает преодоление дополнительных автономных систем, а BGP предпочитает долгим путям короткие. Это обусловлено тем, что для каждого префикса автономные системы на пути к адресу назначения записываются в “AS путь” – самый короткий путь по количеству автономных систем.

    Однако простая утечка целой таблицы, или хотя бы большей ее части, в данном случае была осложнена любопытным проектным решением China Telecom. Это решение наводит на мысль, что China Telecom очистила AS путь от всех префиксов, которые утекли и таким образом наилучший путь к американским сайтам начал пролегать через китайского провайдера. С точки зрения клиентов China Telecom, адрес назначения, например, CNN, находился внутри сети China Telecom, а не просто достигался через эту сеть.

    Поэтому относительно многие автономные системы начали отдавать свой трафик Китаю. Освобождение AS путей случается когда информация из BGP экспортирована в другой протокол маршрутизации, используемый локально, а потом возвращается обратно в BGP. Такая практика кажется опасной из-за подобного обсуждаемого здесь ранее инцидента. К тому же нет никакого логичной причины зачем делать это – есть правда несколько нелогичных – но я не могу допустить мысли, что такое могло произойти совершенно случайно.

    Таким образом утечка целой таблицы BGP или ее части сама по себе не настолько подозрительна, хотя провайдерам размера China Telecom следовало бы в этом разбираться лучше. Но то, что AS пути были очищены, можно расценить как причину для умеренного подозрения.

    Если бы я был еще большим параноиком, я бы, тем не менее, начал искать в Интернете неправильные префиксы/комбинации автономных систем, которые случайно проявлялись бы на некоторое время. Тот, кто хочет перехватить трафик, наверняка бы создал несколько серверов и BGP-маршрутизаторов в дата-центрах с хорошей связью, а потом попытался бы посмотреть, какой Интернет-провайдер дает сбой в фильтрации. С таким провайдером нацеленная атака могла бы вызвать перемаршрутизацию трафика гораздо дольше чем на 18 минут. Перенаправление префиксов Северной Америки внутри самой Америки выглядело бы менее подозрительно, чем перенаправление их в Китай.

    Пока мы ждем появления какой-то формы безопасности для BGP, мы все должны задуматься о том, что бы случилось, если бы адреса удаленных систем, с которыми мы общаемся, были перенаправлены и наш трафик был бы перехвачен. Шифрование и закрытая аутентификация типа HTTPS или VPN защищают от этого. Однако есть проблема и в шифровании: центрам выдачи сертификатов нельзя так уж доверять. А как справиться с этим – расскажу в следующий раз.

  • Qual a diferença entre vazamentos de rotas BGP e sequestros de rotas BGP?

    Qual a diferença entre vazamentos de rotas BGP e sequestros de rotas BGP?

    Uma das principais funcionalidades do serviço de monitoramento e análise de BGP é o monitoramento de anomalias específicas que podem resultar em um incidente, que denominamos vazamento de rota BGP ou sequestro de BGP.

    Ambos redirecionam o tráfego para terceiros, em comparação com o estado sem anomalias, mas de maneiras diferentes. Nos últimos anos, muitos esforços foram investidos na resolução desses problemas, mas ainda existem mal-entendidos sobre o que é o quê e como diferentes ferramentas ajudam a resolver diferentes problemas.

    Começamos a coletar o modelo de relacionamentos BGP alguns anos antes do surgimento da RFC 7908, tentando definir o que é um vazamento de rota BGP. As duas principais diferenças entre esses momentos de ocorrência foram descritas como:

    • Rotas redirecionadas por meio de ASNs/links incorretos (Vazamentos de rota), descritos como tipos 1 a 4 na RFC 7908.
    • Rotas redirecionadas para ASNs incorretos (Sequestro de rota), descritas como tipos 5 e 6 na RFC 7908.

    Durante um vazamento de rota BGP, o tráfego destinado à sua rede provavelmente fluirá de forma ineficiente, o que pode levar ao aumento da latência e à perda de pacotes. No entanto, ele quase certamente chegará à sua rede, a menos que haja congestionamento crítico devido a algum motivo (como a má intenção de um malfunctor). Durante um sequestro de rota BGP, o tráfego destinado à sua rede é redirecionado para um terceiro e permanece lá. Além disso, os mecanismos para criar esses tipos de anomalias também são diferentes. Para criar um vazamento de rota, é necessário transferir uma rota válida para um provedor de internet vizinho inadequado. Para criar um sequestro de rota, é preciso anunciar uma rota com um subprefixo/prefixo válido mais específico (para atrair todo o tráfego dos provedores de internet que receberam tal anúncio com o AS_PATH desejado) ou criar um anúncio de rota com um prefixo de terceiro a partir da sua rede. Como os mecanismos para criar anomalias de roteamento variam, os mecanismos de detecção e prevenção/mitigação de incidentes também devem ser diferentes.

    Para detectar a causa de um vazamento de rotas, é necessário descobrir a relação entre cada uma das duas operadoras conectadas e identificar as rotas BGP (obtidas de um coletor BGP) que violam o modelo formal de Gao-Rexford. Para mais informações, consulte “Relações AS” da CAIDA. Para detectar sequestros de rotas, é preciso ter informações precisas sobre quais prefixos pertencem a quais ISPs e, na maioria dos casos, quando um par de prefixos de ISPs não registrados aparece, é necessário gerar um alerta ou tomar alguma ação.

    Para prevenir/mitigar sequestros de rotas, existem duas abordagens padrão dentro de uma estrutura de Validação de Origem de Prefixo (POV). Você pode registrar um objeto Route em seu IRR ou criar um objeto ROA. Nossa equipe descreveu as diferenças entre essas abordagens durante o RIPE79. No entanto, o que elas têm em comum é que ambas definem quais prefixos pertencem a quais operadoras (pelas próprias operadoras) e tentam bloquear rotas de um ISP com prefixos não registrados (por ISPs de trânsito). Para prevenir/mitigar vazamentos de rotas puros, participamos da criação de uma política aberta de BGP. Outra abordagem é o bloqueio de pares — bloquear rotas com vizinhos/ISPs inesperados no AS_PATH. O rascunho do ASPA da IETF se destaca um pouco da prevenção pura de sequestro/vazamento de rotas, pois se concentra mais no bloqueio de AS_PATHs ruins (casos de vazamento de rotas e sequestros com/sem manipulação inadequada do AS_PATH).

    ROA vs. Vazamentos de Rota

    Então, sua rede estará segura se você implementar assinatura ROA e filtragem ROA? Não, porque sem ASPA ou qualquer equivalente, o ROA por si só não impedirá que outros vazem rotas. Esperamos que agora você entenda a complexidade desse problema, onde abordagens distintas são necessárias para proteger a base do roteamento interdomínio moderno: o Border Gateway Protocol (BGP).

    Assinatura ROA vs. Filtragem ROA

    Outro equívoco comum está relacionado ao ROA. Existem duas partes nos algoritmos ROA: a parte que assina – o operador, que fornece a verdade fundamental sobre os prefixos que possui; e a parte que filtra – o operador de trânsito, que filtra rotas ruins de acordo com as informações fornecidas pela parte que assina.

    Como um operador stub (ou seja, um AS com apenas um provedor upstream), você tem um número limitado de maneiras de influenciar a quantidade de partes que filtram. Quanto mais partes filtram, mais seguros seus prefixos serão (menos regiões serão afetadas se um sequestrador decidir atacar seus prefixos). Se você optar por assinar seus prefixos, poderá usar uma infraestrutura de filtragem existente, que só tende a crescer no futuro próximo. Além disso, recomendamos que você faça exatamente isso, independentemente do tamanho da rede por trás do seu ASN.

    Este artigo termina com um alerta: a infraestrutura de filtragem atual ainda pode ser imperfeita e, em alguns casos, você não conseguirá retornar o tráfego de uma região afetada devido à opção de comprimento máximo escolhida e à filtragem ROA (Root Access Address) do seu provedor de internet.

  • Sự khác biệt giữa rò rỉ tuyến BGP và tấn công chiếm quyền điều khiển tuyến BGP là gì?

    Sự khác biệt giữa rò rỉ tuyến BGP và tấn công chiếm quyền điều khiển tuyến BGP là gì?

    Một trong những tính năng chính của dịch vụ giám sát và phân tích BGP là theo dõi các bất thường cụ thể có thể dẫn đến sự cố mà chúng ta gọi là rò rỉ tuyến BGP hoặc chiếm quyền điều khiển BGP.

    Cả hai đều chuyển hướng lưu lượng truy cập đến bên thứ ba, so với trạng thái không có bất thường, nhưng theo cách khác nhau. Trong vài năm qua, rất nhiều nỗ lực đã được đầu tư vào việc giải quyết những vấn đề này, nhưng vẫn còn những hiểu lầm về bản chất của từng vấn đề và cách các công cụ khác nhau giúp giải quyết các vấn đề khác nhau.

    Chúng tôi bắt đầu thu thập mô hình mối quan hệ BGP vài năm trước khi RFC 7908 xuất hiện, cố gắng định nghĩa rò rỉ tuyến BGP là gì. Hai điểm khác biệt chính giữa hai thời điểm đó được mô tả như sau:

    • Các tuyến được chuyển hướng qua các ASN/liên kết sai (Rò rỉ tuyến), được mô tả là loại 1-4 trong RFC 7908
    • Các tuyến được chuyển hướng đến các ASN sai (Chiếm đoạt), được mô tả là loại 5 và 6 trong RFC 7908

    Trong trường hợp rò rỉ tuyến BGP, lưu lượng truy cập hướng đến mạng của bạn rất có thể sẽ chảy một cách không hiệu quả, dẫn đến tăng độ trễ mạng và mất gói tin. Tuy nhiên, nó vẫn sẽ đến được mạng của bạn gần như chắc chắn nếu không có tắc nghẽn mạng nghiêm trọng vì lý do nào đó (như ý đồ xấu của kẻ gây hại). Trong trường hợp chiếm quyền kiểm soát tuyến BGP, lưu lượng truy cập hướng đến mạng của bạn bị chuyển hướng đến bên thứ ba và ở lại đó. Hơn nữa, cơ chế tạo ra các loại bất thường này cũng khác nhau. Để tạo ra rò rỉ tuyến, bạn cần chuyển một tuyến đường tốt đến một nhà cung cấp dịch vụ Internet (ISP) lân cận không phù hợp. Để tạo ra chiếm quyền kiểm soát, bạn cần thông báo một tuyến đường với tiền tố phụ/cụ thể hơn của một tiền tố hợp lệ (để thu hút tất cả lưu lượng truy cập từ các ISP đã nhận được thông báo đó với bất kỳ AS_PATH nào bạn muốn) hoặc tạo một thông báo tuyến đường với tiền tố của bên thứ ba từ mạng của bạn. Vì cơ chế tạo ra các bất thường định tuyến khác nhau, nên cơ chế phát hiện sự cố và phòng ngừa/giảm thiểu cũng cần khác nhau.

    Để phát hiện nguyên nhân rò rỉ tuyến đường, bạn cần tìm hiểu mối quan hệ giữa hai nhà mạng được kết nối và tìm ra các tuyến BGP (từ bộ thu thập BGP) vi phạm mô hình chính thức Gao-Rexford; để biết thêm thông tin, vui lòng tham khảo tài liệu “Mối quan hệ AS” của CAIDA. Để phát hiện các vụ chiếm đoạt tuyến đường, bạn cần có thông tin chính xác về việc tiền tố nào thuộc về nhà cung cấp dịch vụ Internet (ISP) nào, và trong hầu hết các trường hợp, khi xuất hiện một cặp ISP có tiền tố chưa được đăng ký – hãy tạo cảnh báo hoặc thực hiện hành động.

    Để ngăn chặn/giảm thiểu các vụ chiếm đoạt tuyến đường, có hai phương pháp tiêu chuẩn trong khuôn khổ Xác thực Nguồn gốc Tiền tố (Prefix Origin Validation – ROA) duy nhất. Bạn có thể đăng ký một đối tượng Tuyến đường (Route) trong IRR của mình hoặc tạo một đối tượng ROA. Nhóm của chúng tôi đã mô tả sự khác biệt giữa các phương pháp này trong RIPE79. Tuy nhiên, điểm chung là cả hai đều nêu rõ tiền tố nào thuộc về nhà mạng nào (do chính các nhà mạng cung cấp) và cố gắng chặn các tuyến đường từ một ISP có tiền tố chưa được đăng ký (do các ISP trung chuyển). Để ngăn chặn/giảm thiểu rò rỉ tuyến đường thuần túy, chúng tôi tham gia vào việc tạo ra một chính sách mở BGP. Một cách tiếp cận khác là khóa ngang hàng – chặn các tuyến đường có các láng giềng/ISP không mong muốn trong AS_PATH. Bản dự thảo ASPA IETF hơi khác so với việc ngăn chặn chiếm đoạt/rò rỉ tuyến đường thuần túy vì nó tập trung hơn vào việc chặn các AS_PATH xấu (các trường hợp rò rỉ tuyến đường và chiếm đoạt có/không có thao tác AS_PATH xấu).

    ROA so với rò rỉ định tuyến

    Vậy, mạng của bạn có an toàn không nếu bạn triển khai cả chữ ký ROA và lọc ROA? Không, bởi vì nếu không có ASPA hoặc bất kỳ giao thức tương đương nào, bản thân ROA sẽ không ngăn chặn được việc rò rỉ định tuyến từ bên ngoài. Chúng tôi hy vọng rằng giờ đây bạn đã thấy vấn đề này phức tạp như thế nào, cần có các phương pháp riêng biệt để bảo mật nền tảng của định tuyến liên miền hiện đại – Giao thức Cổng Biên (Border Gateway Protocol).

    Chữ ký ROA so với lọc ROA

    Một quan niệm sai lầm phổ biến khác liên quan đến ROA. Có hai bên trong thuật toán ROA: bên ký – nhà điều hành, cung cấp thông tin xác thực về các tiền tố mà họ sở hữu; và có một bên lọc – nhà điều hành trung chuyển, lọc ra các tuyến đường xấu dựa trên thông tin do bên ký cung cấp.

    Là một nhà điều hành nhánh (nghĩa là một AS chỉ có một nhà cung cấp đường lên), bạn bị hạn chế về số lượng cách bạn có thể tác động đến số lượng các bên lọc. Càng nhiều bên lọc, tiền tố của bạn càng an toàn hơn (càng ít vùng bị ảnh hưởng nếu kẻ tấn công quyết định tấn công tiền tố của bạn). Nếu bạn quyết định ký tiền tố của mình, bạn có thể sử dụng cơ sở hạ tầng lọc hiện có, và cơ sở hạ tầng này sẽ chỉ phát triển hơn nữa trong tương lai gần. Hơn nữa, chúng tôi khuyến khích bạn vẫn nên làm như vậy, bất kể quy mô mạng lưới phía sau ASN của bạn lớn đến đâu.

    Bài viết này vẫn sẽ kết thúc bằng một lời cảnh báo: cơ sở hạ tầng lọc hiện tại vẫn có thể chưa hoàn hảo, và trong một số trường hợp, bạn không thể chuyển hướng lưu lượng truy cập từ khu vực bị ảnh hưởng do tùy chọn độ dài tối đa đã chọn và việc lọc ROA ở phía nhà cung cấp dịch vụ Internet của bạn.