Ние шифрираме според ГОСТ: водич за поставување динамично рутирање на сообраќајот

Ако вашата компанија пренесува или прима лични податоци и други доверливи информации преку мрежата што се предмет на заштита во согласност со законот, потребно е да користи шифрирање ГОСТ. Денес ќе ви кажеме како имплементиравме такво шифрирање врз основа на крипто портата S-Terra (CS) кај еден од клиентите. Оваа приказна ќе биде од интерес за специјалисти за информациска безбедност, како и инженери, дизајнери и архитекти. Ние нема да се нурнеме длабоко во нијансите на техничката конфигурација во овој пост; ќе се фокусираме на клучните точки на основната поставка. Огромен обем на документација за поставување демони на Linux OS, на кои се базира S-Terra CS, се слободно достапни на Интернет. Документацијата за поставување на комерцијален софтвер S-Terra е исто така јавно достапна на порталот производителот.

Неколку зборови за проектот

Топологијата на мрежата на клиентите беше стандардна - целосна мрежа помеѓу центарот и филијалите. Беше неопходно да се воведе шифрирање на каналите за размена на информации помеѓу сите страници, од кои имаше 8.

Обично во вакви проекти сè е статично: статичните правци до локалната мрежа на страницата се поставени на крипто портите (CG), се регистрираат списоци со IP адреси (ACL) за шифрирање. Меѓутоа, во овој случај, сајтовите немаат централизирана контрола и сè може да се случи во нивните локални мрежи: мрежите може да се додаваат, бришат и менуваат на секој можен начин. Со цел да се избегне реконфигурирање на рутирање и ACL на KS при промена на адресирањето на локалните мрежи на локациите, беше одлучено да се користи тунелирање GRE и динамичко рутирање OSPF, кое ги вклучува сите KS и повеќето рутери на ниво на јадро на мрежата на локациите ( на некои локации, администраторите на инфраструктура претпочитаа да користат SNAT кон KS на рутерите на јадрото).

Тунелирањето GRE ни овозможи да решиме два проблеми:
1. Користете ја IP адресата на надворешниот интерфејс на CS за шифрирање во ACL, кој го инкапсулира целиот сообраќај испратен до други локации.
2. Организирајте ptp тунели помеѓу CS, кои ви дозволуваат да конфигурирате динамично рутирање (во нашиот случај, MPLS L3VPN на давателот е организиран помеѓу страниците).

Клиентот нареди имплементација на шифрирање како услуга. Во спротивно, тој ќе мора не само да одржува крипто-порти или да ги нарачува на некоја организација, туку и самостојно да го следи животниот циклус на сертификатите за шифрирање, да ги обновува навреме и да инсталира нови.

И сега вистинската белешка - како и што конфигуриравме

Забелешка за предметот CII: поставување крипто-порта

Основно поставување на мрежата

Пред сè, лансираме нов CS и влегуваме во административната конзола. Треба да започнете со промена на вградената администраторска лозинка - команда сменете го администраторот за лозинка на корисникот. Потоа треба да ја извршите постапката за иницијализација (команда иницијализира) при што се внесуваат податоците за лиценцата и се иницијализира сензорот за случаен број (RNS).

Обрни внимание! Кога S-Terra CC е иницијализиран, се воспоставува безбедносна политика во која интерфејсите на безбедносната порта не дозволуваат пакетите да минуваат низ. Мора или да креирате своја сопствена политика или да ја користите командата активирај го csconf_mgr активирајте однапред дефинирана политика за дозволување.
Следно, треба да го конфигурирате адресирањето на надворешните и внатрешните интерфејси, како и стандардната рута. Пожелно е да се работи со конфигурацијата на мрежата CS и да се конфигурира шифрирањето преку конзола слична на Cisco. Оваа конзола е дизајнирана да внесува команди слични на командите на Cisco IOS. Конфигурацијата генерирана со помош на конзолата слична на Cisco, пак, се претвора во соодветните конфигурациски датотеки со кои работат демони на ОС. Можете да отидете до конзолата слична на Cisco од административната конзола со командата конфигурирате.

Променете ги лозинките за вградените кориснички cscons и овозможете:

>овозможи
Лозинка: csp (преинсталиран)
#конфигурирај терминал
#корисничко име cscons привилегија 15 тајна 0 #овозможи тајна 0 Поставување на основната мрежна конфигурација:

#интерфејс GigabitEthernet0/0
# IP адреса 10.111.21.3 255.255.255.0
#без исклучување
#интерфејс GigabitEthernet0/1
# IP адреса 192.168.2.5 255.255.255.252
#без исклучување
#ip рута 0.0.0.0 0.0.0.0 10.111.21.254

GRE

Излезете од конзолата слична на Cisco и одете во дебијан школка со командата систем. Поставете своја сопствена лозинка за корисникот корен тим passwd.
Во секоја контролна соба, конфигуриран е посебен тунел за секоја локација. Интерфејсот на тунелот е конфигуриран во датотеката / итн / мрежа / интерфејси. Услужната алатка за IP тунел, вклучена во претходно инсталираниот сет iproute2, е одговорна за креирање на самиот интерфејс. Командата за создавање интерфејс е запишана во опцијата за пред-ап.

