CENTRO UNIVERSITÁRIO UNIVATES CURSO DE SISTEMAS DE INFORMAÇÃO PROJETO DE GERENCIAMENTO DE UNIDADES GEOGRAFICAMENTE DISTRIBUÍDAS A PARTIR DE UM NÓ CENTRAL Flávio André Johann Lajeado, dezembro de 2013 B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) Flávio André Johann PROJETO DE GERENCIAMENTO DE UNIDADES GEOGRAFICAMENTE DISTRIBUÍDAS A PARTIR DE UM NÓ CENTRAL Monografia apresentada na disciplina de Trabalho de Conclusão de Curso – Etapa II, do curso de Sistemas de Informação, do Centro Universitário UNIVATES, como parte da exigência para a obtenção do título de Bacharel em Sistemas de Informação. Orientador: Prof. Ms. Luis Antônio Schneiders Lajeado, dezembro de 2013 B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) Flávio André Johann PROJETO DE GERENCIAMENTO DE UNIDADES GEOGRAFICAMENTE DISTRIBUÍDAS A PARTIR DE UM NÓ CENTRAL A banca examinadora abaixo aprova a Monografia apresentada na disciplina de Trabalho de Conclusão de Curso – Etapa II, na linha de formação específica em Sistemas de Informação, do Centro Universitário Univates, como parte da exigência para a obtenção do grau de Bacharel em Sistemas de Informação: Prof. Ms. Luis Antônio Schneiders - orientador Centro Universitário UNIVATES. Prof. Esp. Edson Moacir Ahlert, UNIVATES Centro Universitário UNIVATES Prof. Ms. Marcus Vinícius Lazzari Centro Universitário UNIVATES Lajeado, 06 de dezembro de 2013 B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) DEDICATÓRIA Dedico... A Flávio Ardi Johann e Ritta Bottega Johann, meus pais e mestres desde o ínicio da minha existência, por tudo que me ensinaram e pelo apoio que sempre me deram para que fosse possível trilhar os caminhos de minha formação pessoal e profissional. Dedico também a minha namorada, Júlia Tresoldi, e a toda a sua família, pelo carinho, atenção, compreensão e ajuda nos momentos de dificuldade. Dedico esta obra também aos entusiastas e aficcionados pelo Zabbix, a Vinício Zanchettin, que despertou o meu interesse por este software, a Luciano Alves e toda a equipe da Unirede de Porto Alegre pelo tratamento diferenciado e excepcional treinamento prestado. A Eduardo Johann e toda a equipe da Costaneira, pelos ensinamentos diários e credibilidade disposta neste projeto. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) AGRADECIMENTOS Agradeço ao meu orientador, prof. Ms. Luís Antônio Schneiders pelo tempo dedicado para auxiliar-me na redação e organização desta monografia. Aos demais integrantes do corpo docente do CCTEC pelo excelente trabalho desempenhado ao longo dos anos, contribuindo não só para a formação acadêmica como também humanitária de seus discentes. A Ana Paula Ferreira Antunes pelo auxílio na edição final das imagens e a todos os meus amigos, companheiros e colegas por compartilharem comigo momentos inesquecíveis desta vida. Gratidão eterna! B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) RESUMO Com a expansão da Internet e da tecnologia, tornou-se imprescindível o uso de mecanismos para o controle e gerenciamento das infraestruturas de redes de computadores e dos sistemas que armazenam informações. Assim, essa monografia visa apresentar um projeto que permita controlar e monitorar ativos em unidades geograficamente distribuídas a partir de um nó central. Desse modo, estima-se que um administrador de redes possa identificar e prevenir possíveis pontos críticos de falhas na rede de forma proativa, tendo um maior controle sobre os ativos monitorados, podendo dimensionar melhor as tecnologias utilizadas e planejar futuras expansões, caso seja necessário. Para tanto, foi proposto o estudo da infraestrutura de redes na empresa Costaneira S/A, com sede na cidade de Lajeado- RS, e filiais distribuídas em todo o Estado. A metodologia desse estudo envolveu conceituar os princípios e protocolos utilizados para o gerenciamento de redes, descrever o cenário da empresa sugerida, analisar e comparar algumas das soluções de software livre mais utilizadas nessa área de pesquisa, implantar a solução que melhor se adaptou ao ambiente da empresa, avaliar e discutir os resultados obtidos, propondo melhorias. Palavras-chave: Gerenciamento de redes. Protocolos de gerenciamento de redes. Software de gerenciamento de redes. Zabbix. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) ABSTRACT With the expansion of Internet and technology, it became essential to use mechanisms for the control and management of the infrastructure of computer networks and systems that store information. Therefore, this monograph aims to present a project that allows control and monitor assets in geographically units distributed from a central node. Because of that, it is estimated that a network administrator can identify and prevent potential critical points of network failures proactively taking greater control over the assets monitored and can dimension better the technologies used and to plan future expansion if needed. Therefore, it was proposed to study the network infrastructure in Costaneira S/A company, with headquarters in Lajeado – RS and branches distributed throughout the state. The methodology of this study involved conceptualizing the principles and protocols used for network management, describe the scenario of the suggested company, analyze and compare some of the open source solutions commonly used in this area of search, deploy the solution best adapted to the environment company, evaluate and discuss the results and propose improvements. Keywords: Network management. Network management protocols. Network management software. Zabbix. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) LISTA DE FIGURAS Figura 1 - Modelo de gerenciamento de redes .......................................................... 24 Figura 2 - Áreas-chave de um gerenciamento de redes .......................................... 25 Figura 3 - Modelo de gerenciamento centralizado .................................................... 32 Figura 4 - Modelo de gerenciamento distribuído. ...................................................... 32 Figura 5 - Interação entre o gerente e um agente ..................................................... 35 Figura 6 - Árvore MIB ................................................................................................ 36 Figura 7 - Configurações do serviço SNMP em um ambiente Windows 7. ............... 38 Figura 8 - Arquitetura de gerenciamento de redes utilizando o protocolo SNMP. ..... 39 Figura 9 - Arquitetura de gerenciamento SNMP ........................................................ 42 Figura 10 - Formato SNMP ....................................................................................... 43 Figura 11 - Formato da mensagem de Requisições do SNMP. ................................ 46 Figura 12 - Formato da mensagem de resposta. ...................................................... 46 Figura 13 - Formato de mensagem de Trap no SNMPv1. ......................................... 47 Figura 14 - Sequência do PDU SNMP. ..................................................................... 48 Figura 15 - Arquitetura SNMPv2. .............................................................................. 50 Figura 16 - Formato de mensagem PDU do SNMPv2. ............................................. 51 Figura 17 - Evolução do SNMP. ................................................................................ 54 Figura 18 - Arquitetura de uma entidade SNMPv3 .................................................... 55 Figura 19 - Formato de mensagem SNMPv3 ............................................................ 56 Figura 20 - Imagem de um gráfico gerado pelo MRTG. ............................................ 60 Figura 21 - Imagem de um gráfico gerado pelo RRDTool ......................................... 61 Figura 22 - Informações de host no NTop ................................................................. 62 Figura 23 - Tela do software Nagios ......................................................................... 64 B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) Figura 24 - Tela de gráficos do software Cacti .......................................................... 65 Figura 25 - Interface do OpenNMS ........................................................................... 66 Figura 26 - Interface do Pandora FMS ...................................................................... 67 Figura 27 - Interface do Zabbix ................................................................................. 69 Figura 28 - Interface do Zenoss ................................................................................ 70 Figura 29 - Cenário da administração central da Costaneira .................................... 76 Figura 30 - Cenário das filiais da Costaneira ............................................................ 77 Figura 31 - Tipos de abordagens do Zabbix .............................................................. 80 Figura 32 - Diagrama de operação do Zabbix utilizando proxies .............................. 81 Figura 33 - Componentes do Zabbix Server ............................................................. 82 Figura 34 - Fluxograma de operação do Zabbix........................................................ 83 Figura 35 - Modelo proposto de implantação do Zabbix ........................................... 85 Figura 36 - Tela de templates personalizados........................................................... 88 Figura 37 - Regra de auto busca para descoberta de interfaces de rede ................. 89 Figura 38 - Monitoramento JMX na empresa Costaneira .......................................... 90 Figura 39 - Monitoramento do banco de dados PostgreSQL .................................... 91 Figura 40 - Tela de ações do Zabbix ......................................................................... 92 Figura 41 - Tela de status do Zabbix ......................................................................... 94 Figura 42 - Gráfico de porcentagem de processos de coleta de dados ocupados no Zabbix ....................................................................................................................... 97 Figura 43 - Fila de itens a serem atualizados por proxy usando configurações padrão .................................................................................................................................. 97 Figura 44 - Fila de itens a serem atualizados por proxy após ajustes de configurações ............................................................................................................ 98 Figura 45 - Gráfico de performance do servidor Zabbix ............................................ 98 Figura 46 - Comparativo de tráfego de rede na interface do Zabbix antes e depois de sua implantação ........................................................................................................ 99 Figura 47 - Comparativo de tráfego de rede na interface da VPN na administração central antes e depois da implantação do Zabbix ................................................... 100 Figura 48 - Comparativo de tráfego de rede antes e depois da implantação do Zabbix na interface do Zabbix Proxy em uma filial remota .................................................. 100 Figura 49 - Comparativo de tráfego de rede antes e depois da implantação do Zabbix na interface da VPN em uma filial remota ............................................................... 101 Figura 50 - Consumo de CPU e memória do Zabbix ............................................... 102 B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) Figura 51 - Consumo de CPU e memória do Zabbix Prox. ..................................... 102 Figura 52 - Consumo de CPU do servidor Zabbix sem monitoramento x com monitoramento ........................................................................................................ 103 Figura 53 - Consumo de CPU do Zabbix Proxy sem monitoramento x com monitoramento ........................................................................................................ 104 Figura 54 - Gráfico de tráfego de rede do link ADSL de uma filial remota .............. 105 Figura 55 - Tela contendo gráficos de tráfego de rede em todas as interfaces de um servidor ................................................................................................................... 105 Figura 56 - Mapa contendo elementos de um grupo de host .................................. 106 B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) LISTA DE QUADROS Quadro 1 - Definição e objetivos das técnicas de polling e event-reporting. ............. 29 Quadro 2 - Descrição dos controles de segurança e configuração. .......................... 29 Quadro 3 - Tipos de objetos da MIB. ......................................................................... 36 Quadro 4 - Controles suportados de uma MIB. ......................................................... 37 Quadro 5 - Mensagens SNMP .................................................................................. 43 Quadro 6 - Tipos e descrições de PDUs ................................................................... 51 Quadro 7 - Códigos de erros do SNMPv2 ................................................................. 52 Quadro 8 - Componentes do protocolo SNMPv3 ...................................................... 54 Quadro 9 - Campos utilizados em uma mensagem SNMPv3 ................................... 56 Quadro 10 - Comparativo entre softwares de Gerenciamento .................................. 71 Quadro 11 - Informações dos links na administração da Costaneira ........................ 74 Quadro 12 - Informações dos links nas filiais da Costaneira ..................................... 77 Quadro 13 - Equipamentos gerenciados x risco ao negócio ..................................... 78 Quadro 14 - Equipamentos a serem monitorados ..................................................... 79 Quadro 15 - Comparativo entre monitoramento em node e monitoramento baseado em proxy do Zabbix ................................................................................................... 80 Quadro 16 - Parâmetros alterados no arquivo de configuração do Zabbix Server .... 86 Quadro 17 - Parâmetros alterados no arquivo de configuração do Zabbix Proxy ..... 87 Quadro 18 - Parâmetros alterados no arquivo de configuração dos agentes Zabbix 87 Quadro 19 - Fórmula para estimar o espaço em disco do Zabbix ............................. 94 Quadro 21 - Comparativo de ativos e serviços monitorados antes e depois da implantação do Zabbix ............................................................................................ 107 B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) LISTA DE ABREVIATURAS ASN.1 Abstract Syntax Notation One CMOT Common Management Information Protocol Over Tcp/IP CPU Central Processing Unit GPL General Public License HMP Host Monitoring Protocol HTML HyperText Markup Language IP Internet Protocol IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 ISO International Organization for Standarization JMX Java Management Extensions JSON Javascript Object Notation LAN Local Area Network LDAP Lightweight Directory Access Protocol MIB Management Information Base B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) MRTG Multi Router Traffic Grapher NMP Network Management Protocol OID Object Identifier OSI Open Systems Interconnection PDU Protocol Data Unit RFC Request for Comments RMON Remote Network Monitoring RRDTOOL Round Robin Database Tool ICMP Internet Control Message Protocol SLA Service-Level Agreement SGMP Simple Gateway Monitoring Protocol SMI Structure of Management Information SNMP Simple Network Management Protocol SMS Short Message Service TI Tecnologia da Informação TCP Transmission Control Protocol UDP User Datagram Protocol USM User-based Security Model VACM View-based Access Control Mode VPN Virtual Private Network XMPP Extensible Messaging and Presence Protocol B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) SUMÁRIO 1 INTRODUÇÃO ....................................................................................................... 17 1.1 Motivação ........................................................................................................... 19 1.2 Objetivos ............................................................................................................ 21 1.2.1 Objetivos Gerais ............................................................................................. 21 1.2.2 Objetivos Específicos .................................................................................... 21 1.3 Descrição dos Capítulos ................................................................................... 22 2 CONCEITOS BÁSICOS DE GERÊNCIA DE REDES ............................................ 23 2.1 A importância do gerenciamento de redes ..................................................... 23 2.2 Áreas de gerenciamento ................................................................................... 25 2.2.1 Gerenciamento de Configuração .................................................................. 25 2.2.2 Gerenciamento de Contabilidade ................................................................. 26 2.2.3 Gerenciamento de Desempenho ................................................................... 26 2.2.4 Gerenciamento de Falhas .............................................................................. 26 2.2.5 Gerenciamento de Segurança ....................................................................... 27 2.3 Monitoramento e controle da rede ................................................................... 28 2.3.1 Monitoramento ............................................................................................... 28 2.3.2 Controle de Rede ............................................................................................ 29 2.4 Arquitetura do Gerenciamento de Redes ........................................................ 30 2.4.1 Estação de gerenciamento ............................................................................ 30 2.4.1.1 Gerenciamento centralizado ...................................................................... 31 2.4.1.2 Gerenciamento distribuído ......................................................................... 32 2.4.2 Agentes coletores .......................................................................................... 33 2.4.3 Management Information Base (MIB) ........................................................... 34 2.4.3.1 Tipos de objetos da MIB ............................................................................. 36 2.4.3.2 Controle de acesso aos valores da MIB .................................................... 37 3 PROTOCOLO SNMP ............................................................................................. 39 3.1 Structure of Management Information (SMI) ................................................... 40 3.2 Protocolo SNMPv1 ............................................................................................ 41 3.2.1 Arquitetura do protocolo SNMPv1 ................................................................ 41 3.2.2 Formato da mensagem SNMPv1 ................................................................... 43 3.2.3 Transmissão de uma mensagem SNMPv1 ................................................... 44 B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 3.2.4 Recepção de uma mensagem SNMPv1 ........................................................ 44 3.2.5 Variable bindings do protocolo SNMPv1 ..................................................... 45 3.2.6 GetRequest PDU do protocolo SNMPv1 ....................................................... 45 3.2.7 GetNextRequest PDU do protocolo SNMPv1 ............................................... 46 3.2.8 SetRequest PDU do protocolo SNMPv1 ....................................................... 47 3.2.9 Trap PDU do protocolo SNMPv1 ................................................................... 47 3.2.10 Limitações do protocolo SNMPv1............................................................... 48 3.3 Protocolo SNMPv2 ............................................................................................ 49 3.3.1 Arquitetura do protocolo SNMPv2 ................................................................ 49 3.3.2 Formato da mensagem do protocolo SNMPv2 ............................................ 51 3.3.3 Limitações do protocolo SNMPv2 ................................................................ 53 3.4 Protocolo SNMPv3 ............................................................................................ 53 3.4.1 Arquitetura do protocolo SNMPv3 ................................................................ 54 3.4.2 Formato da mensagem do protocolo SNMPv3 ............................................ 55 3.4.3 Segurança e controle de acesso do protocolo SNMPv3 ............................. 57 4 FERRAMENTAS DE GERENCIAMENTO E MONITORAMENTO DE REDES ..... 59 4.1 MRTG .................................................................................................................. 60 4.2 RRDTool ............................................................................................................. 60 4.3 NTOP .................................................................................................................. 61 4.4 Nagios ................................................................................................................ 62 4.5 Cacti.................................................................................................................... 65 4.6 OpenNMS ........................................................................................................... 66 4.7 Pandora FMS ..................................................................................................... 67 4.8 Zabbix ................................................................................................................. 67 4.9 Zenoss ................................................................................................................ 69 4.10 Comparativo entre as ferramentas de gerenciamento ................................. 71 4.11 Análise dos resultados obtidos ..................................................................... 71 5 PROPOSTA ........................................................................................................... 73 5.1 Caracterização da empresa .............................................................................. 73 5.1.1 Infraestrutura de TI ......................................................................................... 74 5.1.2 Administração Central ................................................................................... 74 5.1.3 Centro de Distribuição ................................................................................... 76 5.1.4 Filiais ............................................................................................................... 76 5.1.5 Análise do ambiente....................................................................................... 78 5.2 Modelo de implantação do Zabbix ................................................................... 79 5.3 Componentes do Zabbix ................................................................................... 82 5.4 Fluxo de operação do Zabbix ........................................................................... 83 5.5 Cenário proposto .............................................................................................. 84 5.6 Uso de templates personalizados .................................................................... 88 5.7 Uso de regras de auto busca ........................................................................... 89 5.8 Monitoramento de aplicações Java ................................................................. 90 5.9 Monitoramento do banco de dados PostgreSQL ........................................... 91 5.10 Monitoramento proativo ................................................................................. 92 6 RESULTADOS OBTIDOS ..................................................................................... 93 6.1 Equipamentos monitorados ............................................................................. 93 B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 6.2 Cálculo para estimativa do banco de dados Zabbix ...................................... 94 6.3 Performance ...................................................................................................... 96 6.4 Consumo de banda de rede ............................................................................. 98 6.5 Consumo de CPU e memória ......................................................................... 101 6.7 Formas de análise dos itens coletados ......................................................... 105 6.8 Comparativo de ativos monitorados antes e depois da implantação do Zabbix ..................................................................................................................... 106 7 CONSIDERAÇÕES FINAIS ................................................................................. 108 7.1 Trabalhos Futuros ........................................................................................... 110 REFERÊNCIAS ....................................................................................................... 111 B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 17 1 INTRODUÇÃO O surgimento das redes de computadores, em meados da década de 60, marcou o início de uma era digital, na qual a informação tornaria-se um bem intangível extremamente valioso não somente para a competitividade econômica, como também para aspectos sociais, culturais, governamentais, entre outros. Neste período inicial, as redes de computadores eram limitadas apenas para o uso militar ou universidades. Pelo fato de serem relativamente simples e pequenas, com poucos nós e distribuídas localmente, a necessidade de gerenciamento era mínima, podendo ser efetuada de forma centralizada. Alguns protocolos de gerenciamento foram inicialmente implementados na década de 70, como o Internet Control Message Protocol (ICMP), que possibilitava a troca de mensagens entre roteadores e hosts, permitindo que houvesse uma interação entre ambas as partes, a fim de monitorar o status da comunicação por meio de mensagens de echo/echo reply (STALLINGS, 1999). A partir da década de 80, com a expansão do Transmission Control Protocol over Internet Protocol(TCP/IP), as redes de computadores passaram a ser mais difundidas, e, com isso, aumentou a necessidade de mecanismos para o gerenciamento das mesmas. Alguns protocolos surgiram nessa época como o Host Monitoring Protocol (HMP), Simple Gateway Monitoring Protocol (SGMP), que mais tarde foi substituído pelo Simple Network Management Protocol (SNMP) e o Common Management Information Protocol Over Tcp/IP (CMOT) (STALLINGS, 1999). B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 18 Desde então, as redes de computadores tornaram-se extremamente complexas. É possível interligar dispositivos dos mais diversos tipos e funções como smartphones, câmeras de vigilância, impressoras, notebooks, servidores, entre outros, não apenas limitando-os em áreas locais, como também geograficamente distribuídas, inclusive entre continentes. Alguns aspectos comuns que afetam a infraestrutura de Tecnologia da Informação (TI) nas organizações e podem acarretar algum tipo de perda, seja financeira ou de informação, são a contaminação por vírus, a indisponibilidade de algum serviço como o acesso à Internet, hardware com defeito, queda de luz, entre outros. Com isso, cinco áreas de gerência de redes foram definidas pela International Organization for Standardization/International Electrotechnical Comission (ISO/IEC 10040,1998), são elas: a) gerenciamento de configuração; b) gerenciamento de contabilidade; c) gerenciamento de desempenho; d) gerenciamento de falhas; e) gerenciamento de segurança. Essas áreas provêm medidas que devem ser tomadas para um melhor gerenciamento da área de redes, favorecendo, assim, a qualidade e disponibilidade dos serviços aos quais estão relacionados. Ao passo que uma rede se torna geograficamente distante, sua complexidade em relação à infraestrutura e o gerenciamento aumenta de tal forma que é imprescindível utilizar algum mecanismo automatizado para auxiliar no seu controle e monitoramento. É nesse ponto que muitas soluções em forma de software surgiram e muitas delas utilizam características semelhantes que visam, no mínimo: a) monitoramento distribuído com um gerenciamento centralizado: Toda a informação de um host monitorado é coletada através de um software agente B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 19 (remoto, local ou móvel) e armazenada em uma estação de gerenciamento, sendo possível visualizar as informações através de um browser, utilizando o modelo Web-based; b) proatividade: os agentes monitores devem ter a capacidade de prever situações adversas baseadas em eventos, estatísticas, entre outros, e, através disso, executarem alguma ação visando alertar, amenizar e/ou corrigir o problema; c) eficiência e disponibilidade: a arquitetura de um software de gerenciamento deve otimizar ao máximo o uso dos recursos computacionais, de forma que o mesmo possa garantir disponibilidade adequada aos serviços geridos com o máximo de eficiência; d) integração e customização: capacidade de integração com outros serviços e possibilidade de customizar novas funcionalidades; e) segurança: controle de acesso e permissões para executar determinadas ações. Logo, busca-se atingir cada vez mais níveis de maturidade quanto à governança de TI, melhorando o serviço prestado, garantindo a disponibilidade, aumentando a eficiência e alinhando os requisitos de TI com os requisitos do negócio, agregando valor ao mesmo. 1.1 Motivação Para quem trabalha na área de administração de redes ou entende da importância de manter os ativos em condições de propiciar uma disponibilidade de serviço aos seus utilizadores, sabe dos riscos expostos ao negócio quando ele está defeituoso ou indisponível. Na empresa Costaneira, a infraestrutura de redes de computadores está distribuída entre nove filiais, mais o prédio da administração e o centro de distribuição. As ferramentas utilizadas para o gerenciamento e monitoramento da B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 20 rede mostram-se ineficientes, pois atendem a uma pequena parcela do que poderia ser gerenciado. Dessa forma, quando algum problema surge, muitas vezes sua identificação demora a ser detectada e consequentemente corrigida, acarretando em problemas de indisponibilidade de serviços que são essenciais para a empresa. Por causa de limitações tecnológicas na época em que foi iniciado o desenvolvimento do sistema de gestão interno da empresa, em meados de 2005, houve a necessidade de utilizar servidores fisicamente alocados em cada uma das filiais, contendo uma cópia do banco de dados principal que, através de um sistema complexo de replicação, pudesse garantir a consistência das informações ali contidas para todas as empresas afiliadas. Portanto, a disponibilidade do link de Internet na empresa é imprescindível para que este processo funcione de forma satisfatória, evitando possíveis problemas de inconsistência e perda de dados. Vale ressaltar, também, que diversos setores da empresa são prejudicados quando não é possível acessar a Internet - como a área de vendas - por não poderem emitir notas fiscais eletrônicas, solicitar liberações de crédito, entre outros fatores. Outra questão que merece relevância é o gerenciamento dos servidores localizados em cada uma das filiais. Pelo fato de os usuários utilizarem terminais thin client, todas as informações pertinentes a eles estão armazenadas no servidor local, além, como já mencionado, do banco de dados da aplicação e arquivos de projetos de móveis específicos para cada cliente. Caso aconteça algum problema com o servidor em uma filial que não possa ser corrigido remotamente, provavelmente determinará o deslocamento de um integrante da equipe de suporte até aquela filial, para avaliar e buscar uma solução. Durante esse período, a ameaça gerou um grande risco de a loja ficar parada em termos de acesso aos sistemas, impossibilitando ou dificultando as vendas e, consequentemente, trazendo problemas ao negócio. Utilizar um software que possa gerenciar todos os nós da rede, mesmo estes estando em locais geograficamente distribuídos, armazenando e apresentando as informações obtidas em um nó central, de forma que o gerenciamento torne-se eficiente e eficaz, é o principal estímulo desse trabalho, bem como uma grande motivação da área de TI da empresa Costaneira. Dessa forma, o adminsitrador de redes poderá dispor de uma ferramenta completa de gerenciamento, capaz de B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 21 monitorar, prevenir, detectar e/ou corrigir determinadas falhas que, do ponto de vista do negócio, podem acarretar perdas significativas. 1.2 Objetivos 1.2.1 Objetivos Gerais O objetivo desse trabalho é apresentar uma proposta de gerenciamento de unidades geograficamente distribuídas a partir de um nó central, atendendo aos conceitos teóricos e padrões de arquitetura necessários para obter o grau de excelência na área de gerenciamento de redes. 1.2.2 Objetivos Específicos No que toca aos objetivos específicos, pretende-se demonstrar que é possível implantar uma solução definitiva para o problema de gerenciamento de ativos e serviços de rede, de forma eficiente, utilizando poucos recursos computacionais e de comunicação de dados, e que seja passível de monitorar qualquer equipamento ou serviço, de forma proativa, sem a necessidade de investimentos em software proprietário. Para que isso seja satisfeito, será necessário compreender metodologias, protocolos e conceitos envolvidos no monitoramento de redes, bem como o planejamento de estratégias para o controle e gerenciamento das mesmas. Assim, espera-se não só melhorar a qualidade e disponibilidade dos serviços de TI do ambiente monitorado, reduzindo as taxas de incidentes, como também poder analisar padrões para melhorar o desempenho dos diversos componentes que englobam a infraestrutura de TI, e verificar tendências para planejar futuras expansões, contribuindo para o sucesso do negócio como um todo. Também é esperado que essa proposta seja útil a todos que estejam buscando algum software que os auxiliem na gerência de suas redes, de forma que B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 22 possam concentrar seus esforços em melhorias para a infraestrutura das mesmas, e, ao mesmo tempo, terem a capacidade de identificar, prevenir e remediar determinados problemas comuns às redes de computadores, de forma centralizada, mesmo apresentando um cenário distribuído. 1.3 Descrição dos Capítulos O presente trabalho está estruturado da seguinte forma: no Capítulo 2 é feita uma introdução sobre os conceitos básicos da gerência de redes, as áreas funcionais de gerenciamento, definição de monitoramento e controle e uma breve introdução à arquitetura de gerência de redes. No Capítulo 3 é contextualizado o protocolo de gerenciamento de redes, o SNMP, em suas três versões: SNMPv1, SNMPv2 e SNMPv3. Já no Capítulo 4 são apresentadas algumas ferramentas em nível de software, que auxiliam no gerenciamento de redes. Também é feito um comparativo entre essas ferramentas e uma análise dos resultados obtidos. O Capítulo 5 é destinado a abordar a proposta de implantação do software Zabbix na empresa analisada, verificando o cenário de TI da mesma, itens com maior necessidade de gerenciamento, entre outros fatores. No Capítulo 6 discute-se os resultados obtidos com a implantação do software referido, fazendo uma análise do cenário antes e depois de sua implementação e o impacto que o mesmo causou na rede da empresa. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 23 2 CONCEITOS BÁSICOS DE GERÊNCIA DE REDES Uma rede de computadores pode ser definida como um meio de interligar recursos físicos e lógicos entre dois ou mais computadores. Tais recursos podem ser o compartilhamento de uma impressora, arquivos, unidades de discos, entre outros. Por existirem inúmeros dispositivos capacitados para interligarem-se em ambientes tanto homogêneos como heterogêneos, e pelo crescimento das redes de computadores, existe a necessidade de gerenciar todos esses recursos. Esse capítulo apresenta os conceitos envolvidos na gerência de redes, mostrando na seção 2.1 a sua importância em um cenário organizacional. Já a seção 2.2 descreve as áreas funcionais envolvidas no gerenciamento de acordo com a ISO/IEC 10040 (1998). A seção 2.3 caracteriza o monitoramento e controle de rede e a seção 2.4 caracteriza a arquitetura envolvida no gerenciamento da mesma. 2.1 A importância do gerenciamento de redes O papel fundamental da gerência de redes de computadores é controlar o seu uso a fim de garantir um funcionamento adequado aos seus usuários (SANTOS, 2004). Maximizar a eficiência e a produtividade da mesma pode se tornar uma tarefa difícil, uma vez que se tem cenários cada vez mais complexos, aglomerando inúmeros ativos, tanto físicos (hardware) como lógicos (software), em pontos distribuídos da rede. Por esta razão, o profissional responsável pela administração B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 24 da rede de computadores, em uma organização, deve dispor de formas automatizadas para monitorar e controlar a parte física e a parte lógica da rede. Ter um software de gerenciamento é essencial, porém, é necessário que o administrador conheça bem cada item que deseja monitorar e o que este representa em um contexto geral da rede (SPECIALSKI, [2002]). Caso ele não tenha muito conhecimento, provavelmente deixará de obter os melhores resultados, uma vez que são inúmeros os padrões e as características envolvidas nos objetos gerenciados. De acordo com Carvalho e Brisa (1993), um esquema de gerenciamento deve conter algumas características, tais como: a) gerenciamento da rede como parte integral dela mesma; b) conter todas as informações sobre a rede, estatísticas, eventos, entre outros devem dispor de um meio centralizado de visualização, de modo que seja facilmente compreendido através de gráficos, por exemplo; c) haver mecanismos de prioridades sobre mensagens de controle de rede quanto a outros tipos de tráfego; d) ter mecanismos de segurança e detecção de acesso não autorizado; e) conter em um banco de dados as informações referentes aos componentes da rede e seus usuários; f) o funcionamento dos processos referentes ao gerenciamento, independente do meio de transmissão; g) a implementação de forma simples e flexível de qualquer alteração na rede. Figura 1 - Modelo de gerenciamento de redes Fonte: Santos et al. (2003, p. 122). B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 25 2.2 Áreas de gerenciamento Segundo disposto pela ISO/IEC 10040 apud Azevedo ([2009?], texto digital) “o gerenciamento de redes provê mecanismos para monitoração, controle e coordenação de recursos em um ambiente OSI e define padrões do protocolo OSI para troca de informações entre estes recursos”. Através deste entendimento, foram estabelecidas cinco áreas da gerência de redes que possuem necessidade de gerenciamento: configuração, contabilidade, desempenho, falhas e segurança (Figura 2). Cada uma destas áreas será analisada a seguir. Figura 2 - Áreas-chave de um gerenciamento de redes Fonte: Bonomo (2006, p. 7). 2.2.1 Gerenciamento de Configuração Essa área é responsável por todas as mudanças relacionadas à estrutura física e lógica da rede. Ela efetua a descoberta de elementos, coleta as suas informações de configuração, adiciona, mantém e atualiza os mesmos, além de descobrir interconectividade entre os objetos gerenciados. Também é responsável por manter um inventário atualizado, registrando informações de configurações, gerando eventos e relatórios, quando necessário, uma vez que todos os itens gerenciados iniciam e terminam nessa etapa (SPECIALSKI, [2002]). B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 26 2.2.2 Gerenciamento de Contabilidade O gerenciamento de contabilidade é utilizado para analisar, mensurar e limitar os recursos da rede por usuários ou grupo de usuários, garantindo, assim, a sua utilização de forma correta, ou seja, sem abuso de privilégios de acessos ou consumo exagerado desses recursos por parte dos usuários. São efetuadas coletas de utilização da rede para conhecer o perfil dos usuários, fornecendo detalhes suficientes para planejar o crescimento da mesma. O gerente de redes pode ainda limitar o uso de certos recursos por usuários e/ou grupos de usuários quando verificar o abuso por parte destes de seus privilégios. 2.2.3 Gerenciamento de Desempenho Consiste em analisar, monitorar e planejar a capacidade da rede de acordo com o seu desempenho. É útil, pois mantém a qualidade do serviço, utilizando indicadores de desempenho que analisam, entre outros fatores, a existência de gargalos, se o tráfego é excessivo, ou se o nível de capacidade de utilização é aceitável (SPECIALSKI, [2002]). Com isso é possível prevenir situações adversas antes que estas causem problemas para o usuário final, efetuando as devidas correções de forma proativa, ou ainda, indicando a necessidade de futuras expansões da rede. 2.2.4 Gerenciamento de Falhas Esse gerenciamento fica a cargo de notificar, isolar e consertar falhas que ocasionam prejuízos ou indisponibilidade do fluxo normal da rede. Segundo Specialski ([2002], p. 3) “uma falha normalmente é causada por operações incorretas ou um número excessivo de erros”. Quando isso ocorre, caso não seja gerenciado, dependendo do nível da falha, poderá gerar indisponibilidade de serviços que podem ser cruciais para o negócio de uma empresa, acarretando, B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 27 assim, prejuízos financeiros a esta. Por isso, quando uma falha ocorrer, é necessário possuir um mecanismo que propicie (SPECIALSKI, [2002]): a) determinar a origem da falha; b) isolar a falha, deixando a rede funcional (sem interferências); c) reorganizar a rede de modo que o impacto do componente que falhou seja mínimo para a estrutura geral; d) providenciar o reparo ou a troca do elemento que acarretou a falha, restaurando, assim, seu estado anterior. É interessante utilizar elementos redundantes, tanto para equipamentos quanto para rotas de comunicação, pois isso gera um impacto minimizado quando ocorre uma falha, gerando certo nível de tolerância a falhas (SPECIALSKI, [2002]). 2.2.5 Gerenciamento de Segurança De acordo com Carvalho e Brisa (1993), o gerenciamento de segurança assegura os dados da rede desde a proteção de senhas, utilizando a criptografia, até a obrigatoriedade de alteração periódica das mesmas. Dessa forma, informações pertinentes aos usuários devem ser acessadas somente por quem estiver autorizado. Segundo Specialski ([2002]), o gerenciamento de segurança trata de questões como: a) gerar, distribuir e armazenar chaves de criptografia; b) manter e distribuir senhas e mecanismos de controle de acesso; c) monitorar e controlar o acesso aos nodos da rede e suas informações; d) coletar, armazenar e examinar logs de auditoria e segurança, permitindo ativar/desativar estas atividades. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 28 2.3 Monitoramento e controle da rede Para que se tenha um ambiente de rede gerenciável, deve-se destacar duas categorias: monitoramento e controle da rede. Conforme Specialski ([2002]), o monitoramento da rede é uma função de “leitura”, pois esta tem como finalidade observar e analisar o estado e configuração da rede. Já o controle da rede, por englobar tarefas como alterações de valores de algum parâmetro ou executar determinada ação, é considerado uma função de “escrita”. Abaixo serão descritas algumas funções pertinentes a cada uma destas categorias. 2.3.1 Monitoramento Consoante Stallings (1999), as informações disponíveis para monitoramento de rede podem ser classificadas em três categorias: a) estática: informações geralmente pouco ou nada modificadas. Informa a configuração atual e os elementos que estão envolvidos nessa configuração, tal como número de portas de um switch ou roteador; b) dinâmica: provê informações relacionadas com eventos na rede como, por exemplo, a transmissão de um pacote na rede; c) estatística: normalmente derivada de informações dinâmicas, possibilitando a verificação de estatísticas sobre determinado item, tal como a média de pacotes transmitidos por unidade de tempo provinda de algum sistema. Também são utilizadas duas técnicas para disponibilizar as informações vindas dos agentes para o gerente. Essas técnicas são chamadas de polling e event-reporting e seus conceitos estão definidos conforme o Quadro a seguir: B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 29 Quadro 1 - Definição e objetivos das técnicas de polling e event-reporting. TÉCNICA DESCRIÇÃO OBJETIVOS Polling Gerente solicita alguma informação (pesquisa, estrutura, variável, etc) da MIB de um agente e este responde com as informações pertinentes. - Aprendizado sobre configuração de algum item gerenciado; - Informação sobre condição de algum item gerenciado; - Informações periódicas para melhor detalhamento de alguma área crítica. Event- reporting Agente gera relatórios periódicos e envia para o gerente. Gerente fica apenas aguardando as informações recebidas. - Relatório sobre estado atual de um agente; - Relatório sobre algum evento importante ou não habitual; - Detectar problemas assim que ocorrerem. Fonte: Adaptado pelo autor com base em Stallings (1999, p. 27 a 29). 2.3.2 Controle de Rede A área de controle de redes está diretamente ligada à questão de modificação de parâmetros de variáveis e execução de ações em um sistema gerenciado. De acordo com as cinco áreas do gerenciamento de redes (configuração, contabilização, desempenho, falhas e segurança) definidas pela ISO/IEC 10040 (1998), o controle de redes está voltado mais ao gerenciamento de configuração e segurança, enquanto o monitoramento de redes está direcionado aos outros elementos restantes. Os aspectos mais relevantes sobre gerência de configuração e de segurança, conforme Specialski ([2002]), são descritos conforme segue (Quadro 2): Quadro 2 - Descrição dos controles de segurança e configuração. CONTROLE FUNÇÃO Configuração - Definir informações de configuração para os recursos e seus atributos sujeitos ao gerenciamento; - Atribuir, modificar e examinar valores de parâmetros; - Definir, modificar e examinar a relação entre recursos/componentes da rede; - Iniciar/Parar as operações de rede; - Relatório de status de configuração. CONTINUA B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 30 CONCLUSÃO CONTROLE FUNÇÃO Segurança - Manter a informação segura; - Controlar o acesso aos recursos; - Controlar o processo de criptografia. Fonte: Specialski ([2002], p. 6). Quanto ao controle de segurança, vale ressaltar que as principais ameaças relacionadas à segurança vêm de aspectos como interrupção, interceptação, modificação e mascaramento. Com isso, os objetivos principais da segurança em redes é manter a confidencialidade, integridade e disponibilidade de seus serviços (STALLINGS, 1999). 2.4 Arquitetura do Gerenciamento de Redes Em conformidade com Stallings (1999), para gerenciar uma rede que usa o protocolo TCP/IP é necessário especificar os seguintes elementos: a) estação de gerenciamento ou gerente; b) agentes coletores; c) Management Information Base (MIB); d) protocolo de gerenciamento de redes (SNMP). As próximas subseções destinam-se a descrever cada um destes elementos. 2.4.1 Estação de gerenciamento Um gerente SNMP capta as informações fornecidas pelos seus agentes através das MIB’s e serve como modelo de interação homem-máquina, através de uma interface, via aplicação, possibilitando que o administrador da rede possa visualizar, monitorar e controlar os elementos gerenciados em uma rede de B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 31 computadores. Ele pode ser instalado tanto em um servidor dedicado, como em um compartilhado, e aborda alguns itens que são necessários para um gerenciamento mínimo, como: a) possuir meios para a gestão de análise de dados como gráficos e mapas, recuperação de falhas, log de eventos, entre outros; b) ter uma interface na qual o administrador possa monitorar e controlar a rede; c) ter capacidade de transformar os requisitos do administrador em informações úteis para o monitoramento e controle efetivo dos elementos na rede; d) conter um banco de dados para armazenar as informações extraídas dos objetos gerenciados (STALLINGS, 1999). Em um ambiente onde há necessidade de gerenciamento, pode-se classificar o uso dos gerentes de duas formas: centralizado e distribuído. 2.4.1.1 Gerenciamento centralizado Quando utilizada a gerência centralizada, todo o fluxo de controle e monitoramento da rede é estabelecido em uma única estação, ou seja, pode ser usado um servidor dedicado, por exemplo, que será responsável pela interação entre os objetos gerenciados (elementos da rede), o gerente (aplicação) e a pessoa responsável pela administração da rede (interface). Esse tipo de arquitetura é normalmente indicado para redes de menor porte, por não necessitar de muita complexidade. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 32 Figura 3 - Modelo de gerenciamento centralizado Fonte: Do autor. 2.4.1.2 Gerenciamento distribuído Já na gerência distribuída, o controle é feito de forma descentralizada, sendo este dividido em domínios de gerência, onde cada domínio é controlado por um gerente. Esse gerente é responsável por coletar as informações e tomar as decisões pertinentes ao seu domínio, e, dentro de um escopo global, existe um gerente principal que recebe as informações vindas de todos os seus subgerentes, formando, assim, uma hierarquia entre domínios. Esse modelo é mais difundido nas redes que se encontram geograficamente distantes (WALSH, 2008) e possuem equipes de suporte em cada nó gerenciado. Figura 4 - Modelo de gerenciamento distribuído. Fonte: Do autor. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 33 2.4.2 Agentes coletores Todos os dispositivos de uma rede que podem ser gerenciados como roteadores, servidores, switches, estações de trabalho, entre outros, para que seja satisfeita essa necessidade de gestão, devem possuir agentes SNMP em nível de software, que são responsáveis por todas as informações trocadas entre as estações de gerenciamento e os elementos gerenciados. De acordo com Stallings (1999), a ligação entre um gerente e seus agentes é estabelecida pelo protocolo Network Management Protocol (NMP), e, ao utilizar uma rede TCP/IP, a troca de mensagens entre os dois é feita pelo protocolo SNMP, que inclui algumas operações principais aplicáveis às MIBs: a) get: provê que o gerente possa recuperar valores dos objetos no agente; b) getNext: tem o mesmo princípio do get, porém, é utilizado para capturar valores de variáveis em tabelas da MIB onde o tamanho é desconhecido. Assim, é necessário utilizar um comando getNext inicial com o nome da tabela para capturar o seu primeiro valor e ir repetindo o comando sempre com a resposta do anterior para continuar a sequência, até chegar ao final, recuperando todos os valores; c) response: permite ao agente responder alguma requisição vinda do gerente. Após receber qualquer operação SNMP, exceto o trap, o agente executa essa operação, e, obtendo ou não sucesso, envia uma mensagem de resposta ao gerente (MELLO, 2000); d) set: permite que a estação de gerenciamento defina o valor dos objetos no agente; e) trap: permite que um agente possa notificar a estação de gerenciamento de eventos significativos (STALLINGS, 1999). A aplicação gerente solicita alguma informação (get) ou envia uma mensagem contendo uma ação (set), que deve ser tomada para o agente, e este, através do protocolo SNMP, se encarrega de validar, interpretar e responder às devidas B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 34 requisições de forma que o processamento pode ser assíncrono, ou seja, as informações retornadas pelo agente podem não ter sido solicitadas pelo gerente, porém, caso o agente assumir que é algo crítico (trap), a informação é transmitida. A priori, um agente não deve originar mensagens SNMP, mas apenas respondê-las. Todavia, há casos em que um agente necessita realizar alguma interceptação direta no dispositivo gerenciado, por algum motivo de segurança, forçando-o a realizar um evento. Esse evento gera um alarme no agente, que se encarrega de executar alguma tarefa crítica, como reinicializar ou desligar um sistema, por exemplo, e agindo, assim, de modo proativo. Para que haja uma maior segurança na comunicação entre gerente e agentes, existe a possibilidade de criar comunidades SNMP, nas quais são explicitamente definidos quais hosts pertencerão ao grupo e somente trocarão informações os agentes e estações de gerenciamento pertencentes a determinada comunidade. 2.4.3 Management Information Base (MIB) Para que um gerente e agente consigam trocar informações sobre os elementos gerenciados na rede é necessário que haja um padrão de nomenclatura para cada objeto. Dessa forma, através do protocolo SNMP, é possível interagir com os mesmos. De acordo com Comer (2007), o protocolo SNMP descreve de forma detalhada apenas o formato da mensagem e a codificação desta; outro padrão é utilizado para especificar as variáveis MIB, juntamente com a definição das operações de carga e armazenamento em cada variável. Já para Specialski ([2002]), uma MIB situada em um agente deve conter informações sobre a configuração e comportamento do mesmo, bem como parâmetros que possibilitem controlar alguma operação no nodo do agente. Da mesma forma, a MIB inserida no gerente também possui as informações da sua localização, entretanto, necessita ter informações sobre os agentes que fazem parte B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 35 de seu domínio. A Figura 5 simboliza a interação entre um gerente e um agente, com suas respectivas MIBs. Figura 5 - Interação entre o gerente e um agente Fonte: Rocha e Serradourada (2008, p. 10). A versão inicial da MIB foi designada através do documento Request For Comments (RFC) 1066 (MCCLOGHRIE; ROSE, 1988) e passou por um processo de evolução, sendo substituída pela MIB II, definida pelo RFC 1213 (MCCLOGHRIE; ROSE, 1991). Uma MIB obedece a uma regra de nomenclatura chamada Abstract Syntax Notation One (ASN.1) e a sua estrutura é descrita através de uma Structure of Management Information (SMI). Com esse modelo é possível representar, armazenar e transferir informações de gerenciamento, bem como criar novas MIBs. Quanto aos objetos de uma MIB, estes são organizados em um formato de árvore hierárquica e não possuem limites de expansão, tornando esse tipo de arquitetura flexível a mudanças. Cada objeto também possui um identificador Object Identifier (OID). Este OID nada mais é do que uma sequência de inteiros que serve para identificar a posição do objeto inserido na árvore da MIB. Para deixar mais claro essa questão, a Figura 6 mostra uma árvore MIB e seus objetos. Caso seja necessário resgatar a posição de um objeto do tipo icmp, por exemplo, este seria referenciado por iso.org.dod.internet.mgmt.Icmp e seu valor seria 1.3.6.1.2.5. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 36 Figura 6 - Árvore MIB Fonte: Do autor, adaptado de Gta.ufrj (2004, texto digital). 2.4.3.1 Tipos de objetos da MIB Conforme Mello (2000), uma MIB possui alguns tipos primitivos de valores para os objetos, dentre eles: Quadro 3 - Tipos de objetos da MIB. TIPO NOME DESCRIÇÃO Texto Display String Texto puro de no máximo 256 caracteres Contador Counter Valor numérico maior que zero que só pode ser incrementado. Medida Gauer Valor numérico que pode aumentar e diminuir. Inteiro Integer Valor inteiro positivo ou negativo. Enumerados Enumerated Value Associa um campo texto a um valor numérico. Tempo Time Tricks Tempo decorrido. Objeto Object Contém um identificador para outro objeto da MIB. CONTINUA B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 37 CONCLUSÃO TIPO NOME DESCRIÇÃO Endereço IP IP address Endereço IP de algum dispositivo da rede. Endereço Físico Physical address Endereço físico de um dispositivo da rede. String String Cadeia de caracteres arbitrários Tabela Table Entradas da tabela MIB. Auxiliar Branch Tipos adicionais. Fonte: Do autor, adaptado de Mello (2000). 2.4.3.2 Controle de acesso aos valores da MIB Para que se tenha maior segurança para o acesso a valores de uma MIB foram definidas algumas diretivas de controle para serem suportadas por ela. Tais diretivas estão descritas no quadro abaixo (WALSH, 2008): Quadro 4 - Controles suportados de uma MIB. Fonte: Walsh (2008). Outra forma de obter mais segurança é a utilização de comunidades. Assim, antes de qualquer interação com algum objeto da MIB, deve-se primeiro informar o nome comunitário do SNMP. Essa diretiva é configurada pelo próprio administrador da rede e garante que somente aquela comunidade cadastrada terá acesso aos objetos da MIB em questão (MELLO, 2000). Um exemplo disso está na Figura 7, na qual é apresentada uma tela de propriedades do serviço SNMP em um ambiente com sistema operacional Windows 7. É possível notar as configurações de controle de acesso, como a criação das comunidades e diretivas das mesmas. CONTROLE SUPORTADO Apenas leitura Sim Leitura e escrita Sim Não acessível Sim Acessível para notificação Sim Leitura e criação Sim Apenas escrita Não B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 38 Figura 7 - Configurações do serviço SNMP em um ambiente Windows 7. Fonte: Do autor. O próximo capítulo será destinado a uma apresentação básica do protocolo de gerenciamento de redes, chamado Simple Network Management Protocol (SNMP) e a diferenciar as suas versões. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 39 3 PROTOCOLO SNMP O SNMP é o protocolo padrão utilizado para administração de redes (COMER, 2007) e atualmente está na sua versão 3. Segundo o RFC 1157 (CASE et al., 1990), o SNMP deve especificar a forma como um gerente e os agentes devem se comunicar, de acordo com uma codificação de mensagem específica nomeada ASN.1. A (Figura 8), esboça a arquitetura de uma rede gerenciada utilizando o procotolo SNMP. Figura 8 - Arquitetura de gerenciamento de redes utilizando o protocolo SNMP. Fonte: Salvo ([2011?], texto digital). Em sua proposta inicial, o SNMP utilizava essas duas características (Stallings,1999): a) Structure of Management Information (SMI): estrutura única para gestão da informação; B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 40 b) MIB: Estrutura global ou esquema global para o banco de dados de objetos. Por utilizar o modelo TCP/IP no lugar do modelo Open Systems Interconnection (OSI), o SNMP tornou-se muito difundido, fato este comprovado pela grande implementação deste protocolo nos equipamentos de rede modernos. Desde a sua criação, o SNMP tem sofrido melhorias quanto à segurança, funcionalidades, entre outros, chegando a ser especificadas novas versões do protocolo, como a versão 2 e 3 (SNMPv2 e SNMPv3, respectivamente), e também extensões adicionais às MIBs, como o Remote Network Monitoring (RMON), versão 1 e 2, que visa monitoramento remoto baseado em fluxo e não somente em dispositivos. (MURRAY;STALVIG, 2008). A seção 3.1 apresenta uma definição ao SMI. Já a seção 3.2 mostrará o princípio de funcionamento do protocolo SNMPv1, sua arquitetura, o formato de envio das mensagens, bem como métodos de transmissão e recebimento das mesmas e suas limitações. A seção 3.3 introduz o protocolo SNMPv2 e as melhorias que este apresenta em relação ao seu antecessor e suas limitações. A seção 3.4 é destinada a apresentar a terceira versão do protocolo SNMP, o SNMPv3, com uma breve descrição das melhorias implementadas, principalmente no que se refere à segurança. 3.1 Structure of Management Information (SMI) Uma SMI, ou estrutura de informação de gerenciamento, está especificada pelo documento RFC 1155 (MCCLOGHRIE; ROSE, 1990) e define um modelo de como uma MIB deve ser definida e construída. A SMI é responsável por identificar os tipos de dados contidos em uma MIB e especificar como os recursos desta são representados e nomeados. A filosofia da SMI é encorajar a simplicidade e extensibilidade dentro da MIB, o que gera um contraste quanto à tentativa de utilizá- la no modelo OSI, pois este é extremamente complexo. Para fornecer uma maneira padronizada de representar a informação de gestão, a SMI deve fazer o seguinte: a) oferecer uma forma padronizada de definir a estrutura de uma MIB; B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 41 b) utilizar uma técnica padronizada para definição de objetos individuais, como sintaxe e o valor de cada objeto; c) padronizar a codificação dos valores de objetos. 3.2 Protocolo SNMPv1 Os estudos abordados até esta seção sobre gerenciamento de redes nos dão uma visão geral do que, na prática, é o protocolo SNMP. Dentre os seus objetivos destacam-se (SPECIALSKI, [2002]): a) minimizar o número e complexidade das funções de gerenciamento; b) possuir flexibilidade para futuras extensões; c) ser independente de arquitetura e mecanismos dos dispositivos gerenciados. Para Rocha e Serradourada (2008, p. 22), a definição do protocolo SNMP é a seguinte: O SNMP é um protocolo de gerência definido no nível de aplicação, e utilizado para obter informações de servidores SNMP. Os dados são obtidos através de requisições de um gerente a um ou mais agentes utilizando os serviços do protocolo de transporte UDP (User Datagram Protocol). 3.2.1 Arquitetura do protocolo SNMPv1 O gerenciamento por SNMP é baseado no conceito de arquitetura cliente/servidor. Uma aplicação de gerenciamento contendo um software gerente é instalada em uma máquina tornando-se assim o servidor. O gerente pode efetuar duas operações básicas de gerenciamento: get e set (operam na porta 161 através do protocolo UDP). Essas operações fazem uma comunicação com cada dispositivo que será gerenciado, efetuando um polling, ou seja, requisitando algum tipo de informação sobre o seu estado naquele instante. Tais dispositivos (clientes) B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 42 possuem um software agente instalado, sendo responsável por interpretar as requisições via SNMP-get ou SNMP-set (o get corresponde a algum tipo de pesquisa e o set uma alteração no parâmetro de alguma variável do objeto gerenciado), consultar uma base que detém todas as informações referentes ao objeto gerenciado (MIB), e retornar ao servidor uma mensagem SNMP (get- response) contendo o valor da informação solicitada pelo gerente. O software agente pode, igualmente, gerar notificações, também conhecidas como traps (opera na porta 162 através do protocolo UDP), sem que o gerente tenha solicitado, quando alguma situação anormal esteja acontecendo. A aplicação gerente recebe este alerta e o administrador da rede pode analisá-lo como bem entender. Esta arquitetura pode ser mais bem exemplificada abaixo (Figura 9). Figura 9 - Arquitetura de gerenciamento SNMP Fonte: Filho (2009, texto digital). B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 43 3.2.2 Formato da mensagem SNMPv1 O SNMP é um protocolo orientado a pacotes, sendo que cada pacote é denominado Protocol Data Unit (PDU), possuindo uma estrutura que contém cabeçalho, dados e informações de verificação do pacote (FILHO, 2009). Para Stallings (1999), as mensagens SNMP são utilizadas para efetuar a troca de informação entre a estação de gerenciamento e os agentes. Cada mensagem possui o número da versão do protocolo SNMP, a comunidade utilizada para intermediação entre o gerente e o agente e um dos cinco tipos de operações do protocolo (getRequest, getNextRequest, setRequest, getResponse, trap), conforme ilustrado na Figura 10. Figura 10 - Formato SNMP Fonte: Stallings (1999). Quadro 5 - Mensagens SNMP CAMPO DESCRIÇÃO Version Versão do SNMP. community Nome da comunidade SNMP. request-id Identificador único dos pedidos tratados. error-status Indica alguma exceção quanto ao comportamento do pedido. Gera valores como: noError(0); tooBig (1); noSuchName(2); badValue(3); readOnly(4) e genErr(5). error-index Provê informação adicional quando um erro ocorre, desde que o status dele seja diferente de 0. variablebindings Lista de nomes de variáveis e seus valores correspondentes. Enterprise Tipo de trap de produção de objeto. agent-addr Endereço do trap de produção de objeto. generic-trap Tipos genéricos de valores trapsão: coldStart(0); warmStart(1); linkDown(2); linkUp(3); authentication-Failure(4); egpNeighborLoss(5) e enterprise-specific(6). CONTINUA B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 44 CONCLUSÃO CAMPO DESCRIÇÃO specific-trap Código de trap específico. time-stamp Tempo decorrido entre a última inicialização da entidade de rede com a produção de trap; contém os valores de sysUpTime. Fonte: Barreto (2008, p. 15). 3.2.3 Transmissão de uma mensagem SNMPv1 De acordo com o RFC 1157 (CASE et al., 1990) e Stallings (1999), uma mensagem SNMP é transmitida da seguinte forma: Uma estrutura ASN.1 é utilizada para montar o PDU. O PDU é encaminhado para um serviço de autenticação, juntamente com o endereço de origem e destino e à comunidade da qual faz parte. Este serviço de autenticação se encarrega de gerar uma transformação como criptografia ou inclusão de algum código de autenticação e retorna o resultado. A entidade que será a transmissora do pacote constrói a mensagem que é constituída por campos contendo a versão do protocolo, nome da comunidade e o resultado da etapa anterior. Através da codificação ASN.1, um novo objeto é representado e passado ao serviço de transporte. 3.2.4 Recepção de uma mensagem SNMPv1 Quanto à recepção de uma mensagem SNMP, segundo Barreto (2008), esta ocorre da seguinte forma: O receptor analisa a sintaxe da mensagem, procurando inconformidades. Caso contenha, descarta a mensagem. Verifica o número da versão, e ,caso haja algum erro de combinação, descarta a mensagem. A entidade receptora do protocolo informa o nome de usuário (comunidade), a PDU da mensagem, e a origem e o destino do endereço de transporte para que seja efetuada uma autenticação. Essa autenticação é feita da seguinte forma: se houver falha de autenticação, a mensagem é descartada, sinalizando o receptor SNMP, que, por sua vez, gera um trap. Caso a autenticação seja validada com sucesso, um PDU B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 45 adequado à estrutura é gerado. O PDU é processado, e, caso o receptor SNMP obtiver falha na combinação da PDU, a mesma é descartada. 3.2.5 Variable bindings do protocolo SNMPv1 Uma variable binding é um campo da mensagem PDU, responsável por implementar múltiplas trocas entre objetos gerenciados. Com ela é possível enviar em uma única mensagem, operações do tipo get, set, trap. Dessa forma, se a aplicação gerente necessita receber os valores de todos os objetos escalares em um grupo particular de um agente, pode enviar esta única mensagem, solicitando todos os valores e obtendo uma resposta única, listando todos os valores (STALLINGS, 1999). Através dessa técnica, pode-se reduzir consideravelmente a carga de comunicações de gerenciamento de rede. 3.2.6 GetRequest PDU do protocolo SNMPv1 Uma operação do tipo GetRequest PDU, provém de um gerente, solicitando algo a um agente. Para que isso seja possível, a PDU deve conter os seguintes campos (Figura 11): a) tipo PDU: indica o tipo da PDU, no caso, um GetRequest; b) request-id: É um valor único que identifique a requisição em questão. Deve possibilitar a detecção de PDUs duplicadas; c) variablebindings: Contém uma lista de objetos que serão requisitados (STALLINGS,1999). B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 46 Figura 11 - Formato da mensagem de Requisições do SNMP. Fonte: Rocha (2011, texto digital). No lado do agente, a resposta a um GetRequest será dada por um GetResponse utilizando o mesmo request-id. Isso torna esta operação atômica, ou seja, todos os valores de objetos solicitados são respondidos ou nenhum. Caso um erro seja reportado, este retorna para o gerente através de um campo error-status, contido no GetResponse PDU. A entidade de resposta também pode indexar um objeto que contenha erro, usando o campo error-index e enviar a informação para a estação de gerenciamento (Figura 12). Figura 12 - Formato da mensagem de resposta. Fonte: Rocha (2011, texto digital). 3.2.7 GetNextRequest PDU do protocolo SNMPv1 O GetNextRequest PDU utiliza os princípios do GetRequest, possuindo o mesmo formato e troca de mensagem. A única diferença é que, enquanto um GetRequest possui em sua variablebindings uma referência a um objeto, obtendo o seu valor através do agente, no GetNextRequest este valor é dado pelo próximo objeto existente na árvore de sua MIB. Com isso, é possível descobrir e percorrer estruturas de uma MIB, na qual o tamanho das tabelas ou o formato é desconhecido (ROCHA, 2011). B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 47 3.2.8 SetRequest PDU do protocolo SNMPv1 Nas operações do tipo SetRequest PDU, sua principal função, se acordo com Barreto (2008), é alterar valores de variáveis do objeto de gerenciamento, utilizando assim, a mesma estrutura de um GetRequest ou GetNextRequest. O campo variablebindings recebe a lista dos valores de objetos que serão alterados. No agente, a resposta é feita utilizando o mesmo formato de mensagem de um GetResponse, contendo, também, o mesmo request-id informado (ROCHA, 2011). O SetRequest também pode ser usado para adicionar ou eliminar linhas, como afirma Barreto (2008). 3.2.9 Trap PDU do protocolo SNMPv1 Informa um alerta de evento provindo de um agente para um gerente, de forma que essa interação seja assíncrona, ou seja, não possui uma ordem cronológica de acontecimento. Algumas notificações mais comuns são: a) cold e warm start: reinicialização de um agente recorrente ou não de alguma falha; b) link down ou up: Falha ou retorno de algum link identificado no campo variablebindings (ROCHA, 2011); c) authentication failure: Informa que houve falha na autenticação de alguma mensagem. Figura 13 - Formato de mensagem de Trap no SNMPv1. Fonte: Rocha (2011). B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 48 Figura 14 - Sequência do PDU SNMP. Fonte: Barreto (2008, p. 17). 3.2.10 Limitações do protocolo SNMPv1 O SNMP, mesmo sendo o protocolo mais utilizado na gerência de redes, possui algumas limitações, dentre outras, determinadas por Stallings (1999). São elas: a) desempenho limitado em grandes redes devido a performance da técnica de polling, onde sempre é necessário enviar um pacote para obter de volta outro pacote de informações. b) mensagens críticas de trap podem não ser entregues e não ocorre uma garantia da sua entrega por usar UDP/IP. c) autenticação simples para o padrão básico SNMP. d) não suporta comunicação entre gerentes. Não há como uma rede gerenciada, aprender sobre os dispositivos de outra rede gerenciada. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 49 3.3 Protocolo SNMPv2 A segunda versão do Protocolo SNMP surgiu das limitações encontradas na versão original, principalmente quanto à questão de segurança, que praticamente não existia na versão 1. Porém, na prática, houve muita controvérsia por parte da equipe de desenvolvimento, quanto a este quesito, fazendo com que o seu mecanismo de segurança permanecesse o mesmo da primeira versão. Mesmo assim, outras funcionalidades foram implantadas em sua arquitetura como, por exemplo, novas operações que permitem a transferência de grandes blocos de dados (bulk), maior padronização estrutural da PDU, melhor detalhamento dos códigos de erros, possibilidade de interação entre entidades gerentes, suporte a multiprotocolos na camada de transporte, entre outros (SPECIALSKI, [2002]). A complexidade do protocolo aumentou consideravelmente e, por causa disso, não houve uma ampla aceitação (SPECIALSKI, [2002]). Os documentos RFC’s, que descrevem essa nova versão, vão do RFC 1901 a 1908 (CASE et al., 1996), o que, de fato, mostra o tamanho da complexidade desta extensão do SNMP, pois a sua versão original era contida em apenas um RFC, o 1157 (CASE et al., 1990). 3.3.1 Arquitetura do protocolo SNMPv2 Enquanto que o SNMPv1 possui dois tipos de interação para acessar valores de objetos gerenciados, o SNMPv2 pode utilizar três. São eles (Figura 15): a) gerente-agente ou request-response: ocorre quando um gerente envia uma requisição a um agente e este o responde (presente no SNMPv1); b) gerente-gerente: uma entidade gerente solicita uma informação à outra entidade gerente, que por sua vez retorna o pedido. Funciona como um request-response, porém é efetuado entre gerentes (presente somente no SNMPv2); B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 50 c) agente-gerente não confirmado ou trap: Esta interação ocorre quando um agente envia uma mensagem não solicitada, de forma assíncrona, para um gerente sem que este retorne nada (presente no SNMPv1). Figura 15 - Arquitetura SNMPv2. Fonte: SpeciaIski ([2002], p. 30). No SNMPv2 foram incluídas duas novas PDU’s para operações do protocolo, GetBulkRequest PDU e InformationRequest PDU. A primeira trata de recuperar grandes blocos de dados, de forma eficiente, como linhas de tabelas, eliminando, assim, uma das principais limitações da primeira versão. Já a segunda operação, é utilizada na troca de mensagens entre gerentes SNMP, onde um gerente informa a outro informações contidas na sua MIB, permitindo, assim, o gerenciamento distribuído. Quando o destinatário recebe a mensagem gera um Response PDU para o remetente, contendo a mesma informação recebida (Quadro 6). B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 51 Quadro 6 - Tipos e descrições de PDUs VALOR DO TIPO DE PDU TIPO DE PDU DESCRIÇÃO 0 GetRequest Retorna o valor de uma instância da variável. 1 GetNextRequest Retorna o valor da variável sucessora lexográfica. 2 Response Retorna o resultado de uma operação. 3 SetRequest Atribui valor a uma variável. 4 Trap (obsoleto) Não usado. Era o antigo Trap do SNMPv1. 5 GetBulkRequest Permite a recuperação de grande quantidade de dados, normalmente o conteúdo de tabelas. 6 InformRequest Permite que um gerente envie informações para outro gerente. 7 Trapv2 Envia sinalizações de eventos. 8 Report Usado para comunicação interna do protocolo para relatar erros excepcionais ocorridos durante o processamento das requisições. Fonte: Fassi ([2008?], texto digital). 3.3.2 Formato da mensagem do protocolo SNMPv2 O formato estrutural da PDU (Figura 16) também foi agrupado, tornando-se, assim, mais padronizado. Inclusive as mensagens de trap, que no SNMPv1 continham uma PDU exclusiva, na versão 2 foi modificada para se enquadrar ao restante das operações. Com isso houve um aumento de eficiência e performance durante a troca de mensagens entre as entidades (SPECIALSKI, [2002]). Figura 16 - Formato de mensagem PDU do SNMPv2. Fonte: Barreto (2008, p.22). Quanto aos códigos de erros, o SNMPv2 possibilitou novas informações, permitindo que houvesse uma análise mais apurada dos problemas ocorridos nas trocas de mensagens. O Quadro 7 informa uma lista de todos códigos de erros possíveis, bem como sua descrição, conforme Fassi ([2008?]). B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 52 Quadro 7 - Códigos de erros do SNMPv2 Fonte: Do autor, adaptado de Fassi ([2008?], texto digital). De acordo com Spescialski ([2002]), o SNMPv2, através da RFC 1906 (CASE, et al., 1996), pode atuar não somente através de transmissão sobre o UDP, como também é possível especificar outros protocolos de transporte. Exemplos disso são os protocolos OSI (RFC 1418), appletalk (RFC 1419) e o Internetwork Packet Exchange (IPX) (RFC 1420). Valor do Código de Erro Código de Erro Descrição 0 noError Nenhum erro ocorrido. 1 tooBig O tamanho do PDU Response muito grande para ser transmitido. 2 noSuchName O nome do objeto requisitado não foi encontrado. 3 badValue Valor incorreto. 4 readOnly Impossibilidade de alterar o valor de uma variável pois a mesma é somente leitura. 5 genErr Erro desconhecido. 6 noAccess Sem acesso ao objeto por motivos de segurança. 7 wrongType Tipo de dado do objeto é incorreto. 8 wrongLength Tamanho do objeto incorreto. 9 wrongEncoding O valor codificado é inconsistente com o tipo do objeto. 10 wrongValue Valor da variável inválido. 11 noCreation Variável especificada não existe ou não pode ser criada. 12 inconsistentValue Condição temporária de inconsistência no valor do objeto. 13 resourceUnavailable Alocação de recursos indisponíveis no momento de atribuir valor a uma variável. 14 commitFailed Falha na atribuição de valores de uma variável. 15 undoFailed Impossibilita desfazer atribuições de variáveis após ocorrência de uma falha. 16 authorizationError Erro de autorização. 17 notWritable Variável não pode ser modificada. 18 inconsistentName o nome da variável é inconsistente e não pode ser criada nestas circunstâncias. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 53 3.3.3 Limitações do protocolo SNMPv2 Apesar de possuir vantagens sobre a primeira versão do SNMP, o SNMPv2 apresenta algumas limitações mencionadas abaixo: a) dificuldade de implementação devido a grande complexidade; b) muitas variações do protocolo, como por exemplo, SNMPv2c, SNMPv2u e SNMPv2* (as duas últimas foram destinadas a melhorias de segurança porém na prática não são utilizadas); c) baixa aceitação pela comunidade de gerência. 3.4 Protocolo SNMPv3 Como o SNMPv2 não conseguiu trazer as melhorias de segurança propostas, houve a necessidade destas serem inclusas ao protocolo, fazendo com que surgisse, em meados de 1999, a terceira versão do SNMP, o SNMPv3. Basicamente, o SNMPv3 utiliza os mesmos mecanismos das troca de mensagem PDU do SNMPv2, porém, sua estrutura geral é diferente das outras versões do protocolo. Dentre as melhorias implementadas, pode-se destacar a inclusão de um modelo de segurança baseado em usuários, chamado User-based Security Model (USM), e um modelo de controle de acesso baseado em visão, o View-based Access Control Model (VACM). Também vale ressaltar a inclusão de módulos na arquitetura que permitem a integração com as versões anteriores do protocolo (SPECIALSKI, [2002]). Esta seção não irá se aprofundar nessa versão do protocolo, limitando-se a abordar, de forma geral, o seu funcionamento. A Figura 17 mostra a evolução do protocolo SNMP. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 54 Figura 17 - Evolução do SNMP. Fonte: Helcio; Iguatemi (2009, texto digital). 3.4.1 Arquitetura do protocolo SNMPv3 Através da RFC 2571 (HARRINGTON et al., 1999), definiu-se o conceito de entidades SNMP, onde cada entidade pode interagir com outra, atuando, assim, como agente, gerente ou ambos. Tais entidades possuem módulos que se comunicam entre si para dispor algum serviço, como afirma Fassi ([2008?]). Uma entidade SNMPv3 (Figura 18) pode ser definida pelos componentes abaixo (SPECIALSKI, [2002]): Quadro 8 - Componentes do protocolo SNMPv3 COMPONENTE DESCRIÇÃO Dispatcher gerenciador de tráfego, permitindo suporte concorrente a múltiplas versões de mensagens SNMP subsistema de processamento de mensagens prepara mensagens para transmissão e extrai dados de mensagens recebidas subsistema de segurança provê mecanismos de autenticação e privacidade. Pode conter vários modelos de segurança subsistema de controle de acesso checa as diretivas de acesso que uma aplicação terá direito CONTINUA B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 55 CONCLUSÃO COMPONENTE DESCRIÇÃO gerador de comandos responsável por inicializar as PDUs SNMP (get, getNext, getBulk, setRequest) e processar as resposta provindas de uma requisição respondedor de comandos responsável por receber as PDUs SNMP, executar alguma operação definida pelo protocolo usando o controle de acesso e criar a mensagem de resposta que será encaminhada originador de notificação origina as mensagens de trap/inform baseado em eventos e condições monitoradas. Responsável também por determinar qual será o destino da mensagem, a versão do SNMP que será usada e quais serão os mecanismos de segurança utilizados receptor de notificação responde as requisições de notificação referentes ao PDU inform encaminhador de proxy Serve para repassar as mensagens SNMP. É de uso opcional. Fonte: Specialski ([2002, p. 33]). Figura 18 - Arquitetura de uma entidade SNMPv3 Fonte: Do autor. 3.4.2 Formato da mensagem do protocolo SNMPv3 O formato da mensagem SNMPv3 é mostrado na (Figura 19) e possui uma estrutura baseada em módulos, sendo que a parte escura representa a área utilizada pelo susbsistema de processamento de mensagem. Os campos utilizados em uma mensagem SNMPv3 são descritos no Quadro abaixo, conforme Barreto (2008) e Karing (2002): B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 56 Quadro 9 - Campos utilizados em uma mensagem SNMPv3 CAMPO DESCRIÇÃO msgVersion versão SNMP utilizada na mensagem msgID identificador único usado entre duas entidades SNMP e pelo processador de mensagens. msgMaxSize tamanho máximo das mensagens. Medido em octetos. msgFlags representa um octeto contendo três flags nos três últimos bits significativos. Tais flags são: reportableFlag, privFlag, authFlag. A primeira é utilizada somente quando uma porção PDU de uma mensagem não pode ser decodificada. Já a privFlag e authFlag são elementos de segurança usados para o processo de criptografia e autenticação, respectivamente msgSecurityModel indica qual modelo de segurança foi usado pelo remetente ao preparar e mensagem e, com isso, qual modelo de segurança deve ser usado pelo destinatário para processar a mensagem. Alguns valores aceitos incluem: “1” para SNMPv1, “2” para SNMPv2c e “3” para USM. msgSecurityParameters representa um octeto que contém informações geradas pelo subsistema de segurança da entidade SNMP que enviou a mensagem e processado pelo subsistema de segurança da entidade receptora. contextEngineID identificador único da entidade SNMP. É representado por um octeto. contextName octeto que identifica de forma única um contexto a um motor de contexto associado. PDU SNMPv2 a PDU utilizada segue os mesmos padrões da versão 2 do protocolo. Fonte: Do autor, adaptado de Barreto (2008) e Karing (2002). Figura 19 - Formato de mensagem SNMPv3 Fonte: Karing (2002, p.51). B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 57 3.4.3 Segurança e controle de acesso do protocolo SNMPv3 Segundo Walsh (2008), no modelo SNMPv3 é definida a autenticação de usuários, através da qual cada um possui seu nome de usuário e senha. Tanto as entidades gerentes como os agentes possuem as suas chaves de segurança e têm seus usuários válidos, juntamente com uma chave secreta única, definida para cada usuário. Quando uma entidade envia uma mensagem SNMPv3, a chave secreta de seu utilizador é usada para criar um hash da mensagem, e este valor é inserido na mesma. Caso a entidade receptora consiga recriar esse hash através de sua chave secreta compartilhada, então a mensagem é autenticada e provém de um usuário válido. As mensagens de traps também são enviadas a partir de usuários válidos e as entidades agentes podem ser configuradas para exercer um controle mais detalhado sobre a transmissão destes traps para os gerentes. Esse tipo de modelo é conhecido como modelo de segurança baseado em usuários (USM), e garante que as mensagens enviadas de forma atemporal não sejam atrasadas ou reproduzidas por quem não pertence ao grupo autenticado. As entidades SNMP, que atuam como agentes, podem ser configuradas para controlar quem pode acessar e o que pode ser acessado dentre os objetos pertencentes à MIB por elas gerenciada (WALSH, 2008). Nas versões anteriores do SNMP, esse quesito era gerenciado através do conceito de nomes de comunidade. Já no SNMPv3, segundo Specialski ([2002], p. 35), “o controle de acesso tornou-se muito mais seguro e flexível pela introdução do modelo de controle de acesso baseado em visão (VACM – View-based Access Control Model)”. Por exemplo, um usuário = Supervisor de Operações pode acessar os dados críticos de leitura e escrita de controle, enquanto o usuário = Manutenção de planta pode acessar somente os dados específicos com permissão de apenas leitura (WALSH, 2008). De acordo com Specialski ([2002]), o SNMPv3 é projetado para prover segurança contra as seguintes ameaças: B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 58 a) modificação da informação: uma entidade poderia alterar uma mensagem em trânsito que tivesse sido gerada por alguma entidade autorizada; b) masquerade: uma entidade possuir o privilégio de entidade autorizada, mesmo não sendo autorizada; c) modificação da cadeia de mensagem: uma mensagem SNMP está sujeita a ser reordenada, atrasada ou repetida pelo fato de o protocolo ter sido projetado a operar sobre um protocolo não orientado à conexão (UDP); d) descoberta: através da observação de troca de mensagens entre gerentes e agentes, uma entidade poderia descobrir valores de objetos gerenciados e assim, alterá-los. Mesmo assim, ainda existem limitações quanto à segurança como nas seguintes ameaças: a) negação de Serviço (Denial of Service – DoS): ocorre quanto um atacante consegue impossibilitar o serviço de troca de mensagens entre gerente e agente; b) análise de tráfego: observação do comportamento de tráfego entre gerente e agente. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 59 4 FERRAMENTAS DE GERENCIAMENTO E MONITORAMENTO DE REDES A fim de atingir um maior número de elementos gerenciados, torna-se viável fazer uso de uma ferramenta capaz de auxiliar, de forma eficaz, toda a parte de gerenciamento e monitoramento de redes. Essa ferramenta deve, no mínimo, ser capaz de prover uma interface única ao usuário e demonstrar informações em tempo real sobre os objetos gerenciados, de forma clara, para que seja efetuada uma análise correta do ambiente gerenciado. A partir disso, esse Capítulo tem como objetivo analisar alguns sistemas baseados em software livre utilizados para efetuar o gerenciamento e monitoramento de redes de computadores. Na seção 4.1 e 4.2 serão introduzidas algumas das principais soluções em software para geração de gráficos de estado, o MRTG e o RRDTOOL, respectivamente, sendo que os mesmos mostram-se como precursores das atuais soluções de sistemas para gerenciamento. Já na seção 4.3 será abordada a ferramenta NTOP, um analisador e monitorador de tráfego de rede. As seções 4.4, 4.5, 4.6, 4.7, 4.8 e 4.9 informam um breve resumo e características principais das ferramentas Nagios, Cacti, OpenNMS, Pandora FMS, Zabbix e Zenoss, nessa ordem. Na seção 4.10 será apresentado um quadro comparativo entre as ferramentas estudadas, e na seção 4.11 será mostrada a análise dos resultados comparativos referente aos tipos de software propostos. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 60 4.1 MRTG O Multi Router Traffic Grapher (MRTG) é um software escrito em perl e funciona em Unix/Linux, bem como nos sistemas Windows e até mesmo Netware. Além disso, é software livre, licenciado sob a GNU General Public License (GPL) (MRTG, 2013). O desenvolvimento dessa ferramenta foi originalmente iniciado em 1994 e sua proposta principal é monitorar o tráfego de rede, baseado em páginas HyperText Markup Language (HTML), que mostram, através de imagens gráficas, o estado em tempo real deste tráfego. Essa ferramenta utiliza agentes SNMP ou scripts personalizados para coletar as informações e expor em forma de gráficos (Figura 20), desde que o software ou hardware monitorado tenham suporte a isso (MRTG, 2013). Figura 20 - Imagem de um gráfico gerado pelo MRTG. Fonte: MRTG (2013). 4.2 RRDTool O Round Robin Database (RRDTool) originou-se a partir do MRTG e utiliza o algoritmo de Round Robin para gerar uma base de dados em séries temporais com valores numéricos, contendo informações sobre estado de diversos elementos como temperatura, carga de Central Processing Unit (CPU), uso de memória e disco, estado da rede, entre outros. É possível coletar dados vindos de agentes SNMP e gerar diversos tipos de gráficos (Figura 21) para monitorar a informação (RRDTOOL, 2013). B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 61 Figura 21 - Imagem de um gráfico gerado pelo RRDTool Fonte: RRDTool (2013). 4.3 NTOP A principal característica do NTOP é poder monitorar a utilização dos recursos de rede de computadores como tráfego e consumo de banda, por exemplo (NTOP, 2013). As informações são mostradas de forma clara através de uma página web (Figura 22), onde é possível verificar todas as conexões estabelecidas dentro da rede interna, identificando o host através de seu endereço IP e outros protocolos envolvidos na conexão. Com essa ferramenta é possível avaliar de forma bem ampla como o estado da rede está se comportando em determinado momento, possibilitando ao administrador de redes observar anomalias e solucionar eventuais problemas em sua rede. O NTOP também possui suporte a múltiplas plataformas como UNIX, LINUX e Windows. Como foi projetado para ser uma aplicação ao nível de kernel, ele visa utilizar poucos recursos de processador e memória. Por ser uma ferramenta simples e com uma análise bem completa do estado da rede, tem-se como um software bastante útil para redes locais, nesse quesito. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 62 Figura 22 - Informações de host no NTop Fonte: NTOP (2013). 4.4 Nagios O Nagios é um dos mais conhecidos sistemas de gerenciamento de rede, de código aberto e licenciado pelo sistema GPL. Com ele é possível gerenciar tanto equipamentos de hardware (switch, roteadores, servidores, estações de trabalho, etc), como serviços funcionais a nível de software em uma rede. Também possui mecanismos de alerta quanto à descoberta de problemas na rede e/ou resolução dos mesmos. Esse software foi originalmente desenvolvido por Ethan Galstad, em 1999, sob o nome de NetSaint, e, em 2001, teve seu nome alterado e registrado para Nagios (Nagios Ain't Gonna Insist On Sainthood), por ter sido acusado de utilizar o mesmo nome, na época, de uma outra marca. Em 2007, Ethan fundou a Nagios Enterprises, que é atualmente a patrocinadora oficial do projeto e possui, além da B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 63 versão comunitária, uma versão comercial que conta com um suporte mais específico e algumas características inicialmente não disponíveis na versão comunitária (NAGIOS, 2013). Em consonância com o site oficial do projeto (NAGIOS, 2013) serão listadas algumas características desta ferramenta, tais como: a) monitoramento de serviços de rede, tais como: SMTP, POP3, HTTP, ICMP, SMNP, entre outros; b) monitoramento da infraestrutura de hardware (uso de memória, carga da CPU, espaço em discos, log de sistema, etc); c) detecção de problemas antes que estes ocorram; d) alertas instantâneos ao surgimento de problemas; e) compartilhamento de informações de disponibilidade entre as partes interessadas; f) detecção de falhas de segurança; g) informações pertinentes para expansão e/ou atualização da TI; h) redução de perdas de tempo de inatividade e de negócios. Com o Nagios é possível, ainda, desenvolver plug-ins em diferentes linguagens para determinadas tarefas. Sua comunidade já disponibilizou uma série deles para auxiliar no gerenciamento de redes. B D U – B ib lio te ca D ig ita l d a U N IV AT E S (h tt p: //w w w .u ni va te s.b r/ bd u) 64 Figura 23 - Tela do software Nagios Fonte: Nagios (2013). Algumas desvantagen