Cisco 200-301: Segurança de Rede e Controle de Acesso — Guia de estudos

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

Faz parte do Cisco CCNA 200-301 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Cisco, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A segurança de rede e o controle de acesso garantem que apenas entidades autorizadas usem os recursos da rede das maneiras previstas, protegendo dados e serviços contra comprometimento ou interrupção. Designs eficazes alinham os controles técnicos com os princípios fundamentais de confidencialidade, integridade, disponibilidade e menor privilégio. Os controles devem abranger o plano de gerenciamento (como os dispositivos são administrados), o plano de controle (como os dispositivos formam adjacências e trocam informações de roteamento) e o plano de dados (como o tráfego do usuário é encaminhado), com defesas em camadas na Camada 2, Camada 3 e superiores. Esta seção destila mecanismos práticos — AAA, ACLs, proteções de Camada 2, VPNs, firewalls/IPS, fortalecimento (hardening) e monitoramento operacional — juntamente com o raciocínio de design, modos de falha comuns e exemplos de configuração concisos.

Princípios de Segurança e Fundamentos do Controle de Acesso

• Confidencialidade: Impede a divulgação não autorizada. Aplicada com criptografia em trânsito (SSH, IPsec), criptografia em repouso e políticas de acesso com escopo definido.
• Integridade: Impede a alteração não autorizada. Alcançada usando verificações criptográficas (HMACs, assinaturas digitais), controles de configuração e imutabilidade dos registros de auditoria.
• Disponibilidade: Mantém os serviços acessíveis apesar de falhas ou ataques. Realizada com redundância, limitação de taxa (rate-limiting), policiamento (policing) e arquiteturas resilientes que mantêm a conectividade contínua durante falhas.
• Menor privilégio: Concede os direitos mínimos necessários, com escopo definido por função, dispositivo, protocolo, tempo e local. Implementado usando controle de acesso baseado em função (RBAC), segmentação e autorização por comando.

Raciocínio de design:

• Baseie as políticas de acesso nas funções de negócio. O RBAC na infraestrutura (ex: network-operator vs. network-admin) reduz o raio de impacto do uso indevido de credenciais e de erros operacionais.
• Separação de funções (ex: operações de segurança vs. operações de rede). Aplicada por meio de grupos AAA distintos e autorização de comando.
• Prefira posturas de negação por padrão (deny-by-default). Permita explicitamente os fluxos e as fontes de gerenciamento pretendidos, com registro de logs nas exceções.

Armadilhas comuns:

• Privilégios excessivos por conveniência (ex: privilégio 15 irrestrito). Isso convida a movimentos laterais e erros irreversíveis.
• Redes planas (flat networks) sem segmentação. Domínios de broadcast e limites de política indiferenciados amplificam ataques (ex: ARP spoofing).
• Controles excessivamente rígidos sem telemetria. A falta de contadores/logs dificulta a solução de problemas e pode prolongar interrupções.

AAA e Gerenciamento Seguro de Dispositivos

Visão geral do AAA:

• Autenticação (Authentication) verifica a identidade. Autorização (Authorization) determina o que uma identidade pode fazer. Contabilização (Accounting) registra o que foi feito e quando.
• Autenticação local: O dispositivo armazena usuários e senhas. Útil para acesso de emergência (break-glass); não escala nem centraliza políticas.
• TACACS+: TCP/49, criptografa todo o payload, suporta autorização granular por comando; preferido para administração de dispositivos.
• RADIUS: UDP/1812 (authn/author), UDP/1813 (acct), criptografa apenas o campo da senha; integra-se bem com 802.1X e acesso à rede, autorização menos granular para CLI.

Configuração AAA típica com TACACS+ e fallback local: aaa new-model tacacs server TAC1 address ipv4 10.20.20.10 key $uperSecretKey aaa group server tacacs+ TAC-GRP server name TAC1 aaa authentication login default group TAC-GRP local aaa authorization exec default group TAC-GRP local if-authenticated aaa accounting exec default start-stop group TAC-GRP username breakglass privilege 15 secret StrongLocal!Pass

Acesso baseado em função:

• Mapeie atributos TACACS+/RADIUS para níveis de privilégio ou conjuntos de comandos do dispositivo. Use autorização por comando para restringir ações de risco (ex: reload, write, edições de policy-map).
• Valide o RBAC com contas de teste; garanta que a conta local de emergência (break-glass) seja documentada, protegida e monitorada.

Plano de gerenciamento seguro:

• Prefira SSHv2 para a CLI. Desabilite o Telnet e servidores não utilizados. ip domain-name corp.local crypto key generate rsa modulus 2048 ip ssh version 2 line vty 0 4 transport input ssh login authentication default access-class MGMT_VTY in ip access-list standard MGMT_VTY permit 10.10.10.0 0.0.0.255

• Restrinja o gerenciamento a redes fora de banda (out-of-band) ou VLANs/VRFs de gerenciamento dedicadas. Aplique ACLs na SVI ou na interface de gerenciamento física para permitir apenas fontes autorizadas.

• Policiamento do plano de controle (CoPP) para proteger protocolos de roteamento, gerenciamento e controle contra inundações (floods): class-map match-any CONTROL-PLANE-MGMT match protocol ssh match protocol snmp match protocol ntp policy-map COPP-POLICY class CONTROL-PLANE-MGMT police 32000 conform-action transmit exceed-action drop class class-default police 64000 conform-action transmit exceed-action drop control-plane service-policy input COPP-POLICY Raciocínio e cuidados: Aplique policiamento (police), não descarte (drop) indiscriminadamente a classe padrão (class-default); uma classificação incorreta pode quebrar adjacências de roteamento ou BFD e causar interrupções. Comece com taxas generosas, observe os contadores e depois restrinja.

Fortalecimento de senhas e integridade do dispositivo:

• Use enable secret (com hash) em vez de enable password.
• Imponha um comprimento mínimo e limite ataques de login: security passwords min-length 12 login block-for 60 attempts 5 within 60
• Prefira secrets de usuários locais (PBKDF2/scrypt em plataformas suportadas). Entenda que service password-encryption apenas ofusca senhas legadas do tipo 7.
• Boot e configuração seguros: secure boot-image secure boot-config
• Proteja e versione as configurações; considere arquivamentos periódicos no armazenamento local e em um repositório remoto seguro. Use SCP ou SFTP para transferências de arquivos; evite TFTP em texto plano para arquivos sensíveis.

Filtragem de Tráfego com ACLs IPv4/IPv6

Conceitos básicos de ACLs IPv4:

• ACLs Standard (1–99, 1300–1999) correspondem apenas ao endereço IPv4 de origem. ACLs Extended (100–199, 2000–2699) correspondem à origem/destino, protocolo e portas L4.
• Máscaras curinga (wildcard masks): o bit 0 deve corresponder; o bit 1 é “não importa” (don’t care). Calcule como o inverso da máscara de sub-rede (ex: /24 => 0.0.0.255). Atalhos: host 192.0.2.5 equivale a 192.0.2.5 0.0.0.0; any equivale a 0.0.0.0 255.255.255.255.
• Direção: inbound é processada antes do roteamento na entrada (ingress); outbound é processada após o roteamento na saída (egress). Os pacotes são verificados de cima para baixo até a primeira correspondência; um deny any implícito encerra a ACL.
• Diretrizes de posicionamento: posicione ACLs extended próximas à origem para descartar tráfego indesejado o mais cedo possível; posicione ACLs standard próximas ao destino para evitar bloqueios excessivos. Plataformas modernas usam TCAM; ainda assim, prefira a precisão perto da origem.

Exemplos:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Aprimoramentos úteis: use remark para documentação; use established para uma permissão rudimentar do caminho de retorno em TCP (valor de segurança limitado); habilite o log em negações (denies) com moderação para evitar picos de CPU.

Princípios de ACLs IPv6:

• A lógica é semelhante, mas as ACLs IPv6 são apenas nomeadas (named) e aplicadas com ipv6 traffic-filter. O deny padrão também é implícito.
• Sempre considere os tipos essenciais de ICMPv6 (neighbor solicitation/advertisement, router solicitation/advertisement, PMTU). ACLs excessivamente restritivas que descartam ICMPv6 quebram o ND (Neighbor Discovery) e causam black holes.

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Verificação e operações:

• show access-lists APP-POLICY e show ipv6 access-lists V6-EDGE-IN para visualizar contadores de correspondência (hit counters) e números de sequência.
• show ip interface ou show ipv6 interface para confirmar a associação e a direção.
• Teste de forma restrita antes de uma implantação ampla; um deny ip any any mal posicionado pode causar interrupções generalizadas.

Modos de falha comuns:

• Cálculos incorretos de máscara curinga que correspondem a mais tráfego do que o pretendido.
• Aplicar ACLs na direção errada ou na interface/SVI errada.
• Omitir permissões críticas de ICMPv6, levando a falhas no neighbor discovery.

Proteções de Camada 2, VPNs e Defesas de Perímetro

Controles de ameaças de Camada 2:

• DHCP snooping: Constrói uma tabela de associação (binding table) de IP–MAC–VLAN–porta para endereços aprendidos via DHCP; descarta respostas de servidores não autorizados (rogue) em portas não confiáveis (untrusted); limita a taxa (rate-limits) de ofertas/requisições.

undefined

undefined

undefined

undefined

undefined

undefined

Modos de falha: Esquecer de configurar como confiáveis (trust) os uplinks para relays/servidores DHCP reais quebra a atribuição de endereços; não salvar a tabela de associação entre reinicializações pode impactar o DAI/IPSG até que as concessões (leases) sejam renovadas.

• Dynamic ARP Inspection (DAI): Valida pacotes ARP contra a tabela de associação do DHCP snooping (ou associações estáticas). Descarta ARP falsificado (spoofed).

undefined

undefined

undefined

Observação: Hosts com endereços estáticos exigem associações estáticas; caso contrário, ARP legítimo pode ser descartado.

• IP Source Guard (IPSG): Usa as associações para permitir apenas o IP de origem válido (e opcionalmente o MAC) por porta.

undefined

undefined

! Opcionalmente, vincule às verificações de MAC do port-security: !

undefined

• Exemplo de associação estática para um dispositivo com IP fixo:

undefined

Fundamentos de VPN e conceitos de IPsec:

• VPNs site-to-site normalmente usam IPsec em modo túnel para criptografar e autenticar sub-redes privadas através de redes não confiáveis. Elementos centrais: IKE Fase 1 (ex: IKEv2) para estabelecer uma SA ISAKMP; Fase 2 para construir SAs IPsec com transformações (transforms) (ex: AES-GCM para modo combinado ou AES-CBC com HMAC-SHA2); PFS para garantir forward secrecy; lifetimes para renovar chaves; NAT-T sobre UDP/4500 se houver NAT.
• VPNs de acesso remoto podem ser baseadas em SSL/TLS (com ou sem cliente) ou em IPsec. O split tunneling reduz o uso de largura de banda no headend e melhora a experiência do usuário, mas aumenta a exposição; o full tunneling centraliza os controles de segurança ao custo de largura de banda e latência.
• Valide o Path MTU e habilite a descoberta de PMTU (PMTU discovery); o overhead da criptografia reduz o MTU efetivo e pode causar fragmentação sem a configuração adequada.

Firewalls e prevenção de intrusão:

• Firewalls aplicam permissões/negações com inspeção de estado (stateful inspection) e reconhecimento de aplicação (NGFW). Em roteadores, o zone-based firewalling fornece políticas stateful entre zonas; ACLs sozinhas são stateless.
• Um IPS analisa o tráfego em busca de assinaturas, anomalias ou comportamentos; um IPS inline pode bloquear, enquanto um IDS passivo apenas alerta. O ajuste fino (tuning) é essencial para reduzir falsos positivos.
• Projete para fluxos simétricos através de dispositivos stateful; o roteamento assimétrico quebra as tabelas de estado. Posicione os sensores onde eles possam ver o tráfego correto (ex: entre zonas não confiáveis e confiáveis).

Operações de Segurança: Monitoramento, Logging e Triagem de Incidentes

Logging de auditoria e tempo:

• Sincronize os relógios para precisão forense:

undefined

undefined

• Habilite o logging local e remoto com a severidade apropriada:

undefined

undefined

undefined

• Aumente a visibilidade de eventos de autenticação e uso de comandos com o accounting do AAA:

undefined

• Use o logging de ACLs em negações (denies) com moderação; logs de alto volume podem sobrecarregar a CPU. Considere amostragem com NetFlow/IPFIX para criar uma linha de base (baseline) do tráfego.

Fluxo de trabalho para triagem de incidentes:

• Detectar e delimitar o escopo: Use syslog, traps SNMP e dados de fluxo para identificar fontes, portas e volumes anômalos. Correlacione os contadores em ACLs, CoPP e interfaces.
• Conter: Aplique temporariamente negações (denies) de ACL direcionadas, desative portas de switch comprometidas (shut) ou coloque VLANs em quarentena. Para DDoS no plano de controle, ajuste o policiamento do CoPP e considere a aplicação de rate-limits no upstream ou blackholing.
• Erradicar e recuperar: Remova artefatos maliciosos, rotacione credenciais (incluindo chaves e segredos compartilhados), reative os serviços gradualmente enquanto monitora.
• Pós-incidente: Preserve logs/snapshots de configuração, conduza uma análise de causa raiz (root-cause analysis) e codifique controles preventivos (ex: expandir proteções de Camada 2, refinar o RBAC).

Lacunas operacionais comuns:

• A ausência de NTP leva a cronogramas inutilizáveis.
• Fazer logging de tudo em todos os lugares cria ruído; ajuste a severidade e os filtros de acordo com a função do dispositivo.
• A falta de um processo de ‘break-glass’ testado prolonga as interrupções quando os servidores AAA estão inacessíveis.

Cenário de Problema Prático

O Orion Retail Group precisa proteger a administração de dispositivos, segmentar o tráfego de usuário para aplicação para IPv4/IPv6, impedir atividades maliciosas de DHCP/ARP nas lojas, habilitar acesso remoto seguro para a equipe e melhorar a visibilidade da resposta a incidentes — sem interromper as operações.

1. Implementar AAA centralizado com TACACS+ e fallback local

• Configuração: Implante servidores TACACS+; defina aaa new-model com o grupo TAC-GRP, autenticação/autorização/accounting; crie um usuário local de ‘break-glass’ com privilégio 15.
• Justificativa: Identidades centralizadas e autorização por comando impõem o princípio do privilégio mínimo, fornecem trilhas de auditoria de ações administrativas e permitem a revogação rápida de credenciais. O fallback local preserva o acesso durante interrupções do AAA.

2. Migrar o acesso de gerenciamento para SSH e restringi-lo por origem

• Configuração: Gere chaves RSA, imponha ip ssh version 2, desabilite o Telnet, configure line vty para transport input ssh com login authentication default; aplique access-class MGMT_VTY in para permitir apenas os jump hosts do NOC.
• Justificativa: Criptografar o tráfego de gerenciamento impede a interceptação de credenciais; ACLs de gerenciamento reduzem a superfície de ataque a um conjunto pequeno e conhecido de origens.

3. Proteger o plano de controle com CoPP conservador

• Configuração: Crie um class-map para SSH, SNMP, NTP; aplique um policy-map COPP-POLICY que faz o policiamento (polices) do tráfego conhecido de gerenciamento/controle e limita a taxa (rate-limits) da class-default; anexe-o à entrada do control-plane.
• Justificativa: A limitação de taxa (rate-limiting) do tráfego do plano de controle mantém a disponibilidade durante inundações de pacotes (floods) sem bloquear protocolos essenciais. Começar com taxas mais relaxadas evita a autonegação acidental de serviço.

