Pokud vaše společnost odesílá nebo přijímá přes síť osobní údaje a další důvěrné informace, které podléhají ochraně podle zákona, je nutné používat šifrování podle GOST. Dnes vám ukážeme, jak jsme implementovali takové šifrování na základě kryptografické brány (KB) S-Terra u jednoho z našich zákazníků. Tento příběh bude zajímavý pro specialisty na informační bezpečnost, stejně jako pro inženýry, projektanty a architekty. V tomto příspěvku se nebudeme detailně zabývat nuancemi technické konfigurace — soustředíme se na klíčové momenty základního nastavení. Obrovské množství dokumentace k nastavení demonů OS Linux, na kterém je KB S-Terra založena, je volně dostupné na internetu. Dokumentace k nastavení proprietárního softwaru S-Terra je také k dispozici v otevřeném přístupu na webových stránkách výrobce.
Pár slov o projektu
Topologie sítě u zákazníka byla standardní — full mesh mezi centrem a pobočkami. Bylo potřeba implementovat šifrování komunikačních kanálů mezi všemi lokalitami, kterých bylo 8.
Obvykle v podobných projektech je všechno statické: na kryptografických bránách (KB) se nastavují statické trasy do místní sítě lokalit, zapisují se seznamy IP adres (ACL) pro šifrování. V tomto případě však nemají lokalit žádné centralizované řízení, a v jejich místních sítích se může dít cokoliv: sítě mohou být přidávány, odstraňovány a různě modifikovány. Abychom se vyhnuli přenastavování směrování a ACL na KB při změnách adresace místních sítí na lokalitách, bylo rozhodnuto použít GRE-tunneling a dynamické směrování OSPF, do kterého jsou zahrnuty všechny KB a většina jádrových směrovačů sítě na lokalitách (na některých lokalitách preferovali správci infrastruktury použít SNAT směrem k KB na jádrových směrovačích).
GRE-tunneling umožnilo vyřešit dvě úlohy:
1. Použít v ACL pro šifrování IP adresu externího rozhraní KB, ve kterém je inkapsulován veškerý provoz směřující na další lokalit.
2. Zorganizovat p-t-p tunely mezi KB, které umožňují nastavit dynamické směrování (v našem případě je mezi lokalitami organizováno poskytovatelské MPLS L3VPN).
Klient objednal implementaci šifrování jako službu. Jinak by musel nejen udržovat kryptopřístupové brány nebo externě delegovat na nějakou organizaci, ale také sám sledovat životní cyklus šifrovacích certifikátů, včas je obnovovat a instalovat nové.
A nyní vlastní stručná příručka – jak a co jsme nastavovali
Subjektu KII k uvážení: nastavujeme kryptopřístupovou bránu
Základní nastavení sítě
Především spustíme novou KŠ a dostaneme se do administrační konzole. Začít bychom měli změnou hesla vestavěného administrátora — příkaz change user password administrator. Poté je třeba provést inicializační proceduru (příkaz initialize) během které se zadávají licenční údaje a inicializuje generátor náhodných čísel (GNC).
Všimněte si! Při inicializaci KŠ S-Terra se nastavuje bezpečnostní politika, podle které bezpečnostní brány nepropouštějí pakety. Je nutné buď vytvořit vlastní politiku, nebo pomocí příkazu run csconf_mgr activate aktivovat přednastavenou povolenou politiku.
Dále je třeba nastavit adresaci externích a interních rozhraní a také výchozí trasu. Práci s síťovou konfigurací KŠ a nastavení šifrování je lépe provádět prostřednictvím konzole podobné Cisco. Tato konzole je určena pro zadávání příkazů podobných příkazům Cisco IOS. Konfigurace vytvořená pomocí konzole podobné Cisco je opět převáděna do odpovídajících konfiguračních souborů, se kterými pracují démoni OS. Do konzole podobné Cisco se z administrační konzole přechází příkazem konfigurovat.
Změňte hesla pro vestavěného uživatele cscons a enable:
>enable
Heslo: csp(přednastavené)
#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
Opouštíme konzolu podobnou Cisco a přecházíme do debian shellu příkazem systém. Nastavujeme vlastní heslo pro uživatele root příkazem passwd.
Na každé KŠ se nastavuje samostatný tunel pro každou lokalitu. Nastavení tunelového rozhraní se provádí v souboru /etc/network/interfaces. Za vytvoření samotného rozhraní odpovídá utilita IP tunnel, která je součástí předinstalovaného balíčku iproute2. Příkaz k vytvoření rozhraní se zapisuje do volby pre-up.
Příklad konfigurace typického tunelového rozhraní:
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
Všimněte si! Je třeba poznamenat, že nastavení tunelových rozhraní by mělo být umístěno mimo sekci
###netifcfg-begin###
*****
###netifcfg-end###
V opačném případě budou tato nastavení přepsána při změně síťových nastavení fyzických rozhraní prostřednictvím konzole typu Cisco.
Dynamické směrování
V S-Terra je dynamické směrování realizováno pomocí balíčku programů Quagga. Pro nastavení OSPF budeme potřebovat aktivaci a konfiguraci démonů. zebra a ospfd. Demon zebra zajišťuje interakci mezi směrovacími démony a OS. Demon ospfd, jak jasně naznačuje jeho název, je zodpovědný za realizaci protokolu OSPF.
Konfigurace OSPF se provádí buď prostřednictvím konzole démona, nebo přímo prostřednictvím konfiguračního souboru /etc/quagga/ospfd.conf. Do souboru se přidávají všechna fyzická a tunelová rozhraní účastnící se dynamického směrování, stejně jako se vyhlašují sítě, které budou ohlášeny a přijímat ohlášení.
Příklad konfigurace, kterou je třeba přidat 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 případě jsou adresy 192.168.1.x/31 vyhrazeny pro tunelové ptp-sítě mezi lokalitami, adresy 192.168.2.x/30 jsou pro tranzitní sítě mezi KŠ a jádrovými směrovači.
Všimněte si! Pro zmenšení směrovací tabulky ve velkých instalacích lze filtrovat ohlášení samotných tranzitních sítí pomocí konstrukcí no redistribute connected nebo redistribute connected route-map.
Po nastavení démonů je nutné změnit stav spuštění démonů v /etc/quagga/daemons. V možnostech zebra a ospfd no změnit na yes. Spustit démon quagga a nastavit jeho automatické spuštění při startu KŠ příkazem update-rc.d quagga enable.
Pokud je nastavení GRE-tunnelů a OSPF provedeno správně, měly by se na KŠ a jádrových směrovačích objevit trasy do sítí ostatních lokalit a tím vzniká síťová konektivita mezi místními sítěmi.
Šifrujeme přenášený provoz
Jak bylo již zmíněno, při šifrování mezi zařízeními obvykle uvádíme rozsahy IP adres (ACL), mezi kterými se šifruje provoz: pokud zdrojová a cílová adresa spadají do těchto rozsahů, provoz mezi nimi je šifrován. V tomto projektu je však struktura dynamická a adresy se mohou měnit. Zatímco jsme již nastavili GRE tunelování, můžeme jako zdrojové a cílové adresy pro šifrování provozu uvést externí adresy KŠ — neboť šifrovaný provoz přichází již inkapsulovaný GRE protokolem. Jinými slovy, šifruje se vše, co přichází do KŠ z lokální sítě jednoho zařízení směrem k sítím, které oznámily jiná zařízení. A již uvnitř každého zařízení může probíhat jakékoliv přesměrování. Takže při jakékoliv změně lokálních sítí stačí, aby administrátor upravil oznámení vycházející z jeho sítě směrem k KŠ, a ta bude dostupná pro jiná zařízení.
Šifrování v KŠ S-Terra se provádí prostřednictvím protokolu IPSec. Používáme algoritmus „Kuzněc“ v souladu s GOST R 34.12-2015, a pro kompatibilitu se staršími verzemi může být použit GOST 28147-89. Autentizace se technicky může provádět jak na předem určených klíčích (PSK), tak na certifikátech. Nicméně v průmyslovém provozu je nutné používat certifikáty vydané podle GOST R 34.10-2012.
Práce s certifikáty, kontejnery a CRL se provádí pomocí utilitky cert_mgr. Nejprve pomocí příkazu cert_mgr create je nutné vytvořit kontejner uzavřeného klíče a žádost o certifikát, která bude zaslána do Centra pro správu certifikátů. Po obdržení certifikátu je nutné jej společně s kořenovým certifikátem ÚC a CRL (pokud se používá) importovat příkazem cert_mgr import. Ověřit, že všechny certifikáty a CRL byly nainstalovány, lze příkazem cert_mgr show.
. Po úspěšné instalaci certifikátů přejdeme do Cisco-like konzole pro nastavení IPSec.
Vytvoříme IKE politiku, ve které uvedeme požadované algoritmy a parametry pro vytvářený chráněný kanál, které budou nabídnuty partnerovi pro dohodu.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Tato politika se uplatňuje při vytváření první fáze IPSec. Výsledkem úspěšného dokončení první fáze je ustanovení SA (Security Association).
Dále je potřeba určit seznam zdrojových a cílových IP adres (ACL) pro šifrování, vytvořit sadu transformací (transform set), vytvořit kryptografickou mapu (crypto map) a připojit ji k externímu rozhraní KŠ.
Nastavujeme ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Sada transformací (stejně jako v první fázi použijeme šifrovací algoritmus „Kuzněček“ s používáním režimu výstupu imitace):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Vytváříme kryptomapu, specifikujeme ACL, transform set a adresu peer:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Připojujeme kryptomapu k externímu rozhraní KŠ:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Pro šifrování kanálů s jinými lokalitami je nutné zopakovat proceduru vytváření ACL a kryptomapy, přičemž se změní název ACL, IP adresy a číslo kryptomapy.
Všimněte si! V případě, že se neprovádí kontrola certifikátů pomocí CRL, je nutné to explicitně uvést:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Tímto lze považovat konfiguraci za dokončenou. V výstupu příkazů konzole Cisco-like show crypto isakmp sa a show crypto ipsec sa by měly být uvedeny vybudované první a druhé fáze IPSec. Tyto informace lze také získat pomocí příkazu sa_mgr show, provedeného z debian shellu. V výstupu příkazu cert_mgr show by měly být zobrazeny certifikáty vzdálených lokalit. Stav těchto certifikátů bude remote. V případě, že tunely nejsou vybudovány, je třeba se podívat do logu VPN-služby, který je uložen v souboru /var/log/cspvpngate.log. Kompletní seznam logovacích souborů s popisem jejich obsahu je uveden v dokumentaci.
Sledujeme "zdraví" systému
V KŠ S-Terra se pro monitorování používá standardní démon snmpd. Kromě obvyklých parametrů pro Linux S-Terra „out of the box“ podporuje poskytování údajů o IPSec tunelech podle CISCO-IPSEC-FLOW-MONITOR-MIB, což používáme pro sledování stavu IPSec tunelů. Také je podporována funkčnost vlastních OID, které poskytují jako hodnoty výsledky provádění skriptu. Tato možnost nám umožňuje sledovat termíny vypršení platnosti certifikátů. Napsaný skript parsuje výstup příkazu cert_mgr show a v důsledku toho vrací počet dní do vypršení platnosti místního a kořenového certifikátu. Tento přístup je nezbytný při správě velkého počtu KŠ.
V čem je smysl takového šifrování
Veškerá výše popsaná funkcionalita je podporována „z krabice“ KŠ S-Terra. To znamená, že nebylo potřeba instalovat žádné další moduly, které by mohly ovlivnit certifikaci kryptogateway a atestaci celého informačního systému. Kanály mezi platformami mohou být jakékoli, klidně přes internet.
Díky tomu, že při změně vnitřní infrastruktury není potřeba přeprogramovávat kryptogateway, systém funguje jako služba, což je velmi pohodlné pro zákazníka: své služby (klientské i serverové) může umisťovat na jakékoli adresy a všechny změny se dynamicky přenesou mezi šifrovacím vybavením.
Nejistě, šifrování díky přídavným nákladům (overhead) ovlivňuje rychlost přenosu dat, ale zanedbatelně – propustnost kanálu může klesnout maximálně o 5–10 %. Tato technologie byla testována a ukázala dobré výsledky i na satelitních kanálech, které jsou poměrně nestabilní a mají nízkou propustnost.
Igor Vinokhodov, inženýr 2. linie administrace „Rostelecom-Solar“
Zdroj: habr.com
