Comparativo entre as versões do SNMP

1. Introdução

Com a evolução dos ambientes de rede, eles se tornaram cada vez mais complexos e difíceis de serem monitorados e gerenciados. Para resolver esse problema, vários pesquisadores buscaram criar soluções que pudessem auxiliar no processo de gerenciamentos de grandes ambientes de rede. Dentre essas soluções destacou-se o SNMP.

O SNMP, desde sua concepção, possui como característica a separação entre as informações trocadas e o protocolo usado para transportar essas informações. Com essa característica, as operações do protocolo não precisam ser definidas de acordo comandos específicos usados para recuperar informações ou alterar as configurações de um dispositivo. Dessa forma, as operações do protocolo são definidas em torno de variáveis chamadas de objects, essas variáveis contêm as informações de gerenciamento.

O resultado dessa separação é um protocolo com complexidade bastante reduzida, pois ao invés de definir dezenas, ou até centenas, de operações quem definem funções específicas de gerenciamento da rede, o protocolo apenas precisa lidar com a transmissão das variáveis objects, sem se importar com o que elas contêm.

2. O SNMP versão 1 (SNMPv1)

O SNMPv1 tem sua origem no protocolo SGMP (Simple Gateway Monitor Protocol) que está definido na RFC 1028. O SGMP foi projetado para ser uma solução intermediária para o gerenciamento de redes enquanto um solução mais abrangente era explorada. No entanto muitos dos conceitos básicos do SNMP atual estão presentes no SGMP.

A primeira definição formal do SNMP ocorreu na RFC 1067 (posteriormente revista nas RFCs 1098 e 1157). Esses documentos descrevem a estrutura das informações de gerenciamento (SMI) (RFC 1155), as bases de informação de gerenciamento (MIB) (RFC 1156) e a estrutura do protocolo propriamente dita (RFC 1157), onde estão descritos os tipos de mensagem, formato das mensagens, protocolos de transporte suportados, entre outras informações.

2.1. As Mensagens

Para um melhor entendimento das mensagens SNMP, é importante ressaltar a diferença entre mensagens SNMP e protocol data units (PDUs). É comum que esses termos sejam usados de forma análoga, isso ocorre porque cada mensagem carrega um PDU, e o PDU é a parte mais importante da mensagem.

No entanto, falando de forma clara, o PDU e a mensagem SNMP não são a mesma coisa. O PDU é a parte da informação que é trocada entre as entidades SNMP (agentes e gerentes). Ele é transportado dentro da mensagem SNMP junto com outros campos de cabeçalho usados para informações de segurança e identificação. Desta forma considera-se, conceitualmente, o formato da mensagem SNMP como tendo duas sessões:

  • Cabeçalho da Mensagem: contém campos usados para controlar a forma como a mensagem é processada, incluindo campos para implementação de segurança;
  • Corpo da Mensagem (PDU): contém a parte principal da mensagem. O corpo da mensagem é o PDU sendo transmitido.
    O cabeçalho da mensagem não requeria muitos campos no SNMPv1, pois o modelo de segurança utilizado, baseado em comunidades, era muito rudimentar. Uma breve descrição da estrutura da mensagem SNMP é mostrada na Tabela 1.
Nome do CampoTipoTamanho (bytes)Descrição
VersionInteiro4Número da Versão: Indica a versão do SNMP da mensagem; usado para assegurar compatibilidade entre versões. Para o SNMPv1, o valor usado é 0, não 1.
ComunityString de octetosVariávelNome da Comunidade: Identifica a comunidade SNMP em que o remetente da mensagem está localizado. Este campo é usado para implementar o mecanismo de segurança baseado em comunidades.
PDUVariávelProtocol Data Unit: O PDU que está sendo transmitido como corpo da mensagem.

Tabela 1: Formato da mensagem SNMPv1

2.1.1. Os Tipos de PDU e seus Formatos

O SNMPv1 define cinco tipos de PDU, são eles: GetRequest, GetNextRequest, GetResponse, SetRequest e Trap.

  • GetRequest: permite ler o valor de uma ou mais instancias de variáveis.
  • GetNextRequest: permite ler o valor de uma ou mais instancias de variáveis sem conhecer o nome exato da mesma.
  • GetResponse: retorna o resultado de uma operação de leitura.
  • SetRequest: permite atribuir o valor de uma variável.
  • Trap: Sinaliza a ocorrência de algum evento. Possui um formato diferente.

Todos os PDUs no SNMPv1 possuem o mesmo formato, com exceção do PDU Trap. A semântica exata de cada campo depende de cada mensagem em particular. Por exemplo, o campo ErrorStatus só tem algum significado quando a mensagem é uma resposta, e não um comando.

A Tabela 2 descreve o formato básico dos PDUs (exceto Trap).

Nome do CampoTipoTamanho (bytes)Descrição
PDU TypeInteiro (Enumeração)4Tipo de PDU: É um valor inteiro que indica o tipo de PDU:Valor do tipo de PDUTipo de PDU0GetRequest1GetNextRequest2GetResponse3SetRequest
Request IDInteiro4Identificador de comando: Um número usado para relacionar comandos às suas respectivas respostas. Ele é normalmente gerado pela entidade que enviou o comando e copiado no mesmo campo em um GetResponse pela entidade SNMP que está respondendo ao comando.
Error StatusInteiro (Enumeração)4Código de Erro: Um valor inteiro que é usado no GetResponse para indicar à entidade que emitiu o comando o resultado de sua requisição. Um código igual a zero indica que nenhum erro ocorreu; os outros valores indicam algum tipo de erro. A relação dos códigos de erro é apresentada na Tabela 3.
Error IndexInteiro4Índice do Erro: Quando o ErrorStatus for diferente de zero, este campo conterá um ponteiro para o objeto que gerou o erro. Caso haja mais de um objeto gerando erro, será apontado apenas o primeiro. Este campo é sempre zero em um comando.
Variable BindingsVariávelVariávelConjunto de Variáveis: Um conjunto de pares do tipo nome/valor que identificam os objetos da MIB dentro do PDU e seus respectivos valores.

Tabela 2: Formato do PDU exceto Trap.

Valor do Código de ErroCódigo de ErroDescrição
0noErrorNenhum erro ocorreu. Este código também é usado em todos os PDUs de comandos, visto que estes não possuem erros a relatar.
1tooBigO tamanho do PDU GetResponse seria muito grande para ser transmitido.
2noSuchNameO nome do objeto requisitado não foi encontrado.
3badValueAlgum valor no comando requisitado não está de acordo com a estrutura que o destinatário tem para o objeto. Por exemplo o tamanho ou o tipo do dado está incorreto.
4readOnlyFoi feita uma tentativa de alterar o valor de alguma variável cujo acesso é de apenas leitura.
5genErrOcorreu algum erro diferente dos especificados anteriormente.

Tabela 3: Relação de códigos de erro.

Conforme citado anteriormente, o PDU Trap possui um formato diferenciado. Esse formato é descrito na Tabela 4.

Nome do CampoTipoTamanho (bytes)Descrição
PDU TypeInteiro (Enumeração)4Tipo de PDU: Um valor inteiro que indica o tipo de PDU, que é 4 para o PDU Trap.
EnterpriseSequencia de InteirosVariávelEmpresa: Um identificador de objeto para um grupo, que indica o tipo de objeto que gerou o Trap.
Agent AddrEndereço de Rede4Endereço do Agente: O endereço IP do agente SNMP que gerou o Trap.
Generic TrapInteiro (Enumeração)4Código Genérico de Trap: Um valor que identifica o Trap entre um conjunto de códigos pré-definidos.
Specific TrapInteiro4Código Específico de Trap: Um valor que identifica um tipo de Trap especifico de uma implementação.
Time StampTimeTicks4Marcação de Tempo: A quantidade de tempo, desde a última inicialização, da entidade SNMP que enviou o Trap. Usado para registro de atividades.
Variable BindingsVariávelVariávelConjunto de Variáveis: Um conjunto de pares do tipo nome/valor que identificam os objetos da MIB dentro do PDU e seus respectivos valores.

Tabela 4: Formato do PDU Trap.

2.2. Mecanismos de segurança

Infelizmente, a segurança incorporada ao SNMPv1 é extremamente limitada e pode ser resumida em um conceito e uma tecnonogia.

  • Objetos Fracos: o SNMP foi criado com a idéia de que os objetos da MIB usados no protocolo seriam relativamente fracos. Isso significa que os objetos foram projetados para que qualquer problema que ocorresse na manipulação deles resultasse em um dano mínimo. Dessa forma a política do desenvolvimento do projeto era que os objetos da MIB que poderiam ser lidos não deveriam conter informações críticas, e os objetos que poderiam ser alterados não deveriam controlar nenhuma funcionalidade critica.
  • Strings de Comunidade: todos os dispositivos em uma rede SNMP administrados por um conjunto particular de gerentes são considerados como pertencentes a uma “comunidade”. Cada mensagem SNMPv1 trocada entre membros de uma comunidade são identificadas por uma string de comunidade que aparece em um campo do cabeçalho da mensagem. Essa string é como uma simples senha; qualquer mensagem recebida com a string de comunidade errada é rejeitada pelo destinatário.

Pode-se dizer que essas características de segurança são melhores do que nada, mas não muito. O uso de objetos fracos é comparável a uma regra que diz para não deixar o carro estacionado com as portas abertas e a chave na ignição – ela está dizendo basicamente para não procurar problemas. Isso é prudente, mas não é uma solução completa de segurança. O uso de strings de comunidade protege contra ataques óbvios na forma de mensagens não autorizadas, no entanto as strings são enviadas em texto puro e podem ser facilmente descobertas. Assim pode-se comparar a deixar seu carro estacionado com as portas trancadas: protege contra um ladrão casual, mas não contra um profissional.

É claro que para muita gente a segurança simplória fornecida pelo SNMPv1 é suficiente. No entanto, para novos e grandes ambientes de rede, principalmente os que englobam redes publicas de operadoras, o SNMPv1 não fornece nível suficiente de segurança.

3. O SNMP versão 2 (SNMPv2c)

Após alguns anos de uso do SNMPv1, certas deficiências passaram a ser percebidas e as necessidades de melhoria foram identificadas. Isso levou ao desenvolvimento da versão original do SNMPv2, que tinha como objetivo aprimorar o SNMPv1 em várias áreas, incluindo as definições de objetos da MIB, operações do protocolo e segurança. Esta última área, segurança, levou a proliferação de variantes do SNMPv2.

Visto que existem diferentes variações do SNMPv2, também existem variações nos formatos das mensagens utilizados para cada uma dessas variações. Isso é bastante confuso, mas seria muito pior caso as mensagens SNMP não possuíssem uma natureza modular. As operações do protocolo foram alteadas da versão SNMPv1 para o SNMPv2, e para isso foram necessárias alterações no formato do PDU. No entanto as operações do protocolo são as mesmas para todas as variações do SNMPv2. As diferenças entre as variações do SNMPv2 estão nas áreas de implementação de segurança. Dessa forma, o resultado é que o formato do PDU é o mesmo para todas as variantes do SNMPv2, mas o formato da mensagem difere de variação para variação.

Durante a divergência do SNMPv2, quatro variações foram definidas: o SNMPv2 original (chamado de SNMPv2p); o SNMPv2 baseado em comunidades (SNMPv2c); o SNMPv2 baseado em usuários (SNMPv2u) e o SNMPv2*. Todas as definições fazem referencia a RFC 1905 que define a estrutura do PDU do SNMPv2.

Neste artigo será abordado apenas o SNMPv2c, pois é a variação que tornou-se mais popular.

3.1. As Melhorias Introduzidas

Na versão 2 do SNMP foram introduzidas varias melhorias em relação à versão anterior, entre elas vale a pena destacar a possibilidade de comunicação entre entidades gerentes através das mensagens InformRequest, que tornou possível o gerenciamento distribuído.

Outras mudanças são a inserção de uma PDU para otimizar e facilitar a recuperação de dados em tabelas, o GetBulkRequest, novos objetos MIBs para comunicação gerente-gerente e alterações nos nomes e formatos de operações existentes.

3.2. As Mensagens

A variação SNMPv2c tinha como objetivo manter as melhorias introduzidas pelo SNMPv2p, mas voltar a utilizar o modelo simples de segurança do SNMPv1 com strings de comunidade. Dessa forma, o documento que define o SNMPv2c (RFC 1901) especifica que o formato geral da mensagem é o mesmo usado para o SNMPv1, com exceção do número de versão que foi alterado. Esse formato é descrito na Tabela 5.

Nome do CampoTipoTamanho (bytes)Descrição
VersionInteiro4Número da Versão: Indica a versão do SNMP da mensagem; usado para assegurar compatibilidade entre versões. Para o SNMPv2c, o valor usado é 1.
ComunityString de octetosVariávelNome da Comunidade: Identifica a comunidade SNMP em que o remetente da mensagem está localizado. Este campo é usado para implementar o mecanismo de segurança baseado em comunidades.
PDUVariávelProtocol Data Unit: O PDU que está sendo transmitido como corpo da mensagem.

Tabela 5: Formato da mensagem do SNMPv2c.

3.2.1. Os Tipos de PDU e seus Formatos

O formato dos PDUs no SNMPv2 á descrito na RFC 1905, e é similar ao do SNMPv1. Os PDUs do SNMPv2 possuem o mesmo formato, com exceção do PDU GetBulkRequest, que é uma novo tipo de PDU adicionado ao protocolo.

Nesta versão do SNMP foram incluídos dois novos tipos de PDU, o já citado GetBulkRequest e o InformRequest. Além destes, o PDU Trap foi alterado e não mais utiliza um formato específico de PDU. A descrição de cada PDU está na Tabela 6.

Valor do Tipo de PDUTipo de PDUDescrição
0GetRequestRetorna o valor de uma instância de variável.
1GetNextRequestRetorna o valor da variável sucessora lexicográfica.
2ResponseRetorna o resultado de uma operação.
3SetRequestAtribui valor a uma variável.
4Trap (obsoleto)Não usado. Era o antigo Trap do SNMPv1.
5GetBulkRequestPermite a recuperação de grande quantidade de dados, normalmente o conteúdo de tabelas.
6InformRequestPermite que um gerente envie informações para outro gerente.
7Trapv2Envia sinalizações de eventos.
8ReportUsado para comunicação interna do protocolo para relatar erros excepcionais ocorridos durante o processamento das requisições.

Tabela 6: Tipos e descrições dos PDUs

Nome do CampoTipoTamanho (bytes)Descrição
PDU TypeInteiro (Enumeração)4Tipo de PDU: um inteiro que identifica o tipo do PDU. Os valores e tipos possíveis estão na Tabela 6, exceto o 5 (GetBulkRequest) que possui PDU com formato diferenciado..
Request IDInteiro4Identificador de comando: Um número usado para relacionar comandos às suas respectivas respostas. Ele é normalmente gerado pela entidade que enviou o comando e copiado no mesmo campo em um GetResponse pela entidade SNMP que está respondendo ao comando.
Error StatusInteiro (Enumeração)4Código de Erro: Um valor inteiro que é usado no Response para indicar à entidade que emitiu o comando o resultado de sua requisição. Um código igual a zero indica que nenhum erro ocorreu; os outros valores indicam algum tipo de erro. A relação dos códigos de erro é apresentada na Tabela 9.Note que os primeiros seis valores estão mantidos da mesma forma como eram usados no SNMPv1 por motivos de compatibilidade. No entanto o SNMPv2 adiciona muitos outros códigos de erro que permitem uma indicação muito mais específica do tipo de erro ocorrido.
Error IndexInteiro4Índice do Erro: Quando o ErrorStatus for diferente de zero, este campo conterá um ponteiro para o objeto que gerou o erro. Caso haja mais de um objeto gerando erro, será apontado apenas o primeiro. Este campo é sempre zero em um comando.
Variable BindingsVariávelVariávelConjunto de Variáveis: Um conjunto de pares do tipo nome/valor que identificam os objetos da MIB dentro do PDU e seus respectivos valores.

Tabela 7: Formato do PDU, exceto GetBulkRequest.

O formato do PDU do GetBulkRequest é diferenciado e apresenta campos específicos para a funcionalidade de resgate de grandes quantidades de dados em tabelas. O formato desse PDU está descrito na Tabela 8.

Nome do CampoTipoTamanho (bytes)Descrição
PDU TypeInteiro (Enumeração)4Tipo de PDU: Um valor inteiro que indica o tipo de PDU, que é 5 para o PDU GetBulkRequest.
Request IDInteiro4Identificador de comando: Um número usado para relacionar comandos às suas respectivas respostas. Ele é normalmente gerado pela entidade que enviou o comando e copiado no mesmo campo em um GetResponse pela entidade SNMP que está respondendo ao comando.
Non RepeatersInteiro4Não Repetidos: Especifica o número de objetos que não serão lidos repetidamente, a partir do início da lista de objetos do comando.
Max RepetitionsInteiro4Número Máximo de Repetições: O número máximo de iterações que deverão ser executadas para os objetos que seguem os não repetidos do comando.
Variable BindingsVariávelVariávelConjunto de Variáveis: Um conjunto de pares do tipo nome/valor que identificam os objetos da MIB dentro do PDU e seus respectivos valores.

Tabela 8: Formato do PDU do GetBulkRequest.

Os códigos de erro também tiveram alteração na versão 2 do SNMP, foram adicionados vários códigos novos para permitir um maior detalhamento quando ocorresse algum problema no processamento do comando. A Tabela 9 lista os códigos de erro possíveis.

Valor do Código de ErroCódigo de ErroDescrição
0noErrorNenhum erro ocorreu. Este código também é usado em todos os PDUs de comandos, visto que estes não possuem erros a relatar.
1tooBigO tamanho do PDU Response seria muito grande para ser transmitido.
2noSuchNameO nome do objeto requisitado não foi encontrado.
3badValueAlgum valor no comando requisitado não está de acordo com a estrutura que o destinatário tem para o objeto. Por exemplo o tamanho ou o tipo do dado está incorreto.
4readOnlyFoi feita uma tentativa de alterar o valor de alguma variável cujo acesso é de apenas leitura.
5genErrOcorreu algum erro diferente dos especificados nesta tabela.
6noAccessO acesso ao objeto foi negado por questões de segurança.
7wrongTypeO tipo de dados do objeto no conjunto de variáveis está incorreto para o objeto.
8wrongLengthO tamanho do objeto especificado no conjunto de variáveis está incorreto para o objeto.
9wrongEncodingO valor codificado é inconsistente com o tipo do objeto.
10wrongValueO valor de uma dada variável não é válido para o objeto.
11noCreationUma variável especificada não existe e não pode ser criada.
12inconsistentValueO valor especificado não pode ser atribuído à variável neste momento, é uma condição temporária.
13resourceUnavailableUma tentativa de atribuir um valor a uma variável requereu alocação de recursos que estão indisponíveis no momento.
14commitFailedNão foi possível realizar todas as atribuições de variável.
15undoFailedNão foi possível desfazer as atribuições de variáveis após a ocorrência de uma falha.
16authorizationErrorErro de autorização.
17notWritableA variável não pode ser modificada.
18inconsistentNameO nome da variável especificada não existe e não pode ser criada nas circunstâncias atuais.

Tabela 9: Códigos de erro do SNMPv2.

Os códigos de erro noSuchName (2), badValue (3) e readOnly (4) foram mantidos apenas para compatibilidade e não são gerados pelo SNMPv2.

3.3. Mecanismos de segurança

Visto que a definição do SNMPv2c tem como objetivo manter as melhorias de funcionalidade do SNMPv2p, porém sem utilizar o mecanismo de segurança especificado para o mesmo, os mecanismos de segurança disponíveis para o SNMPv2c são exatamente os mesmos do SNMPv1.

4. O SNMP versão 3 (SNMPv3)

O SNMP versão 3 foi criado para suprir uma necessidade padronização que se fez necessária com as várias variações do SNMPv2 quem tentavam criar soluções de segurança para o protocolo. O SNMPv3 teve como base as definições das variações SNMPv2u e SNMPv2*.

Além das definições das questões de segurança, o projeto do SNMPv3 também objetivou uma padronização de implementação das entidades (agente/gerente), modularizando suas funcionalidades, o que facilita a evolução de alguns mecanismos do protocolo sem exigir que novas versões sejam lançadas. Outros objetivos eram a manutenção de uma estrutura simples, facilitar a integração com outras versões e, sempre que possível, reaproveitar as especificações existentes.

O SNMPv3 incorporou o SMI e o MIB do SNMPv2, assim como também utilizou as mesmas operações do SNMPv2, apenas com uma reescrita da norma para uma compatibilização da nomenclatura.

4.1. A organização interna (arquitetura)

A arquitetura proposta na RFC 2271 consiste em uma coleção distribuída de entidades SNMP que interagem entre si. Cada entidade implementa uma porção das capacidades do SNMP e pode atuar como agente, gerente ou uma combinação dos dois. Cada entidade SNMP consiste em uma colação de módulos que interagem entre si para prover serviços.

4.1.1. Entidades

Cada entidade incluí apenas um engine SNMP. Um engine SNMP implementa funções para enviar e receber mensagens, autenticar e encriptar/decriptar mensagens, e controlar o acesso aos objetos gerenciados. Essas funções são providas na forma de serviços para uma ou mais aplicações que são configuradas em conjunto com o engine para formar uma entidade SNMP.

Tanto o engine SNMP quanto as aplicações que ele suporta são definidos como uma coleção de módulos. Essa arquitetura prove várias vantagens. Primeiro, o papel de uma entidade SNMP é determinado por quais módulos estão implementados nessa entidade. Por exemplo existem conjuntos de módulos que são necessários para um agente SNMP, enquanto outros são requeridos para um gerente SNMP. Segundo, a estrutura modular da especificação permite a definição de diferentes versões para cada módulo. Por sua vez, isso torna possível:

  • Definir capacidades alternativas ou melhoradas para certos aspectos do SNMP sem precisar levar todo o padrão para uma nova versão;
  • Especificar de forma clara estratégias de coexistência e transição.

A Figura 1 exibe de forma ilustrativa os componentes e as interações dos módulos de uma entidade SNMP.

Figura 1: Layout de uma entidade SNMP.

Todo engine SNMP é identificado com um número chamado de snmpEngineID.

4.1.1.1. Gerentes

Um gerente SNMP tradicional interage com os agentes SNMP enviando comandos (get, set) e recebendo mensagens trap; o gerente também pode interagir com outros gerentes enviando PDUs do tipo InformRequest, que fornece alertas, e recebendo InformResponse PDUs, que confirma o recebimento de InformRequest. Na terminologia do SNMPv3, um gerente tradicionalmente inclui três categorias de aplicações. As Aplicações Geradoras de Comandos monitoram e manipulam dados gerenciados nos agentes remotos; eles utilizam os PDUs do SNMPv1 e/ou do SNMPv2, incluindo Get, GetNext, GetBulk e Set. As Aplicações Emissoras de Notificações iniciam mensagens assíncronas; no caso de um gerente tradicional, o PDU InformRequest é usado por essas aplicações. Uma Aplicação Recebedora de Notificações processa as mensagens assíncronas que chegam; isso inclui os PDUs InformRequest, Trapv2 e Trap. No caso do PDU que chegar for um InformRequest, a Aplicação Recebedora de Notificações responderá com o PDU Response.

Todas as aplicações descritas usam os serviços providos pelo engine SNMP da entidade. O engine SNMP executa dois papeis básicos:

  • Ele aceita PDUs de saída das aplicações SNMP, executa os processamentos necessários, inclusive inserir códigos de autenticação e encriptação, e então encapsula os PDUs em mensagens para transmissão;
  • Ele aceita mensagens SNMP provenientes da camada de transporte, executa os processamentos necessários, inclusive autenticação e decriptação, então extrai os PDUs das mensagens e passa-os para a aplicação SNMP apropriada.

Em um gerente tradicional, o engine SNMP contém um Despachante (Dispatcher), um Subsistema de Processamento de Mensagens (Message Processing Subsystem) e um Subsistema de Segurança (Security Subsystem).

O Despachante é um simples gerenciador de tráfego. Para PDUs de saída, o Despachante aceita os PDUs vindos das aplicações e executa as seguintes funções: para cada PDU, o Despachante determina o tipo de processamento de mensagem requerido (SNMPv1, SNMPv2c ou SNMPv3) e passa o PDU para o módulo de processamento de mensagem apropriado no Subsistema de Processamento de Mensagens. Subseqüentemente, o Subsistema de Processamento de Mensagens retorna uma mensagem contendo o PDU e os cabeçalhos apropriados. O Despachante então mapeia a mensagem na camada de transporte para transmissão. No caso de mensagens de entrada, o Despachante aceita a mensagem vinda da camada de transporte e executa as seguintes funções: o Despachante encaminha cada mensagem para o módulo de processamento adequado. Subseqüentemente, o Subsistema de Processamento de Mensagens retorna o PDU contido na mensagem. O Despachante então passa o PDU para a aplicação apropriada.

O Subsistema de Processamento de Mensagens aceita PDUs de saída vindos do Despachante e prepara-os para transmissão encapsulando-os com o cabeçalho apropriado e retornando-os para o Despachante. O Subsistema de Processamento de Mensagens também aceita mensagens de entrada vindas do Despachante, processa cada cabeçalho da mensagem, e retorna o PDU para o Despachante. Uma implementação do Subsistema de Processamento de Mensagens pode suportar apenas um formato de mensagem correspondente a uma das versões do SNMP, ou ele pode conter um certo número de módulos, cada um suportando uma versão diferente do SNMP.

O Subsistema de Segurança executa funções de autenticação e criptografia. Cada mensagem de saída é passada para o Subsistema de Segurança pelo Subsistema de Processamento de Mensagens. Dependendo dos serviços requeridos, o Subsistema de Segurança pode criptografar o PDU e possivelmente alguns outros campos do cabeçalho da mensagem, e ele pode também gerar um código de autenticação e inseri-lo no cabeçalho da mensagem. A mensagem processada é então devolvida para o Subsistema de Processamento de Mensagens. De maneira similar, cada mensagem de entrada é passada para o Subsistema de Segurança pelo Subsistema de Processamento de Mensagens. Se requerido, o Subsistema de Segurança verifica o código de autenticação e executa a descriptografia. Então a mensagem processada é passada de volta para o Subsistema de Processamento de Mensagens. Uma implementação do Subsistema de Segurança pode suportar um ou mais modelos de segurança distintos. Até o momento, o único modelo de segurança definido é o Modelo de Segurança Baseado em Usuário (USM) para o SNMPv3, especificado na RFC 2274.

Uma representação visual da entidade gerente pode ser observada na Figura 2.

Figura 2: Entidade Gerente do SNMPv3.

4.1.1.2. Agentes

Um agente SNMP tradicional pode conter três tipos de aplicação: a Aplicação que Responde Comandos prove acesso aos dados gerenciados. Estas aplicações respondem às requisições que chegam recuperando ou alterando objetos gerenciados e então gerando um PDU Response. Uma Aplicação Emissora de Notificações inicia mensagens assíncronas; no caso de um agente tradicional, o PDU Trapv2 ou Trap são usados por essa aplicação. Uma Aplicação Encaminhadora Proxy encaminha mensagens entre entidades.

O engine SNMP de um agente tradicional contém todos os componentes encontrados em um engine SNMP de um gerente tradicional, mais um Subsistema de Controle de Acesso. Esse subsistema provém serviços de autorização para controlar o acesso às MIBs quanto à leitura e gravação em objetos gerenciados. Esses serviços são executados com base no conteúdo dos PDUs. Uma implementação do Subsistema de Segurança pode suportar um ou mais modelos de controle de acesso distintos. Até o momento o único modelo de segurança definido é o Modelo de Acesso Baseado e Visões (VACM) para o SNMPv3, especificado na RFC 2275.

Uma representação visual da entidade agente pode ser observada na Figura 3.

Figura 3: Entidade Agente SNMPv3.

