Exemple : Contrôle de la gestion des accès sur les équipements réseau Juniper
Notre équipe de test de contenu a validé et mis à jour cet exemple.
Cet exemple montre comment limiter l’accès de gestion aux équipements réseau Juniper en fonction d’un ensemble spécifique d’adresses IP autorisées. Ce type de fonctionnalité, souvent appelé liste de contrôle d’accès (ACL), est implémenté sous la forme d’un filtre de pare-feu sans état dans Junos OS.
Conditions préalables
Un équipement réseau Juniper connecté à un réseau de gestion. Pour faciliter la validation de la configuration, il doit y avoir au moins un autre périphérique ayant accès au réseau de gestion qui peut initier des connexions SSH ou Telnet vers le périphérique testé (DUT). Aucune configuration spéciale au-delà de l’initialisation de base de l’appareil (interface de gestion et route statique associée, services système, comptes de connexion utilisateur, etc.) n’est requise avant de configurer cet exemple.
Présentation
Vous pouvez configurer un filtre de pare-feu pour limiter les adresses IP pouvant gérer un appareil. Ce filtre de pare-feu doit inclure une condition de refus de tout le trafic, à l’exception des adresses IP autorisées à gérer l’équipement. Vous devez appliquer le filtre de pare-feu à l’interface de bouclage (lo0) pour vous assurer que seul le trafic de gestion, c’est-à-dire le trafic envoyé à l’équipement lui-même, est filtré.
Exemple de topologie
Figure 1 montre la topologie de cet exemple. L’appareil R1 sert de passerelle par défaut pour le réseau de gestion auquel le sous-réseau 172.16.0.0/24 est affecté. Vous appliquez le filtre qui limite l’accès de gestion à l’appareil R2, ce qui en fait le DUT dans cet exemple. Le poste distant est habilité à gérer le DUT et l’adresse 10.0.0.1/32 lui a été attribuée.
Dans cet exemple, vous :
Configurez une liste de préfixes appelée manager-ip. Cette liste définit l’ensemble des adresses IP autorisées à gérer l’appareil. Dans cet exemple, la liste inclut le sous-réseau de gestion lui-même (172.16.0.0/24) et l’adresse IP d’un utilisateur distant autorisé (10.0.0.1/32).
Configurez un filtre limit-mgmt-access de pare-feu qui rejette toutes les adresses source, à l’exception de l’ensemble spécifique d’adresses défini dans la manager-ip liste des préfixes. Cela permet de s’assurer que seules les adresses IP répertoriées dans la liste des préfixes peuvent gérer l’appareil.
Appliquez le limit-mgmt-access filtre à l’interface de bouclage. Chaque fois qu’un paquet adressé à l’équipement local arrive sur une interface, l’interface de bouclage applique le filtre limit-mgmt-access pour limiter l’accès à la gestion aux seules adresses autorisées.
Configurer une liste d’adresses IP pour restreindre l’accès de gestion à un périphérique
Procédure
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, modifiez les commandes suivantes selon vos besoins et collez-les dans l’interface de ligne de commande de l’appareil R2 au niveau de la [edit] hiérarchie. Par souci d’exhaustivité, la configuration inclut des commandes permettant de configurer SSH (pour les non-utilisateurs) et les services système Telnet. Il fournit également la configuration de l’interface de gestion et de la route statique associée. Ces commandes ne sont pas nécessaires si cette fonctionnalité est déjà configurée sur votre appareil.
Telnet ne prend pas en charge la connexion racine sur les équipements Juniper Networks. La connexion SSH pour l’utilisateur root n’est pas configurée dans cet exemple. Votre appareil doit avoir un utilisateur non root configuré pour permettre la connexion à distance. Vous pouvez également ajouter l’argument à l’instruction pour autoriser la connexion de l’utilisateur root à l’aide root-login allowsystem services ssh de SSH.
Assurez-vous d’exécuter un commit mode de configuration à partir pour activer les modifications.
Lorsque vous appliquez un filtre qui restreint l’accès à l’appareil, pensez à utiliser commit confirmed. Cette option annule automatiquement la configuration si vous n’êtes pas en mesure d’émettre un autre commit dans le délai spécifié.
set system services ssh set system services telnet set interfaces fxp0 unit 0 family inet address 172.16.0.253/24 set interfaces lo0 unit 0 family inet address 192.168.255.2/32 set routing-options static route 0.0.0.0/0 next-hop 172.16.0.254 no-readvertise set policy-options prefix-list manager-ip 172.16.0.0/24 set policy-options prefix-list manager-ip 10.0.0.1/32 set firewall filter limit-mgmt-access term block_non_manager from source-address 0.0.0.0/0 set firewall filter limit-mgmt-access term block_non_manager from source-prefix-list manager-ip except set firewall filter limit-mgmt-access term block_non_manager from protocol tcp set firewall filter limit-mgmt-access term block_non_manager from destination-port ssh set firewall filter limit-mgmt-access term block_non_manager from destination-port telnet set firewall filter limit-mgmt-access term block_non_manager then log set firewall filter limit-mgmt-access term block_non_manager then discard set firewall filter limit-mgmt-access term accept_everything_else then accept set interfaces lo0 unit 0 family inet filter input limit-mgmt-access
Procédure étape par étape
Les étapes suivantes vous obligent à 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.
Configurez les interfaces de gestion et de bouclage et assurez-vous que les services système Telnet et SSH sont activés.
[edit] user@R2# set interfaces fxp0 unit 0 family inet address 172.16.0.253/24 user@R2# set interfaces lo0 unit 0 family inet address 192.168.255.2/32 user@R2# set routing-options static route 0.0.0.0/0 next-hop 172.16.0.254 no-readvertise user@R2# set system services ssh user@R2# set system services telnet
Définissez l’ensemble des adresses d’hôte autorisées dans la liste des préfixes. Cette liste inclut les préfixes du sous-réseau de gestion et d’une seule station de gestion distante autorisée.
[edit policy-options] user@R2# set prefix-list manager-ip 172.16.0.0/24 user@R2# set prefix-list manager-ip 10.0.0.1/32
La liste des préfixes est référencée dans le filtre du pare-feu. L’utilisation d’une liste de préfixes facilite la mise à jour des adresses autorisées à accéder à l’appareil. En effet, seule la liste des préfixes doit être mise à jour. Aucune modification n’est requise pour le filtre de pare-feu lui-même lors de l’ajout ou de la suppression de préfixes autorisés.
Configurez un filtre de pare-feu pour refuser le trafic Telnet et SSH provenant de toutes les adresses IP, à l’exception de celles définies dans la liste des préfixes.
[edit firewall filter limit-mgmt-access] user@R2# set term block_non_manager from source-address 0.0.0.0/0 user@R2# set term block_non_manager from source-prefix-list manager-ip except user@R2# set term block_non_manager from protocol tcp user@R2# set term block_non_manager from destination-port ssh user@R2# set term block_non_manager from destination-port telnet user@R2# set term block_non_manager then discard
Notez l’utilisation du modificateur d’action
except. Le premier terme correspond à toutes les adresses source possibles. Le terme suivant inverse la correspondance pour les adresses source de la liste de préfixes spécifiée. Par conséquent, le trafic de gestion destiné au protocole et aux ports spécifiés n’est accepté que s’il provient d’une adresse de la liste. Le trafic provenant de tous les autres préfixes source vers la même combinaison de protocoles et de ports est ignoré. Dans cet exemple, une action de journalisation est ajoutée pour faciliter le débogage et la vérification du filtre.Configurez un terme par défaut pour accepter tout le reste du trafic. Cela permet de s’assurer que les autres services et protocoles, par exemple pings, BGP ou OSPF, ne sont pas affectés par le filtre.
Conseil :L’exemple de filtre est permissif de par sa conception. Il peut représenter une menace pour la sécurité étant donné qu’il accepte explicitement tout le trafic qui n’a pas été rejeté ou rejeté par les termes de filtrage précédents. Vous pouvez configurer un filtre de sécurité plus fort en répertoriant explicitement tous les protocoles et services qui doivent être acceptés, et en terminant le filtre par un terme « tout refuser », implicitement ou explicitement, pour filtrer tout le reste du trafic. L’inconvénient d’un filtre restrictif est qu’il doit être modifié chaque fois qu’un service pris en charge est ajouté ou supprimé.
[edit firewall filter imit-mgmt-access] user@R2# set term accept_everything_else then accept
Appliquez le filtre de pare-feu sans état à l’interface de bouclage en tant que filtre d’entrée. Dans cet exemple, le trafic envoyé à partir de l’appareil local n’est pas filtré.
[edit interfaces lo0 unit 0 ] user@R2# set family inet filter input limit-mgmt-access
Résultats
Confirmez votre travail en entrant les commandes suivantes show configuration à partir du mode de configuration. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
user@R2# show policy-options
prefix-list manager-ip {
172.16.0.0/24;
10.0.0.1/32;
}
user@R2# show firewall
filter limit-mgmt-access {
term block_non_manager {
from {
source-address {
0.0.0.0/0;
}
source-prefix-list {
manager-ip except;
}
protocol tcp;
destination-port [ ssh telnet ];
}
then {
log;
discard;
}
}
term accept_everything_else {
then accept;
}
}
user@R2# show interfaces
fxp0 {
unit 0 {
family inet {
address 172.16.0.253/24;
}
}
}
lo0 {
unit 0 {
family inet {
filter {
input limit-mgmt-access;
}
address 192.168.255.2/32;
}
}
}
user@R2# show routing-options
static {
route 0.0.0.0/0 {
next-hop 172.16.0.254;
no-readvertise;
}
}
user@R2# show system services ssh; telnet;
Lorsque vous êtes satisfait de votre travail, passez commit du mode de configuration.
Lorsque vous appliquez un filtre qui restreint l’accès à l’appareil, pensez à utiliser commit confirmed. Cette option annule automatiquement la configuration si vous n’êtes pas en mesure d’émettre un autre commit dans le délai spécifié.
Vérifier le filtre du pare-feu sans état
Vérifiez que le filtre de pare-feu pour limiter l’accès à la gestion 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 172.16.0.0/24 ou du préfixe d’hôte 10.0.0.1 associé à la station de gestion distante.
Action
Effacez le journal du pare-feu sur votre routeur ou commutateur.
user@R2> clear firewall log
À partir d’un hôte attaché au sous-réseau 172.16.0.0/24, tel que le périphérique R1, utilisez la
ssh 172.16.0.253commande pour initier une connexion au DUT. Par défaut, l’appareil R1 source son trafic à partir de l’interface de sortie utilisée pour atteindre la destination. Par conséquent, le trafic de test provient de l’adresse 172.16.0.254 de R1. Ce trafic ne correspond pas au block_non_manager terme de filtre en raison du modificateur d’action pour lesexceptadresses qui correspondent à la liste de préfixes référencés. Ce trafic correspond au terme de accept_everything_else filtre qui le rend acceptéREMARQUE :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.
user@R1>ssh user@172.16.0.253 Password: Last login: Tue Sep 8 09:46:58 2020 from 10.107.199.39 --- JUNOS 20.2R1.10 Kernel 64-bit XEN JNPR-11.0-20200608.0016468_buil user@R2>
Déconnectez-vous de l’interface de ligne de commande sur le périphérique R2 pour fermer la session SSH.
user@R2> exit logout Connection to 172.16.0.253 closed. user@R1>
REMARQUE :Répétez cette étape à l’aide de la
telnetcommande. La connexion Telnet devrait réussir.Utilisez la commande sur le périphérique R2 pour vérifier que la
show firewall logmémoire tampon du journal du pare-feu sur le périphérique R2 ne contient pas d’entrées avec une adresse source dans le sous-réseau 172.16.0.0/24. Cela signifie que les informations d’en-tête de paquet pour ce trafic ne sont pas consignées dans le journal de filtrage du pare-feu. Dans cet exemple, seul le trafic correspondant au block_non_manager terme est consigné.user@R2> show firewall log user@R2>
Sens
La sortie confirme que les connexions SSH (et Telnet) sont acceptées lorsqu’elles proviennent du réseau de gestion. Il montre également que les paquets qui ne correspondent pas au block_non_manager terme ne sont pas enregistrés. Les mêmes résultats sont attendus si le trafic SSH ou Telnet est généré par la station de gestion distante à laquelle l’adresse 10.0.0.1 est attribuée.
Vérifier les paquets consignés et rejetés
But
Vérifiez que le filtre de pare-feu rejette correctement le trafic SSH et Telnet qui ne provient pas de l’un des préfixes de la manager-ip liste de préfixes.
Action
Générez du trafic SSH provenant d’une adresse qui n’est pas spécifiée dans la liste des manager-ip préfixes. Vous pouvez sourcer la session à partir de l’adresse de bouclage du périphérique R1 pour simuler une adresse IP non autorisée. Vous pouvez également établir la connexion à partir d’un périphérique distant qui n’est pas connecté au sous-réseau de gestion et auquel l’adresse IP 10.0.0.1 n’a pas été attribuée. Les paquets de cette session SSH doivent être ignorés 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.
REMARQUE :Vous ne devez pas vous attendre à un message d’erreur ou à une réponse. La tentative de connexion expirera. Cela est dû au fait que le filtre d’échantillon utilise un plutôt qu’une
discardrejectaction.user@unauthorized-remote-host ssh user@172.16.0.253 ssh: connect to host 172.16.0.253 port 22: Connection timed out
La sortie indique que la connexion SSH échoue. Cela confirme que le filtre bloque correctement le trafic SSH lorsqu’il est envoyé à partir d’une adresse source non autorisée. Le même résultat est attendu pour les sessions Telnet initiées par une adresse IP source non autorisée.
Utilisez la commande pour vérifier que la
show firewall logmémoire tampon du journal du pare-feu sur le périphérique R2 contient désormais des entrées pour les paquets dont l’adresse source n’est pas autorisée.user@R2> show firewall log Log : Time Filter Action Interface Protocol Src Addr Dest Addr 11:35:46 limit-mgmt-access D fxp0.0 TCP 10.0.0.119 172.16.0.253 11:35:14 limit-mgmt-access D fxp0.0 TCP 10.0.0.119 172.16.0.253 11:34:58 limit-mgmt-access D fxp0.0 TCP 10.0.0.119 172.16.0.253
Sens
La sortie confirme que le trafic provenant de l’adresse source 10.0.0.119 correspond à un terme de journalisation dans le limit-mgmt-access filtre. Rappelez-vous que seul le block_non_manager terme a une action de journal dans cet exemple. La Action colonne affiche un pour D indiquer que les paquets ont été ignorés. Il est confirmé que l’interface d’entrée du trafic filtré est le port fxp0.0 de gestion de l’équipement. Le protocole TCP de transport et les adresses IP des paquets filtrés sont également affichés. Notez que l’adresse 10.0.0.119 source de ce trafic n’est pas répertoriée dans la liste des manager-ip préfixes.
Ces résultats confirment que le filtre de pare-feu fonctionne correctement pour cet exemple.