Шифруваме по ГОСТ: указания за настройка на динамично маршрутизиране на трафика

Ако вашата компания предава или получава по мрежата лични данни и друга конфиденциална информация, подлежащи на защита съгласно законодателството, е необходимо да се прилага криптиране по ГОСТ. Днес ще разкажем как внедрихме такова криптиране на базата на криптошлюза (КШ) 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
Парола: 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.

Динамично маршрутизиране

В 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.x/31 са отделени за тунелни ptp мрежи между площадките, адресите 192.168.2.x/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-подобната конзола за настройка на 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-подобната конзола show crypto isakmp sa и show crypto ipsec sa трябва да се отразяват създадените първи и втори фази на IPSec. Тази информация може да бъде получена и чрез командата sa_mgr show, извършена от debian shell. В изхода на командата 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-ра линия администриране "Ростелеком-Солар"

Източник: habr.com