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

Отличие протокола ESP от протокола Authentication Header (AH) состоит в том, что ESP выполняет шифрование данных. При этом оба протокола обеспечивают идентификацию, проверку целостности и защиту от воспроизведения информации. При работе с ESP для шифрования и расшифровки данных обе конечные системы применяют общий ключ.

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

Два способа использования ESP

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

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

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

Алгоритм защиты информации, применяемый ESP

В протоколе ESP применяется симметричный ключ, с помощью которого данные зашифровываются и расшифровываются конечными системами. Перед обменом данными отправитель и получатель должны согласовать ключ, который они будут применять. Функция VPN поддерживает способы шифрования DES, тройной DES (3DES), RC5, RC4, AES или AES-CBC.

При использовании алгоритма шифрования AES можно включить Расширенный порядковый номер (ESN). ESN позволяет передавать большие объемы данных с высокой скоростью. Соединение VPN применяет 64-битовые порядковые номера вместо 32-битовых номеров над IPSec. Использование 64-битовых порядковых номеров увеличивает период времени до смены ключа, что предотвращает окончание пула порядковых номеров и снижает расход системных ресурсов.

Рабочая группа Internet (IETF) формально описывает алгоритмы в следующих документах RFC:

Эти и другие документы RFC можно найти в Internet на следующем веб-сайте: http://www.rfc-editor.org.

Протокол ESP поддерживает алгоритмы идентификации HMAC-MD5, HMAC-SHA, HMAC-SHA-256 и AES-XCBC-MAC. Оба алгоритма получают на входе данные переменной длины и личный ключ, а на их основе создают данные фиксированной длины (или значение хэш-функции или MAC). Если значения хэш-функции, вычисленные для двух сообщений, совпадают, то с высокой вероятностью эти сообщения одинаковые.

Рабочая группа Internet (IETF) формально описывает алгоритмы в следующих документах RFC:

Эти документы RFC можно просмотреть на следующем веб-сайте: http://www.rfc-editor.org.

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

Введение

VPN основанный на технологии IPsec можно разделить на две части:

• Протокол Internet Key Exchange (IKE)
• Протоколы IPsec (AH/ESP/both)

Первая часть (IKE) является фазой согласования, во время которой две VPN-точки выбирают какие методы будут использоваться для защиты IP трафика посылаемого между ними. Помимо этого IKE также используется для управления соединениями, для этого вводится понятие Security Associations (SA) для каждого соединения. SA направлены только в одну сторону, поэтому типичное IPsec соединение использует два SA.

Вторая часть – это те IP данные, которые необходимо зашифровать и аутентифицировать перед передачей методами, согласованными в первой части (IKE). Существуют разные протоколы IPsec, которые могут быть использованы: AH, ESP или оба.

Последовательность установления VPN через IPsec можно кратко описать как:

• IKE согласовывает защиту уровня IKE
• IKE согласовывает защиту уровня IPsec
• защищаемые данные передаются через VPN IPsec

IKE, Internet Key Exchange

Для шифрования и аутентификации данных требуется выбрать способ шифрования/аутентификации (алгоритм) и ключи используемые в них. Задача Internet Key Exchange protocol, IKE, в этом случае сводится к распространению данных “ключей сессии” и согласованию алгоритмов, которыми будут защищаться данные между VPN-точками.

Основные задачи IKE:

• Аутентификация VPN-точек друг друга
• Организация новых IPsec соединений (через создание SA пар)
• Управление текущими соединениями

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

Процесс согласования IKE проходит через несколько этапов (фаз). Данные фазы включают:

1. IKE первой фазы (IKE Phase-1):
   — Согласовывается защита самого IKE (ISAKMP tunnel)
2. IKE второй фазы (IKE Phase-2):
   — Согласовывается защита IPsec
   — Получение данных из первой фазы для формирования ключей сессии

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

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

IKE первой фазы – согласование защиты IKE (ISAKMP Tunnel)
На первой фазе согласования VPN-точки аутентифицируют друг друга на основе общего ключа (Pre-Shared Key). Для аутентификации используются хэш алгоритм: MD5, SHA-1, SHA-2.
Однако перед тем как аутентифицировать друг друга, чтобы не передавать информацию открытым текстом, VPN-точки выполняют обмен списками предложений (Proposals), описанный ранее. Только после того как устраивающее обеих VPN-точек предложение выбрано, происходит аутентификация VPN-точка друг друга.
Аутентификацию можно осуществлять разными способами: через общие ключи (Pre-Shared Keys), сертификаты или . Общие ключи являются наиболее распространенным способом аутентификации.
Согласование IKE первой фазы может происходить в одном из двух режимов: main (основной) и aggressive (агресивный). Основной режим более длительный, но зато и более защищенный. В его процесее происходит обмен шестью сообщениями. Агресивный режим происходит быстрее, ограничиваясь тремя сообщениями.
Основная работа первой фазы IKE лежит в обмене ключами Диффи-Хеллмана. Он основан на шифровании с открытым ключем, каждая из сторон шифрует аутентификационный параметр (Pre-Shared Key) открытым ключем соседа, который получив данное сообщение расшифровывает его своим закрытым ключем. Другой способо аутентификации сторон друг друга — использование сертификатов.

IKE второй фазы – согласование защиты IPsec
Во второй фазе осуществляется выбор способа защиты IPsec подключения.
Для работы второй фазы используется материал (keying material) извлеченный из обмена ключами Диффи-Хеллмана (Diffie-Hellman key exchange), произошедшего на первой фазе. На основе этого материала создаются ключи сессии (session keys), использующиеся для защиты данных в VPN-туннеле.

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

Режим работы второй фазы согласования IKE только один, он называется quick mode — быстрый режим. В процессе согласования второй фазы происходит обмен тремя сообщениями.

По окончании второй фазы, устанавливается VPN-подключение.

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

• Идентификация конечных узлов
  Каким образом узлы аутентифицируют друг друга. Наиболее часто используется общий ключ. Аутентификация основанная на общем ключе использует алгоритм Диффи-Хеллмана.
• Локальная и удаленная сеть/хост
  Определяет трафик, который будет пускаться через VPN-туннель.
• Режим туннеля или транспорта.
  IPsec может работать в двух режимах: туннельном и транспортном. Выбор режима зависит от защищаемых объектов.
  Туннельный режим применяется для защиты между удаленными объектами, т.е. IP-пакет полностью инкапсулируется в новый и для наблюдателя со стороны будет видно только соединение между двумя VPN-точками. Реальные IP-адреса источника и получателя будут видны только после декапсуляции пакета при приеме его на VPN-точке получения. Таким образом туннельный режим чаще всего используется для VPN-подключений.
  Транспортный режим защищает данные IP-пакета (TCP, UDP и протоколы верхних уровней), а сам заголовок оригинального IP-пакета будет сохранен. Таким образом для наблюдателя будет виден оригинальный источник и назначение, но не передаваемые данные. Данный режим наиболее часто используется при защите соединение в локальной сети между хостами.
• Удаленный шлюз
  VPN-точка получатель защищенного соединения, которая будет расшифровывать/аутентифицировать данные с другой стороны и отправлять их к окончательному месту назначения.
• Режим работы IKE
  IKE согласование может работать в двух режимах: основной и агрессивном .
  Разница между ними заключается в том, что в агрессивном режиме используется меньшее кол-во пакетом, что позволяет достичь более быстрого установления соединения. С другой стороны агрессивный режим не передает некоторые параметры согласования, такие как Диффи-Хеллман группы и PFS, что требует предварительной идентичной настройки их на точках участницах подключения.
• IPsec протоколы
  Существует два протокола IPsec: Authentication Header (AH) и Encapsulating Security Payload (ESP), которые выполняют функции шифрования и аутентификации.
  ESP позволяет шифровать, аутентифицировать по отдельности или одновременно.
  AH позволяет только аутентифицировать. Разница с ESP аутентификацией в том, что AH аутентифицирует также и внешний IP заголовок, позволяя подтвердить, что пакет прибыл действительно от источника указанного в нем.
• IKE шифрование
  Указывает используемый алгоритм шифрования IKE и его ключи. Поддерживаются разные симметричные алгоритмы шифрования, например: DES, 3DES, AES.
• IKE аутентификация
  Алгоритм аутентификации используемый в IKE согласовании. Могут быть: SHA, MD5.
• IKE Диффи-Хеллмана (DH) группы
  Используемая DF группа для обмена ключами в IKE. Чем больше группа тем больше размер ключей обмена.
• Продолжительность жизни IKE подключения
  Указывается как по времени (секундах), так и по размеру переданных данных (килобайтах). Как только один из счетчиков достигнет порогового значения запускается новая первая фаза. Если с момента создания IKE соединения не было передано никаких данных, никаких новых подключений не будет создано до тех пор, пока одна из сторон не захочет создать VPN соединение.
• PFS
  При отключенном PFS материал для создания ключей будет извлечен в первой фазе согласования IKE в момент обмена ключей. Во второй фазе согласования IKE ключи сессии будут созданы основываясь на полученном материале. При включенном PFS при создании новых ключей сессии материал для них будет использоваться каждый раз новый. Таким образом при компромате ключа, на основе него не возможно создать новые ключи.
  PFS может быть использован в двух режимах: первый PFS на ключах (PFS on keys), будет запускать новый обмен ключами в первой фазе IKE каждый раз, когда запускается согласование
  второй фазы. Второй режим PFS на идентификаторах (PFS on identities), будет удалять SA первой фазы каждый раз, после прохождения согласования второй фазы, гарантируя тем самым, что ни одно согласование второй фазы не будет зашифровано идентичным предыдущему ключом.
