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 - UnBCaixa 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 noprotocolo SNMP, provendo um mecanismo básicode segurança para sua versão 1 e mantendoflexibilidade suficiente para permitir uma integraçãoao modelo de segurança das novas versões doprotocolo. Tais propostas têm base na utilização desenhas descartáveis na autenticação das mensagensSNMP, com os necessários protocolos criptográficospara geração e troca de chaves de criptografia entreas entidades usuárias do protocolo.

1. INTRODUÇÃO

O protocolo de gerência de redes mais usadoatualmente é o SNMP (Simple Network ManagementProtocol). Juntamente com outros padrõesrelacionados, SNMP oferece um denominador comumna construção de arquiteturas de gerência de redesdistribuídas.

Como está hoje, o SNMP ainda não responde arequisitos importantes de segurança. A efetivagerência de redes demanda tanto facilidades demonitoração, como de controle dos diversoscomponentes das redes. SNMP é usado basicamentepara monitoração, devido aos seus mecanismos fracosde segurança que inibem a execução de ações àdistância, necessárias às diversas tarefas de controledas redes. Em conseqüência, as operações deconfiguração possíveis via SNMP são subutilizadaspor causa da desconfiança dos operadores e gerentesde redes com relação à segurança do processo.

Contudo, o projeto inicial de SNMP previra anecessidade de atualizações. A forma modular comofoi definido o protocolo visou facilitar futurasmodificações para as soluções das falhas, mantendo afilosofia da simplicidade do protocolo.

O problema-chave na versão mais utilizada(SNMPv1) do protocolo é o emprego de ummecanismo de segurança trivial que visava oferecerautenticação para as mensagens e controle básico deautorizações de acesso para operações sobre objetosgerenciados [1]. De fato, o mecanismo de autenticaçãoem SNMPv1 consiste em preencher o campocomunidade (communityString) das mensagens doprotocolo com uma senha não criptografada evirtualmente imutável. Com freqüência, na prática dagerência de redes, é usado o termo public como nomede comunidade. Tal senha pode ser obtida por simplesanálise do tráfego, permitindo a um atacante ter acessoaos elementos gerenciados para executar operações degerência de rede. Assim, o acesso não-autorizado pode

possibilitar a um atacante, não somente descobrirparâmetros críticos dos sistemas e da rede, comotambém alterá-los e prejudicar os serviços que delesdependem.

A segunda versão do protocolo [2], denominadaSNMPv2 clássica ou SNMPv2p, tenta solucionar oproblema da segurança, apresentando um modelo desegurança que integra autenticação e criptografia aoprotocolo, para protegê-lo de ameaças comointerrupção, interceptação, modificação emascaramento de informações. Isso permitiria quetroca de mensagens SNMP fosse ou totalmente aberta,ou autenticada mas não privada, ou privada mas nãoautenticada, ou ainda autenticada e simultaneamenteprivada. O novo conceito de party era muitoimportante nesta proposta. Uma party é definida comoum contexto de execução virtual nas entidades SNMP,onde a operação do protocolo restringe-se a umsubconjunto de possíveis operações. A estrutura daparty substituía as comunidades da versão 1,acrescentando informações de tempo (clocks), chavesde criptografia e políticas de acesso às entidadesSNMP.

Foi difícil a aceitação deste novo protocoloprincipalmente por causa de sua incompatibilidadecom a versão 1, já que as novas mensagenscriptografadas não eram compreendidas pelasentidades SNMPv1. E, além de ter problemas deoverhead nas mensagens, o modelo administrativobaseado em parties implica numa pré-configuraçãodestas parties, o que pode se tornar um processoexcessivamente complexo, já que aspectos comoprotocolos de transporte, clocks, chaves para osalgoritmos de segurança e direitos de acesso devemser previamente definidos na etapa de configuraçãodas entidades do protocolo, ou seja, os agentes degerência e gerentes de rede.

Em conseqüência, foram empreendidos novosesforços de revisão do protocolo em resposta à baixaaceitação da versão SNMPv2 clássica. Tal revisão sedeu principalmente no que diz respeito ao contextobaseado em parties, à configuração dos agentesSNMP, à dificuldade de mapeamento da rede e àimplementação do modelo administrativo e desegurança. Decidiu-se voltar o contexto de operaçãodo protocolo à antiga forma de comunidades, sem omodelo de segurança proposto em SNMPv2 clássico,e, consequentemente, voltando ao antigo formato dasmensagens. Assim, foi apresentada mais uma versãoSNMP, chamada de SNMPv2c, baseada emcomunidades, o que recolocou o problema desegurança original.

A partir daí, dentre as tentativas de definição domodelo administrativo e de segurança, duas linhas dedesenvolvimento se destacaram: a SNMP USEC(User-based Security Model) e a SNMPv2* (SNMPv2“star”). Estas duas propostas, que representaramcaminhos independentes percorridos por integrantesdas equipes originadoras do protocolo, terminaram porconvergir nos trabalhos de definição da versão 3 doprotocolo, denominada SNMPv3, cujos trabalhosainda estão sendo concluídos com a elaboração dedocumentos que serão submetidos ao processo dapadronização definitiva [3]. Alguns detalhes da novaproposta ainda estão em discussão, e, até o momentoda redação deste artigo, as especificações geradasainda não possuíam status de padronização completa.

Na proposta SNMPv3, existe, até o momento daredação deste trabalho, um único modelo de segurançasendo adotado. Ele se chama USM - User-BasedSecurity Model [4] e sua implementação é obrigatóriaem todas as entidades SNMPv3. O modelo desegurança USM identifica as ameaças levadas emconsideração na operação do protocolo SNMP edefine as proteções a serem usadas e as regras que otornarão operacional dentro da arquitetura propostapara SNMPv3.

USM é basicamente derivado do modelo SNMPUSEC de segurança baseado em usuário [5], comalgumas alterações. Nele, existe um conceito deusuário ao qual estão associadas informações desegurança usadas em um ambiente de gerência SNMP.

A definição de SNMPv3 reconhece que é um erroquerer definir um único modelo de segurançadefinitivo e imutável, pois, com o tempo, novosrequisitos de segurança aparecerão e outros podemcair em desuso. Assim, admite-se que SNMP poderásuportar vários modelos de segurança, sendo porémobrigatória a implementação do USM para garantircompatibilidade com o modelo inicial de SNMPv3

As principais ameaças levadas em consideração nadefinição de SNMPv3 são a modificação dainformação gerada por um usuário válido e omascaramento de um usuário, efetivado pelo uso deuma identificação falsa por parte de uma entidade nãoautorizada. Também foram consideradas, ainda comosecundárias, as seguintes ameaças de replay, ou sejareordenamento e atraso das mensagens de formaestranha à operação normal da rede, e falta deprivacidade nas trocas de mensagens entre entidadesSNMP.

Estas ameaças são evitadas com a utilização decriptografia e de uma política de acesso àsinformações, o que subentende a utilização dealgoritmos criptográficos e de chaves de criptografia.

Os serviços de segurança para defesa contra asameaças consideradas acima são: integridade dosdados da mensagem, autenticação da origem dasmensagens, confidencialidade dos dados dasmensagens e proteção temporizada contra replays.Todos eles são serviços comuns de segurança nasmensagens do protocolo.

Cabe notar que o serviço de autenticação da origemdos dados proposto só pode garantir que se saiba qualusuário dentro do modelo USM está enviando a

mensagem. Assim, qualquer um, de posse dasinformações daquele usuário, pode agir sob seu nome.

Por outro lado, o modelo USM oferece capacidadede autenticação e confidencialidade da comunicação.Como não é possível oferecer confidencialidade semter autenticação da origem e garantia da integridadedos dados, existem 3 níveis de segurança possíveisdentro do modelo:

1. Comunicação sem autenticação ouconfidencialidade (nível de segurançadenominado noAuthNoPriv);

2. Comunicação com autenticação, mas semconfidencialidade (denominado authNoPriv);

3. Comunicação com autenticação econfidencialidade (denominado authPriv).

Dentre os campos componentes dos dados globaisda 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çadescritos acima, são definidos 3 módulos dentro domodelo de segurança: módulo de autenticação (quelida com a integridade dos dados e autenticação daorigem), módulo de temporização (que lida comatrasos e replays de mensagens) e módulo deconfidencialidade (que lida com a privacidade damensagem).

Visando a implementação desses módulos, épreconizada a utilização de protocolos criptográficosde autenticação, de integridade dos dados eautenticação da origem, com base nos algoritmosMD5 [6] e SHA-1 [7], além do método HMAC(Keyed-Hashing for Message Authentication) [8].

Diante dessa evolução, e considerando que, apesardo desenvolvimento já avançado, o trabalho emSNMPv3 ainda não está concluído e algumas questõesainda estão em aberto, o trabalho apresentado nesteartigo procura desenvolver alternativas de mecanismosde autenticação para SNMP compatíveis com asversões anteriores do protocolo, ainda largamenteutilizadas e bastante eficazes. Nesse sentido, aspropostas descritas nesta artigo visam apresentar ummecanismo autenticador de mensagens SNMP para asversões v1 e v2c do protocolo, mecanismo este capazde substituir o esquema trivial de autenticação dessasversões. Por outro lado, foi também preocupação nodesenvolvimento manter coerência com os trabalhosem SNMPv3, de forma a tornar possível a utilizaçãodas propostas aqui descritas dentro da arquitetura daversão 3.

Assim, são apresentados a seguir dois protocolos deautenticação, denominados auth-N e auth-P, amboscom base no emprego de chaves de autenticação quemudam constantemente, reduzindo o risco da quebrade qualquer uma das chaves a um comprometimentode somente uma mensagem SNMP e isso apenas nomomento em que tal mensagem está sendo trocadaentre duas entidades de gerência de rede.

2. PROTOCOLOS DE AUTENTICAÇÃO PROPOSTOS

Os protocolos de autenticação aqui propostos sepreocupam basicamente com as ameaças demodificação da informação e mascaramento. Paraoferecer proteção contra estes ataques, é enviadajuntamente com a mensagem, a informação deautenticação. Esta informação será usada pelo receptorno processo de verificação da autenticidade damensagem, implicando na necessidade de um métodode geração desta informação, em função pelo menosdos dados da própria mensagem e de um segredocompartilhado pelas duas partes, ou seja, uma chavede autenticação.

A solução do problema deve estar integradatotalmente com a operação normal dos protocolosSNMPv1 e SNMPv2c. Isto significa que, além de amensagem permanecer a mesma, o novo módulo deautenticação não deve alterar outros aspectos como ocontrole de acesso às informações de gerência ou aexecução normal de cada tipo de operação SNMP.

Um cliente SNMP (gerente) deve construir e enviaro seu pedido ao servidor (agente), usando a chave deautenticação correta. Devido ao fato de o protocoloUDP (ou outro protocolo de transporte que não sejaconfiável) não garantir a entrega dos pacotes, o clientedeve implementar estratégias para timeout eretransmissão das mensagens. Nessa situação, valemais uma vez lembrar que a comunicação autenticadase dá então pelo procedimento que consiste emcalcular o campo de autenticação para a mensagemque se quer enviar e enviar tal campo juntamente coma mensagem. Na recepção, é feito novamente o mesmocálculo e a comparação entre os dois valoresdetermina se a mensagem é autêntica. Para não alteraro formato das mensagens, o próprio campocomunidade (communityString) de SNMPv1 eSNMPv2c é usado para enviar as informações deautenticação entre as entidades participantes.

A idéia básica das soluções aqui propostas é fazercom que o segredo compartilhado entre gerente eagente mude a cada solicitação SNMP. Esta mudançacontínua permite evitar que o segredo, mesmoconhecido, não tenha maior utilidade já que suavalidade cobre tão somente uma única transaçãoSNMP.

Para não alterar o formato da mensagem SNMP v1ou v2c, o campo a ser usado para transporte dainformação de autenticação é unicamente o campocomunidade (communityString), que passa a ter umanova interpretação. Desta forma, toda a informaçãopertinente de autenticação será processada conformedescrito a seguir e será então inserida no campocommunityString, mais especificamente na forma deuma sequência de bits.

A informação de autenticação a ser gerada einserida na mensagem deverá ser uma função da chavede autenticação definida, das características decontrole de acesso desejadas e da própria mensagem.

Mais especificamente, neste trabalho, as duaspropostas de protocolo de autenticação para SNMPimplementam um esquema onde ocorre umatransformação contínua das chaves de autenticação. Ocomprometimento de uma delas não coloca em perigomensagens ou chaves que venham a ser geradasposteriormente. A RFC 1905 [9] sugere que cada nova

