Подпишись на нас

В конце шестидесятых годов американское агентство перспективных исследований в обороне 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 раз;
opad = байт 0x5C, повторённый B раз.

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

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

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

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

Все виды атак на компоненты IPSec можно разделить на следующие группы: атаки, эксплуатирующие конечность ресурсов системы (типичный пример — атака "Отказ в обслуживании", Denial-of-service или DOS-атака), атаки, использующие особенности и ошибки конкретной реализации IPSec и, наконец, атаки, основанные на слабостях самих протоколов. AH и ESP. Чисто криптографические атаки можно не рассматривать — оба протокола определяют понятие "трансформ", куда скрывают всю криптографию. Если используемый криптоалгоритм стоек, а определенный с ним трансформ не вносит дополнительных слабостей (это не всегда так, поэтому правильнее рассматривать стойкость всей системы — Протокол-Трансформ-Алгоритм), то с этой стороны все нормально. Что остается? Replay Attack — нивелируется за счет использования Sequence Number (в одном единственном случае это не работает — при использовании ESP без аутентификации и без AH). Далее, порядок выполнения действий (сначала шифрация, потом аутентификация) гарантирует быструю отбраковку "плохих" пакетов (более того, согласно последним исследованиям в мире криптографии, именно такой порядок действий наиболее безопасен, обратный порядок в некоторых, правда очень частных случаях, может привести к потенциальным дырам в безопасности; к счастью, ни SSL, ни IKE, ни другие распространенные протоколы с порядком действий "сначала аутентифицировать, потом зашифровать", к этим частным случаям не относятся, и, стало быть, этих дыр не имеют). Остается Denial-Of-Service атака. Как известно, это атака, от которой не существует полной защиты. Тем не менее, быстрая отбраковка плохих пакетов и отсутствие какой-либо внешней реакции на них (согласно RFC) позволяют более-менее хорошо справляться с этой атакой. В принципе, большинству (если не всем) известным сетевым атакам (sniffing, spoofing, hijacking и т.п.) AH и ESP при правильном их применении успешно противостоят. С IKE несколько сложнее. Протокол очень сложный, тяжел для анализа. Кроме того, в силу опечаток (в формуле вычисления HASH_R) при его написании и не совсем удачных решений (тот же HASH_R и HASH_I) он содержит несколько потенциальных "дыр" (в частности, в первой фазе не все Payload в сообщении аутентифицируются), впрочем, они не очень серьезные и ведут, максимум, к отказу в установлении соединения.От атак типа replay, spoofing, sniffing, hijacking IKE более-менее успешно защищается. С криптографией несколько сложнее, — она не вынесена, как в AH и ESP, отдельно, а реализована в самом протоколе. Тем не менее, при использовании стойких алгоритмов и примитивов (PRF), проблем быть не должно. В какой-то степени можно рассматривать как слабость IPsec то, что в качестве единственного обязательного к реализации криптоалгоритма в нынешних спецификациях указывается DES (это справедливо и для ESP, и для IKE), 56 бит ключа которого уже не считаются достаточными. Тем не менее, это чисто формальная слабость — сами спецификации являются алгоритмо-независимыми, и практически все известные вендоры давно реализовали 3DES (а некоторые уже и AES).Таким образом, при правильной реализации, наиболее "опасной" атакой остается Denial-Of-Service.

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

Протокол IPSec получил неоднозначную оценку со стороны специалистов. С одной стороны, отмечается, что протокол IPSec является лучшим среди всех других протоколов защиты передаваемых по сети данных, разработанных ранее (включая разработанный Microsoft PPTP). По мнению другой стороны, присутствует чрезмерная сложность и избыточность протокола. Так, Niels Ferguson и Bruce Schneier в своей работе "A Cryptographic Evaluation of IPsec" отмечают, что они обнаружили серьёзные проблемы безопасности практически во всех главных компонентах IPsec. Эти авторы также отмечают, что набор протоколов требует серьёзной доработки для того, чтобы он обеспечивал хороший уровень безопасности. В работе приведено описание ряда атак, использующих как слабости общей схемы обработки данных, так и слабости криптографических алгоритмов.

Заключение

В этой статье мы рассмотрели некоторые основные моменты, касающиеся протокола сетевой безопасности IPsec. Не лишним будет отметить, что протокол IPsec доминирует в большинстве реализаций виртуальных частных сетей. В настоящее время на рынке представлены как программные реализации (например, протокол реализован в операционной системе Windows2000 компании Microsoft), так и программно-аппаратные реализации IPsec — это решения Cisco , Nokia . Несмотря на большое число различных решений, все они довольно хорошо совместимы друг с другом. В заключение статьи приводится таблица, в которой производится сравнение IPSec и широко распространённого сейчас SSL.

Особенности IPSec SSL
Аппаратная независимость Да Да
Код Не требуется изменений для приложений. Может потребовать доступ к исходному коду стека TCP/IP. Требуются изменения в приложениях. Могут потребоваться новые DLL или доступ к исходному коду приложений.
Защита IP пакет целиком. Включает защиту для протоколов высших уровней. Только уровень приложений.
Фильтрация пакетов Основана на аутентифицированных заголовках, адресах отправителя и получателя, и т.п. Простая и дешёвая. Подходит для роутеров. Основана на содержимом и семантике высокого уровня. Более интеллектуальная и более сложная.
Производительность Меньшее число переключений контекста и перемещения данных. Большее число переключений контекста и перемещения данных. Большие блоки данных могут ускорить криптографические операции и обеспечить лучшее сжатие.
Платформы Любые системы, включая роутеры В основном, конечные системы (клиенты/серверы), также firewalls.
Firewall/VPN Весь трафик защищён. Защищён только трафик уровня приложений. ICMP, RSVP, QoS и т.п. могут быть незащищены.
Прозрачность Для пользователей и приложений. Только для пользователей.
Текущий статус Появляющийся стандарт. Широко используется WWW браузерами, также используется некоторыми другими продуктами.

Ссылки

  • www.ietf.org/html.charters/ipsec-charter.html — Домашняя страничка рабочей группы IETF. Там же находятся ссылки на RFC и предложения по стандартам.
  • www.microsoft.com/rus/windows2000/library/security/w2k_IPSecurity.asp – Информация о реализации протокола IPSec в Windows2000 Server.

Благодарности

Вконтакте

Одноклассники

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

Введение

VPN основанный на технологии IPsec можно разделить на две части:

  • Протокол Internet Key Exchange (IKE)
  • Протоколы IPsec (AH/ESP/both)

Первая часть (IKE) является фазой согласования, во время которой две VPN-точки выбирают какие методы будут использоваться для защиты IP трафика посылаемого между ними. Помимо этого IKE также используется для управления соединениями, для этого вводится понятие Security Associations (SA) для каждого соединения. SA направлены только в одну сторону, поэтому типичное IPsec соединение использует два SA.

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

Последовательность установления VPN через IPsec можно кратко описать как:

  • IKE согласовывает защиту уровня IKE
  • IKE согласовывает защиту уровня IPsec
  • защищаемые данные передаются через VPN IPsec

IKE, Internet Key Exchange

Для шифрования и аутентификации данных требуется выбрать способ шифрования/аутентификации (алгоритм) и ключи используемые в них. Задача Internet Key Exchange protocol, IKE, в этом случае сводится к распространению данных “ключей сессии” и согласованию алгоритмов, которыми будут защищаться данные между VPN-точками.

Основные задачи IKE:

  • Аутентификация VPN-точек друг друга
  • Организация новых IPsec соединений (через создание SA пар)
  • Управление текущими соединениями

IKE ведет учет соединений путем назначения каждому из них некого Security Associations, SA. SA описывает параметры конкретного соединения, включая IPsec протокол (AH/ESP или оба), ключи сессии, используемые для шифрования/дешифрования и/или аутентификации данных. SA является однонаправленной, поэтому используется несколько SA на одно соединение. В большинстве случаев, когда используется только ESP или AH, создаются только две SA для каждого из подключений, одна для входящего трафика, а вторая для исходящего. Когда ESP и AH используются вместе, SA требуется четыре.

Процесс согласования IKE проходит через несколько этапов (фаз). Данные фазы включают:

  1. IKE первой фазы (IKE Phase-1):
    — Согласовывается защита самого IKE (ISAKMP tunnel)
  2. IKE второй фазы (IKE Phase-2):
    — Согласовывается защита IPsec
    — Получение данных из первой фазы для формирования ключей сессии

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

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

IKE первой фазы – согласование защиты IKE (ISAKMP Tunnel)
На первой фазе согласования VPN-точки аутентифицируют друг друга на основе общего ключа (Pre-Shared Key). Для аутентификации используются хэш алгоритм: MD5, SHA-1, SHA-2.
Однако перед тем как аутентифицировать друг друга, чтобы не передавать информацию открытым текстом, VPN-точки выполняют обмен списками предложений (Proposals), описанный ранее. Только после того как устраивающее обеих VPN-точек предложение выбрано, происходит аутентификация VPN-точка друг друга.
Аутентификацию можно осуществлять разными способами: через общие ключи (Pre-Shared Keys), сертификаты или . Общие ключи являются наиболее распространенным способом аутентификации.
Согласование IKE первой фазы может происходить в одном из двух режимов: main (основной) и aggressive (агресивный). Основной режим более длительный, но зато и более защищенный. В его процесее происходит обмен шестью сообщениями. Агресивный режим происходит быстрее, ограничиваясь тремя сообщениями.
Основная работа первой фазы IKE лежит в обмене ключами Диффи-Хеллмана. Он основан на шифровании с открытым ключем, каждая из сторон шифрует аутентификационный параметр (Pre-Shared Key) открытым ключем соседа, который получив данное сообщение расшифровывает его своим закрытым ключем. Другой способо аутентификации сторон друг друга — использование сертификатов.

IKE второй фазы – согласование защиты IPsec
Во второй фазе осуществляется выбор способа защиты IPsec подключения.
Для работы второй фазы используется материал (keying material) извлеченный из обмена ключами Диффи-Хеллмана (Diffie-Hellman key exchange), произошедшего на первой фазе. На основе этого материала создаются ключи сессии (session keys), использующиеся для защиты данных в VPN-туннеле.

Если используется механизм Perfect Forwarding Secrecy (PFS) , то для каждого согласования второй фазы будет использоваться новый обмен ключами Диффи-Хеллмана. Несколько снижая скорость работы, данная процедура гарантирует, что ключи сессии не зависимы друг от друга, что повышает защиту, поскольку даже если произойдет компромат одного из ключей, он не сможет быть использован для подбора остальных.

Режим работы второй фазы согласования IKE только один, он называется quick mode — быстрый режим. В процессе согласования второй фазы происходит обмен тремя сообщениями.

По окончании второй фазы, устанавливается VPN-подключение.

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

  • Идентификация конечных узлов
    Каким образом узлы аутентифицируют друг друга. Наиболее часто используется общий ключ. Аутентификация основанная на общем ключе использует алгоритм Диффи-Хеллмана.
  • Локальная и удаленная сеть/хост
    Определяет трафик, который будет пускаться через VPN-туннель.
  • Режим туннеля или транспорта.
    IPsec может работать в двух режимах: туннельном и транспортном. Выбор режима зависит от защищаемых объектов.
    Туннельный режим применяется для защиты между удаленными объектами, т.е. IP-пакет полностью инкапсулируется в новый и для наблюдателя со стороны будет видно только соединение между двумя VPN-точками. Реальные IP-адреса источника и получателя будут видны только после декапсуляции пакета при приеме его на VPN-точке получения. Таким образом туннельный режим чаще всего используется для VPN-подключений.
    Транспортный режим защищает данные IP-пакета (TCP, UDP и протоколы верхних уровней), а сам заголовок оригинального IP-пакета будет сохранен. Таким образом для наблюдателя будет виден оригинальный источник и назначение, но не передаваемые данные. Данный режим наиболее часто используется при защите соединение в локальной сети между хостами.
  • Удаленный шлюз
    VPN-точка получатель защищенного соединения, которая будет расшифровывать/аутентифицировать данные с другой стороны и отправлять их к окончательному месту назначения.
  • Режим работы IKE
    IKE согласование может работать в двух режимах: основной и агрессивном .
    Разница между ними заключается в том, что в агрессивном режиме используется меньшее кол-во пакетом, что позволяет достичь более быстрого установления соединения. С другой стороны агрессивный режим не передает некоторые параметры согласования, такие как Диффи-Хеллман группы и PFS, что требует предварительной идентичной настройки их на точках участницах подключения.
  • IPsec протоколы
    Существует два протокола IPsec: Authentication Header (AH) и Encapsulating Security Payload (ESP), которые выполняют функции шифрования и аутентификации.
    ESP позволяет шифровать, аутентифицировать по отдельности или одновременно.
    AH позволяет только аутентифицировать. Разница с ESP аутентификацией в том, что AH аутентифицирует также и внешний IP заголовок, позволяя подтвердить, что пакет прибыл действительно от источника указанного в нем.
  • IKE шифрование
    Указывает используемый алгоритм шифрования IKE и его ключи. Поддерживаются разные симметричные алгоритмы шифрования, например: DES, 3DES, AES.
  • IKE аутентификация
    Алгоритм аутентификации используемый в IKE согласовании. Могут быть: SHA, MD5.
  • IKE Диффи-Хеллмана (DH) группы
    Используемая DF группа для обмена ключами в IKE. Чем больше группа тем больше размер ключей обмена.
  • Продолжительность жизни IKE подключения
    Указывается как по времени (секундах), так и по размеру переданных данных (килобайтах). Как только один из счетчиков достигнет порогового значения запускается новая первая фаза. Если с момента создания IKE соединения не было передано никаких данных, никаких новых подключений не будет создано до тех пор, пока одна из сторон не захочет создать VPN соединение.
  • PFS
    При отключенном PFS материал для создания ключей будет извлечен в первой фазе согласования IKE в момент обмена ключей. Во второй фазе согласования IKE ключи сессии будут созданы основываясь на полученном материале. При включенном PFS при создании новых ключей сессии материал для них будет использоваться каждый раз новый. Таким образом при компромате ключа, на основе него не возможно создать новые ключи.
    PFS может быть использован в двух режимах: первый PFS на ключах (PFS on keys), будет запускать новый обмен ключами в первой фазе IKE каждый раз, когда запускается согласование
    второй фазы. Второй режим PFS на идентификаторах (PFS on identities), будет удалять SA первой фазы каждый раз, после прохождения согласования второй фазы, гарантируя тем самым, что ни одно согласование второй фазы не будет зашифровано идентичным предыдущему ключом.
  • IPsec DH группы
    Данные DF группы аналогичны использующимся в IKE, только используются для PFS.
  • IPsec шифрование
    Алгоритм использующийся для шифрования данных. Используется в случае использования ESP в режиме шифрования. Пример алгоритмов: DES, 3DES, AES.
  • IPsec аутентификация
    Алгоритм используемый для аутентификации передаваемых данных. Используется в случае AH или ESP в режиме аутентификации. Пример алгоритмов: SHA, MD5.
  • Время жизни IPsec
    Время жизни VPN соединения указывается как по времени (секундах) так и по размеру переданных данных (килобайты). Счетчик первым достигнувший лимита запустит пересоздание ключей сессии. Если с момента создания IKE соединения не было передано никаких данных, никаких новых подключений не будет создано до тех пор, пока одна из сторон не захочет создать VPN соединение.

Методы аутентификации IKE

  • Ручной режим
    Самый простой из методов, при котором IKE не используется, а ключи аутентификации и шифрования, а также некоторые другие параметры задаются в ручную на обоих точках VPN подключения.
  • Через общие ключи (Pre-Shared Keys, PSK)
    Заранее введенный общий ключ на обоих точках VPN соединения. Отличие от предыдущего метода в том, что используется IKE, что позволяет аутентифицировать конечные точки и использовать меняющиеся ключи сессии, вместо фиксированных ключей шифрования.
  • Сертификаты
    Каждая точка VPN использует: свой приватный ключ, свой открытый ключ, свой сертификат включающий свой открытый ключ и подписанный доверенным центром сертификации. В отличие от предыдущего метода позволяет избежать ввода одного общего ключа на всех точках VPN соединения, заменяя его личными сертификатами, подписанными доверенным центром.

Протоколы IPsec

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

AH (Authentication Header)

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

В режиме транспорта, AH встраивает свой заголовок после оригинального IP пакета.
В режиме туннеля AH встраивает свой заголовок после внешнего (нового) IP-заголовка и перед внутренним (оригинальным) IP заголовком.

ESP (Encapsulating Security Payload)

ESP протокол используется для шифрования, для аутентификации или и того, и другого по отношению к IP пакету.

В режиме транспорта ESP протокол вставляет свой заголовок после оригинально IP заголовка.
В режиме туннеля ESP заголовок находится после внешнего (нового) IP заголовка и перед внутренним (оригинальным).

Два основных различия между ESP и AH:

  • ESP помимо аутентификации предоставляет еще возможность шифрования (AH этого не предоставляет)
  • ESP в режиме туннеля аутентифицирует только оригинальный IP заголовок (AH аутентифицирует также внешний).

Работа за NAT (NAT Traversal)
Для поддержки работы за NAT была реализована отдельная спецификация. Если VPN-точка поддерживает данную спецификацию, IPsec поддерживает работу за NAT, однако существуют определённые требования.
Поддержка NAT состоит из двух частей:

  • На уровне IKE конечные устройства обмениваются друг с другом информацией о поддержке, NAT Traversal и версией поддерживаемой спецификации
  • На уровне ESP сформированный пакет инкапсулируется в UDP.

NAT Traversal используется только в том случае, если обе точки поддерживают его.
Определение NAT : обе VPN-точки посылают хеши своих IP адресов вместе с UDP портом источника IKE согласования. Данная информация используется получателем, для того чтобы определить был ли изменен IP адрес и/или порт источника. Если данные параметры не были изменены, то трафик не проходит через NAT и механизм NAT Traversal не нужен. Если адрес или порт были изменены, значит между устройствами находится NAT.

Как только конечные точки определят, что необходим NAT Traversal, согласование IKE перемещаются с порта UDP 500 на порт 4500. Делается это потому, что некоторые устройства некорректно обрабатывают IKE сессию на 500 порту при использовании NAT.
Другая проблема возникает из-за того, что ESP протокол – протокол транспортного уровня и располагается непосредственно поверх IP. Из-за этого к нему не применимы понятия TCP/UDP порта, что делает невозможным подключение через NAT более одного клиента к одному шлюзу. Для решения данной проблемы ESP запаковывается в UDP дейтаграмму и посылается на порт 4500, тот же самый, который использует IKE при включенном NAT Traversal.
NAT Traversal встроен в работу протоколов, его поддерживающих и работает без предварительной настройки.

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

    Шаг 1. Начало процесса IPSec . Трафик, которому требуется шифрование в соответствии с политикой защиты IPSec, согласованной сторонами IPSec, начинает IКЕ-процесс.

    Шаг 2. Первая фаза IKE . IKE-процесс выполняет аутентификацию сторон IPSec и ведет переговоры о параметрах ассоциаций защиты IKE, в результате чего создается защищенный канал для ведения переговоров о параметрах ассоциаций защиты IPSec в ходе второй фазы IKE.

    Шаг 3. Вторая фаза IKE . IKE-процесс ведет переговоры о параметрах ассоциации защиты IPSec и устанавливает соответствующие ассоциации защиты IPSec для устройств сообщающихся сторон.

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

    Шаг 5. Завершение работы туннеля IPSec . Ассоциации защиты IPSec завершают свою работу либо в результате их удаления, либо по причине превышения предельного времени их существования.

Режимы работы ipSec

Существует два режима работы IPSec: транспортный и туннельный.

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

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

Согласование преобразований IPSec

В ходе работы протокола IKE ведутся переговоры о преобразованиях IPSec (алгоритмах защиты IPSec). Преобразования IPSec и связанные с ними алгоритмы шифрования являются следующими:

    Протокол АН (Authentication Header - заголовок аутентификации). Протокол зашиты, обеспечивающий аутентификацию и (в качестве опции) сервис выявления воспроизведения. Протокол АН действует как цифровая подпись и гарантирует, что данные в пакете IP не будут несанкционированно изменены. Протокол АН не обеспечивает сервис шифрования и дешифрования данных. Данный протокол может использоваться или самостоятельно, или совместно с протоколом ESP.

    Протокол ESP (Encapsulating Security Payload -- включающий защиту полезный груз). Протокол защиты, обеспечивающий конфиденциальность и защиту данных, а также (в качестве опции) сервис аутентификации и выявления воспроизведения. Поддерживающие IPSec продукты Cisco используют ESP для шифрования полезного груза IP-пакетов. Протокол ESP может использоваться самостоятельно или совместно с АН.

    Стандарт DES (Data Encription Standard -- стандарт шифрования данных). Алгоритм шифрования и дешифрования данных пакетов. Алгоритм DES используется как в рамках IPSec, так и IKE. Для алгоритма DES используется 56-битовый ключ, что означает не только более высокое потребление вычислительных ресурсов, но и более надежное шифрование. Алгоритм DES является симметричным алгоритмом шифрования, для которого требуются идентичные секретные ключи шифрования в устройствах каждой из сообщающихся сторон IPSec. Для создания симметричных ключей применяется алгоритм Диффи-Хеллмана. IKE и IPSec используют алгоритм DES для шифрования сообщений.

    "Тройной" DES (3DES). Вариант DES, основанный на использовании трех итераций стандартного DES с тремя разными ключами, что практически утраивает стойкость DES. Алгоритм 3DES используется в рамках IPSec для шифрования и дешифрования потока данных. Данный алгоритм использует 168-битовый ключ, что гарантирует высокую надежность шифрования. IKE и IPSec используют алгоритм 3DES для шифрования сообщений.

    AES (advanced encryption standard ). Протокол AES использует алгоритм шифрования Rine Dale4, который обеспечивает существенно более надежное шифрование. Многие криптографы считают, что AES вообще невозможно взломать. Сейчас AES яв­ляется федеральным стандартом обработки информации. Он определен как алгоритм шифрования для использования правительственными организациями США для защи­ты важных, но несекретных сведений. Проблема, связанная с AES, состоит в том, что для его реализации требуется большая вычислительная мощность по сравнению с аналогичными протоколами.

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

    Алгоритм MD5 (Message Digest 5). Алгоритм хэширования, применяемый для аутентификации пакетов данных. В продуктах Cisco используется вычисляемый с помощью MD5 код НМАС (Hashed Message Authentication Code -- хэшированный код аутентичности сообщения)- вариант кода аутентичности сообщения, которому обеспечивается дополнительная защита с помощью хэширования. Хэширование представляет собой процесс одностороннего (т.е. необратимого) шифрования, в результате которого для поступающего на вход сообщения произвольной длины получается вывод фиксированной длины. IKE, АН и ESP используют MD5 для аутентификации данных.

    Алгоритм SHA-1 (Secure Hash Algorithm-1 -- защищенный алгоритм хэширования 1). Алгоритм хэширования, используемый для аутентификации пакетов данных. В продуктах Cisco применяется вариант кода НМАС, вычисляемый с помощью SHA-1. IKЕ, АН и ESP используют SHA-1 для аутентификации данных.

В рамках протокола IKE симметричные ключи создаются с помощью алгоритма Диффи-Хеллмана, использующего DES, 3DES, MD5 и SHA. Протокол Диффи-Хеллмана является криптографическим протоколом, основанным на применении открытых ключей. Он позволяет двум сторонам согласовать общий секретный ключ, не имея достаточно надежного канала связи. Общие секретные ключи требуются для алгоритмов DES и НМАС. Алгоритм Диффи-Хеллмана используется в рамках IKE для создания сеансовых ключей. Группы Diffie-Hellman (DH) – определяют «силу» ключа шифрования, который используется в процедуре обмена ключами. Чем выше номер группы, тем «сильнее» и безопаснее ключ. Однако следует учитывать тот факт, что при увеличении номер группы DH увеличивается «сила» и уровень безопасности ключа, однако одновременно увеличивается нагрузка на центральный процессор, так как для генерации более «сильного» ключа необходимо больше времени и ресурсов.

Устройства WatchGuard поддерживают DH группы 1, 2 и 5:

    DH group 1: 768-bit key

    DH group 2: 1024-bit key

    DH group 5: 1536-bit key

Оба устройства, которые обмениваются данными через VPN должны использовать одну и ту же группу DH. Группа DH, которая будет использоваться устройствами, выбирается во время IPSec Phase 1 процедуры.

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

В 1994 году Совет по архитектуре Интернет выпустил отчет “Безопасность архитектуры Интернет”. Данный отчет посвящался в основном проблемам защиты от несанкционированного мониторинга, подмены пакетов и управлению потоками данных. Требовалась разработка некоторого стандарта, способного решить все эти проблемы. В результате были созданы стандарты протоколов, в число которых входил IPsec.

IPsec (сокр. IP Security) – группа протоколов, предназначенных для обеспечения защиты данных, передаваемых по IP-сети. Задача IPsec сводится к тому, чтобы выбрать конкретные алгоритмы и механизмы и настроить соответствующим образом устройства, участвующие в создании безопасного соединения. IPsec находит применение в организации VPN-соединений.

При создании защищенного канала участникам данного процесса необходимо произвести следующие действия:

  1. Аутентифицировать друг друга
  2. Сгенерировать и обменяться ключами
  3. Договориться с помощью каких протоколов шифровать данные
  4. Начать передавать данные в зашифрованный туннель

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

IKE (Internet Key Exchange) – протокол обмена ключами.

IKE используется на первой стадии установления соединения. К его задачам относят: аутентификация VPN-точек, организация новых IPsec соединений (через создание SA-пар), управление текущими соединениями. SA представляет из себя набор параметров защищенного соединения. При настроенном соединении для каждого протокола создается одна SA-пара: первая для протокола AH, вторая для ESP (расскажу про них дальше). Также стоит отметить, что SA является однонаправленным. Таким образом, при связи двух компьютеров будет использоваться четыре SA. IKE работает в двух фазах, при этом первая фаза может работать как в основном, так и в агрессивном режиме. Рассмотрим две фазы IKE-соединения:

Первая фаза (основной режим):

  1. Обмен параметрами безопасности IKE-соединения (алгоритмы и хэш-функции)
  2. На каждом конце туннеля генерируются общий секретный ключ
  3. Используя алгоритм Деффи-Хеллмана , стороны обмениваются общим секретным ключом
  4. Аутентификация обеих концов туннеля

Первая фаза (агрессивный режим): в первый пакет сразу помещается вся необходимая информация для установления 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


Подписывайтесь на нашу

Посмотрело: 7391

0 Давайте рассмотрим детали технологий, составляющих суть IPSec. Стандарты, используемые в рамках IPSec, являются достаточно сложными для понимания, поэтому в этом разделе мы рассмотрим каждую из составляющих IPSec подробно. Для понимания того что такое IPSEC используйте документ "IPSEC как протокол защиты сетевого трафика", опубликованный ранее на этом сайте. Данная статья является продолжением вышеуказанного документа.

В IPSec используются следующие технологии:

  • протокол АН;
  • протокол ESP;
  • стандарт шифрования DES;
  • стандарт шифрования 3DES;
  • протокол IKE;
  • метод согласования ключей по схеме Диффи-Хеллмана;
  • хэшированные коды аутентичности сообщений (НМАС);
  • защита RSA;
  • центры сертификации.

Протокол АН

Данный протокол обеспечивает аутентификацию и целостность данных для пакетов IP, передаваемых между двумя системами. Протокол АН не
обеспечивает конфиденциальность (т.е. шифрование) пакетов. Аутентификация выполняется путем применения к пакету односторонней, зависящей от ключа функции хэширования, генерирующей "профиль" сообщения. Изменение любой части пакета в пути передачи будет обнаружено получателем в результате применения к полученным данным аналогичной односторонней функции хэширования и сравнения вычисленного значения профиля сообщения с тем, которое указал отправитель. Аутентичность полученной информации гарантируется тем, что для одностороннего хэширования обеими системами используется один и тот же секретный ключ. Схема работы протокола АН пока¬зана ниже. При этом выполняются следующие действия.

  1. Выполняется хэширование IP-заголовка и полезного груза пакета.
  2. Полученный хэш-код используется при построении нового заголовка АН, который подсоединяется к исходному пакету между заголовком и блоком полезного груза.
  3. Новый пакет передается второй стороне IPSec.
  4. Сторона-получатель вычисляет значение хэш-кода для заголовка IP и полезного груза, извлекает переданное значение хэш-кода из заголовка АН и сравнивает эти два значения. Соответствующие значения хэш-кода должны в точности совпадать. Если в пути изменится хотя бы один бит пакета, вычисленный получателем хэш-код пакета не будет совпадать со значением, указанным в заголовке АН.
Протокол АН обеспечивает аутентификацию для максимально возможного числа полей заголовка IP, как и для полей данных протоколов высших уровней. Однако некоторые поля заголовка IP могут изменяться в пути. Значения изменяемых полей (например, поля TTL, указывающего время существования пакета) изменяются промежуточными сетевыми устройствами, через которые проходит пакет, и такие изменения отправитель прогнозировать не может. Значения изменяемых полей не должны защищаться протоколом АН. Таким образом, защита, которая обеспечивается заголовку IP протоколом АН, оказывается несколько ограниченной. Протокол АН может также дополнительно обеспечить защиту от воспроизведения пакетов, для чего в заголовке IP указывается порядковый номер пакета. Полное описание протокола АН со¬держится в документе RFC 2402.

Протокол ESP

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

Протокол ESP обеспечивает конфиденциальность с помощью шифрования на уровне пакетов IP. При этом поддерживается множество алгоритмов симметричной схемы шифрования. Алгоритмом по умолчанию для IPSec является DES с 56-битовым ключом. Этот шифр должен присутствовать для гарантии совместимости между всеми поддерживающими IPSec продуктами. Продукты Cisco поддерживают также алгоритм 3DES, обеспечивающий более стойкое шифрование. Конфиденциальность может быть выбрана независимо от других сервисов.

Аутентификация источника данных и поддержка целостности без установления соединений используются совместно и являются опциями (т.е. необязательны). Эти возможности можно также объединить с сервисом конфиденциальности.
Сервис защиты от воспроизведения можно выбрать только в том случае, если выбрана аутентификация источника данных, и выбор этого сервиса является исключительной прерогативой получателя. Хотя по умолчанию от отправителя и требуется ав¬томатически увеличивать порядковый номер, используемый для защиты от воспроизведения, этот сервис оказывается эффективным только в том случае, если получатель проверяет этот порядковый номер. Конфиденциальность трафика требует выбора тун¬нельного режима. Наиболее эффективным это оказывается в шлюзе защиты, где маскировка источника-адресата может быть выполнена сразу для всего трафика. Здесь следует отметить, что хотя и конфиденциальность, и аутентификация являются опциями, должен быть выбран по крайней мере один из этих сервисов.
Набор сервисов, обеспечиваемых протоколом ESP, зависит от параметров, которые указываются в конфигурации IPSec и выбираются при создании ассоциации защиты IPSec. Однако выбор конфиденциальности без целостности/аутентификации (или в рамках ESP, или отдельно с помощью АН) оставляет противнику возможность для проведения атак определенного вида, что может ограничить пользу применяемого та¬ким образом сервиса конфиденциальности.
Заголовок ESP вставляется в пакет после заголовка IP перед заголовком протокола высшего уровня (в транспортном режиме) или перед инкапсулированным заголовком IP (в туннельном режиме). Полное описание протокола ESP содержится в документе RFC 2406.

Шифрование ESP с применением НМАС

В рамках протокола ESP может также обеспечиваться аутентификация пакетов с помощью необязательного поля аутентификации. В программном обеспечении Cisco IOS и в брандмауэрах PIX Firewall этот сервис называется ESP НМАС. Значения аутентификации вычисляются после того, как выполнено шифрование. Используемый сегодня стандарт IPSec описывает алгоритмы SHA1 и MD5 как обязательные для НМАС.
Главное различие между аутентификацией ESP и аутентификацией АН заключается в области их охвата. ESP не защищает никаких полей заголовка IP, если только не предполагается инкапсуляция ESP (туннельный режим). На рис указано, какие поля защищаются при использовании ESP НМАС.


Обратите внимание на то, что шифрование охватывает только данные полезного груза, a ESP с хэшированием ESP НМАС - заголовок ESP и данные полезного груза. Заголовок IP не защищается. Сервис ESP НМАС не может использоваться самостоя¬тельно, а должен быть объединен с протоколом шифрования ESP.

Туннельный и транспортный режимы IPSec

IPSec действует или в туннельном, или в транспортном режиме. На рис показана схема реализации туннельного режима. В этом режиме вся исходная дейтаграмма IP шифруется и становится полезным грузом в новом пакете IP с новым заголовком IP и дополнительным заголовком IPSec (на рис. заголовок обозначен аббревиатурой HDR). Туннельный режим позволяет сетевому устройству (например, брандмауэру PIX Firewall) выступать в роли шлюза IPSec или прокси-сервера, выполняющего шифрование для хостов, размещенных за брандмауэром. Маршрутизатор источника шифрует пакет и передает его по туннелю IPSec. Брандмауэр PIX Firewall адресата дешифрует полученный пакет IPSec, извлекает исходную дейтаграмму IP и передает ее системе адресата. Главное преимущество туннельного режима заключается в том, что не требуется модифицировать конечные системы, чтобы обеспечить им возможность использования IPSec. Туннельный режим также не позволяет противнику анализировать поток данных. При обмене в туннельном режиме противник имеет возможность определить только конечные точки туннеля, но не истинных источника и адресата проходящих через туннель пакетов, даже если конечные точки туннеля находятся как раз в системах источника и адресата.


Схема на рис ниже иллюстрирует транспортный режим. Здесь шифруется только полезный груз IP, а исходный заголовок IP остается нетронутым.
Добавляется заголовок IPSec. Преимуществом этого режима является добавление только нескольких байтов к каждому пакету. Кроме того, устройства открытой сети могут видеть истинные адреса отправителя и получателя пакета.


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

Использование туннельного и транспортного режимов

Рассмотрим несколько примеров, иллюстрирующих правила выбора туннельного или транспортного режима. На рис ниже показаны ситуации, в которых используется туннельный режим. Этот режим чаще всего используется для шифрования потока данных между шлюзами защиты IPSec - например, между маршрутизатором Cisco и брандмау эром PIX Firewall. Шлюзы IPSec выполняют функции IPSec для устройств, находящихся за такими шлюзами (на указанном рисунке это персональный компьютер Алисы и серверы HR). В этом примере Алиса получает защищенный доступ к серверам HR через туннель IPSec, установленный между шлюзами.

Туннельный режим используется и для связи конечных станций, в которых выполняется программное обеспечение IPSec, например для связи клиента CiscoSecure VPN и шлюза IPSec.
В данном примере туннельный режим применяется для создания туннеля IPSec между маршрутизатором Cisco и сервером, на котором выполняется программное обеспечение IPSec. Обратите внимание на то, что в программном обеспечении Cisco IOS и брандмауэра PIX Firewall туннельный режим для связей IPSec является режимом, устанавливаемым по умолчанию.
Транспортный режим используется между конечными станциями, поддерживающими IPSec, или между конечной станцией и шлюзом, если шлюз интерпретируется как хост. На рис. ниже показан пример Г, иллюстрирующий применение транспортного режима для создания шифрованного туннеля IPSec от компьютера Алисы, на котором выполняется программное обеспечение клиента Microsoft Windows 2000, к концентратору Cisco VPN 3000, что позволяет Алисе использовать L2ТР-туннель над IPSec.

Использование АН и ESP

В определенных ситуациях проблема выбора между АН и ESP может показаться сложной для решения, но ее можно упростить, если следовать нескольким правилам. Если вам необходимо знать, что данные из идентифицированного источника передают¬ся без нарушения целостности, а их конфиденциальность обеспечивать не требуется, используйте протокол АН, который защищает протоколы высших уровней и поля заголовка IP, не изменяемые в пути. Защита означает, что соответствующие значения нельзя изменить, потому что это будет обнаружено второй стороной IPSec и любая модифицированная дейтаграмма IP будет отвергнута. Протокол АН не обеспечивает защиту от прослушивания канала и просмотра нарушителем заголовка и данных. Но поскольку заголовок и данные незаметно изменить нельзя, измененные пакеты отвергаются.

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