Se la tua azienda trasmette o riceve tramite rete dati personali e altre informazioni confidenziali soggette a protezione secondo la legge, è necessario applicare la crittografia secondo lo standard GOST. Oggi parleremo di come abbiamo implementato tale crittografia sulla base del gateway crittografico (KSh) S-Terra presso uno dei nostri clienti. Questa storia sarà interessante per gli specialisti della sicurezza informatica, oltre che per ingegneri, progettisti e architetti. Non ci addentreremo nei dettagli della configurazione tecnica in questo post — ci concentreremo sui punti chiave della configurazione di base. Ci sono enormi volumi di documentazione sulla configurazione dei demoni del sistema operativo Linux, su cui si basa il KSh S-Terra, disponibili liberamente su internet. La documentazione sulla configurazione del software proprietario S-Terra è anch'essa accessibile al pubblico presso sito del produttore.
Due parole sul progetto
La topologia di rete del cliente era tipica: full mesh tra il centro e le filiali. Era necessario implementare la crittografia dei canali per lo scambio di informazioni tra tutte le sedi, che erano 8.
Di solito in progetti simili tutto è statico: nei gateway crittografici (KSh) vengono impostate rotte statiche nella rete locale della sede, e vengono scritti elenchi di indirizzi IP (ACL) per la crittografia. Tuttavia, in questo caso le sedi non hanno una gestione centralizzata, e all'interno delle loro reti locali può accadere di tutto: le reti possono essere aggiunte, rimosse e modificate in vari modi. Per evitare la necessità di riconfigurare la routazione e gli ACL sui KSh in caso di modifica degli indirizzi delle reti locali, è stata presa la decisione di utilizzare il tunneling GRE e la routazione dinamica OSPF, che include tutti i KSh e la maggior parte dei router di livello core delle sedi (in alcune sedi gli amministratori dell'infrastruttura hanno preferito utilizzare SNAT verso i KSh sui router core).
Il tunneling GRE ha permesso di risolvere due problemi:
1. Utilizzare nell'ACL per la crittografia l'indirizzo IP dell'interfaccia esterna del KSh, in cui è incapsulato tutto il traffico diretto verso le altre sedi.
2. Organizzare tunnel p-t-p tra i KSh, che consentono di impostare la routazione dinamica (nel nostro caso è stato organizzato un MPLS L3VPN da parte del provider tra le sedi).
Il cliente ha ordinato l'implementazione della crittografia come servizio. Altrimenti, avrebbe dovuto non solo mantenere i gateway crittografici o esternalizzare a qualche organizzazione, ma anche monitorare autonomamente il ciclo di vita dei certificati di crittografia, rinnovarli in tempo e installare nuovi certificati.
E ora, il promemoria su come e cosa abbiamo configurato
Nota per il soggetto KII: configurazione del gateway crittografico
Impostazione di base della rete
Per prima cosa, avviamo il nuovo KSH e accediamo alla console di amministrazione. Iniziamo con la modifica della password dell'amministratore integrato — comando change user password administrator. Poi è necessario procedere con la procedura di inizializzazione (comando initialize) durante la quale vengono inseriti i dati della licenza e viene inizializzato il generatore di numeri casuali (GNC).
Attenzione! Durante l'inizializzazione del KSH S-Terra, viene stabilita una politica di sicurezza in base alla quale le interfacce del gateway di sicurezza non consentono il passaggio dei pacchetti. È necessario creare una propria politica o attivare la politica di autorizzazione preimpostata con il comando run csconf_mgr activate .
Successivamente, è necessario configurare gli indirizzi delle interfacce esterne e interne, così come il percorso predefinito. È preferibile eseguire le operazioni di configurazione della rete del KSH e configurare la crittografia tramite la console Cisco-like. Questa console è destinata all'inserimento di comandi simili a quelli di Cisco IOS. La configurazione creata tramite la console Cisco-like viene quindi convertita nei relativi file di configurazione, con cui lavorano i demoni del sistema operativo. È possibile accedere alla console Cisco-like dalla console di amministrazione con il comando configure.
Cambiamo le password per l'utente integrato cscons e enable:
>enable
Password: csp (preimpostato)
#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
Esci dalla console Cisco-like e accedi al shell di Debian con il comando system. Imposta la tua password per l'utente root comando passwd.
Ogni KSH ha la propria configurazione di tunnel per ciascun sito. La configurazione dell'interfaccia tunnel avviene nel file /etc/network/interfaces. La creazione stessa dell'interfaccia è gestita dallo strumento IP tunnel, che fa parte del pacchetto preimpostato iproute2. Il comando per creare l'interfaccia viene inserito nell'opzione pre-up.
Esempio di configurazione di un'interfaccia tunnel tipica:
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
Attenzione! È importante notare che le impostazioni delle interfacce tunnel devono essere posizionate al di fuori della sezione
###netifcfg-begin###
*****
###netifcfg-end###
Altrimenti, queste impostazioni verranno sovrascritte quando si modificano le impostazioni di rete delle interfacce fisiche tramite la console simile a Cisco.
Routing dinamico
In S-Terra, il routing dinamico è implementato tramite il pacchetto software Quagga. Per configurare OSPF, è necessario abilitare e configurare i demoni. zebra e ospfd. Il demone zebra è responsabile dell'interazione tra i demoni di routing e il sistema operativo. Il demone ospfd, come suggerisce il nome, è responsabile dell'implementazione del protocollo OSPF.
La configurazione di OSPF viene eseguita attraverso la console del demone o direttamente tramite il file di configurazione /etc/quagga/ospfd.conf. Nel file vengono aggiunte tutte le interfacce fisiche e tunnel coinvolte nel routing dinamico, vengono dichiarate anche le reti che verranno annunciate e accetteranno annunci.
Esempio di configurazione da aggiungere a 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
In questo caso, gli indirizzi 192.168.1.x/31 sono assegnati per reti ptp tunnel tra i siti, mentre gli indirizzi 192.168.2.x/30 sono per reti di transito tra il router e i router core.
Attenzione! Per ridurre la tabella di routing in grandi installazioni, è possibile filtrare l'annuncio delle reti di transito stesse utilizzando le costruzioni no redistribute connected o redistribute connected route-map.
Dopo aver configurato i demoni, è necessario modificare lo stato di avvio dei demoni in /etc/quagga/daemons. Nelle opzioni, cambiare no in yes. Avviare il demone quagga e impostare il suo avvio automatico all'avvio del router con il comando zebra e ospfd update-rc.d quagga enable Se la configurazione dei tunnel GRE e OSPF è corretta, dovrebbero apparire rotte nei router core e nei router, creando così connettività di rete tra le reti locali..
Criptiamo il traffico trasmesso
Crittografiamo il traffico trasmesso
Come già accennato, di solito durante la crittografia tra i punti di accesso indichiamo le gamme di indirizzi IP (ACL) tra cui viene crittografato il traffico: se gli indirizzi di origine e di destinazione rientrano in queste gamme, il traffico tra di essi viene crittografato. Tuttavia, in questo progetto la struttura è dinamica e gli indirizzi possono cambiare. Poiché abbiamo già configurato il tunneling GRE, possiamo utilizzare gli indirizzi esterni del KSH come indirizzi di origine e di destinazione per la crittografia del traffico, poiché il traffico in arrivo è già incapsulato nel protocollo GRE. In altre parole, viene crittografato tutto ciò che entra nel KSH dalla rete locale di un punto di accesso verso le reti annunciate da altri punti di accesso. E già all'interno di ciascun punto di accesso può essere eseguita qualsiasi reindirizzamento. Pertanto, in caso di modifiche alle reti locali, è sufficiente che l'amministratore modifichi gli annunci provenienti dalla propria rete verso il KSH, e questa diventerà accessibile ad altri punti di accesso.
La crittografia nel KSH S-Terra avviene tramite il protocollo IPSec. Utilizziamo l'algoritmo "Grasshopper" in conformità con GOST R 34.12-2015, e per la compatibilità con le versioni precedenti è possibile utilizzare GOST 28147-89. L'autenticazione può tecnicamente avvenire sia su chiavi predefinite (PSK) che su certificati. Tuttavia, nell'uso industriale è necessario utilizzare certificati emessi secondo GOST R 34.10-2012.
La gestione di certificati, contenitori e CRL avviene tramite l'utility cert_mgr. Per prima cosa, utilizzando il comando cert_mgr create , è necessario creare un contenitore per la chiave privata e una richiesta di certificato che sarà inviata al Centro di gestione dei certificati. Dopo aver ricevuto il certificato, è necessario importarlo insieme al certificato radice dell'CA e al CRL (se utilizzato) con il comando cert_mgr import. È possibile verificare che tutti i certificati e il CRL siano stati installati correttamente con il comando cert_mgr show.
. Dopo aver installato con successo i certificati, si passa alla console in stile Cisco per configurare IPSec.
Creiamo una politica IKE in cui vengono indicati gli algoritmi desiderati e i parametri del canale sicuro creato, che saranno proposti al partner per la negoziazione.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Questa politica viene applicata durante la costruzione della prima fase di IPSec. Il risultato del superamento con successo della prima fase è l'istituzione di un SA (Security Association).
Successivamente, sarà necessario definire l'elenco degli indirizzi IP di origine e di destinazione (ACL) per la crittografia, formare un set di trasformazioni (transform set), creare una mappa crittografica (crypto map) e collegarla all'interfaccia esterna del KSH.
Impostiamo l'ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Set di trasformazioni (utilizzando, come per la prima fase, l'algoritmo di crittografia «Grasshopper» in modalità di generazione del messaggio di autenticazione):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Creiamo la mappa crittografica, specificando l'ACL, il set di trasformazioni e l'indirizzo del peer:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Colleghiamo la mappa crittografica all'interfaccia esterna del KSH:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Per criptare i canali con altre piattaforme, è necessario ripetere la procedura di creazione dell'ACL e della mappa crittografica, modificando il nome dell'ACL, gli indirizzi IP e il numero della mappa crittografica.
Attenzione! Nel caso in cui non venga utilizzato il controllo dei certificati tramite CRL, è necessario indicarlo esplicitamente:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
A questo punto, la configurazione può dirsi completata. Nell'output dei comandi della console simile a Cisco show crypto isakmp sa e show crypto ipsec sa dovrebbero apparire le prime e seconde fasi di IPSec. Queste informazioni possono essere ottenute anche tramite il comando sa_mgr show, eseguito dalla shell di debian. Nell'output del comando cert_mgr show dovrebbero comparire i certificati delle piattaforme remote. Lo stato di tali certificati sarà remote. Nel caso in cui i tunnel non vengano stabiliti, è necessario controllare il log VPN-del servizio, che è conservato nel file /var/log/cspvpngate.log. L'elenco completo dei file di log con la descrizione del loro contenuto è presente nella documentazione.
Monitoriamo la «salute» del sistema
Nel KSH S-Terra per il monitoraggio viene utilizzato il demone snmpd standard. Oltre ai parametri tipici di Linux, S-Terra supporta «out of the box» la fornitura di dati sui tunnel IPSec in base a CISCO-IPSEC-FLOW-MONITOR-MIB, che utilizziamo per monitorare lo stato dei tunnel IPSec. Viene anche supportata la funzionalità degli OID personalizzati che restituiscono come valori i risultati dell'esecuzione di uno script. Questa possibilità ci consente di monitorare le scadenze dei certificati. Lo script scritto analizza l'output del comando cert_mgr show e restituisce il numero di giorni fino alla scadenza dei certificati locale e radice. Questa tecnica è indispensabile nella gestione di un gran numero di KSH.
Qual è il vantaggio di tale crittografia
Tutta la funzionalità descritta sopra è supportata «out of the box» dal KSh S-Terra. Questo significa che non è stato necessario installare alcun modulo aggiuntivo che potesse influire sulla certificazione dei gateway criptografici e sulla valutazione dell'intero sistema informatico. I canali tra le piattaforme possono essere di qualsiasi tipo, anche tramite internet.
Grazie al fatto che non è necessario riconfigurare i gateway criptografici quando si modifica l'infrastruttura interna, il sistema funziona come un servizio, il che è molto comodo per il cliente: può posizionare i propri servizi (client e server) su qualsiasi indirizzo e tutte le modifiche verranno trasferite dinamicamente tra l'attrezzatura di crittografia.
Senza dubbio, la crittografia a causa dell'overhead influisce sulla velocità di trasmissione dei dati, ma in modo insignificante: la capacità di banda del canale può ridursi al massimo del 5-10%. Tuttavia, la tecnologia è stata testata e ha dimostrato buoni risultati anche su canali satellitari, che sono piuttosto instabili e hanno una bassa capacità di banda.
Igor Vinokhodov, ingegnere di 2° livello di amministrazione «Rostelecom-Solar»
Fonte: habr.com
