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.

“Pelas oportunidades dadas.” A Minha Família.” . “Pela força e incentivo.A Deus.

. nesta jornada.AGRADECIMENTOS Agradeço ao meu esposo pela compreensão e incentivo.

os principais aspectos e características inerentes à área de Gerenciamento de Redes. Performance. etc.com qualidade e confiabilidade – na questão do gerenciamento de redes. sua arquitetura. . Em continuidade discorre-se sobre o protocolo SNMP – Simple Network Management Protocol. pois as mesmas são imprescindíveis para se obter o desempenho ótimo .algumas do tipo open source e outras proprietárias – enfatizando-se seus principais recursos. agentes. funções criptográficas. também. tendo em vista que os sistemas informatizados são imprescindíveis nos mais diferentes processos utilizados pelo Homem neste mundo globalizado. MIB (Management Information Base) e SMI (Structure of Management Information). de forma sucinta. implementado pela ISO. formatos. Configuration. e que evidencia as áreas funcionais do gerenciamento de redes e. de significativa importância. mostrando suas características. amplamente utilizado.RESUMO Procurou-se neste trabalho abordar.) incluindo o RMON (Remote Network Monitoring) que é uma evolução do SNMP e possibilita um gerenciamento proativo da rede. Security). funcionalidades e recursos e. Accounting. Encerra-se com a apresentação de algumas das ferramentas mais utilizadas na gerencia de redes . comentando sua evolução por meio das versões SNMPv2 e SNMPv3 (operações suportadas. aborda-se as particularidades da gerencia de redes TCP/IP. Neste contexto. também. estações. inicia-se pelo modelo FCAPS (Fault. limitações.

In this context. agents.some type of open source and other proprietary . Performance. . stations. In continuing talks on the protocol SNMP .with quality and reliability -. it is initiated by the model FCAPS (Fault. which highlights the functional areas of management of networks and also addresses to the particularities of management of networks TCP / IP. implemented by ISO. Security). 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 . widely used. MIB (Management Information Base). functions and resources and. limitations.is emphasizing its main features because they are essential to obtain the optimum performance .ABSTRACT It was addressed in this work. etc. cryptographic functions. Accounting. and SMI (Structure of Management Information). commenting on its evolution through the versions SNMPv2 and SNMPv3 (borne operations. also. 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.the issue of managing networks. showing its features. briefly. Configuration.Simple Network Management Protocol.). its architecture. formats.

........................................26 6..............................................................................................................................................................7 3............................2 Recepção de uma Mensagem SNMP ..................21 5................................................24 5.................2 ARQUITETURA DE GERENCIAMENTO DE REDES................2 GetRequest PDU ........................................................................1 OPERAÇÕES SUPORTADAS PELO SNMPV1 ...............................................23 5....................................................5 GetBulkRequest PDU ..............................................................................................................................24 5...............................3 Protocolo de gerenciamento de redes .....................................................15 4................................................................26 6..............................4 SetRequest PDU .1 Transmissão de uma Mensagem SNMP................................................................................................................................1..................................14 4.........................................3...............................1..........1 2 ÁREAS DE GERENCIAMENTO FCAPS .......25 6 O PROTOCOLO SNMP V3 ..1 Transmissão de uma mensagem SNMPv2 ................1....II LISTA DE TABELAS ........................25 5....................2 2.........................1.............................................................................16 4..................20 5..........................................13 4.....................................................................................................................13 4....8 3..18 4........................................................................................................20 5.................................3 GetRequest PDU ..................3..........................................24 5...........................................................................27 6.......19 4......2 2...................................................9 3...............................14 4..8 3................................ I ABSTRACT...1 GERENCIAMENTO DE FALHAS .....................................................3 GERENCIAMENTO DE CONTABILIZAÇÃO.4 GetNextRequest PDU ........1..................2 Agente de gerenciamento.......................................1 Gerente SNMP tradicional ....................................26 6....................4 2..........................................................10 4 O PROTOCOLO SNMP V1 ................................2 Recepção de uma mensagem SNMPv2 ..............................................................................................8 3.....................5 GERENCIAMENTO DE SEGURANÇA...................19 5 PROTOCOLO SNMP V2............................................................................................1 Entidades SNMP.........................7 Trap PDU .....................................................................................................................VII 1 INTRODUÇÃO ..........................................................................4 2........................................1 Estação de gerenciamento.......................................................................5 Trap PDU ...............................................................................................................1.....21 5...............................................................................................................1........1...................................4 LIMITAÇÕES DO SNMP...............................................................................................2............................................ VI LISTA DE ABREVIATURAS .....................13 4...................................................................................3 ARQUITETURA DO PROTOCOLO DE GERENCIAMENTO DE REDES...................1......3................................................................................................2 Agente SNMP tradicional...........................................................................3................................................................1..............3 GetNextRequest PDU ....................................1......................................3...........................................................4 ESTRUTURA DA INFORMAÇÃO DE GERENCIAMENTO (SMI) .....6 SetRequest PDU ..................................................................................................................................2............................8 InformRequest PDU .................................................................................................................6 3...........................................................................................................3 2...............................................4 3 GERÊNCIA DE REDES TCP/IP .5 MANAGEMENT INFORMATION BASE (MIB) ..........................9 3.............................2 COMUNIDADES E NOMES DE COMUNIDADES ................3.......1........................................................................1.......................1 NORMAS RELACIONADAS AO SNMP.....4 GERENCIAMENTO DE PERFORMANCE ........................................................................................................................................2..........................................................................................................................................3 ESPECIFICAÇÕES DO PROTOCOLO ..........................................1...............................1 ARQUITETURA SNMPV3.29 ..................................................................................................................................................................17 4......SUMÁRIO RESUMO ............1 Formato SNMP...............3...........................................................................................7 3.......................................................1 OPERAÇOES SUPORTADAS PELO SNMPV2 .......19 4.....................................................2 GERENCIAMENTO DE CONFIGURAÇÃO ..................1....................................................................................

......................2......................................................2.....3.2....................................5 Gerenciamento da Segurança.............................................2......................5 Gerenciamento de Segurança........5 Gerenciamento de chaves ........48 7...2 View-Based Access Control Model – VACM ................................53 8...1 Gerenciamento de Falhas...............3 Gerenciamento de Contabilização ...............................................................1......................................4.............................................................1 Autenticação .............................................1..........................................2................................................3..........................55 8....6........4....45 6...........2...........................55 8........4 TIVOLI NETVIEW....52 7........................................................66 8...................3..............................................................................32 6.. User-Based Security Model – USM.......................................60 8...................................................30 6...............3 Gerenciamento de Configuração..........................2 RMON 2 ..............2.............4....52 7....................................................................................2 Gerenciamento de Performance ...........4....68 8.........1....56 8................................................................................................1 Nível de Rede.2 A MIB VACM..............49 7.......................................65 8.....50 7....................................................51 7.........................1 Arquitetura de Gerenciamento Distribuído ...................4..................3 Processamento de mensagens USM ......................................................................................................................................................61 8.........75 BIBLIOGRAFIA...1 Múltiplos gerentes .2 Gerenciamento de Configuração.....................49 7...............................................69 8..........................................................1................................4..................1....................................................................................................4..50 7......................1 Gerenciamento de Falhas....62 8..............................................................................................................................................................................................4.....................................................63 8..........................1 HP OPENVIEW........................................................................3 FORMATO DA MENSAGEN SNMPV3.........................................................................63 8.............4..................................................2........2 Encriptação .....................................................59 8.......................60 8.................................1..............................................................................................1...............2 Gerenciamento De Falha ..................................2 Gerência de Tabela ....................................................................................................3 MIB RMON..............4...............32 6........................59 8........................................................................................................................................58 8........................................................................................................2 APLICAÇÕES SNMP.....70 9 CONCLUSÃO .......................................................1.................................................................................39 6..........................1....................1...........................4......................................................................................................................................................................................1 Gerenciamento de Falhas....................................................................................... MONITORAMENTO REMOTO DE REDES (RMON)...................................................................3 MIB RMON2.................1...................... FERRAMENTAS PARA GERENCIAMENTO DE REDES......................................................................................................................................................................................................................................................................................4 ALGORITMOS CRIPTOGRÁFICOS USADOS PELO SNMPV3 ......4 Gerenciamento de Desempenho ...............................................................................32 6......31 6.....................3Gerenciamento de Performance .....................................................................................59 8.33 6..................................39 6....................4 Processo de descoberta ............................76 ...........................................2 Gerenciamento de Configuração.57 8..........................................4 Gerenciamento de Performance ................................................1.....................................................2 Nível de Aplicação..........................53 7.55 8.................................1 Processamento de controle de acesso .......43 6....................................................2 CISCO WORKS ..3 Gerenciamento de Configuração...................................3 NAGIOS.....2..........................................................................4....................................4....................................................................................................................................................................................2......................34 6............................4......................................1 CONTROLE DE MONITORES REMOTOS ..............................64 8............................

...............................Localização de chave..Estrutura da mensagem................2 ....Gerente SNMPv3 tradicional ............Fluxograma VACM...............4 ......................................9 – Tela Correlação de Conjunto de Regras ..............................................................................................................................31 Figura 6......................................................9 ................................................66 Figura 8.............67 Figura 8.Processamento da mensagem USM: transmissão.......................................Tela Alert History Gerência de Falhas....................Relação OSI X RMON.....6 ..Formato da mensagem SNMPv3.....................................................Formato PDU SNMPv2... ................2 Seqüência de PDU SNMP ......7 .....Gerência de Performance..........................................................3 .............................................................10 – Tela Mapa de topologia de rede...69 .........................8 ...............27 Figura 6...........29 Figura 6................................47 Figura 7.......................................................................................57 Figura 8...................................................8 .............................................14 Figura 4.............................3 .............................36 Figura 6...............22 Figura 5..........1 ..........................30 Figura 6....................................................23 Figura 6....................3 .............................1 MIB-II grupos...............................................64 Figura 8...............................................52 Figura 7..............7 ......................................................................................................................Entidade SNMP (RFC 2271).........................................................................................................4 ....63 Figura 8.................................................................1 ..............Tela Configuration Gerência de Configuração....................................56 Figura 8......58 Figura 8.........................................................2 ....................................................2 .....................2 ..................................Arquitetura do gerenciamento distribuído Tivoli .............................................................................Seqüência de PDU SNMP ..................................................45 Figura 6............................................Agente SNMPv3 Tradicional ...............................68 Figura 8.......35 Figura 6...............................................................................Lógica VACM.........................................Processamento da mensagem USM: recepção......................................1 – Tela Service Desk – Gerência de Falhas ................................................................................54 Figura 8....................................12 Figura 4......................................................................LISTA DE FIGURAS Figura 3......................................................................Gerencia de Configuração .................................................RMON MIB ..........Tela Segment ....17 Figura 5..............................................6 .......................................................................................62 Figura 8.42 Figura 6.......................1 ........5 Tela Performance Information .............Grupos MIB RMON.............................................1 Formatos SNMP .......22 Figura 5..53 Figura 7........................................Tela de Controle de Eventos...........................5 ...................................................................................3 – Tela Operations Gerência de Performance.....................................................................

..LISTA DE TABELAS Tabela 4................................................................1 Tabela 8.............................. 15 74 ................................ Comparativo de Recursos de Cada Ferramenta...........................1 Mensagens SNMP..................

Message Authentication Code MD5 .Common Object Request Broker Architecture CRC .Common Management Information Protocol over TCP/IP CBC .Cipher Block Chaining CORBA .LISTA DE ABREVIATURAS ASN.Abstract Syntax Notation One BER .Basic Encoding Rules CMIP .Local Area Network LMS – LAN Management Solution MAC .Internet Protocol ISO . Security FTP .1 .Domain Name System ESP .Network Management Station OSI .Management Information Base MLM – Mid-Level Manager NMS .Open Systems Interconnection .Internet Engineering Task Force IP . Accounting.Cyclic Redundancy Checks CWRW – Routed WAN Management DES .High-Level Entity Management System HMAC .Internet Control Message Protocol IETF .Encapsulated Security Payload FCAPS . Performance.Data Encryption Standard DNS .Fault.Common Management Information Protocol CMOT .File Transfer Protocol HEMS .Hash Message Authentication Code HMP -Host Monitoring Protocol HTTP .International Standards Organization LAN .Internet Arquiteture board ICMP .Hipertext Transfer Protocol IAB .Message-digest 5 MIB . Configuration.

Request For Comment RMON .The Post Office Protocol .Short Message Service SMTP .Extensible Markup Language XOR .Xtended OR WAN .PDU .Simple Gateway Monitoring Protocol SHA-1 .World Wide Web Xtended OR .Secure Sockets Layer TCP .Remote Networking Monitoring SGMP .User Datagram Protocol USM .User Base Security Model VACM .Secure Hash Algorithm 1 SLA – Supplemental License Agreement SMI .Simple Network Management Protocol SQL .Structured Query Language SSH .Structure of Management Information SMS .Secure Shell SSL .Wide Area Network WWW .Packet Internet Groper POP3 .Protocol Data Unit PING .Version 3 QoS .Transmission Control Protocol UDP .Quality of Service RFC .Simple Mail Transfer Protocol SNMP .View-Based Access Control Model VMS – Security Management Solution XML .

A padronização da estratégia de gerenciamento é uma necessidade para permitir uma bem sucedida administração dos recursos das redes. a Gerência de Redes IP (item 3) onde se discorre sobre as normas relacionadas ao SNMP e a arquitetura de gerenciamento de redes. Mesmo com essas características benéficas o SNMP teve mais duas versões: o SNMPv2 que tratava de comunidade. O RMON recolhe novos tipos de informação. as ferramentas para gerenciamento (item 8) onde se apresenta algumas das mais importantes ferramentas e seus principais recursos. Os protocolos SNMPv2 e SNMPv3 (itens 5 e 6) versões otimizadas da versão inicial. encerrando. Com o objetivo de facilitar a compreensão estruturou-se este TCC em sete itens. O controle e gerenciamento eficaz das redes modernas é uma tarefa desafiadora devido à complexidade e diversidade dos dispositivos conectados. razão pela qual foi elaborada e implementada a versão 3 ou SNMPv3 que supriu esta lacuna. O monitoramento remoto de redes RMON (item 7) que trata da comunicação entre gerentes e agentes SNMP e. onde se abordou: O sistema de gerenciamento FCAPS (item 2) que é a referência. mas. além desta introdução e conclusão. O protocolo SNMPv1 (item 4) o qual é considerado o coração do gerenciamento de redes. 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. em um ambiente de rede distribuída. possibilitando o gerenciamento até a camada de aplicação. por meio do Login remoto. mas. assim como alguns tipos de eventos já ocorridos. O Simple Network Management Protocol (SNMP) é o protocolo mais amplamente utilizado para soluções de gerenciamento de redes TCP/IP por ser.1 1 INTRODUÇÃO Inicialmente podia-se dizer que o gerenciamento de redes resumia-se em monitorar e configurar um dispositivo de redes. Com a criação do RMON e RMON II tornou-se possível monitorar as subredes otimizando o gerenciamento da rede. sem melhorias no aspecto segurança de redes. . um padrão aberto e suficientemente simples e flexível para gerenciar diferentes tipos de dispositivos.

2. 2. 4. Isolar o restante da rede. de cada equipamento da rede. Neste contexto. Embora essa padronização funcional esteja voltada para o modelo OSI (Open Systems Interconnection). a saber): 1. 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. Configuration (Configuração). das sete camadas.2 2 ÁREAS DE GERENCIAMENTO FCAPS Sistemas de gerenciamento de redes empregam várias ferramentas.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. Accounting (Contabilização). e Reconfigurar ou modificar a rede de tal forma que minimize o impacto da sua operação sem os componentes com falha. aplicações e dispositivos para a monitoração e manutenção das mesmas. neste contexto considera-se “falha’ como uma condição . em um conjunto de cinco áreas funcionais. para que não seja afetada e possa continuar operando sem interferência devido àquela falha. permitindo a restauração da rede no estado inicial. e 5. individualmente. Reparar ou substituir os componentes sob falha. Performance (Performance). 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. No momento da ocorrência de falhas é importante a seguinte seqüência de ações: Determinar onde ocorreu a falha. Security (Segurança). Fault (Falhas). objetivando acompanhar e garantir o perfeito desempenho da mesma. Para a definição do que é uma falha primeiramente é necessário distinguir o que são falhas e o que são erros. 3.

enquanto que “erro” é um evento simples.3 anormal que requer atenção de gerenciamento (ou ação) para o seu reparo. Teste funcional. Devido a sua importância dentre as demais áreas de gerenciamento de redes. 2.2 GERENCIAMENTO DE CONFIGURAÇÃO O gerenciamento de configuração envolve a iniciação. identificando e especificando as características dos componentes e recursos que compõem a rede. e Teste de diagnóstico. Definir e modificar relações. Teste da integridade do protocolo. 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. Teste de laço de retorno. Inicializar e encerrar as operações da rede. Teste da saturação dos dados. Teste da integridade de dados. Erro → perda de pacotes ou quadros. . o sistema deve realizar os seguintes testes [1]: Teste da conectividade. Teste da saturação da conexão. Teste do tempo de resposta. o gerenciamento de falhas talvez seja o que mais necessite de atenção e acompanhamento. Um sistema de gerenciamento de falhas eficaz deve possibilitar o diagnóstico e a forma de isolar a falha e. Analisar os valores e relacionamento. e Relatar o status da configuração. Definir e modificar valores atributo. Exemplo: Falha → uma linha de comunicação fisicamente cortada onde nenhum sinal pode ser transmitido. Distribuir o software. para tanto. o mesmo inclui as seguintes funções: Definir informação configuração.

compreendendo: Documentar eventos. Estabelecer quotas de utilização com limites de uso de recursos. para isso. preservando a confidencialidade. monitorando quais recursos e quantos desses recursos estão sendo utilizados por qual componente da rede. basicamente. integridade dos dados e a fiscalização. 2.5 GERENCIAMENTO DE SEGURANÇA O gerenciamento de segurança garante o uso legítimo dos recursos da rede. Análise de desempenho. ou seja. os gastos obtidos com cada recurso. Manutenção e análise dos registros de segurança. Relatar violações de segurança. engloba três componentes: Avaliação por meio de estatísticas sobre o tráfego da rede.4 2. Estabelecer escalas de utilização.3 GERENCIAMENTO DE CONTABILIZAÇÃO O gerenciamento de contabilização tem como atribuição.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. por usuários ou grupos de usuários. e Síntese da geração de tráfego. a qual permite observar o desempenho da rede no âmbito de carga total. Monitorar pistas da auditoria de segurança. obtida por meio de um software desenvolvido para reduzir a apresentação dos dados. Aplicação das tarifas e faturamento. que podem também servir apenas para estatísticas. suas funções podem ser agrupadas em três categorias [1]: Manter informações de segurança. manter o pleno controle quanto ao uso dos recursos de rede e. Receber notificações de violações de segurança. utiliza-se das seguintes funções: Coletar informações de utilização. 2. Monitorar a utilização e os usuários dos recursos relacionados à segurança. .

. o gerenciamento de segurança poderá facilitar o uso de criptografia por outras entidades de rede. Manutenção geral dos perfis de usuários da rede. abrangendo: Códigos de segurança. Diretórios. Fonte de roteamento e informação da gravação da rota.5 Manter cópias backup para todos ou parte dos arquivos relacionados à segurança. Esta função é também responsável pelo planejamento dos algoritmos de criptografia e provimento ou suprimento para a distribuição de chaves. Controle de recursos de serviços de acesso. a fim de permitir referencias para conformidade dos perfis de segurança planejados. e perfis empregados para recursos específicos. e Tabelas de Contabilização. Níveis do limiar de disparo de alarmes. Controle do processo de criptografia O gerenciamento de segurança deve ser capaz de criptografar qualquer troca entre gerentes e agentes. Além disso. Tabelas de roteamento. conforme necessário.

No inicio de 1988 a IAB (Internet Architecture Board). mas poderosas ferramentas de gerenciamento.Host Monitoring Protocol). serviços e estrutura de dados sendo padronizados pela ISO para o gerenciamento de redes. Sob o ponto de vista do gerenciamento de rede. o qual provê uma maneira para transferência de mensagens de controle de roteadores e outros hosts para um host. Ante a crescente necessidade de se criar uma ferramenta de gerenciamento geral. o protocolo de monitoramento de host (HMP . avaliando estas propostas.com várias opções de cabeçalho tais como roteamento do código de origem e registro da rota . Essas mensagens ICMP podem ser usadas . o primeiro protocolo de gerenciamento de rede usado na internet. três propostas estavam se destacando: HEMS (High-Level Entity Management System): este foi .para desenvolver simples. para obter uma resposta sobre problemas no ambiente. o qual propiciava o monitoramento de um gateway. o protocolo (protocolo de informação de gerenciamento comum). concluiu pelo desenvolvimento do SNMP como uma solução de curto prazo e o CMOT como uma solução de longo prazo [1]. SNMP (Simple Network Management Protocol): este foi uma versão avançada do SGMP. O mais notável exemplo disso é o amplamente usado comando PING (Packet Internet Groper). CMIP sobre TCP/IP (CMOT): Esta foi uma tentativa de incorporar. o recurso mais usado do ICMP é o par de mensagem echo/echoreplay as quais provêem um mecanismo para testar se existe comunicação ativa entre entidades. em novembro de 1987. O marco inicial em criar uma ferramenta especifica para gerenciamento de redes foi o SGMP (Simple Gateway Monitoring Protocol). talvez. A única ferramenta efetivamente usada para gerenciamento era o Internet Control Message Protocol (ICMP). houve uma natural relutância em se investir recursos em . Portanto.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. para a máxima extensão possível. 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.

logo se tornou evidente que esta fusão dos dois protocolos para nível de objeto era impraticável tendo em vista que. • Base de Gerenciamento de Informação para o gerenciamento de redes TCP / IP baseadas em internet . inclui os seguintes elementos. Porém. Para incrementar e solidificar esta estratégia a IAB determinou que. ou esquema. Portanto. de forma independente e em paralelo. objetos gerenciados são vistos como sofisticadas entidades com atributos. Estação de gerenciamento. 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. • Simple Network Management Protocol (RFC1157): define o protocolo usado para gerenciar esses objetos. contidos na MIB.MIB-II (RFC1213): descreve os objetos gerenciados contidos na MIB. no gerenciamento de rede OSI. procedimentos associados e notificação de capacidades e outras complexas características associadas com tecnologia orientada ao objeto. De modo a obter necessidades imediatas. .7 protocolos de nível de aplicação e serviços sobre TCP/IP os quais poderiam muito cedo ser abandonados. 3. Como o SNMP não foi projetado para trabalhar com tais conceitos sofisticados. são definidos. de base de dados) poderiam ser definidas para ambos os protocolos. 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. tanto o SNMP como o CMOT. 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. usasse a mesma base de dados de objetos gerenciados. a IAB recuou em sua determinação de um SMI/MIB comum e permitiu o desenvolvimento do SNMP e do CMOT.2 ARQUITETURA DE GERENCIAMENTO DE REDES O modelo de gerenciamento para redes TCP/IP.

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.2 Agente de gerenciamento Alguns componentes importantes da rede tais como roteadores.1 Estação de gerenciamento A estação de gerenciamento serve como interface entre o homem (gerente) e o sistema de gerenciamento de rede. Base de informações gerenciais (MIB). o qual possui as seguintes capacidades principais: Get: permite a estação gerenciamento recuperar o valor dos objetos do agente.8 Agente de gerenciamento.2. Set: permite a estação gerenciamento definir o valor dos objetos do agente. etc. pontes. 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. Um banco de dados de informações extraídas das MIBs de gerenciamento de todas os elementos da rede.2. podem ser equipados com um agente SNMP para que possam ser gerenciados pela estação de gerenciamento. 3.2. e . recuperação de falhas.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). hubs e estação de trabalho. Apenas os últimos elementos são objetos de padronização SNMP. 3. 3. Um conjunto de aplicações de gerenciamento para análise de dados. e Protocolo de gerenciamento de redes.

