IPsec

IPsec (аббревиатура от Internet Protocol security ) — это набор протоколов, функция которых заключается в обеспечении безопасности связи по Интернет-протоколу (IP) путем аутентификации и/или шифрования каждого IP-пакета в потоке данных. IPsec также включает протоколы для установления ключей шифрования . ^{[ 1} ]

Резюме

Протоколы IPsec действуют на сетевом уровне, уровне 3 модели OSI . Другие широко используемые протоколы безопасности в Интернете, такие как SSL , TLS и SSH , работают на уровне приложений (уровень 7 модели OSI). Это делает IPsec более гибким, поскольку его можно использовать для защиты протоколов уровня 4, включая TCP и UDP .

Архитектура безопасности

IPsec реализуется набором криптографических протоколов для (1) защиты потока пакетов, (2) обеспечения взаимной аутентификации и (3) установки криптографических параметров .

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

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

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

Текущее состояние стандарта

IPsec был обязательной частью IPv6 на основании определения RFC 4294 , однако в 2011 году этот RFC был признан устаревшим в соответствии с RFC 6434 , в котором указано, что IPsec рекомендуется, а не является обязательным для IPv6. Для IPv4 его использование необязательно. Хотя стандарт не зависит от версии IP, развертывание и опыт до 2007 г. относятся к реализациям IPv4 .

Первоначально протоколы IPsec были определены в RFC 1825 и 1829, опубликованных в 1995 г. В 1998 г. эти документы были заменены RFC 2401 и 2412, которые несовместимы с 1825 и 1829, хотя концептуально идентичны. Документы третьего поколения, RFC 4301 и 4309, были выпущены в декабре 2005 года. Они в значительной степени являются расширенным набором документов 2401 и 2412, но представляют собой второй стандарт обмена ключами в Интернете . Это третье поколение документов стандартизировало аббревиатуру IPsec как «IP» в верхнем регистре и «sec» в нижнем регистре.

Редко можно увидеть продукт, который предлагает поддержку как RFC1825, так и 1829. «ESP» обычно относится к 2406, а ESPbis относится к 4303.

Цель дизайна

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

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

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

Поскольку Интернет-протокол по своей сути не обеспечивает никаких возможностей безопасности, IPsec был введен для предоставления таких услуг безопасности, как:

Шифровать трафик (чтобы его не мог прочитать кто-либо, кроме сторон, для которых он предназначен)
Проверка целостности (убедитесь, что трафик не был изменен на своем пути)
Аутентифицировать конечные точки (убедиться, что трафик поступает из доверенной конечной точки)
Anti-replay (защита от безопасного воспроизведения сеанса).

Режимы

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

Транспортный режим

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

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

Туннельный режим

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

Протоколы

IPsec состоит из трех протоколов, разработанных для обеспечения безопасности на уровне пакетов как для IPv4 , так и для IPv6 :

Заголовок аутентификации (AH) обеспечивает целостность, аутентификацию и неотказуемость, если выбраны соответствующие криптографические алгоритмы.
Инкапсуляция полезной нагрузки безопасности (ESP) обеспечивает конфиденциальность и является настоятельно рекомендуемым вариантом проверки подлинности и защиты целостности.
Обмен ключами в Интернете ( IKE ) использует обмен секретными ключами Диффи-Хеллмана для установления общего секрета сеанса . Обычно используются криптографические системы с открытым ключом или предварительным общим

Криптографические алгоритмы, определенные для использования с IPsec, включают HMAC - SHA-1 для защиты целостности и Triple DES - CBC и AES -CBC для конфиденциальности. Подробнее в RFC 4305 .

Заголовок аутентификации (AH)

AH направлен на обеспечение целостности, отсутствие соединения и аутентификацию исходных данных IP-датаграмм. Для этого он вычисляет хэш-код аутентификации сообщения ( HMAC ) с помощью некоторого хеш- алгоритма, работающего с секретным ключом, содержимым IP-пакета и неизменяемыми частями дейтаграммы. Этот процесс ограничивает возможность использования NAT , которая может быть реализована с обходом NAT . С другой стороны, AH может дополнительно защищать от повторных атак, используя метод скользящего окна и отбрасывая старые пакеты. AH защищает полезную нагрузку IP и все поля в заголовке дейтаграммы IP, за исключением изменяющихся полей, то есть тех, которые могут быть изменены при передаче. В IPv4 меняющиеся (и, следовательно, неаутентифицированные) поля заголовка IP включают TOS , Flags, Fragment Offset, TTL и контрольную сумму заголовка . AH работает непосредственно поверх IP, используя IP-протокол номер 51. Заголовок AH имеет длину 32 бита, вот схема того, как они устроены:

0–7 бит	8–15 бит	16–23 бит
Следующий заголовок	Длина полезной нагрузки	СДЕРЖАННЫЙ
Индекс параметра безопасности (SPI)
Последовательность чисел
Хэш-код аутентификации сообщения (переменная)

Значение полей:

Следующий заголовок: Идентифицирует протокол передаваемых данных.
Длина полезной нагрузки: Размер пакета AH
СДЕРЖАННЫЙ: Зарезервировано для использования в будущем (до этого все нули).
Индекс параметра безопасности (SPI): Указывает параметры безопасности, которые в сочетании с IP-адресом идентифицируют сопоставление безопасности, реализованное с этим пакетом.
Последовательность чисел: Постоянно растущее число, используемое для предотвращения повторных атак.
HMAC: Содержит значение проверки целостности (ICV), необходимое для аутентификации пакета; может содержать наполнитель.

Инкапсуляция полезной нагрузки безопасности (ESP)

Протокол ESP обеспечивает подлинность происхождения, целостность и защиту конфиденциальности пакета. ESP также поддерживает конфигурации только с шифрованием и только с аутентификацией, но использование шифрования без аутентификации настоятельно не рекомендуется, поскольку это небезопасно ^{[ 2 ]}^[ ³^] . ^{[ 4 ]} В отличие от AH, ESP не защищает заголовок IP-пакета (хотя в ESP в туннельном режиме защита обеспечивается для всего внутреннего IP-пакета, включая внутренний заголовок; внешний заголовок остается незащищенным). ESP работает непосредственно через IP, используя IP-протокол номер 50.

Диаграмма пакетов ESP:

0–7 бит	8–15 бит	16–23 бит	24–31 бит
Индекс параметра безопасности (SPI)
Последовательность чисел
Данные полезной нагрузки (переменная)
	Заполнение (0-255 байт)
		Длина колодки	Следующий заголовок
Данные аутентификации (переменная)

Значение полей

Индекс параметра безопасности (SPI): Идентифицирует параметры безопасности в сочетании с IP-адресом.
Последовательность чисел: Постоянно растущее число, используемое для предотвращения повторных атак.
Данные полезной нагрузки: Данные для передачи.
набивка: Используется некоторыми криптографическими алгоритмами для полного заполнения блоков.
длина колодки: Размер заполнения в байтах.
Следующий заголовок: Идентифицирует протокол передаваемых данных.
Дата аутентификации: Содержит данные, используемые для аутентификации пакета.

Реализации

Поддержка IPsec обычно реализуется в ядре , а управление ключами и согласование ISAKMP / IKE выполняется в пользовательском пространстве. Существующие реализации IPsec обычно включают обе функции. Однако, поскольку существует стандартный интерфейс для управления ключами, можно управлять основным стеком IPsec с помощью инструментов управления ключами другой реализации.

По этой причине существует путаница в отношении происхождения реализации IPsec в ядре Linux . Проект FreeS/WAN сделал первую полную реализацию IPsec с открытым исходным кодом для Linux . Он состоит из основного стека IPsec KLIPS , а также демона (pluto) и множества сценариев оболочки . Проект FreeS/WAN был прекращен в марте 2004 года. Openswan и strongSwan являются продолжением FreeS/WAN. В проекте KAME также реализована полная поддержка IPsec для NetBSD и FreeBSD . Его демон управления ключами называется racoon . OpenBSD создала собственного демона ISAKMP/IKE, называемого просто isakmpd (и он был портирован на другие системы, включая Linux ).

Однако ни один из этих основных стеков IPsec не был встроен в Linux. Алексей Кузнецов и Дэвид С. Миллер написали реализацию IPsec ядра для Linux с нуля примерно в конце 2002 года. Этот стек позже был выпущен как часть Linux 2.6, и многие называют его «родным» или «NETKEY».

