Une ACL sur R1 contient uniquement ces entrées :
access-list 101 permit tcp 10.10.10.0 0.0.0.255 any eq 443 access-list 101 permit icmp any any
Que se passe-t-il pour un paquet HTTP provenant de 10.10.10.25 et destiné à 198.51.100.10 si l'ACL 101 est appliquée sur le chemin du trafic ?
Choisissez la meilleure réponse.
Bonne réponse
HTTP utilise le port TCP 80, et non 443. Étant donné que l'ACL n'inclut pas d'autorisation pour ce trafic, il est rejeté par le deny implicite situé à la fin de l'ACL. L'entrée ICMP n'est pas pertinente car le paquet est de type TCP.
Il est autorisé car le sous-réseau source est autorisé.
L'ACL n'autorise pas globalement le sous-réseau source ; elle utilise une entrée d'ACL étendue qui autorise uniquement le trafic TCP destiné au port 443, et non tout le trafic provenant de ce sous-réseau. Un paquet HTTP provenant de ce sous-réseau est destiné au port 80, ce qui ne satisfait pas la condition de port de destination de la seule instruction permit TCP. Étant donné que le sous-réseau source seul ne suffit pas à faire correspondre l'ACL, le paquet n'est pas autorisé par cette instruction et passe à la règle de deny implicite située à la fin de l'ACL 101.
Il est bloqué par le deny implicite.
Le paquet HTTP, qui utilise le port TCP 80, ne correspond pas à la première entrée de l'ACL, laquelle autorise spécifiquement le trafic TCP uniquement pour le port de destination 443. Il ne correspond pas non plus à la seconde entrée, qui autorise le trafic ICMP. Comme le paquet ne correspond à aucune instruction `permit` explicite au sein de l'ACL 101, il est traité par le `deny ip any any` implicite présent à la fin de chaque access control list Cisco. Ce mécanisme garantit que le paquet HTTP est refusé.
Il est traduit par NAT avant que l'ACL ne soit vérifiée.
Cette option applique incorrectement le rôle de NAT dans le filtrage de paquets. Dans Cisco IOS, l'ordre de traitement entre NAT et ACL dépend de l'interface et du sens (par exemple, le NAT inside peut se produire avant une ACL sortante), mais aucune configuration NAT n'est fournie dans le scénario. Même si le NAT était présent, il réécrirait uniquement les adresses IP, et non le port de destination TCP du port HTTP 80 vers le port HTTPS 443. Par conséquent, le paquet ne parvient toujours pas à correspondre à l'autorisation explicite pour le port 443 et est finalement bloqué par le deny implicite.
Il est converti automatiquement en HTTPS.
Les routeurs ne réécrivent pas automatiquement les protocoles de la couche application et ne modifient pas les ports de destination. HTTP et HTTPS sont des protocoles distincts utilisant des ports TCP différents (80 par rapport à 443), et l'ACL effectue la correspondance sur le port de destination littéral présent dans l'en-tête du paquet. À moins qu'une passerelle de niveau application ou qu'une règle d'inspection explicite ne soit configurée pour modifier le port — ce qui n'est pas présent dans ce scénario basé uniquement sur une ACL — le paquet HTTP reste sur le port 80 et ne peut pas correspondre à l'autorisation pour le port 443. Par conséquent, le paquet enfreint le deny implicite et est éliminé.
Les Access Control Lists (ACLs) sont des outils de sécurité fondamentaux dans les réseaux Cisco qui filtrent le trafic en fonction de critères définis tels que les adresses IP source et destination, les protocoles et les numéros de port. Les ACLs sont traitées de manière séquentielle et, dès qu'un paquet correspond à une entrée, l'action permit ou deny correspondante est appliquée immédiatement. Si aucune entrée ne correspond, un deny implicite à la fin de l'ACL rejette le paquet par défaut. Ce comportement garantit que seul le trafic explicitement autorisé passe, renforçant ainsi la sécurité du réseau et le contrôle du trafic. Dans ce scénario, l'ACL 101 autorise le trafic TCP provenant du sous-réseau 10.10.10.0/24 uniquement s'il est destiné à n'importe quelle adresse sur le port 443 (HTTPS). Elle autorise également tout le trafic ICMP, indépendamment de la source ou de la destination. Puisque le trafic HTTP utilise le port TCP 80, un paquet provenant de 10.10.10.25 vers 198.51.100.10 sur le port 80 ne correspond à aucune instruction permit. Par conséquent, la règle de deny implicite de l'ACL bloque ce paquet HTTP. Cela démontre l'importance de spécifier des protocoles et des ports corrects dans les ACLs afin d'éviter les rejets de trafic non intentionnels. Un piège d'examen courant consiste à supposer qu'autoriser un sous-réseau dans une ACL permet automatiquement tout le trafic provenant de ce sous-réseau. Cependant, les ACLs sont explicites et nécessitent des correspondances exactes sur les protocoles et les numéros de port. Un autre piège est de mal comprendre la règle du deny implicite, qui supprime silencieusement les paquets non correspondants sans journalisation par défaut. En pratique, cela signifie que les administrateurs réseau doivent concevoir soigneusement les ACLs pour inclure toutes les instructions permit nécessaires et comprendre que tout trafic non explicitement autorisé sera refusé, garantissant ainsi un comportement réseau prévisible et sécurisé.
À 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.