Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Sur cette page
 

Présentation de l’accès distant

Vous (l’administrateur réseau) pouvez accéder à distance à un routeur, un commutateur ou un équipement de sécurité à l’aide de services tels que DHCP, Finger, FTP, rlogin, SSH et Telnet. Cette rubrique vous montre comment configurer l’accès à distance à l’aide des services Telnet, SSH, FTP et Finger.

Présentation des services système

Pour des raisons de sécurité, l’accès à distance au routeur est désactivé par défaut. Vous devez configurer le routeur explicitement afin que les utilisateurs de systèmes distants puissent y accéder. Les utilisateurs peuvent accéder au routeur à partir d’un système distant au moyen des services DHCP, finger, FTP, rlogin, SSH et Telnet. En outre, les applications clientes du protocole XML Junos peuvent utiliser, entre autres, le protocole SSL (Secure Sockets Layer) ou le service de texte clair spécifique au protocole XML Junos.

REMARQUE :

Pour protéger les ressources système, vous pouvez limiter le nombre de connexions simultanées acceptées par un service et le nombre de processus appartenant à un seul utilisateur. Si l’une ou l’autre des limites est dépassée, les tentatives de connexion échouent.

Configurer le service Telnet pour l’accès à distance à un routeur ou à un commutateur

Pour configurer le routeur ou le commutateur afin qu’il accepte Telnet en tant que service d’accès, incluez l’instruction suivante telnet au niveau de la [edit system services] hiérarchie :

Par défaut, le routeur ou le commutateur prend en charge un nombre limité de sessions Telnet simultanées et de tentatives de connexion par minute.

Si vous le souhaitez, vous pouvez inclure l’une ou l’autre des instructions suivantes, ou les deux, pour modifier les valeurs par défaut :

  • connection-limit limit: nombre maximal de connexions simultanées par protocole (IPV4 et IPv6). La plage va de 1 à 250. La valeur par défaut est 75. Lorsque vous configurez une limite de connexion, celle-ci s’applique au nombre de sessions telnet par protocole (IPv4 et IPv6). Par exemple, une limite de connexion de 10 autorise 10 sessions Telnet IPv6 et 10 sessions Telnet IPv4.

  • rate-limit limit: nombre maximal de tentatives de connexion acceptées par minute (de 1 à 250). La valeur par défaut est 150. Lorsque vous configurez une limite de débit, celle-ci s’applique au nombre de tentatives de connexion par protocole (IPv4 et IPv6). Par exemple, une limite de débit de 10 autorise 10 tentatives de connexion de session telnet IPv6 par minute et 10 tentatives de connexion de session telnet IPv4 par minute.

Vous ne pouvez pas inclure l’instruction telnet sur les périphériques qui exécutent le logiciel Junos-FIPS. Nous vous recommandons de ne pas utiliser Telnet dans un environnement de Critères communs.

Configurer le service FTP pour l’accès à distance au routeur ou au commutateur

Pour configurer l’appareil afin qu’il accepte FTP en tant que service d’accès, incluez l’instruction au ftp niveau de la [edit system services] hiérarchie :

Par défaut, le routeur ou le commutateur prend en charge un nombre limité de sessions FTP simultanées et de tentatives de connexion par minute. Vous pouvez inclure l’une ou l’autre des instructions suivantes, ou les deux, pour modifier les valeurs par défaut :

  • connection-limit limit: nombre maximal de connexions simultanées par protocole (IPV4 et IPv6). La valeur est comprise entre 1 et 250. La valeur par défaut est 75. Lorsque vous configurez une limite de connexion, celle-ci s’applique au nombre de sessions par protocole (IPv4 et IPv6). Par exemple, une limite de connexion de 10 autorise 10 sessions FTP IPv6 et 10 sessions FTP IPv4.

  • rate-limit limit: nombre maximal de tentatives de connexion acceptées par minute (valeur comprise entre 1 et 250). La valeur par défaut est 150. Lorsque vous configurez une limite de débit, celle-ci s’applique au nombre de tentatives de connexion par protocole (IPv4 et IPv6). Par exemple, une limite de débit de 10 autorise 10 tentatives de connexion de session FTP IPv6 et 10 tentatives de connexion de session FTP IPv4.

Vous pouvez utiliser le FTP passif pour accéder aux appareils qui n’acceptent que les services FTP passifs. Toutes les commandes et instructions qui utilisent FTP acceptent également le FTP passif. Incluez l’instruction ftp au niveau de la [edit system services] hiérarchie pour utiliser un FTP actif ou passif.

