Propostas de Autenticação para SNMP

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

A partir daí, dentre as tentativas de definição do mensagem. Assim, qualquer um, de posse das
modelo administrativo e de segurança, duas linhas de informações daquele usuário, pode agir sob seu nome.
desenvolvimento se destacaram: a SNMP USEC Por outro lado, o modelo USM oferece capacidade
(User-based Security Model) e a SNMPv2* (SNMPv2 de autenticação e confidencialidade da comunicação.
“star”). Estas duas propostas, que representaram Como não é possível oferecer confidencialidade sem
caminhos independentes percorridos por integrantes ter autenticação da origem e garantia da integridade
das equipes originadoras do protocolo, terminaram por dos dados, existem 3 níveis de segurança possíveis
convergir nos trabalhos de definição da versão 3 do dentro do modelo:
protocolo, denominada SNMPv3, cujos trabalhos 1. Comunicação sem autenticação ou
ainda estão sendo concluídos com a elaboração de confidencialidade (nível de segurança
documentos que serão submetidos ao processo da denominado noAuthNoPriv);
padronização definitiva [3]. Alguns detalhes da nova 2. Comunicação com autenticação, mas sem
proposta ainda estão em discussão, e, até o momento confidencialidade (denominado authNoPriv);
da redação deste artigo, as especificações geradas 3. Comunicação com autenticação e
ainda não possuíam status de padronização completa. confidencialidade (denominado authPriv).
Na proposta SNMPv3, existe, até o momento da Dentre os campos componentes dos dados globais
redação deste trabalho, um único modelo de segurança da mensagem SNMPv3, está a informação de qual será
sendo adotado. Ele se chama USM - User-Based o nível de segurança que deverá ser aplicado à
Security Model [4] e sua implementação é obrigatória mensagem.
em todas as entidades SNMPv3. O modelo de Para implementar os mecanismos de segurança
segurança USM identifica as ameaças levadas em descritos acima, são definidos 3 módulos dentro do
consideração na operação do protocolo SNMP e modelo de segurança: módulo de autenticação (que
define as proteções a serem usadas e as regras que o lida com a integridade dos dados e autenticação da
tornarão operacional dentro da arquitetura proposta origem), módulo de temporização (que lida com
para SNMPv3. atrasos e replays de mensagens) e módulo de
USM é basicamente derivado do modelo SNMP confidencialidade (que lida com a privacidade da
USEC de segurança baseado em usuário [5], com mensagem).
algumas alterações. Nele, existe um conceito de Visando a implementação desses módulos, é
usuário ao qual estão associadas informações de preconizada a utilização de protocolos criptográficos
segurança usadas em um ambiente de gerência SNMP. de autenticação, de integridade dos dados e
A definição de SNMPv3 reconhece que é um erro autenticação da origem, com base nos algoritmos
querer definir um único modelo de segurança MD5 [6] e SHA-1 [7], além do método HMAC
definitivo e imutável, pois, com o tempo, novos (Keyed-Hashing for Message Authentication) [8].
requisitos de segurança aparecerão e outros podem Diante dessa evolução, e considerando que, apesar
cair em desuso. Assim, admite-se que SNMP poderá do desenvolvimento já avançado, o trabalho em
suportar vários modelos de segurança, sendo porém SNMPv3 ainda não está concluído e algumas questões
obrigatória a implementação do USM para garantir ainda estão em aberto, o trabalho apresentado neste
compatibilidade com o modelo inicial de SNMPv3 artigo procura desenvolver alternativas de mecanismos
As principais ameaças levadas em consideração na de autenticação para SNMP compatíveis com as
definição de SNMPv3 são a modificação da versões anteriores do protocolo, ainda largamente
informação gerada por um usuário válido e o utilizadas e bastante eficazes. Nesse sentido, as
mascaramento de um usuário, efetivado pelo uso de propostas descritas nesta artigo visam apresentar um
uma identificação falsa por parte de uma entidade não mecanismo autenticador de mensagens SNMP para as
autorizada. Também foram consideradas, ainda como versões v1 e v2c do protocolo, mecanismo este capaz
secundárias, as seguintes ameaças de replay, ou seja de substituir o esquema trivial de autenticação dessas
reordenamento e atraso das mensagens de forma versões. Por outro lado, foi também preocupação no
estranha à operação normal da rede, e falta de desenvolvimento manter coerência com os trabalhos
privacidade nas trocas de mensagens entre entidades em SNMPv3, de forma a tornar possível a utilização
SNMP. das propostas aqui descritas dentro da arquitetura da
Estas ameaças são evitadas com a utilização de versão 3.
criptografia e de uma política de acesso às Assim, são apresentados a seguir dois protocolos de
informações, o que subentende a utilização de autenticação, denominados auth-N e auth-P, ambos
algoritmos criptográficos e de chaves de criptografia. com base no emprego de chaves de autenticação que
Os serviços de segurança para defesa contra as mudam constantemente, reduzindo o risco da quebra
ameaças consideradas acima são: integridade dos de qualquer uma das chaves a um comprometimento
dados da mensagem, autenticação da origem das de somente uma mensagem SNMP e isso apenas no
mensagens, confidencialidade dos dados das momento em que tal mensagem está sendo trocada
mensagens e proteção temporizada contra replays. entre duas entidades de gerência de rede.
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 2. PROTOCOLOS DE AUTENTICAÇÃO PROPOSTOS
dos dados proposto só pode garantir que se saiba qual
usuário dentro do modelo USM está enviando a

Os protocolos de autenticação aqui propostos se mensagem tenha um novo valor para o campo
preocupam basicamente com as ameaças de requestId, o mesmo pode ser dito aqui em relação à
modificação da informação e mascaramento. Para chave de autenticação a ser usada: ela deve mudar a
oferecer proteção contra estes ataques, é enviada cada mensagem, mesmo no caso de retransmissão.
juntamente com a mensagem, a informação de No processo de autenticação, as respostas utilizam a
autenticação. Esta informação será usada pelo receptor mesma chave de autenticação usada nas solicitações.
no processo de verificação da autenticidade da Respostas sem correspondência com solicitações são
mensagem, implicando na necessidade de um método descartadas. Ou seja, a autenticação é obrigatória para
de geração desta informação, em função pelo menos as respostas também.
dos dados da própria mensagem e de um segredo Estes mecanismos dependem da inicialização prévia
compartilhado pelas duas partes, ou seja, uma chave de dados de autenticação nos elementos da rede, sendo
de autenticação. este procedimento uma decisão de implementação e
A solução do problema deve estar integrada podendo ser usados quaisquer métodos, tanto
totalmente com a operação normal dos protocolos automáticos (certificados, canais seguros), como
SNMPv1 e SNMPv2c. Isto significa que, além de a manuais. Esta é a mesma posição do grupo de trabalho
mensagem permanecer a mesma, o novo módulo de SNMPv3.
autenticação não deve alterar outros aspectos como o A chave de autenticação proposta tem 128 bits. Este
controle de acesso às informações de gerência ou a valor foi considerado suficiente para a aplicação de
execução normal de cada tipo de operação SNMP. autenticação em questão, pois as operações de
Um cliente SNMP (gerente) deve construir e enviar gerência de rede têm um tempo de vida normalmente
o seu pedido ao servidor (agente), usando a chave de curto.
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 2.1 Protocolo Auth-P
deve implementar estratégias para timeout e
retransmissão das mensagens. Nessa situação, vale Este protocolo cria uma chave de autenticação
mais uma vez lembrar que a comunicação autenticada aleatória a cada mensagem. Esta chave é cifrada e
se dá então pelo procedimento que consiste em enviada juntamente com a mensagem, através de um
calcular o campo de autenticação para a mensagem subcampo do communityString, denominado
que se quer enviar e enviar tal campo juntamente com “informação de chave”.
a mensagem. Na recepção, é feito novamente o mesmo Na recepção, a chave é decifrada e a autenticação é
cálculo e a comparação entre os dois valores testada. O “P” aqui indica que a chave passa pela rede
determina se a mensagem é autêntica. Para não alterar juntamente com a mensagem.
o formato das mensagens, o próprio campo Para realizar o protocolo, uma função cifradora C
comunidade (communityString) de SNMPv1 e chaveada deverá ser usada. Ela deverá consistir de um
SNMPv2c é usado para enviar as informações de cifrador de blocos que terá o papel de cifrar sempre
autenticação entre as entidades participantes. uma mensagem de tamanho 128 bits: a chave de
A idéia básica das soluções aqui propostas é fazer autenticação. O tamanho de sua chave também será
com que o segredo compartilhado entre gerente e 128 bits.
agente mude a cada solicitação SNMP. Esta mudança Em síntese, o procedimento auth-P pode ser descrito
contínua permite evitar que o segredo, mesmo da seguinte maneira, conforme ilustra a Figura 1:
conhecido, não tenha maior utilidade já que sua 1. É inicializada uma mesma chave, chamada chave
validade cobre tão somente uma única transação mestre de autenticação (Kmestre), em cada um
SNMP. dos elementos de rede que compartilharem esta
Para não alterar o formato da mensagem SNMP v1 chave.
ou v2c, o campo a ser usado para transporte da 2. Quando o gerente for enviar um request, uma
informação de autenticação é unicamente o campo chave de autenticação da transaçao (Ktransação)
comunidade (communityString), que passa a ter uma será gerada aleatoriamente e usada no cálculo do
nova interpretação. Desta forma, toda a informação digest.
pertinente de autenticação será processada conforme 3. Ktransação será criptografada pela função C,
descrito a seguir e será então inserida no campo chaveada por Kmestre, gerando sua cifração
communityString, mais especificamente na forma de Kcipher;
uma sequência de bits. 4. Kcipher é inserida na mensagem a ser enviada,
A informação de autenticação a ser gerada e no subcampo “informação de chave” do campo
inserida na mensagem deverá ser uma função da chave communityString redefinido.
de autenticação definida, das características de 5. Na recepção, a chave Ktransação é recuperada
controle de acesso desejadas e da própria mensagem. pela transformação inversa de C utilizando
Mais especificamente, neste trabalho, as duas Kmestre em Kcipher
propostas de protocolo de autenticação para SNMP 6. A chave Ktransação obtida é usada no teste da
implementam um esquema onde ocorre uma autenticação.
transformação contínua das chaves de autenticação. O Cabe notar que não fará diferença se o protocolo de
comprometimento de uma delas não coloca em perigo transporte abaixo do SNMP for não-confiável, pois
mensagens ou chaves que venham a ser geradas cada solicitação espera uma resposta especificada pelo
posteriormente. A RFC 1905 [9] sugere que cada nova valor de requestId da mensagem. Logo, se uma

mensagem ou sua resposta se perderem, cabe ao Supondo um protocolo de transporte não confiável,
gerente estabelecer estratégias de retransmissão para deve-se prever as exceções possíveis na transmissão
aquele determinado request, cuidando para que a nova destas mensagens. Duas situações são mais
operação empregue uma nova chave de autenticação importantes: a perda de mensagem e a troca de ordem
aleatória. na travessia pela rede.
No caso de mensagens duplicadas, a que vale é a Se uma mensagem de request não obtiver resposta,
primeira a chegar corretamente autenticada. Como o timeout de espera do gerente vai expirar. Dependerá
definido anteriormente, mensagens recebidas sem da implementação o que será feito se, durante o tempo
correspondência devem ser descartadas. de timeout, forem recebidas mensagens com mesmo
RequestId, mas com autenticação falha. De qualquer
forma, a sincronização das chaves geradoras não é
2.1 Protocolo Auth-N perturbada. Deve-se observar que a retransmissão do
request deverá usar uma nova chave.
Este protocolo cria uma chave de autenticação pela Se a mensagem com n=1 não obtiver resposta, uma
aplicação de uma função de hash Hn várias vezes exceção à regra é imposta: n deverá permanecer em 1
sobre uma chave inicial, chamada chave geradora até que se receba a resposta para este request e a troca
(Kgeradora). A cada mensagem, o número (n) destas da chave do gerente possa ser efetuada.
aplicações é decrementado pelo gerente e a mensagem Para o manter o sincronismo de chaves, é necessário
carregará o n para o agente poder chegar na mesma que o gerente nunca envie chaves da nova janela
chave. Na recepção, a mesma função de hash Hn é (depois da transformação H) enquanto não receber a
aplicada n vezes sobre a chave inicial para se chegar à resposta da mensagem autenticada com Kauth 1 da
mesma chave usada para autenticar a mensagem. O janela anterior. Quando a mensagem com Kauth 1 não
caracter “N” no nome Auth-N indica a dependência da receber resposta, a próxima mensagem deve ser
chave com relação ao número de vezes n em que a autenticada com a mesma Kauth 1 até que uma
função de hash deve ser aplicada. Este protocolo resposta seja recebida. Esta é a única situação onde o
obedece às seguintes regras (Figura 2): gerente reutiliza a chave de autenticação. Em todos os
1. São inicializadas duas chaves idênticas no outros casos, a chave deve ser constantemente
gerente e agente, K--matriz e Kgeradora. mudada.
2. Chama-se o intervalo 0  n  w de janela. O Quanto ao agente, este responderá às mensagens
valor de n inicialmente é w. A cada nova reenviadas autenticadas com Kauth 1 tantas vezes
transação, n decresce até chegar a 1. A constante quantas forem necessárias e fará sua transformação
alteração do valor de n é de responsabilidade do somente quando receber a primeira mensagem da nova
gerente e deve ser feita a cada mansagem janela, indicando que o gerente realizou sua troca da
enviada. chave geradora. A mensagem será considerada de uma
3. A chave de autenticação da transação corrente, nova janela quando apresentar n > w/2.
Ktransação = Kauth n corresponderá à Kgeradora No percurso pela rede, mensagens enviadas podem
transformada n vezes por uma função de hash h sofrer troca de ordem ao chegar ao seu destino. Esta
(K), sendo n um inteiro maior que 0 e menor ou possibilidade só prejudicaria a operação do protocolo
igual a w. Logo Kauth n= hn(Kgeradora). auth-N se a resposta da mensagem com n=1 trocar de
4. Quando n chegar a 1, deve ser gerada uma nova ordem com uma anterior, caso em que uma mensagem
chave Kgeradora, usando uma função H one-way corretamente autenticada poderia ser rejeitada pelo
e a chave Kmatriz previamente inicializada. gerente.
Logo, Kgeradora nova = H(Kgeradora velha, Se a resposta da mensagem com n=2 chegar depois
Kmatriz). Note-se que para cada Kgeradora, a da resposta de n=1, para o gerente, ela estará na nova
janela será completamente atravessada de w a 1. janela e este tentará autenticá-la com a nova chave
5. O gerente só deve efetuar a transformação da geradora, implicando em falha.
chave após receber a resposta da mensagem com A solução para este problema estaria unicamente no
n = 1. O agente muda sua chave geradora quando gerente. Uma cópia da chave geradora anterior sempre
receber a primeira mensagem da nova janela. estaria disponível e, no caso da falha na autenticação
Uma mensagem é considerada da nova janela de valores de n próximos de 1, essa cópia seria usada.
quando seu valor for maior que w/2. Com esta abordagem, o agente não é onerado com
6. Assim que transformar sua chave geradora, o mais procedimentos de controle.
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.

2.3 Características dos Protocolos Propostos duas chaves usadas na autenticaçao: a chave matriz e a
chave geradora. O que estará disponível para o
Os protocolos propostos e descritos aqui atacante na rede será apenas o digest gerado pela
identificam a origem de uma mensagem como sendo chave da transação, chave esta que muda a cada
um endereço de rede de uma entidade SNMP. Um mensagem. Tanto a chave matriz como a geradora não
endereço de rede, tal como entendido aqui, só poderá atravessam a rede e, portanto, suas características não
ser na realidade um único endereço efetivo de rede estão disponíveis em qualquer informação carregada
atribuído e alcançável. pela mensagem SNMP.
As chaves empregadas nos mecanismos Além disso, em Auth-N, a chave geradora muda a
autenticadores apresentados só fazem sentido quando cada n = 1, evitando que a descoberta de uma chave
usadas entre dois elementos distintos, um gerente e um geradora signifique perda da segurança. Isto é possível
agente. Em SNMPv1/v2c, estes são identificados por por que a nova chave geradora é alterada em função da
seus endereços de rede. Isto associa um endereço de chave matriz por uma função one-way, portanto sem
rede a uma entidade SNMPv1/v2c agente ou gerente. retorno. Para um atacante, só seria possível
Desta forma, uma entidade SNMP (agente ou gerente) acompanhar as alterações das chaves do protocolo se
deverá possuir uma tabela que armazenará chaves de conseguisse ambas as chaves e observasse os valores
autenticação para cada outra entidade SNMP com de n para saber quando obter a nova chave geradora.
quem puder se comunicar. Esta tabela, de forma Contudo, para auth-N funcionar sincronizadamente é
semelhante à tabela de usuários de uma entidade necessário que a mensagem com n=1 receba sua
SNMPv3, conterá informações sobre as possibilidades resposta e, enquanto isso não acontecer, o gerente só
de comunicação daquela entidade com outras deve usar n=1 nas mensagens posteriores. A
entidades SNMPv1/v2c. mensagem de resposta com n=1 é a confirmação do
Uma vantagem direta das abordagens usadas nos agente para a mudança da atual chave geradora. É
protocolos auth-P e auth-N é o fato de que não há interessante notar que esta é uma preocupação
necessidade de se esperar a resposta da mensagem somente do gerente já que o agente só mudará sua
anterior para poder disparar a próxima. Em operações chave geradora quando receber valores de n da nova
SNMP como get-Next-Request, que normalmente são janela. Assim, colocando-se esta responsabilidade
disparadas seguidamente, este aspecto de sobre o gerente, mantém-se a caraterística simples do
seqüenciação é importante. Outro detalhe é que, nem agente SNMP.
no protocolo auth-P nem no protocolo auth-N, é Desse modo, se o agente não responder à mensagem
preciso que o agente armazene chaves anteriores à com n =1 apesar das retransmissões, considera-se que
chave corrente. Conforme se sabe, é um requisito houve um problema com a rede, ou com o dispositivo
interessante que o agente necessite do mínimo de gerenciado, ou ainda um ataque de negação de serviço.
processamento e memória, de modo que o protocolo Por este motivo, é necessário limitar estas
possa ser largamente adotado em todo tipo de retransmissões no gerente. Um número máximo de 50
equipamento. retransmissões parece razoável para operações de
O mecanismo de autenticação auth-N exige que a gerência de rede. Após atingido este limiar, é
comunicação entre agente e gerente seja do tipo de interrompida a comunicação com o elemento de rede
pedido/resposta, ou seja, uma mensagem do gerente em questão e considera-se uma nova inicialização ou
deverá sempre esperar uma resposta. Dentro da intervenção manual, mas isto é uma característica
arquitetura SNMP, a maior parte das operações são particular de implementaçã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 2.3 Implementação dos Protocolos Propostos
utilizado o protocolo auth-P, já que ele não depende
de respostas para sincronizar as alterações dos As propostas apresentadas acima foram
segredos de autenticação. Para este esquema implementadas, para averiguação das condições dos
funcionar, basta que agente e gerente possuam a protocolos e obtenção de dados para uma análise da
mesma chave mestre, como requer o protocolo auth-P. utilidade e operacionalidade destes métodos de
Por outro lado, o protocolo auth-P baseia-se numa autenticação dentro do protocolo SNMP.
única chave: a chave mestre. Se esta for descoberta O protocolo auth-N exige uma função de hash h
pode-se gerar mensagens autenticadas quaisquer. para poder gerar a chave de autenticação específica da
Outra desvantagem deste protocolo é o fato da mensagem em operação. A escolha do MD5 neste
mensagem SNMP carregar a chave de autenticação trabalho levou em conta o nível de segurança aceitável
usada (chave da transação). Mesmo criptografada, esta do algoritmo contra ataques de força bruta e sua
chave estará disponível para criptoanálise. E se uma facilidade de implementação em máquinas de 32 bits
criptoanálise tiver sucesso, a chave usada na cifração (PC Pentium), além da disponibilidade de código já
(chave mestre) ainda poderá ser descoberta. A pronto na Internet.
passagem de chaves de autenticação cifradas pela rede Tanto auth-P como auth-N precisam de uma função
oferece ao atacante várias amostras de cifração com a criptográfica que gere o digest da mensagem, em
chave mestre. função da mensagem e de uma chave. Como SNMP
Auth-N, por sua vez, não apresenta essa opta sempre pela simplicidade e os agentes a serem
característica. O que passa pela rede é somente um implementados devem ser facilmente desenvolvidos,
número com significado apenas para quem possui as 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 [1] IETF, RFC 1157 - Simple Network Management
escolha para a função de hash a ser usada em H. Protocol (SNMP), (Status: standard), 1990.
Para o protocolo auth-P, um cifrador de blocos [2] IETF, RFC 1351 - SNMP Administrative Model,
chaveado é necessário para fazer a cifração da chave (Status: proposed standard), 1992.
de autenticação a ser usada na mensagem. O algoritmo [3] IETF, RFC 2026 - The Internet Standards
Blowfish [10] escolhido é um cifrador de blocos de 64 Process - Revision 3, 1996.
bits desenvolvido por Bruce Schneier em 1993, não é [4] IETF, draft - The User-Based Security Model for
patenteado e é livre para utilização. Version 3 of the Simple Network Management
No que diz respeito ao ambiente de Protocol (SNMPv3), 1999.
desenvolvimento, foi utilizado um sistema Linux Red [5] IETF, RFC 1909 - An Administrative
Hat 5.1 para microcomputar PC. Os testes foram feitos Infrastructure for SNMPv2, (Status:
numa rede local composta de 3 máquinas semelhantes. experimental), 1996.
A linguagem C++ foi escolhida para o [6] IETF, RFC 1321 - The MD5 Message-Digest
desenvolvimento e a interface de protocolo de rede foi Algorithm, (Status: informational), 1992.
a biblioteca sockets que acompanha o sistema Linux [7] NIST, FIPS Publication 180-1 – Secure Hash
usado. Para a implementação, partiu-se de um pacote Algorithm, 1995.
de software CMU versão 3.5, contendo código-fonte [8] IETF, RFC 2104 – HMAC: Keyed-Hashing for
em linguagem C de um agente SNMPv1/v2c Message Authentication, (Status: informational),
acompanhado de algumas pequenas aplicações SNMP. 1997.
Este código-fonte foi alterado para a linguagem C++, [9] IETF, RFC 1905 - Protocol Operations for
resultando em um agente SNMPv1/v2c e algumas Version 2 of the Simple Network Management
pequenas aplicações SNMP, todos integrando os Protocol (SNMPv2), (Status: draft standard),
protocolos auth-P e auth-N aqui propostos. 1996.
O procedimento de teste das implementações [10] SCHNEIER, Bruce. The Blowfish Encryption
preocupou-se em checar os itens críticos da execução Algorithm, 1998. http://www.counterpane.com/
de ambos os protocolos, apontados no item anterior. blowfish.html.
Verificou-se que em ambiente de laboratório os
protocolos funcionam conforme previsto nas
especificações iniciais.
Gerador
Aleatório

