Uso Do SMNP V3

i
UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CINCIAS EXATAS E NATURAIS
CURSO DE CINCIAS DA COMPUTAO
(Bacharelado)
PROTTIPO DE UM SISTEMA DE MONITORAMENTO DE

DESEMPENHO DE REDES DE COMPUTADORES BASEADO
NO PROTOCOLO SNMPV3.
TRABALHO DE CONCLUSO DE CURSO SUBMETIDO UNIVERSIDADE

REGIONAL DE BLUMENAU PARA A OBTENO DOS CRDITOS NA
DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CINCIAS DA
COMPUTAO BACHARELADO
ANDERSON KARING
BLUMENAU, NOVEMBRO/2002
2002/2-03
ii
PROTTIPO DE UM SISTEMA DE MONITORAMENTO DE

DESEMPENHO DE REDES DE COMPUTADORES BASEADO
NO PROTOCOLO SNMPV3.
ANDERSON KARING
ESTE TRABALHO DE CONCLUSO DE CURSO FOI JULGADO ADEQUADO

PARA OBTENO DOS CRDITOS NA DISCIPLINA DE TRABALHO DE
CONCLUSO DE CURSO OBRIGATRIA PARA OBTENO DO TTULO DE:
BACHAREL EM CINCIAS DA COMPUTAO
Prof. Francisco Adell Pricas Orientador na FURB
Prof. Jos Roque Voltolini da Silva Coordenador do TCC
BANCA EXAMINADORA
Prof. Francisco Adell Pricas
ii
iii
AGRADECIMENTOS
Agradeo a todos os professores do curso de Bacharelado em Cincias da Computao
da Universidade Regional de Blumenau pela ajuda prestada ao longo do curso, principalmente
aos professores Francisco Adell Pricas por ter me orientado neste trabalho final e o professor
Roberto Heinzle pelo apoio dado num momento crtico do curso quando eu pensava em
desistir. Muito obrigado pela pacincia, preocupao e dedicao.
Agradeo a todos os novos amigos que conheci em Blumenau no decorrer da
Faculdade, principalmente ao Renato, Rafael, Fernando, Carlos, Erasmo, Hensel, Gilson,
Edson tatu, Marcelo, e a todo o pessoal do NI, especialmente ao Fbio por acreditar em meu
potencial. Na ala feminina agradeo Marilda, Silvanira, Fernanda e Michele. Obrigado a
todos vocs pela fora, apoio e companhia no decorrer do curso.
Agradeo a toda galera da sala, que mesmo nos momentos mais difceis sempre
ajudavam uns aos outros.
Agradeo principalmente aos meus pais Valmor e Renate e aos meus irmos Max e
Ana, por terem me dado todo o apoio nessa luta, no fosse a dedicao deles, no poderia
estar aqui agora redigindo meu trabalho final.
Agradeo aos motoristas da Geneve por levarem e buscarem de Brusque para
Blumenau, a mim e a todos os demais estudantes de Brusque, com segurana durante estes
seis anos.
Agradeo ao pessoal da Igreja Luterana de Bateias, por ter permitido que eu deixasse
minha bike l guardada enquanto estudava, facilitando assim minha vida.
Agradeo tambm ao Governo Estadual pelo auxlio financeiro prestado, e podem ter
certeza: fiz valer cada centavo em mim investido.
Finalmente, agradeo a Marcela e a Brbara por serem as garotas mais incrveis (e
lindas!) que j conheci, e por terem compartilhado dos momentos mais marcantes da minha
vida at hoje.
iii
iv
EPGRAFE
Os verdadeiros vencedores no so aqueles que chegam na frente, mas sim aqueles
que com muita garra, paixo e dedicao chegam ao final.
(autor desconhecido)
iv
SUMRIO
LISTA DE FIGU RAS...........................................................................................................VII
LISTA DE ABREVIATURA S E LISTA DE SIGLAS.....................................................VIII
LISTA DE ABREVIATURA S E LISTA DE SIGLAS........................................................IX
RESUMO..............................................................................................................................XIII
ABSTRACT..........................................................................................................................XIV
1
INTRODUO.....................................................................................................1
1.1
1.2
OBJETIVOS DO TRABALHO ......................................................................................3

E STRUTURA DO TRABALHO .....................................................................................3
FUNDAMENTAO TERIC A.......................................................................5
2.1
2.2
2.2.1
2.2.2
2.2.3
BREVE HISTRICO DE REDES DE COMPUTADORES .................................................5

REDES DE COMPUTADORES .....................................................................................6
Uso Das Redes De Computadores ..........................................................................7
Hardware De Rede ..................................................................................................8
Software De Rede ...................................................................................................9
GERNCIA DE REDES DE COMPUTADORES..........................................13
3.1
3.2
3.2.1
ARQUITETURA DE UM SISTEMA DE GERENCIAMENTO DE REDES ......................... 16

GERENCIAMENTO D E DESEMPENHO ...................................................................... 19
Funo De Monitoramento De Desempenho .......................................................22
SIMPLE NETWORK MANAGEMENT PROTOCOL..................................24
4.1
4.1.1
4.1.2
4.1.2.1
4.1.2.1.1
4.1.2.2
4.1.2.3
4.1.3
4.1.4
4.1.5
4.1.6
CONCEITOS BSICOS DE SNMP ............................................................................ 25

Arquitetura ............................................................................................................ 26
SMI Structure Of Management Information ..................................................... 28
Estrutura MIB .......................................................................................................29
Subgrupo IP .......................................................................................................... 32
ASN.1 ...................................................................................................................34
Codificao...........................................................................................................35
Trap-directed Polling ............................................................................................ 35
Proxy ..................................................................................................................... 37
Comparativo Entre As Verses SNMP ................................................................. 38
Consideraes Finais Sobre O SNMP .................................................................. 41
SNMPV3 ..............................................................................................................42
5.1
5.1.1
5.1.2
5.1.3
5.1.4
M OTOR SNMP V3.................................................................................................. 43

Despachante .......................................................................................................... 44
Subsistema De Processamento De Mensagens..................................................... 44
Subsistema De Segurana ..................................................................................... 45
Subsistema De Controle De Acesso ..................................................................... 46
v
vi
5.1.5
5.1.6
5.2
5.3
5.3.1
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.4.5
5.5
5.5.1
5.5.2
5.5.3
5.5.4
5.6
5.6.1
5.6.2
5.6.3
5.7
5.7.1
5.8
Gerente Snmp Tradicional.................................................................................... 47

Agente SNMP Tradicional ...................................................................................49
APLICAES SNMP ...............................................................................................50
P ROCESSAMENTO DE M ENSAGENS SNMP V3 ........................................................ 51
Formato Das Mensagens SNMPv3.......................................................................51
ALGORITMOS CRIPTOGRFICOS USADOS P ELO SNMP V3 ..................................... 53
Conceitos Bsicos De Criptografia .......................................................................53
Data Encryption Standard (DES) .......................................................................... 55
Message Digest 5 (MD5) ...................................................................................... 56
Secure Hash Function (SHA-1) ............................................................................ 57
Autenticao De Mensagens Com O HMAC .......................................................57
U SER- BASED SECURITY MODEL USM................................................................ 58
Parmetros De Segurana USM ...........................................................................59
Funes Criptogrficas Usadas Pelo USM ...........................................................63
Processamento De Mensagens USM .................................................................... 64
Descoberta ............................................................................................................ 70
GERENCIAMENTO D E CHAVES ...............................................................................71
Algoritmo De Transformao De Senha Para Chave ...........................................71
Localizao De Chaves......................................................................................... 72
Atualizao De Chaves ......................................................................................... 74
VIEW-BASED ACCESS CONTROL M ODEL - VACM ................................................ 75
A MIB VACM ...................................................................................................... 81
A API ADVENTN ET SNMP V3...............................................................................85
DESENVOLVIMENTO DO PROTTIPO.....................................................88
6.1
6.2
6.2.1
6.2.2
6.2.3
6.3
6.3.1
6.3.2
6.4
REQUISITOS P RINCIPAIS DO P ROBLEMA A SER TRABALHADO ...............................88

ESPECIFICAO ...............................................................................................89
Diagramas de Casos de Uso ................................................................................. 89
Diagrama de Classes ............................................................................................. 90
Diagramas de Seqncia .......................................................................................93
IMPLEMENTAO............................................................................................ 98
TCNICAS E FERRAMENTAS UTILIZADAS ................................................ 98
OPERACIONA LIDADE DA IMPLEMENTAO .........................................107
RESULTADOS E DISCUSSO........................................................................ 112
CONCLUSES.................................................................................................113
7.1
EXTENSES .....................................................................................................115
REFERNCIAS BIBLIOGRFICAS................................................................................ 116
vi
vii
LISTA DE FIGURAS
FIGURA 1 Estrutura das camadas......................................................................................... 10
FIGURA 2 Camadas do modelo de referncia OSI...............................................................11
FIGURA 3 Elementos de um sistema de gerenciamento de redes ........................................ 17
FIGURA 4 Arquitetura de uma entidade proxy ..................................................................... 18
FIGURA 5 O papel do SNMP ...............................................................................................27
FIGURA 6 - Grupos de objetos MIB-2 .................................................................................... 30
FIGURA 7 Configurao de proxy ........................................................................................ 37
FIGURA 8 Entidade SNMPv3 .............................................................................................. 43
FIGURA 9 Subsistema de processamento de mensagens ..................................................... 44
FIGURA 10 Subsistema de segurana .................................................................................. 45
FIGURA 11 Subsistema de controle de acesso..................................................................... 46
FIGURA 12 Gerente SNMPv3 tradicional............................................................................ 48
FIGURA 13 Agente SNMPv3 convencional......................................................................... 49
FIGURA 14 Formato da mensagem SNMPv3 ...................................................................... 51
FIGURA 15 Criptografia convencional................................................................................. 54
FIGURA 16 Formato da mensagem SNMPv3 com USM ..................................................... 61
FIGURA 17 Processamento de mensagens USM: transmisso............................................ 65
FIGURA 18 - Processamento de mensagens USM: recepo...............................................67
FIGURA 19 Localizao de chaves ...................................................................................... 73
FIGURA 20 Lgica VACM .................................................................................................. 78
FIGURA 21 Fluxograma VACM .......................................................................................... 80
FIGURA 22 A MIB VACM .................................................................................................. 83
Figura 23 - Diagrama de casos de uso...................................................................................... 89
vii
viii
Figura 24 - Diagrama de Classes: parte agente ........................................................................ 90
Figura 25 - Diagrama de Classes: parte gerente .......................................................................91
Figura 26 - Obter informaes de desempenho ........................................................................ 93
Figura 27 - Inicializao do gerente ......................................................................................... 95
Figura 28 - Inicializao do agente ...........................................................................................97
Figura 29 - Tela Inicial da aplicao gerente ..........................................................................109
Figura 30 - Medio inicial.....................................................................................................111
Figura 31 - Medio final .......................................................................................................112
viii
ix
LISTA DE ABREVIATURAS E LISTA DE SIGLAS

AGR - Aplicao de Gerenciamento de Rede
API - Aplication Programing Interface
ARPA - Advanced Research Projects Agency
ASN.1 - Abstract Syntax Notation dot One
BER - Basic Encoding Rules
CBC - Cipher Block Chaining
CMIP - Common Management Information Protocol
CMIS - Common Management Information Service
CMOT - Common Management Information Protocol over TCP/IP
CORBA - Common Object Request Broker Architecture
DES - Data Encryption Standard
DoD - Department of Defense
DQDB - Distributed Queue Dual Bus
ECB - Electronic Codebook
EGP - Exterior Gateway Protocol
EGR - Entidade de Gerenciamento de Rede
EJB - Enterprise Java Beans
FTP - File Transfer Protocol
HMAC - Hashing for Message Authentication Code
ix
x
HMP - Host Monitoring Protocol
HTTP - Hipertext Transfer Protocol
IAB - Internet Architecture Board
ICMP - Internet Control Message Protocol
IEC - International Electrotecnical Comission
IEEE - Institute of Electrical and Eletronics Engineers
IETF - Internet Engineering Task Force
IP - Internet Protocol
ISO - International Organization for Standardization
JNI - Java Native Interface
JVM Java Virtual Machine
LAN - Local Area Network
MAC - Message Authentication Code
MAN - Metropolitan Area Network
MD5 - Message-digest 5
MIB - Management Information Base
MIT - Massachussets Institute of Technology
MS-DOS Microsoft Disk Operation System
MTU - Maximum Transfer Unit
NCP - Network-Control Protocol
NIST - National Institute of Standards and Tecnology
x
xi
NMS - Network Management Station
OSI - Open Systems Interconection
PC - Personal Computer
PDU - Protocol Data Unit
PhD - Doctor of Philosophy
PING - Packet Internet Groper
PPP - Point to Point Protocol
QoS - Quality of Service
RFC - Request for Comment
RMI - Remote Method Invocation
SAS - SNMP Applet Server
SET - Secure Electronic Transaction
SGMP - Simple Gateway Monitoring Protocol
SHA-1 - Secure Hash Algorithm 1
SMI - Structure of Management Information
SNA - System Network Architecture
SNMP - Simple Network Management Protocol
SNMPv3 - Simple Network Management Protocol version three
SSL - Secure Socket Layer
TCP - Transmission Control Protocol
TTL - Time-To-Live
xi
xii
UDP - User Datagram Protocol
UI - User Interface
UML - Unifield Modeling Language
XML - Extensible Markup Language
XNS - Xerox Network Systems
XOR - Xtended OR
WAN - Wide Area Network
WWW - World Wide Web
xii
xiii
RESUMO
Este trabalho apresenta um estudo de usabilida de do protocolo de gerenciamento de
redes Simple Network Management Protocol version three (SNMPv3), atravs da
especificao e implementao de um prottipo de um sistema de gerenciamento de
desempenho para dispositivos de uma Local Area Network (LAN), ut ilizando na sua
implementao a Aplication Programing Interface (API) da empresa AdventNet escrita com a
linguagem Java.
xiii
xiv
ABSTRACT
This paper presents a study of usability of the Simple Network Management Protocol
version three (SNMPv3) through the specif ication and implementation of a prototype of a
performance management system for Local Area Network (LAN) devices, using for its
implementation the AdventNets Aplication Programing Interface (API) written with the Java
language.
xiv
1 INTRODUO
Segundo Kurose (2001), devido ao fato de uma rede de computadores consistir de
muitas partes complexas de hardware e software tais como links, equipamentos, pontes,
roteadores e outros dispositivos, quando centenas ou milhares destes dispositivos so
conectados uns aos outros para formar uma rede, de se esperar que componentes iro
eventualmente funcionar mal, que elementos de rede podero ser desconfigurados, que
recursos da rede sero superutilizados, ou que componentes de rede iro simplesmente
quebrar (como por exemplo, o corte de um cabo). O administrador de redes deve estar apto
a solucionar (e melhor ainda, evitar) tais problemas. O administrador de redes precisa
claramente de ferramentas para ajudar a monitorar, analisar, gerenciar e controlar a rede.
Lynch (1993) cita que, at recentemente, o gerenciamento de redes se baseava nos
avanos tcnicos em outras reas de redes baseadas em padres abertos; de certa forma ainda
assim. Uma das razes para isso que h uma discordncia sobre o que realmente significa
gerenciamento de redes. Como resultado, tem havido fundamentalmente diferentes
abordagens ao problema de gerenciamento de redes. Algumas destas abordagens foram
prticas, obtendo grande aceitao para solucionar parte do problema de gerenciar redes
baseadas em protocolos de rede abertos. O protocolo Simple Network Management Protocol
(SNMP) a chave da estrutura de gerenciamento de redes de computadores. um padro
aberto e operacional. A estrutura de gerenciamento SNMP foi originalmente desenhada para
uso em redes Transmission Control Protocol/Internet Protocol (TCP/IP), mas vm
encontrando aplicao em reas bem distantes daquelas para as quais foi inicialmente
planejada. A estrutura SNMP constitui um padro aberto para gerenciamento de redes, como
esta belecido pelo Internet Architecture Board (IAB). Conseqentemente, o SNMP pode ser
dito como sendo um padro declarado de jure. Padres declarados que no estejam
disponveis so de pouca utilidade. Entretanto, este certamente no o caso do SNMP.
Vendedores o implementaram, consumidores o adquiriram, desenvolvedores de aplicaes de
redes o disponibilizaram, e administradores de redes o usam ativamente.
Conceitualmente, para Zeltserman (1999), o SNMPv3 nada mais do que uma
estrutura que estende o SNMP original. As duas maiores extenses so a adio de primitivas
de segurana e de administrao. Alm disso, o SNMPv3 define novas Management
2
Information Base MIBs, para configurar segurana, notificaes, redirecionamento de proxy
e controle de acesso baseado em vises.
Isto uma faca de dois gumes pois pela primeira vez possui-se uma forma padro
para que um administrador de redes possa remotamente configurar estas caractersticas. Por
outro lado, configurar segurana e controles de acesso baseados em vises adiciona
complexidade.
De acordo com Carvalho (1993), a abrangncia do gerenciamento de redes muito
grande, envolvendo principalmente as reas de:
a) gerenciamento de falhas: responsvel pela manuteno e monitoramento do estado
de cada um dos objetos gerenciados e pelas aes necessrias ao restabelecimento
das unidades com problemas;
b) gerenciamento de configurao: tem por funo a manuteno e monitorao da
estrutura fsica e lgica da rede, incluindo a existncia de componentes e sua
interconectividade;
c) gerenciamento de segurana: aborda os aspectos de segurana essenciais para
operar uma rede corretamente e proteger os objetos gerenciados;
d) gerenciamento de contabilizao: preocupa-se com a manuteno e monitorao de
quais recursos e de quanto desses recursos esto sendo utilizados;
e) gerenciamento de desempenho: preocupa-se com o desempenho corrente da rede,
incluindo parmetros estatsticos tais como atrasos, vazo, disponibilidade e
nmero de retransmisses. Consiste em um conjunto de funes responsveis por
manter e examinar registros, com histrico dos estados do sistema para fins de
planejamento e anlise.
O gerenciamento de desempenho confundido, s vezes, com o gerenciamento de
falhas. Muitos tendem a confundir desempenho com disponibilid ade. O gerenciamento de
desempenho importante no s para garantir a qualidade de servio acordada com os
usurios, como tambm para assegurar que esta atingida com os menores custos possveis.
Pode-se, por meio do gerenciamento de desempenho, adequar os recursos utilizados pelos
usurios s suas necessidades, auxiliando o setor responsvel pela administrao de redes a
antecipar-se aos usurios na manuteno dos nveis de desempenho dos servios oferecidos,
3
como por exemplo, o tempo de resposta. O gerenciamento de desempenho est diretamente
relacionado ao planejamento da capacidade do sistema sob gerenciamento.
O trabalho proposto apresenta como relevncia em computao a implementao na
linguagem Java de um prottipo de um sistema para a gerncia de redes de computadores
utilizando o protocolo SNMPv3, visando o monitoramento de desempenho de dispositivos de
uma LAN.
1.1 OBJETIVOS DO TRABALHO

O objetivo principal deste trabalho de concluso de curso a especificao e
implementao de um prottipo de um sistema para a gerncia de dispositivos de uma LAN
utilizando algumas funes de gerncia de desempenho atravs do protocolo SNMPv3.
Os objetivos especficos do trabalho so:
a) analisar as novas funcionalidades do protocolo SNMPv3;
b) especificar um prottipo de um sistema de gerncia de redes para o gerenciamento
de desempenho de alguns dispositivos de uma LAN;
c) validar estas funcionalidades atravs da implementao deste prottipo.
1.2 ESTRUTURA DO TRABALHO

Este trabalho est organizado em captulos, conforme apresentados a seguir.
O captulo 1 apresenta a estrutura geral do trabalho: a introduo, os objetivos, a
localizao dos assuntos abordados e a organizao do trabalho.
O captulo 2 apresenta um breve histrico das redes de computadores, sua estrutura
bsica, caractersticas e tecnologias.
O captulo 3 trata especificamente do gerenciamento de redes: conceitos,
caractersticas e modelos so apresentados, e o modelo de gerenciamento de desempenho de
redes estudado com mais detalhes.
O captulo 4 aborda o protocolo de gerenciamento de redes SNMP. Suas
caractersticas, estrutura e elementos so brevemente estudados.
4
O captulo 5 aborda especificamente o protocolo SNMPv3: suas caractersticas,
estrutura e seus elementos. Tambm apresenta a criptografia e seus conceitos bsicos como
autenticao, privacidade, gerenciamento de chaves, modelos e algoritmos utilizados no
desenvolvimento do prottipo.
O captulo 6 voltado ao desenvolvimento do prottipo, onde so apresentadas a
especificao e a implementao do prottipo.
E por fim, o captulo 7 dedicado s concluses e sugestes de continuidade do
trabalho.
2 FUNDAMENTAO TERIC A
A seguir ser apresentada uma breve fundamentao terica, com o objetivo de
posicionar o trabalho no tema abordado.
2.1 BREVE HISTRICO DE REDES DE COMPUTADORES

Segundo Kurose (2001), devido ao crescimento da importncia dos computadores no
incio dos anos 60, e do advento dos computadores com processamento paralelo, foi natural
considerar a questo de como os computadores poderiam ser interligados, podendo assim, ser
compartilhados entre usurios geograficamente distribudos.
Mas o trfego gerado por tais usurios causava pesados perodos de atividade, como
o envio de um comando a um computador remoto, seguido de perodos de inatividade
enquanto este aguardava o retorno do resultado ou enquanto se estudava a resposta recebida.
Era preciso resolver este problema, e a soluo surgiu em 1964 atravs de trs grupos de
pesquisa independentes: Leonard Kleinrock do Massachussets Institute of Technology (MIT),
Paul Baran do Rand Institute e Donald Davis e Roger Scantlebury do National Physical
Laboratory da Inglaterra, todos inconscientes uns dos outros, inventaram o conceito de troca
de pacotes como uma alternativa eficiente e robusta para substituir a transmisso de dados por
circuitos, usada at ento. J.C.R Licklider e Lawrence Roberts, ambos colegas de Kleinrock,
publicaram um plano geral para a chamada ARPAnet da Advanced Research Projects Agency
(ARPA) em 1969, criando a primeira rede de computadores usando a troca de pacotes e
ancestral direta da atual Internet. Em 1972 o primeiro protocolo host-to-host usado na
ARPAnet conhecido como Network -Control Protocol (NCP) estava pronto. Com um
protocolo fim-a-fim disponvel, a partir daquele momento aplicaes poderiam ser escritas.
A ARPAnet era uma rede simples e fechada. Entretanto, na metade dos anos 70, outras
redes baseadas na troca de pacotes surgiram. Dentre elas podem-se citar a ALOHAnet, uma
rede de microondas ligando as universidades da ilha do Hawai; a Telenet, uma rede comercial
pertencente ao BBN, e a Tymnet e Transpac, ambas redes de troca de pacotes francesas. O
nmero das redes de computadores comeava a crescer. Em 1973, a tese de Ph.D. de Robert
Metcalfe demonstrou os princpios da Ethernet, que mais tarde levaram a um enorme
crescimento das chamadas LANs. Era chegado o momento de desenvolver uma arquitetura
6
para conectar as redes entre si. Trabalhos pioneiros sobre interconexo de redes foram feitos
por Vinton Cerf e Robert Kahn, novamente sob patrocnio da ARPA. Estes princpios
arquiteturais de interconexo foram incorporados ao protocolo TCP. Alias, os trs protocolos
chave usados hoje nas redes de computadores TCP, User Datagram Protocol (UDP) e IP
estavam conceitualmente de finidos j no final dos anos 70.
A tecnologia Ethernet representou um passo importante para a interconexo de redes.
Cada LAN Ethernet era em si uma rede e, com a proliferao do nmero de LANs, a
necessidade de interlig -las tornou-se cada vez mais impor tante. Muitas companhias
desenvolveram suas prprias arquiteturas de redes proprietrias como a DEC com a DECnet
(1975), a Xerox com a arquitetura Xerox Network System - XNS e a IBM com a arquitetura
System Network Architecture - SNA.
Os anos 80 foram um perodo de tremendo crescimento. Muito do crescimento foi
resultado do grande esforo de criar redes de computadores ligando as universidades entre si.
Em 1983 a ARPAnet terminou o desenvolvimento do TCP/IP e o adotou em sua rede como o
novo protocolo padro em substituio ao NCP.
Nos anos 90 dois eventos simbolizaram a evoluo e a comercializao das redes.
Primeiro, a progenitora da Internet, a ARPAnet deixou de existir, tornando-se comercial
dando origem a atual Internet. Mas o principal evento foi o surgimento da World Wide Web
(WWW), que trouxe a Internet, e por conseqncia, as redes, s casas e negcios de milhes e
milhes de pessoas ao redor do mundo. Alm disso, ao longo dos anos 90, pesquisas e
desenvolvimento em redes de computadores realizara m avanos nas reas de roteadores de
alta velocidade, roteamento, aplicaes de tempo real e LANs, gerando uma enorme expanso
no uso das redes de computadores nos dias atuais.
2.2 REDES DE COMPUTADORES

Em seguida ser apresentada uma pequena discusso sobre as redes de computadores,
suas tecnologias, utilizao e arquiteturas,
utilizados.
assim como hardware e softwares por elas
2.2.1
USO DAS REDES DE COMPUTADORES

Segundo Tanenbaum (1997), devido ao rpido progresso tecnolgico nas reas de
telefonia, rdio e tv, satlite e computadores, estas reas esto convergindo rapidamente e h
uma diferena cada vez menor entre coleta, transporte, armazenamento e processamento de
informaes. medida que cresce a capacidade de colher, processar e distribuir informaes,
torna-se ainda maior a necessidade de formas de processamento de informaes ainda mais
sofisticadas. Esta fuso entre os computadores e as comunicaes foi de grande importncia
para o surgimento das redes de computadores.
Uma rede de computadores um conjunto de computadores autnomos
interconectados. Dois ou mais computadores so ditos interconectados quando podem
trocar informaes (Tanenbaum, 1997).
Algumas razes econmicas e tecnolgicas para a instalao de redes de
computadores so:
a) compartilhamento de recursos: disponibilizar todos os programas, recursos e dados
a todos os usurios da rede, independentemente da localizao fsica dos recursos e
dos usurios;
b) aumento de confiabilidade: viabilizar fontes alternativas de fornecimento de
recursos (como exemplo, pode-se citar um arquivo salvo em trs computadores
diferentes e assim, se um deles falhar, o arquivo poder ser obtido de um dos outros
dois computadores);
c) economia de dinheiro: a relao custo/desempenho dos computadores de pequeno
porte muito melhor do que a dos computadores de grande porte;
d) escalabilidade: possibilitar o aumento gradual do desempenho do sistema medida
que cresce o volume de carga, bastando para tal, que se adicionem mais
processadores;
e) meio de comunicao: uma rede de computadores representa um meio de
comunicao altamente eficaz para funcionrios que trabalham em locais muito
distantes uns dos outros, aumentando assim, o esprito de equipe entre grandes
grupos de pessoas.
8
Alm destas razes de eficincia corporativa podem-se citar outros motivos para a
interconexo de computadores:
a) acesso s informaes remotamente (ex: transaes financeiras e comrcio
eletrnico);
b) comunicao pessoa a pessoa (ex: correio eletrnico);
c) entretenimento (ex: jogos on-line).
2.2.2
HARDWARE DE REDE
H duas dimenses gerais nas quais as redes de computadores podem ser classificadas
segundo Tanenbaum (1997): a escala e a tecnologia de transmisso.

