Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Supervisión del tráfico VPN

La supervisión de VPN permite determinar la accesibilidad de los dispositivos del mismo nivel mediante el envío de solicitudes del 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 firewall virtual vSRX.

set security log cache

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

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

  • Authentication failures: puede configurar el dispositivo para que genere una alarma del sistema cuando el error de autenticación de paquetes alcance un número especificado.

  • Encryption and decryption failures: puede configurar el dispositivo para que genere una alarma del sistema cuando los errores de cifrado o descifrado superen un número especificado.

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

  • Self-test failures—Las autopruebas son pruebas de que un dispositivo se ejecuta al encenderse o reiniciarse para verificar si el software de seguridad se implementa correctamente en el dispositivo.

    Las autopruebas garantizan la corrección de los algoritmos criptográficos. La imagen Junos-FIPS realiza autopruebas automáticamente al encenderse y de forma continua para la generación de pares de claves. En imágenes domésticas o FIPS, las autopruebas se pueden configurar para que se realicen de acuerdo con un cronograma 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 produzca un error de autocomprobación.

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

  • Replay attacks—Un ataque de reproducción es un ataque a la 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 que genere una alarma del sistema cuando se produzca un ataque de reproducción.

Los mensajes syslog se incluyen en los siguientes casos:

  • Error en la generación de claves simétricas

  • Error en la generación de claves asimétricas

  • Error en la distribución manual de claves

  • Error en la distribución automatizada de claves

  • Error en la destrucción de claves

  • Error en el manejo y almacenamiento de claves

  • Error en el cifrado o descifrado de datos

  • Firma fallida

  • Acuerdo de clave fallido

  • Hash criptográfico fallido

  • Error de IKE

  • Error al autenticar los paquetes recibidos

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

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

Las alarmas se generan en función de los mensajes syslog. Todos los fallos se registran, pero solo se genera una alarma cuando se alcanza un umbral.

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

Después de 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 comando.clear security alarms

Descripción de los métodos de supervisión de VPN

Read this topic to understand multiple ways in which you can monitor VPN tunnels in SRX Series Firewalls.

Monitorear las VPN es una necesidad, ya que la mayoría de los servicios críticos de su negocio se ejecutan en estos túneles VPN. Esperaríamos que los túneles VPN funcionen de manera óptima todo el tiempo. Pero no es el caso en un escenario del mundo real. Un túnel VPN puede estar inactivo debido a múltiples razones. Por ejemplo, el par IKE puede ser inaccesible, la VPN subyacente puede estar inactiva, el túnel puede estar aleteando y varias otras razones. Junos OS soluciona estos problemas.

Descripción de la detección de pares inactivos

La detección de pares inactivos (DPD) es un protocolo basado en estándares que utiliza el tráfico de red para detectar la vida de un par IKE en una conexión IPsec. Durante la creación del túnel IPsec, los pares de VPN negocian para decidir si usar el método DPD o no. Si los pares aceptan usar el protocolo DPD, el firewall comprueba activamente la vida del par. Cuando no hay tráfico activo, el firewall envía mensajes periódicos al par y espera una respuesta. Si el par no responde a los mensajes, el firewall asume que el par ya no está disponible. El comportamiento del protocolo DPD es el mismo para los protocolos IKEv1 e IKEv2. Los temporizadores DPD se activan tan pronto como el firewall establece la asociación de seguridad (SA) de fase 1 de IKE. Los firewalls de la serie SRX utilizan el protocolo DPD para detectar la vida del mismo nivel en una conexión VPN IPsec.

Figura 1: Intercambio de mensajes en protocolo DPDIntercambio de mensajes en protocolo DPD

Figura 1 muestra el intercambio de mensajes DPD entre los pares IKE en un túnel VPN IPsec. Los siguientes eventos se producen cuando el dispositivo realiza DPD:

  1. SRX-A espera hasta el intervalo DPD especificado para comprobar si ha recibido algún tráfico del par, SRX-B.

  2. Si SRX-A no recibe ningún tráfico de SRX-B durante el intervalo de DPD especificado, envía una carga de notificación de fase 1 de IKE cifrada (un mensaje R-U-THERE) a SRX-B.

  3. SRX-A espera el acuse de recibo del DPD, un mensaje R-U-THERE-ACK, de SRX-B.

    1. Si SRX-A recibe un mensaje R-U-THERE-ACK de SRX-B durante este intervalo, considera que el par está vivo. A continuación, SRX-A restablece su contador de mensajes R-U-THERE para ese túnel e inicia un nuevo intervalo.

    2. Si SRX-A no recibe un mensaje R-U-THERE-ACK durante el intervalo, considera que el par, SRX-B, está inactivo. A continuación, SRX-A elimina la SA de fase 1 y todas las SA de fase 2 para ese par.

Veamos qué parámetros DPD necesitará configurar:

  • Modo: en función de la actividad del tráfico, puede configurar DPD en uno de los siguientes modos:

    • Optimizado: en el modo optimizado , cuando el dispositivo iniciador envía paquetes salientes al par, si no hay tráfico IKE o IPsec entrante del par dentro del intervalo configurado, el dispositivo iniciador activa mensajes R-U-THERE. DPD funciona en este modo predeterminado a menos que especifique un modo a través de la configuración.

    • Túnel inactivo de sondeo: en el modo de túnel inactivo de sondeo , el dispositivo activa mensajes R-U-THERE si no hay tráfico IKE o IPsec entrante o saliente dentro de un intervalo configurado. El dispositivo envía mensajes R-U-THERE periódicamente al par hasta que haya actividad de tráfico. Este modo ayuda en la detección temprana de un par que está inactivo, lo que garantiza la disponibilidad del túnel durante el flujo de tráfico activo.



      Nota:

      Si ha configurado varios selectores de tráfico para una VPN, puede establecer varios túneles para la misma SA de IKE. En este escenario, cuando se configura el modo de túnel inactivo de sondeo, se activan mensajes R-U-THERE si un túnel queda inactivo, independientemente del tráfico de otro túnel para la misma SA de IKE.

    • Siempre enviar: en el modo de envío continuo, el dispositivo envía mensajes R-U-THERE en un intervalo configurado, independientemente de la actividad de tráfico entre los pares. Le recomendamos que prefiera utilizar el modo de túnel inactivo de sondeo en lugar del modo de envío continuo .

  • Intervalo: utilice el parámetro interval para especificar la cantidad de tiempo (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, hemos reducido el intervalo de parámetros de intervalo permitido en el que se envían los mensajes R-U-THERE al dispositivo emparejado de 10 segundos a 60 segundos a 2 segundos a 60 segundos. Se recomienda establecer el parámetro de umbral mínimo en 3, cuando el parámetro de intervalo DPD se establece en menos de 10 segundos.

  • Umbral: utilice el parámetro threshold para especificar el número máximo de veces que el dispositivo envía el mensaje R-U-THERE sin recibir una respuesta del par, antes de considerar que el par está inactivo. El número predeterminado de transmisiones es cinco, con un rango permitido de 1 a 5 reintentos.

Tenga en cuenta las siguientes consideraciones antes de configurar DPD:

  • Después de agregar la configuración de DPD a una puerta de enlace existente con túneles activos, el dispositivo comienza a activar mensajes R-U-THERE sin borrar las SA de fase 1 o fase 2.

  • Cuando elimina la configuración de DPD de una puerta de enlace existente con túneles activos, el dispositivo deja de activar mensajes R-U-THERE para los túneles. Pero esto no afecta a las SA de IKE e IPsec.

  • Cuando se modifican parámetros de configuración de DPD, como valores de modo, intervalo o umbral, IKE actualiza la operación de DPD sin borrar las SA de fase 1 o fase 2.

  • Si configura la puerta de enlace de IKE con supervisión de DPD y VPN sin especificar la opción de establecer túneles inmediatamente, IKE no iniciará la negociación de fase 1. Al configurar DPD, también debe configurar la opción en el nivel de jerarquía [] para desactivar la interfaz st0 cuando no haya ninguna SA de fase 1 y fase 2 disponible.establish-tunnelsimmediatelyedit services ipsec-vpn Consulte Establecer túneles inmediatamente.https://www.juniper.net/documentation/us/en/software/junos/interfaces-adaptive-services/topics/ref/statement/establish-tunnels-edit-services-ipsec-vpn.html

  • Si configura la puerta de enlace de IKE con varias direcciones IP del mismo nivel y DPD, pero no logra establecer la SA de fase 1 con la primera dirección IP del mismo nivel, IKE intenta establecerse con la siguiente dirección IP del mismo nivel. DPD solo se activa después de que IKE establezca SA de fase 1. Consulte dead-peer-detection.https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/ref/statement/security-edit-dead-peer-detection.html

  • Si configura una puerta de enlace IKE con varias direcciones IP del mismo nivel y DPD, pero la conexión falla con la dirección IP del par actual, IKE borra las SA de fase 1 y fase 2 y DPD realiza una conmutación por error a la siguiente dirección IP del mismo nivel. Consulte puerta de enlace (IKE de seguridad).https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/ref/statement/security-edit-gateway-ike.html

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

Nota:

Para obtener más información acerca de la implementación de DPD, consulte RFC 3706, Un método basado en el tráfico para detectar pares muertos de intercambio de claves por Internet (IKE).

Si el par IKE está activo, ¿significa que la VPN subyacente está activa?

Consejo:

Piense si DPD garantiza la funcionalidad de SA IPsec.

Descripción de la supervisión de VPN

Aunque el protocolo de detección de pares inactivos (DPD) comprueba la vida de un par IKE, no garantiza la vida de la VPN subyacente. No existe un método basado en estándares para comprobar si la VPN subyacente está activa. La supervisión de VPN es un mecanismo de Junos OS para comprobar la funcionalidad de una asociación de seguridad (SA) IPsec. La supervisión de VPN utiliza solicitudes de eco (o pings) del Protocolo de mensajes de control de Internet (ICMP) y datos de firma, como el ID de túnel, en el paquete ICMP para determinar si el túnel VPN está activo.

Cuando se habilita la supervisión de VPN, el dispositivo envía pings a través del túnel VPN a la puerta de enlace del mismo nivel o a un destino especificado en el otro extremo del túnel. El dispositivo envía pings de forma predeterminada a intervalos de 10 segundos durante un máximo de 10 veces consecutivas. Si el dispositivo no recibe ninguna respuesta después de 10 pings consecutivos, considera que la VPN está inactiva y la asociación de seguridad (SA) IPsec se borra.

El monitoreo de DPD y VPN se complementan entre sí. La supervisión de VPN se aplica a una VPN IPsec individual, mientras que DPD se configura en un contexto de puerta de enlace IKE individual.

Puede utilizar los siguientes modos de funcionamiento para supervisar túneles VPN:

  • Modo de envío permanente: en este modo, el dispositivo envía un paquete de supervisión VPN una vez en cada intervalo configurado, independientemente del tráfico en el túnel. Después de habilitar la supervisión VPN, Junos OS utiliza el modo de envío permanente como modo predeterminado si no especifica uno.

  • Modo optimizado: en este modo, el dispositivo envía un paquete de supervisión VPN una vez cada intervalo configurado solo si hay tráfico saliente y no hay tráfico entrante a través del túnel durante el intervalo. Si hay tráfico entrante a través del túnel VPN, el dispositivo considera que el túnel está activo y no envía pings al par. Puede usar el modo optimizado para ahorrar recursos en el dispositivo, ya que en este modo el dispositivo envía pings solo cuando necesita determinarla vida del par. El envío de pings también puede activar costosos enlaces de copia de seguridad que de otro modo no se utilizarían. El dispositivo funciona en el modo predeterminado de envío permanente si no configura el modo optimizado explícitamente.

Para configurar la supervisión de VPN en los firewalls de la serie SRX:

  1. Active la supervisión de VPN para un túnel VPN específico incluyendo la opción en el nivel de jerarquía [].vpn-monitoredit security ipsec vpn vpn-name Consulte vpn-monitor.https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/ref/statement/security-edit-vpn-monitor.html

  2. Configure el modo de supervisión VPN como optimizado.

  3. Especifique la dirección IP de destino. La dirección IP de la puerta de enlace del par es el destino predeterminado; sin embargo, puede especificar una dirección IP de destino diferente (como la de un servidor) que se encuentre al otro extremo del túnel.

  4. Especifique la dirección.source-interface El extremo del túnel local es la interfaz de origen predeterminada, pero puede especificar un nombre de interfaz diferente.

  5. Configure el intervalo en el que el dispositivo envía los pings y el número de pings consecutivos que envía con las opciones y , respectivamente, en el nivel de jerarquía [].intervalthresholdedit security ipsec vpn-monitor-options Si no configura estas opciones, el dispositivo envía pings en el intervalo predeterminado de 10 segundos hasta 10 veces consecutivas. Si no recibe una respuesta, considera que la VPN está inactiva. A continuación, el dispositivo borra la asociación de seguridad IPsec.

Nota:

Los firewalls SRX5400, SRX5600 y SRX5800 no admiten la supervisión VPN de un dispositivo conectado externamente (como un PC). En estos dispositivos, eldestino de la supervisión de VPN debe ser una interfaz local.

Precaución:

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

Descripción de la comprobación de rutas 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 ruta se basa en el estado del túnel VPN. Poco después de establecer la SA 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 extremos 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 provocar la pérdida de tráfico.

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

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

A partir de Junos OS versión 15.1X49-D120, puede configurar el tamaño del paquete que se utiliza para comprobar una ruta de datos IPsec antes de que se abra la interfaz.st0 Utilice la configuración.set security ipsec vpn vpn-name vpn-monitor verify-path packet-size El tamaño del paquete configurable varía de 64 a 1350 bytes; El valor predeterminado es 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 comprobación de la ruta de datos de IPsec. El origen de las solicitudes ICMP en la comprobación de ruta de datos IPsec es el extremo del túnel local.

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

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

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

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

Descripción de las características globales de monitoreo de SPI y VPN

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

  • SPI: los pares de una asociación de seguridad (SA) pueden dejar de sincronizarse cuando falla uno de los pares. Por ejemplo, si uno de los pares se reinicia, podría enviar un índice de parámetros de seguridad (SPI) incorrecto. Puede habilitar el dispositivo para que detecte dicho evento y volver a sincronizar los pares configurando la función de respuesta SPI incorrecta.

  • Supervisión de VPN: puede utilizar la función de supervisión global de VPN para enviar periódicamente solicitudes del Protocolo de mensajes de control de Internet (ICMP) al par para determinar si es posible comunicarse con él.

Comparación de la supervisión de VPN y DPD

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

El firewall 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 firewall de la serie SRX para iniciar mensajes DPD en pares VPN. También puede configurar la supervisión de DPD y VPN para que funcione simultáneamente en el mismo firewall de la serie SRX, aunque se reduce el número de pares que se pueden supervisar con cualquiera de los métodos.

La supervisión de VPN es un mecanismo de Junos OS que supervisa solo las asociaciones de seguridad (SA) de fase 2. La supervisión de VPN se habilita por VPN con la instrucción en el nivel de jerarquía [].vpn-monitoredit security ipsec vpn vpn-name Se debe especificar la IP de destino y la interfaz de origen. La opción permite que el dispositivo use patrones de tráfico como evidencia de la vivacidad del mismo nivel; Se suprimen las solicitudes ICMP.optimized

Las opciones de supervisión de VPN se configuran con la instrucción en el nivel de jerarquía [].vpn-monitor-optionsedit security ipsec Estas opciones se aplican a todas las VPN para las que está habilitada la supervisión de VPN. Las opciones que puede configurar incluyen el intervalo en el que se envían las 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 el tráfico para detectar pares muertos de intercambio de claves por Internet (IKE). Funciona en el nivel de IKE y supervisa el par en función de la actividad de tráfico de IKE e IPsec.

DPD se configura en una puerta de enlace IKE individual con la instrucción en el nivel de jerarquía [].dead-peer-detectionedit security ike gateway gateway-name Puede configurar los modos de operación 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 los 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 los eventos de túnel

Cuando hay un problema de red relacionado con una VPN, después de que aparece el túnel, solo se rastrea el estado del túnel. Pueden ocurrir muchos problemas antes de que aparezca el túnel. Por lo tanto, en lugar de rastrear solo el estado del túnel, los problemas de túnel o los errores de negociación, ahora se realiza un seguimiento de eventos exitosos como negociaciones exitosas de SA IPsec, reclave de IPsec y reclaves de SA de IKE. Estos eventos se denominan eventos de túnel.

Para la fase 1 y la fase 2, los eventos de negociación para un túnel determinado se rastrean junto con los eventos que ocurren en demonios externos como AUTHD o PKID. Cuando se produce un evento de túnel varias veces, solo se mantiene una entrada con la hora actualizada y el número de veces que se produjo ese evento.

En total, se realiza un seguimiento de 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 de eventos, lo que resulta en la eliminación de eventos importantes. Para evitar la sobrescritura, un evento no se almacena a menos que un túnel esté inactivo.

Los siguientes eventos especiales entran en esta categoría:

  • Duración en kilobytes caducada para SA IPsec

  • La duración dura de IPsec SA expiró

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

  • Pares de IPsec SA de copia de seguridad redundantes no utilizados borrados

  • SA IPsec borradas como SA de IKE correspondientes eliminadas

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 con ningún túnel, por lo que el registro del sistema se utiliza para la depuración en su lugar.

Ejemplo: Configurar una notificación de alerta sonora

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 audibles. Esta función se admite en dispositivos SRX300, SRX320, SRX340, SRX345, SRX550HM y SRX1500 e instancias de firewall virtual vSRX.

Requisitos

No se necesita 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, configura un pitido audible para que se genere en respuesta a una alarma de seguridad.

Configuración

Procedimiento

Procedimiento paso a paso

Para configurar una alarma sonora:

  1. Active las alarmas de seguridad.

  2. Especifique que desea recibir notificaciones de las alarmas de seguridad con un pitido audible.

  3. Cuando termine de configurar el dispositivo, confirme la configuración.

Verificación

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

Ejemplo: Configurar la generación de alarmas de seguridad

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 activa 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 firewall virtual vSRX.

Requisitos

No se necesita 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, se configura una alarma para que se active cuando:

  • El número de errores de autenticación supera los 6.

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

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

  • Se produce un error en la autocomprobación de generación de claves.

  • El número de errores de cifrado supera los 10.

  • El número de errores de descifrado supera 1.

  • El número de errores de fase 1 de IKE supera los 10.

  • El número de errores de fase 2 de IKE supera 1.

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

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 hacerlo, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI de Junos OS.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

Para configurar alarmas en respuesta a posibles infracciones:

  1. Active las alarmas de seguridad.

  2. Especifique que se debe activar una alarma cuando se produzca un error de autenticación.

  3. Especifique que se debe activar una alarma cuando se produzca un error de autocomprobación criptográfica.

  4. Especifique que se debe activar una alarma cuando se produzca un error de autocomprobación no criptográfica.

  5. Especifique que se debe activar una alarma cuando se produzca un error de autocomprobación de generación de claves.

  6. Especifique que se debe activar una alarma cuando se produzca un error de cifrado.

  7. Especifique que se debe activar una alarma cuando se produzca un error de descifrado.

  8. Especifique que se debe activar una alarma cuando se produzca un error de fase 1 de IKE.

  9. Especifique que se debe activar una alarma cuando se produzca un fallo de fase 2 de IKE.

  10. Especifique que se debe activar una alarma cuando se produzca un ataque de repetición.

Resultados

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

Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.

Verificación

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

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.

Liberación
Descripción
15.1X49-D130
A partir de Junos OS versión 15.1X49-D130, el intervalo de parámetros de intervalo permitido en el que se envían mensajes R-U-THERE al dispositivo emparejado 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 utiliza para comprobar una ruta de datos IPsec antes de que se abra la interfaz.st0