Таким образом, вопреки распространенному мнению, стек Linux IPsec возник не в рамках проекта KAME. Поскольку он поддерживает стандартный протокол PF KEY ( RFC 2367 ) и собственный интерфейс XFRM для управления ключами, стек Linux IPsec можно использовать в сочетании с pluto Openswan / strongSwan , isakmpd проекта OpenBSD , racoon проекта KAME или без них. демон ISAKMP. /IKE (используя ручные ключи).

Новые архитектуры сетевых процессоров, в том числе многоядерные процессоры со встроенными механизмами шифрования, изменили способ проектирования стеков IPsec. Выделенный Fast Path используется для разгрузки обработки задач IPsec (SA, поиск SP, шифрование и т. д.). Эти стеки Fast Path должны быть совместно интегрированы в выделенные ядра с Linux или RTOS, работающими на других ядрах. Эти ОС представляют собой плоскость управления, которая запускает ISAKMP/IKE стека IPsec Fast Path.

Существует довольно много реализаций протоколов IPsec и ISAKMP/IKE. Среди прочего:

6WINDGate , стек IPsec Fast Path для многоядерного сетевого процессора
NRL [1] IPsec, один из исходных источников кода IPsec [2]
OpenBSD с собственным кодом, полученным из NRL IPsec.
Стек KAME , включенный в Mac OS X , NetBSD и FreeBSD .
«IPsec» в ПО Cisco IOS [3]
«IPsec» в Microsoft Windows , включая Windows XP [4] [5] , Windows 2000 [6] и Windows 2003 [7]
Инструменты SafeNet QuickSec [8]
IPsec в Solaris [9]
Операционная система IBM AIX
ОС IBM z/
IPsec и IKE на HP-UX (HP-UX IPSec)
«IPsec и IKE» в VxWorks [10]

Список RFC, связанных с IPsec

RFC 2327 : интерфейс PF_KEY
RFC 2367 : интерфейс PF_KEY
RFC 2401 (заменяет RFC 1825 и был заменен RFC 4301 ): Архитектура безопасности для интернет-протокола
RFC 2402 (заменен RFC 4302 и RFC 4305 ): заголовок аутентификации
RFC 2403 : Использование HMAC-MD5-96 в ESP и AH
RFC 2404 : Использование HMAC-SHA-1-96 в ESP и AH
RFC 2405 : Алгоритм шифрования ESP DES-CBC с явным IV
RFC 2406 (заменен RFC 4303 и RFC 4305 ): инкапсуляция полезной нагрузки безопасности
RFC 2407 (заменен RFC 4306 ): Домен интерпретации IPsec для ISAKMP (DoI IPsec)
RFC 2408 (заменен RFC 4306 ): сопоставление безопасности в Интернете и протокол управления ключами (ISAKMP)
RFC 2409 (заменен RFC 4306 ): обмен ключами через Интернет (IKE)
RFC 2410 : Алгоритм шифрования NULL и его использование с IPsec
RFC 2411 : Дорожная карта документа по безопасности IP
RFC 2412 : (заменяет RFC 1829 ) Протокол определения ключа OAKLEY.
RFC 2451 : Алгоритмы шифрования ESP CBC-Mode
RFC 2857 : Использование HMAC-RIPEMD-160-96 в ESP и AH
RFC 3526 : Больше модульных экспоненциальных (MODP) групп Диффи-Хеллмана для обмена ключами через Интернет (IKE)
RFC 3706 : основанный на трафике метод обнаружения мертвых узлов обмена ключами в Интернете (IKE)
RFC 3715 : Требования совместимости IPsec-трансляции сетевых адресов (NAT)
RFC 3947 : согласование обхода NAT в IKE
RFC 3948 : UDP-инкапсуляция пакетов IPsec ESP
RFC 4106 : Использование режима Галуа/счетчика (GCM) в IPsec, инкапсулирующий полезную нагрузку безопасности (ESP)
RFC 4301 (заменяет RFC 2401 ): Архитектура безопасности для интернет-протокола
RFC 4302 (заменяет RFC 2402 ): заголовок IP-аутентификации
RFC 4303 (заменяет RFC 2406 ): IP-инкапсуляция полезной нагрузки безопасности (ESP)
RFC 4304 : Дополнение по расширенному порядковому номеру (ESN) к домену интерпретации IPsec (DOI) для ассоциации безопасности Интернета и протокола управления ключами (ISAKMP)
RFC 4305 (заменен RFC 4835 ): Требования к реализации криптографического алгоритма для инкапсуляции полезной нагрузки безопасности (ESP) и заголовка аутентификации (AH)
RFC 4306 (заменяет RFC 2407 , RFC 2408 и RFC 2409 ): протокол обмена ключами через Интернет ( IKEv2 ).
RFC 4307 : Криптографические алгоритмы для использования в Internet Key Exchange Version 2 ( IKEv2 )
RFC 4308 : Криптографические наборы для IPsec
RFC 4309 : использование режима CCM Advanced Encryption Standard (AES) с инкапсуляцией полезной нагрузки безопасности IPsec (ESP)
RFC 4478 : повторная аутентификация в протоколе обмена ключами в Интернете (IKEv2)
RFC 4543 : Использование кода аутентификации сообщений Галуа (GMAC) в IPsec ESP и AH
RFC 4555 : Протокол мобильности и множественной адресации IKEv2 (MOBIKE)
RFC 4621 : Проект протокола IKEv2 Mobility and Multihoming (MOBIKE)
RFC 4718 : пояснения и рекомендации по реализации IKEv2
RFC 4806 : Расширения протокола статуса онлайн-сертификата (OCSP) для IKEv2
RFC 4809 : Требования к профилю управления сертификатами IPsec
RFC 4835 (заменяет RFC 4305 ): Требования к реализации криптографического алгоритма для инкапсуляции полезной нагрузки безопасности (ESP) и заголовка аутентификации (AH)
RFC 4945 : Профиль PKI IKEv1/ISAKMP, IKEv2 и PKIX для безопасности IP-адресов в Интернете.

