DifícilOpción múltiple

Pregunta de práctica de 200-301

Un administrador desea permitir el tráfico HTTPS desde una subred de origen hacia un servidor, pero denegar todo el tráfico Telnet desde esa misma subred hacia el mismo servidor. ¿Qué capacidad de ACL se requiere para expresar esa política con precisión?

Elige la mejor respuesta.

Respuesta correcta

AUna extended ACL que pueda coincidir con la información del protocolo y del puerto de destino

Explicación

La política requiere la capacidad de una extended ACL porque debe distinguir el tráfico por protocolo y puerto de destino, no solo por la dirección de origen. En términos prácticos, la regla necesita tratar el puerto TCP 443 de manera diferente al puerto TCP 23, aunque las redes de origen y destino sean las mismas. Una standard ACL es demasiado limitada para eso. Esta pregunta trata sobre la precisión en la coincidencia. Cuando la política depende del protocolo y del puerto, las extended ACLs son la herramienta adecuada.

Por qué cada opción es correcta o incorrecta

Correcta

Una extended ACL que pueda coincidir con la información del protocolo y del puerto de destino

Una extended ACL es la herramienta correcta porque evalúa tanto el tipo de protocolo (TCP) como el puerto de destino (443) en sus declaraciones de permiso o denegación, lo que le otorga al router la granularidad necesaria para permitir únicamente HTTPS mientras bloquea otros servicios basados en TCP. A diferencia de las standard ACLs, las extended ACLs se pueden colocar lo más cerca posible del origen y aun así aplicar la política basada en información de capa 4. El requisito específico de permitir HTTPS desde la subred de origen y denegar todo el resto del tráfico, incluido Telnet, no se puede cumplir sin esta coincidencia a nivel de puerto.

Incorrecta

Una standard ACL porque la coincidencia de origen es suficiente

Una standard ACL coincide únicamente con la dirección IP de origen (o subred) en cada regla y no tiene campos para el protocolo o el puerto de destino, por lo que no puede diferenciar HTTPS de Telnet ni de ninguna otra aplicación. Incluso si coincide con la subred de origen exacta, una standard ACL permitiría todo el tráfico de esa subred o lo denegaría todo, lo que no satisface el requisito de permitir solo HTTPS mientras se deniega el otro tráfico. Por lo tanto, la coincidencia de origen por sí sola es insuficiente para esta política.

Incorrecta

Una máscara wildcard con solo todos ceros

Una máscara wildcard con solo todos ceros (0.0.0.0) coincide con una única dirección IP de host exacta y, por sí sola, no ofrece ninguna capacidad para distinguir protocolos o puertos de destino en una ACL. Si bien una máscara wildcard es un componente de una entrada de extended ACL, solo define qué bits de dirección deben coincidir; no le indica al router nada sobre el servicio HTTPS. Para permitir HTTPS, aún se necesitarían los campos de protocolo y puerto de una extended ACL, por lo que esta opción está incompleta y es incorrecta para la política establecida.

Incorrecta

Una ACL de SSID inalámbrico

Una ACL de SSID inalámbrico controla qué dispositivos cliente se pueden asociar a un nombre de WLAN (SSID) en particular o qué pueden hacer en la capa de enlace inalámbrico, no qué tráfico IP se permite o se deniega. La pregunta trata sobre el filtrado del tráfico del puerto TCP 443 desde una subred de origen hacia un servidor, lo cual es una política de capa de red independiente del nombre de la red inalámbrica o de sus reglas de asociación. Por lo tanto, una ACL de SSID no puede aplicar el comportamiento requerido de permitir o denegar HTTPS.

Para profundizar

Las Listas de Control de Acceso (ACLs) son herramientas fundamentales en las redes Cisco que se utilizan para filtrar el tráfico según criterios definidos. Las standard ACLs filtran el tráfico únicamente en función de las direcciones IP de origen, lo que limita su capacidad para diferenciar tipos de tráfico. Sin embargo, las extended ACLs proporcionan un control detallado al permitir el filtrado basado en múltiples parámetros, que incluyen direcciones IP de origen y destino, tipos de protocolo (como TCP o UDP) y números de puerto específicos. Esta capacidad es esencial cuando las políticas requieren distinguir entre diferentes tráficos de aplicaciones, como HTTPS y Telnet. En el escenario donde un administrador desea permitir el tráfico HTTPS (puerto TCP 443) mientras deniega el tráfico Telnet (puerto TCP 23) desde la misma subred de origen hacia un servidor, es necesaria una extended ACL. La extended ACL puede coincidir explícitamente con el protocolo TCP y el número de puerto de destino, lo que permite un control preciso sobre qué tráfico se permite o se deniega. Las standard ACLs no pueden diferenciar el tráfico por puerto o protocolo, lo que las hace insuficientes para este requisito. Una trampa común de los exámenes es asumir que las standard ACLs pueden aplicar políticas basadas en tipos de aplicaciones o puertos, lo cual no pueden hacer. Las extended ACLs son la opción correcta porque proporcionan la granularidad de filtrado necesaria. En la práctica, el uso de extended ACLs garantiza que solo el tráfico deseado (HTTPS) llegue al servidor, mientras que el tráfico no deseado (Telnet) se bloquea, lo que mejora la seguridad de la red y el cumplimiento de las políticas de acceso.

Sobre estas preguntas de práctica

Esta es una de las preguntas de práctica originales de 200-301 de Courseiva, escrita para aprender y nunca copiada de exámenes reales ni de dumps.

Traducida del original en inglés con IA y revisada para comprobar el sentido. Los códigos de examen, los comandos y los nombres de productos se mantienen tal como aparecen en el examen.