DifficileChoix unique

Question d'entraînement 200-301

Un routeur autorise la gestion SSH depuis n'importe quel emplacement du réseau interne. Une nouvelle politique exige que seul le subnet de management 10.50.50.0/24 soit autorisé à initier des connexions SSH vers l'équipement. Quelle approche permet de répondre au mieux à cette exigence ?

Choisissez la meilleure réponse.

Bonne réponse

ARestreindre l'accès SSH de sorte que seul le subnet de management 10.50.50.0/24 soit autorisé

Explication

La meilleure approche consiste à utiliser un mécanisme de contrôle d'accès qui limite l'accès SSH au subnet source approuvé. Concrètement, SSH est le protocole sécurisé adéquat, mais le choix du protocole ne suffit pas à lui seul. L'équipement doit également restreindre les hôtes autorisés à accéder à ce service de management. Cela implique généralement d'appliquer une ACL ou une restriction source équivalente ciblant le subnet de management. Il s'agit d'un modèle de sécurité du plan de management courant : utiliser un protocole sécurisé, puis limiter l'ensemble des sources de confiance autorisées à l'utiliser.

Pourquoi chaque option est juste ou fausse

Juste

Restreindre l'accès SSH de sorte que seul le subnet de management 10.50.50.0/24 soit autorisé

Restreindre l'accès SSH au seul subnet de management 10.50.50.0/24 est l'action correcte, car elle applique une access control list (ACL) standard sur les lignes VTY ou une ACL de plan de contrôle, limitant ainsi les adresses IP source autorisées à initier des sessions SSH. Cela répond directement à l'exposition du routeur en réduisant la surface d'attaque à un réseau de management dédié et de confiance, tout en permettant aux ingénieurs autorisés d'administrer l'équipement en toute sécurité. D'autres mesures, telles que le changement de protocole ou l'activation de fonctionnalités de commutateur, ne restreignent en rien la source SSH. C'est donc la seule option qui met en œuvre la politique déclarée de restriction basée sur la source.

Fausse

Remplacer SSH par Telnet pour que le trafic soit plus facile à identifier

Remplacer SSH par Telnet aggraverait la sécurité, car Telnet transmet les identifiants et le trafic en clair, permettant à n'importe quel utilisateur du réseau interne de capturer des données sensibles à l'aide d'un simple analyseur de paquets. Bien que les paquets Telnet soient effectivement plus faciles à inspecter, cela ne constitue pas une justification valable pour les utiliser sur un réseau de production, et cela ne contribue en rien à limiter les hôtes capables d'atteindre l'interface de management du routeur. L'approche correcte consiste à conserver SSH et à appliquer une restriction de source, et non à rétrograder le protocole, car une identification plus aisée est bien moins importante que la confidentialité et l'intégrité.

Fausse

Activer PortFast sur tous les commutateurs d'accès

L'activation de PortFast sur tous les commutateurs d'accès n'a aucun rapport avec l'accès de management du routeur, car PortFast est une fonctionnalité Spanning Tree Protocol (STP) qui supprime le délai d'écoute/apprentissage pour les ports utilisateur finaux, leur permettant de passer directement à l'état de transfert. Elle est conçue pour accélérer la connectivité des hôtes après la transition d'un port à l'état actif, et elle n'a absolument aucun effet sur SSH, les listes de contrôle d'accès ou les équipements autorisés à se connecter aux lignes VTY du routeur. Par conséquent, cette modification réseau ne bloquerait ni n'accorderait l'accès SSH depuis le subnet de management, ce qui en fait une solution non pertinente pour le problème exposé.

Fausse

Augmenter le seuil de sévérité Syslog

Augmenter le seuil de sévérité Syslog est une configuration de journalisation qui contrôle les messages transférés vers un serveur Syslog, par exemple en définissant un niveau supérieur (tel que 'critical') pour supprimer les messages informatiques. Cela n'a aucun impact sur l'authentification ou l'autorisation des sessions SSH, car Syslog est un mécanisme d'audit passif et non une fonctionnalité de contrôle d'accès. Cette modification ne permet ni ne refuse à aucune adresse IP source d'accéder au service SSH du routeur ; elle ne satisfait donc pas l'exigence de restriction de l'accès de management au subnet 10.50.50.0/24.

Pour aller plus loin

Les Access Control Lists (ACL) sont des outils fondamentaux dans les réseaux Cisco, utilisés pour contrôler le flux de trafic en filtrant les paquets selon des critères tels que les adresses IP source, les adresses IP de destination et les protocoles. Dans le contexte de la gestion des routeurs, les ACL peuvent être appliquées pour restreindre les hôtes ou subnets autorisés à initier des sessions de management telles que SSH. SSH (Secure Shell) est le protocole standard de l'industrie pour la gestion à distance sécurisée, car il chiffre l'ensemble des communications, y compris les identifiants d'authentification, garantissant ainsi la confidentialité et l'intégrité. Pour appliquer une politique stipulant que seul le subnet de management 10.50.50.0/24 peut initier des connexions SSH, une ACL est créée pour autoriser le trafic SSH provenant uniquement de ce subnet et refuser toutes les autres sources. Cette ACL est ensuite appliquée aux lignes VTY (virtual terminal) du routeur ou à l'interface entrante afin de filtrer les tentatives de connexion SSH entrantes. Cette approche garantit que, même si SSH est activé globalement, seuls les hôtes de confiance du subnet de management peuvent établir des sessions, ce qui réduit efficacement la surface d'attaque et améliore la sécurité. Un piège classique d'examen consiste à confondre le choix du protocole avec le contrôle d'accès. Bien que SSH soit le protocole sécurisé adéquat, le simple fait d'activer SSH ne restreint pas les connexions. Un autre piège consiste à supposer que des fonctionnalités sans rapport, telles que PortFast ou les seuils de sévérité Syslog, influencent le contrôle d'accès, ce qui n'est pas le cas. PortFast optimise la convergence Spanning Tree et Syslog gère le niveau de détail des journaux, mais aucune de ces fonctions ne restreint l'accès SSH. Il est essentiel de comprendre la distinction entre la sécurité des protocoles et les mécanismes de contrôle d'accès pour implémenter et sécuriser correctement la gestion des équipements dans les environnements Cisco.

À propos de ces questions d'entraînement

Cette question fait partie des questions d'entraînement 200-301 originales de Courseiva, rédigées pour apprendre et jamais copiées d'examens réels ou de dumps.

Traduite de l'original anglais avec l'IA et vérifiée pour le sens. Les codes d'examen, les commandes et les noms de produits sont conservés tels qu'ils apparaissent à l'examen.