Если ваша компания передаёт или получает по сети персданные и другую конфиденциальную информацию, подлежащую защите в соответствии с законодательством, требуется применять шифрование по ГОСТу. Сегодня мы расскажем, как внедрили такое шифрование на базе криптошлюза (КШ) S-Terra у одного из заказчиков. Эта история будет интересна ИБ-специалистам, а также инженерам, проектировщикам и архитекторам. Глубоко погружаться в нюансы технической конфигурации в данном посте мы не будем — остановимся на ключевых моментах базовой настройки. Огромные объемы документации по настройке демонов ОС Linux, на которой базируется КШ S-Terra, есть в свободном доступе в интернете. Документация по настройке проприетарного ПО S-Terra располагается также в открытом доступе на портале производителя.
Пара слов о проекте
Топология сети у заказчика была типовая — full mesh между центром и филиалами. Требовалось внедрить шифрование каналов обмена информацией между всеми площадками, коих было 8 штук.
Обычно в подобных проектах всё статично: на криптошлюзах (КШ) задаются статические маршруты в локальную сеть площадки, прописываются списки IP-адресов (ACL) для шифрования. Однако в данном случае у площадок нет централизованного управления, и внутри их локальных сетей может происходить всё, что угодно: сети могут добавляться, удаляться и всячески модифицироваться. Для того чтобы избежать перенастройки маршрутизации и ACL на КШ при изменении адресации локальных сетей на площадках, было принято решение использовать GRE-туннелирование и динамическую маршрутизацию OSPF, в которую включены все КШ и большинство маршрутизаторов уровня ядра сети на площадках (на некоторых площадках администраторы инфраструктуры предпочли использовать SNAT в сторону КШ на маршрутизаторах ядра).
GRE-туннелирование позволило решить две задачи:
1. Использовать в ACL для шифрования IP-адрес внешнего интерфейса КШ, в котором инкапсулируется весь трафик, направляющийся на другие площадки.
2. Организовать p-t-p туннели между КШ, которые позволяют настроить динамическую маршрутизацию (в нашем случае между площадками организован провайдерский MPLS L3VPN).
Клиент заказал реализацию шифрования как услугу. Иначе ему пришлось бы не просто поддерживать криптошлюзы или сдавать в аутсорс какой-то организации, но и самостоятельно отслеживать жизненный цикл сертификатов шифрования, вовремя их продлевать и устанавливать новые.
А теперь собственно памятка – как и что мы настраивали
Субъекту КИИ на заметку: настраиваем криптошлюз
Базовая настройка сети
Прежде всего запускаем новый КШ и попадаем в консоль администрирования. Начать стоит с изменения пароля встроенного администратора — команда change user password administrator. Затем необходимо с провести процедуру инициализации (команда initialize) в процессе которой вводятся данные лицензии и инициализируется датчик случайных чисел (ДСЧ).
Обратите внимание! При инициализации КШ S-Terra устанавливается политика безопасности, при которой интерфейсы шлюза безопасности не пропускают пакеты. Необходимо либо создать собственную политику, либо с помощью команды run csconf_mgr activate выполнить активацию предустановленной разрешающей политики.
Далее необходимо настроить адресацию внешних и внутренних интерфейсов, а также маршрут по умолчанию. Работу с сетевой конфигурацией КШ и настройку шифрования предпочтительно выполнять через Cisco-like консоль. Данная консоль предназначена для ввода команд, аналогичных командам Cisco IOS. Конфигурация, сформированная с помощью Cisco-like консоли, в свою очередь конвертируется в соответствующие конфигурационные файлы, с которыми работают демоны ОС. Перейти в Cisco-like консоль из консоли администрирования можно командой configure.
Меняем пароли на встроенного пользователя cscons и enable:
>enable
Password: csp(предустановленный)
#configure terminal
#username cscons privilege 15 secret 0 #enable secret 0 Настраиваем базовую сетевую конфигурацию:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#no shutdown
#interface GigabitEthernet0/1
#ip address 192.168.2.5 255.255.255.252
#no shutdown
#ip route 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Выходим из Cisco-like консоли, и переходим в debian shell командой system. Устанавливаем собственный пароль для пользователя root командой passwd.
На каждом КШ настраивается отдельный туннель для каждой площадки. Настройка туннельного интерфейса производится в файле /etc/network/interfaces. За создание самого интерфейса отвечает утилита IP tunnel, входящая в предустановленный набор iproute2. Команда создания интерфейса прописывается в опцию pre-up.
Пример конфигурации типового туннельного интерфейса:
auto site1
iface site1 inet static
address 192.168.1.4
netmask 255.255.255.254
pre-up ip tunnel add site1 mode gre local 10.111.21.3 remote 10.111.22.3 key hfLYEg^vCh6p
Обратите внимание! Надо заметить, что настройки туннельных интерфейсов необходимо располагать вне секции
###netifcfg-begin###
*****
###netifcfg-end###
В противном случае данные настройки будут затерты при изменении сетевых настроек физических интерфейсов через Cisco-like консоль.
Динамическая маршрутизация
В S-Terra динамическая маршрутизация реализуется при помощи пакета программ Quagga. Для настройки OSPF нам потребуются включение и настройка демонов zebra и ospfd. Демон zebra отвечает за взаимодействие между демонами маршрутизации и ОС. Демон ospfd, как понятно из названия, отвечает за реализацию протокола OSPF.
Настройка OSPF производится либо через консоль демона, либо напрямую через конфигурационный файл /etc/quagga/ospfd.conf. В файл добавляются все физические и туннельные интерфейсы участвующие в динамической маршрутизации, а также объявляются сети, которые будут анонсироваться и принимать анонсы.
Пример конфигурации, которую требуется добавить в ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface site2
router ospf
ospf router-id 192.168.2.21
network 192.168.1.4/31 area 0.0.0.0
network 192.168.1.16/31 area 0.0.0.0
network 192.168.2.4/30 area 0.0.0.0
В данном случае адреса 192.168.1.х/31 отведены под туннельные ptp-сети между площадками, адреса 192.168.2.х/30 — под транзитные сети между КШ и маршрутизаторами ядра.
Обратите внимание! Для уменьшения таблицы маршрутизации в крупных инсталляциях можно отфильтровать анонсирование самих транзитных сетей с помощью конструкций no redistribute connected или redistribute connected route-map.
После настройки демонов необходимо изменить статус запуска демонов в /etc/quagga/daemons. В опциях zebra и ospfd no исправить на yes. Запустить демон quagga и установить его автозапуск при запуске КШ командой update-rc.d quagga enable.
Если настройка GRE-туннелей и OSPF выполнена верно, то на КШ и маршрутизаторах ядра должны появится маршруты в сети остальных площадок и, таким образом, возникает сетевая связность между локальными сетями.
Шифруем передаваемый трафик
Как уже было написано, обычно при шифровании между площадками мы указываем диапазоны IP-адресов (ACL), между которыми шифруется трафик: если адреса источника и получателя попадают в эти диапазоны, то трафик между ними шифруется. Однако в данном проекте структура динамическая и адреса могут меняться. Так как мы уже настроили GRE-туннелирование, в качестве адресов источника и получателя для шифрования трафика можем указать внешние адреса КШ — ведь для шифрования приходит трафик, уже инкапсулированный протоколом GRE. Иными словами, шифруется всё, что попадает в КШ из локальной сети одной площадки в сторону сетей, которые были анонсированы другими площадками. А уже внутри каждой из площадок может выполняться любая переадресация. Таким образом, при каком-либо изменении локальных сетей администратору достаточно модифицировать анонсы, идущие из его сети в сторону КШ, и она станет доступной для других площадок.
Шифрование в КШ S-Terra выполняется посредством протокола IPSec. Мы используем алгоритм «Кузнечик» в соответствии с ГОСТ Р 34.12-2015, а для совместимости со старыми версиями можно применить ГОСТ 28147-89. Аутентификация технически может выполняться как на предопределенных ключах (PSK), так и на сертификатах. Тем не менее в промышленной эксплуатации необходимо использовать сертификаты, выпущенные по ГОСТ Р 34.10-2012.
Работа с сертификатами, контейнерами и CRL выполняется с помощью утилиты cert_mgr. Первым делом с помощью команды cert_mgr create необходимо сформировать контейнер закрытого ключа и запрос на сертификат, который будет направлен в Центр управления сертификатами. После получения сертификата его вместе с корневым сертификатом УЦ и CRL (если используется) необходимо импортировать командой cert_mgr import. Убедиться в том, что все сертификаты и CRL установились можно командой cert_mgr show.
После успешной установки сертификатов переходим в Cisco-like консоль для настройки IPSec.
Создаем IKE-политику, в которой указываются желаемые алгоритмы и параметры создаваемого защищенного канала, которые будут предложены партнеру для согласования.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Данная политика применяется при построении первой фазы IPSec. Результатом успешного прохождения первой фазы служит установление SA (Security Association).
Далее нам потребуется определить список IP-адресов источника и получателя (ACL) для шифрования, сформировать набор преобразований (transform set), создать криптографическую карту (crypto map) и привязать ее к внешнему интерфейсу КШ.
Задаем ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Набор преобразований (так же, как и для первой фазы, используем алгоритм шифрования «Кузнечик» с использованием режима выработки имитовставки):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Создаем криптокарту, указываем ACL, transform set и адрес пира:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Привязываем криптокарту к внешнему интерфейсу КШ:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Для шифрования каналов с другими площадками необходимо повторить процедуру создания ACL и криптокарты, изменив название ACL, IP-адреса и номер криптокарты.
Обратите внимание! В том случае, если не используется проверка сертификатов по CRL, это необходимо явно указать:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
На этом настройку можно считать завершенной. В выводе команд Cisco-like консоли show crypto isakmp sa и show crypto ipsec sa должны отражаться построенные первые и вторые фазы IPSec. Эту же информацию можно получить с помощью команды sa_mgr show, выполненной из debian shеll. В выводе команды cert_mgr show должны появиться сертификаты удаленных площадок. Статус таких сертификатов будет remote. В том случае если туннели не строятся, необходимо заглянуть в лог VPN-сервиса, который хранится в файле /var/log/cspvpngate.log. Полный список лог-файлов с описанием их содержания присутствует в документации.
Мониторим «здоровье» системы
В КШ S-Terra для мониторинга используется стандартный демон snmpd. Помимо типичных для Linux параметров, S-Terra «из коробки» поддерживает выдачу данных об IPSec-туннелях согласно CISCO-IPSEC-FLOW-MONITOR-MIB, чем мы и пользуемся, отслеживая состояние IPSec-туннелей. Также поддерживается функционал кастомных OID’ов выдающих в качестве значений результаты выполнения скрипта. Эта возможность позволяет нам отслеживать сроки истечения сертификатов. Написанный скрипт парсит вывод команды cert_mgr show и в результате выдает количество дней до истечения локального и корневого сертификатов. Данный прием незаменим при администрировании большого количества КШ.
В чем цимус такого шифрования
Вся описанная выше функциональность поддерживается «из коробки» КШ S-Terra. То есть не пришлось устанавливать никаких дополнительных модулей, которые могли бы повлиять на сертификацию криптошлюзов и аттестацию всей информационной системы. Каналы между площадками могут быть любые, хоть через интернет.
Благодаря тому, что при изменении внутренней инфраструктуры не нужно перенастраивать криптошлюзы, система работает как услуга, что очень удобно для заказчика: он может свои сервисы (клиентские и серверные), располагать на любых адресах, и все изменения динамически передадутся между шифровальным оборудованием.
Безусловно, шифрование за счет накладных расходов (overhead) влияет на скорость передачи данных, но незначительно — пропускная способность канала может снизиться максимум на 5—10 %. При этом технология протестирована и показала хорошие результаты даже на спутниковых каналах, которые довольно нестабильны и обладают низкой пропускной способностью.
Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»
Автор: SolarSecurity