• IPsec DH группы
  Данные DF группы аналогичны использующимся в IKE, только используются для PFS.
• IPsec шифрование
  Алгоритм использующийся для шифрования данных. Используется в случае использования ESP в режиме шифрования. Пример алгоритмов: DES, 3DES, AES.
• IPsec аутентификация
  Алгоритм используемый для аутентификации передаваемых данных. Используется в случае AH или ESP в режиме аутентификации. Пример алгоритмов: SHA, MD5.
• Время жизни IPsec
  Время жизни VPN соединения указывается как по времени (секундах) так и по размеру переданных данных (килобайты). Счетчик первым достигнувший лимита запустит пересоздание ключей сессии. Если с момента создания IKE соединения не было передано никаких данных, никаких новых подключений не будет создано до тех пор, пока одна из сторон не захочет создать VPN соединение.

Методы аутентификации IKE

• Ручной режим
  Самый простой из методов, при котором IKE не используется, а ключи аутентификации и шифрования, а также некоторые другие параметры задаются в ручную на обоих точках VPN подключения.
• Через общие ключи (Pre-Shared Keys, PSK)
  Заранее введенный общий ключ на обоих точках VPN соединения. Отличие от предыдущего метода в том, что используется IKE, что позволяет аутентифицировать конечные точки и использовать меняющиеся ключи сессии, вместо фиксированных ключей шифрования.
• Сертификаты
  Каждая точка VPN использует: свой приватный ключ, свой открытый ключ, свой сертификат включающий свой открытый ключ и подписанный доверенным центром сертификации. В отличие от предыдущего метода позволяет избежать ввода одного общего ключа на всех точках VPN соединения, заменяя его личными сертификатами, подписанными доверенным центром.

Протоколы IPsec

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

AH (Authentication Header)

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

В режиме транспорта, AH встраивает свой заголовок после оригинального IP пакета.
В режиме туннеля AH встраивает свой заголовок после внешнего (нового) IP-заголовка и перед внутренним (оригинальным) IP заголовком.

ESP (Encapsulating Security Payload)

ESP протокол используется для шифрования, для аутентификации или и того, и другого по отношению к IP пакету.

В режиме транспорта ESP протокол вставляет свой заголовок после оригинально IP заголовка.
В режиме туннеля ESP заголовок находится после внешнего (нового) IP заголовка и перед внутренним (оригинальным).

Два основных различия между ESP и AH:

• ESP помимо аутентификации предоставляет еще возможность шифрования (AH этого не предоставляет)
• ESP в режиме туннеля аутентифицирует только оригинальный IP заголовок (AH аутентифицирует также внешний).

Работа за NAT (NAT Traversal)
Для поддержки работы за NAT была реализована отдельная спецификация. Если VPN-точка поддерживает данную спецификацию, IPsec поддерживает работу за NAT, однако существуют определённые требования.
Поддержка NAT состоит из двух частей:

• На уровне IKE конечные устройства обмениваются друг с другом информацией о поддержке, NAT Traversal и версией поддерживаемой спецификации
• На уровне ESP сформированный пакет инкапсулируется в UDP.

NAT Traversal используется только в том случае, если обе точки поддерживают его.
Определение NAT : обе VPN-точки посылают хеши своих IP адресов вместе с UDP портом источника IKE согласования. Данная информация используется получателем, для того чтобы определить был ли изменен IP адрес и/или порт источника. Если данные параметры не были изменены, то трафик не проходит через NAT и механизм NAT Traversal не нужен. Если адрес или порт были изменены, значит между устройствами находится NAT.

Как только конечные точки определят, что необходим NAT Traversal, согласование IKE перемещаются с порта UDP 500 на порт 4500. Делается это потому, что некоторые устройства некорректно обрабатывают IKE сессию на 500 порту при использовании NAT.
Другая проблема возникает из-за того, что ESP протокол – протокол транспортного уровня и располагается непосредственно поверх IP. Из-за этого к нему не применимы понятия TCP/UDP порта, что делает невозможным подключение через NAT более одного клиента к одному шлюзу. Для решения данной проблемы ESP запаковывается в UDP дейтаграмму и посылается на порт 4500, тот же самый, который использует IKE при включенном NAT Traversal.
NAT Traversal встроен в работу протоколов, его поддерживающих и работает без предварительной настройки.

pre-shared key : Два даемона racoon подключаются друг к другу, подтверждают, что они именно те, за кого себя выдают (используя секретный ключ, заданный вами, по умолчанию в файле /etc/racoon/psk.txt). Затем даемоны генерируют новый секретный ключ и используют его для шифрования трафика через VPN. Они периодически изменяют этот ключ, так что даже если атакующий сломает один из ключей (что теоретически почти невозможно) это не даст ему слишком много – он сломал ключ, который два даемона уже сменили на другой. Предварительный ключ(pre-shared key) не используется для шифрования трафика через VPN соединение это просто маркер, позволяющий управляющим ключами даемонам доверять друг другу. Права на файл psk.txt должны быть 0600 (т.е. запись и чтение только для root).

IPsec состоит из двух протоколов:

Encapsulated Security Payload (ESP), защищающей данные IP пакета от вмешательства третьей стороны путем шифрования содержимого с помощью симметричных криптографических алгоритмов (таких как Blowfish,3DES, AES).

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

ESP и AH могут быть использованы вместе или по отдельности, в зависимости от обстоятельств.

esp и ah - пакеты ipsec, формируются ядром после того как хосты, при помощи racoon, договорятся о ключе по протоколу isakmp (500/udp).

Режимы работы IPsec(транспортный, туннельный)

Существует два режима работы IPsec: транспортный режим и туннельный режим(когда в транспортном режиме работают только маршрутизаторы).

IPsec может быть использован или для непосредственного шифрования трафика между двумя хостами (транспортный режим); или для построения "виртуальных туннелей" между двумя подсетями, которые могут быть использованы для защиты соединений между двумя корпоративными сетями (туннельный режим). Туннельный режим обычно называют виртуальной частной сетью (Virtual Private Network, vpn).

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

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

Если используется IPsec совместно с GRE туннели , который инкапсулирует исходный пакет и добавляет новый IP заголовок, логично использовать транспортный режим.

Режимы IPsec не являются взаимоисключающими. На одном и том же узле некоторые SA могут использовать транспортный режим, а другие - туннельный.

Security Associations (SA) . Для возможности проводить инкапсуляцию/декапсуляцию стороны участвующие в процессе обмена должны иметь возможность хранить секретные ключи, алгоритмы и IP адреса. Вся эта информация хранится в Ассоциациях Безопасности (SA), SA в свою очередь хранятся в Базе данных Ассоциаций Безопасности (SAD). Конфигурирование Security Association , позволяет задать например mode transport | tunnel | ro | in_trigger | beet - режим безопасной ассоциации. Соответственно, может принимать одно из значений, означающих транспортный, тоннельный, beet (Bound End-to-End Tunnel), оптимизации маршрута (route optimization) или in_trigger режимы. (последние два используются в контексте mobile ipv6).

Security Policy (SP) - политика безопасности, хранится в SPD (База данных политик безопасности). SA специфицирует, как IPsec предполагает защищать трафик, SPD в свою очередь хранит дополнительную информацию, необходимую для определения какой именно трафик защищать и когда. SPD может указать для пакета данных одно из трёх действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA. SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета. Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные SA будут использоваться для каждого приложения, или даже для каждого TCP соединения.

IPSec (сеть-сеть) между серверами FreeBSD

Шаг 1 : Создание и тестирование "виртуального" сетевого подключения.

• Настройте оба ядра с device gif . В версии FreeBSD поддержка gif включена в ядро.

  Отредактируйте /etc/rc.conf на маршрутизаторах и добавьте следующие строки (подставляя IP адреса где необходимо). A.B.C.D - реальный IP первого маршрутизатора, W.X.Y.Z - реальный IP второго маршрутизатора. # IPsec №1 gateway > ee /etc/rc.conf ... # IPsec to S through ISP_V gif_interfaces="gif0" # gifconfig_gif0="local-ip(A.B.C.D) remote-ip (W.X.Y.Z)" gifconfig_gif0="194.x.x.x 91.x.x.x" ifconfig_gif0="inet 10.26.95.254 192.168.1.254 netmask 255.255.255.255" static_routes="vpn vpn1" route_vpn="-net 192.168.1.0/24 192.168.1.254" route_vpn1="-net 192.168.35.0/24 192.168.1.254" # IPsec №2 gateway > ee /etc/rc.conf ... # IPsec na G through ISPGate gif_interfaces="gif0" # gifconfig_gif0="W.X.Y.Z A.B.C.D" gifconfig_gif0="91.x.x.x 194.x.x.x" ifconfig_gif0="inet 192.168.1.254 10.26.95.254 netmask 255.255.255.255" static_routes="vpn" route_vpn="-net 10.26.95.0/24 10.26.95.254"

  Отредактируйте скрипт брандмауэра на обеих маршрутизаторах и добавьте # IPFW ipfw add 1 allow ip from any to any via gif0 # PF set skip on gif0

Теперь ping должны ходить между сетями.

Защита соединения с помощью IPsec

