Построение сетевой архитектуры на базе криптошлюза S-Terra c инициализацией IPsec на сертификатах

1. Введение

Описание продукта

Программно-аппаратный комплекс «С-Терра Шлюз» выполняет функции межсетевого экрана, средства криптографической защиты информации и маршрутизатора. С-Терра Шлюз обеспечивает создание виртуальных защищенных сетей (VPN), защиту транзитного трафика между различными узлами сети, защиту трафика самого шлюза безопасности, а также stateless фильтрацию IP-трафика и stateful фильтрацию для протоколов TCP и FTP.

Состав макета

Макет создан на базе физических устройств:

• Коммутатор Cisco Catalyst 2960

• 2 Криптошлюза S-Terra

• 2 АРМа Пользователей

Цели и задачи макетирования

Целью создания макета является ознакомление с функционалом КШ S-Terra и с принципами их взаимодействия при построении между ними зашифрованного IPsec туннеля на сертификатах.

Задачи макетирования:

• Конфигурация криптошлюзов S-Terra

• Конфигурация интерфейсов и VLAN-ов на коммутаторе Cisco

• Загрузка и регистрация удостоверяющего и локального сертификатов с помощью тестового УЦ (от "Газинформсервиса")

• Создание и настройка политик безопасности, установление IPsec туннеля

• Проверка протекания трафика между АРМ1 и АРМ2 по IPsec туннелю и работы политик безопасности

2. Выполнение задач макетирования

Конфигурация криптошлюзов S-Terra

Далее рассматривается работа на предустановленном заводском ПО, поставляемым вместе с лицензией S-Terra.

После загрузки ОС требуется ввод логина и пароля (по умолчанию: Логин – root; Пароль – пустой)

Система ждет инициализации, для которой нужно активировать скрипт указанной командой:

/opt/VPNagent/bin/init.sh

Далее вводим с подключённой клавиатуры генерируемые символы (устройство так синхронизируется с периферией и параллельно составляет случайные кодовые последовательности для своих нужд) – регистр учитывается.
После успешной инициализации (вывода сообщения «Successfully initialized RNG») необходимо вручную ввести данные лицензии, написанные на бланке документации, поставляемой вместе с пакетом S-Terra: код лицензии, номер лицензии, код пользователя, код организации и т.д.

После успешного ввода наблюдаем запуск демонов VPN и IPsec, ещё немного служебной информации, и можем приступать к работе.

На этом настройка для КШ S-Terra1 закончена.

Отключим МСЭ (межсетевой экран) на время настройки командой:

dp_mgr set –ddp passall

Теперь обновим пароли:

passwd

Дважды вводим новый пароль для Unix.
Далее перейдём в консоль:

cs_console  - переход в режим консоли
en          - переход в расширенный режим (пароль csp)
conf t      - переход в режим конфигурации

Создаём пользователя с привилегией и паролем:

 username имя_пользователя privilege 15 secret 0 пароль_пользователя

Далее после выхода из режима конфигурации (но оставаясь в консоли) настроим интерфейсы при помощи команд:

int имя_интерфейса
ip add ip_адрес маска_сети
no shutdown exit

Таким образом настраиваем все необходимые интерфейсы и назначаем им ip-адреса.

Также задаём адрес шлюза по умолчанию в режиме конфигурации при помощи команды
(эта команда предназначена для КШ S-Terra1 – так как 10.10.1.2 является соседним адресом S-Terra2 для S-Terra1, и указанной командой мы разрешаем любой трафик в этом направлении):

 ip route 0.0.0.0 0.0.0.0 10.10.1.2

Аналогично указываем шлюз по умолчанию для второго КШ, изменяя адрес следования на адрес интерфейса противоположного КШ.

Хоть S-Terra сама сохраняет конфигурацию после двойного выхода из консоли, для надёжности можно прописывать команду:

write memory

Это принудительное сохранение текущей конфигурации.

Аналогичные манипуляции проводим и со вторым КШ S-Terra, задаём на интерфейсы необходимые ip-адреса.

Проблема:

При настройке S-Terra возникла ситуация нераспознанных интерфейсов, которые были определены самим КШ как «виртуальные». Такие интерфейсы отображались в выводе конфигурации (show run), но не являлись физическими, из-за чего их можно было настраивать, но нельзя было использовать.

Для решения проблемы было необходимо в файле сетевой настройки самого КШ сопоставить виртуальный адрес с физическим шлюзом (главное – не путать обозначения интерфейсов).

Конфигурация интерфейсов и VLAN-ов на коммутаторе

Подключившись к коммутатору через консольный порт, начинаем его настройку: создаём VLAN-ы и подвязываем на них интерфейсы.
Команды:

vlan 10                             - создать VLAN 10 
int название_интерфейса             - заходим на интересующий интерфейс
switchport mode access              - перевод порта в 
switchport access vlan номер_vlan   - подвязка порта на указанный VLAN

Так как на коммутаторе по умолчанию все порты подняты, нет необходимости писать no shutdown.
Таким же образом настроим второй VLAN.
Для проверки правильности оформления VLAN-ов можно вывести таблицу виртуальных сетей командой:

sh vlan

Загрузка и регистрация удостоверяющего и локального сертификатов с помощью тестового УЦ

В данном макете для установления защищённого соединения между двумя КШ по технологии IPsec планируется использовать сертификаты. Для этого их необходимо запросить, а после зарегистрировать на КШ. Все действия будем производить через тестовый Удостоверяющий Центр от компании "Газинформсервис" – далее «УЦ».
Ссылка на используемый УЦ:

http://testca.gaz-is.ru/

Для корректного формирования запросов на КШ необходимо в первую очередь установить и зарегистрировать удостоверяющий (доверенный) сертификат УЦ. После этого можно запрашивать локальный сертификат, который после выдачи в УЦ также необходимо будет установить и зарегистрировать на КШ.
Для дальнейшей работы рекомендуется подключиться к КШ по SSH.

Последующие шаги рекомендуется выполнять в данном порядке (пример для КШ S-Terra1):

⦁ Устанавливаем правильное системное время:

date ‑s “07/20/2023 16:50”

⦁ Создаём папку certs:

mkdir /certs

⦁ На удалённом УЦ скачиваем доверенный сертификат, переносим его в созданную папку на КШ (например, можно использовать флешку, или портативный образ winSCP)

Для флешки:

⦁ Создаём директорию для монтирования:

mkdir /mnt/usb

⦁ Открываем список всех подключенных устройств:

ls /dev/sd*

⦁ Вставляем флешку в usb-порт
⦁ Повторяем подключённые устройства:

ls /dev/sd*

⦁ Появившаяся запись с цифрой – наша флешка
⦁ Монтируем флешку в директорию:

mount /dev/sd_флешки /mnt/usb

⦁ Копируем сертификат в папку certs:

cp /mnt/usb/путь_к_сертификату.cer /certs

⦁ Регистрируем загруженный сертификат с помощью утилиты cert_mgr (в данном случае
-t означает удостоверяющий сертификат):

cert_mgr import -f /certs/наш_сертификат.cer -t

⦁ Формируем запрос на локальный сертификат (параметр CN отвечает за название файла, можно поменять его под желаемое):

cert_mgr create -subj "C=RU,O=S-Terra CSP,OU=Research,CN=GW1" - GOST_R341012_256 -f /home/gw_req

Ключ -GOST_R341012_256 предполагает использование ГОСТ Р 34.10-2012. На УЦ для его поддержки должно быть установлено СКЗИ «КриптоПро CSP» версии 4.0 или новее. При необходимости есть возможность использовать старый алгоритм (ГОСТ Р 34.10-94), который задается ключом -GOST_R3410EL.

