IKE Intercambio de Claves por Internet

IKE – Internet Key Exchange

1️⃣ EXPLICACIÓN EN PROFUNDIDAD

🌀 ALEGORÍA PARA COMPRENDERLO

Imagina que dos espías (representando a dos sistemas que quieren comunicarse) están en extremos opuestos del mundo. No pueden simplemente hablar en voz alta por teléfono, porque alguien podría escuchar. Así que necesitan establecer un código secreto que nadie más conozca.

Pero aquí está el problema: si hablan del código por teléfono, ¡ya no es secreto! Entonces uno de ellos sugiere: "Hagamos algo más inteligente: tú elige un número secreto, yo elegiré otro, y los mezclaremos con una fórmula especial (el algoritmo Diffie-Hellman). Así, aunque alguien escuche lo que intercambiamos, no podrá calcular el código secreto completo".

Y así nace un canal seguro entre ambos espías, a través del cual se enviarán instrucciones cifradas. Pero antes de confiar, se aseguran de que ambos sean quienes dicen ser, mostrando su insignia de espía (certificado digital) o una contraseña secreta que ambos conocen (clave precompartida).

Ese acuerdo entre ambos espías sobre el idioma cifrado, los símbolos y los protocolos que usarán se llama asociación de seguridad (SA).

🧠 EXPLICACIÓN TÉCNICA

IKE (Internet Key Exchange) es el protocolo que establece y gestiona las asociaciones de seguridad (Security Associations - SA) utilizadas por IPsec. Funciona como un negociador que:

• Autentica a ambas partes (hosts, routers, firewalls).

• Establece un canal seguro para intercambiar claves.

• Define los algoritmos criptográficos que se usarán (cifrado, hashing).

• Crea y mantiene las SA para IPsec.

📌 Fases de IKE:

• Fase 1:

  • Autenticación de identidad.

  • Establecimiento de un canal seguro (ISAKMP SA).

  • Uso de Diffie-Hellman para intercambio seguro de claves.

  • Métodos de autenticación:

    • Certificados digitales (con CA).

    • PSK (clave precompartida o "shared secret").

• Fase 2:

  • Uso del canal seguro para negociar los parámetros de IPsec (ESP/AH).

  • Establecimiento de una nueva SA específica para IPsec.

🆚 IKEv1 vs IKEv2:

Característica IKEv1 IKEv2
Complejidad Alta (más fases, más pasos) Menor (simplificado)
NAT Traversal Limitado o manual Integrado
EAP (RADIUS, etc.) No compatible directamente Compatible con autenticación EAP
Multihoming y movilidad No Soporta MOBIKE

IKEv2 es la versión moderna, más segura, más eficiente y la preferida para VPN de acceso remoto en la actualidad.

💡 EJEMPLOS PRÁCTICOS

Vamos a ver cómo se aplica IKE en la vida real, tanto en redes empresariales como en soluciones cotidianas para acceso remoto:

🔐 Escenario 1: Acceso remoto a la red de la empresa usando IKEv2 y certificados digitales

Contexto:
Eres Arquitecta de Seguridad en una empresa con personal remoto. Has configurado un servidor VPN en un firewall OPNsense usando IKEv2. Para evitar robo de credenciales o ataques MITM, decides implementar autenticación por certificados.

Funcionamiento:

1. El usuario remoto instala un certificado emitido por la CA interna de la empresa en su cliente VPN (ej: Windows o StrongSwan).

2. El servidor OPNsense también posee un certificado digital válido firmado por la misma CA.

3. Al conectarse, ambos se reconocen por los certificados → autenticación mutua.

4. Usan Diffie-Hellman para acordar una clave secreta y crear el canal cifrado.

5. Una vez establecida la IKE SA, se negocia una IPsec SA (por ejemplo, usando AES-256 + SHA-2).

6. Todo el tráfico entre el cliente y la red interna viaja cifrado a través del túnel IPsec.

🔍 Resultado:

• Seguridad robusta.

• Cero intervención del usuario.

• Protección frente a sniffing y MITM.

🛠️ Escenario 2: VPN sitio a sitio entre dos sedes con clave precompartida

Contexto:
Tu empresa tiene oficinas en Madrid y Bruselas. No quieres configurar certificados aún, así que utilizas PSK (Pre-Shared Key).

Funcionamiento:

1. Configuras en ambos firewalls (ej: pfSense y OPNsense) la misma clave secreta.

2. Definen políticas IPsec idénticas (algoritmos, redes locales/remotas, puertos).

3. Cuando el tráfico entre sitios se activa, los routers:

   • Realizan el intercambio de claves con IKE.

   • Verifican identidad usando la PSK.

   • Establecen la SA y activan el túnel IPsec (modo túnel).

4. Todo el tráfico entre Madrid y Bruselas queda encapsulado y cifrado.

🔍 Resultado:

• VPN estable para interconexión de redes completas.

