universidade do vale do itajaÍ centro de ciÊncias ...siaibib01.univali.br/pdf/marcus vinicius de...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UM PLUGIN NAGIOS PARA O GERENCIAMENTO DE CÂMERAS AXIS MODELO P1343
por
Marcus Vinicius de Souza Simas
Itajaí (SC), dezembro de 2012
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UM PLUGIN NAGIOS PARA O GERENCIAMENTO DE CÂMERAS AXIS MODELO P1343
Área de redes de computadores
por
Marcus Vinicius de Souza Simas Relatório apresentado à Banca Examinadora do Trabalho Técnico-científico de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Fabricio Bortoluzzi, M.Sc.
Itajaí (SC), julho de 2012
AGRADECIMENTOS
A Deus por me dar forças e sempre me guiar em minhas escolhas.
A minha mãe por estar sempre ao meu lado me dando forças, torcendo por mim e querendo sempre o melhor.
Ao meu pai por nunca deixar que eu desistisse e nunca medir esforços para que esta fase de minha vida fosse concluída.
A minha namorada por me apoiar e dedicar longos dias e madrugadas ao meu lado durante o desenvolvimento deste trabalho.
Ao Fabricio por saber me conduzir como um orientador, um professor e um amigo em diferentes momentos deste trabalho.
Ao Gilberto de Souza por ceder a câmera para que este projeto fosse possível ser concluído.
Ao Anderson do laboratório de redes que me inspirou a desenvolver este projeto em uma linguagem de desenvolvimento nunca utilizada por mim antes.
A todos os professores, pois sem o conhecimento e sabedoria repassada por eles este projeto não estaria sendo concluído.
A todos meus Amigos pela boa companhia em momentos necessários para a conclusão deste curso.
RESUMO
SIMAS, Marcus Vinicius de Souza. Dsesenvolvimentode Plugin NAGIOS para gerenciamento de câmeras AXIS modelo P1343. Itajaí, 2012. 86 folhas. Trabalho Técnico-científico de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2012. Com o aumento e evolução das tecnologias utilizadas em redes de computadores e com a necessidade de serviços cada vez mais confiáveis oferecidos pela área de tecnologia da informação, torna-se necessário aos gestores de rede ferramentas centralizadas e otimizadas para garantir o gerenciamento completo da rede. Dentre os ativos de rede o sistema de CFTV está sendo cada vez mais delegado ao departamento de tecnologia sendo necessário que seja gerenciado de maneira equivalente aos outros equipamentos de rede. O resultado desta necessidade impacta em diversas áreas da tecnologia, fazendo com que protocolos de gerência de redes de computadores, softwares para monitoramento e para geração de relatórios gráficos se tornem peças importantes. O software Nagios como ferramenta para o monitoramente de equipamentos conectados a rede oferece flexibilidade e extensibilidade. Com o desenvolvimento deste trabalho foi possível criar de uma ferramenta para estender o Nagios ao gerenciamento direto da câmera Axis modelo p1343. O resultado final foi a criação de um plugin Nagios que oferece recursos de conexão com a câmera utilizando SNMP e HTTP. O estudo e compreensão do funcionamento de agentes, gerentes, da MIB e do Nagios foram fundamentais para o processo de desenvolvimento e estão documentados neste trabalho. Palavras-chave: Agentes. Gerentes. Gerência de redes.
ABSTRACT
With the increase of the technologies used for computer networks and the increasingly necessity for reliable services offered by technology area, it is compulsory to network managers centralized and optimized tools to ensure complete management of the network. Among the network devices the CCTV systems is an asset that is being increasingly delegated to the technology department and needs to be managed in a manner equivalent to other network equipment. The result of this need impact in many areas of technology, making management protocols of computer networks, software for monitoring and graphical reporting become important parts. Nagios software as a tool monitoring equipment connected to the network offers flexibility and extensibility. With the development of this work was possible the creation of a tool to extend the Nagios management to the specific Axis camera modell P1343. The result was a creation of a Nagios plugin that provides resources to connect to the camera using SNMP and HTTP. The study and understanding of the operation of agents, managers, MIB and Nagios were fundamental to the process of development and are documented in this work. Keywords: Agents. Managers. Network Management.
LISTA DE FIGURAS
Figura 1. Visão ampla da Gerência de redes. ........................................................................... 18
Figura 2. Comunicação entre NMS e Agente SNMP. .............................................................. 21
Figura 3. Comunicação TCP/IP entre NMS e Agente SNMP. ................................................. 22
Figura 4. Árvore da MIB. ......................................................................................................... 26
Figura 5. Comunicação entre Agente e Gerente SNMP e MIBs. ............................................. 27
Figura 6. Interface inicial do Nagios. ....................................................................................... 29
Figura 7. Plugin (check_ping) para monitorar a comunicação com a rede de um host............ 30
Figura 8. Template de definição de um objeto no Nagios. ....................................................... 31
Figura 9. Definição de um objeto tipo host no arquivo de configuração do Nagios. ............... 33
Figura 10. Imagem lateral da câmera p1343. ........................................................................... 36
Figura 11. Imagem frontal da câmera p1343. ........................................................................... 37
Figura 12. Interface do software IP Axis IP. ............................................................................ 38
Figura 13. Interface do software Axis Camera Station. ........................................................... 39
Figura 14. Definição do escopo do trabalho a ser desenvolvido. ............................................. 40
Figura 15. Diagrama de casos de uso do plugin Nagios. .......................................................... 44
Figura 16. Arquivo templates.cfg responsável pela criação de objetos padrão no Nagios....... 47
Figura 17. Arquivo commands.cfg do Nagios. ......................................................................... 49
Figura 18. Define um host no arquivo de configuração cameras.cfg. ...................................... 49
Figura 19. Define um hostgroup no arquivo de configuração cameras.cfg. ............................ 50
Figura 20. Define um service no arquivo de configuração cameras.cfg. ................................. 51
Figura 21. Arquivo nagios.cfg do Nagios................................................................................. 51
Figura 22. Imagem inicial do webserver da câmera Axis P1343. ............................................ 59
Figura 23. Interface de gerenciamento principal. Teste com conectividade de rede. ............... 65
Figura 24. Resultado do serviço HTTP Audio Settings. .......................................................... 66
Figura 25. Resultado do serviço HTTP Date/Time. ................................................................. 66
Figura 26. Resultado do serviço HTTP Firmware. ................................................................... 66
Figura 27. Resultado do serviço HTTP Video Settings. .......................................................... 67
Figura 28. Resultado do serviço SNMP Network. ................................................................... 67
Figura 29. Resultado do serviço SNMP Network-ISO............................................................. 68
Figura 30. Resultado do serviço SNMP Ping. .......................................................................... 68
Figura 31. Resultado do serviço SNMP Uptime. ..................................................................... 68
Figura 32. Interface de gerenciamento principal. Teste sem conectividade de rede. ............... 69
Figura 33. Resultado do serviço HTTP Audio Settings. .......................................................... 69
Figura 34. Resultado do serviço HTTP Date/Time. ................................................................. 70
Figura 35. Resultado do serviço HTTP Firmware. ................................................................... 70
Figura 36. Resultado do serviço HTTP Video Settings. .......................................................... 70
Figura 37. Resultado do serviço SNMP Network. ................................................................... 71
Figura 38. Resultado do serviço SNMP Network-ISO............................................................. 71
Figura 39. Resultado do serviço SNMP Ping. .......................................................................... 71
Figura 40. Resultado do serviço SNMP Uptime. ..................................................................... 72
LISTA DE TABELAS
Tabela 1. Retornos aceitáveis pelo Nagios. .............................................................................. 30
Tabela 2. Tipos de valores aceitos no object-type. ................................................................... 32
Tabela 3. Listagem de números estatísticos fornecidos via MIBv2. ........................................ 56
Tabela 4. Teste número 1 ......................................................................................................... 65
Tabela 5. Teste número 2 ......................................................................................................... 67
Tabela 6. Teste número 3 ......................................................................................................... 69
Tabela 7. Teste número 4 ......................................................................................................... 71
LISTA DE QUADROS
Quadro 1. Bibliotecas utilizadas no arquivo check_snmp-uptime.pl. .................................... 52
Quadro 2. Código utilizado para uso da biblioteca Nagios::Plugin. ................................................. 53
Quadro 3. Subrotina getUptime e sua chamada. ................................................................................ 54
Quadro 4. Função de impressão do plugin check_snmp-network2.pl ............................................... 55
Quadro 5. Definição de objeto Net::SNMP::HostInfo. Imprime da tabela de rotas. ......................... 55
Quadro 6. Código para impressão de informações estatísticas. ........................................................ 57
Quadro 7. Rotina de ping via Perl utilizando módulo CPAN. .......................................................... 57
Quadro 8. Rotina de conexão via http no webserver. ........................................................................ 59
Quadro 9. Código para chamada da rotina de conexão ao webserver. .............................................. 60
Quadro 10. Rotina para busca de informações de audio. .................................................................. 61
Quadro 11. Rotina para busca de informações de firmware.............................................................. 61
Quadro 12. Rotina para busca de informações de vídeo. .................................................................. 62
Quadro 13. Rotina de testes para confirmar as informações de vídeo. ............................................. 63
Quadro 14. Rotina de testes para certificar-se a veracidade das informações de vídeo. ................... 64
LISTA DE ABREVIATURAS E SIGLAS
API Application programming interface BSD Berkeley Software Distribution CFTV Circuito Fechado de Televisão CPAN The Comprehensive Perl Archive Network CPU Central Processing Unit FCAPS Fault, Configuration, Accounting, Performance and Security GNU Gnu is Not Unix GPL General Public License HTTP Hypertext Transfer Protocol HTTPS HyperText Transfer Protocol Secure ICMP Internet Control Message Protocol IETF Internet Engineering Task Force IOS Internetwork Operating System IP Internet Protocol IPv6 Internet protocol version six ISO International Standards Organization JPEG Joint Photographic Experts Group MIB Management Information Base NMS Network Management System OID Object Identifier PC Personal Computers PHP PHP Hypertext Preprocessor RFC Request for Comments SH Shell SNMP Simple Network Management Protocol SO Sistema Operacional SSH Secure Shell TCP Transfer Control Protocol TI Tecnologia da Informação TTC Trabalho Técnico-científico de Conclusão de Curso UDP User Datagram Protocol URL Uniform Resource Locator UNIVALI Universidade do Vale do Itajaí VAPIX Linguagem de desenvolvimento proprietária da AXIS
SUMÁRIO
1 INTRODUÇÃO .............................................................................................................................. 12
1.1 PROBLEMATIZAÇÃO ..................................................................................... 13
1.1.1 Formulação do Problema ............................................................................... 13
1.1.2 Solução Proposta ............................................................................................. 14
1.2 OBJETIVOS ........................................................................................................ 14
1.2.1 Objetivo Geral ................................................................................................. 14
1.2.2 Objetivos Específicos ...................................................................................... 14
1.3 METODOLOGIA ................................................................................................ 15
1.4 ESTRUTURA DO TRABALHO ....................................................................... 15
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................................. 17
2.1 GERÊNCIA DE REDES .................................................................................... 17
2.2 PROTOCOLO SNMP ......................................................................................... 19
2.2.1 Agente SNMP .................................................................................................. 23
2.2.2 Gerente SNMP ................................................................................................ 24
2.2.3 Management Information Base (MIB) ......................................................... 25
2.3 NAGIOS ............................................................................................................... 28
2.3.1 Nagios: Software de monitoramento ............................................................. 28
2.4 WEB CRAWLER ................................................................................................ 33
2.4.1 cURL ................................................................................................................ 34
2.5 A CÂMERA AXIS P1343 ................................................................................... 35
2.5.1 Ferramentas similares .................................................................................... 37
3 DESENVOLVIMENTO ................................................................................................................. 40
3.1 REQUISITOS FUNCIONAIS, NÃO FUNCIONAIS E REGRAS DE NEGÓCIO .................................................................................................................. 41
3.1.1 Requisitos Funcionais ..................................................................................... 41
3.1.2 Requisitos Não Funcionais ............................................................................. 41
3.1.3 Regras de Negócio ........................................................................................... 42
3.2 DIAGRAMA DE CASOS DE USO ................................................................... 43
3.2.1 UC01.01 Solicita informações da câmera ..................................................... 44
3.2.2 UC01.02 Verifica conectividade da câmera .................................................. 45
3.3 DESENVOLVIMENTO DO PLUGIN.............................................................. 46
3.3.1 Ferramentas utlizadas para o desenvolvimento .......................................... 46
3.3.2 Configuração do Nagios ................................................................................. 47
3.3.3 Desenvolvimento do plugin Nagios ................................................................ 52
3.3.4 Informações adicionais capturadas ............................................................... 58
3.3.5 Testes realizados .............................................................................................. 64
4 Conclusões ...................................................................................................................................... 73
4.1 TRABALHOS FUTUROS .................................................................................. 73
APÊNDICE A. PROJETO DE SOFTWARE DESENVOLVIDO NO ENTERPRISE ARCHITECT ........................................................................................................................... 77
12
1 INTRODUÇÃO
Os avanços e os benefícios trazidos à sociedade através das redes de computadores
tornaram-nas vitais para a maioria dos negócios. A cada dia mais necessidades são
encontradas e mais recursos são incorporados nas redes de computadores. Entre os diversos
desafios da manutenção destas redes está a necessidade do gerenciamento dos equipamentos
empregados na composição de sua infraestrutura.
Kurose e Ross (2006, p.1) apresentam uma visão bem clara quanto às redes:
[...] de browsers Web de telefones celulares a cafés que oferecem acesso sem fio a internet, de redes domésticas com acesso de banda larga a infraestruturas tradicionais de TI (Tecnologia da Informação) em ambientes de trabalho com PCs interligados em rede, carros em rede, redes de sensores ambientais, Internet interplanetária – quando acharmos que as redes de computadores já estão praticamente presentes em toda parte, novas aplicações começam a ser desenvolvidas para ampliar ainda mais o alcance das redes existentes hoje.
Para Tanenbaum (1997,p.571) o conceito de redes e sua necessidade também estão
expressos como:
[...] Organizações com centenas de escritórios dispersos por uma extensa área geográfica podem analisar o status atual de suas filiais mais remotas. À medida que cresce a capacidade de colher, processar e distribuir informações torna-se ainda maior a necessidade de formas de processamento de informações ainda mais sofisticadas.
O gerenciamento de redes pode ser feito de diversos modos. Entre eles, através de
sistemas centrais de monitoramento que testam os ativos e exibem alertas quando algum
componente falha ou vem a agir de modo inesperado.
Um software de gerência de rede permite aos operadores ou administradores de uma
rede interrogar dispositivos como hosts, roteadores, switches e bridges tentando com isto
determinar seus status ou adicionalmente com o objetivo de obter informações estatísticas
sobre as redes às quais eles se ligam. (COMER, 2007)
Um sistema globalmente utilizado para realizar esta tarefa de gerenciamento de redes é
o software Nagios. O Nagios é um sistema completo de monitoramento, entre suas aplicações
ele também é capaz de realizar ações de coleta de dados e recebimento de alertas a partir de
qualquer dispositivo computacional que atenda requisições por ICMP (Internet Control
Message Protocol – Protocolo de Mensagens de Controle da Internet), SNMP (Simple
Network Management Protocol – Protocolo Simples de Gerência de Redes) ou ainda
13
requisições específicas da camada de aplicação para cada serviço disponibilizado. (BARTH,
2008)
O Nagios é uma plataforma de monitoramento de sistemas e redes de nível
corporativo. Ele realiza checagem dos serviços e hosts utilizando programas externos
chamados plugins Nagios, (ELLISON, 2009).
Uma categoria de equipamento cada vez mais delegado ao departamento de tecnologia
da informação é o sistema de CFTV (Circuito Fechado de Televisão). Estes sistemas são
compostos principalmente por gravadores e câmeras de vídeo que passaram a receber
conectividade por meio de redes de computadores, entretanto, ainda não é comum à
incorporação do gerenciamento deste tipo de recurso nos softwares utilizados atualmente.
O Circuito Fechado de Televisão é uma ferramenta importante para prevenção e
investigação da criminalidade, na prestação de serviços na área de segurança pública e outras
áreas da sociedade. Com os contínuos avanços nesta tecnologia é comum encontrar outras
aplicações onde o CFTV pode ser utilizado. (KEVAL, 2008)
O Nagios possui recursos que permitem a ele ser estendido, possibilitando o
gerenciamento de diferentes tipos de dispositivos através da criação de plugins. Cabe ao
interessado na expansão compreender a sua arquitetura e modelo de desenvolvimento para
então realizar o desenvolvimento das funcionalidades adicionais desejadas. (BARTH, 2008)
A pretensão deste trabalho é de fundamentar e desenvolver o Nagios-Axis Plugin, que
tem como objetivo estender o Nagios para que execute tarefa de monitoramento de Câmeras
Axis modelo P1343.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
A gerência dos ativos de CFTV está se tornando uma responsabilidade dos
departamentos de tecnologia. Uma vez que o Nagios ainda não possui a funcionalidade de
gerenciar câmeras, faz-se necessário estendê-lo por meio de um plugin para que seja possível
a gestão deste tipo de ativo de forma centralizada, isto é, preservando a unicidade do software
de gerenciamento para a infraestrutura toda.
14
1.1.2 Solução Proposta
A solução proposta por este TTC (Trabalho Técnico-científico de Conclusão de
Curso) foi o desenvolvimento do Nagios-Axis-Plugin-p1343 para o gerenciamento das
câmeras de segurança AXIS p1343.
Deste modo, o Nagios é capaz de monitorar o estado de operação da câmera retirando
a obrigatoriedade de utilização de várias interfaces de gerenciamento para os diferentes ativos
e serviços de rede.
O plugin utiliza o sistema de licenciamento já encontrado no Nagios, sendo, portanto,
software de código-fonte aberto nos termos da Licença GNU/GPL (Gnu is Not Unix / General
Public License).
1.2 OBJETIVOS
Este trabalho possui um objetivo geral e sete objetivos específicos.
1.2.1 Objetivo Geral
O objetivo geral deste Trabalho Técnico-científico de Conclusão de Curso (TTC) é
desenvolver um plugin para habilitar a ferramenta Nagios a realizar o gerenciamento de
Câmeras AXIS modelos P1343.
1.2.2 Objetivos Específicos Os objetivos específicos deste projeto de pesquisa são:
1. Realizar a fundamentação teórica do gerenciamento de redes e do Nagios.
2. Compreender a interface de extensibilidade do Nagios através de plugins.
3. Compreender os recursos de gerenciamento oferecidos pela Câmera AXIS P1343.
4. Modelar o plugin de gerenciamento de Câmeras AXIS P1343 para o Nagios.
5. Programar o plugin de gerenciamento de Câmeras AXIS no Nagios
6. Aferir o funcionamento do plugin integrado ao Nagios.
7. Documentar o desenvolvimento e os resultados do sistema.
15
1.3 METODOLOGIA
Foram realizadas diversas pesquisas para compreender qual o modelo mais
comumente utilizado para realização do gerenciamento de redes. Com esta pesquisa além de
outros protocolos que foram conhecidos no decorrer do trabalho e também tiveram
obrigatoriedade na leitura e entendimento, o SNMP foi identificado como o mais utilizado
pelos administradores de redes. O funcionamento do software Nagios e também do seu
recurso de extensão também tiveram que ser pesquisados para que este trabalho chegasse a
uma conclusão.
Foi realizada a busca de informações com a fabricante AXIS para viabilização prática
do projeto do plugin a fim de utilizar o suporte SNMP da câmera P1343. Os materiais
utilizados para a realização da fundamentação teórica foram livros da biblioteca e artigos da
internet.
A modelagem do sistema utilizando a UML (Unified Modeling Language -
Linguagem Unificada de Modelagem) teve como objetivo facilitar o entendimento do escopo
do projeto. Nesta modelagem foram identificados diagramas de atividades, de casos de uso e
os requisitos referentes ao desenvolvimento do trabalho. Para realização desta modelagem
foram utilizados livros da biblioteca e da internet.
A metodologia utilizada na fase de desenvolvimento do TTC II foi baseada em
programar o plugin Nagios para que fosse possível entender a MIB da câmera e estabelecer
comunicação com o dispositivo a fim de capturar as informações para o gerenciamento.
A linguagem na qual o plugin Nagios foi desenvolvido é o Perl de maneira a alcançar
os objetivos que tinham sido propostos no trabalho.
Durante o desenvolvimento do software foi realizada a documentação de diversos
procedimentos e testes de aferição e que foram inseridos no texto final do TTC II.
1.4 Estrutura do trabalho
A Estrutura deste trabalho está composta por quatro capítulos principais: Introdução,
Fundamentação Teórica, Desenvolvimento e Conclusões.
O Capítulo 1, Introdução, demonstra uma visão geral e resumida de suas pretensões.
16
O Capítulo 2, Fundamentação Teórica, aborda os principais assuntos explorados para a
realização e conclusão deste trabalho. Neste capítulo foram apresentados os principais
conceitos sobre gerência e monitoramento de redes e também sobre a ferramenta que serviu
de suporte para o monitoramento da câmera.
O Capítulo 3, Desenvolvimento, aborda o projeto e desenvolvimento do software,
onde estão descritos os requisitos funcionais, não funcionais, diagramas necessários para o
desenvolvimento do plugin, material sobre a infraestrutura instalada, códigos fontes com seus
textos explicativos e uma sessão de testes realizados com o plugin.
O Capítulo 4, Conclusões, aborda uma descrição de como o trabalho foi realizado e
quais os resultados obtidos a partir do trabalho.
17
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo está dividido em 5 seções. A sessão 2.1 descreve e fundamenta o
conceito e a prática de gerência e monitoramento de redes, a seção 2.2 descreve o protocolo
SNMP, a sessão 2.3 descreve e fundamenta a utilização do Software Nagios como escolha
para desenvolvimento do plugin, a sessão 2.4 descreve e fundamenta Web Crawler e a sessão
2.5 descreve a câmera AXIS P1343.
2.1 Gerência de redes
Gerência de redes é a ideia geral do uso de ferramentas, técnicas e sistemas para
auxiliar administradores na gestão e controle de dispositivos, sistemas ou redes. (MAURO;
SCHMIDT, 2005)
Karris (2009) descreve que a gerência da rede de computadores deve objetivar o
fornecimento de uma visão geral do estado de uma rede de computadores e de seu
desempenho. Entretanto, esta visão ampla deve permitir um detalhamento do estado
individual de cada equipamento ou sistema sempre que necessário.
Mauro e Schmidt (2005) defendem que além do aprofundamento, é também necessário
haver mecanismos de medição do desempenho mínimo ou aceitável de cada componente de
rede. Desta maneira é possível realizar diagnósticos e antecipação de uma possível falha ou
previsão de que algum componente está na iminência de falhar.
A gerência da rede implica, portanto na obtenção de valores capturados de
componentes da rede, como sistemas de bases de dados, switches, roteadores ou outros
equipamentos. O objetivo é alimentar a base de informações de um sistema de gerência de
redes, processando os dados, arquivando históricos e exibindo as informações mais relevantes
para os operadores da rede.
O monitoramento é uma ação de leitura para notificação de eventos. Envolve obter um
diagnóstico atual e frequente de cada equipamento ou sistema, a fim de criticar o estado em
que se encontra, ajudando no isolamento e na solução dos problemas. (MCCABE, 2007). A
Figura 1 identifica a composição das redes que utilizam uma estratégia de gerenciamento:
18
Figura 1. Visão ampla da Gerência de redes.
Fonte: Adaptado de Clemm (2007).
Gerência de aplicação: a gerência de aplicação consiste em coletar, por exemplo,
informações de aplicações como bases de dados, etc.
Gerência de Sistema: consiste na gerência de sistemas embarcados, servidores ou
hosts, etc.
Gerência de infraestrutura: consiste na gerência dos equipamentos que compõe a
infraestrutura como roteadores, gateways, switches ou todo equipamento que desempenha
alguma tarefa dentro da rede de computadores.
Segundo Morris (2003), para que se tenha um sistema de gerenciamento de redes
completo se faz necessário à existência de usuário para utilização do sistema, um sistema para
que a gerência seja realizada, um gerente SNMP e agentes SNMP distribuídos.
De maneira a padronizar o estudo e utilização da gerência de redes foi criado um
modelo pela ISO (International Organization for Standardization - Organização internacional
de padronizações). O objetivo deste padrão é auxiliar o entendimento dos benefícios e a
necessidade da gerência de redes como uma ferramenta. Este modelo é chamado de FCAPS
(Fault Management, Configuration Management, Accounting Management, Performance
Management, and Security Management – Gerência de Falhas, Gerência de Configuração,
19
Gerência de Contas, Gerência de Performance e Gerência de Segurança). (MAURO;
SCHMIDT, 2005)
De acordo com Plevyak e Sahin (2010) e Mauro e Schmidt (2005) o conceito da sigla
FCAPS é definido como:
Gestão de falhas – refere-se à gestão de serviços e ativos conectados a rede de
computadores. Esta gestão deve-se estender a todos os serviços oferecidos para a rede de
computadores mesmo os serviços prestados por terceiros, como por exemplo, uma Telecom,
neste caso necessita-se fazer uma gerência de falhas em nível de acordo de serviço.
Gestão de configuração – refere-se ao desenvolvimento, monitoramento e gerência
de configuração de hardware e software nos dispositivos gerenciados ou sistemas, com o
objetivo de manter a operação da rede sem nenhuma parada inesperada.
Gestão de contas – o objetivo da gerência de contas é certificar que todos os recursos
de rede e sistemas estão sendo utilizados de maneira justa por cada usuário ou grupos que
realizam o acesso. Os problemas em sistemas ou redes podem ser minimizados através deste
controle pelo fato que os acessos podem ser ajustados por conhecimento de cada usuário ou
grupo.
Gestão de desempenho – tem por objetivo coletar informações de desempenho dos
ativos ou serviços de rede para que seja realizado o tratamento destas informações e a
notificação no caso de identificação de possíveis problemas.
Gestão de segurança – o objetivo da gestão de segurança é controlar acessos e
protegê-los contra ataques de intrusão de sistemas hosts ou redes.
2.2 Protocolo SNMP
Segundo Morris (2003) um dos esforços feitos na década de 1980 para padronização
da área de gestão de redes foi em relação ao protocolo SNMP que ainda continua a ser um
padrão para o gerenciamento de redes.
O SNMP é um protocolo concebido em 1988 para atender a uma crescente demanda
de um padrão para a gerência de dispositivos que utilizassem o protocolo IP (Internet
Protocol – Protocolo de internet). Ele oferece aos softwares de gerência um conjunto simples
20
de operações a serem utilizadas. O objetivo é identificar o estado dos equipamentos que estão
sendo gerenciados, sendo que, desta maneira é possível relatar todos os problemas e gravar
em bancos de dados para demonstração, utilizando softwares de gestão de redes. (MAURO;
SCHMIDT, 2005)
Segundo Karris (2009) e Morris (2003) o SNMP é um padrão de gerenciamento de
redes adotado globalmente por ser um protocolo leve e moldado para redes TCP/IP.
Os protocolos padrões utilizados no tráfego de informações da internet são definidos
pela IETF (Internet Engineering Task Force – Força Tarefa de Engenharia para Internet) que
é responsável também pela definição do protocolo SNMP. As normas e recomendações
definidas por este órgão são publicadas utilizando documentos denominados RFC (Request
for Comments – Requisição para comentários). (MAURO; SCHMIDT, 2005)
Segundo Mauro e Schimidt (2005) a IETF possui um processo onde toda definição de
normas passa por etapas de avaliação até o momento que elas podem realmente se tornar uma
RFC. O SNMP como qualquer protocolo foi revisado por duas vezes desde a primeira versão
e sofreu alterações conforme as mudanças tecnológicas que ocorreram:
SNMP Versão 1 (SNMPv1): é a versão inicial do protocolo SNMP. As definições
desta versão se encontram na RFC 1157 como um padrão histórico para a IETF. A segurança
do protocolo SNMPv1 baseia-se em senhas de acesso. Estas senhas são strings de texto
simples que permitem acesso a dispositivos que suportem o protocolo SNMP para execução
de três ações básicas: leitura, leitura e escrita e os chamados traps.
SNMP Versão 2 (SNMPv2): esta versão do SNMP está definida na RFC 3416, RFC
3417 e RFC 3418.
SNMP Versão 3 (SNMPv3): além de ser a versão mais atual do SNMP teve uma
grande contribuição na área de segurança oferecendo suporte a autenticação forte e
comunicação privada dentre dispositivos gerenciados. As definições para a versão três do
SNMP estão descritas na RFC 3410, RFC 3411, RFC 3412, RFC 3413, RFC 3414, RFC
3415, RFC 3416, RFC 3417, RFC 3418, e por último na RFC 2576.
O SNMP fornece um método de gerenciamento de hosts, workstations, servidores,
roteadores, bridges e outros diversos equipamentos através de um computador centralizado
executando um software de monitoramento de redes. Ele realiza este trabalho utilizando
21
agentes de gerenciamento que trabalham na captura e envio de informações ao computador
central no qual o sistema de gerenciamento está sendo executado. (KARRIS, 2009)
A Figura 2 ilustra como ocorre esta comunicação entre software de gerenciamento e
agentes de gerenciamento:
Figura 2. Comunicação entre NMS e Agente SNMP.
Fonte: Adaptado de Mauro e Schmidt (2005).
Um agente é um programa que reside no equipamento que está sendo gerenciado para
garantir o envio das informações para o computador centralizado. O núcleo do protocolo
SNMP é composto por um simples conjunto de operações. Estas operações permitem aos
administradores e operadores de rede a capacidade de alterar o estado dos dispositivos que
implementem o suporte a este protocolo. Um exemplo bem prático é a possibilidade de
desabilitar a placa de rede de determinado roteador por exemplo. Antes do desenvolvimento
do SNMP, seu predecessor suportava o gerenciamento apenas de roteadores de internet.
(MAURO; SCHMIDT, 2005)
O SNMP é um protocolo que suporta diversos dispositivos de rede como os sistemas
Unix, sistemas Windows, impressoras, modens de internet, sistemas de alimentação
ininterrupta e muito mais. (MAURO; SCHMIDT, 2005)
O SNMP utiliza o protocolo UDP (User Datagram Protocol – Protocolo de
Datagrama de usuário) para realizar a transferência das informações entre os agentes e os
gerentes SNMP. O protocolo UDP está definido na RFC 768 e é utilizado juntamente com o
protocolo TCP (Transfer Control Protocol – Protocolo de Controle de Transferência). Ele foi
escolhido por não exigir a realização de conexão de ponta a ponta entre Agentes e Gerentes
SNMP quando os datagramas são enviados e recebidos. Este aspecto faz com que o protocolo
UDP seja não confiável por não possuir um acordo de controle quanto a pacotes perdidos no
nível de protocolo. (MAURO; SCHMIDT, 2005)
22
Mauro e Schimdt (2005) ainda afirmam que este, é o SNMP quem deve realizar este
controle, onde ele pode ser configurado para aguardar um período até que receba a resposta da
transmissão, caso ele não receba ele retransmite o pacote. O número de retransmissões de
pacotes também é configurável.
Na Figura 3 é apresentada a comunicação de Gerentes e Agentes SNMP dentro de uma
rede. Ela mostra a pilha do protocolo TCP/IP que qualquer dispositivo que deseja ser
conectado a uma rede de computadores deve implementar incluindo os dispositivos que
suportam o protocolo SNMP.
Figura 3. Comunicação TCP/IP entre NMS e Agente SNMP.
Fonte: Adaptado de Mauro e Schmidt (2005).
A Figura 3 apresenta a seguinte ilustração:
Camada de Aplicação: a camada de aplicação fornece serviços a um usuário final,
como um usuário utilizando um navegador de internet.
UDP: a próxima camada, UDP, permite dois hosts se comunicarem entre si. O
cabeçalho de UDP contém a porta de destino do dispositivo no qual se está a enviando a
mensagem SNMP.
23
IP: a camada IP entrega o pacote SNMP para seu destino, conforme especificado pelo
seu endereço IP.
Protocolo de acesso à rede: a etapa final que deve ocorrer para um pacote SNMP
para chegar ao seu destino é ser encaminhado para a rede física com o objetivo de ser
encaminhado para seu destino final.
Segundo Morris (2003) os principais componentes para o funcionamento do
gerenciamento de redes são os agentes SNMP, os gerentes SNMP e a MIB (Management
Information Base – Base de Informações de Gestão).
2.2.1 Agente SNMP
Qualquer dispositivo executando um software que permite a obtenção de informações
através do protocolo SNMP pode ser gerenciado. Isso inclui não apenas dispositivos físicos,
mas também de software, como serviços de servidores web, bancos de dados e outros.
(MAURO; SCHMIDT, 2005)
Segundo Mauro e Schmidt (2005) este software residente em dispositivos de rede são
os agentes SNMP. Eles são uma parte de software que é executado com o objetivo de fornecer
suporte ao protocolo. Este software pode ser um programa separado, por exemplo, um
daemon em linguagem Unix ou pode ser um programa incorporado ao sistema operacional do
dispositivo, por exemplo, IOS (Internetwork Operating System – Sistema de Operação entre
Redes) da Cisco em um roteador, ou até mesmo o sistema operacional de baixo nível que
controla um nobreak.
Morris (2003) afirma que um agente SNMP pode ser modificado para o
funcionamento em sistemas embarcados como os de um switch ou roteador. Ele também
afirma que este software pode ser acessado por vários mecanismos de comunicação incluindo:
• Serial
• Telnet
• Protocolo SNMP
A inserção destes programas é bem comum na maioria dos dispositivos IP que já
possuem algum tipo de agente SNMP construído para suportar o gerenciamento de redes. O
24
agente fornece informações gerenciais para a NMS (Network Management System – Sistema
de Gerenciamento de Redes), mantendo o controle de vários aspectos operacionais dos
dispositivos de rede. (MAURO; SCHMIDT, 2005)
Segundo Morris (2003) os agentes SNMP são parte importante da gestão de rede e
estão presentes em todos os dispositivos gerenciados em uma rede de computadores. A função
específica deles é ficar escutando na porta UDP 161 para a recepção de mensagens SNMP da
rede e utilizam também a porta UDP 162 para o envio de mensagens de resposta ou
notificação para o gerente de rede. Eles são peças fundamentais para este processo e são
responsáveis por prover as seguintes funcionalidades:
• Manter e implementar a MIB dos objetos gerenciados;
• Responder as operações de gestão tais como requisições do gerente SNMP;
• Gerar notificações do funcionamento dos ativos gerenciados;
• Implementar o suporte as versões anteriores do SNMP;
• Facilitar a definição de políticas de acesso para gestores externos;
Eles têm basicamente a função de escutar na porta UDP 161 por requisições do tipo de
mensagens SNMP:
• Get requisita os valores das instâncias do objeto especificado.
• Get-next requisita os valores dos sucessores léxicos das instâncias do objeto
especificado.
• Get-bulk requisita os valores de partes de uma tabela específica.
• Set modifica um conjunto especificado de valores na instância do objeto
especificado.
2.2.2 Gerente SNMP
Segundo Morris (2003) os gerentes SNMP são entidades que estabelecem
comunicação com os agentes SNMP e devem prover as seguintes funcionalidades:
25
• Leitura e modificação de valores nas instâncias MIB onde residem os agentes
SNMP;
• Recebimento de notificações vindas dos agentes SNMP;
• Comunicação com outros gerentes SNMP na rede;
Mauro e Schmidt (2005) afirmam que um gerente SNMP é basicamente um servidor
que executa algum tipo de software que pode lidar com as tarefas de gerenciamento para uma
rede. Os gerentes são muitas vezes referidos como estações de gerenciamento de rede.
Entende-se, portanto que um gerente de rede ou estação de gerenciamento é o
componente final de uma solução SNMP. É um software que roda em algum equipamento de
rede onde executa requisição de informações aos dispositivos gerenciados, recebe as
informações e trata as informações de diversos ativos de rede que rodam agentes SNMP.
Estas informações podem ser em forma de alertas de que algum problema está ocorrendo.
2.2.3 Management Information Base (MIB)
A MIB é um elemento extremamente importante dentro do gerenciamento de redes por
conter as definições de como se trabalhar com os objetos gerenciados. Ela é uma descrição de
dados de objetos gerenciados e contém a definição da sintaxe (tipos e estruturas) e semântica
dos objetos gerenciados. Os objetos gerenciados são definidos utilizando convenções textuais.
(MORRIS, 2003)
A MIB como qualquer protocolo tem seu histórico de atualizações e já passou por
revisões. Os documentos que definem a MIB e MIBv2 que hoje é a atual versão da MIB são
RFC 1212 e RFC 1213 na mesma ordem.
Todos os objetos MIB têm nomes únicos chamados OID (Object Identifier –
Identificador de objetos). Um OID é uma sequência de 32-bit. A MIBv2 é definida pela ISO
como iso.org.dod.internet.mgmt.1 ou 1.3.6.1.2.1. Segue abaixo o descritivo a árvore da
MIBv2 na Figura 4.
26
Figura 4. Árvore da MIB.
Fonte: Adaptado de Morris (2003).
Todo ativo que suporte gerenciamento SNMP tem em sua MIB alguns atributos
comuns em todas as MIBs. Estes atributos são utilizados com o objetivo de manipulação de
informações da MIB. Os atributos listados abaixo são alguns dos atributos em comum
encontrados nas MIBs:
• SYNTAX;
• MAX-ACCESS;
• STATUS;
• DESCRIPTION;
• DEFVAL;
• OBJECT IDENTIFIER;
27
As MIBs são simples arquivos de texto que são compilados juntamente com o código-
fonte do agente tornando-se parte do arquivo executável. (MORRIS, 2003)
A ordem dos OIDs é um aspecto importante do protocolo SNMP. Todos os objetos
podem ser rastreados a partir da árvore utilizando o processo de caminhada por cada elemento
da árvore MIB. Utilizando este processo de caminhada na árvore da MIB podem ser
descobertos os objetos que a MIB suporta apesar de não ser um método muito utilizado e
também demorado. (MORRIS, 2003)
As MIBs são compostas por vários módulos onde cada módulo é responsável por um
conjunto de objetos relacionados. Nadeau (2003) afirma que organizações como a IETF criam
documentos com o objetivo de normalizar e definir os módulos da MIB para proporcionar
uma interface de gestão padronizada. Os módulos da MIB também definem a sintaxe de
acesso, os níveis de acesso máximos, e interações entre esses objetos definidos no módulo
MIB ou em outros módulos.
Nadeau (2003) ainda afirma que também se deve observar que um módulo MIB é por
vezes referido como "a MIB" em determinados contextos, portanto deve ser tomado cuidado
quando se referir a um módulo da MIB ou a coleção de módulos que compõem a MIB.
Os conceitos de SNMP, Agentes e Gerentes SNMP e MIB podem ser mais bem
visualizados a partir da Figura 5 que detalha mais como a comunicação entre eles acontece.
Figura 5. Comunicação entre Agente e Gerente SNMP e MIBs.
Fonte: Adaptado de Pleviak e Sahin (2010).
28
Os módulos MIB podem ser padronizados e outros patenteados. Um módulo
patenteado é elaborado pelo fabricante de um ativo para armazenar variáveis consideradas
importantes, mas que não fazem parte de nenhum padrão. Os módulos patenteados ficam sob
uma diferente OID que é iso.org.dod.internet.private.enterprises.
2.3 Nagios
Esta sessão tem objetivo de informar os objetivos do Nagios, de seu funcionamento e
como podemos modificá-lo para realizar o monitoramento de um dispositivo específico.
2.3.1 Nagios: Software de monitoramento
Segundo Turnbull (2006) e Josephsen (2007) o Nagios é um software de código livre
licenciado sob a licença General Public License o que o torna livremente disponível e fácil de
estender quando é necessário atender a necessidades específicas de qualquer equipamento ou
serviço.
Turnbull (2006) ainda afirma que o Nagios é uma aplicação utilizada para monitorar
ativos de rede como servidores, dispositivos de rede e também aplicações e serviços,
basicamente qualquer dispositivo que possua conexão com a rede de computadores e possa
ser contatado via TCP/IP.
O Nagios pode monitorar uma variedade de características ou atributos pertencentes
aos ativos de rede. Estes atributos podem ser, por exemplo, o estado da CPU, estado do disco
e também da utilização da memória ou até mesmo o estado das aplicações, arquivos ou bases
de dados. O Nagios pode ser utilizado também para monitorar protocolos de rede onde entre
eles estão os protocolos HTTP, SNMP e também o SSH. (TURNBULL, 2006)
O Nagios constantemente checa o status dos ativos de rede e dos serviços que ele está
monitorando. O propósito principal deste monitoramento e que seja possível detectar e
reportar qualquer sistema com funcionamento incorreto o quanto antes para que o operador ou
administrador de redes possa tomar as providências para efetuar a correção do problema
notificado pelo Nagios. (KOCJAN, 2008)
Na Figura 6 encontra-se a tela principal do Nagios para acesso aos operadores e
administradores de rede.
29
Figura 6. Interface inicial do Nagios.
Segundo Josephsen (2007) a modularidade existente no Nagios faz com que o
procedimento de monitorar tenha uma abordagem simples e também bastante escalável. O
Nagios não tenta fazer tudo o que é preciso no monitoramento de redes, portanto ele se
destaca em interoperabilidade. Ele permite que sejam utilizadas outras ferramentas em
conjunto para trazer melhores resultados, o que o torna muito flexível e de simples aceitação.
A escolha do Nagios como forma de monitoramento significa que o seu esforço de
monitoramento será limitado apenas pela sua própria imaginação, destreza técnica e
habilidade. (JOSEPHSEN, 2007)
Além das ferramentas oferecidas pelo Nagios para se certificar de que seus serviços ou
ativos de rede estão funcionando o Nagios oferece um suporte a plugins que já vem em sua
instalação padrão ou também podemos desenvolver nossos próprios plugins para realizar
30
monitoramento. (KOCJAN, 2008). Na Figura 7 está descrito a chamada de um plugin que
testa os ativos de rede a fim de verificar se eles estão conectados em rede.
Figura 7. Plugin (check_ping) para monitorar a comunicação com a rede de um host.
Fonte: Barth (2008).
O Nagios define que um objeto é qualquer entidade que pode ser gerenciada incluindo
hosts, serviços ou grupos de hosts ou grupos de serviços. Para definição destes objetos existe
um arquivo template que especifica todas as configurações referentes ao objeto fazendo parte
de seu código.
O Nagios plugins é uma coleção de plugins criada por colaboradores para as mais
diferentes funcionalidades. Ele pode ser estendido com a criação de novos plugins
personalizados para situações específicas desejadas pelo operador de rede. Os plugins podem
ser desenvolvidos em qualquer linguagem de desenvolvimento. (JOSEPHSEN, 2007)
Um plugin Nagios é um software que provê um código de saída específico conforme
definido na Tabela 1.
Tabela 1. Retornos aceitáveis pelo Nagios.
Valor Cor Descrição
0 VERDE OK.
Sistema respondeu conforme esperado pelo administrador de redes.
1 AMARELO WARNING.
O sistema apresentou alguma falha ou está com algum valor que deve ser notado pelo administrador no momento do monitoramento.
2 MARRON UNKNOWN.
Valor desconhecido pelo Nagios, necessita verificação do administrador.
3 VERMELHO CRITICAL.
Valor de retorno execeu os limites impostos na programação do plugin retornando esta informação.
null CINZA PENDING. Este estado pode estar presente quando o servidor é reiniciado e o Nagios ainda não fez nenhuma verificação do estado do dispositivo.
Fonte: Josephsen (2007).
31
Com o retorno de um plugin sendo um inteiro de zero a três, é possível tratar esta
informação e mostrar os resultados da consulta no Nagios. Os códigos de saída são comuns
em linguagens de desenvolvimento ou de script. (JOSEPHSEN, 2007)
Plugins para o Nagios representam serviços que devem ser monitorados de tempos em
tempos. Eles devem ser especificados no arquivo de configuração de serviços do host e
também outras informações como o identificador do serviço, frequencia de execução etc.
(JOSEPHSEN, 2007)
O código da template está descrito na Figura 8.
Figura 8. Template de definição de um objeto no Nagios.
Fonte: Barth (2008).
O object-type utilizado na definição do objeto do Nagios possui parâmetros pré-definidos para utilização. Conforme Tabela 2, seguem informações com as opções válidas para utilização do object-type.
32
Tabela 2. Tipos de valores aceitos no object-type.
Object-type Descrição Host A opção host descreve um dos nós da rede que deverá ser monitorado.
O Nagios necessita da informação do número IP do host ou do seu nome identificador na rede e o comando que deve definir se o host possuí ou não conexão com a rede.
Hostgroup Este tipo de objeto simplifica a configuração pelo fato de que um grupo de hosts pode ser referenciado unicamente ao invés de cada host ter sua definição única.
Service Objetos de serviço ao serem monitorados são definidos como service. Um serviço nunca pode existir sem um host para hospeda-lo, portanto é comum existir objetos com o mesmo nome, mas que estão hospedados em diferentes hosts. Na linguagem do Nagios um serviço deve ser encarado sempre como um um par entre host e serviço.
Servicegroup Da mesma maneira que acontece com os hosts o Nagios também pode combinar grupos de serviços para simplificar sua configuração.
Contact Um administrador de redes ou qualquer outro contato que deva ser informado quanto a eventos específicos que possam ocorrer. Esta configuração existe para que cada contato possa visualizar apenas os objetos nos quais tem responsabilidade.
Contactgroup Quando um evento ocorre o grupo de contatos pode ser informado. timeperiod Define um período onde os eventos podem ser enviados aos contatos.
Fora deste horário especificado o Nagios não enviará nenhuma informação. Podem ser especificadas diversas faixas de horários dependendo do host ou serviço.
command O Nagios sempre utiliza este tipo de objeto para executar programas externos. Ele pode executar estes programas por diversos meios incluindo plugins.
Servicedependency Este objeto descreve dependências entre serviços para execução. Um exemplo caso um sistema não funcione sem o serviço de base de dados iniciado o Nagios deve garantir que esta informação deverá aparecer para o operador.
Servicescalation Se um serviço não está disponível após um determinado período de tempo o Nagios pode informar a um grupo de contatos, caso este serviço continue indisponível até atingir outro período de tempo o Nagios pode informar a outro grupo de contatos. Desta maneira é possível configurar o sistema em diferentes níveis.
Hostdependency Da mesma maneira que o servicedependency, mas este funciona com hosts.
Hostescalation Da mesma maneira que o serviceescalation, mas este funciona com hosts.
Hostextinfo Extended Host Information é opcional e define um gráfico com informações opcionais diferentes dos gráficos utilizados por padrão pelo Nagios.
Serviceextinfo Da mesma maneira que o hostextinfo, mas este funciona com hosts.
Fonte: Barth (2008).
Para definição de um objeto do Nagios devem-se utilizar além do object-type outros
parâmetros a fim de identificar informações referentes ao host que deseja gerenciar e também
33
qual o objetivo deste gerenciamento. Para cada tipo de objeto pode haver diferentes
parâmetros que devem ser inseridos na configuração do objeto. (BARTH, 2008)
Para ilustrar a configuração de objetos verifique abaixo a configuração de um objeto
tipo host na Figura 9.
Figura 9. Definição de um objeto tipo host no arquivo de configuração do Nagios.
Fonte: Adaptado de Barth (2008).
Portanto a flexibilidade do Nagios permite que mesmo com as ferramentas disponíveis
por padrão ainda assim seja possível o desenvolvimento de plugins e a integração de outras
ferramentas externas. Com estes recursos é possível apresentar resultados mais detalhados
para o administrador de redes que consegue mitigar os problemas com mais tranquilidade.
2.4 Web Crawler
Web crawler é um programa de computador que realiza navegação por uma
determinada página de internet com o objetivo de buscar informações. Outros termos que
também podem ser utilizados para Web crawlers são indexadores automáticos, bots, web
spiders, Web robot, ou Web scutter. (SCHRENK, 2012)
34
O processo executado por um Web Crawler é chamado de Web crawling ou spidering.
A maioria dos buscadores da internet utilizam crawlers para manter uma base de dados
atualizada.
Os crawlers tem como objetivo realizar uma cópia das páginas visitadas para
realização de um pós-processamento. Os crawlers também podem ser usados para tarefas de
manutenção automatizadas em um website. Uma destas tarefas pode ser checar os links ou
validar o código HTML. Os crawlers também podem ser usados para obter tipos específicos
de informação das páginas da Web, como minerar endereços de email. (CALISHAIN;
HEMENWAY, 2003)
Um Web crawler é um processo que funciona como agente de software. Ele inicia com
uma lista de URLs para visitar e à medida que o crawler visita essas URLs ele identifica os
links contidos na página e os adiciona na lista de URLs para visitar. Estas URLs são visitadas
recursivamente de acordo com um conjunto específico de regras. (CALISHAIN;
HEMENWAY, 2003)
Um processo de crawling será utilizado neste trabalho afim de estabelecer uma
conexão com o webserver da câmera Axis e realizar a busca de algumas informações
interessantes. As informações que serão capturadas não estão disponíveis na MIBv2.
2.4.1 cURL
O cURL é um projeto de software que provê uma biblioteca e uma linguagem via
linha de comando para que seja possível realizar cópia das informações de arquivos de
páginas web utilizando vários protocolos. O projeto cURL apresenta dois produtos, um é a
biblioteca libcurl e o outro é o cURL. O seu desenvolvimento foi iniciado em 1997.
Ele é utilizado globalmente e seu objetivo é acessar arquivos de websites através de
protocolos. (SCHRENK, 2012)
O cURL é um projeto de código aberto e um produto do desenvolvedor sueco Daniel
Stenberg e seu time de desenvolvedores. A Biblioteca cURL está disponível para qualquer
linguagem de desenvolvimento. (SCHRENK, 2012)
35
O nome cURL é uma junção de client e URL (Universe Resource Locator –
Localizador de Recursos Universal) ou um acrônimo de client URL Request Library.
(SCHRENK, 2012)
Libcurl, é uma biblioteca livre para o transporte de dados entre um servidor de um
cliente multidirecional e pode ser utilizado com os protocolos HTTP e HTTPS dentre as
tecnologias suportadas.. A biblioteca suporta certificados HTTPS e HTTP.. (STENBERG,
2012)
A biblioteca libcurl é portátil. Ela funciona de maneira idêntica em várias plataformas.
Ela é livre, compatível com o IPv6 (Internet Protocol Version Six – Protocolo de Internet
Versão Seis) e rápida. O cURL é uma ferramenta de linha de comando para obter ou enviar
arquivos utilizando a sintaxe URL.
2.5 A câmera AXIS P1343
A AXIS é uma empresa de Tecnologia da Informação que oferece soluções de vídeo
em rede para instalações profissionais utilizando iniciativas de vídeo sobre IP. Ela oferece
produtos para vigilância e monitoramento de câmeras de segurança. (AXIS, 2011)
A Câmera de Rede AXIS P1343-E é uma câmera fixa para dia e noite que oferece
excelente desempenho H.264 e possui um design robusto.
Ela oferece qualidade de vídeo superior com varredura progressiva em vários fluxos
H.264 individuais, bem como fluxos Motion JPEG(Joint Photographic Experts Group –
Grupo de Conhecedores de Fotografia). O assistente de foco, o foco posterior remoto e o
contador de pixels simplificam a instalação do equipamento. (AXIS, 2012)
Os recursos oferecidos por este modelo de câmera são inúmeros se tornando possível
obter um controle maior sobre o gerenciamento do hardware do equipamento.
• Recursos inteligentes: detecção de movimento por vídeo avançado, detecção de áudio
e detecção de tentativas de violação contra a câmera, como bloqueios ou pichações.
• Power over Ethernet, que elimina a necessidade de cabos de força e reduz custos de
instalação utilizando-se switches que fornecem energia ao equipamento diretamente.
• Suporte a áudio bidirecional.
36
• Recursos avançados de segurança e gerenciamento de rede, como criptografia HTTPS
com desempenho preservado, suporte a IPv6e Qualidade de Serviço.
• API (Application Programming Interface – Interface para desenvolvimento de
aplicações) para desenvolvimento aberta para integração de outros softwares, inclusive
VAPIX da Axis.(AXIS, 2012)
A Figura 10 mostra uma imagem lateral da câmera que será gerenciada pelo Nagios:
Figura 10. Imagem lateral da câmera p1343.
Fonte: AXIS (2012).
A Figura 11 mostra uma imagem frontal da câmera que será gerenciada pelo Nagios:
37
Figura 11. Imagem frontal da câmera p1343.
Fonte: AXIS (2012).
O VAPIX é uma API aberta da AXIS que permite a ela uma melhor integração com
qualquer sistema de informação. Ela permite flexibilidade, scalabilidade soluções com custo
benefício mais eficiente e com um futuro promissor.
Todas as câmeras AXIS possuem uma interface de desenvolvimento para trabalhar com
uma interface HTTP. Dentre outros recursos oferecidos pela API VAPIX ela possui recursos
para captura de imagens das câmeras e modificação de parâmetros da câmera com o objetivo
de ser facilmente integrada a outros sistemas.
2.5.1 Ferramentas similares
A tecnologia de câmeras IP ainda não é muito antiga, por isto muitas informações nas
quais serão utilizadas neste trabalho tem como fonte de informação site de fabricantes. Como
forma de levantamento de ferramentas similares o número de aplicações para realizar o
gerenciamento do hardware da câmera Axis não trouxe nenhuma ferramenta que fizesse o que
está proposto neste projeto. Desta maneira optou-se por comparar sistemas que façam um
misto de gerenciamento de hardware e também de monitoramento de imagens das câmeras.
As ferramentas encontradas seguem abaixo:
• IP Axis IP
38
• AXIS Camera Station
2.5.1.1 IP Axis IP
A aplicação IP AXIS IP tem como objetivo encontrar e exibir os dispositivos da marca
Axis descobertos em sua rede por ele. O aplicativo também é usado para definir manualmente
endereços IP estáticos e para acessar a página inicial da unidade em configurações
posteriores. Conforme Figura 12.
Figura 12. Interface do software IP Axis IP.
Fonte: AXIS (2012).
2.5.1.2 Axis Camera Station
A aplicação AXIS Camera Station é um sistema de monitoramento e gravação que
pode se estender até cem câmeras. Sua utilização deve ser realizada em um PC comum, é
ideal para pequenas e médias infraestruturas. Ele oferece instalação e configuração fáceis,
com reconhecimento automático de câmeras, um assistente para configuração e
gerenciamento dos produtos de vídeo em rede Axis no sistema. O software abrange a
utilização de três idiomas diferentes.
39
Para eliminar problemas de compatibilidade e assegurar o tempo de funcionamento do
sistema, o AXIS Camera Station foi desenvolvido para ser compatível com a ampla variedade
de produtos de rede e recursos de produto Axis. Conforme Figura 13.
Figura 13. Interface do software Axis Camera Station.
Fonte: AXIS (2012).
Ele possuí suporte para compactação de vídeo H.264 e acionadores de alarme com
base na câmera, como detecção de movimento, Cross Line Detection, permitem a otimização
da largura de banda e da eficiência de armazenamento. Suporte para gravação "fail-over" e
alarme contra violações em câmeras com cartão SD/SDHC protegem ainda mais a operação
do sistema.
40
3 DESENVOLVIMENTO
Nesta sessão encontra-se o projeto do plugin desenvolvido. Foi utilizado a UML
(Unified Modeling Language – Linguagem de Modelagem Unificada) para melhor ilustração
do escopo do projeto.
Segundo Sommerville (2011) a engenharia de software tem como objetivo apoiar o
desenvolvimento profissional de software, ao invés do desenvolvimento individual. Ela possui
técnicas que fornecem suporte a especificação de software, design e evolução, onde nenhuma
destas técnicas é normalmente empregada quando o desenvolvimento de software é individual
ou pessoal.
O produto final gerado através deste trabalho é um plugin Nagios para utilização por
administradores ou operadores de rede. Um exemplo do escopo do trabalho está descrito
abaixo na Figura 14.
Figura 14. Definição do escopo do trabalho a ser desenvolvido.
41
3.1 Requisitos Funcionais, Não Funcionais e Regras de Negócio
Os Requisitos Funcionais, Não Funcionais e as Regras de Negócio são descrições do
que o sistema deve realizar e dos serviços e as restrições que podem ser encontradas no seu
funcionamento. Esta descrição reflete nas necessidades dos usuários do sistema que podem
utiliza-lo para controlar ou monitorar um equipamento ou encontrar uma determinada
informação. (SOMMERVILLE, 2011).
Este capítulo irá apresentar as definições do projeto e que devem ser seguidas durante
o seu desenvolvimento. Ele visa demonstrar os requisitos funcionais, não funcionais e as
regras de negócio do plugin Nagios que estão descritos nas próximas sessões.
3.1.1 Requisitos Funcionais
Os requisitos funcionais devem apresentar os recursos que o sistema deve possuir para
o atendimento do objetivo ao que ele se propõe. A seguinte lista de requisitos funcionais foi
identificada para a execução deste projeto de desenvolvimento.
• RF01. O plugin deverá estabelecer comunicação com a MIB da câmera via SNMP.
• RF02. O plugin deverá permitir a captura de informações para que seja possível identificar se a câmera está on-line ou não.
• RF04. O plugin deverá enviar as informações capturadas da câmera para gravação ao sistema Nagios.
• RF05. O plugin deverá permitir a captura dos logs de reinicialização da câmera quando as configurações do equipamento forem modificadas.
• RF06. O plugin deverá permitir a captura dos logs de reinicialização da câmera quando as configurações do equipamento não forem modificadas.
• RF07. O plugin deverá permitir a captura dos logs de falha de autenticação na câmera.
3.1.2 Requisitos Não Funcionais
42
A seguinte lista de requisitos não funcionais foi identificada para a execução deste
projeto de desenvolvimento. O tipo dos requisitos está entre parênteses.
• RNF01. O plugin deverá utilizar o Nagios como software host para que ele
seja executado. (Software)
• RNF02. O sistema cliente deverá acessar a interface do NMS por um browser
de internet. (Software)
• RNF03. O servidor de bases de dados utilizado pelo Nagios será o MySQL.
(Software)
• RNF04. O servidor web utilizado pelo Nagios será o Apache. (Software)
• RNF05. O controle de acesso ao plugin será gerenciado pelo sistema de
autenticação do Nagios. (Segurança)
• RNF06. O servidor que hospedará o plugin deverá oferecer suporte as
linguagens PHP, C, Perl e bash. (Software)
• RNF07. O SO do servidor que hospedará o plugin deverá ser Linux.
(Software)
• RNF08. Tanto o servidor que hospedará o plugin quanto a câmera da AXIS
devem apresentar conexão com a rede de computadores. (Hardware)
•
• RNF09. O servidor que hospedará o plugin poderá ser hospedado em servidor
físico ou servidor virtual. (Hardware)
3.1.3 Regras de Negócio
A seguinte lista de Regras de Negócio foi identificada para a execução deste projeto de
desenvolvimento.
• RN01. O operador de rede poderá solicitar atualização das informações
utilizando o plugin a qualquer momento.
43
• RN02. O tempo máximo (time out) para consulta de informações das câmeras
deverá ser de cinco segundos.
• RN03. O operador deverá ser previamente cadastrado na base de dados do
Nagios para poder acessar o plugin.
3.2 Diagrama de Casos de Uso
A modelagem utilizando casos de uso foi originalmente desenvolvida na década de
1990 e foi incorporada na primeira versão da UML. Ela é largamente utilizada para dar
suporte ao levantamento de requisitos. (SOMMERVILLE, 2011).
Um caso de uso pode ser extraído como um simples cenário demonstrando o que um
usuário espera de um sistema. Cada caso de uso representa uma tarefa discreta que envolve
uma interação com um sistema. Um diagrama de casos de uso deve prover uma simples e
sucinta visão de uma interação, portanto é necessário que sejam informados mais detalhes do
que realmente o caso de uso se propõe. Este detalhamento pode ser uma simples descrição
textual ou uma descrição estruturada em uma tabela. (SOMMERVILLE, 2011).
Segue o diagrama de casos de uso construído para o plugin Nagios a ser desenvolvido
está descrito na Figura 15.
44
Figura 15. Diagrama de casos de uso do plugin Nagios.
Na próxima sessão é demonstrada a descrição dos diagramas de casos de uso.
3.2.1 UC01.01 Solicita informações da câmera
O caso de uso desta sessão tem como objetivo a captura de informações da câmera.
Relações
• RF05. O plugin deverá permitir a captura dos logs de reinicialização da câmera
quando as configurações do equipamento forem modificadas.
• RF06. O plugin deverá permitir a captura dos logs de reinicialização da câmera
quando as configurações do equipamento não forem modificadas.
• RF07. O plugin deverá permitir a captura dos logs de falha de autenticação na
câmera.
• RN01. O operador de rede poderá solicitar atualização das informações
utilizando o plugin a qualquer momento.
uc PCT01 - Funcionamento do Plugin
Plugin Nagios p1344
Operadores Nagios
UC01.02 Verifica
conectiv idade da
câmera
Câmera
UC01.01 Solicita
informações da câmera
45
Condições
• Pré-Condição: O operador do sistema deverá ter realizado o login no Nagios.
• Pós-condição: As informações são capturadas com sucesso e salvas na base de
dados do Nagios.
Cenários
Busca informações na câmera {Principal}
1. Nagios solicita a busca de informações na câmera.
2. Plugin envia mensagens SNMP para captura das informações.
3. As informações são capturadas com sucesso
4. O Nagios salva o resultado da captura em sua base de dados.
Problema de conexão {Exceção}
1. No passo 2, ao efetuar a captura de informações da câmera, caso ela perca
conectividade deverá retornar uma mensagem de falha ao Nagios.
3.2.2 UC01.02 Verifica conectividade da câmera
O caso de uso desta sessão realiza o teste de comunicação com a câmera pela rede a
fim de iniciar a captura das informações de gerenciamento do dispositivo.
Relações
• RF01. O plugin deverá estabelecer comunicação com a MIB da câmera via
SNMP.
• RF02. O plugin deverá permitir a captura de informações para que seja
possível identificar se a câmera está on-line ou não.
46
Condições
• Pré-Condição: O operador do sistema deverá ter realizado o login no Nagios.
• Pós-condição: A conectividade da câmera é verificada e retorna informação de
êxito.
Cenários
Verifica conectividade da câmera com a rede {Principal}
1. Nagios verifica a conectividade com a câmera através da rede.
2. Câmera retorna informação com sucesso.
Câmera não responde quanto ao teste de conectividade {Exceção}
1. No passo 2, após a verificação da conectividade da câmera, caso a câmera não
responda em 5 segundos o Nagios deverá mostrar ao operador uma mensagem
de erro ou falha na conectividade.
3.3 Desenvolvimento do plugin
Nesta etapa do trabalho os esforços foram centralizados na criação da estrutura
necessária para o desenvolvimento do plugin, na comunicação do Nagios com a camera AXIS
e na visualização dos resultados dentro da interface do Nagios.
3.3.1 Ferramentas utlizadas para o desenvolvimento
O desenvolvimento deste trabalho foi possível utilizando algumas ferramentas
disponíveis por padrão no sistema operacional Linux ou realizando a instalação de softwares
adicionais. A estrutura para desenvolvimento empregou as seguintes ferramentas:
• Ubuntu Server 12.04
• Apache 2.2.22
• PHP 5.3.10-1
• mySQL 14.14
• Nagios 3.4.1
47
• Nagios Plugins 1.4.15
• Perl 5.14.2
• Vim 7.3.429
Os softwares citados na listagem acima tiveram expressiva importância no
desenvolvimento da pesquisa sobre o Nagios e como seria possível estende-lo para criação e
customização de um plugin para uma necessidade específica.
3.3.2 Configuração do Nagios
O Nagios é uma ferramenta de monitoramento que possibilita ter sua configuração
modificada para atender a diferentes tipos de ativos de rede. Para o monitoramento do
hardware da câmera foi necessário realizar modificação em alguns de seus arquivos de
configuração com o objetivo de identificação da câmera na rede de computadores e iniciar o
seu monitoramento.
As configurações realizadas no Nagios que estão descritas neste documento são parte
integrante da pesquisa científica realizada para o desenvolvimento deste trabalho.
O arquivo “templates.cfg“ é responsável pela criação de padrões de objetos (services,
hosts, contacts) dentro do Nagios. Todos os objetos instanciados seguem as configurações
básicas inseridas neste arquivo. Conforme Figura 16.
Figura 16. Arquivo templates.cfg responsável pela criação de objetos padrão no Nagios.
48
As informações abaixo descritas servem para descrever as opções inseridas no quadro
anterior.
• Linha ‘name’ – Nome do template do host.
• Linha ‘use’ – Informa que o objeto herdará os valores padrões de generic-host.
• Linha ‘check_period’ – Período de monitoramento do host.
• Linha ‘check_interval’ – Período para revalidar as informações de monitoramento.
• Linha ‘retry_interval’ – Tempo para o plugin refazer a tentativa de validar as
informações de monitoramento.
• Linha ‘max_check_attempts’ – Vezes para realização de nova tentativa de revalidar o
monitoramento.
• Linha ‘check_command’ – Comando padrão executado com objetivo de checar se o
host está comunicável pela rede.
• Linha ‘notification_period’ – Período para envio de notificações ao operador.
• Linha ‘notification_internval’ – Período para tentar reenviar uma notificação.
• Linha ‘notification_options’ – Opções especiais de notificação.
• Linha ‘contact_groups’ – Grupo para contato.
• Linha ‘register’ – Informa se será necessário registrar ou se será apenas um template.
O arquivo “commands.cfg“ é responsável pela chamada de cada plugin Nagios para
execução. Cada comando definido pode ou não trazer argumentos a serem repassadas no
momento da execução dos plugins. Veja Figura 17.
49
Figura 17. Arquivo commands.cfg do Nagios.
As informações abaixo descritas servem para descrever as opções inseridas no quadro
anterior.
• Linha ‘command_name’ – Nome do comando.
• Linha ‘command_line’ – Chamada para o plugin repassando as informações
necessárias.
O arquivo “cameras.cfg“ foi o arquivo criado com a responsabilidade de fornecer as
informações de host, hostgroup e services configurados para a câmera. Neste caso o gestor ou
operador de redes é instruído para que o nome do arquivo possa identificar o objeto a ser
monitorado. A Figura 18 mostra as informações de definição de host para o Nagios.
Figura 18. Define um host no arquivo de configuração cameras.cfg.
50
As informações abaixo descritas servem para descrever as opções inseridas no quadro
anterior.
• Linha ‘use’ – Herda informações do tipo generic-camera.
• Linha ‘host_name’ – Informa o hostname do dispositivo.
• Linha ‘alias’ – Apelido que deverá ser utilizado pelo Nagios para identificação.
• Linha ‘address’ – Endereço IP do dispositivo.
• Linha ‘hostgroups’ – Grupo ao qual o host pertence.
O hostgroup é importante pois ele é utilizado pelo Nagios para mostrar informações
estatísticas por cada grupo de hosts. As informações de hostgroup estão descritas na
Figura 19.
Figura 19. Define um hostgroup no arquivo de configuração cameras.cfg.
As informações abaixo descritas servem para descrever as opções inseridas no quadro
anterior.
• Linha ‘hostgroup_name’ – Nome do grupo de hosts.
• Linha ‘alias’ – Apelido utilizado para o grupo de hosts.
Serviços são responsáveis por cada objeto a ser monitorado. As informações de
service estão descritas na Figura 20.
51
Figura 20. Define um service no arquivo de configuração cameras.cfg.
As informações abaixo descritas servem para descrever as opções inseridas no quadro
anterior.
• Linha ‘use’ – Informa de qual template herdará os valores padrão.
• Linha ‘host_name’ – Informa o hostname do equipamento.
• Linha ‘service_description’ – Descrição do serviço.
• Linha ‘check_command’ – Comando executado no momento de cada monitoramento.
Veja o arquivo commands.cfg.
• Linha ‘normal_check_interval’ – Tempo para cada nova checagem.
• Linha ‘retry_check_interval’ – Tempo para cada nova rechecagem.
O arquivo “nagios.cfg“ é responsável por carregar na memória todas as configurações
dos arquivos explicados anteriormente.
Caso as configurações em algum destes arquivos seja modificada, para que elas sejam
aplicadas é necessário reiniciar o serviço do Nagios. O código abaixo demonstra a chamada
do arquivo cameras.cfg conforme a Figura 21.
Figura 21. Arquivo nagios.cfg do Nagios.
• Linha ‘cfg_file’ – Informa o caminho do novo arquivo de configurações que o Nagios
deverá carregar no momento da sua execução.
52
3.3.3 Desenvolvimento do plugin Nagios
Para desenvolver um software que tenha como recurso a comunicação via protocolo
SNMP com dispositivos de rede, foi necessário realizar uma busca por bibliotecas para
conexão com o dispositivo e também para tratamento dos dados e retorno das informações
desejadas.
Portanto foi utilizado o CPAN (Comprehensive Perl Archive Network – Rede
Abrangente de Bibliotecas Perl). Ele contém uma biblioteca atualizada e de uso livre de
módulos que extendem e aumentam a utilidade da linguagem Perl.(YOUNG, LINDNER,
KOBES, 2002)
A comunidade de usuários e desenvolvedores da linguagem trabalha criando módulos
para abstrair toda a complexidade das tarefas. Perl possui ferramentas e bibliotecas para
manipulação de dados e está disponível em quase todos os sistemas operacionais modernos e
principalmente tem suas origens visivelmente similares aos sistemas Unix e também a
linguagem C. (EDELMAN, 2009)
Esta seção tem como objetivo descrever as partes do desenvolvimento e detalhar
pontos importantes.
Começando pelo arquivo check_snmp-uptime.pl que foi desenvolvido para capturar o
uptime do equipamento. As bibliotecas que foram utilizadas para o funcionamento deste
arquivo de plugin estão listados no Quadro 1 abaixo:
1 2 3 4 5 6
#! /usr/bin/perl use Nagios::Plugin; use Nagios::Plugin::Getopt; use Net::SNMP; use strict; use warnings;
Quadro 1. Bibliotecas utilizadas no arquivo check_snmp-uptime.pl.
O módulo Nagios::Plugin foi desenvolvido para facilitar e padronizar a criação de
plugins e é mantido pelo grupo de desenvolvimento do Nagios.
53
Um plugin para ser desenvolvido utilizando este módulo deve instanciar um novo
objeto Nagios::Plugin recebendo as informações necessárias para execução do mesmo por
parâmetro.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
my $np; my $VERSION = '0.1.6'; $np = Nagios::Plugin::Getopt->new( usage => "Usage: %s [-H <HOST>] [-U] [-M]", version => $VERSION, ); $np->arg( spec => "host|H=s", help => "Inform the ipaddress/hostname ...", required => 1, ); $np->arg( spec => "uptime|U", help => "Verify the device uptime ...", ); $np->arg( spec => "mac|M", help => "Verify the MAC Address ...", ); $np->getopts();
Quadro 2. Código utilizado para uso da biblioteca Nagios::Plugin.
• Linha 1 até 2 – Criação da variável $VERSION para inserir a versão do plugin e
variável $np para receber as informações de execução.
• Linha 3 até 7 – Atribuição das informações que deverão ser repassadas ao plugin por
parâmetro para execução.
• Linha 8 até 17 – Criação de argumentos para passar no momento da execução do
plugin.
• Linha 18 – Linha que captura as informações repassadas via parâmetro para execução
do plugin.
O SNMP possui recursos de comunicação e extração de informações importantes para
a administração de redes através da MIB. Um dos objetos que podem ser contactados por um
gerente SNMP é o uptime que significa o tempo em que o equipamento está ligado desde sua
última ativação. A câmera Axis fornece esta informação via SNMP já que utiliza a MIBv2
padrão.
A função que retorna o uptime inserida no arquivo check_snmp-uptime.pl está descrita
no código abaixo. Conforme descreve o Quadro 3.
54
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
sub getUptime { my $OID_sysUpTime = '1.3.6.1.2.1.1.3.0'; my ($host) = @_; my ($session, $error) = Net::SNMP->session( -hostname => shift || $host, -community => shift || 'public', ); if (!defined $session) { printf "[PROBLEM DETECTED] %s.\n", $error; exit 1; } my $result = $session->get_request(-varbindlist => [ $OID_sysUpTime ],); if (!defined $result) { printf "[PROBLEM DETECTED] %s.\n", $session->error(); $session->close(); exit 1; } printf "[OK] - The sysUpTime for '%s' is %s.\n", $session->hostname(), $result->{$OID_sysUpTime}; $session->close(); exit 0; } if ($np->get('uptime')) { my $host = $np->get('host'); getUptime($host); }
Quadro 3. Subrotina getUptime e sua chamada.
• Linha 4 – Instanciadas as variáveis $session, $error que devem receber o resultado da
conexão no dispositivo. A variável $session contém a informação se foi possível ou
não executar a conexão.
• Linha 8 até 13 – Executados os testes de conteúdo da variável $session. Neste ponto já
existe a possibilidade do plugin retornar um exit code com o conteúdo ‘1’,
significando problema na conexão.
• Linha 18 até 21 – Impresso o resultado positivo com o uptime do equipamento, retorna
exit code como ‘0’.
• Linha 14 até 27 – Chamada para a funçao getUptime que envia informações
repassadas pelo plugin por parâmetro.
O arquivo check_snmp-network2.pl foi desenvolvido com o objetivo de capturar
informações de rede como endereço IP, máscara de rede e Gateway configurados na câmera
Axis.
55
O retorno deste plugin trás juntamente com as informações solicitadas as OID’s
relacionadas a cada uma das informações conforme mostrado no Quadro 4.
1 2 3 4 5 6 7 8 9 10 11
if ($np->get('network')) { my $host = $np->get('host');my $mask = `snmpget -v1 -c public 192.168.2.90 1.3.6.1.2.1.4.20.1.3.$host`; my $ip = `snmpget -v1 -c public 192.168.2.90 1.3.6.1.2.1.4.20.1.1.$host`; my $gw = `snmpget -v1 -c public 192.168.2.90 1.3.6.1.2.1.4.21.1.7.0.0.0.0`; print "[OK] - See detailed status.\n\n SNMP OID + Device Ip Address: \n--- * ".$ip. "\nSNMP OID + Netmask: \n--- *".$mask. "\nSNMP OID + Gateway: \n--- *".$gw;
Quadro 4. Função de impressão do plugin check_snmp-network2.pl
• Linha 2 até 7 – É realizado a atribuição dos resultados dos comandos do sistema
operacional snmpget para as variáveis $host, $ip, $gw.
• Linha 8 até 11 – É realizado a impressão de conteúdo das variáveis acima
mencionadas na saída padrão.
O arquivo check_snmp-network3.pl foi desenvolvido com o objetivo de capturar
informações da tabela de roteamento da câmera descritas na MIBv2 e capturar estatísticas de
envio e recebimento de dados utilizando a interface de rede da câmera.
Neste arquivo foi utilizada a biblioteca Net::SNMP::HostInfo para conexão ao
dispositivo via SNMP e para a busca de informações.
Segue parte do código deste arquivo conforme Quadro 5.
1 2 3 4 5 6 7 8 9 10 11
$hostinfo = Net::SNMP::HostInfo->new(Hostname => $host); print "Address Table:\n"; for $addr ($hostinfo->ipAddrTable) { printf "Ip: %-15s \n - Mask: %-15s\n - Datagram Size: %5s\n", $addr->ipAdEntAddr, $addr->ipAdEntNetMask, $addr->ipAdEntReasmMaxSize; }
Quadro 5. Definição de objeto Net::SNMP::HostInfo. Imprime da tabela de rotas.
56
• Linha 1 - Foi criado um objeto Net::SNMP::HostInfo para que fosse possível capturar
as informações e imprimir na saída padrão.
• Linha 8 até 10 - Impressão do endereço IP, Máscara de rede e tamanho máximo do
segmento de rede para cada uma das interfaces existentes na tabela de roteamento da
câmera.
Ainda no arquivo check_snmp-network3.pl o plugin fornece a seguinte visão
estatística de acordo com os dados coletados através de SNMP fornecidos pela MIBv2 da
câmera Axis. Conforme Tabela 3 abaixo.
Tabela 3. Listagem de números estatísticos fornecidos via MIBv2.
Função Perl Descrição
ipInReceives O número total de datagramas de entrada recebidos a partir de interfaces, incluindo os que são recebidos com erro.
ipOutRequests
O número total de datagramas IP que protocolos locais (incluindo ICMP) fornecem para o IP em pedidos de transmissão. Este contador não inclui quaisquer datagramas já contados em ipForwDatagrams.
tcpInSegs Número total de segmentos TCP recebidos. tcpOutSegs Número total de segmentos TCP enviados.
tcpRetransSegs O número total de segmentos retransmitidos - ou seja, o número de segmentos TCP transmitidos contendo um ou mais octetos transmitidos anteriormente.
udpInDatagrams Número total de Datagramas UDP recebidos. udpOutDatagrams Número total de Datagramas UDP enviados.
Fonte: CPAN (2012).
O código referente a estas informações tem como objetivo apenas utilizar a conexão
que já foi realizada no começo da execução do plugin e também realizar a impressão de
retorno de métodos existentes no módulo Net::SNMP::HostInfo existente para o Perl.
Pode-se verificar as informações referentes ao arquivo check_snmp-network3.pl
conforme o Quadro 6.
57
1 2 3 4 5 6 7 8
print "\n Packets <- .......: ", $hostinfo->ipInReceives, "\n"; print "Requests -> : ", $hostinfo->ipOutRequests, "\n"; print "TCP Segments <- : ", $hostinfo->tcpInSegs, "\n"; print "TCP Segments -> : ", $hostinfo->tcpOutSegs, "\n"; print "TCP Retransmited <-> : ", $hostinfo->tcpRetransSegs, "\n"; print "UDP Datagrams <- ...: ", $hostinfo->udpInDatagrams, "\n"; print "UDP Datagrams -> ..: ", $hostinfo->udpOutDatagrams, "\n"; exit (0);
Quadro 6. Código para impressão de informações estatísticas.
• Linha 1 até 7 – Impressção das informações estatísticas capturadas pelo plugin.
• Linha 8 – Retorno do exit code para tratamento pelo Nagios e exibição em tela.
Da primeira linha até a linha número sete ocorre a impressão das informações
estatísticas e na última linha ocorre o retorno ao Nagios com o código zero que significa que o
plugin foi executado com sucesso.
O arquivo check_snmp-ping.pl foi desenvolvido com o objetivo de verificar se o
host enviado por parâmetro responde ao pacote de echo e se ele se encontra comunicável
através da rede de computadores. Segue o código conforme o Quadro 7.
1 2 3 4 5 6 7 8 9 10 11
my ($host) = @_; $p = Net::Ping->new(); if ($p->ping($host, 5)) { print "[OK] - The $host is alive.\n"; $p->close(); } else { print "[PROBLEM DETECTED] - Host $host is unrechable.\n\n"; exit (1); }
Quadro 7. Rotina de ping via Perl utilizando módulo CPAN.
• Linha 1 – Informação do endereço ip do host recebida por parâmetro.
• Linha 2 – Criação do objeto Net::Ping para utilização no código.
58
• Linha 4 até 11 – Testes realizados com o host informado verificando se ele está
comunicável pela rede de computadores. Caso sim retorna exit code 0 caso não, retorna
exit code 1.
3.3.4 Informações adicionais capturadas
Esta seção tem como objetivo descrever informações adicionais capturadas através da
rede de computadores.
Foi constatado que a câmera AXIS P1343 dá suporte apenas à MIBv2, capaz apenas
de informar os aspectos mais básicos a seu respeito. Esperava-se a existência de atributos
avançados fornecidos por alguma MIB proprietária.
A ausência destes recursos causou a necessidade de buscar os itens avançados de
gerência em outros locais possíveis. Felizmente o webserver embutido traz tais informações.
Isto redirecionou as pesquisas para a técnica de crawling mencionada e descrita neste
documento.
Desta forma foi possível utilizar o protocolo HTTP através de um dos módulos CPAN
para realizar a busca diretamente no webserver da câmera de informações como
configurações de vídeo ou configurações de audio do dispositivo.
Na Figura 22 imagem básica do webserver da câmera.
59
Figura 22. Imagem inicial do webserver da câmera Axis P1343.
Os módulos utilizados para conexão no webserver da câmera foram HTTP:Request e
também LWP::UserAgent.
O arquivo check_http-axis.pl é um arquivo desenvolvido com o objetivo de
realizar capturas de informações referentes a configuração de vídeo, audio, data e hora
configurados, e firmware utilizado pelo equipamento.
Segue ilustração do código para conexão ao webserver e retorno da variável onde se
encontram as informações da conexão. Segue ilustração do código no Quadro 8.
1 2 3 4 5 6 7 8 9 10
sub getres { $objectStatus = 0; my ($url, $host, $username, $password) = @_; $host = $host . ":80"; my $req = HTTP::Request->new(GET => $url); $req->authorization_basic($username, $password); my $ua = LWP::UserAgent->new(); $ua->timeout(5); my $resposta = $ua->request($req);
Quadro 8. Rotina de conexão via http no webserver.
60
• Linha 3 – Criação de uma variável $objectStatus para retorno no final da execução do
plugin ao Nagios.
• Linha 4 – Informações como host, URL, usuário e senha recebidos via parâmetro para
utilização.
• Linha 6 – A requisição da conexão HTTP é iniciada.
• Linha 7 – Autenticação no host com usuário e senha.
• Linha 10 – Variável $resposta recebe o resultado da conexão através da função
request.
O código desenvolvido nas subrotinas para busca de informação via webserver utiliza
a variável $resposta que recebe seu conteúdo da execução da rotina getres, explicada
anteriormente. Segue ilustração do código no Quadro 9.
1 2 3
my ($host, $username, $password) = @_; my $site = "http://".$host."/operator/basic.shtml"; my $resposta = getres($site,$host,$username,$password);
Quadro 9. Código para chamada da rotina de conexão ao webserver.
• Linha 1 – Recebimento das informações via parâmetro.
• Linha 2 – Recebe a URL responsável pelas informações que precisaremos do
webserver.
• Linha 3 – Chamada para a subrotina getres com o objetivo de conexão no webserver.
Para que estas informações fossem capturadas foi necessário utilizar o conhecimento
em expressões regulares para encontrar a informação necessária.
No código abaixo segue a rotina que foi desenvolvida para a busca de configurações
de audio. As informações capturadas são configurações de comunicação de audio e origem de
audio. Segue ilustração do código no Quadro 10.
61
1 2 3 4 5 6 7 8 9 10 11
if ($resposta == 1) { $objectStatus = 1; exit (objectStatus); } elsif ($resposta =~ m/" selected>([a-zA-Z\-\s]*)<\/option>/g) { $audioConfig = $1; } if ($resposta =~ m/" selected>([a-zA-Z\-\s]*)<\/option>/g) { $audioSource = $1; } printf "[OK] - See detailed status.\n";
Quadro 10. Rotina para busca de informações de audio.
• Linha 1 até 4 – Realização do teste para certificar-se que a conexão foi realizada com
sucesso.
• Linha 5 até 7 –Busca pela informação na variável $resposta pelos caracteres desejados
da configuração de comunicação de audio, caso encontre armazena na variável
$audioConfig.
• Linha 8 até 10 – Busca pela informação na variável $resposta pelos caracteres
desejados de origem de audio, caso encontre armazena na variável $audioSource.
•
• Linha 11 – Impressão de mensagem para verificar os resultados da captura.
O código abaixo tem como objetivo realizar a busca do firmware instalado no
dispositivo e mostrar ao operador de redes. Conforme Quadro 11.
1 2 3 4 5 6 7 8 9 10 11 12
if ($resposta == 1) { $objectStatus = 1; exit ($objectStatus); } elsif ($resposta =~ m/<\/b>(.*)<br>/g) { my $var_teste = $1; $var_teste =~ s/\s//g; $var_teste =~ s/&.58;/:/g; $var_teste =~ s/<br>//g; printf " [OK] - Current firmware: ".$var_teste . "\n"; } exit ($objectStatus);
Quadro 11. Rotina para busca de informações de firmware.
62
• Linha 1 até 4 – Realização do teste para certificar-se que a conexão foi realizada com
sucesso.
• Linha 5 até 10 – Realização da busca pela informação na variável $resposta pelos
caracteres desejados e o tratamento destas informações.
• Linha 12 – O plugin retorna a variável $objectStatus.
O código abaixo se refere à busca de informações de vídeo da câmera. A maneira de
encontrar a informação desejada segue a mesma estratégia fazendo a busca por expressão
regular recebendo o texto da variável $resposta. As informações desejadas são resolução de
vídeo, compressão de vídeo, e rotação de vídeo. Conforme Quadro 12.
1 2 3 4 5 6 7 8 9
elsif ($resposta =~ m/\" selected>(.{13,16})<\/option>/g) { $videoResolution = $1; } if ($resposta=~ m/Appearance_Comp\" value=\"([0-9]*)\"onchange/g) { $videoCompression = $1; } if ($resposta =~ m/\" selected>([0-9]*)<\/option>/g) { $videoRotation = $1; }
Quadro 12. Rotina para busca de informações de vídeo.
• Linha 1 até 3 – Realização da busca pela informação na variável $resposta pelos
caracteres desejados da resolução de vídeo, caso encontre armazena na variável
$videoResolution.
• Linha 4 até 6 – Realização da busca pela informação na variável $resposta pelos
caracteres desejados da compressão de vídeo, caso encontre armazena na variável
$videoCompression.
• Linha 7 até 9 – Realização da busca pela informação na variável $resposta pelos
caracteres desejados de rotação de vídeo, caso encontre armazena na variável
$videoRotation.
63
No código abaixo é mostrado o teste para certificar-se que a informação encontrada
pelo plugin é igual à informação de vídeo disponível no webserver.
Segue ilustração conforme o Quadro 13.
1 2 3 4 5 6 7 8 9 10 11 12
if (($videoRotation == 0) || ($videoRotation == 90) || ($videoRotation == 180) || ($videoRotation == 270)) { printf " Rotation: ".$videoRotation."\n\n"; }else { $objectStatus = 1; printf "\n *** Rotation: ".$videoRotation."\n\n"; } if ($objectStatus == 1) { printf "[WARNING] - Please make a double check in the information marked with asterisks (***)"; }
Quadro 13. Rotina de testes para confirmar as informações de vídeo.
• Linha 1 até 4 – Realização do teste se o conteúdo da variável $videoRotation é igual a
‘0’ que é um dos valores disponíveis no webserver da câmera. Caso o valor seja igual é
impresso na saída principal a mensagem de sucesso, senão a mensagem de saída é
modificada e a variável $objectStatus é modificada para ‘1’, marcando o objeto
gerenciado como warning no Nagios.
• Linha 9 até 12 – Caso a variável $objectStatus tenha sido modificada para ‘1’ é
impresso uma mensagem no final da execução do plugin para verificar se as informações
capturadas estão coerentes com o webserver.
Para a rotina que busca informações sobre a data e hora na câmera é utilizado uma
estratégia semelhante fazendo a busca de informações via comando m/ e utilizando expressões
regulares. Conforme Quadro 14.
64
1 2 3 4 5 6 7 8 9 10 11
if ($resposta =~ m/CurrentServerDate\" size=\"12\" maxlength=\"10\" value=\"([0-9-]{10})\"/g) { my $var_teste = $1; printf "[OK] - See detailed status.\n\n Date: ".$var_teste . " (AA-mm-dd)\n"; } if ($resposta =~ m/CurrentServerTime\" size=\"12\" maxlength=\"8\" value=\"([0-9:]{8})\"/g) { my $var_teste = $1; printf " Time: ".$var_teste . " (hh:mm:ss)\n"; }
Quadro 14. Rotina de testes para certificar-se a veracidade das informações de vídeo.
• Linha 1 até 6 – Busca pela informação na variável $resposta pelos caracteres
desejados da data e impressão do resultado.
• Linha 7 até 10 – Busca pela informação na variável $resposta pelos caracteres
desejados da hora e impressão do resultado.
Com esta abordagem de captura de informações via conexão HTTP foi possível buscar
informações adicionais para o Nagios através do plugin desenvolvido para a câmera Axis e
aumentar sua utilidade.
3.3.5 Testes realizados
Esta sessão tem como objetivo demonstrar os testes realizados com o plugin
desenvolvido e aferir seu funcionamento.
Segue abaixo uma descrição das tabelas criadas com o objetivo de informar o teste
realizado.
• Campo ‘Nr.’ – Enumera os testes realizados.
• Campo ‘Descrição’ – Descreve o teste realizado brevemente.
• Campo ‘Objetivo’ – descreve os objetivos do teste realizado.
• Campo ‘Serviços’ – Descreve os serviços relacionados no teste.
• Campo ‘Resultado esperado’ – Informa o resultado esperado em caso de
sucesso para o teste.
65
• Campo ‘Resultado obtido’ – Informa quanto aos resultados obtidos no teste
realizado.
O teste número 1 foi realizado com o cabo de rede conectado na interface de rede da
câmera a fim de verificar o comportamento do plugin. Ele está sendo executado utilizando
conexão via protocolo HTTP. Conforme Tabela 4.
Tabela 4. Teste número 1 – Testar sucesso na captura via HTTP
Teste Nr. 1 Câmera conectada na rede -
Descrição Cabo de rede conectado na interface de rede da câmera.
Objetivo Realizar o teste de conexão com a rede de computadores e aferir o funcionamento do plugin.
Serviços
HTTP Audio Settings
HTTP Date/Time
HTTP Firmware
HTTP Video Settings
Resultado esperado Alterar status do serviço para OK (verde) e mostrar as informações referentes a cada serviço com sucesso.
Resultado obtido O plugin se comportou da maneira esperada. O teste foi realizado com SUCESSO
Conforme a Figura 23 segue o resultado da tela de gerenciamento principal do Nagios
para a câmera exibindo todos os serviços e status para o teste número 1.
Figura 23. Interface de gerenciamento principal. Teste com conectividade de rede.
Conforme a Figura 24 segue o resultado do serviço HTTP Audio Settings para o teste
número 1.
66
Figura 24. Resultado do serviço HTTP Audio Settings.
Conforme a Figura 25 segue o resultado do serviço HTTP Date/Time para o teste
número 1.
Figura 25. Resultado do serviço HTTP Date/Time.
Conforme a Figura 26 segue o resultado do serviço HTTP Firmware para o teste
número 1.
Figura 26. Resultado do serviço HTTP Firmware.
Conforme a Figura 27 segue o resultado do serviço HTTP Video Settings para o teste
número 1.
67
Figura 27. Resultado do serviço HTTP Video Settings.
O teste número 2 também foi realizado com o cabo de rede conectado na interface de
rede da câmera. Ele está sendo executado utilizando conexão via protocolo SNMP. Conforme
Tabela 5.
Tabela 5. Teste número 2 - Testar sucesso na captura via SNMP
Nr. 2 Câmera conectada na rede
Descrição Cabo de rede conectado na interface de rede da câmera.
Objetivo Realizar o teste de conexão com a rede de computadores e aferir o funcionamento do plugin.
Comportamento
SNMP Network
SNMP Network –ISO
SNMP Ping
SNMP Uptime
Resultado esperado Alterar status do serviço para OK (verde) e mostrar as informações referentes a cada serviço com sucesso.
Resultado obtido O plugin se comportou da maneira esperada. O teste foi realizado com SUCESSO
Conforme a Figura 28 segue o resultado do serviço SNMP Network para o teste
número 2.
Figura 28. Resultado do serviço SNMP Network.
68
Conforme a Figura 29 segue o resultado do serviço SNMP Network-ISO para o teste
número 2.
Figura 29. Resultado do serviço SNMP Network-ISO.
Conforme a Figura 30 segue o resultado do serviço SNMP Ping para o teste número 2.
Figura 30. Resultado do serviço SNMP Ping.
Conforme a Figura 31 segue o resultado do serviço SNMP Uptime para o teste número
2.
Figura 31. Resultado do serviço SNMP Uptime.
O teste número 3 foi realizado com o cabo de rede desconectado da interface de rede
da câmera a fim de verificar o comportamento do plugin. Ele está sendo executado utilizando
conexão via protocolo HTTP. Conforme Tabela 6.
69
Tabela 6. Teste número 3 - Testar falha na captura via HTTP
Nr. 3 Câmera sem comunicação com a rede
Descrição Cabo de rede desconectado da interface de rede da câmera.
Objetivo Realizar o teste de falha na conectividade da câmera com a rede de computadores e demonstrar o comportamento do plugin.
Serviços
HTTP Audio Settings
HTTP Date/Time
HTTP Firmware
HTTP Video Settings
Resultado esperado Alterar status do serviço para Warning (amarelo) e mostrar a mensagem de erro de conexão com a câmera.
Resultado obtido O plugin se comportou da maneira esperada. Sucesso
Conforme a Figura 32 segue o resultado da tela de gerenciamento principal do Nagios
para a câmera exibindo todos os serviços e status para o teste número 3.
Figura 32. Interface de gerenciamento principal. Teste sem conectividade de rede.
Conforme a Figura 33 segue o resultado do serviço HTTP Audio Settings para o teste
número 3.
Figura 33. Resultado do serviço HTTP Audio Settings.
Conforme a Figura 34 segue o resultado do serviço HTTP Date/Time para o teste
número 3.
70
Figura 34. Resultado do serviço HTTP Date/Time.
Conforme a Figura 35 segue o resultado do serviço HTTP Firmware para o teste
número 3.
Figura 35. Resultado do serviço HTTP Firmware.
Conforme a Figura 36 segue o resultado do serviço HTTP Video Settings para o teste
número 3.
Figura 36. Resultado do serviço HTTP Video Settings.
O teste número 4 também foi realizado com o cabo de rede desconectado da interface
de rede da câmera. Ele está sendo executado utilizando conexão via protocolo SNMP.
Conforme Tabela 7.
71
Tabela 7. Teste número 4 - Testar falha na captura via SNMP
Nr. 3 Câmera sem comunicação com a rede
Descrição Cabo de rede desconectado da interface de rede da câmera.
Objetivo Realizar o teste de falha na conectividade da câmera com a rede de computadores e demonstrar o comportamento do plugin.
Serviços
SNMP Network
SNMP Network –ISO
SNMP Ping
SNMP Uptime
Resultado esperado Alterar status do serviço para Warning (amarelo) e mostrar a mensagem de erro de conexão com a câmera.
Resultado obtido O plugin se comportou da maneira esperada. Sucesso
Conforme a Figura 37 segue o resultado do serviço SNMP Network para o teste
número 4.
Figura 37. Resultado do serviço SNMP Network.
Conforme a Figura 38 segue o resultado do serviço SNMP Network-ISO para o teste
número 4.
Figura 38. Resultado do serviço SNMP Network-ISO.
Conforme a Figura 39 segue o resultado do serviço SNMP Ping para o teste número 4.
Figura 39. Resultado do serviço SNMP Ping.
72
Conforme a Figura 40 segue o resultado do serviço SNMP Uptime para o teste número
4.
Figura 40. Resultado do serviço SNMP Uptime.
Através dos testes foi demonstrado o funcionamento do plugin e como ele se comporta
com as situações impostas. O plugin demonstrou capacidade de gerenciar a câmera e realizar
as buscas de informações propostas neste trabalho.
73
4 Conclusões
Diante da necessidade de uma ferramenta de monitoramento de ativos e serviços de
rede centralizada o resultado deste trabalho era desenvolver uma extensão ou plugin para o
software Nagios a fim de estabelecer comunicação com câmeras de segurança da marca Axis
modelo P1343 e utilizar os resultados desta conexão para o gerenciamento deste ativo.
No primeiro capítulo deste documento, foi apresentado um texto introdutório
informando os problemas enfrentados no gerenciamento de redes e também os objetivos deste
trabalho para universalização do processo de gestão de ativos e serviços de rede em uma
interface única de gerenciamento.
Na fundamentação teórica, abordada no segundo capítulo, foram aprofundadas as
bases de conhecimento para o desenvolvimento deste projeto. O conhecimento transmitido
estabeleceu o conceito de gerência de redes de forma generalizada, mas também esclareceu de
forma mais especifica o protocolo utilizado neste trabalho, o SNMP, como também o software
de apoio que será utilizado para desenvolvimento deste projeto, o Nagios.
No capítulo três foi abordado o projeto de software que pretendia ser desenvolvido e o
desenvolvimento do plugin. Neste capítulo foi apresentada a documentação do projeto que
compõe análise e identificação de requisitos funcionais, não funcionais, cenários, regras de
negócio, casos de uso e digramas do projeto. Foi documentado o desenvolvimento da
infraestrutura para realização do projeto juntamente com os códigos desenvolvidos para a
realização do monitoramento da câmera através do Nagios.
Testes de funcionamento do plugin foram realizados através do Nagios para aferição
do desenvolvimento. Os resultados dos testes demonstraram sucesso trazendo as informações
da câmera utilizando a MIBv2 e adicionalmente resultados da conexão HTTP para
complementação do resultado.
4.1 Trabalhos Futuros
Como sugestão de trabalhos futuros estão listadas abaixo as seguintes intenções de
desenvolvimento:
74
• Buscar usuários conectados no webserver da câmera.
• Buscar MAC address da câmera.
• Buscar o hostname da câmera.
• Fazer com que o plugin faça a busca destas informações em outras câmeras de
outros modelos e marcas.
75
REFERÊNCIAS
AXIS: At a glance. 2011. Disponível em: <http://www.axis.com/files/brochure/bc_axis_at_a_glance_43193_en_1106_lo.pdf >. Acesso em: 09 jul. 2012.
AXIS: Sustentability report. 2011. Disponível em: <http://www.axis.com/files/brochure/report_axis_sustainability_2012.pdf >. Acesso em: 09 jul. 2012.
AXIS: Manual P1343. Disponível em: <http://www.axis.com/files/brochure/report_axis_sustainability_2012.pdf >. Acesso em: 09 jul. 2012.
BARTH, Wolfgang. NAGIOS: System and Network Monitoring. 2.ed. No Starch Press, 2003. ISBN: 978-3-937514-46-8.
CALISHAIN, Tara; HEMENWAY, Kevin. Spidering Hacks. O’Reilly, 2003. ISBN: 0-596-00577-6.
CLEMM, Alexander. Network management fundamentals. Indianapolis: Cisco Press, 2007. ISBN: 1-58720-137-2.
COMER, Douglas E. Redes de computadores e internet. Porto Alegre: Bookman, 2007. ISBN: 85-352-1380-5.
ELLISON, Jason. SNMP monitoring with Nagios. In: Linux Journal, Volume 2009, Issue 182, Jun. 2009, ISBN: 1075-3583.
EDELMAN, David N. Blank. Automating System Administration with Perl, 2ed. Sebastopol: O’Reilly Media, 2009. ISBN: 978-0-596-00639-6.
GNU. The GNU General Public License. Disponível em: <http://www.gnu.org/licenses/gpl.html>. Acesso em 24 maio2012.
JOSEPHSEN, David. Building a monitoring infrastructure with Nagios. Boston: Pearson Education, 2007. ISBN: 0-132-23693-1. (JOSEPHSEN, 2007, p21)
KARRIS, Steven T. NETWORKS: design and management. 2.ed. Fremont: Orchard Publications, 2009. ISBN: 978-1934404-16-4.
KEVAL, Hina; ANGELA SASSE, M. To catch a thief -- you need at least 8 frames per second: the impact of frame rates on user performance in a CCTV detection task. In: 16th ACM international conference on Multimedia, 26 Out. 2008,Canada, p.941-944. ISBN: 978-1-60558-303-7.
KOCJAN, Wojciech. Learning Nagios 3.0. Birmingham: Packt, 2008. ISBN: 978-1-84719-518-0.
76
KUROSE, James F.; ROSS, Keith W. Redes de computadores e a internet: Uma abordagem top-down. São Paulo: Pearson, 2006. ISBN: 85-88639-18-1.
MAURO, Douglas; SCHMIDT, Kevin. Essential SNMP. 2.ed. O’Reilly, 2005. ISBN: 0-596-00840-6.
MCCABE, James D. Network analysis, architecture, and design. 3.ed. Burlington: Elsevier, 2007. ISBN: 978-0-12-370480-1.
SCHRENK, Michael. Webbots, Spiders, and Screen Scrapers, 2ed. San Francisco: No Starch Press, Inc., 2012. ISBN-13: 978-1-59327-120-6, ISBN-10: 1-59327-120-4.
MORRIS, Stephen B. Network management, MIBs and MPLS: principles design and implementation. Upper Saddle River: Addison Wesley, 2003. ISBN: 0-13-101113-8. (Wesley, 2033, c1.3)
NADEAU, THOMAS D. MPLS network management: MIBs tools and techniques. San Francisco: Elsevier Science, 2003. ISBN: 1-55860-751-X.
PLEVYAK, Thomas; SAHIN, Veli. Next generation telecomunications networks, services, and management. Hoboken: John Wiley & Sons, Inc., 2010. ISBN: 978-0-470-57528-4.
RFC 1157. Simple network management protocol (SNMP). 1990. Disponível em: <http://www.ietf.org/rfc/rfc1157.txt. Acesso em: 01 abr 2008.
SOMMERVILLE, Ian. Software Engineering. Boston: Pearson, 2011. ISBN: 978-0-13-703515-1.
TANENBAUM, Andrew S. Redes de Computadores. 9.ed.Prentice Hall, 2003. ISBN: 0-13-066102-3.
TURNBULL, James. Pro Nagios 2.0. Nova York: Apress, 2006. ISBN: 978-1-59059-609-8
YOUNG, Geoffrey; LINDNER, Paul; KOBES, Randy.. mod_perl, Developers CookBook. Indianapolis: Sams, 2002, ISBN: 0-672-32240-4.
77
APÊNDICE A. PROJETO DE SOFTWARE DESENVOLVIDO NO ENTERPRISE ARCHITECT
Nagios Plugin
Capa Universidade do Vale do Itajaí - Univali Curso de Ciência da Computação Nagios-Axis-p1334 Versão 1.0 Autor: Marcus Vinicius de Souza Simas Itajaí, 08 de Junho de 2012
1. Introdução 1.1 Objetivos deste documento Descrever e especificar necessidades de administradores e operadores de rede na tarefa de gerenciamento de redes em geral e em específico na gestão de câmeras Axis Modelo p1343 que devem ser atendidas com o desenvolvimento do produto Nagios-Axis-p1343, bem como definir e documentar à equipe de desenvolvimento o plugin a ser desenvolvido.
78
1.2 Público-alvo: Administradores de rede, operadores de rede e equipes de TI em geral. 1.3 Materiais de Referência Reuniões com outros administradores de rede e também com o orientador deste projeto Fabrício Bortoluzzi. Leituras de materiais na internet e de livros de gestão de ativos de tecnologia. Produtos similares do mercado: Nome: AXIS Camera Station Link: http://windows.podnova.com/software/11829.htm Nome: AXIS Camera Management Link: http://windows.podnova.com/software/09270.htm Este documento foi desenvolvido baseado no Padrão IEEE 830-1993: Prática recomendada para as Especificações de Requisitos de Software.
2. Descrição geral do produto 2.1 Visão Geral Administradores de rede tem hoje em sua responsabilidade o gerenciamento de câmeras IP no parque de equipamentos das empresas. Hoje um software que é globalmente conhecido para desempenhar esta função de monitoramento e gerenciamento de redes é o Nagios. Ele tem grande aceitação no meio tecnológico por sua fácil extensibilidade e também sua integração com diversos outros sistemas. Hoje com a grande utilização da tecnologia e também com o crescimento de aplicações e novas tecnologias de rede a necessidade de integração dos sistemas e universalização da gerência é algo imprescindível. Pensando nisso verificou-se a necessidade de utilizaão de um plugin Nagios para que fosse possível adicionar as câmeras de segurança AXIS p1343 na tarefa de gerenciamento de rotina dos administradores de rede, sem a necessidade de utilização de outra interface para a gestão. 2.2 Stakeholder Administradores de redes: Interessado em gerenciar as câmeras AXIS através do mesmo software já utilizado rotineiramente. 2.3 Usuários Administrador de redes: de 18 a 60 anos com conhecimento avançado em informática.
79
2.4 Benefícios do software 1. Agilidade no processo de busca de informações da câmera. 2. Verificações de logs da câmera. 3. Suporte remoto ao equipamento. 4. Facilidade de utilização da mesma ferramenta para gestão de outros ativos. 2.5 Escopo do Software O sistema em questão deve ser composto das seguintes funcionalidades: Gerenciar câmeras AXIS: Compreende conectar nas câmeras e buscar informações pertinentes para o gerenciamento. 2.6 Limitações do software O sistema em questão não aborda aspectos como: 1. Controle de autenticação do NMS ou da câmera; 2. Controle de movimentação da câmera; 3. Controle de imagens ou gravação das lentes da câmera; 4. Geração de relatórios;
2.1 Workflow
Figura 1 : Plugin Nagios
act Plugin Nagios
Operador Nagios Plugin AXIS Câmera
Início
Autenticação
Usuário e senha
Aciona plugin
Faz requisição SNMP Responde requisição SNMP
Armazena resultadosRecebimento de
resultadosResultados mostrados
ao operador
Final
[Conexão mal sucedida]
[Dados
incorretos]
80
3. Especificação de Requisitos
3.1 Requisitos Funcionais
Figura 2 : 3.1 Requisitos Funcionais
RF01. O plugin deverá estabelecer comunicação com a MIB da câmera via SNMP.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.1 Requisitos Funcionais Details: Criado em 20/04/2010 21:40:48. Modified on 06/06/2012 01:08:25. Autor: Developers
Linked (System) Requirements
� RN03. O operador deverá ser previamente cadastrado na base de dados do Nagios para poder acessar o plugin. (Status: ; Dificuldade: Medium; Prioridade: Medium)
Connections
� Realization link to requirement RN03. O operador deverá ser previamente cadastrado na base de dados do Nagios para poder acessar o plugin.<3.3 Requisitos de domínio / Regras de Negócio>
� Realization link from usecase UC01.02 Verifica conectividade da câmera <PCT01 - Funcionamento do Plugin>
RF02. O plugin deverá permitir a captura dos logs de falha de autenticação na câmera.
Type: Requirement
custom 3.1 Requisitos Funcionais
RF01. O plugin deverá estabelecer comunicação com a MIB da câmera via SNMP.
RF02. O plugin deverá permitir a captura dos logs de falha de autenticação na câmera.
RF03. O plugin deverá permitir a captura dos logs de reinicialização da câmera quando as configurações do
equipamento não forem modificadas.
RF04. O plugin deverá enviar as informações capturadas da câmera para gravação no sistema Nagios.
RF05. O plugin deverá permitir a captura dos logs de reinicialização da câmera quando as configurações do
equipamento forem modificadas.
81
Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.1 Requisitos Funcionais Details: Criado em 20/04/2010 21:44:52. Modified on 13/07/2012 19:37:34. Autor: Developers
Connections
� Realization link from usecase UC01.02 Verifica conectividade da câmera <PCT01 - Funcionamento do Plugin>
RF03. O plugin deverá permitir a captura dos logs de reinicialização da câmera quando as configurações do equipamento não forem modificadas.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.1 Requisitos Funcionais Details: Criado em 20/04/2010 21:47:12. Modified on 13/07/2012 19:38:16. Autor: Developers
Linked (System) Requirements
� RN02. A consulta as informações das câmeras não deverão exceder a quantidade de 10 segundos. (Status: ; Dificuldade: Medium; Prioridade: Medium)
Connections
� Realization link from usecase UC01.01 Solicita informações da câmera <PCT01 - Funcionamento do Plugin>
� Realization link to requirement RN02. A consulta as informações das câmeras não deverão exceder a quantidade de 10 segundos.<3.3 Requisitos de domínio / Regras de Negócio>
RF04. O plugin deverá enviar as informações capturadas da câmera para gravação no sistema Nagios.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.1 Requisitos Funcionais Details: Criado em 24/05/2012 22:46:53. Modified on 08/06/2012 14:37:44. Autor: Simas
RF05. O plugin deverá permitir a captura dos logs de reinicialização da câmera quando as configurações do equipamento forem modificadas.
Type: Requirement
82
Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.1 Requisitos Funcionais Details: Criado em 30/05/2012 09:44:38. Modified on 05/06/2012 21:08:14. Autor: Simas
Connections
� Realization link from usecase UC01.01 Solicita informações da câmera <PCT01 - Funcionamento do Plugin>
83
3.2 Requisitos Não Funcionais
Figura 3 : 3.2 Requisitos Não Funcionais
RNF01. O plugin deverá utilizar o Nagios como software host para que ele seja executado.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.2 Requisitos Não Funcionais Details: Criado em 20/04/2010 21:58:25. Modified on 28/05/2012 11:38:50. Autor: Developers
RNF02. O sistema cliente deverá acessar a interface do NMS por um browser de internet.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.2 Requisitos Não Funcionais Details: Criado em 02/05/2010 17:43:31. Modified on 05/06/2012 21:33:01. Autor: Developers
custom 3.2 Requisitos Não Funcionais
RNF01. O plugin deverá uti l izar o Nagios como software host para que ele seja executado.
RNF03. O servidor de bases de dados util izado pelo Nagios será o MySQL.
RNF04. O servidor web uti lizado pelo Nagios será o Apache.
RNF05. O controle de acesso ao plugin será gerenciado pelo sistema de autenticação do Nagios.
RNF07. O SO do servidor que hospedará o plugin deverá ser Linux ou BSD.
RNF02. O sistema cliente deverá acessar a interface do NMS por um browser de internet.
RNF08. Tanto o servidor que hospedará o plugin quanto a câmera da AXIS devem apresentar conexão com
a rede de computadores.
RNF10. O servidor que hospedará o plugin poderá ser hospedado em servidor físico ou servidor virtual.
RNF09. Será necessária a posse da câmera AXIS p1343 para o funcionamento completo do plugin.
(Hardware)
RNF06. O servidor que hospedará o plugin deverá oferecer suporte as l inguagens PHP, C e sh.
84
RNF03. O servidor de bases de dados utilizado pelo Nagios será o MySQL.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.2 Requisitos Não Funcionais Details: Criado em 20/04/2010 22:00:24. Modified on 05/06/2012 21:13:33. Autor: Developers
RNF04. O servidor web utilizado pelo Nagios será o Apache.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.2 Requisitos Não Funcionais Details: Criado em 20/04/2010 22:01:56. Modified on 05/06/2012 21:13:43. Autor: Developers
RNF05. O controle de acesso ao plugin será gerenciado pelo sistema de autenticação do Nagios.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.2 Requisitos Não Funcionais Details: Criado em 20/04/2010 22:07:36. Modified on 05/06/2012 21:14:37. Autor: Developers
RNF06. O servidor que hospedará o plugin deverá oferecer suporte as linguagens PHP, C e sh.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.2 Requisitos Não Funcionais Details: Criado em 05/06/2012 21:33:43. Modified on 08/06/2012 14:40:40. Autor: Simas
RNF07. O SO do servidor que hospedará o plugin deverá ser Linux ou BSD.
Type: Requirement
85
Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.2 Requisitos Não Funcionais Details: Criado em 20/04/2010 22:08:55. Modified on 06/06/2012 01:32:13. Autor: Developers
RNF08. Tanto o servidor que hospedará o plugin quanto a câmera da AXIS devem apresentar conexão com a rede de computadores.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.2 Requisitos Não Funcionais Details: Criado em 06/05/2010 21:53:32. Modified on 06/06/2012 01:32:31. Autor: Developers
RNF09. Será necessária a posse da câmera AXIS p1343 para o funcionamento completo do plugin. (Hardware)
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.2 Requisitos Não Funcionais Details: Criado em 12/05/2010 09:28:09. Modified on 06/06/2012 01:32:46. Autor: Developers
RNF10. O servidor que hospedará o plugin poderá ser hospedado em servidor físico ou servidor virtual.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.2 Requisitos Não Funcionais Details: Criado em 11/05/2010 15:02:41. Modified on 06/06/2012 01:33:59. Autor: Developers
86
3.3 Requisitos de domínio / Regras de Negócio
Figura 4 : 3.3 Regras de Negócio
RN01. O operador de rede poderá solicitar atualização das informações utilizando o plugin a qualquer momento.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.3 Requisitos de domínio / Regras de Negócio Details: Criado em 02/05/2010 19:05:18. Modified on 05/06/2012 21:43:46. Autor: Developers
Connections
� Realization link from usecase UC01.01 Solicita informações da câmera <PCT01 - Funcionamento do Plugin>
RN02. A consulta as informações das câmeras não deverão exceder a quantidade de 10 segundos.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.3 Requisitos de domínio / Regras de Negócio Details: Criado em 20/04/2010 22:20:33. Modified on 28/05/2012 14:19:31. Autor: Developers
Connections
� Realization link from requirement RF03. O plugin deverá permitir a captura dos logs de reinicialização da câmera quando as configurações do equipamento não forem modificadas. <3.1 Requisitos Funcionais>
custom 3.3 Regras de Negócio
RN03. O operador deverá ser previamente cadastrado na base de dados do Nagios para poder
acessar o plugin.
RN02. A consulta as informações das câmeras não deverão exceder a quantidade de 10 segundos.
RN01. O operador de rede poderá solicitar atualização das informações uti l izando o plugin a qualquer
momento.
87
RN03. O operador deverá ser previamente cadastrado na base de dados do Nagios para poder acessar o plugin.
Type: Requirement Status: . Versão 1.0. Fase 1.0.; Prioridade: Medium; Dificuldade: Medium Package: 3.3 Requisitos de domínio / Regras de Negócio Details: Criado em 20/04/2010 22:12:14. Modified on 05/06/2012 21:45:24. Autor: Developers
Connections
� Realization link from requirement RF01. O plugin deverá estabelecer comunicação com a MIB da câmera via SNMP. <3.1 Requisitos Funcionais>
88
4. Modelo de casos de uso
Figura 5 : 4.1 Diagrama de pacotes
pkg 4.1 Diagrama de pacotes
PCT01 - Funcionamento do Plugin
+ Câmera
+ Nagios
+ Operadores
+ UC01.01 Solicita informações da câmera
+ UC01.02 Verifica conectividade da câmera
(from 4.2 Diagrama de casos de uso)
89
4.2 Diagrama de casos de uso
PCT01 - Funcionamento do Plugin
Figura 6 : PCT01 - Funcionamento do Plugin
UC01.01 Solicita informações da câmera
Type: UseCase Status: . Versão 1.0. Fase 1.0. Package: PCT01 - Funcionamento do Plugin Details: Criado em 05/06/2012 12:31:37. Modified on 06/06/2012 00:05:42. Autor: Simas Realiza a busca das informações de gerenciamento na câmera após a verificação de conectividade desta com a rede e armazena os resultados na base de dados do Nagios.
uc PCT01 - Funcionamento do Plugin
Plugin Nagios p1344
Operadores Nagios
UC01.02 Verifica
conectiv idade da
câmera
Câmera
UC01.01 Solicita
informações da câmera
90
Linked (System) Requirements � RF03. O plugin deverá permitir a captura dos logs de reinicialização da câmera
quando as configurações do equipamento não forem modificadas. (Status: ; Dificuldade: Medium; Prioridade: Medium)
� RF05. O plugin deverá permitir a captura dos logs de reinicialização da câmera quando as configurações do equipamento forem modificadas. (Status: ; Dificuldade: Medium; Prioridade: Medium)
� RN01. O operador de rede poderá solicitar atualização das informações utilizando o plugin a qualquer momento. (Status: ; Dificuldade: Medium; Prioridade: Medium)
Constraints
� Approved Pré-condição . O operador do sistema deverá ter realizado o login no Nagios.
� Approved Pós-condição . As informações são capturadas com sucesso e salvas na base de dados do Nagios.
Connections
� Association link from actor Câmera � Association link from actor Nagios � Realization link to requirement RN01. O operador de rede poderá solicitar
atualização das informações utilizando o plugin a qualquer momento.<3.3 Requisitos de domínio / Regras de Negócio>
� Realization link to requirement RF05. O plugin deverá permitir a captura dos logs de reinicialização da câmera quando as configurações do equipamento forem modificadas.<3.1 Requisitos Funcionais>
� Realization link to requirement RF03. O plugin deverá permitir a captura dos logs de reinicialização da câmera quando as configurações do equipamento não forem modificadas.<3.1 Requisitos Funcionais>
Cenários
Busca informações na câmera {Principal}. 1 - Nagios solicita a busca de informações na câmera;\line 2 - Plugin envia mensagens SNMP para captura das informações;\line 3 - As informações são capturadas com sucesso;\line 4 - O Nagios salva o resultado da captura em sua base de dados; Problema de conexão {Exceção}. No passo 2, ao efetuar a captura de informações da câmera, caso ela perca conectividade deverá retornar uma mensagem de falha ao Nagios.
UC01.02 Verifica conectividade da câmera
Type: UseCase Status: . Versão 1.0. Fase 1.0. Package: PCT01 - Funcionamento do Plugin Details: Criado em 05/06/2012 12:23:57. Modified on 06/06/2012 03:08:56. Autor: Simas Realiza o teste de comunicação com a câmera pela rede afim de iniciar a captura das informações de gerenciamento do dispositivo.
91
Linked (System) Requirements
� RF01. O plugin deverá estabelecer comunicação com a MIB da câmera via SNMP. (Status: ; Dificuldade: Medium; Prioridade: Medium)
� RF02. O plugin deverá permitir a captura dos logs de falha de autenticação na câmera. (Status: ; Dificuldade: Medium; Prioridade: Medium)
Constraints
� Approved Pré-condição . O operador do sistema deverá ter realizado o login no Nagios.
� Approved Pós-condição . A conectividade da câmera é verificada e retorna informação de êxito.
Connections
� Association link from actor Operadores � Association link from actor Nagios � Realization link to requirement RF02. O plugin deverá permitir a captura dos logs
de falha de autenticação na câmera.<3.1 Requisitos Funcionais> � Realization link to requirement RF01. O plugin deverá estabelecer comunicação
com a MIB da câmera via SNMP.<3.1 Requisitos Funcionais> Cenários
Verifica conectividade da câmera com a rede {Principal}. 1 - Nagios verifica a conectividade com a câmera através da rede;\line 2 - Câmera retorna informação com sucesso; Câmera não responde quanto ao teste de conectividade {Exceção}. No passo 2, após a verificação da conectividade da câmera, caso a câmera não responda em 5 segundos o Nagios deverá mostrar ao operador uma mensagem de erro ou falha na conectividade.