Nas comunidades de TI e Telecom é bem comum que se propague a idéia de que as disciplinas de gerenciamento e segurança de Redes são inconciliáveis (e mutuamente excludentes). Em vez de formar algum juízo de valor, entendo ser conveniente buscar soluções que mostrem que tal pessimismo não pode se perpetuar. Afinal, as redes precisam ser gerenciadas… E, se por um lado Segurança não pode ser um entrave para o gerenciamento, este último não deve inserir vulnerabilidades.
O objetivo do presente artigo é apresentar resumidamente as áreas de gerência que tipicamente estão presentes em uma rede LAN e, quando possível, mostrar versões seguras para os protocolos de Rede envolvidos (dos quais o SNMPv3, Simple Network Management Protocol versão 3, é apenas um exemplo). Admitiremos em nossa análise o caso mais simples, isto é, o uso de um switch nível 2 na camada de acesso.
Acesso seguro à linha de comando (Command Line Interface = CLI) para fins de configuração e monitorização:
- Usar cliente Secure Shell versão 2 (SSH) em substituição ao Telnet
- Configurar o switch para que não aceite acesso terminal que não seja SSH
- Usar no mínimo criptografia DES mas, se possível, optar por 3DES-168 (ou AES).
- Controlar os comandos que podem ser executados via SSH e console física por meio do protocolo TACACS+ (autenticação, autorização e accounting de comandos).
- Usar HTTPS e não HTTP.
- Definir os algoritmos criptográficos aceitáveis para a garantia de confidencialidade da sessão HTTPS. Usar no mínimo DES mas, preferencialmente, 3DES-168 (ou AES).
- Exigir autenticação de usuário administrativo seguida de autorização e accounting dos comandos através do protocolo TACACS+.
Após esta breve descrição das opções de configuração e acesso a arquivos, voltemos ao SNMP…
A versão 3 do protocolo SNMP (SNMPv3) foi criada com o propósito de eliminar a visão histórica de que o significado da sigla era Security is Not My Problem. O novo modelo inclui não só autenticação individualizada (por usuário) mas também criptografia dos dados transmitidos. Lembrando que há operações do SNMP que permitem até mesmo alteração da configuração do equipamento, é fácil perceber que não convém que os dados (e muito menos a senha de acesso) sejam transferidos em claro.
Vale, no entanto, um alerta: a RFC 3414 (SNMPv3) prevê três modos possíveis de operação do protocolo, os quais são representados na Figura 1. Desses, apenas o AuthPriv contempla simultaneamente autenticação e criptografia, significando que é o único que atende nosso objetivo de gerenciar com Segurança a rede. Desta forma, se você está pensando em utilizar SNMPv3, deve verificar tanto do lado das soluções de gerência como dos elementos gerenciados, se existe suporte ao modo AuthPriv e, neste caso, quais os algoritmos criptográficos disponíveis. (Imagine um produto que suporta criptografia… Mas com chave de 5 bits… )
Figura 1: Modos de operação e exemplo de pacote SNMPv3 AuthPriv
Uma outra área relevante de gerência de Redes é o controle de sincronismo entre os equipamentos. Para se ter uma idéia da importância de se dispor de uma referência única (e confiável) de relógio, listamos algumas aplicações em que a informação de tempo é utilizada:
- Coerência das informações de gerenciamento
- Coerência do accounting de utilização dos serviços de rede (normalmente controlados via RADIUS)
- Coerência do accounting de acesso administrativo a equipamentos de Rede (função clássica do TACACS+)
- Verificação da validade de Certificados Digitais
- Definição de políticas de acesso baseadas em horário
- Verificação da validade de licenças de software vinculadas a horário
- Subsídio para medição confiável de parâmetros de SLA
- Subsídio para auditoria (desde que o processo utilizado para sincronização seja seguro…)
Diante disso, vale advertir que existe uma versão simplificada do NTP, denominada SNTP (Simple NTP), que não inclui autenticação e que, portanto, não é adequada para ambientes em que é preciso comprovar comprometimento com minimização do risco operacional e disponibilizar informações para fins de auditoria. Mais detalhes são providos na Figura 2.
Figura 2: Autenticação entre cliente e servidor NTP
O presente texto é uma tentativa de caracterizar um primeiro passo na busca do objetivo maior de se construir redes LAN mais seguras. Isso porque, apesar de existirem várias funcionalidades específicas de Segurança de LAN (802.1x, Port Security, Private VLANs, etc), se o gerenciamento não for conduzido de forma segura, todo o resto do esforço poderá ser perdido.
** Sumário de Recomendações:
- Acesso Remoto Seguro a CLI: SSHv2
- Acesso Remoto via Interface Gráfica: HTTPS
- Transferência Segura de arquivos: SCP (Secure Copy) ou SFTP (Secure FTP)
- Monitorização e Alertas: SNMPv3 no modo AuthPriv
- Sincronismo Seguro: NTPv3 (no mínimo) com autenticação MD5 por parte do cliente (equipamento)
- Controle de Acesso Administrativo (autorização e accounting de comandos): TACACS+
- Já existe o NTP versão 4 mas muitos produtos ainda não o implementam. Enquanto a disponibilidade do novo protocolo não se amplia, o mínimo aceitavél é o suporte à versão 3.
- As considerações aqui feitas para um switch L2 também se aplicam a elementos que operam em camada 3 (switches L3 e roteadores).
- Há um interessante guia de hardening de switches Cisco produzido pela NSA (National Security Agency), cuja leitura é altamanente incentivada: (http://www.nsa.gov/ia/_files/switches/switch-guide-version1_01.pdf)
- RADIUS e TACACS+: dois protocolos complementares (http://wp.me/p1loe7-2M)
- Projetos Multilayer de Redes LAN: por que usar switches nível 2 na camada de acesso ? (http://wp.me/p1loe7-cn)
Nenhum comentário:
Postar um comentário