4. Garantir a integridade da Camada 2 nas lojas

• Configuração: Habilite o DHCP snooping nas VLANs de acesso, confie (trust) apenas nos uplinks para a WAN/relay; aplique limitação de taxa (rate-limits) para requisições/ofertas. Habilite o DAI nas mesmas VLANs; adicione bindings estáticos para dispositivos com IP fixo. Habilite o IP Source Guard nas portas de acesso.
• Justificativa: Esses recursos bloqueiam servidores DHCP maliciosos (rogue), ARP spoofing e falsificação de IP (IP impersonation) no primeiro salto, impedindo o movimento lateral e ataques man-in-the-middle.

5. Segmentar aplicações com ACLs precisas (IPv4 e IPv6)

• Configuração: Implante ACLs estendidas de IPv4 nas interfaces voltadas para o acesso para permitir apenas os protocolos necessários (ex: HTTPS para os servidores de aplicação) e negar/registrar todo o resto. Implante ACLs de IPv6 com permissões explícitas de ICMPv6 para ND/RA/RS e permissões específicas de aplicação; aplique com ipv6 traffic-filter.
• Justificativa: Filtros próximos à origem e específicos por protocolo minimizam o tráfego indesejado e reduzem o desperdício de largura de banda; preservar o ICMPv6 garante que o neighbor discovery e o PMTU funcionem de forma confiável.

6. Habilitar acesso remoto seguro e criptografia site-to-site

• Configuração: Construa túneis IPsec site-to-site em modo túnel (tunnel mode) entre as lojas e os data centers usando IKEv2, AES-GCM, PFS e tempos de vida (lifetimes) alinhados com as janelas operacionais. Forneça VPN de acesso remoto baseada em SSL/TLS para a equipe com split tunneling para reduzir a carga no headend, juntamente com verificações de postura (posture checks) do endpoint.
• Justificativa: Criptografar caminhos não confiáveis protege a confidencialidade/integridade; o split tunneling equilibra segurança com desempenho quando combinado com controles de endpoint.

7. Implantar firewall e IPS no perímetro e na agregação do DC

• Configuração: Implemente uma política de firewall stateful entre as zonas não confiável (untrusted), de usuário e de servidor; posicione o IPS em modo inline nos caminhos críticos com assinaturas ajustadas para aplicações de varejo. Garanta a simetria de caminho ou habilite o compartilhamento de estado (state sharing).
• Justificativa: Firewalls impõem políticas de zona de alto nível; o IPS detecta/bloqueia exploits que se aproveitam de fraquezas de aplicações e protocolos. O posicionamento e o ajuste corretos evitam falsos positivos e problemas de estado assimétrico.

8. Fortalecer o hardening, o logging e a resposta

• Configuração: Defina o enable secret, imponha um comprimento mínimo de senha e limitação de tentativas de login (login throttling); habilite secure boot-image/config. Configure NTP, syslog remoto e em buffer com severidade informational, e AAA command accounting. Adicione declarações deny log com moderação nas ACLs principais. Teste o procedimento de ‘break-glass’.
• Justificativa: Credenciais fortes e integridade do dispositivo reduzem o risco de comprometimento; logs sincronizados e duráveis e o accounting aceleram a triagem. Procedimentos de recuperação praticados minimizam o tempo de inatividade durante incidentes.

Ao executar esses passos em ordem — começando pela identidade e plano de gerenciamento, passando pelo hardening da Camada 2, segmentação e transporte criptografado, e finalmente pela inspeção de perímetro e visibilidade operacional — o Orion alcança uma segurança em camadas e de privilégio mínimo com controles mensuráveis e interrupção mínima.

← Projeto e Operações de LAN Wireless · Todos os domínios · WAN →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →