Introducción a los conceptos de IKEv1 para VPNs en un firewall de Huawei

Hola . A continuación encontraran la descripción de IKEv1 ampliamente utilizado para la creación de tuneles VPN en IPsec.

Pasemos a la información.

1.       Configurando VPNs IKE / IPSec

Los IKE son mejores para establecer VPN IPSec entre un solo host y varios sub-hosts. Sus ventajas se hacen cada vez más prominentes a medida que crece el número de subhosts. Para mayor comodidad, aquí solo daremos una instantánea de cómo se establece la red VPN IPSec entre un FW de host y un FW de sub-host, como se muestra en la Imagen 1-1.

Imagen 1-1 Red IKEv1 / IPSec VPN

Como se muestra en la Imagen 1-2, en comparación con las configuraciones manuales, el procedimiento utilizado para las VPN IKE/IPSec solo agrega dos pasos adicionales: la configuración de la propuesta de IKE y el par de IKE. La propuesta de IKE se utiliza principalmente para configurar los algoritmos de cifrado y autenticación utilizados para establecer la IKE SA. El interlocutor IKE se utiliza principalmente para configurar la versión de IKE, la autenticación de identidad y el modo de intercambio.

Imagen 1-2 Esquema de la configuración IKEv1/IPSec

Al igual que en las VPN IPSec manuales, la comunicación a través de toda la red primero debe ser libre. Específicamente, primero se deben cumplir las dos condiciones siguientes:

·         Los FW_A y FW_B son enrutables a través de una red pública.

·         Las políticas de seguridad de FW_A y FW_B permiten el tráfico entre PC_A y PC_B.

En cuanto a la configuración de las políticas de seguridad VPN IPSec, consulte las siguientes secciones. Por ahora, primero deberíamos centrarnos en esta sección: configuración VPN IPSec IKE.

Consulte la Tabla 1-1 para conocer los pasos para configurar una VPN IKE / IPSec.

Tabla 1-1 Configuración de IKE / IPSec VPNsd

Una vez configurado, cuando los FW de host y subhost acceden a un flujo de datos, puede activar el establecimiento de un túnel VPN IPSec. Luego, el Dr. WoW utilizará paquetes de captura para ayudarnos a todos a comprender la esencia de IKEv1.

IKEv1 se puede dividir en dos fases para completar el establecimiento dinámico de una SA de IPSec:

·         Fase 1 establecer IKE SA: el modo principal o modo agresivo se utiliza para establecer la negociación IKE SA.

·        Fa se 2 establecer IPSec SA: el modo rápido se utiliza para establecer la negociación de IPSec SA.

¿Por qué dividiríamos esto en dos fases? ¿Cómo se relacionan estas dos fases? En pocas palabras, la fase 1 se utiliza para preparar la fase 2. Ambos pares de IKE intercambiarán materiales clave, generarán claves y realizarán la autenticación de identidad mutua. Solo después de que se completen estos preparativos, IPSec comenzará realmente la negociación de IPSec SA.

A continuación, presentaremos el proceso de modo principal + modo rápido utilizado para establecer una SA de IPSec. Primero, analizaremos las diferencias entre las VPN IKE / IPSec y las VPN IPSec manuales.

2 Fase 1: Establecimiento de IKE SA (Modo principal)

Se toman tres pasos para establecer una IKE SA con seis mensajes ISAKMP a través del modo principal IKEv1. La captura de pantalla de paquetes de mensajes es la siguiente:

A continuación, usaremos una negociación IKE iniciada por FW del host para ilustrar el proceso de negociación de la fase 1, como se muestra en la Imagen 1-3.

Imagen 1-3 Proceso de negociación del modo principal de IKE SA.

2.       Negociación de la propuesta IKE.

La negociación se divide en dos circunstancias:

·         El par de IKE del iniciador citó una propuesta de IKE (envía la propuesta de IKE citada)

·         El par de IKE del iniciador no citó una propuesta de IKE (envía todas las propuestas de IKE)

En estas dos circunstancias, los encuestados buscarán entre sus propias propuestas IKE configuradas para una propuesta IKE que coincida con la del remitente (Como tal, la línea de propuesta IKE citada en la Imagen 1-2 "Esquema de la configuración IKEv1/IPSec" está discontinua, lo que significa que citados y no citados son aceptables). Si no hay una propuesta de seguridad coincidente, la negociación fallará.

Los principios según los cuales ambos pares de IKE juzgan si las propuestas de IKE coinciden o no incluyen si los fines usan el mismo algoritmo de cifrado, algoritmo de autenticación, método de autenticación de identidad e ID de grupo DH, pero no incluye el ciclo de vida de IKE SA.

Los parámetros de configuración de igual a IKE son claves de encabezado, ID de igual o direcciones IP o nombres de dominio que permiten que IKE finalice la conexión exitosa. También incluyen parámetros de autenticación de identidad. No importa dónde se encuentre el error, "aunque nos sentamos de extremo a extremo, el destino no lo tendría tan".

NOTA:

Cuando se establece una SA de IPSec a través de la negociación IKEv1, el tiempo de espera de IKE SA es el ciclo de vida local o el ciclo de vida del par, el que sea más corto. Si los ciclos de vida configurados en los dos dispositivos en cualquiera de los extremos del túnel difieren, no afectará la negociación IKE.

Al observar un paquete de captura de pantalla, podemos ver la propuesta de IKE utilizada para la negociación que se lleva en la carga útil de SA de los mensajes ISAKMP. El mensaje (1) se utiliza como ejemplo a continuación:

3.       El algoritmo DH se utiliza para intercambiar materiales clave y también generar claves.

Los FW de host y subhost utilizan el intercambio de claves y las cargas útiles de nonce en los mensajes ISAKMP para intercambiar materiales clave. Key Exchange se utiliza para intercambiar valores públicos de DH; Nonce se utiliza para transferir números aleatorios temporales. Los dos pares IKE en el algoritmo DH solo intercambian materiales clave y no intercambian las claves compartidas reales. Como tales, los piratas informáticos que roban valores DH y valores temporales no pueden descubrir claves compartidas. Esta es precisamente la belleza del algoritmo DH. Dentro del paquete de captura de pantalla, podemos ver los materiales clave intercambiados entre los pares de IKE. El mensaje (3) se utiliza como ejemplo a continuación:

Una vez que se intercambian los materiales clave, los dos pares de IKE combinarán sus propios métodos de autenticación de identidad configurados para comenzar cada uno sus respectivos procesos de computación clave complicados (las claves precompartidas o los certificados digitales están involucrados en el proceso de computación clave) y, finalmente, generan 3 claves :

·         SKEYID_a: clave de autenticación de integridad de mensaje ISAKMP: nadie se atrevería a manipular un mensaje ISAKMP. Si el mensaje tiene el menor cambio, se detectará la integridad de su respuesta.

·         SKEYID_e: clave de cifrado de mensaje ISAKMP: ni siquiera intente robar un mensaje ISAKMP. Incluso si lo haces, no lo entenderás!

·         SKEYID_d: se utiliza para el cifrado y las claves de autenticación derivadas de paquetes IPSec. En última instancia, esta clave garantiza la seguridad de los paquetes de datos encapsulados IPSec.

Las dos primeras teclas anteriores garantizan la seguridad de los siguientes intercambios de mensajes ISAKMP

A lo largo de todo el intercambio de claves y el proceso de computación, cuando es controlado por un tiempo de espera de IKE SA, el tiempo se actualizará automáticamente en un cierto intervalo para evitar posibles problemas de seguridad cuando las claves se usan por un largo período de tiempo.

1.       Autenticación de identidad

Los dos interlocutores IKE realizan la autenticación de identidad con el mensaje ISAKMP (5) y (6) intercambian mensaje de identidad. Actualmente, hay dos técnicas de autenticación de identidad que se utilizan comúnmente:

·         Método de clave precompartida (precompartido): el mensaje de identidad del dispositivo es la dirección IP o el nombre.

