Chiffrer le trafic à l’aide du proxy SSL et du protocole TLS
Le proxy SSL agit en tant qu’intermédiaire, effectuant le cryptage et le déchiffrement SSL entre le client et le serveur. Une meilleure visibilité sur l’utilisation des applications peut être obtenue lorsque le proxy de transfert SSL est activé.
Présentation du proxy SSL
Le proxy SSL est uniquement pris en charge sur les pare-feu SRX Series.
Secure Sockets Layer (SSL) est un protocole d’application qui fournit une technologie de cryptage pour Internet. SSL, également appelé sécurité couche transport (TLS), assure la transmission sécurisée de données entre un client et un serveur grâce à une combinaison de confidentialité, d’authentification, de confidentialité et d’intégrité des données. SSL s’appuie sur des certificats et des paires d’échange de clés privées-publiques pour ce niveau de sécurité.
Le proxy SSL est un proxy transparent qui effectue le cryptage et le déchiffrement SSL entre le client et le serveur.
- Comment fonctionne le proxy SSL ?
- Proxy SSL avec applications Security Services
- Types de proxy SSL
- Protocoles SSL pris en charge
- Avantages du proxy SSL
- Prise en charge des systèmes logiques
- Limitations
Comment fonctionne le proxy SSL ?
Le proxy SSL assure une transmission sécurisée des données entre un client et un serveur grâce à la combinaison des éléments suivants :
Authentification : l’authentification du serveur protège contre les transmissions frauduleuses en permettant à un navigateur Web de valider l’identité d’un serveur Web.
Confidentialité - SSL renforce la confidentialité en cryptant les données afin d’empêcher les utilisateurs non autorisés d’écouter les communications électroniques. garantit ainsi la confidentialité des communications.
Intégrité : l’intégrité des messages garantit que le contenu d’une communication n’est pas altéré.
Le pare-feu SRX Series agissant comme proxy SSL gère les connexions SSL entre le client à une extrémité et le serveur à l’autre extrémité et effectue les actions suivantes :
Session SSL entre le client et la gamme SRX Series : met fin à une connexion SSL à partir d’un client lorsque les sessions SSL sont initiées entre le client et le serveur. Le pare-feu SRX Series déchiffre le trafic, l’inspecte pour détecter les attaques (dans les deux sens) et établit la connexion au serveur au nom des clients.
Session SSL entre le serveur et la gamme SRX Series - Met fin à une connexion SSL à partir d’un serveur lorsque les sessions SSL sont lancées entre le serveur externe et le serveur local. Le pare-feu SRX Series reçoit du texte clair du client, chiffre et transmet les données sous forme de texte chiffré au serveur SSL. D’autre part, la SRX Series déchiffre le trafic du serveur SSL, l’inspecte pour détecter les attaques et envoie les données au client sous forme de texte clair.
Permet d’inspecter le trafic chiffré.
Le serveur proxy SSL assure la transmission sécurisée des données grâce à la technologie de cryptage. SSL s’appuie sur des certificats et des paires d’échange de clés privées-publiques pour fournir une communication sécurisée. Pour plus d’informations, reportez-vous à la section Certificats SSL.
Pour établir et maintenir une session SSL entre le pare-feu SRX Series et son client/serveur, le pare-feu SRX Series applique une stratégie de sécurité au trafic qu’il reçoit. Lorsque le trafic correspond aux critères de la stratégie de sécurité, le proxy SSL est activé en tant que service d’application dans une stratégie de sécurité.
Proxy SSL avec applications Security Services
La figure 1 illustre le fonctionnement du proxy SSL sur une charge utile chiffrée.
utile chiffrée
Lorsque des services de sécurité avancée tels que le pare-feu d’applications (AppFW), la détection et prévention d’intrusion (IDP), le suivi des applications (AppTrack), la sécurité du contenu et ATP Cloud sont configurés, le proxy SSL agit comme un serveur SSL en mettant fin à la session SSL du client et en établissant une nouvelle session SSL sur le serveur. Le pare-feu SRX Series déchiffre puis rechiffre tout le trafic proxy SSL.
IDP, AppFW, AppTracking, le routage avancé basé sur des stratégies (APBR), la sécurité du contenu, ATP Cloud et la redirection de service ICAP peuvent utiliser le contenu déchiffré du proxy SSL. Si aucun de ces services n’est configuré, les services de proxy SSL sont ignorés, même si un profil de proxy SSL est attaché à une stratégie de pare-feu.
Types de proxy SSL
Le proxy SSL est un proxy transparent qui effectue le cryptage et le déchiffrement SSL entre le client et le serveur. SRX joue le rôle de serveur du point de vue du client et il agit en tant que client du point de vue du serveur. Sur les pare-feu SRX Series, la protection du client (proxy direct) et la protection du serveur (proxy inverse) sont prises en charge en utilisant le même système d’écho SSL-T-SSL [terminateur côté client] et SSL-I-SSL [initiateur côté serveur]).
Le pare-feu SRX Series prend en charge les types de proxy SSL suivants :
Proxy SSL de protection du client, également appelé proxy de transfert—Le pare-feu SRX Series réside entre le client interne et le serveur externe. Session sortante proxy, c’est-à-dire session SSL initiée localement vers Internet. Il décrypte et inspecte le trafic des utilisateurs internes vers le Web.
Proxy SSL de protection serveur également appelé proxy inverse : le pare-feu SRX Series réside entre le serveur interne et le client externe. Session entrante par proxy, c’est-à-dire sessions SSL initiées en externe depuis Internet vers le serveur local.
Pour plus d’informations sur le proxy de transfert SSL et le proxy inverse, consultez Configuration du proxy SSL.
Protocoles SSL pris en charge
Les protocoles SSL suivants sont pris en charge sur les pare-feu SRX Series pour le service d’initiation et de terminaison SSL :
TLS version 1.0 : fournit l’authentification et des communications sécurisées entre les applications qui communiquent.
TLS version 1.1 : cette version améliorée de TLS offre une protection contre les attaques CBC (Cipher Block Chaining).
TLS version 1.2 : cette version améliorée de TLS offre une plus grande flexibilité pour la négociation d’algorithmes cryptographiques.
-
TLS version 1.3 : cette version améliorée de TLS offre une sécurité améliorée et de meilleures performances.
À partir de Junos OS version 15.1X49-D30 et Junos OS version 17.3R1, les protocoles TLS version 1.1 et TLS version 1.2 sont pris en charge sur les pare-feu SRX Series avec TLS version 1.0.
À partir de Junos OS version 15.1X49-D20 et Junos OS version 17.3R1, la prise en charge du protocole SSL 3.0 (SSLv3) est déconseillée.
À partir de Junos OS version 21.2R1, sur les pare-feu SRX Series, le proxy SSL prend en charge TLS version 1.3.
Lorsque vous utilisez TLS 1.3, le pare-feu SRX Series prend en charge le groupe secp256r1 pour l’échange de clés afin d’établir la connexion avec le serveur. Si le serveur ne prend en charge que secp384r1, la connexion sera interrompue.
Avantages du proxy SSL
Déchiffre le trafic SSL pour obtenir des informations granulaires sur les applications, vous permettre d’appliquer une protection des services de sécurité avancés et de détecter les menaces.
Applique l’utilisation de protocoles et de chiffrements forts par le client et le serveur.
Offre une visibilité et une protection contre les menaces intégrées dans le trafic chiffré SSL.
Contrôle ce qui doit être déchiffré à l’aide du proxy SSL sélectif.
Prise en charge des systèmes logiques
Il est possible d’activer le proxy SSL sur les politiques de pare-feu configurées à l’aide de systèmes logiques ; Toutefois, tenez compte des limitations suivantes :
La catégorie « services » n’est actuellement pas prise en charge dans la configuration des systèmes logiques. Étant donné que le proxy SSL se trouve sous « services », vous ne pouvez pas configurer les profils de proxy SSL par système logique.
Étant donné que les profils proxy configurés au niveau global (dans « Services SSL proxy ») sont visibles dans toutes les configurations de systèmes logiques, il est possible de configurer des profils proxy au niveau global, puis de les attacher aux stratégies de pare-feu d’un ou plusieurs systèmes logiques.
Limitations
Sur tous les pare-feu SRX Series, l’implémentation actuelle du proxy SSL présente les limitations de connectivité suivantes :
La prise en charge du protocole SSLv3.0 est déconseillée.
Le protocole SSLv2 n’est pas pris en charge. Les sessions SSL utilisant SSLv2 sont abandonnées.
Seul le certificat X.509v3 est pris en charge.
L’authentification client de l’établissement de liaison SSL n’est pas prise en charge.
Les sessions SSL pour lesquelles l’authentification par certificat client est obligatoire sont abandonnées.
Les sessions SSL dans lesquelles une renégociation est demandée sont abandonnées.
Sur les pare-feu SRX Series, pour une session donnée, le proxy SSL n’est activé que si une fonctionnalité pertinente liée au trafic SSL est également activée. Les fonctionnalités associées au trafic SSL sont l’IDP, l’identification des applications, le pare-feu des applications, le suivi des applications, le routage avancé basé sur des stratégies, la sécurité du contenu, ATP Cloud et le service de redirection ICAP. Si aucune de ces fonctionnalités n’est active sur une session, le proxy SSL contourne la session et les journaux ne sont pas générés dans ce scénario.
Voir aussi
Configuration du proxy de transfert SSL
- Présentation de la configuration du proxy SSL
- Configuration d’un certificat d’autorité de certification racine
- Générer un certificat d’autorité de certification racine avec CLI
- Configuration d’un groupe de profils d’autorité de certification
- Importation d’un certificat d’autorité de certification racine dans un navigateur
- Application d’un profil proxy SSL à une stratégie de sécurité
- Configuration de la journalisation du proxy SSL
- Configuration des profils d’autorité de certification
- Exportation de certificats vers un emplacement spécifié
- Ignorer l’authentification du serveur
Présentation de la configuration du proxy SSL
La configuration du proxy de transfert SSL affiche une vue d’ensemble de la configuration du proxy SSL. La configuration du proxy SSL comprend :
-
Configuration du certificat de l’autorité de certification racine
-
Chargement d’un groupe de profils d’autorité de certification
-
Configurer le profil proxy SSL et associer le certificat d’autorité de certification racine et le groupe de profils d’autorité de certification
-
Créer une stratégie de sécurité en définissant des critères de correspondance du trafic d’entrée
-
Application d’un profil proxy SSL à une stratégie de sécurité
-
Étapes facultatives telles que la création de listes d’autorisation et la journalisation du proxy SSL
Configuration d’un certificat d’autorité de certification racine
Une autorité de certification peut émettre plusieurs certificats sous la forme d’une arborescence. Un certificat racine est le certificat le plus haut de l’arborescence, dont la clé privée est utilisée pour sign d’autres certificats. Tous les certificats immédiatement inférieurs au certificat racine héritent de la signature ou de la fiabilité du certificat racine. C’est un peu comme celui notarizing d’une identité.
Vous pouvez configurer un certificat d’autorité de certification racine en obtenant d’abord un certificat d’autorité de certification racine (en générant un auto-signé ou en en important un), puis en l’appliquant à un profil proxy SSL. Vous pouvez obtenir un certificat d’autorité de certification racine à l’aide de la CLI Junos OS
Générer un certificat d’autorité de certification racine avec CLI
Pour définir un certificat auto-signé dans l’interface de ligne de commande, vous devez fournir les informations suivantes :
Identificateur de certificat (généré à l’étape précédente)
Nom de domaine complet (FQDN) pour le certificat
Adresse e-mail de l’entité propriétaire du certificat
Nom commun et organisation impliquée
Générez un certificat d’autorité de certification racine à l’aide de l’interface de ligne de commande Junos OS :
Configuration d’un groupe de profils d’autorité de certification
Le profil de l’autorité de certification définit les informations de certificat pour l’authentification. Il inclut la clé publique que le proxy SSL utilise lors de la génération d’un nouveau certificat. Junos OS vous permet de créer un groupe de profils d’autorités de certification et de charger plusieurs certificats en une seule action, d’afficher des informations sur tous les certificats d’un groupe et de supprimer les groupes d’autorités de certification indésirables.
Vous pouvez charger un groupe de profils d’autorités de certification en obtenant une liste de certificats d’autorité de certification approuvés, en définissant un groupe d’autorités de certification et en attachant le groupe d’autorités de certification au profil proxy SSL.
Vous pouvez facilement afficher des informations sur tous les certificats d’un groupe de profils d’autorité de certification :
user@host> show security pki ca-certificates ca-profile-group group-name
Vous pouvez supprimer un groupe de profils d’autorité de certification. N’oubliez pas que la suppression d’un groupe de profils d’autorité de certification supprime tous les certificats qui appartiennent à ce groupe :
user@host> clear security pki ca-certificates ca-profile-group group-name
Importation d’un certificat d’autorité de certification racine dans un navigateur
Pour que votre navigateur ou votre système approuve automatiquement tous les certificats signés par l’autorité de certification racine configurée dans le profil proxy SSL, vous devez demander à votre plate-forme ou à votre navigateur de faire confiance au certificat racine de l’autorité de certification.
Pour importer un certificat d’autorité de certification racine :
Application d’un profil proxy SSL à une stratégie de sécurité
Le proxy SSL est activé en tant que service d’application dans le cadre d’une stratégie de sécurité. Dans une stratégie de sécurité, vous spécifiez le trafic sur lequel vous souhaitez que le proxy SSL soit activé en tant que critère de correspondance, puis spécifiez le profil d’autorité de certification du proxy SSL à appliquer au trafic. La figure 2 présente une vue graphique du profil de proxy SSL et de la configuration de la stratégie de sécurité.
Pour activer le proxy SSL dans une stratégie de sécurité :
Cet exemple suppose que vous avez déjà créé des zones de confiance et de non-confiance et que vous avez créé une stratégie de sécurité pour le trafic de la zone de confiance vers la zone d’approbation.
Configuration de la journalisation du proxy SSL
Lors de la configuration du proxy SSL, vous pouvez choisir de définir l’option de réception d’une partie ou de la totalité des journaux. Les journaux de proxy SSL contiennent le nom du système logique, les listes d’autorisation du proxy SSL, les informations de stratégie, les informations de proxy SSL et d’autres informations qui vous aident à résoudre les problèmes en cas d’erreur.
Vous pouvez configurer la journalisation ou all des événements spécifiques, tels que les événements d’erreur, d’avertissement et d’information. Vous pouvez également configurer la journalisation des sessions qui sont ajoutées à la liste d’autorisation, abandonnées, ignorées ou autorisées après l’apparition d’une erreur.
[edit] user@host# set services ssl proxy profile profile-name actions log all user@host# set services ssl proxy profile profile-name actions log sessions-whitelisted user@host# set services ssl proxy profile profile-name actions log sessions-allowed user@host# set services ssl proxy profile profile-name actions log errors
Vous pouvez utiliser l’option enable-flow-tracing pour activer le suivi de débogage.
Configuration des profils d’autorité de certification
La configuration d’un profil d’autorité de certification contient des informations spécifiques à une autorité de certification. Vous pouvez avoir plusieurs profils d’autorité de certification sur un pare-feu SRX Series. Par exemple, vous pouvez avoir un profil pour orgA et un autre pour orgB. Chaque profil est associé à un certificat d’autorité de certification. Si vous souhaitez charger un nouveau certificat d’autorité de certification sans supprimer l’ancien, créez un nouveau profil d’autorité de certification (par exemple, Microsoft-2008). Vous pouvez regrouper plusieurs profils d’autorités de certification dans un groupe d’autorités de certification de confiance pour une topologie donnée.
Dans cet exemple, vous créez un profil d’autorité de certification appelé ca-profile-security avec l’identité d’autorité de certification microsoft-2008. Vous créez ensuite un profil proxy pour le profil de l’autorité de certification.
Exportation de certificats vers un emplacement spécifié
Lorsqu’un certificat auto-signé est généré à l’aide d’une commande PKI, le certificat nouvellement généré est stocké dans un emplacement prédéfini (var/db/certs/common/local).
Utilisez la commande suivante pour exporter le certificat vers un emplacement spécifique (dans l’appareil). Vous pouvez spécifier l’ID de certificat, le nom du fichier et le type de format de fichier (DER/PEM) :
user@host> request security pki local-certificate export certificate-id certificate-id filename filename type der
Ignorer l’authentification du serveur
Junos OS vous permet de configurer une option pour ignorer complètement l’authentification du serveur. Si vous configurez votre système pour ignorer l’authentification, toutes les erreurs rencontrées lors de la vérification du certificat du serveur au moment de l’établissement de liaison SSL sont ignorées. Parmi les erreurs couramment ignorées, citons l’impossibilité de vérifier la signature de l’autorité de certification, les dates d’expiration des certificats incorrectes, etc. Si cette option n’est pas définie, toutes les sessions dans lesquelles le serveur envoie des certificats auto-signés sont abandonnées en cas d’erreur.
Nous vous déconseillons d’utiliser cette option pour l’authentification, car sa configuration entraîne l’absence totale d’authentification des sites Web. Toutefois, vous pouvez utiliser cette option pour identifier efficacement la cause racine des sessions SSL interrompues.
À partir du mode de configuration, spécifiez d’ignorer l’authentification du serveur :
[edit] user@host# set services ssl proxy profile profile-name actions ignore-server-auth-failure
Activation du débogage et du suivi pour le proxy SSL
Le suivi de débogage sur le moteur de routage et le moteur de transfert de paquets peut être activé pour le proxy SSL en définissant la configuration suivante :
user@host# set services ssl traceoptions file file-name
Le proxy SSL est pris en charge sur les équipements SRX340, SRX345, SRX380, SRX550M, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, SRX5800 et les instances Pare-feu virtuel vSRX. Le Tableau 1 indique les niveaux pris en charge pour les options de traçage.
Cause Type |
Description |
|---|---|
Bref |
Traces d’erreur uniquement sur le moteur de routage et le moteur de transfert de paquets. |
Détail |
Moteur de transfert de paquets : seuls les détails de l’événement jusqu’à l’établissement de liaison doivent être tracés. Moteur de routage : traces liées à la validation. Aucune trace périodique sur le moteur de routage ne sera disponible |
Vaste |
Moteur de transfert de paquets – Récapitulatif du transfert de données disponible. Moteur de routage : traces liées à la validation (plus étendues). Aucune trace périodique sur le moteur de routage ne sera disponible. |
Verbose |
Toutes les traces sont disponibles. |
Le tableau 2 indique les indicateurs pris en charge.
Cause Type |
Description |
|---|---|
configuration de l’interface de ligne de commande |
Traces liées à la configuration uniquement. |
Initiation |
Activez le traçage sur le plug-in SSL-I. |
Proxy |
Activez le suivi sur le plug-in SSL-Proxy-Policy. |
Résiliation |
Activez le traçage sur le plug-in SSL-T. |
profil sélectionné |
Activez le suivi uniquement pour les profils définis enable-flow-tracing . |
Vous pouvez activer les journaux dans le profil proxy SSL pour trouver la cause racine de la perte. Les erreurs suivantes sont parmi les plus courantes :
Erreur de validation de la certification du serveur. Vérifiez la configuration de l’autorité de certification approuvée pour vérifier votre configuration.
Les défaillances du système, telles que les échecs d’allocation de mémoire.
Les chiffrements ne correspondent pas.
Les versions SSL ne correspondent pas.
Les options SSL ne sont pas prises en charge.
L’autorité de certification racine a expiré. Vous devez charger une nouvelle autorité de certification racine.
Vous pouvez activer l’option dans le profil proxy SSL pour vous assurer que la validation du certificat, les dates d’expiration de l’autorité de certification racine et d’autres ignore-server-auth-failure problèmes de ce type sont ignorés. Si les sessions sont inspectées après l’activation de l’option ignore-server-auth-failure , le problème est localisé.
Voir aussi
Présentation de la sécurité de la couche transport (TLS)
La sécurité de la couche couche transport (TLS) est un protocole applicatif qui fournit une technologie de chiffrement pour Internet. TLS s’appuie sur des certificats et des paires d’échange de clés privées-publiques pour ce niveau de sécurité. Il s’agit du protocole de sécurité le plus largement utilisé pour les applications qui nécessitent que les données soient échangées en toute sécurité sur un réseau, telles que les transferts de fichiers, les connexions VPN, la messagerie instantanée et la voix sur IP (VoIP).
Le protocole TLS est utilisé pour l’échange de certificats, l’authentification mutuelle et la négociation de chiffrements afin de protéger le flux contre toute altération et écoute clandestine. TLS est parfois appelé Secure Sockets Layer (SSL). TLS et SSL ne sont pas interopérables, bien que TLS offre actuellement une certaine rétrocompatibilité.
Les pare-feu SRX Series fournissent une inspection TLS qui utilise la suite de protocoles TLS composée de différentes versions TLS, chiffrements et méthodes d’échange de clés. La fonctionnalité d’inspection TLS permet aux pare-feu SRX Series d’inspecter le trafic HTTP chiffré dans TLS sur n’importe quel port.
- Avantages de TLS
- TLS Versions
- Trois services essentiels de TLS
- Établissement de liaison TLS
- Chiffrement du trafic Syslog avec TLS
Avantages de TLS
TLS garantit la transmission sécurisée des données entre un client et un serveur grâce à une combinaison de confidentialité, d’authentification, de confidentialité et d’intégrité des données.
TLS Versions
Voici les versions de TLS :
TLS version 1.0 : fournit une communication sécurisée sur les réseaux en assurant la confidentialité et l’intégrité des données entre les applications qui communiquent
TLS version 1.1 : cette version améliorée de TLS offre une protection contre les attaques CBC (Cipher-Block Chaining).
TLS version 1.2 : cette version améliorée de TLS offre une plus grande flexibilité pour la négociation d’algorithmes cryptographiques.
Depuis Junos OS version 12.3X48-D30, les pare-feu SRX Series prennent en charge TLS version 1.2. Les pare-feu SRX Series exécutant la version antérieure 12.3X48-D30 prennent en charge TLS version 1.0.
Trois services essentiels de TLS
Le protocole TLS est conçu pour fournir trois services essentiels aux applications qui s’exécutent au-dessus de lui : le chiffrement, l’authentification et l’intégrité des données.
Chiffrement : afin d’établir un canal de données cryptographiquement sécurisé, le serveur et le client doivent se mettre d’accord sur les suites de chiffrement utilisées et les clés utilisées pour chiffrer les données. Le protocole TLS spécifie une séquence d’établissement de liaison bien définie pour effectuer cet échange. TLS utilise la cryptographie à clé publique, ce qui permet au client et au serveur de négocier une clé secrète partagée sans avoir à établir une connaissance préalable l’un de l’autre, et de le faire via un canal non chiffré.
Authentification : dans le cadre de l’établissement de liaison TLS, le protocole permet au serveur et au client d’authentifier leur identité. La confiance implicite entre le client et le serveur (car le client accepte le certificat généré par le serveur) est un aspect important de TLS. Il est extrêmement important que l’authentification du serveur ne soit pas compromise ; Cependant, dans la réalité, les certificats auto-signés et les certificats présentant des anomalies sont abondants. Les anomalies peuvent inclure des certificats expirés, des instances de nom commun ne correspondant pas à un nom de domaine, etc.
Intégrité : une fois le chiffrement et l’authentification en place, le protocole TLS exécute le mécanisme de tramage des messages et signe chaque message avec un code d’authentification de message (MAC). L’algorithme MAC effectue la somme de contrôle effective, et les clés sont négociées entre le client et le serveur.
Établissement de liaison TLS
Chaque session TLS commence par une négociation au cours de laquelle le client et le serveur se mettent d’accord sur la clé de sécurité spécifique et les algorithmes de chiffrement à utiliser pour cette session. À ce stade, le client authentifie également le serveur. Si vous le souhaitez, le serveur peut authentifier le client. Une fois l’établissement de liaison terminé, le transfert des données chiffrées peut commencer.
Chiffrement du trafic Syslog avec TLS
Le protocole TLS garantit que les messages syslog sont envoyés et reçus en toute sécurité sur le réseau. TLS utilise des certificats pour authentifier et chiffrer la communication. Le client authentifie le serveur en demandant son certificat et sa clé publique. En option, le serveur peut également demander un certificat au client, ce qui permet également une authentification mutuelle.
Un certificat sur le serveur qui identifie le serveur et le certificat de l’autorité de certification (CA) émis par le serveur doivent être disponibles avec le client pour que TLS puisse chiffrer le trafic syslog.
Pour l’authentification mutuelle du client et du serveur, un certificat avec le client qui identifie le client et le certificat de l’autorité de certification émis par le client doivent être disponibles sur le serveur. L’authentification mutuelle garantit que le serveur syslog n’accepte que les messages de journal provenant de clients autorisés.
Voir aussi
configuration du protocole TLS Syslog sur pare-feu SRX Series
Cet exemple montre comment configurer le protocole syslog TLS (couche transport security) sur les pare-feu SRX Series pour recevoir des événements syslog chiffrés des périphériques réseau prenant en charge le transfert d’événements syslog TLS.
Exigences
Avant de commencer, activez les fonctionnalités de vérification et de chiffrement ou de déchiffrement des certificats du serveur.
Aperçu
Le protocole syslog TLS permet aux sources de journaux de recevoir des événements syslog chiffrés à partir de périphériques réseau prenant en charge le transfert d’événements syslog TLS. La source du journal crée un port d’écoute pour les événements syslog TLS entrants et génère un fichier de certificat pour les périphériques réseau.
Dans cet exemple, vous allez configurer un collecteur syslog associé à un profil SSL-I. Chaque profil SSL-I permet à l’utilisateur de spécifier des éléments tels que la suite de chiffrements préférée et les certificats d’autorité de certification de confiance. Plusieurs profils SSL-I peuvent être configurés et associés à différents serveurs collecteurs.
Configuration
Procédure
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cette section de l’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.
set security log mode stream set security log format sd-syslog set security log source-interface ge-0/0/1.0 set security log transport protocol tls set security log transport tls-profile ssl-i-tls set security log stream server1 format sd-syslog set security log stream server1 category all set security log stream server1 host 192.0.2.100 set services ssl initiation profile ssl-i-tls protocol-version all set services ssl initiation profile ssl-i-tls trusted-ca all set services ssl initiation profile ssl-i-tls actions ignore-server-auth-failure
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 façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.
Pour configurer le protocole syslog TLS :
Définissez le mode de journalisation sur streaming.
[edit security] user@host# set log mode stream
Définissez le format de la journalisation des messages de sécurité à distance sur sd-syslog (journal système structuré).
[edit security] user@host# set log format sd-syslog
Définissez le numéro de l’interface source de l’hôte.
[edit security] user@host# set log source-interface ge-0/0/1.0
Définissez le protocole de transport du journal de sécurité tls à utiliser pour consigner les données.
[edit security] user@host# set log transport protocol tls
Spécifiez le nom du profil TLS.
[edit security] user@host# set log transport tls-profile ssl-i-tls
Définissez le flux de journaux pour qu’il utilise le format syslog structuré pour l’envoi des journaux au serveur 1.
[edit security] user@host# set log stream server1 format sd-syslog
Définissez la catégorie de journalisation du serveur 1 sur all .
[edit security] user@host# set log stream server1 category all
Définissez les paramètres de l’hôte du serveur en saisissant le nom du serveur ou l’adresse IP.
[edit security] user@host# set log stream server1 host 192.0.2.100
Définissez la version du protocole pour le profil d’accès à l’initiation SSL.
[edit services] user@host# set ssl initiation profile ssl-i-tls protocol-version all
Attachez tous les groupes de profils d’autorité de certification au profil d’initiation SSL à utiliser lors de la demande d’un certificat à l’homologue.
[edit services] user@host# set ssl initiation profile ssl-i-tls trusted-ca all
Définissez le profil d’accès à l’initiation SSL pour ignorer l’échec de l’authentification du serveur.
[edit services] user@host# set ssl initiation profile ssl-i-tls actions ignore-server-auth-failure
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security log commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show security log
mode stream;
format sd-syslog;
source-interface ge-0/0/1.0;
transport {
protocol tls;
tls-profile ssl-i-tls;
}
stream server1 {
format sd-syslog;
category all;
host {
192.0.2.100;
}
}
}
[edit]
user@host# run show configuration services ssl initiation
profile ssl-i-tls {
protocol-version all;
trusted-ca all;
actions {
ignore-server-auth-failure;
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Pour vérifier que la configuration fonctionne correctement, entrez la show log commande sur le serveur syslog.