estudo snmp

Prévia do material em texto

Estudo do protocolo SNMP 
 
 
 
 
 
 
 
 
 
 
 
 
Filipe Freitas   
Filipe@filipefreitas.net 
http://www.filipefreitas.net 
ww
w.
fili
pe
fre
ita
s.n
et
Introdução 
 
 
O protocolo SNMP (Simple Network Management Protocol) foi desenvolvido pelo 
IETF (Internet Engineering Task Force), com uma primeira RFC em 1988. O seu objectivo 
inicial era ser um protocolo simples que permitisse a gestão de redes. 
Inicialmente, o protocolo SNMP (SNMPv1) era muito limitado para satisfazer todas 
as necessidades de gestão de redes. Em consequência, ao longo dos tempos, foram 
introduzidos melhoramentos no protocolo, surgindo sucessivas versões. No entanto o que o 
foi tornando uma ferramenta indispensável na gestão de redes, foi o constante aumento do 
número de MIBs existentes, e a sua vulgarização por todos os equipamentos. 
O outro melhoramento que surgiu no âmbito do IETF foi a especificação da RMON 
(Remote Network Monitoring) em 1991, que introduziu a capacidade de monitorização 
remota de redes. A RMON definiu algoritmos e bases de dados para gerir LAN’s remotas, e 
estendeu as capacidades do SNMP ao incluir a capacidade de monitorização de LAN’s 
como um todo, em vez de somente dos dispositivos presentes nessas redes locais. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ww
w.
fili
pe
fre
ita
s.n
et
Objectivos, equipamento e topologia de rede 
 
 
Com  este  trabalho prático deseja‐se  ter uma  experiência  hands‐on  sobre  gestão de 
redes  e  o  protocol  SNMP.  Para  tal,  será  observado  o  método  de  comunicação  entre  as 
entidades de gestão, e como estas operam internamente. Concretamente, serão abordados a 
base  de  dados  de  informação  (MIB),  o  protocolo  SNMP  v1  e  suas  limitações,  controlo  de 
acessos e (in)segurança, e finalmente, um exemplo de aplicação de gestão de redes de elevada 
dimensão. A experiência  foi executada com um  terminal, um switch Baystack, e dois routers 
Cisco, dispostos na seguinte topologia: 
 
 
 
  Foi configurado o protocolo de encaminhamento RIP. 
 
 
 
 
 
 
 
 
 
 
 
ww
w.
fili
pe
fre
ita
s.n
et
Operações SNMP 
 
 
  O  SNMP  permite  o  acesso  (de  leitura  e/ou  gravação)  à  MIB  do  dispositivo  a  ser 
acedido. Este acesso é feito através de pedidos do gestor e respostas do dispositivo. Para esta 
experiência foi utilizado o software Nudesign Visual MIBrowser. 
 
 
 
  A identificação dos objectos da MIB no dispositivo é feita através de uma sequência de 
números, que podem  ser  representados através de uma árvore  (ISO Object  Identifier Tree). 
Esta árvore é visível na secção à esquerda do Visual MIBrowser.  
   
 
 
ww
w.
fili
pe
fre
ita
s.n
et
Mensagens Get 
 
Para título de exemplo,  foi pedido o objecto ‘sysName’, identificado por 3.6.1.2.1.1.5. 
Esta accção desencadeia a seguinte sequência de pacotes SNMP na rede: 
 
 Observa-se que o gestor enviou um pacote ‘get-request’ para o dispositivo: 
 
  Uma  análise  ao  conteúdo  deste  pacote  revela  que  este  transporta  a  chave  de 
comunidade   de  leitura, que autentica o acesso à MIB do dispositivo, um  identificador deste 
pedido  (request‐id),  e  a  identificação  do  objecto  pedido.  Após  recepção  deste  pacote,  o 
dispositivo processa este conteúdo, verifica a chave de comunidade e permissões associadas, e 
envia um pacote ‘get‐response’, para o respectivo ‘request‐id’ do pedido com a informação do 
objecto pedido: 
 
  Uma outra informação relevante que é possível obter da análise do conteúdo destes 
pacotes é a versão do protocolo SNMP utilizado. Neste caso, a versão é a 1. 
 
 
 
 
ww
w.
fili
pe
fre
ita
s.n
et
 
Mensagens Set 
 
Analisemos agora o caso de alteração de um objecto da MIB. Neste exemplo  irá  ser 
utilizado  o  mesmo  objecto  utilizado  anteriormente(sysName).  Pretende‐se  alterar  o  valor 
deste objecto para ‘grupo4’. Esta accção desencadeia a seguinte sequência de pacotes SNMP 
na rede: 
 
Observa‐se que o gestor enviou um pacote ‘set‐request’ para o dispositivo: 
 
Analisando o conteúdo deste pacote, observa‐se que a chave de comunidade é agora a 
chave  de  escrita,  necessária  para  alteração  do  valor  de  objectos  na  MIB  no  dispositivo. 
Também é fornecido um  ‘request‐id’, a  identificação do objecto, mas ao contrário do pacote 
‘get‐request’,  é  fornecido  também  o  valor  do  objecto.  Após  recepção  deste  pacote,  o 
dispositivo processa o conteúdo e envia um pacote ‘set‐response’: 
 
Analisando o conteúdo deste pacote, observa‐se a ausência de erros no campo ‘error‐
status’ e o valor do objecto é o mesmo fornecido no pacote ‘set‐request’, confirmando então a 
alteração do valor pedida pelo gestor. 
ww
w.
fili
pe
fre
ita
s.n
et
Observemos agora um caso em que a alteração de um objecto na MIB do dispositivo 
interfira no comportamento do dispositivo. Iremos alterar o estado de uma porta do switch de 
‘up’ para ‘down’, o que irá impedir dos pacotes ping atingirem o destino.  
Esta accção desencadeia a seguinte sequência de pacotes SNMP na rede: 
 
Analisando os pacotes, observa‐se que o Visual MIBrowser começa por pedir o valor 
do estado da porta: 
 
O dispositivo responde a este pedido com o seguinte pacote: 
 
Verifica‐se que o estado está ‘up’, ou seja, a porta está no estado forwarding. 
De seguida, é enviado o pedido para alterar o estado da porta para ‘down’: 
 
ww
w.
fili
pe
fre
ita
s.n
et
Ao qual o switch responde com: 
 
O  switch  aceita  então  o  pedido,  e  altera  o  estado  da  porta.  Esta  acção  bloqueia 
efectivamente o tráfego de pacotes, nomeadamente os pings: 
 
Para repor a situação inicial, foi executada a mesma acção, desta vez com alterando o 
valor do objecto para ‘up’.  
ww
w.
fili
pe
fre
ita
s.n
et  
Analisando a sequência de pacotes, observa‐se que algum tempo após esta operação, 
os pings atingem o  seu destino. O  tempo de  reposição da porta é de aproximadamente 30 
segundos.  Este  elevado  tempo  de  reposição  deve‐se  ao  facto  de  que  o  dispositivo  a  ser 
acedido é um switch, no qual existem 5 estados para as portas. A acção ‘down’ altera o estado 
da porta para ‘blocking’, e a acção ‘up’ altera o estado para ‘forwarding’. A transição do estado 
‘blocking’ para ‘forwarding’ implica a transição para os estados ‘listening’ e ‘learning’, os quais 
implicam um  tempo de permanência nestes de  ‘forwarding delay’,  tipicamente 15  segundos 
cada, originando assim os 30 segundos de espera total. O tempo de espera também poderá ser 
influenciado pelas capacidades de dispositivo, como por exemplo processador dedicado para 
SNMP. 
 
Segurança no SNMP 
 
O acesso aos objectos da MIB é autenticado através de chaves de comunidade, para 
escrita e para  leitura. O acesso aos objectos é negado caso a chave de comunidade não seja 
reconhecida.  Foram  alteradas  no  router  192.10.10.100  as  chaves  de  comunidade.  A 
configuração do Visual MIBrowser permanece inalterada. Efectuando um walk (funcionalidade 
do Visual MIBrowser que efectua download da MIB do dispositivo),  iremos  tentar  aceder  à 
MIB. Após activar o walk, é desencadeada a seguinte sequência de pacotes na rede: 
 
ww
w.
fili
pe
fre
ita
s.n
et
Nesta experiência, observa‐se que o dispositivo não responde com ‘get‐response’, 
responde com mensagens ‘trap’: 
 
Analisando o conteúdo deste pacote, observa‐se que o dispositivo informa o gestor de 
uma falha de autenticação, não permitindo a este o acesso aos objectos. As mensagens ‘trap’ 
são mensagens  especificadas para  alertar o  gestor deerros ou  eventos  excepcionais,  como 
neste  caso,  a  falha  de  autenticação.  Evidentemente,  o  Visual  MIBrowser  não  apresenta 
informações da MIB do dispositivo: 
 
Repondo‐se  a  situação  inicial,  ou  seja,  alterando  as  chaves  de  comunidade  para  as 
reconhecidas, espera‐se que o acesso seja concedido. Note‐se que as chaves de comunidades, 
ou  seja, as  chaves utilizadas no  controlo de acessos,  são enviadas em  formato  texto, o que 
constitui  uma  vulnerabilidade  crítica,  pois  qualquer  intruso  poderá  obter  estas  chaves  e 
apropriar‐se  da  rede.  Esta  vulnerabilidade  foi  posteriormente  corrigida  com  versões 
melhoradas do SNMP. 
ww
w.
fili
pe
fre
ita
s.n
et
 
Como se esperava, o acesso é concedido, e o Visual MIBrowser procede para o 
download e apresentação da MIB: 
 
Neste processo, obteve‐se a seguinte captura de pacotes: 
 
Analisando esta captura, observa‐se que os pedidos são  feitos objecto a objecto. No 
entanto,   os pedidos não  são  feitos por mensagens  ‘get‐request’,  são  feitos por mensagens 
‘get‐next‐request’. Analisando o  conteúdo de  cada um destes  ‘get‐next‐request’, observa‐se 
que  a  identificação  dos  objectos,  é  incrementado  linearmente.  Estas  mensagens  são 
especificadas  para  pedidos  de  objectos  sequenciais,  como  por  exemplo  elementos  de  uma 
ww
w.
fili
pe
fre
ita
s.n
et
tabela. O SNMP v2  introduz uma nova mensagem  ‘get‐bulk‐request’ que permite aceder em 
massa  aos  objectos,  o  que  reduz  o  overhead  e  número  de  pacotes  na  rede,  entre  outras 
vantagens. 
 
Mensagens Trap 
 
  Após alterar a chave de comunidade, efectua‐se a tentativa de alteração do valor de 
um objecto sendo este, neste caso,  sysName (1.3.6.1.2.1.1.5) do router 192.10.10.100. 
 
Como é esperado, a alteração é negada, recebendo‐se uma mensagem ‘trap’ como 
resposta. 
 
 
Analisando o conteúdo deste pacote, observa‐se que o dispositivo informa o gestor de 
que a autenticação falhou, sendo este o motivo da negação de alteração. 
Como  foi dito anteriormente, as mensagens  ‘trap’ são mensagens especificadas para 
alertar o gestor de erros ou eventos excepcionais,  indicando o problema, como neste caso, a 
falha de autenticação. Repondo o sistema para a situação  inicial, a autenticação é efectuada 
com  sucesso,  sendo  permitido  o  acesso  e  alteração  do  valor  do  objecto,  como  pode  ser 
verificado pela sequência de pacotes: 
 
 
ww
w.
fili
pe
fre
ita
s.n
et
Autodiscovery e RMON 
 
A possibilidade de acesso massificado e automático aos dados de vários dispositivos 
permite construir soluções e mecanismos cujas potenciais funcionalidades são essenciais para 
o  gestor. Dois  potenciais  exemplos  dessas  funcionalidades  são  a  descoberta  automática  da 
topologia de rede e relatórios oriundos de RMONs. 
 
Autodiscovery 
 
O SNMP permite  também descobrir automaticamente dispositivos.Com a  ferramenta 
SNMPc, é possível obter a topologia de rede munidos apenas com o endereço de rede: 
 
A alteração do valor de objectos da MIB dos vários dispositivos pode ser feita graficamente. 
Por exemplo, o objecto sysName:
 
ww
w.
fili
pe
fre
ita
s.n
et
  Desligar portas: 
 
Todas as informações à distância de alguns clicks, aqui a tabela de routing: 
 
Com o SNMP é então possível aceder e controlar à distância os dispositivos. Ainda é 
possível ir mais longe, construindo gestores inteligentes de gestão SNMP, scripts, etc. 
ww
w.
fili
pe
fre
ita
s.n
et
RMON 
 
Existem dispositivos  cujo papel é monitorizar a  rede para estatisticas, no  sentido de 
munir o gestor de informações preciosas como, por exemplo, o estado de utilização da rede. 
Estes dispositivos também podem ser acedidos por SNMP, sendo este, no nosso caso, 
o switch. Também através do SNMPc, podemos aceder  aos RMON e seus dados graficamente. 
Aqui, o tráfego das várias portas do switch: 
 
Aqui, o número de pacotes:
 
ww
w.
fili
pe
fre
ita
s.n
et
 
Aqui, o tráfego em bytes: 
 
É então possível aceder  remotamente a  todo o  tipo de estatísticas que o dispositivo 
oferece, cujas informações são essenciais para todo o tipo de tarefas que sejam efectuadas na 
rede. 
Conclusão 
 
  O SNMP é uma  ferramenta essencial para gestão e monitorização remotas de redes, 
disponibilizando ao gestor  informações e controlo sobre o equipamento sob o seu comando, 
possibilitando ainda a construção de mecanismos automáticos de gestão, utilizando o SNMP. 
  A  interacção é feita entre um gestor e vários agentes, cabendo ao gestor o poder de 
decisão,  enquanto  que  os  agentes  apenam  mantêm  a  MIB  (o  agente  é  ‘estúpido’).  Esta 
interacção é feita através de mensagens get‐request, get‐next‐request e set‐request por parte 
do gestor, e get‐response,  set‐response e  trap por parte do agente. As mensagens  trap  são 
mensagens  para  notificação  do  gestor  de  eventos  excepcionais.  Existe  um  mecanismo  de 
controlo de  acessos, nomeadamente  restrição de  leitura  e  restrição de  escrita, no  entanto, 
este  mecanismo  é  uma  vulnerabilidade  no  SNMP  v1,  pois  as  chaves  de  comunidade  são 
transmitidas sem encriptação, podendo ser facilmente interceptadas por intrusos. 
	Introdução
	Objectivos, equipamento e topologia de rede
	Operações SNMP
	Mensagens Get
	Mensagens Set
	Segurança no SNMP
	Mensagens Trap
	Autodiscovery e RMON
	Autodiscovery
	RMON
	Conclusão