Дипломная работа
Построение локальной вычислительной сети на основе VPN технологий
РЕФЕРАТ
Предмет дослідження - методи побудування захищеної локальної
обчислювальної мережі на основі технології VPN.
Мета курсової роботи - систематизація, поглиблення й активне
застосування знань отриманих у лекційному курсі, а також на практичних та
лабораторних заняттях, вивчення сучасних методів та протоколів для побудови
локально обчислювальних мереж на основі техногології VPN.
Ключові слова: VPN, класифікація, побудова, ПРОТОКОЛ, БЕЗПЕКА,
PPTP, IPSEC.
РЕФЕРАТ
Предмет исследования - методы создания защищенной локальной
вычислительной сети на основ технологии VPN.
Цель курсовой работы - систематизация, углубление и активное
применение знаний полученных в лекционном курсе, а также на практических и
лабораторных занятиях, изучение современных методов и протоколов для
постороения локальной вычислительной сети на основе технологии VPN.
Ключевые
слова:
VPN,
КЛАССИФИКАЦИЯ,
ПРОТОКОЛ, БЕЗОПАСНОСТЬ, PPTP, IPSEC.
ПОСТОРОЕНИЕ,
THE ABSTRACT
of research - methods for creating secure network based on VPN
technology.aim of the course work - organizing, deepening and active application of
knowledge obtained in lectures, practical and laboratory classes, the study of modern
methods and protocols for construction the corporate network technology based on
VPN.: VPN, CLASSIFICATION, CONSTRUCTION, PROTOCOL, SECURITY,
PPTP, IPSEC.
ВВЕДЕНИЕ
В последнее время в мире телекоммуникаций наблюдается повышенный
интерес к виртуальным частным сетям. Это обусловлено необходимостью
снижения расходов на содержание корпоративных сетей за счет более дешевого
подключения удаленных офисов и удаленных пользователей через сеть Internet.
Действительно, при сравнении стоимости услуг по соединению нескольких
сетей через Internet, например, с сетями Frame Relay можно заметить
существенную разницу в стоимости. Однако необходимо отметить, что при
объединении сетей через Internet, сразу же возникает вопрос о безопасности
передачи данных, поэтому возникла необходимость создания механизмов
позволяющих обеспечить конфиденциальность и целостность передаваемой
информации. Сети, построенные на базе таких механизмов, и получили
название VPN.
Нередко людям нужен доступ к своей информации, хранящейся на их
домашнем компьютере, или на компьютере фирмы. Эту проблему можно
решить, организовав удалённый доступ к нему с помощью модема и
телефонной линии. Использование телефонной линии имеет свои особенности.
Недостатки этого решения в том, что звонок с другой страны стоит немалых
денег. Есть и другое решение под названием VPN. Преимущества технологии
VPN в том, что организация удалённого доступа делается не через телефонную
линию, а через Internet, что намного дешевле и лучше. По моему мнению,
технология VPN имеет перспективу на широкое распространение по всему
миру.
1. ПРОБЛЕМАТИКА ПОСТРОЕНИЯ VPN СЕТЕЙ
.1 АНАЛИЗ УГРОЗ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
Под угрозой понимают потенциально возможное событие, которое может
привести к нанесению ущерба чьим-либо интересам. В дальнейшем под угрозой
безопасности АС обработки информации будем понимать возможность
воздействия на АС, которое прямо или косвенно может нанести ущерб ее
безопасности.
В настоящее время известен обширный перечень угроз информационной
безопасности АС, содержащий сотни позиций.
Рассмотрение
возможных
угроз
информационной
безопасности
проводится с целью определения полного набора требований к разрабатываемой
системе зашиты.
Перечень угроз, оценки вероятностей их реализации, а также модель
нарушителя
служат
основой
для
анализа риска
реализации
угроз и
формулирования требований к системе защиты АС. Кроме выявления
возможных угроз, целесообразно проведение анализа этих угроз на основе их
классификации по ряду признаков. Каждый из признаков классификации
отражает одно из обобщенных требований к системе защиты. Угрозы,
соответствующие каждому признаку классификации, позволяют детализировать
отражаемое этим признаком требование.
Необходимость классификации угроз информационной безопасности АС
обусловлена тем, что хранимая и обрабатываемая информация в современных
АС подвержена воздействию чрезвычайно большого числа факторов, в силу
чего становится невозможным формализовать задачу описания полного
множества угроз. Поэтому для защищаемой системы обычно определяют не
полный перечень угроз, а перечень классов угроз [1].
Классификация возможных угроз информационной безопасности АС
может быть проведена по следующим базовым признакам.
. По природе возникновения:
естественные угрозы, вызванные воздействиями на АС объективных
физических процессов или стихийных природных явлений;
искусственные угрозы безопасности АС, вызванные деятельностью
человека.
. По степени преднамеренности проявления:
угрозы, вызванные ошибками или халатностью персонала, например
некомпетентное использование средств защиты, ввод ошибочных данных;
угрозы преднамеренного действия, например действия злоумышленников.
. По непосредственному источнику угроз:
природная среда, например стихийные бедствия, магнитные бури и пр.;
человек, например вербовка путем подкупа персонала, разглашение
конфиденциальных данных и т. п.;
санкционированные
программно-аппаратные
средства,
например
удаление данных, отказ в работе ОС;
несанкционированные
программно-аппаратные
средства,
например
заражение компьютера вирусами с деструктивными функциями.
. По положению источника угроз:
вне контролируемой зоны АС, например перехват данных, передаваемых
по каналам связи, перехват побочных электромагнитных, акустических и других
излучений устройств;
в
пределах
подслушивающих
контролируемой
устройств,
зоны
хищение
АС,
например
распечаток,
записей,
применение
носителей
информации и т. п.;
непосредственно в АС, например некорректное использование ресурсов
АС.
. По степени зависимости от активности АС:
независимо от активности АС, например вскрытие шифров криптозащиты
информации;
только в процессе обработки данных, например угрозы выполнения и
распространения программных вирусов.
. По степени воздействия на АС:
пассивные угрозы, которые при реализации ничего не меняют в структуре
и содержании АС, например угроза копирования секретных данных;
активные угрозы, которые при воздействии вносят изменения в структуру
и содержание АС, например внедрение троянских коней и вирусов.
. По этапам доступа пользователей или программ к ресурсам АС:
угрозы, проявляющиеся на этапе доступа к ресурсам АС, например
угрозы несанкционированного доступа в АС;
угрозы, проявляющиеся после разрешения доступа к ресурсам АС,
например угрозы несанкционированного или некорректного использования
ресурсов АС.
. По способу доступа к ресурсам АС:
угрозы, осуществляемые с использованием стандартного пути доступа к
ресурсам АС, например незаконное получение паролей и других реквизитов
разграничения доступа с последующей маскировкой под зарегистрированного
пользователя;
угрозы осуществляемые с использованием скрытого нестандартного пути
доступа к ресурсам АС, например несанкционированный доступ к ресурсам АС
путем использования недокументированных возможностей ОС.
.
По
текущему
месту
расположения
информации,
хранимой
и
обрабатываемой в АС:
угрозы доступа к информации, находящейся на внешних запоминающих
устройствах,
например
несанкционированное
копирование
секретной
информации с жесткого диска;
угрозы доступа к информации, находящейся в оперативной памяти,
например чтение остаточной информации из оперативной памяти, доступ к
системной области оперативной памяти со стороны прикладных программ;
угрозы доступа к информации, циркулирующей в линиях связи, например
незаконное подключение к линиям связи с последующим вводом ложных
сообщений
или
модификацией
передаваемых
сообщений,
незаконное
подключение к линиям связи с целью прямой подмены законного пользователя
с последующим вводом дезинформации и навязыванием ложных сообщений;
угрозы доступа к информации, отображаемой на терминале или
печатаемой на принтере, например запись отображаемой информации на
скрытую видеокамеру.
Как уже отмечалось, опасные воздействия на АС подразделяют на
случайные и преднамеренные. Анализ опыта проектирования, изготовления и
эксплуатации АС показывает, что информация подвергается различным
случайным воздействиям на всех этапах цикла жизни и функционирования АС.
Причинами случайных воздействий при эксплуатации АС могут быть:
аварийные ситуации из-за стихийных бедствий и отключений
электропитания;
отказы и сбои аппаратуры;
ошибки в программном обеспечении;
ошибки в работе обслуживающего персонала и пользователей;
помехи в линиях связи из-за воздействий внешней среды.
Ошибки в ПО являются распространенным видом компьютерных
нарушений. ПО серверов, рабочих станций, маршрутизаторов и т. д. написано
людьми, поэтому оно практически всегда содержит ошибки. Чем выше
сложность подобного ПО, тем больше вероятность обнаружения в нем ошибок
и уязвимостей. Большинство из них не представляют никакой опасности,
некоторые же могут привести к серьезным последствиям, таким как получение
злоумышленником контроля над сервером, неработоспособность сервера,
несанкционированное использование ресурсов (использование компьютера в
качестве плацдарма для атаки и т. п.). Обычно подобные ошибки устраняются с
помощью пакетов обновлений, регулярно выпускаемых производителем ПО.
Своевременная установка таких пакетов является необходимым условием
безопасности информации.
Преднамеренные угрозы связаны с целенаправленными действиями
нарушителя. В качестве нарушителя может быть служащий, посетитель,
конкурент, наемник и т. д. Действия нарушителя могут быть обусловлены
разными мотивами: недовольством служащего своей карьерой, сугубо
материальным интересом (взятка), любопытством, конкурентной борьбой,
стремлением самоутвердиться любой ценой и т. п.
Несанкционированный
доступ
-
наиболее
распространенный
и
многообразный вид компьютерных нарушений. Суть НСД состоит в получении
пользователем (нарушителем) доступа к объекту в нарушение правил
разграничения
доступа,
установленных
в
соответствии
с
принятой
в
организации политикой безопасности. НСД использует любую ошибку в
системе защиты и возможен при нерациональном выборе средств защиты, их
некорректной установке и настройке. НСД может быть осуществлен как
штатными средствами АС, так и специально созданными аппаратными и
программными средствами.
Основные каналы НСД, через которые нарушитель может получить
доступ к компонентам АС и осуществить хищение, модификацию и/или
разрушение информации:
штатные каналы доступа к информации (терминалы пользователей,
оператора,
администратора
документирования
информации;
системы;
каналы
средства
связи)
при
отображения
их
и
использовании
нарушителями,
а
также
законными
пользователями
вне
пределов
их
полномочий;
технологические пульты управления;
линии связи между аппаратными средствами АС;
побочные электромагнитные излучения от аппаратуры, линий связи, сетей
электропитания и заземления и др.
Из всего разнообразия способов и приемов НСД остановимся на
следующих распространенных и связанных между собой нарушениях:
перехват паролей - «маскарад»;
незаконное использование привилегий.
Перехват
паролей
осуществляется
специально
разработанными
программами. При попытке законного пользователя войти в систему
программа-перехватчик имитирует на экране дисплея ввод имени и пароля
пользователя, которые сразу пересылаются владельцу программы-перехватчика,
после чего на экран выводится сообщение об ошибке и управление
возвращается ОС. [1].
1.2 ОСНОВНЫЕ ПОНЯТИЯ И ФУНКЦИИ СЕТИ VPN
VPN - технология позволяющих обеспечить одно или несколько сетевых
соединений (логическую сеть) поверх другой сети (например, Интернет).
Несмотря на то, что коммуникации осуществляются по сетям с меньшим
неизвестным уровнем доверия (например, по публичным сетям), уровень
доверия к построенной логической сети не зависит от уровня доверия к базовым
сетям
благодаря
использованию
средств
криптографии
(шифрования,
аутентификации, инфраструктуры открытых ключей, средств для защиты от
повторов и изменений передаваемых по логической сети сообщений).
Цель VPN-технологий состоит в максимальной степени обособления
потоков данных одного предприятия от потоков данных всех других
пользователей сети общего пользования. Обособленность должна быть
обеспечена в отношении параметров пропускной способности потоков и в
конфиденциальности
технологий
VPN
передаваемых
являются
данных.
обеспечение
в
Таким
сетях
образом,
общего
задачами
пользования
гарантированного качества обслуживания для потоков данных, а также защита
их от возможного НСД.
Так как основной задачей VPN является защита трафика, поэтому
виртуальная сеть должна удовлетворять большому числу требований и, в
первую очередь, обладать надежной криптографией, гарантирующей защиту от
прослушивания, изменения, отказа от авторства. Кроме того, VPN должна иметь
надежную систему управления ключами и криптоинтерфейс, позволяющий
осуществлять криптооперации: защищенная почта, программы шифрования
дисков и файлов и др. В настоящее время интерес к использованию средств для
построения VPN постоянно растёт, что обусловлено целым рядом причин:
низкой стоимостью эксплуатации за счет использования сетей общего
пользования вместо собственных или арендуемых линий связи;
масштабируемостью решений;
простотой изменения конфигурации;
"прозрачностью" для пользователей и приложений.
При использовании VPN-технологий можно обеспечить:
защиту (конфиденциальность, подлинность и целостность) передаваемой
по сетям информации;
защиту внутренних сегментов сети от НСД со стороны сетей общего
пользования;
сокрытие внутренней структуры защищаемых сегментов сети;
идентификацию и аутентификацию пользователей сетевых объектов;
централизованное
управление
политикой
корпоративной
сетевой
безопасности и настройками VPN-сети [2].
1.3
СПОСОБЫ
СОЗДАНИЯ
ЗАЩИЩЕННЫХ
ВИРТУАЛЬНЫХ
КАНАЛОВ
Любой из двух узлов виртуальной сети, между которыми формируется
защищенный туннель, может принадлежать конечной или промежуточной точке
защищаемого
способы
потока
образования
сообщений.
защищенного
Соответственно
виртуального,
возможны
пример
различные
защищенный
виртуального канала изображен на рисунке 1.1.
Вариант, когда конечные точки защищенного туннеля совпадают с
конечными точками защищаемого потока сообщений, является с точки зрения
безопасности лучшим. В этом случае обеспечивается полная защищенность
канала вдоль всего пути следования пакетов сообщений. Однако такой вариант
ведет к децентрализации управления и избыточности ресурсных затрат.
Требуется установка средств создания защищенных туннелей на каждый
клиентский компьютер локальной сети, что усложняет централизованное
управление доступом к компьютерным ресурсам и экономически не всегда
оправдано. В большой сети отдельное администрирование каждого клиентского
компьютера с целью конфигурирования в нем средств защиты является
достаточно трудоемкой процедурой.
Рисунок 1.1 - Защищенный виртуальный канал
Поэтому, если отсутствует необходимость защиты трафика внутри
локальной сети, входящей в виртуальную сеть, то в качестве конечной точки
защищенного туннеля целесообразно выбрать брандмауэр или пограничный
маршрутизатор этой локальной сети. В случае же, когда внутри локальной сети
поток сообщений также должен быть защищен, то в качестве конечной точки
туннеля в этой сети должен выступать компьютер, представляющий одну из
сторон защищенного взаимодействия. При доступе к локальной сети
удаленного пользователя компьютер этого пользователя также должен быть
конечной точкой защищенного виртуального канала [3].
Распространен
также
вариант,
характеризующийся
более
низкой
безопасностью, но более высоким удобством применения. Согласно данному
варианту Рабочие станции и серверы локальной сети, а также удаленные
компьютеры не участвуют в создании защищенного туннеля, который
прокладывается только внутри публичной сети с коммутацией пакетов,
например, внутри Internet. В качестве конечных точек такого туннеля чаще
всего выступают провайдеры Internet или пограничные маршрутизаторы
(брандмауэры) локальной сети. При удаленном доступе к локальной сети
туннель создается между сервером удаленного доступа провайдера Internet, а
также пограничным провайдером Internet или маршрутизатором (брандмауэром)
локальной сети. При объединении локальных сетей туннель формироваться
только между пограничными провайдерами Internet или маршрутизаторами
(брандмауэрами) локальной сети.
Аргументацией в пользу описанного варианта создания виртуальных
сетей выступает тот факт, что уязвимыми для злоумышленников в большей
степени являются сети с коммутацией пакетов, такие, как Internet, а не каналы
телефонной
сети
или
выделенные
каналы
связи.
Виртуальные
сети,
построенные по данному варианту, обладают хорошей масштабируемостью и
управляемостью. Для клиентских компьютеров и серверов локальной сети,
входящей в виртуальную сеть, защищенные туннели полностью прозрачны и
программное обеспечение этих узлов остается без изменений. Однако по
причине того, что часть защищаемого трафика проходит в незащищенном виде
по публичным каналам связи, данный вариант существенно снижает
безопасность информационного взаимодействия. Кроме того, большая часть
работы по созданию защищенных туннелей ложится на провайдеров, которым
необходимо доверять и платить.
Создание защищенного туннеля выполняют компоненты виртуальной
сети, функционирующие на узлах, между которыми формируется туннель. Эти
компоненты принято называть инициатором и терминатором туннеля.
Инициатор туннеля инкапсулирует (встраивает) пакеты в новый пакет,
содержащий наряду с исходными данными новый заголовок с информацией об
отправителе и получателе. Хотя все передаваемые по туннелю пакеты являются
пакетами IP, инкапсулируемые пакеты могут принадлежать к протоколу любого
типа, включая пакеты немаршрутизируемых протоколов, таких, как NetBEUI.
Маршрут между инициатором и терминатором туннеля определяет обычная
маршрутизируемая сеть IP, которая может быть и сетью, отличной от Internet.
Терминатор туннеля выполняет процесс, обратный инкапсуляции - он удаляет
новые заголовки и направляет каждый исходный пакет в локальный стек
протоколов или адресату в локальной сети. Сама по себе инкапсуляция никак не
влияет на защищенность пакетов сообщений, передаваемых по туннелю VPN.
Но
благодаря
инкапсуляции
появляется
возможность
полной
криптографической защиты инкапсулируемых пакетов. Конфиденциальность
инкапсулируемых пакетов обеспечивается путем их криптографического
закрытия, т.е. зашифровывают, а целостность и подлинность - путем
формирования цифровой подписи. Поскольку существует большое множество
методов криптозащиты данных, очень важно, чтобы инициатор и терминатор
туннеля использовали одни и те же методы и могли согласовывать друг с
другом эту информацию.
1.4 КЛАССИФИКАЦИЯ VPN СЕТЕЙ
Классифицировать VPN решения можно по нескольким основным
параметрам, которые представлены на рисунке 1.2.
аутентификация канал сеансовой туннелирование
Рисунок 1.2 - Классификация VPN
По типу используемой среды:
Защищённые VPN сети. Наиболее распространённый вариант приватных
частных сетей. C его помощью возможно создать надежную и защищенную
подсеть на основе ненадёжной сети, как правило, Интернета.
Примером защищённых VPN являются: IPSec, OpenVPN и PPTP.
Доверительные VPN сети. Используются в случаях, когда передающую
среду можно считать надёжной и необходимо решить лишь задачу создания
виртуальной
подсети
в
рамках
большей
сети.
Вопросы
обеспечения
безопасности становятся неактуальными. Примерами подобных VPN решении
являются: MPLS и L2TP. Корректнее сказать, что эти протоколы перекладывают
задачу обеспечения безопасности на другие, например L2TP, как правило,
используется в паре с IPSec [4].
По способу реализации:
VPN сети в виде специального программно-аппаратного обеспечения.
Реализация VPN сети осуществляется при помощи специального комплекса
программно-аппаратных средств. Такая реализация обеспечивает высокую
производительность и, как правило, высокую степень защищённости.
VPN сети в виде программного решения. Используют персональный
компьютер со специальным программным обеспечением, обеспечивающим
функциональность VPN.
VPN сети с интегрированным решением. Функциональность VPN
обеспечивает комплекс, решающий также задачи фильтрации сетевого трафика,
организации сетевого экрана и обеспечения качества обслуживания.
.4.1 КЛАССИФИКАЦИЯ VPN ПО АРХИТЕКТУРЕ
По архитектуре технического решения принято выделять три основных
вида виртуальных частных сетей:
- внутрикорпоративные VPN (Intranet VPN);
VPN с удаленным доступом (Remote Access VPN)
межкорпоративные VPN (Extranet VPN).
Intranet VPN используют для объединения в единую защищённую сеть
нескольких распределённых филиалов одной организации, обменивающихся
данными по открытым каналам связи. При организации такой схемы
подключения требуется наличие VPN серверов равное количеству связываемых
офисов.
Данный способ целесообразно использовать как для обыкновенных
филиалов, так и для мобильных офисов, которые будут иметь доступ к ресурсам
«материнской» компании, а также без проблем обмениваться данными между
собой.
Интранет построен на базе тех же понятий и технологий, которые
используются для Интернета, такие как архитектура клиент-сервер и стек
протоколов Интернет (TCP/IP). В Интранете встречаются все из известных
интернет-протоколов,
например,
протоколы
HTTP
(веб-службы),
SMTP
(электронная почта), и FTP(передача файлов). Интернет-технологии часто
используются
для
обеспечения
современными
интерфейсами
функции
информационных систем, размещающих корпоративные данные.
Интранет можно представить как частную версию Интернета, или как
частное расширение Интернета, ограниченного организацией с помощью
брандмауэра. Первые интранет-веб-сайты и домашние страницы начали
появляться в организациях в 1990-1991. Однако по неофициальным данным,
термин Интранет впервые стал использоваться в 1992 году в таких
учреждениях, как университеты и корпорации, работающие в технической
сфере [5].
Интранет также противопоставляют Экстранету; доступ к Интранету
предоставлен только служащим организации, в то время как к Экстранету могут
получить доступ клиенты, поставщики, или другие утверждённые руководством
лица. В Экстранет-технологии помимо частной сети, пользователи имеют
доступ к Интернет ресурсам, но при этом осуществляются специальные меры
для безопасного доступа, авторизации, и аутентификации.
Интранет компании не обязательно должен обеспечивать доступ к
Интернету. Когда такой доступ всё же обеспечивается, обычно это происходит
через
сетевой
шлюз
несанкционированного
с
брандмауэром,
внешнего
доступа.
ограждая
Сетевой
шлюз
Интранет
часто
от
также
осуществляет пользовательскую аутентификацию, шифрование данных, и часто
- возможность соединения по виртуальной частной сети (VPN) для находящихся
за пределами предприятия сотрудников, чтобы они могли получить доступ к
информации о компании, вычислительным ресурсам и внутренним контактам.
Достоинства Intranet VPN:
применение мощных криптографических протоколов шифрования данных
для защиты конфиденциальной информации;
надежность функционирования при выполнении таких критических
приложений, как системы автоматизированной продажи и системы управления
базами данных;
гибкость управления эффективным размещением быстро возрастающего
числа новых пользователей, новых офисов и новых программных приложений.
Рисунок 1.3 - Схема подключения Intranet VPN
Access VPN используют для создания защищённого канала между
сегментом корпоративной сети (центральным офисом или филиалом) и
одиночным
пользователем,
корпоративным
ресурсам
который,
с
работая
домашнего
дома,
компьютера
подключается
или,
находясь
к
в
командировке, подключается к корпоративным ресурсам при помощи ноутбука
или смартфона.
Рисунок 1.4 - Схема удалённого доступа VPN
Преимущества перехода от частно управляемых dial networks к Remote
Access VPN:
-
возможность
использования
местных
dial-in
numbers
вместо
междугородних позволяет значительно снизить затраты на междугородние
телекоммуникации;
эффективная система установления подлинности удаленных и мобильных
пользователей обеспечивает надежное проведение процедуры аутентификации;
высокая масштабируемость и простота развертывания для новых
пользователей, добавляемых к сети;
сосредоточение
внимания
компании
на
основных
корпоративных
бизнес-целях вместо отвлечения на проблемы обеспечения работы сети.
Существенная экономия при использовании Remote Access VPN является
мощным стимулом, однако применение открытого Интернет в качестве
объединяющей магистрали для транспорта чувствительного корпоративного
трафика становится все более масштабным, что делает механизмы защиты
информации
жизненно
важными
элементами
данной
технологии.VPN.
Используют для сетей, к которым подключаются «внешние» пользователи
(например, заказчики или клиенты). Уровень доверия к ним намного ниже, чем
к сотрудникам компании, поэтому требуется обеспечение специальных
«рубежей» защиты, предотвращающих или ограничивающих доступ последних
к особо ценной, конфиденциальной информации.
Сети Extranet VPN в целом похожи на внутрикорпоративные виртуальные
частные сети с той лишь разницей, что проблема защиты информации является
для них более острой. Для Extranet VPN характерно использование
стандартизированных
VPN-продуктов,
гарантирующих
способность
к
взаимодействию с различными VPN-решениями, которые деловые партнеры
могли бы применять в своих сетях.
Когда несколько компаний принимают решение работать вместе и
открывают друг для друга свои сети, они должны позаботиться о том, чтобы их
новые партнеры имели доступ только к определенной информации. При этом
конфиденциальная
информация
должна
быть
надежно
защищена
от
несанкционированного использования. Именно поэтому в межкорпоративных
сетях большое значение придается контролю доступа из открытой сети
посредством МЭ. Важна и аутентификация пользователей, призванная
гарантировать, что доступ к информации получают только те, кому он
действительно разрешен. Вместе с тем, развернутая система защиты от
несанкционированного доступа не должна привлекать к себе внимания.
Соединения Extranet VPN развертываются, используя те же архитектуру и
протоколы, которые применяются при реализации Intranet VPN и Remote
AccessVPN. Основное различие заключается в том, что разрешение доступа,
которое дается пользователям Extranet VPN, связано с сетью их партнера [3].
1.4.2
КЛАССИФИКАЦИЯ
VPN
ПО
ТИПУ
ТЕХНИЧЕСКОЙ
РЕАЛИЗАЦИИ
Существуют различные варианты построения VPN. При выборе решения
требуется учитывать факторы производительности средств построения VPN.
Например, если маршрутизатор и так работает на пределе мощности своего
процессора, то добавление туннелей VPN и применение шифрования /
дешифрования информации могут остановить работу всей сети из-за того, что
этот маршрутизатор не будет справляться с простым трафиком, не говоря уже о
VPN. Опыт показывает, что для построения VPN лучше всего использовать
специализированное оборудование, однако если имеется ограничение в
средствах, то можно обратить внимание на чисто программное решение.
Рассмотрим некоторые варианты построения VPN.на базе брандмауэров.
Брандмауэры большинства производителей поддерживают туннелирование и
шифрование данных.. Все подобные продукты основаны на том, что трафик,
проходящий через брандмауэр шифруется. К программному обеспечению
собственно брандмауэра добавляется модуль шифрования. Недостатком этого
метода можно назвать зависимость производительности от аппаратного
обеспечения,
на
котором
работает
брандмауэр.
При
использовании
брандмауэров на базе ПК надо помнить, что подобное решение можно
применять только для небольших сетей с небольшим объемом передаваемой
информации. На рисунке 1.5 схематически представлена схема построения VPN
на базе брандмауэров.
Рисунок 1.5 - Схема построения VPN на базе брандмауэров
на базе маршрутизаторов. Другим способом построения VPN является
применение для создания защищенных каналов маршрутизаторов (рисунок 1.6).
Так как вся информация, исходящая из локальной сети, проходит через
маршрутизатор, то целесообразно возложить на этот маршрутизатор и задачи
шифрования.
Примером оборудования для построения VPN на маршрутизаторах
является
оборудование
компании
Cisco
Systems.
Начиная
с
версии
программного обеспечения IOS 11.3, маршрутизаторы Cisco поддерживают
протоколы L2TP и IPSec. Помимо простого шифрования проходящей
информации Cisco поддерживает и другие функции VPN, такие как
идентификация при установлении туннельного соединения и обмен ключами.
Для повышения производительности маршрутизатора может быть
использован дополнительный модуль шифрования ESA. Кроме того, компания
Cisco System выпустила специализированное устройство для VPN, которое так и
называется
VPN
Access
Router
(маршрутизатор
доступа
к
VPN),
предназначенное для установки в компаниях малого и среднего размера, а также
в отделениях крупных организаций.
Рисунок 1.6 - VPN на базе маршрутизаторов
на базе программного обеспечения. Следующим подходом к построению
VPN являются чисто программные решения. При реализации такого решения
используется специализированное программное обеспечение, которое работает
на выделенном компьютере, и в большинстве случаев выполняет роль
proxy-сервера. Компьютер с таким программным обеспечением может быть
расположен за брандмауэром.
В качестве примера такого решения можно выступает программное
обеспечение AltaVista Tunnel компании Digital. При использовании данного
программного
обеспечения
клиент
подключается
к
серверу
Tunnel,
аутентифицируется на нем и обменивается ключами. Шифрация производится
на базе 56 или 128 битных ключей, полученных в процессе установления
соединения. Далее, зашифрованные пакеты инкапсулируются в другие
IP-пакеты, которые в свою очередь отправляются на сервер. Кроме того, данное
программное обеспечение каждые 30 минут генерирует новые ключи, что
значительно повышает защищенность соединения.
Положительными
качествами
AltaVista
Tunnel
являются
простота
установки и удобство управления. Минусами данной системы можно считать
нестандартную архитектуру (собственный алгоритм обмена ключами) и низкую
производительность.на базе сетевой ОС. Решения на базе сетевой ОС мы
рассмотрим на примере системы Windows NT компании Microsoft. Для создания
VPN Microsoft использует протокол PPTP, который интегрирован в систему
Windows NT. Данное решение очень привлекательно для организаций
использующих Windows в качестве корпоративной операционной системы.
Необходимо отметить, что стоимость такого решения значительно ниже
стоимости прочих решений. В работе VPN на базе Windows NT используется
база пользователей NT, хранящаяся на Primary Domain Controller (PDC). При
подключении к PPTP-серверу пользователь аутентифицируется по протоколам
PAP, CHAP или MS-CHAP. Передаваемые пакеты инкапсулируются в пакеты
GRE/PPTP. Для шифрования пакетов используется нестандартный протокол от
Microsoft Point-to-Point Encryption c 40 или 128 битным ключом, получаемым в
момент установки соединения. Недостатками данной системы являются
отсутствие проверки целостности данных и невозможность смены ключей во
время соединения. Положительными моментами являются легкость интеграции
с Windows и низкая стоимость.на базе аппаратных средств представлен на
рисунке 1.7. Вариант построения VPN на специальных устройствах может быть
использован в сетях, требующих высокой производительности. Примером
такого решения служит продукт c IPro-VPN компании Radguard. Данный
продукт использует аппаратное шифрование передаваемой информации,
способное пропускать поток в 100 Мбит/с. IPro-VPN поддерживает протокол
IPSec и механизм управления ключами ISAKMP/Oakley. Помимо прочего,
данное устройство поддерживает средства трансляции сетевых адресов и может
быть дополнено специальной платой, добавляющей функции брандмауэра.
Рисунок 1.7 - VPN на базе аппаратных средств
.4.3 КЛАССИФИКАЦИЯ VPN ПО ТИПУ ИСПОЛЬЗУЕМОЙ СРЕДЫ
Сети VPN можно классифицировать по типу используемой среды, а
именно:
- защищённые VPN сети. Наиболее распространённый вариант приватных
частных сетей. C его помощью возможно создать надежную и защищенную
подсеть на основе ненадёжной сети, как правило, Интернета. Примером
защищённых VPN являются: IPSec, OpenVPN и PPTP.
доверительные VPN сети. Используются в случаях, когда передающую
среду можно считать надёжной и необходимо решить лишь задачу создания
виртуальной
подсети
в
рамках
большей
сети.
Вопросы
обеспечения
безопасности становятся неактуальными. Примерами подобных VPN решении
являются: MPLS и L2TP. Корректнее сказать, что эти протоколы перекладывают
задачу обеспечения безопасности на другие, например L2TP, как правило,
используется в паре с IPSec.
2 .АНАЛИЗ ПРОТОКОЛОВ VPN СЕТЕЙ
Сети VPN строятся с использованием протоколов туннелирования данных
через
сеть
связи
общего
пользования
Интернет,
причем
протоколы
туннелирования обеспечивают шифрование данных и осуществляют их
сквозную передачу между пользователями. Как правило, на сегодняшний день
для построения сетей VPN используются протоколы следующих уровней:
- Канальный уровень
Сетевой уровень
- Транспортный уровень.
2.1 МОДЕЛЬ OSI
Технологий
безопасной
передачи
данных
по
общедоступной
(незащищенной) сети применяют обобщенное название - защищенный канал
(securechannel). Термин «канал» подчеркивает тот факт, что защита данных
обеспечивается между двумя узлами сети (хостами или шлюзами) вдоль
некоторого виртуального пути, проложенного в сети с коммутацией пакетов.
Защищенный канал можно построить с помощью системных средств,
реализованных на разных уровнях модели взаимодействия открытых систем
OSI. Уровни протоколов защищенного канала приведены в таблице 2.1.
По признаку «рабочего» уровня модели OSI различают следующие
группы VPN:
- VPN канального уровня;
VPN сетевого уровня;
VPN сеансового уровня.
Таблица 2.1 Уровни протоколов защищенного канала
Протоколы защищенного доступа
Прикладной
Представительный
Сеансовый
Транспортный
Влияют на приложения
Прозрачны для
приложений
Сетевой
Канальный
Физический
Для
независимости
от
прикладных
протоколов
и
приложений
защищенные виртуальные сети формируются на одном из более низких уровней
модели OSI - канальном, сетевом или сеансовом. Канальному (второму) уровню
соответствуют такие протоколы реализации VPN, как РРТР, L2F и L2TP,
сетевому (третьему) уровню - IPSec, SKIP, а сеансовому (пятому) уровню SSL/TLS и SOCKS. Чем ниже уровень эталонной модели, на котором
реализуется защита, тем она прозрачнее для приложений и незаметнее для
пользователей. Однако при снижении этого уровня уменьшается набор
реализуемых
услуг
безопасности
и
становится
сложнее
организация
управления. Чем выше защитный уровень в соответствии с моделью OSI, тем
шире набор услуг безопасности, надежнее контроль доступа и проще
конфигурирование системы защиты. Однако в этом случае усиливается
зависимость от используемых протоколов обмена и приложений.
В виртуальной сети криптозащита может одновременно выполняться на
нескольких
уровнях
эталонной
модели.
При
этом
увеличивается
криптостойкость, но по причине снижения общей скорости криптографических
преобразований уменьшается пропускная способность виртуальной сети.
Поэтому на практике защищенные виртуальные сети формируются на одном
уровне модели OSI (канальном, сетевом, транспортном или сеансовом).
2.2 ТУННЕЛИРОВАНИЕ НА КАНАЛЬНОМ УРОВНЕ
Для стандартного формирования
криптозащишенных туннелей на
канальном уровне модели OSI компанией Microsoft при поддержке компаний
Ascend Communications, 3Com/Primary Access, ECI-Telematics и US Robotics
был разработан протокол туннелирования РРТР (Point-to-Point Tunnelm
Protocol), представляющий собой расширение протокола РРР (Point-to-Point
Protocol). В протоколе РРТР не специфицируются конкретные методы
аутентификации и шифрования. Клиенты удаленного доступа в Windows NT 4.0
и Windows 98 с Dial-Up Networking поставляются с версией шифрования DES
компании RSA Data Security, получившей название "шифрование двухточечной
связи Microsoft" (Microsoft Point-to-Point Encryption - MPPE). Канальному
уровню модели OSI соответствует также протокол туннелирования L2F (Layer-2
Forwarding), разработанный компанией Cisco Systems при поддержке компаний
Shiva и Northern Telecom. В данном протоколе также не специфицируются
конкретные методы аутентификации и шифрования. В отличие от протокола
РРТР протокол L2F позволяет использовать для удаленного доступа к
провайдеру Internet не только протокол РРР, но и другие протоколы, например,
SUP. При формировании защищенных каналов по глобальной сети провайдерам
Internet
не
нужно
осуществлять
конфигурацию
адресов
и
выполнять
аутентификацию. Кроме того, для переноса данных через защищенный туннель
могут использоваться различные протоколы сетевого уровня, а не только IP, как
в протоколе РРТР. Протокол L2F стал компонентом операционной системы IOS
(Internetwork Operating System) компании Cisco и поддерживается во всех
выпускаемых ею устройствах межсетевого взаимодействия и удаленного
доступа.
Протоколы РРТР и L2F были представлены в организацию Internet
Engineering Task Force (IETF) и в 1996 году соответствующие комитеты решили
их объединить. Получившийся в результате протокол, включивший все лучшее
из РРТР и L2F, был назван протоколом туннелирования второго уровня (Layer-2
Tunneling Protocol - L2TP). Его поддерживают компании Cisco, Microsoft, 3Com,
Ascend и многие другие производители. Как и предшествующие протоколы
канального уровня, спецификация L2TP не описывает методы аутентификации
и шифрования. Протокол L2TP является расширением РРР на канальном уровне
и может поддерживать любые высокоуровневые протоколы.
Протоколы формирования защищенного туннеля на канальном уровне
независимы от протоколов сетевого уровня модели OSI, по которым
фунционируют локальные сети, входящие в состав виртуальных сетей. Они
позволяют создавать защищенные каналы для обмена данными между
удаленными компьютерами и локальными сетями, функционирующими
различным протоколам сетевого уровня - IP, IPX или NetBEUI. Пакеты этих
протоколов криптографически защищаются и инкапсулируются в IP-пакеты
сети Internet, которые и переносятся к месту назначения, образуя защищенные
виртуальные
каналы.
Многопротокольность
-
основное
преимущество
инкапсулирующих протоколов канального уровня.
Вместе с тем формирование криптозащищенных туннелей между
объединяемыми локальными сетями на основе протоколов канального уровня
приводит к сложности конфигурирования и поддержки виртуальных каналов
связи. Туннели на основе РРР требуют, чтобы конечные точки поддерживали
информацию о состоянии каждого канала (например, такую, как тайм-ауты), и,
следовательно, не обладают хорошей масштабируемостью при необходимости
иметь несколько туннелей с общими конечными точками. Кроме того,
протоколы формирования защищенных туннелей на канальном уровне не
специфицируют конкретные методы шифрования, аутентификации, проверки
целостности каждого передаваемого пакета, а также средств управления
ключами.
Исходя из вышесказанного, можно сделать вывод, что протоколы
создания защищенных виртуальных каналов на канальном уровне лучше всего
подходит для защиты информационного взаимодействия при удаленном
доступе к локальной сети. Учитывая, что в состав операционных систем
Windows 98/NT включена реализация протокола РРТР, этот протокол для
организации защищенного удаленного доступа получил наиболее широкое
распространение.
2.2.1 ПРОТОКОЛ РРТР
Протокол
РРТР
(Point-to-Point-Tunneling
Protocol),
разработанный
Microsoft при поддержке других компаний, представляет собой расширение
протокола РРР (Point-to-Point Protocol) для создания защищенных виртуальных
каналов при доступе удаленных пользователей к локальным сетям через Internet
Он предусматривает создание криптозащищенного туннеля на канальном
уровне модели OSI как в случае прямого соединения удаленного компьютера с
публичной сетью, так и в случае подсоединения его к публичной сети по
телефонной линии через провайдера.
Данный протокол был представлен в организацию Internet Engineering
Task Force (IETF) в качестве претендента на стандартный протокол создания
защищенного канала при доступе удаленных пользователей к локальным сетям
через публичные сети (в первую очередь через Internet). РРТР получил статус
проекта стандарта Internet, однако, несмотря на широкое распространение, в
качестве стандарта так и не был утвержден. Сейчас рабочая группа IETF
рассматривает возможность принятия в качестве стандарта протокол L2TP
(Layer 2 Tunneling Protocol), который объединяет лучшие стороны протокола
РРТР и подобного протокола L2F (Layer 2 Forwarding), предложенного
компанией Cisco Systems [6].
Для удаленного пользователя, подключенного через публичную IP-сеть к
серверу удаленного доступа (Remote Access Service - RAS) локальной сети,
РРТР имитирует нахождение компьютера этого пользователя во внутренней
сети посредством туннелирования пакетов сообщений. Данные через туннель
переносятся с помощью стандартного протокола удаленного доступа РРР,
который в протоколе РРТР используется не только для связи компьютера
удаленного пользователя с RAS провайдера Internet, но и для взаимодействия с
RAS локальной сети через туннель. Для передачи данных применяются
IP-пакеты, содержащие инкапсулированные РРР-пакеты. Инкапсулированные
РРР-пакеты в свою очередь включают зашифрованные инкапсулированные
исходные пакеты (IP, IPX или NetBEUI), предназначенные для взаимодействия
между компьютером удаленного пользователя и локальной сетью. Пакеты,
циркулирующие в рамках сессии РРТР, имеют следующую структуру
указанную на рисунке 2.1:
- заголовок канального уровня, используемый внутри Internet, например,
заголовок кадра Ethernet;
- заголовок IP;
- заголовок GRE (Generic Routing Encapsulation - общий метод
инкапсуляции для маршрутизации);
исходный пакет РРР, включающий пакет IP, IPX или NetBEUI.
Рисунок 2.1 - Структура данных для пересылки по туннелю PPTP
Далее,
Encapsulation
PPTP
инкапсулирует
(GRE),
который
PPP-кадр
принадлежит
в
пакет
сетевому
Generic
уровню.
Routing
GRE
инкапсулирует протоколы сетевого уровня. Однако GRE не имеет возможности
устанавливать сессии и обеспечивать защиту данных от злоумышленников. Для
этого используется способность PPTP создавать соединение для управления
туннелем. Применение GRE в качестве метода инкапсуляции ограничивает поле
действия PPTP только сетями IP.
После того как кадр PPP был инкапсулирован в кадр с заголовком GRE,
выполняется инкапсуляция в кадр с IP-заголовком. IP-заголовок содержит
адреса отправителя и получателя пакета. В заключение PPTP добавляет PPP
заголовок и окончание.
Система-отправитель
посылает
данные
через
туннель.
Система-получатель удаляет все служебные заголовки, оставляя только данные
PPP.
Поскольку вся идея дистанционного доступа состоит в разрешении
машине клиента подключаться по сети к машине сервера, соединение PPTP
инициируется клиентом, который использует служебное средство Windows NT Remote Access Service (RAS) - для установления PPP-соединения с поставщиком
услуг Интернет. Затем при активизированном соединении PPP с помощью
сервера, подключенного к Интернет и действующего как сервер RAS, клиент
применяет RAS для выполнения второго соединения. На этот раз в поле номера
телефона указывается IP-адрес (или доменное имя), и клиент, для того чтобы
осуществить соединение, вместо COM-порта использует VPN-порт (VPN-порты
конфигурируются на машинах клиента и сервера в процессе инсталляции
PPTP).
Ввод IP-адреса инициирует передачу запроса серверу на начало сеанса.
Клиент ожидает от сервера подтверждения имени пользователя и пароля и
ответа сообщением, что соединение установлено. В этот момент начинает свою
работу канал PPTP, и клиент может приступить к туннелированию пакетов
серверу. Поскольку они могут быть пакетами IPX и NetBEUI, сервер может
выполнять с ними свои обычные процедуры обеспечения защиты.
В основе обмена данными по протоколу PPTP лежит управляющее
соединение PPTP - последовательность управляющих сообщений, которые
устанавливают и обслуживают туннель. Полное соединение PPTP состоит
только из одного соединения TCP/IP, которое требует передачи эхо-команд для
поддержания его открытым, пока выполняются транзакции.
В протоколе PPTP определено две схемы его применения.
Первая схема рассчитана на поддержание защищенного канала между
сервером
удаленного
доступа
ISP
и
пограничным
корпоративной сети представлена на рисунке 2.2.
маршрутизатором
Рисунок
2.2
-
Защищенный
канал
"провайдер-маршрутизатор
корпоративной сети" на основе протокола PPTP
В этом варианте компьютер удаленного пользователя не должен
поддерживать протокол PPTP. Он связывается с сервером удаленного доступа
RAS, установленного у ISP, с помощью стандартного протокола PPP и проходит
первую аутентификацию у провайдера. RAS ISP должен поддерживать
протокол PPTP. По имени пользователя RAS ISP должен найти в базе учетных
данных пользователей IP-адрес маршрутизатора, являющегося пограничным
маршрутизатором
корпоративной
сети
данного
пользователя.
С
этим
маршрутизатором RAS ISP устанавливает сессию по протоколу PPTP. Протокол
PPTP определяет некоторое количество служебных сообщений, которыми
обмениваются взаимодействующие стороны, служебные сообщения передаются
по протоколу TCP. RAS ISP передает маршрутизатору корпоративной сети
идентификатор
пользователя,
по
которому
маршрутизатор
снова
аутентифицирует пользователя по протоколу CHAP. Если пользователь прошел
вторичную аутентификацию (она для него прозрачна), то RAS ISP посылает ему
сообщение об этом по протоколу РРР и пользователь начинает посылать свои
данные в RAS ISP по протоколу IP, IPX или NetBIOS, упаковывая их в кадры
РРР. RAS ISP осуществляет инкапсуляцию кадров РРР в пакеты IP, указывая в
качестве адреса назначения адрес пограничного маршрутизатора, а в качестве
адреса источника - свой собственный IP-адрес. Пакеты РРР шифруются с
помощью секретного ключа, в качестве которого используется дайджест от
пароля пользователя, который хранится в базе учетных данных RAS ISP для
аутентификации по протоколу CHAP.
Внутренние серверы корпоративной сети также не должны поддерживать
протокол PPTP, так как пограничный маршрутизатор извлекает кадры РРР из
пакетов IP и посылает их по сети в необходимом формате - IP, IPX или
NetBIOS.предложила также и другую схему использования протокола PPTP, с
помощью которой образуется защищенный канал между компьютером
удаленного пользователя и пограничным маршрутизатором корпоративной
сети, в качестве которого должен использоваться RAS Windows NT/2000.
Данная схема приведена на рисунке 2.3
Рисунок
2.3
-
Защищенный
канал
"клиент
-
маршрутизатор"
корпоративной сети на основе протокола PPTP
Сначала клиент звонит на сервер RAS ISP и устанавливает с ним связь по
протоколу PPP, проходя аутентификацию одним из способов, поддерживаемых
провайдером - по протоколам PAP, CHAP или с помощью терминального
диалога.
После аутентификации у провайдера, пользователь вторично "звонит", на
этот раз в сервер удаленного доступа корпоративной сети. Этот "звонок"
отличается от обычного тем, что вместо телефонного номера указывается
IP-адрес RAS Windows NT, подключенного к Интернет со стороны
корпоративной сети. При этом устанавливается сессия по протоколу PPTP
между клиентским компьютером и RAS корпоративной сети. Клиент еще раз
аутентифицируется, теперь на сервере RAS его сети, а затем начинается
передача данных, как и в первом варианте.
2.2.2 ПРОТОКОЛ L2TP
Протокол L2TP (Layer-2 Tunneling Protocol - L2TP) разработан в
организации Internet Engineering Task Force (IETF) при поддержке компаний
Microsoft и Cisco Systems как протокол защищенного туннелирования
РРР-трафика через сети общего назначения с произвольной средой. Работа над
данным протоколом велась на основе протоколов РРТР и L2F, и он вобрал в
себя лучшие возможности обоих проектов. L2TP, в отличие от РРТР, не
привязан к протоколу IP, а потому может быть использован в сетях с
коммутацией
пакетов,
например,
в
сетях
ATM.
Кроме
того,
L2TP
предусматривает управление потоками данных, отсутствующее в L2F. Главное
же, по мнению разработчиков, то, что новый протокол должен стать
общепринятым стандартом, признаваемым всеми производителями.
Чтобы понять суть концепции L2TP, нужно представлять цели, которые
преследовали компании Microsoft и Cisco при разработке РРТР и L2F. В
соответствии с целями, которые преследовались при разработке РРТР и L2F,
различные организации должны были получить возможность делегировать
функции безопасного удаленного доступа провайдерам Internet. Это, в свою
очередь, позволило бы снизить затраты на администрирование и приобретение
аппаратных средств, так как локальные сети этих организаций смогли бы
обойтись без множества модемов и дополнительных телефонных каналов. В
обоих протоколах поставленная цель была достигнута. И L2F, и РРТР
позволяют провайдерам Internet проводить удаленные сеансы по протоколу РРР,
используя для аутентификации запросы к серверам безопасности локальных
сетей [7].
Различия
между
L2F
и
РРТР
объясняются
специализацией
их
разработчиков. Cisco производит аппаратные маршрутизаторы для сетевой
инфраструктуры, тогда как Microsoft выпускает операционные системы. Для
работы провайдеров с L2F нужно, чтобы их маршрутизаторы и серверы
Удаленного доступа поддерживали этот протокол. Что касается протокола
РРТР, то провайдеры не обязательно должны иметь средства организации
туннелей, так как туннели могут формироваться специальным программным
обеспечением конечных точек взаимодействия - компьютеров удаленных
пользователей и серверов удаленного доступа локальных сетей. Тем не менее,
L2F по сравнению с РРТР имеет несколько преимуществ. Так, РРТР требует
применения маршрутизации на базе IP, тогда как L2F не привязан к конкретным
протоколам сетевого уровня, используемым для транспортировки РРР-кадров.
В гибридном протоколе L2TP не только объединены лучшие черты
протоколов РРТР и L2TP, но и добавлены новые функции.
Как и РРТР, новая спецификация не нуждается во встроенной аппаратной
поддержке, хотя оборудование, специально предназначенное для нее, повысит
производительность и защищенность системы. В L2TP есть ряд отсутствующих
в спецификации РРТР функций защиты, включая возможность работы с
протоколом IPsec.
Наследственные черты L2F видны в том, что протокол не привязан к
среде IP и с таким же успехом способен работать в любых сетях с коммутацией
пакетов например, в сетях ATM или в сетях с ретрансляцией кадров (frame
relay).
В L2TP добавлена важная функция управления потоками данных, которая
не допускает в систему больше информации, чем та способна обработать.
Кроме того, в отличие от своих предшественников, L2TP позволяет открывать
между конечными абонентами сразу несколько туннелей, каждый из которых
администратор может выделить для того или иного приложения. Эти
особенности обеспечивают безопасность и гибкость туннелирования, а также
существенно повышают качество обслуживания виртуальных каналов связи.
По
существу
РРР-протокола
протокол
функциями
L2TP
представляет
аутентификации
собой
удаленных
расширение
пользователей,
установки защищенного виртуального соединения, а также управлением
потоками данных. В соответствии с протоколом L2TP в качестве сервера
удаленного доступа провайдера должен выступать концентратор доступа
(Access Concentrator), который реализует клиентскую часть протокола L2TP и
обеспечивает пользователю сетевой доступ к его локальной сети через Internet.
Роль сервера удаленного доступа локальной сети должен выполнять сетевой
сервер L2TP (L2TP Network Server), функционирующий на любых платформах,
совместимых с протоколом РРР.
Подобно протоколам РРТР и L2F, протокол L2TP предусматривает 3
этапа формирования защищенного виртуального канала (рисунок 2.4):
- установление соединения с сервером удаленного доступа локальной
сети;
аутентификация пользователя;
- конфигурирование криптозащищенного туннеля.
Рисунок 2.4 - Схема взаимодействия по протоколу L2TP
Для установления соединения с сервером удаленного доступа локальной
сети, в качестве которого выступает сетевой сервер L2TP, удаленный
пользователь связывается по протоколу РРР с концентратором доступа L2TP,
функционирующим на сервере провайдера Internet или другой публичной сети.
На
данном
этапе
концентратор
доступа
L2TP
может
выполнить
аутентификацию пользователя от имени провайдера. Далее по имени
пользователя концентратор доступа провайдера определяет IP-адрес сетевого
сервера
L2TP,
принадлежащего
требуемой
локальной
сети.
Между
концентратором доступа провайдера и сервером L2TP локальной сети
устанавливается сессия по протоколу L2TP, называемая сессией L2TP.
После установки сессии L2TP происходит процесс аутентификации
пользователя на сервере L2TP локальной сети. Для этого может использоваться
любой из стандартных алгоритмов аутентификации, например, алгоритм CHAP.
Как и в протоколах РРТР и L2F, в спецификации L2TP отсутствуют описания
методов аутентификации.
В случае успешной аутентификации пользователя между концентратором
доступа
провайдера
и
сервером
L2TP
локальной
сети
создается
криптозащищенный
туннель.
С
помощью
управляющих
сообщений
осуществляется настройка различных параметров туннеля. В одном туннеле
могут мультиплексироваться несколько сессий L2TP. Сам протокол L2TP не
специфицирует
конкретные
методы
криптозащиты
и
предусматривает
возможность использования различных стандартов шифрования. Однако если
туннель формируется в IP-сетях, то криптозащита должна выполняться в
соответствии с протоколом IPSec. В этом случае пакеты L2TP инкапсулируются
в UDP-пакеты, которые передаются между концентратором доступа провайдера
и сервером L2TP локальной сети через IPSec-туннель. Для этого задействуется
UDP-порт 1701.
Несмотря на свои достоинства, протокол L2TP не устраняет всех
недостатков туннельной передачи данных на канальном уровне. В частности,
необходима поддержка L2TP провайдерами. Протокол L2TP ограничивает весь
трафик рамками выбранного туннеля и лишает пользователей доступа к Другим
частям
Internet.
Для
текущей
(четвертой)
версии
протокола
IP
не
предусматривается создание криптозащищенного туннеля между конечными
точками
информационного
взаимодействия.
Кроме
того,
предложенная
спецификация обеспечивает стандартное шифрование только в IP-сетях при
использовании протокола IPSec.
2.3 СЕТЕВОЙ УРОВЕНЬ
Спецификацией, где описаны стандартные методы для всех компонентов
и функций защищенных виртуальных сетей, является протокол Internet Protocol
Security (IPSec), соответствующий сетевому уровню модели OSI и входящий в
состав новой версии протокола IP - IPv6. Протокол IPSec иногда еще называют
протоколом туннелирования третьего уровня (Layer-3 Tunneling) . IPSec
предусматривает стандартные методы аутентификации пользователей или
компьютеров при инициации туннеля, стандартные способы шифрования
конечными точками туннеля, формирования и проверки Цифровой подписи, а
также стандартные методы обмена и управления криптографическими ключами
между конечными точками. Этот гибкий стандарт предлагает несколько
способов для выполнения каждой задачи. Выбранные методы для одной задачи
обычно не зависят от методов реализации других задач. Для функций
аутентификации IPSec поддерживает цифровые сертификаты популярного
стандарта Х.509.
Туннель IPSec между двумя локальными сетями может поддерживать
множество индивидуальных каналов передачи данных, в результате чего
приложения
данного
типа
получают
преимущества
с
точки
зрения
масштабирования по сравнению с технологией второго уровня. Протокол IPSec
может использоваться совместно с протоколом L2TP. Совместно эти два
протокола обеспечивают наиболее высокий уровень гибкости при защите
виртуальных каналов. Дело в том, что спецификация IPSec ориентирована на
протокол IP и, таким образом, бесполезна для трафика любых других
протоколов сетевого уровня. Протокол L2TP отличается независимостью от
транспортного уровня, что может быть полезно в гетерогенных сетях,
состоящих и IP-, IPX- и AppleTalk-сегментов. IPSec стремительно завоевывает
популярность и станет, вероятно, доминирующим стандартом по созданию и
поддержке защищенных виртуальных сетей.
Для управления криптографическими ключами на сетевом уровне модели
OSI наиболее широкое распространение получили такие протоколы, как SKIP
(Simple Key management for Internet Protocols) и ISAKMP (Internet Security
Association and Key Management Protocol). SKIP проще в реализации, но он не
поддерживает
переговоров
по
поводу
алгоритмов
шифрования.
Если
получатель, использующий SKIP, не в состоянии расшифровать пакет, он уже
не сможет согласовать метод шифрования с противоположной стороной.
Протокол ISAKMP поддерживает такие переговоры и выбран в качестве
обязательного протокола для управления ключами в IPSec для IPv6. Другими
словами протокол ISAKMP является составной частью протокола IPSec. В
текущей четвертой версии протокола IP (в протоколе IPv4) может применяться
как протокол ISAKMP, так и протокол SKIP.
Протокол IPsec.- набор протоколов для обеспечения защиты данных,
передаваемых
по
межсетевому
протоколу
IP,
позволяет
осуществлять
подтверждение подлинности и/или шифрование IP-пакетов. IPsec также
включает в себя протоколы для защищённого обмена ключами в сети Интернет.
Существует два режима работы IPsec: транспортный режим и туннельный
режим. В транспортном режиме шифруется (или подписывается) только
информативная часть IP-пакета. Маршрутизация не затрагивается, так как
заголовок IP пакета не изменяется (не шифруется). Транспортный режим как
правило используется для установления соединения между хостами. Он может
также использоваться между шлюзами, для защиты туннелей, организованных
каким-нибудь другим способом (IP tunnel, GRE и др.). В туннельном режиме
IP-пакет шифруется целиком. Для того, чтобы его можно было передать по сети,
он помещается в другой IP-пакет. По существу, это защищённый IP-туннель.
Туннельный режим может использоваться для подключения удалённых
компьютеров к виртуальной частной сети или для организации безопасной
передачи данных через открытые каналы связи (например, Интернет) между
шлюзами для объединения разных частей виртуальной частной сети. Режимы
IPsec не являются взаимоисключающими. На одном и том же узле некоторые
SA могут использовать транспортный режим, а другие - туннельный.
В IPsec используются две базы данных: SPD (Security Policy Database,
куда записываются правила обеспечения безопасности) и SADB (Security
Association
Database,
безопасности).
где
хранятся
данные
об
активных
ассоциациях
Система IPsec предлагает многовариантный механизм реализации
безопасности для обоих концов соединения. Эта техника пригодна для
отдельного пользователя, особенно если он работает на выезде, и для
виртуальных субсетей организаций, работающих с данными, которые требуют
секретности.
При использовании совместно с Firewall IPsec предоставляет высокий
уровень безопасности. При этом нужно иметь в виду, что для реализации IPsec
оба партнера должны иметь оборудование и/или программы, которые
поддерживают эти протоколы.предусматривает процедуры аутентификации и
шифрования. Формирование и удаления заголовка IPsec может осуществляться
в машине клиента или в сетевом шлюзе (маршрутизаторе).
Протокол IPsec предоставляет три вида услуг: аутентификацию (АН),
шифрование (ESP) и безопасную пересылку ключей. Обычно желательны обе
первые услуги, так как неавторизованный клиент не сможет проникнуть в VPN,
а шифрование не позволит злоумышленникам прочитать, исказить или
подменить сообщения. По этой причине протокол ESP предпочтительнее, так
как он позволяет совместить обе эти услуги.
Заголовок аутентификации (AH) и Encapsulating Security Payload (ESP)
являются двумя протоколами нижнего уровня, применяемыми IPsec, именно
они осуществляют аутентификацию и шифрование+аутентификацию данных,
передаваемых через соединение. Эти механизмы обычно используются
независимо, хотя возможно (но не типично) их совместное применение.
В протоколе IPSec используются два режима туннельный и транспортный.
Транспортный режим обеспечивает безопасное соединение двух терминалов
путем инкапсуляции содержимого IP-данных, в то время как туннельный режим
инкапсулирует весь IP-пакет на участке между шлюзами. Последний вариант
используется для формирования традиционной VPN, где туннель создает
безопасный путь через полный опасностей Интернет.
Установление
IPsec-соединения
подразумевает
любые
варианты
крипто-алгоритмов, но ситуация существенно упрощается благодаря тому, что
обычно допустимо применение двух, максимум трех вариантов.
На фазе аутентификации вычисляется контрольная сумма ICV (Integrity
Check Value) пакета с привлечением алгоритмов MD5 или SHA-1. При этом
предполагается, что оба партнера знают секретный ключ, который позволяет
получателю
вычислить
отправителем.
Если
ICV
и
сравнение
сравнить
ICV
с
прошло
результатом,
успешно,
присланным
считается,
что
отправитель пакета аутентифицирован. Протокол AH всегда осуществляет
аутентификацию, а ESP выполняет ее опционно.
Шифрование использует секретный ключ для кодирования данных перед
их транспортировкой, что исключает доступ к содержимому со стороны
злоумышленников. В системе IPsec могут применяться следующие алгоритмы:
DES, 3DES, Blowfish, CAST, IDEA, RC5 и AES. Но, в принципе, разрешены и
другие алгоритмы [8].
Так
как
обе
стороны
диалога
должны
знать
секретный
ключ,
используемый при хэшировании или шифровании, существует проблема
транспортировки этих ключей. Возможен ввод ключей вручную, когда эти коды
вводятся при конфигурации системы с помощью клавиатуры обоими
партнерами. При этом предполагается, что доставка этих кодов осуществлена
каким-то достаточно безопасным методом, алгоритм же IKE (Интернет Key
Exchange - обмен ключами по Интернет) является безопасным механизмом
пересылки ключей в реальном масштабе времени, например, через Интернет .
Существует два режима обмена ключами IKE. Эти режимы служат для
управления балансом эффективности и безопасности при исходном обмене
ключами IKE. "Основной режим" требует шести пакетов в обоих направлениях,
но обеспечивает полную безопасность при установлении соединения IPsec. В
агрессивном режиме используется вдвое меньше обменов, но безопасность в
этом случае ниже, так как часть информации передается открытым текстом.
Протокол AH используется для аутентификации, но не для шифрования IP
трафика, и служит для подтверждения того, что мы связаны именно с тем, с кем
предполагаем, что полученные данные не искажены и не подменены при
транспортировке.
Аутентификация
аутентификационного
выполняется
хэш-кода
путем
сообщения.
вычисления
зашифрованного
Хэширование
охватывает
практически все поля IP пакета (исключая только те, которые могут
модифицироваться при транспортировке, например, TTL или контрольная
сумма заголовка). Этот код записывается в AH заголовке и пересылается
получателю.заголовок содержит пять важных полей которые показаны на
рисунке 2.6.
Рисунок 2.6 - Формат заголовка протокола AH
AH len Определяет длину заголовка пакета, измеренную в 32-битовых
словах, за вычетом двух слов (это диктуется RFC 1883 для IPv6).
Зарезервировано. Поле зарезервировано на будущее и должно содержать
нули.
Индекс параметров безопасности (SPI)
32-битовый идентификатор, который помогает получателю выбрать, к
какому из входных обменов относится этот пакет. Каждый обмен, защищенный
AH, использует хэш-алгоритм (MD5, SHA-1 и т.д..), какие-то секретные и
возможно некоторые иные данные. SPI может рассматриваться как индекс
таблицы наборов таких параметров, чтобы облегчить выбор нужного набора.
Номер по порядку. Монотонно увеличивающийся идентификатор,
который позволяет установить соответствие между посланным пакетом и
откликом
подтверждения
аутентификационные
его
данные,
получения.
что
Этот
позволяет
код
включается
детектировать
в
любые
модификации, а также атаки воспроизведения.
Аутентификационные данные. Это контрольная сумма ICV (Integrity
Check Value), вычисленная для всего пакета, включая большинство полей
заголовка. Получатель повторно вычисляет тот же хэш. Если значения кодов не
совпадут, пакет был поврежден в пути или не соответствует секретному ключу.
Такие пакеты отбрасываются. ICV часто называется также МАС (Message
Authentication Code). Для вычисления МАС используются следующие поля:
поля IP-заголовка, которые не меняются при транспортировке.
- заголовок АН, кроме поля данных аутентификации
-
поле
данных
протокола
верхнего
уровня,
которые
остаются
неизменными при транспортировке.
Транспортный
виртуальных
режим
соединений
протокола
АН
используется
точка-точка.
Эта
защита
для
защиты
осуществляется
с
использованием аутентификации, шифрования или обоих методов.
При транспортном режиме AH IP-пакет модифицируется лишь слегка
путем включения AH заголовка между IP заголовком и полем данных (TCP,
UDP и т.д.) и перестановки кодов протокола.
Перестановка кодов протокола необходима для восстановления исходного
вида IP пакетов конечным получателем: после выполнения проверки
получателем корректности IPsec заголовка, этот заголовок удаляется, а в поле
код протокола IP заносится прежнее значение (TCP, UDP и т.д.). Когда к
адресату приходит пакет, успешно прошедший процедуру аутентификации,
заголовок AH удаляется, а содержимое поля протокол (=AH) в IP заголовке
заменяется запомненным значением поля следующий заголовок. Таким
образом, восстанавливается первоначальный вид IP дейтограммы, и пакет
может быть передан ожидающему процессу.
В туннельном режиме реализуется функциональность VPN, где IP пакет
целиком инкапсулируются в другой пакет и в таком виде доставляются
адресату. Также как и в транспортном режиме, пакет защищается контрольной
суммой
ICV,
чтобы
аутентифицировать
отправителя
и
предотвратить
модификацию пакета при транспортировке. Но в отличие от транспортного
режима, здесь инкапсулируется весь IP пакет, а это позволяет адресам
отправителя и получателя отличаться от адресов, содержащихся в пакете, что
позволяет формировать туннель. Когда пакет туннельного режима приходит
адресату, он проходит ту же аутентификационную проверку, что и пакет
AH-типа, после чего удаляются заголовки IP и AH и восстанавливается
первоначальный формат пакета.
Большинство реализаций рассматривает оконечную точку туннеля в
качестве сетевого интерфейса. Реконструированный пакет может быть
доставлен локальной машине или маршрутизован куда-либо еще (согласно
IP-адресу места назначения в инкапсулированном пакете). Дальнейшая его
транспортировка уже не обеспечивается средствами безопасности IPsec.
В то время как транспортный режим используется исключительно для
обеспечения безопасной связи между двумя компьютерами, туннельный режим
обычно применяется между шлюзами (маршрутизаторами, сетевыми экранами,
или отдельными VPN устройствами) для построения VPN (Virtual Private
Network).
Следует заметить, что в пакете IPsec нет специального поля "режим":
которое бы позволяло разделить транспортный режим от туннельного, эту
функцию выполняет поле следующий заголовок пакета AH.
Когда поле следующий заголовок соответствует IP, это означает, что
пакет инкапсулирует всю IP-дейтограмму (туннельный режим), включая
независимые адреса отправителя и получателя, которые позволяют реализовать
маршрутизацию после туннеля. Любое другое значение поля (TCP, UDP, ICMP
и т.д.) означает транспортный режим (безопасная транспортировка по схеме
точка-точка). IP дейтограмма верхнего уровня имеет ту же структуру вне
зависимости от режима, и промежуточные маршрутизаторы обрабатывают
трафик, не анализируя внутреннее содержание IPsec/AH. Заметим, что ЭВМ, в
отличие от сетевого шлюза, должна поддерживать как транспортный, так и
туннельный режим, но при формировании соединения машина-машина
формирование туннеля представляется избыточным. Кроме того, для сетевого
шлюза (маршрутизатора, сетевого экрана и т.д.) необходимо поддерживать
туннельный режим, в то же время поддержка транспортного режима
представляется полезной лишь для случая, когда шлюз сам является конечным
адресатом (например, в случае реализации процедур удаленного управления
сетью). AH содержит ICV (Integrity Check Value) в аутентификационной части
заголовка, и эта контрольная сумма формируется обычно (но не всегда) с
помощью стандартного криптографического хэш алгоритма, например, MD5
или SHA-1. Здесь используется не традиционная контрольная сумма, которая не
может предотвратить намеренное искажение содержимого, а алгоритм HMAC
(Hashed Message Authentication Code), который при вычислении ICV применяет
секретный ключ. Несмотря на то, что хакер может заново вычислить хэш, без
секретного ключа он не сможет корректно сформировать ICV. Алгоритм HMAC
описан в документе RFC 2104. Заметим, что IPsec/AH не определяет, какой
должна быть аутентификационная функция, вместо этого предоставляются
рамки, в которых можно реализовать любую функцию, согласованную
отправителем и получателем. Можно использовать для аутентификации
цифровую подпись или криптографическую функцию, если оба участника их
поддерживают. Именно потому, что AH обеспечивает хорошую защиту
содержимого пакета, так как этот протокол покрывает все, что только нужно
защитить, эта защита приводит к несовместимости с NAT (Network Address
Translation).
Протокол NAT используется для установления соответствия между
частными IP-адресами (например, 19.125.1.X) и легальными IP. При этом IP
заголовок модифицируется устройством NAT путем замены IP-адресов
отправителя и получателя. Когда изменяются IP-адреса, нужно заново
вычислить контрольную сумму заголовка. Это нужно сделать в любом случае.
Так как устройство NAT обычно размещается в одном шаге между
отправителем и получателем это требует, кроме того декрементации значения
TTL (Time To Live). Так как поля TTL и контрольная сумма заголовка всегда
модифицируются на пролете, AH знает, что эти поля следует исключить из зоны
защиты, но это не касается IP адресов. Адреса включены в область вычисления
ICV, и любая модификация вызовет сбой при проверке ICV получателем. Так
как вычисление ICV требует знания секретного ключа, который неизвестен
промежуточным узлам, маршрутизатор NAT не сможет заново вычислить ICV.
Аналогичная проблема возникает при использовании протокола PAT (Port
Address Translation), который устанавливает соответствие нескольких частных
IP адресов одному внешнему IP. В этом случае изменяются не только IP-адреса.
Но и коды портов в UDP и TCP пакетах (а иногда и в поле данных). Это требует
много большей адаптивности со стороны устройства NAT, и более серьезных
модификаций всей IP дейтограммы. По этой причине, протокол AH в
туннельном или транспортном режиме полностью несовместим с NAT.
Заметим, что эта трудность не относится к ESP, так как аутентификация и
шифрование в этом варианте не охватывает IP заголовок, модифицируемый
NAT. Несмотря на это, NAT создает определенные проблемы и для ESP.
Протокол NAT транслирует IP адреса “на пролете” - но он должен отслеживать
то, с каким соединением происходит работа, чтобы корректно связывать
отклики с источником пакетов. При использовании TCP или UDP, это обычно
делается с привлечением номеров порта, но IPsec не оставляет такой
возможности. На первый взгляд можно предположить, что для решения
проблемы можно использовать идентификатор SPI, но так как SPI отличаются
для разных направлений обмена, для устройства NAT нет способа связать
возвращаемый пакет с конкретным соединением. Протокол ESP является
протоколом защиты, обеспечивающим конфиденциальность (т.е. шифрование),
аутентификацию источника и целостность данных, а также (в качестве опции)
сервис защиты от воспроизведения и ограниченную конфиденциальность
трафика путем противодействия попыткам анализа потока данных.
Протокол
ESP
обеспечивает
конфиденциальность
с
помощью
шифрования на уровне пакетов IP. При этом поддерживается множество
алгоритмов симметричной схемы шифрования, например DES, triple-DES, AES
и Blowfish для шифрования поля данных. Алгоритм, используемый для
конкретного соединения, специфицируется ассоциацией безопасности SA, SA
включает в себя не только алгоритм, но и используемый ключ.
В отличие от протокола AH, который вводит небольшой заголовок перед
полем данных, ESP “окружает” защищаемое поле данных. Поля индекс
параметров безопасности (Security Parameters Index) и номер по порядку служат
для тех же целей, что и в случае AH, но в ESP имеются также поля заполнителя,
следующего заголовка, и опционно аутентификационных данных в конце, в
хвостовике ESP. Формат ESP-пакета рассмотрен на рисунке 2.7
Рисунок 2.7 - Формат ESP-пакета без аутентификации
Возможно использование ESP без какого-либо шифрования (чтобы
применить NULL алгоритм). Этот режим не обеспечивает конфиденциальности,
и его имеет смысл использовать в сочетании с аутентификацией ESP.
Неэффективно использовать ESP без шифрования или аутентификации (если
только это не делается для тестирования протокола).
Помимо
шифрования,
ESP
может
опционально
предоставлять
возможность аутентификации, с привлечение алгоритма HMAC. В отличие от
AH, однако, эта аутентификация производится только для ESP заголовка и
зашифрованного поля данных. При этом не перекрывается весь IP пакет. Это не
существенно ослабляет безопасность аутентификации, но дает некоторые
важные преимущества.
Когда посторонний рассматривает IP пакет, содержащий данные ESP,
принципиально невозможно определить IP адреса отправителя и получателя,
нарушитель, конечно, узнает, что это ESP данные (это видно из заголовка
пакета), но тип поля данных и сами данные зашифрованы.
Глядя на сам пакет, невозможно даже определить, присутствуют или нет
аутентифицированные данные (это можно сделать лишь, используя индекс
параметров безопасности).
Как и в случае AH, транспортный режим предполагает инкапсуляцию
поля данных дейтограмм, и протокол ориентирован на обмен машина-машина.
Исходный IP заголовок оставлен на месте (за исключением замененного поля
протокол), и это означает, что адреса отправителя и получателя также остаются
неизмененными [9].в туннельном режиме производит инкапсуляцию всей
IP-дейтограммы внутрь зашифрованной оболочки.
Реализация шифрованного соединения в туннельном режиме очень близка
к традиционным VPN.
В отличие от AH, где наблюдатель может легко сказать, происходил
обмен в туннельном или транспортном режиме, здесь эта информация
недоступна. Это происходит из-за того, что указание на то, что следующий
заголовок является IP, находится в зашифрованном поле данных и, поэтому не
виден для участника, неспособного дешифровать пакет [10].опирается на ряд
технологических решений и методов шифрования которое можно представить в
виде следующих главных шагов:
Шаг 1. Начало процесса IPSec. Трафик, которому требуется шифрование в
соответствии с политикой защиты IPSec, согласованной сторонами IPSec,
начинает IКЕ-процесс.
Шаг 2. Первая фаза IKE. IKE-процесс выполняет аутентификацию сторон
IPSec и ведет переговоры о параметрах ассоциаций защиты IKE, в результате
чего создается защищенный канал для ведения переговоров о параметрах
ассоциаций защиты IPSec в ходе второй фазы IKE.
Шаг 3. Вторая фаза IKE. IKE-процесс ведет переговоры о параметрах
ассоциации защиты IPSec и устанавливает соответствующие ассоциации
защиты IPSec для устройств сообщающихся сторон.
Шаг
4.
Передача
данных.
Происходит
обмен
данными
между
сообщающимися сторонами IPSec, который основывается на параметрах IPSec и
ключах, хранимых в базе данных ассоциаций защиты.
Шаг 5. Завершение работы туннеля IPSec. Ассоциации защиты IPSec
завершают свою работу либо в результате их удаления, либо по причине
превышения предельного времени их существования.
.4 ПОСТРОЕНИЕ ЗАЩИЩЕННЫХ СЕТЕЙ НА СЕАНСОВОМ УРОВНЕ
Сеансовый уровень является максимально высоким уровнем модели OSI,
на котором возможно формирование защищенных виртуальных каналов. При
построении защищенных виртуальных сетей на данном уровне достигаются
наилучшие показатели по функциональной полноте защиты информационного
обмена, надежности контроля доступа, а также простоте конфигурирования
системы безопасности. Протоколы формирования защищенных виртуальных
каналов на сеансовом уровне прозрачны для прикладных протоколов защиты, а
также высокоуровневых протоколов предоставления различных сервисов
(протоколов HTTP, FTP, POP3, SMTP, NNTP и др.). Однако на сеансовом
уровне начинается непосредственная зависимость от приложений, реализующих
высокоуровневые
протоколы.
Поэтому
реализация
протоколов
защиты
информационного обмена, соответствующих этому уровню, в большинстве
случаев требует внесения изменений в высокоуровневые сетевые приложения.
Так как сеансовый уровень модели OSI отвечает за установку логических
соединений и управление этими соединениями, то на данном уровне появляется
возможность
использования
программ-посредников,
проверяющих
допустимость запрошенных соединений и обеспечивающих выполнение других
функций
защиты
межсетевого
взаимодействия.
В
общем
случае
программы-посредники, которые традиционно используются в межсетевых
экранах, могут выполнять следующие функции:
идентификация и аутентификация пользователей;
криптозащита передаваемых данных;
разграничение доступа к ресурсам внутренней сети; - разграничение
доступа к ресурсам внешней сети;
фильтрация
и
преобразование
потока
сообщений,
например,
динамический поиск вирусов и прозрачное шифрование информации;
трансляция внутренних сетевых адресов для исходящих пакетов
сообщений;
регистрация событий и реагирование на задаваемые события;
кэширование данных, запрашиваемых из внешней сети.
Таким образом, при построении защищенных виртуальных сетей на
сеансовом уровне появляется возможность не только криптографической
защиты информационного обмена, включая аутентификацию, но и возможность
реализации ряда функций посредничества между взаимодействующими
сторонами.
Для криптографической защиты информационного обмена на сеансовом
Уровне наибольшую популярность получил протокол SSL/TLS (Secure Sockets
Layer/
Transport
Layer
Security),
разработанный
компанией
Netscape
Communications.
Протокол SSL.
Протокол Secure Sockets Layer (SSL), изначально ориентированный на
защиту информационного обмена между клиентом и сервером компьютерной
сети, является промышленным протоколом сеансового уровня модели OSI
использующим для обеспечения безопасности информационного обмена
криптографические
методы
защиты
информации.
Конфиденциальность
передаваемых данных обеспечивается за счет их криптографического закрытия,
а аутентификация взаимодействующих сторон, а также подлинность и
целостность циркулирующей информации - за счет формирования и проверки
цифровой подписи.
Ядром протокола SSL является технология комплексного использования
асимметричных и симметричных криптосистем. В качестве алгоритмов
асимметричного шифрования используются такие алгоритмы, как RSA
(разработки RSA Data Security Inc.), а также алгоритм Диффи-Хеллмана. Для
вычисления хэш-функций могут применяться стандарты MD5 и SHA-1.
Допустимыми алгоритмами симметричного шифрования являются RC2, RC4,
DES, а также тройной DES. В протоколе SSL третьей версии набор
криптографических алгоритмов является расширяемым. Для аутентификации
взаимодействующих
шифрования
сторон
применяются
пользователей
специальных
(клиента
и
криптозащиты
цифровые
и
сервера),
Сертификационных
ключа
сертификаты
заверенные
Центров.
симметричного
открытых
ключей
цифровой
подписью
Поддерживаются
цифровые
сертификаты, соответствующие общепринятому стандарту Х.509 [11].
Протокол SSL разработан корпорацией Netscape, а затем поддержан рядом
ведущих
производителей
положительных
качеств
программного
SSL
практически
обеспечения.
вытеснил
Из-за
своих
конкурирующие
высокоуровневые протоколы по защите информационного обмена, например,
такие как SHTTP (Secure HTTP), и стал общепризнанным неофициальным
стандартом защиты в Internet и Intranet сетях. Спецификации SSL были в свое
время предложены в качестве официальных стандартов Internet, но не получили
этого статуса по формальным обстоятельствам. Не исключено, что SSL все же
начнет продвигаться по ступеням формального принятия IETF в качестве
стандарта, так как он уже стал промышленным протоколом, развиваемым и
продвигаемым вне иерархии технических координирующих институтов Internet.
Последней версией SSL является версия 3.0, о которой и будет идти речь.
Клиентская часть SSL реализована во всех популярных Web-навигаторах,
к которым относятся Netscape Navigator компании Netscape и Internet Explorer от
Microsoft
а
серверная
-
в
большинстве
как
коммерческих,
так
и
распространяемых на некоммерческих условиях WWW-серверов например, в
серверных приложениях компаний IBM, Netscape, Microsoft, Spyglass, Open
Market.
В соответствии с протоколом SSL криптозащищенные туннели создаются
между конечными точками виртуальной сети (рисунок 2.8). Инициаторами
какого защищенного туннеля являются клиент и сервер, функционирующие на
компьютерах в конечных точках туннеля. Протокол SSL предусматривает два
этапа взаимодействия клиента и сервера при формировании и поддержке
защищаемого соединения:
установление SSL-сессии;
защищенное взаимодействие.
Рисунок 2.8 Криптозащищенный туннель на базе протокола SSL
Процедура установления SSL-сессии, называемая также процедурой
"рукопожатия",
отрабатывается
перед
непосредственной
защитой
информационного обмена и выполняется по протоколу начального приветствия
(Handshake Protocol), входящему в состав протокола SSL. В процессе
становления SSL-сессии решаются следующие задачи:
аутентификация сторон;
согласование криптографических алгоритмов и алгоритмов сжатия,
которые будут использоваться при защищенном информационном обмене;
формирование общего секретного мастер-ключа;
генерация на основе сформированного мастер-ключа общих секретных
сеансовых ключей для криптозащиты информационного обмена.
В реализациях протокола SSL для аутентификации взаимодействующих
сторон и формирования общих секретных ключей чаще всего используют
алгоритм RSA разработки RSA Data Security Inc.
Однозначное и достоверное соответствие между открытыми ключами и
их
владельцами устанавливается с помощью цифровых
сертификатов,
выдаваемых специальными Центрами Сертификации. Сертификат представляет
собой блок данных, содержащий следующую информацию:
имя центра сертификации;
имя владельца сертификата;
открытый ключ владельца сертификата;
период действия сертификата;
идентификатор
и
параметры
криптоалгоритма,
который
должен
использоваться при обработке сертификата;
цифровую подпись центра сертификации, заверяющую все данные в
составе сертификата.
Цифровая
подпись
центра
сертификации
в
составе
сертификата
обеспечивает достоверность и однозначность соответствия открытого ключа и
его владельца. Центр сертификации исполняет роль нотариуса, заверяющего
подлинность открытых ключей, что позволяет их владельцам пользоваться
услугами защищенного взаимодействия без предварительной личной встречи.
Необходимость безусловного доверия к центру сертификации со стороны всех
участников защищенного обмена предъявляет к нему достаточно высокие
требования по проверке подлинности заверяемых открытых ключей. Одним из
таких центров в Internet является компания VeriSign, учрежденная RSA Data
Security Inc., при участии компаний Visa, IBM, Netscape, Microsoft и Oracle.
Третья версия протокола SSL поддерживает три режима аутентификации:
взаимная аутентификация сторон;
односторонняя аутентификация сервера без аутентификации клиента;
полная анонимность.
При использовании последнего варианта взаимодействующие стороны
незащищены от атак, связанных с подменой участников взаимодействия,
данном
режиме
обеспечивается
защита
информационного
обмена
без
каких-либо гарантий относительно подлинности взаимодействующих сторон.
В режиме односторонней аутентификации сервера без аутентификации
клиента процедура установления SSL-сессии между клиентом и сервером
включает следующие шаги.
. Клиент посылает серверу запрос на установление защищенного
соединения, в котором передает некоторые формальные параметры этого
соединения:
текущее время и дату;
случайную последовательность (RAND_CL);
набор
поддерживаемых
клиентом
алгоритмов
шифрования и алгоритмов вычисления хэш-функции;
набор поддерживаемых алгоритмов сжатия и др.
симметричного
. Сервер обрабатывает запрос от клиента и передает ему согласованный
набор параметров:
идентификатор SSL-сессии;
конкретные криптографические алгоритмы из числа предложенных
клиентом (если по какой-либо причине предложенные алгоритмы или их
параметры не удовлетворяют требованиям сервера, сессия закрывается);
сертификат
сервера,
заверенный
цифровой
подписью
центра
сертификации;
случайную последовательность (RAND_SERV).
. Клиент проверяет полученный сертификат сервера с помощью
открытого
ключа
центра
сертификации,
который
ему
известен.
При
отрицательном результате проверки сессия закрывается, а при положительном клиент выполняет следующие действия:
генерирует случайную 48-байтную последовательность Pre_MasterSecret,
предназначенную для генерации общего секретного мастер-ключа; шифрует
Pre_MasterSecret по открытому ключу сервера, полученному в сертификате
сервера, и посылает серверу;
с помощью согласованных хэш-алгоритмов формирует общий секретный
мастер-ключ
(MasterSecret),
используя
последовательность
Pre_MasterSecret,
последовательность
RAND_CL
и
в
качестве
посланную
полученную
серверу
от
параметров
случайную
него
случайную
криптографические
параметры
последовательность RAND_SERV;
используя
MasterSecret,
вычисляет
SSL-сессиии: формирует общие с сервером сеансовые секретные ключи для
симметричного шифрования и вычисления хэш-функций;
переходит в режим защищенного взаимодействия.
.
Сервер
расшифровывает
полученную
последовательность
Pre_MasterSecret по своему закрытому ключу и выполняет на ее основе те же
операции, что и клиент:
с помощью согласованных хэш-алгоритмов формирует общий секретный
мастер-ключ (MasterSecret), используя в качестве параметров Pre_MasterSecret, а
также посланную клиенту случайную последовательность RAND_SERV и
полученную от него случайную последовательность RAND_CL;
используя
MasterSecret,
вычисляет
криптографические
параметры
SSL-сессиии: формирует общие с клиентом сеансовые секретные ключи для
симметричного шифрования и вычисления хэш-функций;
переходит в режим защищенного взаимодействия.
Так как при формировании параметров SSL-сессии и клиент, и сервер
пользовались одними и теми же исходными данными (согласованными
алгоритмами,
общей
секретной
последовательность
Pre_MasterSecret
и
случайными последовательностями RAND_CL и RAND_SERV), то очевидно
что в результате описанных выше действий они выработали одинаковые
сеансовые
секретные
ключи.
Для
проверки
идентичности
параметров
SSL-сессии клиент и сервер посылают друг другу тестовые сообщения,
содержание которых известно каждой из сторон:
клиент формирует сообщение из собственных посылок в адрес сервера на
шаге 1 и посылок, полученных от сервера на шаге 2, внося элемент случайности
в виде последовательности MasterSecret, уникальной для данной сессии;
формирует код для проверки целостности сообщения (MAC), шифрует
сообщение по общему сеансовому секретному ключу и отправляет серверу;
сервер, в свою очередь, формирует сообщение из собственных посылок в
адрес клиента на шаге 2, посылок, полученных от клиента на шаге 1, и
последовательности MasterSecret; формирует код для проверки целостности
сообщения (MAC), шифрует сообщение на общем сеансовом секретном ключе и
отправляет клиенту;
в случае успешной расшифровки и проверки целостности каждой из
сторон полученных тестовых сообщений, SSL-сессия считается установленной
и стороны переходят в штатный режим защищенного взаимодействия.
В
процессе
криптографическими
защищенного
параметрами
взаимодействия
SSL-сессии
с
установленными
выполняются
следующие
действия:
каждая сторона при передаче сообщения формирует МАС-код для
последующей проверки целостности сообщения и затем зашифровывает
исходное сообщение вместе с МАС-кодом по сеансовому секретному ключу;
каждая сторона при приеме сообщения расшифровывает его и проверяет
на целостность (вычисляется текущий МАС-код и сверяется с МАС-кодом
проверки
целостности,
полученным
вместе
с
сообщением);
в
случае
обнаружения нарушения целостности сообщения, SSL-сессия закрывается.
Несмотря на то, что протокол SSL поддерживается программным
обеспечением серверов и клиентов, выпускаемых ведущими западными
компаниями, в нашей стране имеются обстоятельства, препятствующие
распространению данного протокола и принятию его в качестве базового для
реализации
приложений,
требующих
защищенного
информационного
взаимодействия участвующих сторон.
Практически все существующие продукты, поддерживающие протокол
SSL, реализованы в США и из-за экспортных ограничений доступны только в
усеченном варианте (с длиной сеансового ключа 40 бит для алгоритмов
симметричного шифрования и 512 бит для алгоритма RSA, используемого на
этапе установления SSL-сессии), что на сегодняшний день явно недостаточно.
3. ПОСТРОЕНИЕ VPN НА ОСНОВЕ WINDOWS SERVER 2003
.1 НАСТРОЙКА СЕРВЕРА VPN ПОД WINDOWS 2003 SERVER
Проанализировав все возможные варианты построения VPN сети мы
сделав выводы пришли к тому что на сегодняшний день самый дешевый
вариант для построения и настройки VPN сервера является операционная
система Windows 2003 Server. Данная реализация удобна в конфигурации и
настройке. Топология VPN сети изображена на рисунке 3.1.
Рисунок 3.1 - Предложенная топология сети VPN
После успешной установки Windows 2003 Server на компьютер нам нужно
запустить службу Маршрутизация и удаленный доступ. Он настраивается как
сервер удаленного доступа (RAS-сервер) в службе RRAS (Маршрутизация и
удаленный доступ) которая показана на рисунке 3.2
Рисунок 3.2 - Настройка службы "Маршрутизация и удаленный доступ"
Находим здесь имя сервера и щелкаем по нему правой кнопкой мыши. В
появившемся меню нажимаем на Настроить и включить маршрутизацию и
удаленный доступ. После выбора этого пункта запускаеться мастер установки.
Мастер предоставит нам наиболее простой путь для настройки нашего сервера в
качестве любой из служб, перечисленных ниже и, в то же время, оставляет
возможность ручной настройки сервера (последняя опция)
.
Рисунок 3.3 - Выбор конфигурации сервера
Далее выбираем пункт Удаленный доступ (VPN или модем) и нажимаем
далее. В следующем окне ставим галочку напротив Доступ к виртуальной
частной сети (VPN) тем самым разрешаем удалённые подключения к нашему
серверу через интернет.
При выборе сервер VPN мастер запросит, какой протокол следует
использовать для работы удаленных клиентов на этом сервере, мы выбираем
TCP/IP. Мастер попросит нас указать устройство, через которое мы
подключены к Интернету. Через это устройство к нашей частной виртуальной
сети VPN, будут подключатся пользователи, следует отметить, что у этого
устройства должен быть постоянный IP адрес.
Указав устройство, через которое мы подключены к Интернету, мастер
попросит нас указать диапазон IP адресов, из этого диапазона IP адресов,
которого мы укажем, будут раздаваться IP адреса входящим VPN соединениям,
мы укажем такие IP адреса начальный 192.168.0.1 и конечный 192.168.0.40.
Теперь, когда мы указали IP адреса можно нажать кнопку Далее. Настройка
сервера VPN практически завершена, осталось только создать учетную запись
пользователя, под которой пользователи будут заходить в сеть, что мы сейчас с
вами и сделаем.
Для создания учетной записи пользователя нам нужно щелкнуть правой
кнопкой мыши на значке «мой компьютер», который находится на рабочем
столе, и выбрать управление. В появившемся окне мы должны выбрать
локальные пользователи и группы.
Чтобы создать нового пользователя, нужно щелкнуть правой кнопкой
мыши; затем в раскрывшемся контекстном меню выбрать элемент Новый
пользователь. В появившемся окне достаточно ввести имя пользователя и
пароль, еще нужно поставить галочку запретить смену пароля пользователем,
чтобы пользователи не смогли поменять пароль. У пользователя будет имя
Dovbnya, а пароль будет testdasdsa111.
Пользователя нужно включать в группу. Для этого на закладке Членство в
группах существует кнопка Добавить.
Один и тот же пользователь может быть членом любого количества групп
пользователей. На закладке Входящие звонки нужно настроить параметры
удаленного доступа для нашей учетной записи. В пункте Разрешение на
удалённый доступ(VPN или модем)) нужно выбрать Разрешить доступ.
На этом настройка сервера VPN завершена, и любой, кто знает наш IP
адрес, логин и пароль сможет зайти в нашу сеть из любого конца мира через
Интернет.
Рисунок 4.4 - Добавление нового пользователя.
3.2 НАСТРОЙКА КЛИЕНТСКОЙ ЧАСТИ VPN ПОД WINDOWS 2003
SERVER
Настройка клиентской части VPN таким следующим образом. Для того
чтобы приступить к настройке нам нужно зайти в систему с учётной записью
Администратора. Нажимаем Пуск, далее выполнить и вводим Ncpa.cpl, тем
самым вызвав окно сетевых подключений.
Нам нужно щелкнуть два раза левой кнопкой мыши по иконке Создание
нового подключения. Появится окно мастера в этом окне ми нажмём кнопку
Далее. В появившемся окне выберем пункт Подключение к виртуальной
частной сети через Интернет и нажмём кнопку Далее.
В следующем окне в текстовое поле нужно ввести IP-адрес нашего VPN
сервера.
Рисунок 4.5 - Создание VPN подключения
Для
уже
созданного
подключения
можно
в
любой
момент
откорректировать свойства, а также настроить некоторые моменты, касающиеся
безопасности и типа созданного подключения.
Рисунок 4.6 - Выбор типа VPN подключения
ВЫВОДЫ
В данной дипломной работе я рассмотрел протоколы и методы
реализации виртуальных сетей. Преимущества технологии VPN в том, что
организация удалённого доступа делается через Интернет, что намного дешевле
и лучше чем через выделенные каналы. Недостаток технологии VPN в том, что
средства построения VPN не являются полноценными средствами обнаружения
и блокирования атак. Они могут предотвратить ряд несанкционированных
действий, но далеко не все возможности, которые могут использоваться для
проникновения в корпоративную сеть. Но, несмотря на все это технология VPN
имеет перспективы на дальнейшее развитие. Для реализации VPN существуют
множество
аппаратных
комплексов,
но
они
не
нашли
глобального
распространения в связи со своей направленностью на обслуживание больших
предприятий и дороговизны. Вычислительная мощь аппаратных решений
высока, но не всегда целесообразна, поэтому программные решения, а тем более
стандартные, не требующие дополнительных затрат на поиск и приобретение
дополнительного
популярность.
программного
обеспечения,
завоевали
большую
СПИСОК ЛИТЕРАТУРЫ
1. В.Ф. Шаньгин. Информационная безопасность компьютерных систем и
сетей: учеб. Пособие. - М:ИД ФОРУМ: Инфра-М, 2010. - 416 с.
2. А.О. Чефранова. Технология построения VPN.Учебное пособие.- Москва:
Прометей, 2009. - 250 c.
. В.М. Зима, А.А Молдовян, Молдовян Н.А. Безопасность глобальных сетевых
технологий. - 2-е изд. - СПб: БХВ-Петербург, 2009 - 368 с.
. С. Браун. Виртуальные частные сети. Издательство “Лори”, Москва 2001503с.
. RFC 2637 - Point-to-Point Tunneling Protocol (PPTP) The Internet Society 1999.
. RFC 2661 - Layer Two Tunneling Protocol "L2TP" August 2009
7. Петренко С. Защищенная виртуальная частная сеть: современный взгляд на
защиту конфиденциальных данных 2001.
. Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии,
протоколы: Учебник для вузов. 3-еизд.-СПб.: Питер, 2008. - 958 с.
ПРИЛОЖЕНИЕ А
НАСТРОЙКА SLACKWARE LINUX НА ОСНОВЕ OPENVPN
Установка OpenVPN.
Скачиваем
последний
дистрибутив
версии
OpenVPN
с
сайта
http://www.openvpn.net в виде архива source в формате .tar.gz.
Далее распакованный дистрибутив устанавливаем с помощью команд
“./configure” “make” make install“. После успешной установки копируем
содержимое ./easy-rsa/2.0/* в /etc/openvpn/*.
Рисунок А.1 - Процесс установки OpenVPN
Создание ключей и сертификатов.
Создаём сертификат и ключ CA путём интерактивного вызова команды
openssl ./build-ca. После запуска данной команды генерируется 1024 битный
ключ RSA.. После нужно заполнить данные для сертификата.
Рисунок А.2 - Создания сертификата ключей
Создаём сертификат и ключ для сервера командой “build-key-server server.
После успешного генерирования сертификата ключей генерируем параметры
для Diffie-Hellman “./build-dh”
Теперь генерируем ключ и сертификат для клиента “./build-key client1”
Настройка сервера.
Настраиваем конфигурацию для сервера. Открываем server.conf который
находится в /etc/openvpn и конфигурируем следующим образом:
# Порт подключения
port 1194
proto tcp
# Устройство
dev tun0
# Прописываем расположение файлов сертификатов и ключей
ca
/etc/openvpn/keys/ca.crt/etc/openvpn/keys/server.crt/etc/openvpn/
keys/server.key/etc/openvpn/keys/dh1024.pem
# Параметры для виртуального тоннеля сервера.
server 10.10.10.0 255.255.255.0
# Добавляем маршрут
push “192.168.1.0 255.255.255.0”
# Разрешаем клиентам обмениваться пакетами
client-to-client
# Разрешаем использование одинаковых сертификатов
duplicate-cn
# Проверяем соединение каждые 10 секунд, иначе через 120 секунд
переподключиться.
keepalive 10 120
# Используем компрессию
comp-lzo
# Выставляем число максимально одновременных подключений
max-clients 10
# Назначаем пользователя и группу для работы.
user shpion
group shpion
# Записывать в реальном режиме статус сервера OpenVPN
status openvpn-status.log
# Запись логов-append opevpn.log
# Выставляем уровень отладки (1-минимальный, 9-максимальный)
verb 9
mute 20
Настройка клиентской части.
Открываем файл client.conf который находится в /etc/openvpn и
конфигурируем следующим образом
# Роль
client
# Устройство
dev tun
proto tcp
# Адрес сервера
remote
192.168.1.111
1194retry
infiniteshpionshpionkeytun/etc/openvpn/keys/ca.crt/etc/openvpn/keys/client1.crt/etc/o
penvpn/keys/client1.keyappend openvpn.loglzo920.