что обеспечивает протокол ipsec

Семейство протоколов IPSec

Назначение семейства протоколов IPSec

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

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

IPSec может быть реализован как в ОС, так и в маршрутизаторе или межсетевом экране.

Перечислим основные задачи протоколов IPSec:

Рассмотрим выполнение протоколов IPSec, основные компоненты системы и их взаимодействие для обеспечения сервисов безопасности.

Возможные способы реализации IPSec

Существует несколько способов реализации IPSec на хосте или совместно с маршрутизатором или межсетевым экраном (для создания шлюза безопасности).

Протоколы защиты трафика и понятие безопасной ассоциации

Предоставляемые IPSec сервисы по защите трафика реализуются с помощью двух протоколов обеспечения безопасного трафика: Authentication Header ( AH ) и Encapsulating Security Payload ( ESP ).

Для защиты трафика в IPSec определены следующие протоколы:

С трафиком, безопасность которого обеспечивается IPSec, связано понятие безопасной ассоциации ( Security Association – SA ). SA содержит всю информацию, необходимую для выполнения различных сетевых сервисов безопасности.

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

Будем рассматривать SA только для одноадресных соединений.

Источник

Анатомия IPsec. Проверяем на прочность легендарный протокол

В современном мире различные VPN-технологии используются повсеместно. Некоторые (например, PPTP) со временем признаются небезопасными и постепенно отмирают, другие (OpenVPN), наоборот, с каждым годом наращивают обороты. Но бессменным лидером и самой узнаваемой технологией для создания и поддержания защищенных частных каналов по-прежнему остается IPsec VPN. Иногда при пентесте можно обнаружить серьезно защищенную сеть с торчащим наружу лишь пятисотым UDP-портом. Все остальное может быть закрыто, пропатчено и надежно фильтроваться.

В такой ситуации может возникнуть мысль, что здесь и делать-то особо нечего. Но это не всегда так. Кроме того, широко распространена мысль, что IPsec даже в дефолтных конфигурациях неприступен и обеспечивает должный уровень безопасности. Именно такую ситуацию сегодня и посмотрим на деле. Но вначале, для того чтобы максимально эффективно бороться c IPsec, нужно разобраться, что он собой представляет и как работает. Этим и займемся!

IPsec изнутри

Перед тем как переходить непосредственно к самому IPsec, неплохо бы вспомнить, какие вообще бывают типы VPN. Классификаций VPN великое множество, но мы не будем глубоко погружаться в сетевые технологии и возьмем самую простую. Поэтому будем делить VPN на два основных типа — site-to-site VPN-подключения (их еще можно назвать постоянные) и remote access VPN (RA, они же временные).

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

Две основные фазы IPsec

Итак, мы выяснили, что вначале участникам нужно договориться, с помощью каких механизмов будет создано защищенное соединение, поэтому теперь в дело вступает протокол IKE. IKE (Internet Key Exchange) используется для формирования IPsec SA (Security Association, те самые политики безопасности), проще говоря — согласования работы участников защищенного соединения. Через этот протокол участники договариваются, какой алгоритм шифрования будет применен, по какому алгоритму будет производиться проверка целостности и как аутентифицировать друг друга. Нужно заметить, что на сегодняшний день существует две версии протокола: IKEv1 и IKEv2. Нас будет интересовать только IKEv1: несмотря на то что IETF (The Internet Engineering Task Force) впервые представили его в 1998 году, он по-прежнему еще очень часто используется, особенно для RA VPN (см. рис. 1).

Рис. 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 в некоем роде устанавливает не один, а целых два туннеля.

Как обрабатывать данные

Теперь пару слов про 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 ч.

В итоге участники получили шифрованный туннель с параметрами, которые их всех устраивают, и направляют туда потоки данных, подлежащие шифрованию. Периодически, в соответствии с lifetime, обновляются ключи шифрования для основного туннеля: участники вновь связываются по ISAKMP-туннелю, проходят вторую фазу и заново устанавливают SA.

Режимы IKEv1

Мы рассмотрели в первом приближении основную механику работы 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.

Рис. 2. Tunnel group name

Двух фаз оказалось недостаточно