Pour démarrer une session FTP passive, utilisez pasvftp (au lieu de ftp ) au format FTP standard (ftp://destination). Par exemple :

Vous ne pouvez pas inclure cette ftp instruction sur les routeurs ou commutateurs qui exécutent le logiciel Junos-FIPS. Nous vous recommandons de ne pas utiliser le service FTP dans un environnement Critères communs.

Configurer le service Finger pour l’accès à distance au routeur

Pour configurer le routeur afin qu’il accepte finger en tant que service d’accès, incluez l’instruction finger au niveau de la [edit system services] hiérarchie :

Par défaut, le routeur prend en charge un nombre limité de sessions digitales simultanées et de tentatives de connexion par minute. Si vous le souhaitez, vous pouvez inclure l’une ou l’autre des instructions suivantes, ou les deux, pour modifier les valeurs par défaut :

  • connection-limit limit: nombre maximal de connexions simultanées par protocole (IPv4 et IPv6). La valeur est comprise entre 1 et 250. La valeur par défaut est 75. Lorsque vous configurez une limite de connexion, celle-ci s’applique au nombre de sessions par protocole (IPv4 et IPv6). Par exemple, une limite de connexion de 10 autorise 10 sessions de service de texte clair IPv6 et 10 sessions de service de texte clair IPv4

  • rate-limit limit: nombre maximal de tentatives de connexion acceptées par minute (valeur comprise entre 1 et 250). La valeur par défaut est 150. Lorsque vous configurez une limite de débit, celle-ci s’applique au nombre de tentatives de connexion par protocole (IPv4 et IPv6). Par exemple, une limite de débit de 10 autorise 10 tentatives de connexion de session IPv6 par minute et 10 tentatives de connexion de session IPv4 par minute.

Vous ne pouvez pas inclure l’instruction finger sur les routeurs qui exécutent le logiciel Junos-FIPS. Nous vous recommandons de ne pas utiliser le service finger dans un environnement de Critères communs.

Configurer le service SSH pour l’accès à distance au routeur ou au commutateur

Pour configurer le routeur ou le commutateur afin qu’il accepte SSH en tant que service d’accès, incluez l’instruction suivante ssh au niveau de la [edit system services] hiérarchie :

Par défaut, le routeur ou le commutateur prend en charge un nombre limité de sessions SSH simultanées et de tentatives de connexion par minute. Utilisez les instructions suivantes pour modifier les valeurs par défaut :

  • connection-limit limit: nombre maximal de connexions simultanées par protocole (IPv4 et IPv6). La valeur est comprise entre 1 et 250. La valeur par défaut est 75. Lorsque vous configurez une limite de connexion, celle-ci s’applique au nombre de sessions SSH par protocole (IPv4 et IPv6). Par exemple, une limite de connexion de 10 autorise 10 sessions SSH IPv6 et 10 sessions SSH IPv4.

  • max-sessions-per-connection number: incluez cette instruction pour spécifier le nombre maximal de sessions SSH autorisées par connexion SSH. Cela vous permet de limiter le nombre de sessions clonées tunnelisées au sein d’une seule connexion SSH. La valeur par défaut est 10.

  • rate-limit limit: nombre maximal de tentatives de connexion acceptées par minute (valeur comprise entre 1 et 250). La valeur par défaut est 150. Lorsque vous configurez une limite de débit, celle-ci s’applique au nombre de tentatives de connexion par protocole (IPv4 et IPv6). Par exemple, une limite de débit de 10 autorise 10 tentatives de connexion de session SSH IPv6 par minute et 10 tentatives de connexion de session SSH IPv4 par minute.

  • data-limit—Limite de données avant la renégociation des clés de session (octets)

  • time-limit—Limite de temps avant la renégociation des clés de session (minutes)

À partir de Junos OS version 19.4R1 et Junos OS version 17.4R3, vous pouvez désactiver le mot de passe de connexion SSH ou l’authentification défi-réponse à l’aide des no-password-authentication options et no-challenge-response au niveau de la hiérarchie [edit system services ssh].

Par défaut, un utilisateur peut créer un tunnel SSH via une session CLI vers un routeur exécutant Junos OS via SSH. Ce type de tunnel peut être utilisé pour transférer le trafic TCP, en contournant les filtres de pare-feu ou les listes de contrôle d’accès. En contournant les filtres de pare-feu ou les listes de contrôle d’accès, ce type de tunnel permet d’accéder aux ressources au-delà du routeur. Utilisez cette no-tcp-forwarding option pour empêcher un utilisateur de créer un tunnel SSH vers un routeur via SSH.

Pour plus d’informations sur les autres paramètres de configuration, consultez les rubriques suivantes :

Configurer la connexion root via SSH

Par défaut, les utilisateurs sont autorisés à se connecter au routeur ou au commutateur via root SSH lorsque la méthode d’authentification ne nécessite pas de mot de passe. Pour contrôler l’accès des utilisateurs via SSH, incluez l’instruction suivante root-login au niveau de la [edit systems services ssh] hiérarchie :

allow: permet aux utilisateurs de se connecter au routeur ou au commutateur en tant que root via SSH.

deny: empêche les utilisateurs de se connecter au routeur ou au commutateur en tant que root via SSH.

deny-password : permet aux utilisateurs de se connecter au routeur ou au commutateur en tant que root via SSH lorsque la méthode d’authentification (par exemple, RSA) ne nécessite pas de mot de passe.

La valeur par défaut est deny-password.

Configurer les connexions SFTP entrantes

Le protocole SFTP (SSH File Transfer Protocol) est un protocole réseau qui permet d’accéder aux fichiers, de les transférer et de les gérer sur n’importe quel flux de données fiable. À partir de Junos OS version 19.1R1, nous avons globalement désactivé les connexions SFTP entrantes par défaut. Si vous le souhaitez, vous pouvez activer globalement les connexions SFTP entrantes en configurant l’instruction sftp-server au niveau de la [edit system services ssh] hiérarchie. Avant Junos OS version 19.1R1, les connexions SFTP entrantes étaient globalement activées par défaut.

REMARQUE :

Seules les connexions SFTP entrantes sont désactivées par défaut. Par exemple, étant donné les périphériques A et B (où l’appareil A exécute 19.1R1), vous ne pouvez pas vous connecter via SFTP de B à A par défaut. Toutefois, vous pouvez vous connecter via SFTP de l’appareil B à l’appareil A si vous effectuez la configuration sftp-server sur l’appareil A.

Les connexions SFTP entrantes sont désactivées par défaut. Pour activer les connexions SFTP entrantes :

  1. Configurez l’instruction sftp-server au niveau de la [edit system services ssh] hiérarchie :
  2. Validez la configuration.

    L’instruction sftp-server est maintenant active. Par conséquent, les connexions SFTP entrantes sont activées.

Configurer la version du protocole SSH

Par défaut, seule la version 2 du protocole SSH est activée.

Pour configurer le routeur ou le commutateur afin qu’il utilise la version 2 du protocole SSH, incluez l’instruction protocol-version et spécifiez v2 au niveau de la [edit system services ssh] hiérarchie :

Les systèmes en mode FIPS utilisent toujours la version v2du protocole SSH .

Configurer le mécanisme Client Alive

Le mécanisme d’activation du client est utile lorsque le client ou le serveur dépend de la connaissance du moment où une connexion est devenue inactive. Il diffère du mécanisme keepalive standard car les messages du client sont envoyés via le canal chiffré. Le mécanisme de vie du client n’est pas activé par défaut. Pour l’activer, configurez les client-alive-count-max instructions and client-alive-interval . Cette option ne s’applique qu’à la version 2 du protocole SSH.

Dans l’exemple suivant, les clients SSH qui ne répondent pas seront déconnectés après environ 100 secondes (20 x 5) :

Configurer l’algorithme de hachage d’empreintes digitales SSH

Pour configurer l’algorithme de hachage utilisé par le serveur SSH lorsqu’il affiche les empreintes de clé, incluez l’instruction fingerprint-hash et spécifiez md5 ou sha2-256 au niveau de la [edit system services ssh] hiérarchie :

L’algorithme md5 de hachage n’est pas disponible sur les systèmes en mode FIPS.

Présentation de l’authentification par certificat SSH

À partir de Junos OS et Junos OS Evolved version 22.4R1, vous pouvez configurer l’authentification SSH basée sur les certificats pour les utilisateurs et les hôtes. Cette fonctionnalité vous permet d’établir un accès SSH sans mot de passe pour les utilisateurs et les hôtes de confiance sans vérifier les empreintes des clés.

Avantages de l’authentification SSH basée sur les certificats

  • Avec l’authentification SSH basée sur des certificats, les utilisateurs n’ont plus besoin de mémoriser et de saisir des mots de passe, ce qui simplifie le processus de connexion.

  • Par rapport aux approches traditionnelles basées sur des mots de passe, les certificats SSH offrent une sécurité renforcée. Ils sont plus difficiles à pirater sans mot de passe à deviner ou à craquer.

  • Les certificats SSH simplifient la gestion des clés d’authentification. Au lieu de gérer des clés individuelles pour chaque utilisateur et hôte, les administrateurs peuvent émettre et révoquer des certificats à partir d’une autorité de certification centralisée.

Génération de clés de signature

Les clés de signature sont des clés cryptographiques spécialisées utilisées dans l’authentification SSH basée sur des certificats. La première étape de la configuration de l’authentification basée sur les certificats SSH consiste à générer des clés de signature. Vous pouvez générer des clés de signature sur n’importe quel système Linux/FreeBSD. Procédez comme suit pour générer des clés de signature pour l’authentification basée sur un certificat SSH :

  1. Exécutez la commande : ssh-keygen -f <filename_ca>. Cela créera une clé privée nommée et une clé publique correspondante nommée <filename_ca><filename_ca.pub>.

  2. Connectez-vous à votre équipement Juniper et configurez le fichier de clé d’autorité de certification (CA) SSH trusted user en exécutant la commande : set system services ssh trusted-user-ca-key-file <path-to-public-key> puis validez la configuration.

  3. Chaque utilisateur peut générer ses propres clés utilisateur à l’aide de la commande CLI suivante : ssh-keygen -t <rsa|ecdsa|ed25519>.

  4. Copiez la clé publique créée par l’utilisateur sur l’ordinateur sur lequel sont <filename_ca> installés les certificats utilisateur et <filename_ca.pub>.

  5. Signez la clé publique de l’utilisateur dans le <filename_ca.pub> fichier.

Configuration

Pour configurer l’authentification basée sur un certificat SSH, utilisez les instructions de configuration CLI suivantes :

  • [system services ssh trusted-user-ca-key-file filename]: configurez le TrustedUserCAKey fichier à l’adresse /etc/ssh/sshd_config, qui contient les clés publiques d’un certificat SSH.

  • [system services ssh host-certificate-file filename]: configurez le fichier à l’adresse /etc/ssh/sshd_config, qui contient le HostCertificate certificat d’hôte signé.

  • [system services ssh authorized-principals-file filename]: configurez le fichier à l’adresse , qui contient une liste de noms, dont l’un doit apparaître dans le AuthorizedPrincipals certificat pour qu’il /var/etcsoit accepté pour authentification.

  • [system services ssh authorized-principals-command program-path]: spécifiez un programme à utiliser pour générer la liste des principaux de certificat autorisés trouvés dans le AuthorizedPrincipals fichier.

La commande telnet

Vous pouvez utiliser la commande CLI telnet pour ouvrir une session Telnet sur un périphérique distant :

REMARQUE :

Sur les équipements SRX100, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345 et SRX1500, le nombre maximal de sessions Telnet simultanées est indiqué dans le tableau suivant. La prise en charge de la plate-forme dépend de la version de Junos OS dans votre installation.

Le SRX100

Le SRX210SRX220

Le SRX240

SRX300SRX320SRX340

SRX345

SRX1500

3

3

5

3

5

5

Pour quitter la session Telnet et revenir à l’invite de commande Telnet, appuyez sur Ctrl-].

Pour quitter la session Telnet et revenir à l’invite de commande CLI, entrez quit.

Tableau 1 : Options de commande telnet CLI

Option

Description

8bit

Utilisez un chemin de données 8 bits.

bypass-routing

Contournez les tables de routage et n’ouvrez une session Telnet qu’aux hôtes sur des interfaces directement connectées. Si l’hôte n’est pas sur une interface directement connectée, un message d’erreur est renvoyé.

host

Ouvrez une session Telnet avec le nom d’hôte ou l’adresse IP spécifié.

inet

Forcez la session Telnet vers une destination IPv4.

interface source-interface

Ouvrez une session Telnet sur un hôte sur l’interface spécifiée. Si vous n’incluez pas cette option, toutes les interfaces sont utilisées.

no-resolve

Supprimer l’affichage des noms symboliques.

port port

Spécifiez le numéro de port ou le nom du service sur l’hôte.

routing-instance routing-instance-name

Utilisez l’instance de routage spécifiée pour la session Telnet.

source address

Utilisez l’adresse source spécifiée pour la session Telnet.

La commande ssh

Vous pouvez utiliser la commande CLI ssh pour utiliser le programme Secure Shell (SSH) afin d’ouvrir une connexion à un périphérique distant :

REMARQUE :

Sur les équipements SRX100, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345 et SRX1500, le nombre maximal de sessions SSH simultanées est indiqué dans le tableau suivant. La prise en charge de la plate-forme dépend de la version de Junos OS dans votre installation.

Le SRX100

Le SRX210SRX220

Le SRX240

SRX300SRX320SRX340

SRX345

SRX1500

3

3

5

3

5

5

Tableau 2 Décrit les options de commande ssh .

Tableau 2 : Options de commande CLI ssh

Option

Description

bypass-routing

Contournez les tables de routage et ouvrez une connexion SSH uniquement pour les hôtes sur les interfaces directement connectées. Si l’hôte n’est pas sur une interface directement connectée, un message d’erreur est renvoyé.

host

Ouvrez une connexion SSH au nom d’hôte ou à l’adresse IP spécifié.

inet

Forcez la connexion SSH vers une destination IPv4.

interface source-interface

Ouvrez une connexion SSH à un hôte sur l’interface spécifiée. Si vous n’incluez pas cette option, toutes les interfaces sont utilisées.

routing-instance routing-instance-name

Utilisez l’instance de routage spécifiée pour la connexion SSH.

source address

Utilisez l’adresse source spécifiée pour la connexion SSH.

v1

Forcez SSH à utiliser la version 1 pour la connexion.

v2

Forcer SSH à utiliser la version 2 pour la connexion.

Configurer les clés d’hôte connues SSH pour la copie sécurisée des données

Secure Shell (SSH) utilise des algorithmes de chiffrement pour générer un système d’hôte, de serveur et de clé de session qui garantit un transfert de données sécurisé. Vous pouvez configurer les clés d’hôte SSH pour qu’elles prennent en charge la copie sécurisée (SCP) comme alternative au FTP pour le transfert en arrière-plan de données, telles que les archives de configuration et les journaux d’événements. Pour configurer la prise en charge de SSH pour SCP, vous devez effectuer les tâches suivantes :

  • Spécifiez les hôtes connus SSH en incluant les noms d’hôte et les informations de clé d’hôte dans la hiérarchie de configuration du moteur de routage.

  • Définissez une URL SCP pour spécifier l’hôte à partir duquel recevoir les données. La définition de cet attribut récupère automatiquement les informations de clé d’hôte SSH à partir du serveur SCP.

  • Vérifiez que la clé d’hôte est authentique.

  • Acceptez la connexion sécurisée. L’acceptation de cette connexion stocke automatiquement les informations de clé d’hôte dans la base de données de clés d’hôte locale. Le stockage des informations de clé d’hôte dans la hiérarchie de configuration automatise l’établissement de liaison sécurisé et autorise le transfert des données en arrière-plan à l’aide de SCP.

Les tâches permettant de configurer les clés d’hôte SSH pour la copie sécurisée des données sont les suivantes :

Configurer les hôtes connus SSH

Pour configurer des hôtes connus SSH, incluez l’instruction et spécifiez les options de nom d’hôte et de clé d’hôte pour les host serveurs approuvés au niveau de la [edit security ssh-known-hosts] hiérarchie :

Les clés d’hôte sont l’une des suivantes :

  • dsa-key key—Clé DSA (Digital Signature Algorithm) codée en Base64 pour SSH version 2.

  • ecdsa-sha2-nistp256-key key—Clé ECDSA-SHA2-NIST256 codée en Base64.

  • ecdsa-sha2-nistp384-key key—Clé ECDSA-SHA2-NIST384 codée en Base64.

  • ecdsa-sha2-nistp521-key key—Clé ECDSA-SHA2-NIST521 codée en Base64.

  • ed25519-key key—Clé ED25519 codée en Base64.

  • rsa-key key—Algorithme de clé publique codé en Base64 qui prend en charge le chiffrement et les signatures numériques pour SSH version 1 et SSH version 2.

  • rsa1-key key—Algorithme de clé publique RSA codé en Base64, qui prend en charge le chiffrement et les signatures numériques pour SSH version 1.

Configurer la prise en charge du transfert de fichiers SCP

Pour configurer un hôte connu afin qu’il prenne en charge les transferts de fichiers SCP en arrière-plan, incluez l’instruction archive-sites au niveau de la [edit system archival configuration] hiérarchie.

REMARQUE :

Lorsque vous spécifiez une URL dans une instruction à l’aide d’une Junos OS adresse d’hôte IPv6, vous devez placer l’URL entière entre guillemets ( » « ) et placer l’adresse d’hôte IPv6 entre crochets ([ ]). Par exemple, “scp://username<:password>@[host]<:port>/url-path”;

La définition de l’instruction pour qu’elle pointe vers une URL SCP déclenche la récupération automatique de la clé d’hôte archive-sites . À ce stade, se connecte à l’hôte SCP pour récupérer la clé publique SSH, Junos OS affiche le résumé du message de la clé hôte ou l’empreinte digitale en sortie vers la console et met fin à la connexion au serveur.

Pour vérifier que la clé d’hôte est authentique, comparez cette empreinte avec une empreinte que vous obtenez du même hôte à l’aide d’une source fiable. Si les empreintes sont identiques, acceptez la clé d’hôte en la saisissant yes à l’invite. Les informations de clé hôte sont ensuite stockées dans la configuration du moteur de routage et prennent en charge les transferts de données en arrière-plan à l’aide de SCP.

Mettre à jour les informations de la clé de l’hôte SSH

En règle générale, les informations de clé d’hôte SSH sont automatiquement récupérées lorsque vous définissez un attribut URL pour SCP à l’aide de l’instruction au niveau de archival configuration archive-sites la [edit system] hiérarchie. Toutefois, si vous devez mettre à jour manuellement la base de données de clés d’hôte, utilisez l’une des méthodes suivantes.

Récupération manuelle des informations sur la clé de l’hôte

Pour récupérer manuellement les informations de la clé d’hôte public SSH, configurez l’option fetch-from-server au niveau de la [edit security ssh-known-hosts] hiérarchie. Vous devez spécifier l’hôte à partir duquel récupérer la clé publique SSH.

Importer des informations de clé d’hôte à partir d’un fichier

Pour importer manuellement les informations de clé d’hôte SSH à partir d’un known_hosts fichier, incluez l’option load-key-file au niveau de la [edit security ssh-known-hosts] hiérarchie. Vous devez spécifier le chemin d’accès au fichier à partir duquel importer les informations de clé d’hôte.

Configurer le service SSH pour prendre en charge la cryptographie héritée

Le serveur SSH est Junos OS basé sur OpenSSH 7 et utilise par défaut un ensemble plus sécurisé d’algorithmes de chiffrement et d’échange de clés. OpenSSH 7 omet une partie de la cryptographie héritée.

REMARQUE :

L’absence de prise en charge de la cryptographie héritée dans les périphériques entraîne l’échec de la découverte des périphériques Junos Space. Pour contourner ce problème, configurez l’appareil pour qu’il prenne en charge le chiffrement ou (ou 3des-cbcblowfish-cbc les deux) et la méthode d’échange dh-group1-sha1 de clés. Ce problème n’affecte pas les périphériques exécutant Junos OS avec FreeBSD mis à jour.

REMARQUE :

Consultez la documentation OpenSSH 7 à https://www.openssh.com/ pour plus d’informations sur ces extensions.

Junos OS prend en charge l’ensemble de chiffrements suivant par défaut :

  • chacha20-poly1305@openssh.com

  • aes128-ctr

  • aes192-ctr

  • aes256-ctr

  • aes128-gcm@openssh.com

  • aes256-gcm@openssh.com

Dans Junos OS, les chiffrements suivants ne sont pas pris en charge par défaut, mais vous pouvez configurer votre appareil pour qu’il les prenne en charge. Ils sont répertoriés des plus sécurisés aux moins sécurisés :

  • aes256-cbc

  • aes192-cbc

  • aes128-cbc

  • 3des-cbc

  • blowfish-cbc

  • cast128-cbc

  • arcfour256

  • arcfour128

  • arcfour

Junos OS Prend en charge l’ensemble suivant de méthodes d’échange de clés par défaut :

  • curve25519-sha256

  • ecdh-sha2-nistp256

  • ecdh-sha2-nistp384

  • ecdh-sha2-nistp521

  • group-exchange-sha2

  • dh-group14-sha1

