В современном мире различные 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).
Что касается 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.
Двух фаз оказалось недостаточно
Казалось бы, что получается и так не слишком простая схема работы, но на деле все еще чуть сложнее. Со временем стало ясно, что только одного 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).
Первым делом нужно определить наличие IPsec VPN шлюза. Сделать это можно, проведя сканирование портов, но здесь есть небольшая особенность. ISAKMP использует протокол UDP, порт 500, а между тем дефолтное сканирование с помощью Nmap затрагивает только TCP-порты. И в результате будет сообщение: All 1000 scanned ports on 37.59.0.253 are filtered .
Создается впечатление, что все порты фильтруются и как бы открытых портов нет. Но выполнив команду
Nmap -sU --top-ports=20 37.59.0.253 Starting Nmap 6.47 (http://nmap.org) at 2015-03-21 12:29 GMT Nmap scan report for 37.59.0.253 Host is up (0.066s latency). PORT STATE SERVICE 500/udp open isakmp
убеждаемся в том, что это не так и перед нами действительно VPN-устройство.
Атакуем первую фазу
Теперь нас будет интересовать первая фаза, aggressive-режим и аутентификация с использованием pre-shared key (PSK). В этом сценарии, как мы помним, VPN-устройство или отвечающая сторона отправляет хешированный PSK инициатору. Одна из самых известных утилит для тестирования протокола IKE - это ike-scan, она входит в состав дистрибутива Kali Linux. Ike-scan позволяет отправлять IKE сообщения с различными параметрами и, соответственно, декодить и парсить ответные пакеты. Пробуем прощупать целевое устройство:
Root@kali:~# ike-scan -M -A 37.59.0.253 0 returned handshake; 0 returned notify
Ключ -A указывает на то, что нужно использовать aggressive-режим, а -M говорит о том, что результаты следует выводить построчно (multiline), для более удобного чтения. Видно, что никакого результата не было получено. Причина состоит в том, что необходимо указать тот самый идентификатор, имя VPN-группы. Разумеется, утилита ike-scan позволяет задавать этот идентификатор в качестве одного из своих параметров. Но так как пока он нам неизвестен, возьмем произвольное значение, например 0000.
Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Aggressive Mode Handshake returned
В этот раз видим, что ответ был получен (см. рис. 5) и нам было предоставлено довольно много полезной информации. Достаточно важная часть полученной информации - это transform-set. В нашем случае там указано, что «Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK».
Все эти параметры можно указывать и для утилиты ike-scan с помощью ключа --trans . Например --trans=5,2,1,2 будет говорить о том, что алгоритм шифрования 3DES, хеширование HMAC-SHA, метод аутентификации PSK и второй тип группы DH (1024-bit MODP). Посмотреть таблицы соответствия значений можно по этому адресу . Добавим еще один ключ (-P), для того чтобы вывести непосредственно пейлоад пакета, а точнее хеш PSK.
Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P
Преодолеваем первые сложности
Казалось бы, хеш получен и можно пробовать его брутить, но все не так просто. Когда-то очень давно, в 2005 году, на некоторых железках Сisco была уязвимость: эти устройства отдавали хеш, только если атакующий передавал корректное значение ID. Сейчас, естественно, встретить такое оборудование практически невозможно и хешированное значение присылается всегда, независимо от того, правильное значение ID отправил атакующий или нет. Очевидно, что брутить неправильный хеш бессмысленно. Поэтому первая задача - это определить корректное значение ID, чтобы получить правильный хеш. И в этом нам поможет недавно обнаруженная уязвимость. Дело в том, что существует небольшая разница между ответами во время начального обмена сообщениями. Если кратко, то при использовании правильного имени группы происходит четыре попытки продолжить установление VPN-соединения плюс два зашифрованных пакета второй фазы. В то время как в случае неправильного ID в ответ прилетает всего лишь два пакета. Как видим, разница достаточно существенная, поэтому компания SpiderLabs (автор не менее интересного инструмента Responder) разработала сначала PoC, а затем и утилиту IKEForce для эксплуатации этой уязвимости.
В чем сила IKE
Установить IKEForce в произвольный каталог можно, выполнив команду
Git clone https://github.com/SpiderLabs/ikeforce
Работает она в двух основных режимах - режиме вычисления -e (enumeration) и режиме брутфорса -b (bruteforce). До второго мы еще дойдем, когда будем смотреть атаки на второй фактор, а вот первым сейчас и займемся. Перед тем как начать непосредственно процесс определения ID, необходимо установить точное значение transform-set. Мы его уже определили ранее, поэтому будем указывать опцией -t 5 2 1 2 . В итоге выглядеть процесс нахождения ID будет следующим образом:
Python ikeforce.py 37.59.0.253 -e -w wordlists/group.txt -t 5 2 1 2
В результате достаточно быстро удалось получить корректное значение ID (рис. 7). Первый шаг пройден, можно двигаться дальше.
Получаем PSK
Теперь необходимо, используя правильное имя группы, сохранить PSK-хеш в файл, сделать это можно с помощью ike-scan:
Ike-scan -M -A --id=vpn 37.59.0.253 -Pkey.psk
И теперь, когда правильное значение ID было подобрано и удалось получить корректный хеш PSK, мы можем наконец-то начать офлайн-брутфорс. Вариантов такого брутфорса достаточно много - это и классическая утилита psk-crack, и John the Ripper (с jumbo-патчем), и даже oclHashcat, который, как известно, позволяет задействовать мощь GPU. Для простоты будем использовать psk-crack, который поддерживает как прямой брутфорс, так и атаку по словарю:
Psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk
Но даже успешно восстановить PSK (см. рис. 8) - это только половина дела. На этом этапе нужно вспомнить про то, что дальше нас ждет XAUTH и второй фактор IPsec VPN.
Расправляемся со вторым фактором IPsec
Итак, напомню, что XAUTH - это дополнительная защита, второй фактор аутентификации, и находится он на фазе 1.5. Вариантов XAUTH может быть несколько - это и проверка по протоколу RADIUS, и одноразовые пароли (OTP), и обычная локальная база пользователей. Мы остановимся на стандартной ситуации, когда для проверки второго фактора используется локальная база пользователей. До недавнего времени не существовало инструмента в публичном доступе для брутфорса XAUTH. Но с появлением IKEForce эта задача получила достойное решение. Запускается брутфорс XAUTH достаточно просто:
Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]Program started in XAUTH Brute Force Mode [+]Single user provided - brute forcing passwords for user: admin [*]XAUTH Authentication Successful! Username: admin Password: cisco
При этом указываются все найденные ранее значения: ID (ключ -i), восстановленный PSK (ключ -k) и предполагаемый логин (ключ -u). IKEForce поддерживает как грубый перебор логина, так и перебор по списку логинов, который может быть задан параметром -U . На случай возможных блокировок подбора есть опция -s , позволяющая снизить скорость брутфорса. К слову, в комплекте с утилитой идут несколько неплохих словарей, особенно полезных для установления значения параметра ID.
Входим во внутреннюю сеть
Теперь, когда у нас есть все данные, остается последний шаг - собственно проникновение в локальную сеть. Для этого нам понадобится какой-нибудь VPN-клиент, которых великое множество. Но в случае Kali можно без проблем воспользоваться уже предустановленным - VPNC. Для того чтобы он заработал, нужно подкорректировать один конфигурационный файл - /etc/vpnc/vpn.conf . Если его нет, то нужно создать и заполнить ряд очевидных параметров:
IPSec gateway 37.59.0.253 IPSec ID vpn IPSec secret cisco123 IKE Authmode psk Xauth Username admin Xauth password cisco
Здесь мы видим, что были использованы абсолютно все найденные на предыдущих шагах данные - значение ID, PSK, логин и пароль второго фактора. После чего само подключение происходит одной командой:
Root@kali:~# vpnc vpn
Отключение тоже достаточно простое:
Root@kali:~# vpnc-disconnect
Проверить работоспособность подключения можно, используя команду ifconfig tun0 .
Как построить надежную защиту
Защита от рассмотренных сегодня атак должна быть комплексной: нужно вовремя устанавливать патчи, использовать стойкие pre-shared ключи, которые по возможности вовсе должны быть заменены на цифровые сертификаты. Парольная политика и другие очевидные элементы ИБ также играют свою немаловажную роль в деле обеспечения безопасности. Нельзя не отметить и тот факт, что ситуация постепенно меняется, и со временем останется только IKEv2.
Что в итоге
Мы рассмотрели процесс аудита RA IPsec VPN во всех подробностях. Да, безусловно, задача эта далеко не тривиальна. Нужно проделать немало шагов, и на каждом из них могут поджидать трудности, но зато в случае успеха результат более чем впечатляющий. Получение доступа к внутренним ресурсам сети открывает широчайший простор для дальнейших действий. Поэтому тем, кто ответствен за защиту сетевого периметра, необходимо не рассчитывать на готовые дефолтные шаблоны, а тщательно продумывать каждый слой безопасности. Ну а для тех, кто проводит пентесты, обнаруженный пятисотый порт UDP - это повод провести глубокий анализ защищенности IPsec VPN и, возможно, получить неплохие результаты.
краткая историческая справка появления протокола
В 1994 году Совет по архитектуре Интернет (IAB) выпустил отчет "Безопасность архитектуры Интернет". В этом документе описывались основные области применения дополнительных средств безопасности в сети Интернет, а именно защита от несанкционированного мониторинга, подмены пакетов и управления потоками данных. В числе первоочередных и наиболее важных защитных мер указывалась необходимость разработки концепции и основных механизмов обеспечения целостности и конфиденциальности потоков данных. Поскольку изменение базовых протоколов семейства TCP/IP вызвало бы полную перестройку сети Интернет, была поставлена задача обеспечения безопасности информационного обмена в открытых телекоммуникационных сетях на базе существующих протоколов. Таким образом, начала создаваться спецификация Secure IP, дополнительная по отношению к протоколам IPv4 и IPv6.
архитектура IPSec
IP Security - это комплект протоколов, касающихся вопросов шифрования, аутентификации и обеспечения защиты при транспортировке IP-пакетов; в его состав сейчас входят почти 20 предложений по стандартам и 18 RFC.
Спецификация IP Security (известная сегодня как IPsec) разрабатывается рабочей группой IP Security Protocol IETF. Первоначально IPsec включал в себя 3 алгоритмо-независимые базовые спецификации, опубликованные в качестве RFC-документов "Архитектура безопасности IP", "Аутентифицирующий заголовок (AH)", "Инкапсуляция зашифрованных данных (ESP)" (RFC1825, 1826 и 1827). Необходимо заметить, что в ноябре 1998 года Рабочая группа IP Security Protocol предложила новые версии этих спецификаций, имеющие в настоящее время статус предварительных стандартов, это RFC2401 - RFC2412. Отметим, что RFC1825-27 на протяжении уже нескольких лет считаются устаревшими и реально не используются. Кроме этого, существуют несколько алгоритмо-зависимых спецификаций, использующих протоколы MD5, SHA, DES.
Рис.1. Архитектура IPSec
Рабочая группа IP Security Protocol разрабатывает также и протоколы управления ключевой информацией. В задачу этой группы входит разработка Internet Key Management Protocol (IKMP), протокола управления ключами прикладного уровня, не зависящего от используемых протоколов обеспечения безопасности. В настоящее время рассматриваются концепции управления ключами с использованием спецификации Internet Security Association and Key Management Protocol (ISAKMP) и протокола Oakley Key Determination Protocol. Спецификация ISAKMP описывает механизмы согласования атрибутов используемых протоколов, в то время как протокол Oakley позволяет устанавливать сессионные ключи на компьютеры сети Интернет. Ранее рассматривались также возможности использования механизмов управления ключами протокола SKIP, однако сейчас такие возможности реально практически нигде не используются. Создаваемые стандарты управления ключевой информацией, возможно, будут поддерживать Центры распределения ключей, аналогичные используемым в системе Kerberos. Протоколами ключевого управления для IPSec на основе Kerberos сейчас занимается относительно новая рабочая группа KINK (Kerberized Internet Negotiation of Keys).
Гарантии целостности и конфиденциальности данных в спецификации IPsec обеспечиваются за счет использования механизмов аутентификации и шифрования соответственно. Последние, в свою очередь, основаны на предварительном согласовании сторонами информационного обмена т.н. "контекста безопасности" - применяемых криптографических алгоритмов, алгоритмов управления ключевой информацией и их параметров. Спецификация IPsec предусматривает возможность поддержки сторонами информационного обмена различных протоколов и параметров аутентификации и шифрования пакетов данных, а также различных схем распределения ключей. При этом результатом согласования контекста безопасности является установление индекса параметров безопасности (SPI), представляющего собой указатель на определенный элемент внутренней структуры стороны информационного обмена, описывающей возможные наборы параметров безопасности.
По сути, IPSec, который станет составной частью IPv6, работает на третьем уровне, т. е. на сетевом уровне. В результате передаваемые IP-пакеты будут защищены прозрачным для сетевых приложений и инфраструктуры образом. В отличие от SSL (Secure Socket Layer), который работает на четвертом (т. е. транспортном) уровне и теснее связан с более высокими уровнями модели OSI, IPSec призван обеспечить низкоуровневую защиту.
Рис.2. Модель OSI/ISO
К IP-данным, готовым к передаче по виртуальной частной сети, IPSec добавляет заголовок для идентификации защищенных пакетов. Перед передачей по Internet эти пакеты инкапсулируются в другие IP-пакеты. IPSec поддерживает несколько типов шифрования, в том числе Data Encryption Standard (DES) и Message Digest 5 (MD5).
Чтобы установить защищенное соединение, оба участника сеанса должны иметь возможность быстро согласовать параметры защиты, такие как алгоритмы аутентификации и ключи. IPSec поддерживает два типа схем управления ключами, с помощью которых участники могут согласовать параметры сеанса. Эта двойная поддержка в свое время вызвала определенные трения в IETF Working Group.
С текущей версией IP, IPv4, могут быть использованы или Internet Secure Association Key Management Protocol (ISAKMP), или Simple Key Management for Internet Protocol. С новой версией IP, IPv6, придется использовать ISAKMP, известный сейчас как IKE, хотя не исключается возможность использования SKIP. Однако, следует иметь в виду, что SKIP уже давно не рассматривается как кандидат управления ключами, и был исключен из списка возможных кандидатов еще в 1997 г.
заголовки AH и ESP
аутентифицирующий заголовок AH
Аутентифицирующий заголовок (AH) является обычным опциональным заголовком и, как правило, располагается между основным заголовком пакета IP и полем данных. Наличие AH никак не влияет на процесс передачи информации транспортного и более высокого уровней. Основным и единственным назначением AH является обеспечение защиты от атак, связанных с несанкционированным изменением содержимого пакета, и в том числе от подмены исходного адреса сетевого уровня. Протоколы более высокого уровня должны быть модифицированы в целях осуществления проверки аутентичности полученных данных.
Формат AH достаточно прост и состоит из 96-битового заголовка и данных переменной длины, состоящих из 32-битовых слов. Названия полей достаточно ясно отражают их содержимое: Next Header указывает на следующий заголовок, Payload Len представляет длину пакета, SPI является указателем на контекст безопасности и Sequence Number Field содержит последовательный номер пакета.
Рис.3. Формат заголовка AH
Последовательный номер пакета был введен в AH в 1997 году в ходе процесса пересмотра спецификации IPsec. Значение этого поля формируется отправителем и служит для защиты от атак, связанных с повторным использованием данных процесса аутентификации. Поскольку сеть Интернет не гарантирует порядок доставки пакетов, получатель должен хранить информацию о максимальном последовательном номере пакета, прошедшего успешную аутентификацию, и о получении некоторого числа пакетов, содержащих предыдущие последовательные номера (обычно это число равно 64).
В отличие от алгоритмов вычисления контрольной суммы, применяемых в протоколах передачи информации по коммутируемым линиям связи или по каналам локальных сетей и ориентированных на исправление случайных ошибок среды передачи, механизмы обеспечения целостности данных в открытых телекоммуникационных сетях должны иметь средства защиты от внесения целенаправленных изменений. Одним из таких механизмов является специальное применение алгоритма MD5: в процессе формирования AH последовательно вычисляется хэш-функция от объединения самого пакета и некоторого предварительно согласованного ключа, а затем от объединения полученного результата и преобразованного ключа. Данный механизм применяется по умолчанию в целях обеспечения всех реализаций IPv6, по крайней мере, одним общим алгоритмом, не подверженным экспортным ограничениям.
инкапсуляция зашифрованных данных ESP
В случае использования инкапсуляции зашифрованных данных заголовок ESP является последним в ряду опциональных заголовков, "видимых" в пакете. Поскольку основной целью ESP является обеспечение конфиденциальности данных, разные виды информации могут требовать применения существенно различных алгоритмов шифрования. Следовательно, формат ESP может претерпевать значительные изменения в зависимости от используемых криптографических алгоритмов. Тем не менее, можно выделить следующие обязательные поля: SPI, указывающее на контекст безопасности и Sequence Number Field, содержащее последовательный номер пакета. Поле "ESP Authentication Data" (контрольная сумма), не является обязательным в заголовке ESP. Получатель пакета ESP расшифровывает ESP заголовок и использует параметры и данные применяемого алгоритма шифрования для декодирования информации транспортного уровня.
Рис.4. Формат заголовка ESP
Различают два режима применения ESP и AH (а также их комбинации) - транспортный и туннельный:
Транспортный режим используется для шифрования поля данных IP пакета, содержащего протоколы транспортного уровня (TCP, UDP, ICMP), которое, в свою очередь, содержит информацию прикладных служб. Примером применения транспортного режима является передача электронной почты. Все промежуточные узлы на маршруте пакета от отправителя к получателю используют только открытую информацию сетевого уровня и, возможно, некоторые опциональные заголовки пакета (в IPv6). Недостатком транспортного режима является отсутствие механизмов скрытия конкретных отправителя и получателя пакета, а также возможность проведения анализа трафика. Результатом такого анализа может стать информация об объемах и направлениях передачи информации, области интересов абонентов, расположение руководителей.
Туннельный режим предполагает шифрование всего пакета, включая заголовок сетевого уровня. Туннельный режим применяется в случае необходимости скрытия информационного обмена организации с внешним миром. При этом, адресные поля заголовка сетевого уровня пакета, использующего туннельный режим, заполняются межсетевым экраном организации и не содержат информации о конкретном отправителе пакета. При передаче информации из внешнего мира в локальную сеть организации в качестве адреса назначения используется сетевой адрес межсетевого экрана. После расшифровки межсетевым экраном начального заголовка сетевого уровня пакет направляется получателю.
Security Associations
Security Association (SA) - это соединение, которое предоставляет службы обеспечения безопасности трафика, который передается через него. Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA.
политика безопасности
Политика безопасности хранится в SPD (База данных политики безопасности). SPD может указать для пакета данных одно из трех действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA.
SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета. Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные SA будут использоваться для каждого приложения, или даже для каждого TCP соединения.
протокол ISAKMP/Oakley
Протокол ISAKMP определяет общую структуру протоколов, которые используются для установления SA и для выполнения других функций управления ключами. ISAKMP поддерживает несколько Областей Интерпретации (DOI), одной из которых является IPSec-DOI. ISAKMP не определяет законченный протокол, а предоставляет "строительные блоки" для различных DOI и протоколов обмена ключами.
Протокол Oakley - это протокол определения ключа, использующий алгоритм замены ключа Диффи-Хеллмана. Протокол Oakley поддерживает идеальную прямую безопасность (Perfect Forward Secrecy, PFS). Наличие PFS означает невозможность расшифровки всего траффика при компрометации любого ключа в системе.
протокол IKE ipad = байт 0x36, повторенный B раз; Для вычисления HMAC от данных "text" необходимо выполнить следующую операцию: H(K XOR opad, H(K XOR ipad, text)) Из описания следует, что IKE использует для аутентификации сторон HASH величины. Отметим, что под HASH в данном случае подразумевается исключительно название Payload в ISAKMP, и это название не имеет ничего общего со своим содержимым. атаки на AH, ESP и IKE Как известно, это атака, от которой не существует полной защиты. Тем не менее, быстрая отбраковка плохих пакетов и отсутствие какой-либо внешней реакции на них (согласно RFC) позволяют более-менее хорошо справляться с этой атакой. В принципе, большинству (если не всем) известным сетевым атакам (sniffing, spoofing, hijacking и т.п.) AH и ESP при правильном их применении успешно противостоят. С IKE несколько сложнее. Протокол очень сложный, тяжел для анализа. Кроме того, в силу опечаток (в формуле вычисления HASH_R) при его написании и не совсем удачных решений (тот же HASH_R и HASH_I) он содержит несколько потенциальных "дыр" (в частности, в первой фазе не все Payload в сообщении аутентифицируются), впрочем, они не очень серьезные и ведут, максимум, к отказу в установлении соединения.От атак типа replay, spoofing, sniffing, hijacking IKE более-менее успешно защищается. С криптографией несколько сложнее, - она не вынесена, как в AH и ESP, отдельно, а реализована в самом протоколе. Тем не менее, при использовании стойких алгоритмов и примитивов (PRF), проблем быть не должно. В какой-то степени можно рассматривать как слабость IPsec то, что в качестве единственного обязательного к реализации криптоалгоритма в нынешних спецификациях указывается DES (это справедливо и для ESP, и для IKE), 56 бит ключа которого уже не считаются достаточными. Тем не менее, это чисто формальная слабость - сами спецификации являются алгоритмо-независимыми, и практически все известные вендоры давно реализовали 3DES (а некоторые уже и AES).Таким образом, при правильной реализации, наиболее "опасной" атакой остается Denial-Of-Service. оценка протокола IPSec IPsec представляет из себя не один протокол, а систему протоколов предназначенную для защиты данных на сетевом уровне IP-сетей. В данной статье будет описан теория применения IPsec для создания VPN туннеля.
VPN основанный на технологии IPsec можно разделить на две части: Первая часть (IKE) является фазой согласования, во время которой две VPN-точки выбирают какие методы будут использоваться для защиты IP трафика посылаемого между ними. Помимо этого IKE также используется для управления соединениями, для этого вводится понятие Security Associations (SA) для каждого соединения. SA направлены только в одну сторону, поэтому типичное IPsec соединение использует два SA. Вторая часть – это те IP данные, которые необходимо зашифровать и аутентифицировать перед передачей методами, согласованными в первой части (IKE). Существуют разные протоколы IPsec, которые могут быть использованы: AH, ESP или оба. Последовательность установления VPN через IPsec можно кратко описать как: Для шифрования и аутентификации данных требуется выбрать способ шифрования/аутентификации (алгоритм) и ключи используемые в них. Задача Internet Key Exchange protocol, IKE, в этом случае сводится к распространению данных “ключей сессии” и согласованию алгоритмов, которыми будут защищаться данные между VPN-точками. Основные задачи IKE: IKE ведет учет соединений путем назначения каждому из них некого Security Associations, SA. SA описывает параметры конкретного соединения, включая IPsec протокол (AH/ESP или оба), ключи сессии, используемые для шифрования/дешифрования и/или аутентификации данных. SA является однонаправленной, поэтому используется несколько SA на одно соединение. В большинстве случаев, когда используется только ESP или AH, создаются только две SA для каждого из подключений, одна для входящего трафика, а вторая для исходящего. Когда ESP и AH используются вместе, SA требуется четыре. Процесс согласования IKE проходит через несколько этапов (фаз). Данные фазы включают: Соединения IKE и IPsec ограничены по продолжительности (в секундах) и по кол-ву переданных данных (в килобайтах). Это сделано для повышения защищенности. Для согласования IKE вводится понятие IKE предложение (IKE Proposal) – это предложение того, как защитить данные. VPN-точка инициализирующая IPsec подключение отправляет список (предложение) в котором указаны разные методы защиты подключения. IKE первой фазы – согласование защиты IKE (ISAKMP Tunnel)
IKE второй фазы – согласование защиты IPsec
Если используется механизм Perfect Forwarding Secrecy (PFS)
, то для каждого согласования второй фазы будет использоваться новый обмен ключами Диффи-Хеллмана. Несколько снижая скорость работы, данная процедура гарантирует, что ключи сессии не зависимы друг от друга, что повышает защиту, поскольку даже если произойдет компромат одного из ключей, он не сможет быть использован для подбора остальных. Режим работы второй фазы согласования IKE только один, он называется quick mode — быстрый режим. В процессе согласования второй фазы происходит обмен тремя сообщениями. По окончании второй фазы, устанавливается VPN-подключение. Параметры IKE.
Методы аутентификации IKE
IPsec протоколы используются для защиты передаваемых данных. Выбор протокола и его ключей происходит при согласовании IKE. AH предоставляет возможно аутентифицировать передаваемые данные. Для этого используется криптографическая хэш-функция по отношению к данным содержащимся в IP-пакете. Вывод данной функции (хэш) передается вместе с пакетом и позволяет удаленной VPN точке подтвердить целостность оригинального IP-пакета, подтверждая, что он не был изменен по пути. Помимо данных IP-пакета, AH также аутентифицирует часть его заголовка. В режиме транспорта, AH встраивает свой заголовок после оригинального IP пакета. ESP протокол используется для шифрования, для аутентификации или и того, и другого по отношению к IP пакету. В режиме транспорта ESP протокол вставляет свой заголовок после оригинально IP заголовка. Два основных различия между ESP и AH: Работа за NAT (NAT Traversal)
NAT Traversal используется только в том случае, если обе точки поддерживают его. Как только конечные точки определят, что необходим NAT Traversal, согласование IKE перемещаются с порта UDP 500 на порт 4500. Делается это потому, что некоторые устройства некорректно обрабатывают IKE сессию на 500 порту при использовании NAT. Рассмотрим архитектуру семейства протоколов IPSec. Цель данного семейства протоколов состоит в том, чтобы обеспечить различные сервисы безопасности на уровне IP
для протоколов IPv4 и IPv6. Рассмотрим серви-сы безопасности, предоставляемые протоколами IPSec, и использование этих протоколов в сетях ТСР/ IP
. Когда данные сервисы корректно установлены, они не мешают работе пользователей, хостов и других компонентов интернета, которые не применяют данные сервисы безопасности для защиты своего трафика. Эти сервисы являются алгоритмонезависимыми. Это означает возможность добавления новых криптографических алгоритмов без изменения самих протоколов. Например, различные группы пользователей могут использовать различные наборы алгоритмов. Определен стандартный набор алгоритмов по умолчанию для обеспечения интероперабильности во всем интернете. Использование этих алгоритмов совместно с защитой трафика, предоставляемой IPSec, и протоколами управления ключа позволит разработчика систем и приложений обеспечить высокую степень криптографической безопасности. IPSec может быть реализован как в ОС, так и в маршрутизаторе или межсетевом экране. IPSec обеспечивает конфиденциальность
, целостность данных
, управление доступом
и аутентификацию источника данных для IP
-дейтаграмм. Эти сервисы предоставляются с помощью поддержки состояния между источником и получателем IP
-дейтаграмм. Данное состояние определяет конкретные сервисы обеспечения безопасности на уровне дейтаграммы, используемые криптографические алгоритмы для предоставляемых сервисов и ключи для этих алгоритмов. Перечислим основные задачи протоколов IPSec: IPSec предназначен для безопасного взаимодействия с использованием криптографии для протоколов IPv4 и IPv6. Сервисы безопасности включают управление доступом
, целостность
и конфиденциальность
данных и защиту от replay-атак, которая обеспечивается гарантированием целостности некоторой последовательности дейтаграмм. Эти сервисы предоставляются на уровне IP
, обеспечивая защиту для IP
-протокола и протоколов более высокого уровня. IPSec поддерживает две формы целостности: целостность данных
и целостность
определенной последовательности дейтаграмм. Целостность данных
обнаруживает модификацию конкретной IP
-дейтаграммы, безотносительно последовательности дейтаграмм в потоке трафика. Целостность
последовательности дейтаграмм является анти-reply сервисом, с помощью которого определяется получение дубликатов IP
-дейтаграмм. Это отлича-ется от обеспечения целостности соединения, для которого существуют более строгие требования к целостности трафика, а именно, возможность определения потерянных или переупорядоченных сообщений. Рассмотрим выполнение протоколов IPSec, основные компоненты системы и их взаимодействие для обеспечения сервисов безопасности. IPSec выполняется на хосте ( Host
– H) или шлюзе безопасности ( Security
Gateway
– SG), обеспечивая защиту IP
-трафика. Термин " шлюз
безопасности" используется для обозначения маршрутизатора, который реализует IPsec-протоколы. Защита основана на требованиях, определенных в базе данных политики безопасности ( Security Policy
Database
- SPD
), устанавливаемой и поддерживаемой администратором. В общем случае пакеты обрабатываются одним из трех способов, основанных на информации IP
-заголовка и транспортного уровня в соответствии с записями в SPD
. Каждый пакет либо отбрасывается, либо пропускается без обработки, либо обрабатывается в соответствии с записью SPD
для данного пакета. Существует несколько способов реализации IPSec на хосте или совместно с маршрутизатором или межсетевым экраном (для создания шлюза безопасности). Предоставляемые IPSec сервисы по защите трафика реализуются с помощью двух протоколов обеспечения безопасного трафика: Authentication
Header
( AH
) и Encapsulating Security
Payload
( ESP
). Для защиты трафика в IPSec определены следующие протоколы: С трафиком, безопасность
которого обеспечивается IPSec, связано понятие безопасной ассоциации ( Security
Association
– SA
). SA
содержит всю информацию, необходимую для выполнения различных сетевых сервисов безопасности. SA
представляет собой симплексное (однонаправленное) логическое соединение
, создаваемое между двумя конечными точками, для обеспечения безопасности которых используется один из протоколов IPSec. ESP
и АН передают трафик по SA
. Весь трафик, передаваемый по SA
, обрабатывается в соответствии с политикой безопасности, заданной на концах соединения. Опишем различные аспекты управления SA
, определим возможные способы управления политикой безопасности, способы обработки трафика и управления SA
. SA
определяет параметры сервисов безопасности, которые применяются к трафику. В обычном случае при двунаправленном соединении между двумя хостами или между двумя шлюзами безопасности требуется две SA
(по одной на каждое направление). Будем рассматривать SA
только для одноадресных соединений. Определены два режима SA
: режим транспорта и режим туннелирования. Транспортный режим
используется для создания VPN
между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP
-заголовка. В протоколе ESP
транспортный ре-жим SA
обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP
-заголовка. В случае АН защита распространяется также и на отдельные части IP
-заголовка. Другим режимом SA
является режим туннелирования. Если одним из концов соединения является шлюз
безопасности, то по стандартам IPSec SA
обязательно должна выполняться в туннельном режиме, но многие производители допускают в этом случае как туннельный, так и транспортный режимы. Заметим, что когда трафик предназначен для шлюза безопасности, например, в случае ping- или SNMP-команд, шлюз
безопасности рассматривается как хост
, и как правило используется транспортный режим
. Два хоста могут при необходимости устанавливать туннельный режим
. В туннельном режиме добавляется внешний IP
-заголовок, адресами в котором являются шлюзы безопасности. Внутренний IP
-заголовок указывает на конечные
хосты. Заголовок протокола безопасности расположен после внешнего IP
-заголовка и перед внутренним IP
-заголовком. Если АН используется в туннельном режиме, части внешнего IP
-заголовка являются защищенными, как и весь туннелируемый IP
-пакет, т.е. все внутренние заголовки
защищены, как и все протоколы более высокого уровня. Если применяется ESP
, защита обеспечивается только для туннелируемого пакета, а не для внешнего заголовка. Кратко подытожим: Набор реализуемых Посмотрело: 8033 0
Давайте рассмотрим детали технологий, составляющих суть IPSec. Стандарты, используемые в рамках IPSec, являются достаточно сложными для понимания, поэтому в этом разделе мы рассмотрим каждую из составляющих IPSec подробно. Для понимания того что такое IPSEC используйте документ "IPSEC как протокол защиты сетевого трафика", опубликованный ранее на этом сайте. Данная статья является продолжением вышеуказанного документа. В IPSec используются следующие технологии: Протокол ESP обеспечивает конфиденциальность с помощью шифрования на уровне пакетов IP. При этом поддерживается множество алгоритмов симметричной схемы шифрования. Алгоритмом по умолчанию для IPSec является DES с 56-битовым ключом. Этот шифр должен присутствовать для гарантии совместимости между всеми поддерживающими IPSec продуктами. Продукты Cisco поддерживают также алгоритм 3DES, обеспечивающий более стойкое шифрование. Конфиденциальность может быть выбрана независимо от других сервисов. Аутентификация источника данных и поддержка целостности без установления соединений используются совместно и являются опциями (т.е. необязательны). Эти возможности можно также объединить с сервисом конфиденциальности. Шифрование ESP с применением НМАС
В рамках протокола ESP может также обеспечиваться аутентификация пакетов с помощью необязательного поля аутентификации. В программном обеспечении Cisco IOS и в брандмауэрах PIX Firewall этот сервис называется ESP НМАС. Значения аутентификации вычисляются после того, как выполнено шифрование. Используемый сегодня стандарт IPSec описывает алгоритмы SHA1 и MD5 как обязательные для НМАС. Туннельный и транспортный режимы IPSec
IPSec действует или в туннельном, или в транспортном режиме. На рис показана схема реализации туннельного режима. В этом режиме вся исходная дейтаграмма IP шифруется и становится полезным грузом в новом пакете IP с новым заголовком IP и дополнительным заголовком IPSec (на рис. заголовок обозначен аббревиатурой HDR). Туннельный режим позволяет сетевому устройству (например, брандмауэру PIX Firewall) выступать в роли шлюза IPSec или прокси-сервера, выполняющего шифрование для хостов, размещенных за брандмауэром. Маршрутизатор источника шифрует пакет и передает его по туннелю IPSec. Брандмауэр PIX Firewall адресата дешифрует полученный пакет IPSec, извлекает исходную дейтаграмму IP и передает ее системе адресата. Главное преимущество туннельного режима заключается в том, что не требуется модифицировать конечные системы, чтобы обеспечить им возможность использования IPSec. Туннельный режим также не позволяет противнику анализировать поток данных. При обмене в туннельном режиме противник имеет возможность определить только конечные точки туннеля, но не истинных источника и адресата проходящих через туннель пакетов, даже если конечные точки туннеля находятся как раз в системах источника и адресата. Использование туннельного и транспортного режимов
Рассмотрим несколько примеров, иллюстрирующих правила выбора туннельного или транспортного режима. На рис ниже показаны ситуации, в которых используется туннельный режим. Этот режим чаще всего используется для шифрования потока данных между шлюзами защиты IPSec - например, между маршрутизатором Cisco и брандмау эром PIX Firewall. Шлюзы IPSec выполняют функции IPSec для устройств, находящихся за такими шлюзами (на указанном рисунке это персональный компьютер Алисы и серверы HR). В этом примере Алиса получает защищенный доступ к серверам HR через туннель IPSec, установленный между шлюзами. Туннельный режим используется и для связи конечных станций, в которых выполняется программное обеспечение IPSec, например для связи клиента CiscoSecure VPN и шлюза IPSec. Использование АН и ESP
В определенных ситуациях проблема выбора между АН и ESP может показаться сложной для решения, но ее можно упростить, если следовать нескольким правилам. Если вам необходимо знать, что данные из идентифицированного источника передают¬ся без нарушения целостности, а их конфиденциальность обеспечивать не требуется, используйте протокол АН, который защищает протоколы высших уровней и поля заголовка IP, не изменяемые в пути. Защита означает, что соответствующие значения нельзя изменить, потому что это будет обнаружено второй стороной IPSec и любая модифицированная дейтаграмма IP будет отвергнута. Протокол АН не обеспечивает защиту от прослушивания канала и просмотра нарушителем заголовка и данных. Но поскольку заголовок и данные незаметно изменить нельзя, измененные пакеты отвергаются. Если необходимо сохранить данные в тайне (обеспечить конфиденциальность), используйте ESP. Данный протокол предполагает шифрование протоколов высших уровней в транспортном режиме и всей исходной дейтаграммы IP в туннельном режиме, так что извлечь информацию о пакетах путем прослушивания канала передачи невозможно. Протокол ESP может также обеспечить для пакетов сервис аутентификации. Однако при использовании ESP в транспортном режиме внешний оригинальный заголовок IP не защищается, а в туннельном режиме не защищается новый заголовок IP. При использовании IPSec пользователи скорее применят туннельный режим, чем транспортный.
IKE - протокол обмена ключами по умолчанию для ISAKMP, на данный момент являющийся единственным. IKE находится на вершине ISAKMP и выполняет, собственно, установление как ISAKMP SA, так и IPSec SA. IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).
Хэш-функция - это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения m1 и m2, таких, что H(m1)=H(m2), где H - хэш функция.
Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC - механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая хэш функция (обозначим ее как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования - как L (L
opad = байт 0x5C, повторенный B раз.
Все виды атак на компоненты IPSec можно разделить на следующие группы: атаки, эксплуатирующие конечность ресурсов системы (типичный пример - атака "Отказ в обслуживании", Denial-of-service или DOS-атака), атаки, использующие особенности и ошибки конкретной реализации IPSec и, наконец, атаки, основанные на слабостях самих протоколов AH и ESP. Чисто криптографические атаки можно не рассматривать - оба протокола определяют понятие "трансформ", куда скрывают всю криптографию. Если используемый криптоалгоритм стоек, а определенный с ним трансформ не вносит дополнительных слабостей (это не всегда так, поэтому правильнее рассматривать стойкость всей системы - Протокол-Трансформ-Алгоритм), то с этой стороны все нормально. Что остается? Replay Attack - нивелируется за счет использования Sequence Number (в одном единственном случае это не работает - при использовании ESP без аутентификации и без AH). Далее, порядок выполнения действий (сначала шифрация, потом аутентификация) гарантирует быструю отбраковку "плохих" пакетов (более того, согласно последним исследованиям в мире криптографии, именно такой порядок действий наиболее безопасен, обратный порядок в некоторых, правда очень частных случаях, может привести к потенциальным дырам в безопасности; к счастью, ни SSL, ни IKE, ни другие распространенные протоколы с порядком действий "сначала аутентифицировать, потом зашифровать", к этим частным случаям не относятся, и, стало быть, этих дыр не имеют). Остается Denial-Of-Service атака.
Протокол IPSec получил неоднозначную оценку со стороны специалистов. С одной стороны, отмечается, что протокол IPSec является лучшим среди всех других протоколов защиты передаваемых по сети данных, разработанных ранее (включая разработанный Microsoft PPTP). По мнению другой стороны, присутствует чрезмерная сложность и избыточность протокола. Так, Niels Ferguson и Bruce Schneier в своей работе "A Cryptographic Evaluation of IPsec" отмечают, что они обнаружили серьезные проблемы безопасности практически во всех главных компонентах IPsec. Эти авторы также отмечают, что набор протоколов требует серьезной доработки для того, чтобы он обеспечивал хороший уровень безопасности.Введение
IKE, Internet Key Exchange
— Согласовывается защита самого IKE (ISAKMP tunnel)
— Согласовывается защита IPsec
— Получение данных из первой фазы для формирования ключей сессии
Продолжительность IPsec подключения, как правило, короче IKE. Поэтому, когда заканчивается срок IPsec соединения, новое IPsec соединение пересоздается через вторую фазу согласования. Первая фаза согласования используется только при пересоздании IKE подключения.
Переговоры могут вестись как об установлении нового IPsec соединения, так и об установлении нового IKE соединения. В случае IPsec защищаемыми данными является тот трафик, что отправлен чрез VPN-туннель, а в случае IKE защищаемые данные – данные самих согласований IKE.
VPN-точка получившая список (предложение), выбирает из него наиболее подходящее и указывает его в ответе. Если ни одно из предложений не может быть выбрано, VPN шлюз отвечает отказом.
Предложение содержит всю необходимую информацию для выбора алгоритма шифрования и аутентификации и пр.
На первой фазе согласования VPN-точки аутентифицируют друг друга на основе общего ключа (Pre-Shared Key). Для аутентификации используются хэш алгоритм: MD5, SHA-1, SHA-2.
Однако перед тем как аутентифицировать друг друга, чтобы не передавать информацию открытым текстом, VPN-точки выполняют обмен списками предложений (Proposals), описанный ранее. Только после того как устраивающее обеих VPN-точек предложение выбрано, происходит аутентификация VPN-точка друг друга.
Аутентификацию можно осуществлять разными способами: через общие ключи (Pre-Shared Keys), сертификаты или . Общие ключи являются наиболее распространенным способом аутентификации.
Согласование IKE первой фазы может происходить в одном из двух режимов: main (основной) и aggressive (агресивный). Основной режим более длительный, но зато и более защищенный. В его процесее происходит обмен шестью сообщениями. Агресивный режим происходит быстрее, ограничиваясь тремя сообщениями.
Основная работа первой фазы IKE лежит в обмене ключами Диффи-Хеллмана. Он основан на шифровании с открытым ключем, каждая из сторон шифрует аутентификационный параметр (Pre-Shared Key) открытым ключем соседа, который получив данное сообщение расшифровывает его своим закрытым ключем. Другой способо аутентификации сторон друг друга — использование сертификатов.
Во второй фазе осуществляется выбор способа защиты IPsec подключения.
Для работы второй фазы используется материал (keying material) извлеченный из обмена ключами Диффи-Хеллмана (Diffie-Hellman key exchange), произошедшего на первой фазе. На основе этого материала создаются ключи сессии (session keys), использующиеся для защиты данных в VPN-туннеле.
Во время установления соединения используются несколько параметров, без согласования которых невозможно установить VPN-подключение.
Каким образом узлы аутентифицируют друг друга. Наиболее часто используется общий ключ. Аутентификация основанная на общем ключе использует алгоритм Диффи-Хеллмана.
Определяет трафик, который будет пускаться через VPN-туннель.
IPsec может работать в двух режимах: туннельном и транспортном. Выбор режима зависит от защищаемых объектов.
Туннельный режим
применяется для защиты между удаленными объектами, т.е. IP-пакет полностью инкапсулируется в новый и для наблюдателя со стороны будет видно только соединение между двумя VPN-точками. Реальные IP-адреса источника и получателя будут видны только после декапсуляции пакета при приеме его на VPN-точке получения. Таким образом туннельный режим чаще всего используется для VPN-подключений.
Транспортный режим
защищает данные IP-пакета (TCP, UDP и протоколы верхних уровней), а сам заголовок оригинального IP-пакета будет сохранен. Таким образом для наблюдателя будет виден оригинальный источник и назначение, но не передаваемые данные. Данный режим наиболее часто используется при защите соединение в локальной сети между хостами.
VPN-точка получатель защищенного соединения, которая будет расшифровывать/аутентифицировать данные с другой стороны и отправлять их к окончательному месту назначения.
IKE согласование может работать в двух режимах: основной
и агрессивном
.
Разница между ними заключается в том, что в агрессивном режиме используется меньшее кол-во пакетом, что позволяет достичь более быстрого установления соединения. С другой стороны агрессивный режим не передает некоторые параметры согласования, такие как Диффи-Хеллман группы и PFS, что требует предварительной идентичной настройки их на точках участницах подключения.
Существует два протокола IPsec: Authentication Header (AH) и Encapsulating Security Payload (ESP), которые выполняют функции шифрования и аутентификации.
ESP позволяет шифровать, аутентифицировать по отдельности или одновременно.
AH позволяет только аутентифицировать. Разница с ESP аутентификацией в том, что AH аутентифицирует также и внешний IP заголовок, позволяя подтвердить, что пакет прибыл действительно от источника указанного в нем.
Указывает используемый алгоритм шифрования IKE и его ключи. Поддерживаются разные симметричные алгоритмы шифрования, например: DES, 3DES, AES.
Алгоритм аутентификации используемый в IKE согласовании. Могут быть: SHA, MD5.
Используемая DF группа для обмена ключами в IKE. Чем больше группа тем больше размер ключей обмена.
Указывается как по времени (секундах), так и по размеру переданных данных (килобайтах). Как только один из счетчиков достигнет порогового значения запускается новая первая фаза. Если с момента создания IKE соединения не было передано никаких данных, никаких новых подключений не будет создано до тех пор, пока одна из сторон не захочет создать VPN соединение.
При отключенном PFS материал для создания ключей будет извлечен в первой фазе согласования IKE в момент обмена ключей. Во второй фазе согласования IKE ключи сессии будут созданы основываясь на полученном материале. При включенном PFS при создании новых ключей сессии материал для них будет использоваться каждый раз новый. Таким образом при компромате ключа, на основе него не возможно создать новые ключи.
PFS может быть использован в двух режимах: первый PFS на ключах (PFS on keys), будет запускать новый обмен ключами в первой фазе IKE каждый раз, когда запускается согласование
второй фазы. Второй режим PFS на идентификаторах (PFS on identities), будет удалять SA первой фазы каждый раз, после прохождения согласования второй фазы, гарантируя тем самым, что ни одно согласование второй фазы не будет зашифровано идентичным предыдущему ключом.
Данные DF группы аналогичны использующимся в IKE, только используются для PFS.
Алгоритм использующийся для шифрования данных. Используется в случае использования ESP в режиме шифрования. Пример алгоритмов: DES, 3DES, AES.
Алгоритм используемый для аутентификации передаваемых данных. Используется в случае AH или ESP в режиме аутентификации. Пример алгоритмов: SHA, MD5.
Время жизни VPN соединения указывается как по времени (секундах) так и по размеру переданных данных (килобайты). Счетчик первым достигнувший лимита запустит пересоздание ключей сессии. Если с момента создания IKE соединения не было передано никаких данных, никаких новых подключений не будет создано до тех пор, пока одна из сторон не захочет создать VPN соединение.
Самый простой из методов, при котором IKE не используется, а ключи аутентификации и шифрования, а также некоторые другие параметры задаются в ручную на обоих точках VPN подключения.
Заранее введенный общий ключ на обоих точках VPN соединения. Отличие от предыдущего метода в том, что используется IKE, что позволяет аутентифицировать конечные точки и использовать меняющиеся ключи сессии, вместо фиксированных ключей шифрования.
Каждая точка VPN использует: свой приватный ключ, свой открытый ключ, свой сертификат включающий свой открытый ключ и подписанный доверенным центром сертификации. В отличие от предыдущего метода позволяет избежать ввода одного общего ключа на всех точках VPN соединения, заменяя его личными сертификатами, подписанными доверенным центром.Протоколы IPsec
AH (Authentication Header)
В режиме туннеля AH встраивает свой заголовок после внешнего (нового) IP-заголовка и перед внутренним (оригинальным) IP заголовком.ESP (Encapsulating Security Payload)
В режиме туннеля ESP заголовок находится после внешнего (нового) IP заголовка и перед внутренним (оригинальным).
Для поддержки работы за NAT была реализована отдельная спецификация. Если VPN-точка поддерживает данную спецификацию, IPsec поддерживает работу за NAT, однако существуют определённые требования.
Поддержка NAT состоит из двух частей:
Определение NAT
: обе VPN-точки посылают хеши своих IP адресов вместе с UDP портом источника IKE согласования. Данная информация используется получателем, для того чтобы определить был ли изменен IP адрес и/или порт источника. Если данные параметры не были изменены, то трафик не проходит через NAT и механизм NAT Traversal не нужен. Если адрес или порт были изменены, значит между устройствами находится NAT.
Другая проблема возникает из-за того, что ESP протокол – протокол транспортного уровня и располагается непосредственно поверх IP. Из-за этого к нему не применимы понятия TCP/UDP порта, что делает невозможным подключение через NAT более одного клиента к одному шлюзу. Для решения данной проблемы ESP запаковывается в UDP дейтаграмму и посылается на порт 4500, тот же самый, который использует IKE при включенном NAT Traversal.
NAT Traversal встроен в работу протоколов, его поддерживающих и работает без предварительной настройки.Возможные способы реализации IPSec
Протоколы защиты трафика и понятие безопасной ассоциации
Протокол АН
Данный протокол обеспечивает аутентификацию и целостность данных для пакетов IP, передаваемых между двумя системами. Протокол АН не
обеспечивает конфиденциальность (т.е. шифрование) пакетов. Аутентификация выполняется путем применения к пакету односторонней, зависящей от ключа функции хэширования, генерирующей "профиль" сообщения. Изменение любой части пакета в пути передачи будет обнаружено получателем в результате применения к полученным данным аналогичной односторонней функции хэширования и сравнения вычисленного значения профиля сообщения с тем, которое указал отправитель. Аутентичность полученной информации гарантируется тем, что для одностороннего хэширования обеими системами используется один и тот же секретный ключ. Схема работы протокола АН пока¬зана ниже. При этом выполняются следующие действия.
Протокол АН обеспечивает аутентификацию для максимально возможного числа полей заголовка IP, как и для полей данных протоколов высших уровней. Однако некоторые поля заголовка IP могут изменяться в пути. Значения изменяемых полей (например, поля TTL, указывающего время существования пакета) изменяются промежуточными сетевыми устройствами, через которые проходит пакет, и такие изменения отправитель прогнозировать не может. Значения изменяемых полей не должны защищаться протоколом АН. Таким образом, защита, которая обеспечивается заголовку IP протоколом АН, оказывается несколько ограниченной. Протокол АН может также дополнительно обеспечить защиту от воспроизведения пакетов, для чего в заголовке IP указывается порядковый номер пакета. Полное описание протокола АН со¬держится в документе RFC 2402.Протокол ESP
ESP является протоколом защиты, обеспечивающим конфиденциальность (т.е. шифрование), аутентификацию источника и целостность данных, а также (в качестве опции) сервис защиты от воспроизведения и ограниченную конфиденциальность трафика путем противодействия попыткам анализа потока данных.
Сервис защиты от воспроизведения можно выбрать только в том случае, если выбрана аутентификация источника данных, и выбор этого сервиса является исключительной прерогативой получателя. Хотя по умолчанию от отправителя и требуется ав¬томатически увеличивать порядковый номер, используемый для защиты от воспроизведения, этот сервис оказывается эффективным только в том случае, если получатель проверяет этот порядковый номер. Конфиденциальность трафика требует выбора тун¬нельного режима. Наиболее эффективным это оказывается в шлюзе защиты, где маскировка источника-адресата может быть выполнена сразу для всего трафика. Здесь следует отметить, что хотя и конфиденциальность, и аутентификация являются опциями, должен быть выбран по крайней мере один из этих сервисов.
Набор сервисов, обеспечиваемых протоколом ESP, зависит от параметров, которые указываются в конфигурации IPSec и выбираются при создании ассоциации защиты IPSec. Однако выбор конфиденциальности без целостности/аутентификации (или в рамках ESP, или отдельно с помощью АН) оставляет противнику возможность для проведения атак определенного вида, что может ограничить пользу применяемого та¬ким образом сервиса конфиденциальности.
Заголовок ESP вставляется в пакет после заголовка IP перед заголовком протокола высшего уровня (в транспортном режиме) или перед инкапсулированным заголовком IP (в туннельном режиме). Полное описание протокола ESP содержится в документе RFC 2406.
Главное различие между аутентификацией ESP и аутентификацией АН заключается в области их охвата. ESP не защищает никаких полей заголовка IP, если только не предполагается инкапсуляция ESP (туннельный режим). На рис указано, какие поля защищаются при использовании ESP НМАС. 
Обратите внимание на то, что шифрование охватывает только данные полезного груза, a ESP с хэшированием ESP НМАС - заголовок ESP и данные полезного груза. Заголовок IP не защищается. Сервис ESP НМАС не может использоваться самостоя¬тельно, а должен быть объединен с протоколом шифрования ESP.
Схема на рис ниже иллюстрирует транспортный режим. Здесь шифруется только полезный груз IP, а исходный заголовок IP остается нетронутым.
Добавляется заголовок IPSec. Преимуществом этого режима является добавление только нескольких байтов к каждому пакету. Кроме того, устройства открытой сети могут видеть истинные адреса отправителя и получателя пакета. 
Это позволяет использовать специальные возможности промежуточных сетей (например, гарантированное качество сервиса), основанные на информации в заголовке IP. Однако заголовок уровня 4 шифруется, что ограничивает возможности анализа пакета. К сожалению, передача заголовка IP в открытом виде в транспортном режиме позволяет нарушителю в определенной мере выполнить анализ потока данных. Например, нарушитель может выяснить, сколько пакетов было передано сторонами IPSec, действующими в транспортном режиме. Но нарушитель может узнать только о том, что пакеты IP пересылались. Он не сможет определить, были ли они сообщением электронной почты или каким-то другим приложением, если использовался протокол ESP.
В данном примере туннельный режим применяется для создания туннеля IPSec между маршрутизатором Cisco и сервером, на котором выполняется программное обеспечение IPSec. Обратите внимание на то, что в программном обеспечении Cisco IOS и брандмауэра PIX Firewall туннельный режим для связей IPSec является режимом, устанавливаемым по умолчанию.
Транспортный режим используется между конечными станциями, поддерживающими IPSec, или между конечной станцией и шлюзом, если шлюз интерпретируется как хост. На рис. ниже показан пример Г, иллюстрирующий применение транспортного режима для создания шифрованного туннеля IPSec от компьютера Алисы, на котором выполняется программное обеспечение клиента Microsoft Windows 2000, к концентратору Cisco VPN 3000, что позволяет Алисе использовать L2ТР-туннель над IPSec.
