Se la vostra azienda trasmette o riceve dati personali e altre informazioni riservate sulla rete soggetta a protezione ai sensi di legge, è tenuta a utilizzare la crittografia GOST. Oggi vi diremo come abbiamo implementato tale crittografia basata sul gateway crittografico S-Terra (CS) presso uno dei clienti. Questa storia interesserà gli specialisti della sicurezza informatica, nonché ingegneri, designer e architetti. In questo post non approfondiremo le sfumature della configurazione tecnica; ci concentreremo sui punti chiave della configurazione di base. Enormi volumi di documentazione sulla configurazione dei demoni del sistema operativo Linux, su cui si basa S-Terra CS, sono disponibili gratuitamente su Internet. Anche la documentazione per la configurazione del software proprietario S-Terra è disponibile al pubblico su produttore.
Qualche parola sul progetto
La topologia di rete del cliente era standard: mesh completa tra il centro e le filiali. È stato necessario introdurre la crittografia dei canali di scambio di informazioni tra tutti i siti, di cui erano 8.
Di solito in tali progetti tutto è statico: i percorsi statici verso la rete locale del sito sono impostati su gateway crittografici (CG), vengono registrati elenchi di indirizzi IP (ACL) per la crittografia. In questo caso, però, i siti non hanno un controllo centralizzato e all'interno delle loro reti locali può succedere di tutto: le reti possono essere aggiunte, cancellate e modificate in ogni modo possibile. Per evitare di riconfigurare il routing e l'ACL sul KS quando si modifica l'indirizzamento delle reti locali nei siti, si è deciso di utilizzare il tunneling GRE e il routing dinamico OSPF, che include tutti i KS e la maggior parte dei router a livello del core della rete nei siti ( in alcuni siti, gli amministratori dell'infrastruttura preferiscono utilizzare SNAT verso KS sui router kernel).
Il tunneling GRE ci ha permesso di risolvere due problemi:
1. Utilizza l'indirizzo IP dell'interfaccia esterna del CS per la crittografia nell'ACL, che incapsula tutto il traffico inviato ad altri siti.
2. Organizzare tunnel ptp tra CS, che consentono di configurare il routing dinamico (nel nostro caso, tra i siti è organizzato MPLS L3VPN del provider).
Il cliente ha ordinato l'implementazione della crittografia come servizio. Altrimenti, dovrebbe non solo mantenere i gateway crittografici o esternalizzarli a qualche organizzazione, ma anche monitorare in modo indipendente il ciclo di vita dei certificati di crittografia, rinnovarli in tempo e installarne di nuovi.
E ora il promemoria vero e proprio: come e cosa abbiamo configurato
Nota sull'argomento CII: configurazione di un gateway crittografico
Configurazione di rete di base
Prima di tutto lanciamo un nuovo CS ed entriamo nella console di amministrazione. Dovresti iniziare modificando la password dell'amministratore integrata - comando cambiare password utente amministratore. Successivamente è necessario eseguire la procedura di inizializzazione (command inizializzazione) durante il quale vengono immessi i dati della licenza e viene inizializzato il sensore di numeri casuali (RNS).
Fate attenzione! Quando S-Terra CC viene inizializzato, viene stabilita una politica di sicurezza in cui le interfacce del gateway di sicurezza non consentono il passaggio dei pacchetti. È necessario creare la propria policy oppure utilizzare il comando esegui csconf_mgr attiva attivare una politica di autorizzazione predefinita.
Successivamente è necessario configurare l'indirizzamento delle interfacce esterne ed interne, nonché il percorso predefinito. È preferibile lavorare con la configurazione di rete CS e configurare la crittografia tramite una console tipo Cisco. Questa console è progettata per immettere comandi simili ai comandi Cisco IOS. La configurazione generata utilizzando la console simile a Cisco viene, a sua volta, convertita nei corrispondenti file di configurazione con cui funzionano i demoni del sistema operativo. Puoi andare alla console simile a Cisco dalla console di amministrazione con il comando configure.
Modifica le password per i cscons utente integrati e abilita:
>abilitare
Password: csp (preinstallato)
#configura terminale
#nomeutente cscons privilegio 15 segreto 0 #abilita segreto 0 Impostazione della configurazione di rete di base:
#interfaccia GigabitEthernet0/0
#indirizzoip 10.111.21.3 255.255.255.0
#nessun arresto
#interfaccia GigabitEthernet0/1
#indirizzoip 192.168.2.5 255.255.255.252
#nessun arresto
#ip percorso 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Esci dalla console tipo Cisco e vai alla shell Debian con il comando sistema. Imposta la tua password per l'utente radice Il gruppo passwd.
In ciascuna sala di controllo è configurato un tunnel separato per ciascun sito. L'interfaccia del tunnel è configurata nel file / etc / network / interfaces. L'utilità tunnel IP, inclusa nel set iproute2 preinstallato, è responsabile della creazione dell'interfaccia stessa. Il comando di creazione dell'interfaccia è scritto nell'opzione pre-up.
Esempio di configurazione di una tipica interfaccia tunnel:
sito automatico1
iface sito1 inet statico
indirizzo 192.168.1.4
maschera di rete 255.255.255.254
pre-up tunnel ip aggiunta modalità sito1 gre locale 10.111.21.3 remoto 10.111.22.3 chiave hfLYEg^vCh6p
Fate attenzione! Va notato che le impostazioni per le interfacce del tunnel devono essere posizionate all'esterno della sezione
###netifcfg-begin###
*****
###netifcfg-end###
In caso contrario, queste impostazioni verranno sovrascritte quando si modificano le impostazioni di rete delle interfacce fisiche tramite una console simile a Cisco.
Routing dinamico
In S-Terra, il routing dinamico viene implementato utilizzando il pacchetto software Quagga. Per configurare OSPF dobbiamo abilitare e configurare i demoni zebra и ospfd. Il demone zebra è responsabile della comunicazione tra i demoni di routing e il sistema operativo. Il demone ospfd, come suggerisce il nome, è responsabile dell'implementazione del protocollo OSPF.
OSPF viene configurato tramite la console del daemon o direttamente tramite il file di configurazione /etc/quagga/ospfd.conf. Tutte le interfacce fisiche e tunnel che partecipano al routing dinamico vengono aggiunte al file e vengono dichiarate anche le reti che verranno pubblicizzate e riceveranno annunci.
Un esempio della configurazione a cui è necessario aggiungere ospfd.conf:
interfaccia eth0
!
interfaccia eth1
!
sito di interfaccia1
!
sito di interfaccia2
router osp
ospf router-id 192.168.2.21
rete 192.168.1.4/31 zona 0.0.0.0
rete 192.168.1.16/31 zona 0.0.0.0
rete 192.168.2.4/30 zona 0.0.0.0
In questo caso, gli indirizzi 192.168.1.x/31 sono riservati per le reti tunnel ptp tra siti, gli indirizzi 192.168.2.x/30 sono allocati per le reti di transito tra CS e router kernel.
Fate attenzione! Per ridurre la tabella di instradamento nelle grandi installazioni è possibile filtrare l'annuncio delle reti di transito stesse utilizzando i costrutti nessuna ridistribuzione collegata o ridistribuire la mappa del percorso connesso.
Dopo aver configurato i demoni, è necessario modificare lo stato di avvio dei demoni in /etc/quagga/demoni. Nelle opzioni zebra и ospfd nessun cambiamento in sì. Avvia il demone quagga e impostalo su esecuzione automatica quando avvii il comando KS update-rc.d quagga abilita.
Se la configurazione dei tunnel GRE e OSPF viene eseguita correttamente, i percorsi nella rete di altri siti dovrebbero apparire su KSh e sui router principali e, quindi, si verifica la connettività di rete tra le reti locali.
Crittifichiamo il traffico trasmesso
Come è già stato scritto, solitamente quando crittografiamo tra siti, specifichiamo intervalli di indirizzi IP (ACL) tra i quali viene crittografato il traffico: se gli indirizzi di origine e di destinazione rientrano in questi intervalli, il traffico tra loro viene crittografato. Tuttavia in questo progetto la struttura è dinamica e gli indirizzi possono cambiare. Poiché abbiamo già configurato il tunneling GRE, possiamo specificare indirizzi KS esterni come indirizzi di origine e destinazione per crittografare il traffico: dopo tutto, il traffico già incapsulato dal protocollo GRE arriva per la crittografia. In altre parole, tutto ciò che entra nel CS dalla rete locale di un sito verso le reti annunciate da altri siti viene crittografato. E all'interno di ciascuno dei siti è possibile eseguire qualsiasi reindirizzamento. Pertanto, se si verifica un cambiamento nelle reti locali, l'amministratore dovrà solo modificare gli annunci provenienti dalla sua rete verso la rete e questi diventeranno disponibili ad altri siti.
La crittografia in S-Terra CS viene eseguita utilizzando il protocollo IPSec. Utilizziamo l'algoritmo "Grasshopper" in conformità con GOST R 34.12-2015 e per compatibilità con le versioni precedenti è possibile utilizzare GOST 28147-89. Tecnicamente l'autenticazione può essere eseguita sia su chiavi predefinite (PSK) che su certificati. Tuttavia, nel funzionamento industriale è necessario utilizzare i certificati emessi in conformità con GOST R 34.10-2012.
L'utilizzo di certificati, contenitori e CRL viene eseguito utilizzando l'utilità cert_mgr. Prima di tutto, utilizzando il comando cert_mgr creare è necessario generare un contenitore di chiave privata e una richiesta di certificato, che verrà inviata al Centro Gestione Certificati. Dopo aver ricevuto il certificato, è necessario importarlo insieme al certificato CA radice e alla CRL (se utilizzata) con il comando importazione cert_mgr. Puoi assicurarti che tutti i certificati e i CRL siano installati con il comando cert_mgr mostra.
Dopo aver installato correttamente i certificati, vai alla console simile a Cisco per configurare IPSec.
Creiamo una policy IKE che specifica gli algoritmi e i parametri desiderati del canale sicuro in fase di creazione, che verrà offerto al partner per l'approvazione.
Politica #crypto isakmp 1000
#encrgost341215k
#hashgost341112-512-tc26
#segno di autenticazione
#gruppo vko2
#durata 3600
Questa policy viene applicata durante la creazione della prima fase di IPSec. Il risultato del positivo completamento della prima fase è la costituzione della SA (Security Association).
Successivamente, dobbiamo definire un elenco di indirizzi IP di origine e destinazione (ACL) per la crittografia, generare un set di trasformazione, creare una mappa crittografica (mappa crittografica) e associarla all'interfaccia esterna del CS.
Imposta ACL:
#ip access-list sito esteso1
#permit gre host 10.111.21.3 host 10.111.22.3
Una serie di trasformazioni (come per la prima fase, utilizziamo l'algoritmo di crittografia “Grasshopper” utilizzando la modalità di generazione degli inserti di simulazione):
#crypto ipsec trasforma-set GOST esp-gost341215k-mac
Creiamo una mappa crittografica, specifichiamo l'ACL, il set di trasformazione e l'indirizzo peer:
#mappa crittografica MAIN 100 ipsec-isakmp
#corrisponde all'indirizzo sito1
#set trasformazione-imposta GOST
#imposta peer 10.111.22.3
Leghiamo la carta crittografica all'interfaccia esterna del registratore di cassa:
#interfaccia GigabitEthernet0/0
#indirizzoip 10.111.21.3 255.255.255.0
#mappa crittografica PRINCIPALE
Per crittografare i canali con altri siti, è necessario ripetere la procedura per la creazione di una ACL e di una scheda crittografica, modificando il nome ACL, gli indirizzi IP e il numero della scheda crittografica.
Fate attenzione! Se non viene utilizzata la verifica del certificato da parte della CRL, questo deve essere esplicitamente specificato:
#crypto pki trustpoint s-terra_technological_trustpoint
#revoca-controllo nessuno
A questo punto il setup può considerarsi concluso. Nell'output dei comandi della console simile a Cisco mostra cripto isakmp sa и mostra cripto ipsec sa Dovrebbero essere rispecchiate la prima e la seconda fase costruite di IPSec. Le stesse informazioni possono essere ottenute utilizzando il comando spettacolo sa_mgr, eseguito dalla shell Debian. Nell'output del comando cert_mgr mostra Dovrebbero essere visualizzati i certificati del sito remoto. Lo stato di tali certificati sarà a distanza. Se i tunnel non vengono costruiti, è necessario consultare il registro del servizio VPN, archiviato nel file /var/log/cspvpngate.log. Un elenco completo dei file di registro con una descrizione del loro contenuto è disponibile nella documentazione.
Monitoraggio dello “stato di salute” del sistema
S-Terra CC utilizza il demone snmpd standard per il monitoraggio. Oltre ai tipici parametri Linux, S-Terra supporta immediatamente l'emissione di dati sui tunnel IPSec in conformità con CISCO-IPSEC-FLOW-MONITOR-MIB, che è ciò che utilizziamo quando monitoriamo lo stato dei tunnel IPSec. È supportata anche la funzionalità degli OID personalizzati che restituiscono i risultati dell'esecuzione dello script come valori. Questa funzionalità ci consente di tenere traccia delle date di scadenza dei certificati. Lo script scritto analizza l'output del comando cert_mgr mostra e di conseguenza fornisce il numero di giorni rimanenti fino alla scadenza dei certificati locale e radice. Questa tecnica è indispensabile quando si somministrano un gran numero di CABG.
Qual è il vantaggio di tale crittografia?
Tutte le funzionalità sopra descritte sono supportate immediatamente da S-Terra KSh. Non è stato cioè necessario installare alcun modulo aggiuntivo che potesse incidere sulla certificazione dei gateway crittografici e sulla certificazione dell'intero sistema informativo. Possono esserci qualsiasi canale tra i siti, anche tramite Internet.
Poiché quando l'infrastruttura interna cambia, non è necessario riconfigurare i gateway crittografici, il sistema funziona come un servizio, il che è molto conveniente per il cliente: può collocare i suoi servizi (client e server) a qualsiasi indirizzo e tutte le modifiche verranno trasferite dinamicamente tra le apparecchiature di crittografia.
Naturalmente, la crittografia dovuta ai costi generali (overhead) influisce sulla velocità di trasferimento dei dati, ma solo leggermente: la velocità effettiva del canale può diminuire al massimo del 5-10%. Allo stesso tempo, la tecnologia è stata testata e ha mostrato buoni risultati anche sui canali satellitari, che sono piuttosto instabili e hanno una larghezza di banda ridotta.
Igor Vinokhodov, ingegnere della 2a linea di amministrazione di Rostelecom-Solar
Fonte: habr.com