Dans Junos OS, les méthodes d’échange de clés suivantes ne sont pas prises en charge par défaut, mais vous pouvez configurer votre périphérique pour les prendre en charge :

  • group-exchange-sha1

  • dh-group1-sha1

Pour configurer le service SSH afin de prendre en charge le chiffrement hérité :

REMARQUE :

En configurant un ensemble ordonné de chiffrements, de méthodes d’échange de clés ou de codes d’authentification de message (MAC), le nouvel ensemble défini est appliqué aux commandes serveur et client. Les modifications apportées aux valeurs par défaut affectent la commande lorsque vous utilisez le file copy protocole SCP (Secure Copy Protocol).

  1. Ajout de la prise en charge des chiffrements à l’aide de la set system services ssh ciphers [ cipher 1 cipher 2 ... ] commande. Nous vous recommandons d’ajouter les chiffrements à la fin de la liste de configuration afin qu’ils soient parmi les dernières options utilisées. Dans l’exemple suivant, les arcfour chiffrements et blowfish-cbc sont ajoutés à l’ensemble par défaut :
  2. Ajout de la prise en charge des méthodes d’échange de clés à l’aide de la set system services ssh key-exchange [ method 1 method 2 ... ] commande. Nous vous recommandons d’ajouter les méthodes d’échange de clés à la fin de la liste de configuration afin qu’elles fassent partie des dernières options utilisées. Dans l’exemple suivant, la méthode d’échange dh-group1-sha1 de clés est ajoutée à l’ensemble par défaut :
  3. Validez la configuration :

Voir également

Configurer le service SSH sortant

Vous pouvez configurer un périphérique en cours d’exécution Junos OS pour établir une connexion TCP/IP avec une application de gestion des clients. Si l’application de gestion n’atteint pas un équipement Juniper Networks, par exemple, l’équipement étant un pare-feu. Dans ce cas, outbound-ssh peut être configuré sur l’équipement Juniper Networks. Une outbound-ssh configuration initie une connexion SSH inverse entre le serveur et le client, puis l’application de gestion. Cette connexion SSH sortante n’est fermée qu’une fois la configuration supprimée de l’appareil.

REMARQUE :

Il n’y a pas de commande d’initiation avec SSH sortant. Une fois que vous avez configuré et validé le SSH sortant, l’appareil commence à établir une connexion SSH sortante en fonction de la configuration validée. L’appareil tente à plusieurs reprises de créer cette connexion jusqu’à ce qu’il réussisse. Si la connexion entre l’appareil et l’application de gestion des clients est abandonnée, l’appareil tente à nouveau de créer une connexion SSH sortante jusqu’à ce qu’il réussisse. Cette connexion est maintenue jusqu’à ce que la strophe SSH sortante soit supprimée de la configuration.

Pour configurer l’appareil pour les connexions SSH sortantes, incluez l’instruction au outbound-ssh niveau de la [edit system services] hiérarchie :

[edit system services outbound-ssh]

Les rubriques suivantes décrivent les tâches de configuration du service SSH sortant.

Envoyer la clé d’hôte SSH publique au client SSH sortant

Chaque fois que le routeur ou le commutateur établit une connexion SSH sortante, il envoie d’abord une séquence d’initiation au client de gestion. Cette séquence identifie le routeur ou le commutateur auprès du client de gestion. Dans cette transmission se trouve la valeur de device-id.

Pour configurer l’identificateur de périphérique du routeur ou du commutateur, incluez l’instruction suivante device-id au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

La séquence d’initiation lorsque n’est secret pas configurée :

Lors de l’initialisation d’une connexion SSH, le client authentifie l’identité de l’appareil à l’aide de la clé d’hôte SSH publique de l’appareil. Par conséquent, avant que le client puisse lancer la séquence SSH, il a besoin de la clé SSH publique de l’appareil. Lorsque vous configurez l’instruction, l’appareil secret transmet sa clé SSH publique dans le cadre de la séquence d’initiation de la connexion SSH sortante.

Lorsque l’instruction est définie et que l’appareil établit une connexion SSH sortante, l’appareil communique son ID d’appareil, sa clé SSH publique et un hachage SHA1 dérivé en partie de l’instruction secretsecret . La valeur de l’instruction est partagée entre l’appareil secret et le client de gestion. Le client utilise le secret partagé pour authentifier la clé d’hôte SSH publique qu’il reçoit afin de déterminer si la clé publique provient de l’appareil identifié par l’instruction device-id .

L’utilisation de l’instruction secret pour transporter la clé d’hôte SSH publique est facultative. Vous pouvez transporter et installer manuellement la clé publique sur le système client.

REMARQUE :

L’inclusion de l’instruction signifie que l’appareil envoie sa clé d’hôte SSH publique chaque fois qu’il secret établit une connexion avec le client. C’est ensuite au client de décider quoi faire avec la clé d’hôte SSH s’il dispose déjà d’une clé SSH pour cet appareil. Nous vous recommandons de remplacer la copie client de la clé d’hôte SSH par la nouvelle clé. Les clés d’hôte peuvent être modifiées pour diverses raisons. En remplaçant la clé chaque fois qu’une connexion est établie, vous vous assurez que le client dispose de la clé la plus récente.

Pour envoyer la clé d’hôte SSH publique du routeur ou du commutateur lorsque l’appareil se connecte au client, incluez l’instruction suivante secret au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

Le message suivant est envoyé par l’appareil lorsque l’attribut secret est configuré :

Configurer les messages Keepalive pour les connexions SSH sortantes

Une fois que l’application cliente dispose de la clé d’hôte SSH publique du routeur ou du commutateur, elle peut lancer la séquence SSH comme si elle avait créé la connexion TCP/IP. Le client peut ensuite authentifier l’appareil à l’aide de sa copie de la clé SSH de l’hôte public du routeur ou du commutateur dans le cadre de cette séquence. L’équipement authentifie l’utilisateur client à l’aide des mécanismes pris en charge dans Junos OS (authentification RSA/DSA, chaîne publique ou mot de passe).

Pour permettre à l’appareil d’envoyer des messages de conservation du protocole SSH à l’application cliente, configurez l’instruction keep-alive au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

Configurer une nouvelle connexion SSH sortante

Lorsqu’il est déconnecté, l’appareil commence à établir une nouvelle connexion SSH sortante. Pour spécifier la façon dont le périphérique se reconnecte au serveur après l’interruption d’une connexion, incluez l’instruction reconnect-strategy au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

Vous pouvez également spécifier le nombre de nouvelles tentatives et définir le délai avant l’arrêt des tentatives de reconnexion. Reportez-vous à la section Configurer les messages Keepalive pour les connexions SSH sortantes.

Configurez le client SSH sortant pour qu’il accepte NETCONF en tant que service disponible

Pour configurer l’application afin qu’elle accepte NETCONF en tant que service disponible, incluez l’instruction services netconf au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

Configurer les clients SSH sortants

Pour configurer les clients disponibles pour cette connexion SSH sortante, répertoriez chaque client avec une instruction d’adresse distincte au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

REMARQUE :

Les connexions SSH sortantes prennent en charge les formats d’adresse IPv4 et IPv6.

Configurer les instances de routage pour les clients SSH sortants

Pour utiliser l’instance de routage de gestion, activez d’abord l’instance de routage à l’aide de mgmt_junos la set system management-instance commande.

Pour utiliser une autre instance de routage, configurez d’abord l’instance de routage au niveau de la [edit routing-instances] hiérarchie.

Si vous ne spécifiez aucune instance de routage, votre appareil établira la connexion SSH sortante à l’aide de la table de routage par défaut.

Configurer les connexions NETCONF-over-SSH sur un port TCP spécifié

Junos OS vous permet de restreindre les connexions NETCONF entrantes à un port TCP spécifié sans configurer de pare-feu. Pour configurer le port TCP utilisé pour les connexions NETCONF-over-SSH, incluez l’instruction port au niveau de la [edit system services netconf ssh] hiérarchie. Le port configuré n’accepte que les sessions NETCONF-over-SSH. Les demandes de session SSH normales pour ce port sont rejetées.

Vous pouvez soit configurer le port 830 par défaut pour les connexions NETCONF sur SSH, comme spécifié dans la RFC 4742, Utilisation du protocole de configuration NETCONF sur Secure Shell (SSH), soit configurer n’importe quel port de 1 à 65535.

REMARQUE :

  • Le port SSH par défaut (22) continue d’accepter les sessions NETCONF même avec un port de serveur NETCONF configuré. Pour empêcher le port SSH d’accepter les sessions NETCONF, spécifiez-le dans le script d’événement de connexion.

  • Nous vous déconseillons de configurer les ports par défaut pour les services FTP (21) et Telnet (23) pour configurer les connexions NETCONF-over-SSH.

Configurer les limites de nouvelles tentatives de mot de passe pour l’accès Telnet et SSH

Pour empêcher les attaques par force brute et par dictionnaire, un périphérique effectue les actions suivantes pour les sessions Telnet ou SSH par défaut :

  • Déconnecte une session après un maximum de 10 tentatives consécutives de mot de passe.

  • Après la deuxième nouvelle tentative de mot de passe, introduit un délai de 5 secondes entre les tentatives de mot de passe suivantes.

    Par exemple, l’appareil introduit un délai de 5 secondes entre la troisième et la quatrième nouvelle tentative de mot de passe, un délai de 10 secondes entre la quatrième et la cinquième nouvelle tentative de mot de passe, et ainsi de suite.

  • Applique une durée de session minimale de 20 secondes, pendant laquelle une session ne peut pas être déconnectée. La configuration de la durée minimale de session empêche les utilisateurs malveillants de déconnecter les sessions avant l’entrée en vigueur du délai de nouvelle tentative de mot de passe. La configuration de la durée minimale de session les empêche également de tenter des attaques par force brute et par dictionnaire avec plusieurs connexions.

Vous pouvez configurer les limites de nouvelles tentatives de mot de passe pour l’accès Telnet et SSH. Dans cet exemple, vous configurez l’appareil pour qu’il effectue les actions suivantes pour les sessions Telnet et SSH :

  • Autorisez un maximum de quatre tentatives consécutives de mot de passe avant de déconnecter une session.

  • Introduisez un délai de 5 secondes entre les nouvelles tentatives de mot de passe qui se produisent après la deuxième nouvelle tentative de mot de passe.

  • Imposez une durée de session minimale de 40 secondes, pendant laquelle une session ne peut pas être déconnectée.

Pour configurer les limites de nouvelles tentatives de mot de passe pour l’accès Telnet et SSH :

  1. Définissez le nombre maximal de nouvelles tentatives consécutives de mot de passe avant qu’une session Telnet, SSH ou telnet ne soit déconnectée. Le nombre par défaut est 10, mais vous pouvez définir un nombre à partir de 1 .10
  2. Définissez le nombre seuil de nouvelles tentatives de mot de passe au-delà duquel un délai est introduit entre deux tentatives de mot de passe consécutives. Le nombre par défaut est 2, mais vous pouvez spécifier une valeur à partir de 1 .3
  3. Définissez le délai (en secondes) entre les tentatives consécutives de mot de passe après le nombre seuil de tentatives de mot de passe. Le délai par défaut est exprimé en multiples de 5 secondes, mais vous pouvez spécifier une valeur de 5 toutes les 10 secondes.
  4. Définissez la durée minimale (en secondes) pendant laquelle une session Telnet ou SSH ne peut pas être déconnectée. La valeur par défaut est 20 secondes, mais vous pouvez spécifier un intervalle de à toutes 20 les 60 secondes.
  5. Après avoir configuré l’appareil, passez commit en mode de configuration.

Exemple : Configurer un filtre pour bloquer l’accès Telnet et SSH

Conditions préalables

Vous avez besoin de deux équipements fonctionnant Junos OS avec une liaison réseau partagée. Aucune configuration particulière au-delà de l’initialisation de base de l’appareil (interface de gestion, accès à distance, comptes de connexion des utilisateurs, etc.) est nécessaire avant de configurer cet exemple. Bien qu’il ne s’agisse pas d’une exigence stricte, l’accès de la console au périphérique R2 est recommandé.

REMARQUE :

Notre équipe de test de contenu a validé et mis à jour cet exemple.

Vue d’ensemble et topologie

Dans cet exemple, vous créez un filtre de pare-feu sans état IPv4 qui consigne et rejette les paquets Telnet ou SSH envoyés au moteur de routage local, sauf si le paquet provient du sous-réseau 192.168.1.0/30 . Le filtre est appliqué à l’interface de bouclage pour s’assurer que seul le trafic destiné à l’équipement local est affecté. Vous appliquez le filtre dans le sens de la saisie. Aucun filtre de sortie n’est utilisé. Par conséquent, tout le trafic généré localement est autorisé.

  • Pour faire correspondre les paquets provenant d’un sous-réseau ou d’un préfixe IP spécifique, vous utilisez la condition de correspondance IPv4 appliquée dans la source-address direction d’entrée.

  • Pour faire correspondre les paquets destinés au port Telnet et aux ports SSH, vous utilisez la condition de correspondance combinée aux conditions de correspondance a port telnet et port ssh IPv4 appliquées dans la protocol tcp direction d’entrée.

Exemple de topologie

Figure 1 affiche la topologie de test pour cet exemple. Le filtre de pare-feu est appliqué à l’appareil R2, ce qui en fait l’appareil testé (DUT). Les périphériques R1 et R2 partagent une liaison à laquelle est attribué un sous-réseau de 192.168.1.0/30. Les deux périphériques ont des adresses de bouclage attribuées à partir du préfixe 192.168.255.0/30 à l’aide d’un masque de sous-réseau /32. Les routes statiques assurent l’accessibilité entre les adresses de bouclage, car aucun protocole de passerelle intérieure n’est configuré dans cet exemple de base.

Figure 1 : Exemple de topologieExemple de topologie

Configuration

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, consultez Utilisation de l’éditeur CLI en mode Configuration.

ATTENTION :

De par sa conception, le filtre d’échantillonnage restreint l’accès Telnet et SSH à R2, sauf s’il provient du sous-réseau partagé à R1. Si vous utilisez SSH ou Telnet pour accéder directement au périphérique R2, vous perdrez la connectivité lorsque le filtre sera appliqué. Nous vous recommandons d’avoir accès à la console lors de la configuration de cet exemple. Si nécessaire, vous pouvez utiliser le périphérique R1 en tant qu’hôte de saut pour lancer une session SSH vers R2 après l’application du filtre. Vous pouvez également envisager de modifier l’exemple de filtre pour autoriser également le sous-réseau IP affecté à la machine que vous utilisez à accéder au périphérique R2.

Pour configurer cet exemple, effectuez les tâches suivantes :

Configuration rapide de l’interface de ligne de commande

Configuration rapide de l’appareil R1

Pour configurer rapidement l’appareil R1, modifiez les commandes suivantes selon vos besoins et collez-les dans l’interface de ligne de commande au niveau de la [edit] hiérarchie. Assurez-vous d’émettre un commiten mode de configuration pour activer les modifications.

Configuration rapide de l’appareil R2

Pour configurer rapidement l’appareil R2, modifiez les commandes suivantes selon vos besoins et collez-les dans l’interface de ligne de commande au niveau de la [edit] hiérarchie. Assurez-vous d’émettre un commit en mode de configuration pour activer les modifications.

Conseil :

Pensez à l’utiliser lorsque vous apportez des modifications susceptibles d’affecter l’accès commit-confirmed à distance à votre appareil. Activation d’une configuration Junos OS mais nécessitant une confirmation

Configurer l’appareil R1

Procédure étape par étape

Pour configurer l’appareil R1, procédez comme suit :

  1. Configurez les interfaces :

  2. Configurez le nom d’hôte et l’itinéraire statique vers l’adresse de bouclage du périphérique R2. Vous pouvez également configurer l’accès Telnet et SSH :

Vérifier et valider la configuration sur l’appareil R1

Procédure étape par étape

Procédez comme suit pour vérifier et valider votre configuration candidate sur l’appareil R1 :

  1. Confirmez la configuration de l’interface à l’aide de la show interfaces commande configuration mode. Si la sortie de la commande n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

  2. Vérifiez l’itinéraire statique utilisé pour atteindre l’adresse de bouclage de l’appareil R2 et que l’accès SSH et Telnet sont activés. Utilisez les commandes et show routing-optionsshow system services en mode de configuration. Si la sortie de la commande n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

  3. Lorsque vous êtes satisfait de la configuration sur l’appareil R1, validez votre configuration candidate.

Configurer le périphérique R2

Procédure étape par étape

Procédez comme suit pour configurer l’appareil R2. Vous commencez par définir le filtre de pare-feu sans état qui bloque sélectivement l’accès Telnet et SSH :

  1. Positionnez-vous dans la edit firewall family inet filter local_acl hiérarchie :

  2. Définissez le terme terminal_accessde filtre . Ce terme autorise Telnet et SSH à partir du ou des préfixes source spécifiés :

  3. Définissez le terme terminal_access_deniedde filtre . Ce terme rejette SSH et Telnet de toutes les autres adresses source. Ce terme est configuré pour consigner les correspondances avec le terme et pour générer une réponse explicite ICMP (Internet Control Message Protocol) de destination inaccessible à la source du paquet. Pour plus d’informations sur les options de journalisation des filtres, reportez-vous à la section Actions de journalisation des filtres du pare-feu .

    Conseil :

    Vous pouvez utiliser cette action pour supprimer la génération de messages d’erreur ICMP vers la discard source. Pour plus d’informations, reportez-vous à la section Actions de terminaison du filtre de pare-feu .
  4. Optionnel.

    Définissez le terme tcp-estabde filtre . Ce terme autorise l’accès sortant à Internet pour prendre en charge les connexions au cloud Juniper Mist (tcp-established est une condition de correspondance de champ binaire, , qui indique une session TCP établie, tcp-flags "(ack | rst)"mais pas le premier paquet d’une connexion TCP) :

  5. Définissez le terme default-termde filtre . Ce terme accepte tout autre trafic. Rappelez-vous que Junos OS les filtres sans état ont un terme de refus implicite à leur extrémité. Le default-term remplace ce comportement en mettant fin au filtre par une action d’acceptation explicite. La terminaison du filtre entraîne l’acceptation de tous les autres trafics par le serveur de fichiers.

    REMARQUE :

    Dans cet exemple, nous autorisons tous les autres types de trafic, mais pour votre réseau, vous pouvez sécuriser le moteur de routage. Pour plus d’informations , consultez Protection du moteur de routage .

  6. Configurez l’interface de bouclage et appliquez le filtre dans le sens d’entrée :

  7. Configurez le nom d’hôte, l’interface ge-0/0/0, la route statique vers l’adresse de bouclage du périphérique R1 et activez l’accès à distance via SSH et Telnet :

Vérifier et valider la configuration sur l’appareil R2

Procédure étape par étape