·         Método de certificado digital: el mensaje de identidad del dispositivo es el certificado y un mensaje parcial de valor HASH (firma) autenticado mediante cifrado de clave privada.

Los mensajes de identidad anteriores están cifrados con el SKEYID_e. Como tal, en los paquetes de captura de pantalla, solo podemos ver los mensajes ISAKMP identificados como "Encriptados" y no podemos ver el contenido del mensaje (mensaje de identidad). El mensaje (5) se utiliza como ejemplo a continuación:

La clave precompartida es el método más simple y común de autenticación de identidad. Con este método, los mensajes de identidad del dispositivo pueden identificarse por la dirección IP o el nombre (incluidos el FQDN y USER-FQDN). Cuando los pares de IKE tienen una dirección IP fija, en general, ambos serán identificados por sus direcciones IP; cuando un par tiene una dirección IP asignada dinámicamente, este par solo será identificado por su nombre. Solo cuando los mensajes de identidad del par autentificado y el par autenticado coincidan, la autenticación de identidad será exitosa. Los puntos clave para la configuración de autenticación de identidad FW de host y sub-host se muestran en la Tabla 1-2.

Tabla 1-2 Configuración de mensaje de autenticación de identidad

Hay un problema aquí que todos deberíamos conocer. Cuando los dos pares de IKE tienen una dirección IP fija, las direcciones de IP configuradas con un comando de dirección remota deben mantener la misma dirección que la utilizada para la negociación de IKE iniciada por pares. El uso de esta dirección IP es triple: no solo designa la dirección IP del interlocutor del túnel, sino que también se usa cuando se buscan claves locales previamente compartidas y para autenticar las identidades de los interlocutores. Este es el mayor escollo de IPSec; en diferentes circunstancias, puede cambiar en muchos momentos diferentes. Si no se puede encontrar la ley adecuada, definitivamente habrá un error.

En resumen, el IKE realizará dos acciones principales en el proceso de negociación de la fase 1:

·         Generará claves de cifrado y autenticación para los sucesivos mensajes de ISAKMP y también generará materiales clave para IPSec SA.

·         Una vez que se completa la autenticación de identidad y, cuando está cifrada, el mensaje de identidad puede ser una dirección IP, el nombre del dispositivo o un certificado digital con más información.

Además, todas estas contribuciones están sujetas al control del ciclo de vida de las SA, y tan pronto como la SA expira, todas las tareas anteriores se repetirán. El beneficio aquí es que, independientemente de los resultados de la computación clave y la autenticación de identidad, todo el proceso se repetirá en un momento determinado, eliminando así las oportunidades de comportamiento malicioso. Nada de esto se incluye para las VPN IPSec manuales, razón por la cual los IKE son administradores de claves "inteligentes".

3 Fase 2: Establecimiento de IPSec SA

A partir de la fase 2, los dos pares de IKE continuarán intercambiando materiales clave, incluidos SKEYID_d, SPI y protocolos (protocolos AH y / o ESP), nonce y otros parámetros similares. Luego, cada par realizará la computación clave y generará las claves para el cifrado y la autenticación de IPSec SA. De esta manera, se garantiza a cada IPSec SA que use una clave absolutamente única para el posterior cifrado y autenticación de las transferencias de datos. Además, IPSec SA también tiene tiempo de espera; tan pronto como se agote el tiempo de espera de IPSec SA, se eliminarán IKE SA e IPSec SA, y la negociación comenzará de nuevo.

IKEv1 utiliza el modo de intercambio rápido para establecer una SA de IPSec a través de tres mensajes ISAKMP. La captura de pantalla de los mensajes de paquetes es la siguiente:

Debido a que el SKEYID_e generado por IKEv1 fase 1 del modo de intercambio rápido encripta los mensajes ISAKMP, todos los paquetes que hemos capturado están todos encriptados y no podemos ver el contenido específico de las cargas útiles. Como tal, solo podemos explicar los siguientes pasos textualmente. Como se muestra en la Imagen 1-4, todavía lo ilustraremos con una negociación IPSec iniciada por FW del host.

Imagen 1-4 Proceso de negociación del modo de intercambio rápido IPSec SA

4.       El iniciador envía la propuesta de IPSec, el flujo de datos protegidos (ACL) y los materiales clave al respondedor.

5.       El respondedor responde con una propuesta de IPSec coincidente y un flujo de datos protegido. Al mismo tiempo, ambas partes generan una clave para IPSec SA.

La IPSec usa ACL para delinear los flujos de datos que quiere proteger. Como en nuestro ejemplo, donde el host solo necesita comunicarse con un solo sub-host, la configuración es relativamente simple y solo una "duplicación mutua" de ACL (las direcciones IP de origen y destino de una ACL son opuestas a la otra) Para ser configurado en cada FW. Sin embargo, para otras situaciones más complejas, por ejemplo, cuando un host establece una VPN con múltiples subhosts a los que los subhosts acceden a través del host, así como L2TP / GRE sobre IPSec, o 2 en 1 IPSec y NAT Las pasarelas, las configuraciones de ACL se hacen más particulares. Volveremos a visitar estos escenarios cuando volvamos a encontrarlos.

El principio según el cual ambos pares de IKE juzgan si las propuestas IPSec coinciden o no es que los algoritmos de autenticación, los algoritmos de cifrado y los modos de encapsulación utilizados por ambos protocolos de seguridad deben ser todos iguales.

Debido a que todas las claves SA de IPSec se derivan de SKEYID_d, tan pronto como se filtre SKEYID_d, puede comprometer la VPN de IPSec. Para elevar la seguridad de la administración de claves, IKE ofrece una función PFS (perfecto secreto hacia delante). Una vez que se active PFS, se realizará un intercambio DH adicional por única vez durante la negociación de IPSec SA, para regenerar las nuevas claves de SA de IPSec, lo que mejorará aún más la seguridad de SA de IPSec. ¡Recuerde que si se debe configurar un PFS, debe configurarse en ambos FW del túnel!

6.       El iniciador envía los resultados de confirmación.

Una vez que se completa la negociación, el remitente comenzará a enviar los paquetes IPSec (ESP).

Una vez que se haya establecido con éxito una SA IPSec, verifique el mensaje de presencia VPN IPSec. Esto se ilustra con el mensaje de visualización del host FW_A.

·         Compruebe el estado de IKE SA:

<FW_A> display ike sa

current ike sa number: 2

------------------------------------------------------------------------

conn-id peer flag phase vpn

------------------------------------------------------------------------

40129 2.2.3.2 RD|ST v1: 2 public

40121 2.2.3.2 RD|ST v1: 1 public

Aquí se muestran los estados IKE SA (v1: 1) e IPSec SA (v1: 2). RD significa que el SA está configurado en LISTO. Solo hay una IKE SA entre los pares de IKE. IKE SA es una conexión lógica de dos vías (sin distinción entre el origen y el destino).

·         Compruebe el estado de IPSec SA

<FW_A> display IPSec sa brief

current IPSec sa number: 2

current IPSec tunnel number: 1

---------------------------------------------------------------------

Src Address Dst Address SPI Protocol Algorithm

---------------------------------------------------------------------

1.1.1.1 2.2.3.2 4090666525 ESP E: DES; A: HMAC-MD5-96;

2.2.3.2 1.1.1.1 2927012373 ESP E: DES; A: HMAC-MD5-96;

IPSec SA es unidireccional (distinción entre origen y destino), y ambas IPSec SA juntas constituyen un solo túnel IPSec. En términos generales, un solo flujo de datos corresponderá a una única IPSec SA. Sin embargo, cuando la IPSec también utiliza la encapsulación ESP + AH, un solo flujo de datos corresponderá a dos SA de IPSec.

·         Compruebe la tabla de sesiones:

<FW_A> display firewall session table

 Current Total Sessions: 3

 icmp VPN: public --> public 192.168.0.2: 18334-->172.16.2.2: 2048

 udp VPN: public --> public 1.1.1.1: 500-->2.2.3.2: 500

 esp VPN: public --> public 2.2.3.2: 0-->1.1.1.1: 0

