Безопасный пиринг

Андрей Робачевский

Андрей Робачевский

Известно, что система маршрутизации Интернета уязвима. Любая из порядка 60 000 участвующих в маршрутизации сетей может попытаться внедрить в систему ложный маршрут, и шансы велики, что он будет принят другими сетями, порой со значительными последствиями. Защищенность конкретной сети зависит от усилий других сетевых операторов. Технологические решения и инструментарий играют существенную роль, но повсеместное внедрение этих практик и технологий в сетях определяет конечный результат. Как защитить себя и глобальную систему маршрутизации – этот вопрос мы рассмотрим в данной статье.

Современная система маршрутизации Интернета сформировалась более 25 лет назад. Результатом перехода от топологии с центральной, ядровой сетью (NSFNET) и подключенных к ней региональных сетей стала многосвязная система независимых равноправных сетей без Скакого бы ни было центрального контроля. Параллельно произошел переход от изначального протокола маршрутизации EGP к протоколу BGP. Суть его работы была достаточно проста – каждая из сетей сообщала другой сети – пиру – о сетях, которые через нее доступны, путем анонсирования адресного пространства (адресных префиксов) этих сетей. Удивительно, но ни система маршрутизации, ни сам протокол за прошедшее время существенно не изменились.

Однако в 1995 году, когда была стандартизована сегодняшняя версия протокола BGP – BGP-4 (RFC1771), Интернет во многом являлся научно-исследовательским проектом, а не глобальной коммуникационной системой, поддерживающей мультимиллиардную цифровую индустрию. Гибкость, простота и производительность, а отнюдь не защищенность и безопасность являлись основными требованиями.

Незащищенный BGP

Десять лет спустя, в 2006 году, в IETF были опубликованы два документа: RFC4593, в котором обсуждаются потенциальные угрозы системы маршрутизации, и
RFC4272, в котором подробно рассматриваются уязвимые места протокола BGP – основного протокола глобальной системы маршрутизации Интернета.
Суть их сводится к следующему:

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

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

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

Атаки

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

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

Приведу несколько примеров таких атак и их последствий:

Создание «черных дыр». Целью этой атаки является недоступность сети для всего или части Интернета, другими словами – совершение атаки отказа в обслуживании (Denial of Service, DoS). Атакующая сеть анонсирует адресное пространство других сетей. Весь трафик, имеющий отношение к атакуемой сети, направляется в эту сеть и затем отбрасывается. В результате все сервисы, предлагаемые сетью, становятся недоступными для пользователей. Хрестоматийным примером такой атаки является случай недоступности YouTube.

Захват. По сути не отличается от создания «черных дыр», хотя цели злоумышленников отличаются. Злоумышленники маскируются под атакуемую сеть для проведения краткосрочных акций, например, рассылки спама. После этого такая сеть, или ее фантом, разумеется, исчезает. Часто злоумышленниками используется нераспределенное или давно неиспользуемой адресное пространство.

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

«Утечка маршрутов» (route leaks). Очень похожа на атаку «перенаправления», однако не использует сфабрикованные анонсы, а является нарушением стандартной политики маршрутизации. Стандартная политика связана с ролями, которые сети играют в плане межсетевого соединения: клиент, провайдер и равный партнер, или пир. Примером такого нарушения является ситуация, когда сеть-клиент начинает реанонсировать маршруты, полученные от одного провайдера, другому провайдеру. Таким образом сеть-клиент сама становится провайдером услуги транзита, часто с печальными для себя последствиями – объем перенаправленного трафика намного превышает ресурсы сети. Об «утечках маршрутов» подробно рассказано в статье Джеффа Хьюстона в №2 «Интернета Изнутри».

Нестабильность. Нестабильность в глобальной системе маршрутизации может быть вызвана частыми изменениями в анонсировании конкретной сети (попеременное анонсирование и аннулирование), с целью «демпфирования» маршрутов данной сети провайдерами и, как следствие, блокирования связности.

Фабрикация адреса источника трафика. Хотя в этом случае система маршрутизации как таковая не подвергается атаке, данный метод широко используется в так называемых атаках на отражение. В этом случае обратный трафик, например, ответы на изначальные запросы, направляется не к истинному источнику, а к получателю, чей адрес был сфабрикован. Как правило, такие атаки используют протокол без установления соединения UDP (User Datagram Protocol) и основаны на эффекте усиления, когда небольшие запросы от многих источников порождают ответы значительно большего размера. Одна из критических систем, в основном использующая UDP и подверженная атакам такого рода, является DNS.

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

Инструментарий

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

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

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

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

Таких источников, по существу, три: базы данных распределенных номерных ресурсов региональных интернет-регистратур (РИР, Regional Internet Registry, RIR) whois, интернет-регистратуры маршрутизации IRR (Internet Routing Registry) и репозитории системы RPKI (Resource PKI).

Базы данных номерных ресурсов

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

Хотя эту информацию можно получить через соответствующий whois-сервер регистратуры, иногда более практичным способом является использование так называемых файлов статистики, доступных на сайте ftp. Например, интернет ресурсы, распределенные RIPE NCC, представлены в следующем файле: ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest.

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

База данных IANA (Internet Assigned Number Authority, www.iana.org), например, www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml для ресурсов IPv4, является более компактной, хотя и не содержит деталей — каждая запись имеет размер /8 в случае IPv4, а детализация для адресного пространства IPv6 и того меньше. Однако данный подход позволяет по крайней мере блокировать сети, использующие нераспределенные адресные ресурсы.
Организация Team Cymru, специализирующаяся на вопросах инфраструктурной безопасности, каждые четыре часа генерирует полный список неиспользуемого адресного пространства IPv4 и IPv6. Эти списки доступны как в виде текстового файла, так и путем настройки BGP-пиринга с их сервером маршрутов (route server, RS).

Интернет-регистратуры маршрутизации (IRR)

Частичную помощь в решении данной проблемы оказывают интернет-регистратуры маршрутизации (Internet Routing Registry, IRR). Суть их заключается в следующем: сетевые операторы регистрируют в базе данных свою политику маршрутизации, а именно с кем и как сеть взаимодействует, и префиксы, которые сеть использует и анонсирует в Интернет. Для описания политик используется язык RPSL, о котором мы уже говорили. Также существует инструментарий, наиболее известный из которых IRRToolset, который позволяет автоматизировать конфигурацию маршрутизации провайдера по данным IRR.

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

Неполнота и ненадежное качество данных, а также плохая масштабируемость подхода — попробуйте-ка создать фильтры для всех префиксов, зарегистрированных в IRR! – делает IRR малопригодными для проверки достоверности всех маршрутов в глобальном масштабе. В то же время IRR являются весьма удобным инструментом для автоматизации построения фильтров для подключенных клиентов.

Репозитории RPKI

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

Как и любая система PKI, RPKI имеет иерархическую структуру с корневым сертификатом во главе. Корневой сертификат в качестве списка номерных ресурсов охватывает все адресное пространство IPv4, IPv6 и автономных систем. С помощью этого сертификата могут быть сгенерированы сертификаты РИР в соответствии с фактически распределенным адресным пространством. Замечу, что в настоящее время РИР обеспечивают собственные корневые сертификаты, таким образом мы имеем не одну, а пять иерархических структур RPKI.

РИРы осуществляют сертификацию ресурсов, которые они распределяют локальным регистратурам (Local Internet Registry, LIR). Локальные регистратуры могут осуществлять последующее распределение и соответствующую сертификацию. Наконец, сетевые операторы, многие из которых являются локальными регистратурами, фактически использующие адресное пространство, также должны иметь возможность генерирования временных сертификатов для подписания вторичных объектов RPKI, например, ROA.

В плане обеспечения безопасности маршрутизации, ROA – это ключевой элемент RPKI. Как следует из названия, ROA является разрешением, выданным сетью-владельцем прав на использование адресного пространства на анонсирование данных ресурсов автономной системой (АС), указанной в ROA. В соответствии со спецификацией, ROA содержит номер авторизованной АС и список IP-префиксов, которые эта АС имеет разрешение анонсировать. К этому “заявлению” прилагается сертификат, описывающий соответствующие АИР, и весь объект подписан с использованием ключа, указанного в сертификате.
По сравнению с IRR система обладает несколькими существенными преимуществами. Во-первых, данные о распределенных номерных ресурсах предоставляются в стандартной форме цифровых сертификатов со стандартными расширениями (расширения X.509 собственно и содержат список ресурсов, привязанных к открытому ключу сертификата). Во-вторых, достоверность и свежесть данных может быть проверена с использованием криптографических средств третьими лицами. Как и в стандартном PKI, для проверки необходима конфигурация доверия только к одному сертификату – т.н. точка доверия (Trust Anchor, TA). В-третьих, сертификаты ресурсов могут использоваться их владельцами (держателями адресного пространства) для, например, электронной авторизации определенных автономных систем для анонсирования этого адресного пространства, выполняя, таким образом, функцию объектов route традиционных IRR.
Использование ROA возможно как для построения фильтров, так и в качестве дополнительного правила в процессе выбора пути BGP. Логично предположить, что интеграция информации, полученной от системы RPKI в процесс BGP, является более масштабируемым решением.

Возможное применение IRR и RPKI для валидации анонсов, полученных от соседних сетей, представлено на рис. 2. В случае использования RPKI предполагается, что сервис-провайдер хранит собственную копию всех объектов глобальной системы RPKI, проверяет их достоверность и периодически обновляет. Результирующая база данных содержит только достоверную информацию (достоверный кэш, validated cache) и может быть непосредственно использована процессом BGP маршрутизатора с применением протокола RPKI-маршрутизатор (datatracker.ietf.org/doc/rfc8210/). Другим вариантом является использование этой базы данных для построения фильтром, так же, как и в случае с IRR.

Вопросы внедрения

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

Хорошие манеры

Одним из путей решения проблемы трагедии общин, которая по сути представляет собой неспособность рыночных сил исправить ситуацию, является государственное регулирование. Существует много примеров, особенно в области безопасности, когда регулирование в форме требования соответствия определенным стандартам приносило желаемые результаты.
Классическим примером является введение в США закона, предписывающего обязательное оборудование автомобилей ремнями безопасности. На принятие этого закона существенно повлияла книга Ральфа Нейдера «Опасен на любой скорости».
Однако регулирование имеет ряд недостатков, делающих этот подход малоэффективным, по крайней мере, как единственное решение:
• регулирование предполагает наличие стандартов, определяющих требования по безопасности; часто используемые международные стандарты серии ISO 27000 являются очень общими, дорогостоящими в воплощении и сертификации и нацелены на требование соответствия определенным процессам, а не конечным результатам;
• регулирование может стать непропорциональным бременем для отрасли в решении проблемы;
• наконец, регулирование в государственном масштабе малоэффективно для решения глобальных задач, таких как защищенность глобальной системы маршрутизации.
Другой подход, который, впрочем, также вряд ли является полным решением, использует социальные связи сообщества взаимозависимых игроков. В традиционном случае трагедии общин таким сообществом являются фермеры, обеспокоенные истощением совместно используемых пастбищных лугов, в нашем же случае – это сетевые операторы, пиры, обеспокоенные целостностью и достоверностью совместно создаваемой маршрутизационной информации.
Примером использования такого подхода является инициатива MANRS (Mutually Agreed Norms for Routing Security), поддерживаемая растущим сообществом сетевых операторов. MANRS определяет ряд требований и связанных с ними конкретных мер (Actions), которые являются наиболее элементарными практиками защиты системы маршрутизации. Несмотря на относительную простоту, по мере широкого внедрения эти меры смогут существенно усилить защищенность системы.

Требования эти следующие:

Предотвращение распространения неправильной маршрутизационной информации. Сетевой оператор обеспечивает правильность собственных анонсов и анонсов от своих клиентов со степенью детализации на уровне отдельных префиксов и AS-PATH.
Предотвращение трафика с подложными IP-адресами. Оператор осуществляет проверку адреса-источника для, по крайней мере, клиентских сетей с одним подключением, своих собственных конечных пользователей и инфраструктуры.
Улучшение информационного обмена и координации между сетевыми операторами в глобальном масштабе. Оператор публикует актуальную контактную информацию.
Поддержка проверки достоверности маршрутизационной информации в глобальном масштабе.
Оператор публикует собственную политику маршрутизации и данные о префиксах, анонсируемых сетью. Эти данные могут использоваться другими операторами для проверки достоверности анонсов.
Особенностью MANRS является то, что перечисленные требования имеют узкую область применения, делая их максимально конкретными и оптимальными с точки зрения стоимости внедрения и связанных дополнительных операционных рисков. Так, например, требование предотвращения распространения ложной маршрутизационной информации распространяется только на клиентов провайдера и его собственную инфраструктуру – где проверка достоверности этой информации достаточно тривиальна. То же относится и к другим требованиям.
Этот базовый уровень безопасности составляет основу формирования сообщества операторов с общей целью обеспечения большей защищенности системы. Эта инициатива также открывает перспективы использования экономических факторов для решения задачи безопасности. Из выводов недавно проведенного исследования аналитической компании 451 Research очевидно, что организации, пользующиеся услугами сетевых операторов, весьма обеспокоены теми же проблемами, которые являются целевыми для MANRS. Более того, многие из них видят в MANRS эффективное средство решения этих проблем и готовы на дополнительные затраты ради партнерства с оператором-участником инициативы.

Роль точек обмена трафиком

Многие точки обмена трафиком сами в определенной степени являются сетевыми операторами – возьмите, например, внутреннюю сеть обслуживания. Внедрение общепринятых норм маршрутизационной гигиены в сети IXP безусловно необходимо. Однако в плане вклада в улучшения защищенности системы маршрутизации и пиринга IXP могут внести гораздо более значительный вклад.
IXP могут и уже играют очень важную роль в создании более безопасной инфраструктуры Интернета. Многие из них представляют собой активные сообщества операторов с общими оперативными целями. IXP являются платформой для обсуждения оперативных проблем, включая проблемы небезопасного пиринга, борьбы с вредоносным трафиком атак и аномалии маршрутизации. MANRS в этом отношении может служить хорошей отправной точкой таких обсуждений и стимулировать конкретные результаты.
Для IXP MANRS может предоставить возможность построить «безопасное сообщество операторов», используя общий доказанный уровень безопасности, предоставляемый MANRS. Это также способ продемонстрировать внешнему миру внимание IXP к безопасности и устойчивости экосистемы Интернета и, следовательно, к высококачественным услугам.

Каков же может быть конкретный вклад IXP?

Содействие предотвращению распространения неверной информации о маршрутах.
Многие IXP используют сервер маршрутов для облегчения многостороннего пиринга – при этом оператору необходимо установить лишь одну сессию с RS, чтобы получить все анонсы участников. Сервер маршрутов также может осуществлять дополнительные функции – например, проверять полученные анонсы.
Проверка выполняется путем проверки анонсов BGP с использованием IRR или репозитория RPKI. Также разумно проверять анонсы на предмет «богонов» или «марсиан» (префиксы IP, как определено в RFC1918, RFC5735 и RFC6598; ASN в AS-PATH, как определено RFC5398, RFC6793, RFC6996, RFC7300, RFC7607).
Основываясь на результатах процесса проверки, анонс может быть помечен как VALID, INVALID или UNKNOWN с использованием предопределенных сообществ или отфильтрован в зависимости от политики RS, принятой членами IXP.
Защита пиринговой платформы.
Хотя, строго говоря, это не относится к маршрутизации, применение гигиены на уровне 2 может обеспечить плавную работу платформы и способствовать стабильности инфраструктуры и маршрутизации IXP.
Обычно фильтрация применяется к:
• пактам Ethernet с неразрешенными форматами;
• пакетам с недопустимыми Ethertypes;
• трафику, относящемуся к внутренним протоколам, как IRDP, переадресация ICMP, протоколы обнаружения (CDP, EDP), протоколы VLAN/транкинга (VTP, DTP), BOOTP/DHCP и т.п.;
• трафику, ограниченному конфигурацией безопасности порта MAC.
Помощь в предотвращении нежелательного трафика.
Предлагая телеметрические данные на основе потоков Netflow / Jflow / Sflow / IPFIX для L2-L4 для своих членов, IXP может помочь операторам в предотвращении нежелательного трафика (например, трафик с поддельными исходными IP-адресами) или смягчить атаку DDoS.
Поддержка глобальной оперативной связи и координации между сетевыми операторами.
Эффективная коммуникация между членами IXP имеет важное значение для смягчения сетевых инцидентов, таких как неправильные конфигурации, сбои или атаки DoS. Ключевую роль играют списки рассылки или другие средства связи и каталог участников, доступный всем членам биржи, содержащей обновленную контактную информацию. Такие простые меры, как предоставление необходимых списков рассылки и директориев участников может иметь большое значение для быстрого разрешения случаев злоупотреблений, безопасности и операционных инцидентов.
Предоставление участникам средств мониторинга и отладки.
Смотровое стекло (Looking Glass) сервера маршрутов является важным средством, которое может помочь отладить инциденты или аномалии маршрутизации и предотвратить или сократить негативные последствия таких инцидентов.
Содействие в смягчении атаки отказа в обслуживании (Denial of Service, DoS).
Чтобы помочь сетям смягчить влияние атаки DDoS на их сети, IXP может предложить один из двух основных механизмов для прекращения нежелательного трафика без перегрузки пиринговой платформы или инфраструктуры участников: «сток» (sink hole) и «черная дыра» (blackhole).
При использовании «стока» IXP настраивает конкретный MAC-адрес и соответствующий IP-адрес. Весь трафик, предназначенный для этого IP-адреса, удаляется платформой IXP. Оператор-участник, испытывающий объемную DoS-атаку на определенные префиксы своей сети, может объявить эти префиксы с настройкой next hop, указывающей на IP-адрес «стока». Это можно сделать через сервер маршрута или двусторонний пиринг.
При использовании подхода «черной дыры» оператор, испытывающий объемную DoS-атаку, «включает» черную дыру на сервере маршрутов, используя стандартное BGP-сообщество BLACKHOLE (RFC 7999). В результате весь трафик, предназначенный для этих префиксов, будет удален на платформе IXP.

Заключение
Защищенность системы маршрутизации Интернета зависит от усилий многих участников. Технологические решения и инструментарий играют существенную роль, но внедрение этих практик и технологий в сетях определяет конечный результат. Сегодняшний Интернет насчитывает почти 60 000 автономных систем, которые используют BGP для обмена маршрутами. Однако большинство этих сетей являются конечными клиентами сетей следующего ранга, которые предоставляют услуги транзита и играют более существенную роль в глобальной маршрутизации (см. bgp.potaroo.net/as2.0/bgp-transitas.txt). Таких сетей около восьми тысяч. Если большинство из них станут применять базовые практики маршрутизационной гигиены, о которой я писал в этой статье, маршрутизация в Интернете станет гораздо более защищенной и стабильной.