Ссылки

↑ Маркиз, Уильям (12 января 2016 г.). IPsec и виртуальные частные сети . Лулу.com. ISBN 978-1-329-82419-5 . Проверено 3 октября 2021 г. .
^ Белловин, Стивен М. (1996). «Проблемные области протоколов безопасности IP» . Материалы шестого симпозиума по безопасности Usenix Unix . Сан-Хосе, Калифорния. стр. 1-16 . Проверено 13 ноября 2007 г.
↑ К. Г. Патерсон и А. Яу (2006). «Криптография в теории и на практике: случай шифрования в IPsec» . Eurocrypt 2006, Конспект лекций по информатике, том 4004 . стр. 12-29 . Проверено 13 ноября 2007 г. Текст «Берлин» игнорируется ( помощь )
^ Дж. П. Дегабриэле и К. Г. Патерсон (2007). «Атака на стандарты IPsec в конфигурациях только с шифрованием» . Симпозиум IEEE по безопасности и конфиденциальности, IEEE Computer Society . стр. 335-349 . Проверено 13 ноября 2007 г. Текст "Окленд, Калифорния" игнорируется ( помощь )

[1] Маркиз, Уильям (12 января 2016 г.). IPsec и виртуальные частные сети . Лулу.com. ISBN 978-1-329-82419-5 . Проверено 3 октября 2021 г. .

[2] Белловин, Стивен М. (1996). «Проблемные области протоколов безопасности IP» . Материалы шестого симпозиума по безопасности Usenix Unix . Сан-Хосе, Калифорния. стр. 1-16 . Проверено 13 ноября 2007 г.

[3] К. Г. Патерсон и А. Яу (2006). «Криптография в теории и на практике: случай шифрования в IPsec» . Eurocrypt 2006, Конспект лекций по информатике, том 4004 . стр. 12-29 . Проверено 13 ноября 2007 г. Текст «Берлин» игнорируется ( помощь )

[4] Дж. П. Дегабриэле и К. Г. Патерсон (2007). «Атака на стандарты IPsec в конфигурациях только с шифрованием» . Симпозиум IEEE по безопасности и конфиденциальности, IEEE Computer Society . стр. 335-349 . Проверено 13 ноября 2007 г. Текст "Окленд, Калифорния" игнорируется ( помощь )

[ 1

[ 2 ]

[

[ 4 ]