i UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CINCIAS EXATAS E NATURAIS CURSO DE CINCIAS DA COMPUTAO (Bacharelado)

PROTTIPO DE UM SISTEMA DE MONITORAMENTO DE DESEMPENHO DE REDES DE COMPUTADORES BASEADO NO PROTOCOLO SNMPV3.

TRABALHO DE CONCLUSO DE CURSO SUBMETIDO UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTENO DOS CRDITOS NA DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CINCIAS DA COMPUTAO BACHARELADO

ANDERSON KARING

BLUMENAU, NOVEMBRO/2002 2002/2-03

ii

PROTTIPO DE UM SISTEMA DE MONITORAMENTO DE DESEMPENHO DE REDES DE COMPUTADORES BASEADO NO PROTOCOLO SNMPV3.

ANDERSON KARING

ESTE TRABALHO DE CONCLUSO DE CURSO FOI JULGADO ADEQUADO PARA OBTENO DOS CRDITOS NA DISCIPLINA DE TRABALHO DE CONCLUSO DE CURSO OBRIGATRIA PARA OBTENO DO TTULO DE:

BACHAREL EM CINCIAS DA COMPUTAO

Prof. Francisco Adell Pricas Orientador na FURB

Prof. Jos Roque Voltolini da Silva Coordenador do TCC

BANCA EXAMINADORA

Prof. Francisco Adell Pricas

ii

iii

AGRADECIMENTOS
Agradeo a todos os professores do curso de Bacharelado em Cincias da Computao da Universidade Regional de Blumenau pela ajuda prestada ao longo do curso, principalmente aos professores Francisco Adell Pricas por ter me orientado neste trabalho final e o professor Roberto Heinzle pelo apoio dado num momento crtico do curso quando eu pensava em desistir. Muito obrigado pela pacincia, preocupao e dedicao. Agradeo a todos os novos amigos que conheci em Blumenau no decorrer da Faculdade, principalmente ao Renato, Rafael, Fernando, Carlos, Erasmo, Hensel, Gilson, Edson tatu, Marcelo, e a todo o pessoal do NI, especialmente ao Fbio por acreditar em meu potencial. Na ala feminina agradeo Marilda, Silvanira, Fernanda e Michele. Obrigado a todos vocs pela fora, apoio e companhia no decorrer do curso. Agradeo a toda galera da sala, que mesmo nos momentos mais difceis sempre ajudavam uns aos outros. Agradeo principalmente aos meus pais Valmor e Renate e aos meus irmos Max e Ana, por terem me dado todo o apoio nessa luta, no fosse a dedicao deles, no poderia estar aqui agora redigindo meu trabalho final. Agradeo aos motoristas da Geneve por levarem e buscarem de Brusque para Blumenau, a mim e a todos os demais estudantes de Brusque, com segurana durante estes seis anos. Agradeo ao pessoal da Igreja Luterana de Bateias, por ter permitido que eu deixasse minha bike l guardada enquanto estudava, facilitando assim minha vida. Agradeo tambm ao Governo Estadual pelo auxlio financeiro prestado, e podem ter certeza: fiz valer cada centavo em mim investido. Finalmente, agradeo a Marcela e a Brbara por serem as garotas mais incrveis (e lindas!) que j conheci, e por terem compartilhado dos momentos mais marcantes da minha vida at hoje.

iii

iv

EPGRAFE
Os verdadeiros vencedores no so aqueles que chegam na frente, mas sim aqueles que com muita garra, paixo e dedicao chegam ao final. (autor desconhecido)

iv

SUMRIO
LISTA DE FIGU RAS...........................................................................................................VII LISTA DE ABREVIATURA S E LISTA DE SIGLAS.....................................................VIII LISTA DE ABREVIATURA S E LISTA DE SIGLAS........................................................IX RESUMO..............................................................................................................................XIII ABSTRACT..........................................................................................................................XIV 1 1.1 1.2 2 2.1 2.2 2.2.1 2.2.2 2.2.3 3 3.1 3.2 3.2.1 4 4.1 4.1.1 4.1.2 4.1.2.1 4.1.2.1.1 4.1.2.2 4.1.2.3 4.1.3 4.1.4 4.1.5 4.1.6 5 5.1 5.1.1 5.1.2 5.1.3 5.1.4 INTRODUO.....................................................................................................1 OBJETIVOS DO TRABALHO ......................................................................................3 E STRUTURA DO TRABALHO .....................................................................................3 FUNDAMENTAO TERIC A.......................................................................5 BREVE HISTRICO DE REDES DE COMPUTADORES .................................................5 REDES DE COMPUTADORES .....................................................................................6 Uso Das Redes De Computadores ..........................................................................7 Hardware De Rede ..................................................................................................8 Software De Rede ...................................................................................................9 GERNCIA DE REDES DE COMPUTADORES..........................................13 ARQUITETURA DE UM SISTEMA DE GERENCIAMENTO DE REDES ......................... 16 GERENCIAMENTO D E DESEMPENHO ...................................................................... 19 Funo De Monitoramento De Desempenho .......................................................22 SIMPLE NETWORK MANAGEMENT PROTOCOL..................................24 CONCEITOS BSICOS DE SNMP ............................................................................ 25 Arquitetura ............................................................................................................ 26 SMI Structure Of Management Information ..................................................... 28 Estrutura MIB .......................................................................................................29 Subgrupo IP .......................................................................................................... 32 ASN.1 ...................................................................................................................34 Codificao...........................................................................................................35 Trap-directed Polling ............................................................................................ 35 Proxy ..................................................................................................................... 37 Comparativo Entre As Verses SNMP ................................................................. 38 Consideraes Finais Sobre O SNMP .................................................................. 41 SNMPV3 ..............................................................................................................42 M OTOR SNMP V3.................................................................................................. 43 Despachante .......................................................................................................... 44 Subsistema De Processamento De Mensagens..................................................... 44 Subsistema De Segurana ..................................................................................... 45 Subsistema De Controle De Acesso ..................................................................... 46 v

vi 5.1.5 5.1.6 5.2 5.3 5.3.1 5.4 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.5 5.5.1 5.5.2 5.5.3 5.5.4 5.6 5.6.1 5.6.2 5.6.3 5.7 5.7.1 5.8 6 6.1 6.2 6.2.1 6.2.2 6.2.3 6.3 6.3.1 6.3.2 6.4 7 7.1 Gerente Snmp Tradicional.................................................................................... 47 Agente SNMP Tradicional ...................................................................................49 APLICAES SNMP ...............................................................................................50 P ROCESSAMENTO DE M ENSAGENS SNMP V3 ........................................................ 51 Formato Das Mensagens SNMPv3.......................................................................51 ALGORITMOS CRIPTOGRFICOS USADOS P ELO SNMP V3 ..................................... 53 Conceitos Bsicos De Criptografia .......................................................................53 Data Encryption Standard (DES) .......................................................................... 55 Message Digest 5 (MD5) ...................................................................................... 56 Secure Hash Function (SHA-1) ............................................................................ 57 Autenticao De Mensagens Com O HMAC .......................................................57 U SER- BASED SECURITY MODEL USM................................................................ 58 Parmetros De Segurana USM ...........................................................................59 Funes Criptogrficas Usadas Pelo USM ...........................................................63 Processamento De Mensagens USM .................................................................... 64 Descoberta ............................................................................................................ 70 GERENCIAMENTO D E CHAVES ...............................................................................71 Algoritmo De Transformao De Senha Para Chave ...........................................71 Localizao De Chaves......................................................................................... 72 Atualizao De Chaves ......................................................................................... 74 VIEW-BASED ACCESS CONTROL M ODEL - VACM ................................................ 75 A MIB VACM ...................................................................................................... 81 A API ADVENTN ET SNMP V3...............................................................................85 DESENVOLVIMENTO DO PROTTIPO.....................................................88 REQUISITOS P RINCIPAIS DO P ROBLEMA A SER TRABALHADO ...............................88 ESPECIFICAO ...............................................................................................89 Diagramas de Casos de Uso ................................................................................. 89 Diagrama de Classes ............................................................................................. 90 Diagramas de Seqncia .......................................................................................93 IMPLEMENTAO............................................................................................ 98 TCNICAS E FERRAMENTAS UTILIZADAS ................................................ 98 OPERACIONA LIDADE DA IMPLEMENTAO .........................................107 RESULTADOS E DISCUSSO........................................................................ 112 CONCLUSES.................................................................................................113 EXTENSES .....................................................................................................115

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

vi

vii

LISTA DE FIGURAS
FIGURA 1 Estrutura das camadas......................................................................................... 10 FIGURA 2 Camadas do modelo de referncia OSI...............................................................11 FIGURA 3 Elementos de um sistema de gerenciamento de redes ........................................ 17 FIGURA 4 Arquitetura de uma entidade proxy ..................................................................... 18 FIGURA 5 O papel do SNMP ...............................................................................................27 FIGURA 6 - Grupos de objetos MIB-2 .................................................................................... 30 FIGURA 7 Configurao de proxy ........................................................................................ 37 FIGURA 8 Entidade SNMPv3 .............................................................................................. 43 FIGURA 9 Subsistema de processamento de mensagens ..................................................... 44 FIGURA 10 Subsistema de segurana .................................................................................. 45 FIGURA 11 Subsistema de controle de acesso..................................................................... 46 FIGURA 12 Gerente SNMPv3 tradicional............................................................................ 48 FIGURA 13 Agente SNMPv3 convencional......................................................................... 49 FIGURA 14 Formato da mensagem SNMPv3 ...................................................................... 51 FIGURA 15 Criptografia convencional................................................................................. 54 FIGURA 16 Formato da mensagem SNMPv3 com USM ..................................................... 61 FIGURA 17 Processamento de mensagens USM: transmisso............................................ 65 FIGURA 18 - Processamento de mensagens USM: recepo...............................................67 FIGURA 19 Localizao de chaves ...................................................................................... 73 FIGURA 20 Lgica VACM .................................................................................................. 78 FIGURA 21 Fluxograma VACM .......................................................................................... 80 FIGURA 22 A MIB VACM .................................................................................................. 83 Figura 23 - Diagrama de casos de uso...................................................................................... 89

vii

viii Figura 24 - Diagrama de Classes: parte agente ........................................................................ 90 Figura 25 - Diagrama de Classes: parte gerente .......................................................................91 Figura 26 - Obter informaes de desempenho ........................................................................ 93 Figura 27 - Inicializao do gerente ......................................................................................... 95 Figura 28 - Inicializao do agente ...........................................................................................97 Figura 29 - Tela Inicial da aplicao gerente ..........................................................................109 Figura 30 - Medio inicial.....................................................................................................111 Figura 31 - Medio final .......................................................................................................112

viii

ix

LISTA DE ABREVIATURAS E LISTA DE SIGLAS

AGR - Aplicao de Gerenciamento de Rede API - Aplication Programing Interface ARPA - Advanced Research Projects Agency ASN.1 - Abstract Syntax Notation dot One BER - Basic Encoding Rules CBC - Cipher Block Chaining CMIP - Common Management Information Protocol CMIS - Common Management Information Service CMOT - Common Management Information Protocol over TCP/IP CORBA - Common Object Request Broker Architecture DES - Data Encryption Standard DoD - Department of Defense DQDB - Distributed Queue Dual Bus ECB - Electronic Codebook EGP - Exterior Gateway Protocol EGR - Entidade de Gerenciamento de Rede EJB - Enterprise Java Beans FTP - File Transfer Protocol HMAC - Hashing for Message Authentication Code ix

x HMP - Host Monitoring Protocol HTTP - Hipertext Transfer Protocol IAB - Internet Architecture Board ICMP - Internet Control Message Protocol IEC - International Electrotecnical Comission IEEE - Institute of Electrical and Eletronics Engineers IETF - Internet Engineering Task Force IP - Internet Protocol ISO - International Organization for Standardization JNI - Java Native Interface JVM Java Virtual Machine LAN - Local Area Network MAC - Message Authentication Code MAN - Metropolitan Area Network MD5 - Message-digest 5 MIB - Management Information Base MIT - Massachussets Institute of Technology MS-DOS Microsoft Disk Operation System MTU - Maximum Transfer Unit NCP - Network-Control Protocol NIST - National Institute of Standards and Tecnology x

xi NMS - Network Management Station OSI - Open Systems Interconection PC - Personal Computer PDU - Protocol Data Unit PhD - Doctor of Philosophy PING - Packet Internet Groper PPP - Point to Point Protocol QoS - Quality of Service RFC - Request for Comment RMI - Remote Method Invocation SAS - SNMP Applet Server SET - Secure Electronic Transaction SGMP - Simple Gateway Monitoring Protocol SHA-1 - Secure Hash Algorithm 1 SMI - Structure of Management Information SNA - System Network Architecture SNMP - Simple Network Management Protocol SNMPv3 - Simple Network Management Protocol version three SSL - Secure Socket Layer TCP - Transmission Control Protocol TTL - Time-To-Live

xi

xii UDP - User Datagram Protocol UI - User Interface UML - Unifield Modeling Language XML - Extensible Markup Language XNS - Xerox Network Systems XOR - Xtended OR WAN - Wide Area Network WWW - World Wide Web

xii

xiii

RESUMO
Este trabalho apresenta um estudo de usabilida de do protocolo de gerenciamento de redes Simple Network Management Protocol version three (SNMPv3), atravs da especificao e implementao de um prottipo de um sistema de gerenciamento de desempenho para dispositivos de uma Local Area Network (LAN), ut ilizando na sua implementao a Aplication Programing Interface (API) da empresa AdventNet escrita com a linguagem Java.

xiii

xiv

ABSTRACT
This paper presents a study of usability of the Simple Network Management Protocol version three (SNMPv3) through the specif ication and implementation of a prototype of a performance management system for Local Area Network (LAN) devices, using for its implementation the AdventNets Aplication Programing Interface (API) written with the Java language.

xiv

1 INTRODUO
Segundo Kurose (2001), devido ao fato de uma rede de computadores consistir de muitas partes complexas de hardware e software tais como links, equipamentos, pontes, roteadores e outros dispositivos, quando centenas ou milhares destes dispositivos so conectados uns aos outros para formar uma rede, de se esperar que componentes iro eventualmente funcionar mal, que elementos de rede podero ser desconfigurados, que recursos da rede sero superutilizados, ou que componentes de rede iro simplesmente quebrar (como por exemplo, o corte de um cabo). O administrador de redes deve estar apto a solucionar (e melhor ainda, evitar) tais problemas. O administrador de redes precisa claramente de ferramentas para ajudar a monitorar, analisar, gerenciar e controlar a rede. Lynch (1993) cita que, at recentemente, o gerenciamento de redes se baseava nos avanos tcnicos em outras reas de redes baseadas em padres abertos; de certa forma ainda assim. Uma das razes para isso que h uma discordncia sobre o que realmente significa gerenciamento de redes. Como resultado, tem havido fundamentalmente diferentes abordagens ao problema de gerenciamento de redes. Algumas destas abordagens foram prticas, obtendo grande aceitao para solucionar parte do problema de gerenciar redes baseadas em protocolos de rede abertos. O protocolo Simple Network Management Protocol (SNMP) a chave da estrutura de gerenciamento de redes de computadores. um padro aberto e operacional. A estrutura de gerenciamento SNMP foi originalmente desenhada para uso em redes Transmission Control Protocol/Internet Protocol (TCP/IP), mas vm encontrando aplicao em reas bem distantes daquelas para as quais foi inicialmente planejada. A estrutura SNMP constitui um padro aberto para gerenciamento de redes, como esta belecido pelo Internet Architecture Board (IAB). Conseqentemente, o SNMP pode ser dito como sendo um padro declarado de jure. Padres declarados que no estejam disponveis so de pouca utilidade. Entretanto, este certamente no o caso do SNMP. Vendedores o implementaram, consumidores o adquiriram, desenvolvedores de aplicaes de redes o disponibilizaram, e administradores de redes o usam ativamente. Conceitualmente, para Zeltserman (1999), o SNMPv3 nada mais do que uma estrutura que estende o SNMP original. As duas maiores extenses so a adio de primitivas de segurana e de administrao. Alm disso, o SNMPv3 define novas Management

2 Information Base MIBs, para configurar segurana, notificaes, redirecionamento de proxy e controle de acesso baseado em vises. Isto uma faca de dois gumes pois pela primeira vez possui-se uma forma padro para que um administrador de redes possa remotamente configurar estas caractersticas. Por outro lado, configurar segurana e controles de acesso baseados em vises adiciona complexidade. De acordo com Carvalho (1993), a abrangncia do gerenciamento de redes muito grande, envolvendo principalmente as reas de: a) gerenciamento de falhas: responsvel pela manuteno e monitoramento do estado de cada um dos objetos gerenciados e pelas aes necessrias ao restabelecimento das unidades com problemas; b) gerenciamento de configurao: tem por funo a manuteno e monitorao da estrutura fsica e lgica da rede, incluindo a existncia de componentes e sua interconectividade; c) gerenciamento de segurana: aborda os aspectos de segurana essenciais para operar uma rede corretamente e proteger os objetos gerenciados; d) gerenciamento de contabilizao: preocupa-se com a manuteno e monitorao de quais recursos e de quanto desses recursos esto sendo utilizados; e) gerenciamento de desempenho: preocupa-se com o desempenho corrente da rede, incluindo parmetros estatsticos tais como atrasos, vazo, disponibilidade e nmero de retransmisses. Consiste em um conjunto de funes responsveis por manter e examinar registros, com histrico dos estados do sistema para fins de planejamento e anlise. O gerenciamento de desempenho confundido, s vezes, com o gerenciamento de falhas. Muitos tendem a confundir desempenho com disponibilid ade. O gerenciamento de desempenho importante no s para garantir a qualidade de servio acordada com os usurios, como tambm para assegurar que esta atingida com os menores custos possveis. Pode-se, por meio do gerenciamento de desempenho, adequar os recursos utilizados pelos usurios s suas necessidades, auxiliando o setor responsvel pela administrao de redes a antecipar-se aos usurios na manuteno dos nveis de desempenho dos servios oferecidos,

3 como por exemplo, o tempo de resposta. O gerenciamento de desempenho est diretamente relacionado ao planejamento da capacidade do sistema sob gerenciamento. O trabalho proposto apresenta como relevncia em computao a implementao na linguagem Java de um prottipo de um sistema para a gerncia de redes de computadores utilizando o protocolo SNMPv3, visando o monitoramento de desempenho de dispositivos de uma LAN.

1.1 OBJETIVOS DO TRABALHO

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

1.2 ESTRUTURA DO TRABALHO

Este trabalho est organizado em captulos, conforme apresentados a seguir. O captulo 1 apresenta a estrutura geral do trabalho: a introduo, os objetivos, a localizao dos assuntos abordados e a organizao do trabalho. O captulo 2 apresenta um breve histrico das redes de computadores, sua estrutura bsica, caractersticas e tecnologias. O captulo 3 trata especificamente do gerenciamento de redes: conceitos, caractersticas e modelos so apresentados, e o modelo de gerenciamento de desempenho de redes estudado com mais detalhes. O captulo 4 aborda o protocolo de gerenciamento de redes SNMP. Suas caractersticas, estrutura e elementos so brevemente estudados.

4 O captulo 5 aborda especificamente o protocolo SNMPv3: suas caractersticas, estrutura e seus elementos. Tambm apresenta a criptografia e seus conceitos bsicos como autenticao, privacidade, gerenciamento de chaves, modelos e algoritmos utilizados no desenvolvimento do prottipo. O captulo 6 voltado ao desenvolvimento do prottipo, onde so apresentadas a especificao e a implementao do prottipo. E por fim, o captulo 7 dedicado s concluses e sugestes de continuidade do trabalho.

2 FUNDAMENTAO TERIC A
A seguir ser apresentada uma breve fundamentao terica, com o objetivo de posicionar o trabalho no tema abordado.

2.1 BREVE HISTRICO DE REDES DE COMPUTADORES

Segundo Kurose (2001), devido ao crescimento da importncia dos computadores no incio dos anos 60, e do advento dos computadores com processamento paralelo, foi natural considerar a questo de como os computadores poderiam ser interligados, podendo assim, ser compartilhados entre usurios geograficamente distribudos. Mas o trfego gerado por tais usurios causava pesados perodos de atividade, como o envio de um comando a um computador remoto, seguido de perodos de inatividade enquanto este aguardava o retorno do resultado ou enquanto se estudava a resposta recebida. Era preciso resolver este problema, e a soluo surgiu em 1964 atravs de trs grupos de pesquisa independentes: Leonard Kleinrock do Massachussets Institute of Technology (MIT), Paul Baran do Rand Institute e Donald Davis e Roger Scantlebury do National Physical Laboratory da Inglaterra, todos inconscientes uns dos outros, inventaram o conceito de troca de pacotes como uma alternativa eficiente e robusta para substituir a transmisso de dados por circuitos, usada at ento. J.C.R Licklider e Lawrence Roberts, ambos colegas de Kleinrock, publicaram um plano geral para a chamada ARPAnet da Advanced Research Projects Agency (ARPA) em 1969, criando a primeira rede de computadores usando a troca de pacotes e ancestral direta da atual Internet. Em 1972 o primeiro protocolo host-to-host usado na ARPAnet conhecido como Network -Control Protocol (NCP) estava pronto. Com um protocolo fim-a-fim disponvel, a partir daquele momento aplicaes poderiam ser escritas. A ARPAnet era uma rede simples e fechada. Entretanto, na metade dos anos 70, outras redes baseadas na troca de pacotes surgiram. Dentre elas podem-se citar a ALOHAnet, uma rede de microondas ligando as universidades da ilha do Hawai; a Telenet, uma rede comercial pertencente ao BBN, e a Tymnet e Transpac, ambas redes de troca de pacotes francesas. O nmero das redes de computadores comeava a crescer. Em 1973, a tese de Ph.D. de Robert Metcalfe demonstrou os princpios da Ethernet, que mais tarde levaram a um enorme crescimento das chamadas LANs. Era chegado o momento de desenvolver uma arquitetura

6 para conectar as redes entre si. Trabalhos pioneiros sobre interconexo de redes foram feitos por Vinton Cerf e Robert Kahn, novamente sob patrocnio da ARPA. Estes princpios arquiteturais de interconexo foram incorporados ao protocolo TCP. Alias, os trs protocolos chave usados hoje nas redes de computadores TCP, User Datagram Protocol (UDP) e IP estavam conceitualmente de finidos j no final dos anos 70. A tecnologia Ethernet representou um passo importante para a interconexo de redes. Cada LAN Ethernet era em si uma rede e, com a proliferao do nmero de LANs, a necessidade de interlig -las tornou-se cada vez mais impor tante. Muitas companhias desenvolveram suas prprias arquiteturas de redes proprietrias como a DEC com a DECnet (1975), a Xerox com a arquitetura Xerox Network System - XNS e a IBM com a arquitetura System Network Architecture - SNA. Os anos 80 foram um perodo de tremendo crescimento. Muito do crescimento foi resultado do grande esforo de criar redes de computadores ligando as universidades entre si. Em 1983 a ARPAnet terminou o desenvolvimento do TCP/IP e o adotou em sua rede como o novo protocolo padro em substituio ao NCP. Nos anos 90 dois eventos simbolizaram a evoluo e a comercializao das redes. Primeiro, a progenitora da Internet, a ARPAnet deixou de existir, tornando-se comercial dando origem a atual Internet. Mas o principal evento foi o surgimento da World Wide Web (WWW), que trouxe a Internet, e por conseqncia, as redes, s casas e negcios de milhes e milhes de pessoas ao redor do mundo. Alm disso, ao longo dos anos 90, pesquisas e desenvolvimento em redes de computadores realizara m avanos nas reas de roteadores de alta velocidade, roteamento, aplicaes de tempo real e LANs, gerando uma enorme expanso no uso das redes de computadores nos dias atuais.

2.2 REDES DE COMPUTADORES

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

2.2.1

USO DAS REDES DE COMPUTADORES

Segundo Tanenbaum (1997), devido ao rpido progresso tecnolgico nas reas de

telefonia, rdio e tv, satlite e computadores, estas reas esto convergindo rapidamente e h uma diferena cada vez menor entre coleta, transporte, armazenamento e processamento de informaes. medida que cresce a capacidade de colher, processar e distribuir informaes, torna-se ainda maior a necessidade de formas de processamento de informaes ainda mais sofisticadas. Esta fuso entre os computadores e as comunicaes foi de grande importncia para o surgimento das redes de computadores. Uma rede de computadores um conjunto de computadores autnomos interconectados. Dois ou mais computadores so ditos interconectados quando podem trocar informaes (Tanenbaum, 1997). Algumas razes econmicas e tecnolgicas para a instalao de redes de computadores so: a) compartilhamento de recursos: disponibilizar todos os programas, recursos e dados a todos os usurios da rede, independentemente da localizao fsica dos recursos e dos usurios; b) aumento de confiabilidade: viabilizar fontes alternativas de fornecimento de recursos (como exemplo, pode-se citar um arquivo salvo em trs computadores diferentes e assim, se um deles falhar, o arquivo poder ser obtido de um dos outros dois computadores); c) economia de dinheiro: a relao custo/desempenho dos computadores de pequeno porte muito melhor do que a dos computadores de grande porte; d) escalabilidade: possibilitar o aumento gradual do desempenho do sistema medida que cresce o volume de carga, bastando para tal, que se adicionem mais processadores; e) meio de comunicao: uma rede de computadores representa um meio de comunicao altamente eficaz para funcionrios que trabalham em locais muito distantes uns dos outros, aumentando assim, o esprito de equipe entre grandes grupos de pessoas.

8 Alm destas razes de eficincia corporativa podem-se citar outros motivos para a interconexo de computadores: a) acesso s informaes remotamente (ex: transaes financeiras e comrcio eletrnico); b) comunicao pessoa a pessoa (ex: correio eletrnico); c) entretenimento (ex: jogos on-line).

2.2.2

HARDWARE DE REDE
H duas dimenses gerais nas quais as redes de computadores podem ser classificadas

segundo Tanenbaum (1997): a escala e a tecnologia de transmisso. So dois, os tipos principais de tecnologia de transmisso: a) redes de difuso (broadcasting ): possuem apenas um canal de comunicao que compartilhado por todas as mquinas; b) redes ponto a ponto (unicasting ): consistem em conexes entre pares individuais de mquinas. Quanto escala, as redes de computadores podem ser classificadas em: a) redes locais: tambm chamadas de LANs, so redes geralmente privadas, contidas em um prdio ou em um campus universitrio; b) redes metropolitanas: tambm chamadas Metropolitan Area Networks (MANs), so uma verso ampliada de uma LAN, podendo abranger uma cidade inteira e que utilizam um protocolo de transmisso especial: o Distributed Queue Dual Bus (DQDB). Podem ser pblicas ou privadas; c) redes geograficamente distribudas: tambm chamadas Wide Area Networks (WANs), abrangem uma ampla rea geogrfica, com freqncia um pas ou continente. So compostas por equipamentos (mquinas que executam programas de usurios) e sub-redes (compostas por linhas de transmisso e elementos de comutao). As redes locais possuem trs caractersticas que as diferenciam das demais: a) tamanho: restrito, o que significa que o pior tempo de transmisso limitado e conhecido. O conhecimento desse limite permite a utilizao de determinados tipos

9 de projetos que em outras circunstncias seriam inviveis, alm de simplificar o gerenciamento da rede, foco do presente trabalho; b) tecnologia de transmisso: quase sempre consiste em um cabo ao qual todas as mquinas esto conectadas; c) topologia: as LANs de difuso aceitam vrias topologias, dentre as quais pode -se citar a de barramento e a de anel. Para o desenvolvimento do presente trabalho ser utilizada uma LAN de difuso conectada por cabos com uma topologia de barramento padro LAN Ethernet, conforme definido pelo Institute of Electrical and Eletronics Engineers (IEEE) em IEEE 802.3.

2.2.3

SOFTWARE DE REDE
Ta nenbaum (1997) cita que para reduzir a complexidade do projeto, a maioria das

redes foi organizada como uma srie de camadas ou nveis que so colocados um em cima do outro. O objetivo de cada camada oferecer determinados servios para as camadas superiores, ocultando detalhes de implementao desses recursos. Um servio um conjunto de primitivas (operaes) que uma camada oferece para a camada imediatamente acima dela. Os servios podem ser de dois tipos: orientados conexo e sem conexo. J as operaes podem ser: Request, Indication , Response e Confirm. Os servios so classificados tambm pela sua qualidade de servio (QoS - Quality of Service) que a garantia de que uma mensagem chegue ntegra ao seu destino. Os elementos ativos em cada camada s o freqentemente chamados de entidades. As entidades de um mesmo nvel/camada que se encontram em diferentes mquinas so chamadas de pares (peers) e a comunicao entre os pares feita usando o protocolo da camada. Um protocolo basicamente um conjunto de regras que controla o formato e o significado dos quadros, pacotes, ou mensagens trocadas pelas entidades pares contidas em uma camada. Entre cada par h uma interface que define as operaes e os servios que a camada inferior tem a oferecer a camada superior. Para compreender este modelo veja a figura 1.

10

FIGURA 1 Estrutura das camadas

E s tru tu ra d as C am a d as
P r oc e s s o d e tr a n s m is s o Dados Pr o t oc o lo d e C a m ad a d e A p lic a o ap li c a o PH AH Dados C am a da d e A p li c a o P r o c e s s o de re c e p o

P ro to P ro t o c ol o d e C a m ad a d e A pr e s e nt a o a p r e s e n t a o C am ad a d e S e s s o P r oto c o lo d e sesso C a m a d a d e T r a ns p o r te P ro to c o l o d e t ra n s p or te C a m a d a d e R e de P ro to c ol o d e r e de C a m a d a de E n l a c e DH NH TH SH

Dados

C am ad a d e A p r e s e n ta o

Dados

C am a d a d e S e s s o

D ados

C a m a d a d e T r an s p o rt e

D ados

C a m a da d e R e d e

D a d os

DT

C a m a d a d e E n l ac e

C am a d a F s ic a

B it s

C a m ad a F s ic a

C a m in h o d a tr a ns m is s o d e da d o s

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

Como se v, na verdade os dados no so diretamente transmitidos da camada n de uma mquina para a camada n da outra. Cada camada, na verdade, transfere os dados e as informaes de controle para a camada imediatamente abaixo dela, at a ltima camada ser alcanada. Abaixo desta camada est o meio fsico atravs do qual se d a comunicao propriamente dita. Na outra ponta o processo inverso realizado. Um conjunto de camadas de protocolos chamado de arquitetura de rede, e uma lista de protocolos usados por um determinado sistema, um protocolo por camada, chamado de pilha de protocolos. Dentre as arquiteturas de rede podem-se citar o modelo de referncia Open Systems Interconnection (OSI) e o modelo de referncia Internet. O modelo de referncia OSI foi especificado pela International Organization for Standardization/International Electrotechnical Comission (ISO/IEC) e possui sete camadas (fig. 2):

11
FIGURA 2 Camadas do modelo de referncia OSI

Ca m ada 7 A p l ic a o In te r fa c e 6 A p r e se n t a o In t e r fa c e 5 Sess o

C a m a d a s d o Mo d e l o d e R e fe r n c ia O S I
P ro t oc o l o d e a p li c a o A p lica o

U n id a d e AP D U

P r o to c o lo d e a p r e s e n ta o

A p r e s e n ta o

P PD U

P ro to c o l o d e s e s s o

Sesso

SP D U

P r oto c olo d e tr an s p or te 4 T r an s p or te T r an s p or t e TP D U

P r o to c o lo d e r e d e 3 R ede R ede P a c o te

P r o to c olo d e e n l a c e 2 E n la c e d e d a d o s E nlac e de da dos Q uadr o

T r a n s m is s o d e d a d o s 1 F s i c a H ost A F s ic a H os t B B it

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

Cada camada responsvel por uma funo especfica, conforme descrito a seguir: a) fsica: trata da transmisso de bits brutos atravs de um canal de comunicao; b) enlace: transforma um canal de transmisso de dados brutos em uma linha que parea livre dos erros de transmisso no detectados na camada de rede; c) rede: especifica o modo como os pacotes so roteados da origem para o destino; d) transporte: sua principal funo realizar a diviso dos dados em pacotes de tamanhos compatveis com a camada de rede a ser utilizada e, reagrup-los sem erros na outra extremidade. Esta a verdadeira camada fim-a-fim que liga a origem ao destino atravs da resoluo de seus endereos e nomes. tambm a camada responsvel pelo estabelecimento das conexes e pelo controle de fluxos; e) sesso: permite que usurios de diferentes mquinas estabeleam sesses entre si. Um dos servios desta camada gerenciar o controle de trfego; f) apresentao: preocupa-se com a sintaxe e a semntica das informaes transmitidas, como por exemplo, a codificao dos dados de acordo com o padro estabelecido; g) aplicao: possui aplicaes especficas para o protocolo, tais como transferncia

12 de arquivos, gerncia de rede, etc. Observa -se que o modelo OSI em si no uma arquitetura de rede, pois no especifica os servios e os protocolos que devem ser usados em cada camada. Ele apenas informa o que cada camada deve fazer. O modelo OSI possui trs conceitos fundamentais: a) servios; b) interfaces; c) protocolos. Esta separao entre estes trs conceitos talvez seja a maior contribuio do modelo OSI, pois torna explcita a distino entre estes trs conceitos. O servio informa o que a camada faz. A interface de uma camada informa como os processos acima dela podem acessla, e finalmente, que os protocolos utilizados em uma camada so de responsabilidade apenas dessa camada e estes especificam a forma com que a camada implementa seus servios atravs das interfaces. O modelo de referncia Internet segundo Kurose (2001) possui cinco camadas: a) aplicao: responsvel pelas aplicaes de rede. Inclui vrios protocolos como Hipertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), SNMP, etc; b) transporte: fornece os servios para o transporte das mensagens da camada de aplicao entre os lados cliente e servidor da aplicao. Possui dois protocolos: TCP (orientado conexo) e o UDP (no orientado conexo). c) rede: responsvel pelo roteamento de datagramas de um equipamento para outro. Possui o IP, que define os campos do datagrama IP e protocolos de roteamento, que ditam a rota a ser tomada pelos datagramas IP entre a origem e o destino; d) enlace: a camada de rede roteia um pacote entre uma srie de transmissores de pacotes (chamados roteadores) entre a origem e o destino. Como exemplos de camadas de enlace podem-se citar o padro Ethernet e o Point to Point Protocol (PPP); e) fsica: enquanto o trabalho da camada de enlace mover frames inteiros de um n para o outro, o trabalho da camada fsica o de mover bits individuais de cada frame de um n para o outro.

13

3 GERNCIA DE REDES DE COMPUTADORES

Segundo Stallings (2001), as redes de computadores e os sistemas de processamento distribudo so de crescente importncia e, de fato, se tornaram essenciais no mundo dos negcios. Hoje em dia, uma organizao tpica possui uma arquitetura de redes grande e crescente, mas amrfica, com vrias redes locais (LANs) e redes de larga escala (WANs), suportadas por pontes (bridges) e roteadores (routers), e uma grande variedade de servios e dispositivos computacionais distribudos, incluindo Personal Computers - PCs, estaes de trabalho, e servidores (inclusive mainframes). Com esse crescimento em escala das redes de computadores, dois fatos se tornam dolorosamente evidentes: a) a rede e seus recursos a ela associados, se tornaram indispensveis para a organizao; b) mais coisas podem dar errado, interrompendo o funcionamento da rede ou de parte dela, degradando o desempenho para um nvel inaceitvel. J para Rose (1994), h dois motivos pelos quais a gerncia de redes necessria: a) dispositivos heterogneos: pelo fato da interconexo de redes permitir diferentes tipos de dispositivos participarem da rede, estes componentes (hosts , routers, switches , etc) iro quase sempre ser de fabricantes diferentes, e heterogneos por natureza. Atualmente, h no mercado dis positivos de centenas de fabricantes, cada um com vrios modelos de cada linha de produto, que implementam o protocolo TCP/IP. Evidencia -se que uma tecnologia de gerenciamento especfica de um vendedor inutilizvel em tais ambientes. Assim, como apenas a utilizao de uma tecnologia de interconexo "aberta", ou seja, no proprietria como o TCP/IP o que torna um ambiente com mltiplos fabricantes de dispositivos uma realidade, tambm uma tecnologia de gerenciamento de redes "aberta" (SNMP), o que torna possvel gerenciar estes diferentes dispositivos; b) administraes diferentes: pelo fato de interconexo de redes permitir vrias redes com tamanhos e propsitos diferentes se interconectarem, estas redes iro quase sempre estar sob administraes diferent es, como o caso atual da Internet. Para gerenciar estes sistemas e redes, que continuam a crescer em escala e diversidade, um conjunto rico e automatizado de ferramentas de gerenciamento de redes se faz necessrio. fundamental, para o uso destas ferramentas e aplicaes em um ambiente com

14 mltiplos fabricantes, a utilizao de tcnicas padronizadas para representar e trocar informaes relacionadas ao gerenciamento de redes (Stallings, 2001). Para isto, preciso definir o que significa o termo gerenciamento de redes. Abaixo duas definies so apresentadas: O gerenciamento de redes/sistemas a soma total de todos os procedimentos e produtos para planejamento, configurao, controle, monitoramento e gerenciamento de redes de computadores e sistemas distribudos, e a remoo de erros destes sistemas. Estes recursos devem prover suporte econmico e amigvel aos usurios que trabalham com a rede e seus componentes. Logo, cobre todas as precaues e atividades necessrias para assegurar o uso efetivo e eficiente dos recursos gerenciados (Hegering, 1994). A gerncia de redes inclui o desenvolvimento, integrao, e coordenao de hardware, software e elementos humanos para monitorar, testar, juntar (poll), configurar, analisar, avaliar, e controlar a rede e seus recursos para alcanar em tempo real, o desempenho operacional e a qualidade de servio requisitados a um custo razovel. (SAYDAM 1, apud KUROSE, 2001, p. 630-631). Hegering (1994), ainda divide o gerenciamento de redes em trs dimenses: a) a dimenso funcional: esta dimenso se preocupa com a designao de tarefas de gerenciamento em reas funcionais. O modelo ISO de gerenciamento prov uma subdiviso com as seguintes reas: configurao, falhas, desempenho, contabilizao e segurana; b) a dimenso temporal: divide os processos que implementam as funes de gerenciamento em fases com diferentes ciclos de vida, incluindo as fases de planejamento, implementao e operao; c) a dimenso de cenrio: recentemente, alm do gerenciamento clssico de redes, um nmero de outros cenrios de gerenciamento tais como gerenciamento de sistemas, gerenciamento de aplicaes e gerenciamento empresarial, vem surgindo. Estes cenrios so diferenciados pelo fato de que os objetos alvo de gerenciamento so diferentes em cada caso, o que geralmente leva a diferentes aplicaes de gerenciamento.

15 Kurose (2001) cita que a ISO/IEC criou um modelo de gerenciamento de redes que define cinco reas funcionais de gerncia: a) gerncia de desempenho: o objetivo desta rea quantificar, medir, relatar, analisar e controlar o desempenho de diferentes componentes da rede. Estes componentes podem ser dispositivos individuais, como roteadores e equipamentos, ou abstraes, tais como um caminho ao longo da rede; b) gerncia de falhas: registrar, detectar e responder s condies de falhas na rede so os objetivos desta rea. A linha entre gerncia de falhas e gerenciamento de desempenho imprecisa. Pode -se pensar na gerncia de falhas como o tratamento imediato de falhas transientes da rede, enquanto que o gerenciamento de desempenho busca ter uma viso aprofundada da rede para poder fornecer nveis aceitveis de desempenho tendo em vista as vrias demandas de trfego e ocasionais falhas de dispositivos de rede. A gerncia de falhas geralmente

corretiva enquanto que a gerncia de desempenho quase sempre preventiva; c) gerncia de configurao: permite ao administrador da rede rastrear quais dispositivos fazem parte da rede gerenciada e realizar a configurao de hardware e software destes dispositivos; d) gerncia de contabilizao: esta rea permite ao administrador da rede especificar, registrar e controlar o acesso dos usurios aos dispositivos da rede. Cotas de uso, cobranas baseadas em uso de recursos e a alocao de privilgios de acesso aos recursos, fazem parte da gerncia de contabilizao; e) gerenciamento de segurana: o objetivo da gerncia de segurana controlar o acesso aos recursos da rede de acordo com polticas bem definidas. Os centros de distribuio de chaves e autoridades certificadoras so componentes da gerncia de segurana. O uso de firewalls para monitorar e controlar pontos de rede de acesso externo outro componente fundamental. Em resposta a estas necessidades de gerenciamento, administradores de rede e usurios se voltaram para um padro: o SNMP. O SNMP foi especificado no final dos anos 80 e rapidamente se tornou o padro para o gerenciamento de redes em plataformas com mltiplos fabricantes. O SNMP se refere na verdade, a um conjunto de padres para o gerenciamento de re des, incluindo um protocolo, uma especificao de uma estrutura de base de dados e um conjunto de objetos de dados. Entretanto, o SNMP era muito limitado para

16 atender a todas as necessidades crticas de gerenciamento de redes. Trs melhorias (1993 SNMPv2, 1995 reviso do SNMPv2, 1998 SNMPv3) solidificaram o papel do SNMP como uma ferramenta indispensvel para o gerenciamento de redes (Stallings, 2001). O SNMP ser abordado com mais detalhes no captulo 4.

3.1 ARQUITETURA DE UM SISTEMA DE GERENCIAMENTO DE REDES

Um sistema de gerenciamento de redes, segundo Stallings (2001), uma coleo de ferramentas para o monitoramento e controle da rede que so integradas da seguinte forma: a) uma nica e poderosa interface operacional, porm amigvel e com um conjunto de comandos para realizar quase todas, seno todas as tarefas de gerenciamento de redes; b) uma quantidade mnima de equipamentos necessria. Um sistema de gerenciamento de redes consiste de adies incrementais de hardware e software implementados entre os componentes j existentes na rede. Um sistema de gerenciamento de redes designado para visualizar a rede como uma arquitetura unificada. Cada n da rede contm uma coletnea de softwares responsvel pela tarefa de gerenciamento, e so referenciados como uma entidade de gerenciamento de rede (EGR ou Network Management Station - NMS), conforme mostrado na figura 3. Cada EGR pode realizar as seguintes tarefas: a) coletar estatsticas sobre atividades relacionadas rede e s comunicaes; b) armazenar estatst icas localmente; c) responder aos comandos do centro de controle da rede incluindo comandos para: - transmitir as estatsticas coletadas para o centro de controle; - alterar um parmetro; - fornecer informaes sobre o estado da rede; - gerar trfego artificial para realizar um teste; d) enviar mensagens ao centro de controle quando condies locais sofrerem mudanas significativas.

17 Pelo menos um equipamento na rede designado como o equipamento de controle da rede, ou gerente. Alm dos elementos de uma EGR, o equipamento de controle inclui uma coleo de softwares chamados de aplicao de gerenciamento de rede (AGR). A AGR inclui uma interface operacional para permitir que um usurio autorizado gerencie a rede. A AGR responde aos comandos do usurio atravs da exibio de informaes e/ou atribuindo comandos s EGRs da rede. Esta comunicao realizada usando um protocolo de nvel de aplicao de gerenciamento de rede, que emprega a arquitetura de comunicao da mesma forma que qualquer outra aplicao distribuda.
FIGURA 3 Elementos de um sistema de gerenciamento de redes

E le m e nto s de um S is t em a de G e r e nc ia m e nto d e Re de s
H o s t d e c o n t r o le da re de (ge rent e ) S e r v id or ( a g e n t e) EG R Co m EG R Co m A plic SO A p l ic

A GR

SO R o t e ad or (a g e n t e ) EG R E s t a o d e t r a b a lh o ( a ge nt e) E GR C om A G R = A p li c a o d e G e r e n c ia m e n t o d e R ed es A p l i c = A p l i ca o SO E G R = E n ti d a d e d e G e r e n c ia m e n to d e R e d e C o m = s o f t w a r e d e c o m u n ic a o S O = S i s te m a O p e r a c io n a l A plic SO Co m

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

Outros ns na rede que fazem parte do sistema de gerenciamento de redes incluem uma EGR que responde aos pedidos de um gerente do sistema. A EGR em tais sistemas geralmente um mdulo agente, ou simplesmente, agente. Os agentes so implementados em

18 sistemas que suportam aplicaes de usurios finais bem como em ns que provem servios de comunicao, tais como pontes e roteadores. A configurao da figura 3 d a entender que cada componente da configurao que de interesse de gerenciamento, inclui uma entidade de gerenciamento de rede, com um software de gerenciamento de rede comum que atua sobre todos os agentes e gerentes. Na configurao atual, isto pode no ser prtico, ou at mesmo impossvel. Para lidar com tais casos, comum ter um dos agentes no sistema atuando como um proxy, para um ou mais ns da rede (fig. 4).
FIGURA 4 Arquitetura de uma entidade proxy

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

A p l ic . G e r e n c ia m e n t o

G e r en te d e P r o xy

In te r fa c e d e G e r e n ci a m e n t o P r op r i e t r i a

S tu b C li e n t e

S t ub S e r v id o r

S tu b C li e n te p r o xy

S t u b S e v id o r p ro xy

P i lh a d e prot oc olos

P il h a d e p r o to c o lo s

Pilha d e p r ot o c o l o s

P i lh a d e p r o t o c o l o s

R e l a t r io s d e e ve n to s e o p e r a e s p adr o

R e l a t r io s d e e ve n t o s e o p er a es p r o p r ie t r i a s

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

Quando um agente atua como um proxy , ele age em benefcio de um ou mais ns da rede. Um gerente que desejar obter informaes do n ou control -lo, deve se comunicar com o agente proxy. O agente proxy ir traduzir a requisio do gerente usando qualquer protocolo de gerenciamento disponvel, de modo que o sistema alvo receba e entenda a requisio feita. A resposta recebida do sistema alvo similarmente traduzida e repassada ao gerente.

19

3.2 GERENCIAMENTO DE DESEMPENHO

Segundo Stallings (2001), as redes de comunicao de dados modernas so compostas de muitos componentes, que devem se intercomunicar e compartilhar dados e recursos. Em a lguns casos, crtico, para a eficcia de uma aplicao, que a comunicao pela rede tenha certos limites de desempenho. O gerenciamento de desempenho de uma rede de computadores engloba duas grandes categorias funcionais: monitoramento e controle. Monitoramento a funo que rastreia atividades na rede. A funo de controle habilita a gerncia de desempenho a fazer ajustes para aumentar o desempenho da rede. Algumas questes de desempenho, no que diz respeito ao administrador da rede so: a) qual a utilizao do nvel de capacidade? b) h trfego excessivo? c) o throughput foi reduzido a nveis inaceitveis? d) existem gargalos na rede? e) o tempo de resposta est aumentando? Para lidar com estes problemas, o administrador de rede deve focar -se em algum conjunto inicial de recursos a serem monitorados para medir os nveis de desempenho. Isto inclui associar mtricas apropriadas e valores com recursos relevantes da rede, como indicadores de diferentes nveis de desempenho. Hegering (1994) v o gerenciamento de desempenho como uma continuao consistente do gerenciamento de falhas. Enquanto que o gerenciamento de falhas responsvel por assegurar que a rede de comunicao permanea funcionando, isto no suficiente para o gerenciamento de desempenho, que se posiciona com o objetivo de assegurar que o sistema como um todo esteja oferecendo uma boa qualidade de servio. Algumas subtarefas da gerncia de desempenho incluem: a) determinar parmetros de qualidade de servio; b) monitorar a rede de comunicao em busca de gargal s; o c) executar medidas de desempenho; d) processar os dados medidos e gerar relatrios; e) planejar a capacidade e o desempenho da rede.

20 Para Stallings (2001), o gerenciamento de desempenho deve monitorar muitos recursos para fornecer informaes para determinar os nveis de operao da rede. Pela coleta destas informaes, sua anlise e o uso dos resultados obtidos como retorno ( feedback) ao conjunto de valores prescritos, o administrador da rede pode se tornar mais e mais apto a reconhecer situaes indicativas de degradaes de desempenho presentes ou iminentes. Antes de usar uma rede para executar uma aplicao em particular, um usurio final pode querer saber coisas como o pior tempo de resposta e a confiabilidade dos servios da rede. Por isso o desempenho de ve ser conhecido em detalhes suficientes para responder aos questionamentos especficos dos usurios finais. Os usurios finais esperam que os servios sejam gerenciados de forma a garantir bons tempos de resposta para obter assim, uma boa utilizao de suas aplicaes. Os gerentes de rede precisam de estatsticas de desempenho para ajud-los a planejar, gerenciar e manter grandes redes funcionando. As estatsticas de desempenho podem ser usadas para identificar potenciais gargalos antes que causem problemas aos usurios finais. Aes corretivas apropriadas podem ento ser tomadas. Estas aes podem tomar a forma de alteraes nas tabelas de roteamento para balancear ou redistribuir a carga de trfego durante perodos de pico, ou quando um gargalo ide ntificado por um crescimento rpido de carga em uma rea especfica. De modo geral, um planejamento de capacidade baseado em tais informaes de desempenho pode indicar as decises apropriadas a serem tomadas, como por exemplo, a expanso de linhas naquela rea. Por tudo isso, um pr-requisito absoluto para o gerenciamento de uma rede de computadores a habilidade de medir o desempenho da rede, ou monitoramento de desempenho. No se pode gerenciar e controlar um sistema ou atividade se no for possvel monitorar o seu desempenho. Uma das dificuldades que o administrador de redes encontra na seleo e uso dos indicadores apropriados para medir o desempenho da rede. Dentre os problemas pode -se citar os seguintes: a) existem muitos indicadores para usar; b) o significado de muitos destes indicadores no so claramente compreendidos; c) alguns indicadores so suportados apenas por alguns fabricantes; d) muitos indicadores no servem para fazer comparaes entre si;

21 e) freqentemente, os indicadores so medidos corretamente, mas interpretados incorretamente; f) em muitos casos, o clculo dos indicadores consome muito tempo, e o resultado final j no pode mais ser usado para controlar o ambiente. H dois tipos de indicadores: medidas orientadas a servios e medidas orientadas eficincia. As medidas orientadas a servios possuem os seguintes indicadores: a) disponibilidade: o percentual de tempo que uma rede, um componente, ou uma aplicao est disponvel para o usurio; b) tempo de resposta: quanto tempo preciso para uma resposta aparecer no terminal do usurio aps uma solicitao feita pelo mesmo; c) preciso: o percentual de tempo em que no ocorrem erros na transmisso e recepo de informaes. J as medidas orientadas a eficincia possuem indicadores de: a) throughput: a taxa na qual as aplicaes orientadas a eventos ocorrem; b) utilizao: o percentual da capacidade terica de um recurso que est sendo utilizado. Kurose (2001) cita que a rea de monitoramento de desempenho da rede no gerenciamento de redes responsvel por observar e analisar o estado e o comportamento dos sistemas fim (end systems), dos sistemas intermedirios e sub-redes que compe os recursos gerenciados. De acordo com Stallings (2001), a arquitetura funcional de monitoramento de redes composta de: a) aplicao de monitorao: este componente inclui as funes de monitoramento de rede que so visveis ao usurio, tais como monitoramento de desempenho, monitoramento de falhas e monitoramento de configurao; b) funo gerente: este o mdulo no monitor da rede que real za a funo de i monitoramento configurao; c) funo agente: este mdulo obtm e registra informaes de gerenciamento para um ou mais elementos de rede e repassa essas informaes ao monitor; bsica, buscando informaes de outros elementos da

22 d) objetos gerenciados: estas so as informaes gerenciadas, que representam os recursos da rede e suas atividades; importante mencionar um mdulo funcional adicional relacionado com informaes estatsticas: e) agente de monitorao: este mdulo adicional gera sumrios e anlises estatsticas das informaes gerenciadas. Se afastado do gerente, este mdulo age como um agente e comunica estas informaes ao gerente. O monitoramento de desempenho engloba todas as cinco reas funcionais. As informaes disponveis para a monitorao da rede podem ser classificadas como segue: a) esttica: esta a informao que caracteriza a configurao corrente e os elementos na configurao corrente, tais como os nmeros e identificaes das portas de um roteador; b) dinmica: estas informaes so relativas a eventos na rede, tais como: mudanas de estado de uma mquina ou a transmisso de um pacote pela rede; c) estatstica: estas so informaes que podem ser derivadas das informaes dinmicas, como por exemplo, o nmero mdio de pacotes transmitidos por unidade de tempo por um sistema fim.

3.2.1

FUNO DE MONITORAMENTO DE DESEMPENHO

Segundo Stallings (2001), a funo de monitoramento de desempenho engloba trs

componentes: a) medida de desempenho: a reunio de estatsticas sobre o trfego da rede e temporizao; b) anlise de desempenho: consiste de software para reduzir e apresentar os dados; c) gerao de trfego sinttico: consiste de software que permite observar a rede sob uma carga controlada. A medida de desempenho quase sempre completada por mdulo s agentes junto aos dispositivos da rede (equipamentos, roteadores, pontes, etc). Estes agentes esto em posio de observar a quantidade de trfego que entra e sai de um n, o nmero de conexes e o trfego por conexo, alm de outras medidas que fornecem um cenrio detalhado do

23 comportamento daquele n. Em uma rede compartilhada, tal como uma LAN, muitas das informaes necessrias podem ser coletadas por um monitor externo ou remoto que simplesmente observa o trfego na rede. Alguns tipos de medidas que podem ser obtidas em uma LAN tpica so as seguintes: a) histograma de tipos de pacotes circulando na rede; b) histograma com os tamanhos dos pacotes; c) histograma com os tamanhos dos pacotes de dados; d) distribuio ou utilizao de throughput; e) histograma do tempo de chegada de pacotes; f) histograma com a demora de aquisio de canal; g) histograma com a demora de comunicao; h) histograma com a contagem de colises; i) histograma com o contador de transmisses; Com estas medidas possvel responder s vrias perguntas feitas por um administrador de redes relacionadas ao desempenho de uma LAN tais como: a) o trfego est igualmente distribudo entre os usurios da rede ou h pares origem/destino com trfego pesado? b) qual o percentual de cada tipo de pacote? Existem alguns tipos de pacotes com alta freqncia de uso, indicando um erro ou um protocolo ineficiente? c) qual a distribuio dos tamanhos dos pacotes de dados? d) quais so as demoras na aquisio de canal e as distribuies de comunicao? Esses tempos so excessivos? e) qua l a utilizao do canal e seu throughput? Quando a rede possui uma carga de trfego muito pesada, pode no ser prtico coletar os dados exaustivamente. A alternativa tratar cada parmetro como uma varivel aleatria realizando uma amostragem do fluxo de modo a estimar o valor desta varivel. Entretanto, deve -se tomar cuidado ao se usar e interpretar as estimativas de resultados estatsticos. O indivduo responsvel por desenvolver funes de amostragem e por interpretar os resultados precisa ter alguma familiaridade com os princpios estatsticos.

24

4 SIMPLE NETWORK MANAGEMENT PROTOCOL

Nos anos 60, segundo Stallings (2001), o assunto gerncia de redes no existia. Nos anos 70 e metade dos anos 80, apenas o Internet Control Message Protocol (ICMP) e o Packet Internet Groper (PING) eram utilizados para tal tarefa. Com o crescimento da Internet no fim dos anos 80, surgiu a necessidade de se criar ferramentas para o gerenciamento das redes existentes. Primeiro foi o Simple Gateway Monitoring Protocol (SGMP) em 1987. A partir dele surgiram o Host Monitoring Protocol (HMP), o primeiro protocolo de gerenciamento usado na Internet, o SNMP (uma verso melhorada do SGMP), e o Common Management Information Protocol over TCP/IP (CMOT). A IAB aprovou em 1988 o SNMP como u soluo temporria e o CMOT como o ma padro a ser adotado mais tarde. Para tal a IAB determinou que ambos os protocolos usassem a mesma base de dados de objetos gerenciados. Assim ambos usariam uma nica estrutura de gerenciamento de informaes (Structure of Management Information SMI), e uma nica base de gerenciamento de informaes (MIB). O objetivo era tornar mais fcil a futura transio do SNMP para o CMOT. Mas logo se tornou claro que tal ligao seria impossvel. No gerenciamento OSI, os objetos gerenciados so vistos como entidades sofisticadas, com atributos, procedimentos associados, e capacidades de emisso de mensagens, alm de outras caractersticas complexas associadas com a tecnologia orientada a objetos. Para manter o SNMP simples, ele no foi designado para trabalhar com estes conceitos sofisticados. De fato, os objetos no SNMP nada mais so do que variveis com algumas caractersticas bsicas, como tipos de dados e atributos de somente-leitura (readonly) ou leitura-escrita (read-write ). Por isso a IAB relaxou seus termos e com isso o SNMP e o CMOT evoluram independentemente e em paralelo. Os desenvolvedores do SNMP, livres das restries de compatibilidade com o modelo OSI desenvolveram rapidamente o SNMP e logo ele estava sendo usado em larga escala pelos vendedores de equipamentos e seu uso espalhou-se pela Internet. Enquanto isso, os esforos no CMOT se esvaeceram. Atualmente, virtualmente todos os grandes vendedores de equipamentos, estaes de trabalho, roteadores, pontes e hubs, oferecem suporte ao SNMP. As trs especificaes fundamentais do SNMP so:

25 a) Request for Comment - RFC 1155: descreve como os objetos gerenciados contidos nas MIBs so definidos (SMI); b) RFC 1213: descreve os objetos gerenciados contidos na MIB (MIB-II); c) RFC 1157: define o protocolo usado para gerenciar os objetos (SNMP). Todas as RFCs citadas no presente trabalho podem ser encontradas em RFC/STD/FYI/BCP Archives (199-). Para Lynch (1993), o gerenciamento de redes moderno possui muitos requisitos importantes. Primeiro, a estrutura de gerenciamento deve suportar tanto monitoramento quanto controle. Segundo, deve possuir a habilidade de gerenciar todas as camadas da implementao do modelo OSI fornecendo um gerenciamento topo-base (top-down ). Terceiro, pela mxima extenso possvel e economicamente vivel, o escopo do gerenciamento da rede deve ser fim-a-fim. Deve englobar todos os sistemas da rede. Finalmente, o impacto dessa estrutura de gerenciamento de redes no deve ser visvel, ou perceptvel. A largura de b anda consumida pelas funes de gerenciamento deve estar dentro de certos limites. Ento, por que no usar o Common Management Information Protocol CMIP? Para Lynch (1993), primeiro porque a sobrecarga de implementar o Common Management Information Service - CMIS e CMIP em sistemas com recursos limitados pode ser muito caro. Segundo, estes protocolos ocupam uma pequena fatia do mercado atualmente, logo, os vendedores escolhem implementar o SNMP ao invs do CMIP e, como resultado, o mercado ocupado pelo CMIP permanece pequeno. Finalmente, enquanto que o CMIS e CMIP so padres internacionais bem definidos, muito da sua infraestrutura de suporte, tal como os equivalentes ISO do SMI, MIBs e perfis de transporte, no alcanaram ainda este mesmo nvel de padronizao e estabilidade.

4.1 CONCEITOS BSICOS DE SNMP

A seguir sero apresentados os conceitos bsicos relacionados ao SNMP, tais como sua estrutura, seus elementos e a relao entre estes elementos.

26

4.1.1

ARQUITETURA
O modelo de gerncia de redes TCP/IP, de acordo com Stallings (2001), composto

pelos seguintes elementos: a) estao de gerenciamento (gerente); b) agentes; c) base de informaes de gerenciamento; d) protocolo de gerenciamento de redes. A estao de gerenciamento serve como uma interface pela qual o administrador da rede se comunica com o sistema de gerenciamento. No mnimo, uma estao de gerenciamento ter: a) um conjunto de aplicaes para anlise de dados, recuperao de falhas, etc; d) uma interface pela qual o administrador da rede pode monitorar e controlar a rede; e) a capacidade de traduzir os requisitos do administrador da rede no atual controle e monitoramento dos elementos remotos da rede; f) uma base de dados com informaes extradas das MIBs de todas as entidades gerenciadas da rede. Apenas os dois ltimos elementos esto sujeitos padronizao SNMP. Outro elemento ativo no gerenciamento da rede o agente. O agente responde aos pedidos de informaes e s aes vindas do gerente e pode prover de forma assncrona, informaes no solicitadas, porm importantes, para a estao de gerenciamento. Os recursos da rede podem ser gerenciados pela representao dos mesmos como objetos. Cada objeto , essencialmente, uma varivel de dados que representa um aspecto do agente gerenciado. Esta coleo de objetos denominada MIB. Estes objetos so padronizados atravs de sistemas de uma classe em particular. Uma estao de gerenciamento realiza a funo de monitoramento obtendo os valores dos objetos da MIB. A estao de gerenciamento e os agentes so ligados por um protocolo de gerenciamento de rede. O protocolo usado para o gerenciamento de redes TCP/IP o SNMP, que possui as seguintes capacidades chave: a) get: habilita a estao de gerenciamento a obter os valores dos objetos no agente;

27 b) set: habilita a estao de gerenc iamento a configurar os valores dos objetos no agente; c) trap: habilita o agente a notificar espontaneamente a estao de gerenciamento sobre eventos significativos; Alm destas primitivas, o SNMPv2 define uma nova primitiva: e) inform: habilita o agente e o gerente a pedir confirmao de eventos de notificao. O SNMP foi designado para ser um protocolo de nvel de aplicao que parte do conjunto de protocolos TCP/IP. Ele foi projetado para operar sobre o UDP. Cada agente deve no mnimo, implementar o SNMP, o UDP e o IP para poder agir como um agente (fig. 5).
FIGURA 5 O papel do SNMP

O P ap el do SN M P
E s t a o d e g e re n c i am e n t o S N M P A g e n te S N M P

R e c u r s o s g e re n c ia d o s A p li c . d e g e r e n c ia m e n to O b j e t o s g e r e n c ia d o s S N M P

GetNextRequest

GetNextRequest

G etRes pons e

G etRes pons e
IP

GetRequest

GetRequest

SetRequest

SetRequest

Tr ap

M e n s ag en s S N M P G ere nt e S N M P A ge nt e S N M P

U DP

U DP

IP

P r o t o c ol o s d e p e n d e n t e s d e r e d e

P r o to c o lo s d e p e n d e n te d e r e d e

R e de o u In t e r n e t

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

Tr ap

28 Um processo agente interpreta as mensagens SNMP e controla sua MIB. Trs tipos de mensagem agem em favor de uma aplicao de gerenciamento na estao de gerenciamento: GetRequest, GetNextRequest, e SetRequest. As duas primeiras so variaes da funo get. Todos os trs tipos de mensagens so respondidos por um agente na forma d e uma mensagem GetResponse , que passada para a aplicao de gerenciamento. Alm destes tipos de mensagens, um agente pode enviar uma mensagem de Trap em resposta a um evento que afete a MIB e por conseqncia, os recursos gerenciados. Como o SNMP depende do UDP, que um protocolo no orientado conexo, o SNMP em si, sem conexo.

4.1.2

SMI STRUCTURE OF MANAGEMENT INFORMATION

Segundo Stallings (2001), a base do sistema de gerenciamento usado no modelo

SNMP um banco de dados contendo informaes sobre os elementos gerenciados. Tanto no ambiente TCP/IP quanto no OSI, esta base de dados chamada de base de informaes ou simplesmente MIB, onde cada recurso gerenciado representado por um objeto. A MIB uma coleo de tais objetos. Para o SNMP a MIB , em essncia, uma base de dados estruturada na forma de uma rvore. Cada elemento da rede contm uma MIB que reflete o estado dos recursos gerenciados pelo sistema de gerncia. Uma entidade de gerenciamento de rede pode monitorar os recursos atravs da leitur a dos valores dos objetos na MIB e pode controlar estes recursos gerenciados modificando estes valores. Para que a MIB possa atender s necessidades de um sistema de gerenciamento, ela deve atender certos objetivos: a) o objeto ou objetos usados para represen um recurso em particular deve ser o tar mesmo em todos os sistemas; b) um projeto comum para representao destes objetos deve ser usado, para suportar a interoperabilidade. O item (b) alcanado no SNMP pela definio de uma estrutura de gerenciamento de informaes, o SMI. O SMI, que especificado na RFC 1155, define a estrutura principal na qual a MIB pode ser definida e construda. O SMI identifica os tipos de dados que podem ser usados na MIB e especifica como os recursos na MIB sero representados e nomeados. A filosofia por

29 trs do SMI encorajar a simplicidade e a extensibilidade das MIBs. O SMI no suporta a criao ou a recuperao de estruturas de dados complexas. As MIBs iro inevitavelmente conter tipos de dados definidos pelos vendedores de equipamentos de rede e, a menos que restries na definio de tais tipos de dados sejam definidas, haver perda de interoperabilidade. Para fornecer uma forma padro de representao de informaes de gerenciamento, o SMI deve fazer o seguinte: a) fornecer uma tcnica padro para definir a estrutura de uma MIB em particular; b) fornecer uma tcnica padro para definir objetos individuais, incluindo a sintaxe e valor de cada objeto; c) fornecer uma tcnica padro para codificao dos valores dos objetos.

4.1.2.1

ESTRUTURA MIB

Para Stallings (2001), todos os objetos gerenciados no ambiente SNMP esto distribudos em uma estrutura hierrquica ou em rvore. Os objetos folhas desta rvore so os objetos gerenciados em si, cada um deles representando algum recurso, atividade, ou informao relevante que pode ser gerenciada. A estrutura em si define um agrupamento de objetos em conjuntos de objetos logicamente relacionados. Associado com cada tipo de objeto na MIB h um identificador do tipo Abstract Syntax Notation One - ASN.1 cha mado OBJECT IDENTIFIER que serve para nomear o objeto. Em adio, devido ao valor associado ao tipo OBJECT IDENTIFIER ser hierrquico, a conveno de nomeao tambm serve para identificar a estrutura dos tipos de objetos. Partindo da raiz (root) da rvore OBJECT IDENTIFIER, cada valor componente do identificador de objeto identifica uma folha na rvore (fig. 6). Partindo da raiz, h trs ns no primeiro nvel: iso, ccitt, e joint-iso-ccitt. Abaixo do n iso, uma das subrvores para uso por parte de outras organizaes, uma delas sendo o U.S. Department of Defense (dod). A RFC 1155 assume que uma subrvore abaixo do dod ser alocada para administrao pela IAB como segue: internet OBJECT IDENTIFIER ::= {iso (1) org (3) dod (6) 1}.

30 Por isso o n internet tem o identificador de objeto 1.3.6.1. Este valor serve como prefixo para os ns abaixo deste nvel.
FIGURA 6 - Grupos de objetos MIB-2

is o ( 1 )

o rg ( 3)

d o d (6 )

in t e r n e t (1 ) d i re c t o ry ( 1 ) mgmt (2)

m ib-2 ( 1 ) s ys t em ( 1 ) in t e r fa c e s ( 2 ) a t (3 ) ip ( 4 ) ic m p (5 ) t c p (6 ) ud p (7 ) eg p (8 ) tr a n s m is s io n ( 1 0 ) s nm p (11 ) e x p e r i m e n ta l ( 3 ) p r iv a t e ( 4 ) en t erpr is es (1 )

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

Como mostra a figura 6, o SMI define quatro ns abaixo do n internet: a) directory: reservado para uso futuro com o diretrio OSI; b) mgmt : usado por objetos definidos em documentos aprovados pelo IAB;

31 c) experimental: usado para identificar objetos usados em experimentos na Internet; d) private: usado para identificar objetos definidos unilateralmente. A subrvore mgmt contm as definies de bases de gerenciamento MIB que foram aprovados pelo IAB. Atualmente, duas verses da MIB foram desenvolvidas, mib-1 e mib-2. A segunda uma exte nso da primeira e o padro usado pelo SNMPv3. Ambas possuem os mesmos identificadores de objeto na subrvore, mas apenas uma das MIBs est presente em qualquer configurao. Objetos adicionais podem ser definidos para uma MIB das seguintes maneiras: a) a subrvore mib-2 pode ser expandida ou substituda por uma reviso completamente nova (presumivelmente mib-3). Para expandir a mib-2 uma nova subrvore definida; b) uma MIB experimental pode ser construda para uma aplicao em particular. Tais objetos pode m subseqentemente ser removidos da subrvore mgmt; c) extenses privadas podem ser adicionadas a subrvore private. Hegering (1994) define um nico nvel estrutural integrante da MIB internet, o nvel group. Este subdividido em 10 subgrupos conforme segue: a) system: informaes de configurao sobre o n gerenciado como um todo; b) interfaces: informaes de interface sobre os sistemas conectados; c) at addres translation : informaes para resoluo de endereos; d) ip, icmp, tcp , udp , egp , snmp : informaes sobre os protocolos IP, ICMP, TCP, UDP, Exterior Gateway Protocol EGP, e SNMP; e) transmission : informaes sobre tipos especficos de interfaces de rede tais como Ethernet, Token Ring, loopback, etc. Atualmente, segundo Stallings (2001), a subrvore private contm apenas um n definido: o n enterprises. Esta parte da subrvore usada por vendedores para aperfeioar o gerenciamento de seus dispositivos e para compartilhar informaes com outros usurios e vendedores que necessitem interoperar com seus sistemas. A diviso do n internet em quatro subrvores fornece uma fundamentao forte para a evoluo das MIBs. Com os experimentos de novos objetos por parte dos vendedores e de

32 outros desenvolvedores, se ganha um conhecimento prtico desses novos objetos antes q ue eles sejam definidos como parte integrante dos padres para o subgrupo mgmt. Com isso, a MIB til imediatamente para gerenciar objetos que se encaixam na parte padro da MIB e flexvel o bastante para se adaptar s mudanas de ofertas de produtos e tecnologias. Ao conjunto de operaes de gerenciamento permitidas a uma aplicao gerente por um agente denomina-se poltica de acesso; a coleo de objetos que so visveis para estas operaes denominada viso MIB, ou simplesmente uma viso (Hegering, 1994).

4.1.2.1.1

SUBGRUPO IP

Para o desenvolvimento do prottipo, sero utilizados alguns dos objetos escalares existentes no grupo ip da mib-2. Estes objetos sero utilizados para realizar o monitoramento de desempenho, atravs da medio da utilizao de throughput da rede - no que diz respeito aos pacotes IP transmitidos e recebidos - pelo dispositivo analisado, fornecendo assim informaes dinmicas sobre a utilizao destes recursos feitos pelo dispositivo em questo e o seu impacto na utilizao total da largura de banda da rede na qual est inserido. Segundo Zeltserman (1999), o subgrupo ip composto de objetos escalares, uma tabela de endereos, uma tabela de roteamento e uma tabela de endereos de rede para mdias. Alguns dispositivos implementam diversos mdulos de roteamento e mantm objetos do grupo MIB para cada mdulo. possvel acessar subgrupos ip diferentes atravs de strings de comunidade proxy ou atravs de endereos IP diferentes. Os objetos escalares que atualmente fazem parte do subgrupo ip so: a) ipForwarding: pode ser forwarding (1) ou no forwarding (2). Quando o ipForwarding estiver habilitado, o dispositivo age como um roteador normal e ir encaminhar os pacotes IP de uma sub-rede para outra quando requisitado. Quando o ipForwarding estiver desabilitado, o dispositivo descarta os pacotes IP no endereados para uma de suas interfaces definidas localmente. Ir tambm incrementar o contador ipInAddrErrors para cada pacote descartado; b) ipDefaultTTL: tempo de vida (Time-To-Live - TTL) padro; c) ipInReceives : nmero total de datagramas de entrada recebidos de todas as interfaces, incluindo aquelas com erros;

33 d) ipInHdrErrors: nmero de datagramas de entrada descartados devido a erros no seu cabealho IP. Isto inclui falhas de checksum, nmero de verso incompatvel, outros erros de formato, tempo de vida excedido, e erros descobertos no processamento das opes IP; e) ipInAddrErrors: nmero de datagramas de entrada descartados porque o endereo IP de destino no vlido. Isto inclui endereos invlidos, endereos de classes no suportadas e pacotes que no podem ser encaminhados porque o ipForwarding est desativado; f) ipForwDatagrams : nmero de datagramas encaminhados; g) ipInUnknownProtos : nmero de datagramas recebidos com sucesso mas descartados porque o pr otocolo era ou desconhecido ou no suportado; h) ipInDiscards: nmero de datagramas de entrada descartados devido a limitaes de recursos, como por exemplo, a falta de espao em buffer; i) ipInDelivers : nmero de datagramas entregues para os protocolos de usurio IP local; j) ipOutRequests: nmero de datagramas IP requisitados para transmisso. Este contador no inclui qualquer datagrama contado no ipForwDatagrams; k) ipOutDiscards: nmero de datagramas de sada descartados devido falta de recursos; l) ipOutNoRoutes: nmero de datagramas descartados porque no foi possvel encontrar o roteador no endereo de destino; m) ipReasmTimeout: valor de timeout em segundos pelo qual fragmentos IP recebidos esperam enquanto aguardam o reagrupamento; n) ipReasmReqds: nmero de fragmentos IP recebidos que precisam ser reagrupados; o) ipReasmOKs: nmero de datagramas IP reagrupados com sucesso; p) ipReasmFails: nmero de falhas de reagrupamento; q) ipFragsOKs: nmero de datagramas IP fragmentados com sucesso; r) ipFragsFails: nmero de datagramas IP que necessitam fragmentao mas que precisam ser descartados porque possuem a flag IP no fragmentar configurada; s) ipFragCreates: nmero de fragmentos IP criados; t) ipRoutingDiscards: nmero de entradas na tabela de roteamento que foram descartadas devido a limitaes de recursos.

34 Estes objetos podem ajudar a identificar especificamente: a) limitaes de recursos; b) grande nmero de pacotes sendo fragmentados. Isto pode ser causado devido a incompatibilidades na Maximum Transfer Unit - MTU. A reduo da quantidade de fragmentao ir provavelmente aumentar o desempenho da rede; c) grande nmero de pacotes sendo reagrupados. Novamente, isto pode estar acontecendo devido a incompatibilidades nas MTUs; d) um grande percentual de falta de rotas. Isto pode indicar que um dispositivo no est recebendo atualizaes de roteamento apropriadamente ou que a tabela de roteamento foi desconfigurada e no contm rotas vlidas; e) um grande percentual de reagrupamentos falhos. Pode indicar tanto que fragmentos esto sendo corrompidos ou que fragmentos IP esto sendo descartados devido falta de recursos; f) um grande percentual de fragmentaes falhas. Provavelmente indica que os dispositivos esto configurados com a flag no desfragmentar. Enquanto que o conhecimento de que est se detectando um grande nmero de pacotes com erros de cabealhos ou de endereamento fcil, a soluo do problema especfico no to fcil e geralmente dependente de outros fatores que no sero abordados no presente trabalho.

4.1.2.2

ASN.1

Para Lynch (1993), na camada de aplicao as estruturas de dados trocadas pelas entidades de protocolo so potencialmente muito mais complexas. Portanto, necessrio introduzir um novo formalismo para descrever estas estruturas. Esse novo formalismo denominado sintaxe abstrata , que usada para definir dados sem considerar as estruturas orientadas mquina e suas restries. Na estrutura de gerenciamento, uma linguagem OSI denominada ASN.1 usada para atender este princpio. Vale lembrar que a ASN.1 usada por duas razes distintas pela estrutura de gerenciamento: a) definir o formato dos dados (objeto e seu respectivo valor) trocados pelo protocolo de gerenciamento; e b) definir os objetos que so gerenciados.

35 Logo, a sintaxe abstrata usada para descrever ambos, as estruturas de dados trocadas no nvel de protocolo e a informao gerenciada que transportada por estas estruturas de dados. Segundo Stallings (2001), cada objeto em uma MIB SNMP definido formalmente; a definio especifica os tipos de dados dos objetos, suas formas aceitveis e limites de valores, e seu relacionamento com outros objetos da MIB. A notao ASN.1 usada para definir cada objeto individualmente e, alm disso, definir toda a estrutura da MIB.

4.1.2.3

CODIFICAO

Os objetos na MIB so codificados usando regras bsicas de codificao (Basic Encoding Rules - BER) associadas com a ASN.1. Apesar de no ser a forma mais compacta ou eficiente de codificao, a BER uma estrutura de codificao amplamente usada e padronizada. (Stallings, 2001)

4.1.3

TRAP -DIRECTED POLLING

De acordo com Stallings (2001), as informaes que so teis para o monitoramento

da rede so coletadas e armazenadas por agentes e disponibilizadas para um ou mais sistemas gerentes. Se uma estao de gerenciamento responsvel por um grande nmero de agentes, e se cada agente guarda um grande nmero de objetos, ento se torna impraticvel para a estao de gerenciamento regularmente sondar (poll) todos os agentes para obter todos os seus dados de objetos passveis de leitura. Ao invs disso, duas tcnicas so usadas para tornar as informaes do agente disponveis ao gerente: polling e event reporting. Polling uma interao pergunta-resposta entre gerente e agente. O gerente pode consultar qualquer agente (ao qual possuir autorizao de acesso) e requisitar os valores de vrios elementos de informao, e o agente responde com as informaes da sua MIB. Um sistema gerente pode usar o polling para aprender sobre a configurao que est gerenciando, para obter periodicamente uma atualizao de condies, ou investigar em