Gerente SNMP

3. CONCLUSÃO Kmestre Ktransação Geração do
digest

Tanto o modelo de segurança baseado em usuário C

de SNMPv3, como as propostas deste trabalho, Kcipher Agente SNMP

dependem da prévia inicialização de chaves nos comunidade Kcipher digest (Ktransação) Kmestre

elementos da rede sendo gerenciados. O modo de
C
realizar tal operação é deixado a cargo do fabricante e
dos administradores de redes, podendo ser usados Ktransação

certificados, canais seguros, algoritmos assimétricos,
ou até mesmo procedimentos manuais, da maneira Teste da
Autenicação

mais conveniente na inicialização dos segredos. Figura 1: Protocolo Auth-P
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
Gerente SNMP

Kgeradora
atualmente nos protocolos SNMPv1 e SNMPv2c, não
interferindo de maneira nenhuma nos outros aspectos hn

operacionais do SNMP, tais como o processamento da Ktransação Geração do
digest Agente SNMP

mensagem ou o controle de acesso. O formato da comunidade n digest (Ktransação)
Kgeradora
mensagem SNMP não foi alterado nas propostas.
hn
As implementações demostraram a robustez dos
serviços de autenticação dos protocolos auth-P e auth- Ktransação

N. O preço pago pelo melhor serviço traduziu-se
basicamente em pequeno atraso no processamento de Teste da
Autenicação

uma mensagem, já que o tamanho das implementações
Figura 2: Protocolo Auth-N
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

Propostas de Autenticação para SNMP

Mais conteúdo relacionado

Mais procurados

Semelhante a Propostas de Autenticação para SNMP

Mais de Mauro Tapajós

Propostas de Autenticação para SNMP