Пример за конфигурација на типичен тунелен интерфејс:
авто-страница 1
iface site1 inet статичен
адреса 192.168.1.4
мрежна маска 255.255.255.254
пред-ап тунел за додавање сајт1 режим gre локален 10.111.21.3 далечински 10.111.22.3 клуч hfLYEg^vCh6p

Обрни внимание! Треба да се забележи дека поставките за тунелските интерфејси мора да се наоѓаат надвор од делот

###netifcfg-почеток###
*****
###netifcfg-крај###

Во спротивно, овие поставки ќе бидат препишани при промена на мрежните поставки на физичките интерфејси преку конзола слична на Cisco.

Динамично рутирање

Во S-Terra, динамичкото рутирање се спроведува со помош на софтверскиот пакет Quagga. За да го конфигурираме OSPF треба да овозможиме и конфигурираме демони зебра и ospfd. Демонот на зебра е одговорен за комуникација помеѓу рутирачките демони и ОС. Демонот ospfd, како што сугерира името, е одговорен за спроведување на протоколот OSPF.
OSPF е конфигуриран или преку демонската конзола или директно преку конфигурациската датотека /etc/quagga/ospfd.conf. Сите физички и тунелски интерфејси кои учествуваат во динамичкото рутирање се додаваат во датотеката, а се декларираат и мрежите што ќе се рекламираат и ќе добиваат соопштенија.

Пример за конфигурацијата на која треба да се додаде ospfd.conf:
интерфејс eth0
!
интерфејс eth1
!
интерфејс страница 1
!
интерфејс страница 2
рутер ospf
ospf рутер-ид 192.168.2.21
мрежа 192.168.1.4/31 област 0.0.0.0
мрежа 192.168.1.16/31 област 0.0.0.0
мрежа 192.168.2.4/30 област 0.0.0.0

Во овој случај, адресите 192.168.1.x/31 се резервирани за тунелни ptp мрежи помеѓу локациите, адресите 192.168.2.x/30 се распределени за транзитни мрежи помеѓу CS и рутери на јадрото.

Обрни внимание! За да ја намалите рутирачката табела кај големите инсталации, можете да ја филтрирате рекламата на самите транзитни мрежи користејќи ги конструкциите нема редистрибуирање поврзано или прераспределете ја поврзаната мапа на маршрутата.

Откако ќе ги конфигурирате демоните, треба да го промените статусот на стартување на демоните во /etc/quagga/demons. Во опциите зебра и ospfd нема промена на да. Стартувајте го демонот quagga и поставете го на автоматско активирање кога ќе ја стартувате командата KS ажурирање-rc.d quagga овозможи.

Ако конфигурацијата на GRE тунелите и OSPF е направена правилно, тогаш маршрутите во мрежата на други локации треба да се појават на KSh и основните рутери и, на тој начин, ќе се појави мрежно поврзување помеѓу локалните мрежи.

Ние го криптираме пренесениот сообраќај

Како што е веќе напишано, обично кога се шифрираме помеѓу локациите, ги одредуваме опсезите на IP адреси (ACL) меѓу кои сообраќајот е шифриран: ако адресите на изворот и дестинацијата спаѓаат во овие опсези, тогаш сообраќајот меѓу нив е шифриран. Меѓутоа, во овој проект структурата е динамична и адресите може да се променат. Бидејќи веќе го конфигуриравме тунелирањето GRE, можеме да одредиме надворешни KS адреси како изворни и дестинации адреси за шифрирање на сообраќајот - на крајот на краиштата, сообраќајот што е веќе инкапсулиран со протоколот GRE пристигнува за шифрирање. Со други зборови, сè што влегува во CS од локалната мрежа на една локација кон мрежите што се објавени од други сајтови е шифрирано. И во секоја од локациите може да се изврши какво било пренасочување. Така, доколку има некаква промена во локалните мрежи, администраторот треба само да ги измени соопштенијата кои доаѓаат од неговата мрежа кон мрежата и таа ќе стане достапна за други сајтови.

Шифрирањето во S-Terra CS се врши со помош на протоколот IPSec. Ние го користиме алгоритмот „Скакулец“ во согласност со ГОСТ Р 34.12-2015, а за компатибилност со постарите верзии можете да го користите ГОСТ 28147-89. Автентикацијата технички може да се изврши и на претходно дефинирани клучеви (PSK) и на сертификати. Меѓутоа, во индустриското работење неопходно е да се користат сертификати издадени во согласност со ГОСТ Р 34.10-2012.

Работата со сертификати, контејнери и CRL се врши со помош на алатката cert_mgr. Пред сè, користејќи ја командата cert_mgr создаде потребно е да се генерира контејнер за приватен клуч и барање за сертификат, кое ќе биде испратено до Центарот за управување со сертификати. По добивањето на сертификатот, тој мора да се увезе заедно со root CA сертификатот и CRL (ако се користи) со командата увоз на cert_mgr. Можете да бидете сигурни дека сите сертификати и CRL се инсталирани со командата cert_mgr шоу.

