Ipsec tools racoon

NAT traversal

IPsec появился до NAT и в своем чистом виде работать за NAT не может. Эту возможность к нему прикрутили позже. Сам ESP — отдельный протокол IP с номером 50. Для работы за NAT его инкапсулируют в UDP. В этом случае IKE и инкапсулированный ESP используют один порт — UDP/4500.

Изначально от NAT страдали пользователи клиентских соединений вроде L2TP и IPsec. Популярность облачных платформ, где вместо присвоения хостам публичных адресов эти адреса раздают через 1:1 NAT сделала эту проблему актуальной и для соединений между маршрутизаторами.

При этом может возникнуть неожиданная проблема: если на другой стороне туннель настроен на фиксированный адрес, даже если NAT traversal поддерживается, соединение не заработает.

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

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

Например, в StrongSWAN:

1
2
3

conn mypeer

left=%defaultroute

leftid=»192.0.2.10″

Как работает IPsec

В работе протоколов IPsec можно выделить пять этапов:

  1. Первый этап начинается с создания на каждом узле, поддерживающим стандарт IPsec, политики безопасности. На этом этапе определяется, какой трафик подлежит шифрованию, какие функции и алгоритмы могут быть использованы.
  2. Второй этап является по сути первой фазой IKE. Её цель — организовать безопасный канал между сторонами для второй фазы IKE. На втором этапе выполняются:
    • Аутентификация и защита идентификационной информации узлов
    • Проверка соответствий политик IKE SA узлов для безопасного обмена ключами
    • Обмен Диффи-Хеллмана, в результате которого у каждого узла будет общий секретный ключ
    • Создание безопасного канала для второй фазы IKE
  3. Третий этап является второй фазой IKE. Его задачей является создание IPsec-туннеля. На третьем этапе выполняются следующие функции:
    • Согласуются параметры IPsec SA по защищаемому IKE SA каналу, созданному в первой фазе IKE
    • Устанавливается IPsec SA
    • Периодически осуществляется пересмотр IPsec SA, чтобы убедиться в её безопасности
    • (Опционально) выполняется дополнительный обмен Диффи-Хеллмана
  4. Рабочий этап. После создания IPsec SA начинается обмен информацией между узлами через IPsec-туннель, используются протоколы и параметры, установленные в SA.
  5. Прекращают действовать текущие IPsec SA. Это происходит при их удалении или при истечении времени жизни (определенное в SA в байтах информации, передаваемой через канал, или в секундах), значение которого содержится в SAD на каждом узле. Если требуется продолжить передачу, запускается фаза два IKE (если требуется, то и первая фаза) и далее создаются новые IPsec SA. Процесс создания новых SA может происходить и до завершения действия текущих, если требуется непрерывная передача данных.

Часть 1. Рабочий процесс создания и настройки политики IPsec/IKEPart 1 — Workflow to create and set IPsec/IKE policy

В этом разделе описывается рабочий процесс, необходимый для создания и обновления политики IPsec/IKE для VPN-подключений типа «сеть — сеть» или «виртуальная сеть — виртуальная сеть»:This section outlines the workflow to create and update IPsec/IKE policy on a S2S VPN or VNet-to-VNet connection:

  1. Создание виртуальной сети и VPN-шлюза.Create a virtual network and a VPN gateway
  2. Создание шлюза локальной сети для локального подключения или другой виртуальной сети и шлюза для подключения типа «виртуальная сеть — виртуальная сеть».Create a local network gateway for cross premises connection, or another virtual network and gateway for VNet-to-VNet connection
  3. Создание политики IPsec/IKE с выбранными алгоритмами и параметрами.Create an IPsec/IKE policy with selected algorithms and parameters
  4. Создание подключения (IPsec или VNet2VNet) с помощью политики IPsec/IKE.Create a connection (IPsec or VNet2VNet) with the IPsec/IKE policy
  5. Добавление, обновление и удаление политики IPsec/IKE для существующего подключения.Add/update/remove an IPsec/IKE policy for an existing connection

Инструкции из этой статьи помогут установить и настроить политики IPsec/IKE, как показано на следующей схеме:The instructions in this article helps you set up and configure IPsec/IKE policies as shown in the diagram:

Authentication Header

Authentication Header format
Offsets Octet16 1 2 3
Octet16 Bit10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Next Header Payload Len Reserved
4 32 Security Parameters Index (SPI)
8 64 Sequence Number
C 96 Integrity Check Value (ICV)
Тип следующего заголовка (8 bits)
Длина содержимого (8 bits)
Это поле определяет общий размер АН-заголовка в 32-битовых словах, минус 2. Несмотря на это, при использовании IPv6 длина заголовка должна быть кратна 8 байтам.
Зарезервировано (16 bits)
Зарезервировано. Заполняется нулями.
Индекс параметров системы безопасности (32 bits)
Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (АН-протокол), однозначно определяет защищённое виртуальное соединение (SA) для данного пакета. Диапазон значений SPI 1…255 зарезервирован IANA.
Порядковый номер (32 bits)
Последовательный номер. Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может отказаться от услуги по защите от повторной передачи пакетов, оно является обязательным и всегда присутствует в AH-заголовке. Передающий IPsec-модуль всегда использует это поле, но получатель может его и не обрабатывать.
Данные аутентификации
Цифровая подпись. Служит для аутентификации и проверки целостности пакета. Должна быть дополнена до размера, кратного 8-байтам для IPv6, и 4-байтам для IPv4.

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

Обработка выходных IP-пакетов

  • поля IP-заголовка, которые не были подвержены изменениям в процессе транслирования, или определены как наиболее важные
  • АН-заголовок (Поля: «Next Header», «Payload Len, «Reserved», «SPI», «Sequence Number», «Integrity Check Value». Поле «Integrity Check Value» устанавливается в 0 при вычислении ICV
  • данные протокола верхнего уровня

Обработка входных IP-пакетов

После получения пакета, содержащего сообщение АН-протокола, приёмный IPsec-модуль ищет соответствующее защищённое виртуальное соединение (SA) SAD (Security Associations Database), используя IP-адрес получателя, протокол безопасности (АН) и индекс SPI. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищённое виртуальное соединение (SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, то есть на необходимость проверки поля Sequence Number. Если услуга используется, то поле проверяется. При этом используется метод скользящего окна для ограничения буферной памяти, требуемый для работы протоколу. Приёмный IPsec-модуль формирует окно с шириной W (обычно W выбирается равным 32 или 64 пакетам). Левый край окна соответствует минимальному последовательному номеру (Sequence Number) N правильно принятого пакета. Пакет с полем Sequence Number, в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем приёмный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле «Integrity Check Value». Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным и принимается для дальнейшей IP-обработки. Если проверка дала отрицательный результат, то принятый пакет уничтожается.

MitM на IPSec с RSA-Sig

Если для аутентификации сторон вместо PSK в IPSec используется PKI CA (RSA-Sig), то доступ к файлу конфигурации не позволит выполнить описанную выше атаку. Система асимметричного шифрования RSA использует два ключа: public и secret, а секретный не хранится в конфигах… если только пара ключей не была сгенерирована с опцией exportable для обоих. Да, это типичная небрежность, серьезно понижающая уровень безопасности. Есть и другие аспекты практической реализации RSA-Sig, незнание которых снижает защиту до нуля.

Основная уязвимость этой схемы заключается в том, что в ней обычно добавляется функциональность автоматической регенерации ключей и перевыпуска сертификатов через некоторые интервалы времени (в руководстве — через каждый год). Это выглядит очень удобно для сопровождения системы, пока не задумаешься о том, как она работает. Чтобы ключи и сертификаты автоматом перевыпустились через указанное время, администратор заранее вводит и сохраняет пароль для их подписи. То есть мы опять получаем аналог PSK и уровень надежности, соответствующий стойкости пароля.

К сожалению, во многих учебных пособиях (даже в базовом руководстве CCNP Security 300-209) в качестве примера приводится такая упрощенная схема внедрения, сводящая безопасность IPSec на нет.

Черный юмор ситуации в том, что данная конфигурация может пройти аудит безопасности, например PCI-DSS. Знаю это из практики. Аудитор спрашивает вас, шифруются ли в вашей сети данные. Вы уверенно отвечаете «Да!» и в подтверждение показываете ему снимки экрана, где указывается надежный протокол IPSec, да еще и с PKI CA. Он радостно ставит галочки в своем опроснике, и вы идете пить чай. Аудит успешно «пройден».

Можно ли выполнить для RSA-Sig атаку посредника, как для PSK? В отдельных случаях это даже проще сделать: хакеру понадобится только один «злой клон». Вот самая простая и часто встречающаяся топология, рекомендованная в руководствах: Алиса использует роутер А, Боб принимает ее трафик на своем роутере B. Аутентификацию PKI CA выполняет отдельный сервер.

Ничто не предвещало беды…

Атакующая сторона добавляет в сеть свой роутер и присваивает ему MAC/IP-адрес роутера Боба. После этого злоумышленник генерирует пару ключей и отправляет запрос на сервер для подписи публичного ключа (якобы нового, сгенерированного Бобом). В ответ он получает от сервера подписанный сертификат и устанавливает «защищенный» IPSec-туннель с Алисой от имени Боба.

…но тут пришла Ева и клонировала роутер Боба

Схема тестировалась также в эмуляторе GNS. Конфиги доступны по ссылкам:

  • IPSec_MitM-RSA-sig
  • IPSec-MitM-PSK

Фаза 1 и Фаза 2

В IPsec все происходит по Фазам.

На фазе 1 происходит установление SA первой фазы. В первой фазе стороны договариваются о методе идентификации, алгоритме шифрования, алгоритме хэшировнаия и группе Diffie Hellman. Эта фаза может пройти путем обмена тремя нешифрованными пакетами (агрессивный режим) или шестью нешифрованными пакетами — стандартный режим. Если все прошло успешно, то создается SA фазы 1 под названием IKE SA и осуществляется переход ко второй фазе.

На фазе 2 стороны договариваются о политике и создаются сами ключи. Эта фаза, в отличии от первой полностью шифруется и она наступает только в случае успешного окончания первой фазы. В связи с тем, что трафик этой фазы полностью шифрован становится сложно осуществлять поиск неполадок, однако если все прошло успешно, то создается SA фазы 2 под названием IPSec SA. В этот момент можно сказать, что туннель установлен.

Installation

First, update your system with (Ubuntu/Debian) or and reboot. This is optional, but recommended.

To install the VPN, please choose one of the following options:

Option 1: Have the script generate random VPN credentials for you (will be displayed when finished):

Ubuntu & Debian

wget https://git.io/vpnsetup -O vpn.sh && sudo sh vpn.sh

CentOS & RHEL

yum -y install wget
wget https://git.io/vpnsetup-centos -O vpn.sh && sudo sh vpn.sh

Amazon Linux 2

wget https://git.io/vpnsetup-amzn -O vpn.sh && sudo sh vpn.sh

Option 2: Edit the script and provide your own VPN credentials:

Ubuntu & Debian

wget https://git.io/vpnsetup -O vpn.sh
nano -w vpn.sh

sudo sh vpn.sh

CentOS & RHEL

yum -y install wget nano
wget https://git.io/vpnsetup-centos -O vpn.sh
nano -w vpn.sh

sudo sh vpn.sh

Amazon Linux 2

wget https://git.io/vpnsetup-amzn -O vpn.sh
nano -w vpn.sh

sudo sh vpn.sh

Note: A secure IPsec PSK should consist of at least 20 random characters.

Option 3: Define your VPN credentials as environment variables:

Ubuntu & Debian

# All values MUST be placed inside 'single quotes'
# DO NOT use these special characters within values: \ " '
wget https://git.io/vpnsetup -O vpn.sh
sudo VPN_IPSEC_PSK='your_ipsec_pre_shared_key' \
VPN_USER='your_vpn_username' \
VPN_PASSWORD='your_vpn_password' \
sh vpn.sh

CentOS & RHEL

# All values MUST be placed inside 'single quotes'
# DO NOT use these special characters within values: \ " '
yum -y install wget
wget https://git.io/vpnsetup-centos -O vpn.sh
sudo VPN_IPSEC_PSK='your_ipsec_pre_shared_key' \
VPN_USER='your_vpn_username' \
VPN_PASSWORD='your_vpn_password' \
sh vpn.sh

Amazon Linux 2

# All values MUST be placed inside 'single quotes'
# DO NOT use these special characters within values: \ " '
wget https://git.io/vpnsetup-amzn -O vpn.sh
sudo VPN_IPSEC_PSK='your_ipsec_pre_shared_key' \
VPN_USER='your_vpn_username' \
VPN_PASSWORD='your_vpn_password' \
sh vpn.sh

After successful installation, it is recommended to set up IKEv2:

wget https://git.io/ikev2setup -O ikev2.sh && sudo bash ikev2.sh --auto

The command above runs the in auto mode, using default options. Remove the parameter if you want to customize IKEv2 setup options.

Note: If unable to download via , you may also open vpnsetup.sh, vpnsetup_centos.sh or vpnsetup_amzn.sh, and click the button on the right. Press to select all, to copy, then paste into your favorite editor.

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

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

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

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

Код протокола Назначение
6 Протокол TCP (Transmission Control Protocol)
17 Протокол UDP (User Datagram Protocol)
41 Протокол IPv6
50 IPsec: Протокол ESP (Инкапсулированное поле данных безопасности)
51 IPsec: Протокол AH (Заголовок аутентификации)

Security Associations (SA)

В отличие от OpenVPN или wireguard, IPsec сам по себе не создает никаких виртуальных интерфейсов. Во времена его зарождения у каждого хоста в интернете был публичный адрес и никакой потребности в виртуальных сетях с отдельной адресацией просто не было. Виртуальными интерфейсами занимаются отдельные протоколы, например L2TP или GRE, а IPsec только шифрует их трафик. Многие платформы поддерживают VTI — ассоциированный с соединением IPsec виртуальный интерфейс, но на деле это всего лишь автоматизированная настройка IPIP поверх IPsec.

Вместо туннелей IPsec оперирует еще более абстрактными сущностями — security associations. Они не являются сетевыми соединениями, это просто наборы параметров, которые указывают, какой трафик и как шифровать. К примеру, «трафик из 192.168.1.0/24 в 10.1.0.0/24 зашифровать AES‐128 и добавить сумму SHA1».

Security associations существуют на обеих сторонах независимо и не могут оборваться сами по себе, в отличие от сетевых соединений. Если ты видишь на своей стороне живую SA, это еще не значит, что трафик нормально пойдет на вторую сторону туннеля. Не забывай проверять, что все на самом деле работает. Чтобы вторая сторона могла узнать, что у тебя происходит, нужно настроить dead peer detection (для IKEv1) или использовать IKEv2, где есть liveness check.

В случае с dead peer detection не забывай проверять, что параметры на обеих сторонах совпадают, иначе можно надолго остаться с туннелем, который только выглядит как живой.

Что такое VPN-протокол?

VPN-протокол — программный фундамент, на базе которого строится любой VPN-сервис. В нем описывается формат организации подключения, обмена данными внутри частной виртуальной сети и другие аспекты работы ПО. 

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

На какие критерии оценки VPN-протоколов стоит обратить внимание

У каждого протокола свой набор характеристик, исходя из которых нужно выбирать для себя подходящий. Среди них:

  • Поддерживаемые платформы — протоколы могут быть достаточно специфичны и функционировать исключительно на одной-двух операционных системах. Другие же поддерживают сразу все доступные ОС.
  • Поддерживаемые сети — не все протоколы работают в идентичных сетях. Некоторые VPN-сервисы предлагают свои услуги только в конкретных странах ввиду технологических ограничений, введенных, в том числе, государственными органами.
  • Скорость работы — тоже зависит от архитектуры протокола. Есть те, что быстрее передают данные на мобильных устройствах. Есть те, что показывают пиковую производительность только в масштабах больших корпоративных сетей. 
  • Безопасность — в протоколах по-разному реализовано шифрование и другие механизмы обеспечения безопасности данных. Поэтому, в зависимости от поставленных задач, надо выбирать технологию, наименее подверженную распространенным для нее атакам.

Теперь от общего описания форматов и характеристик перейдем к конкретным технологическим решениям и к их особенностям.

Разрыв VPN соединения и смена ключей

Согласованные на двух фазах ключи должны работать оговоренное политикой время. Это означает, что сторонам возможно предстоит пережить процедуру смены ключей (rekeying), а иначе согласованные SA распадутся. Как было сказано выше, у сторон есть ключи в рамках процесса фазы 1 (IKE) и фазы 2 (IPsec). Процедуры их смены различны, как и таймеры, которые за это отвечают. Для того, чтобы не было перерыва связи в процессе смены ключей стороны сначала согласовывают параметры новой SA и лишь после этой успешной процедуры уничтожают старую SA.

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

Настройка

Настройка первого маршрутизатора

Через графический интерфейс

Настройка IPsec-пира. На первом этапе надо указать адрес пира (маршрутизатора с которым будет устанавливаться соединение) и ключ (secret) с помощью, которого будет проходить авторизация. В качестве алгоритма шифрования мы выбрали aes-128. Конечно можно использовать и более длинные ключи, но это не имеет практического смысла, т. к. даже для подбора такого ключа требуется очень-очень много лет. Поэтому мы считаем, что более длинные ключи нужны либо в маркетинговых целях либо, если вы очень заморочены на глобальной слежке правительства.

Настройка политики IPsec. Следующим шагом надо настроить политику IPsec. Политика описывает в каких случаях должно использоваться шифрование. Т. е., если пакет совпадает с правилом описанным в политике, то выполняется заданное действие. В нашем случае это шифрование. Если пакет не совпадает с правилом, то он идет дальше без обработки политикой.

Если правило обхода NAT было создано после того, как было установлено защищенное соединение, то оно не заработает. Для того, что бы оно начало работать надо либо удалить все соединения на вкладке "Connections" у файервола либо перезагрузить маршрутизатор.

И с помощью захвата и перетаскивания мышью перетянем правило так, что бы оно находилось выше правила «masquerade«.

Через консоль

Настройка второго маршрутизатора

Через графический интерфейс

Расписывать заново каждое действие мы не будем, т. к. они полностью аналогичны настройкам на первом маршрутизаторе.
Настройка IPsec-пира.

Настройка политики IPsec.

Правило обхода NAT.

Через консоль

Настройка маршрутизации

Маршрутизация при использовании IPsec «в чистом виде» не может быть использована, т. к. IPsec не создает виртуальный интерфейс, которому может быть назначен IP-адрес и добавлена запись в таблицу маршрутизации.

  • AES является единственным алгоритмом, который поддерживается модулем аппаратного шифрования, если такой установлен на маршрутизатор.
  • Максимальное значение MTU при котором не будет фрагментации с использованием IPsec с алгоритмами SHA1 для подписи и AES-128 для шифрования = 1418. При использовании других алгоритмов значение MTU будет другим. Если используется механизм обхода NAT IPsec, следует понизить MTU на 28.
  • AES является единственным алгоритмом, который поддерживается модулем аппаратного шифрования, если такой установлен на маршрутизатор.
  • IPSec очень не стабильно работает за NAT’ом. Поэтому желательно, что бы внешние интерфейсы маршрутизаторов имели «белые» IP-адреса.

IPsec

Internet Protocol Security (IPsec) — это набор протоколов для обеспечения защиты данных, передаваемых по IP-сети. В отличие от SSL, который работает на прикладном уровне, IPsec работает на сетевом уровне и может использоваться нативно со многими операционными системами, что позволяет использовать его без сторонних приложений (в отличие от OpenVPN).

IPsec стал очень популярным протоколом для использования в паре с L2TP или IKEv2, о чем мы поговорим ниже.

IPsec шифрует весь IP-пакет, используя:

  • Authentication Header (AH), который ставит цифровую подпись на каждом пакете;
  • Encapsulating Security Protocol (ESP), который обеспечивает конфиденциальность, целостность и аутентификацию пакета при передаче.

Обсуждение IPsec было бы неполным без упоминания утечки презентации Агентства Национальной Безопасности США, в которой обсуждаются протоколы IPsec (L2TP и IKE). Трудно прийти к однозначным выводам на основании расплывчатых ссылок в этой презентации, но если модель угроз для вашей системы включает целевое наблюдение со стороны любопытных зарубежных коллег, это повод рассмотреть другие варианты. И все же протоколы IPsec еще считаются безопасными, если они реализованы должным образом.

Теперь мы рассмотрим, как IPsec используется в паре с L2TP и IKEv2.

L2TP/IPsec

Layer 2 Tunneling Protocol (L2TP) был впервые предложен в 1999 году в качестве обновления протоколов L2F (Cisco) и PPTP (Microsoft). Поскольку L2TP сам по себе не обеспечивает шифрование или аутентификацию, часто с ним используется IPsec. L2TP в паре с IPsec поддерживается многими операционными системами, стандартизирован в RFC 3193.

L2TP/IPsec считается безопасным и не имеет серьезных выявленных проблем (гораздо безопаснее, чем PPTP). L2TP/IPsec может использовать шифрование 3DES или AES, хотя, учитывая, что 3DES в настоящее время считается слабым шифром, он используется редко.

У протокола L2TP иногда возникают проблемы из-за использования по умолчанию UDP-порта 500, который, как известно, блокируется некоторыми брандмауэрами.

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

IKEv2/IPsec

Internet Key Exchange version 2 (IKEv2) является протоколом IPsec, используемым для выполнения взаимной аутентификации, создания и обслуживания Security Associations (SA), стандартизован в RFC 7296. Так же защищен IPsec, как и L2TP, что может говорить об их одинаковом уровне безопасности. Хотя IKEv2 был разработан Microsoft совместно с Cisco, существуют реализации протокола с открытым исходным кодом (например, OpenIKEv2, Openswan и strongSwan).

Благодаря поддержке Mobility and Multi-homing Protocol (MOBIKE) IKEv2 очень устойчив к смене сетей. Это делает IKEv2 отличным выбором для пользователей смартфонов, которые регулярно переключаются между домашним Wi-Fi и мобильным соединением или перемещаются между точками доступа.

IKEv2/IPsec может использовать ряд различных криптографических алгоритмов, включая AES, Blowfish и Camellia, в том числе с 256-битными ключами.

IKEv2 поддерживает Perfect Forward Secrecy.

Во многих случаях IKEv2 быстрее OpenVPN, так как он менее ресурсоемкий. С точки зрения производительности IKEv2 может быть лучшим вариантом для мобильных пользователей, потому как он хорошо переустанавливает соединения. IKEv2 нативно поддерживается на Windows 7+, Mac OS 10.11+, iOS, а также на некоторых Android-устройствах.

AH и ESP

Три основных компонента безопасности: доступность, аутентичность и конфиденциальность. IPsec может обеспечивать аутентичность, при этом ничего не делая для конфиденциальности.

Протокол AH (Authentication Header) добавляет в пакет специальный заголовок с контрольной суммой. На практике он используется редко, поскольку никак не способствует конфиденциальности.

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

ESP (Encapsulated Security Payload) шифрует содержимое пакета и добавляет хеши. Его можно использовать в двух режимах — транспортном и туннельном. Это сейчас в сетях IPv4 любой VPN немыслим без маршрутизации частных (серых) адресов через туннель, поскольку со внешним миром хосты общаются через NAT. Но IPsec старше NAT и изначально шифровал только полезную нагрузку пакетов, не трогая заголовки, — это и есть транспортный режим.

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

Что интересно, оба они не работают поверх TCP или UDP, а используют отдельные номера протоколов IP. Во всяком случае, по умолчанию — ESP может быть инкапсулирован в UDP для работы через NAT, но об этом позже.

Ловушки (имитация системы)

DDP – Distributed Deception Platforms

Развитие концепции Honeypot привело к появлению современных DDP, отличительной чертой которых стала имитация максимального числа ИТ-систем, включая не только серверы и конечные станции, но и сетевую инфраструктуру, приложения и данные. Распределенные платформы для имитации инфраструктуры встраиваются между целевой системой и потенциальным атакующим. Идея проста: злоумышленник должен думать, что это реальная система. При этом сама система одновременно будет способствовать проактивному блокированию атак путем вычисления вектора атаки на тестовую инфраструктуру еще до того, как атакующий получит доступ к реальной системе, и помогать в реагировании на уже свершившийся инцидент ИБ, благодаря развернутой аналитике прохождения атаки по тестовой инфраструктуре.

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий