Файл: Федеральное государственное бюджетное образовательное учреждение высшего образования санктпетербургский.pdf

указаны конкретные методы аутентификации и шифрования. В отличие от
PPTP, L2F позволяет использовать не только PPP, но и другие протоколы, например SLIP, для удаленного доступа к своему интернет-провайдеру.
Интернет-провайдеры не должны настраивать адреса и проверять подлинность при создании безопасных каналов по глобальной сети. Кроме того, различные протоколы сетевого уровня могут использоваться для передачи данных через защищенный туннель, а не только через IP, как в
PPTP. Протокол L2F стал компонентом операционной системы Cisco IOS и поддерживается на всех выпускаемых устройствах взаимодействия и удаленного доступа.
Протоколы PPTP и L2F были представлены на рассмотрение Целевой группы по проектированию Интернета (IETF), и в 1996 году соответствующие комитеты приняли решение объединить их.
Результирующий протокол, включавший лучшие из PPTP и L2F, назывался
Layer-2 Tunneling Protocol (L2TP). Поддерживается компаниями Cisco,
Microsoft, 3Com, Ascend и многими другими производителями.
Гибридный протокол L2TP сочетает в себе лучшие функции вышеуказанных протоколов и добавляет новые функции. Протокол L2TP может поддерживать любые протоколы высокого уровня и обеспечивает управление потоком данных, удаленную аутентификацию пользователей, безопасную установку виртуальных соединений, а также позволяет открывать несколько туннелей между пользователями, каждый из которых администратор может выделить приложению. Как и предыдущие протоколы канального уровня, спецификация
L2TP не описывает методы аутентификации и шифрования. Таким образом, протокол L2TP является расширением протокола PPP с помощью функций аутентификации удаленных пользователей, установления безопасного виртуального соединения и управления потоком данных. Протоколы CHAP/PAP или другие могут использоваться для аутентификации в корпоративной сети до начала сеанса PPP. Гарантированная доставка информации в сеансе обеспечивается нумерацией защищенных кадров в соединении, восстановлением потерянных и искаженных кадров. Протокол L2TP предусматривает три этапа установления соединения: установление соединения с удаленным сервером LAN; Аутентификация пользователя;
Конфигурирование безопасного туннеля.
Протоколы защищенных туннелей на канальном уровне не зависят от протоколов сетевого уровня модели OSI, над которыми работают локальные сети, входящие в состав виртуальных сетей. Они позволяют создавать безопасные каналы для связи между удаленными компьютерами и локальными сетями, работающими по разным протоколам сетевого уровня.
Пакеты этих протоколов криптографически защищены и инкапсулируются в
IP-пакеты Интернета, которые транспортируются к месту назначения, образуя безопасные виртуальные каналы. Многопротокольность – является основным преимуществом протоколов инкапсуляции канального уровня.

Однако формирование криптографически защищенных туннелей между
«открытыми» контурами взаимодействующих систем на основе протоколов канального уровня приводит к трудностям конфигурирования и поддержки виртуальных каналов связи. Кроме того, в протоколах формирования безопасных туннелей на канальном уровне не указаны конкретные методы шифрования, аутентификации, проверки целостности каждого передаваемого пакета, а также средства управления ключами.
Из вышесказанного можно сделать вывод, что протоколы для создания безопасных виртуальных линий связи на канальном уровне лучше всего подходят для защиты связи при удаленном доступе к LAN.
4.2.5.2. Протоколы VPN сетевого уровня модели OSI
Спецификация, описывающая стандартные методы для всех компонентов и функций защищённых виртуальных сетей, представляет собой протокол Internet Protocol Security (IPsec), соответствующий сетевому уровню модели OSI и являющийся частью шестой версии протокола IP-IPv6.
IPsec иногда еще называют протоколом туннелирования третьего уровня
(Layer-3 Tunneling). IPsec предоставляет стандартные методы проверки подлинности пользователей или компьютеров при инициировании туннеля, стандартные методы шифрования конечных точек туннеля, создания и проверки цифровой подписи, а также стандартные методы обмена криптографическими ключами между конечными точками и управления ими.
Этот гибкий стандарт предлагает несколько способов выполнения каждой задачи. Методы, выбранные для одной задачи, обычно не зависят от методов для других задач. Для функций аутентификации IPsec поддерживает цифровые сертификаты популярного стандарта X.509.
Туннель IPsec между двумя локальными сетями может поддерживать несколько отдельных каналов передачи данных, что приводит к тому, что этот тип приложения обладает преимуществом масштабирования по сравнению с технологией уровня 2. IPsec может использоваться совместно с
L2TP. Вместе эти два протокола обеспечивают наивысший уровень гибкости в защите виртуальных каналов. Дело в том, что спецификация IPsec ориентирована на IP и, таким образом, бесполезна для трафика любых других протоколов сетевого уровня. Протокол L2TP не зависит от транспортного уровня, который может быть использован в гетерогенных сетях.
Архитектура семейства протоколов IPsec (рис.4.2) включает в себя:
– протокол управления ключами (Internet Security Association Key
Management Protocol, ISAKMP [RFC 2408] и протокол обмена ключевой информацией IKE (Internet Key Exchange) [RFC 2409];
– протокол аутентифицирующего заголовка (Authentication Header, АН);
– протокол инкапсулирующей защиты содержимого (Encapsulating
Security Payload, ESP).
– домен интерпретации (Domain of Interpretation, DOI), который доопределяя структуру блоков данных и задавая правила именования информации, определяющей безопасность (политики безопасности,

криптографические режимы и алгоритмы), связывает IKE с протоколом, защита которого обеспечивается.
Протокол обмена ключевой информацией IKE. Алгоритмическая независимость протоколов АН и ESP требует предварительного согласования набора применяемых алгоритмов и их параметров, поддерживаемых взаимодействующими сторонами. Эту функцию на фазе установления соединения в современной архитектуре IPsec реализует протокол обмена ключевой информацией IKE (Internet Key Exchange) [RFC 2407, 2408, 2409].
Протокол IKE принято рассматривать как расширение ISAKMP [RFC 2408], основой которого он является, хотя отдельные идеи заимствованы у Oakley
(The Oakley Key Determination Protocol [RFC 2412]) и SKEME (A Versatile
Secure Key Exchange Mechanism for Internet).
Верхний уровень
Средний уровень
Нижний уровень
Рис.4.2. Архитектура семейства протоколов IPsec
Согласно протоколу IKE, при формировании безопасного виртуального туннеля взаимодействующие стороны должны разработать общий контекст безопасности (Security Association, SA) и только затем использовать элементы этого контекста [31]. Контекст безопасности SA для любого протокола представляет собой согласованный набор параметров, определяющих услуги и механизмы, предоставляемые этим протоколом для защиты трафика в сеансе связи, копия которого доступна каждой из сотрудничающих сторон. Контекст безопасности по существу представляет собой общее согласованное состояние отправителя и получателя, которое, в частности, определяет предоставляемые услуги, используемые криптографические алгоритмы и ключи в сеансе. Таким образом, основной целью IKE является автоматическое обеспечение безопасности согласования контекста безопасности для семейства протоколов IPsec между участниками мультимедийного сеанса.
Протокол согласования контекста безопасности и управления ключами (IKE)
Протокол аутентифицирую щего заголовка
(АН)
Протокол инкапсулирующ ей защиты содержимого
(ESP)
Алгоритмы согласование контекстов параметров и управления ключами безопасности
Алгоритмы аутентификации
Алгоритмы шифрования
Домен интерпретации
(DOI)

В работе IKE можно выделить две основные фазы (phases). На первой фазе работы IKE происходит согласование обязательных параметров контекста безопасности
IKE
(IKE
SA), выполняется взаимная аутентификация участников, и устанавливаются сеансовые ключи. Контекст безопасности IKE SA определяет, как именно будет обеспечиваться защита последующего трафика. Для семейства IPsec такими контекстами безопасности являются ESP SA и AH SA (общим названием этих контекстов безопасности является IPsec SA).
После завершения первой фазы и установления контекста безопасности
IKE SA между инициатором и ответчиком любой из участников обмена может инициировать вторую фазу. На втором этапе фактически создается контекст безопасности IKE SA, который определяет способ защиты трафика в сеансе. Обязательные параметры IKE SA (алгоритм шифрования, алгоритм вычисления хэш-функции, метод аутентификации и группа Диффи-
Хеллмана, определяющая параметры ключевого материала для обмена
Диффи-Хеллманом) составляют защитный набор. На втором этапе могут выполняться обмены быстрым режимом, новым групповым режимом и информационным режимом. Основное различие между первой и второй фазами состоит в том, что конечные узлы
IKE-соединения аутентифицируются в течение первой фазы, в то время как вторая фаза аутентифицируется для пользователей или приложений. После завершения первой фазы и установления контекста безопасности IKE SA между отправителем и получателем любой из участников обмена может инициировать вторую фазу. Во второй фазе могут выполняться обмены быстрого режима, режима новой группы, а также информационного режима.
В ходе второй фазы согласуются, модифицируются и удаляются контексты безопасности
(которых может быть несколько) для протокола, использующего IKE.
Протокол
аутентифицирующего
заголовка
АН
и
протокол
инкапсулирующей защиты содержимого ESP. Как упоминалось выше, при формировании защищенного виртуального канала взаимодействующие стороны должны разработать общий контекст безопасности SA и только затем использовать элементы этого контекста, такие как алгоритмы и ключи.
Для семейства IPsec такими контекстами безопасности являются ESP SA и
AH SA (общее название этих контекстов безопасности - IPsec SA).
Протокол заголовка аутентификации AN обеспечивает аутентификацию источника данных, проверку его целостности и подлинности после приема, а также защиту от навязывания повторяющихся сообщений.
Протокол инкапсуляции содержимого
ESP обеспечивает криптографическое закрытие пакетов передаваемых сообщений, а также выполняет все функции протокола AS. ESP может поддерживать функции шифрования и аутентификации/целостности в любой комбинации, то есть либо группу функций, только аутентификацию/целостность, либо только шифрование.

Протоколы АН и ESP не зависят от конкретных криптографических алгоритмов. Могут использоваться любые методы аутентификации, типы ключей (симметричные или несимметричные), алгоритмы шифрования и выделения ключей. Например, каждая страна может использовать свой собственный алгоритм, соответствующий национальным стандартам.
В настоящее время регистрируются два значения аутентификации для протоколов AS и ESP - HMAC-MD5 (Hashed Message Authentication Code -
Message Digest версии 5) и HMAC-SHA1 (Hashed Message Authentication Code
- Secure Hash Algorithm версии 1). Эти алгоритмы являются алгоритмами аутентификации секретного ключа. Если секретный ключ известен только передающей и принимающей сторонам, он обеспечивает аутентификацию источника данных, а также целостность пакетов, передаваемых между двумя сторонами. Алгоритм по умолчанию определяет алгоритм HMAC-MD5.
Для ESP зарегистрировано семь алгоритмов шифрования. Стандарт шифрования данных, как и алгоритм НМАС-MD5, является стандартом по умолчанию для совместимости с IPsec. В качестве альтернативы DES определены алгоритмы Triple DES, CAST-128, RC5, IDEA, Blowfish и
ARCFour.
Протоколы AH и ESP поддерживают два режима:
а) туннельный режим. IP-пакеты защищены полностью, включая заголовки. Это главный режим. В этом режиме каждый обычный IP-пакет помещается полностью в криптографически защищенную форму в конверте
IPsec, который, в свою очередь, инкапсулируется в другой IP-пакет.
Туннельный режим обычно реализуется на выделенных шлюзах безопасности, которые могут быть маршрутизаторами или брандмауэрами.
Между этими шлюзами формируются безопасные туннели IPsec.
Туннелирование
IP-пакетов полностью прозрачно для конечных пользователей. В оконечных системах туннельный режим может использоваться для поддержки удаленных и мобильных пользователей. В этом случае компьютеры этих пользователей должны иметь программное обеспечение, реализующее туннель
IPsec.
Протокол заголовка аутентификации AN [RFC1826], [RFC1827] обеспечивает аутентификацию источника данных, проверку его целостности и подлинности после приема и защиту от навязывания повторяющихся сообщений. В основе обеспечения целостности и аутентификации данных лежит шифрование с помощью односторонней функции (one-way function), называемой также хэш-функцией
(hash function);
б) транспортный режим. Только содержимое исходного IP-пакета помещается в конверт IPsec в криптографически защищенной форме, и исходный IP-заголовок добавляется к принятому конверту. Соответственно, в транспортном режиме заголовок IPsec помещается между заголовками сети
(IP) и транспорта (TCP или UDP) обычного IP-пакета. Транспортный режим быстрее туннельного и предназначен для использования на терминальных системах. Это может использоваться для поддержки удаленных и мобильных пользователей и защиты информационных потоков в локальных сетях. В

транспортном режиме IPsec помещает только содержимое защищаемого IP- пакета и добавляет исходный IP-заголовок к полученному конверту.
Заголовки блоков протоколов AN и ESP расположены в транспортном режиме после заголовка IP-пакета источника и перед заголовками протокола верхнего уровня, а в туннельном режиме - после заголовка внешнего IP- пакета и перед заголовком исходного IP-пакета (рис.4.3).
Транспортный режим
Туннельный режим
[IPисх.][AH][сервисный блок TCP/UDP]
[IPвнеш.][AH][IPисх.][ сервисный блок
TCP/UDP]
[IPисх][ESP][ сервисный блок TCP/UDP]
[IPвнеш.][ESP][IPисх.][ сервисный блок
TCP/UDP]
[IPисх.][AH][ESP][ сервисный блок
TCP/UDP]
Рис.4.3. Расположение полей заголовков протокольных блоков в транспортном и туннельном режимах
Сравнение различных режимов для протоколов АН и ESP представлено в табл. 4. 3.
Таблица 4.3.
Сравнение различных режимов для протоколов АН и ESP
Протокол
Транспортный режим
Туннельный режим
АН
Идентифицирует протокол- пассажир IP, а также отдельные части заголовка IP и заголовка расширений IPv6
Идентифицирует весь внутренний пакет IP (заголовок и протокол-пассажир внутреннего пакета IP), а также отдельные части внешнего заголовка IP и внешних заголовков расширений
IPv6
ESP
Шифрует протокол-пассажир IP и все заголовки расширений IPv6, следующие за заголовком ESP
Шифрует внутренний пакет IP
ESP с аутентификацией
Шифрует протокол-пассажир IP и все заголовки расширений Ipv6, следующие за заголовком ESP.
Идентифицирует протокол- пассажир IP и заголовок IP.
Шифрует внутренний пакет IP.
Идентифицирует внутренний пакет IP.
Протоколы АН и ESP могут комбинироваться разными способами. Если используется транспортный режим, то аналогично тому, как в рамках ESP аутентификация идет следом за шифрованием, протокол АН должен применяться после протокола ESP. В туннельном режиме протоколы АН и
ESP применяются к разным вложенным пакетам и, кроме того, в данном режиме допускается многократная вложенность туннелей с различными начальными и/или конечными точками. Поэтому в случае туннельного режима число возможных комбинаций по совместному использованию протоколов АН и ESP существенно больше.

4.2.5.3. Протоколы VPN сеансового уровень модели OSI
Безопасные виртуальные каналы также могут генерироваться на сеансовом уровне модели OSI. Для этого применяются так называемые
«посредники каналов» (circuit proxy). Посредник работает над транспортным уровнем, шифрует и передает трафик из защищенной сети в общедоступный
Интернет для каждого сокета по отдельности. При приеме выполняется обратная процедура. IP-сокет идентифицируется комбинацией TCP- соединения и определенного порта или указанного UDP-порта.
SSL/TLS (Secure Sockets Layer/Transport Layer Security), разработанный
Netscape Communications, является наиболее популярным протоколом для шифрования на уровне сеанса. Этот протокол создает безопасный туннель между конечными точками виртуальной сети, обеспечивая взаимную аутентификацию абонентов, а также конфиденциальность, подлинность и целостность данных, циркулирующих через туннель. Ядром протокола
SSL/TLS является технология комплексного использования асимметричных и симметричных криптосистем организации RSA Data Security.
Для стандартизации связи клиент-серверных приложений TCP/IP через сервер-посредник (брандмауэр) IETF утвердил протокол, называемый
SOCKS. Пятая версия этого протокола (SOCKS5 [RFC1928]) используется для стандартизированной реализации канальных посредников в настоящее время. SOCKS5 поддерживает приложения, требующие контроля над направлениями информационных потоков и настройки условий доступа в зависимости от атрибутов пользователя и/или информации.
Согласно протоколу SOCKS5, клиентский компьютер устанавливает аутентифицированный сеанс с прокси-сервером. Использование этого прокси
- единственный способ взаимодействия через брандмауэр. Посредник, в свою очередь, проводит любые операции, запрошенные клиентом. Поскольку брокер знает о трафике на уровне сеанса (сокета), он может осуществлять тщательный контроль, например, блокировать конкретные пользовательские приложения, если у них нет необходимых полномочий.
В отличие от виртуальных сетей, защищенных на сеансовом уровне модели OSI, виртуальные сети, защищенные на уровне канала или сетевом уровне, обычно просто открывают или закрывают канал для всего трафика в аутентифицированном туннеле. Это может быть проблемой, если ЛВС на другом конце туннеля не является надежной. Кроме того, установленные туннели канального и сетевого уровней работают одинаково в обоих направлениях, а защищенные сеансовым уровнем виртуальные сети обеспечивают независимое управление передачей в каждом направлении.
Виртуальные сети прокси-канала IPsec ориентированы на IP. Если IPsec по существу различает защищенные виртуальные каналы между различными парами взаимодействующих сторон, протокол SOCKS5 предоставляет защищенные туннели для каждого приложения и сеанса по отдельности.
Аналогично протоколам туннелирования IPsec и канального уровня,