Cifrado de acuerdo con GOST: memorando sobre la configuración del enrutamiento dinámico del tráfico


Si su empresa transmite o recibe a través de la red datos personales y otra información confidencial para protegerla de conformidad con la ley, es necesario que utilice el cifrado de acuerdo con GOST. Hoy le diremos cómo implementamos dicho cifrado basado en la puerta de enlace criptográfica S-Terra (KS) en uno de los clientes. Esta historia será interesante para los especialistas en seguridad de la información, así como para ingenieros, diseñadores y arquitectos. No profundizaremos en los matices de la configuración técnica en esta publicación, nos detendremos en los puntos clave de la configuración básica. Una gran cantidad de documentación sobre la configuración de demonios del sistema operativo Linux, en la que se basa el S-Terra KS, está disponible gratuitamente en Internet. La documentación de configuración del software propietario de S-Terra también está disponible públicamente en el portal del fabricante.

Algunas palabras sobre el proyecto.


La topología de red del cliente era típica: malla completa entre el centro y las sucursales. Se requirió introducir encriptación de canales de intercambio de información entre todos los sitios, de los cuales había 8 piezas.

Por lo general, en tales proyectos, todo es estático: en las puertas de enlace criptográficas (KS), las rutas estáticas se establecen en la red de área local del sitio, se escriben listas de direcciones IP (ACL) para el cifrado. Sin embargo, en este caso, los sitios no tienen una administración centralizada, y cualquier cosa puede suceder dentro de sus redes locales: las redes se pueden agregar, eliminar y modificar en todos los sentidos. Para evitar la reconfiguración del enrutamiento y las ACL al KS al cambiar el direccionamiento de las redes locales en los sitios, se decidió utilizar el túnel GRE y el enrutamiento dinámico OSPF, que incluye todos los KS y la mayoría de los enrutadores del nivel central de la red en los sitios (en algunos sitios, los administradores de infraestructura prefirieron use SNAT en la dirección de KS en los enrutadores del núcleo).

El túnel GRE resolvió dos problemas:
1. Utilice en la ACL para cifrar la dirección IP de la interfaz externa de KS, en la que se encapsula todo el tráfico enviado a otros sitios.
2. Organice túneles ptp entre KS, que le permiten configurar el enrutamiento dinámico (en nuestro caso, el proveedor MPLS L3VPN está organizado entre los sitios).

El cliente ordenó la implementación de cifrado como servicio. De lo contrario, no solo tendría que admitir las puertas de enlace de cifrado o externalizar alguna organización, sino también supervisar de forma independiente el ciclo de vida de los certificados de cifrado, renovarlos a tiempo e instalar otros nuevos.

Y ahora el memorándum mismo: cómo y qué configuramos

Nota de asunto de KII: configuramos una puerta de enlace criptográfica


Configuración básica de red


En primer lugar, lanzamos un nuevo caché y entramos en la consola de administración. Debería comenzar cambiando la contraseña del administrador incorporado: el comando de administrador de cambio de contraseña de usuario . Entonces es necesario llevar a cabo el procedimiento de inicialización (el comando de inicialización ) en el proceso en el que se ingresan los datos de la licencia y se inicializa el sensor de número aleatorio (DSN).

¡Presta atención! Cuando se inicializa S-Terra KS, se establece una política de seguridad en la que las interfaces de Security Gateway no pasan paquetes. Debe crear su propia política o utilizar el comando de ejecución csconf_mgr enable para activar una política de permisos predefinida.
A continuación, debe configurar el direccionamiento de las interfaces externas e internas, así como la ruta predeterminada. Es preferible trabajar con la configuración de red de la memoria caché y configurar el cifrado a través de la consola tipo Cisco. Esta consola está diseñada para ingresar comandos similares a los comandos de Cisco IOS. La configuración creada usando la consola similar a Cisco, a su vez, se convierte en los archivos de configuración correspondientes con los que trabajan los demonios del sistema operativo. Puede ir a la consola similar a Cisco desde la consola de administración con el comando configure .

Cambie las contraseñas para los cscons de usuario integrados y habilite:

> habilitar
Contraseña: csp (predefinida)
#configure terminal
#username cscons privilege 15 secret 0 #enable secret 0 Configure la configuración básica de la red:

#interface GigabitEthernet0 / 0
# dirección IP 10.111.21.3 255.255.255.0
#no apagado
#interface GigabitEthernet0 / 1
#ip dirección 192.168.2.5 255.255.255.252
#no apagado
#ip ruta 0.0.0.0 0.0.0.0 10.111.21.254

GRE


Salimos de la consola similar a Cisco y vamos al shell de Debian con el comando del sistema . Establezca su propia contraseña para el usuario root con el comando passwd .
Se configura un túnel separado para cada sitio en cada KSh. La interfaz del túnel se configura en el archivo / etc / network / interfaces . La utilidad de túnel IP, que forma parte del conjunto predefinido de iproute2, es responsable de crear la interfaz en sí. El comando para crear una interfaz está escrito en la opción de preajuste.

Ejemplo de configuración de una interfaz de túnel típica:
auto site1
iface site1 inet static
dirección 192.168.1.4
máscara de red 255.255.255.254
pre-up ip tunnel add site1 mode gre local 10.111.21.3 remoto 10.111.22.3 clave hfLYEg ^ vCh6p

¡Presta atención! Cabe señalar que la configuración de la interfaz del túnel debe ubicarse fuera de la sección

### netifcfg-begin ###
*****
### netifcfg-end ###

De lo contrario, esta configuración se borrará al cambiar la configuración de red de las interfaces físicas a través de la consola tipo Cisco.

Enrutamiento dinámico


En S-Terra, el enrutamiento dinámico se implementa utilizando el paquete de software Quagga. Para configurar OSPF, necesitamos habilitar y configurar los demonios zebra y ospfd . El demonio cebra es responsable de la interacción entre los demonios de enrutamiento y el sistema operativo. El demonio ospfd, como su nombre lo indica, es responsable de implementar el protocolo OSPF.
OSPF se configura a través de la consola daemon o directamente a través del archivo de configuración /etc/quagga/ospfd.conf . Todas las interfaces físicas y de túnel involucradas en el enrutamiento dinámico se agregan al archivo, y se anuncian las redes que serán anunciadas y recibirán anuncios.

Un ejemplo de configuración para agregar a ospfd.conf :
interfaz eth0
!
interfaz eth1
!
sitio de interfaz1
!
interfaz sitio2
enrutador ospf
ospf router-id 192.168.2.21
red 192.168.1.4/31 área 0.0.0.0
red 192.168.1.16/31 área 0.0.0.0
red 192.168.2.4/30 área 0.0.0.0

En este caso, las direcciones 192.168.1.x / 31 están reservadas para redes de túnel ptp entre sitios, las direcciones 192.168.2.x / 30 se asignan para redes de tránsito entre el CABG y los enrutadores centrales.

¡Presta atención! Para reducir la tabla de enrutamiento en grandes instalaciones, puede filtrar el anuncio de las propias redes de tránsito utilizando las construcciones de mapa de ruta no redistribuido conectado o redistribuido conectado .

Después de configurar los demonios, debe cambiar el estado de inicio del demonio en / etc / quagga / daemons . En las opciones zebra y ospfd no hay solución para yes. Ejecute el daemon quagga y configure su ejecución automática al iniciar el caché con el comando update-rc.d quagga enable .

Si los túneles GRE y OSPF están configurados correctamente, entonces las rutas a la red de otros sitios deben aparecer en los enrutadores KS y del kernel, y por lo tanto surge la conectividad de red entre redes locales.

Encriptamos el tráfico transmitido


Como ya se mencionó, cuando se encripta entre sitios, generalmente especificamos los rangos de direcciones IP (ACL) entre los cuales se encripta el tráfico: si las direcciones de origen y destino se encuentran dentro de estos rangos, entonces el tráfico entre ellos está encriptado. Sin embargo, en este proyecto, la estructura es dinámica y las direcciones pueden cambiar. Como ya hemos configurado el túnel GRE, podemos especificar direcciones KS externas como las direcciones de origen y destino para el cifrado de tráfico, porque para el cifrado viene el tráfico ya encapsulado por el protocolo GRE. En otras palabras, todo lo que ingresa al caché desde la red local de un sitio a las redes anunciadas por otros sitios está encriptado. Y ya dentro de cada uno de los sitios se puede realizar cualquier reenvío. Por lo tanto, con cualquier cambio en las redes locales, es suficiente que el administrador modifique los anuncios provenientes de su red hacia la escuela secundaria, y estará disponible para otros sitios.

El cifrado en el S-Terra KS se realiza utilizando el protocolo IPSec. Utilizamos el algoritmo Grasshopper de acuerdo con GOST R 34.12-2015, y para compatibilidad con versiones anteriores, se puede usar GOST 28147-89. La autenticación técnicamente se puede realizar tanto en claves predefinidas (PSK) como en certificados. Sin embargo, en la operación industrial es necesario utilizar certificados emitidos de acuerdo con GOST R 34.10-2012.

El trabajo con certificados, contenedores y CRL se realiza utilizando la utilidad cert_mgr . En primer lugar, con el comando cert_mgr create , debe crear un contenedor de clave privada y una solicitud de certificado, que se enviará al Centro de administración de certificados. Después de recibir el certificado, debe importarse con el comando cert_mgr import junto con el certificado raíz de la CA y la CRL (si se usa). Puede verificar que todos los certificados y CRL estén instalados con el comando cert_mgr show .

Después de instalar con éxito los certificados, vaya a la consola similar a Cisco para configurar IPSec.
Creamos una política IKE que especifica los algoritmos y parámetros deseados del canal seguro creado, que se ofrecerá al socio para su aprobación.

#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
# signo de autenticación
#group vko2
#vida 3600

Esta política se aplica al construir la primera fase de IPSec. La finalización exitosa de la primera fase es el establecimiento de SA (Asociación de Seguridad).
A continuación, debemos definir una lista de direcciones IP de origen y destino (ACL) para el cifrado, formar un conjunto de transformación, crear un mapa criptográfico (mapa criptográfico) y vincularlo a la interfaz externa del CAB.

Establecer la ACL:
#ip access-list extendió el sitio1
#permit gre host 10.111.21.3 host 10.111.22.3

Un conjunto de transformaciones (así como para la primera fase, usamos el algoritmo de encriptación Grasshopper usando el modo de simulación):

#crypto ipsec transform-set GOST esp-gost341215k-mac

Cree un mapa criptográfico, especifique ACL, conjunto de transformación y dirección de igual:

#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3

Adjuntamos el mapa criptográfico a la interfaz externa de la CABG:

#interface GigabitEthernet0 / 0
# dirección IP 10.111.21.3 255.255.255.0
#crypto map MAIN

Para cifrar canales con otros sitios, debe repetir el procedimiento para crear ACL y tarjetas criptográficas, cambiando el nombre de la ACL, las direcciones IP y el número de la tarjeta criptográfica.

¡Presta atención! Si no se utiliza la verificación del certificado CRL, esto debe especificarse explícitamente:

#crypto pki trustpoint s-terra_technological_trustpoint
# revocation-check none

En esta configuración se puede considerar completa. El resultado de los comandos de consola similares a los de Cisco show crypto isakmp sa y show crypto ipsec sa debería reflejar la primera y segunda fases construidas de IPSec. La misma información se puede obtener utilizando el comando sa_mgr show ejecutado desde el shell debian. La salida del comando cert_mgr show debe mostrar certificados de sitio remoto. El estado de dichos certificados será remoto . En el caso de que no se construyan túneles, debe buscar en el registro del servicio VPN, que se almacena en el archivo /var/log/cspvpngate.log . Una lista completa de archivos de registro con una descripción de su contenido está disponible en la documentación.

Monitorear la "salud" del sistema


S-Terra KS utiliza el demonio snmpd estándar para el monitoreo. Además de los parámetros típicos de Linux, S-Terra admite la salida de túneles IPSec de acuerdo con CISCO-IPSEC-FLOW-MONITOR-MIB, que utilizamos para monitorear el estado de los túneles IPSec. La funcionalidad de los OID personalizados también es compatible, dando los resultados del script como valores. Esta característica nos permite rastrear las fechas de vencimiento de los certificados. La secuencia de comandos escrita analiza la salida del comando cert_mgr show y, como resultado, proporciona el número de días antes del vencimiento de los certificados locales y raíz. Esta técnica es indispensable cuando se administra una gran cantidad de CABG.


¿Cuál es el cimus de tal cifrado?


Toda la funcionalidad descrita anteriormente es compatible con K-S-Terra "lista para usar". Es decir, no fue necesario instalar ningún módulo adicional que pudiera afectar la certificación de las puertas de enlace criptográficas y la certificación de todo el sistema de información. Los canales entre sitios pueden ser cualquiera, incluso a través de Internet.

Debido al hecho de que al cambiar la infraestructura interna no es necesario reconfigurar las puertas de enlace criptográficas, el sistema funciona como un servicio , lo cual es muy conveniente para el cliente: puede colocar sus servicios (cliente y servidor) en cualquier dirección, y todos los cambios se transfieren dinámicamente entre el equipo de cifrado.

Por supuesto, el cifrado debido a la sobrecarga afecta la velocidad de transferencia de datos, pero no de manera significativa: el ancho de banda del canal puede disminuir en un máximo del 5-10%. Además, la tecnología fue probada y mostró buenos resultados incluso en canales satelitales, que son bastante inestables y tienen poco ancho de banda.

Igor Vinokhodov, ingeniero de la segunda línea de administración de Rostelecom Solar

Source: https://habr.com/ru/post/471470/


All Articles