Configurar perfiles IPsec Sophos Firewall con seguridad

Un perfil IPsec determina con qué seguridad y bajo qué condiciones se negocia un túnel IPsec. Define la versión IKE, el cifrado, la integridad, el grupo DH, PFS, las duraciones de las claves, la renovación de claves y Dead Peer Detection. Si estos valores no coinciden con los de la contraparte, el túnel no se establece o falla durante una renovación posterior.

Recomendación rápida para nuevas conexiones Site-to-Site: utilizar IKEv2, ofrecer solo las combinaciones robustas que sean realmente necesarias, activar PFS y la renovación de claves y configurar DPD según la función del firewall. Si ambos extremos lo admiten, AES256GCM16 con el grupo 19 (ecp256) para DH y PFS es el punto de partida moderno que propone Avanet. No es un valor predeterminado de Sophos ni una recomendación general del fabricante; prevalecen los requisitos de la contraparte.

Este artículo explica el perfil. La conexión propiamente dicha, con Gateway, IDs, redes, reglas, NAT y Routing, se describe en Configurar una VPN IPsec Site-to-Site en Sophos Firewall. Si un túnel existente no se establece o no transporta tráfico, consulte Solución de problemas de VPN IPsec en Sophos Firewall.

Qué controla un perfil IPsec

El perfil reúne los parámetros de seguridad comunes a Phase 1 y Phase 2 y puede asignarse a varias conexiones. Antes de modificarlo, hay que comprobar qué conexiones lo utilizan. En vez de cambiar directamente un perfil de sistema o producción compartido, se clona y la copia se prueba primero solo con la conexión prevista.

El perfil no incluye:

• dirección pública o FQDN de la contraparte
• Preshared Key, certificado o RSA Key
• Local ID y Remote ID
• redes locales y remotas o Traffic Selectors
• reglas de firewall, NAT y Routing
• dirección XFRM, SD-WAN Route o ruta de Failover

Estos valores se configuran en la conexión IPsec o en las reglas de red asociadas. Por tanto, un estado verde de Phase 1 no demuestra que Phase 2 coincida ni que el tráfico útil se enrute y permita correctamente.

Authentication no es lo mismo que Authentication type

En un perfil IPsec, Authentication designa el algoritmo de integridad, como SHA2 256. En la conexión IPsec, Authentication type determina si las contrapartes se identifican mediante Preshared Key, certificado o RSA Key.

Estos dos campos realizan tareas diferentes. Por tanto, un SHA2 256 correcto no corrige un PSK incorrecto y un certificado válido no compensa una Proposal de Phase 1 incompatible.

Phase 1 y Phase 2 explicadas

Phase 1 establece la IKE Security Association protegida. A través de este canal de control, las contrapartes se autentican y negocian las demás claves y parámetros. Como mínimo, deben ser compatibles la versión IKE, el cifrado, la integridad y el DH Group.

Phase 2 crea las Child o IPsec Security Associations para el tráfico útil. Aquí se aplican el cifrado de Phase 2, la integridad, PFS y los Traffic Selectors. Por ello, un túnel puede completar Phase 1 correctamente y, sin embargo, no crear ninguna Child SA debido a un valor PFS incorrecto o a una combinación de Phase 2 diferente.

Con IKEv2, la primera Child SA puede establecerse junto con la IKE SA. Según la contraparte, un problema de PFS o de renovación puede no aparecer hasta que la Child SA se renueve mediante CREATE_CHILD_SA. Avanet recomienda observar al menos una renovación de Phase 2 durante las pruebas de aceptación.

Coordinar los parámetros con la contraparte

Antes de configurar, ambos administradores acuerdan y documentan los valores por escrito. Una captura de pantalla suele ser insuficiente porque los fabricantes utilizan nombres diferentes para una misma función.

Como mínimo, deben documentarse estos datos:

• función: Initiator, Responder o establecimiento desde ambos lados
• versión IKE y, con IKEv1, Main o Aggressive Mode
• Phase 1 Encryption, Authentication y DH Group
• Phase 1 Key Life, Re-key Margin y aleatorización
• Phase 2 Encryption, Authentication, PFS y Key Life
• Rekeying basado en tiempo y qué lado lo inicia
• intervalo DPD y acción cuando la contraparte no está disponible
• límites conocidos del proveedor y Proposals permitidas

El nombre del perfil no tiene que ser idéntico en ambos dispositivos; lo importante es que al menos una combinación completa sea compatible en ambos lados. Las propuestas innecesarias dificultan la coordinación y pueden aumentar sin necesidad el tamaño de los paquetes IKE. El efecto concreto del problema conocido NC-136352 en SFOS se explica más adelante, junto a los campos de Phase 1.

Elegir una configuración inicial segura

Los siguientes ejemplos son puntos de partida de Avanet para nuevas conexiones Site-to-Site. No sustituyen los requisitos de Azure, AWS, un operador o un firewall de terceros. Muestran deliberadamente solo la selección de propuestas y funciones, no un perfil completo: las duraciones, Re-key Margin, el intervalo DPD y su acción dependen de la contraparte y del papel de Initiator o Responder.

Perfil moderno para contrapartes controladas

Si ambos lados admiten algoritmos actuales:

Key exchange: IKEv2
Phase 1: AES256GCM16, 19 (ecp256)
Phase 2: AES256GCM16, 19 (ecp256)
Re-key connection: On
Use strict profile: On
Compression: Off
SHA2 96-bit truncation: Off
Dead peer detection: On

AES256GCM16 es un algoritmo AEAD: cifra y protege la integridad en una sola operación. Para esta combinación, SFOS no selecciona ningún algoritmo Authentication adicional como SHA2.

La Pseudo-Random Function para generar claves IKE no puede seleccionarse por separado en SFOS. El firewall la deriva de los algoritmos de integridad ofrecidos y la coordina con la contraparte.

El grupo 19 (ecp256) utiliza una curva elíptica. Para contrapartes actuales y controladas, Avanet lo prefiere a los grupos MODP más antiguos. AES128GCM16 también es un algoritmo vigente. La política criptográfica aplicable y el componente más débil del perfil determinan qué combinación es válida.

Perfil compatible sin AES-GCM o ECP

Si la contraparte no admite AES-GCM o no admite un grupo ECP, Avanet utiliza esta combinación más extendida como punto de partida compatible:

Key exchange: IKEv2
Phase 1: AES256, SHA2 256, DH14
Phase 2: AES256, SHA2 256, PFS14
Re-key connection: On
Dead peer detection: On

A diferencia de las entradas AES-GCM, en SFOS AES256 se configura con el algoritmo Authentication independiente SHA2 256. DH14 y PFS14 son opciones de compatibilidad de Avanet, no la variante moderna preferida cuando ambas contrapartes admiten el grupo 19 (ecp256).

Evitar en perfiles nuevos

DES no figura entre los algoritmos IPsec compatibles con SFOS 22. IKEv1, Aggressive Mode, 3DES, Blowfish, MD5, SHA1 y los grupos DH 1, 2 y 5 siguen siendo seleccionables, pero no deben usarse en perfiles nuevos. PFS: None también debe quedar reservado como excepción documentada para contrapartes que no admitan PFS.

A pesar de aparecer en el campo Phase 2 Encryption, AES-GMAC no cifra, sino que solo proporciona autenticación e integridad. Por tanto, un túnel Site-to-Site confidencial normal utiliza AES-GCM o AES con un algoritmo SHA2 adecuado.

Las excepciones Legacy se documentan con su motivo, la contraparte afectada, el riesgo, el Owner y la fecha de sustitución. Una combinación débil no debe permanecer junto a Proposals robustas únicamente porque el túnel también puede establecerse con ella. La BSI TR-02102-3 sobre IPsec e IKEv2 y la guía de NIST sobre VPN IPsec ofrecen orientación técnica.

Si un entorno debe cumplir requisitos criptográficos formales, el procedimiento específico explica cómo el modo FIPS 140-3 en Sophos Firewall afecta a plataformas, perfiles, certificados, backups y HA. El cumplimiento FIPS no sustituye la selección consciente de una proposal común y moderna.

Clonar o crear un perfil

Ruta de menú:

Profiles > IPsec profiles

Para conexiones Sophos con Sophos, los perfiles de sistema emparejados sirven como plantillas comprensibles:

• Branch office (IKEv2) para la sucursal que inicia la conexión
• Head office (IKEv2) para la central que responde

Se clona el perfil adecuado y se le asigna un nombre claro, por ejemplo Branch-Zurich-IKEv2. De este modo, el perfil de sistema permanece sin cambios y durante un Rollback puede volver a asignarse al túnel su perfil anterior.

General settings

• Key exchange: utilizar IKEv2 para nuevas conexiones Site-to-Site. Utilizar IKEv1 solo para una contraparte Legacy documentada.
• Authentication mode: solo existe para IKEv1. No utilizar Aggressive Mode porque, según Sophos, la información de autenticación se transmite en texto claro.
• Key negotiation tries: Sophos recomienda 0. Sin embargo, en un VPN Failover Group, SFOS establece el valor efectivo en 3.
• Re-key connection: activar para negociar nuevas claves de Phase 1 y Phase 2 antes de que caduquen. SFOS solo admite Rekeying basado en tiempo.
• Use strict profile: activar cuando se conocen exactamente las Proposals de la contraparte. De este modo, SFOS solo ofrece los parámetros configurados. En perfiles de proveedores, comprobar primero sus requisitos; por ejemplo, el ejemplo oficial de AWS no utiliza esta opción.
• Pass data in compressed format: Avanet suele dejar esta opción desactivada. Solo debe activarse si la contraparte admite IPComp y el ahorro de ancho de banda compensa la complejidad añadida.
• SHA2 with 96-bit truncation: activar solo por un requisito de compatibilidad documentado, no como mejora general de seguridad.

Use strict profile excluye del intercambio IKE los valores predeterminados del sistema que no estén configurados y puede ayudar con propuestas IKE demasiado grandes. Sin embargo, no es una opción que deba activarse sin comprobar en todos los perfiles de proveedor.

Phase 1

Phase 1 contiene Key life, Re-key margin, Randomize re-keying margin by, el DH Group y hasta tres pares de Encryption y Authentication.

No debe elegirse sin más el valor máximo que acepte el campo. Re-key Margin debe ser considerablemente menor que Key Life y ajustarse al comportamiento de la contraparte; la aleatorización solo modifica este margen.

Solo se introducen los DH Groups y Proposals que sean realmente necesarios. El problema conocido NC-136352 puede producirse cuando un perfil IKEv2 predeterminado ofrece tantos DH Groups que el paquete IKE supera los 1500 bytes. Si un componente intermedio descarta los fragmentos, el Initiator transmite repetidamente mientras el Responder no ve nada. Para una contraparte conocida, un único DH Group confirmado es la configuración más limpia.

Phase 2

Phase 2 contiene PFS, Key Life, Encryption y Authentication para el tráfico útil.

PFS fuerza un nuevo intercambio de claves DH durante el Rekeying de Phase 2. Si posteriormente se compromete una clave de larga duración, se pretende evitar que sesiones antiguas grabadas puedan descifrarse con el mismo material de claves. Por ello, se activa PFS y se selecciona un valor compatible con la contraparte. En perfiles modernos, el PFS Group suele coincidir con el DH Group de Phase 1.

Sophos recomienda elegir una Key Life de Phase 2 más corta que la Key Life de Phase 1. De este modo, las claves del tráfico útil se renuevan con mayor frecuencia que el canal de control IKE.

Dead Peer Detection

DPD detecta una contraparte que deja de responder. No sustituye ni a Gateway Monitoring ni a una prueba real de aplicaciones.

• Sucursal o Initiator: Re-initiate, para que el firewall intente inmediatamente un nuevo establecimiento tras un DPD Timeout.
• Central o Responder: Disconnect, para cerrar la conexión obsoleta. Hold es una alternativa deliberada cuando deben mantenerse los Traffic Selectors y la renegociación solo debe comenzar al llegar tráfico nuevo.
• Check peer after every: intervalo de comprobación en segundos.
• Wait for response up to: solo actúa con IKEv1. Con IKEv2, SFOS utiliza el IKE Retransmission Timeout interno; el valor introducido no modifica este comportamiento.

En los IPsec Failover Groups, SFOS desactiva DPD para las conexiones asignadas y establece Key negotiation tries en 3. La condición del grupo se encarga entonces de la supervisión. La guía enlazada explica el orden, la Failover Condition y Automatic failback; la vista del Profile por sí sola no muestra todo el comportamiento de Failover efectivo.

Interpretar correctamente Lifetimes y Rekeying

Key life no es un Session Timeout ni un Idle Timeout. Limita la duración de una Security Association. Antes de que caduque, la negociación de nuevas claves comienza dentro del Re-key Margin.

Las Lifetimes más cortas renuevan las claves con mayor frecuencia, pero provocan más carga de cálculo y más oportunidades para errores de interoperabilidad o Rekeying. Las Lifetimes más largas reducen esta carga, pero utilizan el material de claves durante más tiempo. Por tanto, ni el valor más corto ni el más largo permitido es automáticamente la mejor elección.

NIST SP 800-77r1 recomienda 24 horas para la IKE SA y 8 horas para la IPsec SA. Son recomendaciones de NIST independientes del fabricante, no valores predeterminados de SFOS. Sophos y los proveedores de nube utilizan otros valores según la función y la plataforma.

Sophos recomienda lo siguiente para evitar colisiones de Rekeying:

1. La Key Life del Initiator es más corta que la del Responder.
2. La Key Life de Phase 2 en ambos firewalls es más corta que la Key Life de Phase 1.
3. Rekeying está activado en al menos uno de los lados y utiliza expresamente Rekeying basado en tiempo con dispositivos de terceros.

La aleatorización modifica el Re-key Margin, no la Key Life completa. Con una Key Life de ocho horas, un Margin de diez minutos y una aleatorización del 20 por ciento, Sophos indica que el Rekeying comienza entre las 7 horas y 48 minutos y las 7 horas y 52 minutos.

Para proveedores, se utilizan sus valores exactos. En Sophos Firewall, el ejemplo documentado de AWS utiliza una Key Life de Phase 1 de 28000, un Re-key Margin de 360 y una aleatorización del 50 por ciento; Phase 2 utiliza 3600 segundos. Este es un ejemplo de AWS, no un valor predeterminado general de Avanet.

Asignar y probar el perfil de forma segura

Durante una ventana de mantenimiento, el nuevo perfil se asigna primero únicamente a la conexión prevista. Antes del cambio se documentan el nombre del perfil, los valores anteriores y el Rollback.

Para Site-to-Site, la asignación se realiza en:

Site-to-site VPN > IPsec

Remote Access IPsec también utiliza perfiles, pero tiene otros límites: la configuración actual de Sophos Connect acepta perfiles IKEv1 con DPD desactivado o configurado como Disconnect. Por ello, el moderno perfil IKEv2 para Site-to-Site no se reutiliza sin comprobarlo en Remote Access. El procedimiento completo se describe en Configurar Sophos Connect en Sophos Firewall. El caso específico de OTP y Rekeying se explica en Sophos Connect desconecta la conexión después de unas cuatro horas.

Una vez establecida la conexión, Avanet utiliza en Advanced Shell únicamente los siguientes comandos de consulta para comprobar el estado y los últimos mensajes IKE:

ipsec statusall
tail -n 200 /log/strongswan.log

A continuación se prueba tráfico real en ambos sentidos. Los contadores de bytes de la Child SA deben aumentar. La prueba se repite después de al menos una renovación de Phase 2. Solo este paso adicional de aceptación de Avanet comprueba también las duraciones, PFS y el comportamiento de renovación.

Causas típicas según el síntoma:

• El túnel no llega a establecerse: comprobar la versión IKE, Phase 1 Encryption, Authentication, DH, Strict Profile, ID y la autenticación de la contraparte.
• NO_PROPOSAL_CHOSEN antes de Phase 1: comparar las Proposals de Phase 1.
• Phase 1 está activa, pero falta la Child SA: comprobar Phase 2 Encryption, Authentication, PFS y Traffic Selectors.
• Desconexión tras un intervalo similar: comparar Key Life, Re-key Margin, aleatorización y valores de Initiator y Responder.
• El túnel está verde, pero no pasa tráfico: no modificar primero el perfil; comprobar las reglas de firewall, NAT, Routing, la ruta de retorno y los contadores de bytes.

Si el cambio causa problemas, se vuelve a asignar a la conexión el perfil anterior documentado. Para esta reversión no es necesario realizar cambios en Advanced Shell.