Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Messages de journal pour les clusters de châssis SRX Series

Présentation des sessions et des flux de paquets

Vous pouvez obtenir des informations sur les sessions et les flux de paquets actifs sur votre appareil, y compris des informations détaillées sur des sessions spécifiques. (L’équipement SRX Series affiche également des informations sur les sessions ayant échoué.) Vous pouvez afficher ces informations pour observer l’activité et à des fins de débogage.

Par exemple, utilisez la show security flow session commande pour :

  • Affiche la liste des flux IP entrants et sortants, y compris les services.

  • Affichez les attributs de sécurité associés à un flux, par exemple, les stratégies qui s’appliquent au trafic appartenant à ce flux.

  • Affichez la valeur du délai d’expiration de la session, la date à laquelle la session est devenue active, sa durée d’activité et la présence éventuelle de trafic actif sur la session.

Pour plus d’informations sur cette commande, reportez-vous au Guide de référence de l’interface de ligne de commande Junos OS.

Les informations de session peuvent également être consignées si une configuration de stratégie associée inclut l’option de journalisation. L’infrastructure de journalisation des sessions consigne les messages du journal des sessions lorsqu’une session est créée, fermée, refusée ou rejetée. Dans les lignes SRX3000 et SRX5000, les messages de journal sont transmis directement à un serveur/référentiel syslog externe, en contournant le moteur de routage. Les équipements SRX Series prennent en charge les syslog traditionnels et structurés. Les lignes SRX3000 et SRX5000 prennent en charge 1000 messages de journal par seconde et la station de gestion doit être équipée pour gérer ce volume. Consultez le Guide de configuration de la sécurité Junos OS pour obtenir des exemples de configuration et des détails sur ces journaux. Les journaux sont disponibles via l’interface de gestion des nœuds principal et secondaire. Assurez-vous que le serveur externe recevant ces messages de journal est accessible par les deux nœuds.

Les équipements haut de gamme de la SRX Series ont une architecture de traitement distribué qui traite le trafic et génère des messages de journal. Dans les équipements SRX Series, le pare-feu traite les sessions de trafic sur chacun des SPU du châssis. Une fois chaque session créée, elle est traitée par le même SPU dans le châssis, qui est également le SPU qui génère le message de journal.

La méthode standard de génération de messages de journal consiste à demander à chaque SPU de générer le message en tant que message syslog UDP et de l’envoyer directement sur le plan de données au serveur syslog. Les appareils SRX Series peuvent enregistrer des débits de trafic extrêmement élevés. Ils peuvent enregistrer jusqu’à 750 Mo par seconde de messages de journal, ce qui dépasse les limites du plan de contrôle. Par conséquent, nous ne recommandons pas de consigner les messages dans le plan de contrôle, sauf dans certaines circonstances.

Pour les filiales SRX Series exécutant Junos OS version 9.6 et ultérieure et les équipements SRX Series haut de gamme exécutant Junos OS version 10.0 et ultérieure, les périphériques peuvent consigner les messages sur le plan de contrôle à un débit maximal limité (1000 messages par seconde) plutôt que de se connecter au plan de données. Si les messages de journal sont envoyés via le plan de données à l’aide de syslog, un collecteur syslog, tel que Juniper Security Threat Response Manager (STRM), doit être utilisé pour collecter les journaux à des fins d’affichage, de création de rapports et d’alertes. Dans les équipements de filiale SRX Series exécutant Junos OS version 9.6 et ultérieure et les périphériques SRX Series haut de gamme exécutant Junos OS version 10.0 et ultérieure, les périphériques peuvent uniquement envoyer des messages de journal au plan de données ou au plan de contrôle, mais pas aux deux en même temps.

Configuration de la journalisation des périphériques SRX Series haut de gamme

  1. Configurez le format de journalisation.

    Deux formats sont pris en charge pour les messages du journal système : structuré et standard. Structured syslog est généralement préféré car il fait précéder les champs d’un titre. Par exemple, le champ adresse IP-source est adresse-source="10.102.110.52 » plutôt que simplement l’adresse IP 10.102.110.52. Dans la commande suivante, l’option configure syslog structuré, tandis que l’option format sd-syslog format syslog configure syslog standard.

    user@host# set security log format sd-syslog

  2. Configurez l’adresse source syslog.

    L’adresse source syslog peut être n’importe quelle adresse IP arbitraire. Il n’est pas nécessaire qu’il s’agisse d’une adresse IP attribuée à l’appareil. Cette adresse IP est plutôt utilisée sur le collecteur syslog pour identifier la source syslog. La meilleure pratique consiste à configurer l’adresse source comme adresse IP de l’interface sur laquelle le trafic est envoyé.

    user@host# set security log source-address ip-address

  3. Configurez le flux du journal système.

    Le flux du journal système identifie l’adresse IP de destination à laquelle les messages syslog sont envoyés. Sur les équipements haut de gamme de la série SRX exécutant Junos OS version 9.5 et ultérieure, il est possible de définir jusqu’à deux flux syslog (tous les messages sont envoyés aux flux syslog). Notez que vous devez donner un nom au flux. Ce nom est arbitraire, mais il est recommandé d’utiliser le nom du collecteur syslog pour faciliter l’identification dans la configuration.

    Vous pouvez également définir le port UDP auquel les messages de journal sont envoyés. Par défaut, les messages de journal sont envoyés au port UDP 1514.

    Pour configurer l’adresse IP du serveur de journaux système :

    user@host# set security log stream name host ip-address

    Pour configurer l’adresse IP du serveur de journaux système et spécifier le numéro de port UDP :

    user@host# set security log stream name host ip-address port port

Configuration de la journalisation haut de gamme du plan de données des équipements SRX Series dans le plan de contrôle

Si la station de gestion ne peut pas recevoir de messages de journal du plan de données, configurez-la pour qu’elle envoie des messages via la connexion de gestion. Si vous vous connectez au plan de contrôle, les équipements SRX Series peuvent également envoyer ces messages syslog via l’interface fxp0. Si la journalisation des événements est configurée, tous les messages du plan de données sont transmis au plan de contrôle.

  1. Configurez la journalisation des événements.

    user@host# set security log mode event

  2. Limitez le débit des messages du journal des événements.

    Il peut être nécessaire de limiter le débit des messages du journal des événements du plan de données au plan de contrôle en raison des ressources limitées sur le plan de contrôle pour traiter de gros volumes de messages de journal. Ceci est particulièrement applicable si le plan de contrôle est occupé à traiter des protocoles de routage dynamique tels que BGP ou des implémentations de routage à grande échelle. Le taux de commande suivant limite les messages de journal afin qu’ils ne surchargent pas le plan de contrôle. Les messages de journal dont le débit est limité sont ignorés. Une bonne pratique pour les équipements SRX Series haut de gamme consiste à ne pas consigner plus de 1000 messages par seconde sur le plan de contrôle.

    user@host# set security log mode event event-rate logs per second

Configuration des équipements de succursale SRX Series pour l’envoi de messages de journal de trafic via le plan de données

Les messages du journal de trafic des équipements des filiales SRX Series peuvent être envoyés via les journaux de sécurité du plan de données en mode flux. Notez que cela n’est possible qu’en utilisant le mode stream. Voici un exemple de configuration et de sortie de journal.

Configuration

Exemple de sortie de message du journal

Sep 06 16:54:26 10.204.225.164 1 2010-09-06T04:24:26.095 nsm-vidar-a RT_FLOW - RT_FLOW_SESSION_CREATE [junos@2636.1.1.1.2.39 source-address="1.1.1.2" source-port="49780" destination-address="2.1.1.1" destination-port="23" service-name="junos-telnet" nat-source-address="1.1.1.2" nat-source-port="49780" nat-destination-address="2.1.1.1" nat-destination-port="23" src-nat-rule-name="None" dst-nat-rule-name="None" protocol-id="6" policy-name="trust-untrust" source-zone-name="trust" destination-zone-name="untrust" session-id-32="208"]

