Найти в Дзене
ИнфоКомм

Курс "Сети и безопасность в Linux". Безопасность GRE туннеля. IPsec на базе StrongSwan

Всем привет! Как и обещал начало четвертого блок.

StrongSwan - многоплатформенная реализация IPsec. Основное внимание в проекте уделяется механизмам аутентификации с использованием сертификатов открытого ключа X.509 и дополнительного хранения закрытых ключей и сертификатов на смарт-картах через интерфейс PKCS#11 и на TPM 2.0. StrongSwan - проект с открытым исходным кодом. Демон  StrongSwan использует Internet Key Exchange protocols (IKEv1 и IKEv2) для шифрования между хостами. В связи с этим StrongSwan используется для организации VPN.

Прежде чем приступим к установке и настройке Сильного Лебедя необходимо заострить внимание на двух режимах работы: tunnel и transport.

tunnel mode:

В туннельном режиме шифруется весь исходный IP-пакет: данные, заголовок, маршрутная информация, а затем он вставляется в поле данных нового пакета, то есть происходит инкапсуляция. Туннельный режим может использоваться для подключения удалённых компьютеров к виртуальной частной сети или для организации безопасной передачи данных через открытые каналы связи (например, Интернет) между шлюзами для объединения разных частей виртуальной частной сети. Т.е. попрос туннелирования/инкапсуляции тут IPsec берет на себя.

tunnel mode
tunnel mode

В данной схеме IPsec настроен на R1 и R2. В терминологии StrongSwan R1 и R2 в такой топологии выступают как Gateways (Шлюзы). Подсети хостов 1 и 2 туннелируются на шлюзах и там же шифруются/расшифровываются пакеты.

Особенности туннельного режима:

  • Поддерживается обход NAT;
  • Добавляются дополнительные заголовки - уменьшается payload MSS.

MSS (Maximum segment size) - является параметром протокола TCP и определяет максимальный размер полезного блока данных в байтах для TCP-пакета.

Подробно о MSS и TCP читайте в моих статьях:

  • TCP/IP (Часть 1) просто о сложном
  • TCP/IP (Часть 2) просто о сложном # тут подробно об MSS
  • TCP/IP (Часть 3) просто о сложном
  • TCP/IP (Часть 4) просто о сложном

Вывод: tunnel mode используется тогда когда надо обеспечить защищенный канал между хостами на которых нет IPsec и обеспечить при этом туннелирование подсетей.

transport mode:

В транспортном режиме шифруются или подписываются только данные IP-пакета, исходный заголовок сохраняется. Транспортный режим, как правило, используется для установления соединения между хостами. Он может также использоваться между шлюзами для защиты туннелей, организованных каким-нибудь другим способом (например, L2TP или GRE (конкретно наш случай)).

Пример топологии, при которой оправдан transport mode:

transport mode
transport mode

Эта схема отражает самое явное отличие при котором используется transport mode - IPsec присутствует на конечных узлах между которыми шифруется трафик.

Частный случай, это когда на R1 и на R2 применяется протокол туннелирования (GRE, L2TP). Тогда схема будет похожа на сценарий при котором надо бы использовать tunnel mode, но так как трафик уже инкапсулирован, то целесообразно использовать transport mode.

Особенности транспортного режима:

  • Не поддерживается обход NAT, так как заголовок L3 уровня не скрывается;
  • MSS больше при транспортном режиме - меньше накладных расходов;
  • Site-to-site возможен в случае наличия на Gateways сторонних протоколов туннелирования (GRE, L2TP).

В нашем частном случае мы имеет ситуацию при которой настроен GRE. На уровне netplan и GRE туннеля осуществляется весь процесс маршрутизации. NAT работает на уровне netfilter. Остается только зашифровать payload. В таком случае идеально подойдет transport mode. Настроим его!

Далее описывается настройка StrongSwan на Ubuntu 20.04. Но  данные настройки актуальны и для других дистрибутивов Linux!

1.Обновляем систему:

sudo apt-get update && sudo apt-get upgrade

2.Устанавливаем StrongSwan и все необходимые для его работы плагины и библиотеки:

sudo apt install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-plugins libtss2-tcti-tabrmd0 -y

3.Генерируем ключи и сертификаты для сервера головного офиса:

3.1 Используя утилиту ipsec создадим приватный CA ключ:

sudo ipsec pki --gen --size 4096 --type rsa --outform pem > /etc/ipsec.d/private/ca.key.pem

3.2 Создадим root CA сертификат и подпишем его CA ключом сгенерированным на предыдущем шаге:

ipsec pki --self --in /etc/ipsec.d/private/ca.key.pem --type rsa --dn "CN=mainoffice.domain.tld" --ca --lifetime 3650 --outform pem > /etc/ipsec.d/cacerts/ca.cert.pem

В моей лабе CN=mainoffice.domain.tld, в вашей может отличаться. "CN=<Name of this VPN Server>"

В нашем примере --lifetime 3650 устанавливает срок актуальности сертификата равным 3650 дней (примерно 10 лет). Для продуктивной среды это будет слишком, но в лабе сойдет

4.Генерируем приватный ключ для сервера головного офиса:

ipsec pki --gen --size 4096 --type rsa --outform pem > /etc/ipsec.d/private/server.key.pem

5.Генерируем публичный сертификат сервера:

ipsec pki --pub --in /etc/ipsec.d/private/server.key.pem --type rsa | \
ipsec pki --issue --lifetime 3650 --cacert /etc/ipsec.d/cacerts/ca.cert.pem \
--cakey /etc/ipsec.d/private/ca.key.pem --dn "CN=mainoffice.domain.tld" \
--san="mainoffice.domain.tld" --flag serverAuth --flag ikeIntermediate --outform pem > /etc/ipsec.d/certs/server.cert.pem

По итогу должно получиться следующее:

-3

6.Переходим непосредственно к настройке StrongSwan:

Ядро Linux позволяет маршрутизировать пакеты между внутренними и внешними интерфейсами, но по умолчанию эта возможность отключена. Если на предыдущих шагах вы еще не настроили соответствующие опции, то стоит перепроверить содержание файла /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

7.Открываем файл /etc/ipsec.conf и настраиваем согласно скрина, с учетом вашей адресации:

-4

//---------------------Начало текста конфига ipsec.conf-----------------------------

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
charondebug="ike 1, knl 1, cfg 0, net 1" # Детализация логирования
strictcrlpolicy=no #Отключаем CRL
uniqueids=yes #ID участников должны быть уникальны
cachecrls=no #Отключаем возможность кеширования CRL

# Add connections here.
conn vpn1
auto=start #Запускать демон срузу при старте, не дожидаясь появление трафика, требующего шифрования
type=transport # Траспортный режим
compress=no #Отключаем сжатие
keyexchange=ike #ike - синоним для ikev2
fragmentation=yes # Если peer поддерживает и IKE сообщения большие, то допускается фрагментация. Размер определяется в strongswan.conf
forceencaps=no # Если "yes", то весь трафик будет инкапсулироваться в UDP. Если "no" - то только тот который попадает по NAT.
dpdaction=clear #DPD (Dead Peer Detection protocol) clear - по истечению dpddelay соединение закрывается, дальнейших действий не осуществяется
dpddelay=300s # Delay таймер по истечении которого соединение разрывается
rekey=no #Отключаем истечение ключевой информации для SA (Security Association) и пересогласование защищенного канала
leftid=@mainoffice.domain.tld #Идентификатор для аутентификации. @ - для предотвращения резолва в IP
rightid=%any
leftcert=server.cert.pem #Сертификат головного офиса
leftsendcert=always # Peer должен обязательно запрашивать сертификат - аутентификация шлюза головного офиса
rightsendcert=never # аутентификация подключающихся к головному шлюзу клиентов не требуется
left=192.168.31.209 # Public IP головного офиса. vpn1.local
right=192.168.31.118 # Public IP филиального офиса vpn1.remote
rightauth=eap-mschapv2 #Определят метод аутентификации
eap_identity=%identity #Запрашивать у клиента EAP идентификацию
rightprotoport=gre #на стороне головного офиса шифруется только GRE трафик
leftprotoport=gre #расшифровывается только входящий трафик GRE от филиального Gateway
ike=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
esp=chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1!

#ike - Перечень IKE/ISAKMP SA алгоритмов которые могут быть использованы
#esp - Перечень ESP алгоритмов которые могут быть использованы

# Sample VPN connections

#conn sample-self-signed
# leftsubnet=10.1.0.0/16
# leftcert=selfCert.der
# leftsendcert=never
# right=192.168.0.2
# rightsubnet=10.2.0.0/16
# rightcert=peerCert.der
# auto=start

#conn sample-with-ca-cert
# leftsubnet=10.1.0.0/16
# leftcert=myCert.pem
# right=192.168.0.2
# rightsubnet=10.2.0.0/16
# rightid="C=CH, O=Linux strongSwan CN=peer name"
# auto=start

//---------------------Конец текста конфига ipsec.conf-------------------------------

8.Заполняем креды для аутентификации, для этого открываем файл /etc/ipsec.secrets и  заполняем согласно скрина, с учетом вашей специфики:

Не забываем стартовать демон:

systemctl start strongswan-starter

-5

//---------------------Начало текста конфига ipsec.secrets--------------------------

# This file holds shared secrets or RSA private keys for authentication.

# RSA private key for this host, authenticating it to any other host
# which knows the public part.

: RSA "server.key.pem"
uservpn1 : EAP "password"
#another_username : EAP "<user’s password>"

//---------------------Конец текста конфига ipsec.secrets----------------------------

9.Смотрим на статус:

-6

10.Настраиваем StrongSwan на клиентской стороне:

sudo apt update && upgrade -y
sudo apt install strongswan libcharon-extra-plugins

Загружаем корневой сертификат CA (ca.cert.pem) в /etc/ipsec.d/cacerts/ либо вручную, либо с помощью scp.

11.Добавляем логин:пароль в файл /etc/ipsec.secrets:

-7

//---------------------Начало текста конфига ipsec.secrets--------------------------

# This file holds shared secrets or RSA private keys for authentication.

# RSA private key for this host, authenticating it to any other host
# which knows the public part.

uservpn1 : EAP "password"

//---------------------Конец текста конфига ipsec.secrets----------------------------

12.Открываем файл /etc/ipsec.conf и настраиваем его в соответствии с скрином:

-8

//---------------------Начало текста конфига ipsec.conf-----------------------------

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
# strictcrlpolicy=yes
# uniqueids = no

# Add connections here.
conn vpn1
auto=start
type=transport
right=mainoffice.domain.tld
rightid=%any
rightauth=pubkey
left=192.168.31.118
leftid=uservpn1
leftauth=eap-mschapv2
eap_identity=%identity


# Sample VPN connections

#conn sample-self-signed
# leftsubnet=10.1.0.0/16
# leftcert=selfCert.der
# leftsendcert=never
# right=192.168.0.2
# rightsubnet=10.2.0.0/16
# rightcert=peerCert.der
# auto=start

#conn sample-with-ca-cert
# leftsubnet=10.1.0.0/16
# leftcert=myCert.pem
# right=192.168.0.2
# rightsubnet=10.2.0.0/16
# rightid="C=CH, O=Linux strongSwan CN=peer name"
# auto=start
//---------------------Конец текста конфига ipsec.conf-------------------------------

13.Cтартуем клиента:

systemctl start strongswan-starter

14.Смотрим на статус на клиенте и на сервере:

sudo ipsec status или sudo ipsec statusall

-9
-10

Посмотрим online, что теперь происходит с трафиком, попадающим в GRE туннель:

-11

Соберу дамп icmp трафика на Ubuntu20_04_1 и покажу как выглядит структура заголовка шифрованных пакетов:

структура заголовка шифрованных пакетов
структура заголовка шифрованных пакетов

Постараемся максимально раскрыть все нюансы, присутствующие в конфигурационных настройках.

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

Authentication Header (АН) обеспечивает целостность передаваемых данных, аутентификацию источника информации и функцию по предотвращению повторной передачи пакетов

Internet Security Association and Key Management Protocol (ISAKMP) — протокол, используемый для первичной настройки соединения, взаимной аутентификации конечными узлами друг друга и обмена секретными ключами. Протокол предусматривает использование различных механизмов обмена ключами, включая задание фиксированных ключей, использование таких протоколов, как Internet Key Exchange (IKE), Kerberized Internet Negotiation of Keys (RFC 4430) или записей DNS типа IPSECKEY (RFC 4025).

Security Association (SA) - является набором параметров, характеризующим соединение. Например, используемые алгоритм шифрования и хеш-функция, секретные ключи, номер пакета и др.

В нашем случае присутствует в выводе команды show ipsec statusall - блок вывода Security Association.

Security Association

Для начала обмена данными между двумя сторонами необходимо установить соединение, которое носит название SA (Security Association). Концепция SA фундаментальна для IPsec, собственно, является его сутью. Она описывает, как стороны будут использовать сервисы для обеспечения защищённого общения. Соединение SA является симплексным (однонаправленным), поэтому для взаимодействия сторон необходимо установить два соединения. Стоит также отметить, что стандарты IPsec позволяют конечным точкам защищённого канала использовать как одно SA для передачи трафика всех взаимодействующих через этот канал хостов, так и создавать для этой цели произвольное число безопасных ассоциаций, например, по одной на каждое TCP-соединение. Это дает возможность выбирать нужную степень детализации защиты. Установка соединения начинается со взаимной аутентификации сторон. Далее происходит выбор параметров (будет ли осуществляться аутентификация, шифрование, проверка целостности данных) и необходимого протокола (AH или ESP) передачи данных. После этого выбираются конкретные алгоритмы (например, шифрования, хеш-функция) из нескольких возможных схем, некоторые из которых определены стандартом (для шифрования — DES, для хеш-функций — MD5 либо SHA-1/2), другие добавляются производителями продуктов, использующих IPsec (например Triple DES, Blowfish, CAST, StrongSwan).

EAP (Extensible Authentication Protocol, Расширяемый Протокол Аутентификации) — фреймворк аутентификации, который часто используется в беспроводных сетях и соединениях точка-точка. Формат был впервые описан в RFC 3748 и обновлён в RFC 5247.

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

EAP довольно популярный формат, он используется в IEEE 802.11 (WiFi), около ста методов EAP из IEEE 802.1X были приняты в качестве официальных механизмов аутентификации в стандартах WPA и WPA2.

Взглянем на это процесс изнутри собрав dump трафика в момент установки SA между R2 и R1.

-13

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

О том что такое ассиметричное и симметричное шифрование я писал достаточно подробно.

Вот мои стать если необходимо быстро понять общий принцип и основные важные концептуальные моменты:

  1. Хеширование информации;
  2. Электронная цифровая подпись;
  3. Nonce числа. Аутентификация client - server;

Более подробно о том как проистекает процесс установления SA можно узнать используя команду tail -f /var/log/syslog | grep ipsec на стороне сервера главного офиса. Данную команду стоит запустить на сервере и в режиме реального времени вы увидите на стандартном потоке вывода подробную информацию о попытках установить соединение между клиентом и сервером. Если что-то настроено не так, то вы почти 100% увидите индикаторы проблем. Ну а как выглядит процесс без ошибок смотрите на скрине:

-14

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

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

В описание типа подключения можно заметить, что есть варианты не только tunnel|transport о котором мы говорили...

-15

На этом обзорная экскурсия по IPsec и StrongSwan заканчивается. Подробное изучение остается в качестве домашней работы (если в этом есть необходимость).

По StrongSwan я уже упоминал есть подробная документация с wiki: ссылка

Если есть желание подробнее вникнуть в сам IPsec, то вот предлагаемая литература:

  1. Дуглас Э.Камер - признанный в мире специалист по протоколу TCP/IP и Internet. Книга - "Сети TCP/IP", Глава 32 - "Безопасность в объединённой сети и брандмауэры (IPsec)
  2. Блог AntiCisco, учебное пособие Фёдорова С.А. В данном пособии три части: I - Теоретическая база. Алгоритмы, II - Реализация алгоритмов и протоколов, III - IPSec.

На этом курс Сети и безопасность в Linux завершается. Тема сетей и безопасности в Linux безгранична. Я ставил целью познакомить вас базовыми концептами. Надеюсь материал будет полезен! Поддержите лайком и комментарием! Спасибо и до новых встреч.