Ciframos según GOST: una guía para configurar el enrutamiento dinámico del tráfico

Ciframos según GOST: una guía para configurar el enrutamiento dinámico del tráfico
Si su empresa transmite o recibe datos personales y otra información confidencial a través de la red que está sujeta a protección de acuerdo con la ley, debe utilizar el cifrado GOST. Hoy le contaremos cómo implementamos dicho cifrado basado en la puerta de enlace criptográfica (CS) de S-Terra en uno de los clientes. Esta historia será de interés 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 centraremos en los puntos clave de la configuración básica. En Internet se encuentran disponibles gratuitamente enormes volúmenes de documentación sobre la configuración de demonios del sistema operativo Linux, en el que se basa S-Terra CS. La documentación para configurar el software propietario S-Terra también está disponible públicamente en el portal fabricante

Algunas palabras sobre el proyecto.

La topología de red del cliente era estándar: malla completa entre el centro y las sucursales. Fue necesario introducir el cifrado de los canales de intercambio de información entre todos los sitios, de los cuales había 8.

Por lo general, en tales proyectos todo es estático: las rutas estáticas a la red local del sitio se configuran en puertas de enlace criptográficas (CG), y se registran listas de direcciones IP (ACL) para el cifrado. Sin embargo, en este caso, los sitios no tienen un control centralizado y dentro de sus redes locales puede pasar cualquier cosa: las redes se pueden agregar, eliminar y modificar de todas las formas posibles. Para evitar reconfigurar el enrutamiento y ACL en KS al cambiar la dirección 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 en el nivel central de la red en los sitios ( en algunos sitios, los administradores de infraestructura prefirieron usar SNAT frente a KS en enrutadores del kernel).

Los túneles GRE nos permitieron resolver dos problemas:
1. Utilice la dirección IP de la interfaz externa del CS para el cifrado en la ACL, que encapsula todo el tráfico enviado a otros sitios.
2. Organice túneles ptp entre CS, que le permitan configurar el enrutamiento dinámico (en nuestro caso, el MPLS L3VPN del proveedor está organizado entre los sitios).

El cliente ordenó la implementación del cifrado como servicio. De lo contrario, no sólo tendría que mantener las puertas de enlace criptográficas o subcontratarlas a alguna organización, sino también monitorear de forma independiente el ciclo de vida de los certificados de cifrado, renovarlos a tiempo e instalar otros nuevos.
Ciframos según GOST: una guía para configurar el enrutamiento dinámico del tráfico
Y ahora la nota real: cómo y qué configuramos.

Nota sobre el tema de la CII: configuración de una puerta de enlace criptográfica

Configuración básica de la red

En primer lugar, lanzamos un nuevo CS y accedemos a la consola de administración. Debe comenzar cambiando la contraseña de administrador integrada: comando cambiar contraseña de usuario administrador. Luego debe realizar el procedimiento de inicialización (comando inicializar) durante el cual se ingresan los datos de la licencia y se inicializa el sensor de números aleatorios (RNS).

Preste atención! Cuando se inicializa S-Terra CC, se establece una política de seguridad en la que las interfaces de la puerta de enlace de seguridad no permiten el paso de paquetes. Debe crear su propia política o utilizar el comando ejecutar csconf_mgr activar 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 CS y configurar el cifrado a través de una consola tipo Cisco. Esta consola está diseñada para ingresar comandos similares a los comandos de Cisco IOS. La configuración generada utilizando la consola similar a Cisco se convierte, a su vez, en los archivos de configuración correspondientes con los que trabajan los demonios del sistema operativo. Puede ir a la consola tipo Cisco desde la consola de administración con el comando configurar.

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

>habilitar
Contraseña: csp (preinstalada)
#configurar terminal
#nombre de usuario cscons privilegio 15 secreto 0 #enable secreto 0 Configuración de la red básica:

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

GRE

Salga de la consola tipo Cisco y vaya al shell de Debian con el comando te. Establece tu propia contraseña para el usuario raíz el equipo passwd.
En cada sala de control, se configura un túnel separado para cada sitio. La interfaz del túnel está configurada en el archivo. / etc / network / interfaces. La utilidad de túnel IP, incluida en el conjunto iproute2 preinstalado, es responsable de crear la interfaz en sí. El comando de creación de interfaz está escrito en la opción previa al inicio.

Ejemplo de configuración de una interfaz de túnel típica:
sitio de automóviles1
iface sitio1 inet estático
dirección 192.168.1.4
netmask 255.255.255.254
túnel IP previo a la instalación agregar modo sitio1 gre local 10.111.21.3 remoto 10.111.22.3 clave hfLYEg^vCh6p

Preste atención! Cabe señalar que la configuración de las interfaces del túnel debe ubicarse fuera de la sección

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

De lo contrario, estas configuraciones se sobrescribirán al cambiar la configuración de red de las interfaces físicas a través de una 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 demonios. cebra и ospfd. El demonio zebra es responsable de la comunicación entre los demonios de enrutamiento y el sistema operativo. El demonio ospfd, como su nombre indica, es responsable de implementar el protocolo OSPF.
OSPF se configura a través de la consola del demonio o directamente a través del archivo de configuración /etc/quagga/ospfd.conf. Todas las interfaces físicas y de túnel que participan en el enrutamiento dinámico se agregan al archivo y también se declaran las redes que se anunciarán y recibirán anuncios.

Un ejemplo de la configuración que debe agregarse a ospfd.conf:
interfaz eth0
!
interfaz eth1
!
sitio de interfaz1
!
sitio de interfaz2
enrutador ospf
ID del enrutador OSPF 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 están reservadas para redes de tránsito entre CS y enrutadores del kernel.

Preste 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 no hay redistribución conectada o redistribuir mapa de ruta conectado.

Después de configurar los demonios, debe cambiar el estado de inicio de los demonios en /etc/quagga/daemons. en opciones cebra и ospfd no hay cambios a sí. Inicie el demonio quagga y configúrelo para que se ejecute automáticamente cuando inicie el comando KS actualizar-rc.d quagga habilitar.

Si la configuración de los túneles GRE y OSPF se realiza correctamente, entonces las rutas en la red de otros sitios deberían aparecer en los enrutadores centrales y KSh y, por lo tanto, surge la conectividad de red entre las redes locales.

Ciframos el tráfico transmitido

Como ya se ha escrito, normalmente al cifrar entre sitios, especificamos rangos de direcciones IP (ACL) entre los cuales se cifra el tráfico: si las direcciones de origen y de destino se encuentran dentro de estos rangos, entonces el tráfico entre ellas se cifra. 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 direcciones de origen y destino para cifrar el tráfico; después de todo, el tráfico que ya está encapsulado por el protocolo GRE llega para cifrarse. En otras palabras, todo lo que ingresa al CS desde la red local de un sitio hacia las redes anunciadas por otros sitios está cifrado. Y dentro de cada uno de los sitios se puede realizar cualquier redirección. Así, si hay algún cambio en las redes locales, el administrador sólo necesita modificar los anuncios provenientes de su red hacia la red, y quedará disponible para otros sitios.

El cifrado en S-Terra CS se realiza mediante el protocolo IPSec. Utilizamos el algoritmo "Grasshopper" de acuerdo con GOST R 34.12-2015 y, para compatibilidad con versiones anteriores, puede utilizar GOST 28147-89. Técnicamente, la autenticación 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.

Trabajar con certificados, contenedores y CRL se realiza mediante la utilidad cert_mgr. En primer lugar, usando el comando cert_mgr crear es necesario generar un contenedor de claves privadas y una solicitud de certificado, que será enviada al Centro de Gestión de Certificados. Después de recibir el certificado, se debe importar junto con el certificado de CA raíz y la CRL (si se usa) con el comando importación cert_mgr. Puede asegurarse de que todos los certificados y CRL estén instalados con el comando mostrar cert_mgr.

Después de instalar exitosamente 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 que se está creando, que se ofrecerá al socio para su aprobación.

#crypto política isakmp 1000
#encr gost341215k
#hashgost341112-512-tc26
#signo de autenticación
#grupo vko2
#vida 3600

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

Establecer ACL:
#ip acceso-lista extendida sitio1
#permitir gre host 10.111.21.3 host 10.111.22.3

Un conjunto de transformaciones (igual que en la primera fase, utilizamos el algoritmo de cifrado "Grasshopper" utilizando el modo de generación de inserción de simulación):

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

Creamos un mapa criptográfico, especificamos la ACL, el conjunto de transformación y la dirección del par:

#mapa criptográfico PRINCIPAL 100 ipsec-isakmp
#coincidir con la dirección del sitio1
#set transformar-establecer GOST
#establecer par 10.111.22.3

Vinculamos la tarjeta criptográfica a la interfaz externa de la caja registradora:

#interfaz GigabitEthernet0/0
# dirección IP 10.111.21.3 255.255.255.0
#mapa criptográfico PRINCIPAL

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

Preste atención! Si no se utiliza la verificación de certificado por CRL, esto debe especificarse explícitamente:

#crypto pki punto de confianza s-terra_technological_trustpoint
#revocación-verificar ninguna

En este punto, la configuración se puede considerar completa. En la salida del comando de la consola tipo Cisco mostrar cripto isakmp sa и mostrar cripto ipsec sa Se deben reflejar las fases primera y segunda construidas de IPSec. La misma información se puede obtener usando el comando. espectáculo sa_mgr, ejecutado desde el shell de Debian. En la salida del comando mostrar cert_mgr Deberían aparecer los certificados del sitio remoto. El estado de dichos certificados será sanaciones. Si no se están construyendo túneles, debe consultar 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

El S-Terra CC utiliza el demonio snmpd estándar para el monitoreo. Además de los parámetros típicos de Linux, S-Terra admite de fábrica la emisión de datos sobre túneles IPSec de acuerdo con CISCO-IPSEC-FLOW-MONITOR-MIB, que es lo que utilizamos cuando monitoreamos el estado de los túneles IPSec. También se admite la funcionalidad de OID personalizados que muestran los resultados de la ejecución del script como valores. Esta función nos permite realizar un seguimiento de las fechas de vencimiento de los certificados. El script escrito analiza la salida del comando. mostrar cert_mgr y como resultado proporciona el número de días hasta que caduquen los certificados local y raíz. Esta técnica es indispensable cuando se administra una gran cantidad de CABG.
Ciframos según GOST: una guía para configurar el enrutamiento dinámico del tráfico

¿Cuál es el beneficio de dicho cifrado?

Todas las funciones descritas anteriormente son compatibles desde el primer momento con el S-Terra KSh. Es decir, no fue necesario instalar ningún módulo adicional que pudiera afectar la certificación de las pasarelas criptográficas y la certificación de todo el sistema de información. Puede haber cualquier canal entre sitios, incluso a través de Internet.

Debido al hecho de que cuando cambia 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 transferirán dinámicamente entre los equipos de cifrado.

Por supuesto, el cifrado debido a los costos generales (gastos generales) afecta la velocidad de transferencia de datos, pero solo ligeramente: el rendimiento del canal puede disminuir en un máximo de un 5 a un 10%. Al mismo tiempo, la tecnología ha sido probada y ha mostrado buenos resultados incluso en canales por satélite, que son bastante inestables y tienen poco ancho de banda.

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

Fuente: habr.com

Añadir un comentario