So dois, os tipos principais de tecnologia de transmisso:
a) redes de difuso (broadcasting ): possuem apenas um canal de comunicao que
compartilhado por todas as mquinas;
b) redes ponto a ponto (unicasting ): consistem em conexes entre pares individuais de
mquinas.
Quanto escala, as redes de computadores podem ser classificadas em:
a) redes locais: tambm chamadas de LANs, so redes geralmente privadas, contidas
em um prdio ou em um campus universitrio;
b) redes metropolitanas: tambm chamadas Metropolitan Area Networks (MANs), so
uma verso ampliada de uma LAN, podendo abranger uma cidade inteira e que
utilizam um protocolo de transmisso especial: o Distributed Queue Dual Bus
(DQDB). Podem ser pblicas ou privadas;
c) redes geograficamente distribudas: tambm chamadas Wide Area Networks
(WANs), abrangem uma ampla rea geogrfica, com freqncia um pas ou
continente. So compostas por equipamentos (mquinas que executam programas
de usurios) e sub-redes (compostas por linhas de transmisso e elementos de
comutao).
As redes locais possuem trs caractersticas que as diferenciam das demais:
a) tamanho: restrito, o que significa que o pior tempo de transmisso limitado e
conhecido. O conhecimento desse limite permite a utilizao de determinados tipos
9
de projetos que em outras circunstncias seriam inviveis, alm de simplificar o
gerenciamento da rede, foco do presente trabalho;
b) tecnologia de transmisso: quase sempre consiste em um cabo ao qual todas as
mquinas esto conectadas;
c) topologia: as LANs de difuso aceitam vrias topologias, dentre as quais pode -se
citar a de barramento e a de anel.
Para o desenvolvimento do presente trabalho ser utilizada uma LAN de difuso
conectada por cabos com uma topologia de barramento padro LAN Ethernet, conforme
definido pelo Institute of Electrical and Eletronics Engineers (IEEE) em IEEE 802.3.
2.2.3
SOFTWARE DE REDE
Ta nenbaum (1997) cita que para reduzir a complexidade do projeto, a maioria das
redes foi organizada como uma srie de camadas ou nveis que so colocados um em cima do
outro. O objetivo de cada camada oferecer determinados servios para as camadas
superiores, ocultando detalhes de implementao desses recursos. Um servio um conjunto
de primitivas (operaes) que uma camada oferece para a camada imediatamente acima dela.
Os servios podem ser de dois tipos: orientados conexo e sem conexo. J as operaes
podem ser: Request, Indication , Response e Confirm. Os servios so classificados tambm
pela sua qualidade de servio (QoS - Quality of Service) que a garantia de que uma
mensagem chegue ntegra ao seu destino. Os elementos ativos em cada camada s o
freqentemente chamados de entidades. As entidades de um mesmo nvel/camada que se
encontram em diferentes mquinas so chamadas de pares (peers) e a comunicao entre os
pares feita usando o protocolo da camada.
Um protocolo basicamente um conjunto de regras que controla o formato e o
significado dos quadros, pacotes, ou mensagens trocadas pelas entidades pares contidas em
uma camada.
Entre cada par h uma interface que define as operaes e os servios que a camada
inferior tem a oferecer a camada superior. Para compreender este modelo veja a figura 1.
10
FIGURA 1 Estrutura das camadas
E s tru tu ra d as C am a d as
P r oc e s s o d e
P r o c e s s o de
tr a n s m is s o
re c e p o
Dados
Pr o t oc o lo d e
C a m ad a d e A p lic a o
AH
ap li c a o
P ro to P ro t o c ol o d e
C a m ad a d e A pr e s e nt a o
a p r e s e n t a o
C am ad a d e S e s s o
PH
P r oto c o lo d e
Dados
C am a da d e A p li c a o
Dados
SH
C am ad a d e A p r e s e n ta o
Dados
C am a d a d e S e s s o
sesso
C a m a d a d e T r a ns p o r te
P ro to c o l o d e
TH
D ados
C a m a d a d e T r an s p o rt e
t ra n s p or te
C a m a d a d e R e de
P ro to c ol o
NH
D ados
C a m a da d e R e d e
d e r e de
C a m a d a de E n l a c e
DH
C am a d a F s ic a
D a d os
DT
B it s
C a m a d a d e E n l ac e
C a m ad a F s ic a
C a m in h o d a tr a ns m is s o d e da d o s
FONTE: Adaptado de Tanenbaum (1997, pg. 39).
Como se v, na verdade os dados no so diretamente transmitidos da camada n de

uma mquina para a camada n da outra. Cada camada, na verdade, transfere os dados e as
informaes de controle para a camada imediatamente abaixo dela, at a ltima camada ser
alcanada. Abaixo desta camada est o meio fsico atravs do qual se d a comunicao
propriamente dita. Na outra ponta o processo inverso realizado.
Um conjunto de camadas de protocolos chamado de arquitetura de rede, e uma lista
de protocolos usados por um determinado sistema, um protocolo por camada, chamado de
pilha de protocolos.
Dentre as arquiteturas de rede podem-se citar o modelo de referncia Open Systems
Interconnection (OSI) e o modelo de referncia Internet.
O modelo de referncia OSI foi especificado pela International Organization for
Standardization/International Electrotechnical Comission (ISO/IEC) e possui sete camadas
(fig. 2):
11
FIGURA 2 Camadas do modelo de referncia OSI
U n id a d e
C a m a d a s d o Mo d e l o d e R e fe r n c ia O S I
Ca m ada
A p l ic a o
P ro t oc o l o d e a p li c a o
A p lica o
AP D U
A p r e s e n ta o
P PD U
Sesso
SP D U
T r an s p or t e
TP D U
R ede
P a c o te
E nlac e de da dos
Q uadr o
In te r fa c e
6
A p r e se n t a o
P r o to c o lo d e a p r e s e n ta o
In t e r fa c e
P ro to c o l o d e s e s s o
Sess o
T r an s p or te
R ede
E n la c e d e d a d o s
F s i c a
F s ic a
H ost A
H os t B
P r oto c olo d e tr an s p or te
P r o to c o lo d e r e d e
P r o to c olo d e e n l a c e
T r a n s m is s o d e d a d o s
B it
FONTE: Adaptado de Tanenbaum (1997, pg. 33).
Cada camada responsvel por uma funo especfica, conforme descrito a seguir:
a) fsica: trata da transmisso de bits brutos atravs de um canal de comunicao;
b) enlace: transforma um canal de transmisso de dados brutos em uma linha que
parea livre dos erros de transmisso no detectados na camada de rede;
c) rede: especifica o modo como os pacotes so roteados da origem para o destino;
d) transporte: sua principal funo realizar a diviso dos dados em pacotes de
tamanhos compatveis com a camada de rede a ser utilizada e, reagrup-los sem
erros na outra extremidade. Esta a verdadeira camada fim-a-fim que liga a
origem ao destino atravs da resoluo de seus endereos e nomes. tambm a
camada responsvel pelo estabelecimento das conexes e pelo controle de fluxos;
e) sesso: permite que usurios de diferentes mquinas estabeleam sesses entre si.
Um dos servios desta camada gerenciar o controle de trfego;
f) apresentao: preocupa-se com a sintaxe e a semntica das informaes
transmitidas, como por exemplo, a codificao dos dados de acordo com o padro
estabelecido;
g) aplicao: possui aplicaes especficas para o protocolo, tais como transferncia
12
de arquivos, gerncia de rede, etc.
Observa -se que o modelo OSI em si no uma arquitetura de rede, pois no especifica
os servios e os protocolos que devem ser usados em cada camada. Ele apenas informa o que
cada camada deve fazer.
O modelo OSI possui trs conceitos fundamentais:
a) servios;
b) interfaces;
c) protocolos.
Esta separao entre estes trs conceitos talvez seja a maior contribuio do modelo
OSI, pois torna explcita a distino entre estes trs conceitos. O servio informa o que a
camada faz. A interface de uma camada informa como os processos acima dela podem acessla, e finalmente, que os protocolos utilizados em uma camada so de responsabilidade apenas
dessa camada e estes especificam a forma com que a camada implementa seus servios
atravs das interfaces.
O modelo de referncia Internet segundo Kurose (2001) possui cinco camadas:
a) aplicao: responsvel pelas aplicaes de rede. Inclui vrios protocolos como
Hipertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), SNMP, etc;
b) transporte: fornece os servios para o transporte das mensagens da camada de
aplicao entre os lados cliente e servidor da aplicao. Possui dois protocolos:
TCP (orientado conexo) e o UDP (no orientado conexo).
c) rede: responsvel pelo roteamento de datagramas de um equipamento para outro.
Possui o IP, que define os campos do datagrama IP e protocolos de roteamento,
que ditam a rota a ser tomada pelos datagramas IP entre a origem e o destino;
d) enlace: a camada de rede roteia um pacote entre uma srie de transmissores de
pacotes (chamados roteadores) entre a origem e o destino. Como exemplos de
camadas de enlace podem-se citar o padro Ethernet e o Point to Point Protocol
(PPP);
e) fsica: enquanto o trabalho da camada de enlace mover frames inteiros de um n
para o outro, o trabalho da camada fsica o de mover bits individuais de cada
frame de um n para o outro.
13
3 GERNCIA DE REDES DE COMPUTADORES

Segundo Stallings (2001), as redes de computadores e os sistemas de processamento
distribudo so de crescente importncia e, de fato, se tornaram essenciais no mundo dos
negcios. Hoje em dia, uma organizao tpica possui uma arquitetura de redes grande e
crescente, mas amrfica, com vrias redes locais (LANs) e redes de larga escala (WANs),
suportadas por pontes (bridges) e roteadores (routers), e uma grande variedade de servios e
dispositivos computacionais distribudos, incluindo Personal Computers - PCs, estaes de
trabalho, e servidores (inclusive mainframes). Com esse crescimento em escala das redes de
computadores, dois fatos se tornam dolorosamente evidentes:
a) a rede e seus recursos a ela associados, se tornaram indispensveis para a
organizao;
b) mais coisas podem dar errado, interrompendo o funcionamento da rede ou de
parte dela, degradando o desempenho para um nvel inaceitvel.
J para Rose (1994), h dois motivos pelos quais a gerncia de redes necessria:
a) dispositivos heterogneos: pelo fato da interconexo de redes permitir diferentes
tipos de dispositivos participarem da rede, estes componentes (hosts , routers,
switches , etc) iro quase sempre ser de fabricantes diferentes, e heterogneos por
natureza. Atualmente, h no mercado dis positivos de centenas de fabricantes, cada
um com vrios modelos de cada linha de produto, que implementam o protocolo
TCP/IP. Evidencia -se que uma tecnologia de gerenciamento especfica de um
vendedor inutilizvel em tais ambientes. Assim, como apenas a utilizao de uma
tecnologia de interconexo "aberta", ou seja, no proprietria como o TCP/IP o
que torna um ambiente com mltiplos fabricantes de dispositivos uma realidade,
tambm uma tecnologia de gerenciamento de redes "aberta" (SNMP), o que torna
possvel gerenciar estes diferentes dispositivos;
b) administraes diferentes: pelo fato de interconexo de redes permitir vrias redes
com tamanhos e propsitos diferentes se interconectarem, estas redes iro quase
sempre estar sob administraes diferent es, como o caso atual da Internet.
Para gerenciar estes sistemas e redes, que continuam a crescer em escala e diversidade,
um conjunto rico e automatizado de ferramentas de gerenciamento de redes se faz necessrio.
fundamental, para o uso destas ferramentas e aplicaes em um ambiente com
14
mltiplos fabricantes, a utilizao de tcnicas padronizadas para representar e trocar
informaes relacionadas ao gerenciamento de redes (Stallings, 2001).
Para isto, preciso definir o que significa o termo gerenciamento de redes. Abaixo
duas definies so apresentadas:
O gerenciamento de redes/sistemas a soma total de todos os procedimentos e
produtos para planejamento, configurao, controle, monitoramento e gerenciamento de redes
de computadores e sistemas distribudos, e a remoo de erros destes sistemas. Estes recursos
devem prover suporte econmico e amigvel aos usurios que trabalham com a rede e seus
componentes. Logo, cobre todas as precaues e atividades necessrias para assegurar o uso
efetivo e eficiente dos recursos gerenciados (Hegering, 1994).
A gerncia de redes inclui o desenvolvimento, integrao, e coordenao de
hardware, software e elementos humanos para monitorar, testar, juntar (poll), configurar,
analisar, avaliar, e controlar a rede e seus recursos para alcanar em tempo real, o
desempenho operacional e a qualidade de servio requisitados a um custo razovel.
(SAYDAM 1, apud KUROSE, 2001, p. 630-631).
Hegering (1994), ainda divide o gerenciamento de redes em trs dimenses:
a) a dimenso funcional: esta dimenso se preocupa com a designao de tarefas de
gerenciamento em reas funcionais. O modelo ISO de gerenciamento prov uma
subdiviso
com
as
seguintes
reas:
configurao,
falhas,
desempenho,
contabilizao e segurana;
b) a dimenso temporal: divide os processos que implementam as funes de
gerenciamento em fases com diferentes ciclos de vida, incluindo as fases de
planejamento, implementao e operao;
c) a dimenso de cenrio: recentemente, alm do gerenciamento clssico de redes, um
nmero de outros cenrios de gerenciamento tais como gerenciamento de
sistemas, gerenciamento de aplicaes e gerenciamento empresarial, vem surgindo.
Estes cenrios so diferenciados pelo fato de que os objetos alvo de gerenciamento
so diferentes em cada caso, o que geralmente leva a diferentes aplicaes de
gerenciamento.
15
Kurose (2001) cita que a ISO/IEC criou um modelo de gerenciamento de redes que
define cinco reas funcionais de gerncia:
a) gerncia de desempenho: o objetivo desta rea quantificar, medir, relatar, analisar
e controlar o desempenho de diferentes componentes da rede. Estes componentes
podem ser dispositivos individuais, como roteadores e equipamentos, ou
abstraes, tais como um caminho ao longo da rede;
b) gerncia de falhas: registrar, detectar e responder s condies de falhas na rede
so os objetivos desta rea. A linha entre gerncia de falhas e gerenciamento de
desempenho imprecisa. Pode -se pensar na gerncia de falhas como o tratamento
imediato de falhas transientes da rede, enquanto que o gerenciamento de
desempenho busca ter uma viso aprofundada da rede para poder fornecer nveis
aceitveis de desempenho tendo em vista as vrias demandas de trfego e
ocasionais falhas de dispositivos de rede. A gerncia de falhas
geralmente
corretiva enquanto que a gerncia de desempenho quase sempre preventiva;

c) gerncia de configurao: permite ao administrador da rede rastrear quais
dispositivos fazem parte da rede gerenciada e realizar a configurao de hardware e
software destes dispositivos;
d) gerncia de contabilizao: esta rea permite ao administrador da rede especificar,
registrar e controlar o acesso dos usurios aos dispositivos da rede. Cotas de uso,
cobranas baseadas em uso de recursos e a alocao de privilgios de acesso aos
recursos, fazem parte da gerncia de contabilizao;
e) gerenciamento de segurana: o objetivo da gerncia de segurana controlar o
acesso aos recursos da rede de acordo com polticas bem definidas. Os centros de
distribuio de chaves e autoridades certificadoras so componentes da gerncia de
segurana. O uso de firewalls para monitorar e controlar pontos de rede de acesso
externo outro componente fundamental.
Em resposta a estas necessidades de gerenciamento, administradores de rede e
usurios se voltaram para um padro: o SNMP. O SNMP foi especificado no final dos anos 80
e rapidamente se tornou o padro para o gerenciamento de redes em plataformas com
mltiplos fabricantes. O SNMP se refere na verdade, a um conjunto de padres para o
gerenciamento de re des, incluindo um protocolo, uma especificao de uma estrutura de base
de dados e um conjunto de objetos de dados. Entretanto, o SNMP era muito limitado para
16
atender a todas as necessidades crticas de gerenciamento de redes. Trs melhorias (1993
SNMPv2, 1995 reviso do SNMPv2, 1998 SNMPv3) solidificaram o papel do SNMP
como uma ferramenta indispensvel para o gerenciamento de redes (Stallings, 2001).
O SNMP ser abordado com mais detalhes no captulo 4.
3.1 ARQUITETURA DE UM SISTEMA DE GERENCIAMENTO

DE REDES
Um sistema de gerenciamento de redes, segundo Stallings (2001), uma coleo de
ferramentas para o monitoramento e controle da rede que so integradas da seguinte forma:
a) uma nica e poderosa interface operacional, porm amigvel e com um conjunto
de comandos para realizar quase todas, seno todas as tarefas de gerenciamento de
redes;
b) uma quantidade mnima de equipamentos necessria.
Um sistema de gerenciamento de redes consiste de adies incrementais de hardware e
software implementados entre os componentes j existentes na rede. Um sistema de
gerenciamento de redes designado para visualizar a rede como uma arquitetura unificada.
Cada n da rede contm uma coletnea de softwares responsvel pela tarefa de
gerenciamento, e so referenciados como uma entidade de gerenciamento de rede (EGR ou
Network Management Station - NMS), conforme mostrado na figura 3.
Cada EGR pode realizar as seguintes tarefas:
a) coletar estatsticas sobre atividades relacionadas rede e s comunicaes;
b) armazenar estatst icas localmente;
c) responder aos comandos do centro de controle da rede incluindo comandos para:
- transmitir as estatsticas coletadas para o centro de controle;
- alterar um parmetro;
- fornecer informaes sobre o estado da rede;
- gerar trfego artificial para realizar um teste;
d) enviar mensagens ao centro de controle quando condies locais sofrerem
mudanas significativas.
17
Pelo menos um equipamento na rede designado como o equipamento de controle da
rede, ou gerente. Alm dos elementos de uma EGR, o equipamento de controle inclui uma
coleo de softwares chamados de aplicao de gerenciamento de rede (AGR). A AGR inclui
uma interface operacional para permitir que um usurio autorizado gerencie a rede. A AGR
responde aos comandos do usurio atravs da exibio de informaes e/ou atribuindo
comandos s EGRs da rede. Esta comunicao realizada usando um protocolo de nvel de
aplicao de gerenciamento de rede, que emprega a arquitetura de comunicao da mesma
forma que qualquer outra aplicao distribuda.
FIGURA 3 Elementos de um sistema de gerenciamento de redes
E le m e nto s de um S is t em a de G e r e nc ia m e nto d e Re de s
H o s t d e c o n t r o le
S e r v id or
da re de (ge rent e )
( a g e n t e)
EG R
A GR
A p l ic
Co m
EG R
A plic
Co m
SO
SO
R o t e ad or
(a g e n t e )
EG R
E s t a o d e
t r a b a lh o
( a ge nt e)
E GR
Co m
A plic
C om
SO
A G R = A p li c a o d e G e r e n c ia m e n t o d e R ed es
A p l i c = A p l i ca o
SO
E G R = E n ti d a d e d e G e r e n c ia m e n to d e R e d e
C o m = s o f t w a r e d e c o m u n ic a o
S O = S i s te m a O p e r a c io n a l
FONTE: Adaptado de Stallings (2001, pg. 8).
Outros ns na rede que fazem parte do sistema de gerenciamento de redes incluem

uma EGR que responde aos pedidos de um gerente do sistema. A EGR em tais sistemas
geralmente um mdulo agente, ou simplesmente, agente. Os agentes so implementados em
18
sistemas que suportam aplicaes de usurios finais bem como em ns que provem servios
de comunicao, tais como pontes e roteadores.
A configurao da figura 3 d a entender que cada componente da configurao que
de interesse de gerenciamento, inclui uma entidade de gerenciamento de rede, com um
software de gerenciamento de rede comum que atua sobre todos os agentes e gerentes. Na
configurao atual, isto pode no ser prtico, ou at mesmo impossvel. Para lidar com tais
casos, comum ter um dos agentes no sistema atuando como um proxy, para um ou mais ns
da rede (fig. 4).
FIGURA 4 Arquitetura de uma entidade proxy
Ar quit etur a de um a e nti da de pr ox y
A p l ic .
S tu b
C li e n t e
P i lh a d e
prot oc olos
In te r fa c e d e G e r e n ci a m e n t o
G e r en te d e P r o xy
G e r e n c ia m e n t o
P r op r i e t r i a
S t ub
S tu b
S e r v id o r
C li e n te p r o xy
P il h a d e
Pilha d e
p r o to c o lo s
p r ot o c o l o s
S t u b S e v id o r p ro xy
P i lh a d e p r o t o c o l o s
R e l a t r io s d e
R e l a t r io s d e
e ve n to s e o p e r a e s
p adr o
e ve n t o s e o p er a es
p r o p r ie t r i a s
Quando um agente atua como um proxy , ele age em benefcio de um ou mais ns da

rede. Um gerente que desejar obter informaes do n ou control -lo, deve se comunicar com
o agente proxy. O agente proxy ir traduzir a requisio do gerente usando qualquer protocolo
de gerenciamento disponvel, de modo que o sistema alvo receba e entenda a requisio feita.
A resposta recebida do sistema alvo similarmente traduzida e repassada ao gerente.
19
3.2 GERENCIAMENTO DE DESEMPENHO

Segundo Stallings (2001), as redes de comunicao de dados modernas so compostas
de muitos componentes, que devem se intercomunicar e compartilhar dados e recursos. Em
a lguns casos, crtico, para a eficcia de uma aplicao, que a comunicao pela rede tenha
certos limites de desempenho.
O gerenciamento de desempenho de uma rede de computadores engloba duas grandes
categorias funcionais: monitoramento e controle. Monitoramento a funo que rastreia
atividades na rede. A funo de controle habilita a gerncia de desempenho a fazer ajustes
para aumentar o desempenho da rede. Algumas questes de desempenho, no que diz respeito
ao administrador da rede so:
a) qual a utilizao do nvel de capacidade?
b) h trfego excessivo?
c) o throughput foi reduzido a nveis inaceitveis?
d) existem gargalos na rede?
e) o tempo de resposta est aumentando?
Para lidar com estes problemas, o administrador de rede deve focar -se em algum
conjunto inicial de recursos a serem monitorados para medir os nveis de desempenho. Isto
inclui associar mtricas apropriadas e valores com recursos relevantes da rede, como
indicadores de diferentes nveis de desempenho.
Hegering (1994) v o gerenciamento de desempenho como uma continuao
consistente do gerenciamento de falhas. Enquanto que o gerenciamento de falhas
responsvel por assegurar que a rede de comunicao permanea funcionando, isto no
suficiente para o gerenciamento de desempenho, que se posiciona com o objetivo de assegurar
que o sistema como um todo esteja oferecendo uma boa qualidade de servio.
Algumas subtarefas da gerncia de desempenho incluem:
a) determinar parmetros de qualidade de servio;
b) monitorar a rede de comunicao em busca de gargalos;
c) executar medidas de desempenho;
d) processar os dados medidos e gerar relatrios;
e) planejar a capacidade e o desempenho da rede.
20
Para Stallings (2001), o gerenciamento de desempenho deve monitorar muitos
recursos para fornecer informaes para determinar os nveis de operao da rede. Pela coleta
destas informaes, sua anlise e o uso dos resultados obtidos como retorno (feedback) ao
conjunto de valores prescritos, o administrador da rede pode se tornar mais e mais apto a
reconhecer situaes indicativas de degradaes de desempenho presentes ou iminentes.
Antes de usar uma rede para executar uma aplicao em particular, um usurio final
pode querer saber coisas como o pior tempo de resposta e a confiabilidade dos servios da
rede. Por isso o desempenho de ve ser conhecido em detalhes suficientes para responder aos
questionamentos especficos dos usurios finais. Os usurios finais esperam que os servios
sejam gerenciados de forma a garantir bons tempos de resposta para obter assim, uma boa
utilizao de suas aplicaes.
Os gerentes de rede precisam de estatsticas de desempenho para ajud-los a planejar,
gerenciar e manter grandes redes funcionando. As estatsticas de desempenho podem ser
usadas para identificar potenciais gargalos antes que causem problemas aos usurios finais.
Aes corretivas apropriadas podem ento ser tomadas. Estas aes podem tomar a forma de
alteraes nas tabelas de roteamento para balancear ou redistribuir a carga de trfego durante
perodos de pico, ou quando um gargalo ide ntificado por um crescimento rpido de carga
em uma rea especfica. De modo geral, um planejamento de capacidade baseado em tais
informaes de desempenho pode indicar as decises apropriadas a serem tomadas, como por
exemplo, a expanso de linhas naquela rea.
Por tudo isso, um pr-requisito absoluto para o gerenciamento de uma rede de
computadores a habilidade de medir o desempenho da rede, ou monitoramento de
desempenho. No se pode gerenciar e controlar um sistema ou atividade se no for possvel
monitorar o seu desempenho. Uma das dificuldades que o administrador de redes encontra
na seleo e uso dos indicadores apropriados para medir o desempenho da rede. Dentre os
problemas pode -se citar os seguintes:
a) existem muitos indicadores para usar;
b) o significado de muitos destes indicadores no so claramente compreendidos;
c) alguns indicadores so suportados apenas por alguns fabricantes;
d) muitos indicadores no servem para fazer comparaes entre si;
21
e) freqentemente, os indicadores so medidos corretamente, mas interpretados
incorretamente;
f) em muitos casos, o clculo dos indicadores consome muito tempo, e o resultado
final j no pode mais ser usado para controlar o ambiente.
H dois tipos de indicadores: medidas orientadas a servios e medidas orientadas
eficincia. As medidas orientadas a servios possuem os seguintes indicadores:
a) disponibilidade: o percentual de tempo que uma rede, um componente, ou uma
aplicao est disponvel para o usurio;
b) tempo de resposta: quanto tempo preciso para uma resposta aparecer no terminal
do usurio aps uma solicitao feita pelo mesmo;
c) preciso: o percentual de tempo em que no ocorrem erros na transmisso e
recepo de informaes.
J as medidas orientadas a eficincia possuem indicadores de:
a) throughput: a taxa na qual as aplicaes orientadas a eventos ocorrem;
b) utilizao: o percentual da capacidade terica de um recurso que est sendo
utilizado.
Kurose (2001) cita que a rea de monitoramento de desempenho da rede no
gerenciamento de redes responsvel por observar e analisar o estado e o comportamento dos
sistemas fim (end systems), dos sistemas intermedirios e sub-redes que compe os recursos
gerenciados.
De acordo com Stallings (2001), a arquitetura funcional de monitoramento de redes
composta de:
a) aplicao de monitorao: este componente inclui as funes de monitoramento de
rede que so visveis ao usurio, tais como monitoramento de desempenho,
monitoramento de falhas e monitoramento de configurao;
b) funo gerente: este o mdulo no monitor da rede que realiza a funo de
monitoramento
bsica,
buscando
informaes
de
outros
elementos
da
configurao;
c) funo agente: este mdulo obtm e registra informaes de gerenciamento para
um ou mais elementos de rede e repassa essas informaes ao monitor;
22
d) objetos gerenciados: estas so as informaes gerenciadas, que representam os
recursos da rede e suas atividades;
importante mencionar um mdulo funcional adicional relacionado com informaes
estatsticas:
e) agente de monitorao: este mdulo adicional gera sumrios e anlises estatsticas
das informaes gerenciadas. Se afastado do gerente, este mdulo age como um
agente e comunica estas informaes ao gerente.
O monitoramento de desempenho engloba todas as cinco reas funcionais. As
informaes disponveis para a monitorao da rede podem ser classificadas como segue:
a) esttica: esta a informao que caracteriza a configurao corrente e os elementos
na configurao corrente, tais como os nmeros e identificaes das portas de um
roteador;
b) dinmica: estas informaes so relativas a eventos na rede, tais como: mudanas
de estado de uma mquina ou a transmisso de um pacote pela rede;
c) estatstica: estas so informaes que podem ser derivadas das informaes
dinmicas, como por exemplo, o nmero mdio de pacotes transmitidos por
unidade de tempo por um sistema fim.
3.2.1
FUNO DE MONITORAMENTO DE DESEMPENHO

Segundo Stallings (2001), a funo de monitoramento de desempenho engloba trs
componentes:
a) medida de desempenho: a reunio de estatsticas sobre o trfego da rede e
temporizao;
b) anlise de desempenho: consiste de software para reduzir e apresentar os dados;
c) gerao de trfego sinttico: consiste de software que permite observar a rede sob
uma carga controlada.
A medida de desempenho quase sempre completada por mdulo s agentes junto aos
dispositivos da rede (equipamentos, roteadores, pontes, etc). Estes agentes esto em posio
de observar a quantidade de trfego que entra e sai de um n, o nmero de conexes e o
trfego por conexo, alm de outras medidas que fornecem um cenrio detalhado do
23
comportamento daquele n. Em uma rede compartilhada, tal como uma LAN, muitas das
informaes necessrias podem ser coletadas por um monitor externo ou remoto que
simplesmente observa o trfego na rede.
Alguns tipos de medidas que podem ser obtidas em uma LAN tpica so as seguintes:
a) histograma de tipos de pacotes circulando na rede;
b) histograma com os tamanhos dos pacotes;
c) histograma com os tamanhos dos pacotes de dados;
d) distribuio ou utilizao de throughput;
e) histograma do tempo de chegada de pacotes;
f) histograma com a demora de aquisio de canal;
g) histograma com a demora de comunicao;
h) histograma com a contagem de colises;
i) histograma com o contador de transmisses;
Com estas medidas possvel responder s vrias perguntas feitas por um
administrador de redes relacionadas ao desempenho de uma LAN tais como:
a) o trfego est igualmente distribudo entre os usurios da rede ou h pares
origem/destino com trfego pesado?
b) qual o percentual de cada tipo de pacote? Existem alguns tipos de pacotes com
alta freqncia de uso, indicando um erro ou um protocolo ineficiente?
c) qual a distribuio dos tamanhos dos pacotes de dados?
d) quais so as demoras na aquisio de canal e as distribuies de comunicao?
Esses tempos so excessivos?
e) qua l a utilizao do canal e seu throughput?
Quando a rede possui uma carga de trfego muito pesada, pode no ser prtico coletar
os dados exaustivamente. A alternativa tratar cada parmetro como uma varivel aleatria
realizando uma amostragem do fluxo de modo a estimar o valor desta varivel. Entretanto,
deve -se tomar cuidado ao se usar e interpretar as estimativas de resultados estatsticos. O
indivduo responsvel por desenvolver funes de amostragem e por interpretar os resultados
precisa ter alguma familiaridade com os princpios estatsticos.
24
4 SIMPLE NETWORK MANAGEMENT PROTOCOL

Nos anos 60, segundo Stallings (2001), o assunto gerncia de redes no existia. Nos
anos 70 e metade dos anos 80, apenas o Internet Control Message Protocol (ICMP) e o
Packet Internet Groper (PING) eram utilizados para tal tarefa. Com o crescimento da Internet
no fim dos anos 80, surgiu a necessidade de se criar ferramentas para o gerenciamento das
redes existentes. Primeiro foi o Simple Gateway Monitoring Protocol (SGMP) em 1987. A
partir dele surgiram o Host Monitoring Protocol (HMP), o primeiro protocolo de
gerenciamento usado na Internet, o SNMP (uma verso melhorada do SGMP), e o Common
Management Information Protocol over TCP/IP (CMOT).
A IAB aprovou em 1988 o SNMP como uma soluo temporria e o CMOT como o
padro a ser adotado mais tarde. Para tal a IAB determinou que ambos os protocolos usassem
a mesma base de dados de objetos gerenciados. Assim ambos usariam uma nica estrutura de
gerenciamento de informaes (Structure of Management Information SMI), e uma nica
base de gerenciamento de informaes (MIB). O objetivo era tornar mais fcil a futura
transio do SNMP para o CMOT. Mas logo se tornou claro que tal ligao seria impossvel.
No gerenciamento OSI, os objetos gerenciados so vistos como entidades
sofisticadas, com atributos, procedimentos associados, e capacidades de emisso de
mensagens, alm de outras caractersticas complexas associadas com a tecnologia orientada a
objetos. Para manter o SNMP simples, ele no foi designado para trabalhar com estes
conceitos sofisticados. De fato, os objetos no SNMP nada mais so do que variveis com
algumas caractersticas bsicas, como tipos de dados e atributos de somente-leitura (readonly) ou leitura-escrita (read-write ). Por isso a IAB relaxou seus termos e com isso o SNMP e
o CMOT evoluram independentemente e em paralelo. Os desenvolvedores do SNMP, livres
das restries de compatibilidade com o modelo OSI desenvolveram rapidamente o SNMP e
logo ele estava sendo usado em larga escala pelos vendedores de equipamentos e seu uso
espalhou-se pela Internet. Enquanto isso, os esforos no CMOT se esvaeceram. Atualmente,
virtualmente todos os grandes vendedores de equipamentos, estaes de trabalho, roteadores,
pontes e hubs, oferecem suporte ao SNMP.
As trs especificaes fundamentais do SNMP so:
25
a) Request for Comment - RFC 1155: descreve como os objetos gerenciados contidos
nas MIBs so definidos (SMI);
b) RFC 1213: descreve os objetos gerenciados contidos na MIB (MIB-II);
c) RFC 1157: define o protocolo usado para gerenciar os objetos (SNMP).
Todas as RFCs citadas no presente trabalho podem ser encontradas em
RFC/STD/FYI/BCP Archives (199-).
Para Lynch (1993), o gerenciamento de redes moderno possui muitos requisitos
importantes. Primeiro, a estrutura de gerenciamento deve suportar tanto monitoramento
quanto controle. Segundo, deve possuir a habilidade de gerenciar todas as camadas da
implementao do modelo OSI fornecendo um gerenciamento topo-base (top-down ).
Terceiro, pela mxima extenso possvel e economicamente vivel, o escopo do
gerenciamento da rede deve ser fim-a-fim. Deve englobar todos os sistemas da rede.
Finalmente, o impacto dessa estrutura de gerenciamento de redes no deve ser visvel, ou
perceptvel. A largura de banda consumida pelas funes de gerenciamento deve estar dentro
de certos limites. Ento, por que no usar o Common Management Information Protocol CMIP?
Para Lynch (1993), primeiro porque a sobrecarga de implementar o Common
Management Information Service - CMIS e CMIP em sistemas com recursos limitados pode
ser muito caro. Segundo, estes protocolos ocupam uma pequena fatia do mercado atualmente,
logo, os vendedores escolhem implementar o SNMP ao invs do CMIP e, como resultado, o
mercado ocupado pelo CMIP permanece pequeno. Finalmente, enquanto que o CMIS e CMIP
so padres internacionais bem definidos, muito da sua infraestrutura de suporte, tal como os
equivalentes ISO do SMI, MIBs e perfis de transporte, no alcanaram ainda este mesmo
nvel de padronizao e estabilidade.
4.1 CONCEITOS BSICOS DE SNMP

A seguir sero apresentados os conceitos bsicos relacionados ao SNMP, tais como
sua estrutura, seus elementos e a relao entre estes elementos.
26
4.1.1
ARQUITETURA
O modelo de gerncia de redes TCP/IP, de acordo com Stallings (2001), composto
pelos seguintes elementos:

a) estao de gerenciamento (gerente);
b) agentes;
c) base de informaes de gerenciamento;
d) protocolo de gerenciamento de redes.
A estao de gerenciamento serve como uma interface pela qual o administrador da
rede se comunica com o sistema de gerenciamento. No mnimo, uma estao de
gerenciamento ter:
a) um conjunto de aplicaes para anlise de dados, recuperao de falhas, etc;
d) uma interface pela qual o administrador da rede pode monitorar e controlar a rede;
e) a capacidade de traduzir os requisitos do administrador da rede no atual controle e
monitoramento dos elementos remotos da rede;
f) uma base de dados com informaes extradas das MIBs de todas as entidades
gerenciadas da rede.
Apenas os dois ltimos elementos esto sujeitos padronizao SNMP.
Outro elemento ativo no gerenciamento da rede o agente. O agente responde aos
pedidos de informaes e s aes vindas do gerente e pode prover de forma assncrona,
informaes no solicitadas, porm importantes, para a estao de gerenciamento.
Os recursos da rede podem ser gerenciados pela representao dos mesmos como
objetos. Cada objeto , essencialmente, uma varivel de dados que representa um aspecto do
agente gerenciado. Esta coleo de objetos denominada MIB. Estes objetos so
padronizados atravs de sistemas de uma classe em particular. Uma estao de gerenciamento
realiza a funo de monitoramento obtendo os valores dos objetos da MIB.
A estao de gerenciamento e os agentes so ligados por um protocolo de
gerenciamento de rede. O protocolo usado para o gerenciamento de redes TCP/IP o SNMP,
que possui as seguintes capacidades chave:
a) get: habilita a estao de gerenciamento a obter os valores dos objetos no agente;
27
b) set: habilita a estao de gerenc iamento a configurar os valores dos objetos no
agente;
c) trap: habilita o agente a notificar espontaneamente a estao de gerenciamento
sobre eventos significativos;
Alm destas primitivas, o SNMPv2 define uma nova primitiva:
e) inform: habilita o agente e o gerente a pedir confirmao de eventos de notificao.
O SNMP foi designado para ser um protocolo de nvel de aplicao que parte do
conjunto de protocolos TCP/IP. Ele foi projetado para operar sobre o UDP. Cada agente deve
no mnimo, implementar o SNMP, o UDP e o IP para poder agir como um agente (fig. 5).
FIGURA 5 O papel do SNMP
O P ap el do SN M P
E s t a o d e g e re n c i am e n t o S N M P
A g e n te S N M P
R e c u r s o s g e re n c ia d o s
A p li c . d e g e r e n c ia m e n to
Tr ap
G etRes pons e
SetRequest
GetNextRequest
GetRequest
Tr ap
G etRes pons e
SetRequest
GetNextRequest
GetRequest
O b j e t o s g e r e n c ia d o s S N M P
M e n s ag en s S N M P
G ere nt e S N M P
A ge nt e S N M P
U DP
U DP
IP
IP
P r o t o c ol o s d e p e n d e n t e s d e r e d e
P r o to c o lo s d e p e n d e n te d e r e d e
R e de o u
In t e r n e t
28
Um processo agente interpreta as mensagens SNMP e controla sua MIB. Trs tipos
de mensagem agem em favor de uma aplicao de gerenciamento na estao de
gerenciamento: GetRequest, GetNextRequest, e SetRequest. As duas primeiras so variaes
da funo get. Todos os trs tipos de mensagens so respondidos por um agente na forma de
uma mensagem GetResponse , que passada para a aplicao de gerenciamento. Alm destes
tipos de mensagens, um agente pode enviar uma mensagem de Trap em resposta a um evento
que afete a MIB e por conseqncia, os recursos gerenciados. Como o SNMP depende do
UDP, que um protocolo no orientado conexo, o SNMP em si, sem conexo.
4.1.2
SMI STRUCTURE OF MANAGEMENT INFORMATION

Segundo Stallings (2001), a base do sistema de gerenciamento usado no modelo
SNMP um banco de dados contendo informaes sobre os elementos gerenciados. Tanto no

ambiente TCP/IP quanto no OSI, esta base de dados chamada de base de informaes ou
simplesmente MIB, onde cada recurso gerenciado representado por um objeto. A MIB
uma coleo de tais objetos. Para o SNMP a MIB , em essncia, uma base de dados
estruturada na forma de uma rvore. Cada elemento da rede contm uma MIB que reflete o
estado dos recursos gerenciados pelo sistema de gerncia. Uma entidade de gerenciamento de
rede pode monitorar os recursos atravs da leitur a dos valores dos objetos na MIB e pode
controlar estes recursos gerenciados modificando estes valores.
Para que a MIB possa atender s necessidades de um sistema de gerenciamento, ela
deve atender certos objetivos:
a) o objeto ou objetos usados para representar um recurso em particular deve ser o
mesmo em todos os sistemas;
b) um projeto comum para representao destes objetos deve ser usado, para suportar
a interoperabilidade.
O item (b) alcanado no SNMP pela definio de uma estrutura de gerenciamento de
informaes, o SMI.
O SMI, que especificado na RFC 1155, define a estrutura principal na qual a MIB
pode ser definida e construda. O SMI identifica os tipos de dados que podem ser usados na
MIB e especifica como os recursos na MIB sero representados e nomeados. A filosofia por
29
trs do SMI encorajar a simplicidade e a extensibilidade das MIBs. O SMI no suporta a
criao ou a recuperao de estruturas de dados complexas. As MIBs iro inevitavelmente
conter tipos de dados definidos pelos vendedores de equipamentos de rede e, a menos que
restries na definio de tais tipos de dados sejam definidas, haver perda de
interoperabilidade.
Para fornecer uma forma padro de representao de informaes de gerenciamento, o
SMI deve fazer o seguinte:
a) fornecer uma tcnica padro para definir a estrutura de uma MIB em particular;
b) fornecer uma tcnica padro para definir objetos individuais, incluindo a sintaxe e
valor de cada objeto;
c) fornecer uma tcnica padro para codificao dos valores dos objetos.
4.1.2.1
ESTRUTURA MIB
Para Stallings (2001), todos os objetos gerenciados no ambiente SNMP esto

distribudos em uma estrutura hierrquica ou em rvore. Os objetos folhas desta rvore so
os objetos gerenciados em si, cada um deles representando algum recurso, atividade, ou
informao relevante que pode ser gerenciada. A estrutura em si define um agrupamento de
objetos em conjuntos de objetos logicamente relacionados. Associado com cada tipo de objeto
na MIB h um identificador do tipo Abstract Syntax Notation One - ASN.1 cha mado OBJECT
IDENTIFIER que serve para nomear o objeto. Em adio, devido ao valor associado ao tipo
OBJECT IDENTIFIER ser hierrquico, a conveno de nomeao tambm serve para
identificar a estrutura dos tipos de objetos. Partindo da raiz (root) da rvore OBJECT
IDENTIFIER, cada valor componente do identificador de objeto identifica uma folha na
rvore (fig. 6).
Partindo da raiz, h trs ns no primeiro nvel: iso, ccitt, e joint-iso-ccitt. Abaixo do n
iso, uma das subrvores para uso por parte de outras organizaes, uma delas sendo o U.S.
Department of Defense (dod). A RFC 1155 assume que uma subrvore abaixo do dod ser
alocada para administrao pela IAB como segue: internet OBJECT IDENTIFIER ::= {iso (1)
org (3) dod (6) 1}.
30
Por isso o n internet tem o identificador de objeto 1.3.6.1. Este valor serve como
prefixo para os ns abaixo deste nvel.
FIGURA 6 - Grupos de objetos MIB-2
is o ( 1 )
o rg ( 3)
d o d (6 )
in t e r n e t (1 )
d i re c t o ry ( 1 )
mgmt (2)
m ib-2 ( 1 )
s ys t em ( 1 )
in t e r fa c e s ( 2 )
a t (3 )
ip ( 4 )
ic m p (5 )
t c p (6 )
ud p (7 )
eg p (8 )
tr a n s m is s io n ( 1 0 )
s nm p (11 )
e x p e r i m e n ta l ( 3 )
p r iv a t e ( 4 )
en t erpr is es (1 )
Como mostra a figura 6, o SMI define quatro ns abaixo do n internet:

a) directory: reservado para uso futuro com o diretrio OSI;
b) mgmt : usado por objetos definidos em documentos aprovados pelo IAB;
31
c) experimental: usado para identificar objetos usados em experimentos na Internet;
d) private: usado para identificar objetos definidos unilateralmente.
A subrvore mgmt contm as definies de bases de gerenciamento MIB que foram
aprovados pelo IAB. Atualmente, duas verses da MIB foram desenvolvidas, mib-1 e mib-2.
A segunda uma exte nso da primeira e o padro usado pelo SNMPv3. Ambas
possuem os mesmos identificadores de objeto na subrvore, mas apenas uma das MIBs est
presente em qualquer configurao. Objetos adicionais podem ser definidos para uma MIB
das seguintes maneiras:
a) a subrvore mib-2 pode ser expandida ou substituda por uma reviso
completamente nova (presumivelmente mib-3). Para expandir a mib-2 uma nova
subrvore definida;
b) uma MIB experimental pode ser construda para uma aplicao em particular. Tais
objetos pode m subseqentemente ser removidos da subrvore mgmt;
c) extenses privadas podem ser adicionadas a subrvore private.
Hegering (1994) define um nico nvel estrutural integrante da MIB internet, o nvel
group. Este subdividido em 10 subgrupos conforme segue:
a) system: informaes de configurao sobre o n gerenciado como um todo;
b) interfaces: informaes de interface sobre os sistemas conectados;
c) at addres translation : informaes para resoluo de endereos;
d) ip, icmp, tcp , udp , egp , snmp : informaes sobre os protocolos IP, ICMP, TCP,
UDP, Exterior Gateway Protocol EGP, e SNMP;
e) transmission : informaes sobre tipos especficos de interfaces de rede tais como
Ethernet, Token Ring, loopback, etc.
Atualmente, segundo Stallings (2001), a subrvore private contm apenas um n
definido: o n enterprises. Esta parte da subrvore usada por vendedores para aperfeioar o
gerenciamento de seus dispositivos e para compartilhar informaes com outros usurios e
vendedores que necessitem interoperar com seus sistemas.
A diviso do n internet em quatro subrvores fornece uma fundamentao forte para
a evoluo das MIBs. Com os experimentos de novos objetos por parte dos vendedores e de
32
outros desenvolvedores, se ganha um conhecimento prtico desses novos objetos antes que
eles sejam definidos como parte integrante dos padres para o subgrupo mgmt. Com isso, a
MIB til imediatamente para gerenciar objetos que se encaixam na parte padro da MIB e
flexvel o bastante para se adaptar s mudanas de ofertas de produtos e tecnologias.
Ao conjunto de operaes de gerenciamento permitidas a uma aplicao gerente por
um agente denomina-se poltica de acesso; a coleo de objetos que so visveis para estas
operaes denominada viso MIB, ou simplesmente uma viso (Hegering, 1994).
4.1.2.1.1
SUBGRUPO IP
Para o desenvolvimento do prottipo, sero utilizados alguns dos objetos escalares

existentes no grupo ip da mib-2. Estes objetos sero utilizados para realizar o monitoramento
de desempenho, atravs da medio da utilizao de throughput da rede - no que diz respeito
aos pacotes IP transmitidos e recebidos - pelo dispositivo analisado, fornecendo assim
informaes dinmicas sobre a utilizao destes recursos feitos pelo dispositivo em questo e
o seu impacto na utilizao total da largura de banda da rede na qual est inserido.
Segundo Zeltserman (1999), o subgrupo ip composto de objetos escalares, uma
tabela de endereos, uma tabela de roteamento e uma tabela de endereos de rede para mdias.
Alguns dispositivos implementam diversos mdulos de roteamento e mantm objetos do
grupo MIB para cada mdulo. possvel acessar subgrupos ip diferentes atravs de strings de
comunidade proxy ou atravs de endereos IP diferentes.
Os objetos escalares que atualmente fazem parte do subgrupo ip so:
a) ipForwarding: pode ser forwarding (1) ou no forwarding (2). Quando o
ipForwarding estiver habilitado, o dispositivo age como um roteador normal e ir
encaminhar os pacotes IP de uma sub-rede para outra quando requisitado. Quando
o ipForwarding estiver desabilitado, o dispositivo descarta os pacotes IP no
endereados para uma de suas interfaces definidas localmente. Ir tambm
incrementar o contador ipInAddrErrors para cada pacote descartado;
b) ipDefaultTTL: tempo de vida (Time-To-Live - TTL) padro;
c) ipInReceives : nmero total de datagramas de entrada recebidos de todas as
interfaces, incluindo aquelas com erros;
33
d) ipInHdrErrors: nmero de datagramas de entrada descartados devido a erros no
seu cabealho IP. Isto inclui falhas de checksum, nmero de verso incompatvel,
outros erros de formato, tempo de vida excedido, e erros descobertos no
processamento das opes IP;
e) ipInAddrErrors: nmero de datagramas de entrada descartados porque o endereo
IP de destino no vlido. Isto inclui endereos invlidos, endereos de classes no
suportadas e pacotes que no podem ser encaminhados porque o ipForwarding est
desativado;
f) ipForwDatagrams : nmero de datagramas encaminhados;
g) ipInUnknownProtos : nmero de datagramas recebidos com sucesso mas
descartados porque o pr otocolo era ou desconhecido ou no suportado;
h) ipInDiscards: nmero de datagramas de entrada descartados devido a limitaes de
recursos, como por exemplo, a falta de espao em buffer;
i) ipInDelivers : nmero de datagramas entregues para os protocolos de usurio IP
local;
j) ipOutRequests: nmero de datagramas IP requisitados para transmisso. Este
contador no inclui qualquer datagrama contado no ipForwDatagrams;
k) ipOutDiscards: nmero de datagramas de sada descartados devido falta de
recursos;
l) ipOutNoRoutes: nmero de datagramas descartados porque no foi possvel
encontrar o roteador no endereo de destino;
m) ipReasmTimeout: valor de timeout em segundos pelo qual fragmentos IP
recebidos esperam enquanto aguardam o reagrupamento;
n) ipReasmReqds: nmero de fragmentos IP recebidos que precisam ser reagrupados;
o) ipReasmOKs: nmero de datagramas IP reagrupados com sucesso;
p) ipReasmFails: nmero de falhas de reagrupamento;
q) ipFragsOKs: nmero de datagramas IP fragmentados com sucesso;
r) ipFragsFails: nmero de datagramas IP que necessitam fragmentao mas que
precisam ser descartados porque possuem a flag IP no fragmentar configurada;
s) ipFragCreates: nmero de fragmentos IP criados;
t) ipRoutingDiscards: nmero de entradas na tabela de roteamento que foram
descartadas devido a limitaes de recursos.
34
Estes objetos podem ajudar a identificar especificamente:
a) limitaes de recursos;
b) grande nmero de pacotes sendo fragmentados. Isto pode ser causado devido a
incompatibilidades na Maximum Transfer Unit - MTU. A reduo da quantidade
de fragmentao ir provavelmente aumentar o desempenho da rede;
c) grande nmero de pacotes sendo reagrupados. Novamente, isto pode estar
acontecendo devido a incompatibilidades nas MTUs;
d) um grande percentual de falta de rotas. Isto pode indicar que um dispositivo no
est recebendo atualizaes de roteamento apropriadamente ou que a tabela de
roteamento foi desconfigurada e no contm rotas vlidas;
e) um grande percentual de reagrupamentos falhos. Pode indicar tanto que fragmentos
esto sendo corrompidos ou que fragmentos IP esto sendo descartados devido
falta de recursos;
f) um grande percentual de fragmentaes falhas. Provavelmente indica que os
dispositivos esto configurados com a flag no desfragmentar.
Enquanto que o conhecimento de que est se detectando um grande nmero de pacotes
com erros de cabealhos ou de endereamento fcil, a soluo do problema especfico no
to fcil e geralmente dependente de outros fatores que no sero abordados no presente
trabalho.
4.1.2.2
ASN.1
Para Lynch (1993), na camada de aplicao as estruturas de dados trocadas pelas

entidades de protocolo so potencialmente muito mais complexas. Portanto, necessrio
introduzir um novo formalismo para descrever estas estruturas. Esse novo formalismo
denominado sintaxe abstrata , que usada para definir dados sem considerar as estruturas
orientadas mquina e suas restries. Na estrutura de gerenciamento, uma linguagem OSI
denominada ASN.1 usada para atender este princpio. Vale lembrar que a ASN.1 usada
por duas razes distintas pela estrutura de gerenciamento:
a) definir o formato dos dados (objeto e seu respectivo valor) trocados pelo protocolo
de gerenciamento; e
b) definir os objetos que so gerenciados.
35
Logo, a sintaxe abstrata usada para descrever ambos, as estruturas de dados trocadas
no nvel de protocolo e a informao gerenciada que transportada por estas estruturas de
dados.
Segundo Stallings (2001), cada objeto em uma MIB SNMP definido formalmente; a
definio especifica os tipos de dados dos objetos, suas formas aceitveis e limites de valores,
e seu relacionamento com outros objetos da MIB. A notao ASN.1 usada para definir cada
objeto individualmente e, alm disso, definir toda a estrutura da MIB.
4.1.2.3
CODIFICAO
Os objetos na MIB so codificados usando regras bsicas de codificao (Basic

Encoding Rules - BER) associadas com a ASN.1. Apesar de no ser a forma mais compacta
ou eficiente de codificao, a BER uma estrutura de codificao amplamente usada e
padronizada. (Stallings, 2001)
4.1.3
TRAP -DIRECTED POLLING

De acordo com Stallings (2001), as informaes que so teis para o monitoramento
da rede so coletadas e armazenadas por agentes e disponibilizadas para um ou mais sistemas

gerentes. Se uma estao de gerenciamento responsvel por um grande nmero de agentes, e
se cada agente guarda um grande nmero de objetos, ento se torna impraticvel para a
estao de gerenciamento regularmente sondar (poll) todos os agentes para obter todos os seus
dados de objetos passveis de leitura.
Ao invs disso, duas tcnicas so usadas para tornar as informaes do agente
disponveis ao gerente: polling e event reporting.
Polling uma interao pergunta-resposta entre gerente e agente. O gerente pode
consultar qualquer agente (ao qual possuir autorizao de acesso) e requisitar os valores de
vrios elementos de informao, e o agente responde com as informaes da sua MIB.
Um sistema gerente pode usar o polling para aprender sobre a configurao que est
gerenciando, para obter periodicamente uma atualizao de condies, ou investigar em
36
detalhe uma rea depois de ter sido alertado de um problema. O polling tambm usado para
gerar relatrios para o usurio e para responder a consultas especficas.
No caso do event reporting , a iniciativa do agente e o gerente atua como um ouvinte,
aguardando por novas informaes. Um agente pode gerar um relatrio peridico para
informar ao seu gerente seu estado atual. O perodo do relatrio pode ser pr-configurado ou
definido pelo gerente. Um agente tambm pode gerar um relatrio quando um evento
significativo (por exemplo, uma mudana de estado) ou um evento incomum (por exemplo,
uma falha) ocorrer. O event reporting til para detectar problemas to logo eles ocorram.
tambm mais eficiente do que o polling para monitorar objetos cujos estados ou valores
raramente so alterados. Um sistema de gerenciamento de redes geralmente faz uso dos dois
mtodos.
Para Rose (1994), com o polling, uma aplicao de gerncia periodicamente pergunta
ao n gerenciado sobre como esto as coisas. Isto fornece a vantagem de manter a aplicao
gerente no controle bem como determinar qual o quadro maior real. A desvantagem o
custo em relao ao tempo. Como a aplicao gerente saber quais elementos de rede deve
sondar e com que freqncia? Se o intervalo for muito curto, a largura de banda
desperdiada; se for muito longo, a resposta a eventos catastrficos muito lenta. Uma
segunda desvantagem que trfego adicional introduzido na rede. Correspondentemente, a
aplicao gerente deve possuir recursos de armazenamento adicionais para atender a este
aumento de trfego.
A estratgia, segundo Stallings (2001), a seguinte: na inicializao, e talvez em
intervalos incomuns, tais como uma vez ao dia, uma estao de gerenciamento pode sondar
(polling) todos os agentes que conhea para obter algumas informaes chave, tais como as
caractersticas da interface e talvez algumas informaes estatsticas bsicas. Uma vez
estabelecida esta linha-base, a estao de gerenciamento se abstm da sondagem. Agora, cada
agente responsvel por notificar a estao de gerenciamento sobre qualquer evento
incomum. Estes eventos assncronos so comunicados no SNMP atravs de mensagens
conhecidas como traps. Uma vez alertada sobre uma condio excepcional, a estao de
gerenciamento pode decidir tomar ou no alguma ao. Neste ponto, a estao de
gerenciamento pode sondar diretamente o agente que relatou a condio, para diagnosticar
qualquer problema e para obter mais informaes especficas sobre a condio excepcional. O
37
trap-directed polling pode resultar em ganhos substanciais de capacidade da rede e tempo de
processamento no agente.
Por isso o SNMP utiliza o trap-directed pooling. Quando um evento extraordinrio
ocorre, o n gerenciado envia um nico e simples trap para a aplicao gerente. A aplicao
gerente ento responsvel por iniciar futuras interaes com o n gerenciado para
determinar a natureza e extenso do problema. Esta abordagem surpreendentemente efetiva:
o impacto nos ns gerenciados permanece pequeno; o impacto na largura de banda da rede
minimizado; e, os problemas podem ser resolvidos rapidamente. claro, como os traps so
enviados usando um protocolo inseguro (UDP), eles servem apenas como um alerta
antecipado; baixas freqncias de polling so necessrias como back-up.
4.1.4
PROXY
Segundo Stallings (2001), o uso do SNMP requer que todos os agentes, bem como as
estaes de gerenciamento, suportem um conjunto de protocolos, tais como UDP e IP. Isto
limita diretamente o gerenciamento de tais dispositivos e exclui outros, como algumas pontes
e modens, que no suportam qualquer parte dos protocolos TCP/IP.
FIGURA 7 Configurao de proxy
C o nf ig u ra o d e p ro x y
A g en te p r ox y
E s t a o d e ge r en c i am en to
F u n o d e m ap ea m e n to
D i s po s iti v o
P r oc es s o g e re n c i ad o
P ro c e s s o g e re n te
P ro c e s s o ag en te
G er e n te S N M P
G e r en te S N M P
A rq u it e tu ra d e
p r o toc o l o u s a da
A r qu i te tu ra d e
p r oto c olo u s a d a
U DP
UDP
p e lo d i s p os iti v o
p r o xy
p e lo d is p o s it iv o
pr ox y
IP
IP
P ro to c ol o s d e p. d e r ed e
P ro t o c ol o s d e p . d e r e de
P r o to c o lo s d e p . d e r ed e
P r oto c o los dep . d e re d e
38
Alm disso, pode haver numerosos sistemas menores (PCs, controladores
programveis) que implementam o TCP/IP para suportar suas aplicaes, mas para os quais
no desejvel adicionar a estrutura adicional do SNMP, como a lgica do agente e a
manuteno da MIB. Para acomodar dispositivos que no implementam o SNMP, o conceito
de proxy foi criado (fig. 7).
Neste cenrio, um agente SNMP age como um proxy para um ou mais dispositivos, ou
seja, o agente SNMP age em nome dos dispositivos a ele relacionados.
Um agente proxy na estrutura do SNMP, segundo Lynch (1993), um agente que tem
os recursos e a autorizao para responder s pesquisas e comandos em nome de outro sistema
gerenciado.
Isto ocorre porque alguns sistemas no possuem suporte nativo ao protocolo SNMP,
mas com este mecanismo de proxy podem fazer parte da estrutura de gerenciamento SNMP.
4.1.5
COMPARATIVO ENTRE AS VERSES SNMP

O padro original da estrutura de gerenciamento SNMPv1, segundo o SNMP
International Research (2001), consiste de trs documentos:

a) RFC 1155: define a Estrutura de Gerenciamento de Informaes - SMI;
b) RFC 1212: define um mecanismo de descrio mais conciso, mas totalmente
consistente com o SMI;
c) RFC 1157: define o protocolo SNMP usado para o acesso via rede aos objetos
gerenciados.
Os dois primeiros documentos descrevem a linguagem de definio de dados do
SNMPv1. O terceiro documento descreve as operaes do protocolo SNMPv1 realizadas
pelas Protocol Data Units - PDUs em listas de ligao de varveis. As operaes definidas
pelo SNMPv1 so: get, get-next, get-response, set-request , e trap. O posicionamento do
SNMPv1 na camada de transporte usando um servio de transporte sem conexo tambm
definido. Muitos destes conceitos fazem parte da estrutura do SNMPv3.
A estrutura do SNMPv1 descreve o encapsulamento das PDUs SNMPv1 em
mensagens SNMP enviadas entre entidades SNMP, e diferencia entre entidades de aplicao e
39
entidades de protocolo. No SNMPv3, estas entidades so renomeadas como aplicaes e
motores, respectivamente.
A estrutura do SNMPv1 tambm introduz o conceito de um servio de autenticao
com suporte a um ou mais esquemas de autenticao. No SNMPv3, o conceito de um servio
de autenticao expandido para incluir outros servios, tais como privacidade.
Finalmente, a estrutura do SNMPv1 introduz o controle de acesso baseado em um
conceito
chamado
viso
de
MIB
SNMP.
SNMPv3
especifica
um
conceito
fundamentalmente similar chamado controle de acesso baseado em vises.

Entretanto, enquanto que a estrutura SNMPv1 antecipou a definio de mltiplos
esquemas de autenticao, esta no define nenhum esquema, seno um esquema trivial de
autenticao baseado em strings de comunidade. Esta uma das principais fraquezas da
estrutura SNMPv1. Entretanto, naquela poca, pensava -se que a definio de uma grade de
segurana comercial poderia no ser satisfatria no seu projeto e difcil de ser aprovada
porque segurana significa muitas coisas diferentes para pessoas diferentes. Devido a isso, e
porque alguns usurios no requeriam um forte servio de autenticao, o SNMPv1 estruturou
um servio de autenticao como um bloco separado, a ser definido mais tarde. O SNMPv3
fornece uma arquitetura para ser usada neste bloco, bem como uma definio para seus
subsistemas.
A estrutura de gerenciamento SNMPv2 completamente descrita da RFC 1902 at a
RFC 1907. A coexistncia e assuntos relacionados transio do SNMPv1 para o SNMPv2
so discutidas na RFC 1908.
O SNMPv2 fornece vrias vantagens sobre o SNMPv1:
a) tipos de dados expandidos: contadores de 64 bits;
b) melhorias de eficincia e desempenho: operador get-bulk;
c) confirmao de eventos de notificao: operador inform;
d) tratamento de erros mais elaborado: erros e excees;
e) melhorias nos conjuntos: especialmente na criao e excluso de colunas;
f) linguagem de definio de dados afinada.
40
Entretanto, a estrutura SNMPv2, conforme descrita nas RFCs de 1902 at 1907,
incompleta no sentido de que no atinge os objetivos originais de desenvolvimento do projeto
SNMPv2. Os objetivos no alcanados incluem a pr oviso de segurana e administrao,
tambm chamados de segurana de grau comercial com:
a) autenticao: identificao de origem, integridade das mensagens, e alguns
aspectos de proteo contra retransmisso e duplicao de mensagens:
b) privacidade: confidencialidade;
c) controle de acesso e autorizao; e
d) capacidades de administrao e configurao remota conveniente a estas
caractersticas.
J a estrutura de gerenciamento SNMPv3, como descrito nas RFCs de 2570 at 2575,
corrige as deficincias encontradas no SNMPv2 relacionadas segurana e administrao.
As RFCs SNMPv3 foram produzidas pelo SNMPv3 Working Group do Internet Engineering
Task Force (IETF). O SNMPv3 Working Group no reinventou a roda, mas reusou os
documentos padres do SNMPv2. Como resultado, o SNMPv3 o SNMPv2 com segurana e
administrao.
As novas caractersticas do SNMPv3 so:
a) segurana:
- autenticao e segurana;
- autorizao e controle de acesso;
b) estrutura administrativa:
- nomeao de entidades;
- pessoas e polticas de acesso;
- nomes de usurios e gerenciamento de chaves;
- notificaes de destinos;
- relacionamentos de proxy.
Estas novas caractersticas sero estudadas com mais detalhes no decorrer do trabalho.
41
4.1.6
CONSIDERAES FINAIS SOBRE O SNMP

A estrutura de gerenciamento SNMP, segundo Lynch (1993), tem obtido um
crescimento e sucesso fenomenal porque preenche os requisitos de gerenciamento de redes

atuais. O SNMP simples, com operaes de protocolo elegantes, um projeto de nomeao de
variveis, e provises para extenso da MIB, caractersticas pelas quais se tornou popular
entre vendedores de equipamentos de rede bem como entre os administradores de redes.
Foram eles, os administradores de rede, que tornaram o SNMP um padro de facto para
gerenciamento aberto atravs de foras de mercado, fazendo com que importantes
organizaes de padronizao abraassem o SNMP e as especificaes a ele referentes como
padres de jure. O crescimento do SNMP continua, ao ser aplicado em novas reas alm
daquelas as quais se destinava or iginalmente, como o gerenciamento de largas reas de trocas
de pacotes TCP/IP. O SNMP no serve apenas para gateways, mas utilizado tambm para
monitorar e controlar muitos tipos de sistemas de redes, de dispositivos da camada Message
Authentication Code - MAC a aplicaes de rede. O SNMP no usado apenas para redes,
mas est sendo usado tambm na administrao de sistemas e outras aplicaes no voltadas
ao gerenciamento de redes. O SNMP no mais usado apenas para redes TCP/IP, mas est
sendo aplicado a todos os tipos de tecnologia de redes, incluindo outras famlias de
protocolos, tais como DECnet e OSI, ou em casos onde no h um protocolo de interconexo
presente (incluindo UDP e IP), para suportar o gerenciamento de redes. A popularidade do
SNMP internacional.
Como resultado deste crescimento e sucesso inesperado, a estrutura de gerenciamento
SNMP, o chamado padro de curto-prazo para gerenciamento de redes aberto no mais de
curto-prazo, mas ir continuar a crescer e prosperar enquanto continuar atendendo s
necessidades de seus usurios constituintes.
O SNMP no perfeito. Entretanto, a habilidade de explorar mecanismos de
extensibilidade dentro da sua estrutura, tal como as provises para acomodar a definio de
novas variveis MIB e de melhorar as provises de segurana, iro ajudar a estrutura a
atender os requisitos dos administradores de redes. Estes mecanismos iro ajudar a garantir
que o SNMP continue a ocupar um lugar importante na arte e cincia do gerenciamento de
redes abertas nos anos que viro (Lynch, 1993).
42
5 SNMPV3
Provavelmente a caracterstica mais importante do SNMPv3 segundo Zeltserman
(1999), a segurana. O SNMPv3 atinge este objetivo ao oferecer autenticao forte e
criptografia de dados. O que a autenticao oferece :
a) que apenas grupos autenticados possam se comunicar. Isto garante que uma
estao gerenciadora possa coletar dados de um dispositivo ou configur-lo apenas
se o dispositivo permitir que aquela estao gerenciadora o acesse;
b) que as mensagens sejam recebidas em um tempo prtico (timely fashion). Isto evita
que as mensagens sejam salvas e/ou adulteradas e repassadas mais tarde de forma a
causar danos.
A privacidade s pode ser usada se a autenticao tambm for usada. Logo as escolhas
de segurana disponveis so: sem autenticao e sem segurana; apenas autenticao; com
autenticao e segurana.
H duas partes na gerncia SNMPv3. Uma a configurao das aplicaes SNMPv3,
especificamente fontes de notificaes e encaminhadoras de proxy :
a) configurar para quem enviar traps ou mensagens informativas;
b) configurar encaminhadores de proxy.
A outra parte definir vises MIB que possam ser acessadas por usurios diferentes.
Usando isto, se pode controlar que variveis da MIB determinado usurio pode acessar.
Notific aes, encaminhadores de proxy e controle de acesso s variveis MIBs podem ser
configurados remotamente atravs de um conjunto complexo de tabelas MIB.
A razo para a popularidade do SNMP e seu contnuo crescimento a sua
simplicidade. De fato, ele possui apenas quatro operaes duas para obter dados, uma para
modificar dados, e uma para um dispositivo enviar notificaes de forma assncrona. A
complexidade est realmente no gerenciamento dos dados que o SNMP acessa. Nem todos os
dados mantidos por um dispositivo so teis. Parte do que torna difcil a construo de
aplicaes de gerenciamento de redes teis entender que dados de gerenciamento usar e
como analis-los.
43
FIGURA 8 Entidade SNMPv3
E ntid ad e S N M P v 3
M ot or S N M P
D es pac h an t e
Subsistema de
S is te m a d e
Processamento
P r o c es s a m e n to
de mensagens
M e n s a g en s
S u b s is te m a d e
S e gu ra n a
S u b s i s te m a d e
C o n tr o le
A c es s o
A p l ic a e s
G e r ad or a d e c o m an d o s
R ec e p t o r a d e n ot i fic a e s
R e sp on d e d o r a d e c o m a n d o s
E n c a m in h a d o r a d e p r o x y
G e r a d o r a d e n o t ifi c a e s
O u tr a s
FONTE: Adaptado de Zeltserman (1999. pg. 98).
A maior misso, entretanto, no desenvolvimento do SNMPv3 foi a de criar uma

estrutura modular que pudesse ser facilmente extendida. Com isso se espera que no seja
necessria a criao de um SNMPv4 no futuro. Uma entidade SNMPv3 composta de duas
partes: um motor SNMP e aplicaes SNMP (fig. 8). O que era antes chamado de agentes e
gerentes SNMP agora se chamam entidades.
5.1 MOTOR SNMPV3

Cada entidade SNMP contm um motor SNMP. Colocando em termos mais simples,
um motor SNMP realiza o processamento de mensagens SNMP, com segurana e controle de
acesso. Como se v na figura 8, um motor SNMP constitudo dos seguintes componentes:
a) despachante;
b) subsistema de processamento de mensagens;
c) subsistema de segurana;
44
d) subsistema de controle de acesso.
5.1.1
DESPACHANTE
responsvel por enviar e receber mensagens. Quando uma mensagem recebida, o
despachante tenta determinar o nmero de verso da mensagem e ento passa a mensagem

para o sistema de processamento de mensagens ade quado. Se a mensagem no puder ser
processada e, assim o nmero de verso no puder ser determinado, ento o
snmpInASNParseErrs incrementado e a mensagem descartada. Se a verso no for
suportada
pelo
subsistema
de
processamento
de
mensagens
ento
contador
snmpInBadVersions incrementado e a mensagem descartada. O despachante tambm

responsvel por enviar PDUs para as aplicaes, e por selecionar o meio de transporte mais
adequado para enviar as mensagens;
5.1.2
SUBSISTEMA DE PROCESSAMENTO DE MENSAGENS

constitudo de um ou mais modelos de processamento de mensagens. A figura 9
mostra um subsistema de processamento de mensagens que suporta o SNMPv3, o SNMPv2, o

SNMPv1 e um modelo chamado Outros.
Este modelo permite que outros modelos possam ser acrescentados ao subsistema. O
subsistema de processamento de mensagens responsvel por:
a) preparar mensagens para serem enviadas;
FIGURA 9 Subsistema de processamento de mensagens
Su bs ist em a de Pr oc es sa m e nto d e M e ns ag ens
M od elo de
Pr oces sam e nt o
d e M en sag en s
S N MP v3
M od elo d e
P ro ce s sa m e nt o
d e M en sag en s
S N M P v2
M o de lo d e
P ro ce ss am en to
de M en sa g en s
S NM P v1

b)
extrair dados das mensagens recebidas.
O u t ro s
45
Exemplo: o despachante recebe uma mensagem SNMPv3 vlida. O despachante
determina a verso da mensagem e a repassa ao modelo de processamento de mensagens
SNMPv3. Este por sua vez processa a mensagem extraindo os dados da mesma e chama ento
o subsistema de segurana para descriptografar a poro de dados da mensagem (se
necessrio) e se assegura que a mensagem est devidamente autenticada. Neste ponto o
despachante ir encaminhar a PDU da mensagem para a aplicao SNMP apropriada.
5.1.3
SUBSISTEMA DE SEGURANA
O subsistema de segurana fornece servios de segurana tais como autenticao de
mensagens e criptografia/descriptografia de mensagens para obter privacidade.

FIGURA 10 Subsistema de segurana
S u bs ist e m a de S e gu ra n a
M o d el o d e
M o d e lo d e
O u t ro
S eg ura n a
S e g u ra n a
M o d e lo d e
B a s e ad o e m
B a se a d o e m
S e g u r an a
U s u rio
C o m u nid ad e
A figura 10 mostra um subsistema de segurana que suporta o modelo para o

SNMPv3, o modelo baseado em comunidade, e um modelo chamado Outro.
O modelo baseado em comunidade d suporte s verses SNMPv1 e SNMPv2c. Um
subsistema de segurana define entre outras coisas:
a) as ameaas de segurana para as quais fornece proteo;
b) os servios que fornece;
c) os protocolos de segurana utilizados para prover os servios utilizados, tais como
privacidade e autenticao.
O modelo de segurana baseado em usurio protege as mensagens SNMPv3 das
seguintes ameaas:
a) um usurio autorizado que envie uma mensagem que seja alterada em trnsito por
uma entidade SNMP no autorizada;
46
b) um usurio no autorizado tentando se mascarar como um usurio autorizado;
c) modificaes no fluxo das mensagens;
d) espionagem.
O modelo de segurana baseado em usurio atualmente define o uso do Hashing for
Message Authentication Code Message Digest 5 96 bits (HMAC -MD5-96) e Hashing for
Message Authentication Code Secure Hash Function 96 bits (HMAC-SHA-96) como os
protocolos de autenticao e o Chain Block Cipher Data Encryption Standard (CBC-DES)
como o protocolo de privacidade. Os modelos de segurana das verses SNMPv1 e SNMPv2c
oferecem apenas uma autenticao fraca (nomes de comunidade) e nenhuma privacidade.
5.1.4
SUBSISTEMA DE CONTROLE DE ACESSO

responsvel por determinar se o acesso a um objeto gerenciado deve ou no ser
permitido (fig. 11).

Atualmente h um modelo de controle de acesso definido: o View-based Access
Control Model (VACM). Com o VACM possvel controlar quais usurios e quais operaes
podem ter acesso aos objetos gerenciados.
Qualquer aplicao SNMP que precise acessar os objetos gerenciados podem chamar
o VACM. Atualmente, seriam as aplicaes processadoras de comandos e as geradoras de
notificaes. Tambm neste caso possvel definir novos modelos de controle de acesso para
serem adicionadas ao subsistema de controle de acesso.
FIGURA 11 Subsistema de controle de acesso
S u bs ist e m a de C o nt r ole d e Ac es s o
M o d el o d e
C on tr o le d e
O u tr o M o d e l o d e
O u tr o M o d e lo d e
A c es s o
C o n t r ol e d e
C o nt role d e
B a s e ad o e m
S e g u ra n a
S e gu ran a
V is o
47
Stallings (2001) define que uma entidade SNMPv3 pode ser de dois tipos: uma
entidade SNMPv3 gerente tradicional (fig. 12) ou uma entidade SNMPv3 agente tradicional
(fig. 13).
5.1.5
GERENTE SNMP TRADICIONAL

Na terminologia SNMPv3 tradicional, um gerente SNMP inclui trs categorias de
aplicaes (fig. 12). As aplicaes geradoras de comandos monitoram e manip ulam dados
gerenciveis em agentes remotos; elas fazem uso das PDUs SNMPv1 e SNMPv2, incluindo
Get, GetNext, GetBulk , e Set. Uma aplicao geradora de notificaes inicia mensagens
assncronas; no caso de um gerente tradicional, a PDU InformRequest usada por esta
aplicao. Uma aplicao receptora de notificaes processa as mensagens assncronas que
chegam ao gerente; estas incluem as PDUs InformRequest , SNMPv2-Trap e SNMPv1-Trap.
No caso de uma PDU InformRequest chegar ao gerente, a aplicao receptora de notificaes
ir responder com uma PDU Response. Todas estas aplicaes fazem uso dos servios
fornecidos pelo motor desta entidade. O motor SNMP realiza duas funes principais:
a) ele aceita PDUs vindas das aplicaes SNMP, realiza o processamento necessrio,
incluindo a insero de cdigos de autenticao e criptografia, e ento encapsula as
PDUs em mensagens para transmisso;
b) ele aceita mensagens que chegam da camada de transporte, realiza o
processamento necessrio, incluindo autenticao e descriptografia, e ento extrai
as PDUs das mensagens e as passa para a aplicao SNMP apropriada.
Em um gerente SNMP tradicional, o motor SNMP contm um despachante, um
subsistema de processamento de mensagens e um subsistema de segurana. O despachante
simplesmente um gerente de trfego. Para as PDUs de sada, o despachante aceita PDUs
vindas das aplicaes e realiza as seguintes funes: para cada PDU, o despachante determina
o tipo de processamento de mensagem requerido (SNMPv1, SNMPv2, SNMPv3) e passa a
PDU no mdulo de processamento de mensagens adequado no subsistema de processamento
de mensagens. Depois disso, o subsistema de processamento de mensagens retorna a
mensagem contendo a PDU incluindo os cabealhos apropriados da mensagem. O
despachante passa ento esta PDU para a aplicao apropriada.
48
FIGURA 12 Gerente SNMPv3 tradicional
A pl ic a es S N M P
A p lic a e s
g er a do ra s d e
A p lic a es
g e r a d o ra s d e
A p li c a e s
re c e p t o r a s d e
c o m a n d os
n o t i fic a e s
n o t i f ic a e s
S ub s is t em a
p r oc es sa m en t o
d e m e ns a g en s
De sp a c ha nt e
v1
d es pa c h an t e de P D U s
v2 c
S ub si s te m a
d e se gu ra n a
M o d elo d e
s eg ur a n a
b a s e ad o e m
u s u ri o
d es p a c h an t e d e m e n s ag en s
m a p e a m e n to d e t r a n s p o r t e
v3
O ut r o
m o d e lo d e
o ut r o
s eg ur a n a
M o to r S N M P v 3
U DP
IP X
O u tr o
R e de
O subsistema de processamento de mensagens aceita as PDUs de sada vindas das

aplicaes via despachante e as prepara para transmisso, envolvendo-as no cabealho
apropriado da mensagem e retornado-as ao despachante. O subsistema de processamento de
mensagens tambm aceita mensagens que chegam entidade e ao serem repassadas pe lo
despachante, processa cada cabealho destas mensagens, e retorna a PDU anexada ao
despachante para que ele possa encaminha-la aplicao adequada.
O subsistema de segurana realiza funes de autenticao e criptografia. Cada
mensagem a ser enviada passada ao subsistema de segurana pelo subsistema de
processamento de mensagens. Dependendo dos servios requisitados, o subsistema de
segurana pode criptografar a PDU em anexo, e/ou gerar um cdigo de autenticao para ser
49
inserido no cabealho da mensagem. A mensagem ento retornada ao subsistema de
processamento de mensagens. Similarmente, cada mensagem recebida pela entidade gerente
passada ao subsistema de segurana pelo subsistema de processamento de mensagens. Se
requisitado, o subsistema de segurana verifica o cdigo de autenticao e realiza a
descriptografia da PDU. Aps estas operaes a mensagem processada retornada ao
subsistema de processamento de mensagens.
5.1.6
AGENTE SNMP TRADICIONAL

Um agente tradicional (fig. 13) deve conter trs tipos de aplicaes: processadoras de
comandos; geradoras de notificaes e encaminhadoras de proxy.

A aplicao processadora de comandos prov acesso aos dados gerenciados.
FIGURA 13 Agente SNMPv3 convencional
U DP
IP X
O u tr o
M ot or SN M Pv 3
Sub sist em a
pr oce ss a m e nt o
de m ens age ns
m a p ea m e n t o d e t ra n s p o r te
M od elo de
s e guran a
b a s e ad o e m
u s u ri o
v1
De spac hante
Subs is te m a
de s e gur a na
v2 c
d e s p a c h a n te d e m e n s a g e n s
d e sp ac h a n t e d e P D U s
A p lic a e s
e n c a m i n h a d o r as
de prox y
A p li c a es
r es p o n d ed o r a s
d e c o m an d os
In st r u m e n t a o M IB
v3
O ut ro
m o delo d e
o u t ro
s e guran a
A p l ic a e s
ge rador as d e
n ot i fic a e s
S ubsi ste m a con tr ol e de ace sso

M o d e lo d e
c o n tr o l e d e
a c es s o b as e a d o
e m v is o
O u tr o
m o d e lo d e
c on tr o le
d e ac es s o
Apl ic a e s SN M P
50
Estas aplicaes respondem as requisies que chegam atravs da obteno e/ou
configurao de objetos gerenciados e emitem ento uma PDU Response.
Uma aplicao geradora de notificaes inicia mensage ns assncronas; no caso de um
agente tradicional, a PDU SNMPv2-Trap, a PDU SNMPv1- Trap ou a PDU Inform usada
por esta aplicao. Uma aplicao encaminhadora de proxy encaminha mensagens entre
entidades.
Um motor SNMP de um agente tradicional possui todos os componentes encontrados
no motor SNMP de um gerente tradicional, mais um subsistema de controle de acesso. Este
subsistema fornece servios de autenticao para controlar o acesso s variveis MIBs para a
leitura e configurao de objetos gerenciados. Estes servios so realizados com base no
contedo das PDUs.
Note que as funes relacionadas segurana esto organizadas em dois subsistemas
separados: segurana e controle de acesso. O subsistema de segurana se preocupa com a
privacidade e a autenticao, e age sobre mensagens SNMP. O subsistema de controle de
acesso se preocupa com o acesso autorizado as informaes gerenciadas, e age sobre as PDUs
SNMPv2c.
5.2 APLICAES SNMP

No caso do SNMPv3, quando se faz referncia s aplicaes, est se fazendo
referncia s aplicaes que possuem uma entidade SNMP, como por exemplo, uma aplicao
de gerncia de redes. Atualmente existem cinco tipos de aplicaes definidas:
a) geradoras de comandos: geram comandos SNMP para coletar ou configurar dados
gerenciados;
b) processadoras de comandos: fornecem acesso aos dados gerenciados;
c) geradoras de notificaes: geram Traps ou mensagens Inform;
d) receptoras de notificaes: recebem e processam Traps ou mensagens Inform;
e) encaminhadoras de proxy: encaminham mensagens entre entidades SNMP.
A partir desta lista, pode -se ver que as aplicaes receptoras de notificaes e as
geradoras de comandos so o que se chamava de gerente SNMP, enquanto que as
51
processadoras de comandos e geradoras de notificao so o que se chamava de agente
SNMP.
5.3 PROCESSAMENTO DE MENSAGENS SNMPV3

A seguir ser demonstrado como realizado o processamento das mensagens pelas
entidades SNMPv3.
5.3.1
FORMATO DAS MENSAGENS SNMPV3

Segundo Stallings (2001), cada mensagem inclui um cabealho e uma PDU. A
estrutura da mensagem ilustrada na figura 14; os campos escuros so aqueles criados e

processados pelo subsistema de processamento de mensagens.
FIGURA 14 Formato da mensagem SNMPv3
m s g V e r s io n
m s g ID
m s g M a x S iz e
m s g F la g s
m s g G l o b a lD a ta =
d ad o s d e ca b e a lh o
m s g S e c u r it y P a r am e t e rs
D e f i n id o e u s a d o p e l o
m o d e lo d e s e g u r a n a
c o n t ex t E n g i n e ID
co n t e xt N a m e
Es copo da c riptogr afia
E sc opo da autenticao
m s g S ec u r i ty M o d e l
m s g D at a = S c op ed PD U
PD U S N M P v 2
( t e xt o p l an o o u
c ript og raf ad o )
A mensagem SNMPv3 inclui os seguintes campos:
52
a) msgVersion: serve para informar sobre a verso SNMP utilizada na composio da
mensagem;
b) msgID: um identificador nico usado entre duas entidades SNMP para coordenar
mensagens de requisio e resposta, e pelo processador de mensagens para
coordenar o processamento da mensagem por diferentes modelos de subsistemas
existentes na arquitetura das entidades;
c) msgMaxSize: contm o tamanho mximo suportado pela mensagem em octetos.
Este o tamanho mximo de segmento que o remetente pode aceitar de outro motor
SNMP;
d) msgFlags: um octeto contendo trs flags nos trs ltimos bits significativos:
reportableFlag , privFlag, authFlag. Se reportableFlag =1 ento uma Report PDU
deve ser retornada ao remetente sob as condies que podem causar a gerao de
uma Report PDU; quando reportableFlag =0, uma Report PDU no deve ser
retornada. A flag reportableFlag configurada para 1 pelo remetente em todas as
mensagens contendo um request (Get, Set) ou um Inform, e configurado para 0 para
mensagens contendo uma Response PDU, uma Trap PDU, ou uma Report PDU. O
flag reportableFlag uma ajuda secundria na determinao de quando enviar uma
Report PDU. usado somente nos casos em que a poro PDU da mensagem no
pode ser dec odificada (por exemplo, quando a descriptografia falha, devido a uma
chave incorreta). As flags privFlag e authFlag so configuradas pelo remetente
para indicar o nvel de segurana que foi aplicado mensagem. Para privFlag=1,
criptografia foi aplicada e para authFlag=1, autenticao foi aplicada. Todas as
combinaes so permitidas exceto privFlag=1 e authFlag=0; ou seja, no
permitido criptografia sem autenticao;
e) msgSecurityModel: um identificador que indica qual modelo de segurana foi
usado pelo remetente para preparar a mensagem, e portanto, qual modelo de
segurana deve ser usado pelo destinatrio para processar a mensagem. Os valores
reservados incluem: 1 para SNMPv1, 2 para SNMPv2c, e 3 para o USM.
f) msgSecurityParameters: um octeto que contm parmetros gerados pelo
subsistema de segurana na entidade SNMP que enviou a mensagem e processado
pelo subsistema de segurana na entidade receptora. O contedo deste campo no
53
interpretado pelo subsistema de processamento de mensagens nem pelo
despachante.
g) contextEngineID: um octeto que identifica unicamente uma entidade SNMP. Para
as mensagens que chegam, este campo determina para qual aplicao a scopedPDU
ser encaminhada para processamento. Para as mensagens que sero enviadas, este
valor fornecido pela aplicao ao emiter uma requisio para enviar uma
mensagem;
h) contextName : um octeto que identifica unicamente um contexto em particular com
o escopo do motor de contexto associado;
i) PDU SNMPv2: uma PDU. O modelo de processamento de mensagem SNMPv3
especifica que esta deve ser uma PDU SNMPv2.
A figura 14 mostra como estes campos esto organizados. Os campos msgID,
msgMaxSize, msgFlags, e msgSecurityModel so referenciados na definio ASN.1 pelo
nome de msgGlobalData. Este bloco contm parmetros necessrios pelo subsistema de
processamento de mensagens para coordenar o tratamento e processamento da mensagem. J
os campos contextEngineID, contextName , e PDU SNMPv2 so referenciados pelo nome
msgData e possui um tipo scopedPduData. Uma PDU de escopo uma PDU que contm
informaes nomeadas em um contexto em que so unicamente identificadas pelo
contextEngineID e pelo contextName . Este bloco contm informaes necessrias pela
aplicao para processar a PDU.
5.4 ALGORITMOS
SNMPV3
CRIPTOGRFICOS
USADOS
PELO
A seguir sero apresentados alguns conceitos bsicos de criptografia e um breve

estudo dos algoritmos criptogrficos utilizados pelo SNMPv3 para prover a autenticao e a
privacidade das mensagens trocadas entre as entidades SNMPv3.
5.4.1
CONCEITOS BSICOS DE CRIPTOGRAFIA

Criptografia, do grego krypts (escondido, oculto) + grpho (grafia, escrita), a arte
ou a cincia de escrever em cifra ou em cdigo; em outras palavras, um conjunto de tcnicas

que permitem tornar incompreensvel uma mensagem originalmente escrita com clareza, de
54
forma a permitir que apenas o destinatrio a decifre e a compreenda. Quase sempre o
deciframento requer o uso de uma chave (Luchesi, 1986).
A criptoanlise, do grego krypts + anlysis (decomposio) a arte ou cincia de
determinar a chave ou decifrar mensagens sem conhecer a chave (Luchesi, 1986).
A criptologia, do grego krypts + logos (estudo, cincia), a cincia que rene a
criptografia e a criptoanlise (Luchesi, 1986).
Stallings (2001) cita que uma estrutura criptogrfica padro possui cinco elementos
(fig. 15):
a) texto simples: esta a mensagem legvel ou os dados que so fornecidos como
entrada para o algoritmo criptogrfico;
b) algoritmo de criptografia: um algoritmo que realiza vrias substituies e
transformaes no texto simples;
c) chave secreta: a chave secreta tambm uma entrada para o algoritmo. As
substituies e transformaes exatas realizadas pelo algoritmo dependem da chave
secreta;
FIGURA 15 Criptografia convencional
C h a ve s e c r e t a
C h a v e s e cr e ta
c o m p a r t ilh ad a
c o m p a r ti lh a d a
p e lo r e m e t e n te e
p e l o r e m e te n t e e
r ec e p t o r
r e c e p to r
t ex to
c r i p t o g ra f a d o
t r a n s m i tid o
e n t ra d a d e
te x to s i m p l e s
a lg o r it m o d e
c r ip to g r a f i a
a lg or itm o d e
d e s cr ip to g r a fi a
s a d a d e
t e xto s im p l e s
d) texto cifrado: esta a mensagem misturada produzida como sada do algoritmo.

Esta depende da chave secreta e do texto simples. Para uma mensagem dada, duas
chaves diferentes iro gerar dois textos cifrados diferentes;
55
e) algoritmo de descriptografia: essencialmente o algoritmo de criptografia
executado de forma reversa. Ele recebe o texto cifrado e a mesma chave secreta e a
partir destes, produz o texto simples original.
Basicamente, segundo Luchesi (1986), a criptografia computacional usada para
permitir:
a) sigilo de informaes: permite que somente os usurios autorizados tenham acesso
informao, ou consigam torn -la inteligvel;
b)
integridade de informaes: garantia oferecida ao usurio de que a informao

correta, original, no foi alterada, nem intencionalmente nem acidentalmente;
c)
autenticao de usurio: processo que permite ao sistema verificar se a pessoa ou

processo com quem est se comunicando de fato a pessoa ou processo que ale ga
ser;
d)
autenticao de remetentes: processo que permite a um usurio certificar-se que a

mensagem recebida foi de fato enviada pelo remetente, podendo inclusive provar,
perante um juiz, que o remetente enviou determinada mensagem;
e)
autenticao de destinatrios: consiste em se ter uma prova de que a mensagem

enviada foi como tal, recebida pelo destinatrio;
f)
autenticao de atualidade: consiste em provas de que a mensagem atual, no se

tratando de mensagens antigas reenviadas.
5.4.2
DATA ENCRYPTION STANDARD (DES)

Segundo Stallings (2001), a estrutura de criptografia mais utilizada atualmente, a
baseada no DES, adotada em 1977 pelo National Bureau of Standards, agora o National
Institute of Standards and Tecnology (NIST).
O DES cifra blocos de 64 bits em blo cos de 64 bits, usando uma chave de 56 bits (64
bits dos quais oito bits so de paridade). Assim, para cifrar, escolhe -se uma chave e divide-se
a mensagem em blocos de 64 bits, cifrando cada bloco separadamente.
Por usar a mesma chave tanto para a criptografia quanto para a descriptografia, sendo
necessrio manter esta chave em segredo (apenas o remetente e o destinatrio devem conhecla), o DES dito um algoritmo simtrico de chave secreta (Luchesi, 1986).
56
O SNMPv3, segundo Stallings (2001), define uma verso melhorada do DES original
chamada de Cipher Block Chaining Mode Data Encryption Standard (CBC-DES). Isto
porque o DES processa apenas blocos de dados de 64 bits por vez. Para grandes quantidades
de texto, necessrio quebrar o texto em blocos maiores que 64 bits. A maneira mais simples
de proceder utilizar o modo electronic codebook (ECB), no qual o texto simples tratado 64
bits de cada vez e cada bloco de texto simples criptografado usando a mesma chave. O
termo codebook usado porque, para uma dada chave, h um nico texto cifrado para cada
bloco de 64 bits de texto simples. Com o ECB, se o mesmo bloco de 64 bits de texto simples
aparecer mais de uma vez na mensagem, ele sempre produzir a mesma sada. Para resolver
este problema preciso usar um mecanismo que gere blocos de textos cifrados diferentes,
mesmo usando o mesmo bloco de texto simples. Uma forma simples de fazer isso usar o
modo CBC. Neste esquema, a entrada do algoritmo de criptografia o Xtended OR - XOR do
bloco de texto simples atual e do bloco de texto cifrado anterior; sendo que a mesma chave
usada para cada bloco. Como efeito, encadeia -se juntamente o processo da seqncia de
blocos de texto simples. A entrada para a funo de criptografia para cada bloco de texto
simples no possui nenhuma relao com o bloco de texto simples. Portanto, a repetio de
padres de 64 bits no exposta. Para obter maiores informaes sobre o DES consulte
Menezes (1997) e Schneier (2001).
5.4.3
MESSAGE DIGEST 5 (MD5)

Stallings (2001) cita que um elemento essencial nas estruturas de autenticao e
assinaturas digitais uma funo hash segura. Uma funo hash aceita uma mensagem de
tamanho varivel como entrada e produz um cdigo hash de tamanho fixo, chamado s vezes
de sumrio da mensagem (message digest), como sada. H duas funes hash especificadas
para uso com o SNMPv3: a MD5 e a SHA-1.
O algoritmo de sumrio de mensagem (message digest ) - MD5, descrito na RFC 1321
foi desenvolvido por Ron Rivest no MIT. At recentemente, o MD5 era o algoritmo hash
seguro mais usado.
Este algoritmo pega uma mensagem de tamanho arbitrrio como entrada e produz
como sada um sumrio de mensagem de 128 bits. A entrada processada em blocos de 512
bits.
57
O algoritmo MD5 tem a propriedade de que cada bit do cdigo hash uma funo de
cada bit da entrada. O autor do MD5 conjectura que a dificuldade de se gerar duas mensagens
com o mesmo sumrio da ordem de 264 operaes, e a dificuldade de gerar uma mensagem
que produza um dado sumrio da ordem de 2128 operaes. Para obter maiores informaes
sobre o algoritmo MD5 consulte Menezes (1997) e Schneier (2001).
5.4.4
SECURE HASH FUNCTION (SHA-1)

O algoritmo SHA foi desenvolvido pelo NIST e publicado como o padro de
processamento de informaes federais a ser usado pelo norte-americano em 1993. Uma

reviso foi feita em 1995 e foi chamada de SHA-1.
O algoritmo SHA -1 possui como entrada uma mensagem com um tamanho mximo
menor que 264 bits, e produz como sada um sumrio de mensagem de 160 bits. A entrada
processada em blocos de 512 bits. Para obter mais informaes sobre o algoritmo SHA-1
consulte Menezes (1997) e Schneier (2001).
5.4.5
AUTENTICAO DE MENSAGENS COM O HMAC

Segundo Stallings (2001), a autenticao de mensagens um procedimento que
permite a grupos que se comuniquem verificar se as mensagens recebidas so autnticas. H

dois aspectos importantes que so: verificar se o contedo da mensagem no foi alterado e se
a origem da mensagem autntica. O MAC uma tcnica amplamente usada para realizar a
autenticao das mensagens, e um algoritmo surgiu como o padro Internet para uma grande
variedade de aplicaes: HMAC.
Um algoritmo MAC envolve o uso de uma chave secreta para gerar um pequeno bloco
de dados, conhecido como um cdigo de autenticao da mensagem, que acrescentado
mensagem. Esta tcnica assume que dois elementos se comunicando, digamos Alice e Bob,
compartilham a chave secreta comum K. Se Alice quiser enviar uma mensagem para Bob, ela
calcula o cdigo de autenticao da mensagem como uma funo da mensagem e da chave. A
mensagem mais o cdigo transmitida para Bob. Bob ento realiza o mesmo clculo na
mensagem recebida, usando a mesma chave secreta, para gerar um novo cdigo de
58
autenticao para a mensagem. O cdigo recebido comparado com o cdigo calculado. Se o
cdigo recebido igual ao cdigo calculado, ento:
a) o receptor tem certeza de que a mensagem no foi alterada;
b) o receptor tem certeza que a mensagem mesmo do remetente especificado;
c) se a mensagem incluir um nmero de seqncia, ento o receptor tem certeza que a
seqncia das mensagens apropriada, porque seria improvvel para um atacante
alterar com sucesso o nmero seqencial.
Um grande nmero de algoritmos pode ser usado para gerar o cdigo, mas a
alternativa mais eficiente e popular o HMAC.
O HMAC descrito na RFC 2104, e foi escolhido como a implementao MAC
mandatria (mandatory-to-implement MAC) para a segurana no IP, e usado em outros
protocolos Internet, tais como o Secure Socket Layer (SSL) e Secure Electronic Transaction
(SET).
A maior vantagem do HMAC tratar a funo hash como uma caixa preta. Isto
possui dois benefcios. Primeiro, uma implementao j existente de uma funo hash pode
ser usada como um mdulo na implementao do HMAC. Segundo, se for desejvel troc ar
uma funo hash especfica de implementao do HMAC por outra, tudo o que necessrio
remover o mdulo com a funo existente e colocar em seu lugar o novo mdulo. Com isso,
se a segurana da funo hash for comprometida, a segurana do HMAC pode ser obtida
novamente simplesmente substituindo a funo hash comprometida por uma nova funo
mais segura (por exemplo, substituir o MD5 pelo SHA-1).
5.5 USER-BASED SECURITY MODEL USM

Segundo Stallings (2001), a RFC 2274 define o modelo de segurana baseado no
usurio (USM) para o SNMPv3. Esta especificao inclui:
a) autenticao: prov integridade de dados e autenticao da origem dos dados. O
cdigo de autenticao de mensagens HMAC, que usa atualmente as funes hash
MD5 ou SHA-1, fornece esta autenticao;
b) sincronizao ( timeliness ): protege contra demoras ou duplicao de mensagens;
59
c) privacidade: protege contra revelao do contedo da mensagem. O modo de
ciframento encadeado de blocos (CBC) do DES usado para a criptografia da
mensagem;
d) formato da mensagem: define o formato do campo msgSecurityParameters, que
suporta as funes de autenticao, tempo e privacidade.
e) descoberta: define procedimentos pelos quais um motor SNMP obtm informaes
sobre outro motor SNMP;
f) gerenciamento de chaves: define procedimentos para a gerao de chaves, sua
atualizao e uso.
5.5.1
PARMETROS DE SEGURANA USM

A RFC 2274 define uma estrutura, UsmSecurityParameters, que especifica o formato
interno do campo msgSecurityParameters de uma mensagem SNMPv3. A figura 16 mostra o

formato de uma mensagem SNMPv3 j com o uso do USM. Os campos escuros indicam os
campos que so criados e processados pelo USM.
Antes de examinar os campos do msgSecurityParameters, preciso definir o conceito
de um motor SNMP autorizado. Em qualquer mensagem transmitida, uma das duas entidades
envolvidas (emissor ou receptor) designada como um motor SNMP autorizado, de acordo
com as seguintes regras:
a) quando uma mensagem SNMP contm uma carga que exige uma resposta (por
exemplo, uma PDU Get, GetNext, GetBulk, Set ou Inform), ento o receptor de tal
mensagem autorizado;
b) quando uma mensagem SNMP contm uma carga que no exige uma resposta (por
exemplo, um Trap-SNMPv2, ou uma PDU Response ou Report), ento o emissor
de tal mensagem autorizado.
Esta designao serve a dois propsitos:
a) O tempo da mensagem determinado atravs de um relgio mantido pelo motor
autorizado. Quando um motor autorizado envia uma mensagem (Trap, Response,
Report), esta contm o valor corrente do relgio deste motor, desta forma o motor
no autorizado pode se sincronizar com este relgio. Quando um motor no
autorizado envia uma mensagem (Get, GetNext, GetBulk , Set, Inform), este inclui o
60
valor de seu tempo corrente, estimado com base no relgio de destino, permitindo
ao destino avaliar o tempo da mensagem.;
b) um processo de localizao de chave, descrito mais adiante, habilita um nico
diretor (usurio) a possuir as chaves armazenadas em mltiplos motores; estas
chaves so localizadas pelo motor autorizado de tal forma que o diretor
responsvel por uma nica chave, evitando o risco de segurana de armazenar
mltiplas cpias da mesma chave em uma rede distribuda.
Faz sentido designar o receptor das mensagens geradas pelo gerador de comandos e
PDUs Inform como um motor autorizado pelo fato deste ser o possuidor do relgio autorizado
em uma troca. Se uma resposta ou trap est atrasada ou duplicada, poucos danos podem
ocorrer. Entretanto, geradores de comandos e, de certa forma, PDUs Inform resultam em
operaes de gerenciamento, tais como leitura ou configurao de objetos MIB. Por isso,
importante garantir que tais PDUs no estejam atrasadas ou duplicadas, o que poderia causar
efeitos indesejados.
Quando uma mensagem a ser enviada passada ao USM pelo processador de
mensagens, o USM preenche o campo msgSecurityParameters. Quando uma mensagem
recebida passada ao USM pelo processador de mensagens, o USM processa os valores
contidos no msgSecurityParameters repassando em seguida a mensagem novamente ao
processador de mensagens. Os campos do msgSe curityParameters so:
a) msgAuthoritativeEngineID: o snmpEngineID do motor SNMP autorizado
envolvido na troca da mensagem;
b) msgAuthoritativeEngineBoots : o valor snmpEngineBoots do motor SNMP
autorizado envolvido na troca da mensagem. O objeto snmpEngineBoots um
inteiro que representa o nmero de vezes que este motor SNMP inicializou ou
reinicializou a si mesmo desde sua configurao inicial;
c) msgAuthoritativeEngineTime:
valor
snmpEngineTime do
motor
SNMP
autorizado envolvido na troca da mensagem. O objeto snmpEngineTime um

inteiro que representa o nmero de segundos desde que este motor SNMP
autorizado incrementou pela ltima vez o objeto snmpEngineBoots. Cada motor
SNMP
autorizado
responsvel
por
incrementar
seu
prprio
valor
snmpEngineTime a cada segundo. Um motor SNMP no autorizado responsvel
61
por incrementar sua noo de snmpEngineTime para cada motor autorizado
remoto com o qual se comunica;
FIGURA 16 Formato da mensagem SNMPv3 com USM
m s g V e r s io n
m s g ID
m s g M a x S iz e
m s g F la g s
m s g G l o b a lD a ta =
d a d o s d e ca b e a lh o
m s g S ec u r i ty M o d e l
m s g A u th or i ta t i ve E n g in eI D
Escopo da autenticao
m s g A u t h o r ita t iv e E n g in e B o o ts
m s g A u t h o r ita ti v e E n g in e T i m e
m s g S e c u r it y P a r a m e te r s
m s gU s e rN a m e
m s g A u th en ti c at i o n P a r a m et e r s
m s g P r i v a c yP a r a m e t e r s
c o n t ex t E n g i n e ID
Es copo da cr iptogr afia
co n t e xt N a m e
m s g D a ta = S c o p e d P D U
PD U S N M P v 2
( te x t o p la n o o u
c ri p t og ra f ad o)
d) msgUserName: o diretor (usurio) em favor do qual a mensagem est sendo

trocada;
e) msgAuthenticationParameters : nulo se a autenticao no for usada na
comunicao agente/gerente. Caso contrrio este um parmetro de autenticao.
Pela definio atual do USM, o parmetro de autenticao um cdigo de
autenticao de mensagem HMAC;
f) msgPrivacyParameters: nulo se no usado privacidade na comunicao
agente/gerente. Caso contrrio este um parmetro de segurana. Pela definio
62
atual do USM, o parmetro de privacidade um valor usado para formar o valor
inicial no algoritmo CBC-DES (privPassword e SnmpEngineID);
O conjunto de mecanismos de sincronizao do USM inclui:
a) gerenciamento de relgios autorizados: cada motor SNMP que possa vir a agir
como um motor autorizado (geralmente um agente), deve manter dois objetos,
snmpEngineBoots e snmpEngineTime, que se referem ao seu tempo local. Com isso
todos os motores que possam receber PDUs Inform devem manter estes dois
objetos;
b) sincronizao: um motor SNMP que opere de modo no autorizado deve
permanecer permanentemente sincronizado com cada motor SNMP autorizado com
o qual este se comunica. Para este fim, o motor no autorizado mantm uma cpia
local
de
trs
variveis
(snmpEngineBoots,
snmpEngineTime,
latestReceivedEngineTime) para cada motor SNMP autorizado que conhecido por

este motor no autorizado (geralmente um gerente);
c) checagem de tempo por um motor autorizado: o SNMPv3 dita que uma mensagem
deve ser recebida em uma janela de tempo razovel, para evitar demora e ataques
de duplicao. O tempo da janela deve ser escolhido para ser o mais pequeno
possvel dada a preciso do relgio envolvido, os atrasos de comunicao do
round-trip, e a freqncia com que os relgios so sincronizados. O teste atual
para determinar este tempo depende se o receptor da mensagem autorizado ou
no;
d) checagem de tempo por um motor no autorizado: para cada mensagem de entrada
a ser autenticada cujo msgAuthoritativeEngineID no for igual ao valor do
snmpEngineID
para
este
msgAuthoritativeEngineBoots
motor,
e
motor
compara
msgAuthoritativeEngineTime
os
da
valores
do
mensagem
recebida com os valores do snmpEngineBoots e snmpEngineTime que este motor

mantm, referente ao motor SNMP remoto correspondente.
Segundo Stallings (2001), cada entidade SNMP mantm uma MIB, a usmUser, que
informa sobre os usurios (diretores) locais e remotos. Este grupo consiste de um objeto
escalar, usmUserSpinLock , e uma tabela usmUserTable. O objeto usmUserSpinLock habilita
aplicaes geradoras de comandos a coordenar o uso de suas fbricas para troca de chaves
63
usando a usmUserTable e para garantir a atomicidade quando da realizao de operaes
nesta tabela a fim de evitar inconsistncias nos dados da mesma.
5.5.2
FUNES CRIPTOGRFICAS USADAS PELO USM

Segundo Stallings (2001), h duas funes criptogrficas definidas para o USM:
autenticao e criptografia. Para suportar estas funes, um motor SNMP requer dois valores:
uma chave privada (privKey ) e uma chave de autenticao (authKey). Valores separados
destas duas chaves so mantidas pelos seguintes usurios:
a) usurios locais: qualquer diretor neste motor SNMP para o qual so autorizadas
operaes de gerenciamento;
b) usurios remotos: qualquer diretor em um motor SNMP remoto com o qual a
comunicao desejada.
Estes valores so atributos de usurio armazenados para cada diretor (usurio)
relevante. Os valores da privKey e authKey no so acessveis via SNMP.
Para a autenticao o USM permite o uso de um dos seguintes protocolos de
autenticao: HMAC -MD5-96 ou HMAC-SHA-96. Para o HMAC-MD5-96, o cdigo de
autenticao de mensagem HMAC usado, com o MD5 atuando como a funo hash. Uma
authKey de 128 bits usada como entrada para o algoritmo HMAC. O algoritmo produz uma
sada de 128 bits, que truncada para 96 bits. Este valor o cdigo de autenticao da
mensagem que ser inserido no campo msgAuthenticationParameters da mensagem
SNMPv3. Para o HMAC-SHA-96, a funo hash usada a SHA-1. A authKey possui 160 bits
de tamanho. O algoritmo produz uma sada de 160 bits que truncada para 96 bits.
Para a criptografia e descriptografia o USM usa o modo CBC do DES. Uma privKey
de 128 bits fornecida como entrada ao protocolo de criptografia. Os primeiros 64 bits desta
privKey so usados como uma chave DES. Como o DES requer apenas uma chave de 56 bits,
o ltimo bit significativo de cada octeto ignorado. Para o modo CBC (64 bits restantes), um
vetor de inicializao (VI) de 64 bits requerido. Este vetor produzido da seguinte maneira:
a) os oito ltimos octetos da privKey so usados como um pr-VI;
b) para garantir que dois VIs so usados para duas entradas de textos planos diferentes
criptografados com a mesma chave, um valor-sal (salt-value) de oito octetos
64
gerado. O valor-sal igual concatenao do valor corrente da snmpEngineBoots
existente neste motor (que possui um tamanho de quatro octetos) e um inteiro de 32
bits mantido pelo algoritmo de criptografia local. Este inteiro de 32 bits
dependente de implementao e deve ser modificado depois de cada uso do mesmo;
c) o valor-sal sofre uma operao XOR bit a bit com o pr-VI para produzir o VI.
O valor-sal colocado no campo msgPrivacyParameters da mensagem SNMPv3 para
permitir que a entidade receptora possa computar o VI corretamente. Este esquema faz o
seguinte: como o valor -sal muda toda vez que usado, um VI diferente usado para
diferentes textos planos. E como apenas o valor-sal transmitido via SNMP, um atacante no
pode determinar o VI.
5.5.3
PROCESSAMENTO DE MENSAGENS USM

A figura 17 mostra em termos gerais, os procedimentos seguidos pelo USM para o
processamento de mensagens recebidas e enviadas. A seguir ser mostrado como feito este
processamento ignorando-se alguns erros bsicos que podem interromper o processo, tais
como um campo msgSecurityParameters invlido. O USM realiza os seguintes passos ao
receber um generateRequestmsg (primitiva gerada pelo subsistema de processamento de
mensagens) tratado por uma aplicao geradora de comandos:
a) o USM determina se h uma entrada na usmUserTable para o destino
securityEngineID e a fonte securityName. Se no houver, uma indicao de erro
retornada;
b) o USM determina se o securityModel requisitado suportado por este usurio e, se
no for, retorna uma indicao de erro;
c) se o securityLevel requisitar privacidade, ento o valor scopedPdu criptografado
usando o CBC-DES e a chave privada de criptografia localizada na privKey deste
usurio. O texto cifrado gerado armazenado no campo scopedPdu, e o valor-sal
derivado do valor da privKey armazenado no campo msgPrivacyParameters da
mensagem SNMPv3. Se a privacidade no for requisitada, ento o campo
msgPrivacyParameters configurado para NULL;
d) o parmetro snmpEngineID armazenado no campo msgAuthoritativeEngineID;
e) o parme tro securityName armazenado no campo msgUserName ;
65
FIGURA 17 Processamento de mensagens USM: transmisso
O b t er
inf orm a e s do
u s u r io
r e q u e r id o
S IM
p ri v a c id a d e ?
E nc ript ar s c op e dP d u
s e t m s g P r i va c y P a r a m e t e r s
NO
m s g P r iv ac y P a r a m e te r s
n u ll S tr in g
r e q u e r id o
S IM
a u te n t i c a o ?
c om p u ta r M A C
se t m sg A u th e n t i c a ti o n P a r a m e t e rs
N O
m s g A u t h e n tic a t io n P a r a m e te r s
n u ll S tr in g
T r an sm it ir m en s a g e m
f) se o securityLevel requisitar autenticao, o valor corrente do snmpEngineBoots e

snmpEngineTime correspondentes ao parmetro snmpEngineID so armazenados
nos
campos
msgAuthoritativeEngineTime,
respectivamente. Ento o cdigo de autenticao da mensagem calculado sobre

toda a mensagem, usando o HMAC e a chave de autenticao localizada na
authKey deste usurio armazenada no msgAuthenticationParameters. Se o
securityLevel no requisitar autenticao, um valor zero armazenado nos campos
msgAuthoritativeTime
campo
msgAuthenticationParameters configurado para NULL;

g) a mensagem completa com seu tamanho retornada ao mdulo de processamento
de mensagens que fez a requisio.
66
Algum tempo aps a transmisso da mensagem de requisio por uma entidade
SNMP, uma mensagem de resposta deve ser recebida. Esta mensagem tratada pelo
despachante e pelo processador de mensagens. O processador de mensagens invoca o USM
com a primitiva processIncomingMessage. Este processamento (fig. 18) inclui os seguintes
passos:
a) os
valores
dos
parmetros
de
segurana
so
extrados
do
campo
securityParameters;
b) se o valor do msgAuthoritativeEngineID no securityParameters for desconhecido,
e este motor SNMP capaz de realizar descobertas, ele pode opcionalmente criar
uma nova entrada na sua MIB usmUserGroup. Caso contrrio, uma indicao de
erro retornada;
c) o USM determina se h uma entrada na usmUserTable para o securityEngineID
remoto autorizado e o securityName local. Se no houver, uma indicao de erro
retorna da;
d) o USM determina se o securityLevel requisitado suportado para este usurio e, se
no for, uma indicao de erro retornada;
e) se o securityLevel especificar que a mensagem para ser autenticada, ento a
mensagem autenticada, usando o HMAC e a chave privada de autenticao
localizada na authKey deste usurio, atravs do clculo do cdigo de autenticao
da mensagem para esta mensagem e comparando o resultado com o do campo
msgAuthenticationParameters na mensagem. Se os resultados no combinarem, o
USM pra o processamento e retorna uma indicao de erro. Se o resultado
conferir, a mensagem declarada autntica e o processamento continua;
f) o USM realiza a sincronizao;
g) o USM realiza a checagem do tempo. Se a mensagem no estiver na janela de
tempo, o USM pra o processamento e retorna uma indicao de erro. Se a
mensagem estiver dentro da janela de tempo o processamento continua;
h) se o securityLevel indicar que foi usada criptografia, ento a scopedPdu
descriptografada usando o CBC-DES e a chave priv ada de criptografia localizada
na privKey deste usurio;
i) a scopedPdu retornada ao mdulo de processamento de mensagens que fez a
requisio.
67
Muitos dos passos citados anteriormente so os mesmos utilizados por uma aplicao
processadora de comandos, mas h algumas diferenas importantes. A seguir so exibidos os
passos
realizados
pelo
USM
quando
este
invocado
com
uma
primitiva
processIncomingMessage vinda do subsistema de processamento de mensagens.

FIGURA 18 - Processamento de mensagens USM: recepo
O b te r o s
p a r m e t ro s d a
m e ns a ge m
Us a
S IM
au te n ti c a o ?
C o m p u t ar M A C ; c o m p a ra r c o m
m s g A u th e n ti c a ti o n P ar a m et e r s
N O
D e t erm ina r s e a m en s ag em
e s t d e n t r o d a j a n e l a d e t em p o
Us a
S IM
p r iv a c id a d e ?
D e s c r ip t o g ra f a r s c op e d P d u
NO
R e c e b e r m en sa g e m
Esse processamento feito enquanto o processador de mensagens est tratando uma

mensagem Request que acaba de chegar. Os passos so os seguintes:
a) os valores dos parmetros de segurana so extrados do securityParameters. Um
bloco cachedSecurityData preparado para servir de cache para as seguintes
informaes:
-
MsgUserName;
SecurityEngineID;
SecurityLevel.
68
b) se o valor do msgAuthoritativeEngineID no securityParameters for desconhecido,
uma indicao de erro retornada;
c) o USM determina se h uma entrada no usmSecurityTable para o securityEngineID
local autorizado e o securityName remoto. Se no houver, uma indicao de erro
retornada;
d) o USM determina se o securityLevel requisitado suportado para este usurio, e se
e) se o securityLevel especifica que esta mensagem deve ser autenticada, ento a
mensagem autenticada usando o HMAC e a chave privada de autenticao
localizada na authKey deste usurio, atravs do clculo do cdigo de autenticao
da mensagem e comparando o resultado obtido ao resultado do campo
msgAuthenticationParameters da mensagem. Se eles no combinarem, o USM pra
o processamento e uma indicao de erro retornada. Se eles combinarem, a
mensagem declarada autntica e o processamento continua;
f) o USM realiza a checagem do tempo. Se a mensagem no estiver no tempo da
janela, o USM pra o processamento e retorna uma indicao de erro. Se a
mensagem estiver dentro da janela de tempo o processamento continua;
g) se o securityLevel indicar que a criptografia foi utilizada, ento a scopedPdu
descriptografada usando o CBC-DES e a chave privada de criptografia localizada
na privKey deste usurio;
h) as seguintes informaes so adicionadas ao bloco cachedSecurityData preparados
no passo a:
-
usmUserAuthProtocol;
usmUserAuthKey;
usmUserPrivProtocol;
usmUserPrivKey;
i) uma referncia ou ponteiro para este bloco em cache colocado na sada do

parmetro securityStateReference;
j) a scopedPdu retornada ao mdulo de processamento de mensagens que realizou a
requisio.
Aps o retorno do USM para o processador de mensagens, o processador de
mensagens subseqentemente retorna a PDU recuperada para a aplicao processadora de
69
comandos. Enquanto isso, o processador de mensagens armazena em cache o valor do
securityStateReference que recebido em retorno do USM, como parte do conjunto dos
parmetros do processador de comandos que este possui no cache. Subseqentemente a isso, o
processador de comandos pode preparar uma PDU Response e invocar ento o processador de
mensagens com uma primitiva prepareResponseMsg. O processador de mensagens ir ento
invocar o USM com a primitiva generateResponseMsg, que possui os mesmos parmetros de
entrada e sada do generateRequestMsg com uma exceo: generateResponseMsg inclui o
securityStateReference como um parmetro de entrada. O processador de mensagens obtm
este valor do seu cache e passa o valor do securityStateReference para a requisio Request
recebida que combine com o Response da sada.
O USM realiza os seguintes passos aps o recebimento de uma generateResponseMsg:
a) usando o valor recebido de securityStateReference , o USM obtm as informaes
do usurio armazenando-as na cache. Estas informaes provm da mensagem
Request processada anteriormente;
b) o USM determina se o securityLevel requisitado suportado para este usurio, e se
c) se o securityLevel requisitar privacidade ento o valor da scopedPdu
criptografado usando o CBC-DES e a chave privada de criptografia localizada na
privKey deste usurio.O texto cifrado resultante armazenado no campo
scopedPdu , e o valor-sal derivado do valor da privKey armazenado no campo
msgPrivacyParameters da mensagem SNMPv3. Se no for requisitado privacidade,
ento o campo mspPrivacyParameters configurado para NULL;
d) o parmetro snmpEngineID armazenado no campo msgAuthoritativeEngineID da
mensagem SNMPv3;
e) o parmetro securityName armazenado no campo msgUserName ;
f) os valores correntes de snmpEngineBoots e do snmpEngineTime para este motor
local autorizado so armazenados nos campos msgAuthoritativeEngineBoots e
msgAuthoritativeEngineTime, respectivamente. Se o securityLevel requisitar
autenticao, o cdigo de autenticao da mensagem calculado sobre toda a
mensagem usando o HMAC e a chave privada de autenticao localizada na
authKey deste usurio, atravs do clculo do cdigo de autenticao da mensagem
70
para
esta
mensagem
comparando
resultado
com
do
campo
msgAuthenticationParameters na mensagem;
g) a mensagem completa com seu tamanho retornada ao mdulo de processamento
de mensagens que solicitou a requisio.
O passo (f) mostra a diferena entre um motor autorizado e um no autorizado. No
caso de um motor no autorizado, os valores dos campos msgAuthoritativeEngineBoots e
msgAuthoritativeEngineTime do cabealho da mensagem so configurados somente se a
mensagem deve ser autenticada por um receptor autorizado. Esta restrio faz sentido porque
o receptor autorizado ir checar estes campos apenas se a mensagem deve ser autenticada.
Entretanto, para uma mensagem Response vinda de um motor autorizado, os valores
msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime presentes no cabealho da
mensagem so sempre configurados. No caso de um remetente autorizado, estes valores
representam os valores locais oficiais do snmpEngineBoots e snmpEngineTime. Quando
uma mensagem Response recebida por um motor no autorizado, este deve usar estes
valores apenas para a sincronizao da mensagem se a mensagem for autenticada.
5.5.4
DESCOBERTA
O USM requer o uso do processo de descoberta para obter informaes suficientes
sobre outros motores SNMP para poder se comunicar com eles. Em particular, um motor
SNMP no autor izado deve aprender o valor snmpEngineID de um motor autorizado antes
que a comunicao seja realizada. Este processo realizado em duas etapas.
Primeiro, o motor no autorizado envia uma mensagem Request ao motor autorizado
ao qual deseja descobrir com um securityLevel requisitado de noAuthnoPriv. A mensagem
inclui um campo msgUserName com o valor initial e um msgAuthoritativeEngineID nulo.
A PDU Request anexada possui uma varBindList vazia. O motor autorizado ir responder
com
uma
mensagem
Report
contendo
seu
snmpEngineID
no
campo
msgAuthoritativeEngineID;
Segundo, se uma comunicao autenticada requisitada, o motor no autorizado
precisa estabelecer uma sincronizao de tempo com o motor autorizado. Para fazer isso, o
motor no autorizado envia uma mensagem Request
autenticada com o campo
71
msgAuthoritativeEngineID configurado com o valor do snmpEngineID remoto recentemente
aprendido
com
os
valores
dos
campos
msgAuthoritativeEngineTime configurados com um valor de zero. A resposta a esta

mensagem autenticada ser uma mensagem Report do motor autorizado com seus valores
correntes
de
snmpEngineBoots
snmpEngineTime
presentes
nos
campos
msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime. A partir deste momento o

motor no autorizado j pode se comunicar (se permitido) usando autenticao (e criptografia
se necessrio) com o motor autorizado.
5.6 GERENCIAMENTO DE CHAVES

Segundo Stallings (2001), um dos requisitos para o uso dos servios de autenticao e
privacidade no SNMPv3 que, para qualquer comunicao entre um diretor em um motor no
autorizado e um motor autorizado remoto, uma chave secreta de autenticao e uma chave
secreta de privacidade devem ser compartilhadas.
Estas chaves permitem a um usurio de um motor n o autorizado (tipicamente um
sistema de gerenciamento) utilizar autenticao e privacidade com sistemas remotos
autorizados que o usurio gerencia (tipicamente, um sistema agente). A RFC 2274 fornece um
guia para a criao, atualizao, e gerenciamento de chaves.
Para simplificar o gerenciamento de chaves centrado nos diretores, cada diretor
requisitado a manter apenas uma nica chave para autenticao e uma nica chave para
privacidade. Estas chaves no so armazenadas em uma MIB e no so acessveis via SNMP.
5.6.1
ALGORITMO DE TRANSFORMAO DE SENHA PARA

CHAVE
A RFC 2274 define um algoritmo para mapeamento de uma senha comum para uma
chave de 128 ou 160 bits. Resumidamente a gerao das chaves feita da seguinte maneira:
a) pega-se a senha do usurio como entrada e se produz uma string de 1.048.576
octetos atravs da repetio da senha tantas vezes o quanto for necessrio,
truncando o ltimo valor se necessrio, para formar uma string digest0;
b) se for desejado criar uma chave de 128 bits, pega -se o hash MD5 do digest0 para
formar digest1. A sada a chave do usurio.
72
Uma das vantagens deste algoritmo que ele reduz bastante a possibilidade de um
ataque de dicionrio ou fora bruta e decouples nas chaves do usurio de qualquer NMS
em particular. Nenhum NMS necessrio para armazenar as chaves do usurio. Ao invs
disso, uma chave de usurio gerada quando necessrio a partir da senha do usurio.
Uma nica senha pode ser usada para gerar uma nica chave usada tanto para
autenticao quanto para privacidade. Entretanto seria mais seguro usar duas senhas, uma
para
gerar
uma
chave
de
autenticao
outra
para
gerar
uma
chave
de
privacidade/criptografia.
5.6.2
LOCALIZAO DE CHAVES
Uma chave localizada definida na RFC 2274 como uma chave secreta compartilhada
entre um usurio e uma entidade SNMP autorizada. O objetivo que assim o usurio precisa
manter apenas uma nica chave (ou duas se usar autenticao e privacidade) e, portanto
lembrar de apenas uma senha (ou duas). O processo pelo qual uma nica chave do usurio
convertida em mltiplas chaves nicas, uma para cada motor SNMP remoto, chamado de
localizao de chave. Dentre os principais objetivos para o gerenciamento de chaves podemos
citar:
a) cada sistema agente SNMP em uma rede distribuda possui sua prpria chave nica
para cada usurio autorizado a gerenci -lo. Se mltiplos usurios esto autorizados
como gerentes, o agente possui uma nica chave de autenticao e uma nica chave
de criptografia para cada usurio. Por isso, se a chave de um usurio
comprometida, as chaves dos outros usurios no o so;
b) as chaves de um usurio so diferentes para agentes diferentes. Nesse caso, se um
agente comprometido, apenas as chaves de usurio para aquele agente so
comprometidas e no as chaves de usurio em uso para os outros agentes.
c) o gerenciamento de rede pode ser realizado de qualquer ponto da rede,
independente da disponibilidade de um sistema de gerenciamento de rede (NMS).
Isto permite a um usurio realizar funes de gerenciamento a partir de qualquer
estao gerenciada. Esta capacidade fornecida pelo algoritmo de senha para
chave.
possvel definir tambm alguns procedimentos a serem evitados:
73
a) um usurio precisa lembrar um grande nmero de chaves, nmero este que cresce
com a adio de novos agentes;
b) um adversrio que obtenha a chave de um agente capaz de personificar qualquer
outro agente para qualquer usurio, ou qualquer usurio para qualquer outro agente.
Para atender aos objetivos e consideraes anteriores, uma nica chave de usurio
mapeada pelo uso de uma funo de mo nica irreversvel em diferentes chaves localizadas,
para motores autenticados diferentes.
FIGURA 19 Localizao de chaves
P e g u e o h as h d a
C h a v e l oc a liz ad a
c h a v e d o u s u ri o
e d o E n g in e ID r e m o to
S en h a d o u s u r io
P egue o hash da
C h a v e loc a li z ad a
s e n h a e x p a n d id a
C h a v e l o c ali z a d a
O procedimento o seguinte:
a) formar uma string digest2 pela concatenao de digest1, o valor snmpEngineID do
motor autorizado (agente) e digest1;
b) se uma chave de 128 bits for desejada, pega -se o hash MD5 do digest2. Se uma
chave de 160 bits for desejada, pega-se o hash SHA-1 do digest2. A sada a chave
do usurio.
A chave localizada resultante pode ento ser configurada no sistema agente de forma segura.
Devido natureza do MD5 e do SHA-1, improvvel que um adversrio possa aprender uma
chave de usurio, mesmo que o adversrio venha a descobrir a chave localizada. A figura 19
resume bem esse processo.
74
5.6.3
ATUALIZAO DE CHAVES
O SNMPv3 assume que h algum meio seguro de entregar chaves localizadas para
sistemas autenticados (agentes). Esta entrega segura est fora do escopo do SNMPv3; ela
deve ser manual ou por outro protocolo seguro. Uma vez que uma chave inicial (ou par de
chaves, no caso de autenticao e privacidade) tenha sido entregue a um agente, o SNMPv3
fornece um mecanismo para atualizar estas chaves de forma segura. Um usurio pode iniciar o
processo de troca de chave atravs da requisio e fornecimento de uma nova senha.
Alternativamente, o NMS pode iniciar o processo atravs da requisio de uma nova senha.
Em ambos os casos a chave existente no NMS atualizada. O NMS pode ento calcular uma
chave localizada para cada agente com o qual se comunica. O NMS deve ento se comunicar
com segurana com cada agente para que ele atualize sua chave localizada. Obviamente, o
NMS no pode simplesmente enviar a chave em texto plano atravs da rede. H duas
possibilidades:
a) criptografar a nova chave usando a chave antiga como a chave de criptografia;
b) usar algum tipo de funo de mo nica para produzir um valor a partir da chave
antiga. Deve -se ento realizar um XOR deste valor com a nova chave e enviar o
resultado ao agente. O agente pode ento aplicar um XOR sobre a mensagem
recebida usando a chave antiga para obter a nova chave.
A desvantagem da criptografia a necessidade de usar criptografia mesmo em
sistemas que suportam apenas autenticao de mensagens. Outra desvantagem da criptografia
as restries feitas sobre a criptografia em vrios pases. Por isso o mtodo adotado pelo
SNMPv3 uma variao do segundo mtodo (XOR).
O mtodo utilizado pelo SNMPv3 envolve o uso de objetos KeyChange localizados no
usmUserGroup. Um diretor remoto ou um NMS configura este objeto, que ento
automaticamente usado pelo agente para atualizar a chave correspondente. O algoritmo leva
em considerao que um tamanho varivel de chave pode ser usado por um algoritmo de
autenticao ou criptografia em particular, o que complica o algoritmo de atualizao de
chaves.
O SNMPv3 permite que ambos, um administrador da rede ou um usurio possam
atualizar uma chave de usurio em particular. Um administrador de rede pode configurar as
75
chaves iniciais para um usurio e pode requerer que o usurio troque as senhas de tempos em
tempos, e cuidar da atualizao de chaves quando isso acontecer. Alm disso, o usurio pode
trocar sua senha e chave(s) a qualquer momento. Para acomodar estes dois requisitos, o grupo
usmUSer contm dois objetos de troca de chaves para cada uma das chaves. Para a chave de
autenticao o usmAuthKeyChange deve ser configurado pelo administrador da rede para que
a chave seja atualizada. O sistema agente configurado de forma que apenas o administrador
da rede tenha acesso a este objeto, permitido pelo subsistema de controle de acesso. O objeto
usmUserOwnAuthKeyChange no protegido por controle de acesso mas definido de forma
a permitir a atualizao apenas se o requisitante possui o mesmo userName como objeto
usmUserName
para
esta
usmUserOwnPrivKeyChange
linha.
provem
Similarmente,
capacidade
o
de
usmUserPrivKeyChange
atualizao
para
uma
chave
criptografada para o administrador da rede e outra para o usurio, respectivamente.
5.7 VIEW-BASED ACCESS CONTROL MODEL - VACM

Segundo Stallings (2001), o modelo de controle de acesso baseado em viso (VACM)
definido na RFC 2275, possui duas caractersticas importantes:
a) o VACM determina se o acesso a um objeto gerenciado em uma MIB local por um
diretor remoto deve ser permitido;
b) o VACM faz uso de uma MIB que define a poltica de controle de acesso para este
agente, e torna possvel o uso da configurao remota.
A RFC 2275 define cinco elementos que fazem parte do VACM:
a) grupos: um grupo definido como um conjunto de zero ou mais tuplas
<securityModel, securityName > nas quais os objetos de gerenciamento SNMP
podem ser acessados. Um securityName se refere a um diretor, e direitos de acesso
para todos os diretores em um dado grupo so idnticos. Um nico groupName
associado com cada grupo. O conceito de grupo uma ferramenta til para
categorizar os gerentes de acordo com seus direitos de acesso. Por exemplo, todos
os gerentes de topo podem possuir um conjunto de direitos de acesso, enquanto que
gerentes de nvel intermedirio podem ter um conjunto totalmente diferente de
direitos de acesso. Qualquer combinao de securityModel e securityName pode
pertencer no mximo a um grupo, ou seja, para um agente qualquer, um diretor
76
cujas comunicaes so protegidas por um securityModel dado, pode somente ser
includo em um grupo;
b) nvel de segurana: os direitos de acesso para um grupo podem ser diferentes
dependendo do nvel de segurana da mensagem que contm a requisio. Por
exemplo, um agente pode permitir acesso somente de leitura para uma requisio
feita por uma mensagem no autenticada, mas, pode requisitar autenticao para
acesso de escrita;
c) contextos: um contexto MIB um subconjunto nomeado de instncias de objetos
na MIB local. Os contextos fornecem uma forma til de agregar objetos em
colees com diferentes polticas de acesso. O contexto um conceito que se
relaciona ao controle de acesso. Quando uma estao de gerenciamento interage
com um agente para acessar informaes de gerenciamento naquele agente, a
iterao entre o diretor de gerenciamento e o motor do agente SNMP, e os
privilgios de controle de acesso so expressos em uma viso MIB que se aplica ao
diretor e seu contexto. Os contextos possuem as seguintes caractersticas chave:
-
uma entidade SNMP, unicamente identificada por um contextEngineID, pode

manter mais de um contexto;
um objeto ou uma instncia de objeto pode aparecer em mais de um contexto;
quando mltiplos contextos existem, para identificar uma instncia de objeto

individual, seu contextName e contextEngineID deve ser identificado em relao
ao seu tipo de objeto e sua instncia.
d) vises MIB: seria interessante restringir o acesso de um grupo particular a um

subconjunto de objetos gerenciados em um agente. Para atingir este objetivo, o
acesso a um contexto feito atravs de uma viso MIB, que define um conjunto
especfico de objetos gerenciados. O VACM faz uso de uma tcnica poderosa e
flexvel para definir vises MIB, baseadas no conceito de vises de subrvores e
vises de famlias. A viso MIB definida como uma coleo, ou famlia de
subrvores, com cada subrvore sendo includa ou excluda da viso. O SNMPv3
inclui o conceito de subrvore. Uma subrvore na da mais do que um n na
hierarquia de nomeao da MIB mais todos os seus elementos subordinados. Mais
formalmente uma subrvore pode ser definida como um conjunto de todos os
objetos e instncias de objetos que tenham um prefixo OBJECT IDENTI FIER
77
ASN.1 comum em seus nomes. Associados a cada entrada na vacmAccessTable
esto trs vises MIB, uma para leitura, uma para escrita e outra para notificao de
acesso. Cada viso MIB consiste em um conjunto de vises de subrvores. Cada
viso de subrvore na viso MIB, especificada como sendo includa ou excluda.
Isto significa que, a viso MIB ou inclui, ou exclui todas as instncias de objetos
contidas na subrvore. Em acrscimo, uma mscara de viso definida para reduzir
a quantidade de informao de configurao requerida quando um controle de
acesso mais refinado requerido.
e) poltica de acesso: o VACM permite que um motor SNMP seja configurado para
reforar um conjunto particular de direitos de acesso. A determinao do acesso ou
negao do mesmo depende dos seguintes fatores:
-
o diretor fazendo a requisio de acesso. O VACM torna possvel para um

agente permitir diferentes privilgios de acesso para diferentes usurios. Os
diretores esto associados a grupos e a poltica de acesso especificada em
relao a estes grupos;
o nvel de segurana pelo qual a requisio foi comunicada na mensagem

SNMP. Tipicamente, um agente ir requerer o uso de autenticao para
mensagens contendo uma requisio set (operao de escrita);
o modelo de segurana usado para processar a mensagem requisitada. Se

mltiplos modelos de segurana esto implantados em um agente, o agente pode
ser configurado para fornecer diferentes nveis de acesso, para requisies
comunicadas via mensagens processadas por modelos de segurana diferentes;
o contexto da MIB usado para a requisio;
a instncia do objeto especfica para o qual acesso requerido. Alguns objetos

mantm mais informaes crticas ou sensitivas que outros, e, portanto a poltica
de acesso deve depender na instncia de objeto especifica requisitada;
o tipo de acesso requisitado (leitura, escrita, notificao). A leitura, escrita e

notificao so operaes de gerenciamento distintas, e diferentes polticas de
controle de acesso podem ser aplicadas para cada uma destas operaes.
O servio fornecido pelo subsistema de controle de acesso definido pela primitiva

isAccessAllowed. A definio desta primitiva especifica que os parmetros de entrada so
securityModel, securityName , securityLevel, viewType, contextName , e variableName.
78
FIGURA 20 Lgica VACM
Q UE M
O N DE
CO MO
c o n te x tN a m e
s e c u ri ty M o d e l
s e c u ri ty M o d e l
P OR QU E
O QU E
Q U AL
s e c u ri ty L e v e l
s e c u r ity N am e
tip o- do o b j e to i n s t nc ia d o ob je to
v a c m C o n te x tT a b l e
v ie w T y p e
v a c m S e c u r ity T o G r ou p T ab le
gr oup N am e
v ar ia b l eN a m e ( O ID )
v a c m A c c es s T a b le
v ie w N am e
v ac m V ie w T r e e F a m ily T ab le
D e c is o S im /N o
Todos estes parmetros so necessrios para realizar a deciso sobre o controle de

acesso. Colocando de outra maneira, o subsistema de controle de acesso definido de forma a
prover uma ferramenta muito flexvel para configurar o controle de acesso no agente, atravs
da diviso dos componentes de controle de acesso em seis variveis separadas.
A figura 20 adaptada da figura existente na RFC 2275, prov uma forma til de
analisar as variveis de entrada, e mostra como as vrias tabelas na MIB VACM so usadas
para realizar a deciso sobre o controle de acesso:
a) quem: a combinao do securityModel e do securityName define o quem da
operao; identifica um dado diretor cujas comunicaes so protegidas por um
certo securityModel. Esta combinao pode pertencer a mais de um grupo neste
motor SNMP. O vacmSecurityToGroupTable prov o groupName, dados o
securityModel e o securityName;
b) onde: o contextName especifica onde o objeto gerenciado desejado pode ser
encontrado. O vacmContextTable contm uma lista dos contextName reconhecidos;
79
c) como: a combinao do securityModel e do securityLevel define como a PDU
Inform ou request foi protegida. A combinao de quem, onde, e como identificam
entradas de zero ou um na vacmAccessTable ;
d) por qu: o viewType especifica porque o acesso requisitado: para uma operao
de leitura, escrita ou notificao. A entrada selecionada na vacmAccessTable
contm uma MIB viewName para cada um destes trs tipos de operaes, e o
viewType usado para selecionar um viewName especfico. Este viewName
seleciona a viso MIB apropriada do vacmViewTreeFamilyTable ;
e) o que: a variableName um identificador de objeto cujo prefixo identifica um tipo
de objeto especfico e cujo sufixo identifica uma instncia de objeto especfica. O
tipo de objeto indica qual tipo de informao de gerenciamento requisitada;
f) qual: a instncia de objeto indica qual item especfico de informao requisitado.
Finalmente, a variableName comparada com a viso MIB obtida. Se a variableName
combina com um elemento includo na viso MIB, ento o acesso e fornecido.
Agora possvel sumarizar os procedimentos usados pelo VACM para determinar se o
acesso permitido. Quando isAccessAllowed invocada por uma aplicao, o VACM realiza
os seguintes passos (fig. 21):
a) o VACM checa se h uma entrada no vacmContextTable para o contextName. Se
houver, ento este contexto conhecido por este motor SNMP. Se no houver ento
um errorIndication de noSuchContext retornado;
b) o VACM checa o vacmSecurityToGroupTable para determinar se h um grupo
associado a este par <secutityModel, securityName >. Se houver, ento este diretor
operando sob este securityModel um membro de um grupo configurado neste
motor SNMP. Se no houver, ento um errorIndication de noGroupName
retornado;
c) o VACM consulta em seguida o vacmAccessTable
usando groupName,
contextName , securityModel, e securityLevel como ndices. Se uma entrada for

encontrada, ento uma poltica de controle de acesso foi definida para este
groupName, operando sob este securityModel, neste securityLevel, para acessar este
contextName. Se no for encontrada uma entrada, ento um errorIndication de
noAccessEntry retornado;
80
FIGURA 21 Fluxograma VACM
C o n t e xt o e s t d is p o n ve l ?
N O
n o S u c h C o n t e xt
( v a c m C o n t ex t T a b l e)
S IM
G ru p o e s t d i s p o n v e l ?
N O
( va c m S e c u r it y G r o u p T a b l e )
no G rou pN am e
S IM
E n t rad a de ac es s o en c o nt rad a?
N O
n o A c c e ss E n t ry
( v a c m A cc e s s T a b l e )
S IM
C h e c a r t ip o d e v is o
n o S u c h V ie w
notific a o
gr avao
leitura
( v a c m A cc e s s T a b l e )
C h e c a r v is o
( va c m V i e w T r e e F a m i ly T a b l e )
C h e c a r a va ri v e l
( v a c m V i e w T r e e F a m i ly Ta b le )
n o S u ch V i e w
n o In V i e w
a c c e s s A l lo w ed
d) o VACM determina ento se a entrada vacmAccessTable selecionada inclui uma

referncia a uma viso MIB de viewType. Se houver uma referncia, ento esta
entrada contm um viewName para esta combinao de groupName , contextName ,
securityModel, securityLevel, e viewType. Se no houver uma referncia, ento um
errorIndication de noSuchView retornado;
81
e) o viewName usado como um ndice na vacmViewTreeFamilyTable . Se uma viso
MIB for encontrada, ento uma viso MIB foi configurada para este viewName.
Caso contrrio, um errorIndication de noSuchView retornado;
f) o VACM verifica a variableName contra a viso MIB selecionada. Se esta varivel
est includa na viso, ento uma statusInformation de accessAllowed retornada;
g) se esta varivel no estiver includa na viso, ento um errorIndication de
noInView retornado.
5.7.1
A MIB VACM
A MIB VACM (fig. 22) contm informaes nas seguintes categorias:
a) informaes sobre contextos locais: a vacmContextTable lista os contextos
localmente disponveis por nome; esta informao usada por aplicaes geradoras
de comandos para configurar a vacmAccessTable para controlar o acesso a todos os
contextos na entidade SNMP. A vacmContextTable em si possui acesso de apenas
leitura e no pode ser configurada por uma operao SNMP. Cada entrada na tabela
um nome human-readable que identifica um contexto em uma entidade SNMP
em
particular.
Um
contexto
vazio,
representa
contexto
padro.
vacmContextTable independente da vacmAccessTable. A qualquer momento pode

haver um contexto listado na vacmContextTable para o qual no h entradas na
vacmAccessTable que referenciem este contexto, e pode haver entradas na
vacmAccessTable que referenciem um contexto que ainda no exista no momento e
que portanto no possua uma entrada atualmente na vacmContextTable ;
b) informaes sobre grupos: esta vacmSecurityToGroupTable prov um groupName
dado um securityModel e um securityName. O groupName usado para definir
uma poltica de controle de acesso para um grupo de diretores sob um dado modelo
de segurana. A tabela indexada por vacmSecurityModel e vacmSecurityName, e
o valor de vacmGroupName usado como um ndice na vacmAccessTable ;
c) informaes sobre direitos de acesso: a vacmAccessTable pode ser configurada
para definir direitos de acesso para grupos. Para um dado grupo, os direitos de
acesso podem ser definidos para um ou mais contextos, um ou mais modelos de
segurana, e um ou mais nveis de segurana. Por isso, pode haver mltiplas
82
entradas na vacmAccessTable para um groupName em particular. Para deixar mais
claro:
-
um contexto se refere a um subconjunto de instncias de objetos na MIB local.

Para um grupo em particular, direitos de acesso podem ser definidos em mais de
um contexto;
se um agente suporta mais de um modelo de segurana, ento os direitos de

acesso para um grupo podem ser definidos separadamente em respeito a cada
modelo de segurana. Em um dado modelo de segurana, os direitos de acesso de
grupo podem ser enumerados para mltiplos contextos;
os direitos de acesso de um grupo para um contexto em particular sob um

modelo de segurana em particular podem depender no nvel de segurana da
troca. Por isso, um grupo pode ter maior direito de acesso para um contexto em
particular sob um modelo de segurana em particular se a autenticao utilizada
e comparada, do que quando a autenticao no utilizada.
Alm do mais, para um dado grupo, contexto, modelo de segurana, e nvel de

segurana, o escopo da informao que pode ser acessada pode diferir para leitura,
escrita, ou notificao;
d) informaes sobre vises MIB: a estrutura vacmMIBView consiste de um nico
objeto escalar: vacmViewSpinLock, e uma tabela: vacmViewTreeFamilyTable . O
objeto vacmViewSpinLock, habilita as aplicaes geradoras de comandos a
coordenarem seus usos da operao Set atravs da criao e modificao de vises.
Pode haver mltiplas subrvores associadas com um dado viewName , caso no qual
a viso MIB para este viewName consiste da unio de todas estas subrvores. Cada
entrada na vacmViewTreeFamilyTable define uma famlia de subrvores MIB,
usando a subrvore, a mscara, e o tipo de objetos da coluna. Esta tcnica usada
tambm no filtro de notificaes. Em essncia, uma subrvore consiste de um
objeto MIB mais todos os objetos que esto subordinados a ela na hierarquia de
nomeao. possvel excluir certas partes desta subrvore de forma que ela
permanea no como uma subrvore completa, mas apenas como uma subrvore
parcial, consistindo de um objeto MIB e alguns de seus objetos subordinados. Esta
uma famlia de subrvores. Ento se mltiplas entradas forem agrupadas,
83
possvel definir uma coleo arbitrria de objetos MIB para serem usados para um
propsito em particular.
FIGURA 22 A MIB VACM
va c m M IB O b j e t c ts
v a c m C on te x t T a b le ( 1 )
va c m C o n t e xtE n t ry (1 )
v a c m C on te x t N a m e ( 1 )
va c m S e c u r it y M od e l ( 1 )
v a cm S e cu ri t y N a m e ( 2 )
v a c m G ro u p N a m e ( 3 )
va c m S e c u r it y T o G r ou p S t o r ag e T y p e ( 4 )
va c m S e c u r it y T o G r ou p S t a t u s (5 )
va c m S e c u ri t y T o G r ou p T ab le ( 2 )
va c m S e c u r ity T o G r o u p E n t r y ( 1 )
v ac m A c c e s s C o n te x tP r ef i x ( 1 )
v a c m A cc e s s Ta b l e ( 4 )
v a c m A c c e s sS e c u r i t yM o d e l ( 2 )
va c m A c c e s s E n t ry ( 1 )
v ac m A c c e s s S e c u r it yL ev e l ( 3 )
v a c m M I B V i ew s ( 5 )
v ac m Vie w S pin Lo c k (1 )
v ac m V ie w T r e e Fa m i ly T a b le ( 2 )
v a c m V i e w T r e e F a m il yE n t r y ( 1 )
v a c m V i e w T re e F am i ly V ie w N a m e ( 1 )
v a c m V ie w T r e e F a m il yS u b tr e e ( 2 )
v a c m V i e w T re e F a m i l yM a s k ( 3 )
v a c m V i e w T r e e F a m i ly T y p e ( 4 )
v a c m V i e w T re e F am i ly S t a tu s ( 5 )
s n m p N o t ify F il t er R o w S t a t u s ( 6 )
v a c m A c c e s s C on te x t M a tc h ( 4 )
v a c m A c c e s s R ea d V i ew N a m e ( 5 )
v a c m A c c e s sW ri t e V i e w N a m e ( 6 )
v ac m A cc e s s N o t if yV i e w N a m e ( 7 )
va c m A c c e s s S t o r a g e T y p e ( 8 )
va c m A c c e ss S t a tu s ( 9 )
84
Segundo Stallings (2001), a RFC 2275 sugere que uma configurao inicial da MIB
VACM seja feita durante a instalao de um novo motor SNMP que suporte o VACM. A
RFC 2275 define trs possveis configuraes iniciais:
a) configurao inicial sem acesso;
b) configurao inicial semi-segura;
c) configurao inicial com segurana mnima.
Para a configurao inicial sem acesso, no h nenhuma configurao inicial e
nenhum acesso s variveis MIBs locais permitido durante a instalao do sistema. Nos
outros dois casos h uma diferena apenas nas entradas da vacmViewTreeFamilyTable. As
demais entradas: vacmContextTable, vacmSecurityToGroupTable, e vacmAccessTable so
iguais para estas duas configuraes.
O vacmContextTable configurado inicialmente com uma nica entrada que possui o
contextName de uma string vazia. Por conveno, este o contexto padro. Similarmente, a
vacmSecurityToGroupTable configurada inicialmente com uma entrada apenas. Esta entrada
especifica o USM como o securityModel, um securityName com initial e um groupName
com initial.
Privilgios
de
acesso
sero
configurados
para
este groupName.
Subseqentemente, se o gerente de configurao para este sistema desejar expandir o uso

desta configurao semi-segura, este pode adicionar mais securityNames a este groupName.
No ser necessrio fazer outras alteraes.
Tendo definido um contexto e um grupo, preciso definir as vises MIB deste
contexto para o qual este grupo tem acesso. As requisies podem chegar neste grupo com
trs nveis de proteo de mensagem: sem proteo, somente autenticao, e autenticao
mais privacidade. A vacmAccessTable configurada para este groupName , contextName , e
securityModel como segue:
a) para comunicao sem proteo (noAuthNoPriv), o acesso a uma viso MIB
restrita permitido para operaes de leitura e notificao, e nenhum acesso
permitido para operaes de escrita;
b) para comunicaes protegidas tanto por autenticao quanto por autenticao mais
privacidade, permitido o acesso viso MIB internet, que se refere a subrvore
internet inteira da MIB-2.
85
Tudo o que ainda resta definir as vises MIB que correspondem aos viewName
internet e restricted. Isto feito na vacmViewTreeFamilyTable . H uma entrada para
internet. Esta entrada possui um valor de subrvore 1.3.6.1, que o identificador para o
objeto internet MIB-2. Por isso, podemos fazer a seguinte afirmao: para todos os diretores
que so membros do grupo initial, que comunicam uma requisio usando autenticao ou
autenticao e privacidade usando o securityModel USM, acesso completo a subrvore
internet sob o contextName garantido para operaes de leitura, escrita e notificaes.
Durante a instalao inicial, o nico diretor que membro deste grupo o diretor com o
securityName initial.
As cinco entradas restantes da vacmViewTreeFamilyTable possuem um valor
vacmViewTreeFamilyViewName com restricted. Entretanto, quando esta tabela indexada
usando um viewName com restricted, a viso MIB definida pela coleo destas cinco
entradas. Cada uma destas cinco entradas tem um tipo included, e cada uma inclui uma
subrvore diferente. Por isso, a viso MIB, definida por estas cinco entradas, consistem da
unio das seguintes subrvores da MIB-2:
a) o grupo system da MIB -2 (1.3.6.1.2.1.1);
b) o grupo snmp da MIB-2 (1.3.6.1.2.1.11);
c) o snmpEngine (1.3.6.1.6.3.7.2.1) definido na RFC 2271;
d) o snmpMPDStats (1.3.6.1.6.3.8.2.1) definido na RFC 2272;
e) o usmStats (1.3.6.1.6.3.9.2.1) definido na RFC 2274.
Com isso, possvel fazer a seguinte afirmao: para todos os diretores que so
membros do grupo initial, que comunicam uma requisio sem autenticao usando o
securityModel USM, o acesso restricted ao conjunto de subrvores sob o contextName
permitido para operaes de leitura e notificao. Em adio, acesso ao conjunto de
subrvores do grupo internet garantido para operaes de leitura, escrita, e notificao
para uma requisio comunicada com autenticao. No momento da instalao, o nico
diretor que membro deste grupo o diretor com securityName initial.
5.8 A API ADVENTNET SNMPV3

Segundo a AdventNet (1995), a API SNMP AdventNet o ambiente de
desenvolvimento mais abrangente para construir aplicaes e applets de gerenciamento
86
baseados na estrutura SNMP. Esta API consiste em pacotes Java que podem ser usados para
desenvolver solues e produtos para o gerenciamento de redes baseados em Java e na Web.
As principais caractersticas da API AdventNet SNMPv3 so:
a) comunicao SNMP para os protocolos SNMPv1, SNMPv2c e SNMPv3;
d) segurana, conforme definido pelos modelos USM e VACM;
e) suporte MIB para os formatos SMIv1 e SMIv2;
f) componentes Java Beans SNMP que aumentam a funcionalidade da API para uso
em ferramentas de desenvolvimento visual em Java;
g) suporte a banco de dados para realizar o carregamento de MIBs;
h) suporte para armazenamento de informaes de usurios SNMPv3 em banco de
dados;
i) SNMP Applet Server (SAS) para facilitar a comunicao entre applets e
dispositivos gerenciados;
j) suporte ao tunelamento (tunneling) HTTP para que os applets se comuniquem
sobre uma rede com restries de firewall;
k) suporte aos Enterprise Java Beans (EJB) para o desenvolvimento de aplicaes de
gerenciamento multicamadas escalveis;
l) acesso a API SNMP via Remote Method Invocation (RMI) e Common Object
Request Broker Architecture (CORBA) para fornecimento de suporte a computao
distribuda;
m) ferramenta MibBrowser poderosa, que pode ser usada tanto como uma aplicao
como um applet;
n) suporte a internacionalizao para os componentes da API e da User Interface
(UI);
o) ferramentas de linha de comando como snmpget, snmpgetnext, snmpset, sendtrap ,
etc.
Dentre os motivos para uso da API AdventNet para construir aplicaes de
gerenciamento pode -se citar:
a) suporte multiplataforma: suporta todas as maiores plataformas atuais como Solaris,
WindowsNT e Linux com um cdigo base comum para ambas as plataformas;
87
p) padres abertos: construda sobre padres abertos e seguindo as tecnologias padro
Internet correntes como Java Beans, HTTP, RMI, CORBA, EJB, etc. O benefcio
chave destas tecnologias a rapidez entre desenvolvimento-venda e a facilidade no
desenvolvimento de solu es personalizadas para o gerenciamento de redes;
q) customizao (customization): fornece uma ampla gama de interfaces Java para o
desenvolvimento e entrega de solues altamente personalizadas;
r) escalabilidade: fundamentalmente designada como um sistema multicamadas,
baseada em tecnologias Internet amplamente usadas, para o desenvolvimento de
solues escalveis;
s) flexibilidade: uma hierarquia de bibliotecas em pacotes Java fornecida,
permitindo a seleo do nvel de suporte via bibliotecas desejado. Assim, possvel
acessar informaes detalhadas sobre o SNMP usando a API de baixo nvel, ou usar
Java Beans de alto nvel para simplificar a programao, alm de funcionalidades
adicionais que fornecem a possibilidade de desenvolvimento sem a necessidade de
negociar com os detalhes do SNMP;
t) gerenciamento de redes baseadas na Web: atravs de suporte ao HTTP e applets. A
API SNMP AdventNet inclui mdulos como SAS e HTTP que permitem aos
usurios gerenciarem sua rede via Internet, ou at mesmo atravs de dispositivos
sob firewalls. As APIs SAS podem ser estendidas para adicionar suporte a SSL;
u) conformidade com padres: a API SNMP da AdventNet est em conformidade
com as seguintes especificaes Internet:
- SNMPv1 - RFC 1155 e RFC 1157;
- SNMPv2c - RFC 1901 e RFC 1907;
- SNMPv3 - RFC 2571 e RFC 2572;
- SNMPv3 - RFC 2574 (USM);
- SNMPv3 - RFC 2575 (VACM);
- co-existncia entre SNMPv1, SNMPv2c, SNMPv3 - RFC 2576;
- filtro de notificaes e proxy forwarding - RFC 2573.
Para o desenvolvimento do prottipo proposto no presente trabalho sero utilizadas as
facilidades existentes na API de alto nvel.
88
6 DESENVOLVIMENTO DO PROTTIPO
A seguir sero apresentadas a especificao e a implementao do prottipo, bem
como as tcnicas, metodologias e ferramentas utilizadas no seu desenvolvimento.
6.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER

TRABALHADO
O sistema a ser desenvolvido dever possuir essencialmente dois elementos:
a) um agente que ir fornecer informaes de desempenho referentes ao elemento de
rede no qual est instalado, mais especificamente, informaes referentes ao
subgrupo IP da Mib-2 deste equipamento e;
b) um gerente que far a exposio grfica dos resultados obtidos deste agente,
permitindo desta forma, que o administrador da rede possa visualizar os dados do
equipamento em tempo real.
A partir destes dados o administrador da rede pode observar o desempenho na
transmisso e recepo de pacotes IP no equipamento analisado, bem como dados sobre
pacotes com erros, desfragmentados, etc.
Mais importante, entretanto, so as primitivas de segurana utilizadas na comunicao
entre o agente e o gerente. O agente deve fornecer informaes apenas aos gerentes que
estejam registrados e habilitados a obterem estas informaes, obedecendo sua poltica de
controle de acesso interna definida e configurada pelo administrador da rede, evitando assim
que estas informaes sejam acessadas e/ou adulteradas por usurios no autorizados. Alm
disso, os dados transmitidos entre o agente e o gerente autorizado devem ser protegidos
usando funes de criptografia, para evitar que um usurio malicioso tenha acesso s
informaes trocadas entre ambos.
Para atingir estes objetivos a comunicao entre o agente e o gerente ser realizada
obedecendo s novas especificaes do SNMPv3, que incluem principalmente a autenticao
e a privacidade na comunicao entre o agente e o gerente atravs do uso da criptografia, da
autenticao via HMAC, do uso das funes de sincronizao e de polticas de controle de
acesso.
89
6.2 ESPECIFICAO
A tcnica utilizada para o desenvolvimento da especificao do prottipo foi a
orientao a objetos atravs da Unifield Modeling Language UML. Para obter maiores
informaes sobre a orientao a objetos usando a UML consulte Booch (2000) e Furlan
(1998).
A ferramenta utilizada para a especificao do prottipo foi a verso Student do
software Rational Rose. Para obter maiores informaes sobre esta ferramenta consulte
Rational (1995).
6.2.1
DIAGRAMAS DE CASOS DE USO

Conforme a notao da UML, e utilizando a ferramenta Rational Rose Student, foi
desenvolvido o diagrama de casos de uso conforme a figura 23, onde se destacam os casos de
uso principais do sistema:
a) obter informaes de desempenho: o usurio acessa a aplicao gerente e solicita
determinadas informaes relacionadas ao dese mpenho. O gerente entra em contato
com o agente e este aps verificar que o pedido vlido, realiza a consulta s
variveis MIB repassando seus valores ao gerente que os exibe em um grfico;
b) inicializar gerente: conjunto de operaes necessrias para o funcionamento do
gerente;
c) inicializar agente: conjunto de operaes necessrias para o funcionamento do
agente.
Figura 23 - Diagrama de casos de uso
AgenteIp
Usurio
Obter Informaes Desempenho

uses
Inicializar Agente
Obter Valores na MIB
GerenteIp
uses
Consultar Valores
Inicializar Gerente
90
6.2.2
DIAGRAMA DE CLASSES
Inicialmente, foram identificadas as principais classes do sis tema, seus atributos,
relacionamentos e operaes, conforme figuras 24 e 25.

Foram definidas as classes AgenteIp, IpRequestHandler, IpInstrument, IpStat e
GerenteDesempenhoIp para atender aos requisitos do prottipo.
Figura 24 - Diagrama de Classes: parte agente
IpInstrument
ipDefaultTTL
ipForwDatagrams
ipForwarding
ipFragCreates
ipFragFails
ipFragOKs
ipInAddrErrors
ipInDelivers
ipInDiscards
ipInHdrErrors
ipInReceives
ipInUnknownProtos
ipOutDiscards
ipOutNoRoutes
ipOutRequests
ipReasmFails
ipReasmOKs
ipReasmReqds
ipReasmTimeout
ipRoutingDiscards
<<uses>>
getIpDefaultTTL()
getIpForwDatagrams()
getIpForwarding()
getIpFragCreates()
getIpFragFails()
getIpFragOKs()
getIpInAddrErrors()
getIpInDiscards()
getIpInDelivers()
getIpInHdrErrors()
getIpInReceives()
getIpInUnknownProtos()
getIpOutDiscards()
getIpOutNoRoutes()
getIpOutRequests()
<<uses>>
getIpReasmFails()
getIpReasmOKs()
getIpReasmReqds()
getIpReasmTimeout()
getIpRoutingDiscards()
setIpDefaultTTL( )
setIpForwarding( )
<<type>>Runnable
IpRequestHandler
agentName
run()
IPDEFAULTTTL
IPFORWARDING
IPFORWDATAGRAMS
IPFRAGCREATES
IPFRAGFAILS
IPFRAGOKS
IPINADDRERRORS
<<uses>>
IPINDELIVERS
IPINDISCARDS
IPINHDRERRORS
IPINRECEIVES
IPINUNKNOWNPROTOS
IPOUTDISCARDS
IPOUTNOROUTES
IPOUTREQUESTS
<<uses>>
IPREASMFAILS
IPREASMOKS
AgenteIp
IPREASMREQDS
IPREASMTIMEOUT
(from Use Case View)
IPROUTINGDISCARDS
agentDir
atomicTable
agentOptions
instrument
agentInfo
REMOVE_ENTRY
ipListener
ipOidRep
usmUserListener
mibVarHash
usmUserTableListener
vacmAccessTableListener
ipRequestHandler( )
vacmContextTableListener
getIpOidRep()
vacmMIBViewsListener
getMibVarHash()
vacmSecurityToGroupTable
getOidRep()
Listener
setIpInstrument( )
vacmViewTreeFamilyTableListener
getSubidList()
processGetNextRequest( )
AgenteIp()
processGetRequest( )
getIp()
processSetRequest( )
initAgenteIp()
0..*
IpStat
int getIpStatField( )
SnmpAgent
initSnmpExtensionNodes()
initializeV3Settings()
shutDownSNMPAgent()
setSnmpVersion( )
setDebugLevel(int debug)
setPort(port, boolean)
setAsyncMode(boolean)
setMaxThreads( )
setSnmpV3Compliance(boolean)
setV3Configuration(boolean)
addSnmpPduRequest
Listener(handler)
addTrapRequestListener( )
91
Figura 25 - Diagrama de Classes: parte gerente
comunica
LineGraphBean
setBounds(int, int, int, int)
setLfontsize(int)
setLfontstyle(String)
setXgrid(int)
setYgrid(int)
setLineColors(Color[])
setTitle(String)
setXlabel(String)
setYlabel(String)
setLineLabels(String[])
SnmpPoller
setValues()
addResultListener( )
setSendTimeout
Events(boolean)
loadMibs(String)
setDebug(boolean)
stopPolling()
restartPolling()
setObjectIDList(String[])
setPollInterval(int)
setSnmpVersion(int)
setTargetHost(Stirng)
setTargetPort(int)
setPrincipal(String)
setSecurityLevel(int)
setAuthProtocol(int)
setAuthPassword(String)
setPrivPassword(String)
setContextName(String)
setContextID(String)
create_v3_tables()
<<type>> ComponentListener
componentHidden( )
componentMoved( )
componentResized( )
componentShown( )
<<uses>>
<<implements>>
0..*
0..* <<uses>>
GerenteDesempenhoIp
0..*
(from Use Case View)
<<implements>>
<<type>>ActionListener
actionPerformed( )
NivSeg
Versao
protAut
protPriv
Comunidade
Contexto
Host
IDContexto
Intervalo
Mib
Oid
Porta
SenhaAut
SenhaPriv
Timeout
Usuario
JFrame
init()
show()
addSingle( )
SnmpApi
setSerializeFileName(String)
serialize()
GerenteDesempenhoIp()
main( )
IniciarPolling()
A classe AgenteIp define mtodos para acessar os dados pelos quais responsvel e
para processar as mensagens SNMPv3, estando diretamente relacionada s seguintes classes:
a) SnmpAgent: classe herdada da API SNMPv3 da AdventNet que contm todos os
mtodos utilizados pela classe AgenteIp relacionados s operaes SNMP;
b) Runnable: interface padro da API Java que define os mtodos utilizados pela
classe AgenteIp para executar o agente no prompt de comando;
c) IpRequestHandler: classe que estende a classe SimpleRequestHandler da API
SNMPv3 da AdventNet. Esta classe responsvel por direcionar as requisies
92
recebidas pelo agente s classes responsveis pelo seu processamento e por
processar automaticamente todas as mensagens SNMPv3 realizando a autenticao
das mensagens e a criptografia/descriptografia dos dados quando necessrio;
d) IpInstrument: classe responsvel por definir e implementar os mtodos utilizados
para acessar e alterar as variveis escalares MIB do grupo ip da Mib-2;
e) IpStat: classe nativa utilizada pela classe IpInstrument para acessar as informaes
diretamente do sistema operacional do equipamento no qual o agente est sendo
executado.
A classe GerenteDesempenhoIp executa os mtodos necessrios para se conectar ao
agente e para buscar e exibir os resultados em um grfico. Assim como a classe AgenteIp, a
classe GerenteDesempenhoIp faz uso de outras classes para realizar suas operaes. Estas
classes so as seguintes:
a) SnmpPoller: classe da API SNMPv3 da AdventNet que contm a definio de
todos os mtodos utilizados pela classe LineGraphBean para tratar as mensagens e
parmetros do SNMPv3, usados durante o polling, alm de possuir mtodos para
realizao da descoberta de novos agentes e de sincronizao com estes agentes;
b) LineGraphBean: classe da API SNMPv3 da AdventNet responsvel por realizar a
exposio dos dados de polling na tela na forma de um grfico de linhas;
c) SnmpApi:
classe
da
API
SNMP
da
AdventNet
utilizada
pela
classe
GerenteDesempenhoIp para armazenar os dados de descoberta e sincronizao de

agentes para uso posterior;
d) Jframe: classe padro da API Java utilizada para exibir o gerente na tela;
e) ComponentListener: interface padro da API Java implementada pela classe
LineGraphBean para tratar os eventos desta classe;
f) ActionListener: interface padro da API Java implementada pela classe
LineGraphBean e utilizada para tratar os eventos de clique de mouse realizados nos
botes de configurao e execuo do gerente.
93
6.2.3
DIAGRAMAS DE SEQNCIA
Nos diagramas de seqncia pode -se observar a execuo de cada caso de uso e
verificar as mensagens trocadas entre os objetos (agente e gerente). Os principais diagramas

de seqncia encontrados no sistema so:
a) obter informaes de desempenho: o usurio utiliza a aplicao gerente para obter
acesso s informaes desejadas e utilizando a interface da aplicao gerente
realiza todos os passos necessrios para poder realizar esta operao. Primeiro o
usurio fornece as informaes que deseja analisar e os parmetros SNMPv3,
depois disso o gerente se encarrega de se conectar ao agente, solicitar as
informaes desejadas e, aps obter as estas informaes do agente, a aplicao
gerente exibe os resultados em um grfico na tela (fig. 26). Este caso de uso
composto de dois outros subcasos de uso:
Figura 26 - Obter informaes de desempenho
94
- consultar valores: o gerente entra em contato com o agente especificado pelo

usurio usando as opes de autenticao e segurana do SNMPv3 e, caso tenha
permisso de acesso s variveis solicitadas pelo usurio, o gerente aps receber os
95
valores do agente os exibe no grfico, caso contrrio, exibe uma mensagem de erro
informando a sua causa;
- obter valores na MIB: aps verificar que o pedido vlido, ou seja, que o gerente
tem permisso para acessar a(s) informao(es) solicitada(s) e que a mensagem
foi corretamente autenticada sem erros, o agente realiza a consulta s variveis
MIB obtendo seus valores e repassando-os ao gerente;
b) inicializar gerente: antes de poder solicitar qualquer tipo de informao de um
determinado agente o gerente precisa inicialmente, se registrar com este agente para
atender aos requisitos do SNMPv3. O gerente realiza esta operao fornecendo as
informaes de autenticao e privacidade e realizando um processo de descoberta
(para obter o agente ao qual vai se registrar) e de sincronizao (pa ra poder usar
autenticao e privacidade). Esta situao pode ser vista na figura 27;
c)
inicializar agente: o agente deve realizar um processo de inicializao a fim de

carregar todas as tabelas com as informaes VACM e USM. Alm disso deve
definir a porta, o host, o protocolo usado, as MIBs que utilizar, enfim, todas as
operaes necessrias para que ele possa atuar como um agente no equipamento
onde foi instalado (fig. 28).
Figura 27 - Inicializao do gerente
96
97
Figura 28 - Inicializao do agente
UmUsuario :
Usurio
:
<<type>>Runnable
UmAgente :
AgenteIp
: SnmpAgent
main (String)
AgenteIp()
run()
init()
initAgenteIp()
initializeV3Settings()
initSnmpExtensionNodes()
Devido ao fato de as operaes de troca de mensagens entre as entidades agente e

gerente serem extensas e numerosas, os diagramas de seqncia exibem apenas uma forma
simplificada sobre como esse processamento realizado. Por exemplo, o mtodo
processarPDU() pode se referir ao mtodo processGetRequestMessage(), ao mtodo
processGetNetxRequestMessage(), ou ao mtodo processSetRequestMessage() da classe
IpRequestHandler. Alm disso os diagramas de seqncia no permitem demonstrar
processos que so processados simultaneamente, como por exemplo o processo de descoberta
e sincronizao.
98
6.3 IMPLEMENTAO
Nesta etapa ser demonstrada a implementao do prottipo conforme a especificao
desenvolvida anteriormente.
6.3.1
TCNICAS E FERRAMENT AS UTILIZADAS

Para o desenvolvimento do prottipo foram utilizados a linguagem de programao
Java, a API SNMPv3 da empresa AdventNet e o sistema operacional Windows2000 Server

no qual foram realizados os testes do prottipo.
De acordo com Furlan (1998), ...uma das linguagens de programao que se adaptou
implementao de funes de gerenciamento foi a linguagem Java. O aparecimento da Java
revolucionou o desenvolvimento de software para Internet, Intranet e quase todas as redes
distribudas. Alm disso, a Java uma linguagem totalmente orientada a objetos, dinmica,
independente de plataforma tecnolgica, segura e relativamente fcil de usar.
Para o desenvolvimento de parte da funcionalidade do agente foi utilizada a Java
Native Interface JNI. Esta foi a forma encontrada para permitir o acesso por parte do agente,
s informaes sobre os pacotes IP do sistema operacional Windows2000 Server.
Tambm foram utilizados Java Beans , ...estruturas utilizadas para definir
componentes de software reutilizveis, incorporveis e modulares. (Flanagan, 1999)
Para obter mais informaes sobre a linguagem Java, Java Beans e JNI consulte Deitel
(2001), Flanagan (1999) e Sun (199-).
Segundo a AdventNet (1995), a API SNMP AdventNet o ambiente de
desenvolvimento mais abrangente para construir aplicaes e applets de gerenciamento
baseados na estrutura SNMP. Esta API consiste em pacotes Java que podem ser usados para
desenvolver solues e produtos para o gerenciamento de redes baseados em Java e na Web.
Para o desenvolvimento do prottipo foi utilizada a API
SNMPv3 verso 4 da
empresa AdventNet. Para obter maiores informaes sobre a API SNMPv3 da AdventNet
consulte AdventNet (2001).
99
O prottipo tambm utiliza a Extensible Markup Language XML para armazenar as
informaes das tabelas VACM e USM do agente. Para obter maiores informaes sobre a
XML consulte W3C (1996).
O prottipo foi executado em uma rede utilizando o sistema operacional
Windows2000 Server. Para obter maiores informaes sobre este sistema operacional
consulte Minasi (2000).
Quadro 01: Inicializao do agente
String version = " V3";
int debugLevel = com.adventnet.agent.logging.Level.WARN;
AgentUtil.setAgentDir(agentDir);
if(agentOptions.getVersion() != null){
version = agentOptions.getVersion(); }
super.setSnmpVersion(version, false);
if(agentOptions.getDebugLevel() != -1){
debugLevel = agentOptions.getDebugLevel(); }
super.setDebugLevel(debugLevel);
int port = 161;
if(agentOptions.getPort() != -1){
port = agentOptions.getPort(); }
super.setPort(port, false);
int trapSendingPort =162;
if(agentOptions.getTrapSendingPort() != -1){
trapSendingPort = agentOptions.getTrapSendingPort(); }
super.setAsyncMode(true);
super.setMaxThreads(4);
if(version.equalsIgnoreCase("V3")){
// Compatibilidade com V3
super.setSnmpV3Compliance(true);
// Inicializa as configuraes V3.
super.setV3Configuration(true);
initializeV3Settings(); }
Inicialmente foram criadas as classes AgenteIP, IpRequestHandler e IpInstrument. Na

classe AgenteIp esto definidas todas as operaes de inicializao do agente dentre as quais
100
destaca-se a initAgenteIp(), conforme mostrado no quadro 01 e a inicializao das tabelas
VACM e USM realizada pelo mtodo initializeV3settings() exibido no quadro 02.
Quadro 02: Inicializao das tabelas VACM e USM do agente
public void initializeV3Settings(){
String engineID = "127.0.0.1x8001";
super.getSnmpAPI().setSnmpEngineID(engineID.getBytes());
usmUserLis tener = new UsmUserRequestHandler(this);
usmUserListener.addRegistrationListener(hdlr);
usmUserTableListener = new UsmUserTableRequestHandler(this, "conf", "UsmUserTable.xml", "xml");
usmUserTableListener.addRegistrationListener(hdlr);
vacmMIBViewsListener = new VacmMIBViewsRequestHandler(this);
vacmMIBViewsListener.addRegistrationListener(hdlr);
vacmContextTableListener = new VacmContextTableRequestHandler(this, "conf", "VacmContextTable.xml",
"xml");
vacmContextTableListener.addRegistrationListener(hdlr);
vacmSecurityToGroupTableListener =
new
"VacmSecurityToGroupTable.xml", "xml");
VacmSecurityToGroupTableRequestHandler(this,
"conf",
vacmSecurityToGroupTableListener.addRegistrationListener(hdlr);
vacmAccessTableListener = new VacmAccessTableRequestHandler(this, "conf", "VacmAccessTable.xml",
"xml");
vacmAccessTableListener.addRegistrationListener(hdlr);
vacmviewTreeFamilyTableListener
=
new
"VacmViewTreeFamilyTable.xml", "xml");
VacmViewTreeFamilyTableRequestHandler(this,
"conf",
vacmviewTreeFamilyTabl eListener.addRegistrationListener(hdlr);
}
O mtodo initializeV3settings() responsvel por ler as informaes das tabelas USM

