IPsec VPN. Основы

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

В 1994 году Совет по архитектуре Интернет выпустил отчет “Безопасность архитектуры Интернет”. Данный отчет посвящался в основном проблемам защиты от несанкционированного мониторинга, подмены пакетов и управлению потоками данных. Требовалась разработка некоторого стандарта, способного решить все эти проблемы. В результате были созданы стандарты протоколов, в число которых входил IPsec.

IPsec (сокр. IP Security) – группа протоколов, предназначенных для обеспечения защиты данных, передаваемых по IP-сети. Задача IPsec сводится к тому, чтобы выбрать конкретные алгоритмы и механизмы и настроить соответствующим образом устройства, участвующие в создании безопасного соединения. IPsec находит применение в организации VPN-соединений.

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

  1. Аутентифицировать друг друга
  2. Сгенерировать и обменяться ключами
  3. Договориться с помощью каких протоколов шифровать данные
  4. Начать передавать данные в зашифрованный туннель

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

IKE (Internet Key Exchange) – протокол обмена ключами.

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

Первая фаза (основной режим):

  1. Обмен параметрами безопасности IKE-соединения (алгоритмы и хэш-функции)
  2. На каждом конце туннеля генерируются общий секретный ключ
  3. Используя алгоритм Деффи-Хеллмана , стороны обмениваются общим секретным ключом
  4. Аутентификация обеих концов туннеля

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

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

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

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

  • Выбирается IPSec-протокол: AH (Authentication Header) и/или ESP (Encapsulation Security Payload)
  • Выбирается алгоритм для шифрования данных: DES, 3DES, AES
  • Выбирается алгоритм для аутентификации: SHA, MD5
  • Выбирается режим работы: туннельный или транспортный
  • Устанавливается время жизни IPSec-туннеля
  • Определяется трафик, который будет пускаться через VPN-туннель

AH (Authentication Header) – протокол IPSec, предназначенный для аутентификации. По сути это обычный опциональный заголовок, располагающийся между основным заголовком IP-пакета и полем данных. Предназначение AH – обеспечение защиты от атак, связанных с несанкционированным изменением данных в IP-пакете, в частности подмены исходного адреса сетевого уровня.

ESP (Encapsulation Security Payload) – протокол IPSec, предназначенный для шифрования данных. Дословно переводится как “поле данных безопасной инкапсуляции”. Также как и AH представляет из себя опциональный заголовок, вкладываемый в IP-пакет. Основной целью ESP является обеспечение конфиденциальности данных.

Вы могли заметить, что ESP и AH имеют разные форматы в зависимости от типа используемого режима: туннельного и транспортного.

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

Транспортный режим применяется, как правило, в локальной сети при защите соединения между хостами. Этот режим обеспечивает защиту данных IP-пакета (TCP, UDP, протоколы верхних уровней). Грубо говоря, транспортный режим инкапсулирует все, что находится выше сетевого уровня эталонной модели OSI, при этом не затрагивая сам IP-заголовок. Естественно в таком случае данные IP-пакета: адрес источника и получателя будут видны извне.

Теперь перейдем к практике: настроим защищенный IPSec-туннель между двумя маршрутизаторами Cisco. Схема будет состоять из трех последовательно соединенных маршрутизаторов, при этом крайние R1 и R3 представляют из себя маршрутизаторы для локальных сетей, а центральный R2 имитирует Интернет. Прежде всего необходимо настроить связность между двумя локальными подсетями. Связность обеспечивается за счет GRE-туннеля. Про GRE-туннели я писал в , также там есть конфигурация GRE-туннеля для маршрутизаторов Cisco. Чтобы понимать логику дальнейший действий настоятельно рекомендую ознакомиться с этим материалом.

Итак, основной GRE-туннель у нас “прокинут”. Он не является защищенным и поэтому поверх него мы будем настраивать IPSec. Мы работали вот с такой схемой.

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

Конфигурация для Router A

Создаем политику безопасности и настраиваем ее RouterA(config)#crypto isakmp policy 1 Указываем метод шифрования (симметричный блочный шифр) RouterA(config)#encryption 3des Указываем метод хеширования MD5 RouterA(config)#hash md5 Указываем метод аутентификации (с предварительным ключом) RouterA(config)#authentication pre-share Выходим из режима редактирования политики безопасности RouterA(config)#exit Ключ для аутентификации (должен совпадать для обеих точек) RouterA(config)#crypto isakmp key PASS address 33.33.33.33 Применение набора преобразований RouterA(config)#crypto ipsec transform-set LAN1 esp-3des esp-md5-hmac Указываем режим работы IPSec (туннельный режим) RouterA(cfg-crypto-trans)#mode tunnel RouterA(cfg-crypto-trans)#exit Создаем крипто-карту (детали туннелирования) RouterA(config)#crypto map MAP1 10 ipsec-isakmp Указываем Ip-адрес маршрутизатора, с которым устанавливаем VPN RouterA(config-crypto-map)#set peer 33.33.33.33 Указываем набор политик безопасности RouterA(config-crypto-map)#set transform-set LAN1 Шифровать данные, которые будут проходить через список доступа под номером 100 RouterA(config-crypto-map)#match address 100 Выходим из режима настройки крипто-карты RouterA(config-crypto-map)#exit GRE-трафик с хоста 11.11.11.11 на хост 33.33.33.33 подлежит шифрованию RouterA(config)#access-list 100 permit gre host 11.11.11.11 host 33.33.33.33 Переходим в режим настройки внешнего интерфейса RouterA(config)#interface fa 0/1 Привязка карты шифрования MAP1 к внешнему интерфейсу RouterA(config-if)#crypto map MAP1

Аналогично настраивается Router B:

RouterB(config)#crypto isakmp policy 1 RouterB(config)#encryption 3des RouterB(config)#hash md5 RouterB(config)#authentication pre-share RouterB(config)#exit RouterB(config)#crypto isakmp key PASS address 11.11.11.11 RouterB(config)#crypto ipsec transform-set LAN2 esp-3des esp-md5-hmac RouterB(cfg-crypto-trans)#mode tunnel RouterB(cfg-crypto-trans)#exit RouterB(config)#crypto map MAP2 10 ipsec-isakmp RouterB(config-crypto-map)#set peer 11.11.11.11 RouterB(config-crypto-map)#set transform-set LAN2 RouterB(config-crypto-map)#match address 100 RouterB(config-crypto-map)#exit RouterB(config)#access-list 100 permit gre host 33.33.33.33 host 11.11.11.11 RouterB(config)#interface fa 0/1 RouterB(config-if)#crypto map MAP2

Поддержите проект

Друзья, сайт Netcloud каждый день развивается благодаря вашей поддержке. Мы планируем запустить новые рубрики статей, а также некоторые полезные сервисы.

У вас есть возможность поддержать проект и внести любую сумму, которую посчитаете нужной.

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

Протокол работает на сетевом уровне модели OSI и, соответственно, он "прозрачен" для приложений. Иными словами, на работу приложений (таких как web- сервер , браузер , СУБД и т.д.) не влияет, используется ли защита передаваемых данных с помощью IPSec или нет.

Операционные системы семейства Windows 2000 и выше имеют встроенную поддержку протокола IPSec. С точки зрения многоуровневой модели защиты, этот протокол является средством защиты уровня сети.


Рис. 5.9.

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

Процесс защищенной передачи данных регулируется правилами безопасности, принятыми в системе. Параметры создаваемого туннеля описывает информационная структура, называемая контекст защиты или ассоциация безопасности (от англ. Security Association , сокр. SA ). Как уже отмечалось выше, IPSec является набором протоколов, и состав SA может различаться, в зависимости от конкретного протокола. SA включает в себя:

  • IP-адрес получателя;
  • указание на протоколы безопасности, используемые при передаче данных;
  • ключи, необходимые для шифрования и формирования имитовставки (если это требуется);
  • указание на метод форматирования, определяющий, каким образом создаются заголовки;
  • индекс параметров защиты (от англ. Security Parameter Index, сокр. SPI ) - идентификатор, позволяющий найти нужный SA.

Обычно, контекст защиты является однонаправленным, а для передачи данных по туннелю в обе стороны задействуются два SA . Каждый хост имеет свою базу SA , из которой выбирается нужный элемент либо на основании SPI , либо по IP -адресу получателя.

Два протокола, входящие в состав IPSec это:

  1. протокол аутентифицирующего заголовка - AH (от англ. Authentication Header), обеспечивающий проверку целостности и аутентификацию передаваемых данных; последняя версия протокола описана в RFC 4302 (предыдущие - RFC 1826, 2402);
  2. протокол инкапсулирующей защиты данных - ESP (от англ. Encapsulating Security Payload ) - обеспечивает конфиденциальность и, дополнительно, может обеспечивать проверку целостности и аутентификацию, описан в RFC 4303 (предыдущие - RFC 1827, 2406).

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

Транспортный режим ориентирован на соединение хост - хост . При использовании ESP в транспортном режиме защищаются только данные IP -пакета, заголовок не затрагивается. При использовании AH защита распространяется на данные и часть полей заголовка. Более подробно режимы работы описаны ниже.