Sep 06 16:54:34 10.204.225.164 1 2010-09-06T04:24:34.098 nsm-vidar-a RT_FLOW - RT_FLOW_SESSION_CLOSE [junos@2636.1.1.1.2.39 reason="TCP FIN" source-address="1.1.1.2" source-port="49780" destination-address="2.1.1.1" destination-port="23" service-name="junos-telnet" nat-source-address="1.1.1.2" nat-source-port="49780" nat-destination-address="2.1.1.1" nat-destination-port="23" src-nat-rule-name="None" dst-nat-rule-name="None" protocol-id="6" policy-name="trust-untrust" source-zone-name="trust" destination-zone-name="untrust" session-id-32="208" packets-from-client="37" bytes-from-client="2094" packets-from-server="30" bytes-from-server="1822" elapsed-time="6"]

Dans ce cas, les messages du journal de trafic du périphérique SRX Series sont envoyés à un serveur syslog externe via le plan de données. Cela garantit que le moteur de routage ne constitue pas un goulot d’étranglement pour la journalisation. Cela garantit également que le moteur de routage n’est pas affecté lors d’une journalisation excessive. Outre les messages du journal de trafic, le plan de contrôle et les messages de journal envoyés au moteur de routage sont écrits dans un fichier en mémoire flash. Voici un exemple de configuration pour activer ce type de journalisation.

Configuration

Syslog (self logs) : cette configuration peut être personnalisée en fonction de la journalisation requise self .

Journaux de trafic (à l’aide du plan de données)

Dans ce cas, les messages du journal de trafic et les messages de journal envoyés au moteur de routage sont envoyés à un serveur syslog. Voici un exemple de configuration pour activer ce type de journalisation.

Configuration

Syslog (serveur syslog)

Journaux de trafic

Configuration des journaux du plan de contrôle

Le plan de contrôle des équipements SRX Series est responsable du contrôle global de la plate-forme SRX Series, ainsi que de l’exécution d’un certain nombre de processus logiciels pour exécuter des tâches telles que les opérations du protocole de routage, les calculs de table de routage, la gestion des administrateurs, la gestion SNMP, l’authentification et de nombreuses autres fonctions critiques. Un large éventail de messages de journal sont générés sur le plan de contrôle, et le plan de contrôle offre une prise en charge granulaire pour définir les messages de journal à écrire dans les deux fichiers et à envoyer aux serveurs syslog. Cette rubrique fournit une vue d’ensemble de la configuration de diverses options syslog sur le plan de contrôle. Seule l’envoi de messages de journal via les services syslog est traité dans cette section.

  1. Configurez le serveur syslog et les messages de journal sélectionnés.

    Pour configurer le serveur syslog afin qu’il reçoive des messages de journal du périphérique SRX Series, définissez quels hôtes syslog reçoivent les flux, ainsi que les installations et les niveaux d’intérêt à envoyer. Notez que plusieurs installations et priorités peuvent être configurées pour envoyer plusieurs types de messages de journal. Pour envoyer tous les types de messages, spécifiez l’option correspondant à l’installation et à la any gravité.

    user@host# set system syslog host syslog server facility severity

  2. Configurez l’adresse IP source syslog.

    L’adresse IP source du flux syslog est nécessaire car le périphérique SRX Series peut envoyer le message syslog avec n’importe quelle adresse. La même adresse IP doit être utilisée quelle que soit l’interface sélectionnée.

    user@host# set system syslog host syslog server source-address source-address

  3. (Facultatif) Configurez la correspondance des expressions régulières.

    Parfois, un administrateur peut vouloir filtrer les messages de journal qui sont envoyés au serveur syslog. Le filtrage des journaux peut être spécifié à l’aide de l’instruction match . Dans cet exemple, seuls les journaux définis dans l’expression régulière (IDP) de l’instruction match sont envoyés au serveur syslog.

    user@host# set system syslog host syslog server facility severity match IDP

