Microsoft Word - TCC-Grasielli Barreto Redes Uel 2007
87
Click here to load reader
Transcript of Microsoft Word - TCC-Grasielli Barreto Redes Uel 2007
GRASIELLI BARRETO
FERRAMENTAS DE GERÊNCIA DE REDES
LONDRINA - PARANÁ 2008
GRASIELLI BARRETO
FERRAMENTAS DE GERÊNCIA DE REDES
Monografia apresentada ao Curso de Especialização em Redes de Computadores e Comunicação de Dados, Departamento de Computação da Universidade Estadual de Londrina, como requisito parcial para a obtenção do título de Especialista, sob orientação do Prof. Dr. Mario Lemes Proença Jr.
LONDRINA - PARANÁ 2008
Barreto, Grasielli Ferramentas de gerência de redes – protocolo SNMP / Barreto. -- Londrina: UEL / Universidade Estadual de Londrina, 2007.
Orientador: Mario Lemes Proença Jr. Dissertação (Especialização) – UEL / Universidade de Londrina, 2008. Referências bibliográficas: f. 77-77
1. Gerência de Redes. 2. SNMP. 3. Ferramentas de Gerenciamento.
GRASIELLI BARRETO
FERRAMENTAS DE GERÊNCIA DE REDES
Esta monografia foi julgada adequada para obtenção do título de Especialista, e
aprovada em sua forma final pela Coordenação do Curso de Especialização em
Redes de Computadores e Comunicação de Dados, do Departamento de
Computação da Universidade Estadual de Londrina.
Banca Examinadora:
____________________________________________
Prof. Dr. Mario Lemes Proença Jr Universidade Estadual de Londrina
____________________________________________ Prof. Msc. Elieser Botelho Manhas
Universidade Estadual de Londrina
____________________________________________ Prof. Msc. Fabio Sakuray
Universidade Estadual de Londrina
Londrina, 12 Maio de 2008.
A Deus,
“Pelas oportunidades dadas.”
A Minha Família.
“Pela força e incentivo.”
AGRADECIMENTOS
Agradeço ao meu esposo pela compreensão e incentivo, nesta jornada.
RESUMO
Procurou-se neste trabalho abordar, de forma sucinta, os principais aspectos e características inerentes à área de Gerenciamento de Redes, de significativa importância, tendo em vista que os sistemas informatizados são imprescindíveis nos mais diferentes processos utilizados pelo Homem neste mundo globalizado. Neste contexto, inicia-se pelo modelo FCAPS (Fault, Configuration, Accounting, Performance, Security), implementado pela ISO, e que evidencia as áreas funcionais do gerenciamento de redes e, também, aborda-se as particularidades da gerencia de redes TCP/IP, sua arquitetura, estações, agentes, MIB (Management Information Base) e SMI (Structure of Management
Information). Em continuidade discorre-se sobre o protocolo SNMP – Simple Network
Management Protocol, amplamente utilizado, mostrando suas características, funcionalidades e recursos e, também, comentando sua evolução por meio das versões SNMPv2 e SNMPv3 (operações suportadas, limitações, formatos, funções criptográficas, etc.) incluindo o RMON (Remote Network Monitoring) que é uma evolução do SNMP e possibilita um gerenciamento proativo da rede. Encerra-se com a apresentação de algumas das ferramentas mais utilizadas na gerencia de redes - algumas do tipo open source e outras proprietárias – enfatizando-se seus principais recursos, pois as mesmas são imprescindíveis para se obter o desempenho ótimo - com qualidade e confiabilidade – na questão do gerenciamento de redes.
ABSTRACT
It was addressed in this work, briefly, the main aspects and characteristics inherent in the area of Network Management of significant importance in view that the systems are indispensable in many different processes used by humans in this globalised world. In this context, it is initiated by the model FCAPS (Fault, Configuration, Accounting, Performance, Security), implemented by ISO, which highlights the functional areas of management of networks and also addresses to the particularities of management of networks TCP / IP, its architecture, stations, agents, MIB (Management Information Base), and SMI (Structure of Management Information). In continuing talks on the protocol SNMP - Simple Network Management Protocol, widely used, showing its features, functions and resources and, also, commenting on its evolution through the versions SNMPv2 and SNMPv3 (borne operations, limitations, formats, cryptographic functions, etc.). including RMON (Remote Monitoring Network) which is an evolution of SNMP and enables a proactive management of the network. It closes with the presentation of some of the most used tools in the management of networks - some type of open source and other proprietary - is emphasizing its main features because they are essential to obtain the optimum performance - with quality and reliability -- the issue of managing networks.
SUMÁRIO
RESUMO.......................................................................................................................................................... I
ABSTRACT.....................................................................................................................................................II
LISTA DE TABELAS .................................................................................................................................. VI
LISTA DE ABREVIATURAS ....................................................................................................................VII
1 INTRODUÇÃO.............................................................................................................................................1
2 ÁREAS DE GERENCIAMENTO FCAPS .................................................................................................2
2.1 GERENCIAMENTO DE FALHAS ........................................................................................................2 2.2 GERENCIAMENTO DE CONFIGURAÇÃO ........................................................................................3 2.3 GERENCIAMENTO DE CONTABILIZAÇÃO.....................................................................................4 2.4 GERENCIAMENTO DE PERFORMANCE ..........................................................................................4 2.5 GERENCIAMENTO DE SEGURANÇA................................................................................................4
3 GERÊNCIA DE REDES TCP/IP ................................................................................................................6
3.1 NORMAS RELACIONADAS AO SNMP......................................................................................7 3.2 ARQUITETURA DE GERENCIAMENTO DE REDES................................................................7
3.2.1 Estação de gerenciamento...............................................................................................................8 3.2.2 Agente de gerenciamento.................................................................................................................8 3.2.3 Protocolo de gerenciamento de redes .............................................................................................8
3.3 ARQUITETURA DO PROTOCOLO DE GERENCIAMENTO DE REDES.................................9 3.4 ESTRUTURA DA INFORMAÇÃO DE GERENCIAMENTO (SMI) ...........................................9 3.5 MANAGEMENT INFORMATION BASE (MIB) .......................................................................10
4 O PROTOCOLO SNMP V1 ......................................................................................................................13
4.1 OPERAÇÕES SUPORTADAS PELO SNMPV1 ..................................................................................13 4.2 COMUNIDADES E NOMES DE COMUNIDADES ...........................................................................13 4.3 ESPECIFICAÇÕES DO PROTOCOLO ...............................................................................................14
4.3.1 Formato SNMP..............................................................................................................................14 4.3.1.1 Transmissão de uma Mensagem SNMP......................................................................................15 4.3.1.2 Recepção de uma Mensagem SNMP ..........................................................................................16 4.3.2 GetRequest PDU ...........................................................................................................................17 4.3.3 GetNextRequest PDU ....................................................................................................................18 4.3.4 SetRequest PDU ............................................................................................................................19 4.3.5 Trap PDU ......................................................................................................................................19
4.4 LIMITAÇÕES DO SNMP.....................................................................................................................19
5 PROTOCOLO SNMP V2...........................................................................................................................20
5.1 OPERAÇOES SUPORTADAS PELO SNMPV2 ..................................................................................20 5.1.1 Transmissão de uma mensagem SNMPv2 .....................................................................................21 5.1.2 Recepção de uma mensagem SNMPv2 ..........................................................................................21 5.1.3 GetRequest PDU ...........................................................................................................................23 5.1.4 GetNextRequest PDU ....................................................................................................................24 5.1.5 GetBulkRequest PDU ....................................................................................................................24 5.1.6 SetRequest PDU ............................................................................................................................24 5.1.7 Trap PDU ......................................................................................................................................25 5.1.8 InformRequest PDU ......................................................................................................................25
6 O PROTOCOLO SNMP V3 ......................................................................................................................26
6.1 ARQUITETURA SNMPV3...................................................................................................................26 6.1.1 Entidades SNMP............................................................................................................................26 6.1.1.1 Gerente SNMP tradicional .........................................................................................................27 6.1.1.2 Agente SNMP tradicional ...........................................................................................................29
6.2 APLICAÇÕES SNMP...........................................................................................................................30 6.3 FORMATO DA MENSAGEN SNMPV3..............................................................................................31 6.4 ALGORITMOS CRIPTOGRÁFICOS USADOS PELO SNMPV3 .......................................................32
6.4.1. User-Based Security Model – USM..............................................................................................32 6.4.1.1 Autenticação ...............................................................................................................................32 6.4.1.2 Encriptação ................................................................................................................................33 6.4.1.3 Processamento de mensagens USM ...........................................................................................34 6.4.1.4 Processo de descoberta ..............................................................................................................39 6.4.1.5 Gerenciamento de chaves ...........................................................................................................39 6.4.2 View-Based Access Control Model – VACM.................................................................................43 6.4.2.1 Processamento de controle de acesso ........................................................................................45 6.4.2.2 A MIB VACM..............................................................................................................................48
7. MONITORAMENTO REMOTO DE REDES (RMON)........................................................................49
7.1 CONTROLE DE MONITORES REMOTOS........................................................................................49 7.1.1 Múltiplos gerentes .........................................................................................................................50 7.1.2 Gerência de Tabela .......................................................................................................................50 7.1.3 MIB RMON....................................................................................................................................51
7.2 RMON 2 ................................................................................................................................................52 7.2.1 Nível de Rede.................................................................................................................................52 7.2.2 Nível de Aplicação.........................................................................................................................53 7.2.3 MIB RMON2..................................................................................................................................53
8. FERRAMENTAS PARA GERENCIAMENTO DE REDES.................................................................55
8.1 HP OPENVIEW .....................................................................................................................................55 8.1.1 Gerenciamento de Falhas..............................................................................................................55 8.1.2 Gerenciamento de Configuração...................................................................................................56 8.1.3Gerenciamento de Performance .....................................................................................................57
8.2 CISCO WORKS .....................................................................................................................................58 8.2.1 Gerenciamento de Falhas..............................................................................................................59 8.2.2 Gerenciamento de Configuração...................................................................................................59 8.2.3 Gerenciamento de Contabilização ................................................................................................59 8.2.4 Gerenciamento de Performance ....................................................................................................60 8.2.5 Gerenciamento de Segurança........................................................................................................60
8.3 NAGIOS................................................................................................................................................61 8.3.1 Gerenciamento de Falhas..............................................................................................................62 8.3.2 Gerenciamento de Performance ....................................................................................................63 8.3.3 Gerenciamento de Configuração...................................................................................................63
8.4 TIVOLI NETVIEW...............................................................................................................................64 8.4.1 Arquitetura de Gerenciamento Distribuído...................................................................................65 8.4.2 Gerenciamento De Falha ..............................................................................................................66 8.4.3 Gerenciamento de Configuração...................................................................................................68 8.4.4 Gerenciamento de Desempenho ....................................................................................................69 8.4.5 Gerenciamento da Segurança........................................................................................................70
9 CONCLUSÃO .............................................................................................................................................75
BIBLIOGRAFIA............................................................................................................................................76
LISTA DE FIGURAS
Figura 3.1 MIB-II grupos.................................................................................................................................12 Figura 4.1 Formatos SNMP .............................................................................................................................14 Figura 4.2 Seqüência de PDU SNMP ..............................................................................................................17 Figura 5.1 - Formato PDU SNMPv2................................................................................................................22 Figura 5.2 - Estrutura da mensagem.................................................................................................................22 Figura 5.3 - Seqüência de PDU SNMP ............................................................................................................23 Figura 6.1 - Entidade SNMP (RFC 2271)........................................................................................................27 Figura 6.2 - Gerente SNMPv3 tradicional .......................................................................................................29 Figura 6.3 - Agente SNMPv3 Tradicional .......................................................................................................30 Figura 6.4 - Formato da mensagem SNMPv3..................................................................................................31 Figura 6.5 - Processamento da mensagem USM: transmissão.........................................................................35 Figura 6.6 - Processamento da mensagem USM: recepção. ............................................................................36 Figura 6.7 - Localização de chave....................................................................................................................42 Figura 6.8 - Lógica VACM..............................................................................................................................45 Figura 6.9 - Fluxograma VACM......................................................................................................................47 Figura 7.1 - Grupos MIB RMON.....................................................................................................................52 Figura 7.2 - Relação OSI X RMON.................................................................................................................53 Figura 7.3 - RMON MIB .................................................................................................................................54 Figura 8.1 – Tela Service Desk – Gerência de Falhas ......................................................................................56 Figura 8.2 - Tela Segment - Gerencia de Configuração ...................................................................................57 Figura 8.3 – Tela Operations Gerência de Performance..................................................................................58 Figura 8.4 - Tela Alert History Gerência de Falhas..........................................................................................62 Figura 8.5 Tela Performance Information - Gerência de Performance............................................................63 Figura 8.6 - Tela Configuration Gerência de Configuração.............................................................................64 Figura 8.7 - Arquitetura do gerenciamento distribuído Tivoli .........................................................................66 Figura 8.8 - Tela de Controle de Eventos.........................................................................................................67 Figura 8.9 – Tela Correlação de Conjunto de Regras ......................................................................................68 Figura 8.10 – Tela Mapa de topologia de rede.................................................................................................69
LISTA DE TABELAS
Tabela 4.1 Mensagens SNMP........................................................................................................... 15
Tabela 8.1 Comparativo de Recursos de Cada Ferramenta............................................................... 74
LISTA DE ABREVIATURAS
ASN.1 - Abstract Syntax Notation One
BER - Basic Encoding Rules
CMIP - Common Management Information Protocol
CMOT - Common Management Information Protocol over TCP/IP
CBC - Cipher Block Chaining
CORBA - Common Object Request Broker Architecture
CRC - Cyclic Redundancy Checks
CWRW – Routed WAN Management
DES - Data Encryption Standard
DNS - Domain Name System
ESP - Encapsulated Security Payload
FCAPS - Fault, Configuration, Accounting, Performance, Security
FTP - File Transfer Protocol
HEMS - High-Level Entity Management System
HMAC - Hash Message Authentication Code
HMP -Host Monitoring Protocol
HTTP - Hipertext Transfer Protocol
IAB - Internet Arquiteture board
ICMP - Internet Control Message Protocol
IETF - Internet Engineering Task Force
IP - Internet Protocol
ISO - International Standards Organization
LAN - Local Area Network
LMS – LAN Management Solution
MAC - Message Authentication Code
MD5 - Message-digest 5
MIB - Management Information Base
MLM – Mid-Level Manager
NMS - Network Management Station
OSI - Open Systems Interconnection
PDU - Protocol Data Unit
PING - Packet Internet Groper
POP3 - The Post Office Protocol - Version 3
QoS - Quality of Service
RFC - Request For Comment
RMON - Remote Networking Monitoring
SGMP - Simple Gateway Monitoring Protocol
SHA-1 - Secure Hash Algorithm 1
SLA – Supplemental License Agreement
SMI - Structure of Management Information
SMS - Short Message Service
SMTP - Simple Mail Transfer Protocol
SNMP - Simple Network Management Protocol
SQL - Structured Query Language
SSH - Secure Shell
SSL - Secure Sockets Layer
TCP - Transmission Control Protocol
UDP - User Datagram Protocol
USM - User Base Security Model
VACM - View-Based Access Control Model
VMS – Security Management Solution
XML - Extensible Markup Language
XOR - Xtended OR
WAN - Wide Area Network
WWW - World Wide Web Xtended OR
1
1 INTRODUÇÃO
Inicialmente podia-se dizer que o gerenciamento de redes resumia-se em
monitorar e configurar um dispositivo de redes, por meio do Login remoto, mas, devido ao
impressionante crescimento do uso de computadores interligados por redes nos diversos
processos empregados pela sociedade, tornou-se imprescindível a implementação de
complexos Sistemas de Gerência de Redes.
O Simple Network Management Protocol (SNMP) é o protocolo mais
amplamente utilizado para soluções de gerenciamento de redes TCP/IP por ser, um padrão
aberto e suficientemente simples e flexível para gerenciar diferentes tipos de dispositivos,
em um ambiente de rede distribuída. Mesmo com essas características benéficas o SNMP
teve mais duas versões: o SNMPv2 que tratava de comunidade, mas, sem melhorias no
aspecto segurança de redes, razão pela qual foi elaborada e implementada a versão 3 ou
SNMPv3 que supriu esta lacuna. Com a criação do RMON e RMON II tornou-se possível
monitorar as subredes otimizando o gerenciamento da rede. O RMON recolhe novos tipos
de informação, assim como alguns tipos de eventos já ocorridos, possibilitando o
gerenciamento até a camada de aplicação.
O controle e gerenciamento eficaz das redes modernas é uma tarefa desafiadora
devido à complexidade e diversidade dos dispositivos conectados. A padronização da
estratégia de gerenciamento é uma necessidade para permitir uma bem sucedida
administração dos recursos das redes.
Com o objetivo de facilitar a compreensão estruturou-se este TCC em sete
itens, além desta introdução e conclusão, onde se abordou: O sistema de gerenciamento
FCAPS (item 2) que é a referência; a Gerência de Redes IP (item 3) onde se discorre sobre
as normas relacionadas ao SNMP e a arquitetura de gerenciamento de redes; O protocolo
SNMPv1 (item 4) o qual é considerado o coração do gerenciamento de redes; Os
protocolos SNMPv2 e SNMPv3 (itens 5 e 6) versões otimizadas da versão inicial; O
monitoramento remoto de redes RMON (item 7) que trata da comunicação entre gerentes e
agentes SNMP e, encerrando, as ferramentas para gerenciamento (item 8) onde se
apresenta algumas das mais importantes ferramentas e seus principais recursos.
2
2 ÁREAS DE GERENCIAMENTO FCAPS
Sistemas de gerenciamento de redes empregam várias ferramentas, aplicações e
dispositivos para a monitoração e manutenção das mesmas. Neste contexto, a estrutura
mais utilizada e a FCAPS padronizado pela ISO (International Standards Organization e
cuja idéia básica é a de concentrar todas as informações que envolvem um sistema de
gerenciamento, em um conjunto de cinco áreas funcionais, a saber):
1. Fault (Falhas);
2. Configuration (Configuração);
3. Accounting (Contabilização);
4. Performance (Performance); e
5. Security (Segurança).
Embora essa padronização funcional esteja voltada para o modelo OSI (Open
Systems Interconnection), das sete camadas, houve grande aceitação por parte dos
fabricantes de equipamentos de redes proprietárias e proporcionou uma forma útil e eficaz
de organizar os requisitos.
2.1 GERENCIAMENTO DE FALHAS
O funcionamento adequado e confiável de uma rede complexa só é possível
com a monitoração do sistema como um todo e, individualmente, de cada equipamento da
rede, objetivando acompanhar e garantir o perfeito desempenho da mesma. No momento
da ocorrência de falhas é importante a seguinte seqüência de ações:
� Determinar onde ocorreu a falha;
� Isolar o restante da rede, para que não seja afetada e possa continuar operando sem
interferência devido àquela falha;
� Reparar ou substituir os componentes sob falha, permitindo a restauração da rede no
estado inicial; e
� Reconfigurar ou modificar a rede de tal forma que minimize o impacto da sua
operação sem os componentes com falha.
Para a definição do que é uma falha primeiramente é necessário distinguir o que
são falhas e o que são erros; neste contexto considera-se “falha’ como uma condição
3
anormal que requer atenção de gerenciamento (ou ação) para o seu reparo, enquanto que
“erro” é um evento simples. Exemplo:
Falha → uma linha de comunicação fisicamente cortada onde nenhum sinal pode ser
transmitido;
Erro → perda de pacotes ou quadros.
Um sistema de gerenciamento de falhas eficaz deve possibilitar o diagnóstico e
a forma de isolar a falha e, para tanto, o sistema deve realizar os seguintes testes [1]:
� Teste da conectividade;
� Teste da integridade de dados;
� Teste da integridade do protocolo;
� Teste da saturação dos dados;
� Teste da saturação da conexão;
� Teste do tempo de resposta;
� Teste de laço de retorno;
� Teste funcional; e
� Teste de diagnóstico.
Devido a sua importância dentre as demais áreas de gerenciamento de redes, o
gerenciamento de falhas talvez seja o que mais necessite de atenção e acompanhamento.
2.2 GERENCIAMENTO DE CONFIGURAÇÃO
O gerenciamento de configuração envolve a iniciação, a manutenção e o
encerramento de cada um dos componentes e subsistemas dentro da configuração da rede e
caracteriza-se por poder dar início ao processo, identificando e especificando as
características dos componentes e recursos que compõem a rede; o mesmo inclui as
seguintes funções:
� Definir informação configuração;
� Definir e modificar valores atributo;
� Definir e modificar relações;
� Inicializar e encerrar as operações da rede;
� Distribuir o software;
� Analisar os valores e relacionamento; e
� Relatar o status da configuração.
4
2.3 GERENCIAMENTO DE CONTABILIZAÇÃO
O gerenciamento de contabilização tem como atribuição, manter o pleno
controle quanto ao uso dos recursos de rede e, para isso, utiliza-se das seguintes funções:
� Coletar informações de utilização, monitorando quais recursos e quantos desses
recursos estão sendo utilizados por qual componente da rede;
� Estabelecer quotas de utilização com limites de uso de recursos, por usuários ou
grupos de usuários;
� Estabelecer escalas de utilização, que podem também servir apenas para estatísticas;
� Aplicação das tarifas e faturamento, ou seja, os gastos obtidos com cada recurso.
2.4 GERENCIAMENTO DE PERFORMANCE
O gerenciamento de performance tem como incumbência monitorar as
atividades da rede de forma que se possa analisar o seu desempenho e, basicamente,
engloba três componentes:
� Avaliação por meio de estatísticas sobre o tráfego da rede;
� Análise de desempenho, obtida por meio de um software desenvolvido para reduzir a
apresentação dos dados; e
� Síntese da geração de tráfego, a qual permite observar o desempenho da rede no
âmbito de carga total.
2.5 GERENCIAMENTO DE SEGURANÇA
O gerenciamento de segurança garante o uso legítimo dos recursos da rede,
preservando a confidencialidade, integridade dos dados e a fiscalização; suas funções
podem ser agrupadas em três categorias [1]:
� Manter informações de segurança, compreendendo:
Documentar eventos;
Monitorar pistas da auditoria de segurança;
Monitorar a utilização e os usuários dos recursos relacionados à segurança;
Relatar violações de segurança;
Receber notificações de violações de segurança;
Manutenção e análise dos registros de segurança;
5
Manter cópias backup para todos ou parte dos arquivos relacionados à segurança;
Manutenção geral dos perfis de usuários da rede, e perfis empregados para recursos
específicos, a fim de permitir referencias para conformidade dos perfis de segurança
planejados.
� Controle de recursos de serviços de acesso, abrangendo:
Códigos de segurança;
Fonte de roteamento e informação da gravação da rota;
Diretórios;
Tabelas de roteamento;
Níveis do limiar de disparo de alarmes; e
Tabelas de Contabilização.
� Controle do processo de criptografia
O gerenciamento de segurança deve ser capaz de criptografar qualquer troca
entre gerentes e agentes, conforme necessário. Além disso, o gerenciamento de segurança
poderá facilitar o uso de criptografia por outras entidades de rede. Esta função é também
responsável pelo planejamento dos algoritmos de criptografia e provimento ou suprimento
para a distribuição de chaves.
6
3 GERÊNCIA DE REDES TCP/IP
Concomitantemente com o desenvolvimento do protocolo TCP/IP surgiram as
primeiras idéias sobre o gerenciamento de redes cabendo destacar que até o final dos anos
70 não existiam protocolos de gerenciamento. A única ferramenta efetivamente usada para
gerenciamento era o Internet Control Message Protocol (ICMP), o qual provê uma
maneira para transferência de mensagens de controle de roteadores e outros hosts para um
host, para obter uma resposta sobre problemas no ambiente. Sob o ponto de vista do
gerenciamento de rede, o recurso mais usado do ICMP é o par de mensagem echo/echo-
replay as quais provêem um mecanismo para testar se existe comunicação ativa entre
entidades. Essas mensagens ICMP podem ser usadas - com várias opções de cabeçalho tais
como roteamento do código de origem e registro da rota - para desenvolver simples, mas
poderosas ferramentas de gerenciamento. O mais notável exemplo disso é o amplamente
usado comando PING (Packet Internet Groper).
O marco inicial em criar uma ferramenta especifica para gerenciamento de
redes foi o SGMP (Simple Gateway Monitoring Protocol), em novembro de 1987, o qual
propiciava o monitoramento de um gateway. Ante a crescente necessidade de se criar uma
ferramenta de gerenciamento geral, três propostas estavam se destacando:
� HEMS (High-Level Entity Management System): este foi , talvez, o primeiro protocolo
de gerenciamento de rede usado na internet, o protocolo de monitoramento de host
(HMP - Host Monitoring Protocol).
� SNMP (Simple Network Management Protocol): este foi uma versão avançada do
SGMP.
� CMIP sobre TCP/IP (CMOT): Esta foi uma tentativa de incorporar, para a máxima
extensão possível, o protocolo (protocolo de informação de gerenciamento comum),
serviços e estrutura de dados sendo padronizados pela ISO para o gerenciamento de
redes.
No inicio de 1988 a IAB (Internet Architecture Board), avaliando estas
propostas, concluiu pelo desenvolvimento do SNMP como uma solução de curto prazo e o
CMOT como uma solução de longo prazo [1]. Tal decisão partia da premissa que dentro de
um razoável período de tempo, instalações em TCP/IP poderiam migrar para protocolos
baseados em OSI. Portanto, houve uma natural relutância em se investir recursos em
7
protocolos de nível de aplicação e serviços sobre TCP/IP os quais poderiam muito cedo ser
abandonados. De modo a obter necessidades imediatas, o SNMP poderia ser rapidamente
desenvolvido para prover alguma ferramenta de gerenciamento básico e suporte para
desenvolvimento de uma experiência básica para executar gerenciamento de rede.
Para incrementar e solidificar esta estratégia a IAB determinou que, tanto o
SNMP como o CMOT, usasse a mesma base de dados de objetos gerenciados. Portanto,
somente uma única estrutura de gerenciamento de informação (SMI: as convenções básicas
para formatação de objetos) e uma única base de gerenciamento de informação (MIB: a
atual estrutura, ou esquema, de base de dados) poderiam ser definidas para ambos os
protocolos. Porém, logo se tornou evidente que esta fusão dos dois protocolos para nível de
objeto era impraticável tendo em vista que, no gerenciamento de rede OSI, objetos
gerenciados são vistos como sofisticadas entidades com atributos, procedimentos
associados e notificação de capacidades e outras complexas características associadas com
tecnologia orientada ao objeto. Como o SNMP não foi projetado para trabalhar com tais
conceitos sofisticados, a IAB recuou em sua determinação de um SMI/MIB comum e
permitiu o desenvolvimento do SNMP e do CMOT, de forma independente e em paralelo.
3.1 NORMAS RELACIONADAS AO SNMP
Na definição do SNMP são considerados três fundamentos específicos:
• Estrutura e Identificação do Gerenciamento de Informação para o TCP/ IP baseado
em redes (RFC1155): descreve como objetos gerenciados, contidos na MIB, são
definidos.
• Base de Gerenciamento de Informação para o gerenciamento de redes TCP / IP
baseadas em internet - MIB-II (RFC1213): descreve os objetos gerenciados
contidos na MIB.
• Simple Network Management Protocol (RFC1157): define o protocolo usado para
gerenciar esses objetos.
3.2 ARQUITETURA DE GERENCIAMENTO DE REDES
O modelo de gerenciamento para redes TCP/IP, inclui os seguintes elementos.
� Estação de gerenciamento;
8
� Agente de gerenciamento;
� Base de informações gerenciais (MIB); e
� Protocolo de gerenciamento de redes.
3.2.1 Estação de gerenciamento
A estação de gerenciamento serve como interface entre o homem (gerente) e o
sistema de gerenciamento de rede.
� Um conjunto de aplicações de gerenciamento para análise de dados, recuperação de
falhas, etc.
� Uma interface pela qual o gerente de rede pode monitorar e controlar a rede
� A capacidade de traduzir as exigências do gerente da rede no próprio acompanhamento
e controle remoto de elementos da rede.
� Um banco de dados de informações extraídas das MIBs de gerenciamento de todas os
elementos da rede.
Apenas os últimos elementos são objetos de padronização SNMP.
3.2.2 Agente de gerenciamento
Alguns componentes importantes da rede tais como roteadores, pontes, hubs e
estação de trabalho, podem ser equipados com um agente SNMP para que possam ser
gerenciados pela estação de gerenciamento. O agente de gerenciamento responde a pedidos
de informações e ações a partir da estação de gerenciamento e pode assincronicamente
prover importantes informações que não foram solicitadas.
3.2.3 Protocolo de gerenciamento de redes
Uma estação de gerenciamento e os agentes estão ligados por um protocolo de
gerenciamento de redes TCP/IP denominado SNMP (Simple Network Management
Protocol), o qual possui as seguintes capacidades principais:
� Get: permite a estação gerenciamento recuperar o valor dos objetos do agente;
� Set: permite a estação gerenciamento definir o valor dos objetos do agente; e
9
� Trap: permite a um agente notificar a estação de gerenciamento quando da ocorrência
de eventos significativos.
3.3 ARQUITETURA DO PROTOCOLO DE GERENCIAMENTO DE
REDES
O SNMP foi projetado para ser um protocolo do nível, aplicação, que é parte do
protocolo TCP/IP e funcionar sobre o protocolo UDP (User Datagrama Protocol). Para
uma estação de gerenciamento individual, um gerente de processo controla o acesso de
uma central MIB para a estação de gerenciamento e fornece uma interface para o gerente
da rede. O gerente realiza o processo de gerenciamento utilizando o SNMP. A partir de
uma estação de gerenciamento três tipos de mensagens SNMP são emitidas em nome de
uma aplicação de gerenciamento: GetRequest, GetNextRequest, e SetRequest. As duas
primeiras são variações da função get e todas as três mensagens são reconhecidas pelo
agente na forma de uma mensagem GetResponse, que é transmitida até o gerenciamento de
aplicação. Além disso, um agente pode emitir uma mensagem trap em resposta a um
evento que afeta a MIB e recursos gerenciados subjacentes. O SNMP é um protocolo não
orientado à conexão, pois nenhuma conexão é mantida entre a estação de gerenciamento e
o agente, e por isso o SNMP trabalha sobre UDP.
3.4 ESTRUTURA DA INFORMAÇÃO DE GERENCIAMENTO (SMI)
A estrutura SMI, define o quadro geral dentro do qual a MIB pode ser definida
e construída. A SMI identifica os tipos de dados que podem ser utilizados na MIB e
especifica como recursos dentro da MIB são representados e nomeados. A filosofia por trás
da SMI é incentivar a simplicidade e a flexibilidade dentro da MIB. Portanto, a MIB pode
armazenar somente tipos de dados simples: escalares e escalares bidimensional. A SMI não
suporta a criação ou recuperação de complexas estruturas de dados. Esta filosofia está em
contraste com o que foi utilizado com gerenciamento OSI, o qual provê complexas
estruturas de dados e recuperação modos de apoiar uma maior funcionalidade.
A SMI evita tipos de dados complexos buscando simplificar a tarefa de
execução e, também, aumentar a interoperabilidade. MIBs conterão inevitavelmente tipos
10
de dados criados pelos fabricantes e, salvo se fortes restrições sejam colocadas sobre a
definição de tais tipos de dados, a interoperabilidade será comprometida.
Com o objetivo de padronizar a representação das informações de
gerenciamento, uma estrutura SMI deve [1]:
� Prover uma técnica padronizada para definir a estrutura de uma determinada MIB;
� Prover uma técnica padronizada para definir objetos individuais, incluindo a sintaxe e
o valor de cada objeto; e
� Prover uma técnica padronizada de codificação valores de objeto.
3.5 MANAGEMENT INFORMATION BASE (MIB)
Os recursos da rede a serem gerenciados podem ser representados como objetos
onde um conjunto de objetos é denominado de Management Information Base (MIB). A
MIB funciona como vários pontos de acesso, estes objetos são padronizados por classe Ex:
uma classe de determinado objeto gerencia varias pontes.
Todos os objetos gerenciados no ambiente SNMP são organizados de maneira hierárquica
ou estrutura de árvore. Os objetos que compõem a árvore são os atuais objetos gerenciados,
cada um dos quais representa algum recurso, atividade, ou informações relacionadas, que
devem ser gerenciadas. A própria estrutura da árvore define um conjunto de objetos
relacionados de maneira lógica.
Associados com cada tipo de objeto em cada MIB há um identificador do tipo
ASN.1 OBJECT IDENTIFIER, o qual serve para nomear o objeto. Além disso, uma vez
que o valor associado ao tipo OBJECT IDENTIFIER é hierarquizada, a convenção também
serve para identificar a estrutura dos tipos de objeto.
O OBJECT IDENTIFIER é um identificador único para um determinado tipo de
objeto. Seu valor consiste de uma seqüência de inteiros. O conjunto de objetos definido
tem uma estrutura árvore, com a raiz da árvore a ser o objeto referindo-se à norma ASN.1.
Começando com a raiz da árvore OBJECT IDENTIFIER, cada valor componente do
OBJECT IDENTIFIER identifica um arco na árvore. A partir da raiz, existem três nós no
primeiro nível: iso, ccitt e joint-iso-ccitt. Sob o nó iso, uma sub árvore é para utilização de
outras organizações, uma das quais é Departamento de Defesa dos Estados Unidos (dod).
RFC 1155 assume que uma sub árvore dod será alocada para administração pela Câmara
de Atividades da Internet como se segue:
11
Internet OBJECT IDENTFIER:: = {iso (1) org (3) dod (6) 1}
Isto é ilustrado na figura 3.1, portanto, o nó internet tem o valor do OBJECT
IDENTIFIER de 1.3.6.1. Este valor serve como o prefixo para os nós no próximo nível
inferior da árvore.
Como mostrado, o documento SMI define quatro nós sob o nó internet, a saber:
� directory: reservado para uso futuro com o diretório OSI (X.500);
� mgmt: usado para objetos definidos nos documentos aprovados pela IAB;
� experimental: usado para identificar objetos utilizados no experimentos da Internet; e
� private: usado para identificar objetos definidos unilateralmente.
A sub árvore mgmt contém as definições das bases de informações de
gerenciamento que tenham sido aprovadas pelo IAB. Atualmente, duas versões da MIB
foram desenvolvidas, mib-1 e mib-2, sendo que esta última é uma extensão da primeira e
ambas foram providas como o mesmo object identifier na sub árvore desde que apenas
uma das MIBs esteja presente em qualquer configuração.
Objetos adicionais podem ser definidos para um MIB em uma das três
maneiras:
1 – Uma sub árvore mib-2 pode ser completamente expandida ou substituída por uma nova
revisão (presumivelmente mib-3). Para expandir mib-2, uma nova subárvore é definida.
2-Uma MIB experimental pode ser construída para uma aplicação particular. Tais objetos
poderão subseqüentemente ser movidos para a sub árvore mgmt.
3- Extensões privadas pode ser adicionadas à sub árvore private.
A subárvore private correntemente tem apenas um nó filho definido, o nó
enterprises. Esta parte da subárvore é usada para permitir aos fabricantes melhorar o
gerenciamento de seus dispositivos e compartilhar essas informações com outros usuários
e fabricantes que possam ter necessidade de interoperar com os seus sistemas. Um ramo
dentro da subárvore enterprise é alocado para cada fabricante que registre para uma
enterprise object identifier.
A divisão do nó internet em quatro subárvores fornece uma forte base para a
evolução das MIBs. Como fabricantes e outros implementadores de experimentos com
novos objetos, que estão em vigor ganhando uma boa oportunidade de praticar know-how
antes que estes objetos sejam aceitos como parte das especificações padronizadas (mgmt).
Portanto, a MIB é utilizada imediatamente para o gerenciamento de objetos que se
enquadram dentro da porção padronizada da MIB e suficientemente flexível para se
12
adaptar à evolução da tecnologia e dos produtos oferecidos. Este caráter revolucionário
mostra que todos esses protocolos sofreram extenso uso experimental e depuração antes de
ser finalizado como protocolos padrões.
Figura 3.1 MIB-II grupos
13
4 O PROTOCOLO SNMP V1
O protocolo SNMP V1 é considerado o coração do gerenciamento de redes e
suas especificações encontram-se descritas na RFC 1157 de maio de 1990.
4.1 OPERAÇÕES SUPORTADAS PELO SNMPv1
As únicas operações que são suportadas em SNMP são a alteração e inspeção
de variáveis. Especificamente, três operações comuns podem ser realizadas:
� Get: uma estação de gerenciamento recupera um valor de um objeto de uma estação
gerenciada.
� Set: uma estação de gerenciamento atualiza um valor de objeto numa estação
gerenciada.
� Trap: Uma estação gerenciada envia um valor não solicitado de objeto para uma
estação de gerenciamento.
Não é possível mudar a estrutura de uma MIB por meio da adição ou
eliminação de instancias de objetos (por exemplo, adicionando ou eliminando um registro
de uma tabela) e, também, não é possível usar comandos para uma ação ser realizada. Tais
restrições simplificam significativamente a implementação do SNMP. Por outro lado elas
limitam a capacidade do sistema de gerenciamento de redes.
4.2 COMUNIDADES E NOMES DE COMUNIDADES
Uma comunidade SNMP é o relacionamento entre um agente SNMP e um
conjunto de gerentes SNMP que definem autenticação, controle de acesso e características
do proxy.
O conceito de comunidade é um local definido como sistema gerenciado. O
sistema gerenciado estabelece uma comunidade desejada para cada combinação de
autenticação, controle de acesso, característica do proxy. Para cada comunidade é dado um
único (dentro desse agente) nome de comunidade e as estações de gerenciamento, dentro
daquela comunidade, devem empregar o nome comunidade em todas as operações de
acessar e selecionar. O agente pode estabelecer um número de comunidades com
sobreposição dos membros da estação de gerenciamento. Uma vez que as comunidades são
14
definidas localmente pelo agente, o mesmo nome pode ser usado por agentes diferentes.
Essa identidade de nomes é irrelevante e não indica qualquer similaridade entre as
comunidades definidas. Portanto, uma estação de gerenciamento deve manter o caminho
do nome comunidade ou nomes associados com cada um dos agentes que desejam acessar.
4.3 ESPECIFICAÇÕES DO PROTOCOLO
4.3.1 Formato SNMP
Com o SNMP, a informação é intercambiada entre uma estação de
gerenciamento e um agente na forma de uma mensagem SNMP. Cada mensagem inclui um
número de versão do SNMP, um nome de comunidade pode ser usado para este
intercâmbio e um dos cinco tipos de unidade de dados de protocolo. A figura 4.1
informalmente descreve a estrutura e a tabela 4.1define os campos constituintes.
Figura 4.1 Formatos SNMP
15
CAMPO DESCRIÇÃO Version Versão do SNMP (RFC 1157 é versão 1)
community O nome da comunidade atua como uma senha para autenticar a mensagem SNMP.
request-id Utilizado para distinguir entre pedidos que estejam sendo tratados, provendo a cada pedido um único ID.
error-status
Usado para indicar que ocorreu uma exceção enquanto está processado um pedido; os valores são: noError (0); tooBig (1);
noSuchName (2); badValue (3); readOnly (4) e genErr (5).
error-index
Quando erro-satuts é diferente de zero, pode prover informação adicional por meio da indicação de qual variável em uma lista causou a exceção.
variablebindings Uma lista de nomes de variáveis e seus valores correspondentes enterprise Tipo de trap de produção de objeto; baseada em sysObjectID. agent-addr Endereço de trap de produção de objeto
generic-trap
Tipos genéricos de valores trap são: coldStart (0); warmStart (1);
linkDown (2); linkUp (3); authentication-Failure (4);
egpNeighborLoss (5) e enterprise-Specific (6). specific-trap Código de Trap específico
time-stamp Tempo decorrido entre a última inicialização da entidade de rede o a produção de Trap; contém os valores de sysUpTime.
Tabela 4.1 Mensagem SNMP
4.3.1.1 Transmissão de uma Mensagem SNMP
Em princípio, uma entidade SNMP realiza as seguintes ações para transmitir
um dos cinco tipos de PDU para outra entidade SNMP:
1. O PDU é construído usando a estrutura ASN. 1;
2. Este PDU é então submetido a um serviço de autenticação, junto com a fonte e a
destinação do endereço de transporte e um nome de comunidade. O serviço de
autenticação então realiza quaisquer transformações requeridas para esta mudança,
tal como encriptação ou a inclusão de um código de autenticação, e retorna o
resultado;
3. A entidade protocolo então constrói uma mensagem, consistindo de campo versão,
o nome da comunidade e o resultado do passo 2;
16
4. Este novo objeto ASN.1 é então codificado usando as regras de codificação básicas
e passado para o serviço de transporte.
Na prática, autenticação não é invocada tipicamente.
4.3.1.2 Recepção de uma Mensagem SNMP
Em princípio, uma entidade SNMP realiza as seguintes ações quando da
recepção de uma mensagem SNMP.
1. Faz uma verificação da sintaxe básica da mensagem e descarta a mesma se
existir falha na análise;
2. Verifica o número da versão e descarta a mensagem se há uma falha de
combinação;
3. A entidade protocolo então transmite o nome de usuário, a porção PDU da
mensagem, e a fonte e destinação do endereço de transporte para um serviço
de autenticação, onde:
a) se a autenticação falha, o serviço de autenticação sinaliza a entidade de
protocolo SNMP, que gera uma trap e descarta a mensagem;
b) se a autenticação tiver sucesso, o serviço de autenticação retorna um
PDU na forma de um objeto ASN.1 adequado para a estrutura.
4. A entidade protocolo faz uma verificação da sintaxe básica da PDU e
descarta a PDU se ele falhar na combinação. De qualquer forma, usando a
comunidade nomeada, a política de acesso SNMP apropriada é selecionada e
o PDU é conseqüentemente processado.
Na prática, o serviço de autenticação serve meramente para verificar que o
nome comunidade autoriza a recepção de mensagens de entidade SNMP.
17
4.3.1.3 Variable Bindings
A Variable Bindings ou VarBind remete à uma instância, de um objeto
administrado, a qual esta diretamente relacionada para a junção do nome e valor de uma
variável.
Figura 4.2 Seqüência de PDU SNMP
4.3.2 GetRequest PDU
O GetRequest PDU é emitido por uma entidade SNMP e de interesse de uma
estação de gerenciamento de rede de uma aplicação. A entidade de transmissão inclui os
seguintes campos na PDU:
� Tipo PDU: indicando que este é um GetRequest PDU;
� Request-id: a entidade de transmissão determina números de tal maneira que
cada Request para cada agente é único.
� Variable-bindings: uma lista de instâncias de objetos cujos valores são
requeridos.
A entidade de recebimento SNMP responde ao GetRequest PDU com um
GetResponse PDU contendo o mesmo Request-id (figura 4.2). Na operação GetRequest :
18
todos os outros valores são recuperados ou nenhum o é. Se a resposta entidade é capaz de
fornecer valores de todas as variáveis enumeradas na lista de entrada variblebindings,
então o GetResponse PDU inclui o campo variablebindings, com o valor fornecido para
cada variável. Se pelo menos um dos valores das variáveis não pode ser fornecido em
seguida, valores não são devolvidos. As seguintes condições de erros podem ocorrer:
� Um objeto especificado no campo variablebindings pode não igualar um identificador
de objetos na MIB, ou um objeto especificado pode ser de um tipo agregado e,
portanto, não ter um valor de instância associado.
� A entidade de resposta pode estar habilitada para fornecer valores para todas as
variáveis na lista, mas o tamanho do resultado GetResponse PDU pode exceder a
limitação local. Neste caso, a entidade de resposta retorna o GetResponse PDU com um
error-status.
� A entidade de resposta pode estar habilitada para fornecer um valor para o último dos
objetos por algum motivo. Neste caso, a entidade de reposta retorna um GetResponse
PDU com um error-status. de genErr e um valor no campo error-index que é a
indexação do objeto problema no campo variablebindings.
Uma estação de gerenciamento pode recuperar toda linha de uma tabela em
certo momento simplesmente incluindo cada instância de objeto do quadro na lista de
variablebindings.
4.3.3 GetNextRequest PDU
O GetNextRequest PDU é quase idêntico a todos os GetRequest PDU - mesmo
módulo de troca e o mesmo formato - a única diferença é que no GetRequest PDU, cada
variável na lista de variablebindings referência a uma instância de objetos de quem o valor
é retornado. No GetNextRequest PDU, para cada variável, a resposta retorna o valor da
instância do objeto que é próximo dentro da ordem lexicográfica.
19
4.3.4 SetRequest PDU
O SetRequest PDU, cuja a função principal é alterar valores de variáveis do
objeto de gerenciamento, basicamente realiza as mesmas funções que o GetRequest PDU
porém com a particularidade que é usado para gravar um valor de objeto, sendo que o
acesso pode ser alterado nas variáveis que permitam leitura/gravação. Adicionalmente, o
SetRequest pode ser usado para adicionar ou eliminar linhas.
4.3.5 Trap PDU
O Trap é um simples pacote SNMP que alerta quando ocorre algum tipo de
problema no agente. Nesta condição o Trap PDU encaminha, para a estação de
gerenciamento, uma mensagem sempre que ocorre uma mudança ou alteração num objeto
gerenciado.
4.4 LIMITAÇÕES DO SNMP
Cabe registrar algumas das limitações do SNMP:
• Não é apropriado para o gerenciamento de redes verdadeiramente amplas, devido a
limitações de desempenho de pooling;
• Traps SNMP são desconhecidos. No caso típico onde UDP/IP é usado para
entregar mensagens Trap, o agente não tem garantia que uma mensagem critica
tenha sido encaminhada à estação de gerenciamento;
• O padrão SMNP básico fornece somente autenticação comum;
• Não suporta comunicação gerente para gerente. Por exemplo, não existe mecanismo
que permita a um sistema de gerenciamento ter conhecimento dos dispositivos e redes
gerenciadas por outro sistema de gerenciamento.
• O SNMP não é bem adaptado para recuperar grandes volumes de dados tal como uma
tabela de roteamento completa.
20
5 PROTOCOLO SNMP v2
5.1 OPERAÇOES SUPORTADAS PELO SNMPv2
O SNMPv2 é uma extensão do SNMPv1 e tal como acontece com este as PDUs
SNMPv2 são encapsuladas em uma mensagem. A mensagem SNMP v2 oferece a
funcionalidade exigida para os requisitos de segurança do SNMPv2. Por meio do
significado do cabeçalho da mensagem, o qual é determinado por um quadro
administrativo, são definidas a autenticação e políticas de privacidade. O SNMPv2 oferece
três tipos de acesso à informação de gerenciamento:
� Pedido de resposta gerente-agente: uma entidade SNMPv2 atuando em um papel
gerente envia um pedido a uma entidade SNMPv2 agindo no papel de um agente, e esta
última entidade SNMPv2 então responde ao pedido. Este tipo é usado para obter ou
modificar gerenciamento da informação associada a gerenciamento do dispositivo.
� Pedido de resposta gerente-gerente: uma entidade SNMPv2 atuando em uma função
gerente envia um pedido a uma entidade SNMPv2 agindo em uma função gerente e
esta última entidade a SNMPv2 responde ao pedido. Este tipo é usado para notificar
uma entidade SNMPv2 atuando em uma função gerente de gerenciamento da
informação associada a outra entidade SNMPv2 também atuando em uma função
gerente
� agente-gerente não confirmada: Uma entidade SNMPv2 agindo na função de um
agente envia uma mensagem não solicitada, designado por "Trap", a uma entidade
SNMPv2 agindo em uma função gerente e nenhuma resposta é retornada. Este tipo é
usado para notificar uma entidade SNMPv2 agindo em uma função gerente de um
evento excepcional que resultou em mudanças de gestão da informação associada à
gerenciamento dispositivo.
Apenas o segundo item é novo para SNMPv2; os outros dois tipos de interação
são encontrados em SNMPv1.
21
5.1.1 Transmissão de uma mensagem SNMPv2
Uma entidade SNMPv2 realiza as seguintes ações para transmitir uma PDU
para outra entidade SNMPv2.
1. A PDU é construída usando a estrutura ASN.1;
2. Essa PDU é então passada para um serviço de autenticação junto com os endereços
de transporte da fonte e destino e o nome da comunidade. O serviço de autenticação então
realiza quaisquer transformações requeridas para esta troca tais como criptografia ou a
inclusão de um código de autenticação, e retorna o resultado;
3. A entidade Protocolo então constrói uma mensagem, consistindo de um campo versão, o
nome da comunidade e o resultado da ação 2;
4. Esse novo objeto ASN.1 é então codificada, usando as regras de codificação básica
(BER) e passada para o serviço de transporte.
Na prática autenticação não é usualmente invocada
5.1.2 Recepção de uma mensagem SNMPv2
Seqüência de ações:
1. Realiza a verificação da sintaxe básica da mensagem descartando-a se houver
falhas no processamento ou análise;
2. Verifica o número da versão descartando-a se existir divergência ou erro;
3. A entidade Protocolo então transmite o nome usuário, a PDU da mensagem e os
endereços de transporte da origem e destino.
a) se a autenticação falha, o serviço de autenticação sinaliza para a entidade
protocolo SNMPv2, a qual gera uma trap e descarta a mensagem;
b) se a autenticação é bem sucedida, o serviço de autenticação retorna um PDU no
formato de um objeto ASN.1 o qual se ajusta à estrutura definida na especificação
do protocolo.
4. A entidade protocolo realiza uma verificação da sintaxe básica da PDU e descarta a
PDU se ele falhar no processamento ou análise. Por outro lado, usando a
comunidade nomeada, a apropriada política de acesso SNMPv2 é selecionada e
conseqüentemente o PDU é processado.
Na prática o serviço de autenticação meramente serve para verificar que a
comunidade autoriza receber mensagens da entidade SNMPv2.
22
A figura 5.1 representa o formato da PDU SNMPv2 e a estrutura da mensagem
descrita na a figura 5.2. A seqüência de PDU SNMPv2 é apresentada na figura 5.3.
Figura 5.1 - Formato PDU SNMPv2
Figura 5.2 - Estrutura da mensagem
� request-id: O valor deste campo em uma resposta PDU deve ser igual ao valor no
campo correspondente de um pedido PDU. O gerente pode atribuir um número único
para cada solicitação pendente para o mesmo agente, a fim de distinguir respostas a
vários pedidos pendentes.
� error-status: Um valor zero indica que uma exceção ocorreu durante o processamento
de um pedido.
23
� error-index: Quando o campo error-status não é zero, o índice de valores de erros
identifica a variável (objeto) na variável-bindings lista o que causou o erro. A primeira
variável na lista tem indice1, a segunda tem índice 2, e assim por diante.
� Variável-bindings: este campo permite que uma única operação a ser aplicada a um
grupo instâncias de objeto. O domínio consiste de uma seqüência de pares sendo que. o
primeiro elemento de cada par é um objeto identificador e o segundo elemento de cada
par pode assumir um dos seguintes parâmetros:
o value: o valor associado a cada instancia de objeto;
o UnSpecified: um valor NULL é usado na recuperação pedidos;
o NoSuchObject: o agente não pode implementar o objeto referido por este
object identifier;
o NoSuchInstance: indica que este objeto, não existe para esta operação;
o endOfMibView: indica uma tentativa de referência a um objeto
identificador.
Figura 5.3 - Seqüência de PDU SNMP
5.1.3 GetRequest PDU
O GetRequest pratica as mesmas funções que o SNMPv1 e, do mesmo modo,
provê um mecanismo para solicitar os valores apresentados no campo Variable Bindings.
24
5.1.4 GetNextRequest PDU
A única diferença entre as versões SNMP v1/v2 é que o GetNextRequest
SNMPv1 ou recupera todos os valores ou não recupera nenhum, enquanto que o
GetNextRequest SNMPv2 recupera todos os valores possíveis.
Uma resposta PDU de um GetNextRequest é construída processando cada
variável na entrada da lista de variáveis de acordo com as seguintes regras:
• A variável (instância de objetos) é determinada para que o próximo na ordem
lexicográfica na variável nomeada;
• Se não existe sucessor lexicográfico o par de variáveis de ligação resultante
consiste do nome da variável na requisição e o campo valor é ajustado para
endOfMibView.
5.1.5 GetBulkRequest PDU
A operação GetBulkRequest elimina uma das maiores limitações do SNMP -
que é a sua incapacidade de recuperar grandes blocos de dados - tendo como propósito
principal o de minimizar o número de trocas de protocolos requeridos, para retornar uma
grande quantidade de informações de gerenciamento. A operação GetBulkRequest usa o
mesmo princípio de seleção que a operação GetNextRequest, isto é, a seleção é sempre
sobre a próxima instância de objeto na ordem lexicográfica. A diferença é que com
GetBulkRequest, é possível especificar que múltiplos sucessores lexicográficos sejam
selecionados.
5.1.6 SetRequest PDU
Comparando-se com o SNMPv1, observa-se que o estabelecimento dos valores
no campo Variable Bindings é realizado de maneira similar exceto na maneira como as
respostas são gerenciadas onde, no SNMPv2, são analisados basicamente se o tamanho
excede a um tamanho determinado ou ainda quanto a restrições locais, para então
estabelecer o Response PDU.
25
5.1.7 Trap PDU
Na versão SNMPv2, o recurso Trap PDU transfere informações, descrevendo
os acontecimentos críticos no gerenciamento. Apesar de ser uma função semelhante ao
SNMPv1, há uma diferença a saber: no SNMPv2 os Traps são nomeados no espaço MIB
(atualmente MIBs controlam como Traps são enviadas).
5.1.8 InformRequest PDU
É enviado por uma entidade SNMPv2 atuando em uma função de gerente,
como suporte de uma aplicação, para outra entidade SNMPv2 atuando em uma função de
gerente, para fornecer informações de gerenciamento para uma aplicação usando a
entidade posteriormente. Quando um InformRequest é recebido, a entidade SNMPv2
determina o tamanho da mensagem, encapsulando um Response PDU com o mesmo valor
no seu request-id, error-status, error-index e o campo variable-bindings como recebido o
InformRequest PDU.
26
6 O PROTOCOLO SNMP v3
O SNMPv3 tem como principal característica a segurança, obtida por meio da
autenticação e criptografia dos dados, o que possibilita:
� Que apenas grupos autenticados possam se comunicar;
� Que as mensagem possam ser recebidas em tempo hábil evitando, com isso, que sejam
adulteradas e passadas adiante causando danos indesejáveis.
A simplicidade do SNMP possibilitou a sua popularização, possuindo apenas
quatro operações duas para obter dados uma para modificar e uma para enviar notificações.
No entanto a complexidade está nos dados que o SNMP acessa, já que nem todas as
características de um dispositivo são úteis, tornando difícil a seleção de informações úteis
para o gerenciamento.
O maior desafio na criação do SNMPv3 foi o desenvolvimento de uma estrutura
que pudesse ser facilmente estendida e, com este objetivo, foi divido em duas partes - o
Motor SNMP e aplicações SNMP – e, além disso, os agentes e gerentes passaram a ser
denominados de entidades.
6.1 ARQUITETURA SNMPv3
A arquitetura SNMP, consiste de uma coleção de entidades SNMP atuando uma
sobre a outra de forma distribuída. Cada entidade implementa uma parte da capacidade
SNMP podendo agir como um nó agente e um nó gerente, ou, uma combinação dos dois.
Cada entidade SNMP consiste num conjunto de módulos que interagem entre si para
fornecer serviços.
6.1.1 Entidades SNMP
Cada entidade SNMP possui um Motor SNMP o qual implementa funções para
enviar e receber mensagens, autenticar e criptografar / descriptografar mensagens, além de
controlar o acesso aos objetos gerenciados. Estas funções são fornecidas com uma ou mais
aplicações configuradas com o Motor SNMP para formar uma entidade SNMP. O Motor
SNMP se divide em quatro componentes:
� Despachante;
27
� Subsistema de processamento de mensagens;
� Subsistema de segurança; e
� Subsistema de controle de acesso.
Na figura 6.1, abaixo, apresenta-se síntese da inter-relação Motor SNMP versus aplicações.
Figura 6.1 - Entidade SNMP (RFC 2271)
6.1.1.1 Gerente SNMP tradicional
O diagrama de bloco da figura 6.2, pág. 29, representa um gerente SMNP
tradicional o qual realiza três tipos de aplicações:
� Aplicações Geradoras de Comando → monitora e manipula dados de
gerenciáveis em agentes remotos, que fazem uso de SNMPv1/v2 PDUs,
incluindo GET, GEtNext, GetBulk e Set.
� Aplicação Geradora de Notificações → inicia mensagens assíncronas; no caso
de um gerente tradicional, o informRequest PDU é utilizado para esta aplicação.
� Aplicação Receptora → processa entradas de mensagens assíncronas; estes
incluem PDU InformRequest, SNMPv2-Trap e SNMPv1 Trap PDUs.
O Motor SNMP realiza duas funções gerais, como se segue:
1. aceita PDUs oriundos de pedidos SNMP e realiza o processamento necessário,
incluindo a inserção de códigos de autenticação e criptografia e, em seguida,
encapsula as PDUs em mensagens para transmissão.
28
2. aceita receber mensagens SNMP da camada de transportes, realiza o
processamento necessário, incluindo autenticação e descriptografia e, em seguida,
extrai as PDUs das mensagens e as envia para a aplicação SNMP apropriada.
Em um gerente tradicional é composto por: um Despachante, um Subsistema de
Processamento de Mensagem e um Subsistema de Segurança. O Despachante é um simples
gerente de tráfego. Para as PDUs de saída, o despachante aceita PDUs de aplicativos e
executa as seguintes funções: Para cada PDU, o despachante determina o tipo
processamento de mensagem necessária (SNMPv1, SNMPv2, ou SNMPv3) e passa o PDU
relativa ao tratamento de mensagem adequado no módulo Subsistema de Processamento de
Mensagem. Posteriormente, o Subsistema de Processamento de Mensagem retorna uma
mensagem contendo a PDU e incluindo cabeçalhos adequados da mensagem. O
Despachante, em seguida, passa a esta PDU para a aplicação adequada. O Subsistema de
Processamento de Mensagem aceita PDUs vindas do Despachante e as prepara para
transmissão, envolve-as no cabeçalho da mensagem adequada e devolve-as ao
Despachante. O Subsistema de Processamento de Mensagem também aceita as mensagens
recebidas do Despachante, processa cada cabeçalho destas mensagens, e retorna a PDU
anexada ao Despachante. Uma implementação do Subsistema de Processamento de
Mensagem pode apoiar um único formato mensagem correspondente a uma única versão
do SNMP (SNMPv1, SNMPv2, SNMPv3) ou pode conter uma série de módulos, cada um
apoiando uma versão diferente do SNMP.
O Subsistema de Segurança exerce funções de autenticação e criptografia. Cada
mensagem enviada é passada para Subsistema de Segurança pelo Subsistema de
Processamento de Mensagem. Dependendo dos serviços solicitados, o Subsistema de
Segurança pode criptografar a PDU em anexo, o que pode gerar um código autenticação e
inseri-lo no cabeçalho da mensagem. A mensagem é retornada ao Subsistema de
Processamento de Mensagem. Da mesma forma, cada mensagem recebida pela entidade
gerente é passada para o Subsistema de Segurança pelo sistema de processamento de
mensagem que verifica a autenticação código e executa descriptografia da PDU. Após esta
operação a mensagem é retornada ao subsistema de processamento de mensagem.
29
Figura 6.2 - Gerente SNMPv3 tradicional
6.1.1.2 Agente SNMP tradicional
A figura 6.3 representa um diagrama de bloco de um Agente SMNP Tradicional
o qual realiza três tipos de aplicações.
� Aplicação Respondedora de Comando: fornece acesso a dados gerenciados;
� Aplicação Geradora de notificações: inicia mensagens assíncronas; no caso de um
agente tradicional, a PDU SNMPv2-Trap ou SNMPv1 Trap PDU é utilizado para esta
aplicação;
� Aplicação encaminhadora de Proxy: encaminha mensagens entre entidades.
O motor SNMP de um agente tradicional tem todos os componentes
encontrados no motor SNMP de um gerente tradicional, acrescida de um Subsistema de
Controle de. Este subsistema fornece serviços de autorização para controlar o acesso a
MIBs para a leitura e a configuração de objetos gerenciados. Estes serviços são realizados
com base no conteúdo das PDUs. Uma implementação do Subsistema de Segurança pode
apoiar ou mais distintas sobre controle de acesso modelos. Até ao momento, o único
modelo de segurança definido é o Ver-Based Access Control Model (VACM) para
SNMPv3, especificado em RFC2275. As funções relacionadas com a segurança estão
organizadas em dois subsistemas: segurança e controle de acesso. O Subsistema de
30
Segurança está preocupado com a privacidade e autenticação, e opera sobre as
mensagens SNMP. O Subsistema de Controle de Acesso está preocupado com acesso
autorizado as informações gerenciadas, e opera sobre as PDUs SNMP.
Figura 6.3 - Agente SNMPv3 Tradicional
6.2 APLICAÇÕES SNMP
Em se tratando de aplicações SNMPv3, subentende-se que as mesmas possuem
uma entidade SNMP sendo que, atualmente, existem cinco tipos de aplicações definidas:
� Geradoras de Comandos: geram comandos SNMP com a finalidade de coletar ou
configurar dados gerenciados;
� Processadoras de Comandos: fornecem acesso aos dados gerenciados;
� Geradoras de notificação: geram Traps ou mensagens Inform;
� Receptoras de notificações: recebem e processam Traps ou mensagens Inform;
� Encaminhadoras de proxy: enviam mensagens entre entidades SNMP.
Com estes cinco tipos de aplicação pode-se concluir que aplicações receptoras
de notificação e as geradoras de comandos são chamadas de gerente SNMP e as
processadoras de comandos e geradoras de notificação são chamadas de agente SNMP.
31
6.3 FORMATO DA MENSAGEN SNMPV3
Figura 6.4 - Formato da mensagem SNMPv3
Tal qual ocorre nas versões anteriores, no SNMPv3 a informação é trocada
entre entidades SNMP, sob a forma de uma mensagem. A estrutura da mensagem SNMPv3
é ilustrada na figura 6.4 onde as áreas sombreadas são aquelas criadas e processadas pelo
subsistema de processamento de mensagem e inclui os seguintes campos:
� msgVersion: utilizado para informar sobre a versão SNMP utilizada na mensagem;
� msgID: identificador único utilizado entre duas entidades SNMP;
� msgMaxSize: contem o tamanho máximo suportado pela mensagem em octetos;
� msgFlags: um octeto contendo três flags nos três últimos bits significativos;
� msgSecurityModel: um identificador que indica qual modelo de segurança foi usado
pelo remetente para preparar a mensagem;
� msgSecurityParameters: um octeto que contem parâmetros gerados pelo subsistema de
segurança na entidade SNMP que enviou a mensagem e processado pelo subsistema de
segurança na entidade receptora;
� contextEngineID: um octeto que identifica unicamente uma entidade SNMP;
� contextName: um octeto que identifica unicamente um contexto em particular com o
escopo do motor de contexto associado; e
� data: SNMPv3 especifica que esta deve ser uma PDU SNMPv2.
32
A figura 6.4 mostra, ainda, como estes campos são organizados. Os cinco
campos – msgVersio, msgID, msgMaxSize, msgFlags, e msgSecurityModel - são
referenciados na definição ASN.1 pelo nome msgGobalData. Este bloco contém
parâmetros necessários pelo subsistema “processamento de mensagem” para coordenar a
manipulação e o processamento da mensagem. O três campos contextEngineID,
contextName e data são referenciados como msgData e possuem um tipo de
scopedPDUData, que é uma PDU contendo as informações mencionadas no contexto onde
é claramente identificado pelo contextEngineID e contextName. Este bloco contém
informações necessárias pela aplicação para processar a PDU.
6.4 ALGORITMOS CRIPTOGRÁFICOS USADOS PELO SNMPv3
6.4.1. User-Based Security Model – USM
O USM utiliza o conceito de motor autorizado, ou seja, de qualquer transmissão
de mensagem uma das duas entidades, emissor ou receptor, é denominada “motor
autorizado”. Possui serviços de integridade, autenticação e privacidade dos dados. A
integridade e a autenticação são obtidas através da função hash, que opera dentro do
código de autenticação, enquanto que a privacidade é obtida através da encriptação dos
dados.
No modo USM há dois recursos criptográficos definidos - Autenticação e
Privacidade – para os quais o SNMP requisita os valores “privKey” e “authKey” para
possibilitar o suporte.
6.4.1.1 Autenticação
Existem duas funções hash identificadas no USM, o Message Digest5 (MD5) e
o Secure Hash Algorithm Revisão One (SHA-1), o qual será detalhado a seguir:
SHA-1 – Secure Hash Algorithm 1
É uma técnica que possibilita a integridade dos dados. Diferencia-se de outros
mecanismos de integridade, por detecção e correção de erros de código, por meio de duas
características:
33
o Resistência de Colisão – avalia a capacidade de encontrar duas mensagens
de entrada que contenham o mesmo valor hash;
o Resistência de pré-imagem – determina a dificuldade de originar dados que
resultem em um valor hash definido sem distinguir o texto que o originou.
Os recursos acima distinguem as funções hash criptografadas, dos demais
mecanismos de verificação de integridade, quanto a permitir a detecção de alterações de
ataques maliciosos ao invés de simplesmente registrar erros.
HMAC - Hash Message Authentication Code
O USM é baseado no código de autenticação de mensagem HMAC, o qual é
um mecanismo utilizado para verificar a veracidade da origem e integridade dos dados. Por
sua vez o HMAC pode ser construído utilizando a função hash - que funciona como uma
chave secreta podendo ser utilizada para gerar uma identificação associada com uma
entrada particular de mensagem – com a condição de que o remetente e o destinatário
devam concordar sobre o compartilhamento da chave secreta. Em síntese, a proteção de
uma mensagem é realizada da seguinte forma: o remetente calcula a transmissão utilizando
uma cópia de identificação de sua chave secreta (authKey) e envia a mensagem marcando a
identificação para o receptor. O receptor calcula a identificação utilizando a chave secreta
local (authkey) verificando se o valor calculado corresponde ao da mensagem recebida.
Caso haja tentativa de ataque malicioso, para tentar modificar a mensagem, esta não teria
sucesso por não ser capaz de prever a identificação correspondente, sem possuir a chave
secreta.
6.4.1.2 Encriptação
Para encriptação o USM adota a técnica denominada Data Encryption Standard
(DES). O DES é uma técnica de encriptação simétrica a qual requer como o HMAC, que o
emissor e o receptor concordem antecipadamente sobre a chave secreta compartilhada que
neste caso é uma chave de encriptação e um vetor de inicialização (VI). A chave de
encriptação e o VI derivam de uma chave de privacidade localizada (privKey), onde os oito
primeiros octetos da mesma são usados como chave de encriptação e os últimos oito
octetos são usados como vetor de inicialização.
34
6.4.1.3 Processamento de mensagens USM
Os procedimentos adotados pelo USM, para o processamento de mensagens
recebidas e enviadas, são mostrados na figura 6.5 sendo realizado ao receber um
generateRequestMsg. O USM realiza os seguintes passos:
1. O USM determina se há uma entrada na usmUserTable para o destino
securityEngineID e a fonte SecurityName. Se houver, uma indicação de erro é
retornada;
2. O USM determina se o securityModel requisitado é suportado por este usuário e, se
não for, retorna uma indicação de erro;
3. se o securityLevel requisitar privacidade, então o valor scopedPDU é criptografado
usando o CBC-DES e a chave privada de criptografia localizada na privKey deste
usuário;
4. O parâmetro snmpEngineID é armazenado no campo msgAuthoritativeEngineID;
5. O parâmetro securityName é armazenado no campo msgUserName;
6. Se o securityLevel requisitar autenticação, o valor corrente do snmpEngineBoots e
snmpEngineTime correspondentes ao parâmetro snmpEngineID são armazenados
nos campos msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime,
respectivamente;
7. A mensagem completa com seu tamanho é retornada ao módulo de processamento
de mensagens que fez a requisição.
35
Figura 6.5 - Processamento da mensagem USM: transmissão
Uma mensagem de resposta deve ser recebida, decorrido um tempo estimado, e
deve ser tratada pelo despachante e pelo processador de mensagem o qual invoca o
USM com a primitiva processIncomingMessage. Este processamento (figura 6.6)
inclui:
1. Os valores dos parâmetros de segurança são extraídos do campo
securityParameters;
2. 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
contrário, uma indicação de erro é retornada;
3. O USM determina se há uma entrada na usmUserTable para o
SecurityEngineID remoto autorizado e o securityName local. Se não houver,
uma indicação de erro é retornada;
4. O USM determina se o securityLevel requisitado é suportado par este usuário e,
se não for, uma indicação de erro é retornada;
5. Se o securityLevel especificar que a mensagem é para ser autenticada, então a
mensagem é autenticada, usando o HMAC e a chave privada de autenticação da
mensagem para esta mensagem e comparando o resultado com o do campo
36
msgAuthenticationParameters na mensagem. Se os resultados não combinarem,
o USM para o processamento e retorna uma indicação de erro. Se o resultado
conferir, a mensagem é declarada autentica e o processamento continua;
6. O USM realiza a sincronização;
7. O USM realiza a checagem do tempo. Se a mensagem não estiver na janela de
tempo, o USM para o processamento e retorna uma indicação de erro. Se a
mensagem estiver dentro da janela de tempo o processamento continua.
8. Se o securityLevel indicar que foi usada criptografia, então a scopedPdu é
descriptografada usando o CBC-DES e a chave privada de criptografia
localizada n privKey deste usuário;
9. A scopedPdu é retornada ao modulo de processamento de mensagens que fez a
requisição.
Figura 6.6 - Processamento da mensagem USM: recepção.
A processadora de comandos, com algumas diferenças importantes, utiliza
muito dos passos citados anteriormente. Quando o USM é invocado com uma primitiva
processIncomingMessage - oriunda do subsistema de processamento de mensagens
(quando está tratando uma mensagem Request que acaba de chegar) - realiza os seguintes
passos:
37
1. Os valores dos parâmetros de segurança são extraídos do securityParameters. Um
bloco cachedSecurityData é preparado pra servir de cachê para as seguintes
informações: msgUserName; securityEngineID; e securityLevel.
2. Se o valor do msgAuthoirtativeEngineID no security Parameters for desconhecido,
uma indicação de erro é retornada;
3. O USM determina se há uma entrada no usmSecurityTable para o securityEngineID
local autorizado e o securityName remoto. Se não houver, uma indicação de erro é
retornada;
4. O USM determina se o securityLevel requisitado é suportado para este usuário, e se
não for, uma indicação de erro é retornada;
5. Se o securityLevel especifica que a mensagem deve ser autenticada, esta ação é
feita - por meio do HMAC e a chave privada de autenticação localizada na authKey
deste usuário - por meio do cálculo do código de autenticação da mensagem e
comparação do resultado obtido com o resultado do msgAuthenticationParameters
da mensagem. Se houver combinação a mensagem é declarada autentica e
processamento continua, caso contrário o USM interrompe o processamento e uma
indicação de erro é encaminhada.
6. Se o securityLevel indicar que a criptografia foi utilizada, então a scopedPdu é
descriptografada usando o CBC-DES e a chave privada de criptografia localizada
na privKey deste usuário;
7. São adicionadas as seguintes informações ao bloco cachedSecurityData disposto no
passo 1: usmUserAuthProtocol; usmUserAuthKey; usmUserPrivProtocol;
usmUserPrivKey.
8. Uma referência ao ponteiro para este bloco em cachê é colocado na saída do
parâmetro securityStateReference;
9. A scopedPdu é retornada ao módulo de processamento de mensagens que realizou
a requisição.
No retorno do USM para o processador de mensagens este, subseqüentemente,
retorna a PDU recuperada para a aplicação processadora de comando. Enquanto isso, o
processador de mensagens armazena em cachê o valor do securityStateReference que é
recebido em retorno do USM, como parte do conjunto dos parâmetros do processador de
comandos que este possui no cachê. Concomitantemente o processador de comandos pode
preparar uma PDU Response e invocar então o processador de mensagens com uma
prepareResponseMsg primitiva. O processador de mensagens irá então invocar o USM
38
com a primitiva generateResponseMsg, que possui os mesmos parâmetros de entrada e
saída do generateRequestMsg com uma exceção: generateResponseMsg inclui o
securityStateReference com o parâmetro de entrada. O processador de mensagens obtém
este valor do seu cachê e passa o valor do securityStateReference para a requisição Request
recebida que combine com o Response da saída.
São realizados pelo USM após o receber uma generateResponseMsg:
1. Usando o valor recebido de securityStateReference, o USM obtém as informações
do usuário armazenando-as na cachê. Estas informações provem da mensagem
Request processada anteriormente;
2. O USM determina se o securityLevel requisitado é suportado para este usuário, e se
não for, uma indicação de erro é retornada;
3. Se o securityLevel requisitar privacidade então o valor da scopedPdu é
criptografado usando o CBC-DES e a chave privada de criptografia localizada na
privKey deste usuário. O texto cifrado resultante é armazenado no campo
scopedPdu, e o valor falso derivado do valor da privKey é armazenado no campo
msgPrivacyParameters da mensagem SNMPv3. Se não for requisitado privacidade
então o campo mspPrivacyParameters é configurado para NULL;
4. O parâmetro snmpEngineID é armazenado no campo msgAuthoritativeEngineID da
mensagem SNMPv3;
5. O parâmetro securityName é armazenado no campo msgUserName;
6. Os valores correntes de snmpEngineBoots e do snmpEngineTime para este motor
local autorizado são armazenados no campos msgAuthoritativeEngineBoots e
msgAuthoritativeEngineTime, respectivamente. Se o securityLevel requisitar
autenticação, o código de autenticação é calculado sobre toda a mensagem usando
o HMAC e a chave privada de autenticação localizada na authkey deste usuário, por
meio do cálculo do código de autenticação de mensagem para a mensagem em
questão e comparando o resultado com o do campo msgAuthenticationParameters
na mensagem;
7. A mensagem completa com seu tamanho é retornada ao modulo de processamento
de mensagem que solicitou a requisição.
A diferença entre o motor autorizado e um não autorizado é demonstrado no
item 6. No caso de um motor não autorizado, os valores dos campos
msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime do cabeçalho da mensagem
39
são configurados somente se a mensagem deve ser autenticada por um receptor autorizado.
Esta restrição faz sentido porque o receptor autorizado ira checar estes campos apenas se a
mensagem deva ser autenticada. Entretanto, para uma mensagem Response vinda de um
motor autorizado, os valores msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime
presentes no cabeçalho da mensagem são 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 não
autorizado, este deve usar estes valores apenas para a sincronização da mensagem se a
mensagem for autenticada.
6.4.1.4 Processo de descoberta
Para obter informações suficientes sobre outros motores SNMP o USM requer
o uso do processo de descoberta. Em particular, um o motor SNMP não autorizado deve
memorizar o valor snmpEngineID de um motor autorizado antes que se realize a
comunicação. Este processo é realizado em duas etapas:
� O motor não autorizado envia uma mensagem Request ao motor autorizado ao qual
deseja descobrir com um securityLevel requisitado de noAuthnoPriv. O motor
autorizado irá responder com uma mensagem Report contendo seu snmpEngineID
no campo msgAuthoritativeEngineID;
� Se uma comunicação autenticada é requisitada, o motor não autorizado precisa
estabelecer uma sincronização de tempo com o motor autorizado.
6.4.1.5 Gerenciamento de chaves
Um dos requisitos para uso dos serviços de autenticação e privacidade no
SNMPv3 é que, para qualquer comunicação entre um diretor em um motor não autorizado
e um motor autorizado remoto, chaves secretas de autenticação e de privacidade devem ser
compartilhadas [1].
Estas chaves possibilitam a um usuário de um motor não autorizado
(tipicamente, um sistema agente) fazer uso da autenticação e privacidade com sistemas
remotos autorizados que o usuário gerencia (um sistema agente). O guia para criação,
atualização e gerenciamento de chaves esta descrito na RFC 2274.
40
Para uma simplificação o gerenciamento de chaves é centrado nos diretores,
cada diretor é requisitado a manter apenas uma única chave para autenticação e uma única
chave para privacidade. Estas chaves não são armazenadas em uma MIB e não são
acessíveis via SNMP.
a) Algoritmo de transformação de senha para chaves
Na RFC 2274 é especificado um algoritmo para mapeamento de uma senha
comum para uma chave de 128 ou 160 bits. Resumidamente a geração de chaves é feita da
seguinte maneira [1]:
1. Com uma string de 1.048.576 cria-se uma senha do usuário e através da repetição
da senha quantas vezes quanto necessário, truncado o último valor para formar uma
string digest0.
2. Se necessário criar uma chave de 128 bits, utiliza-se o hash MD5 do digest0 para
formar digest1. A saída é a chave do usuário.
Esse algoritmo reduz consideravelmente a possibilidade de um ataque
dicionário ou “força bruta” nas chaves do usuário de qualquer NMS em particular.
Nenhum NMS é necessário para armazenar as chaves do usuário. Ao invés disso, uma
chave de usuário é gerada quando necessário a partir da senha do usuário. Uma única senha
pode ser usada para gerar uma única chave usada tanto para autenticação quanto para
privacidade. Entretanto seria mais seguro usar duas senhas, uma para gerar uma chave de
autenticação e outra para gerar uma chave de privacidade/criptografia.
b) Localização de chaves
A RFC 2274 define chave localizada como chave secreta compartilhada entre
um usuário e uma entidade SNMP autorizada. O objetivo é que assim o usuário precisa
manterá apenas uma única chave (ou duas se usar autenticação e privacidade) e, portanto
lembrar-se de apenas uma senha (ou duas). A localização de chaves é o processo pelo qual
uma única chave do usuário é convertida em múltiplas chaves únicas, uma para cada Motor
SNMP remoto. Dentre os principais objetivos para o gerenciamento de chaves podemos
citar:
1. Em uma rede distribuída cada sistema agente SNMP possui sua própria chave única
para cada usuário autorizado a gerenciá-lo. Se múltiplos usuários estão autorizados
41
como gerentes, o agente possui uma única chave de autenticação e uma chave de
criptografia para cada usuário. Por isso, se a chave de um usuário é comprometida,
as chaves dos outros usuários não são;
2. Para agentes diferentes as chaves de um usuário são diferentes. Com isso se um
agente é comprometido, apenas as chaves de usuário para aquele agente são
comprometidas e não as chaves de usuários em uso para os outros agentes.
3. Independente da disponibilidade de um sistema de gerenciamento de rede (NMS)
pode ser executado de qualquer ponto da rede, com isso o usuário pode realizar
funções de gerenciamento a partir de qualquer estação gerenciada. Essa habilidade
é produzida pelo algoritmo de senha para chave.
Alguns procedimentos a serem evitados:
� Um usuário precisa lembrar um grande número de chaves;
� Um adversário que obtenha a chave de um agente é capaz de personificar qualquer
outro agente para qualquer usuário, ou qualquer usuário para qualquer outro agente.
Para que isso seja evitado, uma única chave de usuário é mapeada pelo uso de
uma função de mão única irreversível em diferentes chaves localizadas, para motores
autenticados diferentes. Esse procedimento se faz da seguinte forma:
� Formar uma string digest2 pela concatenação de digest1, o valor snmpEngineID do
motor autorizado (agente) e digest1;
� Se uma chave de 128 bits for desejada, utiliza-se o hash MD5 do digest2. Se for
necessária uma chave de 160 bits adota-se o hash SHA-1 do digest2. A saída é a chave
do usuário.
A chave resultante pode então ser configurada no sistema agente de forma
segura. Devido à origem do MD5 e do SHA-1, é impossível que um adversário possa
aprender uma chave de usuário, mesmo que o adversário venha descobrir a chave
localizada. A figura 6.7 demonstra resumidamente esse processo.
42
Figura 6.7 - Localização de chave
c) Atualização de chaves
Para que a entrega de chaves localizadas para sistemas autenticados (agentes)
seja feita é necessário que o SNMPv3 assuma se há algum meio seguro. Contudo esta
entrega segura esta fora do escopo do SNMPv3, devendo esta ser manual ou por outro
protocolo seguro. O SNMP é responsável pelo fornecimento de um mecanismo para
atualizar essas chaves de modo seguro toda vez que uma chave inicial (ou par de chaves,
no caso da autenticação e privacidade) tenha sido entregue a um agente. Através de
requisição e fornecimento de uma nova senha, um usuário pode iniciar o processo de troca
de chave. Alternativamente, o NMS pode iniciar o processo por meio da requisição de uma
nova senha. Em ambos os casos a chave existente é atualizada permitindo ao NMS calcular
uma chave localizada para cada agente com o qual se comunica e, na continuidade,
comunicar-se de modo seguro com cada agente para que este possa atualizar sua chave
localizada. Obviamente, o NMS não pode simplesmente enviar a chave em texto plano
através da rede devendo adotar umas das seguintes alternativas:
1. Criptografar a nova chave usando a chave antiga como a chave de criptografia;
2. Utilizar algum tipo de função de mão única para produzir um valor a partir da
chave antiga.
Cabe destacar duas desvantagens da criptografia, a saber: a necessidade de ter
que ser utilizada mesmo em sistemas que suportam apenas autenticação de mensagens e
restrições existentes em vários quanto ao emprego da criptografia.
O modo de procedimento empregado pelo SNMPv3 abrange o uso de objetos
KeyChange localizados no usmUserGroup com os quais um diretor remoto ou um NMS
43
pode configurar este objeto, que é então automaticamente usado pelo agente para atualizar
a chave correspondente. O algoritmo considera que um tamanho variável de chave pode ser
utilizado por um algoritmo de autenticação ou de criptografia específico, o que torna
complexo o algoritmo de atualização de chaves.
O recurso de atualizar uma chave de usuário em particular é permitido pelo
SNMPv3, tanto ao administrador de rede como ao próprio usuário. Um administrador de
rede pode configurar as chaves iniciais para um usuário, solicitando ao mesmo para trocar
as senhas de tempos em tempos e cuidar da atualização de chaves quando isso acontecer.
Por outro lado o usuário pode substituir sua senha e chave (s) a qualquer momento. Para
acomodar estes dois requisitos, o grupo usmUser contém dois objetos de troca de chaves
para cada uma das chaves. Para a chave de autenticação 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,
permitindo pelo subsistema de controle de acesso. O objeto usmUserOwnAuthKeyChange
não é protegido por controle de acesso, mas é definido de forma a permitir a atualização
apenas se o requisitante possuir o mesmo userName como objeto usmUseName para esta
linha. Similarmente, o usmUserPrivKeyChange e usmUserOwnPrivKeyChange fornecem
capacidade de atualização de uma chave criptografada, respectivamente, para o
administrador da rede e para o usuário.
6.4.2 View-Based Access Control Model – VACM
A RFC 2275 define o modelo de controle de acesso baseado em visão (VACM)
e destaca duas importantes características:
� Responsável por determinar se o acesso a um objeto gerenciado por um diretor remoto,
em uma MIB local, deve ser permitido;
� Faz uso de uma MIB que define a política de controle de acesso para este agente e
torna possível o uso da configuração remota.
O VACM é constituído por cinco elementos, conforme RFC 2275:
� Grupos: conjunto de zero ou mais duplas <securityModel, securityName > nas quais os
objetos de gerenciamento SNMP podem ser acessados. Um securityName refere-se a
44
um diretor e os direitos de acesso para todos os diretores, em um determinado grupo,
são idênticos. Um único groupName é associado com cada grupo.
� Nível de Segurança: os direitos de acesso para um grupo podem ser diferentes
dependendo do nível de segurança da mensagem que contém a requisição;
� Contextos: é um subconjunto nomeado de instâncias de objetos na MIB local e que
fornecem uma forma útil de agregar objetos em coleções com diferentes políticas de
acesso. O contexto é um conceito que se relaciona ao controle de acesso e possui as
seguintes características chave:
1. Uma entidade SNMP, unicamente identificada por um contextEngineID,
pode manter mais de um contexto;
2. Um objeto ou uma instância de objeto pode aparecer em mais de um
contexto;
3. Quando múltiplos contextos existem, para identificar uma instância de
objeto individual, seus contextName e contextEngineID devem ser
identificados em relação ao seu tipo de objeto e sua instância.
4. Visões MIB: define um conjunto especifico de objetos gerenciados, o
VACM faz uso de uma técnica poderosa e flexível para definir visões MIB,
baseadas no conceito de visões de subárvores e visões de famílias. A visão
MIB é definida como uma coleção, ou família de subárvores, com cada
subárvore sendo incluída ou excluída da visão. Isto significa que, a visão MIB
ou inclui, ou exclui todas as instâncias de objetos contidas na subárvore. Em
acréscimo, uma máscara de visão é definida para reduzir a quantidade de
informação de configuração requerida quando um controle de acesso mais
refinado é requerido.
5. Política de acesso: permite que um motor SNMP seja configurado para
tornar mais sólido um conjunto restrito de direitos de acesso. A determinação
do acesso ou negação do mesmo depende dos seguintes fatores [1]:
� O diretor fazendo a requisição de acesso. O VACM torna possível
para um agente permitir diferentes privilégios de acesso para
diferentes usuários.
� O nível de segurança pelo qual a requisição foi comunicada na
mensagem SNMP.
� O modelo de segurança usado para processar a mensagem
requisitada.
45
� o contexto da MIB usado para a requisição;
� a instância do objeto específica para o qual acesso é requerido.
� o tipo de acesso requisitado (leitura, escrita, notificação).
A primitiva isAccessAllowed define o serviço fornecido pelo subsistema de
controle de acesso. Esta primitiva especifica que os parâmetros de entrada são
securityModel, securityName, securityLevel, viewType, contextName, e variableName.
6.4.2.1 Processamento de controle de acesso
O subsistema de controle de acesso é definido de forma a oferecer uma
ferramenta mais flexível para configurar o controle de acesso no agente, através da divisão
dos componentes de controle de acesso em seis variáveis distintas.
Figura 6.8 - Lógica VACM
A figura 6.8 oferece uma forma simples de analisar as variáveis de entrada e
expõe como as várias tabelas na MIB VACM são usadas para decidir sobre o controle de
acesso:
46
� Quem: o “quem” da operação é definido pela combinação do securityModel e do
securityName; identifica um dado diretor cujas comunicações são protegidas por um
certo securityModel.
� Onde: o contextName especifica “onde” o objeto gerenciado desejado pode ser
encontrado. O vacmContextTable contém uma lista dos contextName reconhecidos;
� Como: a combinação do securityModel e do securityLevel define “como” a PDU
Inform ou request foi protegida.
� Por quê: o viewType especifica porque o acesso é requisitado: para uma operação de
leitura, escrita ou notificação;
� O que: a variableName é um identificador de objeto cujo prefixo identifica um tipo de
objeto específico e cujo sufixo identifica uma instância de objeto específico.
� Qual: a instância de objeto indica qual item específico de informação é requisitado.
Por fim a variableName é confrontada com a visão MIB obtida. Se a
variableName combinar com um elemento incluído na visão MIB, então o acesso é
fornecido.
Agora é possível sumarizar os procedimentos usados pelo VACM para
determinar se o acesso é permitido. Quando isAccessAllowed é invocada por uma
aplicação, o VACM realiza os seguintes passos figura 6.9:
1. confere se há uma entrada no vacmContextTable para o contextName. Se
houver, então este contexto é conhecido por este motor SNMP. Se não houver
então um errorIndication de noSuchContext é retornado;
2. confere o vacmSecurityToGroupTable para determinar se há um grupo
associado a este par <secutityModel, securityName >. Se houver, então este diretor
operando sob este securityModel é um membro de um grupo configurado neste
motor SNMP. Se não houver, então um errorIndication de noGroupName é
retornado;
3. examina em seguida o vacmAccessTable usando groupName, contextName ,
securityModel, e securityLevel como índices. Se uma entrada for encontrada, então
uma política de controle de acesso foi definida para este groupName, operando sob
este securityModel, neste securityLevel, para acessar este contextName. Se não for
encontrada uma entrada, então um errorIndication de noAccessEntry é retornado;
4. determina então se a entrada vacmAccessTable selecionada inclui uma
referência a uma visão MIB de viewType. Se houver uma referência, então esta
47
entrada contém um viewName para esta combinação de groupName, contextName,
securityModel, securityLevel, e viewType. Se não houver uma referência, então um
errorIndication de noSuchView é retornado;
5. O viewName é usado como um índice na vacmViewTreeFamilyTable . Se uma
visão MIB for encontrada, então uma visão MIB foi configurada para este
viewName. Caso contrário, um errorIndication de noSuchView é retornado;
6. verifica a variableName contra a visão MIB selecionada. Se esta variável está
incluída na visão, então uma statusInformation de accessAllowed é retornada; Se
esta variável não estiver incluída na visão, então um errorIndication de noInView é
retornado.
Figura 6.9 - Fluxograma VACM
Entrada de acesso encontrada?(vacmAccessTable)
sim
sim
sim
Checar visão(vacmViewTreeFamilyTable)
Checar variável(vacmViewTreeFamilyTable)
accessAllowed
Checar tipo de visão(vacmAccessTable)
noSuchContext
noGroupNamenão
nãonoAccessEntry
não
leitura gravação notificação
noSuchView
noSuchView
notInView
O Grupo esta disponível?(vacmSecuritytoGroupTable)
Contexto esta disponível?(vacmContextTable)
48
6.4.2.2 A MIB VACM
A MIB VACM inclui informações nas seguintes series:
� Contextos locais: a vacmContextTable relaciona os contextos localmente disponíveis
por nome; esta informação é utilizada por aplicações geradoras de comandos para
configurar a vacmAccessTable e para controlar o acesso a todos os contextos na
entidade SNMP.
� Grupos: esta vacmSecurityToGroupTable fornece um groupName dado um
securityModel e um securityName. O groupName é utilizado para definir uma política
de controle de acesso para um grupo de diretores sob um dado modelo de segurança;
� Direitos de acesso: a vacmAccessTable pode ser configurada para definir direitos de
acesso para grupos.
� Visões MIB: a estrutura vacmMIBView consiste de um único objeto escalar:
vacmViewSpinLock, e uma tabela: vacmViewTreeFamilyTable . O objeto
vacmViewSpinLock, habilita as aplicações geradoras de comandos a coordenarem seus
usos da operação Set através da criação e modificação de visões. Pode haver múltiplas
subárvores associadas com um dado viewName, caso no qual a visão MIB para este
viewName consiste da união de todas estas subárvores. Cada entrada na
vacmViewTreeFamilyTable define uma família de subárvores MIB, usando a
subárvore, a máscara, e o tipo de objetos da coluna
A configuração inicial da MIB VACM é proposta pela RFC 2275 e sugere que
a configuração seja feita durante a instalação de um novo Motor SNMP que suporte o
VACM e, ainda, define três possíveis configurações iniciais [1]:
� Configuração inicial sem acesso;
� Configuração inicial semi-segura;
� Configuração inicial com segurança mínima.
Na configuração inicial sem acesso, não é admitida nenhuma configuração
inicial e nenhum acesso às variáveis MIBs locais durante a instalação do sistema. Para os
outros dois casos existi uma diferença apenas nas entradas da vacmViewTreeFamilyTable.
As demais entradas: vacmContextTable, vacmSecurityToGroupTable, e vacmAccessTable
são iguais para estas duas configurações.
49
7. MONITORAMENTO REMOTO DE REDES (RMON)
O sistema de monitoramento RMON tem por função padrões de interface e
monitoração possibilitando a comunicação entre gerentes/agentes SNMP. É uma extensão
o SNMP, monitora a rede como um todo e não apenas seus componentes individuais. O
RMON opera enxergando cada pacote da rede, podendo com isso estabelecer estatísticas
de erro, colisões e outros. Possibilita o armazenamento de partes de pacotes ou pacotes
inteiros permitindo se necessário analise futura.
Na RFC 1757 são definidas as seguintes funções para RMON:
� Operação Off-line: tem por função se necessário para limitar ou parar a rotina de
polling, ou seja, Polling limitados reduzem custos de comunicação.
� Monitoramento preemptivo: No caso de uma falha na rede, permite a notificação à
estação gerente da falha e apresenta informações importantes no diagnostico da falha.
� Detecção de problemas e relatório: baseia numa vigilância continua da rede, o monitor
pode facilmente detectar certas condições de erro e outros problemas.
� Analise de Dados: o monitor pode executar analises específicas para os dados
coletados na sub-rede, aliviando, com isso a estação de gerenciamento.
� Múltiplos gerentes: uma configuração de rede pode ter mais que uma estação gerente.
Melhorando a confiabilidade no desempenho de diferentes funções, e para fornecer
capacidade de gerenciamento em diferentes unidades na organização.
7.1 CONTROLE DE MONITORES REMOTOS
Um monitor remoto pode ser implementado quer como dispositivo dedicado
quer como uma função disponível em um sistema de processamento e, com esses recursos
dedicados, o mesmo é capaz de executar funções complexas. A MIB RMON contém
funcionalidades que suportam controle extensivo da estação de gerenciamento e se
dividem em duas categorias, a saber:
� Categoria Configuração: o monitor remoto normalmente precisara ser configurado para
coletar dados. Esta configuração especifica o tipo de dados para serem coletados.
� Categoria Invocação de ação: O SNMP providencia mecanismos não específicos para
emitir um comando para um agente executar uma ação, tendo apenas capacidade de ler
valores de objetos e identificar valores de objetos com visão MIB.
50
7.1.1 Múltiplos gerentes
Um agente RMON pode ser submetido a múltiplos gerentes, com isso, várias
dificuldades podem surgir:
� Requisições concorrentes podem exceder a capacidade do monitor para fornecer estes
recursos;
� Uma estação gerente pode capturar e ocupar recursos de monitor por um longo
período de tempo, prevenindo seu uso por outras funções gerente desejadas por outras
estações gerentes.
� Designação de recursos para uma estação gerente que caiu sem liberá-los.
Para superar com esses problemas, é necessária uma combinação de
característica de resolução e prevenção:
� Reconhecimento pela estação gerente de recursos que possui e que já não necessita;
� Identificação pelo operador de rede da estação gerente que possui um determinado
recurso ou função e negocia-os para que o recurso ou função a seja liberado;
� Um operador de rede pode ter a permissão para liberar recursos unilateralmente que
um outro operador de rede tenha reservado.
A especificação RMON sugere que o rótulo proprietário contenha um ou mais:
IP, nome da estação gerente, nome do gerente da rede, localização ou número de telefone.
Contudo o rótulo ser vantajoso, é importante mencionar que o rótulo não tem efeito como o
de uma senha ou mecanismo de controle de acesso.
7.1.2 Gerência de Tabela
Na especificação RMON inclui um conjunto de convenções textuais e regras
procedurais que não violam ou modificam o quadro SNMP, proporcionando uma técnica
clara e disciplinada para se adicionar ou excluir registros. Estes procedimentos são:
� Convenção Textual: na especificação RMON são definidos dois novos tipos de dados:
OwnerString::= DisplayString
EntryStatus::= INTEGER { valid (1),
creatRequest (2),
underCreation (3),
invalid (4) }
51
� Adição de Registro: um SetRquest PDU emitido inclui uma lista de objetos tabulares
identificados na tabela. Cada objeto é identificador de instância, consistindo do
identificador do objeto seguido pelo valor do índice ou índices para aquela tabela
� Modificação ou Deleção de Registro: um registro é excluído selecionando-se o valor
de status na opção inválido.
7.1.3 MIB RMON
Uma MIB RMON é identificada na figura 7.1 e é formada por dez grupos
distintos:
� Grupo Estatísticas: Mantém utilização baixo nível e estatística erro de cada sub-rede
monitorada pelo agente.
� Grupo Histórico: registra amostras de estatísticas da informação disponível no grupo
estatística.
� Grupo Alarme (Alarm): permite ao usuário definir um intervalo de amostragem e um
alarme limiar para qualquer contador registrado pelo gerente.
� Grupo Host: contém contadores de diversos tipos de tráfego para e de servidores e
agregados a sub-rede.
� Grupo HostTopN: contém estatísticas que relatam nos servidores que alcançam uma
lista baseada em alguns parâmetro no grupo host.
� Grupo Matriz (Matrix): apresenta erros e informações no formato matriz, assim
possibilita ao operador reaver informações de qualquer par de endereço da rede.
� Grupo Filtro (Filter): possibilita ao monitor observar pacotes. Pode capturar todos os
pacotes que passem pelo filtro ou apenas gravar estatísticas baseadas nos pacotes.
� Grupo Pacote de Captura (Capture): determina como os dados serão enviados ao
console gerente.
� Grupo Eventos (Event): fornece uma tabela de todos os eventos gerados pelo agente
RMON.
� Grupo TokenRing: Mantêm estatísticas e informações de configuração para sub-redes
TokenRing.
52
Figura 7.1 - Grupos MIB RMON
7.2 RMON 2
A extensão da especificação RMON MIB iniciou-se em 1994 com o objetivo de
incluir a inspeção de tráfego acima do nível MAC, que se refere ao RMON2, o qual define
um caminho baseado em uma estação de gerenciamento SNMP para coletar estatísticas de
rede remota a partir de dispositivos probe colocados em segmentos estratégicos da rede.
RMON2 decodifica pacotes em camadas 3 a 7 do modelo OSI como
representado na figura 7.2. Isto tem duas implicações importantes.
� Pode monitorar o tráfego com base no protocolo da camada de rede e endereços,
incluindo o Internet Protocol (IP).
� Pode decodificar e monitorar o tráfego na camada de aplicação, como e-mail,
transferência de arquivos e protocolos World Wide Web.
Estas duas capacidades são importantes e serão analisadas separadamente.
7.2.1 Nível de Rede
Um RMON probe pode monitorar todo o tráfego nas LANs, capturando quadros
do nível MAC e ler origem e destino nesses quadros, pode também fornecer informações
detalhadas do nível MAC e o tráfego para host anexado a LAN. Tem a capacidade de ver
53
acima do nível MAC lendo o cabeçalho do protocolo de camada de rede anexado, que é
caracteristicamente IP. Isso permite que o probe possa analisar o tráfego que passa pelo
roteador para determinar a origem e o destino final.
7.2.2 Nível de Aplicação
Um RMON2 probe não está limitado a monitorar e decodificar o tráfego na
camada de rede. Também pode visualizar um protocolo da camada acima e rodar em cima
do protocolo de camada de rede. Em particular, um RMON2 probe é capaz de ver acima da
camada IP lendo os cabeçalhos fechados de nível superior, tal como TCP e visualizar os
cabeçalhos de protocolo nível de aplicação.
Com RMON2, uma aplicação de gerência de rede pode ser implementado para
gerarem gráficos e imagens relativas ao percentual de tráfego por protocolos ou por
aplicações, sendo útil no controle de carga e mantendo o desempenho da rede.
Figura 7.2 - Relação OSI X RMON
7.2.3 MIB RMON2
A MIB RMON2 é uma extensão da RMON MIB que acrescenta uma série de
novos grupos. A figura 7.3 à pág. 54 mostra a estrutura completa da combinação MIB
RMON1 e RMON2. Resumidamente os grupos são:
� Protocol directory (protocolDir): é um diretório mestre contendo um inventário de
informações sobre todos os protocolos que a probe pode interpretar.
Protocol distribution (protocolDist): recolhe estatísticas agregadas sobre a distribuição do
tráfego gerado por cada protocolo, por segmento LAN.
54
� Address map (addressMap): cada endereço corresponde a um determinado endereço
MAC e a porta de um dispositivo e acompanha o endereço físico na sub-rede
Figura 7.3 - RMON MIB
� Network layer host (n1Host): Monitora pacotes sobre o tráfego de entrada e saída dos
hosts, com base no endereço de camada de rede.
� Network layer matrix (n1Matrix): coleta de estatísticas sobre pares de hosts baseado no
endereço de camada de rede.
� Aplication layer host (a1Host): detém uma recolha de estatísticas de um protocolo a
partir de um determinado endereço de rede que foi descoberto em uma interface deste
dispositivo.
� application-layer matrix (a1Matrix): lida com a recolha de estatísticas sobre pares de
hosts baseado no protocolo da camada de aplicação.
� User history collection (usrHistory): periodicamente coleta amostras de variáveis de
um usuário especificado e registram os dados, com base em parâmetros definidos pelo
usuário.
� Probe configuration (probeconfig): define parâmetros para o padrão de configuração
RMON probe.
Estes novos grupos tornam possível a visualização padrões de tráfego a nível de
rede (OSI camada 3). Eles também tornam possível compreender protocolo e aplicação
associados à utilização da rede como um todo, bem como cada nó.
55
8. FERRAMENTAS PARA GERENCIAMENTO DE REDES
8.1 HP OPENVIEW
Elaborado e desenvolvido pela Hewlett-Packard Company, e constituído por
um conjunto de programas que proporcionam o gerenciamento distribuído das redes. O HP
OpenView possibilita o gerenciamento em qualquer tamanho de rede e se adaptam
rapidamente as mudanças no ambiente, mantendo as informações seguras, permitem que
dados críticos de negócios e serviços estejam disponíveis a qualquer tempo. As aplicações
da HP permitem as organizações melhorarem a performance da estrutura permitindo
antecipar e corrigir problemas antes que se tornem críticos. Algumas das soluções de
gerenciamento HP OpenView são: OpenView Network Node Manager, OpenView
Repórter, OpenView Operations, OpenViewNavigator, OpenView Service Desk,
compartilham um objetivo comum que é o de fornecer um conjunto de serviços
indispensáveis que possibilitem as bases para uma gerência de ambientes heterogêneos.
Limita-se a: gerenciamento de falhas, configuração e performance das redes TCP/IP.
8.1.1 Gerenciamento de Falhas
� Define status da rede e de dispositivos conectados a ela.
� Se um recurso apresenta um limite considerado critico, o gerente emite relatórios
automaticamente;
� Possibilita a recuperação de informação;
� Disponibiliza e armazena informações sobre a topologia da rede;
� Provimento de ferramentas que traçam o perfil da rede em condições normais;
56
Figura 8.1 – Tela Service Desk – Gerência de Falhas
8.1.2 Gerenciamento de Configuração
� De forma automática o gerente guarda a topologia da rede e busca por novos
dispositivos instalados;
� Instala novos objetos e os adiciona no inventário de controle;
� Relaciona todos os serviços remotos da rede;
� Fornece mapas da rede;
� Restaura informações básicas de gerenciamento;
57
Figura 8.2 - Tela Segment - Gerencia de Configuração
8.1.3Gerenciamento de Performance
� Acompanha o funcionamento da rede e apresenta vários formatos e combinações;
� Coleta informações sobre varias MIBs para formar um histórico de dados;
� Fixa os limites sobre as MIBs e detém informações sobre taxas de erros e Throughput;
� Monitora os recursos do sistema com a carga relativa do sistema;
� Utiliza os recursos de coletar dados e gerar gráficos para reunir informações,
identificando, assim, se o sistema esta sendo utilizado de forma racional.
58
Figura 8.3 – Tela Operations Gerência de Performance
8.2 CISCO WORKS
O CiscoWorks é uma família de aplicativos de gerência - padrões Java, XML,
web server, CORBA e SNMP - desenvolvida pela CISCO para prover ao usuário
ferramentas capazes de detectar falhas, realizar contabilidade de uso, avaliar performance,
monitorar e estabelecer segurança e configurar, graficamente, os equipamentos Cisco nas
redes LAN, Wireless e WAN[2]. Com este objetivo o CiscoWorks contém aplicativos e
dispositivos dedicados para: gerência de voz, qualidade de serviço, Redes Virtuais
Privadas (VPNs), topologia, controle de usuário, VLANs, monitoramento de aplicações,
detecção de intrusos, gerência de firewalls, inventário, decodificação de protocolos e SLA
(Supplemental License Agreement), entre outros.
Algumas das ferramentas de software de gerência CiscoWorks são:
� CiscoView → apresenta através de gráficos o status on-line dos dispositivos, com
estatísticas de utilização;
� Resource Manager Essentials → possibilita o inventário dos softwares e
equipamentos da rede; e
� Campus Manager → fornece a topologia gráfica da rede com sinalização e alarmes
para o estado atual do dispositivo.
Comercialmente, existem vários pacotes da família CiscoWorks, a saber:
59
� LAN Management Solution (LMS) → conjunto de ferramentas de software para
gerência da rede local;
� Routed WAN Management (CWRW) → conjunto de ferramentas de software para
gerência da rede de roteadores; e
� Cisco VPN Security Management Solution (VMS) → conjunto de ferramentas de
software para gerência da segurança da rede fim-a-fim.
8.2.1 Gerenciamento de Falhas
� Possibilita entre dois equipamentos análise de roteamento, coletando dados de
utilização e erros.
� Possui um sistema de monitorização e resolução de problemas;
� Possibilita a emissão de relatórios de mensagens de syslog filtradas para isolar erros de
roteadores e switches Cisco;
� Emprega o modelo VISTA (visão, isolação,solução, teste e aplicação) para automatizar
o diagnostico e solução de problemas.
8.2.2 Gerenciamento de Configuração
� Permite instalar remotamente um roteador novo utilizando um roteador vizinho.
� Possui um repositório central para todo o software Cisco.
� Institui e sustenta um banco de dados que armazena um inventário completo da rede:
hardware, software, versões de componentes operacionais, responsáveis por
manutenção de dispositivos e locais associados.
� Informações homogêneas compartilhadas como senhas e listas de acesso podem ser
configuradas para serem aplicadas automaticamente para um grupo comum de
equipamento.
8.2.3 Gerenciamento de Contabilização
� Relatório de estatísticas de tráfego: apresentam estatísticas relacionadas ao
desempenho e custo / eficácia da rede.
� Atribuição de custo: permite um charge-back de custos de chamadas para as pessoas,
unidades organizacionais, ou locais responsáveis por eles e para conciliar as
60
declarações de prestadores de serviços de rede. Encargos adicionais podem ser
atribuídas a cada conta, como única de encargos para a instalação ou contínua
cobranças de qualidade de serviço (QoS) ou a utilização de equipamento.
Gerenciamento de diretório: é uma base de dados contendo informações sobre pessoas,
locais e Equipamentos.
� Registro de chamada e exibição de manutenção: permitem criar relatórios de registros
de chamada, e dividir os custos das contas.
8.2.4 Gerenciamento de Performance
� Fornece um parecer sobre as condições de uso dos dispositivos, incluindo buffers,
carga de CPU, memória disponível e protocolos/interfaces.
� Reúne dados históricos da rede para análise off-line de tendências de desempenho e
padrões de tráfego. Com o SQL do Sybase projetado para variáveis SNMP é possível
fazer consultas e gerar gráficos.
� Possibilita rapidez e facilidade para localizar roteadores para atualização.
� Expõe graficamente uma visão dos dispositivos físicos Cisco e informação como
estado dinâmico, estatística e de configuração dos switches, roteadores, hubs,
servidores de acesso, concentradores e adaptadores Cisco.
8.2.5 Gerenciamento de Segurança
� Configura métodos de segurança para aplicações e equipamentos de rede selecionados
contra invasões, possibilitando segurança ao ambiente CiscoWorks através de pedido
de login/senha.
� Para processos de atualização faz uso das funcionalidades da memória flash de
roteadores Cisco.
� Oferece uma ferramenta que detecta mudanças de configuração na rede e informa os
responsáveis e a data que da mudança aconteceu.
� Apresenta uma visão ampla do roteador/LAN e do caminho do tráfego percorrido por
ele, verifica a integridade do domínio.
61
8.3 NAGIOS
Nagios é uma solução Open Source de monitoramento de serviços de rede. Ele
verifica constantemente a disponibilidade do serviço, seja local ou remoto, alertando caso
existam anormalidades nos mesmos. Todo monitoramento é feito por meio de plugins -
programas usados sob demanda tais como: executáveis, compilados ou scripts (Perl, shell,
etc.) - sem os quais o Nagios não tem utilidade.
Esta ferramenta permite ao administrador de rede definir os níveis de alerta da maneira que
lhe convir. Dessa forma é possível tratar os problemas antes que eles aconteçam e
configurar ações proativas e/ou corretivas para os problemas ocorridos na rede. É possível
gerar relatórios gráficos de disponibilidade dos serviços e máquinas, e administrá-los via
interface web.
Principais Características:
� Capacidade de monitorar protocolos (SMTP, POP3, HTTP, ICMP, SNMP).
� Monitora recursos de computadores ou equipamentos de rede (carga do processador,
uso de disco, logs do sistema) na maioria dos sistemas operacionais com suporte a rede.
� Através de túneis SSH ou SSL possibilita monitoração remota
� Checagem dos serviços simultaneamente.
� Oferece serviço de notificação quando um componente ou serviço de rede apresentar
problema.
� Permite a definição de tratadores de eventos que executam tarefas em situações pré-
determinadas ou para a resolução pró-ativas de problemas.
� Rotação automática de log.
� Apoio à de implementação de monitoração redundante.
� Interface web otimizada permitindo o acompanhamento do status da rede, das
notificações, do histórico de problemas, e arquivos de log gerados, entre outros.
O Nagios é um software que monitora remotamente os recursos de hosts, tais
como sua carga de processamento, utilização de memória, tempo de resposta, utilização de
banda, etc. Esta ferramenta possui ambiente WEB capaz de gerar mapas da rede, relatórios
e gráficos on-line e, também, notificar os administradores sobre anomalias na rede ou hosts
sob supervisão.
Algumas características do Nagios:
� Monitora serviços de rede;
� Monitora recursos de hosts;
62
� Define hierarquia da rede;
� Sistema inteligente de notificações;
� Alertas para pagers, e-mail, celular, etc.;
� Possibilidade de implementação de servidores de monitoramento distribuídos e
redundantes;
� Interface WEB capaz de informar sobre status de redes, hosts, serviços, logs,
notificações, mapas da rede 2D e 3D;
� Relatórios, integrações com BDs, etc.
8.3.1 Gerenciamento de Falhas
� Em curto espaço de tempo detecta a causa real do problema e corrigir a situação;
� Os 'grupos de contato' – são notificados sobre circunstancias ou eventos (falhas,
recuperação, advertências, etc.).
Figura 8.4 - Tela Alert History Gerência de Falhas
63
8.3.2 Gerenciamento de Performance
� verifica a quantidade de perda de pacotes, a latência e o índice de disponibilidade do
Backbone;
� verifica serviços de rede individuais tais como HTTP, SMTP e DNS e, também,
processos por meio da execução de carga da CPU ou arquivos de log;
� Permite monitoração distribuída pela qual, várias instalações descentralizadas ao
enviar os resultados de seus testes para um ponto central, permitindo uma panorâmica
geral da situação, a partir de um ponto único.
� Diminui a carga no servidor de monitoramento com o redirecionamento de resultados
para o servidor central.
Figura 8.5 Tela Performance Information - Gerência de Performance
8.3.3 Gerenciamento de Configuração
� monitoramento adaptativo – faz mudanças do ajustes de monitoramento sem que
necessite reinicialização do Nagios;
64
� herança de definições de objetos – o tempo de configuração é reduzido facilitando
suas modificações;
� tratamento de eventos – quando ocorrem mudanças no estado de serviço comandos
opcionais executados;
� escalonamento de notificações – possibilita a criação de uma hierarquia de
notificações, onde todos os contatos inferiores recebem cópias das notificações
enviadas aos superiores;
Figura 8.6 - Tela Configuration Gerência de Configuração
8.4 TIVOLI NETVIEW
O programa Tivoli NetView é uma ferramenta de gerência para fornecedores
heterogêneos de dispositivos de redes TCP/IP, que fornece funções de gerenciamento de -
configuração, falhas, segurança e performance - em conjunto com muitos outros atributos e
recursos que possibilitam sua fácil instalação e uso.
O programa permite o gerenciamento de diversas arquiteturas e sistemas
operacionais tais como UNIX, Windows e OS/390 e possui recursos tais como: descobrir
redes TCP/IP, mostrar topologias de rede, correlacionar e gerenciar eventos e traps SNMP,
65
monitorar a saúde da rede e recolher dados de desempenho, além de poder integrar
aplicações multiprotocolo com o programa Tivoli NetView e topologias multiprotocolo
com submaps TCP/IP. Além disso, Tivoli NetView fornece uma plataforma aberta de
gerenciamento de rede que permite a integração das aplicações SNMP com o protocolo
Common Management Information Protocol (CMIP). O programa é capaz de gerenciar
MIBs SNMP incluindo MIBs multiprotocolo de outros fornecedores. Adicionando-se esses
objetos MIB à base de dados SNMP MIB existentes significa que um administrador, o
programa Tivoli NetView, pode gerenciar fornecedores distintos, dispositivos de redes
heterogêneos e, também, prover suporte para o gerenciamento de dispositivos que não
possuem um endereço IP.
Para o gerenciamento cooperativo de redes TCP/IP, o Tivoli NetView utiliza o
programa AIX NetView Service Point para se comunicar com o Tivoli NetView para
OS/390 e o dispositivo de monitoramento gráfico.
O programa Tivoli NetView é uma ferramenta de gerenciamento de redes e de
sistemas, que possibilita o gerenciamento de uma rede de forma centralizada ou distribuída
e, também, com capacidade de ser integrado a outras aplicações Tivoli.
8.4.1 Arquitetura de Gerenciamento Distribuído
Atualmente no ambiente de redes há uma sobrecarga de informação devido ao
aumento do numero de recursos SNMP na rede enviando pacotes de informações
para o ponto central de gerenciamento. O programa Tivoli NetView permite uma
introdução ao aplicativo de Gerenciamento distribuído de rede, Tivoli Enterprise, por meio
da utilização do Tivoli NetView Mid-level Manager (MLM).
O MLM nos permite mover o monitoramento de sistema, monitoramento de rede e
o gerenciamento de rede - da plataforma central de gerenciamento de rede (o nó gerenciado
Tivoli com o Tivoli NetView instalado) para um gerente base SNMP intermediário (o Mid-
Level Manager) instalado em qualquer máquina TCP/IP de sua rede. As tarefas realizadas
pelo Mid-Level Manager incluem o seguinte:
� Descoberta de novos nós e o status polling de nós correntes;
� Eventos de monitoração automática de eventos e ajustes de limites (treshold);
� Detecção automática de dispositivos novamente adicionados ou recentemente
excluídos.
66
Essas características de gerenciamento reduzem a quantidade de tráfico de rede
criado pelo sistema de gerenciamento e minimiza o elevado resultado administrativo
associado com os sistemas de gerenciamento de redes. Além disso, muitos problemas são
resolvidos por meio da automação local, portanto, reduzindo a carga de trabalho
administrativo quanto ao adicionar e eliminar nós.
A figura 8.7 mostra dois nós Mid-level Manager configurados para monitorar
um conjunto de dispositivos SNMP na rede. Esses nós Mid-level Manager podem ser
agrupados por localização, função, tipo ou qualquer outro grupo conveniente para melhor
distribuir o gerenciamento de sua rede.
Figura 8.7 - Arquitetura do gerenciamento distribuído Tivoli
8.4.2 Gerenciamento De Falha
O NetView tem funções para ser proativo, auxiliar na determinação e
identificação de problemas na rede e fornecer mecanismos para recuperação de erros o
mais rapidamente.
As seguintes definições de eventos são utilizadas:
� Eventos de Mapa são notificações enviadas ao servidor NetView por causa de um
usuário ou ação que afete o status do mapa ou submapa de rede na interface gráfica
NetView;
� Eventos de Rede são mensagens enviadas por um agente ao servidor para prover a
notificação da ocorrência de uma atividade que afete um objeto de rede.
O NetView recebe eventos por meio de dispositivos polling na rede. A figura
8.8 a mostra a Tela de Controle de Eventos Tivoli NetView. Eventos são mostrados quando
67
- ocorrem erros na rede, limites são excedidos, mudanças na topologia de rede,
configuração de nós ou status da rede - e esses eventos são recebidos pelo programa
NetView. NetView pode pesquisar o status dos dispositivos enviando comandos echo
requests (pings) -Internet Control Message Protocol (ICMP) – e requests SNMP aos
dispositivos. Em grandes redes contendo muitos objetos e agentes, muitos dos eventos que
o servidor NetView possa ser requisitado para processar, podem ser enviados. Pode-se
reduzir significativamente a quantidade de tempo requerida pelo servidor NetView para
processar a entrada de eventos, filtrando e descartando aqueles eventos que não são
importantes para sua operação.
Também, usando as capacidades de filtragem e correlação do NetView, você
pode selecionar eventos que você quer que sejam mostrados na tela. Critérios de filtragem
podem ser aplicados para inventariar informações recebidas da rede selecionando-se
apenas eventos específicos para serem mostrados na interface gráfica conforme mostrado
na 8.8. Conjuntos de regras de correlação podem ser definidos para correlacionar ou
comparar entradas de eventos ao evento de processamento de decisões e ações. A Figura
8.9 mostra um exemplo de um conjunto de regras de correlação que correlaciona dois
eventos.
O software NetView possui várias ferramentas para diagnosticar problemas de
conectividade em sua rede, as quais podem auxiliar na rápida solução de problemas. Por
meio da seleção do apropriado cartão de eventos, é possível obter informações relevantes
sobre o dispositivo defeituoso, tais como descrição do problema, localização e contato com
o fornecedor. Adicionalmente, a partir de um mapa de topologia, é possível selecionar nós
e escolher itens de menu, de um mapa de topologia.
Figura 8.8 - Tela de Controle de Eventos
68
Figura 8.9 – Tela Correlação de Conjunto de Regras
8.4.3 Gerenciamento de Configuração
As aplicações de gerenciamento de configuração NetView provêem uma
atualização dinâmica das topologias de rede. O NetView automaticamente descobre sua
rede e atualiza os mapas ou submapas de rede. Esta característica de descoberta pode
apresentar várias formas:
� O programa NetView pode descobrir todos os elementos endereçáveis IP, na rede.
� O NetView pode fazer uso de um arquivo origem que define os conjuntos iniciais de
nós IP endereçáveis a serem descobertos.
� Pode-se limitar a descoberta de redes para selecionar nós ou sub-redes.
O programa continuamente encontra novos dispositivos e nós e como eles são
adicionados à rede e determinam quais dispositivos tem sido excluídos da rede. Este
processo de continuo descobrimento assegura que o mapa da topologia de rede na console
do NetView, conforme mostrado na figura 8.10, é sempre o mais atual. Quando um novo
nó é descoberto, ele é adicionado à base de dados da topologia e na lista de nós que está
sendo monitorada. Se o nó, recém descoberto, suporta um agente SNMP, informações
sobre a sua configuração de sistema são recuperadas obtendo-se valores MIBs e
armazenando-as na base de dados.
O NetView pode ser configurado para trabalhar com uma base de dados de
relações e, a partir desta, utilizar qualquer uma das ferramentas, disponíveis para a base de
dados de relações, para criar relatórios sobre os dados da topologia IP e os nós em sua
69
configuração de rede. Em havendo dispositivos que não possam ser descobertos
dinamicamente na rede, o programa edita manuais de suporte dos mapas de rede para
permitir a representação desses dispositivos. Caso seja necessário acrescentar, apagar,
mover ou transferir objetos entre mapas, estes podem ser salvos para o planejamento de
futuras configurações e diagnosticar problemas de rede.
O programa também possui aplicações especiais de gerenciamento de rede que
utilizam protocolos diferentes do IP. Informações obtidas por essas aplicações e
armazenadas na base de dados da topologia geral podem ser exibidas em um submapa
juntamente com a informação sobre nós de rede IP.
Figura 8.10 – Tela Mapa de topologia de rede
8.4.4 Gerenciamento de Desempenho
O NetView possui várias funções que permitem verificar o desempenho de sua
rede, como:
� A coleta de estatísticas da rede em tempo real e mostrá-las em formato gráfico.
� Definir limites de áreas críticas de desempenho da rede e configurar o programa para
verificar esses limites, por meio de polling dos nós, em intervalos especificados e gerar
traps se os mesmos forem ultrapassados.
� Utilizar a função coleta de dados MIB, do NetView, para obter informações específicas
tais como utilização da CPU e o tráfico de interface na rede, de nós que contenham um
agente SNMP em execução.
70
A coleta de dados MIB ajuda a planejar o uso da rede e recursos do computador
assim como isolar falhas na rede e problemas de performance. O coletor de dados MIB
continuamente coleta dados e monitora dispositivos, ou conjunto de dispositivos, na rede
com base nos parâmetros de polling configuráveis. O NetView pesquisa os nós da rede para
obter informações sobre elementos numéricos MIB dos dispositivos SNMP, podendo
acessar essas informações tão logo elas tenham sido coletadas. O coletor de dados MIB
verifica os limites para os dados coletados e pode editá-lo como um evento, se um limite
tenha sido excedido. Tivoli NetView disponibiliza aplicações que permitem ao usuário
monitorar o desempenho da rede em tempo real e, também, fornece uma ferramenta, o
construtor de aplicações MIB, o qual nos habilita a construir nossas próprias aplicações de
monitoração de rede.
8.4.5 Gerenciamento da Segurança
Os programas Tivoli NetView de serviços de gerenciamento da segurança criam
um contexto confiável para a comunicação entre o servidor e os gerentes Mid-Level. Por
meio destes serviços é possível definir uma política de segurança para a rede e controlar o
acesso de usuários ao NetView e suas aplicações. Os serviços de segurança deste programa
possibilitam:
� Identificação e autenticação de rede;
� Rede protegida na comunicação entre o servidor NetView e os Mid-Level Managers;
� Senhas de proteção;
� Auditoria continua do gerenciamento de rede;
� Recursos NetView de controle de acesso à rede;
� Interface gráfica NetView, customizada de acordo com os direitos dos usuários;
� Auditoria do gerenciamento.
Os serviços de segurança autenticam cada usuário onde o mesmo utiliza um
comando login cadastrando um conjunto ID válido, grupo ID e senha. Se a senha fornecida
pelo usuário se enquadra na senha codificada na base de dados de segurança, é concedido
ao mesmo o acesso às funções predefinidas no NetView. Por meio de uma política de
segurança apropriadamente definida, é feito o controle de acesso de usuário às funções
NetView, aplicações, mapas ou submapas.
74
FCAPS Ferramenta
Falhas Configuração Contabilização Performance Segurança
HP
OpenView
� Recupera informação; � Define status dos
dispositivos da rede
� Mapas de rede; � Instala novos objetos
e os adiciona no inventário de controle
� Monitora carga relativa do sistema;
� Coleta dados e gera gráficos X
Cisco Works
� Análise de rotas entre dispositivos;
� Sistema de monitoração e resolução de problemas.
� Instalação remota de equipamentos;
� Repositório central para todo o software da CISCO.
� Análise de custo eficácia da rede;
� Análise de custos por departamento
� Informações sobre o estado dos dispositivos;
� Análise off-line de padrões de tráfego.
� Detecta mudanças de configuração não autorizadas na rede;
� Utiliza login e senha.
Nagios
� Detecta causa real do problema e corrigir a situação;
� “Grupos de contatos” recebem informações sobre as condições da rede.
� Monitoramento adaptativo;
� Herança de definições de objetos.
� Verifica a perda de pacotes, a latência e a disponibilidade do backbone;
� Reduz a carga no servidor de monitoramento.
Tivoli
� Eventos de mapa; � Eventos de rede
� Atualização dinâmica da topologia da rede;
� Descobre todos os elementos endereçáveis IP, na rede.
� Estatísticas em tempo real mostrada em gráficos;
� Define limites críticos de desempenho da rede.
� Senhas de proteção; � Interface gráfica
customizada de acordo com direitos dos usuários.
Tabela 8.1 – Comparativo de Recursos de cada Ferramenta
75
9 CONCLUSÃO
Mostrou-se que o gerenciamento de redes heterogêneas é realizado de maneira simples e
eficaz com uso do protocolo SNMP, pois este proporciona centralização dos recursos da
rede agregando facilidades para os administradores permitindo que um local somente possa
gerenciar uma rede fisicamente separada e, também. Suas funcionalidades foram corrigidas
e otimizadas nas versões posteriores.
Uma das principais vantagens do SNMP é a simplicidade que este protocolo apresenta; tal
condição pode ser verificada no modo de operação e extensibilidade, pois, as MIBs
permitem ser alteradas para a adequação perante novas realidades. A centralização de
informações proporciona aos administradores da rede o domínio de todos os equipamentos
da rede de um único ponto e a integração entre equipamentos e fabricantes diferentes.
No aspecto administração de redes um fator preponderante e tranqüilizador, é o contínuo
investimento por parte das empresas de tecnologia, no desenvolvimento e oferta de
ferramentas cada vez mais sofisticadas e eficazes, principalmente no aspecto segurança da
informação.
Diante do exposto depreende-se que - devido à constante evolução da tecnologia no campo
da informática, acompanhada de correspondente complexidade e diversidade dos
dispositivos empregados para otimizar o desempenho das redes e acompanhada de
crescente utilização - estabelecer um eficaz sistema de gerenciamento é o desafio que se
apresenta.
76
BIBLIOGRAFIA
Stallings William, SNMP, SNMPv2, SNMPv3 and RMON 1 and 2, Editora Addison-Wesley, Third Edition, 1999; Cisco Work, disponível por WWW em 02/04/2008 no endereço http://www.ciscoredacaovirtual.com; Tivoli NetView, disponível por WWW em 04/04/2008 no endereço http://www.ibm.com/software/Tivoli; Nagios disponível por WWW em 08/04/2008 no endereço http://www.nagios.org HP Open View disponível por WWW em 12/04/2008 no endereço http://support.openview.hp.com; Douglas R. Maura & Kevin J. Schmidt, SNMP ESSENCIAL, Editora Campus Ltda., 2001; Gerência de Rede disponível por WWW em 11/02/2008 no endereço http://penta2.ufrgs.br/homegere.htm; Introdução ao Gerenciamento de Redes, disponível por WWW em 07/01/2008 no endereço http://www.rnp.br. RFC 1155 – INTERNET ENGINEERING TASK FORCE – Structure and identification of management information for TCP/IP-based internets, RFC 1155, maio.1990. RFC 1157 – INTERNET ENGINEERING TASK FORCE – Simple Network Management Protocol (SNMP), RFC 1157, maio.1990. RFC 1213 – INTERNET ENGINEERING TASK FORCE – Management Information Base for Network Management of TCP/IP- based internets MIBII, RFC 1213, março.1991 RFC 1757 – INTERNET ENGINEERING TASK FORCE – Remote Network Monitoring Management Information Base, RFC 1757, fevereiro.1995. RFC 2271 – INTERNET ENGINEERING TASK FORCE – An Architecture for Describing SNMP Management Frameworks, RFC 2271, janeiro 1998. RFC 2274 – INTERNET ENGINEERING TASK FORCE – User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), RFC 2274, janeiro.1998. RFC 2275 – INTERNET ENGINEERING TASK FORCE – View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP), RFC 2275, janeiro.1998.
