Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Monitoreo del tráfico VPN

La supervisión de VPN le permite determinar la accesibilidad de los dispositivos par mediante el envío de solicitudes de protocolo de mensajes de control de Internet (ICMP) a los pares.

Descripción de las alarmas vpn y la auditoría

Configure el siguiente comando para habilitar el registro de eventos de seguridad durante la configuración inicial del dispositivo. Esta función se admite en dispositivos SRX300, SRX320, SRX340, SRX345, SRX550HM y SRX1500 e instancias de vSRX.

set security log cache

Los administradores (auditoría, criptografía, IDS y seguridad) no pueden modificar la configuración de registro de eventos de seguridad si el comando anterior está configurado y cada rol de administrador está configurado para tener un conjunto de privilegios distinto y único, aparte de todos los demás roles administrativos.

Las alarmas se activan por una falla de VPN. Se genera una alarma VPN cuando el sistema monitorea cualquiera de los siguientes eventos auditados:

  • Authentication failures: puede configurar el dispositivo para generar una alarma del sistema cuando las fallas de autenticación de paquetes alcancen un número especificado.

  • Encryption and decryption failures: puede configurar el dispositivo para generar una alarma del sistema cuando las fallas de cifrado o descifrado superen un número especificado.

  • IKE Phase 1 and IKE Phase 2 failures— Las negociaciones de fase 1 del intercambio de claves por red (IKE) se utilizan para establecer asociaciones de seguridad ICR (SA). Estas SA protegen las negociaciones de fase 2 de ICR. Puede configurar el dispositivo para generar una alarma del sistema cuando las fallas de fase 1 o fase 2 de IKE superen un número especificado.

  • Self-test failures: las pruebas automáticas son pruebas de que un dispositivo se ejecuta al encender o reiniciar para comprobar si el software de seguridad se implementa correctamente en el dispositivo.

    Las pruebas automáticas garantizan la corrección de los algoritmos criptográficos. La imagen de Junos-FIPS realiza auto pruebas de forma automática al encenderse y de forma continua para la generación de pares de claves. En imágenes nacionales o FIPS, se pueden configurar auto pruebas para que se realicen de acuerdo con un programa definido, a pedido o inmediatamente después de la generación de claves.

    Puede configurar el dispositivo para generar una alarma del sistema cuando se produce una falla de auto prueba.

  • IDP flow policy attacks— Una política de detección y prevención de intrusiones (IDP) le permite aplicar varias técnicas de detección y prevención de ataques en el tráfico de red. Puede configurar el dispositivo para generar una alarma del sistema cuando se producen violaciones de la política de flujo IDP.

  • Replay attacks: un ataque de reproducción es un ataque de red en el que una transmisión de datos válida se repite o retrasa de forma maliciosa o fraudulenta. Puede configurar el dispositivo para generar una alarma del sistema cuando se produce un ataque de reproducción.

Los mensajes syslog se incluyen en los siguientes casos:

  • Generación de claves simétricas fallidas

  • Generación de claves asimétricas errónea

  • Distribución manual de claves fallida

  • Distribución de claves automatizada fallida

  • Destrucción de claves fallida

  • Manipulación y almacenamiento de claves fallidos

  • Cifrado o descifrado de datos con errores

  • Firma con errores

  • Acuerdo clave fallido

  • Hash criptográfico fallido

  • Falla de ICR

  • Error en la autenticación de los paquetes recibidos

  • Error de descifrado debido al contenido de relleno no válido

  • Discordancia en la longitud especificada en el campo de asunto alternativo del certificado recibido de un dispositivo par VPN remoto.

Las alarmas se emiten en función de los mensajes syslog. Cada error se registra, pero solo se genera una alarma cuando se alcanza un umbral.

Para ver la información de alarma, ejecute el show security alarms comando. El recuento de violaciones y la alarma no persisten en los reinicios del sistema. Después de un reinicio, el recuento de violaciones se restablece a cero y la alarma se borra de la cola de alarmas.

Una vez que se hayan tomado las medidas adecuadas, puede borrar la alarma. La alarma permanece en la cola hasta que la desactive (o hasta que reinicie el dispositivo). Para borrar la alarma, ejecute el clear security alarms comando.

Descripción de la supervisión de VPN

La supervisión de VPN utiliza solicitudes de eco ICMP (o pings) para determinar si un túnel VPN está activo. Cuando se habilita la supervisión de VPN, el dispositivo de seguridad envía pings a través del túnel VPN a la puerta de enlace par o a un destino especificado en el otro extremo del túnel. Los pings se envían de forma predeterminada a intervalos de 10 segundos durante hasta 10 veces consecutivas. Si no se recibe ninguna respuesta después de 10 pings consecutivos, se considera que la VPN está inactiva y se borra la asociación de seguridad IPsec (SA).

La supervisión de VPN se habilita para una VPN especificada mediante la configuración de la vpn-monitor opción en el nivel de jerarquía [edit security ipsec vpn vpn-name]. La dirección IP de la puerta de enlace par es el destino predeterminado; sin embargo, puede especificar una dirección IP de destino diferente (como un servidor) en el otro extremo del túnel. El punto de conexión de túnel local es la interfaz de origen predeterminada, pero puede especificar un nombre de interfaz diferente.

La supervisión VPN de un dispositivo conectado externamente (como una PC) no se admite en dispositivos SRX5400, SRX5600 y SRX5800. El destino para la supervisión de VPN debe ser una interfaz local en el dispositivo SRX5400, SRX5600 o SRX5800.

La opción de supervisión optimized de VPN envía pings solo cuando hay tráfico saliente y no hay tráfico entrante a través del túnel VPN. Si hay tráfico entrante a través del túnel VPN, el dispositivo de seguridad considera que el túnel está activo y no envía pings al par. Configurar la optimized opción puede guardar recursos en el dispositivo de seguridad, ya que los pings solo se envían cuando se debe determinar la vida de los pares. El envío de pings también puede activar costosos vínculos de respaldo que, de lo contrario, no se usarían.

Puede configurar el intervalo en el que se envían los pings y el número de pings consecutivos que se envían sin una respuesta antes de que la VPN se considere inactiva. Estos se configuran con las interval opciones y threshold , respectivamente, en el nivel de jerarquía [edit security ipsec vpn-monitor-options].

La supervisión de VPN puede provocar un aleteo de túnel en algunos entornos VPN si el par no acepta paquetes ping según la dirección IP de origen o destino del paquete.

Descripción de la verificación de ruta de datos IPsec

Descripción general

De forma predeterminada, el estado de las interfaces de túnel seguro (st0) configuradas en modo punto a punto en VPN basadas en rutas se basa en el estado del túnel VPN. Poco después de establecer la SA de IPsec, las rutas asociadas con la interfaz st0 se instalan en la tabla de reenvío de Junos OS. En ciertas topologías de red, como cuando se encuentra un firewall de tránsito entre los puntos de conexión del túnel VPN, el firewall de tránsito puede bloquear el tráfico de datos IPsec que usa rutas activas para un túnel VPN establecido en la interfaz st0. Esto puede dar lugar a pérdidas de tráfico.

Cuando habilita la verificación de ruta de datos IPsec, la interfaz st0 no se activa ni se activa hasta que se verifica la ruta de datos. La verificación se configura con la set security ipsec vpn vpn-name vpn-monitor verify-path instrucción para túneles VPN de punto de conexión dinámicos, de sitio a sitio y basados en rutas.

Si hay un dispositivo TDR delante del punto de conexión del túnel par, la dirección IP del punto de conexión del túnel par se traduce a la dirección IP del dispositivo TDR. Para que la solicitud ICMP del monitor VPN llegue al punto de conexión del túnel del par, debe especificar explícitamente la dirección IP original y sin traducción del punto de conexión del túnel del par detrás del dispositivo TDR. Esto se configura con la set security ipsec vpn vpn-name vpn-monitor verify-path destination-ip configuración.

A partir de Junos OS versión 15.1X49-D120, puede configurar el tamaño del paquete que se usa para comprobar una ruta de datos IPsec antes de que se configure la st0 interfaz. Use la set security ipsec vpn vpn-name vpn-monitor verify-path packet-size configuración. El tamaño de paquete configurable varía de 64 a 1350 bytes; el valor predeterminado es de 64 bytes.

Advertencias

La interfaz de origen y las direcciones IP de destino que se pueden configurar para la operación del monitor VPN no tienen ningún efecto en la verificación de ruta de datos IPsec. El origen de las solicitudes ICMP en la verificación de ruta de datos IPsec es el punto de conexión de túnel local.

Cuando habilita la verificación de ruta de datos IPsec, la supervisión de VPN se activa automáticamente y se utiliza después de que se presenta la interfaz st0. Recomendamos que configure la opción optimizada de monitor VPN con el comando siempre que habilite la set security ipsec vpn vpn-name vpn-monitor optimized verificación de ruta de datos IPsec.

Si se produce una conmutación por error de clúster de chasis durante la verificación de ruta de datos IPsec, el nuevo nodo activo inicia de nuevo la verificación. La interfaz st0 no se activa hasta que la verificación se realice correctamente.

No se realiza ninguna verificación de ruta de datos IPsec para las reclaves de SA de IPsec, ya que el estado de la interfaz st0 no cambia para las reclaves.

La verificación de ruta de datos IPsec no se admite en interfaces st0 configuradas en modo punto a multipunto que se utilizan con AutoVPN, VPN de detección automática y varios selectores de tráfico. La supervisión de VPN y la verificación de ruta de datos IPsec no admiten direcciones IPv6, por lo que la verificación de ruta de datos IPsec no se puede utilizar con túneles IPv6.

Descripción de las funciones globales de supervisión de SPI y VPN

Puede supervisar y mantener el funcionamiento eficiente de su VPN mediante las siguientes funciones globales de VPN:

  • SPI: los pares en una asociación de seguridad (SA) pueden no estar sincronizados cuando uno de los pares falla. Por ejemplo, si uno de los pares se reinicia, puede enviar un índice de parámetros de seguridad (SPI) incorrecto. Puede habilitar el dispositivo para detectar dicho evento y resincronizar los pares mediante la configuración de la función de respuesta SPI errónea.

  • Supervisión de VPN: puede usar la función de supervisión vpn global para enviar periódicamente solicitudes de protocolo de mensajes de control de Internet (ICMP) al par para determinar si el par es accesible.

Descripción de la supervisión de VPN y el DPD

La supervisión de VPN y la detección de pares muertos (DPD) son funciones disponibles en dispositivos de la serie SRX para verificar la disponibilidad de dispositivos par VPN. En esta sección se compara la operación y la configuración de estas características.

El dispositivo de la serie SRX responde a los mensajes DPD enviados por pares vpn, incluso si DPD no está configurado en el dispositivo. Puede configurar el dispositivo de la serie SRX para iniciar mensajes DPD a pares VPN. También puede configurar la supervisión de DPD y VPN para que funcione simultáneamente en el mismo dispositivo de la serie SRX, aunque se reduce la cantidad de pares que se pueden supervisar con cualquiera de los métodos.

La supervisión de VPN es un mecanismo de Junos OS que monitorea solo las asociaciones de seguridad (SA) de fase 2. La supervisión de VPN se habilita por VPN con la vpn-monitor instrucción en el nivel de jerarquía [edit security ipsec vpn vpn-name]. Debe especificarse la IP de destino y la interfaz de origen. La optimized opción permite que el dispositivo use patrones de tráfico como evidencia de la vida de los pares; Las solicitudes ICMP se suprimen.

Las opciones de supervisión de VPN se configuran con la vpn-monitor-options instrucción en el nivel de jerarquía [edit security ipsec]. Estas opciones se aplican a todas las VPN para las que está habilitada la supervisión vpn. Las opciones que puede configurar incluyen el intervalo en el que se envían solicitudes ICMP al par (el valor predeterminado es 10 segundos) y el número de solicitudes ICMP consecutivas enviadas sin recibir una respuesta antes de que el par se considere inalcanzable (el valor predeterminado es 10 solicitudes consecutivas).

DPD es una implementación de RFC 3706, un método basado en tráfico para detectar pares muertos de intercambio de claves por internet (IKE). Opera en el nivel de IKE y monitorea al par según la actividad de tráfico IKE y IPsec.

El DPD se configura en una puerta de enlace IKE individual con la dead-peer-detection instrucción en el nivel de jerarquía [edit security ike gateway gateway-name]. Puede configurar los modos de operación de DPD. El modo predeterminado (optimizado) envía mensajes DPD al par si no hay tráfico IKE o IPsec entrante dentro de un intervalo configurado después de que el dispositivo local envíe paquetes salientes al par. Otras opciones configurables incluyen el intervalo en el que se envían mensajes DPD al par (el valor predeterminado es 10 segundos) y el número de mensajes DPD consecutivos enviados sin recibir una respuesta antes de que el par se considere no disponible (el valor predeterminado es cinco solicitudes consecutivas).

Descripción de la detección de pares muertos

La detección de pares inactivos (DPD) es un método que utilizan los dispositivos de red para verificar la existencia actual y la disponibilidad de otros dispositivos par.

Puede usar DPD como alternativa a la supervisión de VPN. La supervisión de VPN se aplica a una VPN IPsec individual, mientras que el DPD solo está configurado en un contexto de puerta de enlace de IKE individual.

Un dispositivo realiza la verificación DPD mediante el envío de cargas de notificación de fase 1 de IKE cifradas (mensajes R-U-THERE) a un par y en espera de confirmaciones DPD (mensajes R-U-THERE-ACK) del par. El dispositivo envía un mensaje R-U-THERE solo si no ha recibido ningún tráfico del par durante un intervalo DPD especificado. Si el dispositivo recibe un mensaje R-U-THERE-ACK del par durante este intervalo, considera al par vivo. Si el dispositivo recibe tráfico en el túnel del par, restablece su contador de mensajes R-U-THERE para ese túnel, iniciando así un nuevo intervalo. Si el dispositivo no recibe un mensaje R-U-THERE-ACK durante el intervalo, considera que el par está muerto. Cuando el dispositivo cambia el estado de un dispositivo par para estar inactivo, el dispositivo elimina la asociación de seguridad de fase 1 (SA) y todas las SA de fase 2 para ese par.

Los siguientes modos DPD se admiten en los dispositivos de la serie SRX:

  • Optimizado: los mensajes R-U-THERE se activan si no hay tráfico IKE o IPsec entrante dentro de un intervalo configurado después de que el dispositivo envíe paquetes salientes al par. Este es el modo predeterminado.

  • Túnel de sondeo inactivo: los mensajes R-U-THERE se activan si no hay tráfico IKE o IPsec entrante o saliente dentro de un intervalo configurado. Los mensajes R-U-THERE se envían periódicamente al par hasta que haya actividad de tráfico. Este modo ayuda a la detección temprana de un par caído y hace que el túnel esté disponible para el tráfico de datos.

    Cuando se configuran varios selectores de tráfico para una VPN, se pueden establecer varios túneles para la misma SA de IKE. En este caso, el modo de túnel inactivo del sondeo activa que se envíen mensajes R-U-THERE si cualquier túnel asociado con la SA de IKE se vuelve inactivo, aunque pueda haber tráfico en otro túnel para la misma SA de IKE.

  • Siempre enviar: los mensajes R-U-THERE se envían a intervalos configurados independientemente de la actividad de tráfico entre los pares.

    Recomendamos que se utilice el modo de túnel inactivo del sondeo en lugar del always-send modo.

Los temporizadores DPD están activos tan pronto como se establece la SA de fase 1. El comportamiento del DPD es el mismo para los protocolos IKEv1 y IKEv2.

Puede configurar los siguientes parámetros DPD:

  • El parámetro interval especifica la cantidad de tiempo (expresada en segundos) que el dispositivo espera el tráfico de su par antes de enviar un mensaje R-U-THERE. El intervalo predeterminado es de 10 segundos. A partir de Junos OS versión 15.1X49-D130, el rango de parámetros de intervalo permitido al que se envían mensajes R-U-THERE al dispositivo par se reduce de 10 a 60 segundos a 2 segundos a 60 segundos. El parámetro de umbral mínimo debe ser 3, cuando el parámetro de intervalo DPD se establece en menos de 10 segundos.

  • El parámetro de umbral especifica la cantidad máxima de veces para enviar el mensaje de R-U-THERE sin una respuesta del par antes de considerar el par muerto. El número predeterminado de transmisiones es cinco veces, con un rango permitido de 1 a 5 reintentos.

Tenga en cuenta las siguientes consideraciones antes de configurar DPD:

  • Cuando se agrega una configuración DPD a una puerta de enlace existente con túneles activos, los mensajes R-U-THERE se inician sin borrar las SA de fase 1 o fase 2.

  • Cuando se elimina una configuración DPD de una puerta de enlace existente con túneles activos, se detienen los mensajes de R-U-THERE para los túneles. Las SA ICR e IPsec no se ven afectadas.

  • Modificar cualquier opción de configuración DPD, como el modo, el intervalo o los valores de umbral, actualiza la operación DPD sin borrar los SA de fase 1 o fase 2.

  • Si la puerta de enlace IKE está configurada con monitoreo DPD y VPN, pero la opción de establecer túneles inmediatamente no está configurada, DPD no inicia la negociación de fase 1. Cuando se configura DPD, la opción establecer túneles inmediatamente también se debe configurar al mismo tiempo para derribar la interfaz st0 cuando no hay SA de fase 1 y fase 2 disponibles.

  • Si la puerta de enlace IKE está configurada con varias direcciones IP par y DPD, pero la SA de fase 1 no se puede establecer a la primera dirección IP del par, se intenta una SA de fase 1 con la siguiente dirección IP del par. El DPD solo está activo después de establecer una SA de fase 1.

  • Si la puerta de enlace IKE está configurada con varias direcciones IP par y DPD, pero DPD falla con la dirección IP del par actual, las SA de fase 1 y fase 2 se borran y se activa una conmutación por error a la siguiente dirección IP del par.

  • Puede haber más de una SA de fase 1 o fase 2 con el mismo par debido a negociaciones simultáneas. En este caso, se envían mensajes R-U-THERE en todas las SA de fase 1. Si no se reciben respuestas DPD para el número configurado de veces consecutivas, se borra la SA de fase 1 y la SA de fase 2 asociada (solo para IKEv2).

Descripción de los eventos de túnel

Cuando hay un problema de red relacionado con una VPN, después de que el túnel aparece solo se rastrea el estado del túnel. Muchos problemas pueden ocurrir antes de que surja el túnel. Por lo tanto, en lugar de rastrear solo el estado del túnel, los problemas de tunelización o los errores de negociación, ahora se rastrean los eventos exitosos, como las negociaciones de SA IPsec correctas, la reclave de IPsec y las reclaves de SA de IKE. Estos eventos se denominan eventos de túnel.

Para las fases 1 y 2, los eventos de negociación de un túnel dado se rastrean junto con los eventos que se producen en demonios externos como AUTHD o PKID. Cuando un evento de túnel se produce varias veces, solo se mantiene una entrada con la hora actualizada y la cantidad de veces que se produjo ese evento.

En general, se rastrean 16 eventos: ocho eventos para la fase 1 y ocho eventos para la fase 2. Algunos eventos pueden volver a ocurrir y llenar la memoria del evento, lo que da como resultado que se eliminen eventos importantes. Para evitar la sobreescritura, no se almacena un evento a menos que un túnel esté apagado.

Los siguientes eventos especiales entran en esta categoría:

  • La vida útil en kilobytes expiró para SA de IPsec

  • Dura vida útil de SA IPsec vencida

  • Carga de eliminación de SA IPsec recibida del par, SAs IPsec correspondientes borradas

  • Pares de SA IPsec de copia de seguridad redundantes sin usar despejadas

  • Sa de IPsec eliminada como SA de IKE correspondiente

Los túneles AutoVPN se crean y eliminan dinámicamente y, en consecuencia, los eventos de túnel correspondientes a estos túneles son de corta duración. A veces, estos eventos de túnel no se pueden asociar a ningún túnel, por lo que el registro del sistema se utiliza para la depuración en su lugar.

Ejemplo: Establecer una alerta acústica como notificación de una alarma de seguridad

En este ejemplo, se muestra cómo configurar un dispositivo para generar un pitido de alerta del sistema cuando se produce un nuevo evento de seguridad. De forma predeterminada, las alarmas no son sonoras. Esta función se admite en dispositivos SRX300, SRX320, SRX340, SRX345, SRX550HM y SRX1500 e instancias de vSRX.

Requisitos

No se requiere ninguna configuración especial más allá de la inicialización del dispositivo antes de configurar esta función.

Descripción general

En este ejemplo, establece un pitido acústico para que se genere en respuesta a una alarma de seguridad.

Configuración

Procedimiento

Procedimiento paso a paso

Para configurar una alarma acústica:

  1. Active alarmas de seguridad.

  2. Especifique que desea recibir una notificación de alarmas de seguridad con un pitido acústico.

  3. Si ha terminado de configurar el dispositivo, confirme la configuración.

Verificación

Para comprobar que la configuración funciona correctamente, escriba el show security alarms detail comando.

Ejemplo: Generación de alarmas de seguridad en respuesta a posibles violaciones

En este ejemplo, se muestra cómo configurar el dispositivo para generar una alarma del sistema cuando se produce una posible infracción. De forma predeterminada, no se genera ninguna alarma cuando se produce una posible infracción. Esta función se admite en dispositivos SRX300, SRX320, SRX340, SRX345, SRX550HM y SRX1500 e instancias de vSRX.

Requisitos

No se requiere ninguna configuración especial más allá de la inicialización del dispositivo antes de configurar esta función.

Descripción general

En este ejemplo, configure una alarma para que se active cuando:

  • La cantidad de errores de autenticación supera los 6.

  • Se produce un error en la autoexaprobación criptográfica.

  • Se produce un error en la autoexaprobación no criptográfica.

  • La autoexaprobación de generación de claves falla.

  • La cantidad de errores de cifrado supera los 10.

  • La cantidad de errores de descifrado supera 1.

  • La cantidad de errores de fase 1 de ICR supera los 10.

  • El número de fallas de fase 2 de ICR supera 1.

  • Se produce un ataque de reproducción.

Configuración

Procedimiento

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 y, luego, ingrese commit desde el [edit] modo de configuración.

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.

Para configurar alarmas en respuesta a posibles violaciones:

  1. Active alarmas de seguridad.

  2. Especifique que se debe producir una alarma cuando se produce un error de autenticación.

  3. Especifique que se debe producir una alarma cuando se produce un error de autoemisión criptográfica.

  4. Especifique que se debe producir una alarma cuando se produce un error de autoexaprobación no criptográfica.

  5. Especifique que se debe generar una alarma cuando se produce un error de autoexaperación de generación de claves.

  6. Especifique que se debe producir una alarma cuando se produce una falla de cifrado.

  7. Especifique que se debe producir una alarma cuando se produce una falla de descifrado.

  8. Especifique que se debe producir una alarma cuando se produce una falla de fase 1 de IKE.

  9. Especifique que se debe producir una alarma cuando se produce una falla de fase 2 de IKE.

  10. Especifique que se debe producir una alarma cuando se produce un ataque de reproducción.

Resultados

Desde el modo de configuración, escriba el comando para confirmar la show security alarms configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Verificación

Para confirmar que la configuración funciona correctamente, desde el modo operativo, ingrese el show security alarms comando.

Tabla de historial de versiones
Liberación
Descripción
15.1X49-D130
A partir de Junos OS versión 15.1X49-D130, el rango de parámetros de intervalo permitido al que se envían mensajes R-U-THERE al dispositivo par se reduce de 10 a 60 segundos a 2 segundos a 60 segundos. El parámetro de umbral mínimo debe ser 3, cuando el parámetro de intervalo DPD se establece en menos de 10 segundos.
15.1X49-D120
A partir de Junos OS versión 15.1X49-D120, puede configurar el tamaño del paquete que se usa para comprobar una ruta de datos IPsec antes de que se configure la st0 interfaz.