Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Основы IPsec

Обзор IPsec

IPsec – это набор сопутствующих протоколов для криптографической защиты данных на уровне IP-пакетов. IPsec также предоставляет методы ручного и автоматического согласования ассоциаций безопасности (SAS) и распределения ключей, все атрибуты, для которых собраны в домене интерпретации (DOI). IPsec DOI – это документ, содержащий определения всех параметров безопасности, необходимых для успешного согласования VPN туннеля — по сути, все атрибуты, необходимые для SA и IKE согласований. Дополнительные сведения см. в RFC 2407 и RFC 2408.

Чтобы использовать службы безопасности IPsec, между хостами создаются SAS. SA – это простое соединение, которое позволяет двум хостам взаимодействовать друг с другом безопасно при помощью IPsec. Существует два типа SAS: ручной и динамический.

IPsec поддерживает два режима безопасности (транспортный и туннельный).

Связи безопасности

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

  • Конфиденциальность (посредством шифрования)

  • Целостность содержимого (с помощью аутентификации данных)

  • Аутентификация отправитель и (при использовании сертификатов) нерезиляция (с помощью аутентификации источника данных)

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

Туннель IPsec состоит из пары однонаправленных SA — по одной SA для каждого направления туннеля, которые определяют индекс параметра безопасности (SPI), IP-адрес назначения и протокол безопасности (Заглавная пара аутентификации [AH] или инкапсулирующий security полезная нагрузка [ESP]. SA объединяет следующие компоненты для обеспечения безопасности связи:

  • Алгоритмы и ключи обеспечения безопасности.

  • Протокольный режим ( транспортный или туннельный). Junos OS устройства всегда используют туннельный режим. (См. "Обработка пакетов в туннельном режиме.)

  • Метод управления ключами, ручной ключ или autoKey IKE.

  • Срок действия SA.

Для входящий трафика Junos OS sa с помощью следующего триплета:

  • IP-адрес назначения.

  • Протокол безопасности AH или ESP.

  • Значение индекса параметра безопасности (SPI).

Для исходя трафика VPN политика вызывает SA, связанную с туннелем VPN.

Управление ключами IPsec

Распределение и управление ключами очень важно для успешного использования VPN. Junos OS IPsec поддерживает технологию создания VPN-туннелей с тремя типами механизмов создания ключей:

  • Ключ вручную

  • AutoKey IKE с предварительным ключом или сертификатом

Механизм создания ключей (также называемый методом аутентификации) можно выбрать в фазах 1 и 2 в конфигурации предложений. См. Internet Key Exchange.

Данная тема включает в себя следующие разделы:

Ключ вручную

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

AutoKey IKE

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

  • AutoKey IKE с предварительными ключами — использование IKE AutoKey с предварительно предварительными ключами для аутентификации участников сеанса IKE, каждая сторона должна заранее настроить и безопасно обмениваться предварительным ключом. В этом отношении проблема защищенного распределения ключей такая же, как и при ручных ключах. Однако после распределенного использования автоматическое управление, в отличие от ручного ключа, может автоматически изменить свои ключи через заранее определенные интервалы с помощью IKE протокола. Частое изменение ключей значительно улучшает безопасность и автоматически снижает ответственность за управление ключами. Однако изменение ключей увеличивает объем трафика; поэтому слишком частое изменение ключей может снизить эффективность передачи данных.

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

  • AutoKey IKE сертификатами — при использовании сертификатов для аутентификации участников во время согласования IKE AutoKey каждая сторона генерирует пару общедоступных частных ключей и получает сертификат. Пока команды, центр сертификации (CA) доверенные обеими сторонами, участники могут извлечь открытый ключ одноранговых участников и проверить подпись одноранговых участников. Нет необходимости отслеживать ключи и SAS; IKE делает это автоматически.

Diffie-Hellman Exchange

Обмен Diffie-Hellman (DH) позволяет участникам создавать общее секретное значение. Сила метода заключается в том, что он позволяет участникам создавать секретное значение через незащиченную среду без передачи секретного значения через провод. Размер обычного модуля, используемого в расчетах каждой группы, отличается, как показано в таблице ниже. Обмен Diffie Hellman (DH) может выполняться как в программном, так и в аппаратном обеспечении. Когда эти операции обмена выполняются на аппаратном оборудовании, мы используем криптографию QuickАst Technology (QAT). Ниже Табл. 1 перечислены различные группы Diffie Hellman (DH) и указывается, выполняется ли операция для этой группы в оборудовании или программном обеспечении.

Табл. 1: Группы Diffie Hellman (DH) и их обмен операциями

Группа Diffie-Hellman (DH)

Размер простого модуля

Группа 1 DH

768-bit

Группа 2 DH

102-bit

Группа 5 DH

1536-bit

Группа 14 DH

2048-bit

Группа 15 DH

3072-bit

Группа 16 DH

4096-bit

Группа DH 19

256-битная эллиптическая заглухо

Группа 20 DH

384-битная эллиптическая заглухо

Группа DH 21

521-битная эллиптическая заглухо

Группа DH 24

2048-бит с 256-битной подгруппой в порядке простого

Начиная Junos OS выпуске 19.1R1, серия SRX поддерживают группы DH 15, 16 и 21.

Начиная Junos OS выпуске 20.3R1, vSRX, где пакет junos-ike установлен для групп поддержки DH 15, 16 и 21.

Не рекомендуется использовать группы DH 1, 2 и 5.

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

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

IPsec использует два протокола для обеспечения безопасности связи на уровне IP:

  • Заглавная часть аутентификации (AH) — протокол безопасности для аутентификации источника IP-пакета и проверки целостности его содержимого.

  • Инкапсулирование полезная нагрузка безопасности (ESP) — протокол безопасности, шифрующий весь IP-пакет (и аутентификация его содержимого)

Во время настройки предложений фазы 2 можно выбрать протоколы безопасности (также называемыеалгоритмами аутентификации и шифрования). См. Internet Key Exchange.

Для каждого VPN-туннеля сеансы туннеля AH и ESP устанавливаются на процессоры обработки служб (SPUs) и на плоскость управления. После завершения согласования сеансы туннеля обновляются согласованным протоколом. Для SRX5400, SRX5600 и SRX5800, сеансы туннеля на якорных spUs обновляются с помощью согласуемого протокола, в то время как неякорные SPUs сохраняют сеансы ESP и AH туннеля. Сеансы туннеля ESP и AH отображаются в выходных данных команд show security flow sessionshow security flow cp-session оперативного режима и режима эксплуатации.

Данная тема включает в себя следующие разделы:

Алгоритмы аутентификации IPsec (протокол AH)

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

  • Message Digest 5 (MD5) — алгоритм, который создает 128-битный hash (также называемый цифровой подписью или дайджест сообщений) из сообщения произвольной длины и 16-byte-ключа. Итоговая hash используется, например, как разметка входных данных, для проверки подлинности и целостности содержимого и источника.

  • Secure Hash Algorithm (SHA) — алгоритм, который создает 160-битный hash-сигнал из сообщения произвольной длины и 20-byte-ключа. Как правило, он считается более безопасным, чем MD5, из-за большего числа его хеш-сема. Поскольку вычислительная обработка обрабатывается в ASIC, стоимость производительности является неозначимой.

Для получения дополнительных сведений об алгоритмах хаширования MD5 см. RFC 1321 и RFC 2403. Дополнительные сведения об алгоритмах hashing SHA см. в RFC 2404. Дополнительные сведения о HMAC см. в RFC 2104.

Алгоритмы шифрования IPsec (протокол ESP)

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

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

  • Стандарт шифрования данных (DES) — алгоритм криптографического блока с 56-битным ключом.

  • Triple DES (3DES)— более мощный вариант DES, в котором исходный алгоритм DES применяется в три этапа с использованием 168-битного ключа. DES обеспечивает значительную экономию производительности, но считается неприемлемым для многих классифицированных или чувствительных к передаче материалов.

  • Расширенный стандарт шифрования (AES) — стандарт шифрования, который обеспечивает более высокий уровень связи с другими устройствами. Junos OS AES с 128-битными, 192-битными и 256-битными ключами.

Для аутентификации можно использовать алгоритмы MD5 или SHA.

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

Согласование туннеля IPsec

Следующие два различных режима определяют способ обмена трафиком в VPN.

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

  • Транспортный режим — защитите трафик, отправив пакет непосредственно между двумя хостами, которые установили туннель IPsec. То есть, когда конечная точка связи и криптографическая конечная точка одинаковы. Часть IP-пакета шифруется, а заглавная ip - нет. Шлюзы VPN, которые предоставляют услуги шифрования и дешифрования для защищенных хостов, не могут использовать транспортный режим для защищенной VPN-связи. В случае перехвата пакета IP-адреса источника или адресата могут быть изменены. Вследствие своей конструкции транспортный режим может использоваться только тогда, когда конечная точка связи и криптографическая конечная точка одинаковы.

Стандарты IPsec и IKE IPsec

На маршрутизаторах, оснащенных одним или более MS-MCS, MS-MICs, или DPC, канада и США версии Junos OS значительно поддерживают следующие документы, определяя стандарты ip Security (IPsec) и Internet Key Exchange (IKE).

  • RFC 2085, IP-аутентификация HMAC-MD5 с предотвращением повторного воспроизведения

  • RFC 2401, архитектура безопасности для протокола Интернета (устаревший по RFC 4301)

  • RFC 2402. Задаток аутентификации IP (устаревший по RFC 4302)

  • RFC 2403. Использование HMAC-MD5-96 в ESP и AH

  • RFC 2404. Использование HMAC-SHA-1-96 в ESP и AH (устаревший RFC 4305)

  • RFC 2405, алгоритм шифров ESP DES-CBC с явным IV

  • RFC 2406. Ip Encapsulating Security полезная нагрузка (ESP) (устаревший под RFC 4303 и RFC 4305)

  • RFC 2407. Интерпретация домена IP-безопасности Интернета для ISAKMP (устаревший под RFC 4306)

  • RFC 2408. Протокол управления ассоциациями безопасности и ключами в Интернете (ISAKMP) (устаревший по RFC 4306)

  • RFC 2409, Internet Key Exchange (IKE) (устаревший RFC 4306)

  • RFC 2410, алгоритм NULL-шифрования и его использование с IPsec

  • RFC 2451. Алгоритмы шифров ESP в режиме CBC

  • RFC 2460, Интернет-протокол, версия 6 (IPv6)

  • RFC 2560, X.509 Internet Public Key Infrastructure Протокол состояния интернет-сертификатов - OCSP

  • RFC 3193. Обеспечение безопасности L2TP с помощью IPsec

  • RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

  • RFC 3602, алгоритм шифров AES-CBC и его использование с IPsec

  • RFC 3948, Инкапсуляция пакетов IPsec ESP UDP

  • RFC 4106. Использование режима счетчика (GCM) в инкапсуляции безопасности IPsec полезная нагрузка (ESP)

  • RFC 4210, Интернет X.509 Протокол управления сертификатами инфраструктуры открытых ключей (CMP)

  • RFC 4211, Формат сообщения запроса сертификата инфраструктуры открытых ключей Интернет X.509 (CRMF)

  • RFC 4301, архитектура безопасности для протокола Интернета

  • RFC 4302, загвоздка аутентификации IP

  • RFC 4303, IP-инкапсулирующий полезная нагрузка (ESP)

  • RFC 4305. Требования к внедрению криптографического алгоритма для инкапсуляции полезная нагрузка безопасности (ESP) и заглавной области аутентификации (AH)

  • Протокол RFC 4306 Internet Key Exchange (IKEv2)

  • RFC 4307. Криптографические алгоритмы для использования в Internet Key Exchange версии 2 (IKEv2)

  • RFC 4308, криптографические пакеты для IPsec

    В Junos OS поддерживается только Пакет VPN-Junos OS.

  • Аутентификация RFC 4754, IKE и IKEv2 с помощью алгоритма цифровой подписи (ECDSA)

  • RFC 4835. Требования к внедрению криптографического алгоритма для инкапсуляции полезная нагрузка безопасности (ESP) и заголовки аутентификации (AH)

  • RFC 5996, Internet Key Exchange версии 2 (IKEv2)

Junos OS частично поддерживает следующие документы РСК для IPsec и IKE:

  • RFC 3526, больше модульной экспоненциальной (MODP) группы Diffie-Hellman для Internet Key Exchange (IKE)

  • RFC 5114, дополнительные группы Diffie-Hellman для использования с IETF стандартами

  • RFC 5903, эллиптические группы сужением по методу Prime (ECP Groups) для IKE и IKEv2

Следующий проект стандартов ВКП и Интернет не определяет стандарты, а предоставляет информацию об IPsec, IKE и сопутствующих технологиях. Эти IETF классифицирует их как "информационные".

  • RFC 2104, HMAC: Кнопирование с ключом для аутентификации сообщений

  • RFC 2412, протокол определения ключа OAKLEY

  • RFC 3706. Метод обнаружения Internet Key Exchange (IKE) равноправных Internet Key Exchange трафика

  • Проект интернет-проекта draft-eastтеe-sha2-02.txt, US Secure Hash Algorithms (SHA и HMAC-SHA) (истекает в июля 2006 г.)

Таблица истории выпусков
Версия
Описание
19.1R1
Начиная Junos OS выпуске 19.1R1, серия SRX поддерживают группы DH 15, 16 и 21.