36 detalhe uma rea depois de ter sido alertado de um problema. O polling tambm usado para gerar relatrios para o usurio e para responder a consultas especficas. No caso do event reporting , a iniciativa do agente e o gerente atua como um ouvinte, aguardando por novas informaes. Um agente pode gerar um relatrio peridico para informar ao seu gerente seu estado atual. O perodo do relatrio pode ser pr-configurado ou definido pelo gerente. Um agente tambm pode gerar um relatrio quando um evento significativo (por exemplo, uma mudana de estado) ou um evento incomum (por exemplo, uma falha) ocorrer. O event reporting til para detectar problemas to logo eles ocorram. tambm mais eficiente do que o polling para monitorar objetos cujos estados ou valores raramente so alterados. Um sistema de gerenciamento de redes geralmente faz uso dos dois mtodos. Para Rose (1994), com o polling, uma aplicao de gerncia periodicamente pergunta ao n gerenciado sobre como esto as coisas. Isto fornece a vantagem de manter a aplicao gerente no controle bem como determinar qual o quadro maior real. A desvantagem o custo em relao ao tempo. Como a aplicao gerente saber quais elementos de rede deve sondar e com que freqncia? Se o intervalo for muito curto, a largura de banda desperdiada; se for muito longo, a resposta a eventos catastrficos muito lenta. Uma segunda desvantagem que trfego adicional introduzido na rede. Correspondentemente, a aplicao gerente deve possuir recursos de armazenamento adicionais para atender a este aumento de trfego. A estratgia, segundo Stallings (2001), a seguinte: na inicializao, e talvez em intervalos incomuns, tais como uma vez ao dia, uma estao de gerenciamento pode sondar (polling) todos os agentes que conhea para obter algumas informaes chave, tais como as caractersticas da interface e talvez algumas informaes estatsticas bsicas. Uma vez estabelecida esta linha-base, a estao de gerenciamento se abstm da sondagem. Agora, cada agente responsvel por notificar a estao de gerenciamento sobre qualquer evento incomum. Estes eventos assncronos so comunicados no SNMP atravs de mensagens conhecidas como traps. Uma vez alertada sobre uma condio excepcional, a estao de gerenciamento pode decidir tomar ou no alguma ao. Neste ponto, a estao de gerenciamento pode sondar diretamente o agente que relatou a condio, para diagnosticar qualquer problema e para obter mais informaes especficas sobre a condio excepcional. O

37 trap-directed polling pode resultar em ganhos substanciais de capacidade da rede e tempo de processamento no agente. Por isso o SNMP utiliza o trap-directed pooling. Quando um evento extraordinrio ocorre, o n gerenciado envia um nico e simples trap para a aplicao gerente. A aplicao gerente ento responsvel por iniciar futuras interaes com o n gerenciado para determinar a natureza e extenso do problema. Esta abordagem surpreendentemente efetiva: o impacto nos ns gerenciados permanece pequeno; o impacto na largura de banda da rede minimizado; e, os problemas podem ser resolvidos rapidamente. claro, como os traps so enviados usando um protocolo inseguro (UDP), eles servem apenas como um alerta antecipado; baixas freqncias de polling so necessrias como back-up.

4.1.4

PROXY
Segundo Stallings (2001), o uso do SNMP requer que todos os agentes, bem como as

estaes de gerenciamento, suportem um conjunto de protocolos, tais como UDP e IP. Isto limita diretamente o gerenciamento de tais dispositivos e exclui outros, como algumas pontes e modens, que no suportam qualquer parte dos protocolos TCP/IP.
FIGURA 7 Configurao de proxy

C o nf ig u ra o d e p ro x y
A g en te p r ox y D i s po s iti v o

E s t a o d e ge r en c i am en to

F u n o d e m ap ea m e n to

P r oc es s o g e re n c i ad o

P ro c e s s o g e re n te

P ro c e s s o ag en te A rq u it e tu ra d e p r o toc o l o u s a da p e lo d i s p os iti v o p r o xy A r qu i te tu ra d e p r oto c olo u s a d a p e lo d is p o s it iv o pr ox y

G er e n te S N M P

G e r en te S N M P

U DP

UDP

IP

IP

P ro to c ol o s d e p. d e r ed e

P ro t o c ol o s d e p . d e r e de

P r o to c o lo s d e p . d e r ed e

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

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

38 Alm disso, pode haver numerosos sistemas menores (PCs, controladores programveis) que implementam o TCP/IP para suportar suas aplicaes, mas para os quais no desejvel adicionar a estrutura adicional do SNMP, como a lgica do agente e a manuteno da MIB. Para acomodar dispositivos que no implementam o SNMP, o conceito de proxy foi criado (fig. 7). Neste cenrio, um agente SNMP age como um proxy para um ou mais dispositivos, ou seja, o agente SNMP age em nome dos dispositivos a ele relacionados. Um agente proxy na estrutura do SNMP, segundo Lynch (1993), um agente que tem os recursos e a autorizao para responder s pesquisas e comandos em nome de outro sistema gerenciado. Isto ocorre porque alguns sistemas no possuem suporte nativo ao protocolo SNMP, mas com este mecanismo de proxy podem fazer parte da estrutura de gerenciamento SNMP.

4.1.5

COMPARATIVO ENTRE AS VERSES SNMP

O padro original da estrutura de gerenciamento SNMPv1, segundo o SNMP

International Research (2001), consiste de trs documentos: a) RFC 1155: define a Estrutura de Gerenciamento de Informaes - SMI; b) RFC 1212: define um mecanismo de descrio mais conciso, mas totalmente consistente com o SMI; c) RFC 1157: define o protocolo SNMP usado para o acesso via rede aos objetos gerenciados. Os dois primeiros documentos descrevem a linguagem de definio de dados do SNMPv1. O terceiro documento descreve as operaes do protocolo SNMPv1 realizadas pelas Protocol Data Units - PDUs em listas de ligao de varveis. As operaes definidas pelo SNMPv1 so: get, get-next, get-response, set-request , e trap. O posicionamento do SNMPv1 na camada de transporte usando um servio de transporte sem conexo tambm definido. Muitos destes conceitos fazem parte da estrutura do SNMPv3. A estrutura do SNMPv1 descreve o encapsulamento das PDUs SNMPv1 em mensagens SNMP enviadas entre entidades SNMP, e diferencia entre entidades de aplicao e

39 entidades de protocolo. No SNMPv3, estas entidades so renomeadas como aplicaes e motores, respectivamente. A estrutura do SNMPv1 tambm introduz o conceito de um servio de autenticao com suporte a um ou mais esquemas de autenticao. No SNMPv3, o conceito de um servio de autenticao expandido para incluir outros servios, tais como privacidade. Finalmente, a estrutura do SNMPv1 introduz o controle de acesso baseado em um conceito chamado viso de MIB SNMP. O SNMPv3 especifica um conceito

fundamentalmente similar chamado controle de acesso baseado em vises. Entretanto, enquanto que a estrutura SNMPv1 antecipou a definio de mltiplos esquemas de autenticao, esta no define nenhum esquema, seno um esquema trivial de autenticao baseado em strings de comunidade. Esta uma das principais fraquezas da estrutura SNMPv1. Entretanto, naquela poca, pensava -se que a definio d uma grade de e segurana comercial poderia no ser satisfatria no seu projeto e difcil de ser aprovada porque segurana significa muitas coisas diferentes para pessoas diferentes. Devido a isso, e porque alguns usurios no requeriam um forte servio de autenticao, o SNMPv1 estruturou um servio de autenticao como um bloco separado, a ser definido mais tarde. O SNMPv3 fornece uma arquitetura para ser usada neste bloco, bem como uma definio para seus subsistemas. A estrutura de gerenciamento SNMPv2 completamente descrita da RFC 1902 at a RFC 1907. A coexistncia e assuntos relacionados transio do SNMPv1 para o SNMPv2 so discutidas na RFC 1908. O SNMPv2 fornece vrias vantagens sobre o SNMPv1: a) tipos de dados expandidos: contadores de 64 bits; b) melhorias de eficincia e desempenho: operador get-bulk; c) confirmao de eventos de notificao: operador inform; d) tratamento de erros mais elaborado: erros e excees; e) melhorias nos conjuntos: especialmente na criao e excluso de colunas; f) linguagem de definio de dados afinada.

40 Entretanto, a estrutura SNMPv2, conforme descrita nas RFCs de 1902 at 1907, incompleta no sentido de que no atinge os objetivos originais de desenvolvimento do projeto SNMPv2. Os objetivos no alcanados incluem a pr oviso de segurana e administrao, tambm chamados de segurana de grau comercial com: a) autenticao: identificao de origem, integridade das mensagens, e alguns aspectos de proteo contra retransmisso e duplicao de mensagens: b) privacidade: confidencialidade; c) controle de acesso e autorizao; e d) capacidades de administrao e configurao remota conveniente a estas caractersticas. J a estrutura de gerenciamento SNMPv3, como descrito nas RFCs de 2570 at 2575, corrige as deficincias encontradas no SNMPv2 relacionadas segurana e administrao. As RFCs SNMPv3 foram produzidas pelo SNMPv3 Working Group do Internet Engineering Task Force (IETF). O SNMPv3 Working Group no reinventou a roda, mas reusou os documentos padres do SNMPv2. Como resultado, o SNMPv3 o SNMPv2 com segurana e administrao. As novas caractersticas do SNMPv3 so: a) segurana: - autenticao e segurana; - autorizao e controle de acesso; b) estrutura administrativa: - nomeao de entidades; - pessoas e polticas de acesso; - nomes de usurios e gerenciamento de chaves; - notificaes de destinos; - relacionamentos de proxy. Estas novas caractersticas sero estudadas com mais detalhes no decorrer do trabalho.

41

4.1.6

CONSIDERAES FINAIS SOBRE O SNMP

A estrutura de gerenciamento SNMP, segundo Lynch (1993), tem obtido um

crescimento e sucesso fenomenal porque preenche os requisitos de gerenciamento de redes atuais. O SNMP simples, com operaes de protocolo elegantes, um projeto de nomeao de variveis, e provises para extenso da MIB, caractersticas pelas quais se tornou popular entre vendedores de equipamentos de rede bem como entre os administradores de redes. Foram eles, os administradores de rede, que tornaram o SNMP um padro de facto para gerenciamento aberto atravs de foras de mercado, fazendo com que importantes organizaes de padronizao abraassem o SNMP e as especificaes a ele referentes como padres de jure. O crescimento do SNMP continua, ao ser aplicado em novas reas alm daquelas as quais se destinava or iginalmente, como o gerenciamento de largas reas de trocas de pacotes TCP/IP. O SNMP no serve apenas para gateways, mas utilizado tambm para monitorar e controlar muitos tipos de sistemas de redes, de dispositivos da camada Message Authentication Code - MAC a aplicaes de rede. O SNMP no usado apenas para redes, mas est sendo usado tambm na administrao de sistemas e outras aplicaes no voltadas ao gerenciamento de redes. O SNMP no mais usado apenas para redes TCP/IP, mas est sendo aplicado a todos os tipos de tecnologia de redes, incluindo outras famlias de protocolos, tais como DECnet e OSI, ou em casos onde no h um protocolo de interconexo presente (incluindo UDP e IP), para suportar o gerenciamento de redes. A popularidade do SNMP internacional. Como resultado deste crescimento e sucesso inesperado, a estrutura de gerenciamento SNMP, o chamado padro de curto-prazo para gerenciamento de redes aberto no mais de curto-prazo, mas ir continuar a crescer e prosperar enquanto continuar atendendo s necessidades de seus usurios constituintes. O SNMP no perfeito. Entretanto, a habilidade de explorar mecanismos de extensibilidade dentro da sua estrutura, tal como as provises para acomodar a definio de novas variveis MIB e de melhorar as provises de segurana, iro ajudar a estrutura a atender os requisitos dos administradores de redes. Estes mecanismos iro ajudar a garantir que o SNMP continue a ocupar um lugar importante na arte e cincia do gerenciamento de redes abertas nos anos que viro (Lynch, 1993).

42

5 SNMPV3
Provavelmente a caracterstica mais importante do SNMPv3 segundo Zeltserman (1999), a segurana. O SNMPv3 atinge este objetivo ao oferecer autenticao forte e criptografia de dados. O que a autenticao oferece : a) que apenas grupos autenticados possam se comunicar. Isto garante que uma estao gerenciadora possa coletar dados de um dispositivo ou configur-lo apenas se o dispositivo permitir que aquela estao gerenciadora o acesse; b) que as mensagens sejam recebidas em um tempo prtico (timely fashion). Isto evita que as mensagens sejam salvas e/ou adulteradas e repassadas mais tarde de forma a causar danos. A privacidade s pode ser usada se a autenticao tambm for usada. Logo as escolhas de segurana disponveis so: sem autenticao e sem segurana; apenas autenticao; com autenticao e segurana. H duas partes na gerncia SNMPv3. Uma a configurao das aplicaes SNMPv3, especificamente fontes de notificaes e encaminhadoras de proxy : a) configurar para quem enviar traps ou mensagens informativas; b) configurar encaminhadores de proxy. A outra parte definir vises MIB que possam ser acessadas por usurios diferentes. Usando isto, se pode controlar que variveis da MIB determinado usurio pode acessar. Notific aes, encaminhadores de proxy e controle de acesso s variveis MIBs podem ser configurados remotamente atravs de um conjunto complexo de tabelas MIB. A razo para a popularidade do SNMP e seu contnuo crescimento a sua simplicidade. De fato, ele possui apenas quatro operaes duas para obter dados, uma para modificar dados, e uma para um dispositivo enviar notificaes de forma assncrona. A complexidade est realmente no gerenciamento dos dados que o SNMP acessa. Nem todos os dados mantidos por um dispositivo so teis. Parte do que torna difcil a construo de aplicaes de gerenciamento de redes teis entender que dados de gerenciamento usar e como analis-los.

43
FIGURA 8 Entidade SNMPv3

E ntid ad e S N M P v 3

M ot or S N M P

D es pac h an t e

Subsistema de S is te m a d e Processamento P r o c es s a m e n to de mensagens

M e n s a g en s

S u b s is te m a d e S e gu ra n a

S u b s i s te m a d e C o n tr o le A c es s o

A p l ic a e s G e r ad or a d e c o m an d o s R ec e p t o r a d e n ot i fic a e s E n c a m in h a d o r a d e p r o x y

R e sp on d e d o r a d e c o m a n d o s

G e r a d o r a d e n o t ifi c a e s

O u tr a s

FONTE: Adaptado de Zeltserman (1999. pg. 98).

A maior misso, entretanto, no desenvolvimento do SNMPv3 foi a de criar uma estrutura modular que pudesse ser facilmente extendida. Com isso se espera que no seja necessria a criao de um SNMPv4 no futuro. Uma entidade SNMPv3 composta de duas partes: um motor SNMP e aplicaes SNMP (fig. 8). O que era antes chamado de agentes e gerentes SNMP agora se chamam entidades.

5.1 MOTOR SNMPV3

Cada entidade SNMP contm um motor SNMP. Colocando em termos mais simples, um motor SNMP realiza o processamento de mensagens SNMP, com segurana e controle de acesso. Como se v na figura 8, um motor SNMP constitudo dos seguintes componentes: a) despachante; b) subsistema de processamento de mensagens; c) subsistema de segurana;

44 d) subsistema de controle de acesso.

5.1.1

DESPACHANTE
responsvel por enviar e receber mensagens. Quando uma mensagem recebida, o

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

snmpInBadVersions incrementado e a mensagem descartada. O despachante tambm responsvel por enviar PDUs para as aplicaes, e por selecionar o meio de transporte mais adequado para enviar as mensagens;

5.1.2

SUBSISTEMA DE PROCESSAMENTO DE MENSAGENS

constitudo de um ou mais modelos de processamento de mensagens. A figura 9

mostra um subsistema de processamento de mensagens que suporta o SNMPv3, o SNMPv2, o SNMPv1 e um modelo chamado Outros. Este modelo permite que outros modelos possam ser acrescentados ao subsistema. O subsistema de processamento de mensagens responsvel por: a) preparar mensagens para serem enviadas;
FIGURA 9 Subsistema de processamento de mensagens

Su bs ist em a de Pr oc es sa m e nto d e M e ns ag ens

M od elo de Pr oces sam e nt o d e M en sag en s S N MP v3

M od elo d e P ro ce s sa m e nt o d e M en sag en s S N M P v2

M o de lo d e P ro ce ss am en to de M en sa g en s S NM P v1

O u t ro s

FONTE: Adaptado de Zeltserman (1999. pg. 99). b)

extrair dados das mensagens recebidas.

45 Exemplo: o despachante recebe uma mensagem SNMPv3 vlida. O despachante determina a verso da mensagem e a repassa ao modelo de processamento de mensagens SNMPv3. Este por sua vez processa a mensagem extraindo os dados da mesma e chama ento o subsistema de segurana para descriptografar a poro de dados da mensagem (se necessrio) e se assegura que a mensagem est devidamente autenticada. Neste ponto o despachante ir encaminhar a PDU da mensagem para a aplicao SNMP apropriada.

5.1.3

SUBSISTEMA DE SEGURANA
O subsistema de segurana fornece servios de segurana tais como autenticao de

mensagens e criptografia/descriptografia de mensagens para obter privacidade.

FIGURA 10 Subsistema de segurana

S u bs ist e m a de S e gu ra n a

M o d el o d e S eg ura n a B a s e ad o e m U s u rio

M o d e lo d e S e g u ra n a B a se a d o e m C o m u nid ad e

O u t ro M o d e lo d e S e g u r an a

FONTE: Adaptado de Zeltserman (1999. pg. 100).

A figura 10 mostra um subsistema de segurana que suporta o modelo para o SNMPv3, o modelo baseado em comunidade, e um modelo chamado Outro. O modelo baseado em comunidade d suporte s verses SNMPv1 e SNMPv2c. Um subsistema de segurana define entre outras coisas: a) as ameaas de segurana para as quais fornece proteo; b) os servios que fornece; c) os protocolos de segurana utilizados para prover os servios utilizados, tais como privacidade e autenticao. O modelo de segurana baseado em usurio protege as mensagens SNMPv3 das seguintes ameaas: a) um usurio autorizado que envie uma mensagem que seja alterada em trnsito por uma entidade SNMP no autorizada;

46 b) um usurio no autorizado tentando se mascarar como um usurio autorizado; c) modificaes no fluxo das mensagens; d) espionagem. O modelo de segurana baseado em usurio atualmente define o uso do Hashing for Message Authentication Code Message Digest 5 96 bits (HMAC -MD5-96) e Hashing for Message Authentication Code Secure Hash Function 96 bits (HMAC-SHA-96) como os protocolos de autenticao e o Chain Block Cipher Data Encryption Standard (CBC-DES) como o protocolo de privacidade. Os modelos de segurana das verses SNMPv1 e SNMPv2c oferecem apenas uma autenticao fraca (nomes de comunidade) e nenhuma privacidade.

5.1.4

SUBSISTEMA DE CONTROLE DE ACESSO

responsvel por determinar se o acesso a um objeto gerenciado deve ou no ser

permitido (fig. 11). Atualmente h um modelo de controle de acesso definido: o View-based Access Control Model (VACM). Com o VACM possvel controlar quais usurios e quais operaes podem ter acesso aos objetos gerenciados. Qualquer aplicao SNMP que precise acessar os objetos gerenciados podem chamar o VACM. Atualmente, seriam as aplicaes processadoras de comandos e as geradoras de notificaes. Tambm neste caso possvel definir novos modelos de controle de acesso para serem adicionadas ao subsistema de controle de acesso.
FIGURA 11 Subsistema de controle de acesso

S u bs ist e m a de C o nt r ole d e Ac es s o
M o d el o d e C on tr o le d e A c es s o B a s e ad o e m V is o O u tr o M o d e l o d e C o n t r ol e d e S e g u ra n a O u tr o M o d e lo d e C o nt role d e S e gu ran a

FONTE: Adaptado de Zeltserman (1999. pg. 102).

47 Stallings (2001) define que uma entidade SNMPv3 pode ser de dois tipos: uma entidade SNMPv3 gerente tradicional (fig. 12) ou uma entidade SNMPv3 agente tradicional (fig. 13).

5.1.5

GERENTE SNMP TRADICIONAL

Na terminologia SNMPv3 tradicional, um gerente SNMP inclui trs categorias de

aplicaes (fig. 12). As aplicaes geradoras de comandos monitoram e manip ulam dados gerenciveis em agentes remotos; elas fazem uso das PDUs SNMPv1 e SNMPv2, incluindo Get, GetNext, GetBulk , e Set. Uma aplicao geradora de notificaes inicia mensagens assncronas; no caso de um gerente tradicional, a PDU InformRequest usada por esta aplicao. Uma aplicao receptora de notificaes processa as mensagens assncronas que chegam ao gerente; estas incluem as PDUs InformRequest , SNMPv2-Trap e SNMPv1-Trap. No caso de uma PDU InformRequest chegar ao gerente, a aplicao receptora de notificaes ir responder com uma PDU Response. Todas estas aplicaes fazem uso dos servios fornecidos pelo motor desta entidade. O motor SNMP realiza duas funes principais: a) ele aceita PDUs vindas das aplicaes SNMP, realiza o processamento necessrio, incluindo a insero de cdigos de autenticao e criptografia, e ento encapsula as PDUs em mensagens para transmisso; b) ele aceita mensagens que chegam da camada de transporte, realiza o processamento necessrio, incluindo autenticao e descriptografia, e ento extrai as PDUs das mensagens e as passa para a aplicao SNMP apropriada. Em um gerente SNMP tradicional, o motor SNMP contm um despachante, um subsistema de processamento de mensagens e um subsistema de segurana. O despachante simplesmente um gerente de trfego. Para as PDUs de sada, o despachante aceita PDUs vindas das aplicaes e realiza as seguintes funes: para cada PDU, o despachante determina o tipo de processamento de mensagem requerido (SNMPv1, SNMPv2, SNMPv3) e passa a PDU no mdulo de processamento de mensagens adequado no subsistema de processamento de mensagens. Depois disso, o subsistema de processamento de mensagens retorna a mensagem contendo a PDU incluindo os cabealhos apropriados da mensagem. O despachante passa ento esta PDU para a aplicao apropriada.

48
FIGURA 12 Gerente SNMPv3 tradicional

A pl ic a es S N M P
A p lic a e s g er a do ra s d e c o m a n d os A p lic a es g e r a d o ra s d e n o t i fic a e s A p li c a e s re c e p t o r a s d e n o t i f ic a e s

De sp a c ha nt e

S ub s is t em a p r oc es sa m en t o d e m e ns a g en s
v1

S ub si s te m a d e se gu ra n a
M o d elo d e s eg ur a n a b a s e ad o e m u s u ri o

d es pa c h an t e de P D U s v2 c d es p a c h an t e d e m e n s ag en s v3

O ut r o m o d e lo d e s eg ur a n a

m a p e a m e n to d e t r a n s p o r t e

o ut r o

M o to r S N M P v 3

U DP

IP X

O u tr o

R e de

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

O subsistema de processamento de mensagens aceita as PDUs de sada vindas das aplicaes via despachante e as prepara para transmisso, envolvendo-as no cabealho apropriado da mensagem e retornado-as ao despachante. O subsistema de processamento de mensagens tambm aceita mensagens que chegam entidade e ao serem repassadas pe lo despachante, processa cada cabealho destas mensagens, e retorna a PDU anexada ao despachante para que ele possa encaminha-la aplicao adequada. O subsistema de segurana realiza funes de autenticao e criptografia. Cada mensagem a ser enviada passada ao subsistema de segurana pelo subsistema de processamento de mensagens. Dependendo dos servios requisitados, o subsistema de segurana pode criptografar a PDU em anexo, e/ou gerar um cdigo de autenticao para ser

49 inserido no cabealho da mensagem. A mensagem ento retornada ao subsistema de processamento de mensagens. Similarmente, cada mensagem recebida pela entidade gerente passada ao subsistema de segurana pelo subsistema de processamento de mensagens. Se requisitado, o subsistema de segurana verifica o cdigo de autenticao e realiza a descriptografia da PDU. Aps estas operaes a mensagem processada retornada ao subsistema de processamento de mensagens.

5.1.6

AGENTE SNMP TRADICIONAL

Um agente tradicional (fig. 13) deve conter trs tipos de aplicaes: processadoras de

comandos; geradoras de notificaes e encaminhadoras de proxy. A aplicao processadora de comandos prov acesso aos dados gerenciados.
FIGURA 13 Agente SNMPv3 convencional
U DP IP X O u tr o

M ot or SN M Pv 3 Sub sist em a pr oce ss a m e nt o de m ens age ns

v1

m a p ea m e n t o d e t ra n s p o r te

Subs is te m a de s e gur a na
M od elo de s e guran a b a s e ad o e m u s u ri o

S ubsi ste m a con tr ol e de ace sso

M o d e lo d e c o n tr o l e d e a c es s o b as e a d o e m v is o O u tr o m o d e lo d e c on tr o le d e ac es s o

De spac hante

v2 c d e s p a c h a n te d e m e n s a g e n s v3

O ut ro m o delo d e s e guran a

d e sp ac h a n t e d e P D U s

o u t ro

A p lic a e s e n c a m i n h a d o r as de prox y

A p li c a es r es p o n d ed o r a s d e c o m an d os

A p l ic a e s ge rador as d e n ot i fic a e s

Apl ic a e s SN M P

In st r u m e n t a o M IB

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

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

5.2 APLICAES SNMP

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

51 processadoras de comandos e geradoras de notificao so o que se chamava de agente SNMP.

5.3 PROCESSAMENTO DE MENSAGENS SNMPV3

A seguir ser demonstrado como realizado o processamento das mensagens pelas entidades SNMPv3.

5.3.1

FORMATO DAS MENSAGENS SNMPV3

Segundo Stallings (2001), cada mensagem inclui um cabealho e uma PDU. A

estrutura da mensagem ilustrada na figura 14; os campos escuros so aqueles criados e processados pelo subsistema de processamento de mensagens.
FIGURA 14 Formato da mensagem SNMPv3

m s g V e r s io n m s g ID m s g M a x S iz e m s g F la g s m s g S ec u r i ty M o d e l

m s g G l o b a lD a ta = d ad o s d e ca b e a lh o

E sc opo da autenticao

m s g S e c u r it y P a r am e t e rs

D e f i n id o e u s a d o p e l o m o d e lo d e s e g u r a n a

c o n t ex t E n g i n e ID co n t e xt N a m e

Es copo da c riptogr afia

m s g D at a = S c op ed PD U PD U S N M P v 2 ( t e xt o p l an o o u c ript og raf ad o )

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

A mensagem SNMPv3 inclui os seguintes campos:

52 a) msgVersion: serve para informar sobre a verso SNMP utilizada na composio da mensagem; b) msgID: um identificador nico usado entre duas entidades SNMP para coordenar mensagens de requisio e resposta, e pelo processador de mensagens para coordenar o processamento da mensagem por diferentes modelos de subsistemas existentes na arquitetura das entidades; c) msgMaxSize: contm o tamanho mximo suportado pela mensagem em octetos. Este o tamanho mximo de segmento que o remetente pode aceitar de outro motor SNMP; d) msgFlags: um octeto contendo trs flags nos trs ltimos bits significativos: reportableFlag , privFlag, authFlag. Se reportableFlag =1 ento uma Report PDU deve ser retornada ao remetente sob as condies que podem causar a gerao de uma Report PDU; quando reportableFlag =0, uma Report PDU no deve ser retornada. A flag reportableFlag configurada para 1 pelo remetente em todas as mensagens contendo um request (Get, Set) ou um Inform, e configurado para 0 para mensagens contendo uma Response PDU, uma Trap PDU, ou uma Report PDU. O flag reportableFlag uma ajuda secundria na determinao de quando enviar uma Report PDU. usado somente nos casos em que a poro PDU da mensagem no pode ser dec odificada (por exemplo, quando a descriptografia falha, devido a uma chave incorreta). As flags privFlag e authFlag so configuradas pelo remetente para indicar o nvel de segurana que foi aplicado mensagem. Para privFlag=1, criptografia foi aplicada e para authFlag=1, autenticao foi aplicada. Todas as combinaes so permitidas exceto privFlag=1 e authFlag=0; ou seja, no permitido criptografia sem autenticao; e) msgSecurityModel: um identificador que indica qual modelo de segurana foi usado pelo remetente para preparar a mensagem, e portanto, qual modelo de segurana deve ser usado pelo destinatrio para processar a mensagem. Os valores reservados incluem: 1 para SNMPv1, 2 para SNMPv2c, e 3 para o USM. f) msgSecurityParameters: um octeto que contm parmetros gerados pelo subsistema de segurana na entidade SNMP que enviou a mensagem e processado pelo subsistema de segurana na entidade receptora. O contedo deste campo no

53 interpretado pelo subsistema de processamento de mensagens nem pelo despachante. g) contextEngineID: um octeto que identifica unicamente uma entidade SNMP. Para as mensagens que chegam, este campo determina para qual aplicao a scopedPDU ser encaminhada para processamento. Para as mensagens que sero enviadas, este valor fornecido pela aplicao ao emiter uma requisio para enviar uma mensagem; h) contextName : um octeto que identifica unicamente um contexto em particular com o escopo do motor de contexto associado; i) PDU SNMPv2: uma PDU. O modelo de processamento de mensagem SNMPv3 especifica que esta deve ser uma PDU SNMPv2. A figura 14 mostra como estes campos esto organizados. Os campos msgID, msgMaxSize, msgFlags, e msgSecurityModel so referenciados na definio ASN.1 pelo nome de msgGlobalData. Este bloco contm parmetros necessrios pelo subsistema de processamento de mensagens para coordenar o tratamento e processamento da mensagem. J os campos contextEngineID, contextName , e PDU SNMPv2 so referenciados pelo nome msgData e possui um tipo scopedPduData. Uma PDU de escopo uma PDU que contm informaes nomeadas em um contexto em que so unicamente identificadas pelo contextEngineID e pelo contextName . Este bloco contm informaes necessrias pela aplicao para processar a PDU.

5.4 ALGORITMOS SNMPV3

CRIPTOGRFICOS

USADOS

PELO

A seguir sero apresentados alguns conceitos bsicos de criptografia e um breve estudo dos algoritmos criptogrficos utilizados pelo SNMPv3 para prover a autenticao e a privacidade das mensagens trocadas entre as entidades SNMPv3.

5.4.1

CONCEITOS BSICOS DE CRIPTOGRAFIA

Criptografia, do grego krypts (escondido, oculto) + grpho (grafia, escrita), a arte

ou a cincia de escrever em cifra ou em cdigo; em outras palavras, um conjunto de tcnicas que permitem tornar incompreensvel uma mensagem originalmente escrita com clareza, de

54 forma a permitir que apenas o destinatrio a decifre e a compreenda. Quase sempre o deciframento requer o uso de uma chave (Luchesi, 1986). A criptoanlise, do grego krypts + anlysis (decomposio) a arte ou cincia de determinar a chave ou decifrar mensagens sem conhecer a chave (Luchesi, 1986). A criptologia, do grego krypts + logos (estudo, cincia), a cincia que rene a criptografia e a criptoanlise (Luchesi, 1986). Stallings (2001) cita que uma estrutura criptogrfica padro possui cinco elementos (fig. 15): a) texto simples: esta a mensagem legvel ou os dados que so fornecidos como entrada para o algoritmo criptogrfico; b) algoritmo de criptografia: um algoritmo que realiza vrias substituies e transformaes no texto simples; c) chave secreta: a chave secreta tambm uma entrada para o algoritmo. As substituies e transformaes exatas realizadas pelo algoritmo dependem da chave secreta;
FIGURA 15 Criptografia convencional

C h a ve s e c r e t a c o m p a r t ilh ad a p e lo r e m e t e n te e r ec e p t o r t ex to c r i p t o g ra f a d o t r a n s m i tid o

C h a v e s e cr e ta c o m p a r ti lh a d a p e l o r e m e te n t e e r e c e p to r

e n t ra d a d e te x to s i m p l e s

a lg o r it m o d e c r ip to g r a f i a

a lg or itm o d e d e s cr ip to g r a fi a

s a d a d e t e xto s im p l e s

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

d) texto cifrado: esta a mensagem misturada produzida como sada do algoritmo. Esta depende da chave secreta e do texto simples. Para uma mensagem dada, duas chaves diferentes iro gerar dois textos cifrados diferentes;

55 e) algoritmo de descriptografia: essencialmente o algoritmo de criptografia executado de forma reversa. Ele recebe o texto cifrado e a mesma chave secreta e a partir destes, produz o texto simples original. Basicamente, segundo Luchesi (1986), a criptografia computacional usada para permitir: a) sigilo de informaes: permite que somente os usurios autorizados tenham acesso informao, ou consigam torn -la inteligvel; b) integridade de informaes: garantia oferecida ao usurio d que a informao e correta, original, no foi alterada, nem intencionalmente nem acidentalmente; c) autenticao de usurio: processo que permite ao sistema verificar se a pessoa ou processo com quem est se comunicando de fato a pessoa ou processo que ale ga ser; d) autenticao de remetentes: processo que permite a um usurio certificar-se que a mensagem recebida foi de fato enviada pelo remetente, podendo inclusive provar, perante um juiz, que o remetente enviou determinada mensagem; e) autenticao de destinatrios: consiste em se ter uma prova de que a mensagem enviada foi como tal, recebida pelo destinatrio; f) autenticao de atualidade: consiste em provas de que a mensagem atual, no se tratando de mensagens antigas reenviadas.

5.4.2

DATA ENCRYPTION STANDARD (DES)

Segundo Stallings (2001), a estrutura de criptografia mais utilizada atualmente, a

baseada no DES, adotada em 1977 pelo National Bureau of Standards, agora o National Institute of Standards and Tecnology (NIST). O DES cifra blocos de 64 bits em blo cos de 64 bits, usando uma chave de 56 bits (64 bits dos quais oito bits so de paridade). Assim, para cifrar, escolhe -se uma chave e divide-se a mensagem em blocos de 64 bits, cifrando cada bloco separadamente. Por usar a mesma chave tanto para a criptografia quanto para a descriptografia, sendo necessrio manter esta chave em segredo (apenas o remetente e o destinatrio devem conhecla), o DES dito um algoritmo simtrico de chave secreta (Luchesi, 1986).

56 O SNMPv3, segundo Stallings (2001), define uma verso melhorada do DES original chamada de Cipher Block Chaining Mode Data Encryption Standard (CBC-DES). Isto porque o DES processa apenas blocos de dados de 64 bits por vez. Para grandes quantidades de texto, necessrio quebrar o texto em blocos maiores que 64 bits. A maneira mais simples de proceder utilizar o modo electronic codebook (ECB), no qual o texto simples tratado 64 bits de cada vez e cada bloco de texto simples criptografado usando a mesma chave. O termo codebook usado porque, para uma dada chave, h um nico texto cifrado para cada bloco de 64 bits de texto simples. Com o ECB, se o mesmo bloco de 64 bits de texto simples aparecer mais de uma vez na mensagem, ele sempre produzir a mesma sada. Para resolver este problema preciso usar um mecanismo que gere blocos de textos cifrados diferentes, mesmo usando o mesmo bloco de texto simples. Uma forma simples de fazer isso usar o modo CBC. Neste esquema, a entrada do algoritmo de criptografia o Xtended OR - XOR do bloco de texto simples atual e do bloco de texto cifrado anterior; sendo que a mesma chave usada para cada bloco. Como efeito, encadeia -se juntamente o processo da seqncia de blocos de texto simples. A entrada para a funo de criptografia para cada bloco de texto simples no possui nenhuma relao com o bloco de texto simples. Portanto, a repetio de padres de 64 bits no exposta. Para obter maiores informaes sobre o DES consulte Menezes (1997) e Schneier (2001).

5.4.3

MESSAGE DIGEST 5 (MD5)

Stallings (2001) cita que um elemento essencial nas estruturas de autenticao e

assinaturas digitais uma funo hash segura. Uma funo hash aceita uma mensagem de tamanho varivel como entrada e produz um cdigo hash de tamanho fixo, chamado s vezes de sumrio da mensagem (message digest), como sada. H duas funes hash especificadas para uso com o SNMPv3: a MD5 e a SHA-1. O algoritmo de sumrio de mensagem (message digest ) - MD5, descrito na RFC 1321 foi desenvolvido por Ron Rivest no MIT. At recentemente, o MD5 era o algoritmo hash seguro mais usado. Este algoritmo pega uma mensagem de tamanho arbitrrio como entrada e produz como sada um sumrio de mensagem de 128 bits. A entrada processada em blocos de 512 bits.

57 O algoritmo MD5 tem a propriedade de que cada bit do cdigo hash uma funo de cada bit da entrada. O autor do MD5 conjectura que a dificuldade de se gerar duas mensagens com o mesmo sumrio da ordem de 264 operaes, e a dificuldade de gerar uma mensagem que produza um dado sumrio da ordem de 2128 operaes. Para obter maiores informaes sobre o algoritmo MD5 consulte Menezes (1997) e Schneier (2001).

5.4.4

SECURE HASH FUNCTION (SHA-1)

O algoritmo SHA foi desenvolvido pelo NIST e publicado como o padro de

processamento de informaes federais a ser usado pelo norte-americano em 1993. Uma reviso foi feita em 1995 e foi chamada de SHA-1. O algoritmo SHA -1 possui como entrada uma mensagem com um tamanho mximo menor que 264 bits, e produz como sada um sumrio de mensagem de 160 bits. A entrada processada em blocos de 512 bits. Para obter mais informaes sobre o algoritmo SHA-1 consulte Menezes (1997) e Schneier (2001).

5.4.5

AUTENTICAO DE MENSAGENS COM O HMAC

Segundo Stallings (2001), a autenticao de mensagens um procedimento que

permite a grupos que se comuniquem verificar se as mensagens recebidas so autnticas. H dois aspectos importantes que so: verificar se o contedo da mensagem no foi alterado e se a origem da mensagem autntica. O MAC uma tcnica amplamente usada para realizar a autenticao das mensagens, e um algoritmo surgiu como o padro Internet para uma grande variedade de aplicaes: HMAC. Um algoritmo MAC envolve o uso de uma chave secreta para gerar um pequeno bloco de dados, conhecido como um cdigo de autenticao da mensagem, que acrescentado mensagem. Esta tcnica assume que dois elementos se comunicando, digamos Alice e Bob, compartilham a chave secreta comum K. Se Alice quiser enviar uma mensagem para Bob, ela calcula o cdigo de autenticao da mensagem como uma funo da mensagem e da chave. A mensagem mais o cdigo transmitida para Bob. Bob ento realiza o mesmo clculo na mensagem recebida, usando a mesma chave secreta, para gerar um novo cdigo de

58 autenticao para a mensagem. O cdigo recebido comparado com o cdigo calculado. Se o cdigo recebido igual ao cdigo calculado, ento: a) o receptor tem certeza de que a mensagem no foi alterada; b) o receptor tem certeza que a mensagem mesmo do remetente especificado; c) se a mensagem incluir um nmero de seqncia, ento o receptor tem certeza que a seqncia das mensagens apropriada, porque seria improvvel para um atacante alterar com sucesso o nmero seqencial. Um grande nmero de algoritmos pode ser usado para gerar o cdigo, mas a alternativa mais eficiente e popular o HMAC. O HMAC descrito na RFC 2104, e foi escolhido como a implementao MAC mandatria (mandatory-to-implement MAC) para a segurana no IP, e usado em outros protocolos Internet, tais como o Secure Socket Layer (SSL) e Secure Electronic Transaction (SET). A maior vantagem do HMAC tratar a funo hash como uma caixa preta. Isto possui dois benefcios. Primeiro, uma implementao j existente de uma funo hash pode ser usada como um mdulo na implementao do HMAC. Segundo, se for desejvel troc ar uma funo hash especfica de implementao do HMAC por outra, tudo o que necessrio remover o mdulo com a funo existente e colocar em seu lugar o novo mdulo. Com isso, se a segurana da funo hash for comprometida, a segurana do HMAC pode ser obtida novamente simplesmente substituindo a funo hash comprometida por uma nova funo mais segura (por exemplo, substituir o MD5 pelo SHA-1).

5.5 USER-BASED SECURITY MODEL USM

Segundo Stallings (2001), a RFC 2274 define o modelo de segurana baseado no usurio (USM) para o SNMPv3. Esta especificao inclui: a) autenticao: prov integridade de dados e autenticao da origem dos dados. O cdigo de autenticao de mensagens HMAC, que usa atualmente as funes hash MD5 ou SHA-1, fornece esta autenticao; b) sincronizao ( timeliness ): protege contra demoras ou duplicao de mensagens;

59 c) privacidade: protege contra revelao do contedo da mensagem. O modo de ciframento encadeado de blocos (CBC) do DES usado para a criptografia da mensagem; d) formato da mensagem: d efine o formato do campo msgSecurityParameters, que suporta as funes de autenticao, tempo e privacidade. e) descoberta: define procedimentos pelos quais um motor SNMP obtm informaes sobre outro motor SNMP; f) gerenciamento de chaves: define procedimentos para a gerao de chaves, sua atualizao e uso.

5.5.1

PARMETROS DE SEGURANA USM

A RFC 2274 define uma estrutura, UsmSecurityParameters, que especifica o formato

interno do campo msgSecurityParameters de uma mensagem SNMPv3. A figura 16 mostra o formato de uma mensagem SNMPv3 j com o uso do USM. Os campos escuros indicam os campos que so criados e processados pelo USM. Antes de examinar os campos do msgSecurityParameters, preciso definir o conceito de um motor SNMP autorizado. Em qualquer mensagem transmitida, uma das duas entidades envolvidas (emissor ou receptor) designada como um motor SNMP autorizado, de acordo com as seguintes regras: a) quando uma mensagem SNMP contm uma carga que exige uma resposta (por exemplo, uma PDU Get, GetNext, GetBulk, Set ou Inform), ento o receptor de tal mensagem autorizado; b) quando uma mensagem SNMP contm uma carga que no exige uma resposta (por exemplo, um Trap-SNMPv2, ou uma PDU Response ou Report), ento o emissor de tal mensagem autorizado. Esta designao serve a dois propsitos: a) O tempo da mensagem determinado atravs de um relgio mantido pelo motor autorizado. Quando um motor autorizado envia uma mensagem (Trap, Response, Report), esta contm o valor corrente do relgio deste motor, desta forma o motor no autorizado pode se sincronizar com este relgio. Quando um motor no autorizado envia uma mensagem (Get, GetNext, GetBulk , Set, Inform), este inclui o

60 valor de seu tempo corrente, estimado com base no relgio de destino, permitindo ao destino avaliar o tempo da mensagem.; b) um processo de localizao de chave, descrito mais adiante, habilita um nico diretor (usurio) a possuir as chaves armazenadas em mltiplos motores; estas chaves so localizadas pelo motor autorizado de tal forma que o diretor responsvel por uma nica chave, evitando o risco de segurana de armazenar mltiplas cpias da mesma chave em uma rede distribuda. Faz sentido designar o receptor das mensagens geradas pelo gerador de comandos e PDUs Inform como um motor autorizado pelo fato deste ser o possuidor do relgio autorizado em uma troca. Se uma resposta ou trap est atrasada ou duplicada, poucos danos podem ocorrer. Entretanto, geradores de comandos e, de certa forma, PDUs Inform resultam em operaes de gerenciamento, tais como leitura ou configurao de objetos MIB. Por isso, importante garantir que tais PDUs no estejam atrasadas ou duplicadas, o que poderia causar efeitos indesejados. Quando uma mensagem a ser enviada passada ao USM pelo processador de mensagens, o USM preenche o campo msgSecurityParameters. Quando uma mensagem recebida passada ao USM pelo processador de mensagens, o USM processa os valores contidos no msgSecurityParameters repassando em seguida a mensagem novamente ao processador de mensagens. Os campos do msgSe curityParameters so: a) msgAuthoritativeEngineID: o snmpEngineID do motor SNMP autorizado envolvido na troca da mensagem; b) msgAuthoritativeEngineBoots : o valor snmpEngineBoots do motor SNMP autorizado envolvido na troca da mensagem. O objeto snmpEngineBoots um inteiro que representa o nmero de vezes que este motor SNMP inicializou ou reinicializou a si mesmo desde sua configurao inicial; c) msgAuthoritativeEngineTime: o valor snmpEngineTime do motor SNMP

autorizado envolvido na troca da mensagem. O objeto snmpEngineTime um inteiro que representa o nmero de segundos desde que este motor SNMP autorizado incrementou pela ltima vez o objeto snmpEngineBoots. Cada motor SNMP autorizado responsvel por incrementar seu prprio valor

snmpEngineTime a cada segundo. Um motor SNMP no autorizado responsvel

61 por incrementar sua noo de snmpEngineTime para cada motor autorizado remoto com o qual se comunica;
FIGURA 16 Formato da mensagem SNMPv3 com USM

m s g V e r s io n m s g ID m s g M a x S iz e m s g F la g s m s g S ec u r i ty M o d e l m s g A u th or i ta t i ve E n g in eI D m s g A u t h o r ita t iv e E n g in e B o o ts

m s g G l o b a lD a ta = d a d o s d e ca b e a lh o

Escopo da autenticao

m s g A u t h o r ita ti v e E n g in e T i m e m s gU s e rN a m e m s g A u th en ti c at i o n P a r a m et e r s m s g P r i v a c yP a r a m e t e r s c o n t ex t E n g i n e ID co n t e xt N a m e

m s g S e c u r it y P a r a m e te r s

Es copo da cr iptogr afia

m s g D a ta = S c o p e d P D U PD U S N M P v 2 ( te x t o p la n o o u c ri p t og ra f ad o)

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

d) msgUserName: o diretor (usurio) em favor do qual a mensagem est sendo trocada; e) msgAuthenticationParameters : nulo se a autenticao no for usada na comunicao agente/gerente. Caso contrrio este um parmetro de autenticao. Pela definio atual do USM, o parmetro de autenticao um cdigo de autenticao de mensagem HMAC; f) msgPrivacyParameters: nulo se no usado privacidade na comunicao agente/gerente. Caso contrrio este um parmetro de segurana. Pela definio

62 atual do USM, o parmetro de privacidade um valor usado para formar o valor inicial no algoritmo CBC-DES (privPassword e SnmpEngineID); O conjunto de mecanismos de sincronizao do USM inclui: a) gerenciamento de relgios autorizados: cada motor SNMP que possa vir a agir como um motor autorizado (geralmente um agente), deve manter dois objetos, snmpEngineBoots e snmpEngineTime, que se referem ao seu tempo local. Com isso todos os motores que possam receber PDUs Inform devem manter estes dois objetos; b) sincronizao: um motor SNMP que opere de modo no autorizado deve permanecer permanentemente sincronizado com cada motor SNMP autorizado com o qual este se comunica. Para este fim, o motor no autorizado mantm uma cpia local de trs varivei s (snmpEngineBoots, snmpEngineTime, e

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

msgAuthoritativeEngineBoots

msgAuthoritativeEngineTime

mensagem

recebida com os valores do snmpEngineBoots e snmpEngineTime que este motor mantm, referente ao motor SNMP remoto correspondente. Segundo Stallings (2001), cada entidade SNMP mantm uma MIB, a usmUser, que informa sobre os usurios (diretores) locais e remotos. Este grupo consiste de um objeto escalar, usmUserSpinLock , e uma tabela usmUserTable. O objeto usmUserSpinLock habilita aplicaes geradoras de comandos a coordenar o uso de suas fbricas para troca de chaves

63 usando a usmUserTable e para garantir a atomicidade quando da realizao de operaes nesta tabela a fim de evitar inconsistncias nos dados da mesma.

5.5.2

FUNES CRIPTOGRFICAS USADAS PELO USM

Segundo Stallings (2001), h duas funes criptogrficas definidas para o USM:

autenticao e criptografia. Para suportar estas funes, um motor SNMP requer dois valores: uma chave privada (privKey ) e uma chave de autenticao (authKey). Valores separados destas duas chaves so mantidas pelos seguintes usurios: a) usurios locais: qualquer diretor neste motor SNMP para o qual so autorizadas operaes de gerenciamento; b) usurios remotos: qualquer diretor em um motor SNMP remoto com o qual a comunicao desejada. Estes valores so atributos de usurio armazenados para cada diretor (usurio) relevante. Os valores da privKey e authKey no so acessveis via SNMP. Para a autenticao o USM permite o uso de um dos seguintes protocolos de autenticao: HMAC -MD5-96 ou HMAC-SHA-96. Para o HMAC-MD5-96, o cdigo de autenticao de mensagem HMAC usado, com o MD5 atuando como a funo hash. Uma authKey de 128 bits usada como entrada para o algoritmo HMAC. O algoritmo produz uma sada de 128 bits, que truncada para 96 bits. Este valor o cdigo de autenticao da mensagem que ser inserido no campo msgAuthenticationParameters da mensagem SNMPv3. Para o HMAC-SHA-96, a funo hash usada a SHA-1. A authKey possui 160 bits de tamanho. O algoritmo produz uma sada de 160 bits que truncada para 96 bits. Para a criptografia e descriptografia o USM usa o modo CBC do DES. Uma privKey de 128 bits fornecida como entrada ao protocolo de criptografia. Os primeiros 64 bits desta privKey so usados como uma chave DES. Como o DES requer apenas uma chave de 56 bits, o ltimo bit significativo de cada octeto ignorado. Para o modo CBC (64 bits restantes), um vetor de inicializao (VI) de 64 bits requerido. Este vetor produzido da seguinte maneira: a) os oito ltimos octetos da privKey so usados como um pr-VI; b) para garantir que dois VIs so usados para duas entradas de textos planos diferentes criptografados com a mesma chave, um valor-sal (salt-value) de oito octetos

64 gerado. O valor-sal igual concatenao do valor corrente da snmpEngineBoots existente neste motor (que possui um tamanho de quatro octetos) e um inteiro de 32 bits mantido pelo algoritmo de criptografia local. Este inteiro de 32 bits dependente de implementao e deve ser modificado depois de cada uso do mesmo; c) o valor-sal sofre uma operao XOR bit a bit com o pr-VI para produzir o VI. O valor-sal colocado no campo msgPrivacyParameters da mensagem SNMPv3 para permitir que a entidade receptora possa computar o VI corretamente. Este esquema faz o seguinte: como o valor -sal muda toda vez que usado, um VI diferente usado para diferentes textos planos. E como apenas o valor-sal transmitido via SNMP, um atacante no pode determinar o VI.

5.5.3

PROCESSAMENTO DE MENSAGENS USM

A figura 17 mostra em termos gerais, os procedimentos seguidos pelo USM para o

processamento de mensagens recebidas e enviadas. A seguir ser mostrado como feito este processamento ignorando-se alguns erros bsicos que podem interromper o processo, tais como um campo msgSecurityParameters invlido. O USM realiza os seguintes passos ao receber um generateRequestmsg (primitiva gerada pelo subsistema de processamento de mensagens) tratado por uma aplicao geradora de comandos: a) o USM determina se h uma entrada na usmUserTable para o destino securityEngineID e a fonte securityName. Se no houver, uma indicao de erro retornada; b) o USM determina se o securityModel requisitado suportado por este usurio e, se no for, retorna uma indicao de erro; c) se o securityLevel requisitar privacidade, ento o valor scopedPdu criptografado usando o CBC-DES e a chave privada de criptografia localizada na privKey deste usurio. O texto cifrado gerado armazenado no campo scopedPdu, e o valor-sal derivado do valor da privKey armazenado no campo msgPrivacyParameters da mensagem SNMPv3. Se a privacidade no for requisitada, ento o campo msgPrivacyParameters configurado para NULL; d) o parmetro snmpEngineID armazenado no campo msgAuthoritativeEngineID; e) o parme tro securityName armazenado no campo msgUserName ;

65
FIGURA 17 Processamento de mensagens USM: transmisso

O b t er inf orm a e s do u s u r io

r e q u e r id o p ri v a c id a d e ? NO

S IM

E nc ript ar s c op e dP d u s e t m s g P r i va c y P a r a m e t e r s

m s g P r iv ac y P a r a m e te r s n u ll S tr in g

r e q u e r id o a u te n t i c a o ?

S IM

c om p u ta r M A C se t m sg A u th e n t i c a ti o n P a r a m e t e rs

N O

m s g A u t h e n tic a t io n P a r a m e te r s n u ll S tr in g

T r an sm it ir m en s a g e m

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

f) se o securityLevel requisitar autenticao, o valor corrente do snmpEngineBoots e snmpEngineTime correspondentes ao parmetro snmpEngineID so armazenados nos campos msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime,

respectivamente. Ento o cdigo de autenticao da mensagem calculado sobre toda a mensagem, usando o HMAC e a chave de autenticao localizada na authKey deste usurio armazenada no msgAuthenticationParameters. Se o securityLevel no requisitar autenticao, um valor zero armazenado nos campos msgAuthoritativeEngineBoots e msgAuthoritativeTime e o campo

msgAuthenticationParameters configurado para NULL; g) a mensagem completa com seu tamanho retornada ao mdulo de processamento de mensagens que fez a requisio.

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

67 Muitos dos passos citados anteriormente so os mesmos utilizados por uma aplicao processadora de comandos, mas h algumas diferenas importantes. A seguir so exibidos os passos realizados pelo USM quando este invocado com uma primitiva processIncomingMessage vinda do subsistema de processamento de mensagens.
FIGURA 18 - Processamento de mensagens USM: recepo

O b te r o s p a r m e t ro s d a m e ns a ge m

Us a au te n ti c a o ? N O

S IM

C o m p u t ar M A C ; c o m p a ra r c o m m s g A u th e n ti c a ti o n P ar a m et e r s

D e t erm ina r s e a m en s ag em e s t d e n t r o d a j a n e l a d e t em p o

Us a p r iv a c id a d e ? NO

S IM

D e s c r ip t o g ra f a r s c op e d P d u

R e c e b e r m en sa g e m

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

Esse processamento feito enquanto o processador de mensagens est tratando uma mensagem Request que acaba de chegar. Os passos so os seguintes: a) os valores dos parmetros de segurana so extrados do securityParameters. Um bloco cachedSecurityData preparado para servir de cache para as seguintes informaes: MsgUserName; SecurityEngineID; SecurityLevel.

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

i) uma referncia ou ponteiro para este bloco em cache colocado na sada do parmetro securityStateReference; j) a scopedPdu retornada ao mdulo de processamento de mensagens que realizou a requisio. Aps o retorno do USM para o processador de mensagens, o processador de mensagens subseqentemente retorna a PDU recuperada para a aplicao processadora d e

69 comandos. Enquanto isso, o processador de mensagens armazena em cache o valor do securityStateReference que recebido em retorno do USM, como parte do conjunto dos parmetros do processador de comandos que este possui no cache. Subseqentemente a isso, o processador de comandos pode preparar uma PDU Response e invocar ento o processador de mensagens com uma primitiva prepareResponseMsg. O processador de mensagens ir ento invocar o USM com a primitiva generateResponseMsg, que possui os mesmos parmetro de s entrada e sada do generateRequestMsg com uma exceo: generateResponseMsg inclui o securityStateReference como um parmetro de entrada. O processador de mensagens obtm este valor do seu cache e passa o valor do securityStateReference para a requisio Request recebida que combine com o Response da sada. O USM realiza os seguintes passos aps o recebimento de uma generateResponseMsg: a) usando o valor recebido de securityStateReference , o USM obtm as informaes do usurio armazenando-as na cache. Estas informaes provm da mensagem Request processada anteriormente; b) o USM determina se o securityLevel requisitado suportado para este usurio, e se no for, uma indicao de erro retornada; c) se o securityLevel requisitar privacidade ento o valor da scopedPdu criptografado usando o CBC-DES e a chave privada de criptografia localizada na privKey deste usurio.O texto cifrado resultante armazenado no campo scopedPdu , e o valor-sal derivado do valor da privKey armazenado no campo msgPrivacyParameters da mensagem SNMPv3. Se no for requisitado privacidade, ento o campo mspPrivacyParameters configurado para NULL; d) o parmetro snmpEngineID armazenado no campo msgAuthoritativeEngineID da mensagem SNMPv3; e) o parmetro securityName armazenado no campo msgUserName ; f) os valores correntes de snmpEngineBoots e do snmpEngineTime para este motor local autorizado so armazenados nos campos msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime, respectivamente. Se o securityLevel requisitar autenticao, o cdigo de autenticao da mensagem calculado sobre toda a mensagem usando o HMAC e a chave privada de autenticao localizada na authKey deste usurio, atravs do clculo do cdigo de autenticao da mensagem

70 para esta mensagem e comparando o resultado com o do campo

msgAuthenticationParameters na mensagem; g) a mensagem completa com seu tamanho retornada ao mdulo de processamento de mensagens que solicitou a requisio. O passo (f) mostra a diferena entre um motor autorizado e um no autorizado. No caso de um motor no autorizado, os valores dos campos msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime do cabealho da mensagem so configurados somente se a mensagem deve ser autenticada por um receptor autorizado. Esta restrio faz sentido porque o receptor autorizado ir checar estes campos apenas se a mensagem deve ser autenticada. Entretanto, para uma mensagem Response vinda de um motor autorizado, os valores msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime presentes no cabealho da mensagem so sempre configurados. No caso de um remetente autorizado, estes valores representam os valores locais oficiais do snmpEngineBoots e snmpEngineTime. Quando uma mensagem Response recebida por um motor no autorizado, este deve usar estes valores apenas para a sincronizao da mensagem se a mensagem for autenticada.

5.5.4

DESCOBERTA
O USM requer o uso do processo de descoberta para obter informaes suficientes

sobre outros motores SNMP para poder se comunicar com eles. Em particular, um motor SNMP no autor izado deve aprender o valor snmpEngineID de um motor autorizado antes que a comunicao seja realizada. Este processo realizado em duas etapas. Primeiro, o motor no autorizado envia uma mensagem Request ao motor autorizado ao qual deseja descobrir com um securityLevel requisitado de noAuthnoPriv. A mensagem inclui um campo msgUserName com o valor initial e um msgAuthoritativeEngineID nulo. A PDU Request anexada possui uma varBindList vazia. O motor autorizado ir responder com uma mensagem Report contendo seu snmpEngineID no campo msgAuthoritativeEngineID; Segundo, se uma comunicao autenticada requisitada, o motor no autorizado precisa estabelecer uma sincronizao de tempo com o motor autorizado. Para fazer isso, o motor no autorizado envia uma mensagem Request autenticada com o campo

71 msgAuthoritativeEngineID configurado com o valor do snmpEngineID remoto recentemente aprendido e com os valores dos campos msgAuthoritativeEngineBoots e

msgAuthoritativeEngineTime configurados com um valor de zero. A resposta a esta mensagem autenticada ser uma mensagem Report do motor autorizado com seus valores correntes de snmpEngineBoots e snmpEngineTime presentes nos campos

msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime. A partir deste momento o motor no autorizado j pode se comunicar (se permitido) usando autenticao (e criptografia se necessrio) com o motor autorizado.

5.6 GERENCIAMENTO DE CHAVES

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

5.6.1

ALGORITMO DE TRANSFORMAO DE SENHA PARA CHAVE

A RFC 2274 define um algoritmo para mapeamento de uma senha comum para uma

chave de 128 ou 160 bits. Resumidamente a gerao das chaves feita da seguinte maneira: a) pega-se a senha do usurio como entrada e se produz uma string de 1.048.576 octetos atravs da repetio da senha tantas vezes o quanto for necessrio, truncando o ltimo valor se necessrio, para formar uma string digest0; b) se for desejado criar uma chave de 128 bits, pega -se o hash MD5 do digest0 para formar digest1. A sada a chave do usurio.

72 Uma das vantagens deste algoritmo que ele reduz bastante a possibilidade de um ataque de dicionrio ou fora bruta e decouples nas chaves do usurio de qualquer NMS em particular. Nenhum NMS necessrio para armazenar as chaves do usurio. Ao invs disso, uma chave de usurio gerada quando necessrio a partir da senha do usurio. Uma nica senha pode ser usada para gerar uma nica chave usada tanto para autenticao quanto para privacidade. Entretanto seria mais seguro usar duas senhas, uma para gerar uma chave de autenticao e outra para gerar uma chave de

privacidade/criptografia.

5.6.2

LOCALIZAO DE CHAVES
Uma chave localizada definida na RFC 2274 como uma chave secreta compartilhada

entre um usurio e uma entidade SNMP autorizada. O objetivo que assim o usurio precisa manter apenas uma nica chave (ou duas se usar autenticao e privacidade) e, portanto lembrar de apenas uma senha (ou duas). O processo pelo qual uma nica chave do usurio convertida em mltiplas chaves nicas, uma para cada motor SNMP remoto, chamado de localizao de chave. Dentre os principais objetivos para o gerenciamento de chaves podemos citar: a) cada sistema agente SNMP em uma rede distribuda possui sua prpria chave nica para cada usurio autorizado a gerenci -lo. Se mltiplos usurios esto autorizados como gerentes, o agente possui uma nica chave de autenticao e uma nica chave de criptografia para cada usurio. Por isso, se a chave de um usurio comprometida, as chaves dos outros usurios no o so; b) as chaves de um usurio so diferentes para agentes diferentes. Nesse caso, se um agente comprometido, apenas as chaves de usurio para aquele agente so comprometidas e no as chaves de usurio em uso para os outros agentes. c) o gerenciamento de rede pode ser realizado de qualquer ponto da rede, independente da disponibilidade de um sistema de gerenciamento de rede (NMS). Isto permite a um usurio realizar funes de gerenciamento a partir de qualquer estao gerenciada. Esta capacidade fornecida pelo algoritmo de senha para chave. possvel definir tambm alguns procedimentos a serem evitados:

73 a) um usurio precisa lembrar um grande nmero de chaves, nmero este que cresce com a adio de novos agentes; b) um adversrio que obtenha a chave de um agente capaz de personificar qualquer outro agente para qualquer usurio, ou qualquer usurio para qualquer outro agente. Para atender aos objetivos e consideraes anteriores, uma nica chave de usurio mapeada pelo uso de uma funo de mo nica irreversvel em diferentes chaves localizadas, para motores autenticados diferentes.
FIGURA 19 Localizao de chaves

P e g u e o h as h d a c h a v e d o u s u ri o e d o E n g in e ID r e m o to

C h a v e l oc a liz ad a

c h a v e d o u s u ri o S en h a d o u s u r io P egue o hash da s e n h a e x p a n d id a

P e g u e o h as h d a c h a v e d o u s u ri o e d o E n g in e ID r e m o to

C h a v e loc a li z ad a

P e g u e o h as h d a c h a v e d o u s u ri o e d o E n g in e ID r e m o to

C h a v e l o c ali z a d a

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

O procedimento o seguinte: a) formar uma string digest2 pela concatenao de digest1, o valor snmpEngineID do motor autorizado (agente) e digest1; b) se uma chave de 128 bits for desejada, pega -se o hash MD5 do digest2. Se uma chave de 160 bits for desejada, pega-se o hash SHA-1 do digest2. A sada a chave do usurio. A chave localizada resultante pode ento ser configurada no sistema agente de forma segura. Devido natureza do MD5 e do SHA-1, improvvel que um adversrio possa aprender uma chave de usurio, mesmo que o adversrio venha a descobrir a chave localizada. A figura 19 resume bem esse processo.

74

5.6.3

ATUALIZAO DE CHAVES
O SNMPv3 assume que h algum meio seguro de entregar chaves localizadas para

sistemas autenticados (agentes). Esta entrega segura est fora do escopo do SNMPv3; ela deve ser manual ou por outro protocolo seguro. Uma vez que uma chave inicial (ou par de chaves, no caso de autenticao e privacidade) tenha sido entregue a um agente, o SNMPv3 fornece um mecanismo para atualizar estas chaves de forma segura. Um usurio pode iniciar o processo de troca de chave atravs da requisio e fornecimento de uma nova senha. Alternativamente, o NMS pode iniciar o processo atravs da requisio de uma nova senha. Em ambos os casos a chave existente no NMS atualizada. O NMS pode ento calcular uma chave localizada para cada agente com o qual se comunica. O NMS deve ento se comunicar com segurana com cada agente para que ele atualize sua chave localizada. Obviamente, o NMS no pode simplesmente enviar a chave em texto plano atravs da rede. H duas possibilidades: a) criptografar a nova chave usando a chave antiga como a chave de criptografia; b) usar algum tipo de funo de mo nica para produzir um valor a partir da chave antiga. Deve -se ento realizar um XOR deste valor com a nova chave e enviar o resultado ao agente. O agente pode ento aplicar um XOR sobre a mensagem recebida usando a chave antiga para obter a nova chave. A desvantagem da criptografia a necessidade de usar criptografia mesmo em sistemas que suportam apenas autenticao de mensagens. Outra desvantagem da criptografia as restries feitas sobre a criptografia em vrios pases. Por isso o mtodo adotado pelo SNMPv3 uma variao do segundo mtodo (XOR). O mtodo utilizado pelo SNMPv3 envolve o uso de objetos KeyChange localizados no usmUserGroup. Um diretor remoto ou um NMS configura este objeto, que ento automaticamente usado pelo agente para atualizar a chave correspondente. O algoritmo leva em considerao que um tamanho varivel de chave pode ser usado por um algoritmo de autenticao ou criptografia em particular, o que complica o algoritmo de atualizao de chaves. O SNMPv3 permite que ambos, um administrador da rede ou um usurio possam atualizar uma chave de usurio em particular. Um administrador de rede pode configurar as

75 chaves iniciais para um usurio e pode requerer que o usurio troque as senhas de tempos em tempos, e cuidar da atualizao de chaves quando isso acontecer. Alm disso, o usurio pode trocar sua senha e chave(s) a qualquer momento. Para acomodar estes dois requisitos, o grupo usmUSer contm dois objetos de troca de chaves para cada uma das chaves. Para a chave de autenticao o usmAuthKeyChange deve ser configurado pelo administrador da rede para que a chave seja atualizada. O sistema agente configurado de forma que apenas o administrador da rede tenha acesso a este objeto, permitido pelo subsistema de controle de acesso. O objeto usmUserOwnAuthKeyChange no protegido por controle de acesso mas definido de forma a permitir a atualizao apenas se o requisitante possui o mesmo userName como objeto usmUserName para esta linha. provem Similarmente, capacidade de o usmUserPrivKeyChange atualizao para uma e

usmUserOwnPrivKeyChange

chave

criptografada para o administrador da rede e outra para o usurio, respectivamente.

5.7 VIEW-BASED ACCESS CONTROL MODEL - VACM

Segundo Stallings (2001), o modelo de controle de acesso baseado em viso (VACM) definido na RFC 2275, possui duas caractersticas importantes: a) o VACM determina se o acesso a um objeto gerenciado em uma MIB local por um diretor remoto deve ser permitido; b) o VACM faz uso de uma MIB que define a poltica de controle de acesso para este agente, e torna possvel o uso da configurao remota. A RFC 2275 define cinco elementos que fazem parte do VACM: a) grupos: um grupo definido como um conjunto de zero ou mais tuplas <securityModel, securityName > nas quais os objetos de gerenciamento SNMP podem ser acessados. Um securityName se refere a um diretor, e direitos de acesso para todos os diretores em um dado grupo so idnticos. Um nico groupName associado com cada grupo. O conceito de grupo uma ferramenta til para categorizar os gerentes de acordo com seus direitos de acesso. Por exemplo, todos os gerentes de topo podem possuir um conjunto de direitos de acesso, enquanto que gerentes de nvel intermedirio podem ter um conjunto totalmente diferente de direitos de acesso. Qualquer combinao de securityModel e securityName pode pertencer no mximo a um grupo, ou seja, para um agente qualquer, um diretor

76 cujas comunicaes so protegidas por um securityModel dado, pode somente ser includo em um grupo; b) nvel de segurana: os direitos de acesso para um grupo podem ser diferentes dependendo do nvel de segurana da mensagem que contm a requisio. Por exemplo, um agente pode permitir acesso somente de leitura para uma requisio feita por uma mensagem no autenticada, mas, pode requisitar autenticao para acesso de escrita; c) contextos: um contexto MIB um subconjunto nomeado de instncias de objetos na MIB local. Os contextos fornecem uma forma til de agregar objetos em colees com diferentes polticas de acesso. O contexto um conceito que se relaciona ao controle de acesso. Quando uma estao de gerenciamento interage com um agente para acessar informaes de gerenciamento naquele agente, a iterao entre o diretor de gerenciamento e o motor do agente SNMP, e os privilgios de controle de acesso so expressos em uma viso MIB que se aplica ao diretor e seu contexto. Os contextos possuem as seguintes caractersticas chave: uma entidade SNMP, unicamente identificada por um contextEngineID, pode manter mais de um contexto; um objeto ou uma instncia de objeto pode aparecer em mais de um contexto; quando mltiplos contextos existem, para identificar uma instncia de objeto individual, seu contextName e contextEngineID deve ser identificado em relao ao seu tipo de objeto e sua instncia. d) vises MIB: seria interessante restringir o acesso de um grupo particular a um subconjunto de objetos gerenciados em um agente. Para atingir este objetivo, o acesso a um contexto feito atravs de uma viso MIB, que define um conjunto especfico de objetos gerenciados. O VACM faz uso de uma tcnica poderosa e flexvel para definir vises MIB, baseadas no conceito de vises de subrvores e vises de famlias. A viso MIB definida como uma coleo, ou famlia de subrvores, com cada subrvore sendo includa ou excluda da viso. O SNMPv3 inclui o conceito de subrvore. Uma subrvore na da mais do que um n na hierarquia de nomeao da MIB mais todos os seus elementos subordinados. Mais formalmente uma subrvore pode ser definida como um conjunto de todos os objetos e instncias de objetos que tenham um prefixo OBJECT IDENTI FIER

77 ASN.1 comum em seus nomes. Associados a cada entrada na vacmAccessTable esto trs vises MIB, uma para leitura, uma para escrita e outra para notificao de acesso. Cada viso MIB consiste em um conjunto de vises de subrvores. Cada viso de subrvore na viso MIB, especificada como sendo includa ou excluda. Isto significa que, a viso MIB ou inclui, ou exclui todas as instncias de objetos contidas na subrvore. Em acrscimo, uma mscara de viso definida para reduzir a quantidade de informao de configurao requerida quando um controle de acesso mais refinado requerido. e) poltica de acesso: o VACM permite que um motor SNMP seja configurado para reforar um conjunto particular de direitos de acesso. A determinao do acesso ou negao do mesmo depende dos seguintes fatores: o diretor fazendo a requisio de acesso. O VACM torna possvel para um agente permitir diferentes privilgios de acesso para diferentes usurios. Os diretores esto associados a grupos e a poltica de acesso especificada em relao a estes grupos; o nvel de segurana pelo qual a requisio foi comunicada na mensagem SNMP. Tipicamente, um agente ir requerer o uso de autenticao para mensagens contendo uma requisio set (operao de escrita); o modelo de segurana usado para processar a mensagem requisitada. Se mltiplos modelos de segurana esto implantados em um agente, o agente pode ser configurado para fornecer diferentes nveis de acesso, para requisies comunicadas via mensagens processadas por modelos de segurana diferentes; o contexto da MIB usado para a requisio; a instncia do objeto especfica para o qual acesso requerido. Alguns objetos mantm mais informaes crticas ou sensitivas que outros, e, portanto a poltica de acesso deve depender na instncia de objeto especifica requisitada; o tipo de acesso requisitado (leitura, escrita, notificao). A leitura, escrita e notificao so operaes de gerenciamento distintas, e diferentes polticas de controle de acesso podem ser aplicadas para cada uma destas operaes. O servio fornecido pelo subsistema de controle de acesso definido pela primitiva isAccessAllowed. A definio desta primitiva especifica que os parmetros de entrada so securityModel, securityName , securityLevel, viewType, contextName , e variableName.

78
FIGURA 20 Lgica VACM

Q UE M

O N DE
c o n te x tN a m e

CO MO
s e c u ri ty M o d e l

P OR QU E

O QU E

Q U AL

s e c u ri ty L e v e l tip o- do o b j e to i n s t nc ia d o ob je to

s e c u ri ty M o d e l

s e c u r ity N am e v a c m C o n te x tT a b l e v ie w T y p e

v a c m S e c u r ity T o G r ou p T ab le

gr oup N am e

v ar ia b l eN a m e ( O ID )

v a c m A c c es s T a b le

v ie w N am e

v ac m V ie w T r e e F a m ily T ab le

D e c is o S im /N o

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

Todos estes parmetros so necessrios para realizar a deciso sobre o controle de acesso. Colocando de outra maneira, o subsistema de controle de acesso definido de forma a prover uma ferramenta muito flexvel para configurar o controle de acesso no agente, atravs da diviso dos componentes de controle de acesso em seis variveis separadas. A figura 20 adaptada da figura existente na RFC 2275, prov uma forma til de analisar as variveis de entrada, e mostra como as vrias tabelas na MIB VACM so usadas para realizar a deciso sobre o controle de acesso: a) quem: a combinao do securityModel e do securityName define o quem da operao; identifica um dado diretor cujas comunicaes so protegidas por um certo securityModel. Esta combinao pode pertencer a mais de um grupo neste motor SNMP. O vacmSecurityToGroupTable prov o groupName, dados o securityModel e o securityName; b) onde: o contextName especifica onde o objeto gerenciado desejado pode ser encontrado. O vacmContextTable contm uma lista dos contextName reconhecidos;

79 c) como: a combinao do securityModel e do securityLevel define como a PDU Inform ou request foi protegida. A combinao de quem, onde, e como identificam entradas de zero ou um na vacmAccessTable ; d) por qu: o viewType especifica porque o acesso requisitado: para uma operao de leitura, escrita ou notificao. A entrada selecionada na vacmAccessTable contm uma MIB viewName para cada um destes trs tipos de operaes, e o viewType usado para selecionar um viewName especfico. Este viewName seleciona a viso MIB apropriada do vacmViewTreeFamilyTable ; e) o que: a variableName um identificador de objeto cujo prefixo identifica um tipo de objeto especfico e cujo sufixo identifica uma instncia de objeto especfica. O tipo de objeto indica qual tipo de informao de gerenciamento requisitada; f) qual: a instncia de objeto indica qual item especfico de informao requisitado. Finalmente, a variableName comparada com a viso MIB obtida. Se a variableName combina com um elemento includo na viso MIB, ento o acesso e fornecido. Agora possvel sumarizar os procedimentos usados pelo VACM para determinar se o acesso permitido. Quando isAccessAllowed invocada por uma aplicao, o VACM realiza os seguintes passos (fig. 21): a) o VACM checa se h uma entrada no vacmContextTable para o contextName. Se houver, ento este contexto conhecido por este motor SNMP. Se no houver ento um errorIndication de noSuchContext retornado; b) o VACM checa o vacmSecurityToGroupTable para determinar se h um grupo associado a este par < secutityModel, securityName >. Se houver, ento este diretor operando sob este securityModel um membro de um grupo configurado neste motor SNMP. Se no houver, ento um errorIndication de noGroupName retornado; c) o VACM consulta em seguida o vacmAccessTable usando groupName,

contextName , securityModel, e securityLevel como ndices. Se uma entrada fo r encontrada, ento uma poltica de controle de acesso foi definida para este groupName, operando sob este securityModel, neste securityLevel, para acessar este contextName. Se no for encontrada uma entrada, ento um errorIndication de noAccessEntry retornado;

80
FIGURA 21 Fluxograma VACM

C o n t e xt o e s t d is p o n ve l ? ( v a c m C o n t ex t T a b l e) S IM

N O n o S u c h C o n t e xt

G ru p o e s t d i s p o n v e l ? ( va c m S e c u r it y G r o u p T a b l e ) S IM

N O

no G rou pN am e

E n t rad a de ac es s o en c o nt rad a? ( v a c m A cc e s s T a b l e ) S IM

N O

n o A c c e ss E n t ry

C h e c a r t ip o d e v is o ( v a c m A cc e s s T a b l e )

n o S u c h V ie w

C h e c a r v is o ( va c m V i e w T r e e F a m i ly T a b l e )

notific a o

gr avao

leitura

n o S u ch V i e w

C h e c a r a va ri v e l ( v a c m V i e w T r e e F a m i ly Ta b le )

n o In V i e w

a c c e s s A l lo w ed

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

d) o VACM determina ento se a entrada vacmAccessTable selecionada inclui uma referncia a uma viso MIB de viewType. Se houver uma referncia, ento esta entrada contm um viewName para esta combinao de groupName , contextName , securityModel, securityLevel, e viewType. Se no houver uma referncia, ento um errorIndication de noSuchView retornado;

81 e) o viewName usado como um ndice na vacmViewTreeFamilyTable . Se uma viso MIB for encontrada, ento uma viso MIB foi configurada para este viewName. Caso contrrio, um errorIndication de noSuchView retornado; f) o VACM verifica a variableName contra a viso MIB selecionada. Se esta varivel est includa na viso, ento uma statusInformation de accessAllowed retornada; g) se esta varivel no estiver includa na viso, ento um errorIndication de noInView retornado.

5.7.1

A MIB VACM
A MIB VACM (fig. 22) contm informaes nas seguintes categorias: a) informaes sobre contextos locais: a vacmContextTable lista os contextos localmente disponveis por nome; esta informao usada por aplicaes geradoras de comandos para configurar a vacmAccessTable para controlar o acesso a todos os contextos na entidade SNMP. A vacmContextTable em si possui acesso de apenas leitura e no pode ser configurada por uma operao SNMP. Cada entrada na tabela um nome human-readable que identifica um contexto em uma entidade SNMP em particular. Um contexto vazio, representa o contexto padro. A

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

82 entradas na vacmAccessTable para um groupName em particular. Para deixar mais claro: um contexto se refere a um subconjunto de instncias de objetos na MIB local. Para um grupo em particular, direitos de acesso podem ser definidos em mais de um contexto; se um agente suporta mais de um modelo de segurana, ento os direitos de acesso para um grupo podem ser definidos separadamente em respeito a cada modelo de segurana. Em um dado modelo de segurana, os direitos de acesso de grupo podem ser enumerados para mltiplos contextos; os direitos de acesso de um grupo para um contexto em particular sob um modelo de segurana em particular podem depender no nvel de segurana da troca. Por isso, um grupo pode ter maior direito de acesso para um contexto em particular sob um modelo de segurana em particular se a autenticao utilizada e comparada, do que quando a autenticao no utilizada. Alm do mais, para um dado grupo, contexto, modelo de segurana, e nvel de segurana, o escopo da informao que pode ser acessada pode diferir para leitura, escrita, ou notificao; d) informaes sobre vises MIB: a estrutura vacmMIBView consiste de um nico objeto escalar: vacmViewSpinLock, e uma tabela: vacmViewTreeFamilyTable . O objeto vacmViewSpinLock, habilita as aplicaes geradoras de comandos a coordenarem seus usos da operao Set atravs da criao e modificao de vises. Pode haver mltiplas subrvores associadas com um dado viewName , caso no qual a viso MIB para este viewName consiste da unio de todas estas subrvores. Cada entrada na vacmViewTreeFamilyTable define uma famlia de subrvores MIB, usando a subrvore, a mscara, e o tipo de objetos da coluna. Esta tcnica usada tambm no filtro de notificaes. Em essncia, uma subrvore consiste de um objeto MIB mais todos os objetos que esto subordinados a ela na hierarquia de nomeao. possvel excluir certas partes desta subrvore de forma que ela permanea no como uma subrvore completa, mas apenas como uma subrvore parcial, consistindo de um objeto MIB e alguns de seus objetos subordinados. Esta uma famlia de subrvores. Ento se mltiplas entradas forem agrupadas,

83 possvel definir uma coleo arbitrria de objetos MIB para serem usados para um propsito em particular.
FIGURA 22 A MIB VACM

va c m M IB O b j e t c ts

va c m S e c u r it y M od e l ( 1 )

v a c m C on te x t T a b le ( 1 )

v a cm S e cu ri t y N a m e ( 2 )

va c m C o n t e xtE n t ry (1 )

v a c m G ro u p N a m e ( 3 )

v a c m C on te x t N a m e ( 1 )

va c m S e c u r it y T o G r ou p S t o r ag e T y p e ( 4 )

va c m S e c u r it y T o G r ou p S t a t u s (5 ) va c m S e c u ri t y T o G r ou p T ab le ( 2 )

va c m S e c u r ity T o G r o u p E n t r y ( 1 )

v ac m A c c e s s C o n te x tP r ef i x ( 1 ) v a c m A cc e s s Ta b l e ( 4 ) v a c m A c c e s sS e c u r i t yM o d e l ( 2 ) va c m A c c e s s E n t ry ( 1 ) v ac m A c c e s s S e c u r it yL ev e l ( 3 )

v a c m M I B V i ew s ( 5 )

v a c m A c c e s s C on te x t M a tc h ( 4 )

v ac m Vie w S pin Lo c k (1 )

v a c m A c c e s s R ea d V i ew N a m e ( 5 )

v ac m V ie w T r e e Fa m i ly T a b le ( 2 )

v a c m A c c e s sW ri t e V i e w N a m e ( 6 )

v a c m V i e w T r e e F a m il yE n t r y ( 1 )

v ac m A cc e s s N o t if yV i e w N a m e ( 7 )

v a c m V i e w T re e F am i ly V ie w N a m e ( 1 ) v a c m V ie w T r e e F a m il yS u b tr e e ( 2 ) v a c m V i e w T re e F a m i l yM a s k ( 3 )

va c m A c c e s s S t o r a g e T y p e ( 8 )

va c m A c c e ss S t a tu s ( 9 )

v a c m V i e w T r e e F a m i ly T y p e ( 4 ) v a c m V i e w T re e F am i ly S t a tu s ( 5 ) s n m p N o t ify F il t er R o w S t a t u s ( 6 )

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

84 Segundo Stallings (2001), a RFC 2275 sugere que uma configurao inicial da MIB VACM seja feita durante a instalao de um novo motor SNMP que suporte o VACM. A RFC 2275 define trs possveis configuraes iniciais: a) configurao inicial sem acesso; b) configurao inicial semi-segura; c) configurao inicial com segurana mnima. Para a configurao inicial sem acesso, no h nenhuma configurao inicial e nenhum acesso s variveis MIBs locais permitido durante a instalao do sistema. Nos outros dois casos h uma diferena apenas nas entradas da vacmViewTreeFamilyTable. As demais entradas: vacmContextTable, vacmSecurityToGroupTable, e vacmAccessTable so iguais para estas duas configuraes. O vacmContextTable configurado inicialmente com uma nica entrada que possui o contextName de uma string vazia. Por conveno, este o contexto padro. Similarmente, a vacmSecurityToGroupTable configurada inicialmente com uma entrada apenas. Esta entrada especifica o USM como o securityModel, um securityName com initial e um groupName com initial. Privilgios de acesso sero configurados para este groupName.

Subseqentemente, se o gerente de configurao para este sistema desejar expandir o uso desta configurao semi-segura, este pode adicionar mais securityNames a este groupName. No ser necessrio fazer outras alteraes. Tendo definido um contexto e um grupo, preciso definir as vises MIB deste contexto para o qual este grupo tem acesso. As requisies podem chegar neste grupo com trs nveis de proteo de mensagem: sem proteo, somente autenticao, e autenticao mais privacidade. A vacmAccessTable configurada para este groupName , contextName , e securityModel como segue: a) para comunicao sem proteo (noAuthNoPriv), o acesso a uma viso MIB restrita permitido para operaes de leitura e notificao, e nenhum acesso permitido para operaes de escrita; b) para comunicaes protegidas tanto por autenticao quanto por autenticao mais privacidade, permitido o acesso viso MIB internet, que se refere a subrvore internet inteira da MIB-2.

85 Tudo o que ainda resta definir as vises MIB que correspondem aos viewName internet e restricted. Isto feito na vacmViewTreeFamilyTable . H uma entrada para internet. Esta entrada possui um valor de subrvore 1.3.6.1, que o identificador para o objeto internet MIB-2. Por isso, podemos fazer a seguinte afirmao: para todos os diretores que so membros do grupo initial, que comunicam uma requisio usando autenticao ou autenticao e privacidade usando o securityModel USM, acesso completo a subrvore internet sob o contextName garantido para operaes de leitura, escrita e notificaes. Durante a instalao inicial, o nico diretor que membro deste grupo o diretor com o securityName initial. As cinco entradas restantes da vacmViewTreeFamilyTable possuem um valor vacmViewTreeFamilyViewName com restricted. Entretanto, quando esta tabela indexada usando um viewName com restricted, a viso MIB definida pela coleo destas cinco entradas. Cada uma destas cinco entradas tem um tipo included, e cada uma inclui uma subrvore diferente. Por isso, a viso MIB, definida por estas cinco entradas, consistem da unio das seguintes subrvores da MIB-2: a) o grupo system da MIB -2 (1.3.6.1.2.1.1); b) o grupo snmp da MIB-2 (1.3.6.1.2.1.11); c) o snmpEngine (1.3.6.1.6.3.7.2.1) definido na RFC 2271; d) o snmpMPDStats (1.3.6.1.6.3.8.2.1) definido na RFC 2272; e) o usmStats (1.3.6.1.6.3.9.2.1) definido na RFC 2274. Com isso, possvel fazer a seguinte afirmao: para todos os diretores que so membros do grupo initial, que comunicam uma requisio sem autenticao usando o securityModel USM, o acesso restricted ao conjunto de subrvores sob o contextName permitido para operaes de leitura e notificao. Em adio, acesso ao conjunto de subrvores do grupo internet garantido para operaes de leitura, escrita, e notificao para uma requisio comunicada com autenticao. No momento da instalao, o nico diretor que membro deste grupo o diretor com securityName initial.

5.8 A API ADVENTNET SNMPV3

Segundo a AdventNet (1995), a API SNMP AdventNet o ambiente de desenvolvimento mais abrangente para construir aplicaes e applets de gerenciamento

86 baseados na estrutura SNMP. Esta API consiste em pacotes Java que podem ser usados para desenvolver solues e produtos para o gerenciamento de redes baseados em Java e na Web. As principais caractersticas da API AdventNet SNMPv3 so: a) comunicao SNMP para os protocolos SNMPv1, SNMPv2c e SNMPv3; d) segurana, conforme definido pelos modelos USM e VACM; e) suporte MIB para os formatos SMIv1 e SMIv2; f) componentes Java Beans SNMP que aumentam a funcionalidade da API para uso em ferramentas de desenvolvimento visual em Java; g) suporte a banco de dados para realizar o carregamento de MIBs; h) suporte para armazenamento de informaes de usurios SNMPv3 em banco de dados; i) SNMP Applet Server (SAS) para facilitar a comunicao entre applets e dispositivos gerenciados; j) suporte ao tunelamento (tunneling) HTTP para que os applets se comuniquem sobre uma rede com restries de firewall; k) suporte aos Enterprise Java Beans (EJB) para o desenvolvimento de aplicaes de gerenciamento multicamadas escalveis; l) acesso a API SNMP via Remote Method Invocation (RMI) e Common Object Request Broker Architecture (CORBA) para fornecimento de suporte a computao distribuda; m) ferramenta MibBrowser poderosa, que pode ser usada tanto como uma aplicao como um applet; n) suporte a internacionalizao para os componentes da API e da User Interface (UI); o) ferramentas de linha de comando como snmpget, snmpgetnext, snmpset, sendtrap , etc. Dentre os motivos para uso da API AdventNet para construir aplicaes de gerenciamento pode -se citar: a) suporte multiplataforma: suporta todas as maiores plataformas atuais como Solaris, WindowsNT e Linux com um cdigo base comum para ambas as plataformas;

87 p) padres abertos: construda sobre padres abertos e seguindo as tecnologias padro Internet correntes como Java Beans, HTTP, RMI, CORBA, EJB, etc. O benefcio chave destas tecnologias a rapidez entre desenvolvimento-venda e a facilidade no desenvolvimento de solu es personalizadas para o gerenciamento de redes; q) customizao (customization): fornece uma ampla gama de interfaces Java para o desenvolvimento e entrega de solues altamente personalizadas; r) escalabilidade: fundamentalmente designada como um sistema multicamadas, baseada em tecnologias Internet amplamente usadas, para o desenvolvimento de solues escalveis; s) flexibilidade: uma hierarquia de bibliotecas em pacotes Java fornecida, permitindo a seleo do nvel de suporte via bibliotecas desejado. Assim, possvel acessar informaes detalhadas sobre o SNMP usando a API de baixo nvel, ou usar Java Beans de alto nvel para simplificar a programao, alm de funcionalidades adicionais que fornecem a possibilidade de desenvolvimento sem a necessidade de negociar com os detalhes do SNMP; t) gerenciamento de redes baseadas na Web: atravs de suporte ao HTTP e applets. A API SNMP AdventNet inclui mdulos como SAS e HTTP que permitem aos usurios gerenciarem sua rede via Internet, ou at mesmo atravs de dispositivos sob firewalls. As APIs SAS podem ser estendidas para adicionar suporte a SSL; u) conformidade com padres: a API SNMP da AdventNet est em conformidade com as seguintes especificaes Internet: - SNMPv1 - RFC 1155 e RFC 1157; - SNMPv2c - RFC 1901 e RFC 1907; - SNMPv3 - RFC 2571 e RFC 2572; - SNMPv3 - RFC 2574 (USM); - SNMPv3 - RFC 2575 (VACM); - co-existncia entre SNMPv1, SNMPv2c, SNMPv3 - RFC 2576; - filtro de notificaes e proxy forwarding - RFC 2573. Para o desenvolvimento do prottipo proposto no presente trabalho sero utilizadas as facilidades existentes na API de alto nvel.

88

6 DESENVOLVIMENTO DO PROTTIPO
A seguir sero apresentadas a especificao e a implementao do prottipo, bem como as tcnicas, metodologias e ferramentas utilizadas no seu desenvolvimento.

6.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO

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

89

6.2 ESPECIFICAO
A tcnica utilizada para o desenvolvimento da especificao do prottipo foi a orientao a objetos atravs da Unifield Modeling Language UML. Para obter maiores informaes sobre a orientao a objetos usando a UML consulte Booch (2000) e Furlan (1998). A ferramenta utilizada para a especificao do prottipo foi a verso Student do software Rational Rose. Para obter maiores informaes sobre esta ferramenta consulte Rational (1995).

6.2.1

DIAGRAMAS DE CASOS DE USO

Conforme a notao da UML, e utilizando a ferramenta Rational Rose Student, foi

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

AgenteIp

Usurio

Obter Informaes Desempenho uses uses

GerenteIp

Inicializar Agente

Obter Valores na MIB

Consultar Valores

Inicializar Gerente

90

6.2.2

DIAGRAMA DE CLASSES
Inicialmente, foram identificadas as principais classes do sis tema, seus atributos,

relacionamentos e operaes, conforme figuras 24 e 25. Foram definidas as classes AgenteIp, IpRequestHandler, IpInstrument, IpStat e GerenteDesempenhoIp para atender aos requisitos do prottipo.
Figura 24 - Diagrama de Classes: parte agente

IpInstrument ipDefaultTTL ipForwDatagrams ipForwarding ipFragCreates ipFragFails ipFragOKs ipInAddrErrors ipInDelivers ipInDiscards ipInHdrErrors ipInReceives ipInUnknownProtos ipOutDiscards ipOutNoRoutes ipOutRequests ipReasmFails ipReasmOKs ipReasmReqds ipReasmTimeout ipRoutingDiscards

<<uses>> getIpDefaultTTL() getIpForwDatagrams() getIpForwarding() getIpFragCreates() getIpFragFails() getIpFragOKs() getIpInAddrErrors() getIpInDiscards() getIpInDelivers() getIpInHdrErrors() getIpInReceives() getIpInUnknownProtos() getIpOutDiscards() getIpOutNoRoutes() getIpOutRequests() <<uses>> getIpReasmFails() getIpReasmOKs() getIpReasmReqds() getIpReasmTimeout() getIpRoutingDiscards() setIpDefaultTTL( ) setIpForwarding( )

<<type>>Runnable IpRequestHandler agentName run() IPDEFAULTTTL IPFORWARDING IPFORWDATAGRAMS IPFRAGCREATES IPFRAGFAILS IPFRAGOKS IPINADDRERRORS <<uses>> IPINDELIVERS IPINDISCARDS IPINHDRERRORS IPINRECEIVES IPINUNKNOWNPROTOS IPOUTDISCARDS IPOUTNOROUTES IPOUTREQUESTS <<uses>> IPREASMFAILS IPREASMOKS AgenteIp IPREASMREQDS IPREASMTIMEOUT (from Use Case View) IPROUTINGDISCARDS agentDir atomicTable agentOptions instrument agentInfo REMOVE_ENTRY ipListener ipOidRep usmUserListener mibVarHash usmUserTableListener vacmAccessTableListener ipRequestHandler( ) vacmContextTableListener getIpOidRep() vacmMIBViewsListener getMibVarHash() vacmSecurityToGroupTable getOidRep() Listener setIpInstrument( ) vacmViewTreeFamilyTableListener getSubidList() processGetNextRequest( ) AgenteIp() processGetRequest( ) getIp() processSetRequest( ) initAgenteIp() 0..*

SnmpAgent initSnmpExtensionNodes() initializeV3Settings() shutDownSNMPAgent() setSnmpVersion( ) setDebugLevel(int debug) setPort(port, boolean) setAsyncMode(boolean) setMaxThreads( ) setSnmpV3Compliance(boolean) setV3Configuration(boolean) addSnmpPduRequest Listener(handler) addTrapRequestListener( )

IpStat

int getIpStatField( )

91
Figura 25 - Diagrama de Classes: parte gerente
comunica LineGraphBean setBounds(int, int, int, int) setLfontsize(int) setLfontstyle(String) setXgrid(int) setYgrid(int) setLineColors(Color[]) setTitle(String) setXlabel(String) setYlabel(String) setLineLabels(String[])

SnmpPoller setValues() addResultListener( ) setSendTimeout Events(boolean) loadMibs(String) setDebug(boolean) stopPolling() restartPolling() setObjectIDList(String[]) setPollInterval(int) setSnmpVersion(int) setTargetHost(Stirng) setTargetPort(int) setPrincipal(String) setSecurityLevel(int) setAuthProtocol(int) setAuthPassword(String) setPrivPassword(String) setContextName(String) setContextID(String) create_v3_tables()

<<type>> ComponentListener componentHidden( ) componentMoved( ) componentResized( ) componentShown( )

<<uses>> <<implements>> 0..* JFrame init() show() addSingle( ) SnmpApi setSerializeFileName(String) serialize()

0..* <<uses>> GerenteDesempenhoIp 0..* (from Use Case View) <<implements>> NivSeg Versao protAut protPriv Comunidade Contexto Host IDContexto Intervalo Mib Oid Porta SenhaAut SenhaPriv Timeout Usuario GerenteDesempenhoIp() main( ) IniciarPolling()

<<type>>ActionListener actionPerformed( )

A classe AgenteIp define mtodos para acessar os dados pelos quais responsvel e para processar as mensagens SNMPv3, estando diretamente relacionada s seguintes classes: a) SnmpAgent: classe herdada da API SNMPv3 da AdventNet que contm todos os mtodos utilizados pela classe AgenteIp relacionados s operaes SNMP; b) Runnable: interface padro da API Java que define os mtodos utilizados pela classe AgenteIp para executar o agente no prompt de comando; c) IpRequestHandler: classe que estende a classe SimpleRequestHandler da API SNMPv3 da AdventNet. Esta classe responsvel por direcionar as requisies

92 recebidas pelo agente s classes responsveis pelo seu processamento e por processar automaticamente todas as mensagens SNMPv3 realizando a autenticao das mensagens e a criptografia/descriptografia dos dados quando necessrio; d) IpInstrument: classe responsvel por definir e implementar os mtodos utilizados para acessar e alterar as variveis escalares MIB do grupo ip da Mib-2; e) IpStat: classe nativa utilizada pela classe IpInstrument para acessar as informaes diretamente do sistema operacional do equipamento no qual o agente est sendo executado. A classe GerenteDesempenhoIp executa os mtodos necessrios para se conectar ao agente e para buscar e exibir os resultados em um grfico. Assim como a classe AgenteIp, a classe GerenteDesempenhoIp faz uso de outras classes para realizar suas operaes. Estas classes so as seguintes: a) SnmpPoller: classe da API SNMPv3 da AdventNet que contm a definio de todos os mtodos utilizados pela classe LineGraphBean para tratar as mensagens e parmetros do SNMPv3, usados durante o polling, alm de possuir mtodos para realizao da descoberta de novos agentes e de sincronizao com estes agentes; b) LineGraphBean: classe da API SNMPv3 da AdventNet responsvel por realizar a exposio dos dados de polling na tela na forma de um grfico de linhas; c) SnmpApi: classe da API SNMP da AdventNet utilizada pela classe

GerenteDesempenhoIp para armazenar os dados de descoberta e sincronizao de agentes para uso posterior; d) Jframe: classe padro da API Java utilizada para exibir o gerente na tela; e) ComponentListener: interface padro da API Java implementada pela classe LineGraphBean para tratar os eventos desta classe; f) ActionListener: interface padro da API Java implementada pela classe LineGraphBean e utilizada para tratar os eventos de clique de mouse realizados nos botes de configurao e execuo do gerente.

93

6.2.3

DIAGRAMAS DE SEQNCIA
Nos diagramas de seqncia pode -se observar a execuo de cada caso de uso e

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

94

- consultar valores: o gerente entra em contato com o agente especificado pelo usurio usando as opes de autenticao e segurana do SNMPv3 e, caso tenha permisso de acesso s variveis solicitadas pelo usurio, o gerente aps receber os

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

inicializar agente: o agente deve realizar um processo de inicializao a fim de carregar todas as tabelas com as informaes VACM e USM. Alm disso deve definir a porta, o host, o protocolo usado, as MIBs que utilizar, enfim, todas as operaes necessrias para que ele possa atuar como um agente no equipamento onde foi instalado (fig. 28).
Figura 27 - Inicializao do gerente

96

97

Figura 28 - Inicializao do agente

UmUsuario : Usurio main (String)

UmAgente : AgenteIp

: <<type>>Runnable

: SnmpAgent

AgenteIp()

run() init()

initAgenteIp()

initializeV3Settings()

initSnmpExtensionNodes()

Devido ao fato de as operaes de troca de mensagens entre as entidades agente e gerente serem extensas e numerosas, os diagramas de seqncia exibem apenas uma forma simplificada sobre como esse processamento realizado. Por exemplo, o mtodo processarPDU() pode se referir ao mtodo processGetRequestMessage(), ao mtodo processGetNetxRequestMessage(), ou ao mtodo processSetRequestMessage() da classe IpRequestHandler. Alm disso os diagramas de seqncia no permitem demonstrar processos que so processados simultaneamente, como por exemplo o processo de descoberta e sincronizao.

98

6.3 IMPLEMENTAO
Nesta etapa ser demonstrada a implementao do prottipo conforme a especificao desenvolvida anteriormente.

6.3.1

TCNICAS E FERRAMENT AS UTILIZADAS

Para o desenvolvimento do prottipo foram utilizados a linguagem de programao

Java, a API SNMPv3 da empresa AdventNet e o sistema operacional Windows2000 Server no qual foram realizados os testes do prottipo. De acordo com Furlan (1998), ...uma das linguagens de programao que se adaptou implementao de funes de gerenciamento foi a linguagem Java. O aparecimento da Java revolucionou o desenvolvimento de software para Internet, Intranet e quase todas as redes distribudas. Alm disso, a Java uma linguagem totalmente orientada a objetos, dinmica, independente de plataforma tecnolgica, segura e relativamente fcil de usar. Para o desenvolvimento de parte da funcionalidade do agente foi utilizada a Java Native Interface JNI. Esta foi a forma encontrada para permitir o acesso por parte do agente, s informaes sobre os pacotes IP do sistema operacional Windows2000 Server. Tambm foram utilizados Java Beans , ...estruturas utilizadas para definir componentes de software reutilizveis, incorporveis e modulares. (Flanagan, 1999) Para obter mais informaes sobre a linguagem Java, Java Beans e JNI consulte Deitel (2001), Flanagan (1999) e Sun (199-). Segundo a AdventNet (1995), a API SNMP AdventNet o ambiente de desenvolvimento mais abrangente para construir aplicaes e applets de gerenciamento baseados na estrutura SNMP. Esta API consiste em pacotes Java que podem ser usados para desenvolver solues e produtos para o gerenciamento de redes baseados em Java e na Web. Para o desenvolvimento do prottipo foi utilizada a API SNMPv3 verso 4 da

empresa AdventNet. Para obter maiores informaes sobre a API SNMPv3 da AdventNet consulte AdventNet (2001).