Казалось бы, что получается и так не слишком простая схема работы, но на деле все еще чуть сложнее. Со временем стало ясно, что только одного PSK недостаточно для обеспечения безопасности. Например, в случае компрометации рабочей станции сотрудника атакующий смог бы сразу получить доступ ко всей внутренней сети предприятия. Поэтому была разработана фаза 1.5 прямо между первой и второй классическими фазами. К слову, эта фаза обычно не используется в стандартном site-to-site VPN-соединении, а применяется при организации удаленных VPN-подключений (наш случай). Эта фаза содержит в себе два новых расширения — Extended Authentication (XAUTH) и Mode-Configuration (MODECFG).

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-ключ (что достаточно ресурсоемкий процесс) и вскоре бы столкнулся с проблемами. В итоге за счет того, что все операции теперь требуют подтверждения от другой стороны соединения, на атакуемом устройстве нельзя создать большое количество полуоткрытых сессий.

Выходим на рубеж

Наконец-то разобравшись с особенностями работы IPsec и его компонентов, можно переходить к главному — к практическим атакам. Топология будет достаточно простой и в то же время приближенной к реальности (см. рис. 3).

Рис. 3. Общая схема сети

Первым делом нужно определить наличие IPsec VPN шлюза. Сделать это можно, проведя сканирование портов, но здесь есть небольшая особенность. ISAKMP использует протокол UDP, порт 500, а между тем дефолтное сканирование с помощью Nmap затрагивает только TCP-порты. И в результате будет сообщение: `All 1000 scanned ports on 37.59.0.253 are filtered`.

Создается впечатление, что все порты фильтруются и как бы открытых портов нет. Но выполнив команду

убеждаемся в том, что это не так и перед нами действительно VPN-устройство.

Атакуем первую фазу

Теперь нас будет интересовать первая фаза, aggressive-режим и аутентификация с использованием pre-shared key (PSK). В этом сценарии, как мы помним, VPN-устройство или отвечающая сторона отправляет хешированный PSK инициатору. Одна из самых известных утилит для тестирования протокола IKE — это ike-scan, она входит в состав дистрибутива Kali Linux. Ike-scan позволяет отправлять IKE сообщения с различными параметрами и, соответственно, декодить и парсить ответные пакеты. Пробуем прощупать целевое устройство:

Рис. 4. Ike-scan aggressive mode

Ключ `-A` указывает на то, что нужно использовать aggressive-режим, а `-M` говорит о том, что результаты следует выводить построчно (multiline), для более удобного чтения. Видно, что никакого результата не было получено. Причина состоит в том, что необходимо указать тот самый идентификатор, имя VPN-группы. Разумеется, утилита ike-scan позволяет задавать этот идентификатор в качестве одного из своих параметров. Но так как пока он нам неизвестен, возьмем произвольное значение, например 0000.

Рис. 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.

Рис. 6. Ike-scan payload

Преодолеваем первые сложности

Казалось бы, хеш получен и можно пробовать его брутить, но все не так просто. Когда-то очень давно, в 2005 году, на некоторых железках Сisco была уязвимость: эти устройства отдавали хеш, только если атакующий передавал корректное значение ID. Сейчас, естественно, встретить такое оборудование практически невозможно и хешированное значение присылается всегда, независимо от того, правильное значение ID отправил атакующий или нет. Очевидно, что брутить неправильный хеш бессмысленно. Поэтому первая задача — это определить корректное значение ID, чтобы получить правильный хеш. И в этом нам поможет недавно обнаруженная уязвимость.

Дело в том, что существует небольшая разница между ответами во время начального обмена сообщениями. Если кратко, то при использовании правильного имени группы происходит четыре попытки продолжить установление VPN-соединения плюс два зашифрованных пакета второй фазы. В то время как в случае неправильного ID в ответ прилетает всего лишь два пакета. Как видим, разница достаточно существенная, поэтому компания SpiderLabs (автор не менее интересного инструмента Responder) разработала сначала PoC, а затем и утилиту IKEForce для эксплуатации этой уязвимости.

В чем сила IKE

Установить IKEForce в произвольный каталог можно, выполнив команду

Работает она в двух основных режимах — режиме вычисления `-e` (enumeration) и режиме брутфорса `-b` (bruteforce). До второго мы еще дойдем, когда будем смотреть атаки на второй фактор, а вот первым сейчас и займемся. Перед тем как начать непосредственно процесс определения ID, необходимо установить точное значение transform-set. Мы его уже определили ранее, поэтому будем указывать опцией `-t 5 2 1 2`. В итоге выглядеть процесс нахождения ID будет следующим образом:

Рис. 7. IKEForce enumeration

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

Получаем PSK

Теперь необходимо, используя правильное имя группы, сохранить PSK-хеш в файл, сделать это можно с помощью ike-scan:

И теперь, когда правильное значение ID было подобрано и удалось получить корректный хеш PSK, мы можем наконец-то начать офлайн-брутфорс. Вариантов такого брутфорса достаточно много — это и классическая утилита psk-crack, и John the Ripper (с jumbo-патчем), и даже oclHashcat, который, как известно, позволяет задействовать мощь GPU. Для простоты будем использовать psk-crack, который поддерживает как прямой брутфорс, так и атаку по словарю:

Рис. 8. Psk-crack

Но даже успешно восстановить PSK (см. рис. 8) — это только половина дела. На этом этапе нужно вспомнить про то, что дальше нас ждет XAUTH и второй фактор IPsec VPN.

Расправляемся со вторым фактором IPsec

Итак, напомню, что XAUTH — это дополнительная защита, второй фактор аутентификации, и находится он на фазе 1.5. Вариантов XAUTH может быть несколько — это и проверка по протоколу RADIUS, и одноразовые пароли (OTP), и обычная локальная база пользователей. Мы остановимся на стандартной ситуации, когда для проверки второго фактора используется локальная база пользователей. До недавнего времени не существовало инструмента в публичном доступе для брутфорса XAUTH. Но с появлением IKEForce эта задача получила достойное решение. Запускается брутфорс XAUTH достаточно просто:

Рис. 9. IKEForce XAUTH

При этом указываются все найденные ранее значения: 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, логин и пароль второго фактора. После чего само подключение происходит одной командой:

Отключение тоже достаточно простое:

Проверить работоспособность подключения можно, используя команду `ifconfig tun0`.

Рис. 10. VPNC

Как построить надежную защиту

Защита от рассмотренных сегодня атак должна быть комплексной: нужно вовремя устанавливать патчи, использовать стойкие pre-shared ключи, которые по возможности вовсе должны быть заменены на цифровые сертификаты. Парольная политика и другие очевидные элементы ИБ также играют свою немаловажную роль в деле обеспечения безопасности. Нельзя не отметить и тот факт, что ситуация постепенно меняется, и со временем останется только IKEv2.

Что в итоге

Мы рассмотрели процесс аудита RA IPsec VPN во всех подробностях. Да, безусловно, задача эта далеко не тривиальна. Нужно проделать немало шагов, и на каждом из них могут поджидать трудности, но зато в случае успеха результат более чем впечатляющий. Получение доступа к внутренним ресурсам сети открывает широчайший простор для дальнейших действий. Поэтому тем, кто ответствен за защиту сетевого периметра, необходимо не рассчитывать на готовые дефолтные шаблоны, а тщательно продумывать каждый слой безопасности. Ну а для тех, кто проводит пентесты, обнаруженный пятисотый порт UDP — это повод провести глубокий анализ защищенности IPsec VPN и, возможно, получить неплохие результаты.

Впервые опубликовано в журнале Хакер #196.
Автор: Александр Дмитренко, PENTESTIT

Источник

Технология IPsec

В IPsec используются две базы данных: SPD (Security Policy Database, куда записываются правила обеспечения безопасности) и SADB (Security Association Database, где хранятся данные об активных ассоциациях безопасности).

Система IPsec предлагает многовариантный механизм реализации безопасности для обоих концов соединения. Эта техника пригодна для отдельного пользователя, особенно если он работает на выезде, и для виртуальных субсетей организаций, работающих с данными, которые требуют секретности.

При использовании совместно с Firewall IPsec предоставляет высокий уровень безопасности. При этом нужно иметь в виду, что для реализации IPsec оба партнера должны иметь оборудование и/или программы, которые поддерживают эти протоколы.

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

Рис. 1. Общая схема преобразования данных в IPsec

Из рисунка видно, что IPsec-заголовки и шифрование данных присутствуют до тех пор, пока пакет транспортируется через среду, где не гарантирована безопасность.

AH и ESP

Заголовок аутентификации (AH) и Encapsulating Security Payload (ESP) являются двумя протоколами нижнего уровня, используемыми IPsec, именно они осуществляют аутентификацию и шифрование+аутентификацию данных, передаваемых через соединение. Эти механизмы обычно используются независимо, хотя возможно (но не типично) их совместное применение.

Режим туннеля и транспортный режим

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

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

На фазе аутентификации вычисляется контрольная сумма ICV (Integrity Check Value) пакета с привлечением алгоритмов MD5 или SHA-1. При этом предполагается, что оба партнера знают секретный ключ, который позволяет получателю вычислить ICV и сравнить с результатом, присланным отправителем. Если сравнение ICV прошло успешно, считается, что отправитель пакета аутентифицирован. Протокол AH всегда осуществляет аутентификацию, а ESP выполняет ее опционно.

Шифрование использует секретный ключ для кодирования данных перед их транспортировкой, что исключает доступ к содержимому со стороны злоумышленников. В системе IPsec могут использоваться следующие алгоритмы: DES, 3DES, Blowfish, CAST, IDEA, RC5 и AES. Но, в принципе, разрешены и другие алгоритмы. Так как обе стороны диалога должны знать секретный ключ, используемый при хэшировании или шифровании, существует проблема транспортировки этих ключей. Возможен ввод ключей вручную, когда эти коды вводятся при конфигурации системы с помощью клавиатуры обоими партнерами. При этом предполагается, что доставка этих кодов осуществлена каким-то достаточно безопасным методом, алгоритм же IKE (Internet Key Exchange – обмен ключами по Интернет) является безопасным механизмом пересылки ключей в реальном масштабе времени, например, через Интернет.

Основной и агрессивный режимы

Эти режимы служат для управления балансом эффективности и безопасности при исходном обмене ключами IKE. «Основной режим» требует шести пакетов в обоих направлениях, но обеспечивает полную безопасность при установлении соединения IPsec. В агрессивном режиме используется вдвое меньше обменов, но безопасность в этом случае ниже, так как часть информации передается открытым текстом.

Пакеты IPsec транспортируются IP-дейтограммами. Заголовки IPsec (AH и ESP) размещаются сразу после IP-заголовка (описание формата IP-дейтограмм смотри в http://book.itep.ru/4/44/ip_441.htm). Тип вложенного пакета в IP идентифицируется содержимым поля протокол.

Некоторые коды поля протокол в IP-дейтограммах представлены в таблице ниже.

Эти коды поля протокол определены IANA (Internet Assigned Numbers Authority). Далее будут более подробно рассмотрены два последних протокола (AH и ESP).

Протокол AH

Протокол AH используется для аутентификации, но не для шифрования IP трафика, и служит для подтверждения того, что мы связаны именно с тем, с кем предполагаем, что полученные данные не искажены и не подменены при транспортировке.

Аутентификация выполняется путем вычисления зашифрованного аутентификационного хэш-кода сообщения. Хэширование охватывает практически все поля IP пакета (исключая только те, которые могут модифицироваться при транспортировке, например, TTL или контрольная сумма заголовка). Этот код записывается в AH заголовке и пересылается получателю. Формат AH заголовка представлен на рис. 2.

Рис. 2. Формат заголовка протокола AH

Этот AH заголовок содержит пять важных полей.

Идентифицирует тип протокола, используемого для следующего поля данных. Фактически это тип пакета, инкапсулированного в AH IPsec.

Определяет длину заголовка пакета, измеренную в 32-битовых словах, за вычетом двух слов (это диктуется RFC 1883 для IPv6).

Поле зарезервировано на будущее и должно содержать нули.

Индекс параметров безопасности (SPI)

32-битовый идентификатор, который помогает получателю выбрать, к какому из входных обменов относится этот пакет. Каждый обмен, защищенный AH, использует хэш-алгоритм (MD5, SHA-1 и т.д..), какие-то секретные и возможно некоторые иные данные. SPI может рассматриваться как индекс таблицы наборов таких параметров, чтобы облегчить выбор нужного набора.

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

Это контрольная сумма ICV (Integrity Check Value), вычисленная для всего пакета, включая большинство полей заголовка (см. рис. 3). Получатель повторно вычисляет тот же хэш. Если значения кодов не совпадут, пакет был поврежден в пути или не соответствует секретному ключу. Такие пакеты отбрасываются. ICV часто называется также МАС (Message Authentication Code). Для вычисления МАС используются следующие поля:

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

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

При транспортном режиме AH IP-пакет модифицируется лишь слегка путем включения AH заголовка между IP заголовком и полем данных (TCP, UDP и т.д.) и перестановки кодов протокола.

Перестановка кодов протокола необходима для восстановления исходного вида IP пакетов конечным получателем: после выполнения проверки получателем корректности IPsec заголовка, этот заголовок удаляется, а в поле код протокола IP заносится прежнее значение (TCP, UDP и т.д.).

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

На рис. 3 показано преобразование форматов заголовков в транспортном режиме IPsec. Слева на рисунке размешен формат исходной дейтограммы с инкапсулированным ТСР-сегментом. Закрашенные области защищены аутентификационными данными АН. Поля TOS, TTL, флаги, указатель (фрагмента) и контрольная сумма заголовка не защищаются, так как их содержимое может изменяться в процессе транспортировки, а промежуточные узлы не владеют необходимыми ключами для дешифрования и повторного шифрования. Поля, не охватываемые защитой хэша, перед вычислением ICV заполняются нулями.

Рис. 3. Преобразование форматов в транспортном режиме АН IPsec

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

Режим туннеля реализует функциональность VPN, где IP пакет целиком инкапсулируются в другой пакет и в таком виде доставляются адресату.

Также как и в транспортном режиме, пакет защищается контрольной суммой ICV, чтобы аутентифицировать отправителя и предотвратить модификацию пакета при транспортировке. Но в отличие от транспортного режима, здесь инкапсулируется весь IP пакет, а это позволяет адресам отправителя и получателя отличаться от адресов, содержащихся в пакете, что позволяет формировать туннель.

На рис. 4 показано преобразование форматов заголовков в туннельном режиме IPsec. Слева на рисунке размешен формат исходной дейтограммы с инкапсулированным ТСР-сегментом. Закрашенные области защищены аутентификационными данными АН.

Рис. 4. Преобразование форматов в туннельном режиме АН IPsec

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

Большинство реализаций рассматривает оконечную точку туннеля в качестве сетевого интерфейса.

Реконструированный пакет может быть доставлен локальной машине или маршрутизован куда-либо еще (согласно IP-адресу места назначения в инкапсулированном пакете). Дальнейшая его транспортировка уже не обеспечивается средствами безопасности IPsec.

В то время как транспортный режим используется исключительно для обеспечения безопасной связи между двумя компьютерами, туннельный режим обычно применяется между шлюзами (маршрутизаторами, сетевыми экранами, или отдельными VPN устройствами) для построения VPN (Virtual Private Network).

Следует заметить, что в пакете IPsec нет специального поля «режим»: которое бы позволяло разделить транспортный режим от туннельного, эту функцию выполняет поле следующий заголовок пакета AH.

Когда поле следующий заголовок соответствует IP, это означает, что пакет инкапсулирует всю IP-дейтограмму (туннельный режим), включая независимые адреса отправителя и получателя, которые позволяют реализовать маршрутизацию после туннеля.

Любое другое значение поля (TCP, UDP, ICMP и т.д.) означает транспортный режим (безопасная транспортировка по схеме точка-точка).

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

Заметим, что ЭВМ, в отличие от сетевого шлюза, должна поддерживать как транспортный, так и туннельный режим, но при формировании соединения машина-машина формирование туннеля представляется избыточным.

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

Алгоритмы аутентификации

AH содержит ICV (Integrity Check Value) в аутентификационной части заголовка, и эта контрольная сумма формируется обычно (но не всегда) с помощью стандартного криптографического хэш алгоритма, например, MD5 или SHA-1.

Здесь используется не традиционная контрольная сумма, которая не может предотвратить намеренное искажение содержимого, а алгоритм HMAC (Hashed Message Authentication Code), который при вычислении ICV применяет секретный ключ. Несмотря на то, что хакер может заново вычислить хэш, без секретного ключа он не сможет корректно сформировать ICV. Алгоритм HMAC описан в документе RFC 2104.

Заметим, что IPsec/AH не определяет, какой должна быть аутентификационная функция, вместо этого предоставляются рамки, в которых можно реализовать любую функцию, согласованную отправителем и получателем. Можно использовать для аутентификации цифровую подпись или криптографическую функцию, если оба участника их поддерживают.

AH и NAT

Именно потому, что AH обеспечивает хорошую защиту содержимого пакета, так как этот протокол покрывает все, что только нужно защитить, эта защита приводит к несовместимости с NAT (Network Address Translation).

Протокол NAT используется для установления соответствия между частными IP-адресами (например, 19.125.1.X) и легальными IP. При этом IP заголовок модифицируется устройством NAT путем замены IP-адресов отправителя и получателя.

Когда изменяются IP-адреса, нужно заново вычислить контрольную сумму заголовка. Это нужно сделать в любом случае. Так как устройство NAT обычно размещается в одном шаге между отправителем и получателем это требует, кроме того декрементации значения TTL (Time To Live).

Так как поля TTL и контрольная сумма заголовка всегда модифицируются на пролете, AH знает, что эти поля следует исключить из зоны защиты, но это не касается IP адресов. Адреса включены в область вычисления ICV, и любая модификация вызовет сбой при проверке ICV получателем. Так как вычисление ICV требует знания секретного ключа, который неизвестен промежуточным узлам, маршрутизатор NAT не сможет заново вычислить ICV.

Аналогичная проблема возникает при использовании протокола PAT (Port Address Translation), который устанавливает соответствие нескольких частных IP адресов одному внешнему IP. В этом случае изменяются не только IP-адреса. Но и коды портов в UDP и TCP пакетах (а иногда и в поле данных). Это требует много большей адаптивности со стороны устройства NAT, и более серьезных модификаций всей IP дейтограммы.

По этой причине, протокол AH в туннельном или транспортном режиме полностью несовместим с NAT.

Заметим, что эта трудность не относится к ESP, так как аутентификация и шифрование в этом варианте не охватывает IP заголовок, модифицируемый NAT. Несмотря на это, NAT создает определенные проблемы и для ESP.

Протокол NAT транслирует IP адреса “на пролете” — но он должен отслеживать то, с каким соединением происходит работа, чтобы корректно связывать отклики с источником пакетов. При использовании TCP или UDP, это обычно делается с привлечением номеров порта, но IPsec не оставляет такой возможности.

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

ESP (Encapsulating Security Payload – поле данных безопасной инкапсуляции)

На рис. 5 показан формат заголовка пакета ESP. Первое поле заголовка имеет длину 32 бита и содержит значение индекса параметров безопасности (SPI), которое определяет конкретный набор таких параметров, используемый для данного пакета. За ним следует 32-битовое поле номера по порядку.

Рис. 5. Формат ESP-пакета без аутентификации

Далее размещается поле зашифрованных данных, для выравнивания его длины (+ 2 октета Pad len и Next hdr) до кратного размеру блока шифрования может использоваться поле заполнитель, которое, как и поле данных, может иметь переменную длину. После поля заполнителя размещается хвостовик, содержащий два однооктетных поля: длины заполнителя (Pad len) и кода следующего заголовка (Next hdr). Поле Next hdr характеризует тип поля данных, расположенного выше на рисунке. Протокол ESP требует, чтобы поля Pad len и Next hdr были выровнены по правому полю 32-битового слова. Для решения этой задачи также может использоваться поле заполнитель.

Добавление шифрования делает ESP несколько более сложным, из-за того, что служебные поля ESP окружают поле данных, а не предшествует ему, как это сделано в протоколе AH: ESP включает в себя поля заголовка и хвостовика. Этот протокол предоставляет также туннельный и транспортный режимы обмена.

Документы RFC IPsec не регламентируют конкретный алгоритм шифрования, но допускают использование DES, triple-DES, AES и Blowfish для шифрования поля данных. Алгоритм, используемый для конкретного соединения, специфицируется ассоциацией безопасности SA (рассмотренной ниже), SA включает в себя не только алгоритм, но и используемый ключ.

В отличие от протокола AH, который вводит небольшой заголовок перед полем данных, ESP “окружает” защищаемое поле данных. Поля индекс параметров безопасности (Security Parameters Index) и номер по порядку служат для тех же целей, что и в случае AH, но в ESP имеются также поля заполнителя, следующего заголовка, и опционно аутентификационных данных в конце, в хвостовике ESP (см. рис. 6).

Возможно использование ESP без какого-либо шифрования (чтобы применить NULL алгоритм). Этот режим не обеспечивает конфиденциальности, и его имеет смысл использовать в сочетании с аутентификацией ESP. Неэффективно использовать ESP без шифрования или аутентификации (если только это не делается для тестирования протокола).

Заполнение делается для того, чтобы сделать возможным применение блочных алгоритмов шифрования, длина поля заполнителя определяется значением поля pad len. Поле next hdr определяет тип протокола поля данные (IP, TCP, UDP и т.д.). Следует иметь в виду, что поле данные размещено до этого указателя (см. рис. 6).

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

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

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

ESP в транспортном режиме

Как и в случае AH, транспортный режим предполагает инкапсуляцию поля данных дейтограмм, и протокол ориентирован на обмен машина-машина. Исходный IP заголовок оставлен на месте (за исключением замененного поля протокол), и это означает, что адреса отправителя и получателя также остаются неизмененными.

Структура данных в пакете для протокола ESP в транспортном режиме показана на рис. 6. Жирным контуром выделены аутентификацируемые данные, а закрашенная область отмечает шифруемую часть данных. Поле Next внизу рисунка характеризует тип протокола поля данных, закрашенного на рисунке (в приведенном примере это ТСР).

Рис. 6. Структура данных в пакете для протокола ESP в транспортном режиме

ESP в туннельном режиме

Посмотрим еще раз на ESP в туннельном режиме, когда инкапсулируется вся IP-дейтограмма внутрь зашифрованной оболочки.

Структура данных в пакете для протокола ESP в туннельном режиме показана на рис. 7. Слева на рисунке размешен формат исходной дейтограммы с инкапсулированным ТСР-сегментом. Жирным контуром выделены аутентифицированные данные, а закрашенная область отмечает шифруемую часть данных. Поле Next внизу рисунка характеризует тип протокола данных (на рисунке закрашено, в приведенном примере это IP).

Рис. 7. Структура данных в пакете для протокола ESP в туннельном режиме

Реализация шифрованного соединения в туннельном режиме очень близка к традиционным VPN.

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

Построение VPN

При полном перекрытии аутентификационного заголовка и инкапсулированного поля данных можно построить настоящую VPN (Virtual Private Network). Конечной целью VPN является объединение двух безопасных сетей через небезопасные каналы (например, сети двух отделений компании через Internet). Схема построения VPN показана на рис. 8. Предполагается, что обработка пакетов VPN на входе/выходе локальных сетей осуществляется в сетевых шлюзах (GW). Функции GW могут выполнять и сетевые экраны (Firewall).

Рис. 8. Схема построения VPN

Понятно, что безопасные VPN требуют применения, как аутентификации, так и шифрования. Известно, что ESP является лишь средством обеспечения шифрования, но ESP и AH могут осуществлять аутентификацию.

На рис. 9 показана структура VPN-пакета при использовании протокола ESP и аутентификации.

Рис. 9. Структура VPN-пакета при использовании протокола ESP и аутентификации

Поле Next в данном случае характеризует тип протокольного пакета, размещенного выше на рисунке (тип=IP, закрашенная область).

Очевидным решением является встраивание ESP в AH, что технически возможно, но на практике не используется, из-за ограничений AH в отношении протокола NAT. Применение комбинации AH и ESP не позволит использовать технику NAT.

Вместо этого, комбинация ESP и Auth используется в туннельном режиме при полной инкапсуляции трафика в процессе транспортировки через области сети, где нет гарантии безопасности.

Трафик, защищенный так, не предоставляет перехватчику информации о том, что два сетевых объекта соединены VPN. Эта информация может оказаться атакеру полезной для понимания структуры отношений партнеров. В протоколе ESP даже тип транспортного протокола (TCP, UDP или ICMP) оказывается скрыт от постороннего.

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

Вложение пакет-в-пакет может быть многослойным. ЭВМ A и ЭВМ B могут установить свое аутентифицированное соединение (с помощью протокола AH), и осуществлять маршрутизацию через VPN. Это приведет к тому, что внутренний пакет AH будет помещен внутрь пакета ESP+Auth. Важно использовать аутентификацию даже в случае применения шифрования, так как такое соединение может стать объектом атаки, описанной в http://eprint.iacr.org/2005/416 (Paterson & Yau).

Ассоциации безопасности и SPI

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

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

Параметры безопасности задаются SA (Security Association), которая определяет параметры и процедуры, специфические для конкретного соединения. Каждый партнер может иметь один или более SA. Когда дейтограмма приходит, для нахождения правильного SA в базе данных SADB (Security Associations Database – база данных ассоциаций безопасности) используются три значения:

Во многих отношениях эта тройка может быть уподоблена IP сокету, который однозначно определяется IP адресом удаленного партнера (IPv4 или IPv6), протоколом и номером порта. В перечень компонентов SA входят:

При создании новой SA в счетчик номера по порядку заносится нуль, далее он инкрементируется при посылке каждого пакета. Когда содержимое счетчика достигает значения 232-1, текущая SA аннулируется и должна быть согласована новая ассоциация безопасности и новый ключ.

Так как IP работает без установления соединения и доставка пакетов по порядку не гарантируется, протокол требует, чтобы получатель сформировал скользящее окно с шириной W, например, W=64 пакета. Правый край окна соответствует наибольшему номеру по порядку N для благополучно принятых пакетов. Любой пакет с номером в диапазоне от N-W+1 до N считается принятым корректно. Если полученный пакет оказался по левую границу окна, или его аутентификация потерпела неудачу, то такой пакет отбрасывается. Ниже приведен пример из [1], где длина W=7 (реально это число может достигать 232). Первые две строки показывают состояние окна с началом в позиции 1 и концом в позиции 7, пакет с номером 9 получен, но его подлинность не подтверждена. Буквами П обозначены полученные пакеты с подтвержденной подлинностью, буквами Н – неполученные пакеты; а буквой О, полученный пакет, подлинность которого не подтверждена. Серым цветом отмечено окно W.

Когда подлинность полученного пакета с номером 9 оказалась подтвержденной, правая граница окна смещается на эту позицию и занимает положение, показанное на вторых строках данного примера. В этом состоянии, если придет пакет с номером 1 или 2, они будут отвергнуты. Если же придут пакеты с номерами 5 или 8 они будут подвергнуты обработке, так как находятся в пределах окна W.

Ассоциации безопасности сопрягаются с однонаправленными соединениями, так что для двунаправленной связи требуется как минимум две такие ассоциации. Кроме того, каждый протокол (ESP/AH) имеет свою собственную SA, для каждого из направлений обмена, таким образом, полномасштабная VPN AH+ESP требует наличия четырех ассоциаций безопасности. Все эти данные хранятся в базе данных SADB.

В базе данных SADB содержится:

Некоторые реализации поддерживают SPD (Security Policy Database) со средствами работы из командной строки, другие с GUI, в то время как прочие предоставляют WEB-интерфейс для работы через сеть. Каждая запись в SPD определяется набором значений полей IP и протокола верхнего уровня, называемых селекторами. Эти селекторы используются для фильтрации исходящего трафика, для того чтобы поставить его в соответствие с определенной SA. Обработка исходящих IP-пакетов производится в следующей последовательности.

SPD запись определяется следующими селекторами:

Управление ключами

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

Наиболее простым способом задания этих секретных ключей является ручная конфигурация: один партер генерирует набор ключей и передает ключи другим партерам.

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

Механизм обмена ключами в IKE берется из протокола Oakley (RFC-2412). Основой протокола обмен ключами Oakley является алгоритм Диффи-Хелмана (см. http://book.itep.ru/6/difi_646.htm), дополненный некоторыми усовершенствованиями. В частности в каноническом алгоритме Диффи-Хелмана отсутствует аутентификация партнеров, что допускает возможность атаки с подменом ключей. В IPsec версии алгоритма, аутентификация партнеров является обязательной процедурой.

Заметим, что IPsec осуществляет пересылку ключей через порт 500/udp. В IPsec при обмене ключами предусмотрено использование сертификатов. Для получения сертификата посылается запрос в сертификационный центр СА (Certificate Authority). Сертификация включает в себя следующие операции:

Клиенты могут пользоваться одним и тем же СА или быть клиентами разных СА. На практике обычно реализуется иерархическая структура СА.

В Интернет имеется огромное количество материалов по проблематике IPsec, но начинать всегда лучше с документов RFC (Requests for Comment), которые со временем обретают статус стандартов.

В декабре 2005, весь набор документов RFC по IPsec был обновлен IETF, а серия RFC 43xx по большей части заменила серию RFC 24xx.

Источник