Файл: Конспект лекций профессиональная образовательная программа.docx

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

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

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

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

В настоящий момент для протоколов АН и ESP зарегистрировано два алго­ритма аутентификации — HMAC-MD5 (Hashed Message Authentication Code - Message Digest version 5) и HMAC-SHA1 (Hashed Message Authentication Code — Secure Hash Algorithm version 1). Данные алгоритмы являются алгоритмами аутентификации с секретным ключом. Если секрет­ный ключ известен только передающей и принимающей сторонам, это обеспечит аутентификацию источника данных, а также целостность пакетов, пересылаемых между двумя сторонами. Алгоритмом, использующимся по умолчанию, определен алгоритм HMAC-MD5.

Для протокола ESP зарегистрировано семь алгоритмов шифрования. Алго­ритм шифрования DES (Data Encryption Standard), как и алгоритм НМАС-MD5, принят по умолчанию и необходим для обеспечения IPSec-совместимости. В качестве альтернативы DES определены алгоритмы Triple DES, CAST-128, RC5, IDEA, Blowfish и ARCFour [10].

Протоколы AH и ESP поддерживают работу в двух режимах:

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

---

В транспортном режиме в конверт IPSec в криптозащищенном виде помеща­ется только содержимое исходного IP-пакета и к полученному конверту до­бавляется исходный IP-заголовок. Соответственно в транспортном режиме заголовок IPSec размещается между сетевым (IP) и транспортным (TCP или UDP) заголовками обычного IP-пакета. Транспортный режим быстрее туннельного и разработан для применения на оконечных системах. Данный ре­жим может использоваться для поддержки удаленных и мобильных пользова­телей, а также защиты информационных потоков внутри локальных сетей.
Протокол АН. Туннельный режим. Протокол заголовка аутентификации АН [RFC1826], [RFC1827] предусматривает аутентификацию источника данных, проверку их целостности и подлинности после приема, а также защиту от навязывания повторных сообщений. В основе обеспечения целостности и аутентификации данных лежит шифрование с помощью односторонней функции (one-way function), называемой также хэш-функцией (hash function). В туннельном режиме внутренний (первоначальный) IP-заголовок содержит целевой адрес пакета, а внешний IP-заголовок содержит адрес конца туннеля (рис.3.2).


Рис.3.2 - Протокол AH в туннельном режиме
Параметры аутентификации рассчитываются с использованием всех полей дейтаграммы IP (включая не только заголовок IP, но и заголовки других протоколов, а также пользовательские данные), которые не могут изменяться в процессе доставки.

Транспортный режим. Протокол АН. При использовании протокола АН в транспортном режиме защита не на­кладывается лишь на те поля IP-заголовков, которые меняются на маршруте доставки непредсказуемым образом. К таким полям для протокола IPv4 от­носится поле Time to Live, задающее время жизни IP-пакета, а также поле Type of Service, определяющее тип его обслуживания. В транспортном режиме в кон­верт IPSec помещается только содержимое защищаемого IP-пакета и к полученному конверту добавляется исходный IP-заголовок (рис. 3.3).



Рис. 3.3. - Протокол AH в транспортно режиме.
Туннельный режим. Протокол ESP.Независимо от режима использования протокола ESP его заголовок формируется как инкапсулирующая оболочка для зашифрованного содержимого. При использовании протокола ESP в туннельном режиме каждый исходный IP-пакет вместе с концевиком ESP шифруется и в криптозащищенном виде с заголовком ESP помещается в конверт IPSec. Сформированный конверт IPSec, в свою очередь, инкапсулируется в новый IP-пакет. Применение протокола ESP в туннельном режиме без аутентификации AH показано на рис.3.4, а с аутентификацией – на рис.3.5.

---

Рис. 3.4 - Работа протокола ESP в туннельном режиме без AH.



Рис. 3.5 - Работа протокола ESP в туннельном режиме с AH.

Транспортный режим. Протокол ESP.В транспортном режиме передача IР-пакета через сеть выполняется с помощью оригинального заголовка. В транспортном режиме предусматриваются и криптографическое закрытие и аутентификация. К внутреннему содержимому исходного пакета присоединяется заголовок ESP и концевик ESP протокола и содержимое шифруется. Далее аутентифицируется зашифрованный пакет. Для входящих пакетов действия выполняются в обратном порядке, то есть сначала производится аутентификация. Работа протокола ESP в транспортном режиме без AH показана на рис.3.6, с применением АН – на рис.3.7.




Рис. 3.6 - Работа протокола ESP в транспортном режиме без AH.



Рис. 3.7 - Работа протокола ESP в транспортном режиме с AH.

Расположение полей заголовков протокольных блоков АН и ESP в транспортном и туннельном режимах показано на рис. 3.8. Заголовки протокольных блоков АН и ESP располагаются в транспортном режиме после заголовка исходного IP-пакета и перед заголовками протоколов верхних уровней, а в туннельном режиме – после заголовка внешнего IP-пакета и перед заголовком внутреннего исходного IP-пакета.

Транспортный режим	Туннельный режим
[IPисх.][AH][верх.]	[IPвнеш.][AH][IPисх.][ верх.]]
[IPисх][ESP][ верх.]	[IPвнеш.][ESP][IPисх.][ верх.]]
[IPисх.][AH][ESP][верх.]

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

---

3.1.3. Сеансовый уровень модели OSI

Защищенные виртуальные каналы могут быть сформированы и на сеансовом уровне модели OSI. Для этого применяются так называемые "посредники каналов" (circuit proxy). Посредник функционирует над транспортным уровнем, шифрует и ретранслирует трафик из защищенной сети в общедоступную сеть Internet для каждого сокета в отдельности. При приеме выполняется обратная процедура. Сокет IP идентифицируется комбинацией TCP-соединения и конкретного порта или заданным портом UDP.

Для шифрования информации на сеансовом уровне наибольшую популярность получил протокол SSL/TLS (Secure Sockets Layer/ Transport Layer Security), разработанный компанией Netscape Communications. Этот протокол создает защищенный туннель между конечными точками виртуальной сети, обеспечивая взаимную аутентификацию абонентов, а также конфиденциальность, подлинность и целостность циркулирующих по туннелю данных. Ядром протокола SSL/TLS является технология комплексного использования асимметричных и симметричных криптосистем компании RSA Data Security. Для аутентификации взаимодействующих сторон и криптозащиты ключа симметричного шифрования используются цифровые сертификаты открытых ключей пользователей (клиента и сервера), заверенные цифровыми подписями специальных Сертификационных Центров. Поддерживаются цифровые сертификаты, соответствующие общепринятому стандарту X.509.

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

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

---

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

Виртуальные сети с посредником канала типа IPSec ориентированы на протокол IP. Если IPSec, по существу, разграничивает защищенные виртуальные каналы между разными парами взаимодействующих сторон, то протокол SOCKS 5 обеспечивает создание защищенных туннелей для каждого приложения и сеанса в отдельности. Аналогично протоколу IPSec и протоколам туннелирования канального уровня, виртуальные сети сеансового уровня можно использовать с другими типами виртуальных частных сетей, поскольку данные технологии не являются взаимоисключающими.
3.1.4. Распределение криптографических ключей и согласование параметров защищенных туннелей

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

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

1. 
   Основные ключи, которые применяются в течение относительно долгого периода времени, например, недели, месяца или нескольких месяцев;
   
2. 
   Временные ключи, каждый из которых генерируется для криптозащиты информации в рамках одного защищенного канала.
   

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

---