Propostas de Autenticação para o Protocolo de Gerência de Redes SNMP

Mauro Tapajós Santos e Rafael Timóteo de Sousa Júnior
Departamento de Engenharia Elétrica - Universidade de Brasília - UnB Caixa Postal 4386, CEP: 70919-970, Brasília DF – Brasil Tel: 061-2735977, Fax: 061-2746651, tapajos@abordo.com.br, desousa@unb.br Sumário - este trabalho apresenta propostas implementadas de serviços de autenticação no protocolo SNMP, provendo um mecanismo básico de segurança para sua versão 1 e mantendo flexibilidade suficiente para permitir uma integração ao modelo de segurança das novas versões do protocolo. Tais propostas têm base na utilização de senhas descartáveis na autenticação das mensagens SNMP, com os necessários protocolos criptográficos para geração e troca de chaves de criptografia entre as entidades usuárias do protocolo. 1. INTRODUÇÃO O protocolo de gerência de redes mais usado atualmente é o SNMP (Simple Network Management Protocol). Juntamente com outros padrões relacionados, SNMP oferece um denominador comum na construção de arquiteturas de gerência de redes distribuídas. Como está hoje, o SNMP ainda não responde a requisitos importantes de segurança. A efetiva gerência de redes demanda tanto facilidades de monitoração, como de controle dos diversos componentes das redes. SNMP é usado basicamente para monitoração, devido aos seus mecanismos fracos de segurança que inibem a execução de ações à distância, necessárias às diversas tarefas de controle das redes. Em conseqüência, as operações de configuração possíveis via SNMP são subutilizadas por causa da desconfiança dos operadores e gerentes de redes com relação à segurança do processo. Contudo, o projeto inicial de SNMP previra a necessidade de atualizações. A forma modular como foi definido o protocolo visou facilitar futuras modificações para as soluções das falhas, mantendo a filosofia da simplicidade do protocolo. O problema-chave na versão mais utilizada (SNMPv1) do protocolo é o emprego de um mecanismo de segurança trivial que visava oferecer autenticação para as mensagens e controle básico de autorizações de acesso para operações sobre objetos gerenciados [1]. De fato, o mecanismo de autenticação em SNMPv1 consiste em preencher o campo comunidade (communityString) das mensagens do protocolo com uma senha não criptografada e virtualmente imutável. Com freqüência, na prática da gerência de redes, é usado o termo public como nome de comunidade. Tal senha pode ser obtida por simples análise do tráfego, permitindo a um atacante ter acesso aos elementos gerenciados para executar operações de gerência de rede. Assim, o acesso não-autorizado pode possibilitar a um atacante, não somente descobrir parâmetros críticos dos sistemas e da rede, como também alterá-los e prejudicar os serviços que deles dependem. A segunda versão do protocolo [2], denominada SNMPv2 clássica ou SNMPv2p, tenta solucionar o problema da segurança, apresentando um modelo de segurança que integra autenticação e criptografia ao protocolo, para protegê-lo de ameaças como interrupção, interceptação, modificação e mascaramento de informações. Isso permitiria que troca de mensagens SNMP fosse ou totalmente aberta, ou autenticada mas não privada, ou privada mas não autenticada, ou ainda autenticada e simultaneamente privada. O novo conceito de party era muito importante nesta proposta. Uma party é definida como um contexto de execução virtual nas entidades SNMP, onde a operação do protocolo restringe-se a um subconjunto de possíveis operações. A estrutura da party substituía as comunidades da versão 1, acrescentando informações de tempo (clocks), chaves de criptografia e políticas de acesso às entidades SNMP. Foi difícil a aceitação deste novo protocolo principalmente por causa de sua incompatibilidade com a versão 1, já que as novas mensagens criptografadas não eram compreendidas pelas entidades SNMPv1. E, além de ter problemas de overhead nas mensagens, o modelo administrativo baseado em parties implica numa pré-configuração destas parties, o que pode se tornar um processo excessivamente complexo, já que aspectos como protocolos de transporte, clocks, chaves para os algoritmos de segurança e direitos de acesso devem ser previamente definidos na etapa de configuração das entidades do protocolo, ou seja, os agentes de gerência e gerentes de rede. Em conseqüência, foram empreendidos novos esforços de revisão do protocolo em resposta à baixa aceitação da versão SNMPv2 clássica. Tal revisão se deu principalmente no que diz respeito ao contexto baseado em parties, à configuração dos agentes SNMP, à dificuldade de mapeamento da rede e à implementação do modelo administrativo e de segurança. Decidiu-se voltar o contexto de operação do protocolo à antiga forma de comunidades, sem o modelo de segurança proposto em SNMPv2 clássico, e, consequentemente, voltando ao antigo formato das mensagens. Assim, foi apresentada mais uma versão SNMP, chamada de SNMPv2c, baseada em comunidades, o que recolocou o problema de segurança original.

A partir daí, dentre as tentativas de definição do modelo administrativo e de segurança, duas linhas de desenvolvimento se destacaram: a SNMP USEC (User-based Security Model) e a SNMPv2* (SNMPv2 “star”). Estas duas propostas, que representaram caminhos independentes percorridos por integrantes das equipes originadoras do protocolo, terminaram por convergir nos trabalhos de definição da versão 3 do protocolo, denominada SNMPv3, cujos trabalhos ainda estão sendo concluídos com a elaboração de documentos que serão submetidos ao processo da padronização definitiva [3]. Alguns detalhes da nova proposta ainda estão em discussão, e, até o momento da redação deste artigo, as especificações geradas ainda não possuíam status de padronização completa. Na proposta SNMPv3, existe, até o momento da redação deste trabalho, um único modelo de segurança sendo adotado. Ele se chama USM - User-Based Security Model [4] e sua implementação é obrigatória em todas as entidades SNMPv3. O modelo de segurança USM identifica as ameaças levadas em consideração na operação do protocolo SNMP e define as proteções a serem usadas e as regras que o tornarão operacional dentro da arquitetura proposta para SNMPv3. USM é basicamente derivado do modelo SNMP USEC de segurança baseado em usuário [5], com algumas alterações. Nele, existe um conceito de usuário ao qual estão associadas informações de segurança usadas em um ambiente de gerência SNMP. A definição de SNMPv3 reconhece que é um erro querer definir um único modelo de segurança definitivo e imutável, pois, com o tempo, novos requisitos de segurança aparecerão e outros podem cair em desuso. Assim, admite-se que SNMP poderá suportar vários modelos de segurança, sendo porém obrigatória a implementação do USM para garantir compatibilidade com o modelo inicial de SNMPv3 As principais ameaças levadas em consideração na definição de SNMPv3 são a modificação da informação gerada por um usuário válido e o mascaramento de um usuário, efetivado pelo uso de uma identificação falsa por parte de uma entidade não autorizada. Também foram consideradas, ainda como secundárias, as seguintes ameaças de replay, ou seja reordenamento e atraso das mensagens de forma estranha à operação normal da rede, e falta de privacidade nas trocas de mensagens entre entidades SNMP. Estas ameaças são evitadas com a utilização de criptografia e de uma política de acesso às informações, o que subentende a utilização de algoritmos criptográficos e de chaves de criptografia. Os serviços de segurança para defesa contra as ameaças consideradas acima são: integridade dos dados da mensagem, autenticação da origem das mensagens, confidencialidade dos dados das mensagens e proteção temporizada contra replays. Todos eles são serviços comuns de segurança nas mensagens do protocolo. Cabe notar que o serviço de autenticação da origem dos dados proposto só pode garantir que se saiba qual usuário dentro do modelo USM está enviando a

mensagem. Assim, qualquer um, de posse das informações daquele usuário, pode agir sob seu nome. Por outro lado, o modelo USM oferece capacidade de autenticação e confidencialidade da comunicação. Como não é possível oferecer confidencialidade sem ter autenticação da origem e garantia da integridade dos dados, existem 3 níveis de segurança possíveis dentro do modelo: 1. Comunicação sem autenticação ou confidencialidade (nível de segurança denominado noAuthNoPriv); 2. Comunicação com autenticação, mas sem confidencialidade (denominado authNoPriv); 3. Comunicação com autenticação e confidencialidade (denominado authPriv). Dentre os campos componentes dos dados globais da mensagem SNMPv3, está a informação de qual será o nível de segurança que deverá ser aplicado à mensagem. Para implementar os mecanismos de segurança descritos acima, são definidos 3 módulos dentro do modelo de segurança: módulo de autenticação (que lida com a integridade dos dados e autenticação da origem), módulo de temporização (que lida com atrasos e replays de mensagens) e módulo de confidencialidade (que lida com a privacidade da mensagem). Visando a implementação desses módulos, é preconizada a utilização de protocolos criptográficos de autenticação, de integridade dos dados e autenticação da origem, com base nos algoritmos MD5 [6] e SHA-1 [7], além do método HMAC (Keyed-Hashing for Message Authentication) [8]. Diante dessa evolução, e considerando que, apesar do desenvolvimento já avançado, o trabalho em SNMPv3 ainda não está concluído e algumas questões ainda estão em aberto, o trabalho apresentado neste artigo procura desenvolver alternativas de mecanismos de autenticação para SNMP compatíveis com as versões anteriores do protocolo, ainda largamente utilizadas e bastante eficazes. Nesse sentido, as propostas descritas nesta artigo visam apresentar um mecanismo autenticador de mensagens SNMP para as versões v1 e v2c do protocolo, mecanismo este capaz de substituir o esquema trivial de autenticação dessas versões. Por outro lado, foi também preocupação no desenvolvimento manter coerência com os trabalhos em SNMPv3, de forma a tornar possível a utilização das propostas aqui descritas dentro da arquitetura da versão 3. Assim, são apresentados a seguir dois protocolos de autenticação, denominados auth-N e auth-P, ambos com base no emprego de chaves de autenticação que mudam constantemente, reduzindo o risco da quebra de qualquer uma das chaves a um comprometimento de somente uma mensagem SNMP e isso apenas no momento em que tal mensagem está sendo trocada entre duas entidades de gerência de rede. 2. PROTOCOLOS DE AUTENTICAÇÃO PROPOSTOS

Os protocolos de autenticação aqui propostos se preocupam basicamente com as ameaças de modificação da informação e mascaramento. Para oferecer proteção contra estes ataques, é enviada juntamente com a mensagem, a informação de autenticação. Esta informação será usada pelo receptor no processo de verificação da autenticidade da mensagem, implicando na necessidade de um método de geração desta informação, em função pelo menos dos dados da própria mensagem e de um segredo compartilhado pelas duas partes, ou seja, uma chave de autenticação. A solução do problema deve estar integrada totalmente com a operação normal dos protocolos SNMPv1 e SNMPv2c. Isto significa que, além de a mensagem permanecer a mesma, o novo módulo de autenticação não deve alterar outros aspectos como o controle de acesso às informações de gerência ou a execução normal de cada tipo de operação SNMP. Um cliente SNMP (gerente) deve construir e enviar o seu pedido ao servidor (agente), usando a chave de autenticação correta. Devido ao fato de o protocolo UDP (ou outro protocolo de transporte que não seja confiável) não garantir a entrega dos pacotes, o cliente deve implementar estratégias para timeout e retransmissão das mensagens. Nessa situação, vale mais uma vez lembrar que a comunicação autenticada se dá então pelo procedimento que consiste em calcular o campo de autenticação para a mensagem que se quer enviar e enviar tal campo juntamente com a mensagem. Na recepção, é feito novamente o mesmo cálculo e a comparação entre os dois valores determina se a mensagem é autêntica. Para não alterar o formato das mensagens, o próprio campo comunidade (communityString) de SNMPv1 e SNMPv2c é usado para enviar as informações de autenticação entre as entidades participantes. A idéia básica das soluções aqui propostas é fazer com que o segredo compartilhado entre gerente e agente mude a cada solicitação SNMP. Esta mudança contínua permite evitar que o segredo, mesmo conhecido, não tenha maior utilidade já que sua validade cobre tão somente uma única transação SNMP. Para não alterar o formato da mensagem SNMP v1 ou v2c, o campo a ser usado para transporte da informação de autenticação é unicamente o campo comunidade (communityString), que passa a ter uma nova interpretação. Desta forma, toda a informação pertinente de autenticação será processada conforme descrito a seguir e será então inserida no campo communityString, mais especificamente na forma de uma sequência de bits. A informação de autenticação a ser gerada e inserida na mensagem deverá ser uma função da chave de autenticação definida, das características de controle de acesso desejadas e da própria mensagem. Mais especificamente, neste trabalho, as duas propostas de protocolo de autenticação para SNMP implementam um esquema onde ocorre uma transformação contínua das chaves de autenticação. O comprometimento de uma delas não coloca em perigo mensagens ou chaves que venham a ser geradas posteriormente. A RFC 1905 [9] sugere que cada nova

mensagem tenha um novo valor para o campo requestId, o mesmo pode ser dito aqui em relação à chave de autenticação a ser usada: ela deve mudar a cada mensagem, mesmo no caso de retransmissão. No processo de autenticação, as respostas utilizam a mesma chave de autenticação usada nas solicitações. Respostas sem correspondência com solicitações são descartadas. Ou seja, a autenticação é obrigatória para as respostas também. Estes mecanismos dependem da inicialização prévia de dados de autenticação nos elementos da rede, sendo este procedimento uma decisão de implementação e podendo ser usados quaisquer métodos, tanto automáticos (certificados, canais seguros), como manuais. Esta é a mesma posição do grupo de trabalho SNMPv3. A chave de autenticação proposta tem 128 bits. Este valor foi considerado suficiente para a aplicação de autenticação em questão, pois as operações de gerência de rede têm um tempo de vida normalmente curto. 2.1 Protocolo Auth-P Este protocolo cria uma chave de autenticação aleatória a cada mensagem. Esta chave é cifrada e enviada juntamente com a mensagem, através de um subcampo do communityString, denominado “informação de chave”. Na recepção, a chave é decifrada e a autenticação é testada. O “P” aqui indica que a chave passa pela rede juntamente com a mensagem. Para realizar o protocolo, uma função cifradora C chaveada deverá ser usada. Ela deverá consistir de um cifrador de blocos que terá o papel de cifrar sempre uma mensagem de tamanho 128 bits: a chave de autenticação. O tamanho de sua chave também será 128 bits. Em síntese, o procedimento auth-P pode ser descrito da seguinte maneira, conforme ilustra a Figura 1: 1. É inicializada uma mesma chave, chamada chave mestre de autenticação (Kmestre), em cada um dos elementos de rede que compartilharem esta chave. 2. Quando o gerente for enviar um request, uma chave de autenticação da transaçao (Ktransação) será gerada aleatoriamente e usada no cálculo do digest. 3. Ktransação será criptografada pela função C, chaveada por Kmestre, gerando sua cifração Kcipher; 4. Kcipher é inserida na mensagem a ser enviada, no subcampo “informação de chave” do campo communityString redefinido. 5. Na recepção, a chave Ktransação é recuperada pela transformação inversa de C utilizando Kmestre em Kcipher 6. A chave Ktransação obtida é usada no teste da autenticação. Cabe notar que não fará diferença se o protocolo de transporte abaixo do SNMP for não-confiável, pois cada solicitação espera uma resposta especificada pelo valor de requestId da mensagem. Logo, se uma

mensagem ou sua resposta se perderem, cabe ao gerente estabelecer estratégias de retransmissão para aquele determinado request, cuidando para que a nova operação empregue uma nova chave de autenticação aleatória. No caso de mensagens duplicadas, a que vale é a primeira a chegar corretamente autenticada. Como definido anteriormente, mensagens recebidas sem correspondência devem ser descartadas. 2.1 Protocolo Auth-N Este protocolo cria uma chave de autenticação pela aplicação de uma função de hash Hn várias vezes sobre uma chave inicial, chamada chave geradora (Kgeradora). A cada mensagem, o número (n) destas aplicações é decrementado pelo gerente e a mensagem carregará o n para o agente poder chegar na mesma chave. Na recepção, a mesma função de hash Hn é aplicada n vezes sobre a chave inicial para se chegar à mesma chave usada para autenticar a mensagem. O caracter “N” no nome Auth-N indica a dependência da chave com relação ao número de vezes n em que a função de hash deve ser aplicada. Este protocolo obedece às seguintes regras (Figura 2): 1. São inicializadas duas chaves idênticas no gerente e agente, K--matriz e Kgeradora. 2. Chama-se o intervalo 0  n  w de janela. O valor de n inicialmente é w. A cada nova transação, n decresce até chegar a 1. A constante alteração do valor de n é de responsabilidade do gerente e deve ser feita a cada mansagem enviada. 3. A chave de autenticação da transação corrente, Ktransação = Kauth n corresponderá à Kgeradora transformada n vezes por uma função de hash h (K), sendo n um inteiro maior que 0 e menor ou igual a w. Logo Kauth n= hn(Kgeradora). 4. Quando n chegar a 1, deve ser gerada uma nova chave Kgeradora, usando uma função H one-way e a chave Kmatriz previamente inicializada. Logo, Kgeradora nova = H(Kgeradora velha, Kmatriz). Note-se que para cada Kgeradora, a janela será completamente atravessada de w a 1. 5. O gerente só deve efetuar a transformação da chave após receber a resposta da mensagem com n = 1. O agente muda sua chave geradora quando receber a primeira mensagem da nova janela. Uma mensagem é considerada da nova janela quando seu valor for maior que w/2. 6. Assim que transformar sua chave geradora, o agente deve começar a usá-la imediantamente na própria mensagem que disparou a mudança. 7. A mensagem a ser transmitida, então, deverá carregar n para que o agente (que supostamente possui também Kmatriz e Kgeradora sincronizadas) transforme Kgeradora tantas vezes quanto necessário para chegar à mesma chave de autenticação usada no envio. 8. Com a chave da transação correta, o agente procede o teste de auteticação da mensagem recebida.

Supondo um protocolo de transporte não confiável, deve-se prever as exceções possíveis na transmissão destas mensagens. Duas situações são mais importantes: a perda de mensagem e a troca de ordem na travessia pela rede. Se uma mensagem de request não obtiver resposta, o timeout de espera do gerente vai expirar. Dependerá da implementação o que será feito se, durante o tempo de timeout, forem recebidas mensagens com mesmo RequestId, mas com autenticação falha. De qualquer forma, a sincronização das chaves geradoras não é perturbada. Deve-se observar que a retransmissão do request deverá usar uma nova chave. Se a mensagem com n=1 não obtiver resposta, uma exceção à regra é imposta: n deverá permanecer em 1 até que se receba a resposta para este request e a troca da chave do gerente possa ser efetuada. Para o manter o sincronismo de chaves, é necessário que o gerente nunca envie chaves da nova janela (depois da transformação H) enquanto não receber a resposta da mensagem autenticada com Kauth 1 da janela anterior. Quando a mensagem com Kauth 1 não receber resposta, a próxima mensagem deve ser autenticada com a mesma Kauth 1 até que uma resposta seja recebida. Esta é a única situação onde o gerente reutiliza a chave de autenticação. Em todos os outros casos, a chave deve ser constantemente mudada. Quanto ao agente, este responderá às mensagens reenviadas autenticadas com Kauth 1 tantas vezes quantas forem necessárias e fará sua transformação somente quando receber a primeira mensagem da nova janela, indicando que o gerente realizou sua troca da chave geradora. A mensagem será considerada de uma nova janela quando apresentar n > w/2. No percurso pela rede, mensagens enviadas podem sofrer troca de ordem ao chegar ao seu destino. Esta possibilidade só prejudicaria a operação do protocolo auth-N se a resposta da mensagem com n=1 trocar de ordem com uma anterior, caso em que uma mensagem corretamente autenticada poderia ser rejeitada pelo gerente. Se a resposta da mensagem com n=2 chegar depois da resposta de n=1, para o gerente, ela estará na nova janela e este tentará autenticá-la com a nova chave geradora, implicando em falha. A solução para este problema estaria unicamente no gerente. Uma cópia da chave geradora anterior sempre estaria disponível e, no caso da falha na autenticação de valores de n próximos de 1, essa cópia seria usada. Com esta abordagem, o agente não é onerado com mais procedimentos de controle.

