>

Шифрование ipsec. Как работает ipSec. Входим во внутреннюю сеть

Рассмотрим архитектуру семейства протоколов IPSec. Цель данного семейства протоколов состоит в том, чтобы обеспечить различные сервисы безопасности на уровне IP для протоколов IPv4 и IPv6. Рассмотрим серви-сы безопасности, предоставляемые протоколами IPSec, и использование этих протоколов в сетях ТСР/ IP .

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

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

IPSec может быть реализован как в ОС, так и в маршрутизаторе или межсетевом экране.

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

Перечислим основные задачи протоколов IPSec:

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

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

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

Рассмотрим выполнение протоколов IPSec, основные компоненты системы и их взаимодействие для обеспечения сервисов безопасности.

IPSec выполняется на хосте ( Host – H) или шлюзе безопасности ( Security Gateway – SG), обеспечивая защиту IP -трафика. Термин " шлюз безопасности" используется для обозначения маршрутизатора, который реализует IPsec-протоколы.

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

Возможные способы реализации IPSec

Существует несколько способов реализации IPSec на хосте или совместно с маршрутизатором или межсетевым экраном (для создания шлюза безопасности).

  1. нтеграция IPSec в конкретную реализацию протокола IP. Это требует доступа к исходному коду IP и делается как на хостах, так и на шлюзах безопасности.
  2. "Bump-in-the-stack" (BITS) реализации, когда IPSec реализован "внизу" существующей реализации стека IP-протоколов, встраивая свою реализацию между стандартной реализацией IP-протоколов и локальными сетевыми драйверами. Доступа к исходному коду стека IP в данном случае не требуется. Данный подход обычно реализуется на хостах, когда IPSec реализован в виде подключаемой библиотеки.
  3. Использование внешнего криптопроцессора. Обычно это называется "Bump-in-the-wire" (BITW) реализацией. Такие реализации могут использоваться как на хостах, так и на шлюзах. Обычно BITW-устройства являются IP-адресуемыми.

Протоколы защиты трафика и понятие безопасной ассоциации

Предоставляемые IPSec сервисы по защите трафика реализуются с помощью двух протоколов обеспечения безопасного трафика: Authentication Header ( AH ) и Encapsulating Security Payload ( ESP ).

Для защиты трафика в IPSec определены следующие протоколы:

  1. Протокол Encapsulating Security Payload (ESP) обеспечивает конфиденциальность и целостность протоколов, расположенных выше в стеке протоколов и дополнительно может обеспечиваться анти-replay сервис, т.е. целостность некоторой последовательности дейтаграмм.
  2. Протокол Authentication Header (AH) обеспечивает целостность протоколов, расположенных выше в стеке протоколов и целостность отдельных полей IP-заголовка, которые не изменяются при пересылке от отправителя к получателю, дополнительно может обеспечиваться анти-replay сервис, т.е. целостность некоторой последовательности дейтаграмм. В IPSec v2 реализация данного протокола не является обязательной.
  3. Параметры этих протоколов определяются в протоколе распределения ключей Internet Key Exchange (IKE).

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

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

Опишем различные аспекты управления SA , определим возможные способы управления политикой безопасности, способы обработки трафика и управления SA .

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

Будем рассматривать SA только для одноадресных соединений.

Определены два режима SA : режим транспорта и режим туннелирования. Транспортный режим используется для создания VPN между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP -заголовка. В протоколе ESP транспортный ре-жим SA обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP -заголовка. В случае АН защита распространяется также и на отдельные части IP -заголовка.

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

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

Кратко подытожим:

  1. Хост может поддерживать оба режима, как транспортный, так и туннельный.
  2. Шлюз безопасности как правило использует только туннель-ный режим. Если он поддерживает транспортный режим, то этот режим как правило используется только тогда, когда без-опасный шлюз является получателем трафика, например, для управления сетью.

Набор реализуемых

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

Протоколы IPSec

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

Протоколы IPSec

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(The Internet Key Exchange (IKE)) - Обмен ключами.

  • RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) - Нулевой алгоритм шифрования и его использование.
  • RFC 2411 (IP Security Document Roadmap) - Дальнейшее развитие стандарта.
  • RFC 2412 (The OAKLEY Key Determination Protocol) - Проверка соответствия ключа.

    • Архитектура IPsec

    Протоколы IPsec, в отличие от других хорошо известных протоколов SSL и TLS , работают на сетевом уровне (уровень 3 модели OSI). Это делает IPsec более гибким, так что он может использоваться для защиты любых протоколов, базирующихся на TCP и UDP . IPsec может использоваться для обеспечения безопасности между двумя IP-узлами , между двумя шлюзами безопасности или между IP-узлом и шлюзом безопасности. Протокол является "надстройкой" над IP-протоколом, и обрабатывает сформированные IP-пакеты описанным ниже способом. IPsec может обеспечивать целостность и/или конфиденциальность данных передаваемых по сети.

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

    • Authentication Header (АН) обеспечивает целостность виртуального соединения (передаваемых данных), аутентификацию источника информации и дополнительную функцию по предотвращению повторной передачи пакетов
    • Encapsulating Security Payload (ESP) может обеспечить конфиденциальность (шифрование) передаваемой информации, ограничение потока конфиденциального трафика. Кроме этого, он может обеспечить целостность виртуального соединения (передаваемых данных), аутентификацию источника информации и дополнительную функцию по предотвращению повторной передачи пакетов (Всякий раз, когда применяется ESP, в обязательном порядке должен использоваться тот или иной набор данных услуг по обеспечению безопасности)
    • Security Association (SA) обеспечивают связку алгоритмов и данных, которые предоставляют параметры, необходимые для работы AH и/или ESP. Internet Security Association and Key Management Protocol (ISAKMP) обеспечивает основу для аутентификации и обмена ключами, проверки подлинности ключей.

    Security Association

    Концепция "Защищенного виртуального соединения" (SA, "Security Association") является фундаментальной в архитектуре IPsec. SA представляет собой симплексное соединение , которое формируется для транспортирования по нему соответствующего трафика. При реализации услуг безопасности формируется SA на основе использования протоколов AH или ESP (либо обоих одновременно). SA определен в соответствии с концепцией межтерминального соединения (point-to-point) и может функционировать в двух режимах: транспортный режим (РТР) и режим тунелирования (РТУ). Транспортный режим реализуется при SA между двумя IP-узлами. В режиме туннелирования SA формирует IP-туннель .

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

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

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

    Последовательный номер 32-битовое значение, которое используется для формирования поля Sequence Number в заголовках АН и ESP. Переполнение счетчика порядкового номера Флаг, который сигнализирует о переполнении счетчика последовательного номера. Окно для подавления атак воспроизведения Используется для определения повторной передачи пакетов. Если значение в поле Sequence Number не попадает в заданный диапазон, то пакет уничтожается. Информация AH используемый алгоритм аутентификации, необходимые ключи, время жизни ключей и другие параметры. Информация ESP алгоритмы шифрования и аутентификации, необходимые ключи, параметры инициализации (например, IV), время жизни ключей и другие параметры Режим работы IPsec туннельный или транспортный MTU Максимальный размер пакета, который можно передать по виртуальному каналу без фрагментации.

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

    • AH: алгоритм аутентификации.
    • AH: секретный ключ для аутентификации
    • ESP: алгоритм шифрования.
    • ESP: секретный ключ шифрования.
    • ESP: использование аутентификации (да/нет).
    • Параметры для обмена ключами
    • Ограничения маршрутизации
    • IP политика фильтрации

    Помимо базы данных SADB, реализации IPsec поддерживают базу данных SPD (Security Policy Database- База данных политик безопасности). Запись в SPD состоит из набора значений полей IP-заголовка и полей заголовка протокола верхнего уровня. Эти поля называются селекторами. Селекторы используются для фильтрации исходящих пакетов, с целью поставить каждый пакет в соответствие с определенным SA. Когда формируется пакет, сравниваются значения соответствующих полей в пакете (селекторные поля) с теми, которые содержатся SPD. Находятся соответствующие SA. Затем определяется SA (в случае, если оно имеется) для пакета и сопряженный с ней индекс параметров безопасности(SPI). После чего выполняются операции IPsec(операции протокола AH или ESP).

    Примеры селекторов, которые содержатся в SPD:

    • IP-адрес места назначения
    • IP-адрес отправителя
    • Протокол IPsec (AH, ESP или AH+ESP)
    • Порты отправителя и получателя

    Authentication Header

    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
    8 64 Sequence Number
    C 96 Integrity Check Value (ICV)
    …
    … …
    Next Header (8 bits) Тип заголовка протокола, идущего после заголовка AH. По этому полю приемный IP-sec модуль узнает о защищаемом протоколе верхнего уровня. Значения этого поля для разных протоколов можно посмотреть в RFC 1700 . Payload Len (8 bits) Это поле определяет общий размер АН-заголовка в 32-битовых словах, минус 2. Несмотря на это, при использовании IPv6 длина заголовка должна быть кратна 8 байтам. Reserved (16 bits) Зарезервировано. Заполняется нулями. Security Parameters Index (32 bits) Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (АН-протокол), однозначно определяет защищенное виртуальное соединение(SA) для данного пакета. Диапазон значений SPI 1...255 зарезервирован IANA. Sequence Number (32 bits) Последовательный номер. Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может отказаться от услуги по защите от повторной передачи пакетов, оно является обязательным и всегда присутствует в AH-заголовке. Передающий IPsec-модуль всегда использует это поле, но получатель может его и не обрабатывать. Integrity Check Value

    Протокол 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) SADB (Security Associations Database), используя IP-адрес получателя, протокол безопасности (АН) и индекс SPI. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищенное виртуальное соединение(SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, т.е. на необходимость проверки поля Sequence Number . Если услуга используется, то поле проверяется. Для этого используется метод скользящего окна. Приемный IPsec-модуль формирует окно с шириной W. Левый край окна соответствует минимальному последовательному номеру(Sequence Number ) N правильно принятого пакета. Пакет с полем Sequence Number , в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем приемный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле "Integrity Check Value". Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным и принимается для дальнейшей IP-обработки. Если проверка дала отрицательный результат, то приемный пакет уничтожается.

    Encapsulating Security Payload 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 Security Parameters Index (SPI)
    4 32 Sequence Number
    8 64 Payload data
    … …
    … …
    … … Padding (0-255 octets)
    … … Pad Length Next Header
    … … Integrity Check Value (ICV)
    …
    … …
    Security Parameters Index (32 bits) Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности(АН-протокол), однозначно определяет защищенное виртуальное соединение(SA) для данного пакета. Диапазон значений SPI 1...255 зарезервирован IANA для последующего использования. Sequence Number (32 bits) Последовательный номер. Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может и отказаться от услуги по защите от повторной передачи пакетов, оно всегда присутствует в AH-заголовке. Отправитель(передающий IPsec-модуль) должен всегда использовать это поле, но получатель может и не нуждаться в его обработке. Payload data (variable) Это поле содержит данные в соответствии с полем "Next Header". Это поле является обязательным и состоит из целого числа байтов. Если алгоритм, который используется для шифрования этого поля, требует данных для синхронизации криптопроцессов (например, вектор инициализации - "Initialization Vector"), то это поле может содержать эти данные в явном виде. Padding (0-255 octets) Дополнение. Необходимо, например, для алгоритмов, которые требуют, чтобы открытый текст был кратен некоторому числу байтов), например, размеру блока для блочного шифра. Pad Length (8 bits) Размер дополнения(в байтах). Next Header (8 bits) Это поле определяет тип данных, содержащихся в поле "Payload data". Integrity Check Value Контрольная сумма. Должна быть кратна 8-байтам для IPv6, и 4-байтам для IPv4.

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

    Если передающий IPsec-модуль определяет, что пакет связан с SA, которое предполагает ESP-обработку, то он начинает обработку. В зависимости от режима(транспортный или режим туннелирования) исходный IP-пакет обрабатывается по-разному. В транспортном режиме передающий IPsec-модуль осуществляет процедуру обрамления(инкапсуляции) протокола верхнего уровня(например, TCP или UDP), используя для этого ESP-заголовок и ESP-концевик, не затрагивая при этом заголовок исходного IP-пакета. В режиме туннелирования IP-пакет обрамляется ESP-заголовком и ESP-концевиком, после чего обрамляется внешним IP-заголовком. Далее производится шифрование- в транспортном режиме шифруется только сообщение протокола выше лежащего уровня (т.е. все, что находилось после IP-заголовка в исходном пакете), в режиме туннелирования- весь исходный IP-пакет. Передающий IPsec-модуль из записи о SA определяет алгоритм шифрования и секретный ключ. Стандарты IPsec разрешают использование алгоритмов шифрования triple-DES, AES и Blowfish. Так как размер открытого текста должен быть кратен определенному числу байт, например, размеру блока для блочных алгоритмов, перед шифрованием производится еще и необходимое дополнение шифруемого сообщения. Защифрованное сообщение помещается в поле Payload Data . В поле Pad Length помещается длина дополнения. Затем, как и в AH, вычисляется Sequence Number . После чего считается контрольная сумма(ICV). Контрольная сумма, в отличие от протокола AH, где при ее вычислении учитываются также и некоторые поля IP-заголовка, в ESP вычисляется только по полям ESP-пакета за вычетом поля ICV. Перед вычислением контрольной суммы оно заполняется нулями. Алгоритм вычисления ICV, как и в протоколе AH, передающий IPsec-модуль узнает из записи об SA, с которым связан обрабатываемый пакет.

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

    После получения пакета, содержащего сообщение ESP-протокола, приемный IPsec-модуль ищет соответствующее защищенное виртуальное соединение(SA) в SADB (Security Associations Database), используя IP-адрес получателя, протокол безопасности (ESP) и индекс SPI. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищенное виртуальное соединение(SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, т.е. на необходимость проверки поля Sequence Number. Если услуга используется, то поле проверяется. Для этого, так же как и в AH, используется метод скользящего окна. Приемный IPsec-модуль формирует окно с шириной W. Левый край окна соответствует минимальному последовательному номеру(Sequence Number) N правильно принятого пакета. Пакет с полем Sequence Number, в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем, если используется услуга аутентификации, приемный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле "Integrity Check Value". Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным. Если проверка дала отрицательный результат, то приемный пакет уничтожается. Далее производится расшифрование пакета. Приемный IPsec-модуль узнает из записи об SA, какой алгоритм шифрования используется и секретный ключ. Надо заметить, что проверка контрольной суммы и процедура расшифрования могут проводиться не только последовательно, но и параллельно. В последнем случае процедура проверки контрольной суммы должна закончиться раньше процедуры расшифрования, и если проверка ICV провалилась, процедура расшифрования также должна прекратиться. Это позволяет быстрее выявлять испорченные пакеты, что, в свою очередь, повышает уровень защиты от атак типа "отказ в обслуживании"(DOS-атаки). Далее расшифрованное сообщение в соответствии с полем Next Header передается для дальнейшей обработки.

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

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

    См. также

    Ссылки

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

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

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


    Рис. 5.9.

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

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

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

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

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

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

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

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

    Протокол AH

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


    Рис. 5.10.

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

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


    Рис. 5.12.


    Рис. 5.13.

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

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

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

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

    IPSec и NAT

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

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

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

    Мы уже обсуждали понятие IPSec, в этом материале мы рассмотрим IPSec подробнее.

    Итак, название IPSec происходит от IP Security.
    IPSec - это совокупность протоколов и адлгоритмов, которые используются для защиты IP пакетов на уровне Layer3.

    IPSec позволяет гарантировать:
    - Confidentiality - с помощью шифрования
    - Data integrity - через Hashing и HMAC\
    - Authentication - через использование Digital Signatures или Pre-shared key (PSK).

    Перечислим основные протоколы IPsec:
    ■ ESP and AH : Два основных протокола, используемых в IPsec.
    Encapsulating Security Payload (ESP) , может делать всё что требуется для IPsec, а
    Authentication Header (AH) , может делать всё, кроме шифрования, encryption of the data, - поэтому чаще всего используют ESP.
    ■ Encryption algorithms for confidentiality : DES, 3DES, AES.
    ■ Hashing algorithms for integrity: MD5, SHA.
    ■ Authentication algorithms : Pre-shared keys (PSK), RSA digital signatures.
    ■ Key management : An example would be Diffie-Hellman (DH), which can be used to
    dynamically generate symmetrical keys to be used by symmetrical algorithms; PKI,
    which supports the function of digital certificates issued by trusted CAs; and Internet
    Key Exchange (IKE), which does a lot of the negotiating and management for us for
    IPsec to operate.

    Зачем нужен IPSec

    Рассмотрим следующую простую топологию соединения двух офисов.

    Нам необходимо обеспечить соединение двух офисов и выполнить следующие цели:

    • Confidentiality - обеспечивается через шифрование данных.
    • Data integrity - обеспечивается через hashing, либо через Hashed Message Authentication Code (HMAC) , - методы позволяющие гарантировать, что данные не были изменены.
    • Authentication - обеспечивается с использованием pre-shared keys (PSK) , либо digital signatures . А при использовании HMAC аутентификация происходит постоянно.
    • Antireplay protection - все пакеты VPN нумеруются, что является защитой от их повторения.

    Протоколы и порты IPSec

    IKEv1 Phase 1 UDP port 500 IKEv1 Phase 1 uses UDP:500 for its negotiation.
    NAT-T (NAT
    Traversal)     		UDP port 4500 NAT Traversal используется устройствами для преодоления NAT. Если оба устройства подключаются друг ко другу через NAT: they want to put a fake UDP port 4500
    header on each IPsec packet (before the ESP header) to
    survive a NAT device that otherwise may have a problem
    tracking an ESP session (Layer 4 protocol 50)
    ESP Layer 4 Protocol
    50     		Все пакеты IPSec представляют из себя Layer 4 protocol of ESP (IP Protocol #50), в него инкапсулируются все данные. Обычно используется именно ESP (а не AH). В случае использования NAT-T, ESP header закрывается вторым UDP header.
    AH Layer 4 protocol
    51     		AH packets представляют собой Layer 4 protocol of AH (IP Protocol #51). AH не поддерживает шифрования полезных данных и поэтому он используется редко.

    Работа IPSec

    Для поднятия безопасного соединения VPN, IPSec использует протокол Internet Key Exchange (IKE) .
    IKE - это framework, обеспечиваемая Internet Security Association , а также Key Management Protocol (ISAKMP)

    Итак у нашей конфигурации оба роутера будут выступать в качестве VPN gateway или IPsec peers .

    Предположим юзер в сети 10.0.0.0 отправляет пакет в сеть 172.16.0.0.
    Поскольку туннель ещё не создан R1 начнёт initiate negotiations со вторым роутером R2.

    Step 1: Negotiate the IKEv1 Phase 1 Tunnel

    Первым шагом между роутерами поднимается Internet Key Exchange (IKE) Phase 1 tunnel .
    Такой туннель не предназначен для передачи пользовательских данных, но используется в служебных целях, для защиты management traffic.

    Поднятие IKE Phase 1 tunnel может быть выполнено в двух режимах:
    - main mode
    - aggressive mode
    Main mode требует обмена большим количеством пакетов но и считается более безопасным.

    Для поднятия IKE Phase 1 tunnel должны быть негоциированы следующие элементы:

    • Hash algorithm : Это может быть message digest 5 algorithm (MD5) или Secure Hash
      Algorithm (SHA)       .
    • Encryption algorithm : Digital Encryption Standard (DES) (слабый, не рекомендуется), Triple DES (3DES) (чуть лучше) or Advanced Encryption Standard (AES) (рекомендуется) AES может использовать ключи разной длины: чем длиннее тем безопаснее.
    • Diffie-Hellman (DH) group to use : The DH “group” refers to the modulus size (length of
      the key) to use for the DH key exchange. Group 1 uses 768 bits, group 2 uses 1024, and
      group 5 uses 1536. More secure DH groups are part of the next-generation encryption
      (NGE):
      - Group 14 or 24: Provides 2048-bit DH
      - Groups 15 and 16: Support 3072-bit and 4096-bit DH
      - Group 19 or 20: Supports the 256-bit and 384-bit ECDH groups, respectively

      Задача DH - сгенерировать keying material (symmetric keys). Эти ключи будут использоваться для передачи данных.
      Сам DH является asymmetrical , но ключи он генерирует symmetrical.

    • Authentication method : может быть в виде pre-shared key (PSK) или RSA signatures
    • Lifetime : врем жизни IKE Phase 1 tunnel. Единственный параметр, который может не совпадать. Чем короче Lifetime, тем чаще будут менять ключи, и тем это безопаснее.

    Step 2: Run the DH Key Exchange

    После того, как роутеры договрились об IKE Phase 1 policy, они могут начать процесс DH key exchange. DH позволяет двум устройствам, между которыми пока нет secure connection, безопасно обменяться симметричными ключами, которые будут использоваться симметричными алгоритмами, например AES.

    Step 3: Authenticate the Peer

    Последнее что будет сделано в IKE Phase 1 - это взаимная аутентификация хостов, которая может быть произведена двумя методами (PSK или RSA digital signatures)
    Если аутентификация прошла удачно, IKE Phase 1 tunnel считается поднятым. Туннель является двунаправленным.

    Step 4: IKE Phase 2

    После того, как поднялся IKE Phase 1 tunnel, роутеры начинают поднимать IKE Phase 1 tunnel.
    Как уже упоминалось, IKE Phase 1 tunnel является чисто служебным, management tunnel и через него проходит весь трафик negotiation для поднятия туннеля IKE Phase 2.
    IKE Phase 2 tunnel также использует алгоритмы hashing и encryption.
    Поднятие IKE Phase 2 tunnel может быть выполнено в одном режимы:
    - quick mode

    IKE Phase 2 tunnel на самом деле состоит из двух однонаправленных туннелей, т.е. можно сказать что создаются:
    Один туннель IKE Phase 1 tunnel, который является bidirectional, используемый для служебных функций.
    И два туннеля IKE Phase 2, которые являются unidirectional, и которые используются для шифрования полезного трафика.
    Все эти туннели также называются как security agreements between the two VPN peers или security associations (SA) .
    Каждый SA имеет свой уникальный номер.

    Теперь, после того как был поднят IKE Phase 2 tunnel, все пакеты выходящие из наружных интерфейсов будут зашифрованы.

    Пример настройки


    Рассмотрим пример настройки IPsec на примере данной схемы.

    1. Configure Interesting Traffic
      Для начала мы должны определить трафик, который мы будем шифровать.
      Router R1
      ip access-list extended VPN-ACL permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

      Router R2

      ip access-list extended VPN-ACL permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
    2. Configure Phase 1 (ISAKMP)
      Phase 1 поднимает туннель, используемый для служебных целей: обмен shared secret keys, authenticate, negotiate IKE security policies и т.д.
      Может быть создано несколько isakmp policies с разными приоритетами.

      Router R1

      crypto isakmp key secretkey address 200.200.200.1

      Router R2

      crypto isakmp policy 1 encryption 3des hash md5 authentication pre-share group 2
      crypto isakmp key secretkey address 100.100.100.1

      Здесь key есть PSK(Preshared Key) используемый роутерами для аутентификации IKE Phase 1.

    3. Configure Phase 2 (IPSEc)
      Цель IKE Phase 2 Tunnel - передача полезного трафика между хостами двух офисов.
      Параметры туннеля Phase 2 Tunnel группируются в sets, называемые transform sets.
      Router R1
      crypto ipsec transform-set TRSET esp-3des esp-md5-hmac ! crypto map VPNMAP 10 ipsec-isakmp set peer 200.200.200.1 set transform-set TRSET match address VPN-ACL ! interface FastEthernet0/0 crypto map VPNMAP

      Router R2

      crypto ipsec transform-set TRSET esp-3des esp-md5-hmac ! crypto map VPNMAP 10 ipsec-isakmp set peer 100.100.100.1 set transform-set TRSET match address VPN-ACL ! interface FastEthernet0/0 crypto map VPNMAP

      На обоих хостах использовалась crypto ipsec transform-set TRSET esp-3des esp-md5-hmac.
      Это означает, что 3des будет использовано для шифрования, а md5-hmac для аутентификации.

      crypto map эплаится на интерфейс. Криптокарта отслеживает трафик, отвечающим заданным условиям. Наша криптокарта будет работать с роутером с адресом 100.100.100.1, заданным ACL внутренним трафиком и будет применять на этот трафик transform-set TRSET.

    Проверка IPSec

    В целом список полезных команд следующий:
    show crypto isakmp policy
    show crypto map
    show crypto isakmp sa detail
    show crypto ipsec sa
    show crypto engine connections active

    На практике наиболее полезно следующее: