Se la tua azienda trasmette o riceve dati personali e altre informazioni riservate che devono essere protette secondo la legislazione, è necessario applicare la crittografia secondo GOST. Oggi ti racconteremo come abbiamo implementato questa crittografia utilizzando il gateway criptografico (KSh) S-Terra per uno dei nostri clienti. Questa storia sarà interessante per gli specialisti di sicurezza informatica, oltre che per ingegneri, progettisti e architetti. Non ci soffermeremo sulle complessità della configurazione tecnica in questo post — ci concentreremo sui punti chiave della configurazione di base. Ci sono enormi volumi di documentazione per la configurazione dei demoni del sistema operativo Linux, su cui si basa il KSh S-Terra, disponibili liberamente su Internet. Anche la documentazione per la configurazione del software proprietario S-Terra è accessibile pubblicamente su del produttore.
Qualche parola sul progetto
La topologia della rete del cliente era standard: full mesh tra il centro e le filiali. Era necessario implementare la crittografia dei canali di scambio delle informazioni tra tutti i siti, che erano 8.
Nei progetti simili, tutto è solitamente statico: nei gateway crittografici (CG) vengono definiti percorsi statici verso la rete locale, e si specificano le liste di indirizzi IP (ACL) per la crittografia. Tuttavia, in questo caso, le piattaforme non hanno una gestione centralizzata, quindi all'interno delle loro reti locali può accadere di tutto: le reti possono essere aggiunte, rimosse e modificate in vari modi. Per evitare la riconfigurazione della routing e delle ACL sui CG quando cambiano gli indirizzi delle reti locali, è stata presa la decisione di utilizzare il tunneling GRE e la routing dinamica OSPF, che includono tutti i CG e la maggior parte dei router di livello core delle reti sulle piattaforme (in alcune piattaforme, gli amministratori dell'infrastruttura hanno preferito utilizzare SNAT verso i CG sui router core).
Il tunneling GRE ha permesso di risolvere due problemi:
1. Utilizzare negli ACL per la crittografia l'indirizzo IP dell'interfaccia esterna del CG, nella quale viene incapsulato tutto il traffico diretto verso altre piattaforme.
2. Organizzare tunnel p-t-p tra le CSH che consentono di configurare il routing dinamico (nel nostro caso, tra i siti è stato organizzato un MPLS L3VPN del fornitore).
Il cliente ha richiesto l'implementazione della crittografia come servizio. Altrimenti, avrebbe dovuto non solo mantenere i gateways crittografici o esternalizzarli a un'organizzazione, ma anche monitorare autonomamente il ciclo di vita dei certificati di crittografia, rinnovandoli in tempo e installando nuovi.
Ora, ecco un promemoria – come e cosa abbiamo configurato.
Nota per il soggetto KII: configura il gateway crittografico.
Configura di base la rete.
Innanzitutto, avviamo il nuovo CSH e accediamo alla console di amministrazione. È opportuno iniziare modificando la password dell'amministratore integrato — comando change user password administrator. Successivamente, è necessario eseguire 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 impostata una politica di sicurezza che blocca i pacchetti negli interfacciamenti del gateway di sicurezza. È necessario creare una propria politica oppure utilizzare il comando run csconf_mgr activate per attivare la politica di autorizzazione preconfigurata.
Successivamente è necessario configurare gli indirizzi delle interfacce esterne e interne, oltre al percorso predefinito. È preferibile eseguire la configurazione di rete del KSH e l'impostazione della crittografia tramite una console simile a Cisco. Questa console è progettata per l'inserimento di comandi simili a quelli di Cisco IOS. La configurazione generata tramite la console simile a Cisco viene a sua volta convertita nei file di configurazione appropriati, con cui lavorano i demoni del sistema operativo. Puoi accedere alla console simile a Cisco dalla console di amministrazione utilizzando il comando configure.
Modifichiamo le password per l'utente integrato cscons e per l'abilitazione:
>enable
Password: csp (predefinita)
#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
Usciamo dalla console simile a Cisco e accediamo alla shell di debian con il comando sistemaImpostiamo una password personalizzata per l'utente root comando passwd.
Per ogni KSH viene configurato un tunnel separato per ogni piattaforma. La configurazione dell'interfaccia tunnel avviene nel file /etc/network/interfaces. La creazione dell'interfaccia stessa è gestita dall'utilità IP tunnel, inclusa nel pacchetto preinstallato iproute2. Il comando per la creazione dell'interfaccia è scritto nell'opzione pre-up.
Esempio di configurazione di un'interfaccia tunnel standard:
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! Va notato che le configurazioni delle interfacce tunnel devono essere posizionate al di fuori della sezione
###netifcfg-begin###
*****
###netifcfg-end###
In caso contrario, queste configurazioni verranno sovrascritte quando si modificano le impostazioni di rete delle interfacce fisiche tramite la console in stile Cisco.
Routing dinamico
In S-Terra, il routing dinamico è implementato tramite il pacchetto di programmi Quagga. Per configurare OSPF avremo bisogno di attivare e configurare i demoni zebra e ospfd. Il demone zebra si occupa delle interazioni 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 può essere effettuata sia tramite la console del demone, sia direttamente tramite il file di configurazione. /etc/quagga/ospfd.conf. Nel file vengono aggiunti tutti gli interfacce fisiche e tunnel coinvolti nella routing dinamica, e vengono dichiarate le reti che saranno pubblicizzate e accetteranno pubblicità.
Esempio di configurazione da aggiungere in ospfd.conf:
interfaccia eth0
!
interfaccia eth1
!
interfaccia site1
!
interfaccia 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 riservati per le reti ptp tunnel tra i siti, mentre gli indirizzi 192.168.2.x/30 sono per le reti di transito tra il switch di livello 3 e i router core.
Attenzione! Per ridurre la tabella di routing in grandi installazioni, è possibile filtrare la pubblicità delle stesse reti di transito utilizzando le configurazioni 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 zebra e ospfd no in yes. Avviare il demone quagga e impostare il suo avvio automatico all'avvio del switch di livello 3 con il comando update-rc.d quagga enable.
Se la configurazione dei tunnel GRE e OSPF è corretta, le rotte nella rete degli altri siti dovrebbero apparire sul switch di livello 3 e sui router core, creando così connettività tra le reti locali.
Criptiamo il traffico trasmesso
Come già menzionato, di solito durante la crittografia tra le piattaforme specifichiamo i range degli indirizzi IP (ACL) all'interno dei quali il traffico viene cifrato: se gli indirizzi di origine e di destinazione rientrano in questi intervalli, il traffico tra di essi viene criptato. Tuttavia, in questo progetto la struttura è dinamica e gli indirizzi possono cambiare. Poiché abbiamo già configurato il tunneling GRE, come indirizzi di origine e di destinazione per la crittografia del traffico possiamo specificare gli indirizzi esterni del KSH – infatti, il traffico che viene crittografato è già incapsulato dal protocollo GRE. In altre parole, viene criptato tutto ciò che entra nel KSH dalla rete locale di una piattaforma verso le reti pubblicizzate da altre piattaforme. E all'interno di ciascuna piattaforma può avvenire qualsiasi tipo di inoltro. Pertanto, in caso di modifiche alle reti locali, l'amministratore deve semplicemente modificare gli annunci provenienti dalla sua rete verso il KSH, rendendolo accessibile ad altre piattaforme.
La crittografia in S-Terra viene eseguita tramite il protocollo IPSec. Utilizziamo l'algoritmo «Grasshopper» in conformità con GOST R 34.12-2015, mentre per la compatibilità con le versioni precedenti possono essere utilizzati GOST 28147-89. L'autenticazione può essere eseguita tecnicamente sia su chiavi predefinite (PSK) sia su certificati. Tuttavia, nell'uso industriale è necessario utilizzare certificati emessi secondo GOST R 34.10-2012.
La gestione dei certificati, dei contenitori e del 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 verrà inviata al Centro di gestione dei certificati. Dopo aver ricevuto il certificato, è necessario importarlo insieme al certificato radice dell'AC e al CRL (se utilizzato) utilizzando il comando cert_mgr import. Per assicurarsi che tutti i certificati e il CRL siano stati installati correttamente, si può usare il comando cert_mgr show.
. Dopo un'installazione riuscita dei certificati, accediamo alla console in stile Cisco per configurare IPSec.
Creiamo una politica IKE che specifica gli algoritmi e i parametri desiderati per il canale protetto, che saranno proposti al partner per approvazione.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Questa politica viene applicata nella creazione della prima fase di IPSec. Il risultato di una prima fase completata con successo è l'instaurazione di una SA (Security Association).
Dobbiamo poi definire un elenco di indirizzi IP di origine e destinatario (ACL) per la crittografia, formare un insieme di trasformazioni (transform set), creare una mappa crittografica (crypto map) e associarla all'interfaccia esterna del KSH.
Definiamo l'ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Set di trasformazioni (come per la prima fase, utilizziamo l'algoritmo di crittografia 'Caterpillar' in modalità di generazione di macchinette di hashing):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Creiamo la mappa crittografica, specificando l'ACL, il transform set 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 la crittografia dei canali con altre piattaforme, è necessario ripetere la procedura di creazione dell'ACL e della mappa crittografica, cambiando il nome dell'ACL, gli indirizzi IP e il numero della mappa crittografica.
Attenzione! Nel caso in cui non venga utilizzata la verifica dei certificati tramite CRL, è necessario indicarlo esplicitamente:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Questa configurazione può considerarsi completata. Nella console simile a Cisco, si dovrebbero vedere show crypto isakmp sa e show crypto ipsec sa le prime e seconde fasi di IPSec. Queste informazioni possono essere ottenute anche tramite il comando sa_mgr show, eseguito dalla shell di Debian. Nella output del comando cert_mgr show si dovrebbero visualizzare i certificati delle sedi remote. Lo stato di tali certificati sarà remoto. Nel caso in cui i tunnel non vengano stabiliti, è necessario controllare il log VPN-del servizio, che si trova nel file /var/log/cspvpngate.log. Un elenco completo dei file di log con la descrizione del loro contenuto è disponibile nella documentazione.
Monitoriamo la "salute" del sistema
Nel sistema S-Terra, si utilizza il demone standard snmpd per il monitoraggio. Oltre ai parametri tipici di Linux, S-Terra supporta "out of the box" l'emissione di dati sui tunnel IPSec secondo il CISCO-IPSEC-FLOW-MONITOR-MIB, che utilizziamo per monitorare lo stato dei tunnel IPSec. È anche supportata la funzionalità di 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 locali e root. Questa funzionalità è indispensabile nella gestione di un gran numero di KSH.
Qual è il succo di questa crittografia?
Tutta la funzionalità descritta sopra è supportata "out of the box" dai KSH S-Terra. Quindi non è stato necessario installare moduli aggiuntivi che potrebbero influenzare la certificazione dei gateway crittografici e l'accreditamento dell'intero sistema informativo. I canali tra i siti possono essere di qualsiasi tipo, anche attraverso Internet.
Grazie al fatto che non è necessario riconfigurare i gateway crittografici in caso di cambiamenti nell'infrastruttura interna, il sistema funziona come un servizio, il che è molto comodo per il cliente: può posizionare i propri servizi (clienti e server) su qualsiasi indirizzo, e tutte le modifiche verranno trasmesse dinamicamente tra l'attrezzatura di crittografia.
Senza dubbio, la crittografia comporta un sovraccarico che influisce sulla velocità di trasmissione dei dati, ma in modo marginale: la capacità del canale può diminuire al massimo del 5-10%. Tuttavia, questa tecnologia è stata testata e ha dimostrato buoni risultati anche su canali satellitari, che sono piuttosto instabili e hanno una bassa capacità.
Igor Vinokhodov, ingegnere di seconda linea per l'amministrazione di «Rostelecom-Solar»
Fonte: habr.com
