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 DH Group, PFS, las Lifetimes, el Rekeying y Dead Peer Detection. Si estos valores no coinciden con los de la contraparte, el túnel permanece down o falla más tarde durante el Rekeying.

Recomendación rápida para nuevas conexiones Site-to-Site: utilizar IKEv2, ofrecer solo las Proposals robustas que sean realmente necesarias, activar PFS y Rekeying y configurar DPD según la función del firewall. Si ambas contrapartes admiten los valores, AES256GCM16 con DH19 y PFS19 constituye un punto de partida moderno. No obstante, los requisitos del proveedor y de la contraparte siempre tienen prioridad.

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 contiene los parámetros de seguridad comunes para Phase 1 y Phase 2. Un mismo perfil puede asignarse a varias conexiones. Precisamente por ello, no debe modificarse espontáneamente un perfil de sistema o producción que esté en uso: el cambio puede afectar a todos los túneles asociados durante el siguiente establecimiento o Rekeying.

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. En consecuencia, un problema de PFS o Rekeying puede no manifestarse hasta horas después, cuando sea necesario renovar la Child SA. La validación no está completa hasta haber observado al menos un Rekeying sin interrupció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. Más Proposals no son automáticamente mejores: amplían la superficie de ataque y error y pueden aumentar tanto el tamaño de los paquetes IKE que la fragmentación se convierta en un problema.

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.

Perfil moderno para contrapartes controladas

Si ambos lados admiten algoritmos actuales:

Key exchange: IKEv2
Phase 1: AES256GCM16, DH19
Phase 2: AES256GCM16, PFS19
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 no se selecciona ningún algoritmo Authentication adicional como SHA2. GCM16 designa el Authentication Tag de 16 bytes, no un cifrado de 16 bits.

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.

DH19 utiliza una curva elíptica y ofrece un buen equilibrio entre nivel de seguridad, tamaño de paquete y carga de cálculo. AES128GCM16 también es un algoritmo actual y no es automáticamente inseguro para un nivel de seguridad normal de 128 bits. La resistencia total siempre depende del componente más débil del perfil.

Perfil compatible para contrapartes actuales de terceros

Si la contraparte no admite AES-GCM ni un ECP Group, esta combinación es un punto de partida con mayor compatibilidad:

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

Aquí AES trabaja en modo CBC y, por tanto, requiere la protección de integridad independiente SHA2 256. DH14 y PFS14 son opciones de compatibilidad, no la variante moderna preferida cuando ambas contrapartes admiten DH19.

Evitar en perfiles nuevos

En diseños nuevos deben evitarse IKEv1, Aggressive Mode, DES, 3DES, Blowfish, MD5, SHA1 y los DH Groups 1, 2 y 5. 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 la información de autenticación se transmite con menos protección.
• 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: mantener desactivado en condiciones normales. Activar solo cuando se hayan confirmado su utilidad y la compatibilidad en ambos lados.
• SHA2 with 96-bit truncation: activar solo por un requisito de compatibilidad documentado, no como mejora general de seguridad.

Use strict profile reduce los Fallbacks inesperados y puede ayudar si las Proposals IKE demasiado grandes causan problemas. 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.

SFOS admite de 120 a 86400 segundos para Key Life, de 30 a 999 segundos para Re-key Margin y de 0 a 100 por ciento para la aleatorización. Un valor formalmente permitido no es automáticamente adecuado: el Margin debe ser considerablemente inferior a la Key Life y coincidir con el comportamiento de la contraparte.

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 1'500 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.

La Key Life de Phase 2 se elige 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 cita 86400 segundos para la IKE SA y 28800 segundos para la IPsec SA como orientación habitual. Sophos y los proveedores Cloud utilizan valores diferentes según la función y la plataforma. Por tanto, estas cifras no representan un perfil SFOS universal.

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. El ejemplo documentado de AWS utiliza aproximadamente 28000 para Phase 1, un Re-key Margin de 360, una aleatorización de 50 y 3600 segundos para Phase 2 en Sophos Firewall. 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.

Después de establecer la conexión, el estado y los últimos mensajes IKE se comprueban en modo de solo lectura en Advanced Shell:

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 un Rekeying de Phase 2; solo entonces se habrán validado realmente Lifetimes, PFS y el comportamiento de Rekeying.

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

• El túnel permanece completamente down: 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 un Rollback normal del perfil no es necesario modificar servicios, bases de datos ni configuraciones de Advanced Shell.