Gerência de Redes - 5.SNMPv3

Notas do Editor

• #3: Situação do protocolo SNMP até então: SNMP v1 e v2c são largamente usadas por fabricantes e operadores Utiliza esquema de segurança trivial baseada em community-strings, o que inibe o uso das operação de controle (sets) SNMPv3 é uma nova alternativa para oferecer serviços robustos de segurança, infra-estrutura administrativa e configuração remota de agentes para SNMP. SNMPv3 apresentará um formato distinto para a mensagem SNMP, mas prevê que agentes e gerentes SNMPv3 possam se comunicar com entidades SNMPv1 e SNMPv2.
• #4: SNMPv3 define várias novas MIB’s e prevê os mesmos componentes e arquitetura das versões anteriores – Gerentes, agentes e MIB’s Sua documentação tem característica modular. Os documentos introdutórios da arquitetura são: RFC 3410, “Introduction to version 3 of the Internet-Standard Network Management Framework”, uma visão geral do SNMPv3 e um roadmap para os demais documentos. RFC 3411, “An Architecture for Describing SNMP Management Framework”, descreve a arquitetura do protocolo, como um todo, dando especial ênfase aos modelos de segurança e administrativo.
• #5: A arquitetura SNMPv3 é compostas por módulos que interagem provendo serviços uns aos outros, através de primitivas Conceitos SNMPv3: Entidades SNMP (SNMP Entities) Contextos SNMP – subconjunto definido da informação de gerenciamento SNMP Engine (“máquina virtual“ que realiza o envio/recepção, encriptação/decriptação de mensagens) – funcionalidades básicas Aplicações SNMPv3 (command generator, notification originator, notification receiver, command responder, notification originator, proxy forwarder) – funcionalidades específicas As engines provêem serviços para as aplicações; Entidade SNMPv3 = Engine + Aplicações O processamento da mensagem SNMPv3 é executado pelas funções do Dispatcher e do Message Processing Subsystem, ambos parte do engine SNMP.
• #6: Ao contrário das versõs anteriores, SNMPv3 propôe a arquitetura interna em módulos do gerente e do agente.
• #7: Ao contrário das versõs anteriores, SNMPv3 propôe a arquitetura interna em módulos do gerente e do agente.
• #8: RFC 3414, “The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)”, descreve ameaças, mecanismos, algoritmos, serviços de segurança e tipos de dados usados com o objetivo de prover segurança ao protocolo; RFC 3415, “View-Based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)”descreve como é definido o controle de acesso às informações de gerenciamento; O proposto modelo de segurança baseado em usuário será flexível de forma que, no futuro, novos algoritmos poderão ser usados sem alterações no modelo. Seu único protocolo de privacidade sendo proposto é baseado no algoritmo DES. Ao se enviar uma mensagem pode-se optar por uma das seguintes opções (campo msgFlags): sem autenticação, sem privacidade com autenticação, sem privacidade com autenticação, com privacidade Neste modelo, autentica-se um usuário (chamado de principal ).
• #9: O modelo de segurança é responsável pelo processamento de segurança da mensagem, implementando mecanismos para garantir a segurança da mensagem. Um único modelo de segurança proposto até o momento para SNMPv3 é o modelo USM (user based security model) mas nada impede a oferta de outros modelos de segurança no futuro. As ameaças consideradas pelo modelo de segurança baseado em usuário focam no trajeto da informação pela rede, levando em consideração as características do tráfego SNMP (fragmentado em muitas mensagens). O modelo de segurança baseado em usuário oferece os seguintes serviços: Autenticação: Protocolos HMAC-MD5-96 e HMAC-SHA-96 Privacidade: Protocolo DES em modo CBC Proteção contra atrasos e reenvios de mensagens através de mecanismos de temporização
• #10: Identificação e privilégios no USM: Principal – uma entidade que pode ter serviços ou processamento SNMP sendo executados. Pode ser um indivíduo, um grupo de indivíduos, uma aplicação ou combinações destes. A um principal estão vinculadas várias informações de segurança, inclusive as chaves criptográficas e contextos possíveis. A associação de um principal com um sistema agente define os aspectos de segurança que serão invocados (autenticação, privacidade e controle de acesso) securityName - é uma string que identifica um principal. Engine ID – identifica unequivocamente um engine SNMP, e a entidade SNMP correspondente.
• #11: msgVersion – Especifica a versão do protocolo em uso (3 - SNMPv3) msgID – Identificador usado para coordenadar requests e responses msgMaxSize – Informa o maior tamanho de mensagem suportado msgFlags – String de bits que identificam a existência de report, autenticação e encriptação na mensagem msgSecurityModel – Identifica o modelo de segurança em uso. Valores possíveis até o momento: SNMPv1, SNMPv2c e USM. msgSecurityParameters – String com parâmetros a serem processados pelo Security Subsystem (depende do modelo de segurança) contextEngineID – Identifica um engine que está sob determinado contexto. Define a aplicação a qual o PDU está relacionado contextName – identificador do contexto sendo usado pelo PDU. é passado como parâmetro para o dispatcher e o VACM. PDU – é o PDU SNMPv2c
• #12: Algoritmo para transformar uma senhas ASCII para uma chave binária: A senhas de um usuário (principal) pode ser originadas a partir de strings (frases). O processo consiste em usar uma string ASCII como ponto de partida. O algoritmo usado pelo modelo USM concatena cópias da string ASCII de forma a completar 1 Mb. Sobre este resultado se aplica a função hash que gera um resultado binário de tamanho fixo. Isto dificulta ataques por dicionário. Processo de autenticação: 1. São geradas duas chaves temporárias, K1 and K2, a partir da chave de autenticação do usuário K; 2. Calcula-se T = Hash (K2 | Mensagem); 3. Calcula-se M = Hash (K1 | T); 4. Os primeiros 96 bits de M são o MAC (Message Authentication Code) a ser enviado com a mensagem. É obrigatória a implementação de HMAC-MD5-96. É opcional mas sugerida a implementação de HMAC-SHA-96.
• #13: Cada usuário possui chaves únicas: uma chave para cada serviço de segurança (autenticação e privacidade). Como as chaves serão colocadas em cada agente não é especificado no protocolo. Com isso, acaba-se criando a necessidade de um serviço de gerenciamento de usuários/chaves externo.
• #14: As mensagens são protegidas por um mecanismos de sincronização para evitar ataques de reenvio de mensagens já enviadas. Este mecanismos é baseado no conceito de Authoritative SNMP engine, usado para definir a noção de tempo correta para uma mensagem. O lado “authoritative” possui a referência de tempo considerada correta. Cabe ao outro lado obter esta informação e usá-la para validar as mensagens que receber ou enviar (no caso de traps). Os campos msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime, dão a indicação de tempo necessária para um serviço de autenticação de um engine definir se uma mensagem é “velha” demais (ultrapassar uma “janela de oportunidade”): 1. Se o campo boots for maior que o valor local, se aceita e atualiza a noção local de boots e time do engine SNMP. 2.Se o valor de boots for menor que o local, se descarta mensagem como velha 3. Se forem iguais, compara-se os valores de time daquele engine : se diferirem por mais de 150 segundos, descarta-se, caso contrário aceita-se.
• #15: As chaves criptográficas passam por um processo de localização gerando chaves específicas para cada engine SNMP. São usados os valores da chave não-localizada e do engineID específico da entidade SNMP. Ambos são combinados e passados por uma função hash. Este processo garante que a chave será armazenada de formas diferentes em cada sistema agente. Se uma for comprometida, somente o agente em questão é afetado. A chave não-localizada não é armazenada em nenhum lugar. Isto garante que um usuário somente verá um único segredo e os vários engines terão segredos independentes. Mesmo se um for comprometido, os demais não estarão vulneráveis por isso.
• #16: É implementado em SNMPv3, através da definição de uma nova textual convention , um mecanismo de troca de chaves onde é impossível determinar a chave antiga a partir da nova. Pode já existir no engine um material criptográfico inicial pré-configurado (“template”) para servir de base. A convenção de texto KeyChange descreve o procedimento: 1. Gera-se um valor randômico 2. Computa-se um valor temporário usando o valor randômico e a chave atual sendo mudada 3. XOR com a senha desejada, gerando o “delta” 4. Enviar o valor randômico e o delta para o engine a mudar de senha 5. O engine destino refaz a computação e chega no mesmo segredo
• #18: Quem? A combinação de securityModel e securityName definem o principal. Esta combinação pertence a um ou mais grupos num engine SNMP. Onde? O contextName especifica onde o objeto desejado deve estar. Como? A combinação do securityModel e o securityLevel definem como a mensagem foi protegida A combinação de Quem-Onde-Como identificam zero ou mais entradas na tabela vacmAccessTable. Porque? O viewType especifica para que o acesso é requerido: leitura, escrita ou notificação. A entrada selecionada na tabela vacmAccessTable contém uma MIB viewName para cada um dos tipos de acesso. A viewType é usada para selecionar qual MIB view será usada. O que? o nome da variável (variableName) possui um identificador de objeto e instância. Qual? o identificador de instância define entre todas, qual a instância em questão é requerida. Ao final, o nome da variável é comparado à MIB view obtida. Se a variável estive dentro da MIB view, o acesso é dado.
• #19: SNMPv3: Trata-se de uma nova tentativa de oferecer segurança e organização, evitando os erros cometidos com SNMPv2p Apresenta uma arquitetura modular permitindo evoluções em todos os aspectos - documentação, módulos de processamento de versões, modelos de segurança e até nos algoritmos criptográficos propostos no modelo USM Reconhece e trata mensagens SNMP de quaisquer versões Utiliza o mesmo PDU SNMPv2 Já é implementado em vários dispositivos/sistemas Para maiores informações: SNMPv3 Documentation and Specification: http://www.snmp.com/snmpv3/index.shtml SNMPv3 Charter: http://www.ietf.org/html.charters/OLD/snmpv3-charter.html Simple-times: http://www.simple-times.org/pub/simple-times/issues/5-1.html
• #20: Como foi visto nesta SA, SNMPv3 apresenta várias novidades, principalmente no que diz respeito a segurança na troca de mensagens SNMP. O agente NET-SNMP oferece suporte à SNMPv3 através de sua configuração. O arquivo de configuração do agente (/etc/snmpd.conf) deve ser adequado para uso com SNMPv3. Mais uma vez o script snmpconf pode auxiliar nesta configuração, mas lembre-se que nem todas as opções possíveis são configuradas por ele. O comando snmpusm é usado para se criar usuários do modelo de segurança USM. O comando snmpvacm é usado para se criar entradas no controle de acesso VACM. Para mais informações use as man pages: man snmpconf man snmp_config man snmpusm man snmpvacm
• #21: Para se criar usuários e privilégios para os mesmos no agente NET-SNMP, cria-se um usuário inicial para que este possa criar os demais. Para se criar um usuário de nome “inicial”, configura-se o arquivo /etc/snmp/snmpd.conf: rwuser inicial e, no arquivo, /var/lib/snmp/snmpd.conf, acrescenta-se a linha createUser initial MD5 password DES Esta linha informará o agente das passwords (de autenticação e privacidade) a serem usadas pelo usuário neste agente. Na carga do agente, ele lê esta linha, gera as chaves localizadas correspondentes e apaga a linha. O motivo é manter gravado em disco somente as chaves localizadas e não mais a password original do usuário.
• #22: Cada usuário possui um nome ( securityName ), uma opção de autenticação ( authProtocol ), uma opção de privacidade ( provProtocol ), além das chaves criptográficas correspondentes ( authKey e privKey ). A autenticação é feita “assinando” a mensagem com a chave do usuário em questão, usando um dos protocolos possíveis (HMAC-MD5 ou HMAC-SHA). As chaves são geradas a partir de uma senha de, no mínimo, 8 carateres. A encriptação é feita codificando a parte de dados da mensagem com um dos protocolos possíveis (AES ou DES) O securityLevel de uma mensagem indica de ela terá autenticação e/ou privacidade. Todas estas informações são passadas para as aplicações em linha de comando. valores default podem ser armazenados em arquivo snmp.conf. Note que é possível se ter este arquivo por usuário no sistema.
• #23: Comando: snmpgetnext -v 3 -n "" -u MD5User -a MD5 -A "Frase" -l authNoPriv test.net-snmp.org sysUpTime Resposta: system.sysUpTime.0 = Timeticks: (83491735) 9 days, 15:55:17.35
• #24: 9. Use o agente e as aplicações do pacote NET-SNMP, ajustando para uso somente de mensagens SNMPv3. Crie as configurações abaixo para o modelo de segurança USM: Usuário: especial Passphrase: entidade_privada 10. Use as aplicações em linha de comando para testar o agente (via SNMPv3). Obtenha: - sysContact - sysName