Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Sur cette page
 

Surveillance du trafic VPN

La surveillance VPN vous permet de déterminer l’accessibilité des appareils homologues en envoyant des requêtes ICMP (Internet Control Message Protocol) aux homologues.

Comprendre les alarmes VPN et l’audit

Configurez la commande suivante pour activer la journalisation des événements de sécurité lors de la configuration initiale de l’appareil. Cette fonctionnalité est prise en charge sur les équipements et Pare-feu virtuel vSRX instances SRX300, SRX320, SRX340, SRX345, SRX550HM et SRX1500.

set security log cache

Les administrateurs (audit, cryptographique, IDS et sécurité) ne peuvent pas modifier la configuration de journalisation des événements de sécurité si la commande ci-dessus est configurée et que chaque rôle d’administrateur est configuré pour disposer d’un ensemble de privilèges distinct et unique de tous les autres rôles administratifs.

Les alarmes sont déclenchées en cas de défaillance du VPN. Une alarme VPN est générée lorsque le système surveille l’un des événements audités suivants :

  • Authentication failures: vous pouvez configurer l’équipement pour qu’il génère une alarme système lorsque les échecs d’authentification des paquets atteignent un nombre spécifié.

  • Encryption and decryption failures: vous pouvez configurer l’appareil pour qu’il génère une alarme système lorsque les échecs de chiffrement ou de déchiffrement dépassent un nombre spécifié.

  • IKE Phase 1 and IKE Phase 2 failures—Les négociations de la phase 1 de l’Internet Key Exchange (IKE) sont utilisées pour établir des associations de sécurité IKE (SA). Ces SA protègent les négociations de phase 2 de l’IKE. Vous pouvez configurer l’appareil pour qu’il génère une alarme système lorsque les défaillances IKE Phase 1 ou IKE Phase 2 dépassent un nombre spécifié.

  • Self-test failuresLes autotests sont des tests qu’un appareil exécute lors de la mise sous tension ou au redémarrage pour vérifier si le logiciel de sécurité est correctement implémenté sur votre appareil.

    Les autotests permettent de s’assurer de l’exactitude des algorithmes cryptographiques. L’image Junos-FIPS effectue des autotests automatiquement à la mise sous tension, et en continu pour la génération de paires de clés. Qu’il s’agisse d’images nationales ou FIPS, les autotests peuvent être configurés pour être effectués selon un calendrier défini, à la demande ou immédiatement après la génération de la clé.

    Vous pouvez configurer l’appareil pour qu’il génère une alarme système en cas d’échec de l’autotest.

  • IDP flow policy attacks: une stratégie de détection et de prévention d’intrusion (IDP) vous permet d’appliquer diverses techniques de détection et de prévention des attaques sur le trafic réseau. Vous pouvez configurer l’appareil pour qu’il génère une alarme système en cas de violation de la stratégie de flux IDP.

  • Replay attacks—Une attaque par rejeu est une attaque réseau dans laquelle une transmission de données valide est répétée ou retardée de manière malveillante ou frauduleuse. Vous pouvez configurer l’appareil pour qu’il génère une alarme système lorsqu’une attaque par rejeu se produit.

Les messages syslog sont inclus dans les cas suivants :

  • Echec de la génération de clé symétrique

  • Echec de la génération de clé asymétrique

  • Échec de la distribution manuelle des clés

  • Échec de la distribution automatique de clés

  • Échec de la destruction de la clé

  • Échec de la manipulation et du stockage des clés

  • Échec du chiffrement ou du déchiffrement des données

  • Échec de la signature

  • Échec de l’accord clé

  • Echec du hachage cryptographique

  • Défaillance IKE

  • Échec de l’authentification des paquets reçus

  • Erreur de déchiffrement due à un contenu de remplissage non valide

  • Incompatibilité dans la longueur spécifiée dans le champ d’objet alternatif du certificat reçu d’un appareil homologue VPN distant.

Les alarmes sont déclenchées en fonction des messages syslog. Chaque défaillance est enregistrée, mais une alarme n’est générée que lorsqu’un seuil est atteint.

Pour afficher les informations sur l’alarme, exécutez la show security alarms commande. Le nombre de violations et l’alarme ne persistent pas après les redémarrages du système. Après un redémarrage, le nombre de violations est remis à zéro et l’alarme est effacée de la file d’attente des alarmes.

Une fois que les mesures appropriées ont été prises, vous pouvez désactiver l’alarme. L’alarme reste dans la file d’attente jusqu’à ce que vous l’effaciez (ou jusqu’à ce que vous redémarriez l’appareil). Pour effacer l’alarme, exécutez la clear security alarms commande.

Voir également

Comprendre les méthodes de surveillance VPN

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

La surveillance des VPN est une nécessité, car la plupart de vos services stratégiques s’exécutent sur ces tunnels VPN. On peut s’attendre à ce que les tunnels VPN fonctionnent de manière optimale en permanence. Mais ce n’est guère le cas dans un scénario réel. Un tunnel VPN peut être en panne pour plusieurs raisons. Par exemple, l’homologue IKE peut être injoignable, le VPN sous-jacent peut être en panne, le tunnel peut être instable et plusieurs autres raisons. Junos OS résout ces problèmes.

Comprendre la détection des pairs morts

Dead Peer Detection (DPD) est un protocole basé sur des normes qui utilise le trafic réseau pour détecter la vivacité d’un pair IKE dans une connexion IPsec. Lors de la création d’un tunnel IPsec, les homologues VPN négocient pour décider d’utiliser ou non la méthode DPD. Si les homologues acceptent d’utiliser le protocole DPD, le pare-feu vérifie activement l’activité de l’homologue. Lorsqu’il n’y a pas de trafic actif, le pare-feu envoie des messages périodiques à l’homologue et attend une réponse. Si l’homologue ne répond pas aux messages, le pare-feu suppose que l’homologue n’est plus disponible. Le comportement du protocole DPD est le même pour les protocoles IKEv1 et IKEv2. Les temporisateurs DPD sont actifs dès que le pare-feu établit l’IKE Phase 1 Security Association (SA). Les pare-feu SRX Series utilisent le protocole DPD pour détecter l’activité des pairs dans une connexion VPN IPsec.

Figure 1 : Échange de messages dans le protocole DPDÉchange de messages dans le protocole DPD

Figure 1 montre l’échange de messages DPD entre les homologues IKE dans un tunnel VPN IPsec. Les événements suivants se produisent lorsque l’appareil effectue DPD :

  1. SRX-A attend l’intervalle DPD spécifié pour vérifier s’il a reçu du trafic de son homologue, SRX-B.

  2. Si le SRX-A ne reçoit aucun trafic de SRX-B pendant l’intervalle DPD spécifié, il envoie à SRX-B une charge utile de notification IKE de phase 1 chiffrée (un message R-U-THERE).

  3. SRX-A attend l’accusé de réception DPD (un message R-U-THERE-ACK) de la part de SRX-B.

    1. Si SRX-A reçoit un message R-U-THERE-ACK de SRX-B au cours de cet intervalle, il considère que l’homologue est actif. Ensuite, SRX-A réinitialise son compteur de messages R-U-THERE pour ce tunnel et démarre un nouvel intervalle.

    2. Si SRX-A ne reçoit pas de message R-U-THERE-ACK pendant l’intervalle, il considère que l’homologue, SRX-B, est inactif. Le SRX-A supprime ensuite la SA de phase 1 et toutes les SA de phase 2 de cet homologue.

Voyons quels paramètres DPD vous devrez configurer :

  • Mode : en fonction de l’activité du trafic, vous pouvez configurer DPD dans l’un des modes suivants :

    • Optimisé : en mode optimisé , lorsque l’appareil à l’origine envoie des paquets sortants à l’homologue, s’il n’y a pas de trafic IKE ou IPsec entrant de l’homologue dans l’intervalle configuré, l’appareil à l’origine déclenche des messages R-U-THERE. DPD fonctionne dans ce mode par défaut, sauf si vous spécifiez un mode par le biais de la configuration.

    • Tunnel inactif de la sonde : en mode tunnel inactif de la sonde , l’appareil déclenche des messages R-U-THERE s’il n’y a pas de trafic IKE ou IPsec entrant ou sortant au cours d’un intervalle configuré. L’appareil envoie régulièrement des messages R-U-THERE à l’homologue jusqu’à ce qu’il y ait une activité de trafic. Ce mode permet de détecter précocement un homologue en panne, garantissant ainsi la disponibilité du tunnel pendant le flux de trafic actif.



      REMARQUE :

      Si vous avez configuré plusieurs sélecteurs de trafic pour un VPN, vous pouvez établir plusieurs tunnels pour la même IKE SA. Dans ce scénario, lorsque vous configurez le mode tunnel inactif de la sonde, cela déclenche des messages R-U-THERE si un tunnel devient inactif, quel que soit le trafic dans un autre tunnel pour la même IKE SA.

    • Always-send (Envoi permanent) : en mode d’envoi permanent, l’appareil envoie des messages R-U-THERE à un intervalle configuré, quelle que soit l’activité du trafic entre les homologues. Nous vous recommandons d’utiliser le mode tunnel inactif de la sonde plutôt que le mode d’envoi permanent .

  • Interval (Intervalle) : utilisez le paramètre interval (en secondes) pour spécifier la durée (en secondes) pendant laquelle l’appareil attend le trafic de son homologue avant d’envoyer un message R-U-THERE. L’intervalle par défaut est de 10 secondes. À partir de la version 15.1X49-D130 de Junos OS, nous avons réduit la plage de paramètres d’intervalle autorisée à laquelle les messages R-U-THERE sont envoyés au périphérique homologue de 10 secondes à 60 secondes à 2 secondes à 60 secondes. Nous vous recommandons de définir le paramètre de seuil minimum sur 3, lorsque le paramètre d’intervalle DPD est défini sur moins de 10 secondes.

  • Threshold (Seuil) : utilisez le paramètre threshold ( seuil ) pour spécifier le nombre maximal de fois que l’appareil envoie le message R-U-THERE sans recevoir de réponse de l’homologue, avant qu’il ne considère que l’homologue est en panne. Le nombre par défaut de transmissions est de cinq, avec une plage autorisée de 1 à 5 tentatives.

Notez les considérations suivantes avant de configurer DPD :

  • Une fois que vous avez ajouté la configuration DPD à une passerelle existante avec des tunnels actifs, l’appareil commence à déclencher des messages R-U-THERE sans effacer les SA de phase 1 ou de phase 2.

  • Lorsque vous supprimez la configuration DPD d’une passerelle existante avec des tunnels actifs, l’appareil cesse de déclencher des messages R-U-THERE pour les tunnels. Mais cela n’affecte pas les IKE et les SA IPsec.

  • Lorsque vous modifiez des paramètres de configuration DPD tels que des valeurs de mode, d’intervalle ou de seuil, IKE met à jour l’opération DPD sans effacer les SA de phase 1 ou de phase 2.

  • Si vous configurez la passerelle IKE avec la surveillance DPD et VPN sans spécifier l’option permettant d’établir des tunnels immédiatement, IKE ne lance pas la négociation de phase 1. Lorsque vous configurez DPD, vous devez également configurer l’option au niveau de la hiérarchie [edit services ipsec-vpn] pour supprimer l’interface establish-tunnels immediately st0 lorsqu’aucune SA de phase 1 et de phase 2 n’est disponible. Reportez-vous à la section Établir des tunnels immédiatement.

  • Si vous configurez la passerelle IKE avec plusieurs adresses IP homologues et DPD, mais que vous ne parvenez pas à établir la phase 1 SA avec la première adresse IP homologue, IKE tente d’établir avec l’adresse IP homologue suivante. Le DPD n’est actif qu’une fois que l’IKE a établi l’AS de phase 1. Reportez-vous à la section détection des pairs morts.

  • Si vous configurez la passerelle IKE avec plusieurs adresses IP homologues et DPD, mais que la connexion échoue avec l’adresse IP de l’homologue actuel, IKE efface les SA de phase 1 et de phase 2 et DPD effectue un basculement vers l’adresse IP homologue suivante. Voir passerelle (IKE de sécurité).

  • Plusieurs SA de phase 1 ou de phase 2 peuvent exister avec le même homologue en raison de négociations simultanées. Dans ce cas, DPD envoie des messages R-U-THERE à toutes les SA de phase 1. Si la passerelle ne parvient pas à recevoir les réponses DPD pendant le nombre configuré de fois consécutifs, elle efface la SA de phase 1 et la SA de phase 2 associée (pour IKEv2 uniquement).

REMARQUE :

Pour plus de détails sur l’implémentation de DPD, consultez RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.

Si l’homologue IKE est actif, cela signifie-t-il que le VPN sous-jacent l’est ?

Conseil :

Demandez-vous si DPD garantit la vivacité IPsec SA.

Comprendre la surveillance VPN

Bien que le protocole Dead Peer Detection (DPD) vérifie la vivacité d’un pair IKE, il ne garantit pas la vivacité du VPN sous-jacent. Il n’existe pas de méthode standardisée pour vérifier si le VPN sous-jacent est opérationnel. La surveillance VPN est un mécanisme de Junos OS permettant de vérifier la vivacité d’une association de sécurité IPsec (SA). La surveillance VPN utilise les requêtes d’écho (ou pings) ICMP (Internet Control Message Protocol) et les données de signature, telles que l’ID de tunnel, dans le paquet ICMP pour déterminer si le tunnel VPN est actif.

Lorsque vous activez la surveillance VPN, l’appareil envoie des pings via le tunnel VPN à la passerelle homologue ou à une destination spécifiée à l’autre extrémité du tunnel. L’appareil envoie des pings par défaut à des intervalles de 10 secondes jusqu’à 10 fois consécutives. Si l’appareil ne reçoit aucune réponse après 10 pings consécutifs, il considère que le VPN est désactivé et que l’association de sécurité IPsec (SA) est effacée.

Les supervisions DPD et VPN se complètent. La surveillance VPN s’applique à un VPN IPsec individuel, tandis que DPD est configuré dans un contexte de passerelle IKE individuel.

Vous pouvez utiliser les modes de fonctionnement suivants pour surveiller les tunnels VPN :

  • Mode d’envoi permanent : dans ce mode, l’appareil envoie un paquet de surveillance VPN une fois par intervalle configuré, quel que soit le trafic dans le tunnel. Une fois que vous avez activé la surveillance VPN, Junos OS utilise le mode d’envoi permanent comme mode par défaut si vous n’en spécifiez pas.

  • Mode optimisé : dans ce mode, l’appareil envoie un paquet de surveillance VPN une fois par intervalle configuré, uniquement s’il y a du trafic sortant et aucun trafic entrant via le tunnel pendant l’intervalle. S’il y a du trafic entrant via le tunnel VPN, l’équipement considère que le tunnel est actif et n’envoie pas de ping à l’homologue. Vous pouvez utiliser le mode optimisé pour économiser des ressources sur l’appareil, car dans ce mode, l’appareil envoie des pings uniquement lorsqu’il a besoin de déterminer l’activité de l’homologue. L’envoi de pings peut également activer des liens de sauvegarde coûteux qui ne seraient pas utilisés autrement. L’appareil fonctionne en mode d’envoi permanent par défaut si vous ne configurez pas explicitement le modeoptimisé.

Pour configurer la surveillance VPN sur les pare-feu SRX Series :

  1. Activez la surveillance VPN pour un tunnel VPN spécifique en incluant l’option au niveau de la vpn-monitor hiérarchie [edit security ipsec vpn vpn-name]. Voir vpn-monitor.

  2. Configurez le mode de surveillance VPN comme optimisé.

  3. Spécifiez l’adresse IP de destination. L’adresse IP de la passerelle homologue est la destination par défaut ; Toutefois, vous pouvez spécifier une adresse IP de destination différente (telle que celle d’un serveur) qui se trouve à l’autre extrémité du tunnel.

  4. Spécifiez l’adresse source-interface . Le point de terminaison du tunnel local est l’interface source par défaut, mais vous pouvez spécifier un autre nom d’interface.

  5. Configurez l’intervalle auquel l’appareil envoie les pings et le nombre de pings consécutifs qu’il envoie avec les interval options et threshold , respectivement, au niveau de la hiérarchie [edit security ipsec vpn-monitor-options]. Si vous ne configurez pas ces options, l’appareil envoie des pings à l’intervalle par défaut de 10 secondes jusqu’à 10 fois consécutives. S’il ne reçoit pas de réponse, il considère que le VPN est en panne. L’appareil efface ensuite l’association de sécurité IPsec.

REMARQUE :

Les pare-feu SRX5400, SRX5600 et SRX5800 ne prennent pas en charge la surveillance VPN d’un appareil connecté en externe (tel qu’un PC). Sur ces appareils, la destination de lasurveillance VPN doit être une interface locale.

ATTENTION :

Dans certainsenvironnements, la surveillance VPN peut provoquer des battements de tunnel si les paquets ping ne sont pas acceptés par l’homologue en fonction de l’adresse IP source ou de destination du paquet.

Comprendre la vérification IPsec des chemins de données

Présentation

Par défaut, l’état des interfaces de tunnel sécurisé (st0) configurées en mode point à point dans les VPN basés sur le routage est basé sur l’état du tunnel VPN. Peu de temps après l’établissement de la SA IPsec, les routes associées à l’interface st0 sont installées dans le Junos OS table de transfert. Dans certaines topologies de réseau, par exemple lorsqu’un pare-feu de transit est situé entre les points de terminaison du tunnel VPN, le trafic de données IPsec qui utilise des routes actives pour un tunnel VPN établi sur l’interface st0 peut être bloqué par le pare-feu de transit. Cela peut entraîner une perte de trafic.

Lorsque vous activez la vérification IPsec du chemin de données, l’interface st0 n’est pas activée et activée tant que le chemin de données n’est pas vérifié. La vérification est configurée avec l’instruction pour les set security ipsec vpn vpn-name vpn-monitor verify-path tunnels VPN de point de terminaison basés sur le routage, site à site et dynamiques.

Si un périphérique NAT se trouve devant le point de terminaison du tunnel homologue, l’adresse IP du point de terminaison du tunnel homologue est convertie en adresse IP du périphérique NAT. Pour que la demande ICMP du moniteur VPN atteigne le point de terminaison du tunnel homologue, vous devez spécifier explicitement l’adresse IP d’origine non traduite du point de terminaison du tunnel homologue derrière le périphérique NAT. Ceci est configuré avec la set security ipsec vpn vpn-name vpn-monitor verify-path destination-ip configuration.

À partir de Junos OS version 15.1X49-D120, vous pouvez configurer la taille du paquet utilisé pour vérifier un chemin de données IPsec avant l’activation de l’interface st0 . Utilisez la set security ipsec vpn vpn-name vpn-monitor verify-path packet-size configuration. La taille de paquet configurable varie de 64 à 1350 octets ; La valeur par défaut est de 64 octets.

Avertissements

L’interface source et les adresses IP de destination qui peuvent être configurées pour le fonctionnement du moniteur VPN n’ont aucun effet sur la vérification du chemin de données IPsec. La source des requêtes ICMP dans la vérification du chemin de données IPsec est le point de terminaison du tunnel local.

Lorsque vous activez la vérification IPsec du chemin de données, la surveillance VPN est automatiquement activée et utilisée après la mise en service de l’interface st0. Nous vous recommandons de configurer l’option optimisée du moniteur VPN à l’aide de la commande chaque fois que vous activez la vérification IPsec du chemin de set security ipsec vpn vpn-name vpn-monitor optimized données.

Si un basculement de cluster de châssis se produit pendant la vérification du chemin de données IPsec, le nouveau nœud actif redémarre la vérification. L’interface st0 n’est pas activée tant que la vérification n’a pas réussi.

Aucune vérification IPsec du chemin de données n’est effectuée pour les reclés IPsec SA, car l’état de l’interface st0 ne change pas pour les reclés.

La vérification IPsec du chemin de données n’est pas prise en charge sur les interfaces st0 configurées en mode point à multipoint qui sont utilisées avec AutoVPN, Auto Discovery VPN et plusieurs sélecteurs de trafic. La surveillance VPN et la vérification des chemins de données IPsec prennent en charge les adresses IPv6, de sorte que la vérification des chemins de données IPsec peut être utilisée avec des tunnels IPv6.

Comprendre les fonctionnalités de surveillance SPI et VPN globales

Vous pouvez surveiller et maintenir le bon fonctionnement de votre VPN à l’aide des fonctionnalités VPN globales suivantes :

  • SPI : les homologues d’une association de sécurité (SA) peuvent se désynchroniser en cas de défaillance de l’un des homologues. Par exemple, si l’un des homologues redémarre, il se peut qu’il envoie un index de paramètres de sécurité (SPI) incorrect. Vous pouvez permettre à l’appareil de détecter un tel événement et de resynchroniser les homologues en configurant la fonctionnalité de réponse SPI incorrecte.

  • Surveillance VPN : vous pouvez utiliser la fonctionnalité de surveillance VPN globale pour envoyer régulièrement des requêtes ICMP (Internet Control Message Protocol) à l’homologue afin de déterminer s’il est joignable.

Comparaison de la surveillance VPN et de la DPD

La surveillance VPN et la détection des pairs morts (DPD) sont des fonctionnalités disponibles sur les pare-feu SRX Series pour vérifier la disponibilité des appareils homologues VPN. Cette section compare le fonctionnement et la configuration de ces fonctionnalités.

Le pare-feu SRX Series répond aux messages DPD envoyés par des homologues VPN, même si DPD n’est pas configuré sur l’équipement. Vous pouvez configurer le pare-feu SRX Series pour qu’il envoie des messages DPD à des homologues VPN. Vous pouvez également configurer la surveillance DPD et VPN pour qu’elle fonctionne simultanément sur le même pare-feu SRX Series, bien que le nombre d’homologues pouvant être surveillés avec l’une ou l’autre méthode soit réduit.

La surveillance VPN est un mécanisme de Junos OS qui surveille uniquement les associations de sécurité (SA) de phase 2. La surveillance VPN est activée pour chaque VPN avec l’instruction vpn-monitor au niveau de la hiérarchie [edit security ipsec vpn vpn-name]. L’adresse IP de destination et l’interface source doivent être spécifiées. Cette optimized option permet à l’appareil d’utiliser les modèles de trafic comme preuve de la vivacité des pairs ; Les requêtes ICMP sont supprimées.

Les options de surveillance VPN sont configurées avec l’instruction vpn-monitor-options au niveau de la hiérarchie [edit security ipsec]. Ces options s’appliquent à tous les VPN pour lesquels la surveillance VPN est activée. Les options que vous pouvez configurer incluent l’intervalle auquel les demandes ICMP sont envoyées à l’homologue (la valeur par défaut est de 10 secondes) et le nombre de demandes ICMP consécutives envoyées sans recevoir de réponse avant que l’homologue ne soit considéré comme inaccessible (la valeur par défaut est de 10 demandes consécutives).

DPD est une implémentation de la RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers. Il fonctionne au niveau de l’IKE et surveille l’homologue en fonction de l’activité du trafic IKE et IPsec.

DPD est configuré sur une passerelle IKE individuelle avec l’instruction dead-peer-detection au niveau de la hiérarchie [edit security ike gateway gateway-name]. Vous pouvez configurer les modes de fonctionnement DPD. Le mode par défaut (optimisé) envoie des messages DPD à l’homologue s’il n’y a pas de trafic IKE ou IPsec entrant dans un intervalle configuré après que l’équipement local a envoyé des paquets sortants à l’homologue. D’autres options configurables incluent l’intervalle auquel les messages DPD sont envoyés à l’homologue (la valeur par défaut est de 10 secondes) et le nombre de messages DPD consécutifs envoyés sans recevoir de réponse avant que l’homologue ne soit considéré comme indisponible (la valeur par défaut est de cinq demandes consécutives).

Voir également

Comprendre les événements de tunnel

Lorsqu’il y a un problème de réseau lié à un VPN, après l’ouverture du tunnel, seul l’état du tunnel est suivi. De nombreux problèmes peuvent survenir avant l’ouverture du tunnel. Par conséquent, au lieu de suivre uniquement l’état du tunnel, les problèmes d’arrêt du tunnel ou les échecs de négociation, les événements réussis, tels que les négociations SA IPsec réussies, les nouvelles clés IPsec et les reclés IKE SA sont désormais suivis. Ces événements sont appelés événements tunnel.

Pour les phases 1 et 2, les événements de négociation pour un tunnel donné sont suivis en même temps que les événements qui se produisent dans les démons externes tels que AUTHD ou PKID. Lorsqu’un événement de tunnel se produit plusieurs fois, une seule entrée est conservée avec l’heure mise à jour et le nombre de fois que cet événement s’est produit.

Au total, 16 événements sont suivis : huit épreuves pour la phase 1 et huit épreuves pour la phase 2. Certains événements peuvent se reproduire et remplir la mémoire des événements, ce qui entraîne la suppression d’événements importants. Pour éviter l’écrasement, un événement n’est pas stocké, sauf si un tunnel est inactif.

Les événements spéciaux suivants entrent dans cette catégorie :

  • Durée de vie expirée en kilo-octets pour IPsec SA

  • Durée de vie stricte de la SA IPsec expirée

  • Les SA IPsec suppriment la charge utile reçue de l’homologue, les SA IPsec correspondantes sont effacées

  • Effacement des paires SA IPsec de sauvegarde redondantes inutilisées

  • Les SA IPsec effacées en tant que SA IKE correspondantes ont été supprimées

Les tunnels AutoVPN sont créés et supprimés dynamiquement, de sorte que les événements de tunnel correspondant à ces tunnels sont de courte durée. Parfois, ces événements de tunnel ne peuvent pas être associés à un tunnel, de sorte que la journalisation système est utilisée pour le débogage à la place.

Voir également

Exemple : Configurer une notification d’alerte sonore

Cet exemple montre comment configurer un appareil pour qu’il génère un bip d’alerte système lorsqu’un nouvel événement de sécurité se produit. Par défaut, les alarmes ne sont pas audibles. Cette fonctionnalité est prise en charge sur les équipements et Pare-feu virtuel vSRX instances SRX300, SRX320, SRX340, SRX345, SRX550HM et SRX1500.

Conditions préalables

Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cette fonctionnalité.

Présentation

Dans cet exemple, vous définissez un bip sonore à générer en réponse à une alarme de sécurité.

Configuration

Procédure

Procédure étape par étape

Pour régler une alarme sonore :

  1. Activez les alarmes de sécurité.

  2. Indiquez que vous souhaitez être averti des alarmes de sécurité par un bip sonore.

  3. Si vous avez terminé de configurer l’appareil, validez la configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, entrez la show security alarms detail commande.

Voir également

Exemple : Configurer la génération d’alarmes de sécurité

Cet exemple montre comment configurer l’appareil pour générer une alarme système lorsqu’une violation potentielle se produit. Par défaut, aucune alarme n’est déclenchée lorsqu’une violation potentielle se produit. Cette fonctionnalité est prise en charge sur les équipements et Pare-feu virtuel vSRX instances SRX300, SRX320, SRX340, SRX345, SRX550HM et SRX1500.

Conditions préalables

Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cette fonctionnalité.

Présentation

Dans cet exemple, vous configurez une alarme pour qu’elle se déclenche lorsque :

  • Le nombre d’échecs d’authentification dépasse 6.

  • L’auto-test cryptographique échoue.

  • L’autotest non cryptographique échoue.

  • L’auto-test de génération de clés échoue.

  • Le nombre d’échecs de chiffrement dépasse 10.

  • Le nombre d’échecs de déchiffrement dépasse 1.

  • Le nombre de défaillances IKE de phase 1 dépasse 10.

  • Le nombre de défaillances IKE de phase 2 dépasse 1.

  • Une attaque par rejeu se produit.

Configuration

Procédure

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette procédure, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.

Pour configurer des alarmes en réponse à des violations potentielles :

  1. Activez les alarmes de sécurité.

  2. Spécifiez qu’une alarme doit être déclenchée en cas d’échec d’authentification.

  3. Spécifiez qu’une alarme doit être déclenchée en cas d’échec de l’autotest cryptographique.

  4. Spécifiez qu’une alarme doit être déclenchée en cas d’échec d’un autotest non cryptographique.

  5. Spécifiez qu’une alarme doit être déclenchée en cas d’échec de l’auto-test de génération de clés.

  6. Spécifiez qu’une alarme doit être déclenchée en cas d’échec de chiffrement.

  7. Spécifiez qu’une alarme doit être déclenchée en cas d’échec de déchiffrement.

  8. Spécifiez qu’une alarme doit être déclenchée lorsqu’une défaillance IKE de phase 1 se produit.

  9. Spécifiez qu’une alarme doit être déclenchée lorsqu’une défaillance IKE de phase 2 se produit.

  10. Spécifiez qu’une alarme doit être déclenchée lorsqu’une attaque par rejeu se produit.

Résultats

À partir du mode configuration, confirmez votre configuration en entrant la show security alarms commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Vérification

Pour confirmer que la configuration fonctionne correctement, à partir du mode opérationnel, entrez la show security alarms commande.

Voir également

Rubriques connexes

Tableau de l'historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Version
Description
15.1X49-D130
À partir de la version 15.1X49-D130 de Junos OS, la plage de paramètres d’intervalle autorisée à laquelle les messages R-U-THERE sont envoyés à l’équipement homologue est réduite de 10 à 60 secondes à 2 secondes à 60 secondes. Le paramètre de seuil minimum doit être 3, lorsque le paramètre d’intervalle DPD est défini sur moins de 10 secondes.
15.1X49-D120
À partir de Junos OS version 15.1X49-D120, vous pouvez configurer la taille du paquet utilisé pour vérifier un chemin de données IPsec avant l’activation de l’interface st0 .