mensagem tenha um novo valor para o camporequestId, o mesmo pode ser dito aqui em relação àchave de autenticação a ser usada: ela deve mudar acada mensagem, mesmo no caso de retransmissão.

No processo de autenticação, as respostas utilizam amesma chave de autenticação usada nas solicitações.Respostas sem correspondência com solicitações sãodescartadas. Ou seja, a autenticação é obrigatória paraas respostas também.

Estes mecanismos dependem da inicialização préviade dados de autenticação nos elementos da rede, sendoeste procedimento uma decisão de implementação epodendo ser usados quaisquer métodos, tantoautomáticos (certificados, canais seguros), comomanuais. Esta é a mesma posição do grupo de trabalhoSNMPv3.

A chave de autenticação proposta tem 128 bits. Estevalor foi considerado suficiente para a aplicação deautenticação em questão, pois as operações degerência de rede têm um tempo de vida normalmentecurto.

2.1 Protocolo Auth-P

Este protocolo cria uma chave de autenticaçãoaleatória a cada mensagem. Esta chave é cifrada eenviada juntamente com a mensagem, através de umsubcampo 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 redejuntamente com a mensagem.

Para realizar o protocolo, uma função cifradora Cchaveada deverá ser usada. Ela deverá consistir de umcifrador de blocos que terá o papel de cifrar sempreuma mensagem de tamanho 128 bits: a chave deautenticação. O tamanho de sua chave também será128 bits.

Em síntese, o procedimento auth-P pode ser descritoda seguinte maneira, conforme ilustra a Figura 1:

1. É inicializada uma mesma chave, chamada chavemestre de autenticação (Kmestre), em cada umdos elementos de rede que compartilharem estachave.

2. Quando o gerente for enviar um request, umachave de autenticação da transaçao (Ktransação)será gerada aleatoriamente e usada no cálculo dodigest.

3. Ktransação será criptografada pela função C,chaveada por Kmestre, gerando sua cifraçãoKcipher;

4. Kcipher é inserida na mensagem a ser enviada,no subcampo “informação de chave” do campocommunityString redefinido.

5. Na recepção, a chave Ktransação é recuperadapela transformação inversa de C utilizandoKmestre em Kcipher

6. A chave Ktransação obtida é usada no teste daautenticação.

Cabe notar que não fará diferença se o protocolo detransporte abaixo do SNMP for não-confiável, poiscada solicitação espera uma resposta especificada pelovalor de requestId da mensagem. Logo, se uma

mensagem ou sua resposta se perderem, cabe aogerente estabelecer estratégias de retransmissão paraaquele determinado request, cuidando para que a novaoperação empregue uma nova chave de autenticaçãoaleatória.

No caso de mensagens duplicadas, a que vale é aprimeira a chegar corretamente autenticada. Comodefinido anteriormente, mensagens recebidas semcorrespondência devem ser descartadas.

2.1 Protocolo Auth-N

Este protocolo cria uma chave de autenticação pelaaplicação de uma função de hash Hn várias vezessobre uma chave inicial, chamada chave geradora(Kgeradora). A cada mensagem, o número (n) destasaplicações é decrementado pelo gerente e a mensagemcarregará o n para o agente poder chegar na mesmachave. 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. Ocaracter “N” no nome Auth-N indica a dependência dachave com relação ao número de vezes n em que afunção de hash deve ser aplicada. Este protocoloobedece às seguintes regras (Figura 2):

1. São inicializadas duas chaves idênticas nogerente e agente, K--matriz e Kgeradora.

2. Chama-se o intervalo wn 0 de janela. Ovalor de n inicialmente é w. A cada novatransação, n decresce até chegar a 1. A constantealteração do valor de n é de responsabilidade dogerente e deve ser feita a cada mansagemenviada.

3. A chave de autenticação da transação corrente,Ktransação = Kauth n corresponderá à Kgeradoratransformada n vezes por uma função de hash h(K), sendo n um inteiro maior que 0 e menor ouigual a w. Logo Kauth n= hn(Kgeradora).

4. Quando n chegar a 1, deve ser gerada uma novachave Kgeradora, usando uma função H one-waye a chave Kmatriz previamente inicializada.Logo, Kgeradora nova = H(Kgeradora velha,Kmatriz). Note-se que para cada Kgeradora, ajanela será completamente atravessada de w a 1.

5. O gerente só deve efetuar a transformação dachave após receber a resposta da mensagem comn = 1. O agente muda sua chave geradora quandoreceber a primeira mensagem da nova janela.Uma mensagem é considerada da nova janelaquando seu valor for maior que w/2.

6. Assim que transformar sua chave geradora, oagente deve começar a usá-la imediantamente naprópria mensagem que disparou a mudança.

7. A mensagem a ser transmitida, então, deverácarregar n para que o agente (que supostamentepossui também Kmatriz e Kgeradorasincronizadas) transforme Kgeradora tantas vezesquanto necessário para chegar à mesma chave deautenticação usada no envio.

8. Com a chave da transação correta, o agenteprocede o teste de auteticação da mensagemrecebida.

Supondo um protocolo de transporte não confiável,deve-se prever as exceções possíveis na transmissãodestas mensagens. Duas situações são maisimportantes: a perda de mensagem e a troca de ordemna 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 tempode timeout, forem recebidas mensagens com mesmoRequestId, mas com autenticação falha. De qualquerforma, a sincronização das chaves geradoras não éperturbada. Deve-se observar que a retransmissão dorequest deverá usar uma nova chave.

Se a mensagem com n=1 não obtiver resposta, umaexceção à regra é imposta: n deverá permanecer em 1até que se receba a resposta para este request e a trocada chave do gerente possa ser efetuada.

Para o manter o sincronismo de chaves, é necessárioque o gerente nunca envie chaves da nova janela(depois da transformação H) enquanto não receber aresposta da mensagem autenticada com Kauth 1 dajanela anterior. Quando a mensagem com Kauth 1 nãoreceber resposta, a próxima mensagem deve serautenticada com a mesma Kauth 1 até que umaresposta seja recebida. Esta é a única situação onde ogerente reutiliza a chave de autenticação. Em todos osoutros casos, a chave deve ser constantementemudada.

Quanto ao agente, este responderá às mensagensreenviadas autenticadas com Kauth 1 tantas vezesquantas forem necessárias e fará sua transformaçãosomente quando receber a primeira mensagem da novajanela, indicando que o gerente realizou sua troca dachave geradora. A mensagem será considerada de umanova janela quando apresentar n > w/2.

No percurso pela rede, mensagens enviadas podemsofrer troca de ordem ao chegar ao seu destino. Estapossibilidade só prejudicaria a operação do protocoloauth-N se a resposta da mensagem com n=1 trocar deordem com uma anterior, caso em que uma mensagemcorretamente autenticada poderia ser rejeitada pelogerente.

Se a resposta da mensagem com n=2 chegar depoisda resposta de n=1, para o gerente, ela estará na novajanela e este tentará autenticá-la com a nova chavegeradora, implicando em falha.

A solução para este problema estaria unicamente nogerente. Uma cópia da chave geradora anterior sempreestaria disponível e, no caso da falha na autenticaçãode valores de n próximos de 1, essa cópia seria usada.Com esta abordagem, o agente não é onerado commais procedimentos de controle.

2.3 Características dos Protocolos Propostos

Os protocolos propostos e descritos aquiidentificam a origem de uma mensagem como sendoum endereço de rede de uma entidade SNMP. Umendereço de rede, tal como entendido aqui, só poderáser na realidade um único endereço efetivo de redeatribuído e alcançável.

As chaves empregadas nos mecanismosautenticadores apresentados só fazem sentido quandousadas entre dois elementos distintos, um gerente e umagente. Em SNMPv1/v2c, estes são identificados porseus endereços de rede. Isto associa um endereço derede a uma entidade SNMPv1/v2c agente ou gerente.Desta forma, uma entidade SNMP (agente ou gerente)deverá possuir uma tabela que armazenará chaves deautenticação para cada outra entidade SNMP comquem puder se comunicar. Esta tabela, de formasemelhante à tabela de usuários de uma entidadeSNMPv3, conterá informações sobre as possibilidadesde comunicação daquela entidade com outrasentidades SNMPv1/v2c.