Шаг 2 : Защита соединения с помощью IPsec

• Настройте оба ядра: > sysctl -a | grep ipsec

  если команда ничего не вывела, значит нужно пересобрать ядра на обоих маршрутизаторах с параметрами

  # IPSEC for FreeBSD 7.0 and above options IPSEC options IPSEC_FILTERTUNNEL device crypto # IPSEC for FreeBSD 6.3 options IPSEC # IP security options IPSEC_ESP # IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG # Необязательно. debug for IP security

  Устанавливаем порт ipsec-tools. > cd /usr/ports/security/ipsec-tools > make config > make install clean > ee /etc/rc.conf racoon_enable="YES" ipsec_enable="YES" > mkdir -p /usr/local/etc/racoon/cert > cp /usr/local/share/examples/ipsec-tools/racoon.conf /usr/local/etc/racoon/racoon.conf > cd /usr/local/etc/racoon/cert/

  Создаем SSL сертификаты на каждом хосте. Копируем с одной на другую файлики *.public. В принципе, имена ключей неважны, можно называть и по IP, с соответствующими расширениями.

  > openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout your.key1.private -outform PEM -out your.key1.pem > openssl x509 -req -in your.key1.pem -signkey your.key.private -out your.key1.public

Создаем файл ipsec.conf. Настройка на шлюзе #1 (где есть публичный IP адрес A.B.C.D) для включения шифрования всего предназначенного W.X.Y.Z трафика. A.B.C.D/32 и W.X.Y.Z/32 это IP адреса и сетевые маски, определяющие сети или хосты, к которым будет применяться данная политика. В данном случае мы хотим применить их к трафику между этими двумя хостами. Параметр ipencap сообщает ядру, что эта политика должна применяться только к пакетам, инкапсулирующим другие пакеты. Параметр -P out сообщает, что эта политика применяется к исходящим пакетам, и ipsec – то, что пакеты будут зашифрованы.

Оставшаяся часть строки определяет, как эти пакеты будут зашифрованы. Будет использоваться протокол esp, а параметр tunnel показывает, что пакет в дальнейшем будет инкапсулирован в IPsec пакет. Повторное использование A.B.C.D и W.X.Y.Z предназначено для выбора используемых параметров безопасности, и наконец параметр require разрешает шифрование пакетов, попадающих под это правило.

Это правило соответствует только исходящим пакетам. Вам потребуется похожее правило, соответствующее входящим пакетам.

> ee /etc/ipsec.conf spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;

Настройка на шлюзе #2 аналогична только меняются IP местами.

Настройка утилиты racoon

> ee /usr/local/etc/racoon/racoon.conf path include "/usr/local/etc/racoon"; path certificate "/usr/local/etc/racoon/cert/"; # following line activates logging & should deactivated later log debug; # если директива listen не задана, racoon слушает все доступные # адреса интерфейсов. listen { #isakmp::1 ; isakmp 202.249.11.124 ; #admin ; # administrative port for racoonctl. #strict_address; # requires that all addresses must be bound. } # описываем удалённый хост (на второй машине - идентично, # тока другой IP и ключи) remote 217.15.62.200 { exchange_mode aggressive,main; my_identifier asn1dn; peers_identifier asn1dn; # сертификаты этой машины certificate_type x509 "via.epia.public" "via.epia.private"; # сертификат удлённой машины peers_certfile x509 "test.su.public"; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig; dh_group 2 ; } } sainfo anonymous { pfs_group 2; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; }

Настройка пакетного фильтра PF, где esp_peers шлюз с которым создается шифрованный туннель. Разрешаем прохождение пакетов ESP и IPENCAP в обе стороны.

#pass IPSec pass in on $ext_if_a inet proto udp from { $esp_peers } to ($ext_if_a) port isakmp pass in on $ext_if_a inet proto esp from { $esp_peers } to ($ext_if_a) # pass out on $ext_if_a inet proto udp from { $esp_peers } to ($ext_if_a) port isakmp pass out on $ext_if_a inet proto esp from { $esp_peers } to ($ext_if_a)

Cмотрим логи /var/log/security и /var/log/messages.

Как только параметры безопасности установлены, вы можете просмотреть их используя setkey(8). Запустите

> /etc/rc.d/ipsec start > /usr/local/etc/rc.d/racoon start > setkey -D # список созданных защищенных каналов > setkey -DP # покажет список политик безопасности

на любом из хостов для просмотра информации о параметрах безопасности.

Проверка работоспособности:

ping между сетями должен работать

Запускаем для прослушки физического интерфейса на котором построен туннель (а не виртуального gif0). В другом окне например ping -ем удаленную серую сеть (например, ping 192.168.1.11) tcpdump -i em0 -n host 91 .x.x.81 ... 16 :15 :54.419117 IP x.x.x.x >

tcpdump Linux примеры использования должен показывать ESP пакеты.

IPSec (сеть-сеть) между серверами Linux

# aptitude install ipsec-tools racoon

Алгоритм настройки IPsec

Настройка пакета racoon

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

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

Ниже приведены конфиги для случая с предопределёнными ключами.

> nano /etc/racoon/racoon.conf path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; #path certificate "/etc/racoon/certs"; remote 10.5.21.23 { exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; my_identifier address; #Определяет метод идентификации, который будет использоваться при проверке подлинности узлов. lifetime time 2 min; initial_contact on; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; # Определяет метод проверки подлинности, используемый при согласовании узлов. dh_group 2; } proposal_check strict; } sainfo anonymous # Отмечает, что SA может автоматически инициализировать соединение с любым партнёром при совпадении учётных сведений IPsec. { pfs_group 2; lifetime time 2 min ; encryption_algorithm 3des, blowfish 448, des, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; }

Создадим политику безопасности

> nano pol.cfg #!/sbin/setkey -f flush; spdflush; spdadd 10.5.21.24 10.5.21.23 any -P out ipsec esp/transport//require; spdadd 10.5.21.23 10.5.21.24 any -P in ipsec esp/transport//require; > chmod +x pol.cfg > ./pol.cfg

Создадим выполняемый файл для создания интерфейсов и запустим его.

>nano tun.sh #!/bin/sh ip tunnel del tun0 ip tunnel add tun0 mode ipip remote 10.5.21.23 local 10.5.21.24 dev eth0 # создаем интерфейс tun0 и устанавливаем туннель # между хостами (здесь нужно использовать реальные IP адреса сетевых интерфейсов). ifconfig tun0 10.0.9.1 pointopoint 10.0.9.2 # назначаем интерфейсу IP адреса, для текущего хоста и для другого конца # туннеля (не обязательно). ifconfig tun0 mtu 1472 ifconfig tun0 up # ниже можно прописать нужные нам маршруты, например так route add -net ... netmask 255.255.255.0 gw ... route add -net ... netmask 255.255.255.0 gw ... > ./tun.sh

Для автоматической загрузки правил файл tun.sh правильно поместить для Debian в директорию /etc/network/if-up.d

Все IPSec тунель между сетями настроен.

iptables IPSec

$IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx --dport 500 -j ACCEPT $IPT -A INPUT -p esp -j ACCEPT $IPT -A INPUT -p ah -j ACCEPT $IPT -A INPUT -p ipencap -j ACCEPT $IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx --dport 4500 -j ACCEPT

IPsec «узел-узел» без виртуальных интерфесов

Задача . При помощи IPSec (pre_shared_key) соединить два сервера (Debian 5 и Debian 7). У обоих реальные IP. Никаких сетей пробрасывать не надо. Должен шифроваться трафик между этими IP. То есть строим транспортный режим (между двумя хостами).

Настройка сводится к двум пунктам

Настройка пакета racoon

Создание политики безопасности: нужно указать режим transport и any spdadd x.x.x.x/32 y.y.y.y/32 any -P out ipsec esp/transport//require; spdadd y.y.y.y/32 x.x.x.x/32 any -P in ipsec esp/transport//require;

IPSec (GRE) (узел-сеть) между Debian и Cisco

Задача: построить IPsec в туннельном режиме. Описание RFC протокола SIP сигнализация между поставщиком (Cisco) и клиентом (Debian 5) шифруется IPsec, а RTP минуя туннель идет кратчайшим маршрутом через обычный Интернет.

Клиент tunnel-endpoint is: 193.xxx.xxx.xxx

Сервер tunnel-endpoint is: 62.xxx.xxx.xxx

Клиент Sip Server is: 193.xxx.xxx.xxx

Сервер SIP Servers are: 62.xxx.237.xxx/26 and 62.xxx.246.xxx/26

да и перед настрокой туннеля (перед auto tun0) прописать pre-up modprobe ip_gre

# modprobe ip_gre

Скрипт для создания GRE туннели туннеля в Debian:

#!/bin/sh -e modprobe ip_gre #ip tunnel del tun0 ip tunnel add tun0 mode gre remote 62.xxx.xxx.xxx local 193.xxx.xxx.xxx dev eth0 ifconfig tun0 mtu 1472 ifconfig tun0 up route add -net 62.xxx.237.xxx netmask 255.255.255.192 dev tun0 route add -net 62.xxx.246.xxx netmask 255.255.255.192 dev tun0

Утилиты

Для управления можно использовать утилиту racoonctl racoonctl show-sa esp

Cписок созданных защищенных каналов > setkey -D

список политик безопасности > setkey -DP

Мониторинг IPsec

Мониторинг IPsec в Debian 5.0 2.6.26-2-686-bigmem i686. В уровень детализации логов log notify или log debug устанавливается в файле racoon.conf.

# tail -F /var/log/syslog | grep racoon

IPSec Openswan

OpenSWAN начал разрабатываться как форк прекратившего в настоящее своё существование проекта FreeS/WAN (Free Secure Wide-Area Networking), релизы продолжают выпускаться под свободной GNU General Public License. В отличие от проекта FreeS/WAN, OpenSWAN разрабатывается не только специально под операционную систему GNU/Linux. OpenSWAN обеспечивает стек протоколов IpSec: AH и ESP для ядра Linux,а также инструментарий для управления ими.

OpenSWAN для ветки ядра 2.6 предоставляет встроенную, NETKEY реализацию IpSec, так и собственную KLIPS.

CentOS 6.6 поддерживает только Openswan в основных пакетах.

Задача . Создать шифрованный туннель между CentOS 6.6 и Debian 7.8 Wheezy. GRE туннели + Openswan (type=transport)

Openswan будет шифровать наш трафик в транспортном режиме(host-to-host), не вмешиваясь в маршрутизацию. Установим пакеты на обоих серверах yum install openswan aptitude install openswan

На обоих концах туннеля настраиваем Правила iptables . Открыть 500 порт, по которому идет обмен сертификатам и ключами. iptables -A INPUT -p udp --dport 500 -j ACCEPT iptables -A INPUT -p tcp --dport 4500 -j ACCEPT iptables -A INPUT -p udp --dport 4500 -j ACCEPT # Более строго выпишем правила для IPSec IPT ="/sbin/iptables" $IPT -A INPUT -p udp -s x.x.x.x -d x.x.x.x --dport 500 -m comment --comment "IpSec" -j ACCEPT $IPT -A INPUT -p tcp -s x.x.x.x -d x.x.x.x --dport 4500 -m comment --comment "IpSec" -j ACCEPT $IPT -A INPUT -p udp -s x.x.x.x -d x.x.x.x --dport 4500 -m comment --comment "IpSec" -j ACCEPT

Подготовка конфигурационных файлов. Используемые файлы и директории / etc/ ipsec.d/ / etc/ ipsec.conf

Проверка системы на правильность окружения для IPsec ipsec verify

Добавить в конец файла sysctl.conf

# IPSec Verify Compliant # Разрешить пересылку пакетов между интерфейсами для IPv4 net.ipv4.ip_forward = 1 # отключаем icmp redirect net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0

Применим параметры ядра без перезагрузки

Первым конфигурационным файлом является /etc/ipsec.conf. Задаем явно в разделе config setup config setup protostack =netkey plutoopts ="--perpeerlog" dumpdir =/ var/ run/ pluto/ nat_traversal =yes virtual_private =% v4:10.0.0.0/ 8 ,% v4:192.168.0.0/ 16 , % v4:172.16.0.0/ 12 ,% v4:25.0.0.0/ 8 ,% v6:fd00::/ 8 ,% v6:fe80::/ 10 oe =off #plutostderrlog=/dev/null

В первую очередь вам необходимо сформировать ключи, используемые шлюзами для аутентификации. В Debian это ключ можно создать при инсталляции. Запускаем на обеих системах ipsec newhostkey, генерируя нужные нам ключи. ipsec newhostkey --output / etc/ ipsec.secrets ipsec showhostkey --left ipsec showhostkey --right

Независимо от того, как вы сконфигурируете сервер, всегда рассматривайте вашу подсеть как расположенную «слева» (left), а подсеть, к которой доступ осуществляется дистанционно, сайт, как расположенный «справа» (right). Следующая конфигурация выполняется на сервере VPN на стороне Left. На другом сервере должен быть точно такие настройки для этого соединения. conn gagahost-to-miraxhost auto =start left =188 .x.x.x leftrsasigkey =0sN4vI6ooUyMyL ... right =91 .x.x.x rightrsasigkey =0sfAhuo4SQ0Qt ... type =transport scp / etc/ ipsec.conf admin@ 192.168.35.254:/ home/ admin/

Диагностика IPSec Openswan

Запуск сервиса и поиск возникающих проблем.

Openwan logs (pluto) : /var/log/auth.log /var/log/syslog /var/log/pluto/peer/a/b/c/d/a.b.c.d.log

Если на обоих серверах нет ошибок, то туннель должен сейчас подняться. Вы можете проверить туннель с помощью команды ping с следующим образом. Если туннель не поднят, то частная подсеть на стороне B не должна быть доступна со стороны А, т. е. команда ping не должна работать. После того, как туннель будет поднят, попробуйте команду ping для доступа к частной подсети на стороне B со стороны A. Это должно работать.

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

# ip route via dev eth0 src default via dev eth0

Команды проверки состояний соединений: ipsec verify service ipsec status ip xfrm state list - управления SAD, возможности шире, чем у setkey ipsec addconn --checkconfig - проверка конфигурации ipsec auto --status - подробное состояние ip xfrm monitor

Политики ipsec, согласно которым принимается решение какой трафик направлять в туннель ip xfrm pol show

tcpdump Linux примеры использования запускаем для прослушки физического интерфейса на котором построен туннель (а не виртуального GRE). В другом окне например ping -ем удаленную серую сеть (например, ping 192.168.1.11). tcpdump должен показывать ESP пакеты. tcpdump -i em0 -n host 91 .x.x.81 ... 16 :15 :54.419117 IP x.x.x.x > 91 .x.x.81: ESP(spi =0x01540fdd,seq =0xa20) , length 92 ...

Рисунок 1 - Пример работы IPsec

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

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

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

Особенности

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

Именно по этой причине IPsec и состоит из стека протоколов, обязанность которых лежит в том, чтобы обеспечить установление защищенного соединения, его работу и управление им. Весь процесс установления соединения включает две фазы: первая фаза применяется для того, чтобы обеспечить безопасный обмен ISAKMP-сообщений уже во второй фазе. ISAKMP (Internet Security Association and Key Management Protocol) - это протокол, который служит для согласования и обновления политик безопасности (SA) между участниками VPN-соединения. В этих политиках как раз и указано, с помощью какого протокола шифровать (AES или 3DES) и с помощью чего аутентифицировать (SHA или MD5).

Основные понятия

AES (Advanced Encryption Standard) , также известный как Rijndael - симметричный алгоритм блочного шифрования (размер блока 128 бит, ключ 128/192/256 бит), принятый в качестве стандарта шифрования правительством США по результатам конкурса AES. По состоянию на 2009 год AES является одним из самых распространённых алгоритмов симметричного шифрования.

DES (Data Encryption Standard) - симметричный алгоритм шифрования, разработанный фирмой IBM и утвержденный правительством США в 1977 году как официальный стандарт (FIPS 46-3). DES имеет блоки по 64 бита и 16 цикловую структуру сети Фейстеля, для шифрования использует ключ с длиной 56 бит. Алгоритм использует комбинацию нелинейных (S-блоки) и линейных (перестановки E, IP, IP-1) преобразований.

3DES (Triple Data Encryption Standard) - симметричный блочный шифр, созданный Уитфилдом Диффи, Мартином Хеллманом и Уолтом Тачманном в 1978 году на основе алгоритма DES, с целью устранения главного недостатка последнего - малой длины ключа (56 бит), который может быть взломан методом полного перебора ключа. Скорость работы 3DES в 3 раза ниже, чем у DES, но криптостойкость намного выше - время, требуемое для криптоанализа 3DES, может быть в миллиард раз больше, чем время, нужное для вскрытия DES. 3DES используется чаще, чем DES, который легко ломается при помощи сегодняшних технологий (в 1998 году организация Electronic Frontier Foundation, используя специальный компьютер DES Cracker, вскрыла DES за 3 дня). 3DES является простым способом устранения недостатков DES. Алгоритм 3DES построен на основе DES, поэтому для его реализации возможно использовать программы, созданные для DES.

RSA (Ron Rivest, Adi Shamir, and Leonard Adleman Algorithm) - криптографический алгоритм с открытым ключом. RSA стал первым алгоритмом такого типа, пригодным и для шифрования, и для цифровой подписи. Алгоритм используется в большом числе криптографических приложений.

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

PKI (Public Key Infrastructure, Инфраструктура открытых ключей) - технология аутентификации с помощью открытых ключей. Это комплексная система, которая связывает открытые ключи с личностью пользователя посредством удостоверяющего центра (УЦ).

CRL (Certificate Revocation list) - список отозванных сертификатов.

Стандарты

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

Построение защищённого канала связи может быть реализовано на разных уровнях модели OSI. Так, например, популярный SSL-протокол работает на уровне представления, а PPTP - на сеансовом. 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 . Рабочая группа 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 призван обеспечить низкоуровневую защиту. К IP-данным, готовым к передаче по виртуальной частной сети, IPSec добавляет заголовок для идентификации защищенных пакетов. Перед передачей по Internet эти пакеты инкапсулируются в другие IP-пакеты. IPSec поддерживает несколько типов шифрования, в том числе Data Encryption Standard и Message Digest 5. Чтобы установить защищенное соединение, оба участника сеанса должны иметь возможность быстро согласовать параметры защиты, такие как алгоритмы аутентификации и ключи. 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 г. IPsec является набором стандартов Интернет и своего рода «надстройкой» над IP-протоколом. Его ядро составляют три протокола:

• Authentication Header (АН) обеспечивает целостность передаваемых данных, аутентификацию источника информации и функцию по предотвращению повторной передачи пакетов

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

• Internet Security Association and Key Management Protocol (ISAKMP) - протокол, используемый для первичной настройки соединения, взаимной аутентификации конечными узлами друг друга и обмена секретными ключами. Протокол предусматривает использование различных механизмов обмена ключами, включая задание фиксированных ключей, использование таких протоколов, как Internet Key Exchange, Kerberized Internet Negotiation of Keys (RFC 4430) или записей DNS типа IPSECKEY (RFC 4025).

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

Заголовок AH

Аутентифицирующий заголовок (AH) является обычным опциональным заголовком и, как правило, располагается между основным заголовком пакета IP и полем данных. Наличие AH никак не влияет на процесс передачи информации транспортного и более высокого уровней. Основным и единственным назначением AH является обеспечение защиты от атак, связанных с несанкционированным изменением содержимого пакета, и в том числе от подмены исходного адреса сетевого уровня. Протоколы более высокого уровня должны быть модифицированы в целях осуществления проверки аутентичности полученных данных. Формат AH достаточно прост и состоит из 96-битового заголовка и данных переменной длины, состоящих из 32-битовых слов. Названия полей достаточно ясно отражают их содержимое: Next Header указывает на следующий заголовок, Payload Len представляет длину пакета, SPI является указателем на контекст безопасности и Sequence Number Field содержит последовательный номер пакета. Последовательный номер пакета был введен в AH в 1997 году в ходе процесса пересмотра спецификации IPsec. Значение этого поля формируется отправителем и служит для защиты от атак, связанных с повторным использованием данных процесса аутентификации. Поскольку сеть Интернет не гарантирует порядок доставки пакетов, получатель должен хранить информацию о максимальном последовательном номере пакета, прошедшего успешную аутентификацию, и о получении некоторого числа пакетов, содержащих предыдущие последовательные номера (обычно это число равно 64). В отличие от алгоритмов вычисления контрольной суммы, применяемых в протоколах передачи информации по коммутируемым линиям связи или по каналам локальных сетей и ориентированных на исправление случайных ошибок среды передачи, механизмы обеспечения целостности данных в открытых телекоммуникационных сетях должны иметь средства защиты от внесения целенаправленных изменений. Одним из таких механизмов является специальное применение алгоритма MD5: в процессе формирования AH последовательно вычисляется хэш-функция от объединения самого пакета и некоторого предварительно согласованного ключа, а затем от объединения полученного результата и преобразованного ключа. Данный механизм применяется по умолчанию в целях обеспечения всех реализаций IPv6, по крайней мере, одним общим алгоритмом, не подверженным экспортным ограничениям.

Заголовок ESP

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

AH и ESP

Security Associations

Security Association (SA) - это соединение, которое предоставляет службы обеспечения безопасности трафика, который передаётся через него. Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA. Для начала обмена данными между двумя сторонами необходимо установить соединение, которое носит название SA (Security Association). Концепция SA фундаментальна для IPsec, собственно, является его сутью. Она описывает, как стороны будут использовать сервисы для обеспечения защищённого общения. Соединение SA является симплексным (однонаправленным), поэтому для взаимодействия сторон необходимо установить два соединения. Стоит также отметить, что стандарты IPsec позволяют конечным точкам защищённого канала использовать как одно SA для передачи трафика всех взаимодействующих через этот канал хостов, так и создавать для этой цели произвольное число безопасных ассоциаций, например, по одной на каждое TCP-соединение. Это дает возможность выбирать нужную степень детализации защиты. Установка соединения начинается со взаимной аутентификации сторон. Далее происходит выбор параметров (будет ли осуществляться аутентификация, шифрование, проверка целостности данных) и необходимого протокола (AH или ESP) передачи данных. После этого выбирается конкретные алгоритмы (например, шифрования, хэш-функция) из нескольких возможных схем, некоторые из которых определены стандартом (для шифрования - DES , для хэш-функций - MD5 либо SHA-1), другие добавляются производителями продуктов, использующих IPsec (например Triple DES , Blowfish, CAST).

Security Associations Database

Все SA хранятся в базе данных SAD (Security Associations Database) IPsec-модуля. Каждое SA имеет уникальный маркер, состоящий из трёх элементов:

• индекса параметров безопасности (Security Parameters Index, SPI)
• IP-адреса назначения
• идентификатора протокола безопасности (ESP или AH)

IPsec-модуль, имея эти три параметра, может отыскать в SAD запись о конкретном SA. В список компонентов SA входят:

Последовательный номер

32-битовое значение, которое используется для формирования поля Sequence Number в заголовках АН и ESP.

Переполнение счетчика порядкового номера

Флаг, который сигнализирует о переполнении счетчика последовательного номера.

Окно для подавления атак воспроизведения

Используется для определения повторной передачи пакетов. Если значение в поле Sequence Number не попадает в заданный диапазон, то пакет уничтожается.

Информация AH

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

Информация ESP

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

Режим работы IPsec

туннельный или транспортный

Время жизни SA

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

Authentication Header

AH используется для аутентификации отправителя информации, для обеспечения целостности данных и опционально может использоваться для защиты от повторной передачи данных. Аутентификация осуществляется за счет вычисления хэш-функции IP пакета (поля, которые могут меняться в процессе передачи пакета (например, TTL) исключаются). Вычисленная хэш-функция добавляется к заголовку пакета AH и отправляется получателю пакета. Заголовок AH содержит поле Integrity Check Value, которое вычисляется по алгоритмам MD5 или SHA-1. На практике чаще используется HMAC (Hash Message Authentication Code), так он при вычислении хэш-функции использует заранее известный участникам секретный ключ. В свою очередь HMAC использует для вычисления хэш-функции алгоритмы MD5 или SHA-1. В зависимости от используемого алгоритма HMAC будет называться соответственно HMAC-MD5 или HMAC-SHA-1.

"Authentication Header format"
Offsets	Octet 16	0								1								2								3
Octet 16	Bit 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Next Header								Payload Len								Reserved
4	32	Security Parameters Index (SPI)
8	64	Sequence Number
C	96	Integrity Check Value (ICV)
...	...

Тип следующего заголовка (8 bits)

Тип заголовка протокола, идущего после заголовка AH. По этому полю приёмный IP-sec модуль узнает о защищаемом протоколе верхнего уровня. Значения этого поля для разных протоколов можно посмотреть в RFC 1700 .

Длина содержимого (8 bits)

Это поле определяет общий размер АН-заголовка в 32-битовых словах, минус 2. Несмотря на это, при использовании IPv6 длина заголовка должна быть кратна 8 байтам.

Зарезервировано (16 bits)

Зарезервировано. Заполняется нулями.

Индекс параметров системы безопасности (32 bits)

Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (АН-протокол), однозначно определяет защищённое виртуальное соединение (SA) для данного пакета. Диапазон значений SPI 1…255 зарезервирован IANA.

Порядковый номер (32 bits)

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

Данные аутентификации

Цифровая подпись. Служит для аутентификации и проверки целостности пакета. Должна быть дополнена до размера, кратного 8-байтам для IPv6, и 4-байтам для IPv4. Протокол AH используется для аутентификации, то есть для подтверждения того, что мы связываемся именно с тем, с кем предполагаем, и что данные, которые мы получаем, не искажены при передаче.

Обработка выходных IP-пакетов

Если передающий IPsec-модуль определяет, что пакет связан с SA, которое предполагает AH-обработку, то он начинает обработку. В зависимости от режима (транспортный или режим туннелирования) он по-разному вставляет AH-заголовок в IP-пакет. В транспортном режиме AH-заголовок располагается после заголовка протокола IP и перед заголовками протоколов верхнего уровня (Обычно, TCP или UDP). В режиме туннелирования весь исходный IP-пакет обрамляется сначала заголовком AH, затем заголовком IP-протокола. Такой заголовок называется внешним, а заголовок исходного IP-пакета- внутренним. После этого передающий IPsec-модуль должен сгенерировать последовательный номер и записать его в поле Sequence Number. При установлении SA последовательный номер устанавливается в 0, и перед отправкой каждого IPsec-пакета увеличивается на единицу. Кроме того, происходит проверка- не зациклился ли счетчик. Если он достиг своего максимального значения, то он снова устанавливается в 0. Если используется услуга по предотвращению повторной передачи, то при достижении счетчика своего максимального значения, передающий IPsec-модуль переустанавливает SA. Таким образом обеспечивается защита от повторной посылки пакета- приёмный IPsec-модуль будет проверять поле Sequence Number, и игнорировать повторно приходящие пакеты. Далее происходит вычисление контрольной суммы ICV. Надо заметить, что здесь контрольная сумма вычисляется с применением секретного ключа, без которого злоумышленник сможет заново вычислить хэш, но не зная ключа, не сможет сформировать правильную контрольную сумму. Конкретные алгоритмы, использующиеся для вычисления ICV, можно узнать из RFC 4305 . В настоящее время могут применяться, например, алгоритмы HMAC-SHA1-96 или AES-XCBC-MAC-96. Протокол АН вычисляет контрольную сумму (ICV) по следующим полям IPsec-пакета:

поля IP-заголовка, которые не были подвержены изменениям в процессе транслирования, или определены как наиболее важные АН-заголовок (Поля: «Next Header», "Payload Len, «Reserved», «SPI», «Sequence Number», «Integrity Check Value». Поле «Integrity Check Value» устанавливается в 0 при вычислении ICV данные протокола верхнего уровня Если поле может изменяться в процессе транспортировки, то его значение устанавливается в 0 перед вычислением ICV. Исключения составляют поля, которые могут изменяться, но значение которых можно предугадать при приёме. При вычислении ICV они не заполняются нулями. Примером изменяемого поля может служить поле контрольной суммы, примером изменяемого, но предопределенного может являться IP-адрес получателя. Более подробное описание того, какие поля как учитываются при вычислении ICV, можно найти в стандарте RFC 2402 .

Обработка входных IP-пакетов

После получения пакета, содержащего сообщение АН-протокола, приёмный IPsec-модуль ищет соответствующее защищённое виртуальное соединение (SA) SAD (Security Associations Database), используя IP-адрес получателя, протокол безопасности (АН) и индекс SPI. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищённое виртуальное соединение (SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, то есть на необходимость проверки поля Sequence Number. Если услуга используется, то поле проверяется. При этом используется метод скользящего окна для ограничения буферной памяти, требуемый для работы протоколу. Приёмный IPsec-модуль формирует окно с шириной W (обычно W выбирается равным 32 или 64 пакетам). Левый край окна соответствует минимальному последовательному номеру (Sequence Number) N правильно принятого пакета. Пакет с полем Sequence Number, в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем приёмный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле «Integrity Check Value». Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным и принимается для дальнейшей IP-обработки. Если проверка дала отрицательный результат, то принятый пакет уничтожается.

Encapsulating Security Payload

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

MTU

Максимальный размер пакета, который можно передать по виртуальному каналу без фрагментации. Каждый протокол (ESP/AH) должен иметь свой собственный SA для каждого направления, таким образом, связка AH+ESP требует для дуплексного канала наличия четырёх SA. Все эти данные располагаются в SAD.

Помимо базы данных SAD, реализации IPsec поддерживают базу данных SPD (Security Policy Database - база данных политики безопасности). SPD служит для соотнесения приходящих IP-пакетов с правилами обработки для них. Записи в SPD состоят из двух полей. В первом хранятся характерные признаки пакетов, по которым можно выделить тот или иной поток информации. Эти поля называются селекторами. Примеры селекторов, которые содержатся в SPD:

• IP-адрес места назначения
• IP-адрес отправителя
• Имя пользователя в формате DNS или X.500
• Порты отправителя и получателя

Второе поле в SPD содержит политику защиты, соответствующую данному потоку пакетов. Селекторы используются для фильтрации исходящих пакетов с целью поставить каждый пакет в соответствие с определенным SA. Когда поступает пакет, сравниваются значения соответствующих полей в пакете (селекторные поля) с теми, которые содержатся в SPD. При нахождении совпадения в поле политики защиты содержится информация о том, как поступать с данным пакетом: передать без изменений, отбросить или обработать. В случае обработки, в этом же поле содержится ссылка на соответствующую запись в SAD. Затем определяется SA для пакета и сопряжённый с ней индекс параметров безопасности (SPI), после чего выполняются операции IPsec (операции протокола AH или ESP). Если пакет входящий, то в нём сразу содержится SPI - проводится соответствующая обработка.

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

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

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

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

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

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

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

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

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

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

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

Протокольный контекст для IPSec идентифицируется целевым IP-адресом, протоколом (AH или ESP), а также дополнительной величиной - индексом параметров безопасности (Security Parameter Index, SPI). Последняя величина необходима, поскольку могут существовать несколько контекстов с одинаковыми IP-адресами и протоколами. Далее показано, как используются индексы SPI при обработке входящих пакетов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Отмеченная асимметрия отражает определенную незавершенность архитектуры IPSec. В более раннем документе RFC 1825 понятия базы данных политики безопасности и селекторов отсутствовали. В новой редакции сделано полшага вперед - специфицирован просмотр базы SPD как обязательный для каждого исходящего пакета, но не изменена обработка входящих пакетов. Извлечение контекста по индексу SPI эффективнее, чем просмотр набора правил, но при таком подходе, затрудняется оперативное изменение политики безопасности. Что касается эффективности просмотра правил, то ее можно повысить методами кэширования, широко используемыми при реализации IP.

ISAKMP/Oakley

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

IKE

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

IKE - протокол обмена ключами по умолчанию для ISAKMP, на данный момент являющийся единственным. IKE находится на вершине ISAKMP и выполняет, собственно, установление как ISAKMP SA, так и IPSec SA. IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF). "Хэш-функция" - это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения m1 и m2, таких, что H(m1)=H(m2), где H - хэш функция. Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC - механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая хэш функция (обозначим её как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования - как L (L

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

IKE совмещает в себе три основных направления (отдельных протокола):

• ISAKMP (Internet Security Association and Key Management Protocol) - протокол ассоциаций безопасности и управления ключами в интернете; это общее описание (framework) для обеспечения аутентификации и обмена ключей без указания конкретных прикладных алгоритмов;
• Oakley (Oakley key determination protocol) - протокол определения ключей Окли; он описывает последовательности обмена ключами - моды (mode) и описывает предоставляемые ими функции;
• SKEMI (Secure Key Exchange Mechanism for Internet) - механизм безопасного обмена ключами в Интернете; он описывает многофункциональные технологии, предоставляющие анонимность, неотрекаемость (аппелируемость) и быстрое обновление ключей;

IKE содержит две фазы согласования ключей. В первой фазе происходит создание защищенного канала, во второй - согласование и обмен ключами, установление SA. Первая фаза использует один из двух режимов: основной (англ. Main Mode) или агрессивный (англ. Aggressive Mode). Различие между ними в уровне защищенности и скорости работы. Основной режим, более медленный, защищает всю информацию, передаваемую между узлами. Агрессивный режим для ускорения работы оставляет ряд параметров открытыми и уязвимыми для прослушивания, его рекомендуется использовать только в случае, когда критическим вопросом является скорость работы. Во второй фазе используется быстрый режим (англ. Quick Mode), названный так потому, что не производит аутентификации узлов, считая, что это было сделано в первой фазе. Эта фаза обеспечивает обмен ключами, с помощью которых происходит шифрование данных.
IKE (произносится айк, аббр. от Internet Key Exchange) - протокол, связывающий все компоненты IPsec в работающее целое. В частности, IKE обеспечивает первоначальную аутентификацию сторон, а также их обмен общими секретными ключами.

Существует возможность вручную установить ключ для сессии (не путать с pre-shared key для аутентификации). В этом случае IKE не используется. Однако этот вариант не рекомендуется и используется редко. Традиционно, IKE работает через порт 500 UDP.

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

Первая фаза

IKE создает безопасный канал между двумя узлами, называемый IKE security association (IKE SA). Также, в этой фазе два узла согласуют сессионный ключ по алгоритму Диффи-Хеллмана. Первая фаза IKE может проходить в одном из двух режимов:

Основной режим

Состоит из трёх двусторонних обменов между отправителем и получателем: Во время первого обмена согласуются алгоритмы и хэш-функции, которые будут использоваться для защиты IKE соединения, посредством сопоставления IKE SA каждого узла. Используя алгоритм Диффи-Хеллмана, стороны обмениваются общим секретным ключом. Также узлы проверяют идентификацию друг друга путём передачи и подтверждения последовательности псевдослучайных чисел. По зашифрованному IP-адресу проверяется идентичность противоположной стороны. В результате выполнения основного режима создается безопасный канал для последующего ISAKMP - обмена (этот протокол определяет порядок действий для аутентификации соединения узлов, создания и управления SA, генерации ключей, а также уменьшения угроз, таких как DoS-атака или атака повторного воспроизведения).

Агрессивный режим

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

Вторая фаза

В фазе два IKE существует только один, быстрый, режим. Быстрый режим выполняется только после создания безопасного канала в ходе первой фазы. Он согласует общую политику IPsec, получает общие секретные ключи для алгоритмов протоколов IPsec (AH или ESP), устанавливает IPsec SA. Использование последовательных номеров обеспечивает защиту от атак повторной передачи. Также быстрый режим используется для пересмотра текущей IPsec SA и выбора новой, когда время жизни SA истекает. Стандартно быстрый режим проводит обновление общих секретных ключей, используя алгоритм Диффи-Хеллмана из первой фазы.

Дополнительно

Со временем стало ясно, что только одного PSK недостаточно для обеспечения безопасности. Например, в случае компрометации рабочей станции сотрудника атакующий смог бы сразу получить доступ ко всей внутренней сети предприятия. Поэтому была разработана фаза 1.5 прямо между первой и второй классическими фазами. К слову, эта фаза обычно не используется в стандартном site-to-site VPN-соединении, а применяется при организации удаленных VPN-подключений (наш случай). Эта фаза содержит в себе два новых расширения - Extended Authentication (XAUTH) и Mode-Configuration (MODECFG).

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

IKEv2 vs IKEv1

Оба протокола работают по UDP-порту с номером 500, но между собой несовместимы, не допускается ситуация, чтобы на одном конце туннеля был IKEv1, а на другом - IKEv2. Вот основные отличия второй версии от первой:

MD5, SHA-1 и др.

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

Аутентификация вычисляет Integrity Check Value (ICV) содержимого пакета, и, как правило, используется криптографический хэш-алгоритм , такой как MD5 или SHA-1. Он включает в себя секретный ключ, известный обоим сторонам, что позволяет получателю вычислить ICV таким же образом. Если получатель получает такое же значение, то это значит, что отправитель успешно аутентифицировался (опираясь на предположение, что криптографические хэши практически невозможно обратить). AH всегда обеспечивает аутентификацию, а для ESP это необязательно. Шифрование использует секретный ключ для шифрования данных перед передачей, что защищает реальное содержимое пакета от прослушки. Существует довольно много вариантов для алгоритмов, распространенными являются DES , 3DES, Blowfish и AES . Возможны и другие.

Атаки на 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 можно выделить пять этапов:

Использование

Протокол IPsec используется, в основном, для организации VPN-туннелей. В этом случае протоколы ESP и AH работают в режиме туннелирования. Кроме того, настраивая политики безопасности определенным образом, протокол можно использовать для создания межсетевого экрана. Смысл межсетевого экрана заключается в том, что он контролирует и фильтрует проходящие через него пакеты в соответствии с заданными правилами. Устанавливается набор правил, и экран просматривает все проходящие через него пакеты. Если передаваемые пакеты попадают под действие этих правил, межсетевой экран обрабатывает их соответствующим образом. Например, он может отклонять определенные пакеты, тем самым прекращая небезопасные соединения. Настроив политику безопасности соответствующим образом, можно, например, запретить веб-трафик. Для этого достаточно запретить отсылку пакетов, в которые вкладываются сообщения протоколов HTTP и HTTPS. IPsec можно применять и для защиты серверов - для этого отбрасываются все пакеты, кроме пакетов, необходимых для корректного выполнения функций сервера. Например, для Web-сервера можно блокировать весь трафик, за исключением соединений через 80-й порт протокола TCP, или через порт TCP 443 в случаях, когда применяется HTTPS . С помощью IPsec здесь обеспечивается безопасный доступ пользователей к серверу. При использовании протокола ESP, все обращения к серверу и его ответы шифруются. Однако за VPN шлюзом (в домене шифрования) передаются открытые сообщения. Другие примеры использования IPsec:

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

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

Преимущества и недостатки

IPsec имеет следующие преимущества:

• Открытый промышленный стандарт. IPSec предоставляет открытый промышленный стандарт как альтернативу проприетарным технологиям безопасности на основе IP. Это позволяет сетевым администраторам извлечь выгоду из полученной оперативной совместимости.
• Прозрачность. IPSec существует ниже транспортного уровня, что делает его прозрачным для пользователей и приложений, что означает, что нет необходимости изменять сетевые приложения на рабочем столе пользователя, если IPSec реализован в брандмауэре или маршрутизатор.
• Аутентификация. Стойкие службы аутентификации предотвращают принятие данных за счет использования ложно заявленных идентичностей.
• Конфиденциальность. Службы конфидениальности предотвращают доступ к важным данным во время их передачи между сторонами.
• Проверка подлинности происхождения и целостности данных. Проверка подлинности источника данных и целостность обеспечивается значением хэш-кода аутентификации сообщения (HMAC), который входит в каждый пакет.
• Динамическое перекодирование. Динамическое перекодирование в ходе текущих соединений исключает ручную переконфигурацию секретных ключей и помогает защититься от определения секретного ключа.
• Безопасные ссылки из конца в конец. IPSec для Windows 2000 предоставляет защищенные ссылки из конца в конец для пользователей частных сетей в пределах одного домена или через какой-либо доверенный домен на предприятии.
• Централизованное управление. Сетевые администраторы используют политики IPSec для обеспечения надлежащего уровня безопасности в зависимости от пользователя, рабочей группы или по другим критериям. Централизованное управление снижает административные расходы.
• Гибкость. Гибкость IPSec для Windows 2000 позволяет применять политики в масштабах всего предприятия или к одной рабочей станции.

Хотя IPSec наиболее популярное и, пожалуй, наилучшее решение для создания виртуальных частных сетей, имеются и некоторые ограничения. В случае его применения в транспортном режиме не исключается возможность атак со стороны, что вызвано некоторыми ограничениями протокола ISAKMP. Взлом сессии IPSec вполне вероятен, если не используется заголовок аутентификации AH. При таком типе атаки данные злоумышленника могут быть вставлены в полезную передающуюся информацию, например, в случае Unix-систем достаточно вставить в поток команду rm -R, чтобы получатель в итоге недосчитался многих, а то и всех файлов на жестком диске. Поскольку трафик IPSec маршрутизируем, различные практические реализации IPSec могут подвергнуться более "изящной" атаке - подмене изначального маршрута. Оговоримся, что данный вид атаки возможен лишь при использовании IPSec в транспортном режиме, если же он применяется для построения туннеля, вся роутинговая информация в этом случае шифруется и подобный вид атаки успеха иметь не будет.

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

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

Конкуренты

Многие продукты, которые могут использовать IPSec, взаимодействуют с альтернативной технологией шифрования, именуемой "Уровень защищенных сокетов" (Secure Sockets Layer, SSL). Основное различие между IPSec и SSL в том, что IPSec работает на уровне сети, обеспечивая защиту сетевого соединения от начала и до конца. SSL же действует на уровне приложений, обеспечивая защиту лишь выбранному приложению, например веб-браузеру или программе для работы с электронной почтой. Хотя как IPSec, так и SSL призваны обеспечить конфиденциальность обмена информацией, что достигается совершенно различными способами. SSL был разработан компанией Netscape для защиты трафика HTTP, проходящего через программу-браузер. SSL - протокол уровня отдельной сессии, и в этом отношении он, несомненно, проигрывает IPSec, который позволяет построить постоянный туннель, не зависящий от проходящего сквозь него сетевого трафика. Протокол SSL основан на клиент-серверной модели и обычно используется для защиты на отрезке "хост-хост". В связи с тем, что IPSec взаимодействует на сетевом уровне, возможны такие варианты, как "подсеть-подсеть", "сеть-сеть" или "сеть-хост". Это наводит на мысль, что IPSec допускает маршрутизацию, а SSL - нет.

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

Сравнение IPSec и SSL

Ниже приведена таблица сравнения IPSec и SSL.

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

Источники

Ссылки

• Unixwiz.net [Электронный ресурс]: An Illustrated Guide to IPsec / Дата обращения: 19.12.2017. Режим доступа:

Сети VPN с IPsec обеспечивают гибкую и масштабируемую связь. Межфилиальные соединения могут обеспечивать безопасную, высокоскоростную и надёжную удалённую связь. При помощи VPN с IPsec информация из частной сети передаётся в защищённом режиме по публичной сети. Благодаря этому можно создать виртуальную сеть, а не использовать выделенное подключение на 2 уровне, как показано на рисунке. Для обеспечения конфиденциальности данных трафик шифруется.

IPsec - это стандарт IETF, который определяет способ настройки сети VPN в защищённом режиме с помощью протокола IP.

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

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

Во всех реализованных решениях протокола IPsec применяется незашифрованный заголовок 3-го уровня, поэтому никаких проблем с маршрутизацией не существует. IPsec функционирует поверх любых протоколов 2-го уровня, таких как Ethernet, ATM и Frame Relay.

Ниже указаны основные особенности протокола IPsec:

• IPsec - это структура открытых стандартов, независимая от алгоритмов.

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

• IPsec действует как протокол сетевого уровня, защищая пакеты IP и проверяя их подлинность.

• Защита IP

На рисунке показано, что сервисы безопасности IPsec выполняют следующие важные функции:

• 
  
• • Конфиденциальность (шифрование) - в сети VPN частные данные передаются по публичной сети. Поэтому ключевой задачей является обеспечение конфиденциальности данных. Для этого перед передачей данных по сети выполняется шифрование данных. Шифрование - это процесс кодирования всех данных, отправляемых с одного компьютера на другой, в ту форму, которую может декодировать только принимающий компьютер. В случае перехвата сообщения злоумышленник (хакер) не сможет его прочесть. IPsec предоставляет расширенные функции безопасности (например, криптостойкие алгоритмы шифрования).
  • Целостность данных - Получатель может убедиться, что данные были нормально переданы через Интернет и никак не были изменены. Важно не только обеспечить шифрование данных в публичной сети, но и убедиться, что они не были изменены в пути. В IPsec предусмотрен механизм проверки отсутствия изменений в шифрованной части пакета, во всём заголовке или в теле данных пакета. IPsec гарантирует целостность данных с помощью контрольных сумм (применяется простая проверка с использованием избыточности). При обнаружении искажений пакет удаляется.
  • Аутентификация - позволяет проверить, кто был источником отправленных данных. Это необходимо для защиты от атак, использующих спуфинг (подмену отправителя). Аутентификация позволяет гарантировать установление подключения к нужному партнеру по связи. Получатель может проверять подлинность источника пакета, сертифицируя источник информации. В IPsec используется технология обмена ключами по Интернету (Internet Key Exchange, IKE) для проверки подлинности пользователей и устройств, которые могут устанавливать связь независимо друг от друга. В IKE применяется аутентификация различного типа (в частности, используются имя пользователя и пароль, одноразовый пароль, биометрия, предварительно распространяемый общий ключ (Pre-Shared Key, PSK) и цифровые сертификаты).
  • Защита от повторов - позволяет обнаруживать и отклонять повторные пакеты, а также предотвращать спуфинг. Благодаря защите от повторов можно убедиться, что пакет является уникальным и не дублированным. Пакеты IPsec защищаются путем сравнения порядкового номера полученных пакетов со «скользящим» окном на узле назначения или шлюзе безопасности. Пакет с порядковым номером, который следует перед скользящим окном, считается задержанным или дублированным. Задержанные и дублированные пакеты удаляются.

  Сокращение CIA во многих случаях позволяет вспомнить три эти функции: конфиденциальность(confidentiality), целостность (integrity), и проверка подлинности (authentication).

• Структура протокола IPsec

Конфиденциальность

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

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

• 
  

На рисунке видно, что Гейл хочет выполнить электронный перевод денежных средств через Интернет к Джереми. На локальной стороне документ объединяется с ключом и подвергается процедуре шифрования. Выходные данные представляют собой шифртекст. Затем этот шифртекст посылается через Интернет. На удалённой стороне сообщение снова объединяется с ключом и пропускается через алгоритм шифрования в обратном направлении. Выходные данные представляют собой исходный финансовый документ.

Конфиденциальность достигается шифрованием трафика при передаче через VPN. Степень безопасности зависит от длины ключа в алгоритме шифрования и сложности самого алгоритма. Если хакер попытается взломать ключ посредством атаки методом последовательного перебора, то количество вариантов для перебора будет зависеть от длины ключа. Время обработки всех возможных вариантов зависит от вычислительной мощности компьютера злоумышленника. Поэтому чем короче ключ, тем проще его взломать. Например, если для взлома 64-битового ключа относительно мощному компьютеру понадобится приблизительно один год, то для взлома 128-битового ключа тому же компьютеру может понадобиться от 10 до 19 лет.

Алгоритмы шифрования IPsec

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

Алгоритмы DES и 3DES больше не считаются надёжными, поэтому для шифрования в протоколе IPsec рекомендуется использовать AES. Наивысший уровень безопасности для шифрования сетей VPN между устройствами Cisco с помощью протокола IPsec обеспечивается 256-битовым вариантом AES. Кроме того, с учетом взлома 512- и 768-битовых ключей Ривеста-Шамира-Эдльмана (RSA) компания Cisco рекомендует использовать 2048-битовые ключи в варианте RSA (если он применяется на этапе аутентификации IKE).

Симметричное шифрование

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

Например, отправитель создаёт кодированное сообщение, где каждая буква меняется на букву, следующую через две буквы ниже в алфавите (то есть A становится C, В становится D и т. д.). В этом случае слово SECRET превращается в UGETGV. Отправитель уже сообщил получателю, что секретный ключ - это смещение на 2. Когда получатель получает сообщение UGETGV, его компьютер раскодирует сообщение путем обратного смещения на две буквы и получает слово SECRET. Любой другой пользователь, смотрящий на это сообщение, видит его в зашифрованном виде. Чтобы такое сообщение не выглядело абракадаброй, необходимо знать секретный ключ.

Ниже указаны особенности симметричных алгоритмов:

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

• при шифровании и расшифровке используется один и тот же ключ;

• обычно используется для шифрования содержимого сообщения.

• Примеры: DES, 3DES и AES

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

Асимметричное шифрование

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

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

Ниже указаны особенности асимметричных алгоритмов:

• используется криптография с открытым ключом;

• при шифровании и расшифровке используются разные ключи;

• обычно применяется при управлении цифровыми сертификатами и ключами.

Целостность и алгоритмы хеширования

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

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

На рисунке показано, что Гейл отправил Алексу электронный денежный перевод в размере 100 долл. США. Джереми перехватил и изменил данный перевод таким образом, чтобы показать, что он является получателем, а сумма перевода составляет 1000 долл. США. В этом случае, если использовался алгоритм целостности данных, то хеш-коды не совпадут друг с другом, и транзакция окажется недействительной.

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

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

Код аутентификации сообщений на основе хешей (Hash-based Message Authentication Code, HMAC) - это механизм аутентификации сообщений с помощью функций хеширования. HMAC с обменом ключами представляет собой алгоритм целостности данных, гарантирующий целостность сообщения. HMAC имеет два параметра: вводимое сообщение и секретный ключ, известный только автору сообщения и предполагаемым получателям. Отправитель сообщения использует функцию HMAC для создания значения (кода аутентификации сообщения), формируемого путем переработки секретного ключа и вводимого сообщения. Код аутентификации сообщения отправляется вместе с сообщением. Получатель вычисляет код аутентификации сообщения в полученном сообщении с помощью того же ключа и функции HMAC, которые использовал отправитель. Затем получатель сравнивает вычисленный результат с полученным кодом аутентификации сообщения. Если оба значения совпадают, это означает, что получено правильное сообщение, а получатель может быть уверен в том, что отправитель является членом сообщества пользователей, применяющих данный общий ключ. Криптографическая стойкость алгоритма HMAC зависит от криптографической стойкости базовой функции хеширования, от размера и качества ключа, а также длины результата хеш-функции (в битах).

Существуют два наиболее распространённых алгоритма HMAC:

• MD5 - используется 128-битовый общий секретный ключ. Сообщение произвольной длины и 128-битовый общий секретный ключ объединяются друг с другом и обрабатываются алгоритмом хеширования HMAC-MD5. В результате создаётся 128-битовый хеш-код. Хеш-код добавляется к исходному сообщению и перенаправляется на удалённую сторону.

• SHA - в SHA-1 используется 160-битовый общий секретный ключ. Сообщение переменной длины и 160-битовый общий секретный ключ объединяются друг с другом и обрабатываются алгоритмом хеширования HMAC-SHA1. В результате создаётся 160-битовый хеш-код. Хеш-код добавляется к исходному сообщению и перенаправляется на удалённую сторону.

Примечание . В ОС Cisco IOS также поддерживаются 256-, 384- и 512-битовые варианты SHA.

Аутентификация IPsec

В сетях IPsec VPN поддерживается функция аутентификации. Если ваши партнеры по бизнесу находятся от вас на большом расстоянии, то важно знать, с кем вы говорите по телефону, кто отправляет вам электронное сообщение или факс. Это же справедливо и для сетей VPN. Как указано на рисунке, подлинность устройства на другом конце туннеля VPN должна быть проверена, прежде чем можно будет считать, что канал связи является защищённым. Существуют два метода аутентификации собеседника:

• PSK - секретный ключ, заранее известный двум пользователям, которые общаются по защищённому каналу. В методе предварительно распространённых общих ключей (PSK) используются криптографические алгоритмы с симметричным ключом. Ключ PSK вручную вводится на каждом из взаимодействующих узлов (пиров) и используется для аутентификации друг друга. На каждой стороне ключ PSK объединяется с другой информацией, что позволяет сформировать ключ аутентификации.

В алгоритме IPsec для аутентификации в контексте IKE используется алгоритм RSA (криптографическая система с открытым ключом). В RSA применяется схема цифровой подписи, благодаря которой каждое устройство прикрепляет цифровую подпись к набору данных и передаёт его другому пользователю. Для создания цифрового сертификата с уникальным идентификатором, назначаемого каждому равноправному узлу для аутентификации, в алгоритме подписывания RSA используется центр сертификации (CA). Сам цифровой сертификат идентификации похож на ключ PSK, но обеспечивает гораздо более высокий уровень безопасности. Каждые инициатор и ответчик в сеансе IKE, использующие подписи RSA, отправляют собственное значение идентификатора, свой цифровой сертификат идентификации и значение подписи RSA, состоящее из нескольких значений IKE. Для шифрования всех этих данных применяется согласованный IKE способ шифрования (например AES).

Ещё одним методом аутентификации является алгоритм цифровой подписи (Digital Signature Algorithm, DSA).

Структура протокола IPsec

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

На рисунке 1 показаны два основных протокола IPsec:

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

• Протокол шифрования полезной нагрузки (Encapsulating Security Payload, ESP) - это протокол безопасности, который обеспечивает конфиденциальность и аутентификацию путем шифрования пакета IP. В процессе шифрования пакета IP скрываются данные и идентификаторы источника и назначения. В ESP проверяется подлинность внутреннего пакета IP и заголовка ESP. Аутентификация обеспечивает проверку подлинности источника данных и целостность данных. Хотя процедуры шифрования и аутентификации не являются обязательными в ESP, необходимо выбрать как минимум одну из них.

На рис. 2 показаны компоненты настройки IPsec. Существует четыре основных компоновочных блока структуры IPsec, которые необходимо выбрать.

• Конфиденциальность (если выбран вариант использования IPsec с протоколом ESP) - выбранный алгоритм шифрования должен наилучшим образом обеспечивать требуемый уровень безопасности: DES, 3DES или AES. Настоятельно рекомендуется применять AES (наивысший уровень безопасности обеспечивает схема AES-GCM).

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

• Аутентификация - определяет способ проверки подлинности устройств на обоих концах туннеля VPN. Доступные варианты: PSK или RSA.

• Группа алгоритмов DH - определяет способ генерации общего секретного ключа между узлами. Существует несколько вариантов, но DH24 обеспечивает наивысший уровень безопасности.

Благодаря сочетанию этих компоновочных блоков обеспечиваются конфиденциальность, целостность и аутентификация сетей VPN на IPsec.

Примечание . В этом разделе приводится общее описание протокола IPsec, которое позволяет понять, каким образом IPsec защищает туннели VPN. Процесс настройки сетей IPsec VPN в рамках этого курса не рассматривается.