Configuration des équipements de succursale SRX Series pour la journalisation

Vous pouvez configurer le périphérique SRX Series pour qu’il envoie uniquement des journaux de trafic au serveur syslog à l’aide du plan de contrôle.

Dans cette configuration :

  • Aucun journal de sécurité n’est configuré.

  • Aucun journal de plan de contrôle n’est reçu.

Utilisez l’expression régulière de l’instruction pour envoyer uniquement des match messages du journal de trafic. Ces messages de journal sont envoyés directement au serveur syslog sans les écrire dans la mémoire flash. Cette configuration n’envoie pas les messages de journal normalement envoyés au moteur de routage au serveur syslog. Toutefois, il est possible de créer un fichier distinct et d’écrire des messages de journal de plan de contrôle dans un fichier sur le moteur de routage, comme indiqué.

Configuration

Exemples de messages du journal :

La configuration suivante envoie des messages du journal de trafic et de contrôle au serveur syslog, mais peut submerger le serveur syslog et provoquer une instabilité du cluster. Nous vous déconseillons d’utiliser cette configuration.

Configuration

Le mode d’événement du journal de sécurité est le mode par défaut sur les équipements des filiales SRX Series, et il n’est pas conseillé pour ces équipements. Nous vous recommandons de modifier le comportement par défaut.

Note:

Une journalisation étendue sur flash local peut avoir un impact indésirable sur l’appareil, tel qu’une instabilité sur le plan de contrôle.

Envoi de messages du journal du plan de données avec une adresse IP dans le même sous-réseau que l’interface fxp0

Vous souhaiterez peut-être déployer des applications et des systèmes de gestion des pannes et des performances, tels que Juniper Networks Security Threat Response Manager (STRM). STRM collecte les messages de journal via le réseau de gestion et est connecté via l’interface fxp0. Les applications de gestion des pannes et des performances gèrent l’équipement SRX Series via l’interface fxp0, mais l’équipement SRX Series doit également envoyer les messages de journal du plan de données à STRM sur le même réseau. Par exemple, si le taux de messages de journal doit être supérieur à 1000 messages de journal par seconde, la journalisation dans le plan de contrôle n’est pas prise en charge. Le problème est que deux interfaces dans le même routeur virtuel ne peuvent pas être dans le même sous-réseau et l’interface fxp0 ne peut pas être déplacée vers un routeur virtuel autre que inet.0.

Pour contourner ces problèmes, placez une interface de plan de données dans un routeur virtuel autre que le routeur virtuel par défaut inet.0 et placez un itinéraire dans la table de routage inet.0 pour acheminer le trafic vers STRM via ce routeur virtuel. L’exemple de configuration suivant montre comment procéder.

Dans cet exemple :

  • fxp0 a l’adresse IP 172.19.200.164/24.

  • L’adresse IP de l’application A (AppA) est 172.19.200.175.

  • L’adresse IP de STRM est 172.19.200.176.

  • L’interface ge-0/0/7 est une interface de plan de données, avec une adresse IP de 172.19.200.177/24 (qui se trouve dans le même sous-réseau que l’interface fxp0).

Pour configurer cet exemple, incluez les instructions suivantes :

Note:

AppA est désormais capable de gérer l’interface ge-0/0/7 puisqu’AppA gère l’appareil à l’aide de l’interface fxp0 dans l’instance de routage par défaut. Pour ce faire, AppA doit utiliser le format de message Logging@<snmp-community-string-name> pour accéder aux données de l’interface ge-0/0/7 à l’aide de SNMP.

Documentation connexe