Защита пути

Предисловие

Незащищенность глобальной системы маршрутизации Интернета известна на протяжении нескольких десятилетий. Существует инструментарий, позволяющий сетям осуществить проверки полученных маршрутов и улучшить уровень «гигиены» в системе. По мере внедрения все более технологичных механизмов проверки все более остро встает задача удостоверения не только маршрута и его источника, но и цепочки сетей, через которые прошел анонс этого маршрута. Решение этой задачи позволит избежать разрушительных аварий.

Вы, наверное, не раз слышали, что протокол маршрутизации BGP, являющийся, так сказать, нервной системой Интернета, был изобретен без особого внимания к безопасности. В то время, в конце 80-х – начале 90-х прошлого века, Интернет находился в опьяняющей фазе стремительного развития базовой инфраструктуры, и требования к масштабированию и простота внедрения являлись основными. Хотя червь Морриса (Morris worm) уже успел наделать шума, все же плохое поведение скорее ожидалось от пользователей оконечных устройств – компьютеров, чем от операторов базовой сетевой инфраструктуры.

Для того, чтобы понять суть проблемы, давайте кратко остановимся на том, как работает BGP. Согласно модели BGP Интернет состоит из произвольным образом соединенных независимых сетей – так называемых автономных систем (Autonomous System, AS). Другими словами, BGP не накладывает каких-либо требований на топологию связности – сети могут соединяться, образуя иерархическую структуру, или формировать паутину.

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

Рис. 1. Передача анонсов в BGP.

«Маршрут» в терминах BGP называется NLRI (Network Layer Reachability Information, дословно – информация досягаемости сетевого уровня) и содержит префикс и его длину, что необходимо для поддержки CIDR. Например, NLRI /24, 198.51.100 указывает на маршрут к устройствам с IP-адресами в диапазоне 198.51.100.0 – 198.51.100.255.

Помимо NRLI в сообщении BGP (BGP Update) также содержаться т.н. атрибуты – параметры, связанные с анонсированным NLRI, которые используются при выборе «лучшего» маршрута и реализации политики маршрутизации. Атрибут, который имеет отношение к сегодняшнему разговору, это AS_PATH, содержащий список номеров автономных систем, через которые было передано сообщение BGP. По мере передачи анонса каждая сеть добавляет свой номер автономной системы. Таким образом, сеть-получатель анонса знает, через какие сети он уже прошел, и может использовать эту информацию при выборе оптимального пути.

Проблема безопасности заключается в том, что эта информация о пути в BGP не защищена и может быть модифицирована любой из сетей в процессе передачи анонса. К чему это может привести?

Во-первых, информация о сети-получателе трафика может быть фальсифицирована. Номер автономной системы, пославший изначальный анонс NLRI и таким образом оповестившей остальных, что она является местом назначения для трафика к этим сетям, стоит первым в атрибуте пути AS_PATH (поскольку AS_PATH растет справа налево, номер автономной системы-получателя самый правый), может быть заменен на номер системы атакующего. Соответственно, трафик к сетям, указанным в NLRI, будет направлен в сеть атакующего с различными последствиями: ложные сервисы сети могут быть выданы за оригинальные или трафик может быть вообще отброшен, что приведет к атаке отказа в услугах. Так, кстати, произошло с сервисом YouTube в 2008 году (https://www.ripe.net/publications/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study). Это – так называемая атака захвата префикса, или prefix hijacking.

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

Оговорюсь, хотя в примерах выше я использовал термины «атака» и «атакующий», в большинстве случаев такие сбои маршрутизации происходят в результате ошибочной конфигурации. Это, впрочем, не делает последствия менее разрушительными.

Решения

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

Является ли префикс, полученный в сообщении BGP, правомерным (т.е. представляющим законно распределенное адресное пространство и право на его использование)?
Является ли автономная система-отправитель сообщения BGP правомочным источником префикса?
Соответствует ли атрибут AS_PATH, полученный в сообщении BGP, действительному пути, который прошло данное сообщение в сети Интернет?

Для получения ответа на первые два вопроса сетевыми операторами издавна использовались так называемые интернет-регистратуры маршрутизации (IRR, Internet Routing Registry). Суть их сводится к следующему: оператор регистрирует специальные объекты – «route», – которые документируют префиксы, анонсируемые данной автономной системой. Соответственно, обращаясь к регистратуре, другие операторы могут получить ответы на первые два вопроса. Проблема заключается в качестве данных – многие из регистратур не имеют достаточных механизмов контроля, что позволяет регистрировать ложные или хранить устаревшие данные. В результате отсутствует механизм надежной валидации полученных ответов.

Система, построенная на основе RPKI, призвана решить эти проблемы. Фундаментом системы является система открытых ключей (Public Key Infrastructure, PKI), элементами которой являются сертификаты интернет-ресурсов. На основе этих сертификатов держатели ресурсов могут создавать криптографически заверенные объекты, например, ROA (Route Origin Authorization), указывающие на список автономных систем, которые могут являться источником определенного маршрута.

Во-первых, данные о распределенных номерных ресурсах предоставляются в стандартной форме цифровых сертификатов со стандартными расширениями (расширения X.509, собственно, и содержат список ресурсов, привязанных к открытому ключу сертификата). Во-вторых, достоверность и свежесть данных может быть проверена с использованием криптографических средств третьими лицами. Как и в стандартном PKI, для проверки необходима конфигурация доверия только к одному сертификату – т.н. «точке доверия» (Trust Anchor, TA). В-третьих, сертификаты ресурсов могут использоваться их владельцами (держателями адресного пространства) для, например, электронной авторизации определенных автономных систем для анонсирования этого адресного пространства, выполняя, таким образом, функцию объектов «route» традиционных IRR.

Использование ROA возможно как для построения фильтров, так и в качестве дополнительного правила в процессе выбора пути BGP. Логично предположить, что интеграция информации, полученной от системы RPKI, в процесс BGP является более масштабируемым решением.

Архитектура такого решения схематично представлена на рисунке 2. Предполагается, что сервис-провайдер хранит собственную копию всех объектов глобальной системы RPKI, проверяет их достоверность и периодически обновляет. Результирующая база данных содержит только достоверную информацию (достоверный кэш, содержащий т.н. проверенные данные ROA – validated ROA payload, или VRP) и может быть непосредственно использована процессом BGP маршрутизатора.

Рис. 2. Интеграция RPKI в процесс принятия решения BGP.

При получении очередного сообщения BGP маршрутизатор запрашивает базу данных на предмет наличия префиксов, указанных в сообщении BGP. В случае, когда атрибуты NRLI и AS_PATH (первая АС пути – источник анонса) полученного анонса соответствуют какому-либо из VRP в кэше, это означает, что маршрут достоверный, и его состояние маркируется как «valid».

Если же база данных не содержит VRP для указанных префиксов, это означает, что система RPKI не содержит ни одного правомерного объекта ROA для этих префиксов. Причин этому может быть несколько. Например, просроченный сертификат в цепочке проверки подлинности ROA или просто отсутствие ROA как такового. Учитывая, что внедрение данной системы будет происходить постепенно, данная ситуация скорее свидетельствует, что сеть еще не использует преимущества RPKI, и такой маршрут может быть принят при отсутствии более надежного. В этом случае результатом определения достоверности маршрута будет «not-found».

Напротив, если база данных содержит VRP, описывающие префиксы, указанные в анонсе BGP, но не соответствующие автономным системам-отправителям, указанным в атрибуте AS_PATH, возможно, это является свидетельством захвата префикса (prefix hijacking), и такой маршрут следует использовать с большой осторожностью. Скорее всего, его следует отбросить, даже если он единственный.

Результат определения достоверности такого маршрута – «invalid».

Описанную процедуру проверки достоверности маршрута с использованием RPKI часто называют ROV (Route Origin Validation, проверка достоверности источника маршрута).

В любом случае, результат ROV является одним из критериев выбора маршрута в BGP, наряду с другими атрибутами BGP: длиной пути (AS_PATH), ORIGIN, MED. В конечном счете интерпретация этой информации является частью политики маршрутизации данной сети. Например, на начальном этапе внедрения RPKI более разумной может быть политика занижения приоритета маршрутов «invalid» с помощью параметра LOCAL_PREF, как показано на рис. 2.

А как же быть с ответом на третий вопрос – как установить, соответствует ли атрибут AS_PATH, полученный в сообщении BGP, действительному пути, который прошло данное сообщение в сети Интернет?

BGPSEC

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

Например, злоумышленник может утверждать, что автономная система, указанная в ROA, является его клиентом, путем присоединения номера этой АС в атрибут AS_PATH своих анонсов BGP. Другими словами, хотя RPKI не сможет полностью защитить глобальный Интернет от фабрикации адреса отправителя, атак типа Pilosov и YouTube, его внедрение и, главное, применение сопутствующих технологий сервис-провайдерами позволит ограничить вред, наносимый маршрутизационными атаками.

Поэтому в IETF были разработаны стандарты, обеспечивающие возможность проверки криптографической подлинности анонса маршрута и достоверности пути, по которому этот анонс был передан.

Например, представим анонс маршрута 192.168/16 сетью AS 1 сети AS 2 и затем AS 3. По получению этого анонса сеть AS 4 сможет удостовериться, что AS 1 является правомочным «владельцем» маршрута 192.168/16, который она анонсировала сети AS 2. Сеть AS 2 получила этот маршрут от сети AS 1 и передала его сети AS 3. Сеть AS 3 получила этот маршрут от сети AS 2 и передала его сети AS 4.
Идея решения этой проблемы основана на расширении возможностей самого протокола BGP. Это расширение реализуется с помощью нового атрибута BGP – BGPSEC_Path_Signatures. Атрибут этот содержит последовательность цифровых подписей для каждой сети (точнее – автономной системы), через которую был передан данный анонс маршрута.

Для лучшего понимания, как это работает, представим три сети – AS1, AS2 и AS3 (см. рис. 2). Допустим, что AS1 анонсирует маршрут 192.168/16 сети AS2. При использовании BGPsec этот анонс будет содержать атрибут BGPSEC_Path_Signatures, состоящий из префикса 192.168/16, сети-источника AS1 и сети-пира, которой этот маршрут передан – AS2. Вся эта информация заверена подписью AS1. В свою очередь, когда сеть AS2 передаст этот анонс сети AS2, она также заверит своей подписью информацию, полученную от AS1, плюс номер автономной системы-пира, которой передается анонс, – AS3. Схематично это показано на рисунке 3.

Заметим, что с точки зрения передачи анонсов, от граничных маршрутизаторов требуется только наличие секретного ключа своей автономной системы для подписания атрибута BGPSEC_Path_Signatures.

Если AS3 захочет удостовериться в подлинности полученного анонса, ей придется проделать несколько проверок. Сначала она должна будет убедиться, что AS1 действительно авторизована держателем соответствующего адресного пространства анонсировать этот маршрут. Для этого AS3 проверит наличие и достоверность соответствующего объекта ROA системы. Затем она должна будет последовательно проверить подписи, содержащиеся в атрибуте BGPSEC_Path_Signatures полученного анонса, чтобы убедиться в их подлинности и соответствию пути прохождения анонса.

Рис. 3. Схема работы BGPSEC.

Для возможности проверки подписей граничных маршрутизаторов BGPSEC определяет дополнительный тип сертификата, связывающего открытый ключ маршрутизатора с номером его автономной системы. Этот сертификат является дочерним по отношению к сертификату RPKI данной автономной системы. Таким образом при проверке анонса проверяющая сторона сможет создать цепочку доверия, используя глобальную систему RPKI.

Более прагматичные решения

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

Во-первых, постепенное внедрение проблематично с экономической точки зрения, так как любая AS на пути, которая не поддерживает BGPSEC, сводит на нет все усилия и преимущества, делая валидацию невозможной. А таких AS на начальном этапе будет очень много. Во-вторых, BGPSEC не защищает от другого вида атак – так называемых утечек маршрута (route leak).

Суть этой атаки можно проиллюстрировать на простом примере. Допустим, сеть AS64501 является клиентом двух провайдеров транзита – AS A и AS B. В случае, если этот клиент реанонсирует маршрут к Google Public DNS (8.8.8.0/24), полученный от AS B, другому провайдеру – сети AS A, а последняя примет его, то произойдет утечка маршрута. В результате весь трафик клиентов AS A к Google будет направлен через клиентскую сеть AS1, вероятнее всего, с катастрофическими последствиями для последней.

Рис. 4. Утечка маршрута сетью-клиентом.

Без дополнительных проверок со стороны сети AS A так и произойдет, поскольку типичная политика маршрутизации предполагает, что маршруты, полученные от клиентов, имеют предпочтение. При этом, конечно, политика предполагает, что клиент анонсирует только свои собственные сети, а не чужие сети где-то в Интернете, о которых он узнал от другого провайдера. Другими словами, в данном случае мы имеем дело с нарушением политики, а не манипуляцей пути. BGPSEC в данной ситуации бессилен.

Но если на BGPSEC рассчитывать не приходится, какие возможности улучшения защищенности маршрутизации есть в распоряжении сетевых операторов?

Peer-lock

Peer-lock (peer-locking) – это механизм, предложенный Джобом Сняйдерсом (Job Snijders, в то время работавший в NTT), обеспечивающий определенную защиту от утечек маршрутов, поступающих от пиров. В отличие от утечки, вызванной сетью-клиентом, как показано на рис. 4, утечки такого типа происходят в результате нарушения пиринговой политики – пиры должны анонсировать только собственные сети и сети своих клиентов. Если пир анонсирует сети, полученные от других пиров, – это приводит к утечке маршрута.

Механизм peer-lock основан на активной координации и требует кооперации от сети-пира, которая желает стать «защищенной» («protected ASN»). В самом простом варианте анонсы, включающие эту AS, позволены только через прямое пиринговое соединение. Анонсы, содержащие эту AS, но полученные от других пиров, будут отброшены.

Схема работы peer-lock показана на рисунке 5. Сеть NTT является провайдером, обеспечивающим механизм. Защищенная сеть «peer A» указывает на возможность альтернативного транзита через сеть «peer B». В этом случае анонсы, содержащие B в пути, будут приняты NTT только непосредственно от A или от B. Анонс с сетью B, полученный от сети C, будет отброшен. Таким образом, даже если сети A и C обмениваются маршрутами в режиме пиринга, peer-lock предотвратит возможную утечку маршрута через C.

Рис. 5. Механизм работы peer-lock. Источник: Job Snijders, https://archive.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf

Механизм может быть адаптирован с учетом географической распределённости сетей, более подробное описание доступно здесь – https://instituut.net/~job/peerlock_manual.pdf.
Была также предпринята попытка расширить и автоматизировать механизм с использованием атрибута community BGP, https://datatracker.ietf.org/doc/draft-heitz-idr-route-leak-community/, но дальше изначального предложения дело не пошло. Некоторые из этих идей были использованы в другом предложении, https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-detection-mitigation, работа над которым продолжается в IETF.

ASPA

ASPA, сокращенное от Autonomous System Provider Authorization, или авторизация провайдеров автономной системы, позволяет автономной системе указать ее непосредственных провайдеров транзита. Подход основан на регистрации объектов ASPA, криптографически сертифицированных с помощью системы RPKI.

Согласно интернет-драфту «Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization» (https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/) ASPA – это объект с цифровой подписью, который связывает для выбранного адресного пространства AFI (например, IPv4 или IPv6) набор номеров AS провайдеров с номером AS клиента (с точки зрения анонсов BGP, а не бизнеса) и подписывается владельцем AS клиента. ASPA подтверждает, что владелец клиентской AS (CAS) авторизовал набор провайдеров AS (Set of Provider ASes, SPAS) для дальнейшего анонсирования сетей клиента, например, провайдерам выше по потоку или пирам.

В этом смысле механизм похож на только что рассмотренный нами peer-lock. Однако peer-lock трудно автоматизировать, и информация о возможных транзитных провайдерах предназначена для конкретной сети, реализующей peer-lock, а не является частью глобального репозитория, как это предполагается в ASPA.

В отличие от BGPSEC, который позволяет проверить всю цепочку пути анонса, ASPA позволяет определить валидность фрагментов пути. Процедура проверки сводится к следующему, при этом предполагается, что проверяющая сторона, например, сеть, осуществляющая фильтрацию неверных анонсов, имеет доступ к кэшу всех криптографически правильных объектов ASPA. Допустим, проверяющей стороне требуется проверить валидность фрагмента пути AS_PATH (AS1, AS2, AFI), а именно предположения, что в случае, если AS1 является клиентской AS, AS2 является законным провайдером транзита для адресного пространства AFI.

Проверяющая сторона запрашивает из кэша все объекты ASPA, у которых CAS имеет значение AS1. Объединенное множество всех SPAS является потенциальными провайдерами.
В случае, если это множество пусто, проверка заканчивается с результатом «Unknown» (Неизвестно).
Если AS2 является членом этого множества, проверка заканчивается с результатом «Valid» (Верно).
В противном случае проверка заканчивается с результатом «Invalid» (Неверно).

Рис. 6. ASPA позволяет предотвратить замаскированные захваты и утечки маршрута.

Как уже обсуждалось, одной из задач защиты пути является предотвратить так называемые замаскированные захваты маршрута, когда атакующий представляется провайдером атакуемой системы. Так, на рис. 6 AS2 может модифицировать AS_PATH анонсов сетей AS5 провайдеру AS1, добавив AS5 в качестве клиента. Проверка с помощью ROA (ROV) в этом случае не поможет, поскольку формально AS5 является источником анонсированных маршрутов. Хотя такой маршрут является менее «конкурентоспособным» в силу увеличенной длины, для многих сетей он может все же являться лучшим маршрутом, что приведет к успешной атаке.

Если же AS5 зарегистрирует своих транзитных провайдеров с помощью ASPA (AS5, [AS1, AS3]), атакующему будет гораздо сложнее представиться провайдером AS5 – фрагмент пути (AS2, AS5) будет отмечен как неверный в процессе проверки ASPA (см. рис. 6). Чем больше фрагментов пути будут зарегистрированы с помощью ASPA, тем меньше шансы у атакующего провести успешный захват маршрута.

Поскольку ASPA указывает на отношения между сетями (клиент-провайдер) и связанную с ними стандартную политику маршрутизации, этот механизм можно использовать для обнаружения утечек маршрутов. Так, AS3 сможет установить, если AS5 «протекла» с маршрутами, полученными от другого провайдера транзита AS1, а AS9 сможет остановить утечку маршрутов через последовательных пиров. Эти примеры приведены на рис. 6.

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

***

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

Так, например, многие операторы используют ROV и фильтруют маршруты с результатом «Invalid». Более строгий контроль за анонсами, получаемыми от клиентских сетей, всегда полезен. Для одноуровневых клиентских конов хорошо работают фильтры, явно указывающие клиентские сети.

Для более сложных топологий определенный контроль правильности пути поможет избежать серьезных происшествий. Наиболее простой способ – следить за так называемыми основными сетями или сетями первого уровня (Tier-1). Эти сети являются «ядром» Интернета, они не являются ничьим клиентом и обмениваются трафиком между собой в режиме равноправного пиринга. Поэтому эти сети не могут присутствовать в пути маршрутов, полученных от клиентской сети. В более общем случае в пути полученного маршрута не должно присутствовать более двух таких сетей, и они должны следовать друг за другом. Несоблюдение этого условия является признаком утечки маршрута.

Многие «строительные блоки» защищённой маршрутизации доступны сегодня, а новые уже на подходе. Слово за операторами!