Surveillance et dépannage des stratégies de sécurité
La surveillance fournit une présentation en temps réel de données significatives représentant l’état des activités d’accès sur un réseau. Ces informations vous permettent d’interpréter et d’affecter facilement les conditions opérationnelles. Le dépannage fournit des conseils contextuels pour résoudre les problèmes d’accès sur les réseaux. Vous pourrez alors répondre aux préoccupations des utilisateurs et résoudre les problèmes dans les meilleurs délais.
Comprendre les alarmes de sécurité
Des alarmes sont déclenchées lorsque des paquets sont perdus en raison d’une violation de politique. Une violation de stratégie se produit lorsqu’un paquet correspond à une politique de rejet ou de refus. Une alarme de non-respect de stratégie est générée lorsque le système surveille l’un des événements audités suivants :
Nombre de violations de politique par un identifiant de réseau source au cours d’une période donnée
Nombre de violations de politique sur un identifiant de réseau de destination au cours d’une période donnée
Nombre de violations de politique d’une application au cours d’une période donnée
Violations de règles de stratégie ou de groupes de règles au cours d’une période donnée
Il existe quatre types d’alarmes correspondant à ces quatre événements. Les alarmes sont basées sur l’IP source, l’IP de destination, l’application et la stratégie.
Lorsqu’un paquet rencontre une politique de rejet ou de refus, le nombre de compteurs de violation de stratégie pour tous les types d’alarmes activés est augmenté. Lorsqu’un compteur atteint le seuil spécifié au cours d’une période donnée, une alarme est générée. Après une période spécifiée, le compteur de violations de stratégie est réinitialisé et réutilisé pour démarrer un autre cycle d’inventaire.
Pour afficher les informations d’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 d’alarme.
Après avoir pris les mesures appropriées, vous pouvez effacer 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. Une fois l’alarme effacée, une série de violations de stratégie de flux peut entraîner le déclenchement d’une nouvelle alarme.
Voir aussi
Exemple : Génération d’une alarme de sécurité en réponse à des violations de stratégie
Cet exemple montre comment configurer l’appareil pour générer une alarme système en cas de violation de stratégie. Par défaut, aucune alarme n’est déclenchée en cas de violation de stratégie.
Exigences
Aucune configuration spéciale au-delà de l’initialisation de l’équipement n’est requise avant de configurer cette fonctionnalité.
Vue d’ensemble
Dans cet exemple, vous configurez une alarme pour qu’elle soit déclenchée lorsque :
La taille de l’application est de 10240 unités.
La violation d’IP source dépasse 1000 en 20 secondes.
Les violations d’IP de destination dépassent 1000 en 10 secondes.
La violation de la correspondance de la politique dépasse 100, avec une taille de 100 unités.
La configuration
Procédure
Configuration rapide de la CLI
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 à votre configuration réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez en commit mode configuration.
set security alarms potential-violation policy application size 10240 set security alarms potential-violation policy source-ip threshold 1000 duration 20 set security alarms potential-violation policy destination-ip threshold 1000 duration 10 set security alarms potential-violation policy policy-match threshold 100 size 100
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 la procédure à suivre, consultez Utilisation de l’éditeur CLI en mode Configuration dans le Guide de l’utilisateur de la CLI.
Pour configurer les alarmes de violation de politique :
Activez les alarmes de sécurité.
[edit] user@host# edit security alarms
Spécifiez qu’une alarme doit être déclenchée en cas de violation d’application.
[edit security alarms potential-violation policy] user@host# set application size 10240
Spécifiez qu’une alarme doit être déclenchée en cas de violation d’IP source.
[edit security alarms potential-violation policy] user@host# set source-ip threshold 1000 duration 20
Spécifiez qu’une alarme doit être déclenchée en cas de violation de l’IP de destination.
[edit security alarms potential-violation policy] user@host# set destination-ip threshold 1000 duration 10
Spécifiez qu’une alarme doit être déclenchée en cas de violation d’une correspondance de stratégie.
[edit security alarms potential-violation policy] user@host# set policy-match threshold 100 size 100
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.
policy {
source-ip {
threshold 1000;
duration 20;
}
destination-ip {
threshold 1000;
duration 10;
}
application {
size 10240;
}
policy-match {
threshold 100;
size 100;
}
}
Si vous avez terminé de configurer l’appareil, entrez en commit mode configuration.
Vérification
Pour confirmer que la configuration fonctionne correctement, à partir du mode opérationnel, entrez la show security alarms commande.
Correspondance des politiques de sécurité
La show security match-policies commande vous permet de résoudre les problèmes de trafic à l’aide des critères de correspondance : port source, port de destination, adresse IP source, adresse IP de destination et protocole. Par exemple, si votre trafic ne passe pas parce qu’une stratégie appropriée n’est pas configurée ou que les critères de correspondance sont incorrects, la show security match-policies commande vous permet de travailler hors connexion et d’identifier où le problème existe réellement. Il utilise le moteur de recherche pour identifier le problème et vous permet ainsi d’utiliser la stratégie de correspondance appropriée pour le trafic.
L’option result-count spécifie le nombre de stratégies à afficher. La première stratégie activée de la liste est la stratégie qui s’applique à tout le trafic correspondant. Les autres stratégies en dessous sont « masquées » par la première et ne sont jamais rencontrées par le trafic correspondant.
La show security match-policies commande s’applique uniquement aux stratégies de sécurité ; Les politiques IDP ne sont pas prises en charge.
Exemple 1 : afficher les politiques de correspondance de sécurité
user@host> show security match-policies from-zone z1 to-zone z2 source-ip 10.10.10.1 destination-ip 192.0.2.1 source-port 1 destination-port 21 protocol tcp
Policy: p1, action-type: permit, State: enabled, Index: 4
Sequence number: 1
From zone: z1, To zone: z2
Source addresses:
a2: 203.0.113.1/25
a3: 10.10.10.1/32
Destination addresses:
d2: 203.0.113.129/25
d3: 192.0.2.1/24
Application: junos-ftp
IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800
Source port range: [0-0]
Destination port range: [21-21]
Exemple 2 : Utilisation de l’option result-count
Par défaut, la liste de sortie contient la stratégie qui sera appliquée au trafic avec les caractéristiques spécifiées. Pour répertorier plusieurs stratégies qui correspondent aux critères, utilisez l’option result-count . La première stratégie répertoriée est toujours la politique qui sera appliquée au trafic correspondant. Si la result-count valeur est comprise entre 2 et 16, la sortie inclut toutes les stratégies qui correspondent aux critères jusqu’au . result-count Toutes les stratégies répertoriées après la première sont « masquées » par la première stratégie et ne sont jamais appliquées au trafic correspondant.
Utilisez cette option pour tester le positionnement d’une nouvelle stratégie ou pour dépanner une stratégie qui n’est pas appliquée comme prévu pour un trafic particulier.
Dans l’exemple suivant, le critère de trafic correspond à deux stratégies. La première stratégie répertoriée, p1, contient l’action appliquée au trafic. La stratégie p15 est masquée par la première stratégie et son action ne sera donc pas appliquée au trafic correspondant.
user@host> show security match-policies from-zone zone-A to-zone zone-B source-ip 10.10.10.1 destination-ip 192.0.2.1 source-port 1004 destination-port 80 protocol tcp result-count 5
Policy: p1, action-type: permit, State: enabled, Index: 4
Sequence number: 1
From zone: zone-A, To zone: zone-B
Source addresses:
sa1: 10.10.0.0/16
Destination addresses:
da5: 192.0.2.0/24
Application: any
IP protocol: 1, ALG: 0, Inactivity timeout: 0
Source port range: [1000-1030]
Destination port range: [80-80]
Policy: p15, action-type: deny, State: enabled, Index: 18
Sequence number: 15
From zone: zone-A, To zone: zone-B
Source addresses:
sa11: 10.10.10.1/32
Destination addresses:
da15: 192.0.2.5/24
Application: any
IP protocol: 1, ALG: 0, Inactivity timeout: 0
Source port range: [1000-1030]
Destination port range: [80-80]
Voir aussi
Suivi du nombre d’occurrences des stratégies
Utilisez la show security policies hit-count commande pour afficher le taux d’utilité des stratégies de sécurité en fonction du nombre d’accès qu’elles reçoivent. Vous pouvez utiliser cette fonctionnalité pour déterminer quelles stratégies sont utilisées sur l’appareil et à quelle fréquence elles sont utilisées. Selon les options de commande que vous choisissez, le nombre d’accès peut être répertorié sans ordre ou trié par ordre croissant ou décroissant, et il peut être limité au nombre d’appels qui se situent au-dessus ou en dessous d’un nombre spécifique ou dans une plage. Les données sont affichées pour toutes les zones associées aux stratégies ou aux zones nommées.
Vérification de l’utilisation de la mémoire
Vous pouvez isoler les problèmes de mémoire en comparant les valeurs de mémoire avant et après les configurations de stratégie.
Certaines pratiques peuvent aider à surveiller l’utilisation actuelle de la mémoire sur l’appareil et à optimiser les paramètres pour mieux dimensionner la configuration du système, en particulier lors de la mise en œuvre des stratégies.
Pour vérifier l’utilisation de la mémoire :
Utilisez la commande pour vérifier l’utilisation globale de la
show chassis routing-enginemémoire du moteur de routage (RE). Le résultat suivant de cette commande montre une utilisation de la mémoire à 39 % :user@host#
show chassis routing-engineRouting Engine status: Slot 0: Current state Master Election priority Master (default) DRAM 1024 MB Memory utilization 39 percent CPU utilization: User 0 percent Background 0 percent Kernel 2 percent Interrupt 0 percent Idle 97 percent Model RE-PPC-1200-A Start time 2011-07-09 19:19:49 PDT Uptime 37 days, 15 hours, 44 minutes, 13 seconds Last reboot reason 0x3:power cycle/failure watchdog Load averages: 1 minute 5 minute 15 minute 0.22 0.16 0.07Utilisez la
show system processes extensivecommande pour obtenir des informations sur les processus en cours d’exécution sur le moteur de routage.Utilisez l’option de la
show system processes extensivecommande pour voir l’utilisationfind nsddirecte sur le démon de la sécurité réseau (NSD) avec sa mémoire totale utilisée à 10 mégaoctets et son utilisation du processeur de 0 %.user@host# show system processes extensive | find nsd 1182 root 1 96 0 10976K 5676K select 2:08 0.00% nsd 1191 root 4 4 0 8724K 3764K select 1:57 0.00% slbd 1169 root 1 96 0 8096K 3520K select 1:51 0.00% jsrpd 1200 root 1 4 0 0K 16K peer_s 1:10 0.00% peer proxy 1144 root 1 96 0 9616K 3528K select 1:08 0.00% lacpd 1138 root 1 96 0 6488K 2932K select 1:02 0.00% ppmd 1130 root 1 96 0 7204K 2208K select 1:02 0.00% craftd 1163 root 1 96 0 16928K 5188K select 0:58 0.00% cosd 1196 root 1 4 0 0K 16K peer_s 0:54 0.00% peer proxy 47 root 1 -16 0 0K 16K sdflus 0:54 0.00% softdepflush 1151 root 1 96 0 15516K 9580K select 0:53 0.00% appidd 900 root 1 96 0 5984K 2876K select 0:41 0.00% eventd
Vérifiez la taille du fichier de configuration. Enregistrez votre fichier de configuration sous un nom unique avant de quitter la CLI. Ensuite, entrez la
ls -1 filenamecommande à partir de l’invite shell dans l’interpréteur de commandes au niveau UNIX pour vérifier la taille du fichier comme indiqué dans l’exemple de sortie suivant :user@host> start shell % ls -l config -rw-r--r-- 1 remote staff 12681 Feb 15 00:43 config
Voir aussi
Surveiller les statistiques des stratégies de sécurité
Objet
Surveillez et enregistrez le trafic autorisé ou refusé par Junos OS en fonction de politiques préalablement configurées.
Mesures à prendre
Pour surveiller le trafic, activez les options count (nombre) et journalisation.
Comte—Configurable dans une stratégie individuelle. Si l’option count est activée, des statistiques sont collectées sur les sessions qui accèdent à l’appareil pour une stratégie donnée, et sur le nombre de paquets et d’octets qui transitent par l’appareil dans les deux sens pour une stratégie donnée. Pour le nombre (uniquement pour les paquets et les octets), vous pouvez spécifier que des alarmes soient générées chaque fois que le trafic dépasse des seuils spécifiés. Voir le nombre (stratégies de sécurité).
Enregistrer —La journalisation peut être activée avec les politiques de sécurité lors de l’initialisation ou de la fermeture de session (session-close). Voir journal (stratégies de sécurité).
Pour afficher les journaux des connexions refusées, activez log on session-init.
Pour enregistrer les sessions après leur conclusion/leur suppression, activez la fermeture de session.
Le journal de session est activé en temps réel dans le code de flux, ce qui a un impact sur les performances de l’utilisateur. Si la fermeture de session et l’initialisation de session sont activées, les performances sont encore plus dégradées par rapport à l’activation de l’initialisation de session uniquement.
Pour plus de détails sur les informations collectées pour les journaux de session, voir Informations fournies dans les entrées du journal de session pour les passerelles de services SRX Series.
Vérification des stratégies fantômes
- Vérification de toutes les stratégies fantômes
- Vérification d’une stratégie masquée d’une ou de plusieurs stratégies
- Vérification qu’une stratégie est masquée par une ou plusieurs politiques
Vérification de toutes les stratégies fantômes
Objet
Vérifiez toutes les stratégies qui masquent une ou plusieurs politiques.
Mesures à prendre
À partir du mode opérationnel, entrez les commandes suivantes :
Pour les systèmes logiques, entrez la
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-namecommande.Pour les stratégies globales, entrez la
show security shadow-policies logical-system lsys-name globalcommande.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b
Policies Shadowed policies
P1 P3
P1 P4
P2 P5
Signification
La sortie affiche la liste de toutes les stratégies qui masquent d’autres stratégies. Dans cet exemple, la stratégie P1 masque les stratégies P3 et P4 et la stratégie P2 applique la stratégie P5.
Vérification d’une stratégie masquée d’une ou de plusieurs stratégies
Objet
Vérifiez si une stratégie donnée fait de l’ombre à une ou plusieurs stratégies positionnées après.
Mesures à prendre
À partir du mode opérationnel, entrez les commandes suivantes :
Pour les systèmes logiques, entrez la
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-name policy policy-namecommande.Pour les stratégies globales, entrez la
show security shadow-policies logical-system lsys-name global policy policy-namecommande.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P1
Policies Shadowed policies
P1 P3
P1 P4
Signification
La sortie affiche toutes les stratégies qui sont masquées par la stratégie donnée. Dans cet exemple, la stratégie P1 fait une ombre aux stratégies P3 et P4.
Vérification qu’une stratégie est masquée par une ou plusieurs politiques
Objet
Vérifiez si une stratégie donnée est masquée par une ou plusieurs stratégies placées avant.
Mesures à prendre
À partir du mode opérationnel, entrez les commandes suivantes :
Pour les systèmes logiques, entrez la
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-name policy policy-name reversecommande.Pour les stratégies globales, entrez la
show security shadow-policies logical-system lsys-name global policy policy-name reversecommande.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P4 reverse
Policies Shadowed policies
P1 P4
Signification
La sortie affiche la stratégie donnée masquée par une ou plusieurs stratégies. Dans cet exemple, la stratégie P4 est masquée par la stratégie P1.
Résoudre les problèmes liés aux politiques de sécurité
- Synchroniser les stratégies entre le moteur de routage et le moteur de transfert de paquets
- Vérification d’un échec de validation d’une stratégie de sécurité
- Vérification d’une validation de stratégie de sécurité
- Recherche de stratégie de débogage
Synchroniser les stratégies entre le moteur de routage et le moteur de transfert de paquets
Problème
Descriptif
Les stratégies de sécurité sont stockées dans le moteur de routage et le moteur de transfert de paquets. Les stratégies de sécurité sont transmises du moteur de routage au moteur de transfert de paquets lorsque vous validez des configurations. Si les stratégies de sécurité du moteur de routage ne sont pas synchronisées avec le moteur de transfert de paquets, la validation d’une configuration échoue. Des fichiers de core dump peuvent être générés si le commit est essayé à plusieurs reprises. Le décalage peut être dû à :
Un message de stratégie du moteur de routage au moteur de transfert de paquets est perdu en transit.
Une erreur avec le moteur de routage, telle qu’un UID de stratégie réutilisé.
Environnement
Les stratégies du moteur de routage et du moteur de transfert de paquets doivent être synchronisées pour que la configuration soit validée. Toutefois, dans certaines circonstances, les stratégies du moteur de routage et du moteur de transfert de paquets peuvent être désynchronisées, ce qui entraîne l’échec de la validation.
Symptômes
Lorsque les configurations de stratégie sont modifiées et que les stratégies ne sont pas synchronisées, le message d’erreur suivant s’affiche : error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)> Please request security policies check/resync.
La solution
Utilisez la show security policies checksum commande pour afficher la valeur de la somme de contrôle de la stratégie de sécurité et utilisez la request security policies resync commande pour synchroniser la configuration des stratégies de sécurité dans le moteur de routage et le moteur de transfert de paquets, si les stratégies de sécurité ne sont pas synchronisées.
Vérification d’un échec de validation d’une stratégie de sécurité
Problème
Descriptif
La plupart des échecs de configuration de stratégie se produisent lors d’une validation ou d’un environnement d’exécution.
Les échecs de validation sont signalés directement sur la CLI lorsque vous exécutez la commande CLI commit-check en mode configuration. Ces erreurs sont des erreurs de configuration et vous ne pouvez pas valider la configuration sans corriger ces erreurs.
La solution
Pour corriger ces erreurs, procédez comme suit :
Passez en revue vos données de configuration.
Ouvrez le fichier /var/log/nsd_chk_only. Ce fichier est remplacé chaque fois que vous effectuez une vérification de validation et contient des informations détaillées sur les défaillances.
Vérification d’une validation de stratégie de sécurité
Problème
Descriptif
Lors d’une validation de configuration de stratégie, si vous remarquez que le comportement du système est incorrect, procédez comme suit pour résoudre ce problème :
La solution
Commandes d’affichage opérationnel : exécutez les commandes opérationnelles pour les stratégies de sécurité et vérifiez que les informations affichées dans la sortie sont cohérentes avec ce que vous attendiez. Si ce n’est pas le cas, la configuration doit être modifiée de manière appropriée.
Traceoptions : définissez la commande dans la configuration de
traceoptionsvotre stratégie. Les indicateurs sous cette hiérarchie peuvent être sélectionnés en fonction de l’analyse utilisateur de la sortie de lashowcommande. Si vous ne pouvez pas déterminer l’indicateur à utiliser, l’optionalld’indicateur peut être utilisée pour capturer tous les journaux de suivi.user@host#
set security policies traceoptions <flag all>
Vous pouvez également configurer un nom de fichier facultatif pour capturer les journaux.
user@host# set security policies traceoptions <filename>
Si vous avez spécifié un nom de fichier dans les options de trace, vous pouvez rechercher dans le fichier journal /var/log/<filename> si des erreurs ont été signalées dans le fichier. (Si vous n’avez pas spécifié de nom de fichier, le nom de fichier par défaut est événement.) Les messages d’erreur indiquent le lieu de la défaillance et la raison appropriée.
Après avoir configuré les options de traçage, vous devez revalider la modification de configuration à l’origine du comportement incorrect du système.
Recherche de stratégie de débogage
Problème
Descriptif
Lorsque la configuration est correcte, mais qu’une partie du trafic a été abandonnée ou autorisée par erreur, vous pouvez activer l’indicateur lookup dans les traceoptions des stratégies de sécurité. L’indicateur lookup consigne les traces liées à la recherche dans le fichier de trace.
La solution
user@host# set security policies traceoptions <flag lookup>
Synchronisation haute disponibilité (HA) du nom d’adresse Cache de résolution
Le processus de sécurité réseau (NSD) redémarre au redémarrage du système, HA basculement se produit ou si le processus se bloque. Pendant ce temps, si un grand nombre d’adresses de noms de domaine sont configurées dans les stratégies de sécurité, les pare-feu SRX tentent d’envoyer des requêtes au serveur DNS pour obtenir toutes les adresses IP résolues. L’échange d’un grand nombre de requêtes et de réponses DNS consomme une grande quantité de ressources système. Ainsi, les pare-feu SRX ne parviennent pas à obtenir de réponse du serveur DNS et l’adresse d’un nom d’hôte dans une entrée de carnet d’adresses peut ne pas se résoudre correctement. Cela peut entraîner une baisse du trafic car aucune stratégie de sécurité ou correspondance de session n’est trouvée. La nouvelle amélioration des pare-feu SRX résout ce problème en mettant en cache les résultats des requêtes DNS dans un fichier cache DNS local et en synchronisant régulièrement le fichier cache DNS d’HA nœud principal vers HA nœud de secours. Les fichiers de cache DNS stockent les adresses IP, le nom de domaine et les valeurs TTL. Après le basculement HA, le nœud de sauvegarde précédent devient le nœud principal. Étant donné que tous les résultats de cache DNS sont disponibles sur le nouveau nœud principal, le traitement des stratégies de sécurité se poursuit et le trafic pass-through est autorisé conformément aux règles de stratégie.
À partir de Junos OS version 19.3R1, la mémoire cache DNS de stratégie est synchronisée dans un fichier de cache DNS local sur le nœud actif HA et est copiée sur le nœud de sauvegarde HA pour supprimer les requêtes ou les réponses DNS lors du redémarrage de NSD.
Les étapes suivantes sont effectuées pour que la synchronisation ait lieu :
La mémoire cache DNS de stratégie est synchronisée dans un fichier de cache DNS de stratégie locale situé au chemin /var/db/policy_dns_cache toutes les 30 secondes si le contenu de la mémoire cache DNS de stratégie a changé pendant cette période.
Le fichier de cache DNS local est synchronisé du nœud principal HA vers HA nœud de secours immédiatement après la mise à jour du fichier de cache DNS local à l’étape 1.
La synchronisation inclut le contenu suivant :
-
Nom de domaine
-
Liste d’adresses IPv4 et son TTL (time to live)
-
Liste d’adresses IPv6 et leur durée de vie
Lorsque NSD redémarre, il lit et analyse le fichier cache DNS local et importe toutes les entrées de cache en mémoire. La synchronisation garantit que les requêtes DNS sont supprimées lors d’un redémarrage NSD. NSD redémarre sur le nouveau nœud principal lors du basculement HA, car les adresses IP résolues pour les noms de domaine existent déjà dans la mémoire cache DNS lors de la lecture des configurations des stratégies. Par conséquent, le nouveau trafic pass-through est autorisé conformément à la stratégie de sécurité après HA basculement, car toutes les adresses IP résolues pour les noms de domaine existent dans les stratégies sur les moteur de routage et moteur de transfert de paquets du nouveau nœud principal.
Comportement d’utilisation de la mémoire spécifique à la plate-forme
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.
Utilisez le tableau suivant pour examiner le comportement spécifique à votre plate-forme :
| Plate-forme |
Différence |
|---|---|
| SRX Series |
|