Dacă compania dumneavoastră transmite sau primește date personale și alte informații confidențiale care trebuie protejate conform legislației, este necesar să aplicați criptarea conform standardului GOST. Astăzi vă vom povesti cum am implementat această criptare pe baza criptogatei (KG) S-Terra pentru unul dintre clienți. Această poveste va fi interesantă pentru specialiștii în securitatea informației, precum și pentru ingineri, proiectanți și arhitecți. Nu ne vom aprofunda în detaliile tehnice ale configurației în acest articol - ne vom concentra asupra aspectelor cheie ale configurării de bază. Există o cantitate enormă de documentație despre configurarea daemonilor sistemului de operare Linux, pe care se bazează KG S-Terra, disponibilă liber pe internet. Documentația despre configurarea software-ului proprietar S-Terra este de asemenea disponibilă publicului. a producătorului.
Câteva cuvinte despre proiect
Topologia rețelei clientului era standard - full mesh între sediu și filialele sale. Era necesară implementarea criptării canalelor de schimb de informații între toate locațiile, erau 8 la număr.
De obicei, în astfel de proiecte totul este static: pe criptogate (KG) sunt configurate rute statice în rețeaua locală a site-ului, sunt specificate listele de IP-uri (ACL) pentru criptare. Totuși, în acest caz, locațiile nu au o gestionare centralizată, iar în rețelele locale ale acestora se poate întâmpla orice: rețelele pot fi adăugate, eliminate și modificate în diverse moduri. Pentru a evita reconfigurarea rutării și ACL-urilor pe KG atunci când se schimbă adresarea rețelelor locale, s-a decis să se utilizeze tunelarea GRE și rutarea dinamică OSPF, în care sunt incluse toate KG-urile și majoritatea routerelor de nivel de bază din rețea (la unele locații, administratorii infrastructurii au preferat să utilizeze SNAT în direcția KG-urilor pe routerele de bază).
Tunelarea GRE a permis rezolvarea a două sarcini:
1. Să folosească în ACL pentru criptare adresa IP a interfeței externe a KG-ului, în care este encapsulat tot traficul destinat altor locații.
2. Să organizeze tuneluri p-t-p între KG-uri, care permit configurarea rutării dinamice (în cazul nostru, între locații este organizat un MPLS L3VPN de furnizor).
Clientul a solicitat implementarea criptării ca serviciu. Altfel, ar fi fost nevoit nu doar să mențină gateway-urile criptografice sau să le externalizeze unei organizații, ci și să urmărească personal ciclul de viață al certificatelor de criptare, prelungindu-le la timp și instalând altele noi.
Și acum, propriul ghid – cum și ce am configurat
Atenție subiecților KIIs: configurăm gateway-ul criptografic
Configurarea de bază a rețelei
În primul rând, lansăm noul KŠ și ajungem în consola de administrare. Trebuie să începem cu schimbarea parolei administratorului încorporat — comanda change user password administrator. Apoi, este necesară efectuarea procedurii de inițializare (comanda initialize) în care se introduc datele licenței și se inițiază generatorul de numere aleatorii (GNU).
Atenție! În timpul inițializării KŠ S-Terra se stabilește o politică de securitate în care interfețele gateway-ului de securitate nu permit pachete. Este necesar fie să creați o politică proprie, fie să activați politica permisivă preinstalată folosind comanda run csconf_mgr activate .
Apoi, este necesar să configurați adresarea interfețelor externe și interne, precum și ruta implicită. Este preferabil să efectuați lucrările cu configurația rețelei KŠ și setarea criptării printr-o consolă Cisco-like. Această consolă este destinată introducerii comenzilor similare cu cele din Cisco IOS. Configurația generată prin consola Cisco-like este apoi convertită în fișiere de configurare corespunzătoare, cu care lucrează demonii OS. Puteți trece în consola Cisco-like din consola de administrare folosind comanda configure.
Schimbăm parolele pentru utilizatorul încorporat cscons și enable:
>enable
Parolă: csp (premontată)
#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
Ieșim din consolă Cisco-like și trecem în shell-ul debian folosind comanda sistem. Setăm propria parolă pentru utilizatorul root comanda passwd.
Pe fiecare KŠ se configurează un tunel separat pentru fiecare locație. Configurarea interfeței tunnel se efectuează în fișierul /etc/network/interfaces. Crearea interfeței în sine este gestionată de utilitarul IP tunnel, care face parte din setul preinstalat iproute2. Comanda pentru crearea interfeței este specificată în opțiunea pre-up.
Exemplu de configurație pentru o interfață tunnel tipică:
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
Atenție! Este important de menționat că setările interfețelor de tunel trebuie situate în afara secțiunii
###netifcfg-begin###
*****
###netifcfg-end###
În caz contrar, aceste setări vor fi suprascrise la modificarea setărilor interfețelor fizice prin consola de tip Cisco.
Rutează dinamic
În S-Terra, rutarea dinamică este realizată prin intermediul pachetului de programe Quagga. Pentru a configura OSPF, vom avea nevoie de activarea și configurarea demonilor zebra și ospfd. Demonul zebra se ocupă de interacțiunea dintre demonii de rutare și SO. Demonul ospfd, așa cum sugerează numele, se ocupă de implementarea protocolului OSPF.
Configurarea OSPF se face fie prin consola demonului, fie direct prin fișierul de configurare /etc/quagga/ospfd.conf. Fișierul conține toate interfețele fizice și de tunel implicate în rutarea dinamică, precum și rețelele care vor fi anunțate și vor accepta anunțuri.
Un exemplu de configurație care trebuie adăugată în ospfd.conf:
interfață eth0
!
interfață eth1
!
interfață site1
!
interfață 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
În acest caz, adresele 192.168.1.x/31 sunt rezervate pentru rețelele PTP între locații, iar adresele 192.168.2.x/30 sunt pentru rețelele de tranzit între KSH și routerele de nucleu.
Atenție! Pentru a reduce tabela de rutare în instalații mari, se pot filtra anunțările rețelelor de tranzit prin construcții no redistribute connected sau redistribute connected route-map.
După configurarea demonilor, este necesar să schimbați statutul de pornire al demonilor în /etc/quagga/daemons. La opțiuni, schimbați "no" în "yes". Rulați demonul quagga și setați-l să pornească automat la pornirea KSH cu comanda zebra și ospfd update-rc.d quagga enable Dacă configurarea tunelurilor GRE și OSPF este realizată corect, atunci pe KSH și routerele de nucleu ar trebui să apară rute în rețelele altor locații și, prin urmare, se va stabili conectivitatea între rețelele locale..
Criptăm traficul transmis
Шифруем передаваемый трафик
Așa cum s-a menționat anterior, de obicei, atunci când criptăm între site-uri, specificăm intervalele de adrese IP (ACL) între care traficul este criptat: dacă adresele de sursă și destinație se încadrează în aceste intervale, traficul între ele este criptat. Cu toate acestea, în acest proiect, structura este dinamică și adresele se pot schimba. Deoarece am configurat deja tunelarea GRE, ca adrese de sursă și destinație pentru criptarea traficului putem specifica adresele externe ale KH - deoarece pentru criptare vine traficul deja încapsulat în protocolul GRE. Cu alte cuvinte, se criptează tot ceea ce ajunge în KH din rețeaua locală a unui site către rețelele care au fost anunțate de alte site-uri. Iar în interiorul fiecărui site poate avea loc orice redirecționare. Astfel, în cazul unei modificări a rețelelor locale, administratorului îi este suficient să modifice anunțurile care vin din rețeaua sa către KH, iar aceasta va deveni accesibilă pentru alte site-uri.
Criptarea în KH S-Terra se realizează prin intermediul protocolului IPSec. Folosim algoritmul „Crisantemă” conform GOST R 34.12-2015, iar pentru compatibilitatea cu versiunile mai vechi se poate aplica GOST 28147-89. Autentificarea se poate realiza tehnic atât pe chei predefinite (PSK), cât și pe certificate. Cu toate acestea, în exploatarea industrială este necesar să se utilizeze certificate emise conform GOST R 34.10-2012.
Lucrul cu certificate, containere și CRL se realizează cu ajutorul utilitarului cert_mgr. Primul lucru de făcut este să folosim comanda cert_mgr create pentru a forma un container al cheii private și o cerere de certificat care va fi trimisă Centrului de gestionare a certificatelor. După primirea certificatului, acesta, împreună cu certificatul rădăcină al CA și CRL (dacă se utilizează), trebuie importat cu comanda cert_mgr import. Pentru a verifica că toate certificatele și CRL s-au instalat, se poate folosi comanda cert_mgr show.
. După instalarea cu succes a certificatelor, trecem la consola de tip Cisco-like pentru configurarea IPSec.
Creăm o politică IKE, în care specificăm algoritmii doriti și parametrii canalului securizat care vor fi oferiți partenerului pentru negociere.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Această politică se aplică în construcția primei etape a IPSec. Rezultatul trecerii cu succes a primei etape este stabilirea SA (Asociației de Securitate).
Apoi va trebui să stabilim lista adreselor IP de sursă și destinație (ACL) pentru criptare, să formăm un set de transformări (transform set), să creăm o hartă criptografică (crypto map) și să o legăm la interfața externă a KSH.
Definim ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Setul de transformări (la fel ca pentru prima fază, folosim algoritmul de criptare „Grasshopper” în modul de generare a imitației):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Creăm harta criptografică, specificăm ACL, transform set și adresa peer-ului:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Legăm harta criptografică la interfața externă a KSH:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Pentru criptarea canalelor cu alte platforme, este necesar să repetăm procedura de creare a ACL și a hărții criptografice, schimbând numele ACL, adresele IP și numărul hărții criptografice.
Atenție! În cazul în care nu se utilizează verificarea certificatelor prin CRL, acest lucru trebuie specificat clar:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Configurarea poate fi considerată finalizată. În ieșirea comenzilor din consola de tip Cisco-like show crypto isakmp sa și show crypto ipsec sa trebuie să fie reflectate primele și a doua fază IPSec. Aceleași informații pot fi obținute folosind comanda sa_mgr show, executată din shell-ul debian. În ieșirea comenzii cert_mgr show trebuie să apară certificatele platformelor externe. Starea acestor certificate va fi remote. În cazul în care tunelurile nu se construiesc, este necesar să consultăm log-ul VPN-serviciului, care este stocat în fișierul /var/log/cspvpngate.log. Lista completă a fișierelor de log cu descrierea conținutului lor este disponibilă în documentație.
Monitorizăm „starea” sistemului
În KSH S-Terra, pentru monitorizare se folosește demonul standard snmpd. Pe lângă parametrii tipici pentru Linux, S-Terra „din cutie” suportă furnizarea datelor despre tunelurile IPSec conform CISCO-IPSEC-FLOW-MONITOR-MIB, ceea ce folosim pentru a monitoriza starea tunelurilor IPSec. De asemenea, este suportată funcționalitatea OID-urilor personalizate care furnizează ca valori rezultatele executării scriptului. Această posibilitate ne permite să urmărim termenele de expirare ale certificatelor. Scriptul scris parsează ieșirea comenzii cert_mgr show și rezultă în numărul de zile până la expirarea certificatelor locale și de rădăcină. Această metodă este esențială în administrarea unui număr mare de KSH.
Care este avantajul acestei criptări
Toată funcționalitatea descrisă mai sus este suportată „din cutie” de KȘ S-Terra. Aceasta înseamnă că nu a fost necesară instalarea unor module suplimentare care ar putea influența certificarea criptogărzilor și acreditarea întregului sistem informațional. Canalele dintre site-uri pot fi oricum, chiar și prin internet.
Datorită faptului că la schimbarea infrastructurii interne nu este necesară reconfigurarea criptogărzilor, sistemul funcționează ca un serviciu, ceea ce este foarte convenabil pentru client: își poate localiza serviciile (client și server) la orice adrese, iar toate modificările vor fi transmise dinamic între echipamentele de criptare.
Desigur, criptarea din cauza cheltuielilor suplimentare (overhead) influențează viteza de transmitere a datelor, dar nesemnificativ – lățimea de bandă a canalului poate scădea cu maxim 5-10%. Totuși, tehnologia a fost testată și a arătat rezultate bune chiar și pe canale prin satelit, care sunt destul de instabile și au o lățime de bandă scăzută.
Igor Vinohodov, inginer de a doua linie de administrare „Rostelecom-Solar”
Sursa: habr.com
