Технологии используемые в IPSEC. Как работает ipSec Настройка утилиты racoon
Изначально сеть Интернет использовалась узким кругом лиц, имеющих представление о политике безопасности. Соответственно явной необходимости в защите информации не было. Безопасность организовывалась на физическом уровне путем изоляции сети от посторонних лиц. Однако со временем Интернет становится публичной площадкой и постепенно возрастает потребность в создании протоколов, которые могли бы шифровать передаваемые данные.
В 1994 году Совет по архитектуре Интернет выпустил отчет “Безопасность архитектуры Интернет”. Данный отчет посвящался в основном проблемам защиты от несанкционированного мониторинга, подмены пакетов и управлению потоками данных. Требовалась разработка некоторого стандарта, способного решить все эти проблемы. В результате были созданы стандарты протоколов, в число которых входил IPsec.
IPsec (сокр. IP Security) – группа протоколов, предназначенных для обеспечения защиты данных, передаваемых по IP-сети. Задача IPsec сводится к тому, чтобы выбрать конкретные алгоритмы и механизмы и настроить соответствующим образом устройства, участвующие в создании безопасного соединения. IPsec находит применение в организации VPN-соединений.
При создании защищенного канала участникам данного процесса необходимо произвести следующие действия:
- Аутентифицировать друг друга
- Сгенерировать и обменяться ключами
- Договориться с помощью каких протоколов шифровать данные
- Начать передавать данные в зашифрованный туннель
Сам IPsec, как уже было указано ранее, состоит из нескольких протоколов, каждый из которых отвечает за конкретную стадию установления IPsec туннеля. Первым из них является IKE.
IKE (Internet Key Exchange) – протокол обмена ключами.
IKE используется на первой стадии установления соединения. К его задачам относят: аутентификация VPN-точек, организация новых IPsec соединений (через создание SA-пар), управление текущими соединениями. SA представляет из себя набор параметров защищенного соединения. При настроенном соединении для каждого протокола создается одна SA-пара: первая для протокола AH, вторая для ESP (расскажу про них дальше). Также стоит отметить, что SA является однонаправленным. Таким образом, при связи двух компьютеров будет использоваться четыре SA. IKE работает в двух фазах, при этом первая фаза может работать как в основном, так и в агрессивном режиме. Рассмотрим две фазы IKE-соединения:
Первая фаза (основной режим):
- Обмен параметрами безопасности IKE-соединения (алгоритмы и хэш-функции)
- На каждом конце туннеля генерируются общий секретный ключ
- Используя алгоритм Деффи-Хеллмана , стороны обмениваются общим секретным ключом
- Аутентификация обеих концов туннеля
Первая фаза (агрессивный режим): в первый пакет сразу помещается вся необходимая информация для установления IKE-соединения. Получатель посылает в ответ все, что необходимо для завершения обмена, после чего первому узлу необходимо лишь подтвердить соединение.
Агрессивный режим быстрей позволяет установить IKE-соединение, но при этом он менее безопасный, потому что стороны обмениваются информацией до того как безопасное соединение установлено.
Таким образом, первая фаза служит для создания защищенного туннеля, через который будут передаваться параметры для IPSec-туннеля. Во время второй фазы строится основной IPSec-туннель.
Во время второй фазы участники защищенного соединения по очереди предлагают друг другу варианты защищенного соединения и, если приходят к согласию, строят основной IPSec-туннель. Во второй фазы происходит согласование множества параметров:
- Выбирается IPSec-протокол: AH (Authentication Header) и/или ESP (Encapsulation Security Payload)
- Выбирается алгоритм для шифрования данных: DES, 3DES, AES
- Выбирается алгоритм для аутентификации: SHA, MD5
- Выбирается режим работы: туннельный или транспортный
- Устанавливается время жизни IPSec-туннеля
- Определяется трафик, который будет пускаться через VPN-туннель
AH (Authentication Header) – протокол IPSec, предназначенный для аутентификации. По сути это обычный опциональный заголовок, располагающийся между основным заголовком IP-пакета и полем данных. Предназначение AH – обеспечение защиты от атак, связанных с несанкционированным изменением данных в IP-пакете, в частности подмены исходного адреса сетевого уровня.
ESP (Encapsulation Security Payload) – протокол IPSec, предназначенный для шифрования данных. Дословно переводится как “поле данных безопасной инкапсуляции”. Также как и AH представляет из себя опциональный заголовок, вкладываемый в IP-пакет. Основной целью ESP является обеспечение конфиденциальности данных.
Вы могли заметить, что ESP и AH имеют разные форматы в зависимости от типа используемого режима: туннельного и транспортного.
Туннельный режим применяется чаще всего для удаленных VPN-подключений. При таком режиме исходный IP-пакет полностью инкапсулируется в новый таким образом, что для наблюдателя со стороны будет видно только соединение между двумя VPN-точками. Реальные IP-адреса источника и получателя видны не будут, их можно получить только при деинкапсуляции на VPN-точке. Исходя из этого, можно считать, что туннельный режим является более защищенным.
Транспортный режим применяется, как правило, в локальной сети при защите соединения между хостами. Этот режим обеспечивает защиту данных IP-пакета (TCP, UDP, протоколы верхних уровней). Грубо говоря, транспортный режим инкапсулирует все, что находится выше сетевого уровня эталонной модели OSI, при этом не затрагивая сам IP-заголовок. Естественно в таком случае данные IP-пакета: адрес источника и получателя будут видны извне.
Теперь перейдем к практике: настроим защищенный IPSec-туннель между двумя маршрутизаторами Cisco. Схема будет состоять из трех последовательно соединенных маршрутизаторов, при этом крайние R1 и R3 представляют из себя маршрутизаторы для локальных сетей, а центральный R2 имитирует Интернет. Прежде всего необходимо настроить связность между двумя локальными подсетями. Связность обеспечивается за счет GRE-туннеля. Про GRE-туннели я писал в , также там есть конфигурация GRE-туннеля для маршрутизаторов Cisco. Чтобы понимать логику дальнейший действий настоятельно рекомендую ознакомиться с этим материалом.
Итак, основной GRE-туннель у нас “прокинут”. Он не является защищенным и поэтому поверх него мы будем настраивать IPSec. Мы работали вот с такой схемой.
По легенде у нас было два офиса с подсетями LAN1 и LAN2. Необходимо обеспечить доступ компьютера из LAN1 к серверу, находящемуся в LAN2 (например, для доступа к файлам). Так вот, основной туннель мы создали. На сетевом уровне все работает прекрасно – пинг от компа до сервера есть. Но существует одна проблема: сервер содержит файлы, которые представляет коммерческую тайну для компании. Таким образом, необходимы механизмы шифрования трафика, а также аутентификация для того, чтобы никто кроме нас не мог получить доступ к этим файлам. И вот тут в бой вступает IPSec.
Конфигурация для Router A
Создаем политику безопасности и настраиваем ее RouterA(config)#crypto isakmp policy 1 Указываем метод шифрования (симметричный блочный шифр) RouterA(config)#encryption 3des Указываем метод хеширования MD5 RouterA(config)#hash md5 Указываем метод аутентификации (с предварительным ключом) RouterA(config)#authentication pre-share Выходим из режима редактирования политики безопасности RouterA(config)#exit Ключ для аутентификации (должен совпадать для обеих точек) RouterA(config)#crypto isakmp key PASS address 33.33.33.33 Применение набора преобразований RouterA(config)#crypto ipsec transform-set LAN1 esp-3des esp-md5-hmac Указываем режим работы IPSec (туннельный режим) RouterA(cfg-crypto-trans)#mode tunnel RouterA(cfg-crypto-trans)#exit Создаем крипто-карту (детали туннелирования) RouterA(config)#crypto map MAP1 10 ipsec-isakmp Указываем Ip-адрес маршрутизатора, с которым устанавливаем VPN RouterA(config-crypto-map)#set peer 33.33.33.33 Указываем набор политик безопасности RouterA(config-crypto-map)#set transform-set LAN1 Шифровать данные, которые будут проходить через список доступа под номером 100 RouterA(config-crypto-map)#match address 100 Выходим из режима настройки крипто-карты RouterA(config-crypto-map)#exit GRE-трафик с хоста 11.11.11.11 на хост 33.33.33.33 подлежит шифрованию RouterA(config)#access-list 100 permit gre host 11.11.11.11 host 33.33.33.33 Переходим в режим настройки внешнего интерфейса RouterA(config)#interface fa 0/1 Привязка карты шифрования MAP1 к внешнему интерфейсу RouterA(config-if)#crypto map MAP1Аналогично настраивается Router B:
RouterB(config)#crypto isakmp policy 1 RouterB(config)#encryption 3des RouterB(config)#hash md5 RouterB(config)#authentication pre-share RouterB(config)#exit RouterB(config)#crypto isakmp key PASS address 11.11.11.11 RouterB(config)#crypto ipsec transform-set LAN2 esp-3des esp-md5-hmac RouterB(cfg-crypto-trans)#mode tunnel RouterB(cfg-crypto-trans)#exit RouterB(config)#crypto map MAP2 10 ipsec-isakmp RouterB(config-crypto-map)#set peer 11.11.11.11 RouterB(config-crypto-map)#set transform-set LAN2 RouterB(config-crypto-map)#match address 100 RouterB(config-crypto-map)#exit RouterB(config)#access-list 100 permit gre host 33.33.33.33 host 11.11.11.11 RouterB(config)#interface fa 0/1 RouterB(config-if)#crypto map MAP2
Поддержите проект
Друзья, сайт Netcloud каждый день развивается благодаря вашей поддержке. Мы планируем запустить новые рубрики статей, а также некоторые полезные сервисы.
У вас есть возможность поддержать проект и внести любую сумму, которую посчитаете нужной.
В конце шестидесятых годов американское агентство перспективных исследований в обороне DARPA приняло решение о создании экспериментальной сети под названием ARPANet. В семидесятых годах ARPANet стала считаться действующей сетью США, и через эту сеть можно было получить доступ к ведущим университетским и научным центрам США. В начале восьмидесятых годов началась стандартизация языков программирования, а затем и протоколов взаимодействия сетей. Результатом этой работы стала разработка семиуровневой модели сетевого взаимодействия ISO/OSI и семейства протоколов TCP/IP, которое стало основой для построения как локальных, так и глобальных сетей.
Базовые механизмы информационного обмена в сетях TCP/IP были в целом сформированы в начале восьмидесятых годов, и были направлены прежде всего на обеспечение доставки пакетов данных между различными операционными системами с использованием разнородных каналов связи. Несмотря на то, что идея создания сети ARPANet (впоследствии превратившейся в современный Интернет) принадлежала правительственной оборонной организации, фактически сеть зародилась в исследовательском мире, и наследовала традиции открытости академического сообщества. Ещё до коммерциализации Интернета (которая произошла в середине девяностых годов) многие авторитетные исследователи отмечали проблемы, связанные с безопасностью стека протоколов TCP/IP. Основные концепции протоколов TCP/IP не полностью удовлетворяют (а в ряде случаев и противоречат) современным представлениям о компьютерной безопасности.
До недавнего времени сеть Интернет использовалась в основном для обработки информации по относительно простым протоколам: электронная почта, передача файлов, удалённый доступ. Сегодня, благодаря широкому распространению технологий WWW, всё активнее применяются средства распределённой обработки мультимедийной информации. Одновременно с этим растёт объём данных, обрабатываемых в средах клиент/сервер и предназначенных для одновременного коллективного доступа большого числа абонентов. Разработано несколько протоколов прикладного уровня, обеспечивающих информационную безопасность таких приложений, как электронная почта (PEM, PGP и т.п.), WWW (Secure HTTP, SSL и т.п.), сетевое управление (SNMPv2 и т.п.). Однако наличие средств обеспечения безопасности в базовых протоколах семейства TCP/IP позволит осуществлять информационный обмен между широким спектром различных приложений и сервисных служб.
Краткая историческая справка появления протокола
В 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
Аутентифицирующий заголовок (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).
Хэш-функция — это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения m 1 и m 2 , таких, что H(m 1) =H(m 2) , где H — хэш функция.
Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции
HMAC (HMAC — механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая
хэш функция (обозначим её как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с
помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков
в байтах, а длину блоков, полученных в результате хэширования — как L (L Ipad = байт 0x36, повторённый B раз; Для вычисления HMAC от данных "text" необходимо выполнить следующую операцию: H(K XOR opad, H(K XOR ipad, text)) Из описания следует, что IKE использует для аутентификации сторон HASH величины. Отметим, что под HASH в данном случае подразумевается
исключительно название Payload в ISAKMP, и это название не имеет ничего общего со своим содержимым. Все виды атак на компоненты 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 является
лучшим среди всех других протоколов защиты передаваемых по сети данных, разработанных ранее (включая разработанный Microsoft
PPTP). По мнению другой стороны, присутствует чрезмерная сложность и избыточность протокола. Так, Niels Ferguson и Bruce Schneier
в своей работе "A Cryptographic Evaluation of IPsec" отмечают,
что они обнаружили серьёзные проблемы безопасности практически во всех главных компонентах IPsec. Эти авторы также отмечают,
что набор протоколов требует серьёзной доработки для того, чтобы он обеспечивал хороший уровень безопасности. В работе приведено
описание ряда атак, использующих как слабости общей схемы обработки данных, так и слабости криптографических алгоритмов. В этой статье мы рассмотрели некоторые основные моменты, касающиеся протокола сетевой безопасности IPsec. Не лишним будет
отметить, что протокол IPsec доминирует в большинстве реализаций виртуальных частных сетей. В настоящее время на рынке представлены
как программные реализации (например, протокол реализован в операционной системе Windows2000 компании Microsoft),
так и программно-аппаратные реализации IPsec — это решения
Cisco , Nokia . Несмотря на большое число различных решений, все они
довольно хорошо совместимы друг с другом. В заключение статьи приводится таблица, в которой производится сравнение IPSec и
широко распространённого сейчас SSL. Вконтакте Одноклассники IPsec (IP security)
- набор протоколов для безопасной передачи трафика через IP сеть. Пожалуй, самый сложный и разветвленный стек протоколов из поддерживаемых системой VPNKI. Включает в себя три основных протокола: Основные используемые порты и номера протоколов Вообще, набор протоколов IPsec непрост с точки зрения возможностей его использования, которые весьма многогранны. Однако, базовой особенностью всего взаимодействия по этому протоколу является понятие SA (Security Association) - это набор параметров о том как стороны будут в дальнейшем использовать те или иные свойства протоколов из состава IPsec. Стоит еще упомянуть про два основных режима работы IPsec - туннельный и транспортный. Грубо говоря, в транспортном режиме шифруются только полезные данные IP пакета, а в туннельном режиме шифруется все данные, включая заголовки IP. Взаимодействие двух узлов начинается с установления SA. Точнее с двух ассоциаций - для протокола AH и ESP причем в одну и в другую стороны. SA начинается с аутентификации и затем стороны согласовывают будущие параметры сессии: Здесь же стороны договариваются о туннельном или транспортном режиме работы IPsec. К завершению процесса у вас должны быть установлены несколько SA, но... чуть подробнее как это на самом деле. В IPsec все происходит по Фазам. На фазе 1 происходит установление SA первой фазы. В первой фазе стороны договариваются о методе идентификации, алгоритме шифрования, алгоритме хэшировнаия и группе Diffie Hellman. Эта фаза может пройти путем обмена тремя нешифрованными пакетами (агрессивный режим) или шестью нешифрованными пакетами - стандартный режим. Если все прошло успешно, то создается SA фазы 1 под названием IKE SA и осуществляется переход ко второй фазе. На фазе 2 стороны договариваются о политике и создаются сами ключи. Эта фаза, в отличии от первой полностью шифруется и она наступает только в случае успешного окончания первой фазы. В связи с тем, что трафик этой фазы полностью шифрован становится сложно осуществлять поиск неполадок, однако если все прошло успешно, то создается SA фазы 2 под названием IPSec SA. В этот момент можно сказать, что туннель установлен. В составе IPsec нет собственного механизма компрессии данны, однако можно использовать механизм IPcomp который компрессирует содержимое IP пакета до его передачи в процесс IPsec. Некоторые демоны IPsec поддерживают включение этого механизма из файлов настроек ipsec.conf (например пакет Strongswan) Внутри IPsec нет штатного средства для проверки работоспособности соединения (типа ping), поэтому работу туннеля можно проверять внешними средствами. Согласованные на двух фазах ключи должны работать оговоренное политикой время. Это означает, что сторонам возможно предстоит пережить процедуру смены ключей (rekeying), а иначе согласованные SA распадутся. Как было сказано выше, у сторон есть ключи в рамках процесса фазы 1 (IKE) и фазы 2 (IPsec). Процедуры их смены различны, как и таймеры, которые за это отвечают. Для того, чтобы не было перерыва связи в процессе смены ключей стороны сначала согласовывают параметры новой SA и лишь после этой успешной процедуры уничтожают старую SA. В IPsec на каждой из фаз есть несколько способов смены ключей - с аутентификацией или без нее, но мы не будем сильно заострять на этом свое внимание. Просто для этой процедуры слишком существует много нюансов, которые зависят от версий ПО и соотношения таймеров - для IKE и IPsec. (The Internet Key Exchange (IKE)) - Обмен ключами.
Протоколы IPsec, в отличие от других хорошо известных протоколов SSL и TLS , работают на сетевом уровне (уровень 3 модели OSI). Это делает IPsec более гибким, так что он может использоваться для защиты любых протоколов, базирующихся на TCP и UDP . IPsec может использоваться для обеспечения безопасности между двумя IP-узлами , между двумя шлюзами безопасности или между IP-узлом и шлюзом безопасности. Протокол является "надстройкой" над IP-протоколом, и обрабатывает сформированные IP-пакеты описанным ниже способом. IPsec может обеспечивать целостность и/или конфиденциальность данных передаваемых по сети. IPsec использует следующие протоколы для выполнения различных функций: Концепция "Защищенного виртуального соединения" (SA, "Security Association") является фундаментальной в архитектуре IPsec. SA представляет собой симплексное соединение , которое формируется для транспортирования по нему соответствующего трафика. При реализации услуг безопасности формируется SA на основе использования протоколов AH или ESP (либо обоих одновременно). SA определен в соответствии с концепцией межтерминального соединения (point-to-point) и может функционировать в двух режимах: транспортный режим (РТР) и режим тунелирования (РТУ). Транспортный режим реализуется при SA между двумя IP-узлами. В режиме туннелирования SA формирует IP-туннель . Все SA хранятся в базе данных SADB (Security Associations Database) IPsec-модуля. Каждое SA имеет уникальный маркер, состоящий из трех элементов: IPsec-модуль, имея эти три параметра, может отыскать в SADB запись о конкретном SA. В список компонентов SA входят: Так как защищенные виртуальные соединения(SA) являются симплексными , то для организации дуплексного канала, как минимум, нужны два SA. Помимо этого, каждый протокол (ESP/AH) должен иметь свою собственную SA для каждого направления, то есть, связка AH+ESP требует наличия четырех SA. Все эти данные располагаются в SADB. Помимо базы данных SADB, реализации IPsec поддерживают базу данных SPD (Security Policy Database- База данных политик безопасности). Запись в SPD состоит из набора значений полей IP-заголовка и полей заголовка протокола верхнего уровня. Эти поля называются селекторами. Селекторы используются для фильтрации исходящих пакетов, с целью поставить каждый пакет в соответствие с определенным SA. Когда формируется пакет, сравниваются значения соответствующих полей в пакете (селекторные поля) с теми, которые содержатся SPD. Находятся соответствующие SA. Затем определяется SA (в случае, если оно имеется) для пакета и сопряженный с ней индекс параметров безопасности(SPI). После чего выполняются операции IPsec(операции протокола AH или ESP). Примеры селекторов, которые содержатся в SPD: Протокол AH используется для аутентификации, то есть для подтверждения того, что мы связываемся именно с тем, с кем предполагаем, и что данные, которые мы получаем, не искажены при передаче. Если передающий 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-пакета: После получения пакета, содержащего сообщение АН-протокола, приемный 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-обработки. Если проверка дала отрицательный результат, то приемный пакет уничтожается. Если передающий 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, с которым связан обрабатываемый пакет. После получения пакета, содержащего сообщение 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 . 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
Протокол работает на сетевом уровне модели OSI
и, соответственно, он "прозрачен" для приложений. Иными словами, на работу приложений (таких как web- сервер
, браузер
, СУБД
и т.д.) не влияет, используется ли защита передаваемых данных с помощью IPSec или нет. Операционные системы семейства Windows 2000
и выше имеют встроенную поддержку протокола IPSec. С точки зрения многоуровневой модели защиты, этот протокол является средством защиты уровня сети.
Архитектура
IPSec является открытой, что, в частности, позволяет использовать для защиты передаваемых данных новые криптографические алгоритмы и протоколы, например соответствующие национальным стандартам. Для этого необходимо, чтобы взаимодействующие стороны поддерживали эти алгоритмы, и они были бы стандартным образом зарегистрированы в описании параметров соединения. Процесс защищенной передачи данных регулируется правилами безопасности, принятыми в системе. Параметры создаваемого туннеля описывает информационная структура, называемая контекст
защиты или ассоциация
безопасности (от англ. Security
Association
, сокр. SA
). Как уже отмечалось выше, IPSec является набором протоколов, и состав SA
может различаться, в зависимости от конкретного протокола. SA
включает в себя: Обычно, контекст
защиты является однонаправленным, а для передачи данных по
туннелю в обе стороны задействуются два SA
. Каждый хост
имеет свою базу SA
, из которой выбирается нужный элемент либо на основании SPI
, либо по
IP
-адресу получателя. Два протокола, входящие в состав IPSec это: Оба эти протокола имеют два режима работы - транспортный и туннельный, последний определен в качестве основного. Туннельный режим
используется, если хотя бы один из соединяющихся узлов является шлюзом безопасности. В этом случае создается новый IP
-заголовок, а исходный IP
-пакет полностью инкапсулируется в новый. Транспортный режим
ориентирован на соединение хост
- хост
. При использовании ESP
в транспортном режиме защищаются только данные IP
-пакета, заголовок не затрагивается. При использовании AH
защита распространяется на данные и часть полей заголовка. Более подробно режимы работы описаны ниже. В IP ver
.4 аутентифицирующий заголовок располагается после IP-заголовка. Представим исходный IP-пакет как совокупность IP-заголовка, заголовка протокола следующего уровня (как правило, это TCP или UDP, на рис.
5.10 он обозначен как ULP
- от англ. Upper-Level Protocol) и данных. Рассмотрим формат заголовка ESP
(
рис.
5.13). Он начинается с двух 32-разрядных значений - SPI
и SN
. Роль их такая же, как в протоколе AH - SPI
идентифицирует SA, использующийся для создания данного туннеля; SN
- позволяет защититься от повторов пакетов. SN
и SPI
не шифруются. Следующим идет поле, содержащее зашифрованные данные. После них - поле заполнителя, который нужен для того, чтобы выровнять длину шифруемых полей до значения кратного размеру блока алгоритма шифрования. После заполнителя идут поля, содержащие значение длины заполнителя и указание на протокол более высокого уровня. Четыре перечисленных поля (данные, заполнитель, длина, следующий протокол) защищаются шифрованием. Если ESP
используется и для аутентификации данных, то завершает пакет поле переменной длины, содержащее ICV. В отличие от AH, в ESP
при расчете значения имитовставки
, поля IP-заголовка (нового - для туннельного режима, модифицированного старого - для транспортного) не учитываются. При совместном использовании протоколов AH и ESP
, после IP заголовка идет AH, после него - ESP
. В этом случае, ESP
решает задачи обеспечения конфиденциальности, AH - обеспечения целостности и аутентификации источника соединения. Рассмотрим ряд дополнительных вопросов, связанных с использованием IPSec. Начнем с того, откуда берется информация о параметрах соединения - SA. Создание базы SA может производиться различными путями. В частности, она может создаваться администратором безопасности
вручную, или формироваться с использованием специальных протоколов - SKIP
, ISAKMP
( Internet Security
Association and Key Management Protocol) и IKE
(Internet Key Exchange). При подключении сетей организаций к Интернет, часто используется механизм трансляции сетевых адресов - NAT ( Network Address Translation
). Это позволяет уменьшить число зарегистрированных IP-адресов, используемых в данной сети. Внутри сети используются незарегистрированные адреса (как правило, из диапазонов, специально выделенных для этой цели, например, адреса вида 192.168.x.x для сетей класса C). Если пакет из такой сети передается в Интернет, то маршрутизатор, внешнему интерфейсу которого назначен по крайней мере один зарегистрированный ip-адрес, модифицирует ip-заголовки сетевых пакетов, подставляя вместо частных адресов зарегистрированный адрес. То, как производится подстановка, фиксируется в специальной таблице. При получении ответа, в соответствии с таблицей делается обратная замена и пакет переправляется во внутреннюю сеть. Рассмотрим пример использования NAT рис.
5.14 . В данном случае, во внутренней сети используются частные адреса 192.168.0.x. С компьютера, с адресом 192.168.0.2 обращаются во внешнюю сеть к компьютеру с адресом 195.242.2.2. Пусть это будет подключение к web-серверу (протокол HTTP, который использует TCP порт 80). При прохождении пакета через маршрутизатор, выполняющий трансляцию адресов, ip-адрес отправителя (192.168.0.2) будет заменен на адрес внешнего интерфейса маршрутизатора (195.201.82.146), а в таблицу трансляции адресов будет добавлена запись, аналогичная приведенной в
opad = байт 0x5C, повторённый B раз.Атаки на AH, ESP и IKE.
Оценка протокола
Заключение
Особенности
IPSec
SSL
Аппаратная независимость
Да
Да
Код
Не требуется изменений для приложений. Может потребовать доступ к исходному коду стека TCP/IP.
Требуются изменения в приложениях. Могут потребоваться новые DLL или доступ к исходному коду приложений.
Защита
IP пакет целиком. Включает защиту для протоколов высших уровней.
Только уровень приложений.
Фильтрация пакетов
Основана на аутентифицированных заголовках, адресах отправителя и получателя, и т.п. Простая и дешёвая. Подходит для роутеров.
Основана на содержимом и семантике высокого уровня. Более интеллектуальная и более сложная.
Производительность
Меньшее число переключений контекста и перемещения данных.
Большее число переключений контекста и перемещения данных. Большие блоки данных могут ускорить криптографические операции
и обеспечить лучшее сжатие.
Платформы
Любые системы, включая роутеры
В основном, конечные системы (клиенты/серверы), также firewalls.
Firewall/VPN
Весь трафик защищён.
Защищён только трафик уровня приложений. ICMP, RSVP, QoS и т.п. могут быть незащищены.
Прозрачность
Для пользователей и приложений.
Только для пользователей.
Текущий статус
Появляющийся стандарт.
Широко используется WWW браузерами, также используется некоторыми другими продуктами.
Ссылки
Благодарности
Аутентификация
Фаза 1 и Фаза 2
Компрессия данных
Автоматическая проверка работоспособности VPN соединения
Разрыв VPN соединения и смена ключей
Архитектура IPsec
Security Association
Authentication Header
Authentication Header
format
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
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)
…
…
…
Обработка выходных IP-пакетов
Если поле может изменяться в процессе транспортировки, то его значение устанавливается в 0 перед вычислением ICV. Исключения составляют поля, которые могут изменяться, но значение которых можно предугадать при приеме. При вычислении ICV они не заполняются нулями. Примером изменяемого поля может служить поле контрольной суммы, примером изменяемого, но предопределенного может являться IP-адрес получателя. Более подробное описание того, какие поля как учитываются при вычислении ICV, можно найти в стандарте RFC 2402 .
Обработка входных IP-пакетов
Encapsulating Security Payload
format
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.
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)
…
…
…
Обработка выходных IPsec-пакетов
Обработка входных IPsec-пакетов
Использование
См. также
Ссылки
Виртуальные частные сети (VPN)
Программное обеспечение
Механизмы
Управляемые поставщиком
сеть
, безопасного туннеля (
рис.
5.9), по
которому передаются конфиденциальные или чувствительные к несанкционированному изменению данные. Подобный туннель
создается с использованием криптографических методов защиты информации.Механизмы безопасности в
Рис.
5.9.
Протокол AH
Рис.
5.10.
Рис.
5.12.
Рис.
5.13.
IPSec и NAT