4.2. As Mensagens

Entre as mudanças significativas trazidas pelo SNMPv3 está uma maneira mais flexível de definir métodos e parâmetros de segurança, para permitir a coexistência de múltiplas técnicas de segurança.

O formato geral das mensagens no SNMPv3 ainda segue a mesma idéia de uma mensagem “envelope” que contém um cabeçalho e um PDU encapsulado. No entanto, na versão 3 esse conceito está ainda mais refinado. Os campos do cabeçalho foram divididos em dois tipos: os que lidam e os que não lidam com questões de segurança. Os campos não voltados para segurança são comuns para todas as implementações do SNMPv3, enquanto o uso dos campos ligados a segurança podem ser guiados por cada modelo de segurança do SNMPv3, e processados pelos módulos correspondentes em uma entidade SNMP que lide com segurança. Esta solução provê uma considerável flexibilidade evitando os problemas que atormentaram o SNMPv2.

Uma descrição mais detalhada do novo formato de mensagem introduzida no SNMPv3 pode ser encontrada nas Tabelas 10, 11 e 12.

Nome do CampoTipoTamanho (bytes)Descrição
Msg VersionInteiro4Número de Versão da Mensagem: Indica a versão do SNMP da mensagem; usado para assegurar compatibilidade entre versões. Para o SNMPv3, esse valor é 3.
Msg IDInteiro4Identificador da Mensagem: Um número usado para identificar uma mensagem SNMPv3 e encontrar as mensagens de resposta de um commando enviado. O uso deste campo é similar ao RequestID descrito no formato do PDU, mas eles não são idênticos. Este campo foi criado para permitir a identificação no nivel de processamento da mensagem sem lever em consideração o conteúdo do PDU, para proteger contra certos ataques à segurança. Dessa forma o Msg ID e o Request ID são usados de forma independente.
Msg Max SizeInteiro4Tamanho Máximo da Mensagem: O tamanho máximo da mensagem que o remetente dessa mensagem pode receber. O valor mínimo desse campo é 484.
Msg FlagsOcteto1Sinalizadores de Mensagem: Um conjunto de sinalizadores que controlam o processamento da mensagem. A estrutura atual desse campo está descrita na Tabela 11.
Msg Security ModelInteiro4Modelo de Segurança da Mensagem: Um valor inteiro que indica qual modelo de segurança foi usado para essa mensagem. Para o modelo de segurança baseado em usuários (o padrão do SNMPv3) este valor é 3.
Msg Security ParametersVariávelParametros de Segurança da Mensagem: Um conjunto de campos que contêm parâmetros requeridos para implementar o modelo de segurança em particular usado na mensagem. Os conteúdos desse campo são especificados em cada documento que descreva um modelo de segurança do SNMPv3. Por exemplo, os parâmetros para o modelo baseado em usuários estão na RFC 3414.
Scoped PDUVariávelPDU Com Escopo: Contém o PDU que será transmitido, juntamente com parâmetros que identificam um contexto SNMP. Esse contexto descreve um conjunto de informações gerenciais acessíveis à uma entidade em particular. O PDU é chamado “Com Escopo” porque está aplicado dentro do escopo de um contexto. Este campo pode ou não estar criptografado dependendo do valor do sinalizador Priv Flag. A estrutura deste campo está descrita na Tabela 12.

Tabela 10: Formato da mensagem do SNMPv3.

Nome do SubcampoTamanho (bytes)Descrição
Reserved5/8
(5 bits)
Reservado: Reservado para uso futuro.
Reportable Flag1/8
(1 bit)
Sinalizador de Resposta: Quando igual a 1, um dispositivo recebendo esta mensagem deve enviar de volta um PDU Report quando determinada condição for alcançada que demande a geração do PDU.
Priv Flag1/8
(1 bit)
Sinalizador de Privacidade: Quando igual a 1, indica que foi usada criptografia para proteger a privacidade da mensagem. Somente pode ser igual a 1 quando o Auth Flag também for igual a 1.
Auth Flag1/8
(1 bit)
Sinalizador de Autenticação: Quando igual a 1, indica que autenticação foi usada para proteger a autenticidade da mensagem.

Tabela 11: Descrição dos sinalizadores de mensagem (Message Flags).

Nome do SubcampoTipoTamanho(bytes)Descrição
Context Engine IDString de OctetosVariávelContext Engine ID: Usado para identificar para qual aplicação o PDU será entregue para processamento.
Context NameString de OctetosVariávelNome do Contexto: Um identificados de objeto que especifica o contexto associado ao PDU.
PDUVariávelPDU: A unidade de dados do protocolo sendo transmitida.

Tabela 12: Descrição do campo PDU Com Escopo (Escoped PDU).

4.2.1. Os tipos de PDU e seus formatos

Como o SNMPv3 utiliza as mesmas operações do SNMPv2, a RFC 3416 que define os formatos de PDU do SNMPv3 é apenas uma atualização da RFC 1904. Sendo assim os PDUs do SNMPv3 são iguais aos do SNMPv2 listados anteriormente.

4.3. Mecanismos de segurança

Antes de começar a descrever os mecanismos de segurança definidos no SNMPv3, é interessante relacionar os novos termos que foram inseridos nessa versão e que estão associados a várias questões de segurança.

  • snmpEngineID: um identificador único e livre de ambigüidade atribuído a um engine SNMP. Serve também para identificar a entidade SNMP que contem o engine, visto que a relação de um-para-um entre engines e entidades.
  • contextEngineID: identifica unicamente uma entidade SNMP que pode conter uma instância de um context com um contextName particular.
  • contextName: identifica um contexto particular dentro de um engine SNMP. Ele á passado como parâmetro para o Despachante e o Subsistema de controle de acesso.
  • principal: a entidade em nome da qual os serviços são providos ou o processamento ocorre. Um principal pode ser um indivíduo atuando com um papel particular; um conjunto de indivíduos, com cada um atuando com um papel particular; uma aplicação ou conjunto de aplicações; uma combinação destes.
  • securityName: uma string legível que representa um principal. Ela é passada como parâmetro em todas as primitivas SNMP (Despachante, Processamento de Mensagens, Segurança e Controle de Acesso).