Uma vantagem direta das abordagens usadas nosprotocolos auth-P e auth-N é o fato de que não hánecessidade de se esperar a resposta da mensagemanterior para poder disparar a próxima. Em operaçõesSNMP como get-Next-Request, que normalmente sãodisparadas seguidamente, este aspecto deseqüenciação é importante. Outro detalhe é que, nemno protocolo auth-P nem no protocolo auth-N, épreciso que o agente armazene chaves anteriores àchave corrente. Conforme se sabe, é um requisitointeressante que o agente necessite do mínimo deprocessamento e memória, de modo que o protocolopossa ser largamente adotado em todo tipo deequipamento.

O mecanismo de autenticação auth-N exige que acomunicação entre agente e gerente seja do tipo depedido/resposta, ou seja, uma mensagem do gerentedeverá sempre esperar uma resposta. Dentro daarquitetura SNMP, a maior parte das operações sãodeste tipo. A exceção são as traps que são mensagensespôntaneas do agente. No caso de necessidade daautenticação de traps, esta só seria possível se forutilizado o protocolo auth-P, já que ele não dependede respostas para sincronizar as alterações dossegredos de autenticação. Para este esquemafuncionar, basta que agente e gerente possuam amesma 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 descobertapode-se gerar mensagens autenticadas quaisquer.Outra desvantagem deste protocolo é o fato damensagem SNMP carregar a chave de autenticaçãousada (chave da transação). Mesmo criptografada, estachave estará disponível para criptoanálise. E se umacriptoanálise tiver sucesso, a chave usada na cifração(chave mestre) ainda poderá ser descoberta. Apassagem de chaves de autenticação cifradas pela redeoferece ao atacante várias amostras de cifração com achave mestre.

Auth-N, por sua vez, não apresenta essacaracterística. O que passa pela rede é somente umnúmero com significado apenas para quem possui as

duas chaves usadas na autenticaçao: a chave matriz e achave geradora. O que estará disponível para oatacante na rede será apenas o digest gerado pelachave da transação, chave esta que muda a cadamensagem. Tanto a chave matriz como a geradora nãoatravessam a rede e, portanto, suas características nãoestão disponíveis em qualquer informação carregadapela mensagem SNMP.

Além disso, em Auth-N, a chave geradora muda acada n = 1, evitando que a descoberta de uma chavegeradora signifique perda da segurança. Isto é possívelpor que a nova chave geradora é alterada em função dachave matriz por uma função one-way, portanto semretorno. Para um atacante, só seria possívelacompanhar as alterações das chaves do protocolo seconseguisse ambas as chaves e observasse os valoresde n para saber quando obter a nova chave geradora.Contudo, para auth-N funcionar sincronizadamente énecessário que a mensagem com n=1 receba suaresposta e, enquanto isso não acontecer, o gerente sódeve usar n=1 nas mensagens posteriores. Amensagem de resposta com n=1 é a confirmação doagente para a mudança da atual chave geradora. Éinteressante notar que esta é uma preocupaçãosomente do gerente já que o agente só mudará suachave geradora quando receber valores de n da novajanela. Assim, colocando-se esta responsabilidadesobre o gerente, mantém-se a caraterística simples doagente SNMP.

Desse modo, se o agente não responder à mensagemcom n =1 apesar das retransmissões, considera-se quehouve um problema com a rede, ou com o dispositivogerenciado, ou ainda um ataque de negação de serviço.Por este motivo, é necessário limitar estasretransmissões no gerente. Um número máximo de 50retransmissões parece razoável para operações degerência de rede. Após atingido este limiar, éinterrompida a comunicação com o elemento de redeem questão e considera-se uma nova inicialização ouintervenção manual, mas isto é uma característicaparticular de implementação.

2.3 Implementação dos Protocolos Propostos

As propostas apresentadas acima foramimplementadas, para averiguação das condições dosprotocolos e obtenção de dados para uma análise dautilidade e operacionalidade destes métodos deautenticação dentro do protocolo SNMP.

O protocolo auth-N exige uma função de hash hpara poder gerar a chave de autenticação específica damensagem em operação. A escolha do MD5 nestetrabalho levou em conta o nível de segurança aceitáveldo algoritmo contra ataques de força bruta e suafacilidade 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çãocriptográfica que gere o digest da mensagem, emfunção da mensagem e de uma chave. Como SNMPopta sempre pela simplicidade e os agentes a seremimplementados 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 aescolha para a função de hash a ser usada em H.

Para o protocolo auth-P, um cifrador de blocoschaveado é necessário para fazer a cifração da chavede autenticação a ser usada na mensagem. O algoritmoBlowfish [10] escolhido é um cifrador de blocos de 64bits desenvolvido por Bruce Schneier em 1993, não épatenteado e é livre para utilização.

No que diz respeito ao ambiente dedesenvolvimento, foi utilizado um sistema Linux RedHat 5.1 para microcomputar PC. Os testes foram feitosnuma rede local composta de 3 máquinas semelhantes.A linguagem C++ foi escolhida para odesenvolvimento e a interface de protocolo de rede foia biblioteca sockets que acompanha o sistema Linuxusado. Para a implementação, partiu-se de um pacotede software CMU versão 3.5, contendo código-fonteem linguagem C de um agente SNMPv1/v2cacompanhado de algumas pequenas aplicações SNMP.Este código-fonte foi alterado para a linguagem C++,resultando em um agente SNMPv1/v2c e algumaspequenas aplicações SNMP, todos integrando osprotocolos auth-P e auth-N aqui propostos.

O procedimento de teste das implementaçõespreocupou-se em checar os itens críticos da execuçãode ambos os protocolos, apontados no item anterior.Verificou-se que em ambiente de laboratório osprotocolos funcionam conforme previsto nasespecificações iniciais.

3. CONCLUSÃO

Tanto o modelo de segurança baseado em usuáriode SNMPv3, como as propostas deste trabalho,dependem da prévia inicialização de chaves noselementos da rede sendo gerenciados. O modo derealizar tal operação é deixado a cargo do fabricante edos administradores de redes, podendo ser usadoscertificados, canais seguros, algoritmos assimétricos,ou até mesmo procedimentos manuais, da maneiramais conveniente na inicialização dos segredos.

Este trabalho procurou mostrar que ainda é possívelimplementar autenticação segura nas versões v1 e v2cdo protocolo SNMP. Mais ainda, foram propostos eimplementados dois protocolos de autenticação,aproveitando elementos que existem e são empregadosatualmente nos protocolos SNMPv1 e SNMPv2c, nãointerferindo de maneira nenhuma nos outros aspectosoperacionais do SNMP, tais como o processamento damensagem ou o controle de acesso. O formato damensagem SNMP não foi alterado nas propostas.

As implementações demostraram a robustez dosserviços de autenticação dos protocolos auth-P e auth-N. O preço pago pelo melhor serviço traduziu-sebasicamente em pequeno atraso no processamento deuma mensagem, já que o tamanho das implementaçõesnã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 ManagementProtocol (SNMP), (Status: standard), 1990.

[2] IETF, RFC 1351 - SNMP Administrative Model,(Status: proposed standard), 1992.

[3] IETF, RFC 2026 - The Internet StandardsProcess - Revision 3, 1996.

[4] IETF, draft - The User-Based Security Model forVersion 3 of the Simple Network ManagementProtocol (SNMPv3), 1999.

[5] IETF, RFC 1909 - An AdministrativeInfrastructure for SNMPv2, (Status:experimental), 1996.

[6] IETF, RFC 1321 - The MD5 Message-DigestAlgorithm, (Status: informational), 1992.

[7] NIST, FIPS Publication 180-1 – Secure HashAlgorithm, 1995.

[8] IETF, RFC 2104 – HMAC: Keyed-Hashing forMessage Authentication, (Status: informational),1997.

[9] IETF, RFC 1905 - Protocol Operations forVersion 2 of the Simple Network ManagementProtocol (SNMPv2), (Status: draft standard),1996.

[10] SCHNEIER, Bruce. The Blowfish EncryptionAlgorithm, 1998. http://www.counterpane.com/blowfish.html.

Gerente SNMP

Agente SNMP

Ktransação

Kcipher

Kmestre

Kmestre

GeradorAleatório

C

Kcipher digest (Ktransação)comunidade

C

Ktransação

Teste daAutenicação

Geração dodigest

Figura 1: Protocolo Auth-P

Gerente SNMP

Agente SNMP

Kgeradora

Ktransação

hn

n digest (Ktransação)comunidade

Teste daAutenicação

Geração dodigest

Kgeradora

Ktransação

hn

Figura 2: Protocolo Auth-N