🥇Криптираме по ГОСТ: бележка за настройка на динамична маршрутизация на трафика

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

Променяме паролите на вградения потребител 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-подобния интерфейс и преминаваме в 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-like конзолата 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