Si su empresa transmite o recibe datos personales y otra información confidencial que debe ser protegida de acuerdo con la legislación, es necesario aplicar encriptación según GOST. Hoy les contaremos cómo implementamos dicha encriptación utilizando el gateway criptográfico S-Terra para uno de nuestros clientes. Esta historia será interesante para 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 este post, sino que nos detendremos en los puntos clave de la configuración básica. Hay una gran cantidad de documentación sobre la configuración de demonios de sistemas operativos Linux, sobre los que se basa el S-Terra, disponible públicamente en Internet. La documentación sobre la configuración del software propietario S-Terra también está disponible al público en el fabricante.
Unas palabras sobre el proyecto
La topología de red del cliente era típica: full mesh entre la sede central y las sucursales. Era necesario implementar la encriptación de los canales de intercambio de información entre todos los sitios, que eran 8.
Normalmente, en proyectos como este, todo es estático: se configuran rutas estáticas en los gateways criptográficos (KSh) hacia la red local del sitio, se especifican listas de direcciones IP (ACL) para la encriptación. Sin embargo, en este caso, los sitios no tienen gestión centralizada, y dentro de sus redes locales puede ocurrir cualquier cosa: las redes pueden ser añadidas, eliminadas y modificadas de diversas formas. Para evitar la reconfiguración de rutas y ACL en los KSh al cambiar la direccionamiento de las redes locales en los sitios, se tomó la decisión de utilizar túneles GRE y enrutamiento dinámico OSPF, en el que están incluidos todos los KSh y la mayoría de los routers de núcleo de la red en los sitios (en algunos sitios, los administradores de infraestructura prefirieron utilizar SNAT hacia los KSh en los routers de núcleo).
El túnel GRE permitió resolver dos tareas:
1. Utilizar en las ACL para la encriptación la dirección IP de la interfaz externa del KSh, en la que se encapsula todo el tráfico que se dirige a otros sitios.
2. Organizar túneles p-t-p entre los KSh, que permiten configurar el enrutamiento dinámico (en nuestro caso, se organizó un MPLS L3VPN de proveedor entre los sitios).
El cliente solicitó la implementación de cifrado como servicio. De lo contrario, tendría que no solo mantener los criptoenrutadores o externalizarlo a alguna organización, sino también monitorear por sí mismo el ciclo de vida de los certificados de cifrado, renovarlos a tiempo e instalar nuevos.
Y ahora, en realidad, la nota – cómo y qué configuramos
Nota para el sujeto del KII: configuramos el criptoenrutador
Configuración básica de la red
Primero iniciamos el nuevo CE y accedemos a la consola de administración. Es recomendable comenzar por cambiar la contraseña del administrador incorporado — el comando change user password administrator. Luego es necesario llevar a cabo el procedimiento de inicialización (comando initialize) durante el cual se introducen los datos de la licencia y se inicializa el generador de números aleatorios (GNA).
¡Atención! Al inicializar el CE S-Terra, se establece una política de seguridad en la que las interfaces del enrutador de seguridad no permiten paquetes. Es necesario crear una política propia o activar la política de permisos preestablecida mediante el comando run csconf_mgr activate .
A continuación, es necesario configurar las direcciones de las interfaces externas e internas, así como la ruta por defecto. Se recomienda trabajar con la configuración de red del CE y la configuración de cifrado a través de la consola tipo Cisco. Esta consola está diseñada para introducir comandos similares a los comandos de Cisco IOS. La configuración formada mediante la consola tipo Cisco se convierte a su vez en los correspondientes archivos de configuración, que son manejados por los demonios del sistema operativo. Se puede acceder a la consola tipo Cisco desde la consola de administración mediante el comando — simplemente ejecuto.
Cambiamos las contraseñas del usuario incorporado cscons y enable:
>enable
Contraseña: csp (preestablecido)
#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
Salimos de la consola tipo Cisco y pasamos a la shell de debian con el comando system. Establecemos nuestra propia contraseña para el usuario root con el comando passwd.
En cada CE se configura un túnel separado para cada sitio. La configuración de la interfaz de túnel se realiza en el archivo /etc/network/interfaces. La utilidad IP tunnel, que forma parte del conjunto preinstalado iproute2, es responsable de la creación de la propia interfaz. El comando para crear la interfaz se registra en la opción pre-up.
Ejemplo de configuración de una interfaz de túnel típica:
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
¡Atención! Es importante notar que la configuración de las interfaces de túnel debe estar fuera de la sección
###netifcfg-begin###
*****
###netifcfg-end###
De lo contrario, esta configuración se sobrescribirá al cambiar la configuración 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 a través del paquete de software Quagga. Para configurar OSPF, necesitaremos habilitar y ajustar los demonios zebra y ospfd. El demonio zebra se encarga de la interacción entre los demonios de enrutamiento y el sistema operativo. El demonio ospfd, como se entiende por su nombre, es responsable de la implementación del protocolo OSPF.
La configuración de OSPF se puede realizar a través de la consola del demonio o directamente a través del archivo de configuración /etc/quagga/ospfd.conf. En el archivo se añaden todas las interfaces físicas y de túnel que participan en el enrutamiento dinámico, así como las redes que se anunciarán y recibirán anuncios.
Ejemplo de configuración que debe añadirse a ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface 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
En este caso, las direcciones 192.168.1.x/31 están reservadas para redes ptp de túneles entre las ubicaciones, mientras que las direcciones 192.168.2.x/30 son para redes de tránsito entre el KSH y los enrutadores centrales.
¡Atención! Para reducir la tabla de enrutamiento en instalaciones grandes, se puede filtrar el anuncio de las propias redes de tránsito mediante construcciones no redistribute connected o redistribute connected route-map.
Después de configurar los demonios, es necesario cambiar el estado de inicio de los demonios en /etc/quagga/daemons. En las opciones zebra y ospfd no se corrige a yes. Iniciar el demonio quagga y habilitar su inicio automático al arrancar el KSH con el comando update-rc.d quagga enable.
Si la configuración de los túneles GRE y OSPF se ha realizado correctamente, deberían aparecer rutas en el KSH y en los enrutadores centrales en la red de las otras ubicaciones, y así establecer conectividad de red entre las redes locales.
Ciframos el tráfico transmitido
Como ya se mencionó, generalmente al cifrar entre plataformas, especificamos rangos de direcciones IP (ACL) entre los cuales se cifra el tráfico: si las direcciones de origen y destino están dentro de estos rangos, 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 un túnel GRE, podemos usar las direcciones externas de la red de control (КШ) como direcciones de origen y destino para cifrar el tráfico, ya que el tráfico que se cifra ya está encapsulado por el protocolo GRE. En otras palabras, se cifra todo lo que llega a la red de control desde la red local de una plataforma hacia redes que han sido anunciadas por otras plataformas. Y dentro de cada una de las plataformas se puede realizar cualquier redirección. Así, ante cualquier cambio en las redes locales, el administrador solo necesita modificar los anuncios que van desde su red hacia la red de control, y esta se volverá accesible para otras plataformas.
El cifrado en la red de control S-Terra se realiza a través del protocolo IPSec. Utilizamos el algoritmo 'Grasshopper' de acuerdo con GOST R 34.12-2015, y para la compatibilidad con versiones más antiguas se puede aplicar GOST 28147-89. La autenticación puede llevarse a cabo técnicamente tanto con claves predefinidas (PSK) como con certificados. Sin embargo, en la explotación industrial es necesario usar certificados emitidos de acuerdo con GOST R 34.10-2012.
El trabajo con certificados, contenedores y CRL se realiza mediante la utilidad cert_mgr. Primero, con el comando cert_mgr create , es necesario crear el contenedor de clave privada y la solicitud de certificado, que se enviará al Centro de gestión de certificados. Después de recibir el certificado, este, junto con el certificado raíz de la CA y el CRL (si se utiliza), debe importarse con el comando cert_mgr import. Se puede verificar que todos los certificados y CRL se instalaron correctamente con el comando cert_mgr show.
. Tras la instalación exitosa de los certificados, pasamos a la consola tipo Cisco para configurar IPSec.
Creamos una política IKE, en la que se especifican los algoritmos y parámetros deseados del canal seguro que se propondrán al socio para la negociación.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Esta política se aplica al establecer la primera fase de IPSec. El resultado de pasar exitosamente la primera fase es el establecimiento de SA (Asociación de Seguridad).
A continuación, necesitaremos definir la lista de direcciones IP de origen y receptor (ACL) para el cifrado, crear un conjunto de transformaciones (transform set), establecer un mapa criptográfico (crypto map) y vincularlo a la interfaz externa del KСH.
Establecemos ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Conjunto de transformaciones (al igual que en la primera fase, utilizamos el algoritmo de cifrado «Grasshopper» en modo de producción de inserción de firma):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Creamos el mapa criptográfico, especificando ACL, el conjunto de transformaciones y la dirección del par:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Vinculamos el mapa criptográfico a la interfaz externa del KСH:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Para cifrar canales con otros sitios, es necesario repetir el procedimiento de creación del ACL y del mapa criptográfico, cambiando el nombre del ACL, las direcciones IP y el número del mapa criptográfico.
¡Atención! En caso de que no se utilice la comprobación de certificados a través de CRL, esto debe indicarse explícitamente:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
Con esto, la configuración se puede considerar completada. En la salida de comandos de la consola tipo Cisco show crypto isakmp sa y show crypto ipsec sa deben reflejarse las fases uno y dos del IPSec construidas. Esta misma información se puede obtener mediante el comando sa_mgr show, ejecutado desde el shell de debian. En la salida del comando cert_mgr show deben aparecer los certificados de los sitios remotos. El estado de dichos certificados será remoto. En caso de que los túneles no se construyan, es necesario revisar el log VPN-servicio, que se guarda en el archivo /var/log/cspvpngate.log. La lista completa de archivos de logs con la descripción de su contenido está presente en la documentación.
Monitoreamos la «salud» del sistema
En el KСH S-Terra, se utiliza el demonio estándar snmpd para la monitorización. Además de los parámetros típicos de Linux, S-Terra admite «out-of-the-box» la emisión de datos sobre los túneles IPSec de acuerdo con CISCO-IPSEC-FLOW-MONITOR-MIB, que utilizamos para rastrear el estado de los túneles IPSec. También se admite la funcionalidad de OID personalizados que emiten como valores los resultados de la ejecución de un script. Esta capacidad nos permite rastrear los plazos de caducidad de los certificados. El script escrito analiza la salida del comando cert_mgr show y como resultado devuelve la cantidad de días hasta la caducidad de los certificados local y raíz. Este enfoque es indispensable para administrar un gran número de KСH.
¿Cuál es la esencia de este cifrado?
Toda la funcionalidad descrita anteriormente está soportada 'de fábrica' por el KSH S-Terra. Es decir, no fue necesario instalar módulos adicionales que pudieran afectar la certificación de los criptogateways y la validación de todo el sistema de información. Los canales entre las plataformas pueden ser cualquier tipo, incluso a través de Internet.
Gracias a que no es necesario reconfigurar los criptogateways al cambiar la infraestructura interna, el sistema funciona como un servicio, lo que es muy conveniente para el cliente: puede ubicar sus servicios (tanto los del cliente como los del servidor) en cualquier dirección, y todos los cambios se transmitirán dinámicamente entre el equipo de cifrado.
Sin duda, el cifrado debido a los gastos operativos (overhead) afecta la velocidad de transmisión de datos, pero de manera insignificante: el ancho de banda del canal puede disminuir como máximo entre un 5 y un 10%. Además, la tecnología ha sido probada y ha mostrado buenos resultados incluso en canales satelitales, que son bastante inestables y tienen un bajo ancho de banda.
Igor Vinokhodov, ingeniero de segunda línea de administración en 'Rostelecom-Solar'
Fuente: habr.com
