DifficileChoix unique

Question d'entraînement 200-301

Exhibit

Requirement:
- Block HTTPS from 10.20.20.0/24 to 172.16.5.10
- Allow all other traffic

Configured entry:
deny ip 10.20.20.0 0.0.0.255 host 172.16.5.10

D'après l'illustration, pourquoi l'ACL ne respecte-t-elle pas l'exigence de bloquer uniquement le trafic HTTPS vers le serveur ?

Choisissez la meilleure réponse.

Bonne réponse

AParce que l'entrée de l'ACL est trop large et bloque tout le trafic IP vers l'hôte.

Explication

L'ACL échoue car elle utilise 'deny ip', ce qui bloque tout le trafic IP vers le serveur et pas seulement le HTTPS. Pour bloquer uniquement le HTTPS, l'ACL doit cibler le port TCP 443 avec 'deny tcp eq 443'. L'option B est incorrecte car le HTTPS utilise TCP et non UDP. L'option C est incorrecte car les ACL étendues (et non standard) sont requises pour filtrer par port. L'option D est incorrecte car une destination de type host est parfaitement valide dans les ACL étendues ; un sous-réseau avec wildcard n'est pas obligatoire.

Pourquoi chaque option est juste ou fausse

Juste

Parce que l'entrée de l'ACL est trop large et bloque tout le trafic IP vers l'hôte.

L'entrée de l'ACL utilise le mot-clé 'ip', qui correspond à tous les protocoles IP, y compris TCP, UDP, ICMP et GRE. Pour bloquer uniquement le HTTPS, l'administrateur doit spécifier 'tcp' et cibler le port de destination 443, comme dans 'deny tcp any host 192.0.2.10 eq 443'. Puisque 'deny ip' englobe tout, il empêche l'ensemble du trafic vers l'hôte et pas seulement le HTTPS, ce qui explique pourquoi l'ACL ne satisfait pas l'exigence.

Fausse

Parce que le HTTPS utilise UDP et non TCP.

Le HTTPS est du HTTP fonctionnant sur TLS et utilise traditionnellement TCP pour un acheminement fiable, avec le port de destination 443. Cette option confond le HTTPS avec QUIC, un transport HTTP/3 qui utilise le port UDP 443, mais le HTTPS en soi n'utilise pas UDP. L'ACL en question ayant été rédigée pour le HTTPS basé sur TCP, cette justification est factuellement erronée.

Fausse

Parce que des ACL standard sont requises pour le filtrage HTTPS.

Les ACL standard sont numérotées de 1 à 99 et de 1300 à 1999, et elles ne peuvent filtrer qu'en se basant sur l'adresse IP source ; elles ne peuvent pas correspondre à un protocole, un port de destination ou une adresse de destination. Le filtrage HTTPS requiert une ACL étendue, numérotée de 100 à 199 ou de 2000 à 2699, qui fournit les capacités de correspondance 'tcp' et 'eq 443'. Par conséquent, l'affirmation selon laquelle des ACL standard sont nécessaires est fausse.

Fausse

Parce que la destination doit toujours être un sous-réseau avec wildcard et non un hôte.

Le mot-clé 'host' dans une ACL est un raccourci pour un masque wildcard de 0.0.0.0, correspondant exactement à l'adresse spécifiée, ce qui est valide pour les destinations dans les ACL étendues. Une destination n'a pas besoin d'être un sous-réseau avec wildcard ; l'utilisation de 'host 192.0.2.10' constitue une méthode précise et courante pour cibler un serveur individuel. Ainsi, l'assertion selon laquelle un sous-réseau avec wildcard est obligatoire est fausse.

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 tels que le protocole, les adresses IP source et destination, ainsi que les numéros de port. Les ACL étendues offrent un contrôle granulaire en permettant le filtrage sur les paramètres de couche 3 et de couche 4, y compris les ports TCP/UDP, ce qui est indispensable pour un filtrage spécifique à un protocole comme HTTPS. Le trafic HTTPS utilise spécifiquement le port TCP 443 ; par conséquent, une ACL destinée à bloquer uniquement le HTTPS doit explicitement interdire le trafic TCP sur le port 443 tout en autorisant le reste du trafic. Lors de la conception d'une ACL visant à bloquer uniquement le trafic HTTPS vers un serveur, la règle doit correspondre précisément au protocole TCP et au port de destination 443. L'utilisation d'une instruction générale telle que "deny ip" bloque l'ensemble du trafic IP, indépendamment du protocole ou du port, ce qui est excessivement restrictif et ne répond pas aux exigences. Le processus décisionnel consiste à sélectionner une ACL étendue avec une instruction deny pour le port de destination TCP 443, suivie d'une instruction permit pour le reste du trafic, garantissant ainsi que seul le HTTPS est bloqué et que tous les autres services restent accessibles. Un piège d'examen classique consiste à confondre les interdictions IP globales et les interdictions spécifiques à un protocole. L'utilisation de "deny ip" dans une ACL bloque tout le trafic IP et non seulement le HTTPS, ce qui peut provoquer des pannes réseau ou des interruptions de service involontaires. Concrètement, cela signifie que le trafic légitime tel que HTTP, DNS ou ICMP se trouve également bloqué. Comprendre la différence entre les ACL standard et étendues ainsi que l'importance de spécifier le protocole et les numéros de port est essentiel pour éviter cette erreur et pour implémenter des politiques de sécurité précises dans des 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.