EN ESTA PÁGINA
Intercambio de claves por Internet (IKE) para VPN IPsec
Intercambio de claves por Internet versión 2 (IKEv2) es un protocolo de tunelización basado en IPsec que proporciona un canal de comunicación VPN seguro entre dispositivos VPN pares y define la negociación y autenticación para las asociaciones de seguridad (SA) IPsec de manera protegida.
Procesamiento de paquetes IKE e IPsec
IKE proporciona administración de túnel para IPsec y autentica a las entidades finales. IKE realiza un intercambio de claves Diffie-Hellman (DH) para generar un túnel IPsec entre los dispositivos de red. Los túneles IPsec generados por IKE se utilizan para cifrar, descifrar y autenticar el tráfico de usuario entre los dispositivos de red en la capa IP.
Procesamiento de paquetes de IKE
Cuando un paquete de texto sin cifrar llega a un dispositivo de Juniper Networks que requiere tunelización y no existe ninguna SA de fase 2 activa para ese túnel, Junos OS comienza las negociaciones de IKE y descarta el paquete. Las direcciones de origen y de destino en el encabezado del paquete IP son las de las puertas de enlace IKE local y remota, respectivamente. En la carga del paquete IP, hay un segmento UDP que encapsula un paquete ISAKMP (IKE). El formato para los paquetes IKE es el mismo para la fase 1 y la fase 2. Consulte Figura 1.
Mientras tanto, el host de origen volvió a enviar el paquete interrumpido. Normalmente, para cuando llega el segundo paquete, las negociaciones de IKE se completan y Junos OS protege el paquete y todos los paquetes subsiguientes en la sesión, con IPsec antes de reenviarlo.
El campo Carga siguiente contiene un número que indica uno de los siguientes tipos de carga:
-
0002: Carga de negociación de SA contiene una definición para una SA de fase 1 o fase 2.
-
0004: la carga útil de la propuesta puede ser una propuesta de fase 1 o fase 2.
-
0008: la carga de transformación se encapsula en una carga de propuesta que se encapsula en una carga de SA.
-
0010: la carga de intercambio de claves (KE) contiene información necesaria para realizar un intercambio de claves, como un valor DH público.
-
0020—Carga de identificación (IDx).
-
En la fase 1, IDii indica el ID del iniciador e IDir indica el ID del respondedor.
-
En la fase 2, IDui indica el usuario iniciador e IDur indica el usuario que responde.
Los ID son tipos de ID de IKE, como FQDN, U-FQDN, dirección IP y ASN.1_DN.
-
-
0040: Carga de certificado (CERT).
-
0080—Carga de solicitud de certificado (CERT_REQ).
-
0100—La carga de hash (HASH) contiene el resultado de síntesis de una función hash determinada.
-
0200—La carga útil de firma (SIG) contiene una firma digital.
-
0400—La carga útil de Nonce (Nx) contiene información pseudoaleatoria necesaria para el intercambio).
-
0800—Carga de notificación.
-
1000: Carga de eliminación ISAKMP.
-
2000—La carga útil de ID de proveedor (VID) se puede incluir en cualquier lugar en las negociaciones de la fase 1. Junos OS lo utiliza para marcar la compatibilidad con NAT-T.
Cada carga ISAKMP comienza con el mismo encabezado genérico, tal como se muestra en la Figura 2.
Puede haber varias cargas ISAKMP enlazadas, con cada tipo de carga subsiguiente indicado por el valor en el campo Encabezado siguiente. Un valor de 0000 indica la última carga ISAKMP. Consulte Figura 3 para ver un ejemplo.
Procesamiento de paquete IPsec
Una vez que se completan las negociaciones de IKE y las dos puertas de enlace IKE han establecido asociaciones de seguridad (SA) de fase 1 y fase 2, todos los paquetes subsiguientes se reenvían mediante el túnel. Si la SA de fase 2 especifica el Protocolo de seguridad de encapsulación (ESP) en modo de túnel, el paquete tiene un aspecto similar al que se muestra en Figura 4. El dispositivo agrega dos encabezados adicionales al paquete original que envía el host iniciador.
Tal como se muestra en Figura 4, el paquete que crea el host iniciador incluye la carga, el encabezado TCP y el encabezado de IP interior (IP1).
El encabezado IP del enrutador (IP2), agregado por Junos OS, contiene la dirección IP de la puerta de enlace remota como dirección IP de destino y la dirección IP del enrutador local como dirección IP de origen. Junos OS también agrega un encabezado ESP entre los encabezados IP externo e interno. El encabezado ESP contiene información que permite al par remoto del mismo nivel procesar correctamente el paquete cuando lo recibe. Esto se muestra en Figura 5.
El campo Siguiente encabezado indica el tipo de datos del campo de carga. En el modo de túnel, este valor es 4, lo cual indica que un paquete IP está contenido dentro de la carga. Consulte Figura 6.
Introducción a IKE en Junos OS
IKE proporciona formas de intercambiar claves para el cifrado y la autenticación de forma segura a través de un medio no seguro, como Internet. IKE habilita un par de puertas de enlace de seguridad: Establezca dinámicamente un túnel seguro a través del cual las puertas de enlace de seguridad puedan intercambiar información clave y de túnel. Configure túneles o SA a nivel de usuario, incluidas las negociaciones de atributos de túnel y la administración de claves. Estos túneles también se pueden actualizar y terminar en la parte superior del mismo canal seguro. IKE emplea métodos Diffie-Hellman y es opcional en IPsec (las claves compartidas se pueden especificar manualmente en los extremos).
IKEv2 incluye soporte para:
VPN basadas en rutas.
VPN de sitio a sitio.
Detección de pares muertos.
Clúster de chasis.
Autenticación de clave precompartida.
Autenticación basada en certificados.
SA infantiles. Una SA secundaria IKEv2 se conoce como SA de fase 2 en IKEv1. En IKEv2, una SA secundaria no puede existir sin la SA de IKE subyacente.
AutoVPN.
VPN de punto de conexión dinámico.
EAP es compatible con el acceso remoto mediante IKEv2.
Selectores de tráfico.
IKEv2 no admite las siguientes características:
VPN basada en políticas.
Supervisión de VPN.
Protocolo de compresión de carga IP (IPComp).
- Configuración de IKEv2 en Junos OS
- Descripción de la carga de configuración de IKEv2
- Descripción del aprovisionamiento de células pico
Configuración de IKEv2 en Junos OS
Un par VPN se configura como IKEv1 o IKEv2. Cuando un par se configura como IKEv2, no puede recurrir a IKEv1 si su par remoto inicia la negociación de IKEv1. De forma predeterminada, los dispositivos de seguridad de Juniper Networks son pares IKEv1.
Utilice la instrucción de version v2-only configuración en el nivel de jerarquía [edit security ike gateway gw-name] para configurar IKEv2.
La versión de IKE se muestra en la salida de los show security ike security-associations comandos operativos y show security ipsec security-associations CLI.
Los dispositivos de Juniper Networks admiten hasta cuatro propuestas para negociaciones de fase 2, lo que le permite definir qué tan restrictivo será un rango de parámetros de túnel que aceptará. Junos OS proporciona conjuntos predefinidos de propuestas de fase 2 de tipo básicas, compatibles y estándar. También puede definir propuestas de fase 2 personalizadas.
Descripción de la carga de configuración de IKEv2
La carga de configuración es una opción de Intercambio de claves por Internet versión 2 (IKEv2) que se ofrece para propagar la información de aprovisionamiento de un respondedor a un iniciador. La carga de configuración de IKEv2 solo es compatible con VPN basadas en rutas.
RFC 5996, Protocolo de intercambio de claves por Internet versión 2 (IKEv2), define 15 atributos de configuración diferentes que el respondedor puede devolver al iniciador. Tabla 1 describe los atributos de configuración de IKEv2 admitidos en los firewalls de la serie SRX.
|
Tipo de atributo |
valor |
Description |
Largura |
|---|---|---|---|
|
INTERNAL_IP4_ADDRESS |
1 |
Especifica una dirección en la red interna. Se pueden solicitar múltiples direcciones internas. El respondedor puede enviar hasta el número de direcciones solicitadas. |
0 o 4 octetos |
|
INTERNAL_IP4_NETMASK |
2 |
Especifica el valor de máscara de red de la red interna. Solo se permite un valor de máscara de red en los mensajes de solicitud y respuesta (por ejemplo, 255.255.255.0) y solo debe usarse con un atributo INTERNAL_IP4_ADDRESS. |
0 o 4 octetos |
|
INTERNAL_IP4_DNS |
3 |
Especifica la dirección de un servidor DNS dentro de la red. Se pueden solicitar varios servidores DNS. El respondedor puede responder con cero o más atributos del servidor DNS. |
0 o 4 octetos |
|
INTERNAL_IP4_NBNS |
4 |
Especifica una dirección de un servidor de nombres NetBIOS (NBNS), por ejemplo, un servidor WINS, dentro de la red. Se pueden solicitar múltiples servidores NBNS. El respondedor puede responder con cero o más atributos de servidor NBNS. |
0 o 4 octetos |
| INTERNAL_IP6_ADDRESS |
8 |
Especifica una dirección en la red interna. Se pueden solicitar múltiples direcciones internas. El respondedor puede enviar hasta el número de direcciones solicitadas. |
0 o 17 octetos |
| INTERNAL_IP6_DNS |
10 |
Especifica la dirección de un servidor DNS dentro de la red. Se pueden solicitar varios servidores DNS. El respondedor puede responder con cero o más atributos del servidor DNS. |
0 o 16 octetos |
Para que el respondedor IKE proporcione al iniciador información de aprovisionamiento, debe adquirir la información de un origen especificado, como un servidor RADIUS. La información de aprovisionamiento también se puede devolver desde un servidor DHCP a través de un servidor RADIUS. En el servidor RADIUS, la información del usuario no debe incluir una contraseña de autenticación. El perfil de servidor RADIUS está enlazado a la puerta de enlace IKE mediante la aaa access-profile profile-name configuración en el nivel de jerarquía [edit security ike gateway gateway-name].
A partir de Junos OS versión 20.3R1, en SRX5000 línea con SPC3 y vSRX Virtual Firewall ejecutando iked proceso, hemos mejorado la carga de configuración de IKEv2 para:
-
Compatibilidad con el conjunto de direcciones locales IPv4 e IPv6. También puede asignar una dirección IP fija a un par.
Durante el establecimiento de IKE, el iniciador solicita una dirección IPv4, una dirección IPv6, una dirección DNS o una dirección WINS del respondedor. Después de que el respondedor ha autenticado correctamente al iniciador, asigna una dirección IP desde un grupo de direcciones local o a través del servidor RADIUS. Dependiendo de la configuración, esta dirección IP se asigna dinámicamente cada vez que un par se conecta o se asigna como una dirección IP fija. Si el servidor RADIUS responde con un grupo enmarcado, Junos OS asigna una dirección IP o información en función de la configuración de su grupo local correspondiente. Si configura tanto el grupo de direcciones local como el servidor RADIUS, la dirección IP asignada desde el servidor RADIUS tiene prioridad sobre el grupo local. Si configura un grupo de direcciones IP local y el servidor RADIUS no devolvió ninguna dirección IP, el grupo local asignará la dirección IP a la solicitud.
-
Opción adicional,
noneintroducida paraauthentication-order. Consulte Orden de autenticación (perfil de acceso). -
Los mensajes de inicio y detención de la contabilidad RADIUS informan del estado del túnel o del par del servidor RADIUS. Estos mensajes se pueden utilizar con fines de seguimiento o notificaciones a subsistemas como un servidor DHCP.
Asegúrese de que el servidor RADIUS admite mensajes de inicio o detención de cuentas. Asegúrese también de que tanto los firewalls de la serie SRX como el servidor RADIUS tengan la configuración adecuada para realizar un seguimiento de estos mensajes.
-
La introducción de la compatibilidad con IPv6 permite túneles de pila dual que utilizan la carga de configuración. Durante el proceso de inicio de sesión, IKE solicita direcciones IPv4 e IPv6. AAA permite el inicio de sesión solo si todas las direcciones solicitadas se han asignado correctamente. IKE finaliza la negociación si no se asigna la IP solicitada.
En una VPN basada en ruta, las interfaces de túnel seguro (st0) funcionan en modo punto a multipunto o punto a punto. La asignación de direcciones a través de la carga de configuración de IKEv2 ahora se admite para el modo punto a multipunto o punto a punto. Para las interfaces de punto a multipunto, las interfaces deben estar numeradas y las direcciones en la carga de configuración INTERNAL_IP4_ADDRESS tipo de atributo deben estar dentro del rango de subred de la interfaz punto a multipunto asociada.
A partir de Junos OS versión 20.1R1, puede configurar una contraseña común para las solicitudes de carga de configuración de IKEv2 para una configuración de puerta de enlace IKE. La contraseña común en el intervalo de 1 a 128 caracteres permite al administrador definir una contraseña común. Esta contraseña se utiliza entre el firewall de la serie SRX y el servidor RADIUS cuando el firewall de la serie SRX solicita una dirección IP en nombre de un par IPsec remoto mediante la carga de configuración de IKEv2. El servidor RADIUS coincide con las credenciales antes de proporcionar cualquier información IP al firewall de la serie SRX para la solicitud de carga de configuración. Puede configurar la contraseña común mediante config-payload-password configured-password la instrucción de configuración en el nivel de jerarquía [edit security ike gateway gateway-name aaa access-profile access-profile-name].
Tanto el firewall de la serie SRX como el servidor RADIUS deben tener la misma contraseña configurada y el servidor RADIUS debe configurarse para usar el Protocolo de autenticación de contraseña (PAP) como protocolo de autenticación. Sin esto, el establecimiento del túnel no tendrá éxito.
Figura 7 muestra un flujo de trabajo típico para una carga de configuración IKEv2.
La función de carga de configuración IKEv2 es compatible tanto con interfaces de túnel seguro punto a multipunto (st0) como con interfaces punto a punto. Las interfaces punto a multipunto deben estar numeradas y las direcciones proporcionadas en la carga de configuración deben estar dentro del rango de subred de la interfaz punto a multipunto asociada.
A partir de Junos OS versión 20.1R1, admitimos la función de carga de configuración IKEv2 con interfaces punto a punto en línea SRX5000 y firewall virtual vSRX ejecutando iked.
Descripción del aprovisionamiento de células pico
La carga de configuración de IKEv2 se puede usar para propagar información de aprovisionamiento desde un respondedor IKE, como un firewall de la serie SRX, a múltiples iniciadores, como las estaciones base de celdas pico LTE en una red celular. Las picoceldas se envían de fábrica con una configuración estándar que les permite conectarse al firewall de la serie SRX, pero la información de aprovisionamiento de picoceldas se almacena en uno o más servidores de aprovisionamiento dentro de una red protegida. Las picoceldas reciben información completa de aprovisionamiento después de establecer conexiones seguras con los servidores de aprovisionamiento.
El flujo de trabajo necesario para arrancar y aprovisionar una pico celda e introducirla en el servicio incluye cuatro etapas distintas:
-
Adquisición de direcciones iniciales: la pico cell se envía desde la fábrica con la siguiente información:
-
Configuración del túnel de puerta de enlace segura al firewall de la serie SRX
-
Certificado digital emitido por el fabricante
-
Nombre de dominio completo (FQDN) de los servidores de aprovisionamiento que se encuentran dentro de la red protegida
La pico celda se inicia y adquiere una dirección que se utilizará para la negociación de IKE desde un servidor DHCP. A continuación, se construye un túnel a la puerta de enlace segura en el firewall de la serie SRX utilizando esta dirección. El servidor DHCP también asigna una dirección para el tráfico de operación, administración y administración (OAM) para su uso en la red protegida.
-
Aprovisionamiento de pico celling: mediante su dirección de tráfico OAM asignada, la pico cell solicita su información de aprovisionamiento (normalmente certificado de operador, licencia, software e información de configuración) a los servidores de la red protegida.
Reiniciar: la pico celda se reinicia y utiliza la información de aprovisionamiento adquirida para hacerla específica para la red y el modelo de operación del proveedor de servicios.
-
Prestación de servicios: cuando la pico cell entra en servicio, utiliza un único certificado que contiene valores de nombre distintivo (DN) y nombre alternativo de sujeto con un FQDN para construir dos túneles a la puerta de enlace segura en el firewall de la serie SRX: uno para el tráfico OAM y el otro para el tráfico de datos del Proyecto de Asociación de Tercera Generación (3GPP).
Consulte también
Propuesta de IKE
La configuración de IKE define los algoritmos y las claves utilizados para establecer la conexión IKE segura con la puerta de enlace de seguridad del mismo nivel. Puede configurar una o varias propuestas de IKE. Cada propuesta es una lista de atributos IKE para proteger la conexión IKE entre el host IKE y su par.
Para configurar una propuesta de IKE, incluya la proposal instrucción y especifique un nombre en el nivel de jerarquía [edit security ike ]:
Política de IKE
Una política de IKE define una combinación de parámetros de seguridad (propuestas de IKE) que se utilizarán durante la negociación de IKE. Define una dirección de pares y las propuestas necesarias para esa conexión. Según el método de autenticación que se utilice, define la clave previamente compartida para el par dado o el certificado local. Durante la negociación de IKE, IKE busca una política de IKE que sea la misma en ambos pares. El par que inicia la negociación envía todas sus directivas al par remoto y el par remoto intenta encontrar una coincidencia. Se realiza una coincidencia cuando ambas directivas de los dos pares tienen una propuesta que contiene los mismos atributos configurados. Si las duraciones no son idénticas, se utiliza la vida útil más corta entre las dos políticas (del host y del par). La clave previamente compartida configurada también debe coincidir con su par.
En primer lugar, configure una o varias propuestas de IKE; a continuación, asociar estas propuestas a una política de IKE.
Para configurar una política de IKE, incluya la policy instrucción y especifique un nombre de política en el nivel de jerarquía [edit security ike]:
Reintroducción de claves y reautenticación
Descripción general
Con IKEv2, la reintroducción de claves y la reautenticación son procesos separados. La reintroducción de claves establece nuevas claves para la asociación de seguridad (SA) de IKE y restablece los contadores de ID de mensajes, pero no vuelve a autenticar a los pares. La reautenticación verifica que los pares de VPN conserven su acceso a las credenciales de autenticación. La reautenticación establece nuevas claves para la SA de IKE y las SA secundarias; ya no se necesitan las reclaves de ninguna SA IKE o SA secundaria pendiente. Después de crear el nuevo IKE y las SA secundarias, se eliminan el IKE antiguo y las SA secundarias.
La reautenticación IKEv2 está deshabilitada de forma predeterminada. Para habilitar la reautenticación, configure un valor de frecuencia de reautenticación entre 1 y 100. La frecuencia de reautenticación es el número de reclaves IKE que se producen antes de que se produzca la reautenticación. Por ejemplo, si la frecuencia de reautenticación configurada es 1, se produce una nueva autenticación cada vez que hay una reclave IKE. Si la frecuencia de reautenticación configurada es 2, la reautenticación se produce en cada dos reclaves de IKE. Si la frecuencia de reautenticación configurada es 3, se produce una nueva autenticación en cada tercera reclave IKE, y así sucesivamente.
La frecuencia de reautenticación se configura con la reauth-frequency instrucción en el nivel de jerarquía [edit security ike policy policy-name]. La reautenticación se deshabilita estableciendo la frecuencia de reautenticación en 0 (valor predeterminado). La frecuencia de reautenticación no es negociada por los pares y cada par puede tener su propio valor de frecuencia de reautenticación.
Características soportadas
La reautenticación IKEv2 es compatible con las siguientes características:
Iniciadores o respondedores de IKEv2
Detección de pares muertos (DPD)
Enrutadores virtuales e interfaces de túnel seguro (st0) en enrutadores virtuales
Recorrido de traducción de direcciones de red (NAT-T)
Clústeres de chasis en modo activo-activo y activo-pasivo para dispositivos de SRX5400, SRX5600 y SRX5800
Actualización de software en servicio (ISSU) en dispositivos SRX5400, SRX5600 y SRX5800
Actualización o inserción de una nueva unidad de procesamiento de servicios (SPU) mediante el procedimiento de actualización de hardware en servicio (ISHU)
Limitaciones
Tenga en cuenta las siguientes advertencias al usar la reautenticación IKEv2:
Con NAT-T, se puede crear una nueva SA de IKE con puertos diferentes de la SA de IKE anterior. En este escenario, es posible que no se elimine la SA de IKE antigua.
En un escenario NAT-T, el iniciador detrás del dispositivo NAT puede convertirse en el respondedor después de la reautenticación. Si la sesión NAT caduca, el dispositivo NAT podría descartar nuevos paquetes IKE que podrían llegar a un puerto diferente. NAT-T keepalive o DPD deben estar habilitados para mantener viva la sesión NAT. Para AutoVPN, recomendamos que la frecuencia de reautenticación configurada en los radios sea menor que la frecuencia de reautenticación configurada en el concentrador.
En función de la frecuencia de reautenticación, el iniciador o el respondedor de la SA original pueden iniciar una nueva SA de IKE. Dado que la carga de configuración y autenticación del Protocolo de autenticación extensible (EAP) requieren que la SA de IKE la inicie la misma parte que la SA de IKE original, no se admite la reautenticación con la autenticación EAP ni con la carga de configuración.
Autenticación IKE (autenticación basada en certificados)
Jerarquía multinivel para la autenticación de certificados
La autenticación basada en certificados es un método de autenticación admitido en los firewalls de la serie SRX durante la negociación IKE. En redes grandes, varias autoridades de certificación (CA) pueden emitir certificados de entidad final (EE) a sus respectivos dispositivos finales. Es común tener CA independientes para ubicaciones, departamentos u organizaciones individuales.
Cuando se emplea una jerarquía de un solo nivel para la autenticación basada en certificados, todos los certificados EE de la red deben estar firmados por la misma CA. Todos los dispositivos de firewall deben tener el mismo certificado de CA inscrito para la validación del certificado del mismo nivel. La carga del certificado enviada durante la negociación de IKE solo contiene certificados EE.
Alternativamente, la carga de certificado enviada durante la negociación de IKE puede contener una cadena de certificados EE y CA. Una cadena de certificados es la lista de certificados necesarios para validar el certificado EE de un par. La cadena de certificados incluye el certificado EE y cualquier certificado de CA que no esté presente en el par local.
El administrador de red debe asegurarse de que todos los pares que participan en una negociación de IKE tengan al menos una CA de confianza común en sus respectivas cadenas de certificados. La CA de confianza común no tiene que ser la CA raíz. El número de certificados de la cadena, incluidos los certificados para EE y la CA más alta de la cadena, no puede superar los 10.
A partir de Junos OS versión 18.1R1, la validación de un par IKE configurado se puede realizar con un servidor de CA especificado o un grupo de servidores de CA. Con las cadenas de certificados, la CA raíz debe coincidir con el grupo de CA de confianza o el servidor de CA configurado en la política de IKE
En la jerarquía de CA de ejemplo que se muestra en Figura 8, Root-CA es la CA de confianza común para todos los dispositivos de la red. La CA raíz emite certificados de CA a las CA de ingeniería y ventas, que se identifican como Eng-CA y Sales-CA, respectivamente. Eng-CA emite certificados de CA para las CA de desarrollo y control de calidad, que se identifican como Dev-CA y Qa-CA, respectivamente. El host A recibe su certificado EE de Dev-CA, mientras que el host B recibe su certificado EE de Sales-CA.
Cada dispositivo final debe cargarse con los certificados de CA en su jerarquía. El host-A debe tener certificados Root-CA, Eng-CA y Dev-CA; Los certificados Sales-CA y Qa-CA no son necesarios. El host B debe tener certificados Root-CA y Sales-CA. Los certificados se pueden cargar manualmente en un dispositivo o inscribirse mediante el Proceso simple de inscripción de certificados (SCEP).
Cada dispositivo final debe configurarse con un perfil de CA para cada CA de la cadena de certificados. El siguiente resultado muestra los perfiles de CA configurados en el host-A:
admin@host-A# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
}
ca-profile Eng-CA {
ca-identity Eng-CA;
enrollment {
url “www.example.net/scep/Eng/”;
}
}
ca-profile Dev-CA {
ca-identity Dev-CA;
enrollment {
url “www.example.net/scep/Dev/”;
}
}
}El siguiente resultado muestra los perfiles de CA configurados en el host B:
admin@host-B# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
}
ca-profile Sales-CA {
ca-identity Sales-CA;
enrollment {
url “www.example.net/scep/Sales/”;
}
}
}Consulte también
Protección IKE contra ataques DDoS
La denegación de servicio(DoS) es uno de los ataques más comunes y graves en una red VPN IPsec insegura. Un ataque DoS proporciona una manera rápida y fácil de apoderarse de la red, ya que no requiere mucho punto de apoyo en la infraestructura de red. Losatacantes eligen este método para tomar el control de la red.
¿Qué sucede en un ataque DoS?
El atacante intenta inundar y bloquear gradualmente la red con demasiado tráfico, agotando los recursos de red y tomando aún más el control de los recursos del dispositivo, como la memoria y la CPU. Si el atacante intenta controlar mediante varios sistemas orquestados, atacando sincrónicamente a un único objetivo, se denomina ataques DoS distribuidos (DDoS).
- Vulnerabilidades de DDoS en implementaciones de IKE
- Protección Against Ataques DDoS
- Formas de monitorear ataques DDoS
Vulnerabilidades de DDoS en implementaciones de IKE
Cuando el interlocutor remoto (iniciador) envía un mensaje SA_INIT, el interlocutor local (respondedor) responde y asigna memoria para la estructura del mensaje. Llamamos a la sesión una sesión IKE semiabierta hasta que se produzca la autenticación con la ayuda del mensaje IKE_AUTH. Después de que los pares establecen una asociación de seguridad (SA) de IKE, la sesión se convierte en una sesión de IKE completamente abierta.
Para comprender las vulnerabilidades de IKEv2 DDoS, veamos algunas de las formas en que un atacante puede crear un vector de ataque fácil contra las SA de IKE:
-
Enviar un gran número de mensajes de SA_INIT (sin mensajes IKE_AUTH) para los que el atacante puede crear estructuras de asociación de seguridad IKE medio abiertas. El ataque hace que el dispositivo utilice los recursos y se quede sin memoria.
-
Envíe una gran cantidad de paquetes de IKE_AUTH no deseado con el SPI_i y el SPI_r correctos en el iniciador y el respondedor, respectivamente. El dispositivo se queda sin memoria al intentar descifrar los paquetes.
-
Envíe paquetes SA_INIT continuamente. El dispositivo se queda sin memoria al intentar generar claves para los paquetes cifrados.
-
Envíe un gran número de solicitudes de reclave por segundo durante las sesiones de IKE completamente abiertas.
-
Envíe un gran número de mensajes con identificadores de mensajes (ID) distintos. Eldispositivo pone en cola todos los mensajes IKE entrantes y se quedasin memoria.
Cómo proteger las implementaciones de IKE
Proporcionamos una infraestructura robusta para mitigar y monitorear los ataques DDoS para los protocolos IKEv1 e IKEv2. Puede protegerse contra los ataques a las implementaciones de IKE cuando el firewall ejecuta el proceso iked (en el junos-ike paquete) para el servicio VPN IPsec.
Para obtener más información sobre la protección DDoS para IKEv2, consulte RFC 8019, Protección de implementaciones del Protocolo de intercambio de claves por Internet versión 2 (IKEv2) de ataques de denegación de servicio distribuidos. Proporcionamosuna protección similar para IKEv1 cuando su firewall ejecuta el servicio VPN IPsec mediante el proceso iked. No admitimos el mecanismo de rompecabezas de cliente que presenta el RFC.
Protección Against Ataques DDoS
Puede habilitar varios mecanismos de defensa contra los ataques DDoS durante el proceso de creación de asociaciones de seguridad IKE. Estos mecanismos incluyen la configuración de la limitación de la tasa y un período de retención para las SA de IKE semiabiertas, y la gestión adicional de los tipos de cambio entrantes para las solicitudes de reclave. Proporcionamos las siguientes medidas para garantizar la protección contra ataques DDoS en SA IKE:
- Medidas de protección deSA de IKE o semiabiertas:
-
El respondedor no permite la configuración de SAde IKE semiabiertos durante un período determinado. Puede establecer este límite para que el respondedor no configure las SA hasta que alcance la duración del tiempo de espera. Para obtener más información, consulte session (Security IKE) la opción
timeout. -
Puede establecer un límite para el máximo permitido de SA de IKE medio abiertas en el respondedor. Cuando el número total de SA de IKE semiabiertas alcanza el recuento máximo, el respondedor rechaza las nuevas conexiones para las SA IKEv1 e IKEv2. Para obtener más información, consulte la
max-countopción ensession (Security IKE). -
El respondedor aplica valores de umbral en el recuento de sesiones para las SA de IKE medio abiertas. Cuando el número total de SA de IKE semiabiertas alcanzalos valores de umbral:
-
En el caso de las SA IKEv2, el respondedor invoca el mecanismo de cookies para cualquier conexión nueva.
-
En el caso de las SA IKEv1, el respondedor rechaza las nuevas conexiones.
Para obtener más información, consulte las opciones y las opciones de session (Security IKE)
thresholdssend-cookiereduce-timeout. -
-
El respondedor puede descartar sesiones duplicadas. Para obtener más información, consulte la
discard-duplicateopción en session (Security IKE). -
Puede establecer tiempos de espera de retroceso para las fases de error de autenticación e iniciación. Para obtener más información, consulte session (Security IKE) las opciones
backoff-timeouts,init-phase-failureyauth-phase-failure.
-
-
Para SA de IKE completamente abiertas:
-
Puede configurar las tasas máximas de solicitudes de reclave entrantes para limitar las solicitudes en un escenario escalado. Para obtener más información, consulte la
incoming-exchange-max-ratesopción en session (Security IKE).
-
-
El respondedor puede bloquear una sesión de IKE entrante de pares en función del ID de IKE del mismo nivel. Para obtener más información, consulte blocklists (Security IKE).
-
En el caso de las puertas de enlace dinámicas, puede establecer un límite para el número de conexiones en el nivel de configuración de la puerta de enlace de IKE mediante la opción
connections-limit. Para obtener más información, consulte Puerta de enlace (IKE de seguridad).
Para obtener más información sobre cómo configurar estas opciones, consulte Configurar la protección contra ataques DDoS de IKE.
No admitimos:
-
Protección DDoS con el servicio VPN IPsec basado en el proceso kmd.
-
Protección contra ataques de codificación de certificados hash y URL , ya que no admitimos estos tipos de codificación.
Formas de monitorear ataques DDoS
Proporcionamos los siguientes mecanismos para monitorear los ataques DDoS:
-
Utilice el
show security ike security-associationscomando para enumerar todas las asociacionesde seguridad de IKE maduras y no maduras. Para obtener más información, consulte mostrar asociaciones de seguridad ike de seguridad. -
Utilice el
show security ike statscomando para mostrar estadísticas globales de IKE del túnel VPN IPsec, como estadísticas en curso, establecidas y caducadas. Para obtener más información, consulta Mostrar estadísticas de ike de seguridad. -
Utilice el
show security ike active-peercomando para mostrar detalles de las negociaciones exitosas de IKE con los pares remotos. Para obtener más información, consulte mostrar ike de seguridad active-peer. -
Utilice el
show security ike peers in-progresscomando para mostrar los detalles de las SA de IKE en curso, incluidas las SA de IKE medio abiertas. Para obtener más información, consulte show security ike peers. También puede ver los detalles de los pares bloqueados, con errores y de retroceso mediante este comando. -
Utilice el
clear security ike peerscomando para borrar los pares de IKE que están retrocedidos, bloqueados, fallidos o en curso. Para obtener más información, consulte clear security ike peers. -
Para eliminar una asociación de seguridad IKE existente con pares que deba bloquearse para que no pueda seguir comunicándose, utilice el
clear security ike security-associationscomando. Para obtener más información, consulte clear security ike security-associations. -
Los mensajes iked system log (syslog) IKE_GATEWAY_PEER_BLOCKED, IKE_GATEWAY_PEER_BACKOFF y IKE_GATEWAY_PEER_FAILED proporcionan detalles sobre las negociaciones IKE bloqueadas, respaldadas y fallidas con los pares remotos, respectivamente.
-
Para mayor seguridad, Junos OS ofrece servicios a los usuarios para protegerse contra ataques al sistema basados en paquetes, como el filtrado, el recuento de sesiones y la limitación de velocidad. Para obtener más información, consulte el comando show firewall y la instrucción ids-option en el nivel de jerarquía [
edit security screen ids-option screen-name].
Configurar la protección contra ataques DDoS de IKE
SUMMARY Consulte esta sección para comprender cómo configurar la protección contra ataques DDoS en el protocolo IKE.
Prerequisitos
Antes de configurar la protección contra los ataques DDoS de IKE, asegúrese de que cumple los siguientes requisitos previos:
-
Firewall de la serie SRX que admite
junos-ikeel paquete para ejecutar el servicio VPN IPsec mediante el proceso iked. -
El firewall serie SRX que sirve como punto de conexión local (el respondedor) es accesible para el par IKE remoto (el iniciador).
-
Una política de IKE que puede asociar una lista de bloqueo de IKE.
La configuración de la protección contra los ataques DDoS de IKE consiste en las siguientes acciones :
-
Administre las SA de IKE medio abiertas entrantes.
-
Gestione las SA de IKE completamente abiertas entrantes.
-
Configure varios métodos de bloqueo para bloquear las sesiones entrantes de IKE de varios pares y asociar una de las listas de bloqueo con un par IKE.
Consulte las siguientes tareas para configurar estas acciones.
- Configurar la sesión de IKE para SA de IKE medio abiertas
- Configurar la sesión de IKE para SA de IKE completamente abiertas
- Configurar las listas de bloqueo de sesión de IKE
Configurar la sesión de IKE para SA de IKE medio abiertas
Descripción general
Asegúrese de cumplir con todos los requisitos previos descritos anteriormente.
En esta sección, verá cómo configurar los tiempos de espera, el recuento máximo y los umbrales para las SA de IKE medio abiertas. Los cambios de configuración son aplicables a las nuevas sesiones, mientras que las sesiones existentes siguen utilizando los valores predeterminados cuando no se configuran explícitamente antes. El alcance de estas configuraciones en el nivel jerárquico [edit security ike session half-open] es aplicable a nivel global y no por nivel par.
Configuración
-
Para establecer el parámetro de duración del respondedor mediante la opción
timeout seconds:[edit] user@host# set security ike session half-open timeout 150
Durante este período, el respondedor no permite la configuración de SA de IKE medio abiertas hasta que alcanza la duración del tiempo de espera. El iniciador puede seguir teniendo una duración de tiempo de espera de 60 segundos, independientemente de la configuración del respondedor.
-
Para establecer el parámetro de recuento máximo del respondedor mediante la opción
max-count value:[edit] user@host# set security ike session half-open max-count 1000
La opción establece el número máximo de sesiones de IKE semiabiertas en el respondedor. El valor predeterminado es 300, si no lo especifica. La
max-countconfiguración deshabilita todos los umbrales. En tales casos, debe configurar explícitamente los umbrales para hacerlos cumplir. -
Especifique los diferentes tipos de acciones mediante la opción
thresholdcuando el recuento de sesiones del respondedor alcance el límite.-
Para establecer el número mínimo de sesiones de IKE medio abiertas para aplicar la acción de cookie mediante la opción
send-cookie count:[edit] user@host# set security ike session half-open threshold send-cookie 500
Esto especifica el límite de umbral a partir del cual el respondedor solicita a los pares remotos que reintenten el inicio de la sesión con una cookie enviada de vuelta al par en la respuesta inicial. Aquí, cuando el límite de recuento de sesiones de IKE medio abiertas alcanza 500, el proceso iked emplea un mecanismo de cookies para las nuevas sesiones de IKE.
-
Para establecer el número mínimo de sesiones de IKE medio abiertas para aplicar una acción de tiempo de espera reducido mediante la opción
reduced-timeout count timeout seconds:[edit] user@host# set security ike session half-open threshold reduce-timeout 600 timeout 100
Esto especifica el límite a partir del cual el proceso iked reduce la duración de las nuevas SA de IKE medio abiertas. Una vez que el recuento de sesiones de IKE del respondedor medio abierto se reduce por debajo del umbral, las sesiones IKE del respondedor medio abierto vuelven a utilizar el valor de tiempo de espera predeterminado.
-
-
Para definir la opción
discard-duplicatecon el fin de descartar las sesiones IKE medio abiertas duplicadas sin enviar una respuesta al iniciador:[edit] user@host# set security ike session half-open discard-duplicate
Para una solicitud de inicio de sesión (SA_INIT) duplicada que proviene del mismo par, con una cookie de iniciador diferente para la cual no hay SA de IKE mientras la negociación está en curso, el respondedor descarta el paquete.
-
Puede establecer los tiempos de espera de retroceso mediante la opción
backoff-timeouts.Esto da algo de tiempo para que el par remoto retroceda en caso de que se produzca un error en el inicio de una sesión, lo que garantiza que el mismo par no pueda iniciar una nueva sesión durante ese período. Después del tiempo de espera de retroceso, el par puede iniciar una nueva sesión. El inicio de la sesión puede fallar en dos fases: la fase de inicialización y la fase de autenticación.
-
Para establecer el tiempo de espera de retroceso cuando se produce un error durante la fase de IKE_AUTH mediante la opción
backoff-timeouts auth-phase-failure value:[edit] user@host# set security ike session half-open backoff-timeouts auth-phase-failure 150
Al configurar
auth-phase-failure, cualquier par remoto que esté en la lista de bloqueados, retrocede incluso cuando no configure el retroceso como una acción para la regla de la lista de bloqueo de destino. El tiempo de espera para el backoff es el configurado paraauth-phase-failure. En este ejemplo, el dispositivo inicia una nueva sesión después de 150 segundos. Para sobrescribir este tiempo de espera de retroceso para una regla determinada, puede configurar explícitamente labackoffacción para la listarulede bloqueo mencionando el tiempo de espera en el [edit security ike blocklists blocklist1 rule rule-name then backoff timeout-value] hierarchy level. -
Para establecer el tiempo de espera de retroceso cuando hay un error durante la fase de SA_INIT mediante la opción
backoff-timeouts init-phase-failure value:[edit] user@host# set security ike session half-open backoff-timeouts init-phase-failure 160
En este ejemplo, el dispositivo inicia una nueva sesión después de 160 segundos.
-
Para establecer el parámetro de duración del respondedor mediante la opción
timeout seconds:[edit] user@host# set security ike session half-open timeout 150
Durante este período, el respondedor no permite la configuración de SA de IKE medio abiertas hasta que alcanza la duración del tiempo de espera. El iniciador puede seguir teniendo una duración de tiempo de espera de 60 segundos, independientemente de la configuración del respondedor.
-
Configurar la sesión de IKE para SA de IKE completamente abiertas
Descripción general
Asegúrese de cumplir con todos los requisitos previos descritos anteriormente.
En esta sección, verá cómo configurar varias tasas de solicitudes entrantes para las SA de IKE abiertas completas mediante la opción incoming-exchange-max-rates en el nivel de jerarquía [edit security ike session full-open].
Configuración
Configure la incoming-exchange-max-rates opción para establecer las tasas máximas para varios intercambios iniciados por el par remoto después de establecer una SA de IKE. Puede configurar tres tipos de cambio: reclave IKE, reclave IPsec y keepalive (también conocido como detección de pares inactivos).
-
Para establecer la velocidad máxima de reclave del IKE iniciado por el par entrante mediante la opción
incoming-exchange-max-rates ike-rekey value:[edit] user@host# set security ike session full-open incoming-exchange-max-rates ike-rekey 200/60
La opción se aplica a la reclave IKEv2 por par con un par existente en el que ya esté presente una SA de IKE.
-
Para establecer la velocidad máxima de reclave de SA IPsec iniciada por el par entrante mediante la opción
incoming-exchange-max-rates ipsec-rekey value:[edit] user@host# set security ike session full-open incoming-exchange-max-rates ipsec-rekey 100/60
El límite se aplica por túnel.
-
Para establecer la tasa máxima de keepalive iniciado por pares entrantes usando la opción
incoming-exchange-max-rates keepalive value:[edit] user@host# set security ike session full-open incoming-exchange-max-rates keepalive 60/60
El límite se aplica por par.
Configurar las listas de bloqueo de sesión de IKE
Descripción general
Asegúrese de cumplir con todos los requisitos previos descritos anteriormente.
Para bloquear una sesión de IKE entrante de pares según el ID de IKE del mismo nivel, debe configurar una o más listas de bloqueo. Cada lista de bloqueo contiene una o más reglas. Cada regla tiene un criterio de coincidencia y una acción.
Tenga en cuenta los siguientes criterios al configurar las listas de bloqueo:
-
Las reglas de la lista de bloqueo se aplican a las nuevas SA de IKE que se están negociando y no afectan a las SA de IKE existentes. En la etapa de autenticación del mismo nivel, el dispositivo aplica las reglas de la lista de bloqueo.
-
El orden de aplicación de las reglas depende de la secuencia en la que se enumeran estas reglas.
-
Configure los criterios de coincidencia en función del rol (iniciador o respondedor), un tipo de ID (dirección IPv4 o IPv6, nombre de host, nombre distintivo, ID de correo electrónico o ID de clave) y un patrón de ID que es una expresión regular para que coincida con el ID de IKE.
-
Puede configurar cada regla con un tipo de ID. Esto le permite configurar diferentes ID de IKE para diferentes reglas dentro de la misma lista de bloqueo.
-
Configure una acción para descartar o rechazar la conexión del mismo nivel. En función de la coincidencia, el dispositivo aplica una acción. Opcionalmente, puede establecer el temporizador de retroceso con estas acciones.
-
Consulte la lista de bloqueo en la política de IKE asociada a la puerta de enlace de IKE.
-
Cada puerta de enlace de IKE solo admite un tipo de tipo de ID de IKE remoto. Si adjunta una lista de bloqueo a una puerta de enlace y la configura con reglas que contienen diferentes ID de IKE, la puerta de enlace aplicará y coincidirá solo con las reglas cuyo tipo de ID de IKE sea el mismo que el configurado para la puerta de enlace de IKE.
-
Las métricas de velocidad de configuración de túneles con listas de bloqueo que se adjuntan a las puertas de enlace de IKE se basan en el número de reglas configuradas en las listas de bloqueo.
En esta sección, verá cómo configurar listas de bloqueo y asociar la lista de bloqueo a una política de IKE.
Configuración
-
Para crear una lista de bloqueo con varias reglas:
-
Crear una lista de bloqueo.
[edit] user@host# set security ike blocklists blocklist1 description block_from_remote
-
Cree una o varias reglas.
[edit] user@host# set security ike blocklists blocklist1 rule rule1 description rule_1 user@host# set security ike blocklists blocklist1 rule rule2 description rule_2
Puede crear varias listas de bloqueo y sus reglas.
-
-
Para configurar los criterios de coincidencia y especificar la acción:
-
Configure los criterios de coincidencia para el rule1 en la lista blocklist1de bloqueo .
[edit] user@host# set security ike blocklists blocklist1 rule rule1 match role initiator user@host# set security ike blocklists blocklist1 rule rule1 match id-type hostname user@host# set security ike blocklists blocklist1 rule rule1 match id-pattern "peer.*\.example\.net" user@host# set security ike blocklists blocklist1 rule rule2 match role initiator user@host# set security ike blocklists blocklist1 rule rule2 match id-type user-at-hostname user@host# set security ike blocklists blocklist1 rule rule2 match id-pattern "hr.example.com"
Para configurar listas de bloqueo mediante un grupo de ID de IKE o ID de IKE parciales, utilice el
id-pattern valuecon un sufijo o prefijo. Por ejemplo, puede usar el valor *.example.com cuando necesite hacer coincidir hr.example.com, finance.example.com admin.example.com. En la regla rule1, el dispositivo busca el nombre de host que coincida con el patrón peer.*\.example\.net. Aquí peer.example.net, peer.1.example.net y peer.uplink.example.net hay algunas coincidencias potenciales. En la regla rule2, el dispositivo busca la dirección de correo electrónico que coincida con el patrón hr.example.com. Del mismo modo, puede configurar otro criterio de coincidencia para las otras reglas basadas en diferentesid-typeoid-pattern. Estos patrones utilizan la expresión regular estándar. -
Especifique la acción para una coincidencia:
[edit] user@host# set security ike blocklists blocklist1 rule rule1 then reject user@host# set security ike blocklists blocklist1 rule rule1 then backoff 60 user@host# set security ike blocklists blocklist1 rule rule2 then discard user@host# set security ike blocklists blocklist1 rule rule2 then backoff 100
-
-
Para asociar una lista de bloqueo con un par IKE:
-
Configure la lista blocklist1 de bloqueo en la política ike_policy1de IKE.
[edit] user@host# set security ike policy ike_policy1 blocklist blocklist1
-
Ejemplo: Configuración de un dispositivo para la validación en cadena de certificados del mismo nivel
En este ejemplo se muestra cómo configurar un dispositivo para cadenas de certificados utilizadas para validar dispositivos del mismo nivel durante la negociación de IKE.
- Requisitos
- Descripción general
- Configuración
- Verificación
- Error de IKE y SA IPsec para un certificado revocado
Requisitos
Antes de comenzar, obtenga la dirección de la entidad de certificación (CA) y la información que necesitan (como la contraseña de desafío) cuando envíe solicitudes de certificados locales.
Descripción general
En este ejemplo se muestra cómo configurar un dispositivo local para cadenas de certificados, inscribir certificados de CA y locales, comprobar la validez de los certificados inscritos y comprobar el estado de revocación del dispositivo del mismo nivel.
Topología
En este ejemplo se muestran los comandos de configuración y operativos en el host A, tal y como se muestra en Figura 9. Se crea automáticamente un perfil de CA dinámico en el Host-A para permitir que el Host-A descargue la CRL de Sales-CA y compruebe el estado de revocación del certificado del Host-B.
La configuración de VPN IPsec para la negociación de fase 1 y fase 2 se muestra para el host-A en este ejemplo. El dispositivo del mismo nivel (host-B) debe estar configurado correctamente para que las opciones de fase 1 y fase 2 se negocien correctamente y se establezcan asociaciones de seguridad (SA). Consulte Configuración de ID de IKE remoto para VPN de sitio a sitio para ver ejemplos de configuración de dispositivos del mismo nivel para VPN.
Configuración
Para configurar un dispositivo para cadenas de certificados:
Configurar perfiles de CA
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.
set security pki ca-profile Root-CA ca-identity CA-Root set security pki ca-profile Root-CA enrollment url http://198.51.100.230:8080/scep/Root/ set security pki ca-profile Root-CA revocation-check crl set security pki ca-profile Eng-CA ca-identity Eng-CA set security pki ca-profile Eng-CA enrollment url http://198.51.100.230:8080/scep/Eng/ set security pki ca-profile Eng-CA revocation-check crl set security pki ca-profile Dev-CA ca-identity Dev-CA set security pki ca-profile Dev-CA enrollment url http://198.51.100.230:8080/scep/Dev/ set security pki ca-profile Dev-CA revocation-check crl
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacer eso, consulte Uso del editor de CLI en el modo de configuración de la Guía del usuario de CLI.
Para configurar perfiles de CA:
Cree el perfil de CA para Root-CA.
[edit security pki] user@host# set ca-profile Root-CA ca-identity CA-Root user@host# set ca-profile Root-CA enrollment url http://198.51.100.230:8080/scep/Root/ user@host# set ca-profile Root-CA revocation-check crl
Cree el perfil de CA para Eng-CA.
[edit security pki] user@host# set ca-profile Eng-CA ca-identity Eng-CA user@host# set ca-profile Eng-CA enrollment url http://198.51.100.230:8080/scep/Eng/ user@host# set ca-profile Eng-CA revocation-check crl
Cree el perfil de CA para Dev-CA.
[edit security pki] user@host# set ca-profile Dev-CA ca-identity Dev-CA user@host# set ca-profile Dev-CA enrollment url http://198.51.100.230:8080/scep/Dev/ user@host# set ca-profile Dev-CA revocation-check crl
Resultados
Desde el modo de configuración, confírmela con el comando show security pki. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
[edit]
user@host# show security pki
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Root/";
}
revocation-check {
crl ;
}
}
ca-profile Eng-CA {
ca-identity Eng-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Eng/";
}
revocation-check {
crl ;
}
}
ca-profile Dev-CA {
ca-identity Dev-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Dev/";
}
revocation-check {
crl ;
}
}
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Inscribir certificados
Procedimiento paso a paso
Para inscribir certificados:
Inscriba los certificados de CA.
user@host> request security pki ca-certificate enroll ca-profile Root-CA
user@host> request security pki ca-certificate enroll ca-profile Eng-CA
user@host> request security pki ca-certificate enroll ca-profile Dev-CA
Escriba yes en las indicaciones para cargar el certificado de CA.
Compruebe que los certificados de CA estén inscritos en el dispositivo.
user@host> show security pki ca-certificate ca-profile Root-CA Certificate identifier: Root-CA Issued to: Root-CA, Issued by: C = us, O = example, CN = Root-CA Validity: Not before: 08-14-2012 22:19 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Eng-CA Certificate identifier: Eng-CA Issued to: Eng-CA, Issued by: C = us, O = example, CN = Root-CA Validity: Not before: 08-15-2012 01:02 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Dev-CA Certificate identifier: Dev-CA Issued to: Dev-CA, Issued by: C = us, O = example, CN = Eng-CA Validity: Not before: 08-15-2012 17:41 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)Compruebe la validez de los certificados de CA inscritos.
user@host> request security pki ca-certificate verify ca-profile Root-CA CA certificate Root-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Eng-CA CA certificate Eng-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Dev-CA CA certificate Dev-CA verified successfully
Generar un par de claves.
user@host> request security pki generate-key-pair certificate-id Host-A type rsa size 1024
Inscribir el certificado local.
user@host> request security pki local-certificate enroll certificate-id Host-A ca-profile Dev-CA challenge-password example domain-name host-a.example.net email host-a@example.net subject DC=example,CN=Host-A, OU=DEV,O=PKI,L=Sunnyvale,ST=CA,C=US
Compruebe que el certificado local está inscrito en el dispositivo.
user@host> show security pki local-certificate Issued to: Host-A, Issued by: C = us, O = example, CN = Dev-CA Validity: Not before: 09-17-2012 22:22 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(1024 bits)Compruebe la validez del certificado local inscrito.
user@host> request security pki local-certificate verify certificate-id Host-A Local certificate Host-A verification success
Compruebe si hay perfiles de CA configurados en la descarga de CRL.
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02
Configurar las opciones de VPN IPsec
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.
set security ike proposal ike_cert_prop_01 authentication-method rsa-signatures set security ike proposal ike_cert_prop_01 dh-group group5 set security ike proposal ike_cert_prop_01 authentication-algorithm sha1 set security ike proposal ike_cert_prop_01 encryption-algorithm aes-256-cbc set security ike policy ike_cert_pol_01 mode main set security ike policy ike_cert_pol_01 proposals ike_cert_prop_01 set security ike policy ike_cert_pol_01 certificate local-certificate Host-A set security ike gateway ike_cert_gw_01 ike-policy ike_cert_pol_01 set security ike gateway ike_cert_gw_01 address 192.0.2.51 set security ike gateway ike_cert_gw_01 external-interface ge-0/0/1.0 set security ike gateway ike_cert_gw_01 local-identity 192.0.2.31 set security ipsec proposal ipsec_prop_01 protocol esp set security ipsec proposal ipsec_prop_01 authentication-algorithm hmac-sha1-96 set security ipsec proposal ipsec_prop_01 encryption-algorithm 3des-cbc set security ipsec proposal ipsec_prop_01 lifetime-seconds 300 set security ipsec policy ipsec_pol_01 proposals ipsec_prop_01 set security ipsec vpn ipsec_cert_vpn_01 bind-interface st0.1 set security ipsec vpn ipsec_cert_vpn_01 ike gateway ike_cert_gw_01 set security ipsec vpn ipsec_cert_vpn_01 ike ipsec-policy ipsec_pol_01
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacer eso, consulte Uso del editor de CLI en el modo de configuración de la Guía del usuario de CLI.
Para configurar las opciones de VPN IPsec:
Configure las opciones de la fase 1.
[edit security ike proposal ike_cert_prop_01] user@host# set authentication-method rsa-signatures user@host# set dh-group group5 user@host# set authentication-algorithm sha1 user@host# set encryption-algorithm aes-256-cbc [edit security ike policy ike_cert_pol_01] user@host# set mode main user@host# set proposals ike_cert_prop_01 user@host# set certificate local-certificate Host-A [edit security ike gateway ike_cert_gw_01] user@host# set ike-policy ike_cert_pol_01 user@host# set address 192.0.2.51 user@host# set external-interface ge-0/0/1.0 user@host# set local-identity 192.0.2.31
Configure las opciones de la fase 2.
[edit security ipsec proposal ipsec_prop_01] user@host# set protocol esp user@host# set authentication-algorithm hmac-sha1-96 user@host# set encryption-algorithm 3des-cbc user@host# set lifetime-seconds 300 [edit security ipsec policy ipsec_pol_01] user@host# set proposals ipsec_prop_01 [edit security ipsec vpn ipsec_cert_vpn_01] user@host# set bind-interface st0.1 user@host# set ike gateway ike_cert_gw_01 user@host# set ike ipsec-policy ipsec_pol_01
Resultados
Desde el modo de configuración, escriba los comandos show security ike y show security ipsec para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
[edit]
user@host# show security ike
proposal ike_cert_prop_01 {
authentication-method rsa-signatures;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
}
policy ike_cert_pol_01 {
mode main;
proposals ike_cert_prop_01;
certificate {
local-certificate Host-A;
}
}
gateway ike_cert_gw_01 {
ike-policy ike_cert_pol_01;
address 192.0.2.51;
external-interface ge-0/0/1.0;
}
[edit]
user@host# show security ipsec
proposal ipsec_prop_01 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 300;
}
policy ipsec_pol_01 {
proposals ipsec_prop_01;
}
vpn ipsec_cert_vpn_01 {
bind-interface st0.1;
ike {
gateway ike_cert_gw_01;
ipsec-policy ipsec_pol_01;
}
}
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Verificación
Si la validación del certificado se realiza correctamente durante la negociación de IKE entre dispositivos pares, se establecen asociaciones de seguridad (SA) IKE e IPsec.
La SA de IKE está activa si el certificado es válido. La SA de IKE está inactiva y la SA de IPSEC se forma si se revoca el certificado, solo si la comprobación de revocación está configurada en el dispositivo del mismo nivel
Verificación del estado de la fase 1 de IKE
Propósito
Verifique el estado de la fase 1 de IKE.
Acción
Ingrese el comando desde el show security ike security-associations modo operativo.
user@host> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
2090205 DOWN 285feacb50824495 59fca3f72b64da10 Main 192.0.2.51
Comprobación del estado de fase 2 de IPsec
Propósito
Compruebe el estado de fase 2 de IPsec.
Acción
Ingrese el comando desde el show security ipsec security-associations modo operativo.
user@host> show security ipsec security-associations
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway
<131073 ESP:3des/sha1 a4756de9 207/ unlim - root 500 192.0.2.51
>131073 ESP:3des/sha1 353bacd3 207/ unlim - root 500 192.0.2.51
Error de IKE y SA IPsec para un certificado revocado
Comprobación de certificados revocados
Problema
Si se produce un error en la validación del certificado durante la negociación de IKE entre dispositivos del mismo nivel, asegúrese de que el certificado del mismo nivel no se haya revocado. Un perfil de CA dinámico permite que el dispositivo local descargue la CRL de la CA del mismo nivel y compruebe el estado de revocación del certificado del par. Para habilitar los perfiles de CA dinámicos, la opción debe configurarse en un perfil de revocation-check crl CA primario.
Solución
Para comprobar el estado de revocación del certificado de un par:
Identifique el perfil de CA dinámico que mostrará la CRL para el dispositivo par ingresando el comando desde el show security pki crl modo operativo.
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02 CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = example, CN = Sales-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02El perfil
dynamic-001de CA se crea automáticamente en el host A para que el host A pueda descargar la CRL de la CA del host B (Sales-CA) y comprobar el estado de revocación del certificado del par.Para mostrar la información de CRL para el perfil de CA dinámico, ingrese el comando desde el show security pki crl ca-profile dynamic-001 detail modo operativo.
Ingrese
user@host> show security pki crl ca-profile dynamic-001 detail CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = example, CN = Sub11 Effective date: 09-19-2012 17:29 Next update: 09-20-2012 01:49 Revocation List: Serial number Revocation date 10647C84 09-19-2012 17:29 UTCEl certificado del host B (número de serie 10647084) ha sido revocado.
Fragmentación IKEv2
Fragmentación de mensajes
La fragmentación de mensajes IKEv2, como se describe en RFC 7383, Fragmentación de mensajes del Protocolo de intercambio de claves por Internet versión 2 (IKEv2), permite que IKEv2 funcione en entornos donde los fragmentos de IP podrían estar bloqueados y los pares no podrían establecer una asociación de seguridad (SA) IPsec. La fragmentación de IKEv2 divide un mensaje IKEv2 grande en un conjunto de mensajes más pequeños para que no haya fragmentación en el nivel de IP. La fragmentación tiene lugar antes de cifrar y autenticar el mensaje original, de modo que cada fragmento se cifra y autentica por separado. En el receptor, los fragmentos se recopilan, verifican, descifran y fusionan en el mensaje original.
Para que se produzca la fragmentación de IKEv2, ambas VPN del mismo nivel deben indicar la compatibilidad con la fragmentación mediante la inclusión de la carga de notificación IKEV2_FRAGMENTATION_SUPPORTED en el intercambio IKE_SA_INIT. Si ambos pares indican compatibilidad con la fragmentación, corresponde al iniciador del intercambio de mensajes determinar si se utiliza o no la fragmentación de IKEv2.
En los firewalls de la serie SRX, se permite un máximo de 32 fragmentos por mensaje IKEv2. Si el número de fragmentos de mensaje IKEv2 que se enviarán o recibirán supera los 32, los fragmentos se eliminarán y el túnel no se establecerá. No se admite la retransmisión de fragmentos de mensajes individuales
Configuración
En los firewalls de la serie SRX, la fragmentación IKEv2 está habilitada de forma predeterminada para los mensajes IPv4 e IPv6. Para deshabilitar la fragmentación de IKEv2, utilice la disable instrucción en el nivel de jerarquía [edit security ike gateway gateway-name fragmentation]. También puede utilizar la size instrucción para configurar el tamaño del paquete en el que se fragmentan los mensajes; el tamaño del paquete oscila entre 500 y 1300 bytes. Si size no está configurado, el tamaño predeterminado del paquete es 576 bytes para el tráfico IPv4 y 1280 bytes para el tráfico IPv6. Un paquete IKEv2 mayor que el tamaño de paquete configurado está fragmentado.
Después de deshabilitar o habilitar la fragmentación de IKEv2 o cambiar el tamaño del fragmento de paquete, los túneles VPN alojados en la puerta de enlace de IKE se desactivan y las SA de IKE e IPsec se renegocian.
Advertencias
Las siguientes características no son compatibles con la fragmentación de IKEv2:
Descubrimiento de MTU de ruta.
SNMP.
Consulte también
Política de IKE con una CA de confianza
En este ejemplo se muestra cómo enlazar un servidor de CA de confianza a una política IKE del mismo nivel.
Antes de comenzar, debe tener una lista de todas las CA de confianza que desea asociar a la directiva IKE del par.
Puede asociar una política de IKE a un único perfil de CA de confianza o a un grupo de CA de confianza. Para establecer una conexión segura, la puerta de enlace de IKE utiliza la política de IKE para limitarse al grupo configurado de CA (perfiles de ca) mientras valida el certificado. No se valida un certificado emitido por cualquier origen que no sea la CA o el grupo de CA de confianza. Si hay una solicitud de validación de certificado procedente de una política de IKE, el perfil de CA asociado de la política de IKE validará el certificado. Si una política de IKE no está asociada a ninguna CA, cualquiera de los perfiles de CA configurados valida el certificado de forma predeterminada.
En este ejemplo, se crea un perfil de CA denominado root-ca y se asocia a un root-ca-identity perfil.
Puede configurar un máximo de 20 perfiles de CA que desee agregar a un grupo de CA de confianza. No puede confirmar su configuración si configura más de 20 perfiles de CA en un grupo de CA de confianza.
Para ver los perfiles de CA y los grupos de CA de confianza configurados en su dispositivo, ejecute show security pki comando.
user@host# show security ike
proposal ike_prop {
authentication-method rsa-signatures;
dh-group group2;
authentication-algorithm sha-256;
encryption-algorithm aes-256-cbc;
}
policy ike_policy {
proposals ike_prop;
certificate {
local-certificate SPOKE;
trusted-ca ca-profile root-ca;
}
}
El show security ike comando muestra el grupo de perfiles de CA bajo la política de IKE denominada ike_policy y el certificado asociado a la política de IKE.
Consulte también
Configuración de Establish-Tunnel Responder-only en IKE
En este tema se muestra cómo configurar túneles establecidos de solo respuesta en Intercambio de claves por Internet (IKE). Inicie los túneles desde el par remoto y envíe el tráfico a través de todos los túneles. Especifica cuándo se activa IKE.
A partir de Junos OS versión 19.1R1, en SRX5000 línea, la opción establecer túneles admite los responder-only valores y responder-only-no-rekey bajo el [edit security ipsec vpn vpn-name] nivel de jerarquía.
Las responder-only opciones y responder-only-no-rekey se admiten en la línea SRX5000 con una tarjeta SPC3 sólo si está junos-ike-package instalada. Estas opciones solo se admiten en una VPN de sitio a sitio. Estas opciones no son compatibles con Auto VPN.
Las responder-only opciones y responder-only-no-rekey no establecen ningún túnel VPN desde el dispositivo, por lo que el túnel VPN se inicia desde el par remoto. Cuando se configura responder-only, un túnel establecido vuelve a definir la clave de IKE e IPsec en función de los valores de duración de IKE e IPsec configurados. Cuando se configura responder-only-no-rekey, un túnel establecido no vuelve a crear la clave desde el dispositivo y depende del par remoto para iniciar la nueva clave. Si el par remoto no inicia la reclave, el desmontaje del túnel se produce después de que expire la vida útil.
Antes de empezar:
Comprender cómo establecer un túnel IPsec de IKE de clave automática. Leer Información general sobre IPsec.
Para configurar el respondedor de túnel establecido solo en IKE:
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.