Построение защищенных виртуальных сетей Общие сведения - umotnas.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Построение защищенных виртуальных сетей Общие сведения - страница №1/1


Построение защищенных виртуальных сетей

Построение защищенных виртуальных сетей

Общие сведения


Безопасность информационного взаимодействия локальных сетей и отдельных компьютеров через общедоступные сети (к примеру, через Интернет), требует качественного решения двух базовых задач:

  • Защиты подключенных к публичным каналам связи локальных сетей и отдельных компьютеров от несанкционированных действий со стороны внешней среды;

  • Защиты информации в процессе передачи по открытым каналам связи.

Рис. 1. Задачи по обеспечению безопасности информационного взаимодействия

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

Защита информации в процессе передачи по открытым каналам связи основана на выполнении следующих функций:



  • Аутентификации взаимодействующих сторон;

  • Криптографическом закрытии передаваемых данных;

  • Подтверждении подлинности и целостности доставленной информации;

  • Защите от повтора, задержки и удаления сообщений;

  • Защите от отрицания фактов отправления и приема сообщений.

Объединение локальных сетей и отдельных компьютеров через открытую сеть передачи данных в единую виртуальную сеть, обеспечивающую безопасность циркулирующих данных, называют защищенной виртуальной сетью (Virtual Private Network - VPN).

Рис. 2. Построение виртуальной сети на основе Internet

Организация виртуальных сетей на основе Интернет обладает рядом преимуществ:


  • Гарантирует высокое качество информационного обмена;

  • Обеспечивает масштабируемую поддержку удаленного доступа к ресурсам локальной сети;

  • Для организации удаленного доступа к локальной сети исключается необходимость наличия модемных пулов;

  • Использование Интернет для объединения локальных сетей значительно дешевле аренды каналов связи телефонных и других глобальных сетей.

Защита информации в процессе ее передачи по открытым каналам связи основана на построении защищенных виртуальных каналов связи, называемых защищенными туннелями или туннелями VPN.

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

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

Для независимости от прикладных протоколов и приложений защищенные виртуальные сети формируются на одном из более низких уровней модели ISO/OSI - канальном, сетевом или сеансовом. Канальному (второму) уровню соответствуют такие протоколы реализации VPN, как РРТР, L2F и L2TP. Сетевому (третьему) уровню - IPSec, сеансовому (пятому) уровню - SSL/TLS и SOCKS.


Туннелирование на канальном уровне

Протокол РРТР


Протокол РРТР (Point-to-Point Tunneling Protocol) разработан компанией Microsoft совместно с компаниями Ascend Communications, 3Com/Primary Access, ECI-Telematics и US Robotics. Этот протокол был представлен в рабочую группу "РРР Extentions" IETF в качестве претендента на стандартный протокол создания защищенного канала при доступе удаленных пользователей через публичные сети (в первую очередь Internet) к корпоративным сетям. Этот протокол получил статус проекта стандарта Internet, однако, в качестве стандарта так и не был утвержден. Сейчас рабочая группа IETF рассматривает возможность принятия в качестве стандарта протокол L2TP (Layer 2 Tunneling Protocol), который должен объединить лучшие стороны протокола РРТР с протоколом аналогичного назначения L2F (Layer 2 Forwarding), предложенного компанией Cisco.

Протокол РРТР позволяет создавать защищенные каналы для обмена данными по различным сетевым протоколам — IP, IPX или NetBEUI. Данные этих протоколов инкапсулируются с помощью протокола РРТР в пакеты протокола IP, с помощью которого переносятся в зашифрованном виде через любую сеть TCP/IP. Инкапсулируется исходный кадр РРР, поэтому протокол РРТР можно отнести к классу протоколов инкапсуляции канального уровня в сетевой.

