Протокол работает на сетевом уровне модели OSI и, соответственно, он "прозрачен" для приложений. Иными словами, на работу приложений (таких как web- сервер , браузер , СУБД и т.д.) не влияет, используется ли защита передаваемых данных с помощью IPSec или нет.
Операционные системы семейства Windows 2000 и выше имеют встроенную поддержку протокола IPSec. С точки зрения многоуровневой модели защиты, этот протокол является средством защиты уровня сети.
Рис.
5.9.
Архитектура IPSec является открытой, что, в частности, позволяет использовать для защиты передаваемых данных новые криптографические алгоритмы и протоколы, например соответствующие национальным стандартам. Для этого необходимо, чтобы взаимодействующие стороны поддерживали эти алгоритмы, и они были бы стандартным образом зарегистрированы в описании параметров соединения.
Процесс защищенной передачи данных регулируется правилами безопасности, принятыми в системе. Параметры создаваемого туннеля описывает информационная структура, называемая контекст защиты или ассоциация безопасности (от англ. Security Association , сокр. SA ). Как уже отмечалось выше, IPSec является набором протоколов, и состав SA может различаться, в зависимости от конкретного протокола. SA включает в себя:
Обычно, контекст защиты является однонаправленным, а для передачи данных по туннелю в обе стороны задействуются два SA . Каждый хост имеет свою базу SA , из которой выбирается нужный элемент либо на основании SPI , либо по IP -адресу получателя.
Два протокола, входящие в состав IPSec это:
Оба эти протокола имеют два режима работы - транспортный и туннельный, последний определен в качестве основного. Туннельный режим используется, если хотя бы один из соединяющихся узлов является шлюзом безопасности. В этом случае создается новый IP -заголовок, а исходный IP -пакет полностью инкапсулируется в новый.
Транспортный режим ориентирован на соединение хост - хост . При использовании ESP в транспортном режиме защищаются только данные IP -пакета, заголовок не затрагивается. При использовании AH защита распространяется на данные и часть полей заголовка. Более подробно режимы работы описаны ниже.
В IP ver .4 аутентифицирующий заголовок располагается после IP-заголовка. Представим исходный IP-пакет как совокупность IP-заголовка, заголовка протокола следующего уровня (как правило, это TCP или UDP, на рис. 5.10 он обозначен как ULP - от англ. Upper-Level Protocol) и данных.
Рассмотрим формат заголовка ESP ( рис. 5.13). Он начинается с двух 32-разрядных значений - SPI и SN . Роль их такая же, как в протоколе AH - SPI идентифицирует SA, использующийся для создания данного туннеля; SN - позволяет защититься от повторов пакетов. SN и SPI не шифруются.
Следующим идет поле, содержащее зашифрованные данные. После них - поле заполнителя, который нужен для того, чтобы выровнять длину шифруемых полей до значения кратного размеру блока алгоритма шифрования.
После заполнителя идут поля, содержащие значение длины заполнителя и указание на протокол более высокого уровня. Четыре перечисленных поля (данные, заполнитель, длина, следующий протокол) защищаются шифрованием.
Если ESP используется и для аутентификации данных, то завершает пакет поле переменной длины, содержащее ICV. В отличие от AH, в ESP при расчете значения имитовставки , поля IP-заголовка (нового - для туннельного режима, модифицированного старого - для транспортного) не учитываются.
При совместном использовании протоколов AH и ESP , после IP заголовка идет AH, после него - ESP . В этом случае, ESP решает задачи обеспечения конфиденциальности, AH - обеспечения целостности и аутентификации источника соединения.
Рассмотрим ряд дополнительных вопросов, связанных с использованием IPSec. Начнем с того, откуда берется информация о параметрах соединения - SA. Создание базы SA может производиться различными путями. В частности, она может создаваться администратором безопасности вручную, или формироваться с использованием специальных протоколов - SKIP , ISAKMP ( Internet Security Association and Key Management Protocol) и IKE (Internet Key Exchange).
При подключении сетей организаций к Интернет, часто используется механизм трансляции сетевых адресов - NAT ( Network Address Translation ). Это позволяет уменьшить число зарегистрированных IP-адресов, используемых в данной сети. Внутри сети используются незарегистрированные адреса (как правило, из диапазонов, специально выделенных для этой цели, например, адреса вида 192.168.x.x для сетей класса C). Если пакет из такой сети передается в Интернет, то маршрутизатор, внешнему интерфейсу которого назначен по крайней мере один зарегистрированный ip-адрес, модифицирует ip-заголовки сетевых пакетов, подставляя вместо частных адресов зарегистрированный адрес. То, как производится подстановка, фиксируется в специальной таблице. При получении ответа, в соответствии с таблицей делается обратная замена и пакет переправляется во внутреннюю сеть.
Рассмотрим пример использования NAT рис. 5.14 . В данном случае, во внутренней сети используются частные адреса 192.168.0.x. С компьютера, с адресом 192.168.0.2 обращаются во внешнюю сеть к компьютеру с адресом 195.242.2.2. Пусть это будет подключение к web-серверу (протокол HTTP, который использует TCP порт 80).
При прохождении пакета через маршрутизатор, выполняющий трансляцию адресов, ip-адрес отправителя (192.168.0.2) будет заменен на адрес внешнего интерфейса маршрутизатора (195.201.82.146), а в таблицу трансляции адресов будет добавлена запись, аналогичная приведенной в
Мы уже обсуждали понятие IPSec, в этом материале мы рассмотрим IPSec подробнее.
Итак, название IPSec происходит от IP Security.
IPSec - это совокупность протоколов и адлгоритмов, которые используются для защиты IP пакетов на уровне Layer3.
IPSec позволяет гарантировать:
- Confidentiality - с помощью шифрования
- Data integrity - через Hashing и HMAC\
- Authentication - через использование Digital Signatures или Pre-shared key (PSK).
Перечислим основные протоколы IPsec:
■ ESP and AH
: Два основных протокола, используемых в IPsec.
Encapsulating Security Payload (ESP)
, может делать всё что требуется для IPsec, а
Authentication Header (AH)
, может делать всё, кроме шифрования, encryption of the data, - поэтому чаще всего используют ESP.
■ Encryption algorithms for confidentiality
: DES, 3DES, AES.
■ Hashing algorithms for integrity:
MD5, SHA.
■ Authentication algorithms
: Pre-shared keys (PSK), RSA digital signatures.
■ Key management
: An example would be Diffie-Hellman (DH), which can be used to
dynamically generate symmetrical keys to be used by symmetrical algorithms; PKI,
which supports the function of digital certificates issued by trusted CAs; and Internet
Key Exchange (IKE), which does a lot of the negotiating and management for us for
IPsec to operate.
Рассмотрим следующую простую топологию соединения двух офисов.
Нам необходимо обеспечить соединение двух офисов и выполнить следующие цели:
| IKEv1 Phase 1 | UDP port 500 | IKEv1 Phase 1 uses UDP:500 for its negotiation. |
| NAT-T (NAT Traversal) |
UDP port 4500 | NAT Traversal используется устройствами для преодоления NAT. Если оба устройства подключаются друг ко другу через NAT: they want to put a fake UDP port 4500 header on each IPsec packet (before the ESP header) to survive a NAT device that otherwise may have a problem tracking an ESP session (Layer 4 protocol 50) |
| ESP | Layer 4 Protocol 50 |
Все пакеты IPSec представляют из себя Layer 4 protocol of ESP (IP Protocol #50), в него инкапсулируются все данные. Обычно используется именно ESP (а не AH). В случае использования NAT-T, ESP header закрывается вторым UDP header. |
| AH | Layer 4 protocol 51 |
AH packets представляют собой Layer 4 protocol of AH (IP Protocol #51). AH не поддерживает шифрования полезных данных и поэтому он используется редко. |
Для поднятия безопасного соединения VPN, IPSec использует протокол Internet Key Exchange (IKE)
.
IKE - это framework, обеспечиваемая Internet Security Association
, а также Key Management Protocol (ISAKMP)
Итак у нашей конфигурации оба роутера будут выступать в качестве VPN gateway или IPsec peers .
Предположим юзер в сети 10.0.0.0 отправляет пакет в сеть 172.16.0.0.
Поскольку туннель ещё не создан R1 начнёт initiate negotiations со вторым роутером R2.
Первым шагом между роутерами поднимается Internet Key Exchange (IKE) Phase 1 tunnel
.
Такой туннель не предназначен для передачи пользовательских данных, но используется в служебных целях, для защиты management traffic.
Поднятие IKE Phase 1 tunnel может быть выполнено в двух режимах:
- main mode
- aggressive mode
Main mode требует обмена большим количеством пакетов но и считается более безопасным.
Для поднятия IKE Phase 1 tunnel должны быть негоциированы следующие элементы:
Задача DH - сгенерировать keying material (symmetric keys). Эти ключи будут использоваться для передачи данных.
Сам DH является asymmetrical , но ключи он генерирует symmetrical.
После того, как роутеры договрились об IKE Phase 1 policy, они могут начать процесс DH key exchange. DH позволяет двум устройствам, между которыми пока нет secure connection, безопасно обменяться симметричными ключами, которые будут использоваться симметричными алгоритмами, например AES.
Последнее что будет сделано в IKE Phase 1 - это взаимная аутентификация хостов, которая может быть произведена двумя методами (PSK или RSA digital signatures)
Если аутентификация прошла удачно, IKE Phase 1 tunnel считается поднятым. Туннель является двунаправленным.
После того, как поднялся IKE Phase 1 tunnel, роутеры начинают поднимать IKE Phase 1 tunnel.
Как уже упоминалось, IKE Phase 1 tunnel является чисто служебным, management tunnel и через него проходит весь трафик negotiation для поднятия туннеля IKE Phase 2.
IKE Phase 2 tunnel также использует алгоритмы hashing и encryption.
Поднятие IKE Phase 2 tunnel может быть выполнено в одном режимы:
- quick mode
IKE Phase 2 tunnel на самом деле состоит из двух однонаправленных туннелей, т.е. можно сказать что создаются:
Один туннель IKE Phase 1 tunnel, который является bidirectional, используемый для служебных функций.
И два туннеля IKE Phase 2, которые являются unidirectional, и которые используются для шифрования полезного трафика.
Все эти туннели также называются как security agreements between the two VPN peers
или security associations (SA)
.
Каждый SA имеет свой уникальный номер.
Теперь, после того как был поднят IKE Phase 2 tunnel, все пакеты выходящие из наружных интерфейсов будут зашифрованы.
Рассмотрим пример настройки IPsec на примере данной схемы.
ip access-list extended VPN-ACL permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
Router R2
ip access-list extended VPN-ACL permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
Router R1
crypto isakmp key secretkey address 200.200.200.1
Router R2
crypto isakmp policy 1 encryption 3des hash md5 authentication pre-share group 2
crypto isakmp key secretkey address 100.100.100.1
Здесь key есть PSK(Preshared Key) используемый роутерами для аутентификации IKE Phase 1.
crypto ipsec transform-set TRSET esp-3des esp-md5-hmac ! crypto map VPNMAP 10 ipsec-isakmp set peer 200.200.200.1 set transform-set TRSET match address VPN-ACL ! interface FastEthernet0/0 crypto map VPNMAP
Router R2
crypto ipsec transform-set TRSET esp-3des esp-md5-hmac ! crypto map VPNMAP 10 ipsec-isakmp set peer 100.100.100.1 set transform-set TRSET match address VPN-ACL ! interface FastEthernet0/0 crypto map VPNMAP
На обоих хостах использовалась crypto ipsec transform-set TRSET esp-3des esp-md5-hmac.
Это означает, что 3des будет использовано для шифрования, а md5-hmac для аутентификации.
crypto map эплаится на интерфейс. Криптокарта отслеживает трафик, отвечающим заданным условиям. Наша криптокарта будет работать с роутером с адресом 100.100.100.1, заданным ACL внутренним трафиком и будет применять на этот трафик transform-set TRSET.
В целом список полезных команд следующий:
show crypto isakmp policy
show crypto map
show crypto isakmp sa detail
show crypto ipsec sa
show crypto engine connections active
На практике наиболее полезно следующее:
В современном мире различные VPN-технологии используются повсеместно. Некоторые (например, PPTP) со временем признаются небезопасными и постепенно отмирают, другие (OpenVPN), наоборот, с каждым годом наращивают обороты. Но бессменным лидером и самой узнаваемой технологией для создания и поддержания защищенных частных каналов по-прежнему остается IPsec VPN. Иногда при пентесте можно обнаружить серьезно защищенную сеть с торчащим наружу лишь пятисотым UDP-портом. Все остальное может быть закрыто, пропатчено и надежно фильтроваться. В такой ситуации может возникнуть мысль, что здесь и делать-то особо нечего. Но это не всегда так. Кроме того, широко распространена мысль, что IPsec даже в дефолтных конфигурациях неприступен и обеспечивает должный уровень безопасности. Именно такую ситуацию сегодня и посмотрим на деле. Но вначале, для того чтобы максимально эффективно бороться c 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).
Итак, мы выяснили, что вначале участникам нужно договориться, с помощью каких механизмов будет создано защищенное соединение, поэтому теперь в дело вступает протокол 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.
Мы рассмотрели в первом приближении основную механику работы IPsec, но необходимо заострить внимание еще на нескольких вещах. Первая фаза, помимо всего прочего, может работать в двух режимах: main mode или aggressive mode. Первый вариант мы уже рассмотрели выше, но нас интересует как раз aggressive mode. В этом режиме используется три сообщения (вместо шести в main-режиме). При этом тот, кто инициирует соединение, отдает все свои данные разом - что он хочет и что умеет, а также свою часть обмена DH. Затем ответная сторона сразу завершает свою часть генерации DH. В итоге в этом режиме, по сути, всего два этапа. То есть первые два этапа из main mode (согласование хешей и обмен DH) как бы спрессовываются в один. В результате этот режим значительно опаснее по той причине, что в ответ приходит много технической информации в plaintext’е. И самое главное - VPN-шлюз может прислать хеш пароля, который используется для аутентификации на первой фазе (этот пароль еще часто называется pre-shared key или PSK).
Ну а все последующее шифрование происходит без изменений, как обычно. Почему же тогда этот режим по-прежнему используется? Дело в том, что он намного быстрее, примерно в два раза. Отдельный интерес для пентестера представляет тот факт, что aggressive-режим очень часто используется в RA IPsec VPN. Еще одна небольшая особенность RA IPsec VPN при использовании агрессивного режима: когда клиент обращается к серверу, он шлет ему идентификатор (имя группы). Tunnel group name (см. рис. 2) - это имя записи, которая содержит в себе набор политик для данного IPsec-подключения. Это уже одна из фич, специфичных оборудованию Cisco.
Казалось бы, что получается и так не слишком простая схема работы, но на деле все еще чуть сложнее. Со временем стало ясно, что только одного PSK недостаточно для обеспечения безопасности. Например, в случае компрометации рабочей станции сотрудника атакующий смог бы сразу получить доступ ко всей внутренней сети предприятия. Поэтому была разработана фаза 1.5 прямо между первой и второй классическими фазами. К слову, эта фаза обычно не используется в стандартном site-to-site VPN-соединении, а применяется при организации удаленных VPN-подключений (наш случай). Эта фаза содержит в себе два новых расширения - Extended Authentication (XAUTH) и Mode-Configuration (MODECFG).
XAUTH - это дополнительная аутентификация пользователей в пределах IKE-протокола. Эту аутентификацию еще иногда называют вторым фактором IPsec. Ну а MODECFG служит для передачи дополнительной информации клиенту, это может быть IP-адрес, маска, DNS-сервер и прочее. Видно, что эта фаза просто дополняет ранее рассмотренные, но полезность ее несомненна.
Оба протокола работают по UDP-порту с номером 500, но между собой несовместимы, не допускается ситуация, чтобы на одном конце туннеля был IKEv1, а на другом - IKEv2. Вот основные отличия второй версии от первой:
Наконец-то разобравшись с особенностями работы IPsec и его компонентов, можно переходить к главному - к практическим атакам. Топология будет достаточно простой и в то же время приближенной к реальности (см. рис. 3).
Первым делом нужно определить наличие IPsec VPN шлюза. Сделать это можно, проведя сканирование портов, но здесь есть небольшая особенность. ISAKMP использует протокол UDP, порт 500, а между тем дефолтное сканирование с помощью Nmap затрагивает только TCP-порты. И в результате будет сообщение: All 1000 scanned ports on 37.59.0.253 are filtered .
Создается впечатление, что все порты фильтруются и как бы открытых портов нет. Но выполнив команду
Nmap -sU --top-ports=20 37.59.0.253 Starting Nmap 6.47 (http://nmap.org) at 2015-03-21 12:29 GMT Nmap scan report for 37.59.0.253 Host is up (0.066s latency). PORT STATE SERVICE 500/udp open isakmp
убеждаемся в том, что это не так и перед нами действительно VPN-устройство.
Теперь нас будет интересовать первая фаза, aggressive-режим и аутентификация с использованием pre-shared key (PSK). В этом сценарии, как мы помним, VPN-устройство или отвечающая сторона отправляет хешированный PSK инициатору. Одна из самых известных утилит для тестирования протокола IKE - это ike-scan, она входит в состав дистрибутива Kali Linux. Ike-scan позволяет отправлять IKE сообщения с различными параметрами и, соответственно, декодить и парсить ответные пакеты. Пробуем прощупать целевое устройство:
Root@kali:~# ike-scan -M -A 37.59.0.253 0 returned handshake; 0 returned notify
Ключ -A указывает на то, что нужно использовать aggressive-режим, а -M говорит о том, что результаты следует выводить построчно (multiline), для более удобного чтения. Видно, что никакого результата не было получено. Причина состоит в том, что необходимо указать тот самый идентификатор, имя VPN-группы. Разумеется, утилита ike-scan позволяет задавать этот идентификатор в качестве одного из своих параметров. Но так как пока он нам неизвестен, возьмем произвольное значение, например 0000.
Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Aggressive Mode Handshake returned
В этот раз видим, что ответ был получен (см. рис. 5) и нам было предоставлено довольно много полезной информации. Достаточно важная часть полученной информации - это transform-set. В нашем случае там указано, что «Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK».
Все эти параметры можно указывать и для утилиты ike-scan с помощью ключа --trans . Например --trans=5,2,1,2 будет говорить о том, что алгоритм шифрования 3DES, хеширование HMAC-SHA, метод аутентификации PSK и второй тип группы DH (1024-bit MODP). Посмотреть таблицы соответствия значений можно по этому адресу . Добавим еще один ключ (-P), для того чтобы вывести непосредственно пейлоад пакета, а точнее хеш PSK.
Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P
Казалось бы, хеш получен и можно пробовать его брутить, но все не так просто. Когда-то очень давно, в 2005 году, на некоторых железках Сisco была уязвимость: эти устройства отдавали хеш, только если атакующий передавал корректное значение ID. Сейчас, естественно, встретить такое оборудование практически невозможно и хешированное значение присылается всегда, независимо от того, правильное значение ID отправил атакующий или нет. Очевидно, что брутить неправильный хеш бессмысленно. Поэтому первая задача - это определить корректное значение ID, чтобы получить правильный хеш. И в этом нам поможет недавно обнаруженная уязвимость. Дело в том, что существует небольшая разница между ответами во время начального обмена сообщениями. Если кратко, то при использовании правильного имени группы происходит четыре попытки продолжить установление VPN-соединения плюс два зашифрованных пакета второй фазы. В то время как в случае неправильного ID в ответ прилетает всего лишь два пакета. Как видим, разница достаточно существенная, поэтому компания SpiderLabs (автор не менее интересного инструмента Responder) разработала сначала PoC, а затем и утилиту IKEForce для эксплуатации этой уязвимости.
Установить IKEForce в произвольный каталог можно, выполнив команду
Git clone https://github.com/SpiderLabs/ikeforce
Работает она в двух основных режимах - режиме вычисления -e (enumeration) и режиме брутфорса -b (bruteforce). До второго мы еще дойдем, когда будем смотреть атаки на второй фактор, а вот первым сейчас и займемся. Перед тем как начать непосредственно процесс определения ID, необходимо установить точное значение transform-set. Мы его уже определили ранее, поэтому будем указывать опцией -t 5 2 1 2 . В итоге выглядеть процесс нахождения ID будет следующим образом:
Python ikeforce.py 37.59.0.253 -e -w wordlists/group.txt -t 5 2 1 2
В результате достаточно быстро удалось получить корректное значение ID (рис. 7). Первый шаг пройден, можно двигаться дальше.
Теперь необходимо, используя правильное имя группы, сохранить PSK-хеш в файл, сделать это можно с помощью ike-scan:
Ike-scan -M -A --id=vpn 37.59.0.253 -Pkey.psk
И теперь, когда правильное значение ID было подобрано и удалось получить корректный хеш PSK, мы можем наконец-то начать офлайн-брутфорс. Вариантов такого брутфорса достаточно много - это и классическая утилита psk-crack, и John the Ripper (с jumbo-патчем), и даже oclHashcat, который, как известно, позволяет задействовать мощь GPU. Для простоты будем использовать psk-crack, который поддерживает как прямой брутфорс, так и атаку по словарю:
Psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk
Но даже успешно восстановить PSK (см. рис. 8) - это только половина дела. На этом этапе нужно вспомнить про то, что дальше нас ждет XAUTH и второй фактор IPsec VPN.
Итак, напомню, что XAUTH - это дополнительная защита, второй фактор аутентификации, и находится он на фазе 1.5. Вариантов XAUTH может быть несколько - это и проверка по протоколу RADIUS, и одноразовые пароли (OTP), и обычная локальная база пользователей. Мы остановимся на стандартной ситуации, когда для проверки второго фактора используется локальная база пользователей. До недавнего времени не существовало инструмента в публичном доступе для брутфорса XAUTH. Но с появлением IKEForce эта задача получила достойное решение. Запускается брутфорс XAUTH достаточно просто:
Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]Program started in XAUTH Brute Force Mode [+]Single user provided - brute forcing passwords for user: admin [*]XAUTH Authentication Successful! Username: admin Password: cisco
При этом указываются все найденные ранее значения: ID (ключ -i), восстановленный PSK (ключ -k) и предполагаемый логин (ключ -u). IKEForce поддерживает как грубый перебор логина, так и перебор по списку логинов, который может быть задан параметром -U . На случай возможных блокировок подбора есть опция -s , позволяющая снизить скорость брутфорса. К слову, в комплекте с утилитой идут несколько неплохих словарей, особенно полезных для установления значения параметра ID.
Теперь, когда у нас есть все данные, остается последний шаг - собственно проникновение в локальную сеть. Для этого нам понадобится какой-нибудь VPN-клиент, которых великое множество. Но в случае Kali можно без проблем воспользоваться уже предустановленным - VPNC. Для того чтобы он заработал, нужно подкорректировать один конфигурационный файл - /etc/vpnc/vpn.conf . Если его нет, то нужно создать и заполнить ряд очевидных параметров:
IPSec gateway 37.59.0.253 IPSec ID vpn IPSec secret cisco123 IKE Authmode psk Xauth Username admin Xauth password cisco
Здесь мы видим, что были использованы абсолютно все найденные на предыдущих шагах данные - значение ID, PSK, логин и пароль второго фактора. После чего само подключение происходит одной командой:
Root@kali:~# vpnc vpn
Отключение тоже достаточно простое:
Root@kali:~# vpnc-disconnect
Проверить работоспособность подключения можно, используя команду ifconfig tun0 .
Защита от рассмотренных сегодня атак должна быть комплексной: нужно вовремя устанавливать патчи, использовать стойкие pre-shared ключи, которые по возможности вовсе должны быть заменены на цифровые сертификаты. Парольная политика и другие очевидные элементы ИБ также играют свою немаловажную роль в деле обеспечения безопасности. Нельзя не отметить и тот факт, что ситуация постепенно меняется, и со временем останется только IKEv2.
Мы рассмотрели процесс аудита RA IPsec VPN во всех подробностях. Да, безусловно, задача эта далеко не тривиальна. Нужно проделать немало шагов, и на каждом из них могут поджидать трудности, но зато в случае успеха результат более чем впечатляющий. Получение доступа к внутренним ресурсам сети открывает широчайший простор для дальнейших действий. Поэтому тем, кто ответствен за защиту сетевого периметра, необходимо не рассчитывать на готовые дефолтные шаблоны, а тщательно продумывать каждый слой безопасности. Ну а для тех, кто проводит пентесты, обнаруженный пятисотый порт UDP - это повод провести глубокий анализ защищенности IPsec VPN и, возможно, получить неплохие результаты.
0 В этой статье предлагается обзор средств IPSEC (IP Security - система защиты на уровне IP) и соответствующих протоколов IPSec, доступных в продуктах Cisco и используемых для создания виртуальных частных сетей (VPN). В данной статье мы определим, что такое IPSEC, а также какие протоколы и алгоритмы защиты лежат в основе IPSEC.
Продукты Cisco для поддержки VPN используют набор протоколов IPSec, являющийся на сегодня промышленным стандартом обеспечения широких возможностей VPN. IPSec предлагает механизм защищенной передачи данных в IP-сетях, обеспечивая конфиденци¬альность, целостность и достоверность данных, передаваемых через незащищенные сети типа Internet. IPSec обеспечивает следующие возможности VPN в сетях Cisco:
IPSec представляет собой основанный на стандартах набор протоколов и алгоритмов защиты. Технология IPSec и связанные с ней протоколы защиты соответствуют открытым стандартам, которые поддерживаются группой IETF (Internet Engineering Task Force - проблемная группа проектирования Internet) и описаны в спецификациях RFC и проектах IETF. IPSec действует на сетевом уровне, обеспечивая защиту и аутентификацию пакетов IP, пересылаемых между устройствами (сторонами) IPSec - такими как маршрутизаторы Cisco, брандмауэры PIX Firewall, клиенты и концентраторы Cisco VPN, а также многие другие продукты, поддерживающие IPSec. Средства поддержки IPSec допускают масштабирование от самых малых до очень больших сетей.
Ассоциация защиты (Security Association - SA) представляет собой согласованную политику или способ обработки данных, обмен которыми предполагается между двумя устройствами сообщающихся сторон. Одной из составляющих такой политики может быть алгоритм, используемый для шифрования данных. Обе стороны могут ис¬пользовать один и тот же алгоритм как для шифрования, так и для дешифрования. Действующие параметры SA сохраняются в базе данных ассоциаций защиты (Security Association Database - SAD) обеих сторон.
Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA.
Протокол IKE (Internet Key Exchange - обмен Internet-ключами) является гибридным протоколом, обеспечивающим специальный сервис для IPSec, а именно аутентификацию сторон IPSec, согласование параметров ассоциаций защиты IKE и IPSec, а также выбор ключей для алгоритмов шифрования, используемых в рамках IPSec. Протокол IKE опира¬ется на протоколы ISAKMP (Internet Security Association and Key Management Protocol - протокол управления ассоциациями и ключами защиты в сети Internet) и Oakley, которые применяются для управления процессом создания и обработки ключей шифрования, используемых в преобразованиях IPSec. Протокол IKE применяется также для формирования ассоциаций защиты между потенциальными сторонами IPSec.
Как IKE, так и IPSec используют ассоциации зашиты, чтобы указать параметры связи.
IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).
Хэш-функция – это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения m1 и m2, таких, что
H(m1)=H(m2), где H – хэш функция.
Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC - механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая хэш функция (обозначим её как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования - как L (L
ipad = байт 0x36, повторённый B раз;
opad = байт 0x5C, повторённый B раз.
Для вычисления HMAC от данных "text" необходимо выполнить следующую операцию:
H(K XOR opad, H(K XOR ipad, text))
Из описания следует, что IKE использует для аутентификации сторон HASH величины. Отметим, что под HASH в данном случае подразумевается исключительно название Payload в ISAKMP, и это название не имеет ничего общего со своим содержимым
Перед тем как приступить к подробному ознакомлению с протоколом IPsec и его настройкой, следует выявить его возможности и преимущества перед другими доступными протоколами защиты данных.
IPsec существует в виде расширения протокола IPv4 и является неотъемлемой частью IPv6. Рассматриваемый протокол обеспечивает безопасность IP-уровня сети (3 уровень в модели ISO/OSI, рис. 1), что позволяет обеспечить высокий уровень защиты, прозрачный для большинства приложений, служб и протоколов верхнего уровня, использующих в качестве транспорта протокол IP. IPSec не требует внесения изменений в существующие приложения или операционные системы.
Рис. 1, Модель ISO/OSI.
Внедрение безопасности на данном уровне обеспечивает защиту для всех протоколов семейства TCP/IP, начиная с уровня IP, таких как TCP, UDP, ICMP, а также множества других.
Другие службы безопасности, работающие выше третьего уровня, например протокол SSL (Secure Sockets Layer), защищают лишь конкретный прикладной сокет. Для защиты всех устанавливаемых соединений подобные протоколы требуют изменения всех служб и приложений для обеспечения ими поддержки, протокола, в то время как службы, действующие ниже третьего уровня, такие как аппаратное шифрование уровня связи, в состоянии защитить лишь конкретную связь, но не все связи на пути следования данных, что делает их применение в условиях интернет нецелесообразным.
Использование протокола IPsec наиболее целесообразно для обеспечения безопасной связи между компьютерами либо сетями через другую масштабную сеть, безопасность которой невозможно контролировать. Одним из важных преимуществ протокола IPsec также является невысокая стоимость внедрения, так как в большинстве случаев не требуется установки нового оборудования или замены старого, а также то, что протокол является стандартным и открытым, и поставляется практически со всеми современными операционными системами.
Одним из важных преимуществ протокола является дешевизна его использования. Он позволяет обезопасить данные и обеспечить проверку подлинности пользователей и данных в ранее незащищенной сети без дополнительных затрат на сетевое оборудование, так как сохраняется совместимость со всем ранее выпущенным оборудованием.
Протокол IPsec обеспечивает высокий настраиваемый уровень безопасности с помощью служб, основанных на криптографии (хеширование – для защиты от повторений, обеспечения целостности данных и проверки их подлинности, и непосредственно шифрование, обеспечивающее конфиденциальность данных).
Субпротоколы AH (Authentication Header) и ESP (Encapsulating Security Payload) могут использоваться как совместно для обеспечения наибольшего уровня безопасности, так и независимо друг от друга.
Работа протокола возможна в двух режимах - транспортном и туннельном, обеспечивающих различный уровень безопасности и применимые в различных условиях.
Транспортный режим имеет целью обезопасить соединения между конкретными компьютерами, как правило объединенных единой (локальной) сетью. При использовании транспортного режима обеспечивается защита полезных данных IP (например сегментов TCP), при этом IP-заголовок защищается от изменения, оставаясь доступным для чтения.
В транспортном режиме протоколы AH и ESP имеют следующие функции и возможности:
протокол AH обеспечивает проверку подлинности и целостность данных, а также отсутствие повторов (как заголовка IP, так и полезных данных), то есть защищает данные от целенаправленных изменений. При этом данные не шифруются, и остаются доступными для чтения. AH подписывает пакеты используя алгоритмы хеширования с ключами (MD5, а в более современных реализациях SHA1), при этом заголовок AH помещается между заголовком IP и полезными данными (как показано на рисунке 2). В заголовке AH подписывается весь IP-пакет, за исключением полей, подлежащих изменению в процессе передачи по сети (рисунок 3). Заголовок AH всегда расположен перед любыми другими заголовками, используемыми в Ipsec.
Рис. 2, Размещение заголовка АН
Рис. 3, Охват AH (транспортный режим)
протокол ESP в транспортном режиме обеспечивает конфиденциальность полезных данных IP, но не заголовка IP. Кроме шифрования полезных данных IP, ESP обеспечивает проверку подлинности и целостности пакета, а точнее заголовка ESP, полезных данных IP и трейлера ESP (но не заголовка IP). Значение проверки целостности хранится в поле «трейлер проверки подлинности ESP». Заголовок ESP размещается перед полезными данными IP, а трейлер ESP и трейлер проверки подлинности ESP помещаются за полезными данными IP (рисунок 5).
Рис. 4, Размещение заголовка и трейлеров ESP
Рис. 5, Охват ESP (транспортный режим)
Туннельный режим используется преимущественно совместно с VPN-туннелями, что позволяет защитить связь между двумя географически удаленными сетями, объединенными посредством сети интернет. Рассматриваемый режим обеспечивает защиту всего пакета IP, рассматривая его как полезные данные AH или ESP. При использовании этого режима весь пакет IP инкапсулируется в заголовок AH или ESP и дополнительный заголовок IP. IP-адреса внешнего заголовка IP указывают конечные точки туннеля, а IP-адреса инкапсулированного заголовка IP указывают исходную точку и точку назначения пакета. Благодаря этому обеспечивается защита всего IP-пакета, включая заголовок IP.
AH в режиме туннеля подписывает пакет для сохранения целостности и инкапсулирует его в заголовки IP и AH (рисунок 6), при этом данные остаются доступными для чтения.
Рис. 6, Охват AH (туннельный режим)
ESP в туннельном режиме помещает исходный пакет целиком между заголовком ESP и трейлером проверки подлинности ESP, включая заголовок IP, и шифрует эти данные, создавая новый заголовок IP, как и AH, в котором в качестве адресов отправителя и получателя указываются IP адреса серверов туннеля (рисунок 7). Сервер туннеля на другой стороне расшифровывает пакет и, отбросив туннельный IP-заголовок и заголовки ESP, передает пакет получателю в своей интрасети. Весь процесс происходит совершенно прозрачно для конечных рабочих станций.
Рис. 7, Охват ESP (туннельный режим)
Туннельный режим протокола IPsec используется в тех случаях, когда требуется защитить данные (в том числе заголовки IP), передаваемые через общедоступную сеть. Примерами могут служить связи между удаленными подразделениями компании.
Транспортный же режим служит для защиты данных преимущественно внутри одной сети, безопасность которой не может быть надежно обеспечена другими способами без значительных затрат, либо когда требуется высокий уровень безопасности, что достигается совместным использованием различных протоколов. В качестве примеров можно назвать беспроводные сети, а также кабельные сети, покрывающие большие территории.
В зависимости от требуемого уровня безопасности, возможны различные конфигурации работы протокола IPsec. Например если требуется обеспечить лишь аутентификацию пользователей и проверку целостности и подлинности данных, то можно ограничится использованием AH, что существенно не повлияет на производительность сети и отдельных рабочих станций, даже при применении наиболее стойких алгоритмов хеш-функций, как будет показано ниже. В случае если передаваемые данные требуют их шифрования, то используется протокол ESP, что, в зависимости от применяемых криптографических алгоритмов и скорости передачи данных, может значительно сказаться на производительности рабочих станций, которые выполняют функции конечных точек туннеля или участвуют в сети, где применяется транспортный режим IPsec..
Настройка
Описание настройки VPN-туннелей, как и рассмотрение их свойств и возможностей, выходит за рамки данной статьи, поэтому ограничимся описанием процесса настройки транспортного режима IPsec.
В Windows XP настройка IPsec выполняется посредством оснастки «Локальные параметры безопасности», запуск которой возможен из меню «Администрирование», «Панели управления», либо через команду «Выполнить» «secpol.msc». Возможно использование созданных по умолчанию политик, либо создание новой.
Для создания политики безопасности IP необходимо выделить из списка пункт «Политики безопасности IP» и в меню «Действие» выбрать «Создать политику безопасности IP».
Рис. 8, Создание политики безопасности IP
Откроется «Мастер политики IP-безопасности». Для продолжения следует нажать «Далее». В следующем окне нужно ввести имя новой политики, и нажать «Далее».
Рис. 9, Имя политики IP
В следующем окне «Мастер» предложит принять решение использовать ли правило по умолчанию. Использование этого правила можно отменить и после создания политики, если возникнет такая необходимость.
Рис. 10, Правило по умолчанию
После этого «Мастер» предлагает выбрать способ проверки подлинности пользователя. IPsec поддерживает следующие способы: посредством протокола Kerberos (стандартный протокол аутентификации в доменах Windows 2000 и Windows 2003), с помощью сертификата пользователя, либо на основании строки защиты («пароля»). Если в вашей сети нет контроллеров домена и пользователи сети не обладают действительными сертификатами, остается только выбрать строку посложнее и держать ее в строгой тайне. Строка защиты на самом деле может состоять из нескольких строк.
Рис. 11, Выбор способа аутентификации
Создание политики практически закончено. Изменить свойства можно немедленно по завершении работы мастера (окно свойств откроется автоматически), либо позже, выделив нужную политику и выбрав из контекстного меня пункт «Свойства».
Рис. 12, Завершение создания политики
Теперь пришло время изменить свойства политики так, чтобы они удовлетворяли потребностям, а значит предстоит создать правила безопасности IP, фильтр и правила фильтра.
Для создания правила безопасности необходимо открыть свойства созданной политики безопасности IP и на вкладке «Правила» нажать кнопку «Добавить», предварительно сняв флажок «Использовать мастер», как показано на рисунке 13.
Рис.13, Создание правила безопасности IP
На закладке «Параметры туннеля» не следует что-либо изменять если Вы не настраиваете IPsec в туннельном режиме. На закладке «Тип подключения» есть возможность выбрать для каких сетевых подключений будет применяться создаваемое правило – для всех подключений, только для локальных подключений или только для удаленных. Таким образом предусмотрена возможность создания различных правил для сетевых подключений с различной скоростью передачи данных, что позволяет для более медленных и, как правило, менее защищенных удаленных подключений установить другие параметры как аутентификации, так и проверки целостности и шифрования.
Рис. 14, Тип подключения
На закладке «Методы проверки подлинности» есть возможность добавить несколько методов проверки и изменить порядок их предпочтения, что позволяет более гибко настроить правило для связи с различными узлами, поддерживающими различные способы аутентификации.
Рис. 15, Методы проверки подлинности
После выбора типа подключений и методов проверки подлинности следует выбрать список фильтров IP и действие фильтра, либо создать новые. Для выбора либо создания фильтров IP следует перейти на закладку «Список фильтров IP»(рисунок 16).
По умолчанию созданы следующие фильтры:
Полный IP-трафик, который применяется ко всему IP-трафику, независимо от используемого протокола более высокого уровня;
Полный ICMP-трафик, который применяется соотвественно ко всему ICMP-трафику.
Рис. 16, Список фильтров IP.
Для создания нового фильтра следует нажать кнопку «Добавить», после чего откроется окно «Список фильтров IP», где, после ввода имени списка фильтров и снятия галочки «Использовать мастер», следует нажать кнопку «Добавить»(рисунок 17).
Рис. 17, Создание списка фильтров IP.
Откроется окно «Свойства: Фильтр» (рисунок 18), где следует указать адреса источника и получателя пакетов, к которым будет применяться фильтр, а также, при необходимости, протокол и порты источника и получателя.
Рис. 18, Параметры нового списка фильтров IP
После выбора или создания списков фильтров, необходимо определить действие фильтра. Это можно сделать на закладке «Действие фильтра». Созданные по умолчанию действия:
Разрешить, которое разрешает прохождение небезопасных пакетов (без использования IPsec),
Требуется безопасность, что определяет разрыв связи с клиентами, не поддерживающими IPsec, а с клиентами, поддерживающими IPsec будет производиться обмен данными с применение проверки целостности ESP, но без AH и без шифрования данных.
Последнее предустановленное действие – Запрос безопасности – предусматривает требование от клиентов безопасной связи, но при невыполнении этих требований небезопасная связь прервана не будет.
Рис. 19, Действия фильтра
Создать новое действие можно нажав на кнопку «Добавить», предварительно сняв флажок «Использовать мастер» (рисунок 19). На вкладке «Методы безопасности» открывшегося окна «Свойства: создание действия фильтра», следует указать нужно ли разрешить прохождение данных, заблокировать их либо согласовать безопасность(рисунок 20).
Рис. 20, Пустой список возможных действий фильтра
Если выбран пункт согласовать безопасность, можно добавить методы безопасности и изменить порядок их предпочтения. При добавлении методов безопасности следует выбрать, будет ли использоваться AH, ESP, либо настроить безопасность вручную, выбрав пункт «Настраиваемая безопасность». Только таким образом можно задействовать и AH и ESP. В параметрах настраиваемой безопасности устанавливаются требуемые протоколы (AH и ESP)(рисунок 21).
Рис. 21, Создание действия фильтра
Здесь также предоставлена возможность вручную выбрать алгоритмы проверки целостности и шифрования, а таже параметры смены ключей сеанса. По умолчания ключи изменяются каждый час либо через каждые 100Mb переданной информации (рисунок 22).
Рис. 22, Параметры особого метода безопасности
После выбора действий фильтров настройку политики безопасности IP можно считать завершенной. Если настройка производилась в Windows XP, как в этом примере, для транспортного режима IPsec, то такую же операцию следует произвести на каждом компьютере. Средства автоматизации в Windows Server позволяют централизовано развернуть политику IP на всех рабочих станциях домена. Вне домена автоматизация возможна лишь отчасти посредством сценариев командной строки (с помощью программы ipseccmd).
Тестирование
Тестирование производительности протокола IPsec имеет целью выявить уровень нагрузки на центральный процессор при передаче данных по сети с использованием различных криптографических алгоритмов.
Тестирование производилось на компьютерах следующей конфигурации:
|
Компьютер 1 |
Компьютер 2 |
|
|
Процессор |
AMD Athlon 64 3000+ Socket 754 |
AMD Athlon XP 1700+ Socket А |
|
Материнская плата |
||
|
2*512 Mb Samsung PC 3200 |
256 Mb Samsung PC 2700 |
|
|
Жесткий диск |
Seagate ST3160023A |
Seagate ST380011A |
|
Сетевой адаптер |
Между двумя копьютерами передавался файл обьемом 701 Мб, с различными настройками IPsec, а также без использования рассматриваемого протокола.
К сожалению, не было найдено более точных способов измерения загруженности процессора и времени передачи файла, чем часы и диспетчер задач Windows, поэтому, возможна некоторая погрешность в измерениях.
Без использования IPsec, файл был передан за 86 с. При этом загруженность процессоров на обоих компьютерах была не высока, как показано на рисунках 23 и 24, а средняя скорость передачи данных достигла 65,21 Мбит/с.
После этого IPsec был настроен описанным выше образом для обеспечения целостности передаваемых данных (субпротокол AH с использованием SHA-1).
Время передачи данных возросло незначительно, до 91 с, а скорость незначительно упала, до 61,63 Мбит/с. При этом загрузка процессоров выросла не на много и изображена на рисунках 25 и 26.
Следующий тестовый вариант настройки IPsec был таким: ESP без использования AH, с шифрованием при помощи DES и хешированием MD5. Значительных изменений в производительности в этой конфигурации по сравнению с предыдущими замечено не было.
Файл передан за 93 с, скорость передачи составила 60,3 Мбит/с. Загрузка процессоров показана соответственно на рисунках 27 и 28. Следует заметить, что DES является устаревшим алгоритмом и не рекомендуется к использованию там, где защищаемые данные действительно имею большую ценность. В то же время стойкость этого алгоритма может быть значительно улучшена благодаря более частой смене ключа.
При использовании более стойкого 3DES вместо DES в той же конфигурации (MD5), скорость передачи упала более чем в два раза, и составила 29,99 Мбит/с, а время соответственно 187 с. Графики загруженности процессоров практически не изменились (рисунки 29 и 30).
При использовании ESP с 3DES и SHA1 время передачи выросло на 1с (до 188), а скорость упала до 29,83 Мбит/с. Приводить графики загруженности процессора нет смысла – они такие же как на рисунках 29 и 30.
Используя совместно с ESP протокол AH в наиболее безопасной, а значит и наиболее ресурсоемкой конфигурации, доступной в Windows XP, получены следующие результаты: время передачи увеличилось до 212 с, скорость упала до 26,45 Мбит/с.
Диаграмма 1, Время передачи файла и скорость в зависимости от используемых криптографических алгоритмов
Как видно из результатов тестирования (диаграмма 1), ресурсоемкость IPsec невысока при использовании только лишь AH и при применении ESP с DES. В случае же использования 3DES производительность резко падает, но при низких скоростях передачи данных производительности даже устаревших процессоров будет достаточно. Там же, где требуется высокая скорость передачи данных, может оказаться достаточным использование DES с частой сменой ключа. Характерно, что загрузка двух процессоров различного класса не слишком отличалась.
