Cisco Solution Technology Integrator IPsec, IKE и смежные технологии Рябко С.Д., к.ф.-м.н. СТАНДАРТ СЕТЕВОЙ БЕЗОПАСНОСТИ ДЛЯ РОССИЙСКОГО БИЗНЕСА

Cisco Solution Technology Integrator Предпосылки и требования IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ Предпосылки и требования Архитектура IPsec Протокол IKE Применения Литература

© S-Terra CSP 3 Безопасность... задолго до TCP IP Paul Baran. RAND MEMORANDUM RM-3765-PR, AUGUST On Distributed Communications: IX Security, Secrecy, and Tamper-Free Considerations DTE DCE L2-шифрование L3-шифрование

© S-Terra CSP 4 Проблемы безопасности TCP/IP TCP/IP проектировался, как коммуникационный протокол с целями: ­надежной передачи данных через гетерогенные физические среды ­контроля связности сети и маршрутизации ­оптимизации загрузки, адаптации транспортных сервисов к условиям сети TCP/IP ИЗНАЧАЛЬНО НЕ ПРОЕКТИРОВАЛСЯ КАК ЗАЩИЩЕННАЯ КОММУНИКАЦИОННАЯ СРЕДА Результаты: ­IP-атаки ­ICMP-атаки ­атаки на системы маршрутизации ­UDP- и TCP-атаки ­атаки на уровне прикладных протоколов

© S-Terra CSP 5 IPsec, зачатие BOF-сессия IETF в Бостоне в 1992 году, Элтон Гувер (Alton Hoover): ­«Протокол защиты сетевого уровня будет создан, чтобы обеспечить криптографические сервисы защиты: аутентификацию, целостность, контроль доступа и конфиденциальность. Первоначальными целями будет поддержка взаимодействия между компьютерами, вслед на тем – между двумя подсетями и между компьютером и подсетью»

© S-Terra CSP 6 Требования к протоколам защиты 1.Аутентификация, целостность, контроль доступа и конфиденциальность 2.Cеть-сеть, клиент-сеть, клиент-сервер (др. клиент) 3.Нейтральность по отношению к криптоалгоритмам 4.Независимость мастер-ключа и временного ключа 5.Пересинхронизация ключевых контекстов ­по мере накопления статистики для криптоанализа ­по событиям 6.Целостность потока пакетов уход от дейтаграммной природы IP, контекст соединения, SA

© S-Terra CSP 7 Требования по управлению ключами 1.Установление ключа (key establishment) – генерация ключа и доставка его потребителю 2.Аутентификация – поддержка множества механизмов аутентификации: симметричный ключи и сертификат, одноразовый пароль и серверы аутентификации (RADIUS и т.п.), произвольные комбинации этих механизмов 3.Симметрия – равная способность каждой из сторон создать ключ для защищенного обмена; относительная устойчивость к DoS-атаке 4.Защита сеансового ключа (perfect forward secrecy) 5.Независимость сеансовых ключей (back traffic protection) 6.Согласование политик безопасности сторон 7.Расширяемость (payload, domain of interpretation)

© S-Terra CSP 8 История группы IPsec в IETF

Cisco Solution Technology Integrator Архитектура IPsec IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ Предпосылки и требования Архитектура IPsec Протокол IKE Применения Литература

© S-Terra CSP 10 IPsec. Основные стандарты RFC 2402 «IP Authentication Header» (AH) – обеспечивает целостность и аутентификацию передаваемых пакетов, целостность потока пакетов RFC 2406 «IP Encapsulating Security Payload» (ESP) – обеспечивает конфиденциальность (шифрование), целостность и аутентификацию источника данных передаваемых пакетов, ограниченную конфиденциальность потока данных, защиту от повторно переданного пакета ­протоколы AH и ESP могут использоваться совместно или по отдельности RFC 2408 «Internet Security Association and Key Management Protocol» (ISAKMP) - обеспечивает согласование параметров, создание, изменение, уничтожение контекстов защищенных соединений (далее – Security Association, SA) и управление ключами RFC 2409 «The Internet Key Exchange» (IKE) – развитие (адаптация) ISAKMP для работы с протоколами IPsec

© S-Terra CSP 11 Туннельный и транспортный режимы Протоколы IPsec работают в двух режимах: транспортном (взаимодействие хостов) и туннельном (взаимодействие с подсетями) Транспортный режим ­ниже вычислительные и коммуникационные накладные ­недостатки: невозможность скрыть топологию сети ESP в транспортном режиме не защищает заголовок IP-пакета Туннельный режим ­взаимодействие сеть-сеть, хост- сеть, возможно также – хост-хост ­скрывает топологию сети, поскольку снаружи выставляется другой заголовок (а исходный шифруется) ­потребляет несколько больше ресурсов

© S-Terra CSP 12 IPsec. Протокол AH Аутентификация источника и данных каждого IP пакета (является эффективным методом борьбы с атаками типа перехвата, модификации трафика и подмены IP адресов) Целостность данных IP пакетов, данные пакетов передаются в незашифрованном виде Защита от повторной передачи пакетов

© S-Terra CSP 13 IPsec. Протокол AH При расчете значений хеш-сумм для контроля целостности данных (integrity check value, ICV) не используются переменные поля IP-заголовка оригинального пакета AH заголовок увеличивает длину оригинального IP пакета приблизительно на 24 байта Криптографические алгоритмы хеширования поддерживаемые протоколом AH: ­обязательные (для обеспечения совместимости программных продуктов различных производителей): HMAC-MD5-96 (RFC 2403) HMAC-SHA-1-96 (RFC 2404) ­дополнительные: DES-MAC HMAC-ГОСТ Р , Протокол AH может использоваться в туннельном или транспортном режимах, а также в комбинации с протоколом ESP

© S-Terra CSP 14 IPsec. Протокол ESP Протокол ESP обеспечивает: ­шифрование данных IP пакета ­дополнительно (аналогично протоколу AH): аутентификацию источника каждого IP пакета целостность данных IP пакетов защиту от повторной передачи пакетов

© S-Terra CSP 15 IPsec. Протокол ESP ESP заголовок увеличивает длину оригинального IP пакета приблизительно на 24 байта Протокол ESP поддерживает криптографические алгоритмы шифрования: ­обязательные: DES-CBC (RFC 2405) NULL (RFC 2410) ­дополнительные: CAST-128 (RFC 2451) IDEA (RFC 2451) 3DES (RFC 2451) AES- 128, 192, 256 ГОСТ (ГОСТ ) Протокол ESP поддерживает криптографические алгоритмы хэширования: ­обязательные: HMAC-MD5-96 (RFC 2403) HMAC-SHA-1-96 (RFC 2404) ­дополнительные: DES-MAC HMAC-ГОСТ Р , Протокол ESP может использоваться в туннельном или транспортном режимах, а также в комбинации с протоколом AH

© S-Terra CSP 16 AH и ESP в транспортном режиме

© S-Terra CSP 17 AH и ESP в туннельном режиме

© S-Terra CSP 18 Контекст безопасности, IPsec SA Контекст безопасности IPsec, Security Association, SA – это структура данных, которая организуется при помощи протокола IKE для защиты трафика в каждом из направлений ­контекст безопасности уникальным образом определяется, как комбинация Security Parameter Index (SPI), IP Destination address и идентификатор протокола AH/ESP Контексты безопасности соответствуют режиму AH/ESP – транспортный или туннельный В случае, если необходимо создать сложную политику безопасности, которую невозможно описать при помощи одного контекста (SA), используется «связка контекстов» (SA bundle). Связки SA применяются для двух целей: ­в транспортном режиме – для применения одновременно протоколов AH и ESP ­в туннельном режиме – для создания вложенных туннелей, которые могут терминироваться в различных точках сети