Поскольку вся идея дистанционного доступа состоит в разрешении машине клиента подключаться по телефонной линии к машине сервера, соединение РРТР инициируется клиентом, который использует служебное средство Windows NT — Remote Access Service (RAS) — для установления РРР-соединения с поставщиком услуг Internet. Затем при активизированном соединении РРР с помощью сервера, подключенного к Internet и действующего как сервер RAS, клиент применяет RAS для выполнения второго соединения. На этот раз в поле номера телефона указывается IP-адрес (или доменное имя), и клиент, для того чтобы осуществить соединение, вместо СОМ-порта использует VPN-порт (VPN-порты конфигурируются на машинах клиента и сервера в процессе инсталляции РРТР).

В протоколе РРТР определено две схемы его применения.

Первая схема рассчитана на поддержание защищенного канала между сервером удаленного доступа ISP и пограничным маршрутизатором корпоративной сети (рис. 3).

Рис.3. Защищенный канал «провайдер-маршрутизатор корпоративной сети» на основе протокола РРТР.

В этом варианте компьютер удаленного пользователя не должен поддерживать протокол РРТР. Он связывается с сервером удаленного доступа RAS, установленного у ISP, с помощью стандартного протокола РРР и проходит первую аутентификацию у провайдера. RAS ISP должен поддерживать протокол РРТР. По имени пользователя RAS ISP должен найти в базе учетных данных пользователей IP-адрес маршрутизатора, являющегося пограничным маршрутизатором корпоративной сети данного пользователя. С этим маршрутизатором RAS ISP устанавливает сессию по протоколу РРТР. Протокол РРТР определяет некоторое количество служебных сообщений, которыми обмениваются взаимодействующие стороны, служебные сообщения передаются по протоколу TCP. RAS ISP передает маршрутизатору корпоративной сети идентификатор пользователя, по которому маршрутизатор снова аутентифицирует пользователя по протоколу CHAP. Если пользователь прошел вторичную аутентификацию (она для него прозрачна), то RAS ISP посылает ему сообщение об этом по протоколу РРР и пользователь начинает посылать свои данные в RAS ISP по протоколу IP, IPX или NetBIOS, упаковывая их в кадры РРР. RAS ISP осуществляет инкапсуляцию кадров РРР в пакеты IP, указывая в качестве адреса назначения адрес пограничного маршрутизатора, а в качестве адреса источника — свой собственный IP-адрес. Пакеты РРР шифруются с помощью секретного ключа, в качестве которого используется дайджест от пароля пользователя, который хранится в базе учетных данных RAS ISP для аутентификации по протоколу CHAP.

Пакеты, циркулирующие в рамках сессии РРТР, имеют следующий вид:



  • заголовок канального уровня, используемого внутри Internet (РРР, SLIP, Ethernet);

  • заголовок IP;

  • заголовок GRE;

  • исходный пакет РРР, включающий пакет IP, IPX или NetBEUI.

Для указания сведений о том, что внутри пакета IP находится инкапсулированный пакет РРР, используется стандартный для Internet заголовок GRE v.2 (RFC 1701 и 1702), используемый при инкапсуляции различного типа.

Microsoft предложила также и другую схему использования протокола РРТР, с помощью которой образуется защищенный канал между компьютером удаленного пользователя и пограничным маршрутизатором корпоративной сети, в качестве которого должен использоваться RAS Windows NT/2000/2003.

Эта схема приведена на рисунке 4.



Рис.4. Защищенный «канал клиент - маршрутизатор корпоративной сети» на основе протокола РРТР

В первый раз клиент звонит на сервер RAS ISP и устанавливает с ним связь по протоколу РРР, проходя аутентификацию одним из способов, поддерживаемых провайдером — по протоколам PAP, CHAP или с помощью терминального диалога.

После аутентификации у провайдера, пользователь вторично «звонит», на этот раз в сервер удаленного доступа корпоративной сети. Этот «звонок» отличается от обычного тем, что вместо телефонного номера указывается IP-адрес RAS Windows NT, подключенного к Internet со стороны корпоративной сети. При этом устанавливается сессия по протоколу РРТР между клиентским компьютером и RAS корпоративной сети. Клиент еще раз аутентифицируется, теперь на сервере RAS его сети, а затем начинается передача данных, как и в первом варианте.

При прямом соединении компьютера удаленного пользователя с Интернетом, например, при доступе из локальной сети, подключенной к Интернет, пользователь устанавливает удаленное соединения с помощью клиентской части сервиса удаленного доступа. Он обращается к серверу удаленного доступа, указывая его IP-адрес, и устанавливает с ним связь по протоколу РРТР. Функции сервера удаленного доступа может выполнять и пограничный маршрутизатор локальной сети. Протокол РРТР определяет некоторое количество служебных сообщений, которыми обмениваются взаимодействующие стороны.. После успешной аутентификации начинается процесс защищенного информационного обмена. Служебные сообщения передаются по протоколу TCP, порт 1723, а при передаче инкапсулированных пакетов РРР в заголовке IP устанавливается идентификатор протокола, равный 47.

Протокол L2F


Протокол эстафетной передачи на втором уровне (Layer 2 Forwarding — L2F) был разработан компанией Cisco Systems. Он обеспечивает туннелирование протоколов канального уровня (то есть фреймов High Level Data Link Control [HDLC], async HDLC или Serial Line Internet Protocol [SLIP] ) с использованием протоколов более высокого уровня, например, IP. С помощью таких туннелей можно разделить местоположение сервера удаленного доступа, к которому подключается пользователь, используя местные коммутируемые линии связи, и точки, где происходит непосредственная обработка протокола удаленного доступа (SLIP, РРР), и пользователь получает доступ в сеть. Эти туннели дают возможность использовать приложения, требующие удаленного доступа с частными адресами IP, IPX и AppleTalk через протокол SLIP/PPP по существующей инфраструктуре Интернет. Поддержка таких многопротокольных приложений виртуального удаленного доступа очень выгодна конечным пользователям и независимым поставщикам услуг, поскольку позволяет разделить на всех расходы на средства доступа и базовую инфраструктуру и дает возможность осуществлять доступ через местные линии связи. Кроме того, такой подход защищает инвестиции, сделанные в существующие приложения, работающие не по протоколу IP, предоставляя защищенный доступ к ним и в то же время поддерживая инфраструктуру доступа к Интернет.

Рис. 5. Пример виртуального удаленного доступа.


Протокол L2TP


Протоколы L2F и РРТР имеют сходную функциональность. Компании Cisco и Microsoft согласились вместе (в рамках IETF) разработать единый стандартный протокол, который получил название туннельного протокола второго уровня (Layer 2 Tunneling Protocol — L2TP). Обе компании будут и далее поддерживать свои собственные решения для виртуальных частных сетей (L2F и РРТР), а также путь перехода от этих решений к L2TP.

Подобно протоколам РРТР и L2F, протокол L2TP предусматривает 3 этапа формирования защищенного виртуального канала:



  • установление соединения с сервером удаленного доступа локальной сети;

  • аутентификация пользоватеся;

  • конфигурирование криптозащищенного туннеля.

Защита виртуальных каналов на сетевом уровне

Архитектура безопасности IPSec


Практически все механизмы сетевой безопасности могут быть реализованы на третьем уровне эталонной модели ISO/OSI. Более того, IP-уровень можно считать оптимальным для размещения защитных средств, поскольку при этом достигается удачный компромисс между защищенностью, эффективностью функционирования и прозрачностью для приложений. Стандартизованными механизмами IP-безопасности могут (и должны) пользоваться протоколы более высоких уровней и, в частности, управляющие протоколы, протоколы конфигурирования и маршрутизации.

Средства безопасности для IP описываются семейством спецификаций IPsec, разработанных рабочей группой IP Security. Протоколы IPsec обеспечивают управление доступом, целостность вне соединения, аутентификацию источника данных, защиту от воспроизведения, конфиденциальность и частичную защиту от анализа трафика. Основные составляющие архитектуры средств безопасности для IP представлены на Рис. 4. Это прежде всего протоколы обеспечения аутентичности (протокол аутентифицирующего заголовка Authentication Header, АН) и конфиденциальности (протокол инкапсулирующей защиты содержимого — Encapsulating Security Payload, ESP), а также механизмы управления криптографическими ключами. На более низком архитектурном уровне располагаются конкретные алгоритмы шифрования, контроля целостности и аутентичности. Наконец, роль фундамента выполняет так называемый домен интерпретации (Domain of Interpretation, DOI), являющийся по сути базой данных, хранящей сведения об алгоритмах, их параметрах, протокольных идентификаторах и т.п.



Рис. 6. - Архитектура IPSec.

Архитектура является основным документом, охватывающим все технологические аспекты и вопросы безопасности. Это своеобразная точка входа для начального понимания набора протоколов IPsec.

Протоколы ESP (Encapsulating Security Payload - протокол инкапсулирующей защиты содержимого) и АН (Authentication Header - протокол аутентифицирующего заголовка) представляют собой группу документов, детализирующих форматы и стандартную структуру пакетов, включая алгоритмы реализации.

Алгоритмы шифрования определяют использование различных методов шифрования, которые применяются протоколами ESP и АН

Алгоритмы аутентификации описывают процессы и технологии, предназначенные для механизма аутентификации для протоколов ESP и АН

Все эти документы специфицируют значения, которые должны быть объединены и определены в Области интерпретации (Domain of Interpretation -- DOI). DOI предоставляет центральный репозитарий для значений, позволяя различным документам устанавливать связи друг с другом. Он содержит параметры, которые необходимы для других частей протокола, чтобы обеспечить непротиворечивость определений



Протокол согласования параметров виртуального канала и управления ключами (Internet Security Association Management Protocol - ISAKMP) обеспечивает общее управление защищенным виртуальным соединением, включая согласование используемых алгоритмов криптозащиты, а также генерацию и распределение ключевой информации.

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

Алгоритмическая независимость протоколов имеет и оборотную сторону, состоящую в необходимости предварительного согласования набора применяемых алгоритмов и их параметров, поддерживаемых общающимися сторонами. Иными словами, стороны должны выработать общий контекст безопасности (Security Association, SA) и затем использовать элементы этого контекста, такие как алгоритмы и их ключи. За формирование контекстов безопасности в IPsec отвечает семейство протоколов ISAKMP.

Протоколы обеспечения аутентичности и конфиденциальности могут использоваться в двух режимах: транспортном и туннельном. В первом случае защищается только содержимое пакетов и некоторые поля заголовков. Как правило, транспортный режим используется хостами. В туннельном режиме защищается весь пакет — он инкапсулируется в другой IP-пакет. Туннельный режим обычно реализуют на специально выделенных защитных шлюзах (в роли которых могут выступать маршрутизаторы или межсетевые экраны). Схема функционирования в туннельном режиме представлена на Рис 2.7.



Рис. 7. Функционирование средств IP-безопасности в туннельном режиме.


Контексты безопасности и управление ключами


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

В принципе, для функционирования механизмов IPsec необходимы только протокольные контексты; управляющий контекст играет вспомогательную роль. Более того, явное выделение двух фаз утяжеляет и усложняет формирование ключей, если рассматривать последнее как однократное действие. Тем не менее, из архитектурных соображений управляющие контексты не только могут, но и должны существовать, поскольку они обслуживают все протокольные уровни стека TCP/IP, концентрируя в одном месте необходимую функциональность. Первая фаза начинается в ситуации, когда взаимодействующие стороны, вообще говоря, не имеют общих секретов (общих ключей) и не уверены в аутентичности друг друга. Если с самого начала не создать надежный путь, то для выполнения каждого управляющего действия с ключами (их модификация, выдача диагностических сообщений и т.п.) в каждом протоколе (АН, ESP, SSL и т.д.) этот путь придется формировать заново.


Управляющий контекст и управление ключами


Общие вопросы формирования контекстов безопасности и управления ключами освещаются в спецификации — "Контексты безопасности и управление ключами в Интернет" (Internet Security Association and Key Management Protocol, ISAKMP). Здесь вводятся две фазы выработки протокольных ключей, определяются виды управляющих информационных обменов и используемые форматы заголовков и данных. Иными словами, строится протокольно-независимый каркас. Существует несколько способов формирования управляющего контекста. Они различаются по двум показателям:

  • используемый механизм выработки общего секретного ключа;

  • степень защиты идентификаторов общающихся сторон.

В простейшем случае секретные ключи задаются заранее (по сути это ручной метод распределения ключей). Для небольших сетей такой подход вполне работоспособен, но он не является масштабируемым. Последнее свойство может быть обеспечено при использовании протоколов, основанных на алгоритме Диффи-Хелмана. Таковым является Протокол для обмена ключами в Интернет (The Internet Key Exchange, IKE).

При формировании управляющего контекста идентификаторы общающихся сторон (такие, например, как IP-адреса) могут передаваться в открытом виде или шифроваться. Поскольку ISAKMP предусматривает функционирование в режиме клиент/сервер (то есть ISAKMP-сервер может формировать контекст для клиента), сокрытие идентификаторов в определенной степени повышает защищенность от пассивного прослушивания сети.

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

Рис. 8. Формирование управляющего контекста

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

В сообщениях (3) и (4) инициатор и партнер отправляют свои части ключевого материала, необходимые для выработки общего секретного ключа. В случае алгоритма Диффи-Хелмана эти части имеют вид gXi и gXr, где g - генератор согласованной группы Диффи-Хелмана, a Xi и Хr -значения, выбранные, соответственно, инициатором и партнером. (Общий секрет при этом имеет вид g^xixr.) Одноразовые номера (попсе) представляют собой псевдослучайные величины, служащие для защиты от воспроизведения сообщений.



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

В представленном виде протокол формирования управляющего контекста защищает от атак, производимых нелегальным посредником, а также от нелегального перехвата соединений. Для защиты от атак на доступность, связанных прежде всего с навязыванием интенсивных вычислений, присущих криптографии с открытым ключом, используются так называемые идентифицирующие цепочки (cookies). Эти цепочки, формируемые инициатором и его партнером с использованием текущего времени (для защиты от воспроизведения), на самом деле присутствуют во всех ISAKMP-сообщениях и в совокупности идентифицируют управляющий контекст (в первом сообщении, по понятным причинам, фигурирует только цепочка инициатора). Согласно спецификациям , заголовок ISAKMP-сообщения имеет вид, изображенный на Рис.2.9. Если злоумышленник пытается "завалить" кого-либо запросами на создание управляющего контекста, подделывая при этом свой IP-адрес, то в сообщении (3) (см. Рис. 8.) он не сможет предъявить идентифицирующую цепочку партнера, так что до выполнения алгоритма Диффи-Хелмана и, тем более, до выработки электронной подписи и полномасштабной проверки аутентичности дело попросту не дойдет.



Рисунок 9. Формат заголовка ISAKMP-сообщения

Управляющие контексты являются двунаправленными в том смысле, что любая из общающихся сторон может инициировать с их помощью выработку новых протокольных контекстов или иные действия. Для передачи ISAKMP-сообщений в принципе может использоваться любой протокол, однако стандартным является UDP с номером порта 500.

Протокольные контексты и политика безопасности.


Системы, реализующие IPsec, должны поддерживать две базы данных:

  • база данных политики безопасности (Security Policy Database, SPD);

  • база данных протокольных контекстов безопасности (Security Association Database,
    SAD).

Все IP-пакеты (входящие и исходящие) сопоставляются с упорядоченным набором правил политики безопасности. При сопоставлении используется фигурирующий в каждом правиле селектор — совокупность анализируемых полей сетевого и более высоких протокольных уровней. Первое подходящее правило определяет дальнейшую судьбу пакета:

  • пакет может быть ликвидирован;

  • пакет может быть обработан без участия средств IPsec;

  • пакет должен быть обработан средствами IPsec с учетом набора протокольных
    контекстов, ассоциированных с правилом.

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

Протокольный контекст безопасности в IPsecэто однонаправленное "соединение" (от источника к получателю), предоставляющее обслуживаемым потокам данных набор защитных сервисов в рамках какого-то одного протокола (АН или ESP). В случае симметричного взаимодействия партнерам придется организовать как минимум два контекста (по одному в каждом направлении). Если используются и АН, и ESP, потребуется четыре контекста (см. Рис. 10).

Рисунок 10. Протокольные контексты безопасности, необходимые для двустороннего обмена данными с применением протоколов АН и ESP.

Элементы базы данных протокольных контекстов содержат следующие поля (в каждом конкретном случае часть значений полей будут пустыми):


  • используемый в АН алгоритм аутентификации, его ключи и т.п.;

  • используемый в ESP алгоритм шифрования, его ключи, начальный вектор и т.п.;

  • используемый в ESP алгоритм аутентификации, его ключи и т.п.;

  • время жизни контекста;

  • режим работы IPsec: транспортный или туннельный;

  • максимальный размер пакетов (MTU);

  • группа полей (счетчик, окно, флаги) для защиты от воспроизведения пакетов.

Пользователями протокольных контекстов, как правило, являются прикладные процессы. Вообще говоря, между двумя узлами сети может существовать произвольное число протокольных контекстов, так как произвольным является число приложений в узлах. Отметим, что в качестве пользователей управляющих контекстов обычно выступают узлы сети (поскольку в этих контекстах желательно сосредоточить общую функциональность, необходимую сервисам безопасности всех уровней модели ISO/OSI для управления криптографическими ключами). Управляющие контексты являются двусторонними, то есть любой из партнеров может инициировать новый ключевой обмен. В принципе, пара узлов может одновременно поддерживать несколько активных управляющих контекстов, если имеются приложения с существенно разными криптографическими требованиями. Например, допустима выработка части ключей на основе предварительно распределенного материала, в то время как другая часть порождается по алгоритму Диффи-Хелмана. На Рис. 2.11 изображена типичная комбинация управляющего и протокольных контекстов.

Рисунок 11. Множество протокольных контекстов, выработанных с использованием одного управляющего.



Протокольный контекст для IPsec идентифицируется целевым IP-адресом, протоколом (АН или ESP), а также дополнительной величиной — индексом параметров безопасности (Security Parameter Index, SPI). Последняя величина необходима, так как может существовать несколько контекстов с одинаковыми IP-адресами и протоколами (см. Рис. 11).

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

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

Рисунок 12. Формирование протокольного контекста.

Когда вырабатывался управляющий контекст, для него было создано три вида ключей:


  • SKEYID_d — ключевой материал, используемый для генерации протокольных ключей;

  • SKEYID_a — ключевой материал, используемый для аутентификации;

  • SKEYID_e — ключевой материал, используемый для шифрования.

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

Сообщения (1) и (2) могут нести дополнительную нагрузку, например, данные для выработки "совсем новых" ключей по алгоритму Диффи-Хелмана или идентификаторы клиентов, от имени которых ISAKMP-серверы формируют протокольный контекст. В соответствии с протоколом IKE, за один обмен (состоящий из трех показанных на Рис. 2.12 сообщений) формируется два однонаправленных контекста — по одному в каждом направлении. Получатель контекста задает для него индекс параметров безопасности (SPI), с помощью которого он (получатель) будет находить контекст для обработки принимаемых пакетов IPsec.

Строго говоря, протокольные контексты играют вспомогательную роль, являясь лишь средством проведения в жизнь политики безопасности. Политика безопасности должна быть задана для каждого сетевого интерфейса с задействованными средствами IPsec и для каждого направления потоков данных (входящие/исходящие). Согласно спецификациям IPsec , политика должна быть рассчитана на бесконтекстную (независимую) обработку IP-пакетов, в духе современных фильтрующих маршрутизаторов. Разумеется, должны существовать средства администрирования базы данных SPD, аналогично средствам администрирования базы правил межсетевого экрана, однако этот аспект не входит в число стандартизуемых.

С внешней точки зрения база данных политики безопасности (SPD) представляет собой упорядоченный набор правил. Каждое правило задается как пара:



  • совокупность селекторов;

  • совокупность протокольных контекстов безопасности.

Селекторы служат для отбора пакетов, контексты задают требуемую обработку. Если правило ссылается на несуществующий контекст, оно должно содержать достаточную информацию для его (контекста) динамического создания. Очевидно, в этом случае должно поддерживаться автоматическое управление контекстами и ключами. В принципе, функционирование системы может начинаться с задания базы SPD при пустой базе контекстов (SAD); последняя будет наполняться по мере необходимости.

Дифференцированность политики безопасности определяется селекторами, употребленными в правилах. Например, пара взаимодействующих хостов может использовать единственный набор контекстов, если в селекторах фигурируют только IP-адреса; с другой стороны, этот набор может быть своим для каждого приложения, если анализируются номера TCP- и UDP-портов. Аналогично, два защитных шлюза могут организовать единый туннель для всех обслуживаемых хостов или же расщепить его (путем организации разных контекстов) по парам хостов или даже приложений.

Все реализации IPsec должны поддерживать селекцию следующих элементов:



  • исходный и целевой IP-адреса (адреса могут быть индивидуальными и групповыми,
    допускается использование в правилах диапазонов адресов и метасимволов "любой";


  • имя пользователя или узла, в формате DNS или Х.500;

  • транспортный протокол;

  • номера исходного и целевого портов (здесь также могут использоваться диапазоны и
    метасимволы).


Обработка исходящего и входящего трафика, не является симметричной. Для исходящих пакетов просматривается база SPD, находится подходящее правило, извлекаются ассоциированные с ним протокольные контексты и применяются соответствующие механизмы безопасности. Во входящих пакетах для каждого защитного протокола уже проставлено значение SPI, однозначно определяющее контекст. Таким образом, просмотр базы SPD в этом случае не требуется; можно считать, что политика безопасности учитывалась при формировании соответствующего контекста. Практически это означает, что ISAKMP-пакеты нуждаются в особой трактовке, а правила с соответствующими селекторами должны быть включены в SPD.

Протокол АН.


Протокол аутентифицирующего заголовка (Authentication Header, АН) служит в IPsec для обеспечения целостности пакетов и аутентификации источника данных, а также для защиты от воспроизведения ранее посланных пакетов. АН защищает данные протоколов более высоких уровней, а также те поля IP-заголовков, которые не меняются на маршруте доставки или меняются предсказуемым образом. Число "непредсказуемых" полей невелико — это Pri. (Traffic Class), Flow Label и Hop Limit. Предсказуемо меняется целевой адрес при наличии дополнительного заголовка исходящей маршрутизации.

Формат заголовка АН показан на Рис. 13.



Рисунок 13. Формат заголовка АН.

Смысл полей, специфичных для АН.


  • Payload Len — длина заголовка АН в 32-битных словах минус 2.

  • SPI — 32-битное значение, выбираемое получателем пакетов с АН-заголовками в
    качестве идентификатора протокольного контекста

  • Sequence Number — беззнаковое 32-битное целое, наращиваемое от пакета к пакету.
    Отправитель обязан поддерживать этот счетчик, в то время как получатель может (но не
    обязан) использовать его для защиты от воспроизведения. При формировании
    протокольного контекста обе взаимодействующие стороны делают свои счетчики
    нулевыми, а потом согласованным образом увеличивают их. Когда значение Sequence
    Number становится максимально возможным, должен быть сформирован новый контекст
    безопасности.

  • Authentication Data — поле переменной длины, содержащее имитовставку
    (криптографическую контрольную сумму, Integrity Check Value, ICV) пакета. Способ
    вычисления этого поля определяется алгоритмом аутентификации.

Протокол АН может применяться в транспортном и туннельном режимах. На Рис. 2.14 изображен пакет IPv6 до и после применения АН в транспортном режиме. Здесь защищаются (аутентифицируются) все поля пакета, кроме непредсказуемо изменяющихся.

Рисунок 14. Пакет IPv6 до (а) и после (б) применения протокола АН в транспортном режиме.

В туннельном режиме внутренний (первоначальный) заголовок содержит целевой адрес пакета, в то время как во внешнем заголовке помещается адрес конца туннеля. АН помещается во внешний заголовок по тем же правилам, что и в транспортном режиме (см. Рис. 2.15), однако теперь обеспечивается аутентификация всего первоначального пакета, а также всех неизменяемых или предсказуемо изменяемых полей внешнего заголовка.

Рисунок 15. Пакет IPv6 до (а) и после (6) применения протокола АН в туннельном режиме.

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


  • HMAC-MD5 (Hashed Message Authentication Code - Message Digest version 5);

  • HMAC-SHA-1 (Hashed Message Authentication Code — Secure Hash Algorithm version 1).

Протокол ESP.


Протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload, ESP) предоставляет три вида сервисов безопасности:

  • обеспечение конфиденциальности (шифрование содержимого IP-пакетов, а также
    частичная защита от анализа трафика путем применения туннельного режима);

  • обеспечение целостности IP-пакетов и аутентификации источника данных;

  • обеспечение защиты от воспроизведения IP-пакетов.

Можно видеть, что функциональность ESP шире, чем у АН (добавляется шифрование). ESP не обязательно предоставляет все сервисы, но либо конфиденциальность, либо аутентификация должны быть задействованы. Формат заголовка ESP выглядит несколько необычно (см. Рис. 2.16). Причина в том, что это не столько заголовок, сколько обертка (инкапсулирующая оболочка) для зашифрованного содержимого. Например, поле Next Header нельзя выносить в начало, в незашифрованную часть, так как тогда оно лишится конфиденциальности.

Рисунок 16. Формат заголовка ESP.

Поля SPI, Sequence Number, Next Header и Authentication Data (присутствующее только при включенной аутентификации) имеют тот же смысл, что и для АН. Правда, ESP аутентифицирует лишь зашифрованную часть пакета (плюс два первых поля заголовка).

Применение протокола ESP к исходящим пакетам можно представлять себе следующим образом. Назовем остатком пакета ту его часть, которая помещается после предполагаемого места вставки заголовка ESP (см. Рис. 2.17). При этом не важно, какой режим используется — транспортный или туннельный. Шаги протокола таковы:



  • остаток пакета копируется в буфер;

  • к остатку приписываются дополняющие байты, их число и номер (тип) первого заголовка
    остатка, так чтобы номер был прижат к границе 32-битного слова, а размер буфера
    удовлетворял требованиям алгоритма шифрования;

  • текущее содержимое буфера шифруется;

  • в начало буфера приписываются поля SPI и Sequence Number с соответствующими
    значениями;

  • пополненное содержимое буфера аутентифицируется, в его конец помещается поле
    Authentication Data;

  • в новый пакет переписываются начальные заголовки старого пакета и конечное
    содержимое буфера (см. Рис. 2.17).

Рисунок 17. Пакет IPv6 до (а) и после (б) применения протокола ESP.

Таким образом, если в ESP включены и шифрование, и аутентификация, то аутентифицируется зашифрованный пакет. Для входящих пакетов действия выполняются в обратном порядке, то есть сначала производится аутентификация. Это позволяет не тратить ресурсы на расшифровку поддельных пакетов, что в какой-то степени защищает от атак на доступность.

Два защитных протокола — АН и ESP — могут комбинироваться разными способами. Если используется транспортный режим, то АН должен применяться после ESP (аналогично тому, как в рамках ESP аутентификация идет следом за шифрованием). В туннельном режиме АН и ESP применяются, строго говоря, к разным (вложенным) пакетам, так что число возможных комбинаций здесь больше (хотя бы потому, что возможна многократная вложенность туннелей с различными начальными и/или конечными точками).

Пусть, например, два хоста, HI и Н2, общаются через защитные шлюзы SG1 и SG2 (см. Рис. 2.18). Пусть, далее, хосты поддерживают взаимную аутентификацию в транспортном режиме, а защитные шлюзы реализуют и аутентификацию, и шифрование в туннельном режиме (как того требует реализация виртуальной частной сети). Тогда структуру IP-пакетов на отрезке между шлюзами можно представить в виде, показанном на Рис. 2.19.



Рисунок 2.19. Структура IP-пакетов на отрезке между защитными шлюзами.