⦁ Переносим файл gw_req в окно формирования сертификата в УЦ (перенос при помощи флешки//winSCP), созданный сертификат также загружаем в /certs

⦁ Регистрируем локальный сертификат:

cert_mgr import -f /certs/GW1.cer

⦁ проверим регистрацию сертификатов:

cert_mgr show

Вывод должен быть примерно следующим (здесь нас интересуют состояния "trusted" и "local"):

Found 3 certificates. No CRLs found.
1 Status: trusted 1.2.840.113549.1.9.1=resp@gaz-is.ru, C=RU,L=\d0\a1\d0\9f\d0\b5\d1\82\d0\b5\d1\80\d0\b1\d1\83\d1\80\d0\b3,O=\d0\93\d0\90\d0\97\d0\98\d0\9d\d0\a4\d0\9e\d0\a0\d0\9c\d0\a1\d0\95\d0\a0\d0\92\d0\98\d0\a1,OU=IT,CN=\d0\a2\d0\b5\d1\81\d1\82\d0\be\d0\b2\d1\8b\d0\b9 \d1\83\d0\b4\d0\be\d1\81\d1\82\d0\be\d0\b2\d0\b5\d1\80\d1\8f\d1\8e\d1\89\d0\b8\d0\b9 \d1\86\d0\b5\d0\bd\d1\82\d1\80 \d0\93\d0\90\d0\97\d0\98\d0\9d\d0\a4\d0\9e\d0\a0\d0\9c\d0\a1\d0\95\d0\a0\d0\92\d0\98\d0\a1,2.5.4.5=198096,STREET=\d1\83\d0\bb. \d0\9a\d1\80\d0\be\d0\bd\d1\88\d1\82\d0\b0\d0\b4\d1\82\d1\81\d0\ba\d0\b0\d1\8f, \d0\b4.10, \d0\bb\d0\b8\d1\82\d0\b5\d1\80\d0\b0 \d0\90
2 Status: local C=RU,OU=Sales,CN=GW1
3 Status: local C=RU,OU=Test,CN=GW2

Если состояния определены, переходим дальше.

⦁ проверим работу сертификатов командой:

cert_mgr check

Вывод должен быть примерно следующим (здесь нас интересуют состояния "Active".):

1 State: Active 1.2.840.113549.1.9.1=resp@gaz-is.ru,C=RU,L=\d0\a1-\d0\9f\d0\b5\d1\82\d0\b5\d1\80\d0\b1\d1\83\d1\80\d0\b3,O=\d0\93\d0\90\d0\97\d0\98\d0\9d\d0\a4\d0\9e\d0\a0\d0\9c\d0\a1\d0\95\d0\a0\d0\92\d0\98\d0\a1,OU=IT,CN=\d0\a2\d0\b5\d1\81\d1\82\d0\be\d0\b2\d1\8b\d0\b9 \d1\83\d0\b4\d0\be\d1\81\d1\82\d0\be\d0\b2\d0\b5\d1\80\d1\8f\d1\8e\d1\89\d0\b8\d0\b9 \d1\86\d0\b5\d0\bd\d1\82\d1\80 \d0\93\d0\90\d0\97\d0\98\d0\9d\d0\a4\d0\9e\d0\a0\d0\9c\d0\a1\d0\95\d0\a0\d0\92\d0\98\d0\a1,2.5.4.5=198096,STREET=\d1\83\d0\bb. \d0\9a\d1\80\d0\be\d0\bd\d1\88\d1\82\d0\b0\d0\b4\d1\82\d1\81\d0\ba\d0\b0\d1\8f, \d0\b4.10, \d0\bb\d0\b8\d1\82\d0\b5\d1\80\d0\b0 \d0\90
2 State: Active C=RU,OU=Sales,CN=GW1
3 State: Active C=RU,OU=Test,CN=GW2

Если все сертификаты активны - их установка и инициализация выполнены успешно.
Можно переходить к следующему этапу.

Проблемы:

1. При прохождении этого шага возникла ошибка – локальный сертификат определялся как «удалённый» (remote), что не позволяло двигаться дальше. Это произошло из-за того, что запрос на локальный сертификат был сделан до загрузки и регистрации удостоверяющего сертификата.

   Вывод со стенда:

   root@sterragate:~# cert_mgr show
   Found 3 certificates. No CRLs found.
   1 Status: trusted 1.2.840.113549.1.9.1=resp@gaz-is.ru, C=RU,L=\d0\a1\d0\9f\d0\b5\d1\82\d0\b5\d1\80\d0\b1\d1\83\d1\80\d0\b3,O=\d0\93\d0\90\d0\97\d0\98\d0\9d\d0\a4\d0\9e\d0\a0\d0\9c\d0\a1\d0\95\d0\a0\d0\92\d0\98\d0\a1,OU=IT,CN=\d0\a2\d0\b5\d1\81\d1\82\d0\be\d0\b2\d1\8b\d0\b9 \d1\83\d0\b4\d0\be\d1\81\d1\82\d0\be\d0\b2\d0\b5\d1\80\d1\8f\d1\8e\d1\89\d0\b8\d0\b9 \d1\86\d0\b5\d0\bd\d1\82\d1\80 \d0\93\d0\90\d0\97\d0\98\d0\9d\d0\a4\d0\9e\d0\a0\d0\9c\d0\a1\d0\95\d0\a0\d0\92\d0\98\d0\a1,2.5.4.5=198096,STREET=\d1\83\d0\bb. \d0\9a\d1\80\d0\be\d0\bd\d1\88\d1\82\d0\b0\d0\b4\d1\82\d1\81\d0\ba\d0\b0\d1\8f, \d0\b4.10, \d0\bb\d0\b8\d1\82\d0\b5\d1\80\d0\b0 \d0\90
   2 Status: local C=RU,OU=Sales,CN=GW1
   3 Status: remote C=RU,OU=Test,CN=GW2

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

2. По ГОСТу при формировании запроса на удостоверяющий сертификат на месте ключа -f должен был быть ключ -fb64, но при его использовании нарушалась целостность файла запроса, и УЦ не мог его обработать (это, скорее, частный случай, но имел место быть).

   
   Решением проблемы стала замена ключа -fb64 на -f.

Создание и настройка политик безопасности, установление IPsec туннеля

Настройки политик безопасности производятся при помощи криптокарт. Задействуются такие технологии, как IKE, ISAKMP, IPsec, алгоритмы хеширования и различные ГОСТы.

Рекомендуемый порядок выполнения (для S-Terra1):

⦁ Переходим в консоль:

cs_console

⦁ Расширенный режим:

enable (вводим пароль, по умолчанию csp)

⦁ Зададим тип идентификации:

crypto isakmp identity dn (для идентификации будет использовано поле DN сертификата)

⦁ Зададим параметры DPD (dead peer detection):

 crypto isakmp keepalive 10 2 
 crypto isakmp keepalive retry-count 5

Такая настройка задаёт условие - если в течение 10 секунд отсутствует входящий трафик в IPsec туннеле, то с интервалом в 2 секунды посылается 5 keepalive-пакетов в IKE туннель (туннель, по которому IKE передаёт ключи авторизации), чтобы удостовериться в работоспособности туннеля IPsec. Если партнёр не отвечает на keepalive-пакеты, то существующий IKE туннель переходит в состояние disabled, а связанные с ним IPsec туннели удаляются. В случае наличия исходящего трафика происходит попытка создать новый IKE туннель.

⦁ Настроим параметры IKE:

crypto isakmp policy 1  - создаём политику ISAKMP под номером 1 
authentication gost-sig - назначаем ГОСТ аутентификации 
encr gost               - назначаем ГОСТ шифрования 
hash gost               - назначаем ГОСТ хеширования 
group vko               - задаём алгоритм формирования ключей IKE

⦁ Задаём параметры для IPsec:

crypto ipsec transform-set TSET esp-gost28147-4m-imit

Этим мы формируем набор параметров IPsec под названием TSET, который работает по алгоритмам в расширении ГОСТа, который мы указали - esp-gost28147-4m-imit

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

⦁ Создадим расширенный список доступа:

ip access-list extended LIST 
permit ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255

Здесь мы создаём расширенный список доступа под названием LIST и указываем, какой трафик разрешён (в нашем случае – из сети АРМ1 в сеть АРМ2)

⦁ Создаём крипто-карту:

crypto map CMAP 1 ipsec-isakmp  - создание криптокарты CMAP 
match address LIST              - применяем политику созданного списка доступа 
set transform-set TSET          - применяем набор параметров IPsec – ISAKMP под названием TSET 
set peer 10.10.1.2              - задаём пир (адрес шлюза соседнего КШ)

⦁ Привяжем крипто-карту к интерфейсу, на котором будет туннель:

interface GigabitEthernet 0/1 
crypto map CMAP

⦁ Отключим службу CRL, так как в стенде он не нужна:

revocation-check none

Аналогичную настройку необходимо провести на втором КШ, учитывая указываемые адреса для списка доступа, маршрутов, пиров и т.д.

Примечание:

Если во время работы на одном из КШ криптокарта была отвязана от интерфейса, из-за чего при проверке не будет создан туннель, проблема не отобразится в логах, так как это корректная инструкция для КШ, но неправильная настройка с точки зрения логики задачи. При возникновении проблем с подключением рекомендуется внимательно проверить все настройки перед их изменением.

Проверка протекания трафика между АРМ1 и АРМ2 по IPsec туннелю и работы политик безопасности

Перед началом тестирования туннеля необходимо настроить АРМы:

• задать адреса внутри сети

• задать шлюз по умолчанию – адрес интерфейса соседствующего КШ S-Terra

  После этого можно приступать к тестированию. Заходим на АРМ1 и формируем трафик icmp запросов к другому АРМу при помощи команды:

ping -t ip_адрес_АРМ1 ip_адрес_АРМ2

Вывод со стенда (здесь нам важно увидеть время прохождения пинга, оно подтверждает рабочее состояние канала трафика):

ping 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes
from 192.168.1.1: icmp_req=1 ttl=62 time=1121 ms 64 bytes from
192.168.1.1: icmp_req=2 ttl=62 time=115 ms 64 bytes from
192.168.1.1: icmp_req=3 ttl=62 time=0.412 ms 64 bytes from
192.168.1.1: icmp_req=4 ttl=62 time=0.440 ms 64 bytes from
...

Как видим, трафик успешно проходит, а значит в результате выполнения команды между двумя КШ был успешно установлен VPN туннель.

Убедиться в этом можно введя на КШ команду:

sa_mgr show

Вывод со стенда:

root@sterragate:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 44 (10.10.1.3,500)-(10.10.1.2,500) active 3032 2952

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 3 (192.168.0.0-192.168.0.255,)-(192.168.1.0-192.168.1.255,) * ESP tunn 288 0
2 4 (192.168.0.0-192.168.0.255,)-(192.168.1.0-192.168.1.255,) * ESP tunn 63560 73856

Вывод показывает, что ISAKMP работает, а IPsec туннель поднят и проводит трафик.
Задачи выполнены!

3. Заключение

В ходе выполнения макетирования был реализован сценарий установления шифрованного IPsec туннеля на сертификатах между криптошлюзами S-TERRA с применением технологий безопасности на основе ГОСТов. Было успешно проведено тестирование работоспособности стенда и настроенных политик безопасности. Все поставленные задачи выполнены.

Данная статья создана с ознакомительной целью и не претендует на звание эталонной - допускаются неточности и ошибки в определениях и в использовании терминов. В основу заложен учебный проект сетевой архитектуры на базе криптошлюза S-Terra.

P.S. Это моя первая серьёзная статья, поэтому жду от Вас комментарии и предложения по улучшению последующих работ.

Для более глубокого ознакомления с технологией IPsec могу порекомендовать следующие статьи:

• https://habr.com/ru/companies/xakep/articles/256659/

• https://habr.com/ru/articles/518116/