1. Введение
1.1 Описание продукта
Программно-аппаратный комплекс «С-Терра Шлюз» выполняет функции межсетевого экрана, средства криптографической защиты информации и маршрутизатора. С-Терра Шлюз обеспечивает создание виртуальных защищенных сетей (VPN), защиту транзитного трафика между различными узлами сети, защиту трафика самого шлюза безопасности, а также stateless фильтрацию IP-трафика и stateful фильтрацию для протоколов TCP и FTP.
1.2 Состав макета
Макет создан на базе физических устройств:
Коммутатор Cisco Catalyst 2960
2 Криптошлюза S-Terra
2 АРМа Пользователей
1.3 Цели и задачи макетирования
Целью создания макета является ознакомление с функционалом КШ S-Terra и с принципами их взаимодействия при построении между ними зашифрованного IPsec туннеля на сертификатах.
Задачи макетирования:
Конфигурация криптошлюзов S-Terra
Конфигурация интерфейсов и VLAN-ов на коммутаторе Cisco
Загрузка и регистрация удостоверяющего и локального сертификатов с помощью тестового УЦ (от "Газинформсервиса")
Создание и настройка политик безопасности, установление IPsec туннеля
Проверка протекания трафика между АРМ1 и АРМ2 по IPsec туннелю и работы политик безопасности
2. Выполнение задач макетирования
2.1 Конфигурация криптошлюзов 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), но не являлись физическими, из-за чего их можно было настраивать, но нельзя было использовать.
Для решения проблемы было необходимо в файле сетевой настройки самого КШ сопоставить виртуальный адрес с физическим шлюзом (главное – не путать обозначения интерфейсов).
2.2 Конфигурация интерфейсов и VLAN-ов на коммутаторе
Подключившись к коммутатору через консольный порт, начинаем его настройку: создаём VLAN-ы и подвязываем на них интерфейсы.
Команды:
vlan 10 - создать VLAN 10
int название_интерфейса - заходим на интересующий интерфейс
switchport mode access - перевод порта в режим доступа
switchport access vlan номер_vlan - подвязка порта на указанный VLAN
Так как на коммутаторе по умолчанию все порты подняты, нет необходимости писать no shutdown.
Таким же образом настроим второй VLAN.
Для проверки правильности оформления VLAN-ов можно вывести таблицу виртуальных сетей командой:
sh vlan
2.3 Загрузка и регистрация удостоверяющего и локального сертификатов с помощью тестового УЦ
В данном макете для установления защищённого соединения между двумя КШ по технологии IPsec планируется использовать сертификаты. Для этого их необходимо запросить, а после зарегистрировать на КШ. Все действия будем производить через тестовый Удостоверяющий Центр от компании "Газинформсервис" – далее «УЦ».
Ссылка на используемый УЦ:
Для корректного формирования запросов на КШ необходимо в первую очередь установить и зарегистрировать удостоверяющий (доверенный) сертификат УЦ. После этого можно запрашивать локальный сертификат, который после выдачи в УЦ также необходимо будет установить и зарегистрировать на КШ.
Для дальнейшей работы рекомендуется подключиться к КШ по 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
Если все сертификаты активны - их установка и инициализация выполнены успешно.
Можно переходить к следующему этапу.
Проблемы:
При прохождении этого шага возникла ошибка – локальный сертификат определялся как «удалённый» (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Решением проблемы (как описано выше) является последовательная загрузка и регистрация сначала удостоверяющего, а потом локального сертификатов.
По ГОСТу при формировании запроса на удостоверяющий сертификат на месте ключа -f должен был быть ключ -fb64, но при его использовании нарушалась целостность файла запроса, и УЦ не мог его обработать (это, скорее, частный случай, но имел место быть).
Решением проблемы стала замена ключа -fb64 на -f.
2.4 Создание и настройка политик безопасности, установление 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
Аналогичную настройку необходимо провести на втором КШ, учитывая указываемые адреса для списка доступа, маршрутов, пиров и т.д.
Примечание:
Если во время работы на одном из КШ криптокарта была отвязана от интерфейса, из-за чего при проверке не будет создан туннель, проблема не отобразится в логах, так как это корректная инструкция для КШ, но неправильная настройка с точки зрения логики задачи. При возникновении проблем с подключением рекомендуется внимательно проверить все настройки перед их изменением.
2.5 Проверка протекания трафика между АРМ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 respondedISAKMP 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 2952IPsec 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 могу порекомендовать следующие статьи: