Курсовая работа (т): ООП в Python

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

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

·              является ли автономная система-отправитель сообщения BGP, правомочным источником (origin) префикса?

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

Следует отметить, что существующая практика среди сетевых операторов во многих случаях игнорирует указанные вопросы. Ряд операторов ограничиваются инспекцией (фильтрацией) префиксов, получаемых от непосредственных клиентов (по существу частично отвечая на первый вопрос). Некоторые операторы осуществляют инспекцию префиксов на основе "макро"-фильтров, отражающих, например, распределенное адресное пространство на уровне IANA.

Одной из причин такой ситуации является трудоемкость получения четких ответов на поставленные вопросы и сложность автоматизации этого процесса. Это, в первую очередь, связано с отсутствием достоверного способа документирования использования адресного пространства. Как уже упоминалось, существующие базы данных whois Региональных Интернет Регистратур содержат неполную и сильно различающуюся по качеству информацию; еще хуже состояние дел в Интернет-регистратурах маршрутизации (Internet Routing Registry, IRR). Эта проблема усугубляется отсутствием надежного способа определения достоверности данных, полученных из этих баз данных.

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

1.      Генерация трафика с использованием подложных адресов в качестве источника трафика. Данная технология используется в атаках отказа в обслуживании DoS (Denial of Service). Например, в случае использования протокола DNS, атакуемые компьютеры играют роль отражателей и усилителей трафика, который затем поражает компьютеры, якобы являющиеся источником запросов.

2.      Притягивание трафика, является одним из видов атаки DoS. Ярким примером явилось анонсирование компанией Pakistan Telecom адресного пространства серверов YouTube, с последующим игнорированием входящего трафика, что привело к невозможности доступа к сервису YouTube.

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

.        Краткосрочная незаконная деятельность с использованием присвоенного адресного пространства. Примером может служить анонсирование временной сети для атаки DoS или рассылки спама.

Система RPKI может упростить решение проблем 2-4. Следует отметить, что RPKI сама по себе не является решением проблем безопасности, поскольку решение о принятии дополнительных мер - например дополнительных проверок при предоставлению транзита сети или фильтрация маршрутов, - остается за сетевым оператором. Но система RPKI может облегчить или даже автоматизировать подобные задачи.

.4 Установление пиринга

В настоящее время установление пиринга и предоставление услуг передачи данных сети во многих случаях не предусматривает дополнительных проверок достоверности прав использования АИР. В случаях, когда сетевой оператор все же осуществляет такие проверки, они зачастую носят характер детективной работы с привлечением нескольких баз данных (например whois, IRR), точность данных которых небезупречна.

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

.5 Поддержка текущей практики фильтрации маршрутов

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

Настоящая практика в основном предусматривает «локальную» фильтрацию - использование сетевыми операторами IRR, в которой сети-клиенты обязаны зарегистрировать т.н. объекты маршрутов (объекты “route: ”), описывающие адресное пространство, которое анонсирует автономная система. Коллекция объектов «route:» всех автономных систем - клиентов оператора, составляет его фильтр маршрутов. Следует отметить, что хотя данный метод может быть автоматизирован, надежность IRR с точки зрения достоверности данных невысока.

Идея использования сертификатов RPKI для поддержки эффективного построения фильтров является весьма привлекательной. Во-первых, сертификаты свободны от многих недостатков упомянутых баз данных и предоставляют ряд преимуществ. Например, возможность криптографического установление достоверности данных сертификата, или документа, созданного на основе сертификата, вне контекста какой-либо базы данных. Во-вторых, криптографический характер сертификатов позволяет эффективно использовать его производные - данные, подписанные сертифицированным ключом. Этими данными, так называемыми вторичными объектами, могут быть документы ROA (Route Origination Authorisation), которые позволяют удостоверить правомерность анонсирования автономной системой определенных префиксов.

.6 Безопасность на уровне протокола BGP

Полным решением указанных проблем безопасности является определение достоверности анонсируемых маршрутов на уровне протокола BGP. Основная идея заключается в том, что на всем пути маршрута граничные маршрутизаторы связанных автономных систем «подписывают» соответствующие участки пути. В результате каждый анонсированный маршрут может быть достоверно проверен как на предмет адресного пространства и автономной системы, его анонсирующей, но также и на то, что полученный маршрут действительно был передан через автономные системы, которые в нем указаны (атрибут AS_PATH).

Данный подход получил некоторое развитие в архитектуре sBGP и soBGP, работа над которыми началась несколько лет назад. Однако в последнее время стало очевидно, что дороговизна применения (например, требуемая компьютерная мощность) и сложность внедрения (последовательное внедрение технологии не приносит ожидаемых улучшений до достижения значительной критической массы) данных технологий несоразмерны с теми преимуществами, которые они обещают (например, величина и вероятность рисков, которым они противодействуют). В силу этого работы в этом направлении не получили достаточного развития и вряд ли можно рассчитывать на практическое внедрение безопасности на уровне протокола BGP в обозримом будущем.

2.7 Основные принципы RPKI

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

Для эффективного применения данной технологии необходимо удовлетворить два основных условия:

·              обеспечить эффективную систему распространения открытых ключей и

·              обеспечить достоверную идентификацию открытого ключа с его владельцем

Данная задача успешно решается с помощью иерархической системы PKI. Основным элементом этой системы являются сертификаты. Сертификат выдается удостоверяющими центрами сертификации, УЦС, - органами, отвечающими за установление связи между субъектом сертификата и его открытым ключом. По существу, сертификат является цифровым документом, который содержит некоторый идентификатор субъекта и его открытый ключ, подписанным органом, выдавшим сертификат. Посредством сертификатов, УЦС могут сертифицировать УЦС следующего уровня и так далее, образуя, таким образом, древовидную иерархическую структуру. Эта структура является также «структурой доверия». Если вы доверяете УЦС, сертифицировавшему другой УЦС, вы также доверяете и этой организации, и т.д. То есть, третьим лицам достаточно доверять УЦС в корне данной структуры, чтобы установить достоверность любого сертификата и, таким образом, достоверно идентифицировать связь какого-либо открытого ключа с его владельцем.

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

Система RPKI основана на сертификатах стандарта X.509, содержащими критические расширения для документации АИР, стандартизованные в RFC3779. Данное расширение содержит список всех АИР (адресов IPv4 и IPv6, а также номера АС) полученных субъектом сертификата. Важно отметить, что задачей СР не является идентификация субъекта, в отличие от стандартной системы PKI. СР удостоверяет, что УЦС распределил определенные ресурсы субъекту сертификата, и данные ресурсы

перечислены в расширении сертификата. УЦС удостоверяет, что любой документ, подписанный секретным ключом, соответствующим открытому ключу сертификата, подписан законным обладателем прав использования ИР, перечисленных в сертификате. Данная концепция схематично представлена на рис. 1.

Рис.3.7.1 X.509 Сертификат Ресурсов с расширениями

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

При этом почтовый адрес отправителя не имеет значения и не влияет на достоверность описанной проверки.

.8 Cтруктура RPKI

Любая система PKI имеет иерархическую структуру с корневым сертификатом во главе. Поскольку для корневого сертификата не существует родительского УЦС, данный сертификат представляет собой самоподписанный корневой ключ. Организация, которой принадлежит корневой СР, является т.н. «точкой доверия» (Trust Anchor). Важно отметить, что как и в любой системе PKI вопрос доверия данной PKI остается за третьими лицами - пользователями системы.

Хотя в случае RPKI очевидным кандидатом на роль точки доверия является IANA, можно предположить, что некоторая организация создаст СР, охватывающий все ИР (все адресное пространство IPv4, IPv6 и АС). Эта организация теперь может предоставлять СР любым участниками системы распределения ИР, при этом выданные сертификаты будут формально отвечать требованиям удостоверения подлинности в соответствии с RFC 3779. Единственным условием успешного использования этих сертификатов является выбор данной организации пользователями СР в качестве точки доверия. Очевидным недостатком такой системы является отсутствие надежных регистрационных данных у такого УЦС, что делает процесс сертификации менее надежным.

Более реалистичным является предположение, что процесс внедрения RPKI начнется с создания нескольких точек доверия, включающих РИР, и последующим созданием единого корневого СР.

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

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

Важным последствием такого подхода является требование, что все участники RPKI являются органами выдачи сертификатов, УЦС, со всеми вытекающими последствиями: необходимостью соответствующей защищенной инфраструктуры, процессов управления ключами и т.п. Общая схема RPKI проиллюстрирована на рис. 2.

Рис. 3.8.1 Общая структура RPKI

Как и в случае традиционной PKI, в состав RPKI входят следующие компоненты:

·              Служба выдачи сертификатов (Certificate Authority, CA). Основной функцией CA является генерация и публикация сертификатов и списков ануллированных сертификатов. Эта функция по существу не меняется в RPKI, за исключением того, что СР содержат расширения документирующие распределенные АИР.

·              Служба регистрации (Registration Authority, RA) отвечает за проверку подлинности связи между субъектом сертификата и его ключом. В случае RPKI также удостоверяется, что субъект сертификата имеет права на использование АИР, перечисленных в расширении. По существу, эта функция неотличима от функции регистрационных услуг, выполняемых сегодня РИР. Отметим, что хотя предполагается, что УЦС удостоверяет субъекта СР, данное условие не является необходимым, и информация о субъекте в СР может не быть неявной (например, субъект может быть представлен цифровым идентификатором, имеющим значение только во внутренней структуре УЦС).

Эти две службы являются частью УЦС.

·              Репозитории - открытые базы данных, в которых публикуются выданные сертификаты, списки аннулированных сертификатов и, в случае RPKI, вторичные объекты.

·              Сертификаты и вторичные объекты. О структуре СР уже говорилось достаточно много. Вторичные объекты специфичны для системы RPKI и, строго говоря, не являются частью системы, а предоставляются из соображений удобства практического применения RPKI. Они являются документами, подписанными владельцем сертификата (т.е. закрытым ключом, соответствующим открытому ключу сертификата). Следует также оговориться, что ни один из вторичных объектов пока не стандартизован IETF, хотя работа над разработкой такого стандарта активно ведется.

·              Разрешение на создание маршрута (Route Origin Authorisation, ROA). Одним из наиболее проработанных вторичных объектов является ROA. Использование ROA предполагается в контексте безопасности маршрутизации. Как следует из названия, ROA является разрешением, данным сетью - владельцем прав использования АИР на анонсирование данных ресурсов Автономной Системой, указанной в ROA. В соответствии со спецификацией ROA содержит номер авторизованной АС и список IP префиксов, которые эта АС имеет разрешение анонсировать. К этому "заявлению" прилагается сертификат, описывающий соответствующие АИР, и весь объект подписан с использованием ключа, указанного в сертификате. Также отметим, что наличие ROA не означает «согласие» авторизованной АС и что указанные префиксы непременно будут анонсированы данной Автономной Системой.