DifícilMúltipla escolha

Questão de prática de 200-301

Um administrador deseja permitir o tráfego HTTPS de uma subnet de origem para um servidor, mas negar todo o tráfego Telnet dessa mesma subnet para o mesmo servidor. Qual capacidade de ACL é necessária para expressar essa política com precisão?

Escolha a melhor resposta.

Resposta correta

AUma extended ACL que pode corresponder a informações de protocolo e porta de destino

Explicação

A política requer a capacidade de uma extended ACL porque ela deve distinguir o tráfego por protocolo e porta de destino, e não apenas pelo endereço de origem. Em termos práticos, a regra precisa tratar a porta TCP 443 de forma diferente da porta TCP 23, mesmo que as redes de origem e destino sejam as mesmas. Uma standard ACL é muito limitada para isso. Esta questão trata de precisão de correspondência. Quando a política depende do protocolo e da porta, as extended ACLs são a ferramenta correta.

Por que cada alternativa está certa ou errada

Correta

Uma extended ACL que pode corresponder a informações de protocolo e porta de destino

Uma extended ACL é a ferramenta correta porque ela avalia tanto o tipo de protocolo (TCP) quanto a porta de destino (443) em suas instruções de permit ou deny, dando ao roteador a granularidade necessária para permitir apenas HTTPS enquanto bloqueia outros serviços baseados em TCP. Ao contrário das standard ACLs, as extended ACLs podem ser colocadas mais perto da origem e ainda aplicar políticas com base em informações da camada 4. O requisito específico de permitir HTTPS da subnet de origem e negar todo o outro tráfego, incluindo Telnet, não pode ser atendido sem essa correspondência em nível de porta.

Incorreta

Uma standard ACL porque a correspondência de origem é suficiente

Uma standard ACL corresponde apenas ao endereço IP de origem (ou subnet) em cada regra e não possui campos para protocolo ou porta de destino, portanto, ela não pode diferenciar HTTPS de Telnet ou de qualquer outro aplicativo. Mesmo se você corresponder à exata subnet de origem, uma standard ACL permitiria todo o tráfego dessa subnet ou negaria tudo, o que não atende ao requisito de permitir apenas HTTPS enquanto nega outro tráfego. Assim, a correspondência de origem isolada é insuficiente para esta política.

Incorreta

Uma wildcard mask apenas com todos os zeros

Uma wildcard mask com todos os zeros (0.0.0.0) corresponde a um único endereço IP de host exato e, por si só, não oferece capacidade de distinguir protocolos ou portas de destino em uma ACL. Embora uma wildcard mask seja um componente de uma entrada de extended ACL, ela define apenas quais bits de endereço devem corresponder; ela não diz nada ao roteador sobre o serviço HTTPS. Para permitir HTTPS, você ainda precisaria dos campos de protocolo e porta de uma extended ACL, portanto, esta opção está incompleta e incorreta para a política declarada.

Incorreta

Uma wireless SSID ACL

Uma wireless SSID ACL controla quais dispositivos clientes podem se associar a um nome de WLAN (SSID) específico ou o que eles podem fazer na camada de enlace sem fio, e não qual tráfego IP é permitido ou negado. A questão é sobre filtrar o tráfego da porta TCP 443 de uma subnet de origem para um servidor, o que é uma política de camada de rede independente do nome da rede sem fio ou de suas regras de associação. Portanto, uma SSID ACL não pode aplicar o comportamento necessário de permitir/negar HTTPS.

Para se aprofundar

Access Control Lists (ACLs) são ferramentas fundamentais em redes Cisco usadas para filtrar o tráfego com base em critérios definidos. As standard ACLs filtram o tráfego exclusivamente com base nos endereços IP de origem, o que limita sua capacidade de diferenciar tipos de tráfego. As extended ACLs, no entanto, fornecem controle granular ao permitir a filtragem com base em vários parâmetros, incluindo endereços IP de origem e destino, tipos de protocolo (como TCP ou UDP) e números de porta específicos. Essa capacidade é essencial quando as políticas exigem a distinção entre diferentes tráfegos de aplicativos, como HTTPS e Telnet. No cenário em que um administrador deseja permitir o tráfego HTTPS (porta TCP 443) e negar o tráfego Telnet (porta TCP 23) da mesma subnet de origem para um servidor, uma extended ACL é necessária. A extended ACL pode corresponder explicitamente ao protocolo TCP e ao número da porta de destino, permitindo um controle preciso sobre qual tráfego é permitido ou negado. As standard ACLs não conseguem diferenciar o tráfego por porta ou protocolo, tornando-as insuficientes para esse requisito. Uma armadilha comum de exames é assumir que as standard ACLs podem aplicar políticas com base em tipos de aplicativos ou portas, o que elas não podem fazer. As extended ACLs são a escolha correta porque fornecem a granularidade de filtragem necessária. Na prática, o uso de extended ACLs garante que apenas o tráfego pretendido (HTTPS) chegue ao servidor, enquanto o tráfego indesejado (Telnet) é bloqueado, aprimorando a segurança da rede e a conformidade com as políticas de acesso.

Sobre estas questões de prática

Esta é uma das questões de prática originais de 200-301 da Courseiva, escrita para o aprendizado e nunca copiada de provas reais nem de dumps.

Traduzida do original em inglês com IA e conferida quanto ao sentido. Códigos de exame, comandos e nomes de produtos são mantidos como aparecem na prova.