Se a súa empresa transmite ou recibe datos persoais e outra información confidencial a través da rede que está suxeita a protección de acordo coa lei, debe utilizar o cifrado GOST. Hoxe contarémosche como implementamos ese cifrado baseado na pasarela criptográfica S-Terra (CS) nun dos clientes. Esta historia será de interese para especialistas en seguridade da información, así como para enxeñeiros, deseñadores e arquitectos. Non mergullaremos profundamente nos matices da configuración técnica nesta publicación; centrarémonos nos puntos clave da configuración básica. Grandes volumes de documentación sobre a configuración de daemons do sistema operativo Linux, nos que se basea o S-Terra CS, están dispoñibles gratuitamente en Internet. A documentación para configurar o software propietario S-Terra tamén está dispoñible públicamente en fabricante.
Unhas palabras sobre o proxecto
A topoloxía de rede do cliente era estándar: malla completa entre o centro e as sucursais. Foi necesario introducir o cifrado das canles de intercambio de información entre todos os sitios, dos que había 8.
Normalmente, nestes proxectos todo é estático: as rutas estáticas á rede local do sitio están configuradas en pasarelas criptográficas (CG), rexístrase listas de enderezos IP (ACL) para o cifrado. Non obstante, neste caso, os sitios non teñen control centralizado, e calquera cousa pode ocorrer dentro das súas redes locais: as redes pódense engadir, eliminar e modificar de todas as formas posibles. Para evitar a reconfiguración do enrutamento e da ACL no KS cando se cambia o enderezo das redes locais nos sitios, decidiuse utilizar o túnel GRE e o enrutamento dinámico OSPF, que inclúe todos os KS e a maioría dos enrutadores no núcleo de rede nos sitios ( nalgúns sitios, os administradores de infraestrutura preferiron usar SNAT cara a KS nos enrutadores do núcleo).
O túnel GRE permitiunos resolver dous problemas:
1. Use o enderezo IP da interface externa do CS para o cifrado na ACL, que encapsula todo o tráfico enviado a outros sitios.
2. Organiza túneles ptp entre CS, que che permiten configurar o enrutamento dinámico (no noso caso, o MPLS L3VPN do provedor está organizado entre os sitios).
O cliente ordenou a implementación do cifrado como servizo. En caso contrario, tería que non só manter pasarelas criptográficas ou subcontratalas a algunha organización, senón tamén supervisar de forma independente o ciclo de vida dos certificados de cifrado, renovalos a tempo e instalar outros novos.
E agora a nota real: como e que configuramos
Nota para o tema CII: configuración dunha pasarela criptográfica
Configuración básica da rede
En primeiro lugar, lanzamos un novo CS e entramos na consola de administración. Debería comezar cambiando o comando contrasinal do administrador integrado cambiar o contrasinal do usuario administrador. A continuación, cómpre realizar o procedemento de inicialización (comando arrincar) durante o cal se introducen os datos da licenza e se inicia o sensor de números aleatorios (RNS).
Preste atención! Cando se inicializa S-Terra CC, establécese unha política de seguridade na que as interfaces da pasarela de seguridade non permiten o paso de paquetes. Debes crear a túa propia política ou usar o comando executa csconf_mgr activate activar unha política de permisos predefinida.
A continuación, cómpre configurar o enderezo das interfaces externas e internas, así como a ruta predeterminada. É preferible traballar coa configuración de rede CS e configurar o cifrado a través dunha consola similar a Cisco. Esta consola está deseñada para introducir comandos similares aos comandos de Cisco IOS. A configuración xerada mediante a consola tipo Cisco convértese, á súa vez, nos correspondentes ficheiros de configuración cos que traballan os daemons do SO. Podes ir á consola tipo Cisco desde a consola de administración co comando configurar.
Cambia os contrasinais para os cscons de usuario integrados e activa:
> activar
Contrasinal: csp (preinstalado)
#configure terminal
#username cscons privilege 15 secret 0 #enable secret 0 Configuración da configuración básica da rede:
#interface GigabitEthernet0/0
# enderezo IP 10.111.21.3 255.255.255.0
#sen apagado
#interface GigabitEthernet0/1
# enderezo IP 192.168.2.5 255.255.255.252
#sen apagado
#ip ruta 0.0.0.0 0.0.0.0 10.111.21.254
GRE
Saia da consola tipo Cisco e vai ao shell debian co comando sistema. Establece o teu propio contrasinal para o usuario raíz o equipo passwd.
En cada sala de control, configúrase un túnel separado para cada sitio. A interface do túnel está configurada no ficheiro / etc / network / interfaces. A utilidade do túnel IP, incluída no conxunto iproute2 preinstalado, é a responsable de crear a propia interface. O comando de creación da interface está escrito na opción previa.
Exemplo de configuración dunha interface de túnel típica:
sitio automático 1
iface site1 inet static
enderezo 192.168.1.4
máscara de rede 255.255.255.254
pre-up túnel ip engadir modo site1 gre local 10.111.21.3 remoto 10.111.22.3 clave hfLYEg^vCh6p
Preste atención! Nótese que a configuración das interfaces do túnel debe situarse fóra da sección
###netifcfg-begin###
*****
###netifcfg-end###
En caso contrario, esta configuración sobrescribirase ao cambiar a configuración de rede das interfaces físicas a través dunha consola tipo Cisco.
Enrutamento dinámico
En S-Terra, o enrutamento dinámico implétase mediante o paquete de software Quagga. Para configurar OSPF necesitamos activar e configurar daemons cebra и ospfd. O daemon zebra é responsable da comunicación entre os daemons de enrutamento e o SO. O daemon ospfd, como o nome indica, é o responsable de implementar o protocolo OSPF.
OSPF configúrase a través da consola daemon ou directamente a través do ficheiro de configuración /etc/quagga/ospfd.conf. Engádense ao ficheiro todas as interfaces físicas e de túnel que participan no enrutamento dinámico e tamén se declaran as redes que se anunciarán e recibirán anuncios.
Un exemplo da configuración que hai que engadir ospfd.conf:
interface eth0
!
interface eth1
!
sitio de interface 1
!
sitio de interface 2
router ospf
ID do enrutador ospf 192.168.2.21
rede 192.168.1.4/31 área 0.0.0.0
rede 192.168.1.16/31 área 0.0.0.0
rede 192.168.2.4/30 área 0.0.0.0
Neste caso, os enderezos 192.168.1.x/31 resérvanse para redes ptp de túneles entre sitios, os enderezos 192.168.2.x/30 atribúense para redes de tránsito entre CS e enrutadores do núcleo.
Preste atención! Para reducir a táboa de enrutamento en grandes instalacións, pode filtrar a publicidade das propias redes de tránsito mediante as construcións ningunha redistribución conectada ou redistribuír o mapa de rutas conectado.
Despois de configurar os daemons, cómpre cambiar o estado de inicio dos daemons /etc/quagga/daemons. En opcións cebra и ospfd ningún cambio a si. Inicie o daemon quagga e configúreo en execución automática cando inicie o comando KS update-rc.d activar quagga.
Se a configuración dos túneles GRE e OSPF se fai correctamente, as rutas da rede doutros sitios deberían aparecer nos enrutadores KSh e principais e, polo tanto, xorde a conectividade de rede entre as redes locais.
Ciframos o tráfico transmitido
Como xa se escribiu, normalmente ao cifrar entre sitios, especificamos intervalos de enderezos IP (ACL) entre os que se cifra o tráfico: se os enderezos de orixe e destino están dentro destes intervalos, entón o tráfico entre eles está cifrado. Non obstante, neste proxecto a estrutura é dinámica e as direccións poden cambiar. Dado que xa configuramos o túnel GRE, podemos especificar enderezos KS externos como enderezos de orixe e destino para cifrar o tráfico; despois de todo, o tráfico que xa está encapsulado polo protocolo GRE chega para o cifrado. Noutras palabras, todo o que entra no CS desde a rede local dun sitio cara a redes que foron anunciadas por outros sitios está cifrado. E dentro de cada un dos sitios pódese realizar calquera redirección. Así, se hai algún cambio nas redes locais, o administrador só necesita modificar os anuncios que veñen da súa rede cara á rede, e esta estará dispoñible para outros sitios.
O cifrado en S-Terra CS realízase mediante o protocolo IPSec. Usamos o algoritmo "Grasshopper" de acordo co GOST R 34.12-2015, e para compatibilidade con versións antigas pode usar GOST 28147-89. A autenticación pódese realizar tecnicamente tanto en claves predefinidas (PSK) como en certificados. Non obstante, na operación industrial é necesario utilizar certificados emitidos de acordo co GOST R 34.10-2012.
O traballo con certificados, contedores e CRL realízase mediante a utilidade certificado_mgr. En primeiro lugar, usando o comando cert_mgr crear é necesario xerar un contedor de clave privada e unha solicitude de certificado, que se enviará ao Centro de Xestión de Certificados. Despois de recibir o certificado, debe importarse xunto co certificado CA raíz e CRL (se se usa) co comando importación cert_mgr. Podes asegurarte de que todos os certificados e CRL estean instalados co comando cert_mgr espectáculo.
Despois de instalar correctamente os certificados, vaia á consola similar a Cisco para configurar IPSec.
Creamos unha política IKE que especifica os algoritmos e parámetros desexados da canle segura que se está a crear, que se ofrecerá ao socio para a súa aprobación.
#crypto política isakmp 1000
#encr gost341215k
#hash gost341112-512-tc26
#sinal de autenticación
#grupo vko2
#vida 3600
Esta política aplícase ao crear a primeira fase de IPSec. O resultado da conclusión exitosa da primeira fase é a creación de SA (Asociación de Seguridade).
A continuación, necesitamos definir unha lista de enderezos IP de orixe e destino (ACL) para o cifrado, xerar un conxunto de transformacións, crear un mapa criptográfico (mapa criptográfico) e vinculalo á interface externa do CS.
Establecer ACL:
#ip access-list sitio estendido1
#permit gre host 10.111.21.3 host 10.111.22.3
Un conxunto de transformacións (igual que para a primeira fase, usamos o algoritmo de cifrado "Grasshopper" usando o modo de xeración de inserción de simulación):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Creamos un mapa criptográfico, especificamos a ACL, o conxunto de transformacións e o enderezo de pares:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Vinculamos a tarxeta criptográfica á interface externa da caixa rexistradora:
#interface GigabitEthernet0/0
# enderezo IP 10.111.21.3 255.255.255.0
#crypto map MAIN
Para cifrar canles con outros sitios, debes repetir o procedemento para crear unha ACL e unha tarxeta criptográfica, cambiando o nome da ACL, os enderezos IP e o número da tarxeta criptográfica.
Preste atención! Se non se utiliza a verificación do certificado mediante CRL, debe especificarse explícitamente:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocación-comproba ningunha
Neste punto, a configuración pódese considerar completa. Na saída do comando da consola similar a Cisco mostrar crypto isakmp sa и mostrar cripto ipsec sa Deben reflectirse as primeiras e segundas fases construídas de IPSec. A mesma información pódese obter mediante o comando show sa_mgr, executado dende o shell debian. Na saída do comando cert_mgr espectáculo Deberían aparecer os certificados do sitio remoto. O estado de tales certificados será remoto. Se non se están construíndo túneles, cómpre consultar o rexistro do servizo VPN, que se almacena no ficheiro /var/log/cspvpngate.log. Na documentación está dispoñible unha lista completa de ficheiros de rexistro cunha descrición do seu contido.
Vixilancia da "saúde" do sistema
O S-Terra CC usa o daemon snmpd estándar para supervisar. Ademais dos parámetros típicos de Linux, S-Terra admite a emisión de datos sobre túneles IPSec de acordo co CISCO-IPSEC-FLOW-MONITOR-MIB, que é o que usamos cando monitorizamos o estado dos túneles IPSec. Tamén se admite a funcionalidade dos OID personalizados que emiten os resultados da execución do script como valores. Esta función permítenos seguir as datas de caducidade do certificado. O script escrito analiza a saída do comando cert_mgr espectáculo e como resultado dá o número de días ata que caducan os certificados locais e raíz. Esta técnica é indispensable cando se administra un gran número de CABG.
Cal é o beneficio deste tipo de cifrado?
S-Terra KSh admite todas as funcións descritas anteriormente. É dicir, non houbo que instalar ningún módulo adicional que puidese afectar á certificación de pasarelas criptográficas e á certificación de todo o sistema de información. Pode haber calquera canle entre sitios, incluso a través de Internet.
Debido ao feito de que cando a infraestrutura interna cambia, non hai necesidade de reconfigurar as pasarelas criptográficas, o sistema funciona como un servizo, que é moi cómodo para o cliente: pode colocar os seus servizos (cliente e servidor) en calquera enderezo, e todos os cambios serán transferidos de forma dinámica entre equipos de cifrado.
Por suposto, o cifrado debido aos custos xerais (overhead) afecta a velocidade de transferencia de datos, pero só lixeiramente - o rendemento da canle pode diminuír nun máximo de 5-10%. Ao mesmo tempo, a tecnoloxía foi probada e mostrou bos resultados incluso en canles de satélite, que son bastante inestables e teñen un ancho de banda baixo.
Igor Vinokhodov, enxeñeiro da 2ª liña de administración de Rostelecom-Solar
Fonte: www.habr.com