По успешно инсталирање на сертификатите, одете во конзолата слична на Cisco за да го конфигурирате IPSec.
Создаваме политика на IKE која ги специфицира саканите алгоритми и параметри на безбедниот канал што се создава, а кои ќе му бидат понудени на партнерот за одобрување.

#крипто isakmp политика 1000
#encr gost341215k
#hash gost341112-512-tc26
#знак за автентикација
#група vko2
#доживотно 3600

Оваа политика се применува при изградбата на првата фаза на IPSec. Резултатот од успешното завршување на првата фаза е формирањето на СА (Асоцијација за безбедност).
Следно, треба да дефинираме листа на изворни и одредишни IP адреси (ACL) за шифрирање, да генерираме сет на трансформации, да креираме криптографска карта (криптомапа) и да ја поврземе со надворешниот интерфејс на CS.

Поставете ACL:
#ip access-list проширена локација1
#permit gre домаќин 10.111.21.3 домаќин 10.111.22.3

Збир на трансформации (исто како и за првата фаза, го користиме алгоритмот за шифрирање „Скакулец“ користејќи го режимот за генерирање на вметнување за симулација):

#crypto ipsec transform-set GOST esp-gost341215k-mac

Ние создаваме крипто-мапа, го одредуваме ACL, го трансформираме множеството и врсничката адреса:

#крипто мапа ГЛАВНА 100 ipsec-isakmp
#match адреса сајт1
#set transform-set GOST
#постави peer 10.111.22.3

Ние ја врзуваме крипто картичката со надворешниот интерфејс на касата:

#интерфејс GigabitEthernet0/0
# IP адреса 10.111.21.3 255.255.255.0
#криптомапа ГЛАВНА

За да ги шифрирате каналите со други сајтови, мора да ја повторите постапката за креирање ACL и крипто-картичка, менување на името на ACL, IP адресите и бројот на крипто картичката.

Обрни внимание! Ако потврдата на сертификатот со CRL не се користи, ова мора да биде експлицитно наведено:

#crypto pki trustpoint s-terra_technological_trustpoint
#отповикување-проверка нема

Во овој момент, поставувањето може да се смета за завршено. Во излез на командна конзола слична на Cisco покажете крипто исакмп са и покажете крипто ipsec sa Конструираните први и втори фази на IPSec треба да се рефлектираат. Истата информација може да се добие со помош на командата sa_mgr шоу, извршена од дебијан школка. Во командниот излез cert_mgr шоу Треба да се појават сертификатите за далечинска локација. Статусот на таквите сертификати ќе биде Далечински управувач. Ако не се градат тунели, треба да го погледнете дневникот за услуги на VPN, кој е зачуван во датотеката /var/log/cspvpngate.log. Комплетна листа на датотеки со дневници со опис на нивната содржина е достапна во документацијата.

Следење на „здравјето“ на системот

S-Terra CC го користи стандардниот snmpd демон за следење. Покрај типичните параметри на Linux, надвор од кутијата S-Terra поддржува издавање податоци за IPSec тунели во согласност со CISCO-IPSEC-FLOW-MONITOR-MIB, што е она што го користиме кога го следиме статусот на IPSec тунелите. Поддржана е и функционалноста на прилагодените OID кои ги даваат резултатите од извршувањето на скриптата како вредности. Оваа функција ни овозможува да ги следиме датумите на истекување на сертификатот. Напишаната скрипта го анализира излезот на командата cert_mgr шоу и како резултат го дава бројот на денови до истекот на локалните и коренските сертификати. Оваа техника е незаменлива кога се администрираат голем број на CABG.

Која е користа од таквото шифрирање?

Целата функционалност опишана погоре е поддржана надвор од кутијата од S-Terra KSh. Односно, немаше потреба да се инсталираат дополнителни модули кои би можеле да влијаат на сертификацијата на крипто портите и на сертификацијата на целиот информациски систем. Може да има какви било канали помеѓу страниците, дури и преку Интернет.

Поради фактот што кога се менува внатрешната инфраструктура, нема потреба да се реконфигурираат крипто портите, системот работи како сервис, што е многу погодно за клиентот: тој може да ги постави своите услуги (клиент и сервер) на која било адреса, а сите промени ќе бидат динамички префрлени помеѓу опремата за шифрирање.

Се разбира, шифрирањето поради режиски трошоци (надземни) влијае на брзината на пренос на податоци, но само малку - пропусната моќ на каналот може да се намали за максимум 5-10%. Во исто време, технологијата е тестирана и покажа добри резултати дури и на сателитски канали, кои се прилично нестабилни и имаат низок пропусен опсег.

Игор Виноходов, инженер на 2-та линија на администрација на Ростелеком-Солар

Извор: www.habr.com