APRENDER. PRATICAR. EVOLUIR.1. Proteger o caminho administrativo
Uma equipa APS perde SSH a um equipamento durante uma alteração. O serviço de dados ainda funciona, mas isso não comprova disponibilidade do plano de gestão. Desenha origem administrativa, bastion, encaminhamento, ACL, interface e serviço de destino. Um caminho out-of-band ajuda apenas se as suas dependências sobreviverem ao incidente considerado; valida energia, rede, identidade e acesso dos operadores. Restringe origens e protocolos, usa transporte protegido e confirma identidade do destino. Uma loopback configurada pode fornecer endereço estável, mas precisa de encaminhamento utilizável. Não copies uma checklist inteira sem verificar suporte, serviços necessários e risco de bloquear a única via de recuperação.
2. Separar as três decisões AAA
Autenticação responde à identidade; autorização decide serviços ou comandos; accounting regista ações e sessões. Na ficha fictícia, o login passa mas um comando autorizado pelo pedido de mudança recebe recusa. Investiga a política de autorização e o perfil efetivo antes de alterar a password. Noutro caso, os comandos funcionam mas falta o registo no destino: sucesso de acesso não comprova accounting. Conserva utilizador, equipamento, origem, hora, sessão e comando necessário ao diagnóstico, sem incluir passwords. Testa explicitamente um comando permitido e outro recusado, a chegada dos registos e a recuperação de falhas. Uma conta que consegue entrar não está automaticamente autorizada a fazer tudo.
3. Distinguir recusa de indisponibilidade
Na lista IOS XE estudada, o método TACACS+ vem antes do local. Uma recusa explícita não deve ser tratada como erro de transporte para experimentar credenciais locais até entrar. O método seguinte é tentado perante erro ou ausência de resposta, conforme a lista e serviço configurados. Testa separadamente ACCEPT, REJECT e servidor indisponível, incluindo autorização após login. Duas entradas AAA que dependem da mesma rota ou do mesmo serviço de identidade podem falhar juntas. A conta de emergência precisa de âmbito, proteção, owner e revisão depois da utilização. O comando none em autorização pode permitir acesso na condição em que é usado; não equivale a uma conta local com privilégios mínimos.
4. Validar transporte e controlos associados
O guia de hardening recomenda TACACS+ sobre TLS 1.3 nas versões que o suportam e assinala o mecanismo antigo de ofuscação como obsoleto. O exemplo consultado usa IOS XE 17.18.1 e ISE 3.4 Patch 2; confirma modelos, versões, certificados e configuração dos dois lados. “Porta alcançável” não demonstra autenticação TLS bem-sucedida. Para SNMP, revê autenticação, proteção do conteúdo, views e acesso de escrita, em vez de aceitar só o rótulo v3. Em CoPP, uma ACL usada para classificar tráfego não tem necessariamente o efeito de uma ACL aplicada numa interface: permit pode selecionar a classe cujo policy-map faz drop. Lê classificação e ação em conjunto antes da mudança.
5. Demonstrar acesso depois da mudança
Mantém uma via de recuperação autorizada durante a janela e abre uma sessão nova para testar a política; uma sessão antiga pode continuar sem exercitar a nova autenticação. Define critérios de rollback por erro, perda de acesso e impacto no serviço. Recolhe contadores de classificação, drops, CPU e tráfego necessário ao interpretar uma alteração de CoPP; um aumento de drops sozinho não prova ataque nem sucesso do controlo. Sincroniza tempo e confirma que RUN consegue pesquisar accounting no destino. A ficha contém oito ensaios planeados, não executados em Cisco. Resumo: valida caminho, transporte, autenticação, autorização, registo e recuperação como etapas distintas, com evidência e responsável.
Login ACCEPT e comando REJECT apontam para etapas diferentes; alterar a password não demonstra correção da autorização.
Armadilhas comuns
REJECT como timeout; sessão antiga como teste novo; none como privilégio mínimo; permit numa ACL de classificação como autorização final.
Tópicos relacionados: AAA e TACACS+ · Plano de gestão e CoPP · Mudança e continuidade
O acesso administrativo só está aceite quando identidade, ação, auditoria e recuperação funcionam no âmbito pretendido.
Referência: Cisco IOS XE Software Hardening Guide · 350-701 SCOR v2.0, effective 2026-08-27; core component of CCNP Security