Технологии используемые в IPSEC. Режимы работы ipSec
В конце шестидесятых годов американское агентство перспективных исследований в обороне 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. Вконтакте Одноклассники В современном мире различные VPN-технологии используются повсеместно. Некоторые (например, PPTP) со временем признаются небезопасными и постепенно отмирают, другие (OpenVPN), наоборот, с каждым годом наращивают обороты. Но бессменным лидером и самой узнаваемой технологией для создания и поддержания защищенных частных каналов по-прежнему остается IPsec VPN. Иногда при пентесте можно обнаружить серьезно защищенную сеть с торчащим наружу лишь пятисотым UDP-портом. Все остальное может быть закрыто, пропатчено и надежно фильтроваться. В такой ситуации может возникнуть мысль, что здесь и делать-то особо нечего. Но это не всегда так. Кроме того, широко распространена мысль, что IPsec даже в дефолтных конфигурациях неприступен и обеспечивает должный уровень безопасности. Именно такую ситуацию сегодня и посмотрим на деле. Но вначале, для того чтобы максимально эффективно бороться c IPsec, нужно разобраться, что он собой представляет и как работает. Этим и займемся! Перед тем как переходить непосредственно к самому IPsec, неплохо бы вспомнить, какие вообще бывают типы VPN. Классификаций VPN великое множество, но мы не будем глубоко погружаться в сетевые технологии и возьмем самую простую. Поэтому будем делить VPN на два основных типа - site-to-site VPN-подключения (их еще можно назвать постоянные) и remote access VPN (RA, они же временные). Нас будет интересовать именно второй вариант, так как в случае успешной атаки удается сразу же получить доступ к внутренней сети предприятия, что для пентестера достаточно серьезное достижение. IPsec, в свою очередь, позволяет реализовывать как site-to-site, так и remote access VPN. Что же это за технология и из каких компонентов она состоит? Стоит отметить, что IPsec - это не один, а целый набор различных протоколов, которые обеспечивают прозрачную и безопасную защиту данных. Специфика IPsec состоит в том, что он реализуется на сетевом уровне, дополняя его таким образом, чтобы для последующих уровней все происходило незаметно. Основная сложность состоит в том, что в процессе установления соединения двум участникам защищенного канала необходимо согласовать довольно большое количество различных параметров. А именно - они должны аутентифицировать друг друга, сгенерировать и обменяться ключами (причем через недоверенную среду), а также договориться, с помощью каких протоколов шифровать данные. Именно по этой причине IPsec и состоит из стека протоколов, обязанность которых лежит в том, чтобы обеспечить установление защищенного соединения, его работу и управление им. Весь процесс установления соединения включает две фазы: первая фаза применяется для того, чтобы обеспечить безопасный обмен ISAKMP-сообщений уже во второй фазе. ISAKMP (Internet Security Association and Key Management Protocol) - это протокол, который служит для согласования и обновления политик безопасности (SA) между участниками VPN-соединения. В этих политиках как раз и указано, с помощью какого протокола шифровать (AES или 3DES) и с помощью чего аутентифицировать (SHA или MD5). Итак, мы выяснили, что вначале участникам нужно договориться, с помощью каких механизмов будет создано защищенное соединение, поэтому теперь в дело вступает протокол IKE. IKE (Internet Key Exchange) используется для формирования IPsec SA (Security Association, те самые политики безопасности), проще говоря - согласования работы участников защищенного соединения. Через этот протокол участники договариваются, какой алгоритм шифрования будет применен, по какому алгоритму будет производиться проверка целостности и как аутентифицировать друг друга. Нужно заметить, что на сегодняшний день существует две версии протокола: IKEv1 и IKEv2. Нас будет интересовать только IKEv1: несмотря на то что IETF (The Internet Engineering Task Force) впервые представили его в 1998 году, он по-прежнему еще очень часто используется, особенно для RA VPN (см. рис. 1). Что касается IKEv2, первые его наброски были сделаны в 2005 году, полностью описан он был в RFC 5996 (2010 год), и лишь в конце прошлого года он был объявлен на роль стандарта Интернет (RFC 7296). Более подробно про различия между IKEv1 и IKEv2 можно прочитать во врезке. Разобравшись с IKE, возвращаемся к фазам IPsec. В процессе первой фазы участники аутентифицируют друг друга и договариваются о параметрах установки специального соединения, предназначенного только для обмена информацией о желаемых алгоритмах шифрования и прочих деталях будущего IPsec-туннеля. Параметры этого первого туннеля (который еще называется ISAKMP-туннель) определяются политикой ISAKMP. Первым делом согласуются хеши и алгоритмы шифрования, далее идет обмен ключами Диффи - Хеллмана (DH), и лишь затем происходит выяснение, кто есть кто. То есть в последнюю очередь идет процесс аутентификации, либо по PSK-, либо по RSA-ключу. И если стороны пришли к соглашению, то устанавливается ISAKMP-туннель, по которому уже проходит вторая фаза IKE. На второй фазе уже доверяющие друг другу участники договариваются о том, как строить основной туннель для передачи непосредственно данных. Они предлагают друг другу варианты, указанные в параметре transform-set, и, если приходят к согласию, поднимают основной туннель. Важно подчеркнуть, что после его установления вспомогательный ISAKMP-туннель никуда не девается - он используется для периодического обновления SA основного туннеля. В итоге IPsec в некоем роде устанавливает не один, а целых два туннеля. Теперь пару слов про transform-set. Нужно ведь как-то шифровать данные, идущие через туннель. Поэтому в типовой конфигурации transform-set представляет собой набор параметров, в которых явно указано, как нужно обрабатывать пакет. Соответственно, существует два варианта такой обработки данных - это протоколы ESP и AH. ESP (Encapsulating Security Payload) занимается непосредственно шифрованием данных, а также может обеспечивать проверку целостности данных. AH (Authentication Header), в свою очередь, отвечает лишь за аутентификацию источника и проверку целостности данных. Например, команда crypto ipsec transform-set SET10 esp-aes укажет роутеру, что transform-set с именем SET10 должен работать только по протоколу ESP и c шифрованием по алгоритму AES. Забегая вперед, скажу, что здесь и далее мы будем использовать в качестве цели маршрутизаторы и файрволы компании Cisco. Собственно с ESP все более-менее понятно, его дело - шифровать и этим обеспечивать конфиденциальность, но зачем тогда нужен AH? AH обеспечивает аутентификацию данных, то есть подтверждает, что эти данные пришли именно от того, с кем мы установили связь, и не были изменены по дороге. Он обеспечивает то, что еще иногда называется anti-replay защитой. В современных сетях AH практически не используется, везде можно встретить только ESP. Параметры (они же SA), выбираемые для шифрования информации в IPsec-туннеле, имеют время жизни, по истечении которого должны быть заменены. По умолчанию параметр lifetime IPsec SA составляет 86 400 с, или 24 ч. Мы рассмотрели в первом приближении основную механику работы IPsec, но необходимо заострить внимание еще на нескольких вещах. Первая фаза, помимо всего прочего, может работать в двух режимах: main mode или aggressive mode. Первый вариант мы уже рассмотрели выше, но нас интересует как раз aggressive mode. В этом режиме используется три сообщения (вместо шести в main-режиме). При этом тот, кто инициирует соединение, отдает все свои данные разом - что он хочет и что умеет, а также свою часть обмена DH. Затем ответная сторона сразу завершает свою часть генерации DH. В итоге в этом режиме, по сути, всего два этапа. То есть первые два этапа из main mode (согласование хешей и обмен DH) как бы спрессовываются в один. В результате этот режим значительно опаснее по той причине, что в ответ приходит много технической информации в plaintext’е. И самое главное - VPN-шлюз может прислать хеш пароля, который используется для аутентификации на первой фазе (этот пароль еще часто называется pre-shared key или PSK). Ну а все последующее шифрование происходит без изменений, как обычно. Почему же тогда этот режим по-прежнему используется? Дело в том, что он намного быстрее, примерно в два раза. Отдельный интерес для пентестера представляет тот факт, что aggressive-режим очень часто используется в RA IPsec VPN. Еще одна небольшая особенность RA IPsec VPN при использовании агрессивного режима: когда клиент обращается к серверу, он шлет ему идентификатор (имя группы). Tunnel group name (см. рис. 2) - это имя записи, которая содержит в себе набор политик для данного IPsec-подключения. Это уже одна из фич, специфичных оборудованию Cisco. Казалось бы, что получается и так не слишком простая схема работы, но на деле все еще чуть сложнее. Со временем стало ясно, что только одного PSK недостаточно для обеспечения безопасности. Например, в случае компрометации рабочей станции сотрудника атакующий смог бы сразу получить доступ ко всей внутренней сети предприятия. Поэтому была разработана фаза 1.5 прямо между первой и второй классическими фазами. К слову, эта фаза обычно не используется в стандартном site-to-site VPN-соединении, а применяется при организации удаленных VPN-подключений (наш случай). Эта фаза содержит в себе два новых расширения - Extended Authentication (XAUTH) и Mode-Configuration (MODECFG). XAUTH - это дополнительная аутентификация пользователей в пределах IKE-протокола. Эту аутентификацию еще иногда называют вторым фактором IPsec. Ну а MODECFG служит для передачи дополнительной информации клиенту, это может быть IP-адрес, маска, DNS-сервер и прочее. Видно, что эта фаза просто дополняет ранее рассмотренные, но полезность ее несомненна. Оба протокола работают по UDP-порту с номером 500, но между собой несовместимы, не допускается ситуация, чтобы на одном конце туннеля был IKEv1, а на другом - IKEv2. Вот основные отличия второй версии от первой: Наконец-то разобравшись с особенностями работы IPsec и его компонентов, можно переходить к главному - к практическим атакам. Топология будет достаточно простой и в то же время приближенной к реальности (см. рис. 3). Первым делом нужно определить наличие IPsec VPN шлюза. Сделать это можно, проведя сканирование портов, но здесь есть небольшая особенность. ISAKMP использует протокол UDP, порт 500, а между тем дефолтное сканирование с помощью Nmap затрагивает только TCP-порты. И в результате будет сообщение: All 1000 scanned ports on 37.59.0.253 are filtered . Создается впечатление, что все порты фильтруются и как бы открытых портов нет. Но выполнив команду Nmap -sU --top-ports=20 37.59.0.253
Starting Nmap 6.47 (http://nmap.org) at 2015-03-21 12:29 GMT
Nmap scan report for 37.59.0.253
Host is up (0.066s latency).
PORT STATE SERVICE
500/udp open isakmp
убеждаемся в том, что это не так и перед нами действительно VPN-устройство. Теперь нас будет интересовать первая фаза, aggressive-режим и аутентификация с использованием pre-shared key (PSK). В этом сценарии, как мы помним, VPN-устройство или отвечающая сторона отправляет хешированный PSK инициатору. Одна из самых известных утилит для тестирования протокола IKE - это ike-scan, она входит в состав дистрибутива Kali Linux. Ike-scan позволяет отправлять IKE сообщения с различными параметрами и, соответственно, декодить и парсить ответные пакеты. Пробуем прощупать целевое устройство: Root@kali:~# ike-scan -M -A 37.59.0.253
0 returned handshake; 0 returned notify
Ключ -A указывает на то, что нужно использовать aggressive-режим, а -M говорит о том, что результаты следует выводить построчно (multiline), для более удобного чтения. Видно, что никакого результата не было получено. Причина состоит в том, что необходимо указать тот самый идентификатор, имя VPN-группы. Разумеется, утилита ike-scan позволяет задавать этот идентификатор в качестве одного из своих параметров. Но так как пока он нам неизвестен, возьмем произвольное значение, например 0000. Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253
37.59.0.253 Aggressive Mode Handshake returned
В этот раз видим, что ответ был получен (см. рис. 5) и нам было предоставлено довольно много полезной информации. Достаточно важная часть полученной информации - это transform-set. В нашем случае там указано, что «Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK». Все эти параметры можно указывать и для утилиты ike-scan с помощью ключа --trans . Например --trans=5,2,1,2 будет говорить о том, что алгоритм шифрования 3DES, хеширование HMAC-SHA, метод аутентификации PSK и второй тип группы DH (1024-bit MODP). Посмотреть таблицы соответствия значений можно по этому адресу . Добавим еще один ключ (-P), для того чтобы вывести непосредственно пейлоад пакета, а точнее хеш PSK. Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P
Казалось бы, хеш получен и можно пробовать его брутить, но все не так просто. Когда-то очень давно, в 2005 году, на некоторых железках Сisco была уязвимость: эти устройства отдавали хеш, только если атакующий передавал корректное значение ID. Сейчас, естественно, встретить такое оборудование практически невозможно и хешированное значение присылается всегда, независимо от того, правильное значение ID отправил атакующий или нет. Очевидно, что брутить неправильный хеш бессмысленно. Поэтому первая задача - это определить корректное значение ID, чтобы получить правильный хеш. И в этом нам поможет недавно обнаруженная уязвимость. Дело в том, что существует небольшая разница между ответами во время начального обмена сообщениями. Если кратко, то при использовании правильного имени группы происходит четыре попытки продолжить установление VPN-соединения плюс два зашифрованных пакета второй фазы. В то время как в случае неправильного ID в ответ прилетает всего лишь два пакета. Как видим, разница достаточно существенная, поэтому компания SpiderLabs (автор не менее интересного инструмента Responder) разработала сначала PoC, а затем и утилиту IKEForce для эксплуатации этой уязвимости. Установить IKEForce в произвольный каталог можно, выполнив команду Git clone https://github.com/SpiderLabs/ikeforce
Работает она в двух основных режимах - режиме вычисления -e (enumeration) и режиме брутфорса -b (bruteforce). До второго мы еще дойдем, когда будем смотреть атаки на второй фактор, а вот первым сейчас и займемся. Перед тем как начать непосредственно процесс определения ID, необходимо установить точное значение transform-set. Мы его уже определили ранее, поэтому будем указывать опцией -t 5 2 1 2 . В итоге выглядеть процесс нахождения ID будет следующим образом: Python ikeforce.py 37.59.0.253 -e -w wordlists/group.txt -t 5 2 1 2
В результате достаточно быстро удалось получить корректное значение ID (рис. 7). Первый шаг пройден, можно двигаться дальше. Теперь необходимо, используя правильное имя группы, сохранить PSK-хеш в файл, сделать это можно с помощью ike-scan: Ike-scan -M -A --id=vpn 37.59.0.253 -Pkey.psk
И теперь, когда правильное значение ID было подобрано и удалось получить корректный хеш PSK, мы можем наконец-то начать офлайн-брутфорс. Вариантов такого брутфорса достаточно много - это и классическая утилита psk-crack, и John the Ripper (с jumbo-патчем), и даже oclHashcat, который, как известно, позволяет задействовать мощь GPU. Для простоты будем использовать psk-crack, который поддерживает как прямой брутфорс, так и атаку по словарю: Psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk
Но даже успешно восстановить PSK (см. рис. 8) - это только половина дела. На этом этапе нужно вспомнить про то, что дальше нас ждет XAUTH и второй фактор IPsec VPN. Итак, напомню, что XAUTH - это дополнительная защита, второй фактор аутентификации, и находится он на фазе 1.5. Вариантов XAUTH может быть несколько - это и проверка по протоколу RADIUS, и одноразовые пароли (OTP), и обычная локальная база пользователей. Мы остановимся на стандартной ситуации, когда для проверки второго фактора используется локальная база пользователей. До недавнего времени не существовало инструмента в публичном доступе для брутфорса XAUTH. Но с появлением IKEForce эта задача получила достойное решение. Запускается брутфорс XAUTH достаточно просто: Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2
[+]Program started in XAUTH Brute Force Mode
[+]Single user provided - brute forcing passwords for user: admin
[*]XAUTH Authentication Successful! Username: admin Password: cisco
При этом указываются все найденные ранее значения: ID (ключ -i), восстановленный PSK (ключ -k) и предполагаемый логин (ключ -u). IKEForce поддерживает как грубый перебор логина, так и перебор по списку логинов, который может быть задан параметром -U . На случай возможных блокировок подбора есть опция -s , позволяющая снизить скорость брутфорса. К слову, в комплекте с утилитой идут несколько неплохих словарей, особенно полезных для установления значения параметра ID. Теперь, когда у нас есть все данные, остается последний шаг - собственно проникновение в локальную сеть. Для этого нам понадобится какой-нибудь VPN-клиент, которых великое множество. Но в случае Kali можно без проблем воспользоваться уже предустановленным - VPNC. Для того чтобы он заработал, нужно подкорректировать один конфигурационный файл - /etc/vpnc/vpn.conf . Если его нет, то нужно создать и заполнить ряд очевидных параметров: IPSec gateway 37.59.0.253
IPSec ID vpn
IPSec secret cisco123
IKE Authmode psk
Xauth Username admin
Xauth password cisco
Здесь мы видим, что были использованы абсолютно все найденные на предыдущих шагах данные - значение ID, PSK, логин и пароль второго фактора. После чего само подключение происходит одной командой: Root@kali:~# vpnc vpn
Отключение тоже достаточно простое: Root@kali:~# vpnc-disconnect
Проверить работоспособность подключения можно, используя команду ifconfig tun0 . Защита от рассмотренных сегодня атак должна быть комплексной: нужно вовремя устанавливать патчи, использовать стойкие pre-shared ключи, которые по возможности вовсе должны быть заменены на цифровые сертификаты. Парольная политика и другие очевидные элементы ИБ также играют свою немаловажную роль в деле обеспечения безопасности. Нельзя не отметить и тот факт, что ситуация постепенно меняется, и со временем останется только IKEv2. Мы рассмотрели процесс аудита RA IPsec VPN во всех подробностях. Да, безусловно, задача эта далеко не тривиальна. Нужно проделать немало шагов, и на каждом из них могут поджидать трудности, но зато в случае успеха результат более чем впечатляющий. Получение доступа к внутренним ресурсам сети открывает широчайший простор для дальнейших действий. Поэтому тем, кто ответствен за защиту сетевого периметра, необходимо не рассчитывать на готовые дефолтные шаблоны, а тщательно продумывать каждый слой безопасности. Ну а для тех, кто проводит пентесты, обнаруженный пятисотый порт UDP - это повод провести глубокий анализ защищенности IPsec VPN и, возможно, получить неплохие результаты. Рассмотрим архитектуру семейства протоколов IPSec. Цель данного семейства протоколов состоит в том, чтобы обеспечить различные сервисы безопасности на уровне IP
для протоколов IPv4 и IPv6. Рассмотрим серви-сы безопасности, предоставляемые протоколами IPSec, и использование этих протоколов в сетях ТСР/ IP
. Когда данные сервисы корректно установлены, они не мешают работе пользователей, хостов и других компонентов интернета, которые не применяют данные сервисы безопасности для защиты своего трафика. Эти сервисы являются алгоритмонезависимыми. Это означает возможность добавления новых криптографических алгоритмов без изменения самих протоколов. Например, различные группы пользователей могут использовать различные наборы алгоритмов. Определен стандартный набор алгоритмов по умолчанию для обеспечения интероперабильности во всем интернете. Использование этих алгоритмов совместно с защитой трафика, предоставляемой IPSec, и протоколами управления ключа позволит разработчика систем и приложений обеспечить высокую степень криптографической безопасности. IPSec может быть реализован как в ОС, так и в маршрутизаторе или межсетевом экране. IPSec обеспечивает конфиденциальность
, целостность данных
, управление доступом
и аутентификацию источника данных для IP
-дейтаграмм. Эти сервисы предоставляются с помощью поддержки состояния между источником и получателем IP
-дейтаграмм. Данное состояние определяет конкретные сервисы обеспечения безопасности на уровне дейтаграммы, используемые криптографические алгоритмы для предоставляемых сервисов и ключи для этих алгоритмов. Перечислим основные задачи протоколов IPSec: IPSec предназначен для безопасного взаимодействия с использованием криптографии для протоколов IPv4 и IPv6. Сервисы безопасности включают управление доступом
, целостность
и конфиденциальность
данных и защиту от replay-атак, которая обеспечивается гарантированием целостности некоторой последовательности дейтаграмм. Эти сервисы предоставляются на уровне IP
, обеспечивая защиту для IP
-протокола и протоколов более высокого уровня. IPSec поддерживает две формы целостности: целостность данных
и целостность
определенной последовательности дейтаграмм. Целостность данных
обнаруживает модификацию конкретной IP
-дейтаграммы, безотносительно последовательности дейтаграмм в потоке трафика. Целостность
последовательности дейтаграмм является анти-reply сервисом, с помощью которого определяется получение дубликатов IP
-дейтаграмм. Это отлича-ется от обеспечения целостности соединения, для которого существуют более строгие требования к целостности трафика, а именно, возможность определения потерянных или переупорядоченных сообщений. Рассмотрим выполнение протоколов IPSec, основные компоненты системы и их взаимодействие для обеспечения сервисов безопасности. IPSec выполняется на хосте ( Host
– H) или шлюзе безопасности ( Security
Gateway
– SG), обеспечивая защиту IP
-трафика. Термин " шлюз
безопасности" используется для обозначения маршрутизатора, который реализует IPsec-протоколы. Защита основана на требованиях, определенных в базе данных политики безопасности ( Security Policy
Database
- SPD
), устанавливаемой и поддерживаемой администратором. В общем случае пакеты обрабатываются одним из трех способов, основанных на информации IP
-заголовка и транспортного уровня в соответствии с записями в SPD
. Каждый пакет либо отбрасывается, либо пропускается без обработки, либо обрабатывается в соответствии с записью SPD
для данного пакета. Существует несколько способов реализации IPSec на хосте или совместно с маршрутизатором или межсетевым экраном (для создания шлюза безопасности). Предоставляемые IPSec сервисы по защите трафика реализуются с помощью двух протоколов обеспечения безопасного трафика: Authentication
Header
( AH
) и Encapsulating Security
Payload
( ESP
). Для защиты трафика в IPSec определены следующие протоколы: С трафиком, безопасность
которого обеспечивается IPSec, связано понятие безопасной ассоциации ( Security
Association
– SA
). SA
содержит всю информацию, необходимую для выполнения различных сетевых сервисов безопасности. SA
представляет собой симплексное (однонаправленное) логическое соединение
, создаваемое между двумя конечными точками, для обеспечения безопасности которых используется один из протоколов IPSec. ESP
и АН передают трафик по SA
. Весь трафик, передаваемый по SA
, обрабатывается в соответствии с политикой безопасности, заданной на концах соединения. Опишем различные аспекты управления SA
, определим возможные способы управления политикой безопасности, способы обработки трафика и управления SA
. SA
определяет параметры сервисов безопасности, которые применяются к трафику. В обычном случае при двунаправленном соединении между двумя хостами или между двумя шлюзами безопасности требуется две SA
(по одной на каждое направление). Будем рассматривать SA
только для одноадресных соединений. Определены два режима SA
: режим транспорта и режим туннелирования. Транспортный режим
используется для создания VPN
между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP
-заголовка. В протоколе ESP
транспортный ре-жим SA
обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP
-заголовка. В случае АН защита распространяется также и на отдельные части IP
-заголовка. Другим режимом SA
является режим туннелирования. Если одним из концов соединения является шлюз
безопасности, то по стандартам IPSec SA
обязательно должна выполняться в туннельном режиме, но многие производители допускают в этом случае как туннельный, так и транспортный режимы. Заметим, что когда трафик предназначен для шлюза безопасности, например, в случае ping- или SNMP-команд, шлюз
безопасности рассматривается как хост
, и как правило используется транспортный режим
. Два хоста могут при необходимости устанавливать туннельный режим
. В туннельном режиме добавляется внешний IP
-заголовок, адресами в котором являются шлюзы безопасности. Внутренний IP
-заголовок указывает на конечные
хосты. Заголовок протокола безопасности расположен после внешнего IP
-заголовка и перед внутренним IP
-заголовком. Если АН используется в туннельном режиме, части внешнего IP
-заголовка являются защищенными, как и весь туннелируемый IP
-пакет, т.е. все внутренние заголовки
защищены, как и все протоколы более высокого уровня. Если применяется ESP
, защита обеспечивается только для туннелируемого пакета, а не для внешнего заголовка. Кратко подытожим: Набор реализуемых Протокол работает на сетевом уровне модели 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), а в таблицу трансляции адресов будет добавлена запись, аналогичная приведенной в (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
opad = байт 0x5C, повторённый B раз.Атаки на AH, ESP и IKE.
Оценка протокола
Заключение
Особенности
IPSec
SSL
Аппаратная независимость
Да
Да
Код
Не требуется изменений для приложений. Может потребовать доступ к исходному коду стека TCP/IP.
Требуются изменения в приложениях. Могут потребоваться новые DLL или доступ к исходному коду приложений.
Защита
IP пакет целиком. Включает защиту для протоколов высших уровней.
Только уровень приложений.
Фильтрация пакетов
Основана на аутентифицированных заголовках, адресах отправителя и получателя, и т.п. Простая и дешёвая. Подходит для роутеров.
Основана на содержимом и семантике высокого уровня. Более интеллектуальная и более сложная.
Производительность
Меньшее число переключений контекста и перемещения данных.
Большее число переключений контекста и перемещения данных. Большие блоки данных могут ускорить криптографические операции
и обеспечить лучшее сжатие.
Платформы
Любые системы, включая роутеры
В основном, конечные системы (клиенты/серверы), также firewalls.
Firewall/VPN
Весь трафик защищён.
Защищён только трафик уровня приложений. ICMP, RSVP, QoS и т.п. могут быть незащищены.
Прозрачность
Для пользователей и приложений.
Только для пользователей.
Текущий статус
Появляющийся стандарт.
Широко используется WWW браузерами, также используется некоторыми другими продуктами.
Ссылки
Благодарности
IPsec изнутри
Первый тип служит для постоянной связи различных сетевых островков, например центрального офиса со множеством разбросанных филиалов. Ну а RA VPN представляет собой сценарий, когда клиент подключается на небольшой промежуток времени, получает доступ к определенным сетевым ресурсам и после завершения работы благополучно отключается.Две основные фазы IPsec
Как обрабатывать данные
В итоге участники получили шифрованный туннель с параметрами, которые их всех устраивают, и направляют туда потоки данных, подлежащие шифрованию. Периодически, в соответствии с lifetime, обновляются ключи шифрования для основного туннеля: участники вновь связываются по ISAKMP-туннелю, проходят вторую фазу и заново устанавливают SA.Режимы IKEv1
Двух фаз оказалось недостаточно
IKEv2 vs IKEv1
Выходим на рубеж
Атакуем первую фазу
Преодолеваем первые сложности
В чем сила IKE
Получаем PSK
Расправляемся со вторым фактором IPsec
Входим во внутреннюю сеть
Как построить надежную защиту
Что в итоге
Возможные способы реализации IPSec
Протоколы защиты трафика и понятие безопасной ассоциации
Рис.
5.9.
Протокол AH
Рис.
5.10.
Рис.
5.12.
Рис.
5.13.
IPSec и NAT
Архитектура 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)
Программное обеспечение
Механизмы
Управляемые поставщиком
Механизмы безопасности в
