Организация vpn средствами протокола pptp Постановка задачи
Предлагается организовать соединение по протоколу PPTP между двумя сетевыми узлами. При этом имитируется соединение, которое пользователь Интернет устанавливает с сервером провайдера в том случае, когда используется подключение по выделенному каналу на основе Ethernet. В результате подключения пользователю выделяется IP-адрес, который может быть известен пользователю заранее либо выделяться динамически. Динамическое выделение адресов позволяет затруднить идентификацию узла пользователя из Интернет, сделав его в какой-то степени анонимным. Кроме того, это дает возможность провайдеру более эффективно использовать выделенное ему адресное пространство.
Для имитации предполагается использовать два рабочих места. Первое рабочее место (Рис. 1 .8) имитирует PPTP-сервер Интернет-провайдера, этим сервером является компьютер под управлением ОС Windows 2000/XP. На этом же рабочем месте имитируется пользовательский компьютер, который выполняется в виде виртуальной машины VMWare с установленной Windows 2000.
Второе рабочее место (им может быть любой компьютер в локальной сети) имитирует удаленный Web-сервер.
Предполагается, что удаленный Web-сервер имеетIP-адрес 192.168.1.1, основной компьютер имеет два интерфейса — внутренний с адресом 192.168.200.1 и внешний с адресом 192.168.1.128. Пользовательский компьютер имеет внутренний адрес 192.168.200.2. Пройдя авторизацию наPPTP-сервере, пользовательский компьютер получит адрес внешней сети 192.168.1.129. В дальнейшем пользовательский компьютер будет обращаться к внешнемуWeb-серверу по протоколуHTTP.
Анализ трафика будет осуществляться в локальной сети между пользовательским компьютером и PPTP-сервером.
Рис. 1.8. Схема имитируемой VPN-сети
Защита данных на сетевом уровне
На сетевом уровне применяются два основных алгоритма: SKIPиIPSec. Различие в алгоритмах, главным образом, состоит в способе генерации и передачи ключей для шифрования содержимого пакетов.
Протокол skip
Протокол SKIP (Simple Key management for Internet Protocol – простое управление ключами для IP-протокола) разработан компанией Sun Microsystems в 1994 году. Основными его свойствами являются: аппаратная независимость, прозрачность для приложений и независимость от системы шифрования. Последнее очень важно ввиду того, что в большинстве стран мира, включая и Россию, существуют ограничения на применяемые в данной стране стандарты шифрования передаваемых данных. Таким образом, при реализации алгоритма в каждой стране может быть применен свой стандарт шифрования, в частности в России применяется симметричный алгоритм ГОСТ 28147-89. Широко известная реализация — линейка программных продуктов «Застава» российской компании «ЭЛВИС+».
В основе алгоритма лежит система открытых ключей Диффи-Хелмана. В этой системе предполагается наличие у каждого из пользователей пары ключей. Каждый пользователь системы защиты информации имеет секретный ключ Кс, известный только ему, и открытый ключКо. Открытые ключи могут быть выложены на любом общедоступном сервере.
Особенностью схемы является то, что открытый ключ Ко вычисляется из секретного ключа Кс. Вычисление осуществляется следующим образом:Ko = gKc mod n, где g и n — некоторые заранее выбранные достаточно длинные простые целые числа.
При этом если узел Jустанавливает соединение с узлом I, то они легко могут сформировать общий ключ для симметричного алгоритма шифрования данных, воспользовавшись возможностью вычисления общего для них разделяемого секретаKij:
Kij = Koj *Kci = (gKcj)*Kci mod n = (gKci)*Kcj mod n = Koi *Kcj = Kij.
Иными словами, отправитель и получатель пакета могут вычислить разделяемый секрет на основании собственного секретного ключа и открытого ключа партнера.
Полученный ключ Kij является долговременным разделяемым секретом для любой пары абонентовIиJи не может быть вычислен третьей стороной, так как секретные ключиKci иKcjв сетевом обмене не участвуют и третьей стороне не доступны.
Таким образом, разделяемый секрет не требуется передавать по линии связи для организации соединения, и он пригоден в качестве ключа для симметричного алгоритма шифрования. Однако на практике для шифрования отдельных пакетов применяют так называемый пакетный ключ, который помещают в заголовок SKIP-пакета и зашифровывают с помощью разделяемого секрета.
Далее полученный пакет дополняется новым IP-заголовком, адресами в котором являются адреса туннелирующих узлов (Рис. 1 .9).
Рис. 1.9. Схема создания SKIP-пакета
Преимуществами такого решения являются, во-первых, дополнительная защита разделяемого секрета, так как он используется для шифрования малой части трафика (только лишь пакетного ключа) и не даёт вероятному противнику материал для статистического криптоанализа в виде большого количества информации, зашифрованного им; во-вторых, в случае компрометации пакетного ключа ущерб составит лишь небольшая группа пакетов, зашифрованных им.
В том случае, когда отсутствует необходимость шифрования или подписывания данных, соответствующие элементы, а именно пакетный ключ и ЭЦП пакета, могут отсутствовать. Необходимость шифрования и/или подписывания указывается при установке параметров SKIP-соединения. Так, в примере настроекSKIP-протокола в СЗИ «Застава», приведенном на Рис. 1 .10 (в нижней части рисунка), указано на необходимость шифрования данных пакетов с использованием алгоритмаDES, требование аутентификации, т. е. применения ЭЦП пакета, отсутствует.
Рис. 1.10. Настройки параметров протокола SKIP
Технология, применяющая протокол SKIP, не свободна от ряда организационных проблем:
необходимо обеспечить безопасное хранение секретных ключей Kc и кэширования разделяемых секретов Kij;
необходимо обеспечить безопасный способ генерации и хранения (в течение относительно короткого времени жизни) пакетных ключей Kp;
обеспечить сертификацию открытых ключей.
Проблема обеспечения сертификации открытых ключей возникает вследствие возможности проведения известной атаки «man-in-the-middle». Идея данной атаки не нова и состоит в следующем. Атакующая сторона находится внутри сети, где обмениваются информацией пользователи i и j. Цель атаки — хакер должен предложить от своего имени пользователю i «поддельный» открытый ключ Koj, а пользователю j, соответственно, «поддельный» ключ Koi. Данное действие вполне возможно вследствие того, что открытые ключи пользователей должны располагаться в общедоступном месте, где обязательно должна быть разрешена запись файлов (иначе никто не сможет поместить туда свой открытый ключ). После того, как подмена ключей осуществится, третья сторона сможет принимать весь шифрованный трафик от одного абонента, расшифровывать, читать, шифровать под другим ключом и передавать другому абоненту. Иными словами, весь зашифрованный трафик пойдет через «человека в центре».
В качестве защиты от подобной атаки применяется сертификация открытых ключей. Смысл сертификации заключается в создании электронного документа — сертификата открытого ключа. В данном документе кроме самого электронного ключа должна содержаться информация о том, кому данный сертификат выдан, каков срок его действия, кем выдан и, самое важное, должна присутствовать ЭЦП открытого ключа, сгенерированная организацией, выдавшей сертификат. Зная эту организацию, любой пользователь, желающий проверить подлинность сертификата, может получить ее открытый ключ и проверить ЭЦП, хранящуюся в сертификате.
Таблица 1.2
Пример сертификата открытого ключа
|
Поле |
Пример значения |
|
Версия сертификата |
1, 2, 3 |
|
Серийный номер сертификата |
40:00:00:00:00:00:00:ab:38:1e:8b:e9:00:31:0c:60 |
|
Идентификатор алгоритма ЭЦП |
ГОСТ Р 34.10-94 |
|
Имя издателя сертификата |
C=RU, ST=Moscow,O=PKI, CN=Certification Authority |
|
Срок действия сертификата |
Действителен с: Ноя 2 06:59:00 1999 GMT Действителен по: Ноя 6 06:59:00 2004 GMT |
|
Имя владельца сертификата |
C=RU, ST=Moscow, O=PKI, CN=Sidorov |
|
Открытый ключ владельца |
тип ключа: Открытый ключ ГОСТ длина ключа: 1024 значение: AF:ED:80:43..... |
|
Уникальный идентификатор издателя |
|
|
Уникальный идентификатор владельца |
|
|
ЭЦП Центра сертификации |
|
Предполагается, что распределением открытых ключей должна заниматься заслуживающая доверия сторона. В зарубежной литературе для подобного органа используется термин CertificateAuthority(«Нотариус»), в российских документах он именуется Центром сертификации (ЦС).
Как уже говорилось, сертификат — файл определенного формата. Наибольшее распространение получил формат сертификата, установленный Международным телекоммуникационным союзом — ITU Rec. X.509. Электронный сертификат стандарта X.509 содержит: имя издателя сертификата; имя владельца сертификата; открытый ключ владельца; срок действия открытого (секретного) ключа издателя и владельца; дополнения; списки отозванных сертификатов.
Пример сертификата открытого ключа в формате X.509 приведен в табл. 1.2.
Протокол SKIPсодержит механизмы защиты от следующих видов атак.
Атаки из сети на сервисы ОС и на прикладные программы, подключение неавторизованных узлов к сети. Механизм: в защищаемую сеть или компьютер пропускаются пакеты только от владельца разделяемого секрета.
Прослушивание трафика. Механизм: передаваемые пакеты могут быть прочитаны только владельцем разделяемого секрета.
Повторение пакетов. Механизм: в аутентифицирующую часть заголовка SKIP-пакета перед вычислением криптосуммы пакета подставляется, в частности, текущее время.
Подмена/маскарад. Механизм: все пакеты и их адресная информация аутентифицируются и защищаются от подделки криптосуммой по пакету, разделяемому секрету и текущему времени.
Перехват сессий. Механизм: в сеть может войти только владелец разделяемого секрета.
Атака Man-in-the-middle. Механизм: подписанные ЦС сертификаты.
Анализ топологии сети. Механизм: топология сети полностью скрывается туннелированием всех исходящих из сети пакетов.
Криптоанализ. Механизм: большая длина пакетных ключей (до 256 бит); частая смена пакетных ключей – через каждые 5-10 IP- пакетов; отсутствие данных для криптоанализа разделяемого секрета — он не используется непосредственно для криптообработки.
Атака: отказ в обслуживании. Механизм: нейтрализуется для всех DoS атак, ведущихся на уровне выше чем IP. В сеть пропускаются пакеты только от владельца разделяемого секрета.
Вместе с тем, защита от ряда атак протоколом не реализуется:
осуществляется защита лишь части трафика, например направленного в удаленный филиал. Остальной трафик (например, к Web-серверам) проходит через VPN-устройство без обработки;
нет защиты от действий пользователей, имеющих санкционированный доступ в корпоративную сеть.