Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Exemple: Accès à la gestion des contrôles sur Juniper périphériques réseau

Remarque :

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

Cet exemple montre comment limiter l’accès de gestion aux Juniper réseau en fonction d’un ensemble spécifique d’adresses IP autorisées. Ce type de fonctionnalité est souvent appelé liste de contrôle d’accès (ACL) et est implémenté sous la forme d’un filtre de pare-feu sans état dans Junos OS.

Conditions préalables

Équipement Juniper réseau connecté à un réseau de gestion. Pour faciliter la validation de la configuration, au moins un autre équipement ayant un accès au réseau de gestion peut établir des connexions SSH ou Telnet à l’équipement à l’épreuve (DUT). Aucune configuration particulière au-delà de l’initialisation de base de l’équipement (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 qui peuvent gérer un équipement. Ce filtre de pare-feu doit inclure un terme qui interdit tout trafic, sauf les adresses IP autorisées pour 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é.

Topologie d’exemple

Figure 1 montre la topologie de cet exemple. L’équipement R1 sert de passerelle par défaut au réseau de gestion affecté au sous-réseau 172.16.0.0/24. Vous appliquez le filtre qui limite l’accès de gestion à l’équipement R2, ce qui en fait le DUT dans cet exemple. Le poste de travail à distance est autorisé à gérer le DUT et a reçu l’adresse 10.0.0.1/32.

Dans cet exemple, vous pouvez:

  • Configurez une liste de préfixes appelée manager-ip. Cette liste définit l’ensemble des adresses IP autorisées à gérer l’équipement. 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 accès à la gestion par filtre de pare-feu qui rejette toutes les adresses source, à l’exception de l’ensemble d’adresses spécifiques définies dans la liste de préfixe manager-ip. Cela garantit que seules les adresses IP répertoriées dans la liste de préfixe peuvent gérer l’équipement.

  • Appliquez le filtre d’accès à la gestion limitée à l’interface de bouclation. Chaque fois qu’un paquet adressé à l’équipement local arrive sur n’importe quelle interface, l’interface de bouclage applique l’accès à la gestion par limite de filtre pour limiter l’accès à la gestion aux adresses uniquement autorisées.

Figure 1 : Topologie de réseau par exempleTopologie de réseau par exemple

Configurer une liste d’adresses IP pour restreindre l’accès de gestion à un équipement

Procédure

CLI configuration rapide

Pour configurer rapidement cet exemple, modifiez les commandes suivantes selon vos besoins et collez-les dans l’CLI de l’équipement R2 au niveau [edit] de la hiérarchie. Pour être complète, la configuration inclut des commandes pour configurer SSH (pour les non-utilisateurs) et les services du système Telnet. Il fournit également la configuration de l’interface de gestion et du routeur statique associé. Ces commandes ne sont pas nécessaires si votre équipement dispose déjà de cette fonctionnalité configurée.

Remarque :

Telnet ne prend pas en charge la connexion sur Juniper Networks périphériques mobiles. La connexion SSH pour l’utilisateur n’est pas configurée dans cet exemple. Un utilisateur non-utilisateur doit être configuré pour permettre une connexion à distance. Vous pouvez également ajouter l’argument à -login allow l’énoncé system services ssh afin d’autoriser la connexion à l’aide de SSH.

Assurez-vous d’émettre un commit numéro de mode de configuration pour activer les modifications.

Conseil :

Lorsque vous appliquez un filtre qui restreint l’accès à l’équipement, envisagez d’utiliser commit confirmed . Cette option revient automatiquement à la configuration si vous n’êtes pas en mesure d’émettre une autre validation dans l’heure spécifiée.

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 manière de vous y rendre, consultez le manuel Using the CLI Editor in Configuration Mode dans le CLI User Guide.

  1. Configurez les interfaces de gestion et de bouclant et assurez-vous que les services système Telnet et SSH sont activés.

    Remarque :

    Telnet ne prend pas en charge la connexion sur Juniper Networks périphériques mobiles. La connexion SSH pour l’utilisateur n’est pas configurée dans cet exemple. Un utilisateur non-utilisateur doit être configuré pour permettre une connexion à distance. Vous pouvez également ajouter l’argument à -login allow l’énoncé system services ssh afin d’autoriser la connexion à l’aide de SSH.

  2. Définir l’ensemble des adresses hôtes autorisées dans la liste de préfixes. Cette liste comprend des préfixes pour le sous-réseau de gestion et une seule station de gestion à distance autorisée.

    La liste des préfixes est référencé dans le filtre de pare-feu. L’utilisation d’une liste de préfixes facilite la mise à jour des adresses permettant d’accéder à l’équipement. Car seule la liste de préfixes doit être mise à jour. Aucune modification n’est requise au filtre de pare-feu lui-même lors de l’ajout ou de la suppression des préfixes autorisés.

  3. Configurez un filtre de pare-feu pour refuser le trafic Telnet et SSH à partir de toutes les adresses IP, sauf celles définies dans la liste de préfixes.

    Notez l’utilisation du except modifier l’action. Le premier terme correspond à toutes les adresses source possibles. Le terme suivant inverse la correspondance pour ces adresses source dans la liste de préfixe spécifiée. Il en résulte que le trafic de gestion destiné au protocole et aux ports spécifiés n’est accepté que lorsque le trafic provient d’une adresse de la liste. Le trafic provenant de tous les autres préfixes source vers la même combinaison de protocole et de ports est éliminé. Dans cet exemple, une action de journalisation est ajoutée pour faciliter le débogage et la vérification des filtres.

  4. Configurez un terme par défaut pour accepter tout le autre trafic. Cela garantit que d’autres services et protocoles, par exemple les pings, BGP, OSPF, ne sont pas affectés par le filtre.

    Conseil :

    Le filtre d’exemple est par conception permissive. Cette menace peut représenter une menace de sécurité, car elle accepte explicitement tout le trafic qui n’a pas été rejeté ou éliminé par les termes de filtres précédents. Vous pouvez configurer un filtre de sécurité plus robuste en listant de manière explicite tous les protocoles et services qui doivent être acceptés mettant fin au filtre avec un refus de tout terme, implicitement ou explicitement, pour filtrer tout le trafic. L’inconvénient d’un filtre à filtre à filtres à filtres a été modifié chaque fois qu’un service pris en charge est ajouté ou supprimé.

  5. Appliquez le filtre de pare-feu sans état à l’interface de bouclation en tant que filtre d’entrée. Le trafic envoyé à partir de l’équipement local n’est pas filtré dans cet exemple.

Résultats

Confirmez votre travail en entrant les commandes show configuration suivantes à partir du mode de configuration. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration dans cet exemple pour la corriger.

Une fois que vous êtes satisfait de votre travail, entrez commit depuis le mode de configuration.

Conseil :

Lorsque vous appliquez un filtre qui restreint l’accès à l’équipement, envisagez d’utiliser commit confirmed . Cette option revient automatiquement à la configuration si vous n’êtes pas en mesure d’émettre une autre validation dans l’heure spécifiée.

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

Vérifier que le filtre de pare-feu pour limiter les accès de 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 est issu du sous-réseau 172.16.0.0/24 ou du préfixe hôte 10.0.0.1 associé à la station de gestion à distance.

Action

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

  2. À partir d’un hôte relié au sous-réseau 172.16.0.0/24, tel que l’équipement R1, utilisez la commande pour établir une connexion au ssh 172.16.0.253 DUT. Par défaut, les sources de l’équipement R1 sont le trafic depuis l’interface de sortie utilisée pour atteindre sa destination. Le trafic test est donc issu de l’adresse 172.16.0.254 de R1. Ce trafic ne correspond pas au terme block_non_manager en raison du modifier l’action pour les adresses qui correspondent à la liste de except préfixes référencé. Ce trafic correspond au terme accept_everything_else qui lui permet d’être accepté

    Remarque :

    Si c’est la première connexion SSH en tant qu’utilisateur entre ces équipements, vous serez invité à enregistrer la clé d’hôte SSH.

  3. Vous vous déconnectez du CLI au niveau de l’équipement R2 pour fermer la session SSH.

    Remarque :

    Répétez cette étape à l’aide de la telnet commande. La connexion Telnet doit réussir.

  4. Utilisez la commande sur l’équipement R2 pour vérifier que la mise en mémoire tampon du pare-feu sur l’équipement R2 ne contient pas d’entrées contenant une adresse source dans le sous-réseau show firewall log 172.16.0.0/24. Cela signifie que les informations de l’en-tête des paquets pour ce trafic ne sont pas consignées dans le journal des filtres de pare-feu. Seul le trafic qui correspond au block_non_manager terme est enregistré dans cet exemple.

Sens

La sortie confirme que les connexions SSH (et Telnet) sont acceptées lors de la source du réseau de gestion. Il indique é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 à distance qui est affectée à l’adresse 10.0.0.1.

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

But

Vérifiez que le filtre de pare-feu écarte correctement le trafic SSH et Telnet qui n’est pas à l’origine de l’un des préfixes de la liste de préfixes ip gestionnaire.

Action

  1. Générer du trafic SSH provenant d’une adresse non spécifiée dans la liste de préfixe manager-ip. Vous pouvez sourcer la session à partir de l’adresse loopback de l’équipement R1 pour simuler une adresse IP non autorisée. Ou établir la connexion depuis n’importe quel équipement distant non connecté au sous-réseau de gestion et qui n’a pas reçu d’adresse IP 10.0.0.1. Les paquets de cette session SSH doivent être éliminés et les informations d’en-tête des paquets doivent être consignées dans la mise en mémoire tampon du filtre de pare-feu.

    Remarque :

    Vous ne devez pas attendre de message d’erreur ou de réponse. La tentative de connexion prendra fin. Cela est dû au fait que le filtre de l’échantillon utilise une discard action plutôt reject qu’une action.

    La sortie indique que la connexion SSH n’a pas réussi. Cela confirme que le filtre bloque correctement le trafic SSH lorsqu’il est envoyé à partir d’une adresse source non officielle. Le même résultat est attendu pour les sessions Telnet initiées par toute adresse source IP non autorisée.

  2. Utilisez la commande pour vérifier que la mise en mémoire tampon du pare-feu sur l’équipement R2 contient désormais des entrées pour les paquets avec une show firewall log adresse source non autorisée.

Sens

La sortie confirme que le trafic de l’adresse source 10.0.0.119 correspond à un terme de journalisation dans le filtre d’accès à la gestion limitée. Rappel: seul le terme « block_non_manager » possède une action de journal dans cet exemple. La Action colonne affiche une pour indiquer que les D paquets ont été éliminés. L’interface d’entrée du trafic filtré est confirmée comme port de gestion fxp0.0 de l’équipement. Les adresses IP et le protocole de transport des TCP paquets filtres sont également affichés. Notez que l’adresse source de ce trafic n’est pas répertoriée dans la liste des 10.0.0.119 préfixes manager-ip.

Ces résultats confirment que le filtre de pare-feu fonctionne correctement pour cet exemple.