4.3.1. O modelo de segurança baseado em usuários

A RFC 2274 define o modelo de segurança baseado em usuários (USM). O USM provê serviços de autenticação e privacidade ao SNMP. Especificamente, o USM foi projetado para fornecer segurança contra as seguintes principais ameaças:

  • Modificação de Informação: uma entidade poderia alterar uma mensagem em transito gerada por uma entidade autorizada de forma a conseguir acesso não autorizado às operações gerenciais, inclusive alterar valores dos objetos. A essência desse ameaça é que uma entidade não autorizada poderia alterar qualquer parâmetro gerencial, inclusive os relacionados a configuração, operação e contabilização.
  • Mascaramento: operações gerenciais que não são permitidas para uma dada entidade podem ser executadas por essa entidade caso ela assuma a identidade de uma entidade autorizada.
  • Modificação da Cadeia de Mensagem: o SNMP foi projetado para operar sobre um protocolo de transporte não orientado a conexão. Existe uma ameaça em que mensagens SNMP poderiam ser reordenadas, atrasadas ou repetidas (duplicadas) para efetuar operações gerenciais não autorizadas. Por exemplo, uma mensagem para reiniciar um dispositivo poderia ser copiada e repetida posteriormente.
  • Descoberta: uma entidade poderia observar trocas de mensagens entre gerente e agente e dessa forma, descobrir valores de objetos gerenciais e notificações de eventos. Por exemplo, a observação de um comando Set que altere alguma senha habilitaria um atacante a descobrir a nova senha.

O USM não tem como objetivo oferecer segurança para as seguintes ameaças:

  • Negação de Serviço (Denial of Serviçe – DoS): um atacante pode evitar a troca de mensagens entre um gerente e um agente.
  • Analise de Tráfego: um atacante poderia observar a forma genérica como se comporta o trafego entre um gerente e um agente.

A falta de um contador para evitar as ameaças do tipo DoS pode ser justificada de duas formas: primeiro, os ataques do tipo DoS, em muitos casos, não podem ser distinguidos do tipo de falha de rede para a qual uma aplicação de gerência de rede deve saber lidar; e segundo, um ataque do tipo DoS tem como objetivo impedir toda troca de informações, portanto é uma questão pra ser tratada por uma solução de segurança mais abrangente, não apenas para uma que esteja embutida dentro de um protocolo de gerenciamento. Quanto à análise de trafego, muitas das características do tráfego de gerenciamento de rede são previsíveis (por exemplo, entidades podem ser gerenciadas via comandos SNMP que são enviados de forma regular por uma ou mais estações de gerenciamento) e dessa forma não há nenhuma vantagem significativa em proteger contra esse tipo de observação.

4.3.2. O modelo de segurança baseado em visões

Controle de acesso é uma função de segurança executada em nível de PDU. Um documento de controle de acesso define mecanismos para determinar se um acesso a um objeto gerenciado na MIB local pode ser permitido para um determinado sistema remoto. É concebível que vários mecanismos de controle de acesso podem ser definidos. A documentação do SNMPv3 define o Modelo de Segurança Baseado em Visões (VACM).

O VACM tem duas principais características:

  • O VACM determina se o acesso a um objeto gerenciado na MIB local deve ser acessado por um sistema remoto;
  • O VACM faz uso de uma MIB que:
    • Define a política de controle de acesso para o agente
    • Torna possível a utilização de configuração remota.

A RFC 2275 define cinco elementos que compõe o VACM: grupos, níveis de segurança, contextos, visões MIB e políticas de acesso.

4.3.2.1. Grupos

Um grupo é definido como um conjunto de zero ou mais duplas do tipo , com base nas quais os objetos gerenciados do SNMP podem ser acessados. Um securityName se refere a um principal, e os direitos de acesso para todos os principais em um dado grupo são idênticos. Um groupName único é associado a cada grupo. O conceito de grupo é uma ferramenta útil para categorizar gerentes com respeito a seus direitos de acesso. Por exemplo todos os gerentes de alto nível têm um determinado conjunto de direitos de acesso, enquanto os gerentes de nível intermediário têm um conjunto de direitos de acesso completamente diferente.

Uma determinada combinação de securityModel e securityName pode pertencer a no máximo um grupo. Ou seja, para um agente, um determinado principal cuja comunicação está protegida por um determinado securityModel pode apenas estar incluído em um grupo.

4.3.2.2. Níveis de Segurança

Os direitos de acesso para um grupo podem variar de acordo com o nível de segurança da mensagem que contém a requisição. Por exemplo, um agente pode permitir um acesso de somente leitura para uma requisição comunicada em uma mensagem não autenticada, mas pode requerer autenticação para permitir acesso de escrita. Dessa forma, para certos objetos críticos, o agente pode requerer que a requisição e sua resposta sejam transmitidas usando serviço de segurança.

4.3.2.3. Contextos

Um contexto é um subconjunto nomeado das instâncias de objetos na MIB local Os contextos provêm uma maneira de agregar objetos em coleções com diferentes políticas de acesso.

O contexto é um conceito que está relacionado com o controle de acesso. Quando uma estação gerente interage com um agente para acessar informações gerenciadas, essa interação ocorre entre um principal do gerente e o engine SNMP do agente, e os privilégios de controle de acesso são expressados em uma visão MIB que se aplica a esse principal e a esse contexto. Contextos têm as seguintes características:

  • Uma entidade SNMP, identificada unicamente por um contextEngineID, pode manter mais de um contexto;
  • Um objeto ou uma instância de objeto pode aparecer em mais de um contexto;
  • Quando múltiplos contextos existirem, para identificar uma instância individual de um objeto, o seu contextName e contextEngineID precisam ser identificados além do seu tipo de objeto e sua instância.

4.3.2.4. Visões MIB

São freqüente as situações em que desejamos restringir o acesso de um grupo em particular a um subconjunto dos objetos gerenciados de um agente. Para alcançar esse objetivo, o acesso a um contexto é executado através de uma visão MIB, que define um conjunto específico de objetos gerenciados (e opcionalmente instâncias específicas de objetos). O VACM faz uso de uma técnica poderosa e flexível para definir visões MIB, baseada no conceito de visão de subárvore e visão de famílias. A visão MIB é definida nos termos de uma coleção, ou família, ou subárvores, com cada subárvore sendo incluída ou excluída da visão.

Os objetos gerenciados de uma base local são organizados de forma hierárquica (em forma de árvore), baseado nos identificadores de cada objeto. Essa base local compreende um subconjunto de todos os tipos de objetos definidos de acordo com o SMI (Structure of Management Information), e inclui instâncias de objetos cujos identificadores estão em conformidade com as convenções do SMI.

O SNMPv3 introduz o conceito de subárvore. Uma subárore é apenas um nó, e seus elementos subordinados, na hierarquia de nomes da MIB. De forma mais formal, uma subárvore pode ser definida como o conjunto de todos os objetos e instâncias de objetos que possuem um mesmo Identificador de Objeto ASN.1 como prefixo de seus nomes. O mais longo prefixo em comum de todas as instancias de uma subárvore é o identificador de objeto do nó pai dessa subárvore.

A cada entrada na vacmAccessTable estão associadas três visões MIB, cada uma para um tipo de acesso (leitura, escrita e notificação). Cada visão MIB consiste em um conjunto de visões de subárvores. Cada visão de subárvore na visão MIB é especificada como sendo incluída ou excluída. Ou seja, a visão MIB inclui ou exclui todas as instâncias de objetos contidas em uma subárvore. Além disso, uma máscara de visão é definida para reduzir a quantidade de informações de configuração necessárias quando uma maior granularidade é requerida (por exemplo, controle de acesso ao nível de uma instância de objeto).

4.3.2.5. Políticas de Acesso

O VACM permite ao engine SNMP ser configurado de forma a aplicar um conjunto específico de direitos de acesso. A determinação do acesso depende dos seguinte fatores:

  • principal que está fazendo a requisição de acesso. O VACM torna possível que um agente permita diferentes privilégios de acesso para usuários diferentes. Por exemplo, um sistema gerente responsável pela configuração de toda uma rede pode ter uma vasta autoridade para alterar itens nas MIBs locais, enquanto um gerente de nível intermediário com responsabilidade de monitoramento pode direito de leitura apenas, e pode ainda ser limitado a acessar apenas um subconjunto das MIBs locais. Como visto anteriormente, principais são atribuídos a grupos a as políticas de acesso são especificadas com relação a grupos.
  • nível de acesso pelo qual a requisição foi comunicada em uma mensagem SNMP. Normalmente um agente vai requerer o uso de autenticação para mensagens contendo uma requisição do tipo set (operação de escrita).
  • modelo de segurança usado para processar a mensagem de requisição. Se um agente implementa múltiplos modelos de segurança, o agente pode ser configurado para prover diferentes níveis de acesso para as requisições que foram comunicadas por mensagens processadas por diferentes modelos de segurança. Por exemplo, certos itens podem estar acessíveis caso a requisição veio em uma mensagem que deve ser processada pelo USM, mas podem não estar acessíveis se forem processadas pelo modelo do SNMPv1.
  • contexto MIB da requisição.
  • instância de objeto específica para a qual o acesso está sendo requerido. Alguns objetos carregam informações mais críticas ou sensíveis do que outros, e dessa forma a política de acesso deve depender especificamente da instância de objeto que está sendo requisitada.
  • tipo de acesso requisitado (leitura, escrita ou notificação). A leitura, a escrita e a notificação são operações gerenciais distintas e políticas de controle de acesso diferentes precisam ser aplicadas para cada uma dessas operações.

5. Conclusão

Com base nas informações apresentadas pode-se verificar que o SNMPv3 possui várias características que o torna muito mais seguro que suas versões anteriores, no entanto esse benefício de segurança vem acompanhado de uma maior complexidade para configurar todas as funcionalidades de segurança necessárias.

Dessa forma, para ambientes em que haja necessidade de uma implementação rápida e que segurança não seja uma questão crítica, é justificado o uso do SNMPv1, ou preferencialmente, do SNMPv2c.

No entanto, para ambientes em que a segurança é uma questão crucial, se faz necessário a utilização do SNMPv3, para que nem os dispositivos gerenciados nem as informações gerenciais sejam comprometidas.

6. Referências

STALLINGS, WILLIAN – SNMPv3: A Security Enhancement for SNMP, http://www.comsoc.org/livepubs/surveys/public/4q98issue/stallings.html – Acessado em 25/04/2008.

STALLINGS, WILLIAN – SNMP, SNMPv2, SNMPv3, RMON AND RMON2 Pratical Network Management. 3.ed. USA:Addison- Wesley, 1999.

TCP/IP Guide – http://www.tcpipguide.com/free/t_TCPIPSimpleNetworkManagementProtocolSNMPProtocol.htm – Acessado em 25/04/2008.

Leave a Reply

Your email address will not be published. Required fields are marked *

three × four =