Esta filosofia está em contraste com o que foi utilizado com gerenciamento OSI. a MIB pode armazenar somente tipos de dados simples: escalares e escalares bidimensional. 3. Para uma estação de gerenciamento individual. define o quadro geral dentro do qual a MIB pode ser definida e construída. MIBs conterão inevitavelmente tipos . Além disso. GetNextRequest. 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 é parte do protocolo TCP/IP e funcionar sobre o protocolo UDP (User Datagrama Protocol). pois nenhuma conexão é mantida entre a estação de gerenciamento e o agente. A SMI evita tipos de dados complexos buscando simplificar a tarefa de execução e. 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. e SetRequest. o qual provê complexas estruturas de dados e recuperação modos de apoiar uma maior funcionalidade. A filosofia por trás da SMI é incentivar a simplicidade e a flexibilidade dentro da MIB. aplicação.3 ARQUITETURA DO PROTOCOLO DE GERENCIAMENTO DE REDES O SNMP foi projetado para ser um protocolo do nível. Portanto. e por isso o SNMP trabalha sobre UDP. 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. um agente pode emitir uma mensagem trap em resposta a um evento que afeta a MIB e recursos gerenciados subjacentes. 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 SMI não suporta a criação ou recuperação de complexas estruturas de dados.4 ESTRUTURA DA INFORMAÇÃO DE GERENCIAMENTO (SMI) A estrutura SMI. aumentar a interoperabilidade. também. que é transmitida até o gerenciamento de aplicação. 3. O SNMP é um protocolo não orientado à conexão.9 Trap: permite a um agente notificar a estação de gerenciamento quando da ocorrência de eventos significativos.

e Prover uma técnica padronizada de codificação valores de objeto. incluindo a sintaxe e o valor de cada objeto. o qual serve para nomear o objeto. RFC 1155 assume que uma sub árvore dod será alocada para administração pela Câmara de Atividades da Internet como se segue: . a interoperabilidade será comprometida.1 OBJECT IDENTIFIER.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). com a raiz da árvore a ser o objeto referindo-se à norma ASN. existem três nós no primeiro nível: iso. Começando com a raiz da árvore OBJECT IDENTIFIER. Prover uma técnica padronizada para definir objetos individuais. O OBJECT IDENTIFIER é um identificador único para um determinado tipo de objeto. Todos os objetos gerenciados no ambiente SNMP são organizados de maneira hierárquica ou estrutura de árvore.1. uma estrutura SMI deve [1]: Prover uma técnica padronizada para definir a estrutura de uma determinada MIB. uma sub árvore é para utilização de outras organizações. ccitt e joint-iso-ccitt. Os objetos que compõem a árvore são os atuais objetos gerenciados. Além disso. cada um dos quais representa algum recurso. cada valor componente do OBJECT IDENTIFIER identifica um arco na árvore. uma vez que o valor associado ao tipo OBJECT IDENTIFIER é hierarquizada. estes objetos são padronizados por classe Ex: uma classe de determinado objeto gerencia varias pontes. Sob o nó iso. uma das quais é Departamento de Defesa dos Estados Unidos (dod). Associados com cada tipo de objeto em cada MIB há um identificador do tipo ASN. a convenção também serve para identificar a estrutura dos tipos de objeto. ou informações relacionadas. salvo se fortes restrições sejam colocadas sobre a definição de tais tipos de dados. 3. A partir da raiz. Seu valor consiste de uma seqüência de inteiros. que devem ser gerenciadas. Com o objetivo de padronizar a representação das informações de gerenciamento. O conjunto de objetos definido tem uma estrutura árvore. A MIB funciona como vários pontos de acesso. A própria estrutura da árvore define um conjunto de objetos relacionados de maneira lógica. atividade.10 de dados criados pelos fabricantes e.

duas versões da MIB foram desenvolvidas.500).1. experimental: usado para identificar objetos utilizados no experimentos da Internet. o nó internet tem o valor do OBJECT IDENTIFIER de 1. A divisão do nó internet em quatro subárvores fornece uma forte base para a evolução das MIBs. Atualmente. 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.1. Este valor serve como o prefixo para os nós no próximo nível inferior da árvore. A subárvore private correntemente tem apenas um nó filho definido. 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).Extensões privadas pode ser adicionadas à sub árvore private.11 Internet OBJECT IDENTFIER:: = {iso (1) org (3) dod (6) 1} Isto é ilustrado na figura 3. Portanto. uma nova subárvore é definida. Como mostrado. Um ramo dentro da subárvore enterprise é alocado para cada fabricante que registre para uma enterprise object identifier. a saber: directory: reservado para uso futuro com o diretório OSI (X. 2-Uma MIB experimental pode ser construída para uma aplicação particular. Para expandir mib-2. o nó enterprises. portanto. 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).6.3. o documento SMI define quatro nós sob o nó internet. Tais objetos poderão subseqüentemente ser movidos para a sub árvore mgmt. mgmt: usado para objetos definidos nos documentos aprovados pela IAB. e private: usado para identificar objetos definidos unilateralmente. 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. 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 . A sub árvore mgmt contém as definições das bases de informações de gerenciamento que tenham sido aprovadas pelo IAB. 3. mib-1 e mib-2.

Figura 3.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.1 MIB-II grupos .

controle de acesso. adicionando ou eliminando um registro de uma tabela) e. O sistema gerenciado estabelece uma comunidade desejada para cada combinação de autenticação. O agente pode estabelecer um número de comunidades com sobreposição dos membros da estação de gerenciamento. O conceito de comunidade é um local definido como sistema gerenciado. característica do proxy. Uma vez que as comunidades são . Trap: Uma estação gerenciada envia um valor não solicitado de objeto para uma estação de gerenciamento. controle de acesso e características do proxy. Tais restrições simplificam significativamente a implementação do SNMP.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. dentro daquela comunidade. não é possível usar comandos para uma ação ser realizada. 4. Por outro lado elas limitam a capacidade do sistema de gerenciamento de redes. também. Para cada comunidade é dado um único (dentro desse agente) nome de comunidade e as estações de gerenciamento. 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.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.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. devem empregar o nome comunidade em todas as operações de acessar e selecionar. Especificamente. 4. Não é possível mudar a estrutura de uma MIB por meio da adição ou eliminação de instancias de objetos (por exemplo. Set: uma estação de gerenciamento atualiza um valor de objeto numa estação gerenciada.

uma estação de gerenciamento deve manter o caminho do nome comunidade ou nomes associados com cada um dos agentes que desejam acessar. o mesmo nome pode ser usado por agentes diferentes. A figura 4.14 definidas localmente pelo agente. 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.1define os campos constituintes.1 informalmente descreve a estrutura e a tabela 4.3. a informação é intercambiada entre uma estação de gerenciamento e um agente na forma de uma mensagem SNMP.3 ESPECIFICAÇÕES DO PROTOCOLO 4.1 Formato SNMP Com o SNMP. Essa identidade de nomes é irrelevante e não indica qualquer similaridade entre as comunidades definidas.1 Formatos SNMP . Figura 4. 4. Portanto.

baseada em sysObjectID. Utilizado para distinguir entre pedidos que estejam sendo tratados.1 Mensagem SNMP 4. O serviço de autenticação então realiza quaisquer transformações requeridas para esta mudança. 2. contém os valores de sysUpTime. junto com a fonte e a destinação do endereço de transporte e um nome de comunidade. linkUp (3). provendo a cada pedido um único ID. O PDU é construído usando a estrutura ASN. Endereço de trap de produção de objeto Tipos genéricos de valores trap são: coldStart (0). linkDown (2). consistindo de campo versão. . readOnly (4) e genErr (5). egpNeighborLoss (5) e enterprise-Specific (6). Usado para indicar que ocorreu uma exceção enquanto está processado um pedido. 1. tooBig (1).3. badValue (3). Uma lista de nomes de variáveis e seus valores correspondentes Tipo de trap de produção de objeto. A entidade protocolo então constrói uma mensagem. e retorna o resultado. warmStart (1). os valores são: noError (0). Quando erro-satuts é diferente de zero. uma entidade SNMP realiza as seguintes ações para transmitir um dos cinco tipos de PDU para outra entidade SNMP: 1.1 Transmissão de uma Mensagem SNMP Em princípio. pode prover informação adicional por meio da indicação de qual variável em uma lista causou a exceção.1. 3. Este PDU é então submetido a um serviço de autenticação. o nome da comunidade e o resultado do passo 2. noSuchName (2).15 CAMPO Version community request-id error-status error-index variablebindings enterprise agent-addr generic-trap specific-trap time-stamp DESCRIÇÃO Versão do SNMP (RFC 1157 é versão 1) O nome da comunidade atua como uma senha para autenticar a mensagem SNMP. authentication-Failure (4). Código de Trap específico Tempo decorrido entre a última inicialização da entidade de rede o a produção de Trap. tal como encriptação ou a inclusão de um código de autenticação. Tabela 4.

3. . b) se a autenticação tiver sucesso.1 é então codificado usando as regras de codificação básicas e passado para o serviço de transporte. Faz uma verificação da sintaxe básica da mensagem e descarta a mesma se existir falha na análise. 1. 4. o serviço de autenticação retorna um PDU na forma de um objeto ASN.16 4. Na prática. que gera uma trap e descarta a mensagem. o serviço de autenticação sinaliza a entidade de protocolo SNMP. a política de acesso SNMP apropriada é selecionada e o PDU é conseqüentemente processado. 4. autenticação não é invocada tipicamente. De qualquer forma. Este novo objeto ASN. Na prática.1. A entidade protocolo faz uma verificação da sintaxe básica da PDU e descarta a PDU se ele falhar na combinação. onde: a) se a autenticação falha.1 adequado para a estrutura. 2.3.2 Recepção de uma Mensagem SNMP Em princípio. A entidade protocolo então transmite o nome de usuário. o serviço de autenticação serve meramente para verificar que o nome comunidade autoriza a recepção de mensagens de entidade SNMP. a porção PDU da mensagem. Verifica o número da versão e descarta a mensagem se há uma falha de combinação. uma entidade SNMP realiza as seguintes ações quando da recepção de uma mensagem SNMP. e a fonte e destinação do endereço de transporte para um serviço de autenticação. usando a comunidade nomeada.

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. Figura 4. a qual esta diretamente relacionada para a junção do nome e valor de uma variável.3 Variable Bindings A Variable Bindings ou VarBind remete à uma instância. 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.1.2 Seqüência de PDU SNMP 4.3.17 4.3. Na operação GetRequest : . Request-id: a entidade de transmissão determina números de tal maneira que cada Request para cada agente é único.2). A entidade de transmissão inclui os seguintes campos na PDU: Tipo PDU: indicando que este é um GetRequest PDU. de um objeto administrado.

3. a entidade de resposta retorna o GetResponse PDU com um error-status.3 GetNextRequest PDU O GetNextRequest PDU é quase idêntico a todos os GetRequest PDU . A entidade de resposta pode estar habilitada para fornecer um valor para o último dos objetos por algum motivo. valores não são devolvidos. Neste caso. a resposta retorna o valor da instância do objeto que é próximo dentro da ordem lexicográfica. A entidade de resposta pode estar habilitada para fornecer valores para todas as variáveis na lista.mesmo módulo de troca e o mesmo formato . com o valor fornecido para cada variável. a entidade de reposta retorna um GetResponse PDU com um error-status. para cada variável. ou um objeto especificado pode ser de um tipo agregado e. cada variável na lista de variablebindings referência a uma instância de objetos de quem o valor é retornado. As seguintes condições de erros podem ocorrer: Um objeto especificado no campo variablebindings pode não igualar um identificador de objetos na MIB.18 todos os outros valores são recuperados ou nenhum o é. No GetNextRequest PDU. . Neste caso. não ter um valor de instância associado. de genErr e um valor no campo error-index que é a indexação do objeto problema no campo variablebindings. Se pelo menos um dos valores das variáveis não pode ser fornecido em seguida. 4. 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. 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. portanto.a única diferença é que no GetRequest PDU. mas o tamanho do resultado GetResponse PDU pode exceder a limitação local.

5 Trap PDU O Trap é um simples pacote SNMP que alerta quando ocorre algum tipo de problema no agente. • . uma mensagem sempre que ocorre uma mudança ou alteração num objeto gerenciado. O padrão SMNP básico fornece somente autenticação comum.4 LIMITAÇÕES DO SNMP Cabe registrar algumas das limitações do SNMP: • Não é apropriado para o gerenciamento de redes verdadeiramente amplas. Adicionalmente.19 4.3. 4. para a estação de gerenciamento. 4.4 SetRequest PDU O SetRequest PDU. devido a limitações de desempenho de pooling. cuja a função principal é alterar valores de variáveis do objeto de gerenciamento. não existe mecanismo que permita a um sistema de gerenciamento ter conhecimento dos dispositivos e redes gerenciadas por outro sistema de gerenciamento. o SetRequest pode ser usado para adicionar ou eliminar linhas. No caso típico onde UDP/IP é usado para entregar mensagens Trap. basicamente realiza as mesmas funções que o GetRequest PDU porém com a particularidade que é usado para gravar um valor de objeto. Traps SNMP são desconhecidos. o agente não tem garantia que uma mensagem critica tenha sido encaminhada à estação de gerenciamento. O SNMP não é bem adaptado para recuperar grandes volumes de dados tal como uma tabela de roteamento completa. sendo que o acesso pode ser alterado nas variáveis que permitam leitura/gravação. Por exemplo. Nesta condição o Trap PDU encaminha.3. • • • Não suporta comunicação gerente para gerente.

. e esta última entidade SNMPv2 então responde ao pedido. Por meio do significado do cabeçalho da mensagem. 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. 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. designado por "Trap". Apenas o segundo item é novo para SNMPv2. são definidas a autenticação e políticas de privacidade. 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. o qual é determinado por um quadro administrativo. 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 obter ou modificar gerenciamento da informação associada a gerenciamento do dispositivo. os outros dois tipos de interação são encontrados em SNMPv1. a uma entidade SNMPv2 agindo em uma função gerente e nenhuma resposta é retornada. A mensagem SNMP v2 oferece a funcionalidade exigida para os requisitos de segurança do SNMPv2.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.

1 é então codificada.1.1 Transmissão de uma mensagem SNMPv2 Uma entidade SNMPv2 realiza as seguintes ações para transmitir uma PDU para outra entidade SNMPv2. Na prática autenticação não é usualmente invocada 5. Por outro lado. 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. 4. o serviço de autenticação retorna um PDU no formato de um objeto ASN. 2. a PDU da mensagem e os endereços de transporte da origem e destino. Verifica o número da versão descartando-a se existir divergência ou erro. 1. Realiza a verificação da sintaxe básica da mensagem descartando-a se houver falhas no processamento ou análise. o serviço de autenticação sinaliza para a entidade protocolo SNMPv2. Na prática o serviço de autenticação meramente serve para verificar que a comunidade autoriza receber mensagens da entidade SNMPv2. o nome da comunidade e o resultado da ação 2. usando as regras de codificação básica (BER) e passada para o serviço de transporte. 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. consistindo de um campo versão. . Esse novo objeto ASN. a apropriada política de acesso SNMPv2 é selecionada e conseqüentemente o PDU é processado. 3.21 5. A PDU é construída usando a estrutura ASN. b) se a autenticação é bem sucedida. usando a comunidade nomeada.1. e retorna o resultado.1.1 o qual se ajusta à estrutura definida na especificação do protocolo.2 Recepção de uma mensagem SNMPv2 Seqüência de ações: 1. 2. 4. A entidade Protocolo então transmite o nome usuário. a) se a autenticação falha. a qual gera uma trap e descarta a mensagem. 3. A entidade Protocolo então constrói uma mensagem. 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.

error-status: Um valor zero indica que uma exceção ocorreu durante o processamento de um pedido. Figura 5.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.1 representa o formato da PDU SNMPv2 e a estrutura da mensagem descrita na a figura 5.2.1 .3.22 A figura 5. a fim de distinguir respostas a vários pedidos pendentes. O gerente pode atribuir um número único para cada solicitação pendente para o mesmo agente.2 . A seqüência de PDU SNMPv2 é apresentada na figura 5. .Formato PDU SNMPv2 Figura 5.

o NoSuchObject: o agente não pode implementar o objeto referido por este object identifier. do mesmo modo. Figura 5. a segunda tem índice 2.23 error-index: Quando o campo error-status não é zero. Variável-bindings: este campo permite que uma única operação a ser aplicada a um grupo instâncias de objeto. não existe para esta operação. 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 índice de valores de erros identifica a variável (objeto) na variável-bindings lista o que causou o erro. provê um mecanismo para solicitar os valores apresentados no campo Variable Bindings.3 .3 GetRequest PDU O GetRequest pratica as mesmas funções que o SNMPv1 e. A primeira variável na lista tem indice1. e assim por diante.1. O domínio consiste de uma seqüência de pares sendo que. o UnSpecified: um valor NULL é usado na recuperação pedidos. . o endOfMibView: indica uma tentativa de referência a um objeto identificador.Seqüência de PDU SNMP 5. o NoSuchInstance: indica que este objeto.

A diferença é que com GetBulkRequest. 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.6 SetRequest PDU Comparando-se com o SNMPv1. é possível especificar que múltiplos sucessores lexicográficos sejam selecionados. para então estabelecer o Response PDU. • 5. são analisados basicamente se o tamanho excede a um tamanho determinado ou ainda quanto a restrições locais.1. 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.1.24 5. 5. isto é. 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. a seleção é sempre sobre a próxima instância de objeto na ordem lexicográfica.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 . no SNMPv2.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.1. .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. enquanto que o GetNextRequest SNMPv2 recupera todos os valores possíveis.

error-index e o campo variable-bindings como recebido o InformRequest PDU. o recurso Trap PDU transfere informações. a entidade SNMPv2 determina o tamanho da mensagem. error-status. como suporte de uma aplicação. Apesar de ser uma função semelhante ao SNMPv1.1. Quando um InformRequest é recebido.8 InformRequest PDU É enviado por uma entidade SNMPv2 atuando em uma função de gerente. . 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).7 Trap PDU Na versão SNMPv2. descrevendo os acontecimentos críticos no gerenciamento. para outra entidade SNMPv2 atuando em uma função de gerente.25 5. 5. para fornecer informações de gerenciamento para uma aplicação usando a entidade posteriormente.1. encapsulando um Response PDU com o mesmo valor no seu request-id.

1 Entidades SNMP Cada entidade SNMP possui um Motor SNMP o qual implementa funções para enviar e receber mensagens. O Motor SNMP se divide em quatro componentes: Despachante. Que as mensagem possam ser recebidas em tempo hábil evitando. O maior desafio na criação do SNMPv3 foi o desenvolvimento de uma estrutura que pudesse ser facilmente estendida e. A simplicidade do SNMP possibilitou a sua popularização. foi divido em duas partes . Cada entidade SNMP consiste num conjunto de módulos que interagem entre si para fornecer serviços. os agentes e gerentes passaram a ser denominados de entidades. com este objetivo. ou. uma combinação dos dois. Cada entidade implementa uma parte da capacidade SNMP podendo agir como um nó agente e um nó gerente. obtida por meio da autenticação e criptografia dos dados. além de controlar o acesso aos objetos gerenciados. com isso. 6. No entanto a complexidade está nos dados que o SNMP acessa. além disso. que sejam adulteradas e passadas adiante causando danos indesejáveis.1. Estas funções são fornecidas com uma ou mais aplicações configuradas com o Motor SNMP para formar uma entidade SNMP.26 6 O PROTOCOLO SNMP v3 O SNMPv3 tem como principal característica a segurança.o Motor SNMP e aplicações SNMP – e. já que nem todas as características de um dispositivo são úteis. o que possibilita: Que apenas grupos autenticados possam se comunicar. tornando difícil a seleção de informações úteis para o gerenciamento. 6.1 ARQUITETURA SNMPv3 A arquitetura SNMP. . possuindo apenas quatro operações duas para obter dados uma para modificar e uma para enviar notificações. consiste de uma coleção de entidades SNMP atuando uma sobre a outra de forma distribuída. autenticar e criptografar / descriptografar mensagens.

pág.1. em seguida. apresenta-se síntese da inter-relação Motor SNMP versus aplicações. encapsula as PDUs em mensagens para transmissão. Aplicação Receptora → processa entradas de mensagens assíncronas. abaixo. Figura 6. como se segue: 1. que fazem uso de SNMPv1/v2 PDUs. Na figura 6. aceita PDUs oriundos de pedidos SNMP e realiza o processamento necessário.27 Subsistema de processamento de mensagens. . SNMPv2-Trap e SNMPv1 Trap PDUs. incluindo GET. O Motor SNMP realiza duas funções gerais. GEtNext. incluindo a inserção de códigos de autenticação e criptografia e.1. GetBulk e Set. 29. Subsistema de segurança. no caso de um gerente tradicional. o informRequest PDU é utilizado para esta aplicação.1 .1. e Subsistema de controle de acesso.2.1 Gerente SNMP tradicional O diagrama de bloco da figura 6. Aplicação Geradora de Notificações → inicia mensagens assíncronas. 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.Entidade SNMP (RFC 2271) 6. estes incluem PDU InformRequest.

envolve-as no cabeçalho da mensagem adequada e devolve-as ao Despachante. passa a esta PDU para a aplicação adequada. o despachante aceita PDUs de aplicativos e executa as seguintes funções: Para cada PDU. SNMPv2. A mensagem é retornada ao Subsistema de Processamento de Mensagem. o despachante determina o tipo processamento de mensagem necessária (SNMPv1. O Subsistema de Processamento de Mensagem aceita PDUs vindas do Despachante e as prepara para transmissão. O Despachante. SNMPv3) ou pode conter uma série de módulos. realiza o processamento necessário. incluindo autenticação e descriptografia e. 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. extrai as PDUs das mensagens e as envia para a aplicação SNMP apropriada. Após esta operação a mensagem é retornada ao subsistema de processamento de mensagem. em seguida. Uma implementação do Subsistema de Processamento de Mensagem pode apoiar um único formato mensagem correspondente a uma única versão do SNMP (SNMPv1. o que pode gerar um código autenticação e inseri-lo no cabeçalho da mensagem. aceita receber mensagens SNMP da camada de transportes. SNMPv2. ou SNMPv3) e passa o PDU relativa ao tratamento de mensagem adequado no módulo Subsistema de Processamento de Mensagem. Cada mensagem enviada é passada para Subsistema de Segurança pelo Subsistema de Processamento de Mensagem. processa cada cabeçalho destas mensagens.28 2. o Subsistema de Processamento de Mensagem retorna uma mensagem contendo a PDU e incluindo cabeçalhos adequados da mensagem. O Subsistema de Segurança exerce funções de autenticação e criptografia. . Em um gerente tradicional é composto por: um Despachante. o Subsistema de Segurança pode criptografar a PDU em anexo. Da mesma forma. e retorna a PDU anexada ao Despachante. O Despachante é um simples gerente de tráfego. Dependendo dos serviços solicitados. cada um apoiando uma versão diferente do SNMP. um Subsistema de Processamento de Mensagem e um Subsistema de Segurança. Posteriormente. em seguida. O Subsistema de Processamento de Mensagem também aceita as mensagens recebidas do Despachante. Para as PDUs de saída.

Uma implementação do Subsistema de Segurança pode apoiar ou mais distintas sobre controle de acesso modelos. no caso de um agente tradicional.29 Figura 6.2 Agente SNMP tradicional A figura 6. O Subsistema de . a PDU SNMPv2-Trap ou SNMPv1 Trap PDU é utilizado para esta aplicação. Aplicação encaminhadora de Proxy: encaminha mensagens entre entidades.2 . Este subsistema fornece serviços de autorização para controlar o acesso a MIBs para a leitura e a configuração de objetos gerenciados. As funções relacionadas com a segurança estão organizadas em dois subsistemas: segurança e controle de acesso. especificado em RFC2275.1. O motor SNMP de um agente tradicional tem todos os componentes encontrados no motor SNMP de um gerente tradicional. o único modelo de segurança definido é o Ver-Based Access Control Model (VACM) para SNMPv3. Aplicação Geradora de notificações: inicia mensagens assíncronas.1. Até ao momento. acrescida de um Subsistema de Controle de. Estes serviços são realizados com base no conteúdo das PDUs.Gerente SNMPv3 tradicional 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.

atualmente. Figura 6.3 . . Receptoras de notificações: recebem e processam Traps ou mensagens Inform. e opera sobre as mensagens 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. subentende-se que as mesmas possuem uma entidade SNMP sendo que. Geradoras de notificação: geram Traps ou mensagens Inform. Processadoras de Comandos: fornecem acesso aos dados gerenciados.30 Segurança está preocupado com a privacidade e autenticação. e opera sobre as PDUs SNMP. O Subsistema de Controle de Acesso está preocupado com acesso autorizado as informações gerenciadas.2 APLICAÇÕES SNMP Em se tratando de aplicações SNMPv3. Encaminhadoras de proxy: enviam mensagens entre entidades SNMP. existem cinco tipos de aplicações definidas: Geradoras de Comandos: geram comandos SNMP com a finalidade de coletar ou configurar dados gerenciados.Agente SNMPv3 Tradicional 6.

contextEngineID: um octeto que identifica unicamente uma entidade SNMP. msgMaxSize: contem o tamanho máximo suportado pela mensagem em octetos. no SNMPv3 a informação é trocada entre entidades SNMP. 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. 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.3 FORMATO DA MENSAGEN SNMPV3 Figura 6. e data: SNMPv3 especifica que esta deve ser uma PDU SNMPv2. contextName: um octeto que identifica unicamente um contexto em particular com o escopo do motor de contexto associado.4 .31 6. msgID: identificador único utilizado entre duas entidades SNMP. 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.Formato da mensagem SNMPv3 Tal qual ocorre nas versões anteriores.

autenticação e privacidade dos dados. de qualquer transmissão de mensagem uma das duas entidades.são referenciados na definição ASN.4. é denominada “motor autorizado”. Diferencia-se de outros mecanismos de integridade.1. como estes campos são organizados.4 ALGORITMOS CRIPTOGRÁFICOS USADOS PELO SNMPv3 6. que é uma PDU contendo as informações mencionadas no contexto onde é claramente identificado pelo contextEngineID e contextName.4. msgMaxSize. emissor ou receptor. Este bloco contém parâmetros necessários pelo subsistema “processamento de mensagem” para coordenar a manipulação e o processamento da mensagem. contextName e data são referenciados como msgData e possuem um tipo de scopedPDUData. o qual será detalhado a seguir: SHA-1 – Secure Hash Algorithm 1 É uma técnica que possibilita a integridade dos dados. que opera dentro do código de autenticação. msgID. 6.1 pelo nome msgGobalData.32 A figura 6. ou seja. No modo USM há dois recursos criptográficos definidos . por detecção e correção de erros de código. O três campos contextEngineID. Os cinco campos – msgVersio.1 Autenticação Existem duas funções hash identificadas no USM.Autenticação e Privacidade – para os quais o SNMP requisita os valores “privKey” e “authKey” para possibilitar o suporte. por meio de duas características: . 6.4 mostra. msgFlags. Este bloco contém informações necessárias pela aplicação para processar a PDU. enquanto que a privacidade é obtida através da encriptação dos dados. o Message Digest5 (MD5) e o Secure Hash Algorithm Revisão One (SHA-1). e msgSecurityModel . Possui serviços de integridade.1. User-Based Security Model – USM O USM utiliza o conceito de motor autorizado. ainda. A integridade e a autenticação são obtidas através da função hash.

sem possuir a chave secreta.2 Encriptação Para encriptação o USM adota a técnica denominada Data Encryption Standard (DES). HMAC . 6. 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. quanto a permitir a detecção de alterações de ataques maliciosos ao invés de simplesmente registrar erros.33 o Resistência de Colisão – avalia a capacidade de encontrar duas mensagens de entrada que contenham o mesmo valor hash. para tentar modificar a mensagem.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.4. Em síntese. O receptor calcula a identificação utilizando a chave secreta local (authkey) verificando se o valor calculado corresponde ao da mensagem recebida. 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. dos demais mecanismos de verificação de integridade. Por sua vez o HMAC pode ser construído utilizando a função hash . O DES é uma técnica de encriptação simétrica a qual requer como o HMAC.Hash Message Authentication Code O USM é baseado no código de autenticação de mensagem HMAC. A chave de encriptação e o VI derivam de uma chave de privacidade localizada (privKey). Caso haja tentativa de ataque malicioso. Os recursos acima distinguem as funções hash criptografadas.1. esta não teria sucesso por não ser capaz de prever a identificação correspondente. o qual é um mecanismo utilizado para verificar a veracidade da origem e integridade dos dados. 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. . 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).

4. 3. 5.3 Processamento de mensagens USM Os procedimentos adotados pelo USM. retorna uma indicação de erro. então o valor scopedPDU é criptografado usando o CBC-DES e a chave privada de criptografia localizada na privKey deste usuário. Se o securityLevel requisitar autenticação. se não for. O USM realiza os seguintes passos: 1. O parâmetro securityName é armazenado no campo msgUserName. O parâmetro snmpEngineID é armazenado no campo msgAuthoritativeEngineID. são mostrados na figura 6. 6. 2.1. o valor corrente do snmpEngineBoots e snmpEngineTime correspondentes ao parâmetro snmpEngineID são armazenados nos campos msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime.5 sendo realizado ao receber um generateRequestMsg.34 6. se o securityLevel requisitar privacidade. para o processamento de mensagens recebidas e enviadas. . 7. O USM determina se o securityModel requisitado é suportado por este usuário e. Se houver. respectivamente. A mensagem completa com seu tamanho é retornada ao módulo de processamento de mensagens que fez a requisição.4. O USM determina se há uma entrada na usmUserTable para o destino securityEngineID e a fonte SecurityName. uma indicação de erro é retornada.

Processamento da mensagem USM: transmissão Uma mensagem de resposta deve ser recebida. uma indicação de erro é retornada. Se não houver. e este motor SNMP é capaz de realizar descobertas. Os valores dos parâmetros de segurança são extraídos do campo securityParameters. Se o securityLevel especificar que a mensagem é para ser autenticada. uma indicação de erro é retornada.35 Figura 6.5 . se não for.6) inclui: 1. 5. decorrido um tempo estimado. uma indicação de erro é retornada. O USM determina se há uma entrada na usmUserTable para o SecurityEngineID remoto autorizado e o securityName local. ele pode opcionalmente criar uma nova entrada na sua MIB usmUserGroup. usando o HMAC e a chave privada de autenticação da mensagem para esta mensagem e comparando o resultado com o do campo . 3. O USM determina se o securityLevel requisitado é suportado par este usuário e. e deve ser tratada pelo despachante e pelo processador de mensagem o qual invoca o USM com a primitiva processIncomingMessage. então a mensagem é autenticada. 4. Se o valor do msgAuthoritativeEngineID no securityParameters for desconhecido. Caso contrário. Este processamento (figura 6. 2.

então a scopedPdu é descriptografada usando o CBC-DES e a chave privada de criptografia localizada n privKey deste usuário. Figura 6. 7. o USM para o processamento e retorna uma indicação de erro. a mensagem é declarada autentica e o processamento continua.realiza os seguintes passos: .oriunda do subsistema de processamento de mensagens (quando está tratando uma mensagem Request que acaba de chegar) .6 . Se a mensagem não estiver na janela de tempo. Se os resultados não combinarem. O USM realiza a checagem do tempo. Se o securityLevel indicar que foi usada criptografia.36 msgAuthenticationParameters na mensagem. o USM para o processamento e retorna uma indicação de erro. 6. Se a mensagem estiver dentro da janela de tempo o processamento continua. Se o resultado conferir. A scopedPdu é retornada ao modulo de processamento de mensagens que fez a requisição. Quando o USM é invocado com uma primitiva processIncomingMessage . utiliza muito dos passos citados anteriormente. O USM realiza a sincronização. A processadora de comandos. 9. com algumas diferenças importantes. 8.Processamento da mensagem USM: recepção.

9. 7. Os valores dos parâmetros de segurança são extraídos do securityParameters. usmUserPrivProtocol. esta ação é feita . Uma referência ao ponteiro para este bloco em cachê é colocado na saída do parâmetro securityStateReference. 4. Concomitantemente o processador de comandos pode preparar uma PDU Response e invocar então o processador de mensagens com uma prepareResponseMsg primitiva. uma indicação de erro é retornada. como parte do conjunto dos parâmetros do processador de comandos que este possui no cachê. o processador de mensagens armazena em cachê o valor do securityStateReference que é recebido em retorno do USM. O USM determina se há uma entrada no usmSecurityTable para o securityEngineID local autorizado e o securityName remoto. Se o securityLevel indicar que a criptografia foi utilizada. Se houver combinação a mensagem é declarada autentica e processamento continua. subseqüentemente. Se o valor do msgAuthoirtativeEngineID no security Parameters for desconhecido. caso contrário o USM interrompe o processamento e uma indicação de erro é encaminhada. Um bloco cachedSecurityData é preparado pra servir de cachê para as seguintes informações: msgUserName. 5. Enquanto isso. retorna a PDU recuperada para a aplicação processadora de comando. 6. São adicionadas as seguintes informações ao bloco cachedSecurityData disposto no passo 1: usmUserAuthProtocol. usmUserPrivKey. Se o securityLevel especifica que a mensagem deve ser autenticada. usmUserAuthKey.37 1. 2. A scopedPdu é retornada ao módulo de processamento de mensagens que realizou a requisição. 8. No retorno do USM para o processador de mensagens este. uma indicação de erro é retornada. 3. uma indicação de erro é retornada.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. e se não for. então a scopedPdu é descriptografada usando o CBC-DES e a chave privada de criptografia localizada na privKey deste usuário.por meio do HMAC e a chave privada de autenticação localizada na authKey deste usuário . O USM determina se o securityLevel requisitado é suportado para este usuário. O processador de mensagens irá então invocar o USM . e securityLevel. Se não houver. securityEngineID.

O USM determina se o securityLevel requisitado é suportado para este usuário. os valores dos campos msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime do cabeçalho da mensagem . 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. Se não for requisitado privacidade então o campo mspPrivacyParameters é configurado para NULL. O parâmetro snmpEngineID é armazenado no campo msgAuthoritativeEngineID da mensagem SNMPv3. O texto cifrado resultante é armazenado no campo scopedPdu. 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. 3. Estas informações provem da mensagem Request processada anteriormente. 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.38 com a primitiva generateResponseMsg. 2. A diferença entre o motor autorizado e um não autorizado é demonstrado no item 6. A mensagem completa com seu tamanho é retornada ao modulo de processamento de mensagem que solicitou a requisição. O parâmetro securityName é armazenado no campo msgUserName. e se não for. No caso de um motor não autorizado. Usando o valor recebido de securityStateReference. 5. o USM obtém as informações do usuário armazenando-as na cachê. e o valor falso derivado do valor da privKey é armazenado no campo msgPrivacyParameters da mensagem SNMPv3. uma indicação de erro é retornada. São realizados pelo USM após o receber uma generateResponseMsg: 1. Os valores correntes de snmpEngineBoots e do snmpEngineTime para este motor local autorizado são armazenados no campos msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime. 4. respectivamente. 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. 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. Se o securityLevel requisitar autenticação. 6. 7.

estes valores representam os valores locais “oficiais” do snmpEngineBoots e snmpEngineTime. No caso de um remetente autorizado. um o motor SNMP não autorizado deve memorizar o valor snmpEngineID de um motor autorizado antes que se realize a comunicação. atualização e gerenciamento de chaves esta descrito na RFC 2274. um sistema agente) fazer uso da autenticação e privacidade com sistemas remotos autorizados que o usuário gerencia (um sistema agente). chaves secretas de autenticação e de privacidade devem ser compartilhadas [1]. este deve usar estes valores apenas para a sincronização da mensagem se a mensagem for autenticada. 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. Quando uma mensagem Response é recebida por um motor não autorizado.4 Processo de descoberta Para obter informações suficientes sobre outros motores SNMP o USM requer o uso do processo de descoberta. para qualquer comunicação entre um diretor em um motor não autorizado e um motor autorizado remoto.39 são configurados somente se a mensagem deve ser autenticada por um receptor autorizado.4. 6. . Se uma comunicação autenticada é requisitada. O guia para criação.4. para uma mensagem Response vinda de um motor autorizado. os valores msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime presentes no cabeçalho da mensagem são sempre configurados. 6. Esta restrição faz sentido porque o receptor autorizado ira checar estes campos apenas se a mensagem deva ser autenticada.5 Gerenciamento de chaves Um dos requisitos para uso dos serviços de autenticação e privacidade no SNMPv3 é que.1. Entretanto.1. Estas chaves possibilitam a um usuário de um motor não autorizado (tipicamente. Em particular. o motor não autorizado precisa estabelecer uma sincronização de tempo com o motor autorizado. O motor autorizado irá responder com uma mensagem Report contendo seu snmpEngineID no campo msgAuthoritativeEngineID.

Nenhum NMS é necessário para armazenar as chaves do usuário. Estas chaves não são armazenadas em uma MIB e não são acessíveis via SNMP. Se múltiplos usuários estão autorizados .40 Para uma simplificação o gerenciamento de chaves é centrado nos diretores. O objetivo é que assim o usuário precisa manterá apenas uma única chave (ou duas se usar autenticação e privacidade) e. Dentre os principais objetivos para o gerenciamento de chaves podemos citar: 1. utiliza-se o hash MD5 do digest0 para formar digest1. Entretanto seria mais seguro usar duas senhas. truncado o último valor para formar uma string digest0. portanto lembrar-se de apenas uma senha (ou duas). Ao invés disso.576 cria-se uma senha do usuário e através da repetição da senha quantas vezes quanto necessário. Com uma string de 1. cada diretor é requisitado a manter apenas uma única chave para autenticação e uma única chave para privacidade. A localização de chaves é o processo pelo qual uma única chave do usuário é convertida em múltiplas chaves únicas. 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. uma para cada Motor SNMP remoto. uma para gerar uma chave de autenticação e outra para gerar uma chave de privacidade/criptografia. 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. A saída é a chave do usuário. Resumidamente a geração de chaves é feita da seguinte maneira [1]: 1. 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. Em uma rede distribuída cada sistema agente SNMP possui sua própria chave única para cada usuário autorizado a gerenciá-lo. 2. Se necessário criar uma chave de 128 bits. b) Localização de chaves A RFC 2274 define chave localizada como chave secreta compartilhada entre um usuário e uma entidade SNMP autorizada.048.

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. utiliza-se o hash MD5 do digest2. A chave resultante pode então ser configurada no sistema agente de forma segura. A saída é a chave do usuário. com isso o usuário pode realizar funções de gerenciamento a partir de qualquer estação gerenciada. é impossível que um adversário possa aprender uma chave de usuário. ou qualquer usuário para qualquer outro agente. Esse procedimento se faz da seguinte forma: Formar uma string digest2 pela concatenação de digest1. as chaves dos outros usuários não são. para motores autenticados diferentes. . Se uma chave de 128 bits for desejada. Por isso. o agente possui uma única chave de autenticação e uma chave de criptografia para cada usuário. Alguns procedimentos a serem evitados: Um usuário precisa lembrar um grande número de chaves. se a chave de um usuário é comprometida. 2. mesmo que o adversário venha descobrir a chave localizada. Com isso se um agente é comprometido.7 demonstra resumidamente esse processo. 3. A figura 6. Independente da disponibilidade de um sistema de gerenciamento de rede (NMS) pode ser executado de qualquer ponto da rede.41 como gerentes. o valor snmpEngineID do motor autorizado (agente) e digest1. Essa habilidade é produzida pelo algoritmo de senha para chave. Devido à origem do MD5 e do SHA-1. Se for necessária uma chave de 160 bits adota-se o hash SHA-1 do digest2. Para agentes diferentes as chaves de um usuário são diferentes. uma única chave de usuário é mapeada pelo uso de uma função de mão única irreversível em diferentes chaves localizadas. Para que isso seja evitado. Um adversário que obtenha a chave de um agente é capaz de personificar qualquer outro agente para qualquer usuário.

devendo esta ser manual ou por outro protocolo seguro. Cabe destacar duas desvantagens da criptografia. na continuidade. um usuário pode iniciar o processo de troca de chave. 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. Utilizar algum tipo de função de mão única para produzir um valor a partir da chave antiga. Em ambos os casos a chave existente é atualizada permitindo ao NMS calcular uma chave localizada para cada agente com o qual se comunica e. 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 .42 Figura 6. 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. o NMS não pode simplesmente enviar a chave em texto plano através da rede devendo adotar umas das seguintes alternativas: 1. 2. Obviamente. Criptografar a nova chave usando a chave antiga como a chave de criptografia.7 . o NMS pode iniciar o processo por meio da requisição de uma nova senha. Alternativamente. comunicar-se de modo seguro com cada agente para que este possa atualizar sua chave localizada. Através de requisição e fornecimento de uma nova senha. no caso da autenticação e privacidade) tenha sido entregue a um agente.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.

Um securityName refere-se a . tanto ao administrador de rede como ao próprio usuário. O recurso de atualizar uma chave de usuário em particular é permitido pelo SNMPv3. 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. em uma MIB local. Um administrador de rede pode configurar as chaves iniciais para um usuário. O objeto usmUserOwnAuthKeyChange não é protegido por controle de acesso. O sistema agente é configurado de forma que apenas o administrador da rede tenha acesso a este objeto. que é então automaticamente usado pelo agente para atualizar a chave correspondente. o grupo usmUser contém dois objetos de troca de chaves para cada uma das chaves. respectivamente. O algoritmo considera que um tamanho variável de chave pode ser utilizado por um algoritmo de autenticação ou de criptografia específico. 6. Similarmente. deve ser permitido.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. Para a chave de autenticação o usmAuthKeyChange deve ser configurado pelo administrador da rede para que a chave seja atualizada. solicitando ao mesmo para trocar as senhas de tempos em tempos e cuidar da atualização de chaves quando isso acontecer. o usmUserPrivKeyChange e usmUserOwnPrivKeyChange fornecem capacidade de atualização de uma chave criptografada.43 pode configurar este objeto. mas é definido de forma a permitir a atualização apenas se o requisitante possuir o mesmo userName como objeto usmUseName para esta linha. O VACM é constituído por cinco elementos. conforme RFC 2275: Grupos: conjunto de zero ou mais duplas <securityModel. para o administrador da rede e para o usuário. Para acomodar estes dois requisitos. o que torna complexo o algoritmo de atualização de chaves. Por outro lado o usuário pode substituir sua senha e chave (s) a qualquer momento.4. securityName > nas quais os objetos de gerenciamento SNMP podem ser acessados. permitindo pelo subsistema de controle de acesso.

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. em um determinado grupo. são idênticos. Política de acesso: permite que um motor SNMP seja configurado para tornar mais sólido um conjunto restrito de direitos de acesso. Uma entidade SNMP. O nível de segurança pelo qual a requisição foi comunicada na mensagem SNMP. Visões MIB: define um conjunto especifico de objetos gerenciados. com cada subárvore sendo incluída ou excluída da visão. . 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. 2. 5. O modelo de segurança usado para processar a mensagem requisitada. a visão MIB ou inclui. 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. ou exclui todas as instâncias de objetos contidas na subárvore. Um único groupName é associado com cada grupo. para identificar uma instância de objeto individual. ou família de subárvores. 3. A visão MIB é definida como uma coleção. o VACM faz uso de uma técnica poderosa e flexível para definir visões MIB.44 um diretor e os direitos de acesso para todos os diretores. Em acréscimo. Quando múltiplos contextos existem. A determinação do acesso ou negação do mesmo depende dos seguintes fatores [1]: O diretor fazendo a requisição de acesso. Um objeto ou uma instância de objeto pode aparecer em mais de um contexto. O VACM torna possível para um agente permitir diferentes privilégios de acesso para diferentes usuários. baseadas no conceito de visões de subárvores e visões de famílias. unicamente identificada por um contextEngineID. pode manter mais de um contexto. seus contextName e contextEngineID devem ser identificados em relação ao seu tipo de objeto e sua instância. Isto significa que. 4.

e variableName. a instância do objeto específica para o qual acesso é requerido. notificação). escrita.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: .4.45 o contexto da MIB usado para a requisição. securityName. através da divisão dos componentes de controle de acesso em seis variáveis distintas.Lógica VACM A figura 6. viewType. contextName.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. Esta primitiva especifica que os parâmetros de entrada são securityModel. securityLevel. Figura 6. A primitiva isAccessAllowed define o serviço fornecido pelo subsistema de controle de acesso.2. 6.8 . o tipo de acesso requisitado (leitura.

neste securityLevel. examina em seguida o vacmAccessTable usando groupName. então o acesso é fornecido. então uma política de controle de acesso foi definida para este groupName. 4. securityName >. Por fim a variableName é confrontada com a visão MIB obtida. Como: a combinação do securityModel e do securityLevel define “como” a PDU Inform ou request foi protegida. escrita ou notificação. Se houver. identifica um dado diretor cujas comunicações são protegidas por um certo securityModel. Se não houver. 2. Se houver uma referência. 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. Se houver. o VACM realiza os seguintes passos figura 6. Agora é possível sumarizar os procedimentos usados pelo VACM para determinar se o acesso é permitido. confere o vacmSecurityToGroupTable para determinar se há um grupo associado a este par <secutityModel. então este contexto é conhecido por este motor SNMP. então um errorIndication de noGroupName é retornado. Se não for encontrada uma entrada. Onde: o contextName especifica “onde” o objeto gerenciado desejado pode ser encontrado. Se a variableName combinar com um elemento incluído na visão MIB. e securityLevel como índices. contextName . securityModel. Se não houver então um errorIndication de noSuchContext é retornado. para acessar este contextName. O vacmContextTable contém uma lista dos contextName reconhecidos. confere se há uma entrada no vacmContextTable para o contextName. Quando isAccessAllowed é invocada por uma aplicação. operando sob este securityModel. Por quê: o viewType especifica porque o acesso é requisitado: para uma operação de leitura. determina então se a entrada vacmAccessTable selecionada inclui uma referência a uma visão MIB de viewType. Se uma entrada for encontrada. então um errorIndication de noAccessEntry é retornado.9: 1. Qual: a instância de objeto indica qual item específico de informação é requisitado. então esta . então este diretor operando sob este securityModel é um membro de um grupo configurado neste motor SNMP. 3.46 Quem: o “quem” da operação é definido pela combinação do securityModel e do securityName.

Se uma visão MIB for encontrada. e viewType. então uma statusInformation de accessAllowed é retornada.9 .Fluxograma VACM . Contexto esta disponível? (vacmContextTable) sim O Grupo esta disponível? (vacmSecuritytoGroupTable) sim Entrada de acesso encontrada? (vacmAccessTable) sim Checar tipo de visão (vacmAccessTable) não noSuchContext não noGroupName não noAccessEntry noSuchView leitura gravação notificação Checar visão (vacmViewTreeFamilyTable) noSuchView Checar variável (vacmViewTreeFamilyTable) notInView accessAllowed Figura 6. contextName. Se esta variável está incluída na visão. 5.47 entrada contém um viewName para esta combinação de groupName. verifica a variableName contra a visão MIB selecionada. Caso contrário. então um errorIndication de noInView é retornado. então uma visão MIB foi configurada para este viewName. Se esta variável não estiver incluída na visão. 6. securityLevel. então um errorIndication de noSuchView é retornado. O viewName é usado como um índice na vacmViewTreeFamilyTable . securityModel. Se não houver uma referência. um errorIndication de noSuchView é retornado.

ainda. não é admitida nenhuma configuração inicial e nenhum acesso às variáveis MIBs locais durante a instalação do sistema. O groupName é utilizado para definir uma política de controle de acesso para um grupo de diretores sob um dado modelo de segurança. vacmSecurityToGroupTable. Pode haver múltiplas subárvores associadas com um dado viewName. usando a subárvore. Para os outros dois casos existi uma diferença apenas nas entradas da vacmViewTreeFamilyTable.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. Configuração inicial com segurança mínima.4. Visões MIB: a estrutura vacmMIBView consiste de um único objeto escalar: vacmViewSpinLock. Na configuração inicial sem acesso. Configuração inicial semi-segura. Direitos de acesso: a vacmAccessTable pode ser configurada para definir direitos de acesso para grupos.48 6. . Grupos: esta vacmSecurityToGroupTable fornece um groupName dado um securityModel e um securityName. 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. a máscara. O objeto vacmViewSpinLock. e vacmAccessTable são iguais para estas duas configurações. Cada entrada na vacmViewTreeFamilyTable define uma família de subárvores MIB. As demais entradas: vacmContextTable. define três possíveis configurações iniciais [1]: Configuração inicial sem acesso. 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.2. e uma tabela: vacmViewTreeFamilyTable . 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. caso no qual a visão MIB para este viewName consiste da união de todas estas subárvores.

aliviando. Melhorando a confiabilidade no desempenho de diferentes funções.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. podendo com isso estabelecer estatísticas de erro. a saber: Categoria Configuração: o monitor remoto normalmente precisara ser configurado para coletar dados. 7. colisões e outros. 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. É uma extensão o SNMP. com esses recursos dedicados. Possibilita o armazenamento de partes de pacotes ou pacotes inteiros permitindo se necessário analise futura. monitora a rede como um todo e não apenas seus componentes individuais. Esta configuração especifica o tipo de dados para serem coletados. Monitoramento preemptivo: No caso de uma falha na rede. 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. . O RMON opera enxergando cada pacote da rede. 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. e para fornecer capacidade de gerenciamento em diferentes unidades na organização.49 7. com isso a estação de gerenciamento. permite a notificação à estação gerente da falha e apresenta informações importantes no diagnostico da falha. Múltiplos gerentes: uma configuração de rede pode ter mais que uma estação gerente. o mesmo é capaz de executar funções complexas. tendo apenas capacidade de ler valores de objetos e identificar valores de objetos com visão MIB. Polling limitados reduzem custos de comunicação. Analise de Dados: o monitor pode executar analises específicas para os dados coletados na sub-rede. ou seja. A MIB RMON contém funcionalidades que suportam controle extensivo da estação de gerenciamento e se dividem em duas categorias. 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.

várias dificuldades podem surgir: Requisições concorrentes podem exceder a capacidade do monitor para fornecer estes recursos. prevenindo seu uso por outras funções gerente desejadas por outras estações gerentes. Uma estação gerente pode capturar e ocupar recursos de monitor por um longo período de tempo. nome da estação gerente. 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. creatRequest (2). invalid (4) } . é importante mencionar que o rótulo não tem efeito como o de uma senha ou mecanismo de controle de acesso. proporcionando uma técnica clara e disciplinada para se adicionar ou excluir registros. com isso. Designação de recursos para uma estação gerente que caiu sem liberá-los. 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.50 7.1. Contudo o rótulo ser vantajoso. 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). A especificação RMON sugere que o rótulo proprietário contenha um ou mais: IP. localização ou número de telefone.1 Múltiplos gerentes Um agente RMON pode ser submetido a múltiplos gerentes. nome do gerente da rede. underCreation (3). 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.

Grupo Eventos (Event): fornece uma tabela de todos os eventos gerados pelo agente RMON. Grupo Host: contém contadores de diversos tipos de tráfego para e de servidores e agregados a sub-rede. Cada objeto é identificador de instância. Grupo Alarme (Alarm): permite ao usuário definir um intervalo de amostragem e um alarme limiar para qualquer contador registrado pelo gerente.3 MIB RMON Uma MIB RMON é identificada na figura 7. Grupo Histórico: registra amostras de estatísticas da informação disponível no grupo estatística. Grupo Pacote de Captura (Capture): determina como os dados serão enviados ao console gerente. . assim possibilita ao operador reaver informações de qualquer par de endereço da rede. Grupo Matriz (Matrix): apresenta erros e informações no formato matriz. Grupo Filtro (Filter): possibilita ao monitor observar pacotes. 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. Grupo HostTopN: contém estatísticas que relatam nos servidores que alcançam uma lista baseada em alguns parâmetro no grupo host.1.51 Adição de Registro: um SetRquest PDU emitido inclui uma lista de objetos tabulares identificados na tabela. Pode capturar todos os pacotes que passem pelo filtro ou apenas gravar estatísticas baseadas nos pacotes. Grupo TokenRing: Mantêm estatísticas e informações de configuração para sub-redes TokenRing. 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.

2.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. Pode decodificar e monitorar o tráfego na camada de aplicação. Pode monitorar o tráfego com base no protocolo da camada de rede e endereços. transferência de arquivos e protocolos World Wide Web. incluindo o Internet Protocol (IP). pode também fornecer informações detalhadas do nível MAC e o tráfego para host anexado a LAN.52 Figura 7.Grupos MIB RMON 7. Estas duas capacidades são importantes e serão analisadas separadamente.1 . que se refere ao RMON2.2. capturando quadros do nível MAC e ler origem e destino nesses quadros. Tem a capacidade de ver . RMON2 decodifica pacotes em camadas 3 a 7 do modelo OSI como representado na figura 7. 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. como e-mail. Isto tem duas implicações importantes. 7.1 Nível de Rede Um RMON probe pode monitorar todo o tráfego nas LANs.

Protocol distribution (protocolDist): recolhe estatísticas agregadas sobre a distribuição do tráfego gerado por cada protocolo. 54 mostra a estrutura completa da combinação MIB RMON1 e RMON2. sendo útil no controle de carga e mantendo o desempenho da rede. Figura 7. tal como TCP e visualizar os cabeçalhos de protocolo nível de aplicação.2 Nível de Aplicação Um RMON2 probe não está limitado a monitorar e decodificar o tráfego na camada de rede. 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. A figura 7. Também pode visualizar um protocolo da camada acima e rodar em cima do protocolo de camada de rede.Relação OSI X RMON 7.53 acima do nível MAC lendo o cabeçalho do protocolo de camada de rede anexado. Em particular. 7.3 MIB RMON2 A MIB RMON2 é uma extensão da RMON MIB que acrescenta uma série de novos grupos. que é caracteristicamente IP. 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. .2 . Com RMON2. um RMON2 probe é capaz de ver acima da camada IP lendo os cabeçalhos fechados de nível superior.2.2. por segmento LAN. Isso permite que o probe possa analisar o tráfego que passa pelo roteador para determinar a origem e o destino final.3 à pág.

Network layer matrix (n1Matrix): coleta de estatísticas sobre pares de hosts baseado no endereço de camada de rede. application-layer matrix (a1Matrix): lida com a recolha de estatísticas sobre pares de hosts baseado no protocolo da camada de aplicação. bem como cada nó. User history collection (usrHistory): periodicamente coleta amostras de variáveis de um usuário especificado e registram os dados. Estes novos grupos tornam possível a visualização padrões de tráfego a nível de rede (OSI camada 3).RMON MIB Network layer host (n1Host): Monitora pacotes sobre o tráfego de entrada e saída dos hosts.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 . Probe configuration (probeconfig): define parâmetros para o padrão de configuração RMON probe. com base em parâmetros definidos pelo usuário. com base no endereço de camada de rede. Eles também tornam possível compreender protocolo e aplicação associados à utilização da rede como um todo. 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. .

OpenView Operations. 8. 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. FERRAMENTAS PARA GERENCIAMENTO DE REDES 8. 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. Provimento de ferramentas que traçam o perfil da rede em condições normais. .55 8. 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. o gerente emite relatórios automaticamente. Limita-se a: gerenciamento de falhas. OpenView Service Desk. Disponibiliza e armazena informações sobre a topologia da rede. Possibilita a recuperação de informação. OpenView Repórter. OpenViewNavigator. Se um recurso apresenta um limite considerado critico. configuração e performance das redes TCP/IP.1 HP OPENVIEW Elaborado e desenvolvido pela Hewlett-Packard Company. permitem que dados críticos de negócios e serviços estejam disponíveis a qualquer tempo. Algumas das soluções de gerenciamento HP OpenView são: OpenView Network Node Manager.1.1 Gerenciamento de Falhas Define status da rede e de dispositivos conectados a ela.

1 – Tela Service Desk – Gerência de Falhas 8. .1. Fornece mapas da rede.2 Gerenciamento de Configuração De forma automática o gerente guarda a topologia da rede e busca por novos dispositivos instalados. Relaciona todos os serviços remotos da rede.56 Figura 8. Instala novos objetos e os adiciona no inventário de controle. Restaura informações básicas de gerenciamento.

identificando.3Gerenciamento de Performance Acompanha o funcionamento da rede e apresenta vários formatos e combinações. assim. Coleta informações sobre varias MIBs para formar um histórico de dados.Gerencia de Configuração 8.1. se o sistema esta sendo utilizado de forma racional.57 Figura 8. Utiliza os recursos de coletar dados e gerar gráficos para reunir informações. Fixa os limites sobre as MIBs e detém informações sobre taxas de erros e Throughput.Tela Segment . . Monitora os recursos do sistema com a carga relativa do sistema.2 .

padrões Java. Algumas das ferramentas de software de gerência CiscoWorks são: CiscoView → apresenta através de gráficos o status on-line dos dispositivos. existem vários pacotes da família CiscoWorks. Resource Manager Essentials → possibilita o inventário dos softwares e equipamentos da rede. inventário. topologia. graficamente. Com este objetivo o CiscoWorks contém aplicativos e dispositivos dedicados para: gerência de voz. gerência de firewalls. Comercialmente. com estatísticas de utilização. XML. realizar contabilidade de uso. web server. e Campus Manager → fornece a topologia gráfica da rede com sinalização e alarmes para o estado atual do dispositivo.desenvolvida pela CISCO para prover ao usuário ferramentas capazes de detectar falhas.58 Figura 8. os equipamentos Cisco nas redes LAN. monitoramento de aplicações. VLANs. qualidade de serviço. decodificação de protocolos e SLA (Supplemental License Agreement). Redes Virtuais Privadas (VPNs).2 CISCO WORKS O CiscoWorks é uma família de aplicativos de gerência . a saber: . Wireless e WAN[2]. entre outros. avaliar performance.3 – Tela Operations Gerência de Performance 8. detecção de intrusos. CORBA e SNMP . monitorar e estabelecer segurança e configurar. controle de usuário.

Possui um repositório central para todo o software Cisco. Routed WAN Management (CWRW) → conjunto de ferramentas de software para gerência da rede de roteadores. Emprega o modelo VISTA (visão. responsáveis por manutenção de dispositivos e locais associados.solução. teste e aplicação) para automatizar o diagnostico e solução de problemas. Institui e sustenta um banco de dados que armazena um inventário completo da rede: hardware.2. versões de componentes operacionais. e Cisco VPN Security Management Solution (VMS) → conjunto de ferramentas de software para gerência da segurança da rede fim-a-fim. Atribuição de custo: permite um charge-back de custos de chamadas para as pessoas. ou locais responsáveis por eles e para conciliar as . Possui um sistema de monitorização e resolução de problemas. Informações homogêneas compartilhadas como senhas e listas de acesso podem ser configuradas para serem aplicadas automaticamente para um grupo comum de equipamento.2. 8. coletando dados de utilização e erros. unidades organizacionais.1 Gerenciamento de Falhas Possibilita entre dois equipamentos análise de roteamento.2. 8. 8. isolação.2 Gerenciamento de Configuração Permite instalar remotamente um roteador novo utilizando um roteador vizinho. Possibilita a emissão de relatórios de mensagens de syslog filtradas para isolar erros de roteadores e switches Cisco.59 LAN Management Solution (LMS) → conjunto de ferramentas de software para gerência da rede local. software.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.

2. hubs. Para processos de atualização faz uso das funcionalidades da memória flash de roteadores Cisco. locais e Equipamentos. estatística e de configuração dos switches. verifica a integridade do domínio. 8. possibilitando segurança ao ambiente CiscoWorks através de pedido de login/senha. e dividir os custos das contas. incluindo buffers.2. 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.60 declarações de prestadores de serviços de rede. Encargos adicionais podem ser atribuídas a cada conta. memória disponível e protocolos/interfaces. roteadores. 8. servidores de acesso.4 Gerenciamento de Performance Fornece um parecer sobre as condições de uso dos dispositivos. Gerenciamento de diretório: é uma base de dados contendo informações sobre pessoas. 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.5 Gerenciamento de Segurança Configura métodos de segurança para aplicações e equipamentos de rede selecionados contra invasões. Expõe graficamente uma visão dos dispositivos físicos Cisco e informação como estado dinâmico. Com o SQL do Sybase projetado para variáveis SNMP é possível fazer consultas e gerar gráficos. Registro de chamada e exibição de manutenção: permitem criar relatórios de registros de chamada. Possibilita rapidez e facilidade para localizar roteadores para atualização. concentradores e adaptadores Cisco. Apresenta uma visão ampla do roteador/LAN e do caminho do tráfego percorrido por ele. Reúne dados históricos da rede para análise off-line de tendências de desempenho e padrões de tráfego. . carga de CPU.

notificar os administradores sobre anomalias na rede ou hosts sob supervisão.) . também.61 8. É possível gerar relatórios gráficos de disponibilidade dos serviços e máquinas. Algumas características do Nagios: Monitora serviços de rede. Principais Características: Capacidade de monitorar protocolos (SMTP.3 NAGIOS Nagios é uma solução Open Source de monitoramento de serviços de rede. Esta ferramenta permite ao administrador de rede definir os níveis de alerta da maneira que lhe convir. etc. utilização de memória. shell. ICMP. tais como sua carga de processamento. Apoio à de implementação de monitoração redundante. alertando caso existam anormalidades nos mesmos. entre outros. relatórios e gráficos on-line e. logs do sistema) na maioria dos sistemas operacionais com suporte a rede.sem os quais o Nagios não tem utilidade. Rotação automática de log. etc. Todo monitoramento é feito por meio de plugins programas usados sob demanda tais como: executáveis. e arquivos de log gerados. O Nagios é um software que monitora remotamente os recursos de hosts. uso de disco. Esta ferramenta possui ambiente WEB capaz de gerar mapas da rede. 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. HTTP. Monitora recursos de computadores ou equipamentos de rede (carga do processador. 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. POP3. Ele verifica constantemente a disponibilidade do serviço. Interface web otimizada permitindo o acompanhamento do status da rede. seja local ou remoto. Através de túneis SSH ou SSL possibilita monitoração remota Checagem dos serviços simultaneamente. . Monitora recursos de hosts. utilização de banda. compilados ou scripts (Perl. SNMP). e administrá-los via interface web. tempo de resposta. Oferece serviço de notificação quando um componente ou serviço de rede apresentar problema. das notificações. do histórico de problemas.

serviços. hosts. Possibilidade de implementação de servidores de monitoramento distribuídos e redundantes. e-mail. recuperação. Sistema inteligente de notificações. etc. mapas da rede 2D e 3D. integrações com BDs.3. etc. Alertas para pagers. notificações. Interface WEB capaz de informar sobre status de redes. logs.). Relatórios.1 Gerenciamento de Falhas Em curto espaço de tempo detecta a causa real do problema e corrigir a situação. Figura 8. etc. advertências.Tela Alert History Gerência de Falhas . 8.4 ..62 Define hierarquia da rede. Os 'grupos de contato' – são notificados sobre circunstancias ou eventos (falhas. celular.

2 Gerenciamento de Performance verifica a quantidade de perda de pacotes. verifica serviços de rede individuais tais como HTTP.5 Tela Performance Information . permitindo uma panorâmica geral da situação. SMTP e DNS e. várias instalações descentralizadas ao enviar os resultados de seus testes para um ponto central. Diminui a carga no servidor de monitoramento com o redirecionamento de resultados para o servidor central. a latência e o índice de disponibilidade do Backbone.3.3 Gerenciamento de Configuração monitoramento adaptativo – faz mudanças do ajustes de monitoramento sem que necessite reinicialização do Nagios. também.63 8. . Figura 8. processos por meio da execução de carga da CPU ou arquivos de log. Permite monitoração distribuída pela qual.Gerência de Performance 8. a partir de um ponto único.3.

correlacionar e gerenciar eventos e traps SNMP.em conjunto com muitos outros atributos e recursos que possibilitam sua fácil instalação e uso. hierarquia de notificações. tratamento de eventos – quando ocorrem mudanças no estado de serviço comandos opcionais executados. segurança e performance .Tela Configuration Gerência de Configuração 8. que fornece funções de gerenciamento de configuração. Windows e OS/390 e possui recursos tais como: descobrir redes TCP/IP. . falhas. escalonamento de notificações – possibilita a criação de uma enviadas aos superiores.64 herança de definições de objetos – o tempo de configuração é reduzido facilitando suas modificações. O programa permite o gerenciamento de diversas arquiteturas e sistemas operacionais tais como UNIX.4 TIVOLI NETVIEW O programa Tivoli NetView é uma ferramenta de gerência para fornecedores heterogêneos de dispositivos de redes TCP/IP. onde todos os contatos inferiores recebem cópias das notificações Figura 8.6 . mostrar topologias de rede.

monitoramento de rede e o gerenciamento de rede . O MLM nos permite mover o monitoramento de sistema. O programa é capaz de gerenciar MIBs SNMP incluindo MIBs multiprotocolo de outros fornecedores.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. As tarefas realizadas pelo Mid-Level Manager incluem o seguinte: Descoberta de novos nós e o status polling de nós correntes. Para o gerenciamento cooperativo de redes TCP/IP. Tivoli Enterprise. O programa Tivoli NetView é uma ferramenta de gerenciamento de redes e de sistemas.da plataforma central de gerenciamento de rede (o nó gerenciado Tivoli com o Tivoli NetView instalado) para um gerente base SNMP intermediário (o MidLevel Manager) instalado em qualquer máquina TCP/IP de sua rede. O programa Tivoli NetView permite uma introdução ao aplicativo de Gerenciamento distribuído de rede. além de poder integrar aplicações multiprotocolo com o programa Tivoli NetView e topologias multiprotocolo com submaps TCP/IP.65 monitorar a saúde da rede e recolher dados de desempenho. Além disso. também. Eventos de monitoração automática de eventos e ajustes de limites (treshold). que possibilita o gerenciamento de uma rede de forma centralizada ou distribuída e. com capacidade de ser integrado a outras aplicações Tivoli. dispositivos de redes heterogêneos e. 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 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. também. o programa Tivoli NetView. Detecção automática de dispositivos novamente adicionados ou recentemente excluídos. por meio da utilização do Tivoli NetView Mid-level Manager (MLM). Adicionando-se esses objetos MIB à base de dados SNMP MIB existentes significa que um administrador. pode gerenciar fornecedores distintos. 8. prover suporte para o gerenciamento de dispositivos que não possuem um endereço IP. .4.

A figura 8. 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.7 mostra dois nós Mid-level Manager configurados para monitorar um conjunto de dispositivos SNMP na rede. Eventos são mostrados quando . A figura 8. tipo ou qualquer outro grupo conveniente para melhor distribuir o gerenciamento de sua rede. Figura 8.8 a mostra a Tela de Controle de Eventos Tivoli NetView. muitos problemas são resolvidos por meio da automação local.7 .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. reduzindo a carga de trabalho administrativo quanto ao adicionar e eliminar nós. 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.Arquitetura do gerenciamento distribuído Tivoli 8. Além disso. auxiliar na determinação e identificação de problemas na rede e fornecer mecanismos para recuperação de erros o mais rapidamente. Esses nós Mid-level Manager podem ser agrupados por localização. função.4.2 Gerenciamento De Falha O NetView tem funções para ser proativo. portanto.

NetView pode pesquisar o status dos dispositivos enviando comandos echo requests (pings) -Internet Control Message Protocol (ICMP) – e requests SNMP aos dispositivos.8 . filtrando e descartando aqueles eventos que não são importantes para sua operação.Tela de Controle de Eventos . Adicionalmente. configuração de nós ou status da rede . Pode-se reduzir significativamente a quantidade de tempo requerida pelo servidor NetView para processar a entrada de eventos. é possível selecionar nós e escolher itens de menu. Também. você pode selecionar eventos que você quer que sejam mostrados na tela. 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.8. é possível obter informações relevantes sobre o dispositivo defeituoso. usando as capacidades de filtragem e correlação do NetView. podem ser enviados.e esses eventos são recebidos pelo programa NetView. 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. Em grandes redes contendo muitos objetos e agentes.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.67 . de um mapa de topologia. limites são excedidos. Por meio da seleção do apropriado cartão de eventos. a partir de um mapa de topologia.ocorrem erros na rede. as quais podem auxiliar na rápida solução de problemas. Figura 8. mudanças na topologia de rede. A Figura 8. muitos dos eventos que o servidor NetView possa ser requisitado para processar. tais como descrição do problema. localização e contato com o fornecedor.

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

Ferramenta

FCAPS
Falhas Recupera informação; Define status dos dispositivos da rede Análise de rotas entre dispositivos; Sistema de monitoração e resolução de problemas. Configuração Mapas de rede; Instala novos objetos e os adiciona no inventário de controle Instalação remota de equipamentos; Repositório central para todo o software da CISCO. Monitoramento adaptativo; Herança de definições de objetos. Contabilização Performance Monitora carga relativa do sistema; Coleta dados e gera gráficos X Informações sobre o estado dos dispositivos; Análise off-line de padrões de tráfego. Segurança

HP OpenView

Cisco Works

Análise de custo eficácia da rede; Análise de custos por departamento

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. Eventos de mapa; Eventos de rede

Tivoli

Atualização dinâmica da topologia da rede; Descobre todos os elementos endereçáveis IP, na rede.

Verifica a perda de pacotes, a latência e a disponibilidade do backbone; Reduz a carga no servidor de monitoramento. 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

pois.devido à constante evolução da tecnologia no campo da informática. tal condição pode ser verificada no modo de operação e extensibilidade. Uma das principais vantagens do SNMP é a simplicidade que este protocolo apresenta. .estabelecer um eficaz sistema de gerenciamento é o desafio que se apresenta. No aspecto administração de redes um fator preponderante e tranqüilizador. as MIBs permitem ser alteradas para a adequação perante novas realidades. no desenvolvimento e oferta de ferramentas cada vez mais sofisticadas e eficazes. 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. Suas funcionalidades foram corrigidas e otimizadas nas versões posteriores. também. acompanhada de correspondente complexidade e diversidade dos dispositivos empregados para otimizar o desempenho das redes e acompanhada de crescente utilização . Diante do exposto depreende-se que .75 9 CONCLUSÃO Mostrou-se que o gerenciamento de redes heterogêneas é realizado de maneira simples e eficaz com uso do protocolo SNMP. principalmente no aspecto segurança da informação. é o contínuo investimento por parte das empresas de tecnologia. 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.

com. Maura & Kevin J. janeiro. WWW WWW em em 02/04/2008 04/04/2008 no no endereço endereço Nagios disponível por WWW em 08/04/2008 no endereço http://www. RFC 2275. RFC 1155. Editora Campus Ltda.. Schmidt. RFC 2274.1995. 2001.1998. RFC 1157.openview. março.ciscoredacaovirtual. disponível por WWW em 07/01/2008 no endereço http://www.based internets MIBII. RFC 1155 – INTERNET ENGINEERING TASK FORCE – Structure and identification of management information for TCP/IP-based internets. Gerência de Rede disponível http://penta2. 1999. por WWW em 11/02/2008 no endereço Introdução ao Gerenciamento de Redes.htm. RFC 2271 – INTERNET ENGINEERING TASK FORCE – An Architecture for Describing SNMP Management Frameworks.76 BIBLIOGRAFIA Stallings William. Third Edition. maio. disponível por http://www. RFC 2271.com/software/Tivoli.nagios.ufrgs. RFC 2275 – INTERNET ENGINEERING TASK FORCE – View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP).com. Tivoli NetView. Cisco Work. maio. RFC 1157 – INTERNET ENGINEERING TASK FORCE – Simple Network Management Protocol (SNMP). por WWW em 12/04/2008 no endereço Douglas R.br/homegere. .1991 RFC 1757 – INTERNET ENGINEERING TASK FORCE – Remote Network Monitoring Management Information Base.1990. RFC 1213. SNMP ESSENCIAL. RFC 1213 – INTERNET ENGINEERING TASK FORCE – Management Information Base for Network Management of TCP/IP.1998. RFC 1757. janeiro 1998.br. Editora AddisonWesley.rnp. fevereiro.org HP Open View disponível http://support. disponível por http://www.hp. SNMPv2. SNMP. janeiro. RFC 2274 – INTERNET ENGINEERING TASK FORCE – User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). SNMPv3 and RMON 1 and 2.1990.ibm.

Sign up to vote on this title
UsefulNot useful