2.3 Características dos Protocolos Propostos Os protocolos propostos e descritos aqui identificam a origem de uma mensagem como sendo um endereço de rede de uma entidade SNMP. Um endereço de rede, tal como entendido aqui, só poderá ser na realidade um único endereço efetivo de rede atribuído e alcançável. As chaves empregadas nos mecanismos autenticadores apresentados só fazem sentido quando usadas entre dois elementos distintos, um gerente e um agente. Em SNMPv1/v2c, estes são identificados por seus endereços de rede. Isto associa um endereço de rede a uma entidade SNMPv1/v2c agente ou gerente. Desta forma, uma entidade SNMP (agente ou gerente) deverá possuir uma tabela que armazenará chaves de autenticação para cada outra entidade SNMP com quem puder se comunicar. Esta tabela, de forma semelhante à tabela de usuários de uma entidade SNMPv3, conterá informações sobre as possibilidades de comunicação daquela entidade com outras entidades SNMPv1/v2c. Uma vantagem direta das abordagens usadas nos protocolos auth-P e auth-N é o fato de que não há necessidade de se esperar a resposta da mensagem anterior para poder disparar a próxima. Em operações SNMP como get-Next-Request, que normalmente são disparadas seguidamente, este aspecto de seqüenciação é importante. Outro detalhe é que, nem no protocolo auth-P nem no protocolo auth-N, é preciso que o agente armazene chaves anteriores à chave corrente. Conforme se sabe, é um requisito interessante que o agente necessite do mínimo de processamento e memória, de modo que o protocolo possa ser largamente adotado em todo tipo de equipamento. O mecanismo de autenticação auth-N exige que a comunicação entre agente e gerente seja do tipo de pedido/resposta, ou seja, uma mensagem do gerente deverá sempre esperar uma resposta. Dentro da arquitetura SNMP, a maior parte das operações são deste tipo. A exceção são as traps que são mensagens espôntaneas do agente. No caso de necessidade da autenticação de traps, esta só seria possível se for utilizado o protocolo auth-P, já que ele não depende de respostas para sincronizar as alterações dos segredos de autenticação. Para este esquema funcionar, basta que agente e gerente possuam a mesma chave mestre, como requer o protocolo auth-P. Por outro lado, o protocolo auth-P baseia-se numa única chave: a chave mestre. Se esta for descoberta pode-se gerar mensagens autenticadas quaisquer. Outra desvantagem deste protocolo é o fato da mensagem SNMP carregar a chave de autenticação usada (chave da transação). Mesmo criptografada, esta chave estará disponível para criptoanálise. E se uma criptoanálise tiver sucesso, a chave usada na cifração (chave mestre) ainda poderá ser descoberta. A passagem de chaves de autenticação cifradas pela rede oferece ao atacante várias amostras de cifração com a chave mestre. Auth-N, por sua vez, não apresenta essa característica. O que passa pela rede é somente um número com significado apenas para quem possui as

duas chaves usadas na autenticaçao: a chave matriz e a chave geradora. O que estará disponível para o atacante na rede será apenas o digest gerado pela chave da transação, chave esta que muda a cada mensagem. Tanto a chave matriz como a geradora não atravessam a rede e, portanto, suas características não estão disponíveis em qualquer informação carregada pela mensagem SNMP. Além disso, em Auth-N, a chave geradora muda a cada n = 1, evitando que a descoberta de uma chave geradora signifique perda da segurança. Isto é possível por que a nova chave geradora é alterada em função da chave matriz por uma função one-way, portanto sem retorno. Para um atacante, só seria possível acompanhar as alterações das chaves do protocolo se conseguisse ambas as chaves e observasse os valores de n para saber quando obter a nova chave geradora. Contudo, para auth-N funcionar sincronizadamente é necessário que a mensagem com n=1 receba sua resposta e, enquanto isso não acontecer, o gerente só deve usar n=1 nas mensagens posteriores. A mensagem de resposta com n=1 é a confirmação do agente para a mudança da atual chave geradora. É interessante notar que esta é uma preocupação somente do gerente já que o agente só mudará sua chave geradora quando receber valores de n da nova janela. Assim, colocando-se esta responsabilidade sobre o gerente, mantém-se a caraterística simples do agente SNMP. Desse modo, se o agente não responder à mensagem com n =1 apesar das retransmissões, considera-se que houve um problema com a rede, ou com o dispositivo gerenciado, ou ainda um ataque de negação de serviço. Por este motivo, é necessário limitar estas retransmissões no gerente. Um número máximo de 50 retransmissões parece razoável para operações de gerência de rede. Após atingido este limiar, é interrompida a comunicação com o elemento de rede em questão e considera-se uma nova inicialização ou intervenção manual, mas isto é uma característica particular de implementação. 2.3 Implementação dos Protocolos Propostos As propostas apresentadas acima foram implementadas, para averiguação das condições dos protocolos e obtenção de dados para uma análise da utilidade e operacionalidade destes métodos de autenticação dentro do protocolo SNMP. O protocolo auth-N exige uma função de hash h para poder gerar a chave de autenticação específica da mensagem em operação. A escolha do MD5 neste trabalho levou em conta o nível de segurança aceitável do algoritmo contra ataques de força bruta e sua facilidade de implementação em máquinas de 32 bits (PC Pentium), além da disponibilidade de código já pronto na Internet. Tanto auth-P como auth-N precisam de uma função criptográfica que gere o digest da mensagem, em função da mensagem e de uma chave. Como SNMP opta sempre pela simplicidade e os agentes a serem implementados devem ser facilmente desenvolvidos, constitui-se uma boa escolha utilizar um método que

utiliza o mesmo algoritmo usado na função h. Assim, MD5, com o método de chaveamento HMAC, foi a escolha para a função de hash a ser usada em H. Para o protocolo auth-P, um cifrador de blocos chaveado é necessário para fazer a cifração da chave de autenticação a ser usada na mensagem. O algoritmo Blowfish [10] escolhido é um cifrador de blocos de 64 bits desenvolvido por Bruce Schneier em 1993, não é patenteado e é livre para utilização. No que diz respeito ao ambiente de desenvolvimento, foi utilizado um sistema Linux Red Hat 5.1 para microcomputar PC. Os testes foram feitos numa rede local composta de 3 máquinas semelhantes. A linguagem C++ foi escolhida para o desenvolvimento e a interface de protocolo de rede foi a biblioteca sockets que acompanha o sistema Linux usado. Para a implementação, partiu-se de um pacote de software CMU versão 3.5, contendo código-fonte em linguagem C de um agente SNMPv1/v2c acompanhado de algumas pequenas aplicações SNMP. Este código-fonte foi alterado para a linguagem C++, resultando em um agente SNMPv1/v2c e algumas pequenas aplicações SNMP, todos integrando os protocolos auth-P e auth-N aqui propostos. O procedimento de teste das implementações preocupou-se em checar os itens críticos da execução de ambos os protocolos, apontados no item anterior. Verificou-se que em ambiente de laboratório os protocolos funcionam conforme previsto nas especificações iniciais. 3. CONCLUSÃO Tanto o modelo de segurança baseado em usuário de SNMPv3, como as propostas deste trabalho, dependem da prévia inicialização de chaves nos elementos da rede sendo gerenciados. O modo de realizar tal operação é deixado a cargo do fabricante e dos administradores de redes, podendo ser usados certificados, canais seguros, algoritmos assimétricos, ou até mesmo procedimentos manuais, da maneira mais conveniente na inicialização dos segredos. Este trabalho procurou mostrar que ainda é possível implementar autenticação segura nas versões v1 e v2c do protocolo SNMP. Mais ainda, foram propostos e implementados dois protocolos de autenticação, aproveitando elementos que existem e são empregados atualmente nos protocolos SNMPv1 e SNMPv2c, não interferindo de maneira nenhuma nos outros aspectos operacionais do SNMP, tais como o processamento da mensagem ou o controle de acesso. O formato da mensagem SNMP não foi alterado nas propostas. As implementações demostraram a robustez dos serviços de autenticação dos protocolos auth-P e authN. O preço pago pelo melhor serviço traduziu-se basicamente em pequeno atraso no processamento de uma mensagem, já que o tamanho das implementações não aumentou de forma a inviabilizar a sua utilização. O agente SNMPv1/v2c básico foi pouco onerado, atendendo assim a uma das premissas do trabalho. 4. BIBLIOGRAFIA

[1] IETF, RFC 1157 - Simple Network Management Protocol (SNMP), (Status: standard), 1990. [2] IETF, RFC 1351 - SNMP Administrative Model, (Status: proposed standard), 1992. [3] IETF, RFC 2026 - The Internet Standards Process - Revision 3, 1996. [4] IETF, draft - The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3), 1999. [5] IETF, RFC 1909 - An Administrative Infrastructure for SNMPv2, (Status: experimental), 1996. [6] IETF, RFC 1321 - The MD5 Message-Digest Algorithm, (Status: informational), 1992. [7] NIST, FIPS Publication 180-1 – Secure Hash Algorithm, 1995. [8] IETF, RFC 2104 – HMAC: Keyed-Hashing for Message Authentication, (Status: informational), 1997. [9] IETF, RFC 1905 - Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2), (Status: draft standard), 1996. [10] SCHNEIER, Bruce. The Blowfish Encryption Algorithm, 1998. http://www.counterpane.com/ blowfish.html.

Gerador Aleatório

Gerente SNMP

Kmestre

Ktransação C Kcipher

Geração do digest

Agente SNMP comunidade
Kcipher

digest (Ktransação)

Kmestre C Ktransação

Teste da Autenicação

Figura 1: Protocolo Auth-P

Gerente SNMP

Kgeradora hn Ktransação
Geração do digest

Agente SNMP comunidade
n

digest (Ktransação)

Kgeradora hn Ktransação

Teste da Autenicação

Figura 2: Protocolo Auth-N

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.