CINARA BRENDA ZERBINI

SURVEY PROTOCOLO DE GERENCIAMENTO SNMP

LONDRINA–PR
2017
 SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 CONTEXTUALIZAÇÃO HISTÓRICA . . . . . . . . . . . . . 5

3 O PROTOCOLO SNMP . . . . . . . . . . . . . . . . . . . . . . 7

4 MANAGEMENT INFORMATION BASE . . . . . . . . . . . . 9

4.1 Estrutura da MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 OPERAÇÕES SNMP . . . . . . . . . . . . . . . . . . . . . . . . 13

6 VERSÕES DO PROTOCOLO SNMP . . . . . . . . . . . . . . 15

6.1 SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.1 Mensagens SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2 SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3 SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7 SISTEMA DE GERENCIAMENTO DE REDE (NMS) . . . . 19

^
REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
 3

1 INTRODUÇÃO

Com o crescimento da internet, diversos segmentos da sociedade utilizam a rede

mundial de computadores, aumentando assim, a quantidade de switches, roteadores, ser-
vidores e hosts na rede. Atualmente, diversos serviços são disponibilizados por meio da
rede, de maneira que é necessário que exista um gerenciamento e monitoramento dos
dispositivos contidos nesta rede, de forma a manter a qualidade dos serviços, proteger
informações importantes, evitar acessos indevidos, detectar agentes maliciosos e monito-
rar o uso da rede. Com base nisto, no final da década de 80, surgiu o protocolo SNMP
(Simple Network Management Protocol), que, por meio de uma implementação simples e
computacionalmente leve, coleta informações do tráfego da rede.
O SNMP segue um conjunto de padrões para o gerenciamento de redes, incluindo
um protocolo, uma especificação de uma estrutura de base de dados [1].
O SNMP possui tr^es versões, o SNMPv1, o SNMPv2 e o SNMPv3. Para visualizar
e analisar as informações coletadas utiliza-se o sistema de gerenciamento de rede, definido
pelo acr^onimo NMS (Network Management System).
Nas seções a seguir serão apresentados os principais conceitos à respeito do proto-
colo de gerenciamento SNMP, organizadas da seguinte forma: a seção 2 fará uma breve
contextualização histórica, a seção 3 abordará os principais conceitos acerca do funcio-
namento e da estruturação do protocolo SNMP, a seção 4 falará da MIB (Management
Information Base - base de gerenciamento de informações), a seção 5 mostrará as prin-
cipais operações presentes no protocolo SNMP, a seção 6 abordará as diferentes versões
do SNMP, apresentando suas diferenças e melhorias, e por fim, a seção 7 falará sobre os
NMS, apresentando os principais conceitos e sistemas existentes.
 5

2 CONTEXTUALIZAÇÃO HISTÓRICA

O protocolo SNMP surgiu no final da década de 80, desenvolvido pela IETF (Inter-
net Engineering Task Force). A base para o desenvolvimento do SNMP foi um protocolo
de monitoração de gateways IP, o SGMP (Simple Gateway Management Protocol). O
modelo SNMP possui uma abordagem genérica, podendo ser utilizado para gerenciar di-
ferentes tipos de sistemas. A seguir serão apresentadas as principais versões de SNMP
lançadas e suas respectivas RFC’s (Request for Comment) [2] [3].

∙ Padronização SNMPv1 – 1990 (RFC 1157)

∙ Padronização MIB-I – 1990 (RFC 1156)

∙ Padronização MIB-II – 1991 (RFC 1213)

∙ Padronização SNMPv2 – 1993 (RFC 1442)

∙ Padronização SNMPv3 – 2002 (RFC 3410-3418)

 7

3 O PROTOCOLO SNMP

O protocolo SNMP surgiu com um conjunto de operações simples que permitem

que dispositivos da rede sejam gerenciados de maneira remota. O SNMP utiliza o para-
digma de funcionamento gerente/agente de forma que a comunicação gerente/agente é
feita por meio do protocolo UDP (User Datagram Protocol). O protocolo UDP foi esco-
lhido em detrimento do protocolo TCP (Transport Control Protocol) por ser sem conexão,
ou seja, nenhuma conexão de ponta a ponta é feita entre o agente e o NMS quando pacotes
são enviados e recebidos. Este aspecto do UDP torna-o não confiável, uma vez que não há
reconhecimento de pacotes perdidos no nı́vel do protocolo. Depende da aplicação SNMP
determinar se os pacotes foram ou não perdidos e retransmiti-los se assim o desejar [2].
Para o envio de solicitações regulares (sı́ncronas), a caracterı́stica não confiável do
protocolo UDP não chega a ser um problema, no entanto, no envio de traps, a situação se
modifica um pouco, pois se um agente envia uma trap e ela nunca chega, a NMS não sabe
se essa trap sequer foi enviada, e nem o próprio agente detecta a necessidade de reenvio
desta trap. Outra vantagem do UDP é o baixo overhead, que gera um impacto menor no
desempenho da rede [1].
Como dito anteriormente o SNMP utiliza o paradigma gerente/agente para o ge-
renciamento da rede. Este paradigma utiliza basicamente tr^es componentes: o disposi-
tivo gerenciado, o gerente e o agente. Um dispositivo gerenciado é um nó da rede que
contém um agente SNMP responsável por reunir as informações sobre as operações do
nó e disponibilizá-los ao gerente. Esse agente utiliza chamadas de sistema para realizar o
monitoramento das informações do dispositivo onde se encontra, e utiliza as chamadas de
procedimento remoto (RPC – Remote Procedure Call) para o controle das informações do
dispositivo. Se ocorrer alguma exceção no dispositivo gerenciado, o agente fica responsável
por notificar o gerente através de uma interrupção trap. O gerente compreende um tipo de
software (NMS) que permite a obtenção e o envio de informações de gerenciamento dos
agentes por meio de comunicação com estes agentes. Um único gerente pode se comunicar
com diversos agentes [4] [5] [3].
A figura 1 apresenta o sistema de funcionamento da comunicação gerente/agente
As informações de gerenciamento trocadas entre agente e gerente são armazenadas na
MIB (Management Information Base), a qual será apresentada na seção 4.
8

Figura 1 – Comunicação gerente/agente. (Fonte: adaptado de [2])

 9

4 MANAGEMENT INFORMATION BASE

A MIB armazena as informações de objetos gerenciados, que podem ser definidos

como uma lista de variáveis. Esses objetos gerenciados são definidos conforme a neces-
sidade requerida para o monitoramento da rede. Esses objetos gerenciados podem ter
permissões para serem lidos ou alterados, sendo que cada leitura representará o estado
real do recurso e cada alteração também será refletida no próprio recurso [6] [7] [4].
A primeira versão da MIB, a MIB I, é definida pelo RFC 1066. Este padrão explicou
e definiu a base de informação necessária para monitorar e controlar redes TCP. A segunda
versão da MIB, a MIB II, foi definida pelo RFC 1213. A MIB II é considerada uma
evolução da MIB I e fornece informações gerais de gerenciamento sobre um determinado
dispositivo gerenciado. Através da MIB II podemos obter informações como: número de
pacotes transmitidos, estado da interface, entre outras coisas [7].
As regras de construção das estruturas da MIB são descritas pela SMI (Struc-
ture Management Information). A SMI é um método para definir os objetos gerenciados
e os seus respectivos comportamentos. Um agente possui uma lista de objetos por ele
rastreados.
Os objetos da MIB são especificados por meio da ASN.1 (Abstract Syntax Notation
One). Esta notação é uma forma de descrição abstrata dos dados com o objetivo de não
se levar em conta a estrutura e as particularidades e restrições contidas no equipamento
no qual está sendo implementada. Para cada objeto são definidas como variáveis básicas:

∙ Object Name: nome do objeto, é composto por uma string de texto curto;

∙ Object Identifier: identificador do objeto, é formado por números que são separados
por pontos;

∙ Syntax: é a sintaxe do objeto, descreve o formato, ou o valor da informação, que

pode ser: uma sintaxe do tipo simples (inteiro, string de octetos, Object Identifier
ou nulo) ou uma sintaxe de aplicação (endereço de rede, contador, medida, intervalo
de tempo ou incompreensı́vel;

∙ Definição: é uma descrição textual do objeto.

∙ Acesso: é o tipo de controle que se pode ter sobre o objeto, podendo ser: somente
leitura, leitura e escrita ou não acessı́vel.
10

4.1 Estrutura da MIB

A ISO (International Organization for Standardization) definiu uma árvore hierárquica

para representar a estrutura lógica da MIB. A figura 2 mostra esta estrutura [7].

Figura 2 – Árvore da MIB. (Fonte: adaptado de [7])

A árvore representada na figura 2 possui tr^es nós logo abaixo da raiz, sendo que
o nó CCITT é administrado pela Consultative Committe for International Telegraph and
Telephone; o nó ISO é administrado pela ISO; o nó CCITT/ISO conjunto é administrado
pela ISO e CCITT em conjunto. Sob o nó ISO fica o nó ORG, que pode ser utilizado
por outras instituições. Abaixo do nó ORG, fica o nó DOD, que pertence ao departa-
mento de defesa dos EUA. O departamento de defesa dos Estados Unidos alocou um nó
logo abaixo do nó DOD, que é o nó INTERNET, que é administrado pela International
Activities Board (IAB). Abaixo deste nó temos os nós DIRECTORY, MANAGEMENT,
EXPERIMENTAL e PRIVATE. No nó EXPERIMENTAL estão as MIBs experimentais,
no nó PRIVATE fica o nó ENTERPRISES que por sua vez possui os nós das indústrias
de equipamentos, o nó MANAGEMENT traz informações de gerenciamento, e é neste nó
que se encontra o nó MIB II [7].
Na sub árvore MIB II estão os objetos que trazem as informações especı́ficas dos
dispositivos gerenciados. Esses objetos se dividem em dez grupos, como pode ser verificado
na tabela 1 e na figura 3 [7].
 11

Figura 3 – Sub árvore do nó MIB II. (Fonte: adaptado de [7])

Tabela 1 – Nós da sub árvore do nó MIB II. Fonte: 7

Grupo Informação
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
 13

5 OPERAÇÕES SNMP

Até aqui, já verificamos que o SNMP utiliza o sistema gerente/agente para geren-
ciamento dos dispositivos da rede, e que as informações coletadas são armazenadas na
MIB, mas para que a comunicação seja realizada entre gerente e agente, são necessárias
algumas operações, entre as principais temos [7] [5]:

∙ Get Request: é utilizada pelo gerente para solicitar uma informação ao agente

∙ Get Response: o agente utiliza essa operação para responder ao comando get Request
do gerente

∙ Set Request: operação utilizada pelo gerente para modificar o valor de uma variável
de um objeto;

∙ Trap: a operação trap é utilizada pelo agente para notificar o gerente que algo errado
ocorreu; é uma operação assı́ncrona.
 15

6 VERSÕES DO PROTOCOLO SNMP

Na seção de contextualização histórica 2 foram listadas as tr^es versões do SNMP

que foram desenvolvidas. A seguir será apresentada uma descrição das tr^es versões, com
suas diferenças e melhorias.

6.1 SNMPv1

A padronização do SNMPv1 foi lançada no ano de 1990. Essa padronização está

definida no RFC 1157. A segurança do SNMPv1 é baseada em communities. As com-
munities t^em a função de definir a confiabilidade entre o gerenciadores e agentes. No
agente é configurado tr^es strings, que podem ser: read-only, que permite apenas a leitura
das variáveis de um objeto, read-write, que permite leitura e escrita (modificação) das
variáveis de um objeto, e trap, que permite o envio de traps do agente. Na maioria dos
equipamentos com suporte ao SNMP, o padrão para estas strings são: public para string
read-only e private para string read-write.
Na seção 5 foram definidas quatro operações consideradas as básicas no protocolo
SNMP, porém o protocolo SNMPv1 possui uma quinta operação, a operação get Next.
Que possui função similar a operação get, porém, o NMS envia essa operação com um
identificador de um determinado objeto, então o agente retorna (get Response) o valor do
objeto sucessor ao identificado na operação get Next.
As operações traps genéricas do protocolo SNMPv1 são apresentadas na tabela 2.

Tabela 2: Traps genéricas. Fonte: [1]

Nome e número da trap genérica Definição

ColdStart (0) Indica que o agente foi reini-
cializado. Todas as variáveis de
gerenciamento serão redefinidas;
Quando um novo hardware é adi-
cionado à rede esta instrução é
utilizada para detectar este dispo-
sitivo.
WarmStart (1) Indica que o agente reinicializou a
si mesmo. Nenhuma das variáveis
de gerenciamento será redefinida
16

LinkDown (2) Enviada quando uma interface

LinkUp (3)
AutenticationFailure (4)
EgpNeighborLoss (5)
EnterpriseSpecific (6)
em um dispositivo é paralisada. A
primeira vinculação de variáveis
identifica a interface inativa
Enviada quando uma interface
em um dispositivo é reativada. A
primeira vinculação de variáveis
identifica a interface reativada
Indica que alguém tentou consul-
tar o agente com uma string de
comunidade incorreta; útil para
detectar se alguém estiver ten-
tando obter acesso não autorizado
a um dos dispositivos
Indica que um vizinho do Exte-
rior Gateway Protocol (EGP) fi-
cou inativo
Indica que a trap é especı́fica de
empresa. Para processar esta trap
corretamente, a NMS deve codi-
ficar o número da trap especı́fica
que faz parte da mensagem do
SNMP

O SNMPv1 possui mensagens de erro, que são respostas de erro enviadas pelo
agente ao gerente, devido ao processamento incorreto do agente. A tabela 3 apresenta
essas mensagens de erro.

6.1.1 Mensagens SNMPv1

As mensagens trocadas entre gerente e agente possuem uma padronização, no

SNMPv1 as mensagens contém duas partes, um cabeçalho de mensageme um Protocol
Data Unit (PDU). As figuras 4 e 5 apresentam a estrutura geral de uma mensagem no
SNMPv1 e alguns exemplos de mensagens, respectivamente.

6.2 SNMPv2

A padronização SNMPv2, lançada em 1993 e definida pelo RFC 1442, é uma

evolução da versão inicial SNMPv1. O SNMPv2, além das operações já definidas na versão
 17

Tabela 3 – Mensagens de erro do SNMPv1. Fonte: 1

Mensagens de Erro do SNMPv1 Descrição

NotError(0) Solicitação executada
sem problemas
TooBig(1) Resposta à solicitação
muito grande para
acomodar em uma
única resposta
NoSuchName(2) Um agente foi solici-
tado a obter ou definir
uma OID (identifica-
dor de um objeto) não
encontrado, por exem-
plo, a OID não existe
BadValue(3) Objeto read-write ou
read-only definido
com valor inconsis-
tente
ReadOnly(4) Erro geralmente não
utilizado. Erro equiva-
lente: NoSuchName
0 Este é o erro genérico.
Se ocorrer um erro
para o qual não existe
uma mensagem ante-
rior adequada, é emi-
tido um erro gerError

Figura 4 – Estrutura de uma mensagem do SNMPv1. (Fonte: adaptado de [1])

anterior, possui duas novas operações, a operação get-bulk, que permite que um aplicativo
de gerenciamento recupere uma grande seção de uma tabela de uma só vez, e a operação
inform, que permite a comunicação entre gerenciadores [1].
As mensagens do SNMPv2 possuem o mesmo cabeçalho, porém a PDU possui
algumas diferenças. O SNMPv2 especifica dois formatos de PDU, a PDU para a operação
get-bulk é diferente da PDU das demais operações, sendo que a primeira pode ser visua-
18

Figura 5 – Exemplos de mensagens do SNMPv1. (Fonte: adaptado de [1])

lizada na figura 6, e a última, na figura 7 [1].

Figura 6 – PDU para a operação get-bulk. (Fonte: adaptado de [1])

Figura 7 – PCU para as operações get, getNext, Inform, Response, Set e Trap. (Fonte:
adaptado de [1])

6.3 SNMPv3

No SNMPv3, as principais mudanças em relação às versões anteriores foram: a

preocupação com a segurança na autenticação entre gerenciadores e agentes. A segurança
nesta versão do protocolo é codificada. E o abandono da ideia de gerentes e agentes na
rede, que agora são denominados entidades do SNMP. Cada entidade consiste em um
mecanismo do SNMP ou em uma ou mais aplicações do SNMP [1].
 19

7 SISTEMA DE GERENCIAMENTO DE REDE (NMS)

Os sistemas de gerenciamento de rede são softwares presentes no dispositivo ge-

rente, que tem como função o monitoramento e o controle das informações coletadas pelo
agente. Um NMS é composto pelos seguintes elementos: estação de gerenciamento, ge-
rente, agente de gerenciamento, MIB e Protocolo de gerenciamento. Entre os principais
NMS disponı́veis temos:

∙ HP Openview: desenvolvido pela HP entre 2004 e 2005, pode ser utilizado em con-
junto com outros NMS, não é freeware.

∙ IBM Tivoli Netview: desenvolvido pela IBM, e segundo consta no site da fabricante
o Tivoli Netview é um software de gerenciamento de rede distribuı́da, não é freeware;

∙ CiscoWorks: desenvolvido pela Cisco possui versões free (trials) com licença de no-
venta dias, porém para adquirir sua versão completa deve ser comprada licença;

∙ MRTG: o Multi Router Traffic Grapher é gratuito e de distribuição aberta. Foi

desenvolvido em C e Perl [7].

∙ CACTI: é liberado sob a licença GNU (General Public License), ou seja, é um

software livre e de código aberto;

∙ Zabbix: conforme consta na documentação disponı́vel no website da Zabbix, foi

criado por Alexei Vladishev e atualmente é desenvolvido ativamente e suportado
pela Zabbix SIA. É uma solução open source;

∙ Nagios: assim como o CACTI, também é liberado sob licença GNU, o que também
o torna livre e de código aberto.
 21

^
REFERENCIAS

[1] DUARTE, R. L. Protocolo de Gerenciamento SNMP. 2003. UEL.

[2] MAURO, D. R.; SCHMIDT, K. J. Essentials SNMP. [S.l.: s.n.], 2001.

[3] OLIVEIRA, L. de S. O Protocolo SNMP. Disponı́vel em: ”⟨http://www.

logicengenharia.com.br/mcamara/alunos/snmp lecia.pdf⟩”.

[4] FERNANDES, G. J. Caracterização de Tráfego e Detecção de Anomalias Utilizando

a Análise de Componentes Principais e Fluxos IP. 2014. 23 p.

[5] ZARPELãO, B. B. Detecção de Anomalias em Redes de Computadores. 2010.

7-10 p.

[6] CARVALHO, L. F. Metaheurı́stica Ant Colony Optimization e Análise de Fluxos IP

Aplicados à Detecção de Anomalias e à Ger^encia de Redes. 2014. 26-27 p. Disponı́vel
em: ”⟨http://www.bibliotecadigital.uel.br/document/?view=vtls000189801⟩”.

[7] DIAS, B. Z.; ALVES, N. J. Protocolo de Gerenciamento SNMP. 2001. Disponı́vel

em: ”⟨http://www.rederio.br/downloads/pdf/nt00601.pdf⟩”.