Ahora hemos establecido la IPSec SA En la superficie, puede parecer que no hay muchas diferencias entre el método IKE y el método manual, pero de hecho, las diferencias son masivas:

·         Diferentes métodos de generación de claves.

Manualmente, todos los parámetros de IPSec SA que deben crearse, incluidas las claves de autenticación y cifrado, se configuran manualmente y solo se pueden actualizar manualmente.

Con el método IKE, todas las claves de autenticación y cifrado IPSec SA que deben crearse son generadas por el algoritmo DH y se pueden actualizar dinámicamente. Los costos clave de administración son más bajos y la seguridad es más alta.

·         Diferentes ciclos de vida de IPSec SA

Las SA de IPSec creadas manualmente tendrán una presencia permanente.

Con el método IKE, las SA de IPSec se activan mediante el flujo de datos, y los controles del parámetro del ciclo de vida de SA (también conocido como tiempo de espera de SA) se configuran en ambos extremos.

El modo principal es el método recomendado de configuración para una seguridad confiable. A continuación, veremos brevemente otro tipo de método de negociación de IKE SA: el modo agresivo.

4 Fase 1: Establecimiento de IKE SA (Modo agresivo)

IKEv1 completa la negociación dinámica IPSec en dos fases; Cuando la fase 1 utiliza la negociación del modo principal, ofrece una seguridad confiable, pero a veces, el modo principal perfecto aún será inútil. ¿Porqué es eso? Echemos un vistazo a lo que sucede cuando reemplazamos el modo principal con el modo agresivo.

En la Tabla 1-1 "Configuración de VPN IKE / IPSec", si cambiamos el modo de intercambio principal del comando de configuración de igual IKE al modo de intercambio agresivo, el modo de negociación de la fase 1 de IKEv1 cambiará al modo agresivo. Echemos un vistazo a los paquetes de captura para ver cómo interactúan los paquetes de modo agresivo:

muestra en la Imagen 1-5, el modo agresivo solo necesita tres mensajes ISAKMP para completar el proceso de negociación de la fase 1. La fase 2 sigue siendo el mismo modo rápido que antes.

Imagen 1-5 Proceso de negociación del modo agresivo de IKE SA

El iniciador y el respondedor colocan de forma perentoria todos sus mensajes, incluida la propuesta IKE, los mensajes clave relevantes y los mensajes de identidad, en un solo mensaje ISAKMP y lo envían al otro extremo, lo que mejora la eficiencia de negociación IKE. Sin embargo, dado que el mensaje de identidad se transfiere como texto sin formato, no pasa por el proceso de autenticación de encriptación e integridad, lo que reduce la seguridad de IKE SA. Claramente, la seguridad aquí cae en corto. Entonces, ¿por qué tenemos modo agresivo?

En los primeros días de las VPN IPSec, cuando las personas usaban el método de autenticación de identidad de clave principal en modo principal + compartido, el IPSec necesitaba buscar la clave compartida previamente localmente en la dirección IP del par. Este tipo de método de búsqueda clave solo funciona cuando el par tiene una dirección IP fija. Si no hay una dirección fija, se puede usar el modo agresivo para resolver "brutalmente" este problema.

En el modo agresivo, los "mensajes de identidad" no están cifrados, y localmente, el mensaje de identidad es exactamente el mismo que el que se envió desde el par (es decir, la dirección IP). Esto es todo lo que se necesita para buscar la clave precompartida. Como tal, en las etapas iniciales de las aplicaciones VPN IPSec, el modo agresivo se usó principalmente para implementar VPN IPSec en nodos que no tenían direcciones IP fijas. Hoy en día, IPSec VPN tiene muchas otras formas de resolver este problema y el modo agresivo inseguro claramente no es la mejor opción. Todo lo que realmente necesitamos hacer ahora es entender cómo solía usarse; Sin embargo, el Dr. WoW no recomienda ningún uso real de la misma.