DifficileChoix unique

Question d'entraînement 200-301

Un administrateur souhaite autoriser le trafic HTTPS provenant d'un sous-réseau source vers un serveur, mais refuser tout le trafic Telnet provenant de ce même sous-réseau vers le même serveur. Quelle capacité d'ACL est requise pour exprimer cette règle avec précision ?

Choisissez la meilleure réponse.

Bonne réponse

AUne ACL étendue capable de faire correspondre les informations de protocole et de port de destination

Explication

La politique nécessite la capacité d'une ACL étendue car elle doit distinguer le trafic par protocole et par port de destination, et non seulement par adresse source. Concrètement, la règle doit traiter le port TCP 443 différemment du port TCP 23, même si les réseaux source et de destination sont les mêmes. Une ACL standard est trop limitée pour cela. Cette question porte sur la précision du filtrage. Lorsque la politique dépend du protocole et du port, les ACL étendues constituent l'outil approprié.

Pourquoi chaque option est juste ou fausse

Juste

Une ACL étendue capable de faire correspondre les informations de protocole et de port de destination

Une ACL étendue est l'outil approprié car elle évalue à la fois le type de protocole (TCP) et le port de destination (443) dans ses instructions permit ou deny, donnant au routeur la granularité nécessaire pour autoriser uniquement le HTTPS tout en bloquant les autres services basés sur TCP. Contrairement aux ACL standard, les ACL étendues peuvent être placées au plus près de la source et appliquer tout de même la politique sur la base d'informations de niveau 4. L'exigence spécifique d'autoriser le HTTPS depuis le sous-réseau source et de refuser tout le reste du trafic, y compris Telnet, ne peut pas être satisfaite sans cette correspondance au niveau des ports.

Fausse

Une ACL standard car la correspondance de la source est suffisante

Une ACL standard fait uniquement correspondre l'adresse IP source (ou le sous-réseau) dans chaque règle et ne comporte aucun champ pour le protocole ou le port de destination, de sorte qu'elle ne peut pas différencier le HTTPS du Telnet ou de toute autre application. Même si vous faites correspondre exactement le sous-réseau source, une ACL standard autoriserait soit tout le trafic de ce sous-réseau, soit le refuserait entièrement, ce qui ne satisfait pas l'exigence d'autoriser uniquement le HTTPS tout en refusant le reste du trafic. Ainsi, la correspondance de la source seule est insuffisante pour cette politique.

Fausse

Un masque générique (wildcard mask) avec uniquement des zéros

Un masque générique (wildcard mask) avec uniquement des zéros (0.0.0.0) correspond à une seule adresse IP d'hôte exacte et, par lui-même, n'offre aucune capacité à distinguer les protocoles ou les ports de destination dans une ACL. Bien qu'un masque générique soit un composant d'une entrée d'ACL étendue, il définit uniquement les bits d'adresse qui doivent correspondre ; il n'indique rien au routeur concernant le service HTTPS. Pour autoriser le HTTPS, vous auriez toujours besoin des champs de protocole et de port d'une ACL étendue, de sorte que cette option est incomplète et incorrecte pour la politique énoncée.

Fausse

Une ACL SSID sans fil

Une ACL SSID sans fil contrôle quels appareils clients peuvent s'associer à un nom WLAN particulier (SSID) ou ce qu'ils peuvent faire au niveau de la couche liaison sans fil, et non quel trafic IP est autorisé ou refusé. La question concerne le filtrage du trafic sur le port TCP 443 d'un sous-réseau source vers un serveur, ce qui est une politique de niveau réseau indépendante du nom du réseau sans fil ou de ses règles d'association. Par conséquent, une ACL SSID ne peut pas appliquer le comportement d'autorisation/refus HTTPS requis.

Pour aller plus loin

Les Access Control Lists (ACLs) sont des outils fondamentaux dans les réseaux Cisco utilisés pour filtrer le trafic en fonction de critères définis. Les ACL standard filtrent le trafic uniquement sur la base des adresses IP sources, ce qui limite leur capacité à différencier les types de trafic. Les ACL étendues offrent en revanche un contrôle granulaire en permettant un filtrage basé sur plusieurs paramètres, notamment les adresses IP source et de destination, les types de protocoles (tels que TCP ou UDP) et des numéros de port spécifiques. Cette capacité est essentielle lorsque les politiques exigent de distinguer le trafic de différentes applications, telles que HTTPS et Telnet. Dans le scénario où un administrateur souhaite autoriser le trafic HTTPS (port TCP 443) tout en refusant le trafic Telnet (port TCP 23) depuis le même sous-réseau source vers un serveur, une ACL étendue est nécessaire. L'ACL étendue peut faire correspondre explicitement le protocole TCP et le numéro de port de destination, permettant un contrôle précis sur le trafic autorisé ou refusé. Les ACL standard ne peuvent pas différencier le trafic par port ou par protocole, ce qui les rend insuffisantes pour cette exigence. Un piège fréquent aux examens consiste à supposer que les ACL standard peuvent appliquer des politiques basées sur les types d'applications ou les ports, ce qu'elles ne peuvent pas faire. Les ACL étendues sont le bon choix car elles fournissent la granularité de filtrage nécessaire. En pratique, l'utilisation d'ACL étendues garantit que seul le trafic souhaité (HTTPS) atteint le serveur, tandis que le trafic indésirable (Telnet) est bloqué, renforçant ainsi la sécurité du réseau et la conformité aux politiques d'accès.

À 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.