© S-Terra CSP 19 Целостность потока пакетов Целостность пакетов в потоке обеспечивается механизмами IPsec AH или IPsec ESP-auth ­эти же механизмы отсекают «чужой» или «свой», модифицированный злоумышленником, пакет КАК ЗАЩИТИТЬСЯ ОТ ПОВТОРНОЙ ПЕРЕДАЧИ СВОЕГО ПАКЕТА? ­счетчик пакетов 2 32 (при инициализации SA устанавливается в 0 и инкрементируется для каждого последующего пакета) ­поскольку пакеты в IP-сети могут переупорядочиваться, дуплицироваться и теряться – оконное управление потоком

© S-Terra CSP 20 Основные преимущества IPsec Прозрачность для любых приложений Полный контроль входящего/исходящего трафика ­IPsec драйвер размещен в нижней части драйвера, реализующего IP протокол Защита от большинства сетевых атак, включая DoS Высокая производительность ­используются симметричные криптографические алгоритмы Большое количество сценариев защиты ­сочетание AH и ESP протоколов ­туннельный и транспортный режимы

Cisco Solution Technology Integrator Протокол IKE IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ Предпосылки и требования Архитектура IPsec Протокол IKE Применения Литература

© S-Terra CSP 22 Протокол IKE Протоколы IPsec AH и ESP не самодостаточны в том смысле, что требуют поставки ключевого материала и политики «извне» Протокол IKE обеспечивает IPsec необходимыми ключами и согласованной политикой Протокол IKE – разработан в развитие протоколов ISAKMP, Oakley и SKEME ­полностью защищен ­расширяем (может применяться для конфигурирования адресов, передачи абстрактных данных - Vendor ID, keep alive и т.п.) ­обеспечивает строгую взаимную аутентификацию партнеров

© S-Terra CSP 23 Функции протокола IKE Протокол IKE обеспечивает: ­создание ключевого криптографического материала и взаимную аутентификацию партнеров по взаимодействию при ключевом обмене ­создание контекстов защищенных взаимно аутентифицированных соединений (ISAKMP Security Association, ISAKMP SA) для обмена ключевой/аутентификационной информацией – первая фаза протокола IKE ­согласование параметров (политик) защищенных соединений (IPsec Security Association, IPsec SA) для обмена данными – вторая фаза протокола IKE ­автоматическую замену криптографических ключей по задаваемому перечню событий или компрометации ­защиту сеансовых криптографических ключей (Perfect forward secrecy, PFS) ­строгую взаимную аутентификацию партнеров по взаимодействию

© S-Terra CSP 24 Фазы и режимы протокола IKE Протокол IKE формально разделен на две фазы Первая фаза может быть реализована в двух разных режимах: ­Main Mode более сложен, но при этом более гибок и обеспечивает анонимность участников (identity protection) ­Aggressive Mode В рамках первой фазы создается контекст защищенного соединения ISAKMP SA, все дальнейшие информационные обмены производятся под его защитой ­однажды созданный на первой фазе контекст ISAKMP SA может использоваться для нескольких вторых фаз, таким образом, на его основе может быть создано несколько IPsec SA

© S-Terra CSP 25 Фазы и режимы протокола IKE (продолжение) Вторая фаза реализована в Quick Mode На второй фазе производится: ­обновление ключевого материала для обеспечения защищенного обмена данными в рамках IPsec AH и/или ESP ­согласование параметров IPsec SA ­защита сеансовых криптографических ключей (Perfect forward secrecy, PFS) Для согласования параметров «собственной» группы DH должна быть использована New Group Mode, которая должна следовать сразу за первой фазой, но не является частью Quick Mode Контекст соединения - ISAKMP SA двунаправленный, т.е. в его рамках любой из участников взаимодействия может быть инициатором Quick Mode, New Group Mode и информационных обменов (Informational Exchanges)

© S-Terra CSP 26 Структура обменов в IKE Задача любой фазы (Main, Aggressive и Quick Modes) – согласовать параметры взаимодействия, обменяться открытыми ключами DH и аутентифицировать ключевой обмен Согласование параметров производится в рамках обменов (Exchange) структурированными (стандартизованными) сообщениями (Message) Каждое сообщение формализовано как набор вложенных структур данных (Payload)

© S-Terra CSP 27 Первая фаза протокола IKE, Main Mode Согласование параметров ISAKMP SA - сообщения 1, 2: ­метод аутентификации ­время жизни ISAKMP SA ­группа DH ­алгоритм хэширования ­алгоритм шифрования Обмен открытыми ключами DH и служебными данными (Nonces) – сообщения 3, 4 Расчет ключевого материала для процедур шифрования и аутентификации в рамках ISAKMP SA Взаимная аутентификация – сообщения 5, 6 ­в Main Mode аутентификационная информация передается в зашифрованном виде Дальнейшие информационные обмены производятся под защитой созданного контекста (SA)

© S-Terra CSP 28 Первая фаза IKE, Aggressive Mode Выбор между безопасностью и производительностью Как и в Main Mode партнеры должны согласовать: ­метод аутентификации ­время жизни ISAKMP SA ­группу DH ­алгоритм хэширования ­алгоритм шифрования Произвести обмен открытыми ключами DH и служебными данными и расчет ключевого материала Провести взаимную аутентификацию ­аутентификационная информация передается в открытом виде

© S-Terra CSP 29 Методы аутентификации В рамках протокола IKE стандартизованы четыре метода аутентификации: ­на предопределенных ключах - with a Pre-Shared Key ­на электронной цифровой подписи - with Signature ­шифрование на открытых ключах with Public Key Encryption with a Revised Mode of Public Key Encryption ­наиболее широко используемые методы – на предопределенных ключах и ЭЦП

© S-Terra CSP 30 Вторая фаза протокола IKE, Quick Mode Вторая фаза протокола IKE реализуется в Quick Mode ­согласование параметров IPsec SA ­обновление ключевого материала для обеспечения защищенного обмена данными в рамках IPsec AH и/или ESP ­защита сеансовых криптографических ключей (Perfect forward secrecy, PFS)

Cisco Solution Technology Integrator Применения IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ Предпосылки и требования Архитектура IPsec Протокол IKE Применения Литература

© S-Terra CSP 32 Роль и место IKE/IPsec Что мне лучше использовать – защиту сетевого, транспортного и прикладного уровня? ­И то, и другое, и третье, но в разных сценариях ­Защита сетевого уровня нужна там, где требуется создать изолированную доверенную среду предприятия, единую для всех приложений ­Защита транспортного уровня пригодится там, где у Вас нет возможности установить для всех пользователей VPN-клиента, например, в задачах защиты доступа граждан к порталу госорганов или в задачах электронной коммерции ­Защита прикладного уровня незаменима при работе с электронными документами

© S-Terra CSP 33 L3 или L4 VPN? Равнозначны (равнозащищены) ли технологии VPN сетевого (IPsec) и транспортного (SSL, TLS) уровней? ­С точки зрения стойкости криптографий – да ­С точки зрения дизайна криптографических протоколов предпочтение экспертов принадлежит IKE/IPsec (The Burton group) ­По целям дизайна протоколы 4го уровня рассчитаны на защиту отдельного приложения (защита транспортного соединения порт-порт в системе клиент-сервер). Другие порты на том же сервере могут быть открыты (и атакованы). VPN сетевого уровня может защитить сетевую инфраструктуру или сервер в целом Однако в последнее время появились и приобретают популярность «шлюзовые» L4 VPN-продукты, которые «умеют» инкапсулировать IP-трафик в SSL/TLS. Такие продукты функционально практически эквивалентны L3 VPN с двумя отличиями: (1) функциональность протокола управления ключами в SSL/TLS много уступает IKE и (2) поскольку это – «нетрадиционное» использование протокола на сегодня «шлюзовые» продукты L4 VPN от разных производителей плохо совместимы между собой

