Esse artigo traz algumas medidas de segurança em switches e reforço na configuração geral dos switches Cisco que você provavelmente já estudou até mesmo no CCNA R&S, mas que para um CCNP é essencial.
De nada vale implementar recursos avançados de segurança na rede e deixar portas óbvias abertas que atacantes pode utilizar muito facilmente.
Lembre-se que existem várias informações e padrões que são divulgados pelos fabricantes, por isso é preciso aplicar algumas configurações e tomar alguns cuidados básicos para que os atacantes não utilizem isso ao seu proveito.
A seguir vamos estudar essas recomendações que você deve seguir em suas implantações para melhorar a segurança em switches Cisco Catalyst.
Configurar senhas seguras
A primeira recomendação é básica para segurança em switches e quaisquer outros dispositivos de rede que utilizam Cisco IOS.
Sempre que possível utilizar o “enable secret” para definir a senha para acesso privilegiado ao invés do “enable password”.
Se possível também implementar servidores de autenticação externos RADIUS ou TACACS+ e utilizar o AAA para implementar no mínimo o processo de autenticação.
Com o AAA e servidores externos as informações de autenticação não são mantidas nos switches e permite a implementação de outros recursos como Autorização e Auditoria.
Outra vantagem da autenticação com servidores externos é a centralização do processo de autenticação, que possibilita implementar mudanças de senhas ou regras de autenticação mais facilmente, pois não é preciso entrar dispositivo por dispositivo para esse tipo de atividade.
Também é importante utilizar o comando “service password-encryption” para aplicar a criptografia das senhas que normalmente são armazenadas em texto claro, tais como senhas de console e VTY locais.
Apesar dessa solução implementar uma criptografia fraca, ela previne que observadores casuais vejam suas senhas quando trabalhando ao lado e você eventualmente entra com um “show running-config”, por exemplo.
Utilizar os banners do sistema
Os banners são importantes porque eles informam a usuários que tiveram acesso aos dispositivos de rede que existe uma política corporativa e essa conexão pode estar sendo monitorada, por exemplo.
A ideia é informar que acesso não é autorizado e que se um usuário conseguiu acesso e pode ser punido conforme os termos contratuais ou códigos de conduta da empresa.
O “banner motd” define o texto para usuários autenticados, tente não inserir informações muito elaboradas ou que um atacante possa utilizar contra o próprio esquema de segurança da empresa.
Apesar de não aumentar a segurança em switches, esse recurso pode pelo menos deixar os avisos padrões para que usuários desapercebidos não façam nada errado.
Implemente Segurança na Interface Web
Utilizar ou não a interface Web do switch é uma decisão corporativa, pois muitas empresas permitem apenas acesso CLI e desabilitam a interface web com o comando “no ip http Server” em modo de configuração global.
Se for preciso utilizar o acesso web prefira sempre através do HTTPS se for suportado.
O comando para ativar o HTTPS é “ip http secure server” em modo de configuração global
Além disso, limite os endereços que podem acessar o switch via HTTPS, por exemplo, dando acesso via ACL apenas para a rede de administração ou gerenciamento de redes da empresa, e também implemente autenticação local (username/secret ou password) ou através do AAA, se possível.
Veja exemplo abaixo onde a rede de administração é 10.100.50.0/24 e vamos utilizar usuários locais para autenticar a interface HTTPS.
O usuário será “dltec” e a senha secreta “d3lt1c123#!”.
Switch(config)#username dltec privilege 15 secret d3lt1c123#!
Switch(config)#ip http secure server
Switch(config)#ip http authentication local
Switch(config)#access-list 1 permit 10.100.50.0 0.0.0.255
Switch(config)#ip http access-class 1
Proteja o acesso via console e VTY utilizando senhas fortes
Apesar de maioria dos ambientes os switches estarem em locais fechados e de difícil acesso é preciso proteger tanto a porta de console como o acesso remote via VTY com senha. Normalmente é utilizado o mesmo método de controle de acesso da console e VTY.
Proteja o acesso remoto ou virtual terminal access
É importante utilizar autenticação em todas as linhas VTY, limitar o acesso por endereço IP de origem através de ACLs aplicadas às VTYs tanto para acesso remoto via Telnet ou Secure Shell (SSH).
Além disso, sempre prefira SSH ao invés de Telnet, pois apesar de simples ele não é seguro por enviar mensagens em texto claro, possibilitando o roubo de usuários e senhas de acesso privilegiado.
O SSH possui criptografia e por isso é mais seguro, porém você precisa de um IOS que suporte esse recurso.
Veja exemplo abaixo onde vamos permitir apenas dois servidores de gerenciamento acessar as linhas VTY, os endereços dos servidores são 192.168.100.10 e 192.168.200.100.
Cuidado ao implementar essa configuração e aplicar realmente a todas as linhas VTY, pois algumas vezes os switches separam em line VTY 0 4 e 5 a 15 no show running, gerando confusão na aplicação do comando e deixando abertas portas para conexão sem verificação da ACL.
Veja o exemplo abaixo.
Switch(config)#access-list 10 permit 192.168.100.10
Switch(config)#access-list 10 permit 192.168.200.100
Switch(config)#line vty 0 15
Switch(config-line)#access-class 10 in
Switch(config-line)#transport input ssh
Switch(config-line)#login local
As versões de SSHv1 e SSHv1.5 possuem algumas fraquezas, por isso sempre que possível utilize o SSHv2.
Proteja o acesso para monitoração via SNMP
Para evitar que alterações sejam feitas via SNMP evite utilizar comunidades de escrita e leitura (read-write), elas aparecem no comando “snmp-server community nome-da-comunidade RW”, permitindo apenas comunidades “read-only” (apenas leitura).
É aconselhável utilizar ACLs para limitar o acesso, mesmo utilizando comunidades apenas read-only.
Se possível utilize o SNMPv3 que possui autenticação e criptografia, não dependendo de comunidades com segurança fraca como nas versões SNMPv1 e SNMPv2c.
Proteja portas do switch não utilizadas
As portas dos switches não utilizadas deveriam ser desabilitadas, assim nenhum usuário conseguiria conectar um host sem o conhecimento da administração de redes.
Isso é feito com o comando “shutdown” dentro da interface, porém nem sempre isso é possível devido a possível sobrecarga para equipe de TI que cuida da rede para tratar solicitações desse tipo e também controlar cada porta de switch.
Portas de usuários ou de acesso devem ter o comando “switchport mode Access” na interface, assim um usuário mal intencionado não conseguirá negociar para passar a porta para trunking.
Você também podem colocar portas de acesso não utilizada em uma VLAN inativa e filtrada nos trunks entre switches, assim mesmo que um usuário se conecte em uma porta não autorizada ele ficaria isolado na rede.
Outra opção é o comando “switchport host” no modo de configuração de interface, pois esse comando coloca a porta como acesso, ativa o portfast e desativa negociação de etherchannel na porta. Veja exemplo abaixo.
Switch(config)#int f0/1
Switch(config-if)#switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled
Proteja a operação do STP
Como já estudamos, é possível que um usuário mal intencionado injete BPDUs nas portas do switch para tentar tomar acesso como root bridge e afetar a estabilidade do STP, causar loops ou alterar o fluxo de quadros para um possível sniffing de rede.
Por isso é recomendável ativar o recurso de BPDU guard nas portas de acesso dos switches.
Proteger o uso do CDP e LLDP
Por padrão os anúncios do CDP são enviados em todas as portas do switch a cada 60 segundos. Apesar de muito útil, principalmente em redes com Telefonia IP, o CDP é considerado um risco de segurança por muitos administradores de rede por possibilitarem a coleta de informações sobre os roteadores e switches Cisco, possibilitando descobrir vários informações e ataques como VLAN hopping.
O CDP pode ser ativado e desativado em modo global, afetando todas as interfaces ou então pode ser feito por interface com o comando “[no] cdp enable”.
Se você tem certeza que não vai utilizar o CDP o melhor é desativá-lo.
Com isso terminamos mais um artigo sobre segurança em switches Cisco e espero que tenha ajudado mais um pouco na sua formação.
Dúvidas? Deixe sua pergunta ou sugestão na área de comentários mais abaixo nessa mesma página!
Obrigado e até um próximo artigo.
One Response
Faltou Port-Security, DHCP Snooping + DAI + IPSG… &;-D