99 O prottipo tambm utiliza a Extensible Markup Language XML para armazenar as informaes das tabelas VACM e USM do agente. Para obter maiores informaes sobre a XML consulte W3C (1996). O prottipo foi executado em uma rede utilizando o sistema operacional Windows2000 Server. Para obter maiores informaes sobre este sistema operacional consulte Minasi (2000). Quadro 01: Inicializao do agente
String version = " V3"; int debugLevel = com.adventnet.agent.logging.Level.WARN; AgentUtil.setAgentDir(agentDir); if(agentOptions.getVersion() != null){ version = agentOptions.getVersion(); } super.setSnmpVersion(version, false); if(agentOptions.getDebugLevel() != -1){ debugLevel = agentOptions.getDebugLevel(); } super.setDebugLevel(debugLevel); int port = 161; if(agentOptions.getPort() != -1){ port = agentOptions.getPort(); } super.setPort(port, false); int trapSendingPort =162; if(agentOptions.getTrapSendingPort() != -1){ trapSendingPort = agentOptions.getTrapSendingPort(); } super.setAsyncMode(true); super.setMaxThreads(4); if(version.equalsIgnoreCase("V3")){ // Compatibilidade com V3 super.setSnmpV3Compliance(true); // Inicializa as configuraes V3. super.setV3Configuration(true); initializeV3Settings(); }

Inicialmente foram criadas as classes AgenteIP, IpRequestHandler e IpInstrument. Na classe AgenteIp esto definidas todas as operaes de inicializao do agente dentre as quais

100 destaca-se a initAgenteIp(), conforme mostrado no quadro 01 e a inicializao das tabelas VACM e USM realizada pelo mtodo initializeV3settings() exibido no quadro 02. Quadro 02: Inicializao das tabelas VACM e USM do agente
public void initializeV3Settings(){ String engineID = "127.0.0.1x8001"; super.getSnmpAPI().setSnmpEngineID(engineID.getBytes()); usmUserLis tener = new UsmUserRequestHandler(this); usmUserListener.addRegistrationListener(hdlr); usmUserTableListener = new UsmUserTableRequestHandler(this, "conf", "UsmUserTable.xml", "xml"); usmUserTableListener.addRegistrationListener(hdlr); vacmMIBViewsListener = new VacmMIBViewsRequestHandler(this); vacmMIBViewsListener.addRegistrationListener(hdlr); vacmContextTableListener = new VacmContextTableRequestHandler(this, "conf", "VacmContextTable.xml", "xml"); vacmContextTableListener.addRegistrationListener(hdlr); vacmSecurityToGroupTableListener = new "VacmSecurityToGroupTable.xml", "xml"); VacmSecurityToGroupTableRequestHandler(this, "conf",

vacmSecurityToGroupTableListener.addRegistrationListener(hdlr); vacmAccessTableListener = new VacmAccessTableRequestHandler(this, "conf", "VacmAccessTable.xml", "xml"); vacmAccessTableListener.addRegistrationListener(hdlr); vacmviewTreeFamilyTableListener = new "VacmViewTreeFamilyTable.xml", "xml"); VacmViewTreeFamilyTableRequestHandler(this, "conf",

vacmviewTreeFamilyTabl eListener.addRegistrationListener(hdlr); }

O mtodo initializeV3settings() responsvel por ler as informaes das tabelas USM e VACM e carreg-las para a memria do agente. No quadro 03 listado parte de uma destas tabelas: a UsmUserTable.xml.

101 Quadro 03: Parte do arquivo UsmUSerTable.xml

<? xml version="1.0" encoding="UTF -8" ? > <Table > <row > <column name =" usmUserSecurityName" value=" privUser" /> <column name =" usmUserSecurityLevel " value =" 3" /> <column name =" usmUserCloneFrom" value=" .0.0" /> <column name =" usmUserAuthProtocol" value =" MD5_AUTH" /> <column name =" usmUserPrivProtocol" value=" CBC_DES" /> <column name =" usmUserPublic" value="757365725075626c6963" /> <column name =" usmUserAuthPassword" value ="7a78817495778578" /> <column name =" usmUserPrivPassword " va lue =" 7a78817495778578" /> <column name =" usmUserStorageType" value="3" /> <column name =" usmUserStatus" value=" 1" /> </row > </Table >

Estes arquivos de tabela podem ser editados manualmente pelo administrador ou dinamicamente pelos gerentes. No caso de edio manual o agente deve ser reiniciado para que as novas alteraes entrem em vigor. A listagem completa das tabelas de configurao utilizadas pelo agente SNMPv3 a seguinte: a) UsmUserTable.xml: armazena os usurios que podem realizar operaes neste agente; b) V3TrapForwardingTable.xml : armazena os usurios configurados para receber traps SNMPv3; c) VacmAccessTable.xml : armazena informaes sobre grupos de acesso; d) VacmContextTable.xml : armazena informaes sobre os contextos; e) VacmSecurityToGroupTable.xml : contm a relao SecurityLevel/Group que relacionam os usurios de um nvel de segurana com um grupo especfico; f) VacmViewTreeFamilyTable.xml : armazena informaes sobre as vises existentes. J a classe IpRequestHandler responsvel por processar todas as mensag ens SNMPv3 recebidas pelo agente destinadas ao grupo ip da Mib-2, realizando a autenticao e criptografia/descriptografia encaminhando em seguida a requisio para a classe responsvel por processar esta requisio. Parte deste processamento pode ser vist o no quadro 04.

102 Quadro 04: Parte do processamento de mensagens GET-Request SNMPv3

// Mtodo que processa todas as operaes GET solicitadas. protected void processGetRequest(SnmpVarBind varb, AgentNode node, VarBindRequestEvent pe) throws Agent SnmpException{ try { // Isto indica que o n est fora da viso das mibs carregadas. if(node == null){ AgentUtil.throwNoSuchInstance(pe.getVersion()); } int [] oid = (int [] )varb.getObjectID().toValue();

if(oid.length != ipOidRep.length + 2){ AgentUtil.throwNoSuchInstance(pe.getVersion()); } int [] inst = (int [] )AgentUtil.getInstance(oid,ipOidRep.length); if(inst[1] != 0){ AgentUtil.throwNoSuchInstance(pe.getVersion()); } Object toReturn = null; switch(node.getSubId()){ case IPFORWARDING: toReturn = instrument.getIpForwarding(); if(toReturn == null){ AgentUtil.throwNoSuchInstance(pe.getVersion()); } SnmpInt var0 = new SnmpInt(((Integer )toReturn).intValue()); varb.setVariable(var0); break;

Aps o processamento, a classe IpRequestHandler envia uma requisio classe IpInstrument (desde que seja uma requisio s variveis do grupo ip da Mib -2) para que ela realize as operaes necessrias sobre as variveis IP. Em seguida a classe IpInstrument retorna o resultado da operao para a classe IpRequestHandler que monta uma PDUResponse e, realiza o processamento SNMPv3 necessrio encaminhando a resposta ao

103 gerente. Parte do processamento realizado pela classe IpInstrument pode ser visto no quadro 05. Quadro 05: Parte do processamento de requisies do grupo ip da Mib-2
/** * Trata o pedido SNMP Set Request para a varivel ipForwarding * @param valor - O valor Integer a ser configurado * @throws AgentException em caso de erro */ public synchronized void setIpForwarding(Integer value) throws AgentException{ if(value == null){ throw new AgentException("", CommonUtils.WRONGVALUE); } if(!((value.intValue() == 1)||(value.intValue() == 2))){ throw new AgentException("", CommonUtils.WRONGVALUE); } ipForwarding = value; } /** * Trata o p edido SNMP Get Request para a varivel ipDefaultTTL */ public Integer getIpDefaultTTL() throws AgentException{ int Val_ipStat = 0; Val_ipStat = IpStat.getIpStatField(1); Integer ipDefaultTTL = new Integer(Val_ipStat); return ipDefaultTTL; }

J por parte do gerente o principal mtodo o mtodo setValues() (quadro 06) que obtm os valores das variveis SNMPv3 da tela do gerente e as utiliza para montar PDUs GET-Request utilizadas para realizar o polling sobre as variveis solicitadas pelo usurio, alm de realizar a descoberta e sincronizao com o agente salvando as informaes em um arquivo para uso em sesses futuras com o mesmo agente.

104 Quadro 06: Mtodo setValues() do arquivo GerenteDesempenhoIp.java

public void setValues() { // Configurar os Oids da sesso. String Oids = tfOid.getText(); StringTokenizer stoken = new StringTokenizer(Oids, " "); int num = stoken.countTokens(); grafLinhas.setTitle("Plotando "+num +" OIDs"); grafLinhas.setXlabel ("Tempo em segundos"); grafLinhas.setYlabel ("Nmero de pacotes"); String listaOids[] = new String[num]; for(int i=0; i<num; i++) { // Obtm os Oids da caixa de texto. listaOids[i] = stoken.nextToken(); } // Transfere os OIDs para o objeto poller gerente. poller.setObjectIDList(listaOids); // Configura o intervalo de polling. try { poller.setPollInterval( Integer.parseInt(tfIntervalo.getText()) ); } catch (NumberFormatException nfm) { JOptionPane.showMessageDialog( GerenteDesempenhoIp.this, "O valor do intervalo deve ser um nmero inteiro!", "Configurao", JOptionPane.ERROR_MESSAGE ); tfIntervalo.setText(String.valueOf(poller.getPollInterval())); } // Configura a verso. String ver = new String((String) comboVersao.getSelectedItem ()); if(ver.equalsIgnoreCase ("v1")) { poller.setSnmpVersion (poller.VERSION1); } else if (ver.equalsIgnoreCase ("v2")) {

105

poller.setSnmpVersion (poller.VERSION2C); } else if (ver.equalsIgnoreCase ("v3")) { poller.setSnmpVersion (poller.VERSION3); } // Configura o host. poller.setTargetHost( tfHost.getText() ); // Configura a porta. poller.setTargetPort (Integer.parseInt ((tfPorta.getText ()))); // Caso seja a verso 3 do SNMP faa: if(ver.equalsIgnoreCase ("v3")) { // Configura o usurio que far as requisies. poller.setPrincipal (tfUsuario.getText ()); // Configura o nvel de segurana. String NivSeg = new String((String) comboNivSeg.getSelectedItem ()); if(NivSeg.equalsIgnoreCase ("noAuth,noPriv")) { poller.setSecurityLevel(poller.NO_AUTH_NO_PRIV); } else if (NivSeg.equalsIgnoreCase ("Auth,noPriv")) { poller.setSecurityLevel(poller.AUTH_NO_PRIV); } else if (NivSeg.equalsIgnoreCase ("Auth,Priv")) { poller.setSecurityLevel(poller.AUTH_PRIV); } // Configura o protocolo de autenticao. String ProtAut = new String((String) comboAut.getSelectedItem ()); if(ProtAut.equalsIgnoreCase ("MD5")) {

106

} poller.setAuthProtocol(poller.MD5_AUTH);

else if (ProtAut.equalsIgnoreCase ("SHA"))

{ poller.setAuthProtocol(poller.SHA_AUTH); } // Configura a senha para autenticao. poller.setAuthPassword(tfSenhaAut.getText()); // Configura a senha para privacidade. poller.setPrivPassword(tfSenhaPriv.getText ()); // Configura o contexto. poller.setContextName (tfContexto.getText ()); // Configura o IDContexto. poller.setContextID (tfIDContexto.getText ()); // Cria as tabelas USM e VACM necessrias e faz a sincronizao. int criar = poller.create_v3_tables (); // Testar se tudo funcionou. if(criar == 1) { JOptionPane.showMessageDialog( GerenteDesempenhoIp.this, "Inicializao e Sincronizao Efetuada!", "Configurao V3", JOptionPane.INFORMATION_MESSAGE ); // Salvar as informaes em disco para uso futuro (nao necessrio). SnmpAPI api = new SnmpAPI(); api.setSerializeFileName ("ConfV3.ser"); try { if(api.serialize() == false) { JOptionPane.showMessageDialog( GerenteDesempenhoIp.this, "Erro ao salvar as informaes no arquivo!", "Configurao V3", JOptionPane.ERROR_MESSAGE ); } } catch (SnmpException se) { } }

107

{ else JOptionPane.showMessageDialog( GerenteDesempenhoIp.this, "Inicializao e/ou Sincronizao Falhou!", "Configurao V3", JOptionPane.INFORMATION_MESSAGE ); } // fim criar. } // fim poller.getVersion==3.

else

{ poller.setCommunity(tfComunidade.getText()); } // Exibe os resultados no grafico. grafLinhas.setLineLabels(Oids); // E inicia o polling. grafLinhas.restartPolling() ; // O envio e recepo das mensagens controlado automaticamente // pela API, no necessrio fazer mais nada. }

A seguir ser discutida a operacionalidade do prottipo.

6.3.2

OPERACIONALIDADE DA IMPLEMENTAO
Para a execuo do prottipo preciso tomar as seguintes medidas: a) no(s) equipamento(s) onde ser instalado/executado o agente e o gerente, esteja instalada a Java Virtual Machine JVM verso 1.4 ou superior; b) configurar o arquivo java.security presente em C:\Program

files\Java \j2re1.x.x\lib\security acrescentando-se a seguinte linha ao mesmo: security.provider.2=com.sun.crypto.provider.SunJCE; c) copiar todos os arquivos existentes no diretrio Agente para um diretrio qualquer no equipamento onde ser executada a aplicao agente e todos os

108 arquivos do diretrio Gerente para um diretrio qualquer no equipamento onde ser executada a aplicao gerente; d) copiar o arquivo IpStatProj.dll presente no diretrio IpStatNativo para o diretrio System do sistema operacional; e) configurar as variveis de ambiente Java executando o arquivo de configurao ConfJavaVars.bat presente no diretrio bin das aplicaes agente e gerente; f) executar as aplicaes agente e gerente atravs da execuo do arquivo run.bat presente no diretrio bin das aplicaes agente e gerente. Estes passos so necessrios porque o prottipo foi desenvolvido utilizando a linguagem Java, algoritmos de privacidade e um mtodo nativo (JNI) escrito em Java. No caso do agente possvel execut -lo usando-se opes especiais de inicializao, executando-se a aplicao AgenteIp presente no diretrio bin do agente, diretamente no prompt de comando do Microsoft Disk Operating System - MS-DOS. A seguir so exibidos todos os parmetros adicionais que podem ser usados na inicializao do agente: java AgenteIp [-d Debug_Level(0-6)] [-m arquivo_MIB] [-p porta] [-v versao] [-t TrapSendingPort]

109
Figura 29 - Tela Inicial da aplicao gerente

onde: -d [nvel depurao (0-6)] indica o nvel de depurao a ser utilizado pelo agente; -m [arquivo] indica o arquivo de definio MIB a ser utilizado pelo agente; -p [porta] indica a porta na qual o agente ir aguardar por requisies; -v [verso] indica qual verso SNMP o agente ir suportar; -t [porta de envio de trap] indica a porta que o agente ir utilizar para enviar traps . No caso do agente, um exemplo de inicializao seria o seguinte: java AgenteIp p 161 m AKIP-MIB No exemplo acima o agente ser inicializado na porta 161 usando a MIB AKIP -MIB. Esta MIB contm a definio de todos os objetos escalares do grupo ip da Mib-2 Ela

110 utilizada no prottipo tanto pelo agente quanto pelo gerente para realizar o gerenciamento de desempenho. A tela inicial do gerente, que surge logo aps a execuo do arquivo run.bat mostrada na figura 29. Nesta tela possvel configurar todas as opes utilizadas pelo SNMPv3. Primeiramente deve-se carregar a MIB que a aplicao gerente utilizar realizandose o seguinte procedimento: a) clicar no boto Procurar MIB...; b) escolher um arquivo de definio MIB que esteja presente no equipamento onde o agente se encontra. No caso do prottipo preciso carregar a MIB AKIP -MIB presente no diretrio mibs da aplicao gerente; c) clicar no boto Carregar MIB. Se houverem erros de sintaxe no arquivo MIB carregado ser exibida uma mensagem de erro no prompt do MS-DOS. Em seguida o usurio deve preencher os campos SNMPv3 com as informaes necessrias para se conectar ao agente com o qual deseja se comunicar. Aps preencher os campos o usurio deve clicar no boto Configurar gerente. Se as informaes estiverem corretas e o processo de descoberta e sincronizao com o agente ocorrerem com sucesso, ser exibida uma mensagem informando que tudo correu bem e que possvel a partir de a gora consultar o agente, seno, uma mensagem de erro ser exibida informando o motivo do erro. Agora o usurio deve preencher o campo OID especificando as variveis do grupo ip que deseja consultar digitando a parte final de seu ObjectID ou OID (a aplica o gerente preenche internamente a parte inicial do OID .1.3.6.2.1) possvel consultar mais de um OID ao mesmo tempo. Para isso basta preencher o campo OID separando as variveis com um espao simples. tambm possvel utilizar a aplicao gerente para consultar agentes SNMPv1 e SNMPv2. Para tal, basta preencher o campo Comunidade e fornecer o(s) OID(s) que deseja consultar.

111 A aplicao gerente tambm pode consultar outras variveis alm daquelas existentes na MIB AKIP-MIB. Para poder consultar outras variveis da Mib -2 basta carregar outra MIB contendo a definio de variveis de outros grupos da Mib-2 tais como if, system, etc. A seguir ser exibido um exemplo do uso do sistema no monitoramento de um elemento de rede (PC) do laboratrio Protem da Universidade Regional de Blumenau durante o perodo de 30 minutos. As informaes de gerenciamento de desempenho coletadas foram as seguintes: ipInDiscards , ipOutDiscards, ipInDelivers e ipInReceives.
Figura 30 - Medio inicial

Foram realizadas duas coletas em tempos diferentes. A primeira foi realizada com intervalos de 20 segundos entre cada polling (fig. 30). A segunda coleta foi realizada com intervalos de 15 segundos entra cada polling (fig. 31) . Os resultados obtidos sero discutidos e analisados no prximo tpico.

112
Figura 31 - Medio final

6.4 RESULTADOS E DISCUSSO

possvel perceber pelos grficos exibidos nas figuras 30 e 31 que na primeira coleta o equipamento estava utilizando muitos pacotes IP para a transmisso e recepo de dados. Na segunda coleta entretanto, percebe -se que o nmero de pacotes sendo transmitidos e recebidos diminuiu, indicando que o sistema operacional aumentou o tamanho dos pacotes IP, o que permitiu o aumento do desempenho da rede. Resultado este que pode ser observado ao se observar a taxa de transmisso de um arquivo sendo descarregado no equipamento analisado. Durante a primeira coleta a taxa de transmisso era de aproximadamente 15Kb por segundo sendo que no momento da segunda coleta esta taxa j estava em 32Kb por segundo. Seria interessante poder testar o prottipo em um servidor Web, pois neste, h um grande nmero de pacotes IP sendo processados, sendo que neste c aso, analisar o trfego gerado pelos pacotes IP bem como o nmero de pacotes sendo descartados devido a erros ou falta de espao em buffer seria essencial para um administrador de rede poder tomar decises baseadas nas informaes disponibilizadas pelo gerente do prottipo.

113

7 CONCLUSES
Atualmente, h um grande crescimento no uso das redes de computadores, e devido ao grande nmero de equipamentos de rede existentes atualmente e por estes equipamentos possurem caractersticas heterogneas e por serem produzidos por vrios fabricantes diferentes, a possibilidade de que estes equipamentos venham a falhar ou que algum destes equipamentos possa comprometer o desempenho desta rede (sua qualidade de servio) tambm maior. Neste cenrio, essencial o uso de ferramentas automatizadas que possam gerenciar remotamente estes equipamentos. O SNMPv3 torna possvel realizar esse gerenciamento de forma segura e eficaz, fornecendo funcionalidades para obteno de segurana e controle de acesso via polticas de acesso. O nico objetivo que no foi completamente atingido foi o de gerenciar o desempenho real de uma rede de computadores. Isto aconteceu devido falta de tempo hbil para realizar um estudo mais detalhado das funes de gerenciamento de desempenho existentes, al m da pouca literatura existente at mesmo na Internet sobre o assunto. O uso dos diagramas de seqncia, se mostrou parcialmente inadequado para representar o processamento e a troca de mensagens entre o agente e o gerente, principalmente por no permitir representar situaes que ocorram em paralelo e situaes onde existe mais de um caminho possvel a ser seguido. Para resolver este problema sugere-se a utilizao de diagramas de estado e de atividades que tambm fazem parte da UML. As ferramentas utilizadas na implementao do prottipo se mostraram totalmente adequadas para o seu desenvolvimento. importante destacar que a utilizao da API SNMPv3 da AdventNet sem dvida facilita e possibilita o rpido desenvolvimento de aplicaes para o gerenciamento de redes utilizando o protocolo SNMP, alm de disponibilizar um suporte rpido e gratuito aos desenvolvedores que utilizam a sua API. A utilizao do SNMP como uma plataforma para realizar o gerenciamento de redes de computadores prtica e fcil, entretanto, a terceira verso desta plataforma SNMPv3 j no mais to simples, pois a adio de privacidade e controle de acesso adiciona tambm, complexidade.

114 Uma das limitaes do prottipo o fato de o gerente no realizar nenhum processamento ou tomada de deciso sobre os dados coletados, ou seja, apresentar alguma inteligncia. Novamente, em um sistema de gerncia de redes real, seria indispensvel que a aplicao gerente realizasse pelo menos um processamento bruto dos dados (um clculo estatstico, o uso de alguma funo de comparao de dados, etc), ou algo como avisar o administrador da rede sempre que certos limiares fossem atingidos. Outra limitao a de que apesar do prottipo ter sido desenvolvido em Java, parte da portabilidade (caracterstica comum e importante desta linguagem) foi perdida, devido ao uso de um mtodo nativo, sendo necessrio realizar adaptaes no presente prottipo para acessar as informaes de desempenho em outras plataformas. Isto ocorreu, porque na poca do desenvolvimento da proposta no se descobriu nenhum equipamento de rede que j disponibiliza, e por conseqncia, implementa as novas funcionalidades SNMPv3 sendo necessrio ento definir na proposta o desenvolvimento de todo um sistema de gerncia (agente e gerente) ao nvel de prottipo. Pouco antes do trmino do presente trabalho entretanto, descobriu-se que praticamente todos os roteadores da empresa Cisco j possuam em seus equipamentos, a partir da verso 12 de seu sistema operacional, suporte via configurao de agentes Cisco, s novas funcionalidades do SNMPv3. Como contribuies do presente trabalho pode -se citar as seguintes: a) um estudo simplificado da estrutura SNMPv3, seus elementos, caractersticas e suas novas funcionalidades; b) a criao de um prottipo simples mas funcional, implementando na prtica as novas funcionalidades do SNMPv3; c) um trabalho que pode ser estendido, podendo servir como base para novos trabalhos conforme as sugestes para extenso citadas na prxima sesso; d) um estudo da viabilidade e praticidade no uso da API SNMPv3 da empresa AdventNet no desenvolvimento de aplicaes para o gerenciamento de redes de computadores utilizando o SNMPv3; e) a criao de um gerente SNMPv3, que pode vir a ser utilizado com outros softwares de gerncia de redes de computadores baseados no SNMPv3 para a implantao da gerncia de desempenho;

115 f) a criao de um agente SNMPv3 para o gerenciamento de desempenho de uma rede de computadores, que implementa parte do grupo ip da Mib-2.

7.1 EXTENSES
Como sugestes para trabalhos futuros pode-se citar as seguintes: a) implementar alguma inteligncia no gerente e no agente a fim de automatizar o processo de deciso quando do surgimento de problemas; b) estender o agente para que ele possa tratar mensagens Notification e implementar o mecanismo de Trap Forwarding mecanismo este no implementado no presente trabalho; c) estender o agente para que ele possa fornecer suporte a todos os objetos presentes na MIB-2, aumentando sua escalabilidade; d) testar a extensibilidade do SNMPv3 atravs da implementao de novos mdulos para realizar as tarefas de autenticao, privacidade e controle de acesso; e) testar a modularidade do SNMPv3 atravs da utilizao de novos algoritmos de criptografia e autenticao em substituio queles definidos pelo SNMPv3 alm da definio de novas MIBs para criao de polticas de acesso especializadas; f) realizar testes de desempenho para medir a utilizao de largura de banda e processamento utilizados pelo SNMPv3 em comparao com as verses anteriores a fim de medir o custo overhead e perda de desempenho ocasionada pelas novas primitivas de autenticao e segurana do SNMPv3.

116

REFERNCIAS BIBLIOGRFICAS
ADVENTNET Inc. AdventNet SNMP API 3.3 documentation, Pleasanton, [2001]. Disponvel em: <http://www.adventnet.com/products/snmp/help.html>. Acesso em: 14 nov. 2002. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usurio. 5. ed. Rio de Janeiro: Campus, 2000. 472p. CARVALHO, Tereza Cristina Melo de Brito. Gerenciamento de redes: uma abordagem de sistemas abertos. Sao Paulo: Makron Books, 1993. 364p. DEITEL, Harvey M, DEITEL, Paul J, SANTRY, S. (Sean), et al.. Advanced Java 2 platform : how to program. Upper Saddle River : Prentice Hall, 2001. 1811p. FLANAGAN, David. Java in a nutshell: a desktop quick reference. 3.ed. Beijing: OReilly, 1999. 649p. FURLAN, Jose Davi. Modelagem de objetos atravs da UML-The Unifield Modeling Language . So Paulo: Makron Books do Brasil, 1998. 329p. HEGERING, Heinz-Gerd; ABECK, Sebastian. Integrated network and system

management. Wokingham: Addison-Wesley, 1994. 491p. HORSTMANN, Cay S, CORNELL, Gary. Core Java 2 . So Paulo : Makron Books, 2001. RFC/STD/FYI/BCP Archives. Internet RFC/STD/FYI/BCP archives, [199-]. Disponvel em: < http://www.faqs.org/rfcs/>. Acesso em: 16 nov. 2002. KUROSE, James F.; ROSS, Keith W. Computer networking: a top-down approach featuring the Internet. Boston: Addison Wesley, 2001. 711p. LUCHESI, Claudio Leonardo; Introduo criptografia computacional. Campinas: Ed. Papirus/Unicamp, 1986.

117 LYNCH, Daniel C.; ROSE, Marshall T. Internet system handbook. Boston: Addison Wesley, 1993. MENEZES, A; OORSCHOT, P; VANSTONE, S. Handbook of applied cryptography. Canada: CRC Press, 1997. 780p. MINASI, Mark. Mastering Windows 2000 Server. 2.ed. San Francisco: Sybex, 2000. 1593p. RATIONAL Software Corporation. Rational software , Cupertino, [1995]. Disponvel em: <http://www.rational.com/support/documentation/>. Acesso em: 27 ago. 2002. ROSE, Marshall T. The simple book: an introduction to Internet management. 2. ed. Englewood Cliffs: Prentice-Hall, 1994. 456p. SCHNEIER, Bruce. Applied cryptography: protocols, algorithms, and source code in C. 2. ed. Canada: Wiley & Sons, 2001. 762p. SNMP International Research Inc. SNMPv3 white paper, New York, [2001?]. Disponvel em: <http://www.snmp.com/snmpv3/v3white.html>. Acesso em: 14 ago. 2002. STALLINGS, William. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. 3. ed. Boston: Addison Wesley, 2001. 628p. SUN. Java tutorial, Palo Alto, [199-]. Disponvel em: <http://docs.sun.com/>. Acesso em: 14 ago. 2002. TANENBAUM, Andrew S. Redes de computadores. 3. ed. Traduo nome do tradutor/a. Rio de Janeiro: Campus, 1997. W3C. Extensible Markup Language , Massachussets, [1996]. Disponvel em: < http://www.w3.org/XML/>. Acesso em: 16 nov. 2002. ZELTSERMAN, Dave. A practical guide to SNMPv3 and network management. Upper Saddler River: Prentice Hall, 1999. 337p.