Procédez comme suit pour vérifier et valider votre configuration candidate sur l’appareil R2 :

  1. Confirmez la configuration du filtre de pare-feu sans état à l’aide de la show firewall commande configuration mode. Si la sortie de la commande n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

  2. Confirmez la configuration de l’interface et filtrez l’application à l’aide de la show interfaces commande configuration mode. Si la sortie de la commande n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

  3. Vérifiez l’itinéraire statique utilisé pour atteindre l’adresse de bouclage du périphérique R1 et vérifiez que l’accès Telnet et SSH est activé. Utilisez les commandes et show routing-optionsshow system services en mode de configuration. Si la sortie de la commande n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

  4. Lorsque vous êtes satisfait de la configuration sur l’appareil R2, validez votre configuration candidate.

    Conseil :

    Pensez à l’utiliser lorsque vous apportez des modifications susceptibles d’affecter l’accès commit-confirmed à distance à votre appareil.

Vérifier le filtre du pare-feu sans état

Vérifiez que le filtre de pare-feu pour limiter l’accès Telnet et SSH fonctionne correctement.

Vérifier les paquets acceptés

But

Vérifiez que le filtre de pare-feu autorise correctement SSH et Telnet lorsque le trafic provient du sous-réseau 192.168.1.0/30 .

Action

  1. Effacez le journal du pare-feu sur votre routeur ou commutateur.

  2. À partir d’un hôte dont l’adresse IP se trouve dans le sous-réseau 192.168.1.0/30 , utilisez une commande pour vérifier que vous pouvez vous connecter au périphérique à l’aide de SSH à partir d’une ssh 192.168.255.2 adresse source autorisée. Ce paquet doit être accepté, mais les informations d’en-tête de paquet pour ce paquet ne doivent pas être consignées dans la mémoire tampon du journal du filtre du pare-feu dans le moteur de transfert de paquets. Vous serez invité à enregistrer la clé d’hôte SSH s’il s’agit de la première connexion SSH entre user ces périphériques.

    REMARQUE :

    Par défaut, le périphérique R1 sourcera le trafic SSH à partir de l’interface de sortie utilisée pour atteindre la destination. Par conséquent, ce trafic provient de l’adresse 192.168.1.1 attribuée à l’interface ge-0/0/0 du périphérique R1.

  3. Déconnectez-vous de l’interface de ligne de commande sur le périphérique R2 pour fermer la session SSH.

  4. À partir d’un hôte dont l’adresse IP se trouve dans le sous-réseau 192.168.1.0/30 , utilisez la telnet 192.168.255.2 commande pour vérifier que vous pouvez vous connecter à votre routeur ou commutateur à l’aide de Telnet à partir d’une adresse source autorisée. Ce paquet doit être accepté, mais les informations d’en-tête de paquet pour ce paquet ne doivent pas être consignées dans la mémoire tampon du journal du filtre du pare-feu dans le moteur de transfert de paquets.

  5. Déconnectez-vous de la CLI pour fermer la session Telnet sur le périphérique R2.

  6. Utilisez la commande pour vérifier que la show firewall log mémoire tampon du journal du pare-feu sur le moteur de transfert de paquets (PFE) du périphérique R2 ne contient aucune entrée avec une adresse source dans le sous-réseau 192.168.1.0/30 .

Vérifier les paquets consignés et rejetés

But

Vérifiez que le filtre du pare-feu rejette correctement le trafic SSH et Telnet qui ne provient pas du sous-réseau 192.168.1.0/30 .

Action

  1. Effacez le journal du pare-feu sur votre routeur ou commutateur.

  2. Générez du trafic SSH provenant de l’adresse de bouclage de l’appareil R1. L’adresse source de ce trafic se trouve en dehors du sous-réseau 192.168.1.0/30 autorisé. Utilisez la ssh 192.168.255.2 source 192.168.255.1 commande pour vérifier que vous ne pouvez pas vous connecter à l’appareil à l’aide de SSH à partir de cette adresse source. Ce paquet doit être rejeté et les informations d’en-tête du paquet doivent être consignées dans la mémoire tampon du journal du filtre du pare-feu.

    La sortie indique que la connexion SSH est rejetée. Cette sortie confirme que le filtre génère un message d’erreur ICMP et qu’il bloque correctement le trafic SSH lorsqu’il est envoyé à partir d’une adresse source non autorisée.

  3. Générez du trafic Telnet provenant de l’adresse de bouclage de l’appareil R1. L’adresse source de ce trafic se trouve en dehors du sous-réseau 192.168.1.0/30 autorisé. Utilisez la telnet 192.168.255.2 source 192.168.255.1 commande pour vérifier que vous ne pouvez pas vous connecter à l’appareil à l’aide de Telnet à partir de cette adresse source. Ce paquet doit être rejeté et les informations d’en-tête de paquet de ce paquet doivent être consignées dans la mémoire tampon du journal du filtre du pare-feu dans le PFE.

    La sortie indique que la connexion Telnet est rejetée. Cette sortie confirme que le filtre génère un message d’erreur ICMP et qu’il bloque correctement le trafic Telnet lorsqu’il est envoyé à partir d’une adresse source non autorisée.

  4. Utilisez la commande pour vérifier que la show firewall log mémoire tampon du journal du pare-feu sur le périphérique R2 contient des entrées indiquant que les paquets dont l’adresse source est 192.168.255.1 ont été rejetés.

    La sortie confirme que le trafic provenant de l’adresse source 192.168.255.1 correspond au terme du terminal_access_denied filtre. La Action colonne affiche un pour R indiquer que ces paquets ont été rejetés. L’interface, le protocole de transport et les adresses source et de destination sont également répertoriés. Ces résultats confirment que le filtre de pare-feu fonctionne correctement pour cet exemple.

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
19.4R1
À partir de Junos OS version 19.4R1 et Junos OS version 17.4R3, vous pouvez désactiver le mot de passe de connexion SSH ou l’authentification défi-réponse à l’aide des no-password-authentication options et no-challenge-response au niveau de la hiérarchie [edit system services ssh].
19.1R1
À partir de Junos OS version 19.1R1, nous avons globalement désactivé les connexions SFTP entrantes par défaut. Si vous le souhaitez, vous pouvez activer globalement les connexions SFTP entrantes en configurant l’instruction sftp-server au niveau de la [edit system services ssh] hiérarchie
18.3R1
À compter de Junos OS version 18.3R1, les ssh-dss algorithmes et hostkey sont déconseillés (plutôt que supprimés immédiatement) afin d’assurer la compatibilité descendante et ssh-dsa de mettre votre configuration en conformité avec la nouvelle configuration.
18.3R1
(SRX Series et MX Series uniquement) À partir de Junos OS version 19.3R1, vous pouvez spécifier le nom de l’instance de routage sur laquelle la connectivité SSH sortante doit être établie en incluant l’instruction routing-instance au niveau de la [edit system services outbound-ssh] hiérarchie :