• Acceso a recursos internos como si estuvieran en la misma LAN.

📱 Escenario 3: Trabajador remoto en smartphone con IKEv2 + EAP

Contexto:
Una trabajadora se conecta desde su smartphone. Configuras IKEv2 + EAP para que pueda autenticarse con usuario/contraseña en el RADIUS de la empresa.

Funcionamiento:

1. La VPN del smartphone (iOS o Android) usa IKEv2.

2. El servidor usa EAP para autenticación → consulta al servidor RADIUS.

3. Se establece la SA de IPsec automáticamente.

🔍 Resultado:

• No requiere certificado.

• Uso cómodo para usuarios móviles.

🧠 EJERCICIOS DE ENTRENAMIENTO PURPLE TEAM

🧩 Tema: Intercambio de claves de Internet (IKE + IPsec)
🎯 Objetivo: Comprender cómo se negocia la seguridad entre pares, detectar vectores de ataque y reforzar la defensa desde una visión unificada Red + Blue.

🔴 RED TEAM (Ataque)

1. ¿Qué vectores puedo aprovechar si la autenticación se hace con PSK débil?

• Investigo si el túnel VPN usa una clave precompartida.

• Capturo el tráfico inicial de IKE (fase 1) si está expuesto.

• Utilizo herramientas como ike-scan o strongswan para identificar configuraciones débiles.

• Si logro capturar el hash de la PSK, intento romperlo con fuerza bruta o diccionario (ej: hashcat).

• Si se logra, obtengo la clave → puedo emular un cliente legítimo → acceso remoto total.

🛡️ Resultado: Identifico que el uso de una PSK débil en entornos sin MFA ni certificados puede ser catastrófico.

2. ¿Cómo puedo realizar un MITM durante el intercambio IKE si no hay validación estricta de certificados?

• Me posiciono como proxy entre cliente y servidor (ARP spoofing o rogue AP).

• Si el cliente no valida correctamente el certificado del servidor, puedo presentar uno falso.

• Obtengo las credenciales del usuario, las paso al servidor legítimo (proxying).

• Capturo datos confidenciales, extraigo hashes, o mantengo persistencia.

🛡️ Resultado: Detecto que la falta de validación de certificados abre la puerta al phishing y MITM, incluso en conexiones cifradas.

3. ¿Qué puedo hacer si los clientes VPN permiten downgrade de IKEv2 a IKEv1 o TLS inseguro?

• Lanzo ataques de downgrade forzando al cliente a usar un protocolo más débil (ej: IKEv1 sin PFS).

• Exploto algoritmos débiles o configuraciones obsoletas (DES, MD5, etc).

• Utilizo herramientas como ikeforce, metasploit, o escaneo pasivo para identificar estos patrones.

🛡️ Resultado: Aprendo que la compatibilidad con versiones antiguas puede abrir vulnerabilidades críticas, y deben eliminarse.

🔵 BLUE TEAM (Defensa)

1. ¿Cómo fortalezco la autenticación en IKE para impedir ataques por PSK?

• Uso certificados digitales emitidos por una CA interna, configurados tanto en cliente como en servidor.

• Activo autenticación mutua (mTLS).

• Deshabilito PSK como opción.

• Configuro logs de validación y alertas por intentos fallidos.

🛡️ Resultado: Refuerzo la autenticación evitando PSK, usando métodos fuertes y trazables.

2. ¿Cómo detecto y bloqueo escaneos de IKE o fuerza bruta?

• Monitorizo tráfico en los puertos UDP 500 y 4500 (IKE/IPsec).

• Utilizo un IPS que detecte patrones de ike-scan, nmap, ikeforce.

• Configuro el firewall para limitar conexiones por IP.

• Uso reglas como las de Suricata o Snort para alertas específicas de tráfico IKE anómalo.

🛡️ Resultado: Detecto actividad sospechosa y respondo en tiempo real, reduciendo la ventana de ataque.

3. ¿Cómo protejo la negociación de IKE contra MITM?

• Obligo a que todos los certificados estén firmados por una CA confiable.

• Desactivo cualquier opción de conexión con certificados no válidos o sin autenticación.

• Utilizo TLS 1.3 en lugar de versiones anteriores.

• Desactivo protocolos obsoletos como IKEv1 o PPTP.

🛡️ Resultado: Mitigo ataques MITM asegurando que los canales IKE sean firmemente autenticados y cifrados.

🟣 INTEGRACIÓN PURPLE TEAM

🔄 ¿Qué se ha logrado?

• Como Red Team, simulo ataques reales contra túneles IPsec mal configurados, demostrando el impacto de errores comunes.

• Como Blue Team, establezco prácticas sólidas como uso de certificados, bloqueo de escaneos y configuración de alertas inteligentes.

• Como Arquitecta de Seguridad Purple Team, valido continuamente la resistencia del sistema frente a intentos reales de explotación.