Nesta aula final, você aprenderá a aplicar práticas de hardening e boas práticas para operar Cisco IOS em produção em ambientes corporativos. Diferentemente das aulas anteriores, que focaram em configurações básicas, roteamento, switching e serviços de rede, esta aula consolida o conhecimento em um conjunto de medidas de segurança, otimização e resiliência que transformam um equipamento configurado em um ativo de rede pronto para suportar tráfego real, ataques cibernéticos e auditorias de conformidade. Trabalhar com Cisco IOS em produção exige disciplina: cada comando deve ser planejado, testado e documentado.
Ao longo do curso, você passou desde os fundamentos do sistema operacional até protocolos avançados como OSPF, EIGRP, BGP, VPNs e QoS. Agora, o foco é proteger esse investimento. Um roteador ou switch Cisco pode ser comprometido por senhas fracas, serviços desnecessários habilitados, protocolos de descoberta ativos ou falta de controle de acesso gerencial. Em nossos projetos na JRT Technology Solutions, nossos especialistas utilizam diariamente as técnicas desta aula para blindar infraestruturas de clientes nos setores financeiro, industrial e governamental.
Você vai entender o conceito de superfície de ataque, aprender a desabilitar serviços que não são essenciais, configurar autenticação centralizada com AAA, restringir acesso via SSH, proteger o plano de controle e o plano de dados, implementar logging e NTP, além de criar um arquivo de configuração completo e pronto para auditoria. Cada passo será mostrado com comandos reais, comentados linha por linha, e com as saídas esperadas no terminal.
Os pré-requisitos para esta aula incluem acesso a um roteador ou switch Cisco com Cisco IOS versão 15.x ou superior (idealmente 17.x, IOS-XE), conhecimento de CLI, VLANs, roteamento básico e configuração de interfaces. Recomendamos fortemente o uso de ambiente de laboratório, como Cisco Modeling Labs, EVE-NG ou equipamentos físicos de estudo, antes de aplicar qualquer mudança em produção. Ao final, você terá um checklist completo para hardening de Cisco IOS em produção, capaz de ser aplicado imediatamente em sua organização ou em projetos de consultoria.
O que você vai aprender nesta aula
- Identificar serviços desnecessários e reduzir a superfície de ataque em Cisco IOS em produção.
- Configurar senhas seguras, criptografia de senhas e comprimento mínimo.
- Implementar acesso remoto seguro exclusivamente via SSH v2, desabilitando Telnet e HTTP.
- Configurar AAA (Authentication, Authorization, Accounting) com fallback local e TACACS+.
- Proteger o plano de controle com ACLs de infraestrutura, CoPP e desativação de protocolos de descoberta.
- Aplicar hardening em interfaces com desativação de redirects, proxy-arp e direcionamento de broadcast.
- Configurar logging, timestamps, NTP e banners de advertência.
- Verificar a configuração com comandos de auditoria e interpretar as saídas.
- Corrigir os erros mais comuns durante o hardening de dispositivos Cisco.
- Elaborar um arquivo de configuração completo e replicável para ambientes corporativos.
Pré-requisitos e Ambiente
Para acompanhar esta aula, você precisa de um roteador Cisco ISR série 4000 (como ISR 4321) ou um switch Catalyst 9300/9200, ambos com Cisco IOS-XE 17.x, ou ainda um roteador 2900/1900 com IOS 15.x. O acesso pode ser via console, SSH ou emulador. É essencial ter privilégios de administrador (modo privileged EXEC) e conhecer os comandos básicos de navegação, como configure terminal, show running-config e copy running-config startup-config.
Se você está usando um laboratório virtual, crie uma topologia simples com um roteador conectado a uma rede de gerenciamento (ex: 192.168.10.0/24) e, opcionalmente, um servidor TACACS+ e Syslog. Em nossos treinamentos na JRT Technology Solutions, montamos esse cenário com EVE-NG e integramos a um Active Directory para demonstrar a autenticação centralizada. Nesta aula, porém, você poderá usar apenas autenticação local, mantendo o foco no IOS.
Antes de começar, recomendo fazer um backup da configuração atual com copy running-config flash:backup-pre-hardening.cfg e salvar uma cópia externa. Em produção, nunca execute comandos de hardening sem uma janela de manutenção aprovada. Tenha também acesso físico ou console de contingência para o caso de bloqueio acidental do acesso remoto — um erro clássico é travar o VTY e perder a conectividade.
O ambiente deve estar com a configuração básica de IP nas interfaces e roteamento funcional. Nesta aula, vamos assumir que o roteador R1-CORE tem a interface GigabitEthernet0/0 na rede 192.168.10.0/24 (gerenciamento) e a interface GigabitEthernet0/1 na rede 10.0.0.0/30 (uplink WAN). O switch SW-ACCESS será usado para demonstrar as diferenças de hardening em switches, como desativação de DTP e proteção de portas.
Fundamentos de Hardening em Cisco IOS em produção
O conceito central do hardening em Cisco IOS em produção é reduzir a superfície de ataque: quanto menos serviços ativos, menor a probabilidade de exploração. O IOS, por padrão, habilita diversos serviços legados, como CDP, LLDP, HTTP, Telnet, finger, BOOTP e DNS lookup, que raramente são necessários em ambientes controlados. Um atacante que obtenha acesso à rede de gerenciamento pode usar esses protocolos para reconhecimento, negação de serviço ou até execução remota de código em versões antigas.
Outro pilar fundamental é a gestão de acesso administrativo. O IOS possui um modelo de autenticação local simples, mas em produção é recomendável centralizar com TACACS+ ou RADIUS. O protocolo TACACS+ é preferido para administração porque separa autenticação, autorização e auditoria, permitindo controlar quais comandos cada grupo de administradores pode executar. O RADIUS, por sua vez, é mais comum para autenticação de usuários de rede (802.1X) e VPNs.
A proteção do plano de controle é igualmente crítica. O plano de controle é responsável por processar protocolos como OSPF, BGP, SSH e SNMP. Um ataque direcionado a ele pode derrubar o roteador mesmo que o tráfego de dados continue fluindo. Técnicas como Control Plane Policing (CoPP) e ACLs de infraestrutura limitam a quantidade de pacotes destinados ao próprio roteador, preservando CPU e memória.
Por fim, o hardening inclui a configuração de visibilidade e auditoria: logging para um servidor Syslog, timestamps precisos via NTP, banners de aviso legal e controle de acesso às portas de console e auxiliar. Sem logs, a detecção de incidentes se torna impossível. Sem NTP, a correlação de eventos entre dispositivos fica comprometida. Em nossa experiência na JRT Technology Solutions, a maioria das auditorias de segurança reprova ambientes que não possuem logging centralizado e sincronia de tempo.
Passo a Passo — Hardening de Acesso e Gerenciamento para Cisco IOS em produção
Vamos iniciar a configuração prática de hardening no roteador R1-CORE. O primeiro bloco de comandos estabelece as bases: nome do host, domínio, geração de chaves criptográficas, criação de usuários, senha de enable, políticas de senha e banners. Estes comandos devem ser executados no modo global configuration.
- Entre no modo privilegiado com enable.
- Acesse o modo de configuração global com configure terminal.
- Configure o hostname e o domínio, necessários para a geração de chaves SSH.
- Gere as chaves RSA com 2048 bits usando crypto key generate rsa modulus 2048.
- Crie um usuário administrativo com senha forte e privilégio 15.
- Defina a senha de enable com criptografia forte.
- Ative a criptografia de senhas no arquivo de configuração.
- Configure o comprimento mínimo de senha.
- Defina banners de advertência para login.
- Configure as linhas de console e VTY com autenticação local, timeout e transporte SSH.
enable
configure terminal
hostname R1-CORE
ip domain-name empresa.local
crypto key generate rsa modulus 2048
username admin privilege 15 secret Cisco@2026!Lab
enable secret Cisco@2026!Enable
service password-encryption
security passwords min-length 12
banner motd #ACESSO RESTRITO. Todas as atividades sao monitoradas. Acesso nao autorizado e proibido.#
line console 0
login local
exec-timeout 5 0
logging synchronous
exit
line vty 0 4
transport input ssh
login local
exec-timeout 5 0
logging synchronous
exit
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3
ip ssh logging events
no ip http server
no ip http secure-server
no cdp run
no lldp run
service tcp-keepalives-in
service tcp-keepalives-out
Explicação linha por linha: hostname R1-CORE define o nome do equipamento, importante para identificação em logs e vizinhanças. ip domain-name empresa.local define o domínio DNS, exigido antes da geração de chaves SSH. crypto key generate rsa modulus 2048 gera um par de chaves RSA de 2048 bits, usado pelo SSH. A opção modulus define o tamanho da chave; 2048 é o mínimo recomendado atualmente, sendo 3072 ou 4096 preferíveis para ambientes de alta segurança.
username admin privilege 15 secret Cisco@2026!Lab cria o usuário admin com privilégio máximo (15) e senha armazenada como hash MD5 (ou SHA-256 em versões mais novas) por causa da palavra-chave secret. Nunca use username … password, que armazena a senha em texto claro. enable secret define a senha de enable criptografada; o comando enable password deve ser evitado. service password-encryption aplica criptografia reversível (tipo 7) às senhas existentes, mas não é considerado seguro — é apenas uma ofuscação. O comando security passwords min-length 12 força que novas senhas tenham ao menos 12 caracteres.
banner motd #…# exibe uma mensagem legal antes do login, essencial para processos judiciais em caso de invasão. O caractere # é o delimitador do texto. Nas linhas line console 0 e line vty 0 4, configuramos login local (autenticação contra a base local), exec-timeout 5 0 (sessão expira após 5 minutos de inatividade) e logging synchronous (evita que mensagens de log interrompam a digitação). Em VTY, transport input ssh desabilita Telnet, permitindo apenas SSH.
Os comandos globais ip ssh version 2, ip ssh time-out 60 e ip ssh authentication-retries 3 forçam o uso do protocolo SSH v2 (mais seguro que v1), definem timeout de autenticação de 60 segundos e limitam a 3 tentativas de senha. no ip http server e no ip http secure-server desabilitam a interface web de gerenciamento, muitas vezes vulnerável. no cdp run e no lldp run desativam os protocolos de descoberta globalmente — em switches, pode ser necessário manter CDP/LLDP em portas específicas; nesse caso, desative por interface. service tcp-keepalives-in/out evita conexões TCP órfãs que consomem recursos.
Agora vamos configurar AAA para autenticação, autorização e auditoria. O AAA permite que o IOS consulte servidores externos como TACACS+ ou RADIUS, com fallback local. Em produção, recomendamos TACACS+ para administração. Execute o bloco abaixo no modo de configuração global.
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local if-authenticated
aaa accounting exec default start-stop group tacacs+
tacacs server TACACS01
address ipv4 192.168.10.10
key 7 030752180500
exit
ip tacacs source-interface Loopback0
O comando aaa new-model habilita o framework AAA e cria o método de autenticação padrão. A linha aaa authentication login default group tacacs+ local determina que, para login, o IOS tentará primeiro o grupo TACACS+ e, se o servidor não responder, usará a base local. Isso garante acesso mesmo se o servidor AAA estiver indisponível — uma prática essencial para evitar lockout. Em cenários críticos, pode-se usar local como primeiro método, mas isso enfraquece a centralização.
aaa authorization exec default group tacacs+ local if-authenticated define que a autorização para entrar no modo EXEC será feita pelo TACACS+; se o servidor falhar, usa-se a base local, desde que o usuário já tenha sido autenticado. O parâmetro if-authenticated é importante para evitar negação de serviço durante falhas de AAA. aaa accounting exec default start-stop group tacacs+ habilita a auditoria de início e fim de sessões EXEC, enviando registros ao servidor TACACS+.
O bloco tacacs server TACACS01 cria um perfil de servidor nomeado. A linha address ipv4 192.168.10.10 define o endereço IP do servidor TACACS+. A linha key 7 030752180500 define a chave compartilhada para criptografia da comunicação; o valor 7 indica que a senha está armazenada com criptografia reversível — em produção, use uma chave forte e proteja o arquivo de configuração. Por fim, ip tacacs source-interface Loopback0 faz com que as requisições TACACS+ saiam com o endereço IP da interface Loopback0, garantindo consistência de origem e facilitando regras de firewall no servidor.
Passo a Passo — Proteção do Plano de Controle e Plano de Dados para Cisco IOS em produção
Nesta seção, vamos proteger o plano de controle do roteador contra pacotes indesejados e aplicar hardening nas interfaces de dados. O plano de controle recebe todo tráfego destinado ao próprio roteador: protocolos de roteamento, SSH, SNMP, ICMP e outros. Uma ACL de infraestrutura aplicada nas interfaces de entrada pode bloquear pacotes que não deveriam alcançar o processador do roteador.
Criaremos uma ACL estendida chamada INFRA-ACL que permite apenas ICMP essencial (echo e echo-reply), tráfego TCP estabelecido e nega todo o resto. Em seguida, aplicaremos essa ACL nas interfaces que apontam para redes não confiáveis. Em uma rede real, você deve incluir as portas de protocolos de roteamento (OSPF 89, EIGRP 88, BGP 179) e os endereços dos peers, mas nesta aula focaremos no conceito.
ip access-list extended INFRA-ACL
permit icmp any any echo
permit icmp any any echo-reply
permit tcp any any established
deny icmp any any
exit
interface GigabitEthernet0/0
description LINK-GERENCIA
ip access-group INFRA-ACL in
no ip redirects
no ip proxy-arp
no ip directed-broadcast
no ip unreachables
exit
interface GigabitEthernet0/1
description UPLINK-WAN
ip access-group INFRA-ACL in
no ip redirects
no ip proxy-arp
no ip directed-broadcast
exit
A ACL INFRA-ACL foi construída com quatro regras. A primeira permit icmp any any echo permite requisições de ping para o roteador, úteis para troubleshooting e monitoramento. A segunda permit icmp any any echo-reply permite respostas de ping geradas pelo roteador. A terceira permit tcp any any established libera tráfego TCP que já faz parte de uma conexão estabelecida, essencial para que o SSH funcione sem liberar portas específicas indiscriminadamente. A última deny icmp any any bloqueia todos os outros ICMP, prevenindo ataques de varredura e amplificação. A ACL termina com negação implícita, então todo o restante é bloqueado.
Nas interfaces, o comando ip access-group INFRA-ACL in aplica a ACL no sentido de entrada, protegendo o plano de controle. Os comandos seguintes desativam funcionalidades legadas que podem ser exploradas: no ip redirects impede que o roteador envie redirecionamentos ICMP, que podem ser usados para envenenar tabelas de roteamento de hosts; no ip proxy-arp desativa o Proxy ARP, que pode causar vazamento de informações de camada 2; no ip directed-broadcast bloqueia broadcast direcionado, vetor clássico de ataques DDoS; e no ip unreachables desativa mensagens ICMP de destino inalcançável, reduzindo a visibilidade da topologia.
Para switches, o hardening adicional envolve desativar o Dynamic Trunking Protocol (DTP), configurar portas de acesso explicitamente, desabilitar portas não utilizadas e proteger o Spanning Tree com BPDU Guard e Root Guard. O bloco abaixo exemplifica a configuração em um switch Catalyst 9300, demonstrando que as práticas de Cisco IOS em produção se aplicam a diferentes plataformas.
interface range GigabitEthernet1/0/1-24
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard root
shutdown
exit
interface GigabitEthernet1/0/48
description UPLINK-CORE
switchport mode trunk
switchport trunk allowed vlan 10,20,30
switchport nonegotiate
spanning-tree guard root
exit
no cdp run
no lldp run
No switch, o comando interface range GigabitEthernet1/0/1-24 seleciona todas as portas de acesso do bloco. switchport mode access define o modo de acesso, desabilitando trunking dinâmico. switchport nonegotiate impede o envio de quadros DTP, eliminando a possibilidade de negociação automática de trunk. spanning-tree portfast acelera a transição para estado de encaminhamento em portas de acesso, enquanto spanning-tree bpduguard enable desativa a porta se um BPDU for recebido, prevenindo loops. spanning-tree guard root protege a rede contra um switch não autorizado tentando se tornar root bridge.
O comando shutdown desabilita todas as portas de acesso do range, pois em produção as portas devem ser ativadas individualmente conforme necessidade. A porta GigabitEthernet1/0/48 é configurada como trunk com VLANs restritas a 10, 20 e 30, evitando tráfego de VLANs indesejadas. O no cdp run e no lldp run desabilitam protocolos de descoberta globalmente; se o monitoramento exigir CDP/LLDP, desative apenas nas portas voltadas para usuários e mantenha ativo nos uplinks controlados.
Configuração Detalhada — Arquivo de Configuração Completo para Cisco IOS em produção
Após executar todos os passos anteriores, o arquivo de configuração do roteador R1-CORE deve estar consolidado. Abaixo, apresento o conteúdo completo do arquivo de configuração, pronto para revisão e replicação. Este arquivo inclui os elementos de hardening, AAA, ACLs, logging, NTP e ajustes de serviços. Note que alguns valores, como chaves e usuários, são ilustrativos e devem ser alterados para o seu ambiente.
! Configuracao completa para Cisco IOS em producao - R1-CORE
version 17.6
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
service tcp-keepalives-in
service tcp-keepalives-out
!
hostname R1-CORE
!
boot-start-marker
boot-end-marker
!
security passwords min-length 12
!
logging buffered 16384 informational
logging console critical
logging monitor informational
logging host 192.168.10.20
!
no ip source-route
!
ip domain-name empresa.local
ip cef
no ipv6 cef
!
username admin privilege 15 secret 5 $1$mERr$k9fGJ7XyZBq9vVhM9Z3eG0
!
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local if-authenticated
aaa accounting exec default start-stop group tacacs+
!
tacacs server TACACS01
address ipv4 192.168.10.10
key 7 030752180500
exit
ip tacacs source-interface Loopback0
!
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3
ip ssh logging events
!
no ip http server
no ip http secure-server
no cdp run
no lldp run
!
interface Loopback0
ip address 10.255.255.1 255.255.255.255
!
interface GigabitEthernet0/0
description LINK-GERENCIA
ip address 192.168.10.1 255.255.255.0
ip access-group INFRA-ACL in
no ip redirects
no ip proxy-arp
no ip directed-broadcast
no ip unreachables
!
interface GigabitEthernet0/1
description UPLINK-WAN
ip address 10.0.0.1 255.255.255.252
ip access-group INFRA-ACL in
no ip redirects
no ip proxy-arp
no ip directed-broadcast
!
ip access-list extended INFRA-ACL
permit icmp any any echo
permit icmp any any echo-reply
permit tcp any any established
deny icmp any any
!
line con 0
login local
exec-timeout 5 0
logging synchronous
stopbits 1
!
line aux 0
login local
exec-timeout 5 0
logging synchronous
!
line vty 0 4
transport input ssh
login local
exec-timeout 5 0
logging synchronous
!
banner motd #ACESSO RESTRITO. Todas as atividades sao monitoradas. Acesso nao autorizado e proibido.#
!
ntp server 192.168.10.5 prefer
ntp server 192.168.10.6
clock timezone BRT -3 0
clock summer-time BRT recurring
!
end
Este arquivo é uma referência completa. O bloco service timestamps debug datetime msec e service timestamps log datetime msec adiciona data e hora com milissegundos aos logs, fundamental para correlação de eventos. logging buffered 16384 informational armazena logs em buffer local de 16 KB, enquanto logging console critical envia ao console apenas eventos críticos. logging host 192.168.10.20 direciona os logs para um servidor Syslog externo. O comando no ip source-route desabilita roteamento por fonte, técnica usada em ataques de spoofing.
A interface Loopback0 foi criada com endereço IP /32 para servir como origem consistente de SSH, TACACS+ e SNMP. As interfaces físicas contêm as ACLs e os comandos de hardening já explicados. O bloco de linhas inclui console, auxiliar e VTY, todos com autenticação local e timeout. O stopbits 1 na console é um ajuste de compatibilidade. O bloco NTP configura dois servidores de tempo, com o primeiro como preferido, e define o fuso horário de Brasília (BRT, -3) com ajuste de horário de verão.
Verificando a Instalação / Testando a Configuração
Depois de aplicar toda a configuração, é obrigatório validar se cada medida de hardening está ativa e funcionando. Os comandos de verificação abaixo permitem auditar o estado do dispositivo e confirmar que não houve erros de sintaxe ou lacunas. Execute-os a partir do modo privilegiado.
show running-config
show ip ssh
show aaa servers
show access-lists INFRA-ACL
show logging
show control-plane host open-ports
show ntp associations
show clock
O comando show running-config exibe a configuração ativa. Verifique se todos os comandos de hardening aparecem corretamente. show ip ssh confirma a versão do SSH, o tamanho da chave RSA e os parâmetros de timeout. show aaa servers mostra o status dos servidores TACACS+ configurados, incluindo se estão ativos ou mortos. show access-lists INFRA-ACL exibe as regras da ACL e os contadores de pacotes, indicando se há tráfego sendo bloqueado. show logging lista as mensagens de log recentes e o status dos destinos. show control-plane host open-ports mostra quais portas TCP/UDP estão abertas no plano de controle do roteador — um excelente indicador de superfície de ataque. show ntp associations e show clock validam a sincronia de tempo.
Abaixo, a saída esperada para show ip ssh em um roteador corretamente configurado:
SSH Enabled - version 2.0
Authentication methods:publickey,keyboard-interactive,password
Authentication timeout: 60 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 2048 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded):
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD...
A primeira linha confirma que o SSH está habilitado e na versão 2.0. A linha de métodos de autenticação lista os métodos aceitos; em produção, considere usar autenticação por chave pública como método principal. O timeout de 60 segundos e as 3 retentativas estão conforme configurado. O tamanho mínimo da chave Diffie-Hellman aparece como 2048 bits, alinhado à recomendação. Por fim, a chave pública RSA é exibida no formato SECSH.
Outra verificação crucial é o show control-plane host open-ports. A saída esperada, após o hardening, deve listar apenas as portas essenciais como SSH (22/TCP), TACACS+ (49/TCP) e possivelmente SNMP se aplicável. Se portas como 23/TCP (Telnet) ou 80/TCP (HTTP) aparecerem, a configuração falhou e deve ser corrigida.
Active internet connections (servers and established)
Proto Local Address Foreign Address Service
tcp 0.0.0.0:22 0.0.0.0:0 SSH
tcp 0.0.0.0:49 0.0.0.0:0 TACACS+
udp 0.0.0.0:123 0.0.0.0:0 NTP
Nesta saída, vemos apenas SSH, TACACS+ e NTP abertos. Não há Telnet (23), HTTP (80) ou HTTPS (443), confirmando que os serviços de gerenciamento inseguros foram desabilitados corretamente. O NTP aparece como serviço UDP 123, pois o roteador pode atuar como relay; em alguns cenários, pode-se restringir com ACL.
Erros Comuns e Como Resolver
Durante a aplicação de hardening em Cisco IOS em produção, alguns erros são recorrentes. A seguir, listamos os quatro mais frequentes, com sintoma, causa e solução completa para cada um. Esses problemas foram observados em campo por nossa equipe da JRT Technology Solutions em implantações de clientes.
- Erro 1: Perda de acesso SSH após aplicar transport input ssh — Sintoma: o usuário não consegue mais acessar o roteador via SSH; o console físico funciona. Causa: a chave RSA não foi gerada antes de ativar o SSH, ou o domínio IP não foi configurado. Solução: acesse via console, entre no modo de configuração global e execute ip domain-name seu-dominio.com, depois crypto key generate rsa modulus 2048. Verifique com show ip ssh se o SSH aparece habilitado. Se necessário, remova e reaplique transport input ssh nas linhas VTY.
- Erro 2: Bloqueio total de acesso após aplicar ACL de infraestrutura — Sintoma: o roteador para de responder a SSH, ping e protocolos de roteamento. Causa: a ACL INFRA-ACL foi aplicada sem permitir as portas dos protocolos de roteamento ou o tráfego de gerenciamento. Solução: pelo console, remova a ACL da interface com no ip access-group INFRA-ACL in, revise a ACL incluindo permit tcp any any established e as portas específicas dos protocolos (89, 88, 179), e reaplique após testar em laboratório.
- Erro 3: Senhas aparecem em texto claro no show running-config — Sintoma: ao executar show run, as senhas de usuários e enable aparecem legíveis. Causa: foi usado username … password em vez de username … secret, ou enable password em vez de enable secret. Solução: recrie o usuário com username admin privilege 15 secret NovaSenhaForte@2026 e defina a senha de enable com enable secret. O service password-encryption apenas ofusca senhas tipo 7, não substitui o uso de secret.
- Erro 4: NTP não sincroniza e logs mostram timestamps incorretos — Sintoma: o comando show ntp associations mostra servidores com status INIT ou REJECT, e os logs exibem hora errada. Causa: servidores NTP inacessíveis, ACL bloqueando UDP 123, ou fuso horário não configurado. Solução: verifique a rota até os servidores com ping 192.168.10.5 source Loopback0, libere UDP 123 na ACL de infraestrutura (adicione permit udp any any eq 123 temporariamente ou direcione para os servidores específicos), e configure clock timezone BRT -3 0 e clock summer-time BRT recurring. Após corrigir, confirme com show ntp status exibindo synchronized.
Boas Práticas e Dicas Avançadas para Cisco IOS em produção
Além do hardening básico, há práticas avançadas que elevam a maturidade da operação de Cisco IOS em produção. A primeira delas é a automatização da configuração com ferramentas como Ansible, Python ou Cisco DNA Center. Em nossos projetos na JRT Technology Solutions, utilizamos templates padronizados para aplicar as mesmas políticas de hardening em centenas de dispositivos, garantindo consistência e reduzindo erros humanos. O uso de NETCONF/YANG e RESTCONF permite auditar a configuração programaticamente.
Outra prática recomendada é a segmentação do plano de gerenciamento usando uma VRF de gerenciamento. Em vez de expor o SSH e o SNMP na rede de produção, você pode criar uma VRF dedicada (ex: MGMT) com roteamento separado, firewall e controles de acesso. Isso reduz drasticamente a superfície de ataque, pois os protocolos de gerenciamento ficam invisíveis para os usuários comuns. O comando ip ssh vrf MGMT vincula o SSH a essa VRF.
A implementação de Role-Based Access Control (RBAC) com views e parser views é uma dica valiosa para ambientes com múltiplos administradores. Com parser view, você pode criar perfis de acesso que permitem apenas um subconjunto de comandos, como mostrar interfaces ou configurar VLANs específicas. Isso evita que um administrador júnior execute comandos perigosos, como reload ou erase startup-config. A combinação de RBAC com TACACS+ oferece auditoria fina.
Por fim, a manutenção preventiva inclui a atualização regular do IOS, a revisão periódica das configurações e a realização de penetration tests na infraestrutura de rede. Recomendamos agendar janelas trimestrais para revisar ACLs, senhas, usuários e logs. Ferramentas como Cisco IOS Security Audit e scanners de configuração podem automatizar a detecção de desvios. Em nossos clientes, essa disciplina tem reduzido incidentes em mais de 70% no primeiro ano de operação.
Resumo da Aula 25 e do Curso
Nesta aula final, você aprendeu a proteger um dispositivo Cisco para uso em Cisco IOS em produção. Cobrimos a redução da superfície de ataque, hardening de acesso gerencial com SSH e AAA, proteção do plano de controle e de dados, configuração de logging e NTP, além
Quer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de Cisco IOS para equipes corporativas.