Протокол AH

В IP ver .4 аутентифицирующий заголовок располагается после IP-заголовка. Представим исходный IP-пакет как совокупность IP-заголовка, заголовка протокола следующего уровня (как правило, это TCP или UDP, на рис. 5.10 он обозначен как ULP - от англ. Upper-Level Protocol) и данных.


Рис. 5.10.

Рассмотрим формат заголовка ESP ( рис. 5.13). Он начинается с двух 32-разрядных значений - SPI и SN . Роль их такая же, как в протоколе AH - SPI идентифицирует SA, использующийся для создания данного туннеля; SN - позволяет защититься от повторов пакетов. SN и SPI не шифруются.

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


Рис. 5.12.


Рис. 5.13.

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

Если ESP используется и для аутентификации данных, то завершает пакет поле переменной длины, содержащее ICV. В отличие от AH, в ESP при расчете значения имитовставки , поля IP-заголовка (нового - для туннельного режима, модифицированного старого - для транспортного) не учитываются.

При совместном использовании протоколов AH и ESP , после IP заголовка идет AH, после него - ESP . В этом случае, ESP решает задачи обеспечения конфиденциальности, AH - обеспечения целостности и аутентификации источника соединения.

Рассмотрим ряд дополнительных вопросов, связанных с использованием IPSec. Начнем с того, откуда берется информация о параметрах соединения - SA. Создание базы SA может производиться различными путями. В частности, она может создаваться администратором безопасности вручную, или формироваться с использованием специальных протоколов - SKIP , ISAKMP ( Internet Security Association and Key Management Protocol) и IKE (Internet Key Exchange).

IPSec и NAT

При подключении сетей организаций к Интернет, часто используется механизм трансляции сетевых адресов - NAT ( Network Address Translation ). Это позволяет уменьшить число зарегистрированных IP-адресов, используемых в данной сети. Внутри сети используются незарегистрированные адреса (как правило, из диапазонов, специально выделенных для этой цели, например, адреса вида 192.168.x.x для сетей класса C). Если пакет из такой сети передается в Интернет, то маршрутизатор, внешнему интерфейсу которого назначен по крайней мере один зарегистрированный ip-адрес, модифицирует ip-заголовки сетевых пакетов, подставляя вместо частных адресов зарегистрированный адрес. То, как производится подстановка, фиксируется в специальной таблице. При получении ответа, в соответствии с таблицей делается обратная замена и пакет переправляется во внутреннюю сеть.

Рассмотрим пример использования NAT рис. 5.14 . В данном случае, во внутренней сети используются частные адреса 192.168.0.x. С компьютера, с адресом 192.168.0.2 обращаются во внешнюю сеть к компьютеру с адресом 195.242.2.2. Пусть это будет подключение к web-серверу (протокол HTTP, который использует TCP порт 80).

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

В конце шестидесятых годов американское агентство перспективных исследований в обороне DARPA приняло решение о создании экспериментальной сети под названием ARPANet. В семидесятых годах ARPANet стала считаться действующей сетью США, и через эту сеть можно было получить доступ к ведущим университетским и научным центрам США. В начале восьмидесятых годов началась стандартизация языков программирования, а затем и протоколов взаимодействия сетей. Результатом этой работы стала разработка семиуровневой модели сетевого взаимодействия ISO/OSI и семейства протоколов TCP/IP, которое стало основой для построения как локальных, так и глобальных сетей.

Базовые механизмы информационного обмена в сетях TCP/IP были в целом сформированы в начале восьмидесятых годов, и были направлены прежде всего на обеспечение доставки пакетов данных между различными операционными системами с использованием разнородных каналов связи. Несмотря на то, что идея создания сети ARPANet (впоследствии превратившейся в современный Интернет) принадлежала правительственной оборонной организации, фактически сеть зародилась в исследовательском мире, и наследовала традиции открытости академического сообщества. Ещё до коммерциализации Интернета (которая произошла в середине девяностых годов) многие авторитетные исследователи отмечали проблемы, связанные с безопасностью стека протоколов TCP/IP. Основные концепции протоколов TCP/IP не полностью удовлетворяют (а в ряде случаев и противоречат) современным представлениям о компьютерной безопасности.

До недавнего времени сеть Интернет использовалась в основном для обработки информации по относительно простым протоколам: электронная почта, передача файлов, удалённый доступ. Сегодня, благодаря широкому распространению технологий WWW, всё активнее применяются средства распределённой обработки мультимедийной информации. Одновременно с этим растёт объём данных, обрабатываемых в средах клиент/сервер и предназначенных для одновременного коллективного доступа большого числа абонентов. Разработано несколько протоколов прикладного уровня, обеспечивающих информационную безопасность таких приложений, как электронная почта (PEM, PGP и т.п.), WWW (Secure HTTP, SSL и т.п.), сетевое управление (SNMPv2 и т.п.). Однако наличие средств обеспечения безопасности в базовых протоколах семейства TCP/IP позволит осуществлять информационный обмен между широким спектром различных приложений и сервисных служб.

Краткая историческая справка появления протокола

В 1994 году Совет по архитектуре Интернет (IAB) выпустил отчет "Безопасность архитектуры Интернет". В этом документе описывались основные области применения дополнительных средств безопасности в сети Интернет, а именно защита от несанкционированного мониторинга, подмены пакетов и управления потоками данных. В числе первоочередных и наиболее важных защитных мер указывалась необходимость разработки концепции и основных механизмов обеспечения целостности и конфиденциальности потоков данных. Поскольку изменение базовых протоколов семейства TCP/IP вызвало бы полную перестройку сети Интернет, была поставлена задача обеспечения безопасности информационного обмена в открытых телекоммуникационных сетях на базе существующих протоколов. Таким образом, начала создаваться спецификация Secure IP, дополнительная по отношению к протоколам IPv4 и IPv6.

Архитектура IPSec

IP Security — это комплект протоколов, касающихся вопросов шифрования, аутентификации и обеспечения защиты при транспортировке IP-пакетов; в его состав сейчас входят почти 20 предложений по стандартам и 18 RFC.

Спецификация IP Security (известная сегодня как IPsec) разрабатывается Рабочей группой IP Security Protocol IETF . Первоначально IPsec включал в себя 3 алгоритмо-независимые базовые спецификации, опубликованные в качестве RFC-документов "Архитектура безопасности IP", "Аутентифицирующий заголовок (AH)", "Инкапсуляция зашифрованных данных (ESP)" (RFC1825, 1826 и 1827). Необходимо заметить, что в ноябре 1998 года Рабочая группа IP Security Protocol предложила новые версии этих спецификаций, имеющие в настоящее время статус предварительных стандартов, это RFC2401 — RFC2412. Отметим, что RFC1825-27 на протяжении уже нескольких лет считаются устаревшими и реально не используются. Кроме этого, существуют несколько алгоритмо-зависимых спецификаций, использующих протоколы MD5, SHA, DES.

Рис. 1 – Архитектура IPSec.

Рабочая группа IP Security Protocol разрабатывает также и протоколы управления ключевой информацией. В задачу этой группы входит разработка Internet Key Management Protocol (IKMP), протокола управления ключами прикладного уровня, не зависящего от используемых протоколов обеспечения безопасности. В настоящее время рассматриваются концепции управления ключами с использованием спецификации Internet Security Association and Key Management Protocol (ISAKMP) и протокола Oakley Key Determination Protocol. Спецификация ISAKMP описывает механизмы согласования атрибутов используемых протоколов, в то время как протокол Oakley позволяет устанавливать сессионные ключи на компьютеры сети Интернет. Ранее рассматривались также возможности использования механизмов управления ключами протокола SKIP, однако сейчас такие возможности реально практически нигде не используются. Создаваемые стандарты управления ключевой информацией, возможно, будут поддерживать Центры распределения ключей, аналогичные используемым в системе Kerberos . Протоколами ключевого управления для IPSec на основе Kerberos сейчас занимается относительно новая рабочая группа KINK (Kerberized Internet Negotiation of Keys).

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

По сути, IPSec, который станет составной частью IPv6, работает на третьем уровне, т. е. на сетевом уровне. В результате передаваемые IP-пакеты будут защищены прозрачным для сетевых приложений и инфраструктуры образом. В отличие от SSL (Secure Socket Layer), который работает на четвертом (т. е. транспортном) уровне и теснее связан с более высокими уровнями модели OSI, IPSec призван обеспечить низкоуровневую защиту.


Рис. 2 — Модель OSI/ISO.

К IP-данным, готовым к передаче по виртуальной частной сети, IPSec добавляет заголовок для идентификации защищенных пакетов. Перед передачей по Internet эти пакеты инкапсулируются в другие IP-пакеты. IPSec поддерживает несколько типов шифрования, в том числе Data Encryption Standard (DES) и Message Digest 5 (MD5).

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

С текущей версией IP, IPv4, могут быть использованы или Internet Secure Association Key Management Protocol (ISAKMP), или Simple Key Management for Internet Protocol. С новой версией IP, IPv6, придется использовать ISAKMP, известный сейчас как IKE, хотя не исключается возможность использования SKIP. Однако, следует иметь в виду, что SKIP уже давно не рассматривается как кандидат управления ключами, и был исключён из списка возможных кандидатов ещё в 1997 г.

Заголовок AH

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

Формат AH достаточно прост и состоит из 96-битового заголовка и данных переменной длины, состоящих из 32-битовых слов. Названия полей достаточно ясно отражают их содержимое: Next Header указывает на следующий заголовок, Payload Len представляет длину пакета, SPI является указателем на контекст безопасности и Sequence Number Field содержит последовательный номер пакета.


Рис. 3 — Формат заголовка AH.

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

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

Заголовок ESP

В случае использования инкапсуляции зашифрованных данных заголовок ESP является последним в ряду опциональных заголовков, "видимых" в пакете. Поскольку основной целью ESP является обеспечение конфиденциальности данных, разные виды информации могут требовать применения существенно различных алгоритмов шифрования. Следовательно, формат ESP может претерпевать значительные изменения в зависимости от используемых криптографических алгоритмов. Тем не менее, можно выделить следующие обязательные поля: SPI, указывающее на контекст безопасности и Sequence Number Field, содержащее последовательный номер пакета. Поле "ESP Authentication Data" (контрольная сумма), не является обязательным в заголовке ESP. Получатель пакета ESP расшифровывает ESP заголовок и использует параметры и данные применяемого алгоритма шифрования для декодирования информации транспортного уровня.


Рис. 4 — Формат заголовка ESP.

Различают два режима применения ESP и AH (а также их комбинации) — транспортный и туннельный.

Транспортный режим

Транспортный режим используется для шифрования поля данных IP пакета, содержащего протоколы транспортного уровня (TCP, UDP, ICMP), которое, в свою очередь, содержит информацию прикладных служб. Примером применения транспортного режима является передача электронной почты. Все промежуточные узлы на маршруте пакета от отправителя к получателю используют только открытую информацию сетевого уровня и, возможно, некоторые опциональные заголовки пакета (в IPv6). Недостатком транспортного режима является отсутствие механизмов скрытия конкретных отправителя и получателя пакета, а также возможность проведения анализа трафика. Результатом такого анализа может стать информация об объемах и направлениях передачи информации, области интересов абонентов, расположение руководителей.

Туннельный режим

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

Security Associations

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

Политика безопасности

Политика безопасности хранится в SPD (База данных политики безопасности). SPD может указать для пакета данных одно из трёх действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA.

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

ISAKMP/Oakley

Протокол ISAKMP определяет общую структуру протоколов, которые используются для установления SA и для выполнения других функций управления ключами. ISAKMP поддерживает несколько Областей Интерпретации (DOI), одной из которых является IPSec-DOI. ISAKMP не определяет законченный протокол, а предоставляет "строительные блоки" для различных DOI и протоколов обмена ключами.

Протокол Oakley — это протокол определения ключа, использующий алгоритм замены ключа Диффи-Хеллмана. Протокол Oakley поддерживает идеальную прямую безопасность (Perfect Forward Secrecy — PFS). Наличие PFS означает невозможность расшифровки всего траффика при компрометации любого ключа в системе.

IKE

IKE — протокол обмена ключами по умолчанию для ISAKMP, на данный момент являющийся единственным. IKE находится на вершине ISAKMP и выполняет, собственно, установление как ISAKMP SA, так и IPSec SA. IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).

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

Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC — механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая хэш функция (обозначим её как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования — как L (L

Ipad = байт 0x36, повторённый B раз;
opad = байт 0x5C, повторённый B раз.

Для вычисления HMAC от данных "text" необходимо выполнить следующую операцию:

H(K XOR opad, H(K XOR ipad, text))

Из описания следует, что IKE использует для аутентификации сторон HASH величины. Отметим, что под HASH в данном случае подразумевается исключительно название Payload в ISAKMP, и это название не имеет ничего общего со своим содержимым.

Атаки на AH, ESP и IKE.

Все виды атак на компоненты IPSec можно разделить на следующие группы: атаки, эксплуатирующие конечность ресурсов системы (типичный пример — атака "Отказ в обслуживании", Denial-of-service или DOS-атака), атаки, использующие особенности и ошибки конкретной реализации IPSec и, наконец, атаки, основанные на слабостях самих протоколов. AH и ESP. Чисто криптографические атаки можно не рассматривать — оба протокола определяют понятие "трансформ", куда скрывают всю криптографию. Если используемый криптоалгоритм стоек, а определенный с ним трансформ не вносит дополнительных слабостей (это не всегда так, поэтому правильнее рассматривать стойкость всей системы — Протокол-Трансформ-Алгоритм), то с этой стороны все нормально. Что остается? Replay Attack — нивелируется за счет использования Sequence Number (в одном единственном случае это не работает — при использовании ESP без аутентификации и без AH). Далее, порядок выполнения действий (сначала шифрация, потом аутентификация) гарантирует быструю отбраковку "плохих" пакетов (более того, согласно последним исследованиям в мире криптографии, именно такой порядок действий наиболее безопасен, обратный порядок в некоторых, правда очень частных случаях, может привести к потенциальным дырам в безопасности; к счастью, ни SSL, ни IKE, ни другие распространенные протоколы с порядком действий "сначала аутентифицировать, потом зашифровать", к этим частным случаям не относятся, и, стало быть, этих дыр не имеют). Остается Denial-Of-Service атака. Как известно, это атака, от которой не существует полной защиты. Тем не менее, быстрая отбраковка плохих пакетов и отсутствие какой-либо внешней реакции на них (согласно RFC) позволяют более-менее хорошо справляться с этой атакой. В принципе, большинству (если не всем) известным сетевым атакам (sniffing, spoofing, hijacking и т.п.) AH и ESP при правильном их применении успешно противостоят. С IKE несколько сложнее. Протокол очень сложный, тяжел для анализа. Кроме того, в силу опечаток (в формуле вычисления HASH_R) при его написании и не совсем удачных решений (тот же HASH_R и HASH_I) он содержит несколько потенциальных "дыр" (в частности, в первой фазе не все Payload в сообщении аутентифицируются), впрочем, они не очень серьезные и ведут, максимум, к отказу в установлении соединения.От атак типа replay, spoofing, sniffing, hijacking IKE более-менее успешно защищается. С криптографией несколько сложнее, — она не вынесена, как в AH и ESP, отдельно, а реализована в самом протоколе. Тем не менее, при использовании стойких алгоритмов и примитивов (PRF), проблем быть не должно. В какой-то степени можно рассматривать как слабость IPsec то, что в качестве единственного обязательного к реализации криптоалгоритма в нынешних спецификациях указывается DES (это справедливо и для ESP, и для IKE), 56 бит ключа которого уже не считаются достаточными. Тем не менее, это чисто формальная слабость — сами спецификации являются алгоритмо-независимыми, и практически все известные вендоры давно реализовали 3DES (а некоторые уже и AES).Таким образом, при правильной реализации, наиболее "опасной" атакой остается Denial-Of-Service.

Оценка протокола

Протокол IPSec получил неоднозначную оценку со стороны специалистов. С одной стороны, отмечается, что протокол IPSec является лучшим среди всех других протоколов защиты передаваемых по сети данных, разработанных ранее (включая разработанный Microsoft PPTP). По мнению другой стороны, присутствует чрезмерная сложность и избыточность протокола. Так, Niels Ferguson и Bruce Schneier в своей работе "A Cryptographic Evaluation of IPsec" отмечают, что они обнаружили серьёзные проблемы безопасности практически во всех главных компонентах IPsec. Эти авторы также отмечают, что набор протоколов требует серьёзной доработки для того, чтобы он обеспечивал хороший уровень безопасности. В работе приведено описание ряда атак, использующих как слабости общей схемы обработки данных, так и слабости криптографических алгоритмов.

Заключение

В этой статье мы рассмотрели некоторые основные моменты, касающиеся протокола сетевой безопасности IPsec. Не лишним будет отметить, что протокол IPsec доминирует в большинстве реализаций виртуальных частных сетей. В настоящее время на рынке представлены как программные реализации (например, протокол реализован в операционной системе Windows2000 компании Microsoft), так и программно-аппаратные реализации IPsec — это решения Cisco , Nokia . Несмотря на большое число различных решений, все они довольно хорошо совместимы друг с другом. В заключение статьи приводится таблица, в которой производится сравнение IPSec и широко распространённого сейчас SSL.

Особенности IPSec SSL
Аппаратная независимость Да Да
Код Не требуется изменений для приложений. Может потребовать доступ к исходному коду стека TCP/IP. Требуются изменения в приложениях. Могут потребоваться новые DLL или доступ к исходному коду приложений.
Защита IP пакет целиком. Включает защиту для протоколов высших уровней. Только уровень приложений.
Фильтрация пакетов Основана на аутентифицированных заголовках, адресах отправителя и получателя, и т.п. Простая и дешёвая. Подходит для роутеров. Основана на содержимом и семантике высокого уровня. Более интеллектуальная и более сложная.
Производительность Меньшее число переключений контекста и перемещения данных. Большее число переключений контекста и перемещения данных. Большие блоки данных могут ускорить криптографические операции и обеспечить лучшее сжатие.
Платформы Любые системы, включая роутеры В основном, конечные системы (клиенты/серверы), также firewalls.
Firewall/VPN Весь трафик защищён. Защищён только трафик уровня приложений. ICMP, RSVP, QoS и т.п. могут быть незащищены.
Прозрачность Для пользователей и приложений. Только для пользователей.
Текущий статус Появляющийся стандарт. Широко используется WWW браузерами, также используется некоторыми другими продуктами.

Ссылки

  • www.ietf.org/html.charters/ipsec-charter.html — Домашняя страничка рабочей группы IETF. Там же находятся ссылки на RFC и предложения по стандартам.
  • www.microsoft.com/rus/windows2000/library/security/w2k_IPSecurity.asp – Информация о реализации протокола IPSec в Windows2000 Server.

Благодарности

Вконтакте

Одноклассники

Протоколы IPSec Организация защищенного канала https://www.сайт/lan/protokoly-ipsec https://www.сайт/@@site-logo/logo.png

Протоколы IPSec

Организация защищенного канала

Протоколы IPSec

Организация защищенного канала с помощью AH, ESP и IKE.

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

Основное назначение протоколов IPSec - обеспечение безопасной передачи данных по сетям IP. Применение IPSec гарантирует:

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

(Заметим, что в соответствии с классическим определением понятие безопасности данных включает еще одно требование - доступность данных, что в рассмотренном контексте может быть интерпретировано как гарантия их доставки. Протоколы IPSec не решают данную задачу, оставляя ее протоколу транспортного уровня TCP.)

ЗАЩИЩЕННЫЕ КАНАЛЫ НА РАЗНЫХ УРОВНЯХ

IPSec - это только одна из многих, хотя и самая популярная на сегодня, технология безопасной передачи данных по общедоступной (незащищенной) сети. Для технологий такого назначения используется обобщенное название - защищенный канал (secure channel). Термин «канал» подчеркивает тот факт, что защита данных обеспечивается между двумя узлами сети (хостами или шлюзами) вдоль некоторого виртуального пути, проложенного в сети с коммутацией пакетов.

Защищенный канал можно построить с помощью системных средств, реализованных на разных уровнях модели OSI (см. Рисунок 1). Если для защиты данных используется протокол одного из верхних уровней (прикладного, презентационного или сеансового), то такой способ защиты не зависит от того, какие сети (IP или IPX, Ethernet или ATM) применяются для транспортировки данных, что можно считать несомненным достоинством. С другой стороны, приложение при этом становится зависимым от конкретного протокола защиты, т. е. для приложений такой протокол не является прозрачным.

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

Наиболее известным протоколом защищенного канала, работающим на следующем, презентационном уровне, стал протокол Secure Socket Layer (SSL) и его новая открытая реализация Transport Layer Security (TLS). Снижение уровня протокола превращает его в гораздо более универсальное средство защиты. Теперь единым протоколом защиты могут воспользоваться любые приложения и любые протоколы прикладного уровня. Однако приложения необходимо переписывать по-прежнему - в них должны быть встроены явные вызовы функций протокола защищенного канала.

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

Рассмотрим, например, протокол защищенного канала Point-to-Point Tunneling Protocol (PPTP), работающий на канальном уровне. Он основан на протоколе PPP, который широко используется в соединениях «точка-точка», например при работе по выделенным линиям. Протокол PPTP не только обеспечивает прозрачность средств защиты для приложений и служб прикладного уровня, но и не зависит от применяемого протокола сетевого уровня: в частности, протокол PPTP может переносить пакеты как в сетях IP, так и в сетях, работающих на основе протоколов IPX, DECnet или NetBEUI. Однако, поскольку протокол PPP используется далеко не во всех сетях (в большинстве локальных сетей на канальном уровне работает протокол Ethernet, а в глобальных - протоколы ATM, frame relay), то PPTP нельзя считать универсальным средством.

Работающий на сетевом уровне протокол IPSec является компромиссным вариантом. С одной стороны, он прозрачен для приложений, а с другой - он может работать практически во всех сетях, так как основан на широко распространенном протоколе IP: в настоящее время в мире только 1% компьютеров не поддерживает IP вообще, остальные 99% используют его либо как единственный протокол, либо в качестве одного из нескольких протоколов.

РАСПРЕДЕЛЕНИЕ ФУНКЦИЙ МЕЖДУ ПРОТОКОЛАМИ IPSEC

Ядро IPSec составляют три протокола: протокол аутентификации (Authenti-cation Header, AH), протокол шифрования (Encapsulation Security Payload, ESP) и протокол обмена ключами (Internet Key Exchange, IKE). Функции по поддержанию защищенного канала распределяются между этими протоколами следующим образом:

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

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

Для шифрования данных в IPSec может быть применен любой симметричный алгоритм шифрования, использующий секретные ключи. В основе обеспечения целостности и аутентификации данных также лежит один из приемов шифрования - шифрование с помощью односторонней функции (one-way function), называемой также хэш-функцией (hash function) или дайджест-функцией (digest function).

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

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

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

БЕЗОПАСНАЯ АССОЦИАЦИЯ

Для того чтобы протоколы AH и ESP могли выполнять свою работу по защите передаваемых данных, протокол IKE устанавливает между двумя конечными точками логическое соединение, которое в стандартах IPSec носит название «безопасная ассоциация» (Security Association, SA). Установление SA начинается со взаимной аутентификации сторон, потому что все меры безопасности теряют смысл, если данные передаются или принимаются не тем или не от того лица. Выбираемые далее параметры SA определяют, какой из двух протоколов, AH или ESP, применяется для защиты данных, какие функции выполняет протокол защиты: например, только аутентификацию и проверку целостности или, кроме того, еще и защиту от ложного воспроизведения. Очень важным параметром безопасной ассоциации является так называемый криптографический материал, т. е. секретные ключи, используемые в работе протоколов AH и ESP.

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

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

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

Для обеспечения совместимости в стандартной версии IPsec определен некоторый обязательный «инструментальный» набор: в частности, для аутентификации данных всегда может быть использована одна из функций односторонней шифрации MD5 либо SHA-1, а в число алгоритмов шифрования непременно входит DES. При этом производители продуктов, включающих IPSec, вольны расширять протокол за счет других алгоритмов аутентификации и шифрования, что они с успехом и делают. Например, многие реализации IPSec поддерживают популярный алгоритм шифрования Triple DES, а также сравнительно новые алгоритмы - Blowfish, Cast, CDMF, Idea, RC5.

Стандарты IPSec позволяют шлюзам использовать как одну ассоциацию SA для передачи трафика всех взаимодействующих через Internet хостов, так и создавать для этой цели произвольное число ассоциаций SA, например по одной на каждое соединение TCP. Безопасная ассоциация SA представляет собой в IPSec однонаправленное (симплексное) логическое соединение, поэтому при двустороннем обмене данными необходимо установить две ассоциации SA.

ТРАНСПОРТНЫЙ И ТУННЕЛЬНЫЙ РЕЖИМЫ

Протоколы AH и ESP могут защищать данные в двух режимах: транспортном и туннельном. В транспортном режиме передача IP-пакета через сеть выполняется с помощью оригинального заголовка этого пакета, а в туннельном режиме исходный пакет помещается в новый IP-пакет и передача данных по сети выполняется на основании заголовка нового IP-пакета. Применение того или иного режима зависит от требований, предъявляемых к защите данных, а также от роли, которую играет в сети узел, завершающий защищенный канал. Так, узел может быть хостом (конечным узлом) или шлюзом (промежуточным узлом). Соответственно, имеются три схемы применения IPSec: «хост-хост», «шлюз-шлюз» и «хост-шлюз».

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

В соответствии со второй схемой, защищенный канал устанавливается между двумя промежуточными узлами, так называемыми шлюзами безопасности (Security Gateway, SG), на каждом из которых работает протокол IPSec. Защищенный обмен данными может происходить между любыми двумя конечными узлами, подключенными к сетям, которые расположены позади шлюзов безопасности. От конечных узлов поддержка протокола IPSec не требуется, они передают свой трафик в незащищенном виде через заслуживающих доверие сети Intranet предприятий. Трафик, направляемый в общедоступную сеть, проходит через шлюз безопасности, который и обеспечивает его защиту с помощью IPSec, действуя от своего имени. Шлюзы могут использовать только туннельный режим работы.

Схема «хост-шлюз» часто применяется при удаленном доступе. Здесь защищенный канал организуется между удаленным хостом, на котором работает IPSec, и шлюзом, защищающим трафик для всех хостов, входящих в сеть Intranet предприятия. Удаленный хост может использовать при отправке пакетов шлюзу как транспортный, так и туннельный режим, шлюз же отправляет пакет хосту только в туннельном режиме. Эту схему можно усложнить, создав параллельно еще один защищенный канал - между удаленным хостом и каким-либо хостом, принадлежащим внутренней сети, защищаемой шлюзом. Такое комбинированное использование двух SA позволяет надежно защитить трафик и во внутренней сети.

Наталья Олифер

Операции с документом