© S-Terra CSP 34 IPsec в «реальной сети» Как работает IPsec AH при наличии NAT? (Целостность заголовка противоречит трансляции адресов) ­В хороших реализациях IKE/IPsec – без проблем. IKE автоматически детектирует NAT на пути туннеля и включает режим «NAT traversal IPsec» Как обстоят дела с фрагментацией? ­Корректный VPN-продукт умеет фрагментировать/ дефрагментировать шифрованный трафик. Однако при этом производительность шифрования падает. Рекомендуется настройка MTU «с запасом» на заголовки IPsec Насколько повышают общую защищенность системы контроля целостности ESP-auth и AH? ­Полезная функция, однако может приводить к «узкому горлу» в производительности. Поэтому ряд наших заказчиков устраивает политика безопасности, когда для защиты трафика используется IPsec ESP, а целостность потока данных «обеспечивает» TCP ­Также интересным является решение, когда целостность обеспечивается на «внешних» маршрутизаторах на базе IPsec AH/MD5, а конфиденциальность – во внутреннем периметре на базе IPsec ESP/ГОСТ

© S-Terra CSP 35 Какова избыточность протоколов IPsec? Зависит от политики безопасности и криптографии. Расчет Кирилла Корнилова (для IPv4): ­Протокол AH: 12 байт + длина digest, все это округляется кратного 4 в большую сторону, если туннель - еще +20 байт длина digest: HMAC 96 (SHA1, MD5, ГОСТ) - 12 байт (полное увеличение пакета – ) KPDK (MD5) - 16 байт (полное увеличение пакета – ) ­ Протокол ESP: 8 байт + длина IV + длина digest + 2 байта, длина шифрованных данных дополняется до блока алгоритма если туннель - еще +20 байт если NAT traversal - еще +8 байт если нет integrity - длина digest = 0 если нет шифрования - длина блока = 1, длина IV = 0 Длина IV, длина блока: DES, 3DES, ГОСТ - 8 байт AES - 16 байт Например, ESP/ГОСТ без integrity, туннельный режим, без NAT traversal увеличивает пакет на байт

© S-Terra CSP 36 Еще пара вопросов Нужен ли IPcomp? ­по нашему опыту статистическая база пакета не дает возможности обеспечить его существенное сжатие ­Cisco не рекомендует IPcomp по причинам снижения производительности (при малой эффективности сжатия) и плохой совместимости ПО Совместимы ли VPN-продукты различных производителей? ­В базовых протоколах IKE/IPsec – да. Однако из-за несовместимости дополнительных спецификаций и различной инфраструктуры/логики управления целесообразно минимизировать количество используемых VPN-продуктов

Cisco Solution Technology Integrator Литература IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ Предпосылки и требования Архитектура IPsec Протокол IKE Применения Литература

© S-Terra CSP 38 Источники разработки 1.RFC 2401, Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. November RFC 2402, IP Authentication Header. S. Kent, R. Atkinson. November RFC 2403, The Use of HMAC-MD5-96 within ESP and AH. C. Madson, R. Glenn. November RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH. C. Madson, R. Glenn. November RFC 2405, The ESP DES-CBC Cipher Algorithm With Explicit IV. C. Madson, N. Doraswamy. November RFC 2406, IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson. November RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP. D. Piper. November RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner. November RFC 2409, The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November RFC 2410 The NULL Encryption Algorithm and Its Use With IPsec. R. Glenn, S. Kent. November RFC 2411, IP Security Document Roadmap. R. Thayer, N. Doraswamy, R. Glenn. November RFC 2412, The OAKLEY Key Determination Protocol. H. Orman. November Московиц Р. Протокол IPSec для групп по интересам // Network Computing Busby M. Demystifying Virtual Private Networks. Wordware Publishing, Inc p. 15.A Comprehensive Guide to Virtual Private Networks, Volume II: IBM Nways Router Solutions. IBM. International Technical Support Organization SG November p. 16.Davies C.R. IPSec: Securing VPNs. Osborne/McGraw-Hill, p. 17.Using IPSec to Construct Secure Virtual Private Networks. International Business Machines Corporation p.

Cisco Solution Technology Integrator Вопросы? Обращайтесь к нам! КОНТАКТЫ web: Тел.:+7 (495) (495) Факс:+7 (495)