Está habilitando https em um roteador Cisco um risco de segurança considerável?

Question

Eu gostaria de usar o Network Assistant da Cisco para gerenciar meus roteadores Cisco (sei que existem outras soluções para isso, mas por enquanto decidi usar o CNA). Isso requer que o serviço HTTP ou HTTPS esteja em execução nos roteadores que estão sendo gerenciados. Onde eu trabalho, já me disseram que provavelmente não será permitido implementar isso, porque ativar o HTTP / HTTPS nos roteadores é um risco de segurança.

Mas é realmente uma falha de segurança, desde que eu ative o HTTPS e mude o número da porta padrão? Eu quero poder dizer com confiança que fazer isso dessa maneira é completamente seguro. É claro que nada é "completamente" seguro e um scanner de porta pode encontrar qualquer porta aberta, mas o serviço HTTP em execução no IOS não é tão hackável?

Por fim, eu deveria ter feito essa pergunta no fórum de segurança?

    

Answer 1

Como um princípio de Garantia da Informação (IA), quanto menos serviços desnecessários estiverem sendo executados em um dispositivo, menor será a superfície de ataque. Para atenuar problemas, a configuração adequada e os níveis de patch são fundamentais. Alterar portas é um dos muitos elementos que você pode fazer para diminuir o risco de segurança em potencial.

A Cisco tem um excelente guia para a implementação adequada do serviço HTTP / HTTPS aqui (Selective Habilitando aplicativos usando um HTTP ou HTTPS)

    

Answer 2

Um possível problema com HTTPS é que pessoas preguiçosas (como eu) podem não configurar um certificado Kerberos no dispositivo para garantir que as conexões sejam seguras. Seu certificado teria que vir de uma das três fontes: uma autoridade de certificação comercial como a Verisign (cara), configurar sua própria CA usando um servidor Windows ou Linux (não tão difícil, mas demorada), a terceira opção é usar uma certificado assinado, conforme descrito aqui:

link

Se o seu dispositivo não tiver certificado, as conexões ainda deverão ser criptografadas, dificultando o uso do usuário casual wireshark, mas de maneira alguma "seguro" em qualquer sentido significativo. Você não terá nenhuma garantia de que as conexões não sejam afetadas por um ataque man-in-the-middle. além disso, você (ou os usuários dependendo do recurso) pode ter uma falsa sensação de segurança, análogo a ter antivírus, mas não atualizá-lo.

Eu diria que, embora a alteração da porta de escuta seja uma boa precaução básica, uma vez que seu dispositivo é encontrado em uma varredura de porta, qualquer pessoa interessada poderia começar a testar os serviços básicos, por exemplo. HTTP, HTTPS, SSH ou SMTP usando o cliente apropriado para esse serviço e veja se eles obtêm respostas válidas. Isso pode ser script, por ex. com cURL para HTTP / S, mutt para smtp, ssh ... para SSH. As melhores defesas, se suas portas de escuta devem estar voltadas para a Internet, são manter o sistema operacional e os serviços corrigidos e restringir o acesso apenas aos endereços IP ou intervalos confiáveis, usando ACLs (Access Control Lists).

    

Answer 3

Ativar o HTTPS e alterar o número da porta é, na verdade, uma prática muito comum. Usar uma senha segura para o login também aumentará a segurança.

Claro, você deve sempre usar HTTPS sobre HTTP.

Mas, finalmente, para responder à sua pergunta, não, não é inseguro. A interface de gerenciamento da web é apenas uma maneira amigável de definir as configurações, mas se alguém quiser entrar no seu roteador (e souber o que está fazendo), ele não usará a interface da web. Você deveria estar bem.

    

Answer 4

Todas as portas abertas no seu dispositivo ou servidor aumentam a superfície de ataque, certamente. Dito isso, habilitar o HTTPS seria mais seguro do que ativar um protocolo não criptografado como o Telnet ou o HTTP.

Você menciona a alteração do número da porta. Tenha cuidado com isso, você pode impedir que o Cisco Network Assistant encontre / gerencie o dispositivo. (O CNA permite que você especifique um número de porta personalizado?)

Quaisquer que sejam os serviços de gerenciamento que você tenha, verifique se os bloqueios de segurança apropriados estão em vigor. Implemente o maior número possível de itens a seguir:

1. Use apenas protocolos criptografados para gerenciamento (HTTPS e SSH).
2. Nenhuma porta de gerenciamento deve ser exposta à internet pública ou a uma rede de convidados (por exemplo, WiFi do visitante).
3. Tempo limite da sessão ociosa para as interfaces de gerenciamento. Note que estes podem ser configurados separadamente para HTTP vs SSH vs console serial, portanto, certifique-se de ter todas as suas bases cobertas.
4. Implemente a limitação de taxa e o bloqueio de conta temporário para atenuar os ataques de força bruta.
5. Use senhas longas e complexas exclusivas
6. A conta de administrador no switch não deve ser algo "conhecido" como admin, administrador, root. (Algo que um script automatizado tentaria usar para invadir).
7. Verifique se as senhas / tempos limite / bloqueios também são aplicados ao console serial. (Eu vi vários dispositivos em que o console serial não estava com a senha ou nunca atingiu o tempo limite. Você poderia conectar um cabo serial e ingressar em uma sessão ativa que foi aberta meses atrás.)
8. Cuidado com o SNMP deixando uma porta traseira no sistema.
9. Considere AAA e RADIUS para permitir o gerenciamento central de senhas e permissões.
10. Certifique-se de que o registro está configurado para rastrear quem efetuou login no dispositivo e quando.
11. Use o NTP para obter a data / hora correta em seus registros (também importante para a validade do certificado).
12. Tenha registros armazenados em algum lugar onde eles não serão limpos se o dispositivo travar / reinicializar. Registre-se no sistema de arquivos ou, idealmente, em um servidor syslog independente.
13. Faça backup de suas configurações regularmente.
14. As senhas armazenadas no dispositivo devem ser criptografadas usando a criptografia mais strong disponível. (Alguém não deve conseguir a senha se encontrar seus backups de configuração.)
15. Fique por dentro dos boletins de segurança que afetam seus dispositivos, atualize seu IOS regularmente.
16. Implemente certificados HTTPS adequados com sua própria autoridade cert interna.
17. Limite o intervalo de IPs que podem acessar as portas de gerenciamento (por exemplo, apenas o PC com o CNA instalado)
18. Limite as interfaces de gerenciamento a uma VLAN ou porta de rede específica que não seja acessível por usuários comuns.
19. Se várias pessoas gerenciam o dispositivo, considere várias contas de gerenciamento com diferentes níveis de acesso.