Ak vaša spoločnosť prenáša alebo prijíma prostredníctvom siete osobné údaje a iné dôverné informácie chránené zákonom, je potrebné aplikovať šifrovanie v súlade s normou GOST. Dnes vám predstavíme, ako sme implementovali takéto šifrovanie na báze kryptoserveru (KŠ) S-Terra u jedného z našich klientov. Tento príbeh bude zaujímavý pre odborníkov na informačnú bezpečnosť, ako aj inžinierov, projektantov a architektov. Hlbšie sa do technických detailov konfigurácie v tomto príspevku nepustíme — zameriame sa na kľúčové aspekty základného nastavenia. Obrovské množstvo dokumentácie k nastaveniu demonštrátorov operačného systému Linux, na ktorom je založený KŠ S-Terra, je vo voľnom prístupe na internete. Dokumentácia k nastaveniu proprietárneho softvéru S-Terra je tiež dostupná na výrobcu.
Slovo o projekte
Topológia siete u klienta bola štandardná — full mesh medzi centrom a pobočkami. Bolo potrebné implementovať šifrovanie kanálov na výmenu informácií medzi všetkými lokalitami, ktorých bolo 8.
Vo väčšine podobných projektov je všetko statické: na kryptoserveroch (KŠ) sú nastavené statické trasy do miestnej siete, definujú sa zoznamy IP adries (ACL) pre šifrovanie. V tomto prípade však lokality nemajú centralizované riadenie a v ich miestnych sieťach sa môže diať čokoľvek: siete môžu byť pridávané, odstraňované a rôzne modifikované. Aby sa predišlo prenastavovaniu smerovania a ACL na KŠ pri zmene adresácie lokálnych sietí na lokalitách, bolo rozhodnuté použiť GRE tunelovanie a dynamické smerovanie OSPF, do ktorého sú zahrnuté všetky KŠ a väčšina smerovačov v jadre siete na lokalitách (na niektorých lokalitách administrátori infraštruktúry uprednostnili používanie SNAT smerom na KŠ na jadrových smerovačoch).
GRE tunelovanie umožnilo vyriešiť dve úlohy:
1. Použiť v ACL na šifrovanie IP adresu vonkajšieho rozhrania KŠ, v ktorom je encapsulovaný celý traffic smerujúci na iné lokality.
2. Organizovať p-t-p tunely medzi KŠ, ktoré umožňujú nastaviť dynamické smerovanie (v našom prípade je medzi lokalitami organizovaný poskytovateľský MPLS L3VPN).
Zákazník si objednal implementáciu šifrovania ako službu. Inak by musel nielen udržiavať kryptoprelivy alebo ich outsourcovať nejakej organizácii, ale aj samostatne sledovať životný cyklus šifrovacích certifikátov, včas ich predlžovať a inštalovať nové.
A teraz konkrétne pripomienka – ako a čo sme nastavovali
Subjektu kritickej informačnej infraštruktúry na vedomie: nastavujeme kryptopreliv
Základné nastavenie siete
Predovšetkým spustíme nový kryptopreliv a dostaneme sa do administrátorskej konzoly. Začať by sme mali zmenou hesla zabudovaného administrátora — príkaz change user password administrator. Potom je potrebné vykonať procedúru inicializácie (príkaz initialize) počas ktorej sa zavádzajú licenčné údaje a inicializuje sa generátor náhodných čísel (GNU).
Pozor! Pri inicializácii kryptoprelivu S-Terra sa nastavuje bezpečnostná politika, pri ktorej bezpečnostné rozhrania prelivu neprijímajú pakety. Je nevyhnutné buď vytvoriť vlastnú politiku, alebo pomocou príkazu run csconf_mgr activate vykonať aktiváciu predinštalovanej povolenej politiky.
Ďalej je potrebné nastaviť adresáciu externých a interných rozhraní, ako aj predvolenú trasu. Prácu s konfiguráciou siete kryptoprelivu a nastavením šifrovania je vhodné vykonávať cez konzolu podobnú Cisco. Táto konzola je určená na zadávanie príkazov, ktoré sú podobné príkazom Cisco IOS. Konfigurácia vytvorená pomocou konzoly podobnej Cisco sa potom konvertuje do príslušných konfiguračných súborov, s ktorými pracujú démoni operačného systému. Prechod do konzoly podobnej Cisco z administrátorskej konzoly je možné vykonať príkazom configure.
Zmeníme heslá zabudovanému používateľovi cscons a enable:
>enable
Heslo: csp (predinštalované)
#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
Vystúpime z konzoly podobnej Cisco a prejdeme do debian shell príkazom systém. Nastavíme vlastné heslo pre používateľa root príkazom passwd.
Na každom kryptoprelive sa nastavuje samostatný tunel pre každú lokalitu. Nastavenie tunelového rozhrania sa vykonáva v súbore /etc/network/interfaces. Za vytvorenie samotného rozhrania zodpovedá utilita IP tunnel, ktorá patrí do predinštalovanej sady iproute2. Príkaz na vytvorenie rozhrania sa zapisuje do možnosti pre-up.
Príklad konfigurácie typického tunelového rozhrania:
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
Pozor! Je potrebné poznamenať, že nastavenia tunelových rozhraní by mali byť umiestnené mimo sekcie
###netifcfg-begin###
*****
###netifcfg-end###
V opačnom prípade budú tieto nastavenia zmazané pri zmene sieťových nastavení fyzických rozhraní cez konzolu podobnú Cisco.
Dynamické smerovanie
V S-Terra je dynamické smerovanie implementované prostredníctvom balíka programov Quagga. Na konfiguráciu OSPF budeme potrebovať povolenie a nastavenie démonov zebra a ospfd. Démon zebra zodpovedá za interakciu medzi démonmi smerovania a operačným systémom. Démon ospfd, ako naznačuje názov, zodpovedá za implementáciu protokolu OSPF.
Nastavenie OSPF sa vykonáva buď prostredníctvom konzoly démona, alebo priamo cez konfiguračný súbor /etc/quagga/ospfd.conf. Do súboru sa pridávajú všetky fyzické a tunelové rozhrania zúčastňujúce sa na dynamickom smerovaní, ako aj sa vyhlasujú siete, ktoré budú oznámené a prijímať oznámenia.
Príklad konfigurácie, ktorú je potrebné pridať do 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
V tomto prípade sú adresy 192.168.1.x/31 vyhradené pre tunelové ptp-siete medzi lokalitami, adresy 192.168.2.x/30 — pre tranzitné siete medzi KŠ a jadrovými smerovačmi.
Pozor! Na zníženie smerovacích tabuliek vo veľkých inštaláciách je možné filtrovať oznamovanie samotných tranzitných sietí pomocou konštrukcií no redistribute connected alebo redistribute connected route-map.
Po nastavení démonov je potrebné zmeniť stav spúšťania démonov v /etc/quagga/daemons. V možnostiach zebra a ospfd no opraviť na yes. Spustiť démon quagga a nastaviť jeho automatické spúšťanie pri štarte KŠ príkazom update-rc.d quagga enable.
Ak je nastavenie GRE-tunelov a OSPF vykonané správne, mali by sa na KŠ a jadrových smerovačoch objaviť trasy v sieti ostatných lokalít, a tým vzniká sieťová konektivita medzi miestnymi sieťami.
Šifrujeme prenášaný traffic
Ako už bolo napísané, obvykle pri šifrovaní medzi lokalitami uvádzame rozsahy IP adries (ACL), medzi ktorými sa šifruje prevádzka: ak sa zdrojové a cieľové adresy nachádzajú v týchto rozsahoch, prevádzka medzi nimi sa šifruje. V tomto projekte je však štruktúra dynamická a adresy sa môžu meniť. Keďže sme už nastavili GRE tunelovanie, ako adresy zdroja a cieľa pre šifrovanie prevádzky môžeme uviesť externé adresy KŠ – veď na šifrovanie prichádza prevádzka, už zapuzdrená protokolom GRE. Inými slovami, šifruje sa všetko, čo prichádza do KŠ z lokálnej siete jednej lokality smerom k sieťam, ktoré boli oznámené inými lokalitami. A už v rámci každej z lokalít môže prebiehať akékoľvek presmerovanie. Týmto spôsobom, pri akýchkoľvek zmenách v lokálnych sieťach, stačí administrátorovi upraviť oznámenia, ktoré idú z jeho siete smerom k KŠ, a stane sa dostupnou pre ostatné lokality.
Šifrovanie v KŠ S-Terra sa vykonáva prostredníctvom protokolu IPSec. Používame algoritmus „Kuznechik“ v súlade s GOST R 34.12-2015, a pre kompatibilitu so staršími verziami je možné použiť GOST 28147-89. Autentifikácia môže byť technicky vykonaná buď na preddefinovaných kľúčoch (PSK), alebo na certifikátoch. Avšak v priemyselnej prevádzke je potrebné používať certifikáty vydané podľa GOST R 34.10-2012.
Práca so certifikátmi, kontajnermi a CRL sa vykonáva pomocou utilitky cert_mgr. Najprv pomocou príkazu cert_mgr create je potrebné vytvoriť kontajner súkromného kľúča a žiadosť o certifikát, ktorá bude zaslaná do Centra správy certifikátov. Po obdržaní certifikátu je potrebné ho spolu s koreňovým certifikátom UC a CRL (ak sa používa) importovať príkazom cert_mgr import. Uistiť sa, že všetky certifikáty a CRL boli nainštalované, je možné príkazom cert_mgr show.
. Po úspešnej inštalácii certifikátov prechádzame do Cisco-like konzoly na konfiguráciu IPSec.
Vytvárame IKE politiku, v ktorej sú uvedené požadované algoritmy a parametre vytváraného zabezpečeného kanála, ktoré budú navrhnuté partnerovi na dohodu.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Táto politika sa uplatňuje pri budovaní prvej fázy IPSec. Výsledkom úspešného prechodu prvej fázy je vytvorenie SA (Security Association).
Ďalej je potrebné určiť zoznam IP adries zdroja a príjemcu (ACL) pre šifrovanie, vytvoriť sadu transformácií (transform set), vytvoriť kryptografickú mapu (crypto map) a priradiť ju k vonkajšiemu rozhraniu KŠ.
Definujeme ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Sada transformácií (rovnako ako pre prvú fázu, použijeme šifrovací algoritmus „Kôra“ v režime generovania imitačky):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Vytvárame kryptomapu, uvádzame ACL, transform set a adresu páru:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Priraďujeme kryptomapu k vonkajšiemu rozhraniu KŠ:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Pre šifrovanie kanálov s inými platformami je potrebné zopakovať postup vytvorenia ACL a kryptomapy, pričom zmeníme názov ACL, IP adresy a číslo kryptomapy.
Pozor! V prípade, že sa nevyužíva overovanie certifikátov pomocou CRL, je to potrebné výslovne uviesť:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Týmto môžeme považovať nastavenie za dokončené. Vo výstupe príkazov konzoly podobnej Cisco show crypto isakmp sa a show crypto ipsec sa by mali byť zobrazené vybudované prvé a druhé fázy IPSec. Túto informáciu môžeme získať aj pomocou príkazu sa_mgr show, vykonaného z debian shell. Vo výstupe príkazu cert_mgr show by mali byť certifikáty vzdialených platforiem. Stav takýchto certifikátov bude remote. V prípade, že tunely sa nevytvárajú, je potrebné nahliadnuť do logu VPN-služby, ktorá sa uchováva v súbore /var/log/cspvpngate.log. Kompletný zoznam logovacích súborov s popisom ich obsahu je uvedený v dokumentácii.
Monitorujeme „zdravie“ systému
V KŠ S-Terra pre monitoring sa používa štandardný démon snmpd. Okrem typických parametrov pre Linux, S-Terra „z krabice“ podporuje poskytovanie údajov o IPSec tuneloch podľa CISCO-IPSEC-FLOW-MONITOR-MIB, čo využívame na sledovanie stavu IPSec tunelov. Podporuje sa aj funkcia vlastných OID, ktoré poskytujú ako hodnoty výsledky vykonania skriptu. Táto možnosť nám umožňuje sledovať lehoty vypršania certifikátov. Napísaný skript parsuje výstup príkazu cert_mgr show a výsledkom je počet dní do vypršania lokálnych a koreňových certifikátov. Tento postup je nenahraditeľný pri správe veľkého počtu KŠ.
V čom je podstata tohto šifrovania
Celá výše uvedená funkcionalita je podporovaná «out of the box» KŠ S-Terra. To znamená, že nebolo potrebné inštalovať žiadne ďalšie moduly, ktoré by mohli ovplyvniť certifikáciu kryptogateways a akreditáciu celého informačného systému. Kanály medzi lokalitami môžu byť akékoľvek, aj cez internet.
Vďaka tomu, že pri zmene vnútornej infraštruktúry nie je potrebné opätovne nastavovať kryptogateways, systém funguje ako služba, čo je veľmi výhodné pre zákazníka: svoje služby (klientske a serverové) môže umiestniť na akýchkoľvek adresách, a všetky zmeny sa dynamicky prenesú medzi šifrovacím zariadením.
Nechybne, šifrovanie v dôsledku režijných nákladov (overhead) ovplyvňuje rýchlosť prenosu dát, ale nepatrne — priepustnosť kanála môže klesnúť maximálne o 5—10 %. Týmto technológia bola testovaná a preukázala dobré výsledky aj na satelitných kanáloch, ktoré sú pomerne nestabilné a majú nízku priepustnosť.
Igor Vinokhodov, inžinier 2. línie administrácie «Rostelecom-Solar»
Zdroj: habr.com