e VACM e carreg-las para a memria do agente. No quadro 03 listado parte de uma destas
tabelas: a UsmUserTable.xml.
101
Quadro 03: Parte do arquivo UsmUSerTable.xml
<? xml version="1.0" encoding="UTF -8" ? >
<Table >
<row >
<column name =" usmUserSecurityName" value=" privUser" />
<column name =" usmUserSecurityLevel " value =" 3" />
<column name =" usmUserCloneFrom" value=" .0.0" />
<column name =" usmUserAuthProtocol" value =" MD5_AUTH" />
<column name =" usmUserPrivProtocol" value=" CBC_DES" />
<column name =" usmUserPublic" value="757365725075626c6963" />
<column name =" usmUserAuthPassword" value ="7a78817495778578" />
<column name =" usmUserPrivPassword " va lue =" 7a78817495778578" />
<column name =" usmUserStorageType" value="3" />
<column name =" usmUserStatus" value=" 1" />
</row >
</Table >
Estes arquivos de tabela podem ser editados manualmente pelo administrador ou

dinamicamente pelos gerentes. No caso de edio manual o agente deve ser reiniciado para
que as novas alteraes entrem em vigor. A listagem completa das tabelas de configurao
utilizadas pelo agente SNMPv3 a seguinte:
a) UsmUserTable.xml: armazena os usurios que podem realizar operaes neste
agente;
b) V3TrapForwardingTable.xml : armazena os usurios configurados para receber
traps SNMPv3;
c) VacmAccessTable.xml : armazena informaes sobre grupos de acesso;
d) VacmContextTable.xml : armazena informaes sobre os contextos;
e) VacmSecurityToGroupTable.xml : contm a relao SecurityLevel/Group que
relacionam os usurios de um nvel de segurana com um grupo especfico;
f) VacmViewTreeFamilyTable.xml : armazena informaes sobre as vises existentes.
J a classe IpRequestHandler responsvel por processar todas as mensagens
SNMPv3 recebidas pelo agente destinadas ao grupo ip da Mib-2, realizando a autenticao e
criptografia/descriptografia encaminhando em seguida a requisio para a classe responsvel
por processar esta requisio. Parte deste processamento pode ser vist o no quadro 04.
102
Quadro 04: Parte do processamento de mensagens GET-Request SNMPv3
// Mtodo que processa todas as operaes GET solicitadas.
protected void processGetRequest(SnmpVarBind varb,
AgentNode node,
VarBindRequestEvent pe)
throws Agent SnmpException{
try {
// Isto indica que o n est fora da viso das mibs carregadas.
if(node == null){
AgentUtil.throwNoSuchInstance(pe.getVersion());
}
int [] oid = (int [] )varb.getObjectID().toValue();
if(oid.length != ipOidRep.length + 2){

}
int [] inst = (int [] )AgentUtil.getInstance(oid,ipOidRep.length);
if(inst[1] != 0){
}
Object toReturn = null;
switch(node.getSubId()){
case IPFORWARDING:
toReturn = instrument.getIpForwarding();
if(toReturn == null){
}
SnmpInt var0 = new SnmpInt(((Integer )toReturn).intValue());
varb.setVariable(var0);
break;
Aps o processamento, a classe IpRequestHandler envia uma requisio classe

IpInstrument (desde que seja uma requisio s variveis do grupo ip da Mib -2) para que ela
realize as operaes necessrias sobre as variveis IP. Em seguida a classe IpInstrument
retorna o resultado da operao para a classe IpRequestHandler que monta uma PDUResponse e, realiza o processamento SNMPv3 necessrio encaminhando a resposta ao
103
gerente. Parte do processamento realizado pela classe IpInstrument pode ser visto no quadro
05.
Quadro 05: Parte do processamento de requisies do grupo ip da Mib-2
/**
* Trata o pedido SNMP Set Request para a varivel ipForwarding
* @param valor - O valor Integer a ser configurado
* @throws AgentException em caso de erro
*/
public synchronized void setIpForwarding(Integer value)
throws AgentException{
if(value == null){
throw new AgentException("", CommonUtils.WRONGVALUE);
}
if(!((value.intValue() == 1)||(value.intValue() == 2))){
throw new AgentException("", CommonUtils.WRONGVALUE);
}
ipForwarding = value;
}
/**
* Trata o p edido SNMP Get Request para a varivel ipDefaultTTL
*/
public Integer getIpDefaultTTL()
throws AgentException{
int Val_ipStat = 0;
Val_ipStat = IpStat.getIpStatField(1);
Integer ipDefaultTTL = new Integer(Val_ipStat);
return ipDefaultTTL;
}
J por parte do gerente o principal mtodo o mtodo setValues() (quadro 06) que
obtm os valores das variveis SNMPv3 da tela do gerente e as utiliza para montar PDUs
GET-Request utilizadas para realizar o polling sobre as variveis solicitadas pelo usurio,
alm de realizar a descoberta e sincronizao com o agente salvando as informaes em um
arquivo para uso em sesses futuras com o mesmo agente.
104
Quadro 06: Mtodo setValues() do arquivo GerenteDesempenhoIp.java
public void setValues() {

// Configurar os Oids da sesso.
String Oids = tfOid.getText();
StringTokenizer stoken = new StringTokenizer(Oids, " ");
int num = stoken.countTokens();
grafLinhas.setTitle("Plotando "+num +" OIDs");
grafLinhas.setXlabel ("Tempo em segundos");
grafLinhas.setYlabel ("Nmero de pacotes");
String listaOids[] = new String[num];
for(int i=0; i<num; i++)
{ // Obtm os Oids da caixa de texto.
listaOids[i] = stoken.nextToken();
}
// Transfere os OIDs para o objeto poller gerente.
poller.setObjectIDList(listaOids);
// Configura o intervalo de polling.
try
{
poller.setPollInterval( Integer.parseInt(tfIntervalo.getText()) );
}
catch (NumberFormatException nfm)
{
JOptionPane.showMessageDialog( GerenteDesempenhoIp.this,
"O valor do intervalo deve ser um nmero inteiro!",
"Configurao", JOptionPane.ERROR_MESSAGE );
tfIntervalo.setText(String.valueOf(poller.getPollInterval()));
}
// Configura a verso.
String ver = new String((String) comboVersao.getSelectedItem ());
if(ver.equalsIgnoreCase ("v1"))
{
poller.setSnmpVersion (poller.VERSION1);
}
else if (ver.equalsIgnoreCase ("v2"))
{
105
poller.setSnmpVersion (poller.VERSION2C);
}
else if (ver.equalsIgnoreCase ("v3"))
{
poller.setSnmpVersion (poller.VERSION3);
}
// Configura o host.
poller.setTargetHost( tfHost.getText() );
// Configura a porta.
poller.setTargetPort (Integer.parseInt ((tfPorta.getText ())));
// Caso seja a verso 3 do SNMP faa:
if(ver.equalsIgnoreCase ("v3"))
{
// Configura o usurio que far as requisies.
poller.setPrincipal (tfUsuario.getText ());
// Configura o nvel de segurana.
String NivSeg = new String((String) comboNivSeg.getSelectedItem ());
if(NivSeg.equalsIgnoreCase ("noAuth,noPriv"))
{
poller.setSecurityLevel(poller.NO_AUTH_NO_PRIV);
}
else if (NivSeg.equalsIgnoreCase ("Auth,noPriv"))
{
poller.setSecurityLevel(poller.AUTH_NO_PRIV);
}
else if (NivSeg.equalsIgnoreCase ("Auth,Priv"))
{
poller.setSecurityLevel(poller.AUTH_PRIV);
}
// Configura o protocolo de autenticao.
String ProtAut = new String((String) comboAut.getSelectedItem ());
if(ProtAut.equalsIgnoreCase ("MD5"))
{
106
}
poller.setAuthProtocol(poller.MD5_AUTH);
else if (ProtAut.equalsIgnoreCase ("SHA"))
{
poller.setAuthProtocol(poller.SHA_AUTH);
}
// Configura a senha para autenticao.
poller.setAuthPassword(tfSenhaAut.getText());
// Configura a senha para privacidade.
poller.setPrivPassword(tfSenhaPriv.getText ());
// Configura o contexto.
poller.setContextName (tfContexto.getText ());
// Configura o IDContexto.
poller.setContextID (tfIDContexto.getText ());
// Cria as tabelas USM e VACM necessrias e faz a sincronizao.
int criar = poller.create_v3_tables ();
// Testar se tudo funcionou.
if(criar == 1)
{
"Inicializao e Sincronizao Efetuada!",
"Configurao V3", JOptionPane.INFORMATION_MESSAGE );
// Salvar as informaes em disco para uso futuro (nao necessrio).
SnmpAPI api = new SnmpAPI();
api.setSerializeFileName ("ConfV3.ser");
try {
if(api.serialize() == false)
{
"Erro ao salvar as informaes no arquivo!",
"Configurao V3", JOptionPane.ERROR_MESSAGE );
}
} catch (SnmpException se) { }
}
107
{
else
"Inicializao e/ou Sincronizao Falhou!",
"Configurao V3", JOptionPane.INFORMATION_MESSAGE );

} // fim criar.
} // fim poller.getVersion==3.
else
{
poller.setCommunity(tfComunidade.getText());
}
// Exibe os resultados no grafico.
grafLinhas.setLineLabels(Oids);
// E inicia o polling.
grafLinhas.restartPolling() ;
// O envio e recepo das mensagens controlado automaticamente
// pela API, no necessrio fazer mais nada.
}
A seguir ser discutida a operacionalidade do prottipo.
6.3.2
OPERACIONALIDADE DA IMPLEMENTAO
Para a execuo do prottipo preciso tomar as seguintes medidas:
a) no(s) equipamento(s) onde ser instalado/executado o agente e o gerente, esteja
instalada a Java Virtual Machine JVM verso 1.4 ou superior;
b) configurar
arquivo
java.security
presente
em
C:\Program
files\Java \j2re1.x.x\lib\security acrescentando-se a seguinte linha ao mesmo:

security.provider.2=com.sun.crypto.provider.SunJCE;
c) copiar todos os arquivos existentes no diretrio Agente para um diretrio
qualquer no equipamento onde ser executada a aplicao agente e todos os
108
arquivos do diretrio Gerente para um diretrio qualquer no equipamento onde
ser executada a aplicao gerente;
d) copiar o arquivo IpStatProj.dll presente no diretrio IpStatNativo para o diretrio
System do sistema operacional;
e) configurar as variveis de ambiente Java executando o arquivo de configurao
ConfJavaVars.bat presente no diretrio bin das aplicaes agente e gerente;
f) executar as aplicaes agente e gerente atravs da execuo do arquivo run.bat
presente no diretrio bin das aplicaes agente e gerente.
Estes passos so necessrios porque o prottipo foi desenvolvido utilizando a
linguagem Java, algoritmos de privacidade e um mtodo nativo (JNI) escrito em Java.
No caso do agente possvel execut -lo usando-se opes especiais de inicializao,
executando-se a aplicao AgenteIp presente no diretrio bin do agente, diretamente no
prompt de comando do Microsoft Disk Operating System - MS-DOS. A seguir so exibidos
todos os parmetros adicionais que podem ser usados na inicializao do agente:
java AgenteIp [-d Debug_Level(0-6)] [-m arquivo_MIB] [-p porta] [-v versao] [-t
TrapSendingPort]
109
Figura 29 - Tela Inicial da aplicao gerente
onde:
-d [nvel depurao (0-6)] indica o nvel de depurao a ser utilizado pelo agente;
-m [arquivo] indica o arquivo de definio MIB a ser utilizado pelo agente;
-p [porta] indica a porta na qual o agente ir aguardar por requisies;
-v [verso] indica qual verso SNMP o agente ir suportar;
-t [porta de envio de trap] indica a porta que o agente ir utilizar para enviar traps .
No caso do agente, um exemplo de inicializao seria o seguinte:
java AgenteIp p 161 m AKIP-MIB
No exemplo acima o agente ser inicializado na porta 161 usando a MIB AKIP -MIB.
Esta MIB contm a definio de todos os objetos escalares do grupo ip da Mib-2 Ela
110
utilizada no prottipo tanto pelo agente quanto pelo gerente para realizar o gerenciamento de
desempenho.
A tela inicial do gerente, que surge logo aps a execuo do arquivo run.bat
mostrada na figura 29. Nesta tela possvel configurar todas as opes utilizadas pelo
SNMPv3. Primeiramente deve-se carregar a MIB que a aplicao gerente utilizar realizandose o seguinte procedimento:
a) clicar no boto Procurar MIB...;
b) escolher um arquivo de definio MIB que esteja presente no equipamento onde o
agente se encontra. No caso do prottipo preciso carregar a MIB AKIP -MIB
presente no diretrio mibs da aplicao gerente;
c) clicar no boto Carregar MIB. Se houverem erros de sintaxe no arquivo MIB
carregado ser exibida uma mensagem de erro no prompt do MS-DOS.
Em seguida o usurio deve preencher os campos SNMPv3 com as informaes
necessrias para se conectar ao agente com o qual deseja se comunicar.
Aps preencher os campos o usurio deve clicar no boto Configurar gerente. Se as
informaes estiverem corretas e o processo de descoberta e sincronizao com o agente
ocorrerem com sucesso, ser exibida uma mensagem informando que tudo correu bem e que
possvel a partir de agora consultar o agente, seno, uma mensagem de erro ser exibida
informando o motivo do erro.
Agora o usurio deve preencher o campo OID especificando as variveis do grupo ip
que deseja consultar digitando a parte final de seu ObjectID ou OID (a aplica o gerente
preenche internamente a parte inicial do OID .1.3.6.2.1) possvel consultar mais de um
OID ao mesmo tempo. Para isso basta preencher o campo OID separando as variveis com
um espao simples.
tambm possvel utilizar a aplicao gerente para consultar agentes SNMPv1 e
SNMPv2. Para tal, basta preencher o campo Comunidade e fornecer o(s) OID(s) que deseja
consultar.
111
A aplicao gerente tambm pode consultar outras variveis alm daquelas existentes
na MIB AKIP-MIB. Para poder consultar outras variveis da Mib -2 basta carregar outra MIB
contendo a definio de variveis de outros grupos da Mib-2 tais como if, system, etc.
A seguir ser exibido um exemplo do uso do sistema no monitoramento de um
elemento de rede (PC) do laboratrio Protem da Universidade Regional de Blumenau durante
o perodo de 30 minutos. As informaes de gerenciamento de desempenho coletadas foram
as seguintes: ipInDiscards , ipOutDiscards, ipInDelivers e ipInReceives.
Figura 30 - Medio inicial
Foram realizadas duas coletas em tempos diferentes. A primeira foi realizada com
intervalos de 20 segundos entre cada polling (fig. 30). A segunda coleta foi realizada com
intervalos de 15 segundos entra cada polling (fig. 31) .
Os resultados obtidos sero discutidos e analisados no prximo tpico.
112
Figura 31 - Medio final
6.4 RESULTADOS E DISCUSSO

possvel perceber pelos grficos exibidos nas figuras 30 e 31 que na primeira coleta
o equipamento estava utilizando muitos pacotes IP para a transmisso e recepo de dados.
Na segunda coleta entretanto, percebe -se que o nmero de pacotes sendo transmitidos e
recebidos diminuiu, indicando que o sistema operacional aumentou o tamanho dos pacotes IP,
o que permitiu o aumento do desempenho da rede. Resultado este que pode ser observado ao
se observar a taxa de transmisso de um arquivo sendo descarregado no equipamento
analisado. Durante a primeira coleta a taxa de transmisso era de aproximadamente 15Kb por
segundo sendo que no momento da segunda coleta esta taxa j estava em 32Kb por segundo.
Seria interessante poder testar o prottipo em um servidor Web, pois neste, h um
grande nmero de pacotes IP sendo processados, sendo que neste caso, analisar o trfego
gerado pelos pacotes IP bem como o nmero de pacotes sendo descartados devido a erros ou
falta de espao em buffer seria essencial para um administrador de rede poder tomar decises
baseadas nas informaes disponibilizadas pelo gerente do prottipo.
113
7 CONCLUSES
Atualmente, h um grande crescimento no uso das redes de computadores, e devido ao
grande nmero de equipamentos de rede existentes atualmente e por estes equipamentos
possurem caractersticas heterogneas e por serem produzidos por vrios fabricantes
diferentes, a possibilidade de que estes equipamentos venham a falhar ou que algum destes
equipamentos possa comprometer o desempenho desta rede (sua qualidade de servio)
tambm maior. Neste cenrio, essencial o uso de ferramentas automatizadas que possam
gerenciar remotamente estes equipamentos. O SNMPv3 torna possvel realizar esse
gerenciamento de forma segura e eficaz, fornecendo funcionalidades para obteno de
segurana e controle de acesso via polticas de acesso.
O nico objetivo que no foi completamente atingido foi o de gerenciar o desempenho
real de uma rede de computadores. Isto aconteceu devido falta de tempo hbil para realizar
um estudo mais detalhado das funes de gerenciamento de desempenho existentes, alm da
pouca literatura existente at mesmo na Internet sobre o assunto.
O uso dos diagramas de seqncia, se mostrou parcialmente inadequado para
representar o processamento e a troca de mensagens entre o agente e o gerente,
principalmente por no permitir representar situaes que ocorram em paralelo e situaes
onde existe mais de um caminho possvel a ser seguido. Para resolver este problema sugere-se
a utilizao de diagramas de estado e de atividades que tambm fazem parte da UML.
As ferramentas utilizadas na implementao do prottipo se mostraram totalmente
adequadas para o seu desenvolvimento. importante destacar que a utilizao da API
SNMPv3 da AdventNet sem dvida facilita e possibilita o rpido desenvolvimento de
aplicaes para o gerenciamento de redes utilizando o protocolo SNMP, alm de
disponibilizar um suporte rpido e gratuito aos desenvolvedores que utilizam a sua API.
A utilizao do SNMP como uma plataforma para realizar o gerenciamento de redes
de computadores prtica e fcil, entretanto, a terceira verso desta plataforma SNMPv3 j no mais to simples, pois a adio de privacidade e controle de acesso adiciona
tambm, complexidade.
114
Uma das limitaes do prottipo o fato de o gerente no realizar nenhum
processamento ou tomada de deciso sobre os dados coletados, ou seja, apresentar alguma
inteligncia. Novamente, em um sistema de gerncia de redes real, seria indispensvel que a
aplicao gerente realizasse pelo menos um processamento bruto dos dados (um clculo
estatstico, o uso de alguma funo de comparao de dados, etc), ou algo como avisar o
administrador da rede sempre que certos limiares fossem atingidos.
Outra limitao a de que apesar do prottipo ter sido desenvolvido em Java, parte da
portabilidade (caracterstica comum e importante desta linguagem) foi perdida, devido ao uso
de um mtodo nativo, sendo necessrio realizar adaptaes no presente prottipo para acessar
as informaes de desempenho em outras plataformas. Isto ocorreu, porque na poca do
desenvolvimento da proposta no se descobriu nenhum equipamento de rede que j
disponibiliza, e por conseqncia, implementa as novas funcionalidades SNMPv3 sendo
necessrio ento definir na proposta o desenvolvimento de todo um sistema de gerncia
(agente e gerente) ao nvel de prottipo. Pouco antes do trmino do presente trabalho
entretanto, descobriu-se que praticamente todos os roteadores da empresa Cisco j possuam
em seus equipamentos, a partir da verso 12 de seu sistema operacional, suporte via
configurao de agentes Cisco, s novas funcionalidades do SNMPv3.
Como contribuies do presente trabalho pode -se citar as seguintes:
a) um estudo simplificado da estrutura SNMPv3, seus elementos, caractersticas e
suas novas funcionalidades;
b) a criao de um prottipo simples mas funcional, implementando na prtica as
novas funcionalidades do SNMPv3;
c) um trabalho que pode ser estendido, podendo servir como base para novos
trabalhos conforme as sugestes para extenso citadas na prxima sesso;
d) um estudo da viabilidade e praticidade no uso da API SNMPv3 da empresa
AdventNet no desenvolvimento de aplicaes para o gerenciamento de redes de
computadores utilizando o SNMPv3;
e) a criao de um gerente SNMPv3, que pode vir a ser utilizado com outros softwares
de gerncia de redes de computadores baseados no SNMPv3 para a implantao da
gerncia de desempenho;
115
f) a criao de um agente SNMPv3 para o gerenciamento de desempenho de uma rede
de computadores, que implementa parte do grupo ip da Mib-2.
7.1 EXTENSES
Como sugestes para trabalhos futuros pode-se citar as seguintes:
a) implementar alguma inteligncia no gerente e no agente a fim de automatizar o
processo de deciso quando do surgimento de problemas;
b) estender o agente para que ele possa tratar mensagens Notification e implementar o
mecanismo de Trap Forwarding mecanismo este no implementado no presente
trabalho;
c) estender o agente para que ele possa fornecer suporte a todos os objetos presentes
na MIB-2, aumentando sua escalabilidade;
d) testar a extensibilidade do SNMPv3 atravs da implementao de novos mdulos
para realizar as tarefas de autenticao, privacidade e controle de acesso;
e) testar a modularidade do SNMPv3 atravs da utilizao de novos algoritmos de
criptografia e autenticao em substituio queles definidos pelo SNMPv3 alm da
definio de novas MIBs para criao de polticas de acesso especializadas;
f) realizar testes de desempenho para medir a utilizao de largura de banda e
processamento utilizados pelo SNMPv3 em comparao com as verses anteriores
a fim de medir o custo overhead e perda de desempenho ocasionada pelas novas
primitivas de autenticao e segurana do SNMPv3.
116
REFERNCIAS BIBLIOGRFICAS
ADVENTNET Inc. AdventNet SNMP API 3.3 documentation, Pleasanton, [2001].
Disponvel em: <http://www.adventnet.com/products/snmp/help.html>. Acesso em: 14 nov.
2002.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usurio. 5. ed. Rio de Janeiro:
Campus, 2000. 472p.
CARVALHO, Tereza Cristina Melo de Brito. Gerenciamento de redes: uma abordagem de
sistemas abertos. Sao Paulo: Makron Books, 1993. 364p.
DEITEL, Harvey M, DEITEL, Paul J, SANTRY, S. (Sean), et al.. Advanced Java 2
platform : how to program. Upper Saddle River : Prentice Hall, 2001. 1811p.
FLANAGAN, David. Java in a nutshell: a desktop quick reference. 3.ed. Beijing: OReilly,
1999. 649p.
FURLAN, Jose Davi. Modelagem de objetos atravs da UML-The Unifield Modeling
Language . So Paulo: Makron Books do Brasil, 1998. 329p.
HEGERING,
Heinz-Gerd;
ABECK,
Sebastian. Integrated
network
and
system
management. Wokingham: Addison-Wesley, 1994. 491p.

HORSTMANN, Cay S, CORNELL, Gary. Core Java 2 . So Paulo : Makron Books, 2001.
RFC/STD/FYI/BCP Archives. Internet RFC/STD/FYI/BCP archives, [199-]. Disponvel
em: < http://www.faqs.org/rfcs/>. Acesso em: 16 nov. 2002.
KUROSE, James F.; ROSS, Keith W. Computer networking: a top-down approach
featuring the Internet. Boston: Addison Wesley, 2001. 711p.
LUCHESI, Claudio Leonardo; Introduo criptografia computacional. Campinas: Ed.
Papirus/Unicamp, 1986.
117
LYNCH, Daniel C.; ROSE, Marshall T. Internet system handbook. Boston: Addison
Wesley, 1993.
MENEZES, A; OORSCHOT, P; VANSTONE, S. Handbook of applied cryptography.
Canada: CRC Press, 1997. 780p.
MINASI, Mark. Mastering Windows 2000 Server. 2.ed. San Francisco: Sybex, 2000.
1593p.
RATIONAL Software Corporation. Rational software , Cupertino, [1995]. Disponvel em:
<http://www.rational.com/support/documentation/>. Acesso em: 27 ago. 2002.
ROSE, Marshall T. The simple book: an introduction to Internet management. 2. ed.
Englewood Cliffs: Prentice-Hall, 1994. 456p.
SCHNEIER, Bruce. Applied cryptography: protocols, algorithms, and source code in C. 2.
ed. Canada: Wiley & Sons, 2001. 762p.
SNMP International Research Inc. SNMPv3 white paper, New York, [2001?]. Disponvel
em: <http://www.snmp.com/snmpv3/v3white.html>. Acesso em: 14 ago. 2002.
STALLINGS, William. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. 3. ed. Boston:
Addison Wesley, 2001. 628p.
SUN. Java tutorial, Palo Alto, [199-]. Disponvel em: <http://docs.sun.com/>. Acesso em: 14
ago. 2002.
TANENBAUM, Andrew S. Redes de computadores. 3. ed. Traduo nome do tradutor/a.
Rio de Janeiro: Campus, 1997.
W3C. Extensible Markup Language , Massachussets, [1996]. Disponvel em: <
http://www.w3.org/XML/>. Acesso em: 16 nov. 2002.
ZELTSERMAN, Dave. A practical guide to SNMPv3 and network management. Upper
Saddler River: Prentice Hall, 1999. 337p.

Uso Do SMNP V3

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uso Do SMNP V3

Enviado por

Direitos autorais:

Formatos disponíveis

i

UNIVERSIDADE REGIONAL DE BLUMENAU

PROTTIPO DE UM SISTEMA DE MONITORAMENTO DE

TRABALHO DE CONCLUSO DE CURSO SUBMETIDO UNIVERSIDADE

PROTTIPO DE UM SISTEMA DE MONITORAMENTO DE

ESTE TRABALHO DE CONCLUSO DE CURSO FOI JULGADO ADEQUADO

BACHAREL EM CINCIAS DA COMPUTAO

Prof. Francisco Adell Pricas Orientador na FURB

Prof. Jos Roque Voltolini da Silva Coordenador do TCC

Prof. Francisco Adell Pricas

OBJETIVOS DO TRABALHO ......................................................................................3

FUNDAMENTAO TERIC A.......................................................................5

BREVE HISTRICO DE REDES DE COMPUTADORES .................................................5

GERNCIA DE REDES DE COMPUTADORES..........................................13

ARQUITETURA DE UM SISTEMA DE GERENCIAMENTO DE REDES ......................... 16

SIMPLE NETWORK MANAGEMENT PROTOCOL..................................24

CONCEITOS BSICOS DE SNMP ............................................................................ 25

M OTOR SNMP V3.................................................................................................. 43

Gerente Snmp Tradicional.................................................................................... 47

REQUISITOS P RINCIPAIS DO P ROBLEMA A SER TRABALHADO ...............................88

REFERNCIAS BIBLIOGRFICAS................................................................................ 116

LISTA DE ABREVIATURAS E LISTA DE SIGLAS

1.1 OBJETIVOS DO TRABALHO

1.2 ESTRUTURA DO TRABALHO

2.1 BREVE HISTRICO DE REDES DE COMPUTADORES

2.2 REDES DE COMPUTADORES

assim como hardware e softwares por elas

USO DAS REDES DE COMPUTADORES

segundo Tanenbaum (1997): a escala e a tecnologia de transmisso.

FIGURA 1 Estrutura das camadas

FONTE: Adaptado de Tanenbaum (1997, pg. 39).

Como se v, na verdade os dados no so diretamente transmitidos da camada n de

FONTE: Adaptado de Tanenbaum (1997, pg. 33).

3 GERNCIA DE REDES DE COMPUTADORES

corretiva enquanto que a gerncia de desempenho quase sempre preventiva;

3.1 ARQUITETURA DE UM SISTEMA DE GERENCIAMENTO

FONTE: Adaptado de Stallings (2001, pg. 8).

Outros ns na rede que fazem parte do sistema de gerenciamento de redes incluem

Ar quit etur a de um a e nti da de pr ox y

FONTE: Adaptado de Stallings (2001, pg. 15).

Quando um agente atua como um proxy , ele age em benefcio de um ou mais ns da

3.2 GERENCIAMENTO DE DESEMPENHO

FUNO DE MONITORAMENTO DE DESEMPENHO

4 SIMPLE NETWORK MANAGEMENT PROTOCOL

4.1 CONCEITOS BSICOS DE SNMP

pelos seguintes elementos:

FONTE: Adaptado de Stallings (2001, pg. 81).

SMI STRUCTURE OF MANAGEMENT INFORMATION

SNMP um banco de dados contendo informaes sobre os elementos gerenciados. Tanto no

Para Stallings (2001), todos os objetos gerenciados no ambiente SNMP esto

FONTE: Adaptado de Stallings (2001, pg. 82).

Como mostra a figura 6, o SMI define quatro ns abaixo do n internet:

Para o desenvolvimento do prottipo, sero utilizados alguns dos objetos escalares

Para Lynch (1993), na camada de aplicao as estruturas de dados trocadas pelas

Os objetos na MIB so codificados usando regras bsicas de codificao (Basic

TRAP -DIRECTED POLLING

da rede so coletadas e armazenadas por agentes e disponibilizadas para um ou mais sistemas

P r oto c o los dep . d e re d e

FONTE: Adaptado de Stallings (2001, pg. 82).

COMPARATIVO ENTRE AS VERSES SNMP

International Research (2001), consiste de trs documentos:

fundamentalmente similar chamado controle de acesso baseado em vises.

CONSIDERAES FINAIS SOBRE O SNMP