Yazov_ITKS

Частные виртуальные сети (VPN)

Протоколы шифрования TLS,SOCKS

VPN прикладного уровня

Протоколы Secure HTTP (SHTTP), Secure MIME (SMIME)

Рис. 5.31. Классификация частных виртуальных сетей

551

Рис. 5.32. Внутрикорпоративная частная виртуальная сеть («Client/Server VPN»)

552

Рис. 5.33. Межкорпоративная частная виртуальная сеть («Intranet VPN»)

553

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

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

Рассмотрим варианты создания VPN на примере протокола PPTP [55].

Протокол PPTP (Point-to-PointTunnelingProtocol)

предназначен для создания защищенного канала при доступе удаленных пользователей. С помощью этого протокола фактически имитируется нахождение компьютера пользователя во внутренней сети путем туннелирования пакетов сообщений. Данные по туннелю переносятся с помощью стандартного протокола удаленного доступа PPP (Point-to-Point Protocol), который используется только для связи с сервером провайдера. В технологии создания защищенного туннеля по протоколу PPTP предусматривается как аутентификация удаленного пользователя, так и зашифрованная передача данных.

Впротоколе PPTP определены три схемы его применения: первая – прямое соединение (рис. 5.35) и две другие – по телефонной линии (рис. 5.36) через провайдера.

555

личия заключаются лишь в реализуемых по этим протоколам процедурах создания защищенных туннелей, которые достаточно подробно описаны, например, в [55]. Так, для протокола L2TP имеет место следующий порядок установления взаимодействия.

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

3CHAP (англ.ChallengeHandshakeAuthenticationProtocol) — широко распространённый алгоритм проверки подлинности, предусматривающий передачу не самого пароля пользователя, а косвенных сведений о нём. При использовании CHAP сервер удалённого доступа отправляет клиенту строку запроса. На основе этой строки и пароля пользователя клиент вычисляетхеш-кодMD5(англ. MessageDigest-5) и передаёт его серверу. Сервер, которому доступен пароль пользователя, выполняет те же самые вычисления и сравнивает результат с хешкодом, полученным от клиента. В случае совпадения учётные данные клиента удалённого доступа считаются подлинными, при этом пароль никогда не пересылается по каналу, что значительно увеличивает безопасность процесса аутентификации

557

криптозащита должна выполняться в соответствии с про-

токолом IPSec (InternetProtocolSecurity). В этом случае па-

кеты L2TP инкапсулируются в UDP-пакеты, которые передаются между концентратором доступа провайдера и сервером локальной сети через IPSec-туннель. Для этого задействуется UDP-порт 1701.

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

В соответствии с протоколом IPSec4 архитектура средств безопасности информационного обмена разделяется на три уровня (рис. 5.37) [55].

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

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

Протокол ESP обеспечивает криптографическое закрытие передаваемых пакетов сообщений и выполнение всех функций протокола AH.

4 Протокол IPSecпредставляет собой стек нескольких протоколов

558

Рис. 5.37. Архитектура средств безопасности протокола IPSec

559

Использование в IPSec двух различных протоколов (AH и ESP) обусловлено практикой, применяемого во многих странах ограничения экспорта или импорта криптосредств. Каждый из этих протоколов может использоваться самостоятельно. Протоколы АН и ESP не зависят от конкретных криптографических алгоритмов, могут использоваться любые методы аутентификации, типы ключей (симметричные и асимметричные), алгоритмы шифрования и распределения ключей. Например, в каждой стране могут применяться свои алгоритмы, соответствующие национальным стандартам.

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

(SA – Security Association) и только затем использовать элементы этого контекста, такие как алгоритмы и ключи.

Роль фундамента в архитектуре IPSec выполняет так называемый домен интерпретации (DomainofInterpretation), являющийся, по сути, базой данных, хранящей сведения об используемых в IPSec протоколах и алгоритмах, их параметрах, протокольных идентификаторах и т.д. В IPSec могут использоваться протоколы и алгоритмы. Которые изначально не разрабатывались для этой архитектуры. Поэтому возникла необходимость в домене интерпретации. Для того чтобы в качестве алгоритмов аутентификации и шифрования в протоколах АН и ESP можно было использовать, алгоритмы, соответствующие национальным стандартам, необходимо как минимум зарегистрировать их в домене интерпретации. В настоящее время для протоко-

560