O Protocolo SNMP


O protocolo SNMP (do inglês Simple Network Management Protocol – Protocolo Simples de Gerência de Rede) é um protocolo de gerência típica de redes UDP, da camada de aplicação, que facilita o intercâmbio de informação entre os dispositivos de rede, como placas e comutadores (em inglês: switches). O SNMP possibilita aos administradores de rede gerenciar o desempenho da rede, encontrar e resolver seus eventuais problemas, e fornecer informações para o planejamento de sua expansão, dentre outras.

Agentes e Gerentes
Toda aplicação de gerência de redes é baseada na troca de informações entre um agente e um gerente, sendo que cada um possui as seguintes características:

  • Agente: Mantém informações relativas ao funcionamento dos dispositivos em objetos de informação que são armazenados na MIB (Management Information Base) do dispositivo. Realiza operações de gerenciamento sobre estes objetos atendendo a solicitações enviadas pelo gerente. Também pode enviar informações de alerta sem prévia solicitação, no caso de falhas.
  • Gerente: Normalmente executado em NMSs (Network Management Stations), coleta informações sobre os objetos gerenciados junto aos agentes, processa as informações e solicita aos agentes que execute as funções de gerenciamento a fim de controlar o funcionamento do objeto gerenciado.

Figura 1

Como pode ser visto na Figura 1, o agente e gerente se comunicam através de operações e notificações definidas pelo protocolo de comunicação. O protocolo apresentado neste trabalho é o SNMP (RFC1157). As informações sobre objetos gerenciados são armazenadas na MIB, que contém informações sobre o funcionamento dos dispositivos (hosts, gateways) e dos processos que executam os protocolos de comunicação (IP, TCP, ARP, etc). A MIB é especificada pela SMI (Structure of Management Information – RFC 2578) e descrita em ASN.1 (Abstract Syntax Notation One). O SNMP permite que o gerente solicite ao agente a informação ou a modificação do valor de um objeto de informação da MIB. O SNMP define também uma operação que permite ao agente informar o gerente sobre a ocorrência de um evento específico.
SNMPv1, SNMPv2
A padronização da primeira versão do protocolo SNMP foi publicada em maio de 1990, através da RFC 1157. Em abril de 1993, as RFCs 1442 a 1444 foram publicadas, tornando-se obsoletas com as publicações das respectivas RFCs: 1902 a 1907, que, por sua vez, se tornaram obsoletas pelas RFCs 2578, 2579 e 2580. A terceira versão SNMP, surge em abril de 1999, com a RFC 2574, que foi substituída posteriormente pela RFC 3414.
A estratégia implícita no SNMP é que o monitoramento do estado da rede num determinado nível de detalhes seja realizado primeiramente por uma lista de informações apropriadas. Um número limitado de mensagens esporádicas guia o tempo e o foco da lista. Limitando o número dessas mensagens (traps) torna-se consistente, com a característica de simplicidade e redução do tráfego gerado pela função de gerenciamento da rede.
A arquitetura SNMP admite uma variedade de relacionamentos administrativos entre entidades que participam no protocolo. As entidades que residem nas estações de gerência e os elementos da rede que se comunicam usando o protocolo SNMP são rotulados entidades de aplicação SNMP. Os processos ponto a ponto que implementa o SNMP, e consequentemente suportam as entidades de aplicação SNMP, são rotulados entidades do protocolo.
A combinação de agentes com algum conjunto arbitrário de entidades de aplicação SNMP é chamado comunidade SNMP. Cada comunidade SNMP é nomeada por uma string de octetos.
Uma mensagem SNMP originada por uma entidade de aplicação SNMP, que de fato pertença a uma comunidade SNMP, nomeada pela mensagem indicativa de componente da comunidade, é chamada mensagem SNMP. O conjunto de regras para que uma mensagem SNMP seja identificada como uma mensagem autêntica para uma comunidade particular é chamado de esquema de autenticação. E, uma implementação da função que identifica mensagens autênticas de acordo com um ou mais esquemas é chamado de serviço de autenticação.
O efetivo relacionamento administrativo entre entidades de aplicação requer serviço de autenticação, podendo usar criptografia ou outra técnica, que seja capaz de identificar mensagens autênticas com certo grau de certeza. No SNMPv3, a mensagem é criptografada com Data Encryption Standard (DES), que cifra os dados a serem transmitidos através de uma chave secreta. Para alguns elementos da rede, o subconjunto de objetos contidos em suas MIBs são chamados visões da MIB.
Os elementos do conjunto como somente de leitura, ou de leitura e escrita são chamados modo de acesso. E, a combinação do modo de acesso com a visão MIB é chamada perfil da comunidade. Um perfil de comunidade SNMP representa os privilégios de acesso especificados para as variáveis na visão MIB.
A combinação de uma comunidade SNMP com um perfil da comunidade SNMP é chamada política de acesso, que representa um perfil de comunidade específica, permitido para um agente SNMP da comunidade especificada, para outros membros daquela comunidade.
A diferença entre os dois tipos de acesso aos dados da MIB SNMPv1 e SNMPv2 são: valores dos status de erros gerados; geração de códigos de exceção; uso do tipo de dado Counter64; formato dos parâmetros proporcionados quando uma notificação é gerada.
O acesso aos dados na MIB com base no SNMPv1, pode gerar valores de erros de status SNMPv1, mas nunca gerará códigos de exceção nem uso do tipo de dados Counter64, e proporcionará parâmetros no formato SNMPv1 para geração de notificações. Ele também nunca gerará um erro readOnly (somente de leitura), mas sim noSuchName em seu lugar.
Os parâmetros de notificação SNMPv1 consistem de: um parâmetro de negócio (OBJECT IDENTIFIER); um parâmetro de endereço do agente (endereço de rede); um parâmetro de trap genérica (INTEGER); um parâmetro de trap específica (INTEGER); um parâmetro de tempo (TimeTicks); e uma lista de variáveis de ligação (VarBindList).
Já o acesso à MIB, com base no SNMPv2, pode gerar valores de erro de status SNMPv2 e código de exceção, usar tipo de dados Counter64 e proporcionar parâmetros no formato SNMPv2 para geração de notificações. E, ele nunca gerará erros readOnly, noSuchName, ou badValues.
Os parâmetros de notificação SNMPv2 consistem de: um parâmetro de tempo ativo do sistema (TimeTicks), aparecendo na primeira variável de ligação da trap ou solicitação de informação; um parâmetro de identificação da trap SNMP (OBJECT IDENTIFIER); e uma lista de variáveis de ligação (VarBindList).
SNMPv3
A RFC 3414 descreve as características de segurança incorporada ao SNMPv3, como o uso Hashed Message Authentication Code – Message Digests 5 – 96 (HMAC-MD5-96) e Hashed Message Authentication Code – Secure Hash Algorithm – 96 (HMAC-SHA-96) como protocolos de autenticação, e o uso do Cipher Block Chaining – Data Encryption Standard (CBC-DES) como protocolo de privacidade. O User-based Security Model (USM) permite, então, que outros protocolos sejam usados com o SNMP ao invés de concorrer com eles.
Várias ameaças clássicas para protocolos de rede são aplicáveis ao problema de gerenciamento de rede, e, portanto são também aplicáveis ao modelo de segurança utilizado no SNMPv1 e SNMPv2. Algumas dessas ameaças podem ser citadas:

  • Modificação da informação: algumas entidades desautorizadas poderiam alterar mensagens SNMP em trânsito geradas em interesse de um principal autorizado, e efetuar operações de gerência indesejadas como incluir valores falsos nos objetos;
  • Masquerade: operações de gerenciamento não autorizadas por algum usuário podem ser tentadas com a identidade de algum outro usuário que tem autorizações apropriadas;
  • Divulgação: o perigo de alguém monitorar as trocas e negociações entre agentes e estação de trabalho.
  • Modificação da sequência da mensagem: visto que o serviço de transporte do protocolo SNMP não é orientado a conexão, a reordenação, o retardo, ou o reenviou de mensagens pode provocar anomalias nas operações do protocolo.

Pelo menos dois tipos de ameaça ao modelo de segurança SNMPv3 não são abordados pela sua especificação:

  • Negação de serviço: o atual modelo do protocolo SNMPv3 não tenta proteger de uma ampla série de ataques, para que serviços em nome de usuários autorizados não sejam negados. De fato, ataques de negação de serviços são, em muitos casos, indistinguíveis de certos tipos de falhas de rede;
  • Análises de tráfego: muitos padrões de tráfego são preditíveis. Dispositivos podem ser gerenciados numa base regular por um número relativamente pequeno de aplicações. Além disso, não há vantagens significativas para proteger contra ataque de análise de tráfego.

Structure of Management Information – SMI
É o mecanismo utilizado para definição da estrutura da Base de Informações Gerenciais e permite a especificação formal da sintaxe e identificação dos objetos SNMP componentes de uma MIB:

  • Tipo;
  • Restrições de Acesso;
  • Identificação (OBJECT IDENTIFIER).

O SNMP é usado para gerenciar uma ampla variedade de objetos MIB, e há a necessidade de uma identificação única para cada objeto gerenciado, especificando a sintaxe e identificação dos mesmos.
A linguagem ASN.1 (Abstract Syntax Notation One), definida pela ISO, é usada para definir as informações trocadas entre protocolos, sob a forma de uma sintaxe abstrata, sem levar em conta a arquitetura de uma máquina especifica, ela não permite qualquer ambiguidade na informação que representa. Há duas possibilidades de representação da informação (vide figura 2 com árvore de Identificação OID):
Nome do objeto: representação pontuada dos mnemônicos que definem a hierarquia do objeto, sendo de fácil leitura pelas pessoas (iso.org.dod.internet.mgmt.mib-2.system.sysUpTime);
Identificação do Objeto (Object ID): forma codificada, utilizada pelo protocolo de comunicação (1.3.6.1.2.1.1.3).

Figura 2

Abaixo da subárvore MIB II estão os objetos usados para obter informações específicas dos dispositivos da rede. Esses objetos estão divididos em 10 grupos:
system (1) – informações básicas do sistema;
interfaces (2) – interfaces de rede;
at (3) – tradução de endereços;
ip (4) – protocolo ip;
icmp (5) – protocolo icmp;
tcp (6) – protocolo tcp;
udp (7) – protocolo udp;
egp (8) – protocolo egp;
transmission (10) – meios de transmissão;
snmp (11) – protocolo snmp.
Alguns dos objetos pertencentes aos grupos da MIB II são:
Grupo System (1.3.6.1.2.1.1)
sysDescr (1.3.6.1.2.1.1.1): Descrição textual da unidade. Pode incluir o nome e a versão do hardware, sistema operacional e o programa de rede.
sysUpTime (1.3.6.1.2.1.1.3): Tempo decorrido (em centésimos de segundos) desde a última inicialização do gerenciamento do sistema na rede.
sysContact (1.3.6.1.2.1.1.4): Texto de identificação do gerente da máquina gerenciada e como contatá-lo.
Grupo Interfaces (1.3.6.1.2.1.2)
ifNumber (1.3.6.1.2.1.2.1): Número de interfaces de rede (não importando seu atual estado) presentes neste sistema.
ifOperStatus (1.3.6.1.2.1.2.2.1.8): Estado atual da interface.
ifInOctets (1.3.6.1.2.1.2.2.1.10): Número total de octetos recebidos pela interface.
Grupo IP (1.3.6.1.2.1.4)
ipForwarding (1.3.6.1.2.1.4.1): Indica se esta entidade é um gateway.
ipInReceives (1.3.6.1.2.1.4.3): Número total de datagramas recebidos pelas interfaces, incluindo os recebidos com erro.
ipInHdrErrors (1.3.6.1.2.1.4.4): Número de datagramas que foram recebidos e descartados devido a erros no cabeçalho IP.
Grupo ICMP (1.3.6.1.2.1.5)
icmpInMsgs (1.3.6.1.2.1.5.1): Número total de mensagens ICMP recebidas por esta entidade. Incluindo aquelas com erros.
icmpOutMsgs (1.3.6.1.2.1.5.14): Número total de mensagens ICMP enviadas por esta entidade. Incluindo aquelas com erros.
Grupo TCP (1.3.6.1.2.1.6)
tcpMaxConn(1.3.6.2.1.6.4): Número máximo de conexões TCP que esta entidade pode suportar.
tcpCurrentEstab (1.3.6.2.1.6.9): Número de conexões TCP que estão como estabelecidas ou a espera de fechamento.
tcpRetransSegs (1.3.6.2.1.6.12): Número total de segmentos retransmitidos.
Grupo UDP (1.3.6.1.2.1.7)
udpInDatagrams (1.3.6.1.2.1.7.1): Número total de datagramas UDP entregues aos usuários UDP.
udpNoPorts (1.3.6.1.2.1.7.2): Número total de datagramas UDP recebidos para os quais não existia aplicação na referida porta.
udpLocalPort (1.3.6.1.2.1.7.5.1.2): Número da porta do usuário UDP local.
Grupo SNMP (1.3.6.1.2.1.11)
snmpInPkts (1.3.6.1.2.1.11.1): Número total de mensagens recebidas pela entidade SNMP.
snmpOutPkts (1.3.6.1.2.1.11.2): Número total de mensagens enviadas pela entidade SNMP.
snmpInTotalReqVars (1.3.6.1.2.1.11.13): Número total de objetos da MIB que foram resgatados pela entidade SNMP.
Formato das Mensagens SNMP
O SNMP é um protocolo da camada de aplicação agindo na troca de informações de gerenciamento entre dispositivos de rede.
As funções básicas do SNMP são:

  • Get: utilizado para se obter um valor do objeto escalar de um agente;
  • Set: utilizado para se atribuir um valor a um objeto escalar de um agente;
  • Trap: utilizado pelo agente para encaminhar um evento (objeto) não solicitado para uma estação de gerenciamento da rede.

Normalmente, o SNMP utiliza as portas UDP 161 para agente e 162 para o gerente. O gestor pode enviar solicitações de qualquer porta disponível (porta de origem) até a porta 161 no agente (porta de destino). A resposta do agente será reportada de volta a porta de origem. O Gestor receberá traps na porta 162. O agente pode gerar as traps de qualquer porta disponível. Muitas distribuições podem mudar isso, porém essa alteração não é sempre necessariamente verdade.
O SNMP utiliza como serviço de autenticação e controle de acesso uma forma primitiva e limitada chamada de comunidade SNMP (Community). Cada mensagem SNMP, ao ser encaminhada para o agente, contém a Community que será utilizado como parâmetro de identificação.
Através da definição de uma comunidade, um agente pode limitar o acesso a um conjunto selecionado de estações gerentes, à visão de um subconjunto de objetos de uma MIB e ao modo de acesso (READ-ONLY ou READ-WRITE).
As mensagens trocadas durante a comunicação entre os agentes e os gerentes são divididas em cinco tipos, vide figuras 3 e 4:

  • GetRequest – solicita a informação sobre um objeto escalar;
  • GetNextrequest – solicita informação sobre o próximo objeto escalar;
  • GetResponse – resposta da solicitação;
  • SetRequest – atribui um valor escalar a um objeto;
  • Trap – utilizado pelo agente para encaminhar uma notificação para um gerente.

 

Figura 3 – Arquitetura SNMP

Figura 4 – Formato das mensagens SNMP

 
O presente post é parte do Trabalho de Conclusão de Curso (TCC) de Eduardo do Nascimento Pureza ([email protected]), com a sua devida autorização para a publicação em nosso Portal. Espero que tenham gostado do Post, não se esqueçam de assinar o Portal e continuem votando no topblog.
 
 

Share

    Comments

    1. Ricardo Pinheiro, bom dia, parabéns pela iniciativa e obrigado pela divulgação.
      Abs
      Eduardo Pureza

    2. Riqueza de detalhes. Parabéns!

    3. Já ouviu falar no “The dude”, pelo que li não tem muito com o seu post, mas é uma dica de “monitoramento” também…. The Dude… é free até onde eu sei! 🙂

      • Walter,
        Não conhecia, percebi que é uma ferramenta da mesma equipe do mikrotik é desenvolvido para Windows, mas até a versão 3.5 pode rodar no GNU/Linux via wine. Vamos analisar a ferramenta e testar suas funcionalidades e quem sabe podemos criar um post sobre ele.
        Abraços

    4. […] Enviado por Ricardo Pinheiro (ricardoΘcooperati·com·br): “”Gradativamente, durante anos, têm-se notado uma atenção especial as redes de computadores. A cada dia, as organizações estão mais dependentes aos recursos providos pelos computadores. Com esta expansão, a possibilidade de ocorrerem problemas também aumenta, podendo levar as redes a um estado de inoperância ou a níveis inadequados de desempenho. Com isso, a necessidade de um melhor controle sobre seus recursos se faz necessário. Apresento com riqueza de detalhes, nesse artigo, o Protocolo SNMP.”” [referência: cooperati.com.br] […]

    5. […] Enviado por Ricardo Pinheiro (ricardoΘcooperati·com·br): “”Gradativamente, durante anos, têm-se notado uma atenção especial as redes de computadores. A cada dia, as organizações estão mais dependentes aos recursos providos pelos computadores. Com esta expansão, a possibilidade de ocorrerem problemas também aumenta, podendo levar as redes a um estado de inoperância ou a níveis inadequados de desempenho. Com isso, a necessidade de um melhor controle sobre seus recursos se faz necessário. Apresento com riqueza de detalhes, nesse artigo, o Protocolo SNMP.”” [referência: cooperati.com.br] […]

    6. Muito bom o artigo, parabéns!!

    7. Excelente,
      conseguiu tirar a minha dúvida sobre uma questão que caiu na prova do SENADO.

    8. Boa tarde Ricardo.
      Estou montando uma rede virtual no VB para testes de monitoramento.
      Criei uma VM com o Centreon CES(Servidor de monitoramento) que é uma versão do Nagios+FrontEnd para acesso via browser. É uma ISO.
      Criei duas VMs, uma com Ubuntu Server 10.04 32 e outra com o Ubuntu Desktop 10.04 ambas de 32 bits.
      Criei duas VMs, uma com Windows 2008 e a outra com o Windows 7 Professional ambas de 32 bits.
      Nas máquinas windows há uma opção de se ativar o protocolo SNMP para monitoramento.
      Nas Linux tenho que instalar o pacote.
      Minha dúvida é:
      Existem dois pacotes distintos o SNMP e o SNMPd.
      Pelo que entendo o SNMPd é o daemon que monitora e que também foi instalado no Centreon(Obs: Este tem como base um CentOS) quando da instalação.
      No meu caso qual dos dois pacotes acima terei que instalar nas estações e servidores para que o Centreon possa monitorá-las?
      Como faço a configuração nas máquinas clientes?
      Sem mais.

      • Marcos,
        Você tem que instalar o snmpd que é o servidor de snmp, assim ele abre a porta para receber as consultas feitas através do protocolo snmp.
        No arquivo basta liberar o acesso a porta para toda a rede, geralmente vem liberado acesso pela 127.0.0.1.

    Deixe um comentário

    O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

    © 2019 All Rights Reserved. Cooperati. 

    %d blogueiros gostam disto: