Esp шифрование. Как работает ipSec. Туннельный и транспортный режимы IPSec

(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) (англ.)

Виртуальные частные сети (VPN)
Программное обеспечение	Chaply Check Point VPN-1 Cisco Systems VPN Client CloudVPN CryptoLink Gbridge Hamachi Jabpunch Microsoft Forefront Unified Access Gateway n2n NetworkManager OpenVPN Openswan pLan OpenVPN Edition (ZeroGC Gaming Client) rp-pppoe Social VPN strongSwan Tinc tcpcrypt Vyatta Wippien
Механизмы
Управляемые поставщиком

Механизмы безопасности в

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

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

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

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

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

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

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

К IP-данным, готовым к передаче по виртуальной частной сети, IPSec добавляет заголовок для идентификации защищенных пакетов. Перед передачей по Internet эти пакеты инкапсулируются в другие IP-пакеты. IPSec поддерживает несколько типов шифрования, в том числе Data Encryption Standard (DES) и Message Digest 5 (MD5).
Чтобы установить защищенное соединение, оба участника сеанса должны иметь возможность быстро согласовать параметры защиты, такие как алгоритмы аутентификации и ключи. IPSec поддерживает два типа схем управления ключами, с помощью которых участники могут согласовать параметры сеанса. Эта двойная поддержка в свое время вызвала определенные трения в IETF Working Group.
С текущей версией IP, IPv4, могут быть использованы или Internet Secure Association Key Management Protocol (ISAKMP), или Simple Key Management for Internet Protocol. С новой версией IP, IPv6, придется использовать ISAKMP, известный сейчас как IKE, хотя не исключается возможность использования SKIP. Однако, следует иметь в виду, что SKIP уже давно не рассматривается как кандидат управления ключами, и был исключен из списка возможных кандидатов еще в 1997 г.

заголовки AH и ESP

аутентифицирующий заголовок AH

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

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

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

инкапсуляция зашифрованных данных ESP

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

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

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

Security Associations

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

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

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

протокол ISAKMP/Oakley

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

протокол IKE

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

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

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

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

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

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

Все виды атак на компоненты IPSec можно разделить на следующие группы: атаки, эксплуатирующие конечность ресурсов системы (типичный пример - атака "Отказ в обслуживании", Denial-of-service или DOS-атака), атаки, использующие особенности и ошибки конкретной реализации IPSec и, наконец, атаки, основанные на слабостях самих протоколов AH и ESP. Чисто криптографические атаки можно не рассматривать - оба протокола определяют понятие "трансформ", куда скрывают всю криптографию. Если используемый криптоалгоритм стоек, а определенный с ним трансформ не вносит дополнительных слабостей (это не всегда так, поэтому правильнее рассматривать стойкость всей системы - Протокол-Трансформ-Алгоритм), то с этой стороны все нормально. Что остается? Replay Attack - нивелируется за счет использования Sequence Number (в одном единственном случае это не работает - при использовании ESP без аутентификации и без AH). Далее, порядок выполнения действий (сначала шифрация, потом аутентификация) гарантирует быструю отбраковку "плохих" пакетов (более того, согласно последним исследованиям в мире криптографии, именно такой порядок действий наиболее безопасен, обратный порядок в некоторых, правда очень частных случаях, может привести к потенциальным дырам в безопасности; к счастью, ни SSL, ни IKE, ни другие распространенные протоколы с порядком действий "сначала аутентифицировать, потом зашифровать", к этим частным случаям не относятся, и, стало быть, этих дыр не имеют). Остается Denial-Of-Service атака.

Как известно, это атака, от которой не существует полной защиты. Тем не менее, быстрая отбраковка плохих пакетов и отсутствие какой-либо внешней реакции на них (согласно RFC) позволяют более-менее хорошо справляться с этой атакой. В принципе, большинству (если не всем) известным сетевым атакам (sniffing, spoofing, hijacking и т.п.) AH и ESP при правильном их применении успешно противостоят. С IKE несколько сложнее. Протокол очень сложный, тяжел для анализа. Кроме того, в силу опечаток (в формуле вычисления HASH_R) при его написании и не совсем удачных решений (тот же HASH_R и HASH_I) он содержит несколько потенциальных "дыр" (в частности, в первой фазе не все Payload в сообщении аутентифицируются), впрочем, они не очень серьезные и ведут, максимум, к отказу в установлении соединения.От атак типа replay, spoofing, sniffing, hijacking IKE более-менее успешно защищается. С криптографией несколько сложнее, - она не вынесена, как в AH и ESP, отдельно, а реализована в самом протоколе. Тем не менее, при использовании стойких алгоритмов и примитивов (PRF), проблем быть не должно. В какой-то степени можно рассматривать как слабость IPsec то, что в качестве единственного обязательного к реализации криптоалгоритма в нынешних спецификациях указывается DES (это справедливо и для ESP, и для IKE), 56 бит ключа которого уже не считаются достаточными. Тем не менее, это чисто формальная слабость - сами спецификации являются алгоритмо-независимыми, и практически все известные вендоры давно реализовали 3DES (а некоторые уже и AES).Таким образом, при правильной реализации, наиболее "опасной" атакой остается Denial-Of-Service.

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

Протокол IPSec получил неоднозначную оценку со стороны специалистов. С одной стороны, отмечается, что протокол IPSec является лучшим среди всех других протоколов защиты передаваемых по сети данных, разработанных ранее (включая разработанный Microsoft PPTP). По мнению другой стороны, присутствует чрезмерная сложность и избыточность протокола. Так, Niels Ferguson и Bruce Schneier в своей работе "A Cryptographic Evaluation of 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, в этом материале мы рассмотрим 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

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

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

IPsec существует в виде расширения протокола IPv4 и является неотъемлемой частью IPv6. Рассматриваемый протокол обеспечивает безопасность IP-уровня сети (3 уровень в модели ISO/OSI, рис. 1), что позволяет обеспечить высокий уровень защиты, прозрачный для большинства приложений, служб и протоколов верхнего уровня, использующих в качестве транспорта протокол IP. IPSec не требует внесения изменений в существующие приложения или операционные системы.

Рис. 1, Модель ISO/OSI.

Внедрение безопасности на данном уровне обеспечивает защиту для всех протоколов семейства TCP/IP, начиная с уровня IP, таких как TCP, UDP, ICMP, а также множества других.

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

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

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

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

Субпротоколы AH (Authentication Header) и ESP (Encapsulating Security Payload) могут использоваться как совместно для обеспечения наибольшего уровня безопасности, так и независимо друг от друга.

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

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

В транспортном режиме протоколы AH и ESP имеют следующие функции и возможности:

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

Рис. 2, Размещение заголовка АН

Рис. 3, Охват AH (транспортный режим)

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

Рис. 4, Размещение заголовка и трейлеров ESP

Рис. 5, Охват ESP (транспортный режим)

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

AH в режиме туннеля подписывает пакет для сохранения целостности и инкапсулирует его в заголовки IP и AH (рисунок 6), при этом данные остаются доступными для чтения.

Рис. 6, Охват AH (туннельный режим)

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

Рис. 7, Охват ESP (туннельный режим)

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

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

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

Настройка

Описание настройки VPN-туннелей, как и рассмотрение их свойств и возможностей, выходит за рамки данной статьи, поэтому ограничимся описанием процесса настройки транспортного режима IPsec.

В Windows XP настройка IPsec выполняется посредством оснастки «Локальные параметры безопасности», запуск которой возможен из меню «Администрирование», «Панели управления», либо через команду «Выполнить» «secpol.msc». Возможно использование созданных по умолчанию политик, либо создание новой.

Для создания политики безопасности IP необходимо выделить из списка пункт «Политики безопасности IP» и в меню «Действие» выбрать «Создать политику безопасности IP».

Рис. 8, Создание политики безопасности IP

Откроется «Мастер политики IP-безопасности». Для продолжения следует нажать «Далее». В следующем окне нужно ввести имя новой политики, и нажать «Далее».

Рис. 9, Имя политики IP

В следующем окне «Мастер» предложит принять решение использовать ли правило по умолчанию. Использование этого правила можно отменить и после создания политики, если возникнет такая необходимость.

Рис. 10, Правило по умолчанию

После этого «Мастер» предлагает выбрать способ проверки подлинности пользователя. IPsec поддерживает следующие способы: посредством протокола Kerberos (стандартный протокол аутентификации в доменах Windows 2000 и Windows 2003), с помощью сертификата пользователя, либо на основании строки защиты («пароля»). Если в вашей сети нет контроллеров домена и пользователи сети не обладают действительными сертификатами, остается только выбрать строку посложнее и держать ее в строгой тайне. Строка защиты на самом деле может состоять из нескольких строк.

Рис. 11, Выбор способа аутентификации

Создание политики практически закончено. Изменить свойства можно немедленно по завершении работы мастера (окно свойств откроется автоматически), либо позже, выделив нужную политику и выбрав из контекстного меня пункт «Свойства».

Рис. 12, Завершение создания политики

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

Для создания правила безопасности необходимо открыть свойства созданной политики безопасности IP и на вкладке «Правила» нажать кнопку «Добавить», предварительно сняв флажок «Использовать мастер», как показано на рисунке 13.

Рис.13, Создание правила безопасности IP

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

Рис. 14, Тип подключения

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

Рис. 15, Методы проверки подлинности

После выбора типа подключений и методов проверки подлинности следует выбрать список фильтров IP и действие фильтра, либо создать новые. Для выбора либо создания фильтров IP следует перейти на закладку «Список фильтров IP»(рисунок 16).

По умолчанию созданы следующие фильтры:

Полный IP-трафик, который применяется ко всему IP-трафику, независимо от используемого протокола более высокого уровня;

Полный ICMP-трафик, который применяется соотвественно ко всему ICMP-трафику.

Рис. 16, Список фильтров IP.

Для создания нового фильтра следует нажать кнопку «Добавить», после чего откроется окно «Список фильтров IP», где, после ввода имени списка фильтров и снятия галочки «Использовать мастер», следует нажать кнопку «Добавить»(рисунок 17).

Рис. 17, Создание списка фильтров IP.

Откроется окно «Свойства: Фильтр» (рисунок 18), где следует указать адреса источника и получателя пакетов, к которым будет применяться фильтр, а также, при необходимости, протокол и порты источника и получателя.

Рис. 18, Параметры нового списка фильтров IP

После выбора или создания списков фильтров, необходимо определить действие фильтра. Это можно сделать на закладке «Действие фильтра». Созданные по умолчанию действия:

Разрешить, которое разрешает прохождение небезопасных пакетов (без использования IPsec),

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

Последнее предустановленное действие – Запрос безопасности – предусматривает требование от клиентов безопасной связи, но при невыполнении этих требований небезопасная связь прервана не будет.

Рис. 19, Действия фильтра

Создать новое действие можно нажав на кнопку «Добавить», предварительно сняв флажок «Использовать мастер» (рисунок 19). На вкладке «Методы безопасности» открывшегося окна «Свойства: создание действия фильтра», следует указать нужно ли разрешить прохождение данных, заблокировать их либо согласовать безопасность(рисунок 20).

Рис. 20, Пустой список возможных действий фильтра

Если выбран пункт согласовать безопасность, можно добавить методы безопасности и изменить порядок их предпочтения. При добавлении методов безопасности следует выбрать, будет ли использоваться AH, ESP, либо настроить безопасность вручную, выбрав пункт «Настраиваемая безопасность». Только таким образом можно задействовать и AH и ESP. В параметрах настраиваемой безопасности устанавливаются требуемые протоколы (AH и ESP)(рисунок 21).

Рис. 21, Создание действия фильтра

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

Рис. 22, Параметры особого метода безопасности

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

Тестирование

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

Тестирование производилось на компьютерах следующей конфигурации:

	Компьютер 1	Компьютер 2
Процессор	AMD Athlon 64 3000+ Socket 754	AMD Athlon XP 1700+ Socket А
Материнская плата
	2*512 Mb Samsung PC 3200	256 Mb Samsung PC 2700
Жесткий диск	Seagate ST3160023A	Seagate ST380011A
Сетевой адаптер

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

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

Без использования IPsec, файл был передан за 86 с. При этом загруженность процессоров на обоих компьютерах была не высока, как показано на рисунках 23 и 24, а средняя скорость передачи данных достигла 65,21 Мбит/с.

После этого IPsec был настроен описанным выше образом для обеспечения целостности передаваемых данных (субпротокол AH с использованием SHA-1).

Время передачи данных возросло незначительно, до 91 с, а скорость незначительно упала, до 61,63 Мбит/с. При этом загрузка процессоров выросла не на много и изображена на рисунках 25 и 26.

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

Файл передан за 93 с, скорость передачи составила 60,3 Мбит/с. Загрузка процессоров показана соответственно на рисунках 27 и 28. Следует заметить, что DES является устаревшим алгоритмом и не рекомендуется к использованию там, где защищаемые данные действительно имею большую ценность. В то же время стойкость этого алгоритма может быть значительно улучшена благодаря более частой смене ключа.

При использовании более стойкого 3DES вместо DES в той же конфигурации (MD5), скорость передачи упала более чем в два раза, и составила 29,99 Мбит/с, а время соответственно 187 с. Графики загруженности процессоров практически не изменились (рисунки 29 и 30).

При использовании ESP с 3DES и SHA1 время передачи выросло на 1с (до 188), а скорость упала до 29,83 Мбит/с. Приводить графики загруженности процессора нет смысла – они такие же как на рисунках 29 и 30.

Используя совместно с ESP протокол AH в наиболее безопасной, а значит и наиболее ресурсоемкой конфигурации, доступной в Windows XP, получены следующие результаты: время передачи увеличилось до 212 с, скорость упала до 26,45 Мбит/с.

Диаграмма 1, Время передачи файла и скорость в зависимости от используемых криптографических алгоритмов

Как видно из результатов тестирования (диаграмма 1), ресурсоемкость IPsec невысока при использовании только лишь AH и при применении ESP с DES. В случае же использования 3DES производительность резко падает, но при низких скоростях передачи данных производительности даже устаревших процессоров будет достаточно. Там же, где требуется высокая скорость передачи данных, может оказаться достаточным использование DES с частой сменой ключа. Характерно, что загрузка двух процессоров различного класса не слишком отличалась.