MONITORAMENTO E SEGURANÇA - Uma abordagem sobre como o Zabbix pode contribuir com relação à segurança e a gestão de suas melhores práticas em Tecnologia da Informação
Descrição do Produto
Universidade Federal do ABC Pós-graduação em Tecnologias e Sistemas de Informação
Roni Peterson Cunha de Alvarenga
MONITORAMENTO E SEGURANÇA Uma abordagem sobre como o Zabbix pode contribuir com relação à segurança e a gestão de suas melhores práticas em Tecnologia da Informação
Trabalho de Conclusão de Curso
Santo André – SP 2015
Roni Peterson Cunha de Alvarenga
MONITORAMENTO E SEGURANÇA Uma abordagem sobre como o Zabbix pode contribuir com relação à segurança e a gestão de suas melhores práticas em Tecnologia da Informação
Trabalho de Conclusão de Curso
Trabalho de Conclusão de Curso apresentado ao Curso de Pós-graduação da Universidade Federal do ABC, como requisito parcial para obtenção do grau de Especialista em Tecnologias e Sistemas de Informação.
Orientador: Prof.ª Dr.ª Denise Hideko Goya
Santo André – SP 2015
Roni Peterson Cunha de Alvarenga
MONITORAMENTO E SEGURANÇA Uma abordagem sobre como o Zabbix pode contribuir com relação à segurança e a gestão de suas melhores práticas em Tecnologia da Informação
Esse Trabalho de Conclusão de Curso foi julgado e aprovado para a obtenção do grau de Especialista em Tecnologias e Sistemas de Informação no curso de Pósgraduação em Tecnologias e Sistemas de Informação da Universidade Federal do ABC.
Santo André – SP,
24 de Agosto de 2015
BANCA EXAMINADORA ________________________________ Prof.ª Dr.ª Denise Hideko Goya Orientador
________________________________ Prof. Dr. Rodrigo Reina Muñoz UFABC ________________________________ Prof. Dr. Irineu Antunes Júnior UFABC
AGRADECIMENTOS
Agradeço a todos que, mesmo indiretamente, contribuíram para o desenvolvimento desse trabalho, entretanto alguns se destacaram por passar várias horas revisando, lendo e me dando sugestões de como melhorar, como meu grande amigo Paulo, meu amigo de longa data Petrus e minha colega de trabalho, a amiga Tamires que me ajudou em muito a contextualizar toda a estrutura do trabalho de conclusão de curso e claro a minha namorada Janaina que esteve comigo durante todo o processo. Não posso deixar de agradecer a todos meus tutores e à minha orientadora que estavam sempre disponíveis e tirando minhas dúvidas. E aos meus colegas de trabalho, que me ajudaram com a implantação da ferramenta Zabbix.
“Se você não pode medir, você não pode gerenciar” Peter Drucker
RESUMO
O monitoramento do ambiente de tecnologia é essencial e de grande importância para garantir a disponibilidade dos serviços ofertados pelas aplicações de negócios. Por isso, falhas nos sistemas podem trazer prejuízos imensuráveis, podendo até, serem irrecuperáveis. O monitoramento não evitará o inevitável, porém, irá fornecer subsídios para evitar situações que poderão ser previstas e planejadas como contingência evitando exemplos trágicos. O gerenciamento eficiente de uma rede de computadores permite que falhas possam ser identificadas e prevenidas rapidamente, com o intuito de minimizar o impacto sobre os usuários e diminuir os prejuízos da instituição. Realizar auditoria em logs de maneira rápida é imprescindível para um administrador de redes assim como buscar e minimizar as vulnerabilidades encontradas no seu ambiente. Com base nesta argumentação, surgiu a necessidade de realizar um estudo de caso na Câmara Municipal de Campinas, pois havia uma grande falha no monitoramento de dados e informações que gerava uma equipe reativa na resolução de problemas correntes. Isso resultou em um projeto de implantação do Zabbix, com a finalidade de melhorar a gestão de ativos mediante um sistema de monitoramento eficaz, atendendo os objetivos necessários, incluindo as melhores práticas de gestão de gerenciamento, governança e, principalmente, da segurança de Tecnologia da Informação. Escolhemos o Zabbix pois ele possui mecanismos flexíveis que permitem ao administrador de sistemas e a equipe de que faz parte de modo geral, agir de forma proativa, por exemplo, a notificação de alertas por e-mail ou por SMS, em caso de falha em determinado dispositivo, podendo ele, agir de forma disciplinada para a correção preventiva ou uma ação corretiva. Após sua implantação, foi visível a melhora no rendimento da equipe de TI, principalmente em determinar falhas na rede. Com a utilização da ferramenta a mesma demonstrou-se eficaz aumentando a resposta na resolução de problemas e incidentes
Palavras-Chave: Monitoramento de Redes, Zabbix, Gerência, Auditoria de Logs, Disponibilidade, Segurança da Informação.
ABSTRACT
The monitoring technology is essential and of great importance Environment To ensure availability of the offered Services For Business Applications. For IT, systems failures nos can bring immeasurable losses and can eat, to be unrecoverable. Monitoring not avoid the inevitable, however, will provide grants paragraph avoid situations that can be anticipated and planned contingency avoiding Examples How tragic. The Efficient Management of a Computer Network allows que Failures can sor identified and prevented quickly, in order to Minimize Impact on Users and Decrease OS losses of the institution. Held in auditoriums records Quick Way and essential paragraph hum network administrator So How to seek and to minimize vulnerabilities found in his environment. On the basis of this argument, the need arose to conduct a case study in the Municipality of Campinas, for there was a major failure in data monitoring and information que generated a reactive team in Troubleshooting Chains. IT resulted in hum Zabbix Deployment Project, in order to improve Upon hum Asset Management Effective Monitoring System, serving OS Required Goals, including Best Practices of Management Management, governance and mainly Technology Security information. We chose Zabbix because he has Flexible Mechanisms that allow the systems administrator and team that is part of General Mode, the act proactively Example in an Alert notification via email OR SMS at fault Case in certain device and can him, the act in a disciplined manner paragraph one preventive Correction or a Corrective Action. After his Implementation, it was visible improvement in the IT Team of income, especially in determining faults in the network. Using one tool same proved to be effective in.
Keywords: Network Monitoring, Zabbix, Management, Audit Logs, Availability, Information Security.
LISTA DE SIGLAS
CMC - Câmara Municipal de Campinas
DTIC - Diretoria de Tecnologia da Informação e Telecomunicação
FDDI - Fiber Distributed Data Interface
HTTP - Hypertext Transfer Protocol
ICMP - Internet Control Message Protocol
IETF - Internet Engineering Task Force
IMAP - Internet Message Access Protocol
IP
IPMI - Intelligent Platform Management Interface
ISO
LAN - Local Area Network
MAC - Media Access Control
MAN - Metropolitan Area Network
MIB
NMS - Network-Management Systems
OID
- Object IDentifier
OSI
- Open Systems Interconnection
QoS
- Quality of service
RFC
- Request for Comments
RTP
- Real-time Transport Protocol
SI
- Segurança da Informação
SLA
- Service Level Agreement
SNMP - Simple Network Management Protocol
TCP
- Transmission Control Protocol
TI
- Tecnologia da Informação
UDP - User Datagram Protocol
VLAN - Virtual Lan
VM
WAN - Wide Area Network
- Internet Protocol
- International Organization for Standardization
- Management Information Base
- Virtual Machine
LISTA DE ILUSTRAÇÕES
Figura 1: Total de Incidentes Reportados ao Cert.br por Ano.................................................. 17 Figura 2: Exemplo de uma rede doméstica .............................................................................. 22 Figura 3: Exemplo de rede Metropolitana (MAN) ................................................................... 23 Figura 4: Exemplo de uma rede Continental (WAN) ............................................................... 24 Figura 5: Topologia em Anel.................................................................................................... 25 Figura 6: Topologia em Estrela ............................................................................................... 25 Figura 7: Topologia em Barramento ........................................................................................ 26 Figura 8: O modelo de referência OSI...................................................................................... 30 Figura 9: O Modelo TCP/IP ..................................................................................................... 31 Figura 10: Comparação OSI / TCP........................................................................................... 32 Figura 11: O modelo de gerência FCAPS ................................................................................ 35 Figura 12: Funcionamento do SNMP ....................................................................................... 38 Figura 13: Tela Inicial – Nagios ............................................................................................... 42 Figura 14: Interface do ZenOSS ............................................................................................... 43 Figura 15: Painéis do CACTI ................................................................................................... 44 Figura 16: A pirâmide da Segurança da Informação ................................................................ 46 Figura 17: Evolução do Zabbix ................................................................................................ 53 Figura 18: Arquitetura do Zabbix ............................................................................................. 55 Figura 19: Monitoramento de Páginas Web do Zabbix ............................................................ 60 Figura 20: Zabbix Appliance .................................................................................................... 63 Figura 21: Download de Appliances do Zabbix ....................................................................... 64 Figura 22: Fluxograma de resolução de falhas anterior ao Zabbix .......................................... 66 Figura 23: Fluxograma de desenvolvimento do Zabbix na CMC ............................................ 68 Figura 24: Estrutura da Rede da Câmara de Campinas ............................................................ 71
Figura 25: Modelos de autenticação do Zabbix ....................................................................... 73 Figura 26: Monitoramento Zabbix - Log auth.log.................................................................... 74 Figura 27: Monitoramento Zabbix - Espaço em disco ............................................................. 74 Figura 28: Monitoramento Zabbix - Active Directory ............................................................. 75 Figura 29: Monitoramento Zabbix - Tráfego de internet ......................................................... 76 Figura 30: Monitoramento Zabbix - DHCP ............................................................................. 76 Figura 31:Monitoramento Zabbix - Mapa da Rede .................................................................. 77 Figura 32: Fluxograma de resolução de falhas após a instalação do Zabbix ........................... 78 Figura 33: Instalação com Zabbix Proxy.................................................................................. 79 Figura 34: Monitoramento Zabbix - Dados em Tempo Real ................................................... 80 Figura 35: Monitoramento Zabbix - Mapas e Telas ................................................................. 81 Figura 36: Instalação Zabbix – Tela Inicial .............................................................................. 88 Figura 37: Instalação Zabbix – Checagem de pré-requisitos ................................................... 88 Figura 38: Instalação Zabbix – Primeiro Login ....................................................................... 89 Figura 39: Instalação Zabbix – Dashboard ............................................................................... 89
LISTA DE TABELAS
Tabela 1: Plataformas Suportadas - Zabbix .............................................................................. 56 Tabela 2: Requisitos Mínimos de Hardware para o Zabbix ..................................................... 57 Tabela 3: Requisitos Mínimos de Hardware para o Nagios ..................................................... 57 Tabela 4: Requisitos Mínimos de Hardware para o ZenOSS ................................................... 57 Tabela 5: Comparação de Ferramentas de Monitoramento ...................................................... 61 Tabela 6: Tabela de ativos a serem monitorados pelo Zabbix ................................................. 69 Tabela 7: Configuração do Servidor Zabbix ............................................................................ 72 Tabela 8: Configuração do Banco de Dados PostgreSQL ........................................................ 72
SUMÁRIO 1.
INTRODUÇÃO ........................................................................................................... 14
1.1
Motivação .................................................................................................................... 14
1.2
Justificativa ................................................................................................................. 18
1.3
Objetivo ....................................................................................................................... 19
1.3.1
Objetivo geral .......................................................................................................... 19
1.3.2
Objetivos específicos ............................................................................................... 19
1.4
Metodologia ................................................................................................................. 20
1.5
Organização do Trabalho .......................................................................................... 20
2.
CONCEITOS ............................................................................................................... 21
2.1
Rede de Computadores .............................................................................................. 21
2.1.1
Classificação baseada em extensão geográfica ..................................................... 22
2.1.2
Classificação baseada na Topologia ...................................................................... 24
2.2
Modelos de Referência ............................................................................................... 27
2.2.1
Protocolos de Rede .................................................................................................. 27
2.2.2
Modelo de referência OSI ....................................................................................... 28
2.2.3
Modelo de referência TCP/IP ................................................................................. 31
2.3
Gerenciamento de Rede ............................................................................................. 33
2.3.1
O Modelo de gerenciamento FCAPS ..................................................................... 33
2.3.2
SNMP ...................................................................................................................... 36
2.3.3
Sistemas de Monitoramento e Gerência ................................................................. 40
2.4
Segurança da Informação e de Redes ....................................................................... 45
2.4.1
Ameaças e Vulnerabilidades ................................................................................... 47
2.4.2
Mecanismos de Segurança de Redes ...................................................................... 48
3
O ZABBIX .................................................................................................................... 52
3.1
Arquitetura do Zabbix ............................................................................................... 54
3.1.1 3.2
Requisitos Mínimos Recomendados ....................................................................... 56 Tipos de Monitoramento ............................................................................................ 57
3.2.1
Agente Zabbix ......................................................................................................... 57
3.2.2
Agente SNMP .......................................................................................................... 58
3.2.3
Monitoramento IPMI .............................................................................................. 58
3.2.4
Monitoramento Simples .......................................................................................... 59
3.2.5
Monitoramento Web ............................................................................................... 60
3.2.6
Monitoramento de Serviços de TI - SLA ................................................................ 60
3.2.7
Outros tipos de monitoramento .............................................................................. 61
3.2.8
Comparativo das ferramentas ................................................................................. 61
3.3
O Ambiente de Testes ................................................................................................. 62
4
O CENÁRIO DA APLICAÇÃO ................................................................................ 64
4.1
A Câmara Municipal de Campinas........................................................................... 64
4.1.1
Números .................................................................................................................. 65
4.1.2
Infraestrutura da Rede............................................................................................ 65
4.1.3
Cenário anterior à instalação do Zabbix ............................................................... 66
4.2
A Análise e Monitoramento ....................................................................................... 67
4.2.1
A implantação do Zabbix ........................................................................................ 72
4.2.2
Pontos Analisados ................................................................................................... 73
5
CONCLUSÃO.............................................................................................................. 79
5.1
Tempo de Resposta ..................................................................................................... 80
5.2
Identificação dos Problemas ...................................................................................... 80
5.3
Finalizando .................................................................................................................. 81
5.4
Próximos Estudos........................................................................................................ 82
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 83
ANEXO I – INSTALAÇÃO DO ZABBIX ........................................................................... 85 ANEXO II – QUESTIONÁRIO ............................................................................................ 91
1. INTRODUÇÃO Sistemas de monitoramento abrangem uma ampla categoria. Há ferramentas apropriadas para monitorar servidores, equipamentos de rede e aplicações, bem como soluções que rastreiam desempenho de sistemas e dispositivos, oferecendo tendências e análises, (COMPUTERWORLD, 2014). Algumas dessas tecnologias acionam alarmes e notificações quando detectam problemas, enquanto outras já realizam ações antes mesmo do sistema estar efetivamente crítico. Dessa forma, a ferramenta escolhida para esse trabalho foi o Zabbix, pois disponibiliza recursos como auditoria de logs, gráficos, telas e alertas. Há agentes para a maioria dos sistemas operacionais e ações automáticas, já incorporando, desta maneira, várias formas de aplicar práticas de gerenciamento e segurança. 1.1 Motivação Nos dias atuais não é possível gerenciar o ambiente de TI de forma empírica. Conforme as redes foram se desenvolvendo e integrando-se às organizações, passaram a fazer parte do cotidiano das pessoas como uma ferramenta que oferece recursos e serviços que permitem uma maior interação entre os usuários e um consequente aumento de produtividade. Houve então um grande aumento no rol de serviços oferecidos, além do inicial compartilhamento de recursos, novos serviços como correio eletrônico, transferência de arquivos, Internet, aplicações multimídias, aumentando a complexidade das redes. E assim, as organizações viram uma forma de tornarem-se mais competitivas ao fazer uso de tais recursos. “A própria infraestrutura de rede e a informática podem ser consideradas como sendo uma das responsáveis pela rápida globalização”. (NAKAMURA, 2000) Considerando este novo cenário, a gestão e o monitoramento da TI, tornaram-se parte essencial do processo de gestão de negócio. Gerir TI hoje, significa saber trabalhar as ideias e os problemas de modo a analisar a questão sob diferentes aspectos que se integram: os fatores estratégicos, funcionais, técnicos, tecnológicos, segurança e de custos. Em vista dessa constante mutação tecnológica, fez-se necessário formas mais ágeis e flexíveis de gestão permitindo estabelecer metas, monitorar os resultados e verificar, de forma objetiva, se as propostas foram atingidas através de metodologias, indicadores e métricas.
14
Os principais objetivos de gerenciar esses ambientes são reduzir custos operacionais, minimizar os congestionamentos da rede, detectar e corrigir falhas de segurança no menor tempo possível de forma a diminuir o downtime (indisponibilidade) dos sistemas, aumentar a flexibilidade de operação e integração, imprimir maior eficiência de aplicações e facilitar o uso para a organização como um todo. A realização dessas tarefas requer metodologias apropriadas, ferramentas que as automatizem e pessoal qualificado. Entre a gama de soluções possíveis para o gerenciamento de redes, uma das mais usuais consiste em utilizar um computador que interage com os diversos componentes da rede extraindo as informações necessárias ao seu gerenciamento. Isso envolve esforço para identificar, rastrear e resolver situações de falhas. Como o tempo de espera do usuário pelo restabelecimento do serviço deve ser o menor possível, tudo isso deve ser feito de maneira eficaz. Os sistemas de gerenciamento de redes apresentam a vantagem de ter um conjunto de ferramentas para análise e depuração. Eles podem apresentar também uma série de mecanismos que facilitam a identificação, a notificação e o registro de problemas, por exemplo:
Alarmes que indicam, por meio de mensagens ou bips de alerta, anormalidades na rede;
Geração automática de relatórios contendo as informações coletadas;
Facilidades para integrar novas funções ao próprio sistema de gerenciamento;
Geração de gráficos estatísticos em tempo real;
Apresentação gráfica da topologia das redes. O monitoramento do ambiente de tecnologia é devidamente importante e,
amplamente abordado dentro das melhores práticas de Gerenciamento, Governança e Segurança da Informação. Como consequência do aumento exponencial da importância da TI, a estrutura da segurança da informação ficou cada vez mais complexa, conforme é citado por (CARUSO e STEFFEN, 2006) “é difícil imaginar os processos operacionais da maioria das organizações e instituições sem o uso de recursos de processamento de informações.” Tudo isso acaba por refletir a necessidade do uso de metodologias e indicadores que permitam definir objetivos, monitorar os resultados e verificar, de forma objetiva, o gerenciamento e segurança de redes de computadores independentemente do tamanho da 15
organização, NIST (1995). Nesse contexto, negligenciar o gerenciamento da rede é algo arriscado e causa prejuízos irreparáveis para a organização. O administrador de sistemas deve atentar se uma porta de rede foi aberta sem necessidade, se um vírus ou software malicioso está alterando arquivos de sistemas, se o controle de algum sistema foi dado a pessoas sem permissão, se o arquivo de senha de algum sistema foi alterado quando ele deveria permanecer inalterado ou ainda, se um processo está consumindo todo recurso disponível em um servidor. Podemos citar como exemplo uma pesquisa solicitada pela Paessler1 sobre monitoramento de TI no Reino Unido, realizada com 300 gerentes de TI. Descobriu-se que 43% das empresas que não monitoram seus sistemas perdem, em média, duas horas por semana resolvendo problemas corriqueiros que poderiam ter sido evitados. A pesquisa também revelou que uma em cada 10 empresas que não monitoram seus sistemas perde mais de cinco horas por semana tratando desses problemas e também demonstrou que quase metade das empresas (46%) que não monitoram seus sistemas, frequentemente, recebiam alerta de problemas de equipes que não trabalhavam com TI ou, pior, dos próprios clientes. (PAESSLER, 2015). Outro dado retirado do Centro de Estudos, Respostas e Tratamento de Incidentes de Segurança do Brasil, o (CERT.BR, 2014) demonstra quantidade total de incidentes de segurança reportados no periodo que abrange 1999 a 2013, exemplifica como é importante investir na Segurança da Informação dentro das organizações.
1
http://www.paessler.com/ - É uma Empresa internacional de TI com foco no desenvolvimento de sistemas de monitoramento e gerencia.
16
Figura 1: Total de Incidentes Reportados ao Cert.br por Ano Fonte: (CERT.BR, 2014)
Como a figura 1 demonstra, houve um aumento na quantidade de incidentes reportados ao CERT.BR, principalmente a partir de 2006, isso se deve ao grande avanço de utilização de equipamentos que recorrem à internet como meio de comunicação, como por exemplo os smartphones e tablets. Esses incidentes reportados são, principalmente phishing2, spam3, ataques de negação de serviço e outros tipos de ataques que utilizam a Internet como meio de propagação. Concluindo, o gerenciamento de uma rede consiste em coletar dados de servidores, serviços e ativos de rede para análise e monitoramento dos recursos do ambiente. A ideia principal desta gerência é obter informações da rede, tratá-las, diagnosticar problemas e aplicar soluções. O gerenciamento está associado ao controle das atividades e ao monitoramento do uso dos recursos no ambiente da rede.
2
Phishing é um tipo de roubo de identidade online. Ele usa e-mail e sites fraudulentos que são projetados para roubar seus dados ou informações pessoais, como número de cartão de crédito, senhas, dados de conta ou outras informações. 3
Spam é o termo usado para referir-se aos e-mails não solicitados, que geralmente são enviados para um grande número de pessoas
17
1.2 Justificativa Tanto o setor público quanto o setor privado, no que diz respeito à segurança da informação, possuem os mesmos desafios: rápida evolução das ameaças e das tecnologias, complexidade dos ataques, dificuldade para detectar incidentes rapidamente e diminuir o tempo de reação. Entretanto, órgãos governamentais possuem o agravante de sofrerem ataques com muito mais frequências, como (ZANI, 2014) aponta: Muitas vezes, ativistas e criminosos virtuais tendem a focar seus ataques em órgãos governamentais devido a visibilidade que isto causa, além da riqueza de informação que pode ser adquirida.
E como observado em (CARUSO e STEFFEN, 2006): O bem mais válido de uma empresa pode não ser o produzido pela sua linha de produção ou serviço prestado, mas as informações relacionadas com esse bem de consumo ou serviço.
De acordo com o Relatório Anual sobre Ameaças à Segurança na Internet de 2014 (ISTR) da Symantec4, o Brasil ocupou a oitava posição no ranking de países que são origens de ataques cibernéticos e o quinto com mais computadores zumbis5. Isso demonstra como é altamente importante tratar da segurança de informação. Outro aspecto importante é definir as demandas de diversos serviços e seus graus de qualidade. A maximização de todos os recursos de TI é vital para evitar a degradação da Qualidade do Serviço, tanto para usuário (tempo de resposta por uma requisição), quanto para aplicação (recursos disponíveis). Com base nessas afirmações, buscamos garantir melhor qualidade da gerência de informação e controle da rede de dados da Câmara Municipal de Campinas, uma vez que a mesma não possuía nenhum tipo de monitoramento. Houve a necessidade de encontrar uma solução de Código-Livre, e que atendesse aos requisitos exigidos como confiabilidade, fácil curva de aprendizagem e robustez, coube ao Zabbix suprir essa demanda. E verificando a questão da viabilidade econômica, uma vez que o Zabbix é uma ferramenta de Código-
4
http://www.symantec.com/content/en/us/enterprise/other_resources/b-istr_main_report_v19_21291018.enus.pdf 5
Computadores Zumbis ou botnet são rede de computadores infectados por algum software malicioso que realizam ações sem saber com que o usuário saiba, As botnets normalmente são utilizadas para derrubar sites, enviar spam, hospedar sites falsos e realizar ataques de negação de serviço.
18
Livre sob licença da GNU General Public License (GPL) v26, não há gastos com investimentos em softwares proprietários pois funcionamento do Estado é muito diferente de uma empresa convencional devido à legislação presente, uma vez que elas criam camadas de burocracia para regrar seu funcionamento. No Brasil, leis como a 8.6667 de 1993 que definem como são realizados os processos de compra são extremamente rígidas e burocráticas. Os controles instituídos para diminuir a corrupção fazem com que mudanças e alterações tecnológicas sejam mais difíceis no Estado do que na iniciativa privada. Há ainda possibilidade de expansão e adaptação para o ambiente proposto, ao compararmos os aspectos relativos à segurança entre sistemas proprietários e livres, constatamos que em uma aplicação proprietária fica mais difícil encontrar os erros e problemas que um sistema pode ter, já em um software livre, devido a seu código-fonte ser aberto, fica mais fácil encontrá-los, ajustá-los e tratá-los. E por fim, utilizando os dados de gerência e monitoramento, desenvolver uma TI proativa, criando Indicadores-chave de performance para que haja uma forma de aferir o desempenho de serviços de TI e prevenir incidentes.
1.3 Objetivo 1.3.1
Objetivo geral Demonstrar como a ferramenta de monitoramento Zabbix pode auxiliar nas técnicas
de segurança da informação, como controles, alarmes e relatórios. 1.3.2
Objetivos específicos
Monitorar a infraestrutura a fim de diminuir e/ou mitigar falhas na segurança da rede;
Obtenção de logs para Auditoria;
Armazenamento de histórico do status do sistema para análise futura;
Relatórios para acompanhamento de disponibilidade do ambiente.
Relatórios gerenciar para acompanhamento do SLA de aplicações vitais.
6
https://www.gnu.org/licenses/gpl-2.0.html
7
http://www.planalto.gov.br/ccivil_03/leis/l8666cons.htm
19
1.4 Metodologia
Revisão bibliográfica com a finalidade de obter a melhor forma de contextualizar as informações e embasamento teórico para a implantação;
Criação de ambiente de Testes;
Implantação da ferramenta de monitoramento;
Desenvolvimento do trabalho a partir dos estudos e conclusões da pesquisa.
1.5 Organização do Trabalho O texto encontra-se organizado da seguinte maneira:
O Capítulo 2 abordará os aspectos de segurança da informação e uma série de conceitos das áreas envolvidas para compreender melhor como funciona toda a estrutura da ferramenta;
O Capítulo 3 será direcionado ao Zabbix, mostrando suas principais funcionalidades;
No Capítulo 4 será tratado o case, seu ambiente de estudo e implantação em si;
Por fim, no Capítulo 5 serão apresentadas as principais conclusões do trabalho.
20
2. CONCEITOS Antes de tratar as práticas e técnicas utilizadas junto a ferramenta Zabbix, é importante introduzir uma série de conceitos a fim de dar embasamento e melhorar o entendimento sobre a ferramenta. Serão citados seus pontos mais importantes e correlacionados à segurança da informação e ao Zabbix. 2.1 Rede de Computadores Redes de computadores são estruturas físicas e lógicas que permitem que dois ou mais dispositivos de redes troquem informações. Entende-se por estrutura física os equipamentos como roteadores8, comutadores9, cabos e os próprios computadores, e por estrutura lógica seus protocolos e tecnologias utilizadas para interconexão. Na definição de (TANENBAUM, 2003) “Uma rede de computadores é um conjunto de computadores autônomos interconectados por uma única tecnologia”. Conectar um computador a outro significa que eles podem trocar informações entre si e acessar recursos de um ou outro. Quanto maior a quantidade de dispositivos conectados, maior a troca de informação. Mesmo em uma residência é possível encontrar uma estrutura, básica, de redes de computadores: uma SmartTV, um videogame, celulares, notebooks e computadores, todos trocando informações e utilizando a Internet através de um plano de banda larga contratada.
8
Roteador (ou router) é um equipamento utilizado para interligar redes de diferentes tecnologias.
9
Comutador (ou switch) é um equipamento que funciona na camada 2 do modelo OSI, responsável por endereçar pacotes da fonte para o destino dentro de uma rede, evitando assim, colisão de pacotes
21
Figura 2: Exemplo de uma rede doméstica Fonte: Elaborado pelo próprio autor
Redes de computadores são classificadas com base em vários critérios: Quanto a sua Arquitetura, quanto a sua Topologia, quanto ao Meio de Transmissão e quanto a sua Extensão Geográfica. Citaremos os tipos de redes mais utilizados.
2.1.1
Classificação baseada em extensão geográfica
Redes Locais (LANS): Para (TANENBAUM, 2003), LANs são redes privadas contidas em um único edifício ou campus universitário com até alguns quilômetros de extensão. LANs normalmente são pequenas redes, utilizadas em casa, escritório ou empresa, e, geralmente compreendem um perímetro de um edifício, elas são conhecidas ainda por possuírem alta taxa de transmissão de dados e baixas taxas de erros. Uma maneira de descrever LANs é descrever as características que distinguem uma rede local a partir de outros tipos de redes. As características mais comuns são:
Âmbito geográfico pequeno;
A velocidade rápida;
22
Mídia especial (uso comum de cabo coaxial e fibra óptica, bem como par trançado);
A propriedade privada.
Redes Metropolitanas (MANs): De acordo com (TANENBAUM, 2003), uma rede metropolitana ou MAN é uma rede que abrange uma cidade, sendo o exemplo mais conhecido a televisão a cabo disponível em muitas cidades, podemos então entender o conceito de MAN ao aplicá-la em uma empresa com uma central e várias filiais localizadas em uma mesma cidade, por exemplo. Essas filiais possuem suas LANs e também estão conectadas com a central.
Figura 3: Exemplo de rede Metropolitana (MAN) Fonte: (TANENBAUM, 2003)
Redes Geograficamente Distribuídas (WANs): São redes que compreendem grandes áreas, como países e continentes. São ligações de várias MANs. A topologia de rede, referese ao “layout físico” e ao meio de conexão dos dispositivos na rede, ou seja, como estes estão conectados. Os pontos no meio onde são conectados recebem a denominação de nós, sendo que estes “nós” sempre estão associados a um endereço, para que possam ser reconhecidos pela rede”.
23
Figura 4: Exemplo de uma rede Continental (WAN) Fonte: (TANENBAUM, 2003)
Quanto ao que diz respeito a Topologia das redes de computadores, temos: 2.1.2
Classificação baseada na Topologia
Topologia em Anel (Token Ring): Cada computador possui dois cabos, cada um destes conectado a seus computadores adjacentes. Nessa topologia há um token que circula a rede. Quando esse token chega vazio em um micro, este tem a possibilidade de enviar um quadro de dados para outro micro da rede. O token10 circula indefinidamente, sempre procurando o endereço do destino do quadro de dados e assim repetir todo processo
10
O Token Ring utiliza um símbolo formado por uma trama de três bytes (token), que funciona ao circular em uma topologia de anel onde as estações precisam aguardar a sua recepção para poderem transmitir. A partir daí, a transmissão é realizada durante uma pequena janela de tempo e apenas pelas que possuem o token.
24
novamente. Importante citar que essa topologia é quase imune a colisão de pacotes, devido à forma do token trabalhar.
Figura 5: Topologia em Anel Fonte: Elaborado pelo próprio autor
Topologia em Estrela: Os nós (estações) são conectados por um ativo de rede concentrador, normalmente um switch. Se um cabo partir apenas a conexão dos ativos que ele conecta irá ser interrompida. É a principal topologia utilizada em redes Ethernet.
Figura 6: Topologia em Estrela
25
Fonte: Elaborado pelo próprio autor
Topologia em Barramento: Nesta configuração todos os nós se ligam ao mesmo meio de transmissão. A barra é geralmente compartilhada em tempo e frequência, permitindo transmissão de informação. Essa topologia utiliza como meio de transmissão o cabo coaxial. Há de se observar que caso haja vários computadores interligados através de um HUB essa estrutura não se caracteriza estrela, e sim barramento, pois um HUB utiliza um único meio de transmissão, ou seja barramento. Essa estrutura acaba recebendo o nome de Estrutura Física de Estrela e Lógica de Barramento.
Figura 7: Topologia em Barramento Fonte: Elaborado pelo próprio autor
Topologia sem Fio: É a topologia que permite que computadores se comuniquem sem a necessidade de cabos. Para isso é necessário um equipamento conhecido como Ponto de Acesso ou Access Point11. Suas principais características são a pouca segurança, taxa elevada de erros e, em contrapartida, sua flexibilidade e mobilidade.
Topologia Mista: Redes que utilizam mais do que uma topologia ao mesmo tempo. Isso tem se tornado cada vez mais comum, principalmente a utilização de várias topologias
11
Access Point é um dispositivo que conecta rede sem fio para um sistema de fios. Então tem que ter pelo menos duas interfaces: wireless - WLAN - com padrão 802.11, e com fio - LAN - usando 802.3.
26
estrelas, formando uma topologia em arvore, se comunicando com uma rede de topologia sem fio.
2.2 Modelos de Referência Modelos de referência são definições que estabelecem descrição, estrutura de uma determinada tecnologia, um ponto de referência que buscamos seguir para que possamos nos comunicar. Em outras palavras, um modelo de referência pode ser comparado ao processo de comunicação, pois para nos comunicarmos necessitamos de mensagem, meio, canal e estes são componentes de todo contexto da comunicação. 2.2.1
Protocolos de Rede Para que haja uma comunicação efetiva, dispositivos de rede usam os protocolos,
que são um conjunto de diretrizes ou regras, para a troca de informação pela rede, ou seja, protocolos de redes são a forma de ativos e computadores se comunicarem por uma rede de dados, (ANDERSON e BENEDETTI, 2011). Entretanto, para que haja realmente a comunicação vários protocolos são utilizados, cada um com uma finalidade diferente. Há uma infinidade de protocolos, citaremos alguns protocolos da camada de aplicação do modelo de referência TCP/IP (explicado logo a baixo) que são os mais utilizados.
HTTP: HyperText Transfer Protocol é um protocolo de comunicação utilizado para transferência de páginas HTML do computador para a Internet.
SNMP, Simple Network Management Protocol é um protocolo de gerência típica de redes TCP/IP, da camada de aplicação, que facilita o intercâmbio de informação entre os dispositivos de rede, como placas e comutadores. O SNMP será detalhado mais a baixo.
POP3: Post Office Protocol é um protocolo utilizado no acesso remoto a uma caixa de correio eletrônico. Ele está definido no RFC 1225 e permite que todas as mensagens contidas numa caixa de correio eletrônico possam ser transferidas sequencialmente para um computador local.
27
SMTP: Simple Mail Transfer Protocol (SMTP) é o protocolo padrão para envio de e-mails através da Internet. SMTP é um protocolo relativamente simples, baseado em texto simples, onde um ou vários destinatários de uma mensagem são especificados sendo, depois, a mensagem transferida.
NTP: Network Time Protocol é um protocolo para sincronização dos relógios dos computadores baseado no UDP (TCP/IP), baseados em alguma fonte confiável de tempo.
DHCP: Dynamic Host Configuration Protocol é um protocolo de serviço TCP/IP que oferece configuração dinâmica de terminais, com concessão de endereços IP de host e outros parâmetros de configuração para clientes de rede.
Como citado anteriormente, estes são protocolos da camada de aplicação, porém não os únicos. Entretanto, é comum o monitoramento de tais protocolos para verificar se o serviço que eles empregam está funcionando.
2.2.2
Modelo de referência OSI O modelo OSI (Open System Interconnection) foi desenvolvido em 1984 pela ISO
(International Standardization Organization). Seu propósito foi desenvolver um padrão aberto, que pudesse ser seguido por futuros protocolos de rede. Esse modelo possui sete camadas, também denominadas de níveis, que juntas formam uma pilha, onde cada camada na pilha recebe e provê informações para as camadas adjacentes. Tanto (TANENBAUM, 2003) quanto (TORRES, 2014) veem como objetivo da OSI facilitar a interconexão de sistemas de computadores, a ISO desenvolveu esse modelo de referência teórico chamado para que os fabricantes pudessem criar protocolos a partir desse modelo, tendo como objetivo a padronização internacional. Teoricamente, cada camada possui um protocolo responsável por ela, cada camada presta um serviço para sua camada superior, esse serviço é encapsulado, ou seja, cada camada não sabe como e o que foi feito pela outra camada, basta ela saber o que precisa
28
receber e o que precisa enviar. Protocolos são regras de controle que gerem os pacotes que são trocados pelas camadas. O modelo OSI possui sete camadas, completamente independente entre si, sendo elas:
Aplicação: Responsável pela interface entre a pilha de protocolos e o aplicativo que solicitou ou receberá a informação. Exemplo de protocolos dessa camada: HTTP, FTP, SMTP;
Apresentação: Responsável por converter os dados recebidos da camada de aplicação em um formato comum para ser usado pela transmissão desse dado, nessa camada que ocorre a compressão de dados e também a criptografia, o SSL é um protocolo dessa camada;
Sessão: Responsável por estabelecer uma sessão de comunicação e sincronização;
Transporte: Responsável por receber os dados vindo da camada de sessão, dividilos em pacotes de dados, repassar e assegurar que todos chegarão à camada de rede. Os protocolos mais conhecidos dessa camada são o TCP e o UDP;
Rede: Responsável pelo endereçamento lógico dos pacotes de dados (comunicação entre diferentes arquiteturas de rede, por exemplo um pacote de dados saindo de uma rede Ethernet e chegando, com sucesso, a uma rede Token Ring) e pela tradução de endereços lógicos em endereços físicos, é responsabilidade da camada de Rede saber qual a rota que os pacotes terão que realizar para chegar ao seu destino. O protocolo IP pertence a essa camada;
Enlace: Ou link de dados é responsável por receber os pacotes da camada de rede e transformá-los em quadros ou células que irão trafegar pela rede, adicionando informações como endereço da placa de rede de destino e checksum. É responsabilidade dessa camada, verificar se o meio está disponível para uso;
29
Física: É a responsável por tratar a transmissão dos bits puros, ou seja transmite os quadros em sinais elétricos, luminosos ou de radiofrequência. Assim como a camada de Enlace, a camada Física é controlada por hardware. Fazem parte dessa camada os protocolos Ethernet, Token Ring, FDDI, X.25, Retransmissão de Quadros, RS232, v.3;
Figura 8: O modelo de referência OSI Fonte: (TANENBAUM 2003)
A figura 8 demonstra, de acordo com (TANENBAUM, 2003), como estão dispostas as camadas do modelo OSI e qual caminho segue seus protocolos. Cabe observar, que essas definições foram tratadas de forma resumida, visto que elas são assunto para livros inteiros.
30
2.2.3
Modelo de referência TCP/IP O conjunto de protocolos TCP / IP funciona em um modelo de rede OSI. Cada
camada tem sua própria funcionalidade definida de forma muito clara. O TCP é um protocolo da camada de transporte, e o IP é uma camada de rede. O TCP gerencia a conexão e a integridade dos dados, enquanto que o IP é responsável pela entrega de dados para o destino correto. A camada de enlace controla a transmissão e recepção de pacotes de dados através da conversão em sinais digitais e conversão de sinais em dados digitais. O meio físico, na verdade, carrega todos os dados e sinais de controle, sob a forma de tensão ou ondas, (SETH e VENKATESULU, 2008). O IP, por outro lado, transporta dados TCP através da internet. O IP tem muitas funcionalidades, como roteamento, enviando de volta mensagens de erro para o remetente, criptografia de pacotes, NAT, e assim por diante. O modelo TCP/IP baseia-se em quatro camadas, todos os protocolos que pertencem ao conjunto de protocolos TCP/IP estão localizados nas três camadas superiores.
Figura 9: O Modelo TCP/IP Fonte: (MICROSOFT TECHNET, 2015)
Aplicação: Define os protocolos de aplicativos TCP/IP e como os programas host estabelecem uma interface com os serviços de camada de
31
transporte para usar a rede. HTTP, HTTPS, FTP, e muitos outros conhecidos fazem parte desta camada;
Transporte: Fornece gerenciamento de sessão de comunicação entre computadores host. Define o nível de serviço e o status da conexão usada durante o transporte de dados, exemplo de pacotes são TCP, UDP, RTP;
Internet: Empacota dados em quadros IP, que contêm informações de endereço de origem e de destino usadas para encaminhar quadros entre hosts e redes. Executa o roteamento de quadros IP. Os protocolos IP, ICMP, ARP, RARP pertencem a essa camada;
Interface com a Rede: Especifica os detalhes de como os dados são enviados fisicamente pela rede, inclusive como os bits são assinalados eletricamente por dispositivos de hardware que estabelecem interface com um meio da rede, como cabo coaxial, fibra óptica ou fio de cobre de par trançado. Os protocolos Ethernet, Token Ring, FDDI, X.25, Retransmissão de Quadros, RS-232, v.3 fazem parte desta camada.
Figura 10: Comparação OSI / TCP Fonte: (TORRES, 2014)
32
2.3 Gerenciamento de Rede O gerenciamento de rede pode ser definido como a coordenação (controle de atividades e monitoração de uso) de recursos materiais (modems, roteadores, etc.) e lógicos (protocolos), fisicamente distribuídos na rede, assegurando, na medida do possível, confiabilidade, tempos de resposta aceitáveis e segurança das informações. O modelo clássico de gerenciamento pode ser dividido em três etapas:
Coleta de dados: um processo, em geral automático, que consiste de monitoração sobre os recursos gerenciados;
Diagnóstico: consiste no tratamento e análise realizados a partir dos dados coletados. O computador de gerenciamento executa uma série de procedimentos (por intermédio de um operador ou não) com o intuito de determinar a causa do problema representado no recurso gerenciado;
Ação ou controle: Uma vez diagnosticado o problema, cabe uma ação, ou controle, sobre o recurso, caso o evento não tenha sido passageiro (incidente operacional).
2.3.1
O Modelo de gerenciamento FCAPS O FCAPS é um modelo de gerência de rede criado pela ISO para auxiliar as
principais funções de sistemas de gerenciamento de redes. Ele está descrito na ISO/IEC 7498-412. O FCAPS inclui o fornecimento, integração e coordenação de hardwares, softwares, além do profissional humano para monitorar, testar, configurar, consultar, analisar, avaliar e controlar uma rede. Seus recursos necessitam atender a requisitos de desempenho, qualidade de serviço (QoS), segurança e operação em tempo real dentro de um custo compreensivelmente justo para empresa ou corporação. Ele é baseado em cinco princípios de gerencia, sendo eles:
12
http://www.iso.org/iso/catalogue_detail.htm?csnumber=14258
33
Gerenciamento de falha: O gerenciamento de falha engloba: detecção da falha, isolamento e correção de operações anormais do ambiente OSI. Falhas causam sistemas abertos a não conseguirem atingir seus objetivos operacionais, e elas podem ser constantes ou momentâneas. Falhas se manifestam em eventos particulares, como erros, na operação de um sistema aberto. A detecção de erros fornece a capacidade de identificar falhas. Funções do gerenciamento de falhas incluem:
Manter e examinar logs de erros
Agir de acordo com notificações de detecção de erros
Rastrear e identificar falhas
Realizar sequências de testes de diagnóstico
Corrigir falhas
Gerenciamento de configuração: O gerenciamento de configuração identifica, exerce controle, coleta e fornece dados para sistema abertos com o objetivo de preparar, inicializar, prover a contínua operação e terminar serviços de interconexão. Funções do gerenciamento de configuração incluem:
Definir os parâmetros que controlam a operação cotidiana do sistema aberto
Associar nomes com objetos gerenciados e conjuntos de objetos gerenciados
Inicializar e encerrar objetos gerenciados
Coletar informações da demanda sobre o estado atual do sistema aberto
Obter informações sobre mudanças significativas no estado do sistema aberto
Alterar a configuração do sistema aberto
Gerenciamento de contabilidade: O gerenciamento de contabilidade possibilita que sejam estabelecidas cobranças pelo uso dos recursos no ambiente OSI, e que os custos sejam identificados. Funções do gerenciamento de contabilidade incluem:
Informar aos usuários sobre custos gerados ou recursos consumidos
Possibilitar que sejam estabelecidos limites de contabilidade e tarifas diferenciadas associadas ao uso dos recursos
34
Permitir que os custos sejam combinados quando múltiplos recursos forem requisitados para alcançar um determinado objetivo de comunicação
Gerenciamento de desempenho: Para permitir a avaliação do comportamento dos recursos no ambiente OSI, assim como a eficácia nas atividades de comunicação, existe o gerenciamento de desempenho. Suas funções incluem:
Coletar informações estatísticas
Manter e examinar logs dos estados do sistema
Determinar o desempenho do sistema sob condições naturais e artificiais
Modificar os modos de operação do sistema com o objetivo de conduzir atividades de gerenciamento de desempenho
Gerenciamento de segurança: O objetivo do gerenciamento de segurança é apoiar a aplicação de políticas de segurança através de funções que incluem:
A criação, deleção e controle de serviços e mecanismos de segurança
A distribuição de informações de segurança
A descrição de eventos relacionados à segurança
F
FAULT (Falha)
C
CONFIGURATION (Configuração)
A
ACCOUNTING (Contabilidade)
P
PERFORMANCE (Desempeho)
S
SECURITY (Segurança)
Figura 11: O modelo de gerência FCAPS Fonte: Elaborado pelo próprio autor
35
2.3.2
SNMP Devido a evolução dos ambientes computacionais, houve também um aumento na
complexidade de gerenciar e monitorar. Para resolver esse problema, surgiram várias soluções para auxiliar no gerenciamento de redes. Esses programas de gerenciamento de rede reúnem várias ferramentas de monitoramento e de controle. Sua função é coletar estatísticas do movimento dos dados e vigiar as condições que excederem o limite dos programas. Ao detectar algum problema, alertam o programa de gerenciamento central, o que pode desencadear ações de reinicialização, roteamento ou em pedido de ajuda através de alarmes e avisos, (MAURO e SCHMIDT, 2005). De uma forma geral, os fabricantes adotam padrões que permitem a operação de programas gerenciadores. Dentre esses o mais conhecido é SNMP. O SNMP foi apresentado em 1988 para atender a demanda por um protocolo que pudesse gerenciar dispositivos IP. É um protocolo da camada de aplicação que tem como objetivo coletar e transportar informações dos dispositivos encontrados na rede. Com isso ele possibilita ao administrador gerenciar o desempenho da rede monitorando hardware de equipamentos como interfaces de redes, processadores, memória, além de outros dados como fabricante, modelo e temperatura. Ele usa um simples conjunto de comandos para recuperar e configurar informações. Muitos tipos de dispositivos suportam SNMP, incluindo roteadores, switches, servidores, estações de trabalho, impressoras, modem e fontes de alimentação ininterrupta (nobreaks). A informação que você pode monitorar varia de itens relativamente simples e padronizados, como a quantidade de tráfego de uma interface de rede a informações como a temperatura do ar dentro de um roteador, MAURO e SCHMIDT (2005) O SNMP trabalha com basicamente cinco comandos:
GET: Leitura de um valor de uma ou mais variáveis
SET: Atribui um valor a uma variável
GET-NEXT: permite ler o valor de uma ou mais instâncias de variáveis sem conhecer o nome exato da mesma
GET-RESPONSE: retorna o resultado de uma operação de leitura
36
TRAP: Um comando que o dispositivo gerenciado envia ao agente com alguma informação. É um evento disparado pelo objeto gerenciado envia ao NMS
A topologia de uma rede gerenciada por meio de SNMP inclui 03 (três) elementos:
1. Dispositivos Gerenciados: São os dispositivos da rede que serão gerenciados e que possuem suporte ao protocolo SNMP, exemplo: roteadores, switches, dispositivos wireless, servidores entre outros menos comum como catracas e câmeras IP.
2. Agentes: Módulos de software que armazenam informações dos dispositivos gerenciados (roteadores, switches...) em uma base de informações altamente estruturada conhecida como MIBs (Management information base). Em um roteador pode-se ler a quantidade de pacotes que passam por uma interface, estes dados são armazenados pelos agentes em uma base local (MIBs) dentro do próprio roteador. Os agentes também podem armazenar informações como quantidade de processamento, ocupação
de
memória,
temperatura
do
dispositivo,
quantidade mensagens de erro, número de bytes e de pacotes recebidos e enviados, quantidade de mensagens de broadcast enviadas e recebidas entre ouras varáveis de gerenciamento.
3. Sistemas de Gestão de Redes (NMS - Network-Management Systems): Sistema responsável pelo monitoramento e controle dos dispositivos gerenciados. Permite que os administradores de redes visualizem as informações de leitura SNMP, através de gráfico, tabelas, relatórios, alertas por e-mail ou envio de SMS. Um exemplo de NMS é o Zabbix ou Nagios.
37
MIB Management Information Base
COMUNIDADE SNMP
MIB Management Information Base
SNMP SET
NMS Estação de Gerenciamento
SNMP GET / GET - NEXT
Dispositivo de Rede
SNMP TRAP
Figura 12: Funcionamento do SNMP Fonte: Elaborado pelo próprio autor
O Internet Engineering Task Force13 (IETF) é responsável pela definição do padrão de protocolos que regem o tráfego de Internet, incluindo SNMP. O IETF é quem publica os RFC (Requests for Comments), que são as especificações para muitos protocolos existentes. A seguinte lista inclui todas as versões do SNMP atuais. SNMP versão 1 (SNMPv1): O SNMPv1 tem sua origem no protocolo SGMP (Simple Gateway Monitor Protocol) que está definido na RFC 1028. É a versão inicial do protocolo SNMP e está definido na RFC 1157. A segurança da SNMPv1 é baseada em comunidades, que nada mais são do que as senhas de texto simples: uma sequência de caracteres que permite que qualquer aplicação baseada em SNMP que a conheça possa ganhar o acesso à informação de gestão de um dispositivo. Há tipicamente três comunidades em SNMPv1: somente leitura, leitura e escrita, e trap, (MAURO e SCHMIDT, 2005). O SNMPv1 consiste de três documentos:
RFC 1155 define o Structure of Management Information (SMI). Ou seja, os mecanismos usados para descrever e nomear os objetos que serão gerenciados
RFC 1212 define um mecanismo de descrição mais conciso mas é inteiramente consistente ao SMI.
13
RFC 1157 define o Simple Network Management Protocol (SNMP)
https://www.ietf.org/
38
SNMP versão 2 (SNMPv2): Na versão 2 do SNMP foram introduzidas várias melhorias em relação à versão anterior, entre elas vale a pena destacar a possibilidade de comunicação entre entidades gerentes através das mensagens InformRequest, que tornou possível o gerenciamento distribuído. É definido na RFC 3416, RFC 3417 e RFC 3418. O SNMPv2 possui algumas vantagens sobre o SNMPv1. São elas:
Melhora na eficiência e na performance: operador GetBulkRequest;
Notificação de evento confirmado: operador InformRequest;
Maior detalhamento dos erros;
Modos facilitados de criação e deleção de linhas na MIB;
Melhorias na definição da linguagem de dados.
Alguns objetivos iniciais do projeto não foram implementados. Os objetivos não alcançados incluem o fornecimento de segurança tais como:
Autenticação: identificação da origem, integridade da mensagem;
Privacidade: confidencialidade;
Autorização e controle de acesso.
SNMP versão 3 (SNMPv3): Além de ser a mais recente versão do SNMP, O SNMP versão 3 foi criado para suprir uma necessidade de padronização que se fez necessária com as várias variações do SNMPv2 que tentavam criar soluções de segurança para o protocolo. Sua principal contribuição, a gestão da rede, é a segurança. Ele adiciona suporte para autenticação forte e comunicação privada entre entidades gerenciadas. Em 2002, ele finalmente fez a transição do projeto de norma para a norma completa. Os seguintes RFC definiram a norma: RFC 3410, RFC 3411, RFC 3412, RFC 3413, RFC 3414, RFC 3415, RFC 3416, RFC 3417, RFC 3418 e RFC 2576, (MAURO e SCHMIDT, 2005). Além das definições das questões de segurança, o projeto do SNMPv3 também objetivou uma padronização de implementação das entidades (agente/gerente), modularizando suas funcionalidades, o que facilita a evolução de alguns mecanismos do protocolo sem exigir que novas versões sejam lançadas. Outros objetivos eram a manutenção
39
de uma estrutura simples, facilitar a integração com outras versões e, sempre que possível, reaproveitar as especificações existentes. O SNMPv3 incorporou o SMI e o MIB do SNMPv2, assim como também utilizou as mesmas operações do SNMPv2, apenas com uma reescrita da norma para uma compatibilização da nomenclatura. Novas ferramentas foram adicionadas no SNMPv3. São elas:
2.3.3
Segurança;
Autenticação e privacidade;
Autorização e controle de acesso;
Modelo administrativo;
Nomeação das entidades;
Gerência das chaves;
Notificação dos destinos;
Sistemas de Monitoramento e Gerência Um sistema de gerência de rede pode ser definido como um conjunto de ferramentas
integradas para o monitoramento e controle, que oferece uma interface única e que traz informações sobre o status da rede podendo oferecer ainda um conjunto de comandos que visam executar praticamente todas as atividades de gerenciamento sobre o sistema em questão. Segundo (FRY e NYSTROM, 2009), a arquitetura geral dos sistemas de gerenciamento de redes apresenta quatro componentes básicos: “Os elementos gerenciados, as estações de gerência, os protocolos de gerenciamento e as informações de gerência.” Os elementos gerenciados são dotados de um software chamado agente, que permite o monitoramento e controle do equipamento através de uma ou mais estações de gerência. A princípio, qualquer dispositivo de rede (impressoras, roteadores, repetidores, switches, etc.) pode ter um agente instalado. Nas estações de gerência encontramos o software gerente, responsável pela comunicação direta desta estação com os agentes nos elementos gerenciados. Claro que para que aconteça a troca de informações entre o gerente e os agentes é necessário ainda um
40
protocolo de gerência que será o responsável pelas operações de monitoramento e de controle, (FRY e NYSTROM, 2009). Gerentes e agentes podem trocar tipos específicos de informações, conhecidas como informações de gerência. Tais informações definem os dados que podem ser utilizados nas operações do protocolo de gerenciamento. O sistema de gerenciamento de uma rede é integrado e composto por uma coleção de ferramentas para monitorar e controlar seu funcionamento. Uma quantidade mínima de equipamentos separados é necessária, sendo que a maioria dos elementos de hardware e software para gerenciamento está incorporada aos equipamentos já existentes. Grande parte das ferramentas de gerência de redes utiliza o RRDTool, um sistema de base de dados Round-Robin criado por Tobias Oetiker sob licença GNU GPL. Foi desenvolvido para armazenar uma série de dados numéricos sobre o estado de redes de computadores, porém pode ser empregado no armazenamento de qualquer outra série de dados como temperatura, CPU e outros. RRD é a abreviação de Round Robin Database. Alguns dos principais Sistemas de monitoramento da atualidade, são:
NAGIOS: É uma aplicação de monitoramento de redes de código aberto bastante popular. Ele permite monitorar tanto hosts quanto serviços, alertando o administrador quando ocorrerem problemas na rede. É utilizado por administradores de redes para que possam ter um controle sobre os serviços e equipamentos de sua rede. Foi idealizado inicialmente para ser utilizado em sistemas operacionais Linux e, a partir da versão 3.0.4, tornou-se compatível com outros Sistemas Operacionais, (KOCJAN, 2014). A características principais do Nagios são: o monitoramento de serviços de rede como tráfego de dados de host e serviços que podem ser definidos pelo administrador da rede, além de monitorar serviços como SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol), HTTP (HyperText Transfer Protocol), NNTP (Network News Transfer Protocol), ICMP (Internet Control Message Protocol) e SNMP (Simple Network Management Protocol). O Nagios monitora também os recursos de servidores como logs do sistema, carga do processador, uso de memória e uso de disco. O Nagios também trabalha com plug-ins, permitindo adicionar novas funcionalidades ao mesmo. Os plug-ins podem ser desenvolvidos em qualquer linguagem, mas a grande maioria é desenvolvida em perl e python, (BENINI e DAIBERT, 2013).
41
Um de seus pontos negativos é sua interface web, que não foi atualizada com o passar dos anos e tornou-se pouco amigável, principalmente para a configuração do sistema. Suas principais características são:
Monitoramento de serviços de rede;
Monitoramento de recursos de dispositivos;
Monitoramento de sensores;
Diversos plug-ins criados pela comunidade
Notificação de usuários sobre falhas
Possibilidade de armazenar dados em arquivos de texto ao invés de banco de dados.
Figura 13: Tela Inicial – Nagios Fonte: (BENINI e DAIBERT, 2013)
ZENOSS: O ZenOSS foi desenvolvido em 2002. Trata-se de um sistema robusto, e uma de suas características é sua facilidade na configuração, gráficos de qualidade e uma comunidade ativa, (MOHR, 2012). Toda sua coleta de dados é feita via SNMP, bastando o servidor buscar essas informações no dispositivo a ser monitorado. Isso afeta um pouco a questão de flexibilidade
42
já que os únicos dados capturados são os disponíveis nas tabelas MIB do dispositivo com SNMP. Seu ponto negativo é a segurança, pois não há uma documentação específica neste quesito, além de seu front-end ser web e não possuir o mesmo nível de segurança de seus concorrentes. Sua instalação é mais complexa que os demais o que exige um conhecimento mais profundo em ambientes Unix-Like. Outro ponto ruim é que sua versão Open Source é limitada, necessitando adquirir a versão paga para ter acesso a todos os recursos da ferramenta Sua interface também é a que mais se destaca, pois é atrativa e bem trabalhada. Entretanto, sua interface web é lenta devido a ser desenvolvida em Zope, (BADGER, 2008).
Figura 14: Interface do ZenOSS Fonte: Zenoss Inc.14
CACTI: É uma ferramenta que recolhe e exibe informações sobre o estado de uma rede de computadores através de gráficos, sendo um front-end para a ferramenta RRDTool, que armazena todos os dados necessários para criar gráficos e inseri-los em um banco de dados MySQL. Foi desenvolvido para ser flexível de modo a se adaptar facilmente a diversas necessidades, bem como ser robusto e fácil de usar. Monitora o estado de elementos da rede e programa bem como a largura de banda utilizada e uso de CPU. O Front-end é
14
http://www.zenoss.com/
43
escrito em PHP e contém suporte as três versões do protocolo SNMP. Sua arquitetura prevê expansão através de plug-ins criadas pela comunidade que adicionam novas funcionalidades, (BLACK, 2008).
Dentre os principais recursos destacam-se
Manipulação de dados em gráficos;
Suporte à SNMP
Templates para gráficos;
Templates para fonte de dados
Templates para dispositivos;
Autenticação por LDAP.
Entretanto, uma grande dificuldade encontrada pelos usuários do CACTI é o fato do mesmo não possuir agente de descoberta automático, assim o administrador de rede tem que adicionar cada host manualmente à ferramenta.
Figura 15: Painéis do CACTI Fonte: CACTIC.NET15
15
http://www.cacti.net
44
Essas soluções possuem suas vantagens e desvantagens e são semelhantes entre si, e seu desempenho poderá variar dependendo do escopo em que forem implantadas. Entretanto, todas são concorrentes da solução escolhida, o Zabbix. 2.4 Segurança da Informação e de Redes O Security Handbook NIST Computer (NIST, 1995) define a segurança da computação seguinte forma: A proteção conferida a um sistema de informação automatizada, a fim de atingir os objetivos aplicáveis de preservação da integridade, disponibilidade e confidencialidade dos recursos do sistema de informação (inclui hardware, software, firmware, informações / dados e telecomunicações).
A gestão de segurança de TI evoluiu consideravelmente ao longo das últimas décadas. Isso tem ocorrido em resposta ao rápido crescimento e dependência de sistemas informáticos de trabalho e do aumento associado em riscos para esses sistemas. Na última década, foram publicadas uma série de normas nacionais e internacionais. Estes representam um consenso sobre a melhor prática no campo. A Organização Internacional de Normalização (ISO) reviu e consolidou um número destas normas na série ISO 27000, (BOSWORTH e JACOBSON, 2014). A informação é um ativo que, como qualquer outro ativo importante, tem um valor para a organização e, consequentemente necessita ser adequadamente protegido. De acordo com (CARUSO e STEFFEN, 2006), independente do setor da economia em que a organização atue, as informações estão relacionadas intimamente com seus processos de produção e de negócios. Hoje, a crescente complexidade do mercado, a forte competição e a velocidade imposta pela modernização das relações corporativas elevaram a importância estratégica da informação para os negócios. De sua gestão, pode depender o sucesso ou fracasso de uma organização A descentralização da informação em compartimento em redes, a necessidade de conexão entre parceiros, o acesso rápido, a atualização constante da base de dados, a integração de unidade de negócios e colaboradores internos, a disponibilidade para o cliente, tudo isto incluindo na grande trama digital em constante expansão que é a internet, são apenas alguns dos fatores que transformaram a informação na principal moeda de troca do mundo corporativo.
45
A Segurança da informação é caracterizada, de acordo com (FERREIRA, 2003) e também (STALLINGS, 2012) por três propriedades principais:
Confidencialidade:
Propriedade que limita o acesso à
informação a entidades legítimas, ou seja, àquelas autorizadas pelo proprietário de tal informação
Disponibilidade: Se refere ao acesso à informação quando é
preciso, com fácil localização e disseminação. Propriedade que garante que a informação esteja sempre disponível para seu uso legítimo, ou seja, pelos usuários autorizados pelo proprietário da informação.
Integridade: Se refere à garantia que a informação não sofreu
nenhum tipo de fraude. Propriedade que garante que a informação manipulada mantenha todas as características originais definidas pelo proprietário da informação, incluindo o controle de mudanças e a garantia de seu ciclo de vida (nascimento, manutenção e destruição).
Figura 16: A pirâmide da Segurança da Informação Fonte: (STALLINGS, 2012)
O maior desafio da indústria mundial de segurança é, e talvez sempre tenha sido, oferecer soluções no tempo mais curto possível, a partir da descoberta de determinada ameaça ou problema. É importante ressaltar que muitas empresas não sobrevivem mais do que poucos dias a um colapso em seu fluxo de informação, (CARUSO e STEFFEN, 2006). Uma das principais portas de entrada para incidentes de segurança no setor corporativo é a Internet. Isto se deve ao fato de que a maioria das empresas permite que seus 46
funcionários e terceiros, tenham acesso total, por extranets, por links dedicados ou pela web. Apesar do uso de conexões criptografadas e outros cuidados, na prática, isso pode não ser suficiente. É importante que a empresa avalie no mapa da rede, todos os pontos que devem ser cobertos por processos seguros. Isso pode ser feito começando pela avaliação de infraestrutura de TI e a utilização do diagrama da arquitetura da rede para determinar como e onde os usuários internos e externos podem ter acesso ao ambiente ou sistema. Em seguida, é recomendado que os sistemas da instituição sejam checados contra invasões, fisicamente e logicamente. Fisicamente podemos verificar quem possui acesso ao local e por quanto tempo pode ficar no mesmo, por exemplo. Já a segurança lógica pode ser avaliada através de ferramentas de escaneamento de portas, de proxies e verificação de serviços desnecessários nos servidores. Possuir uma lista com todos os servidores e sistemas críticos para a empresa constitui outra boa iniciativa, complementada pela lista de funcionários que instalaram-na e/ou desenvolveram-na. Também é fundamental criar uma lista para todos os administradores de rede, especificando quem são os encarregados dos sistemas, um por um. Para funcionários, deve ser definida uma política que explique como utilizar de forma adequada as informações corporativas. Por exemplo, podem ser enumeradas as medidas que devem ser tomadas quando surgir uma suspeita de invasão ou infecção na rede ou em um microcomputador. Estes profissionais também devem ser instruídos sobre como lidar com suas senhas de aceso aos sistemas e se podem ou não deixar seus computadores ligados ao sair, para evitar a exposição de informações internas a pessoas não autorizadas, (STALLINGS, 2012). 2.4.1
Ameaças e Vulnerabilidades São
consideradas
ameaças
quaisquer
elementos
que
possam
explorar
vulnerabilidades e, dessa forma, causar problemas nos ativos de rede e em seus sistemas. Algumas classificações acerca de ameaças são, (SOUZA, 2007):
Ameaças Naturais:
Condições naturais, como terremotos, incêndios,
inundações; 47
Ameaças Intencionais: Propositais, como vírus de computador, fraude, vandalismo, roubo de informações, etc;
Ameaças Involuntárias: Acidentes, falhas não voluntárias, causado por falta de conhecimento ou sem intenção.
Vulnerabilidades são falhas ou deficiências do sistema de origens diversas, que quando não identificadas a tempo ou não devidamente tratadas podem revelar brechas para ataques, (NAKAMURA, 2000). Essas vulnerabilidades provém de diversas origens, como lista SEMOLA16 apud (SOUZA, 2007):
Agentes da Natureza: Poeira, calor excessivo, humidade, elementos que causam dano a ativos;
Hardware: Hardware antigo, tecnologia ultrapassada, mal fixação;
Software: Falhas no desenvolvimento;
Mídias de armazenamento: Falhas no armazenamento e inclusão de malwares, são alguns exemplos;
Meios de comunicação: Cabeamento corrompido, baixa segurança em Hotspots.
Humanas: Aspectos relacionados ao vazamento de informações, má utilização de equipamento e software, falta de treinamento, etc.
2.4.2
Mecanismos de Segurança de Redes São chamadas de ferramentas de segurança de informação o conjunto de software,
hardware e técnicas empregadas com o objetivo de combater ataques à rede, diminuir vulnerabilidades e, consequentemente, aumentar a segurança da rede, (SOUZA, 2007). O desenvolvimento de bons mecanismos de segurança para redes é, geralmente, baseado nos princípios de STALLINGS:
O Antivírus: Ferramentas antimalware são aquelas que procuram detectar e, então, anular ou remover os códigos maliciosos de um computador. O antivírus é o termo
16
http://www.semola.com.br/
48
mais utilizado para esse tipo de software pois, apesar do nome indicar que o programa apenas irá atuar contra vírus, a grande maioria dos novos aplicativos antivírus também faz varreduras de outras pragas virtuais como worms, trojans e adwares, como apontado pela cartilha do (CERT.BR, 2014). Faz varredura de arquivos maliciosos disseminados pela internet ou por correio eletrônico. Basicamente, sua função se relaciona com a ponta do processo, ou seja, com o usuário que envia e recebe dados; as vezes pode estar no servidor ou inclusive em um provedor de serviços, garantindo assim, a integridade dos dados.
Balanceamento de Carga: Ferramentas relacionadas com a capacidade de operar de cada servidor da empresa. Permitem que, em horários de grande utilização da rede, seja possível determinar a hierarquia do que está sendo trafegado, assim como o equilíbrio da carga disseminada entre os servidores. Um dos papéis da segurança corporativa é garantir a disponibilidade da informação, algo que pode ser comprometido, se não houver um controle preciso da capacidade de processamento da empresa.
Firewall: É uma solução de segurança baseada em hardware ou software que, a partir de um conjunto de regras ou instruções, analisa o tráfego de rede para determinar quais operações de transmissão ou recepção de dados podem ser executadas. Atua como uma barreira e tem a função de controlar os acessos. São soluções que administram tudo o que deve entrar e sair da rede corporativa. Tecnicamente, a definição de firewall é algo simples. “Firewall é todo esforço físico e lógico utilizado para prover segurança de uma rede de computadores”, (FILHO, 2013). Os Firewalls podem ser dividos em duas grandes classes: Filtros de pacotes e servidores proxys, (LAUREANO, 2005): o Filtros de Pacotes: A filtragem de pacotes é um dos principais mecanismos que, mediante regras definidas pelo administrador do firewall, permite ou não a passagem de datagramas IP’s em uma rede. Por exemplo, filtrar pacotes SSH impedindo que o trafego SSH seja realizado na rede. o Servidores Proxy: Permite executar a conexão ou não a serviços de uma rede indiretamente. Normalmente os proxies são 49
utilizados também como caches de conexão com serviços web, dessa forma acelerando a resposta a certos serviços e páginas da web.
Sistema Detector de Intrusão (IDS): É uma ferramenta que tem como função monitorar o tráfego contínuo da rede e identificar ataques em tempo real. É um complemento do firewall. O IDS se baseia em dados dinâmicos para realizar sua varredura como por exemplo, pacotes de dados com comportamentos suspeitos e códigos de ataque, (FILHO, 2013).
Varredura de vulnerabilidade: Os portscan são produtos que permitem realizar verificações regulares em determinados componentes de sua rede, tais como servidores e roteadores. O objetivo dessas ferramentas é encontrar brechas de sistemas ou de configurações. Seu funcionamento consiste em realizar uma varredura no alvo buscando portas abertas, essa técnica é utilizada tanto por atacantes que buscam descobrir brechas para invasão quanto por profissionais de SI que procuram verificar quais portas realmente necessitam estar abertas para funcionamento de determinado serviço. Um exemplo de scanner de rede é o conhecido Wireshark17. Algumas portas lógicas que podem ser descobertas por uma ferramenta de varredura: o SSH: Porta 22; o HTTP: Porta 80; o Telnet: Porta 23.
Rede virtual privada (VPN):
VPNs são redes virtuais sobrepostas às redes
públicas, mas com a maioria das propriedades das redes privadas, (TANENBAUM, 2003). São chamadas de virtuais por criarem, na internet, uma conexão entre pontos como se fosse uma rede local. O conceito de VPN surgiu da necessidade de se utilizar redes de comunicação não confiáveis para trafegar informações de forma segura. As redes públicas são consideradas não confiáveis, tendo em vista que os
17
https://www.wireshark.org/
50
dados que nelas trafegam estão sujeitos a interceptação e captura. As VPNs provêm confidencialidade, devido a utilização de chaves públicas de criptografia, integridade e autenticidade, já que, para se ter acesso ao conteúdo trafegado ambos os lados precisam ser autorizados a trafegar pela rede. Uma das principais vantagens das VPNs é a redução de custos com comunicações corporativas, pois elimina a necessidade de links dedicados de longa distância que podem ser substituídos pela Internet, (LAUREANO, 2005).
Criptografia: A criptografia fornece base para implementação de serviços de segurança como a confidencialidade, integridade, autenticidade e não repúdio. Trata-se de um processo de codificar os dados de um arquivo, mensagem ou dado qualquer, de forma a torná-lo ilegível; para reverter esse processo precisa-se de uma chave que possui a codificação para tornar o dado legível novamente. As chaves criptográficas podem ser simétricas (privadas) ou assimétricas (públicas). Na criptografia simétrica, a chave utilizada para criptografar é a mesma utilizada para descriptografar. Já as chaves assimétricas, a chave utilizada para criptografar não pode ser a usada para reverter o processo; isso é somente possível com outra chave, (CARUSO e STEFFEN, 2006).
Autenticação: Processo de identificação de pessoas habilitadas para acessos. A autenticação, e consequente autorização da manipulação dos dados, pode se basear em algo que o indivíduo sabe (senha por exemplo), que tem (dispositivos tais como tokens de segurança, cartões inteligentes, certificados digitais) ou com alguma característica física que o define (leitura de íris, linhas das mãos)
Observando os mecanismos de segurança de uma rede de dados notamos como a SI é intimamente ligada à gerência de redes, entretanto nas bibliografias de autores consultados como (FERREIRA, 2003), (STALLINGS, 2012) e (CARUSO e STEFFEN, 2006) não citam ferramentas de gerência e monitoramento de redes com a finalidade de apoiar os mecanismos de segurança da informação. A ferramenta de monitoramento Zabbix atua como um complemento para as ferramentas de SI, monitorando e gerenciando todos os ativos da rede, verificando portas abertas, serviços rodando e sua disponibilidade. Com a análise de hash é possível verificar a integridade de arquivos de senhas, pode atuar em conjunto ao firewall e
51
ao proxy monitorando páginas acessadas ou mesmo o uso de proxies externos. O Zabbix implantado e trabalhando em conjunto com as outras soluções que a Câmara já possui, que será muito mais rápido e fácil localizar um erro ou falha quando o mesmo ocorrer e tomar medidas preventivas.
3
O ZABBIX O Zabbix é uma solução de código livre de monitoramento para empresas. É um
software que monitora diversos parâmetros de diversos ativos em uma rede de computadores. Zabbix foi criado por Alexei Vladishev em 1998. A ideia surgiu quando trabalhava em um banco na Letônia como administrador de sistemas, pois não estava satisfeito com os sistemas de monitoramento que estava trabalhando na época, (ZABBIX SIA, 2015). Em 2001 foi lançada a primeira licença do Zabbix sob a GPL com a versão 0.1 alpha. Em 2004 foi lançada a versão estável, a 1.0. Já em 2005, devido a uma necessidade de tratar o Zabbix de uma forma mais profissional, foi instituída a empresa ZABBIX SIA. A partir de 2006, o Zabbix evoluiu para o padrão alcançado hoje, atingindo a marca de 800.000 downloads em 2012, (LIMA, 2014).
52
Figura 17: Evolução do Zabbix Fonte: (ZABBIX SIA, 2015)
Entre algumas de suas funcionalidades, destacam-se:
Monitoração por agentes
Auto busca
Escalonamentos e repetição de notificações
Monitoramento proativo
Ações remotas
Monitoramento via web
Gráficos, mapas, telas
SLA, Reports
Monitoração distribuída, IPV6, etc.
A sua principal vantagem é sua flexibilidade, pois é possível monitorar praticamente qualquer dado com o Zabbix. Por meio de scripts é possível criar uma infinidade de tipos de monitoramento e de coleta de dados que podem ser utilizados para diversos fins. É possível ainda, obter diferentes tipos de dados sobre a rede com a ferramenta. Podem ser monitorados simultaneamente vários servidores, ativos de rede e máquinas virtuais, por exemplo. Além de armazenar os dados obtidos, o Zabbix oferece muitas formas 53
de visualização dessas informações, através mapas, telas, gráficos e outros. O sistema possui uma grande flexibilidade na questão de análise de dados, criação de alertas e monitoramento. Em ambientes de grande porte, o Zabbix pode ser escalonado através de seus Proxies. Pode-se dizer que o Zabbix atua em vários pontos para aumentar a segurança de uma rede. Ele pode realizar varredura de portas, análise de dados e logs, alteração e comportamento estranho de servidores e sistemas, tentativas de ataques e muitas outras opções. 3.1 Arquitetura do Zabbix Sua arquitetura se organiza no modelo de três-camadas18. Essas camadas são a Aplicação, seu banco de dados e a interface web.
A camada de aplicação é representada pelo back-end, responsável pela coleta de dados;
A camada de banco de dados é responsável por armazenar as informações coletadas no back-end;
A camada de front-end é responsável por dar acesso a informações e consolidálas para o administrador do sistema.
Servidor Zabbix (back-end), assim como o agente foi escrito em C, e seu front-end web escrito em PHP. Esses componentes tanto podem residir em uma mesma máquina ou em servidores distintos. Ao executar cada componente em uma máquina separada, tanto o servidor Zabbix e o front-end precisam ter acesso ao banco de dados. A solução Zabbix é composta por vários componentes de software:
Servidor: Servidor Zabbix é o componente central da solução e, em ambientes centralizados, os agentes enviam os dados coletados (sobre integridade,
18
As três partes de um ambiente modelo três camadas são: camada de apresentação, camada de negócio e camada de dados. Deve funcionar de maneira que o software executado em cada camada possa ser substituído sem prejuízo para o sistema. De modo que atualizações e correções de defeitos podem ser feitas sem prejudicar as demais camadas. Por exemplo: alterações de interface podem ser realizadas sem o comprometimento das informações contidas no banco de dados
54
disponibilidade e estatísticos) para ele. Em ambientes descentralizados o envio dos dados é feito para um componente intermediário, o proxy.
Banco de Dados: Todas as informações de configuração e os dados recebidos pelo Zabbix são armazenados em um sistema gerenciador de banco de dados (SGBD).
Interface Web: Para acesso rápido, e a partir de qualquer dispositivo, a solução vem com uma interface web. Normalmente esta interface é parte da mesma máquina do Servidor Zabbix, apesar de ser possível sua instalação em outro servidor.
Proxy: O Proxy Zabbix pode coletar dados de desempenho e disponibilidade em nome do Servidor Zabbix. Este é um componente opcional na implantação do Zabbix, no entanto, pode ser muito benéfico para seu ambiente distribuir a carga de coletas entre o Servidor Zabbix e um ou mais proxies.
Agente: O Agente Zabbix é instalado nos servidores alvo da monitoração e pode monitorar ativamente os recursos e aplicações locais, enviando os dados obtidos para o Servidor ou Proxy Zabbix.
Figura 18: Arquitetura do Zabbix Fonte: (OLUPS, 2010)
55
O Zabbix suporta várias plataformas, conforme pode ser observado na tabela 1, entretanto sua utilização em servidores Windows ainda não é suportada.
Platform
Zabbix server
Zabbix proxy
AIX
Suportado
Suportado
Suportado
FreeBSD
Suportado
Suportado
Suportado
HP-UX
Suportado
Suportado
Suportado
Linux
Suportado
Suportado
Suportado
Mac OS X
Suportado
Suportado
Suportado
Open BSD
Suportado
Suportado
Suportado
SCO Open Server
Suportado
Suportado
Suportado
Solaris
Suportado
Suportado
Suportado
Tru64/OSF
Suportado
Suportado
Suportado
-
-
Suportado
Windows 2000, Windows Server 2003, Windows XP, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2012, Windows 8
Zabbix agent
O zabbix agent não é necessário para monitorar serviços como FTP, SSH, HTTP, DNS, LDAP, etc. Tabela 1: Plataformas Suportadas - Zabbix Fonte: (ZABBIX SIA, 2015)
3.1.1 Requisitos Mínimos Recomendados Os requisitos básicos são referenciais visto que cada ambiente deve ser tratado de maneira única, o que precisa ser levado em consideração é:
Capacidade do hardware escolhido;
Tecnologia do banco de dados empregado;
Qual será a carga de dados do servidor Zabbix;
Tamanho do parque a ser monitorado.
Para ter como referência dos requisitos de hardware, a Zabbix SAI (2014), disponibiliza a seguinte tabela: Tipo de Rede Pequeno Médio
Plataforma Ubuntu Linux 32bits Ubuntu Linux 64bits
CPU Intel PentiumII 350 Mhz AMD Athlon64 3200+
Memória 256MB 2GB
Banco de Dados MySQL MyISAM MySQL InnoDB
Hosts Monitorados 20 500
56
Grande
Ubuntu Linux 64bits
Intel Dual Core 6400
4GB
Enorme
RedHat Enterprise
2x Intel Xeon 2 GHz
8GB
Mysql InnoDB, Oracle ou PostgreSQL Mysql InnoDB, Oracle ou PostgreSQL
>1000
>10000
Tabela 2: Requisitos Mínimos de Hardware para o Zabbix Fonte: (ZABBIX SIA, 2015)
Em comparação com seus concorrentes o Zabbix demonstra claramente um baixo consumo de recursos de hardware:
Tabela 3: Requisitos Mínimos de Hardware para o Nagios Fonte: (NAGIOS ENTERPRISES, 2015)
Tabela 4: Requisitos Mínimos de Hardware para o ZenOSS Fonte: (ZENOSS, INC, 2015)
3.2 Tipos de Monitoramento 3.2.1 Agente Zabbix
Junto ao Zabbix, foi criado um agente, escrito em C, com suporte em várias plataformas, que é capaz de coletar vários dados do sistema em que está monitorando,
57
como memória, processador, interface de rede e discos. Há dois tipos de checagens com o Zabbix Agent: passiva e ativa. Em uma verificação passiva o Servidor Zabbix (ou proxy) pede dados, por exemplo, a carga da CPU, e o agente Zabbix envia de volta o resultado. Checagens ativas requerem um processo mais complexo. O agente deve primeiro obter uma lista de itens de servidor Zabbix para processamento independente. Em seguida, ele irá enviar periodicamente novos valores para o servidor (ZABBIX SIA, 2015). 3.2.2 Agente SNMP O Zabbix pode coletar informações de dispositivos que suportem o protocolo SNMP. É um tipo de monitoramento de suma importância para os administradores de rede, uma vez que a grande maioria de ativos de rede possuem suporte ao protocolo, como por exemplo roteadores, impressoras e comutadores, (LIMA, 2014). Há dois tipos de monitoramento SNMP que o Zabbix suporta: o SNMP e o SNMP Trap. No SNMP o dispositivo monitorado trabalha como um servidor SNMP e o Zabbix como um cliente SNMP. Isso porque o Zabbix envia uma consulta ao Servidor SNMP (uma impressora por exemplo) que retorna o resultado. Essa comunicação acontece na porta 161/UDP, (LIMA, 2014). No SNMP Trap, ocorre o inverso do monitoramento SNMP convencional, o dispositivo age como cliente e o Zabbix como servidor SNMP. O cliente ficará encarregado de enviar os dados monitorados enquanto o Zabbix fica no aguardo. Essa comunicação acontece na porta 162/UDP, (LIMA, 2014). 3.2.3 Monitoramento IPMI Enquanto SNMP é muito popular e está disponível na maioria dos ativos de rede, há um protocolo relativamente novo que também fornece monitoramento de dados o IPMI (Intelligent Platform Management Interface) .
58
O IPMI é um padrão utilizado para gerenciar um sistema de computador e monitorar seu funcionamento. Seu surgimento foi liderado pela INTEL19 e hoje é suportado por mais de 200 fabricantes de hardware, (LIMA, 2014). Seu funcionamento não depende de um sistema operacional, o que permite que os administradores gerenciem remotamente os recursos de hardware antes mesmo de ter o sistema operacional iniciado. O IPMI pode monitorar temperatura do sistema, ventoinhas, fontes de alimentação e vários outros componentes de hardware. O IPMI trabalha por meio de uma conexão TCP/IP. O Monitoramento Zabbix IPMI funciona somente para os aparelhos com suporte IPMI (HP OIT, a DELL DRAC, IBM RSA, Sun SSP, etc), (ZABBIX SIA, 2015). A DELL, por exemplo gerencia seus aparelhos com o protocolo IPMI através do DELL REMOTE ACCESS CONTROL (DRAC).
3.2.4 Monitoramento Simples Há situações nas quais não é possível monitorar o ativo nem com o Zabbix Agent, nem com o protocolo SNMP (catracas ou algumas câmeras IP, por exemplo), ou quando não se tem permissão para instalação do Zabbix Agent. Nesses casos, ainda há a possibilidade de monitorar com o protocolo ICMP, com o ICMP Ping e verificação de portas abertas (FTP, SSH, etc). O ICMP Ping é interessante para verificar se o host em questão está ativo, ou seja, está respondendo naquele IP, mesmo sendo um teste simples é muito útil para verificar a disponibilidade do ativo.
19
http://www.intel.com.br/
59
3.2.5 Monitoramento Web O Zabbix fornece uma maneira de monitorar sistemas web de uma forma muito flexível. O módulo web executa, de forma periódica, vários cenários pré-definidos. É uma maneira de avaliar o desempenho de vários recursos web, como o tempo de login, o tempo de processamento de requisição, o tempo de resposta da página, entre outros.
Figura 19: Monitoramento de Páginas Web do Zabbix Fonte: (ZABBIX SIA, 2015)
A figura 16 ilustra um exemplo de monitoramento de um sistema web, verificando o tempo de resposta da primeira página, login, checagem de login e por fim o logout. É muito útil quando se quer verificar o desempenho de sistemas web utilizados. 3.2.6 Monitoramento de Serviços de TI - SLA Outro recurso que o Zabbix oferece é o gerenciamento de serviços de TI. O monitoramento feito pelo sistema se traduz em uma visão de alto nível da infraestrutura da rede analisada. Essa característica da ferramenta permite que os administradores da rede tenham informações sobre a disponibilidade dos serviços prestados tanto pelo departamento de TI da instituição como por empresas externas.
60
3.2.7 Outros tipos de monitoramento A partir da versão 2.0 do Zabbix, tornou-se possível monitorar aplicações em Java usando JMX (Java Management Extensions). O Servidor Zabbix, através do Zabbix Java gateway requisita as informações pela API JMX das aplicações. O Zabbix também monitora logs nativamente, a função está nativa desde a versão 2.2. A partir de strings ou expressões regulares, é possível fazer filtros nos arquivos de logs de um servidor pelo agente Zabbix. Se uma ocorrência for encontrada nos logs, o Zabbix pode disparar um gatilho e notificar o administrador para este tomar uma ação. 3.2.8 Comparativo das ferramentas Em uma comparação feita por (BLACK, 2008) é possível ver as principais diferenças entre o Zabbix e as diversas ferramentas de monitoramento encontradas no mercado
Tabela 5: Comparação de Ferramentas de Monitoramento Fonte: (BLACK, 2008)
61
Na tabela 5, ainda é possível notar como o Zabbix é completo mesmo em sua instalação padrão, sem necessidade de plug-ins. Uma questão impactante é seu front-end web, o Nagios não possui um front-end nativo, sendo que suas principais funcionalidades são baseadas em linha de comando enquanto o ZenOSS, mesmo possuindo uma interface, a mesma é lenta e baseada em Zope, um framework construído em python, pouco dominada pela equipe de TI da Câmara. O Zabbix por sua vez, possui sem front-end desenvolvido em php, uma linguagem de fácil aprendizagem, manutenção e amplamente utilizada pela DTIC. O licenciamento também impacta bastante na comparação entre Zabbix e ZenOSS, o Zabbix possui uma versão entreprise, porém essa garante apenas um suporte maior, já que todas suas funcionalidades são disponíveis na versão community. O ZenOSS entretanto, possui limitações de suas funcionalidades na versão community. 3.3 O Ambiente de Testes A (ZABBIX SIA, 2015) disponibiliza uma forma rápida para quem quer testar o Zabbix através de Appliances, que são sistemas já compilados com o sistema instalado, disponíveis no site para downloads, para isso basta que se tenha alguma ferramenta de virtualização. Há Appliances para diversas plataformas, MS Hyper-V, Citrix XenServer, VMWare e Virtualbox, por exemplo.
62
Figura 20: Zabbix Appliance Fonte: (ZABBIX SIA, 2015)
Para a construção do ambiente de testes, foi escolhida uma Appliance para Hyper-V, vários testes foram realizados nessa etapa, principalmente no que se refere aos recursos de monitoramento, interface do sistema, e opções de exibição dos dados obtidos. Há de se levar em consideração que a imagem da Appliance deve ser utilizada apenas com finalidade de testar a ferramenta e jamais utilizar com o sistema em produção, uma vez que a imagem não é otimizada para ambiente de produção, e não é customizada para o cenário real da empresa.
63
Figura 21: Download de Appliances do Zabbix Fonte: (ZABBIX SIA, 2015)
Como pode-se observar na figura 18, há várias formas de testar o zabbix através de imagens já prontas e preparadas para vários tipos de soluções de virtualização como VMWare, Hyper-V ou Citrix XenServer.
4
O CENÁRIO DA APLICAÇÃO
4.1 A Câmara Municipal de Campinas O Poder Legislativo é exercido pela Câmara Municipal20, composta de 33 vereadores, eleitos através do sistema proporcional, dentre cidadãos maiores de 16 anos, no exercício dos direitos políticos, pelo voto direto e secreto.
20
http://www.campinas.sp.leg.br/
64
A Câmara Municipal tem comissões permanentes e temporárias e reuniões plenárias ordinárias para discussão e votação de projetos todas as segundas e quartas-feiras com início às 18h00. 4.1.1 Números A Câmara possui atualmente 650 funcionários, sendo 200 Efetivos e 450 comissionados. Circulam diariamente, aproximadamente, 500 pessoas pela Câmara. O parque computacional possui cerca de 600 computadores utilizados pelos seus funcionários, 400 ramais distribuídos entre telefones digitais e analógicos e 40 servidores de aplicação que hospedam diversos sistemas da instituição. Desses 40 servidores, 6 são físicos, sendo 2 deles servidores de Virtualização Xen, 1 Servidor de backup Bacula, 1 servidor de E-mails Zimbra, 1 Firewall PFsense e 1 Proxy Squid e IDS A Diretoria de Tecnologia da Informação e Telecomunicações (DTIC), hoje conta com 3 Analistas em Tecnologia da Informação e 1 Técnico Legislativo. Cada um dos analistas cuida de uma coordenadoria, sendo elas:
Coordenadoria de Atendimento ao Usuário;
Coordenadoria de Infraestrutura de Redes e Telefonia;
Coordenadoria de Sistemas.
Entretanto, antes do início desse trabalho o quadro de funcionários da DTIC contava apenas com 1 funcionário. Os outros vieram a partir do último concurso público realizado no ano de 2014.
4.1.2 Infraestrutura da Rede A infraestrutura física da instituição é relativamente nova, a estrutura cabeada é inteiramente Cabo padrão CAT621. O datacenter fica localizado na DTIC. Nele há um comutador principal que liga todas as pilhas de comutadores da instituição. Ainda no datacenter, estão localizados os três links privativos de Internet da Câmara, todos conectados
21
http://www.furukawa.com.br/br/produtos/cabo-eletronico/cabo-eletronico-gigalan-cat6-513.html
65
em um servidor Firewall PFSENSE22, trabalhando com balanceamento de carga e Failover23 dos links de Internet. 4.1.3 Cenário anterior à instalação do Zabbix A Câmara municipal não possuía nenhum tipo de ferramenta de monitoramento ou análise de vulnerabilidades no início desse projeto. Todo e qualquer problema era tratado de forma empírica, exemplificado pelo fluxograma:
Falha informada por outro setor ou terceiros
Já havia acontecido anteriormente
SIM
NÃO
Pesquisa sobre onde a falha pode estar
Localização da falha
Tentativa de Correção NÃO
Correção Funcionou
SIM
Figura 22: Fluxograma de resolução de falhas anterior ao Zabbix Fonte: Elaborado pelo próprio Autor
22
https://www.pfsense.org/
23
Failover é um modo de operação de backup em que as funções de um componente do sistema (como um processador, servidor, rede, Internet, ou banco de dados, por exemplo) são assumidos pelos componentes do sistema secundário quando o componente primário se tornar indisponível por qualquer falha ou programado o tempo de inatividade.
66
Como pode-se notar, não havia uma metodologia fixa adotada para correções e, grande parte dos problemas eram relatados por terceiros, quando o erro já estava em estágio avançado. Um ponto mais agravante era a falta de documentação dos erros e falhas encontradas na rede. E como constatado no questionário em anexo respondido pelo único funcionário existente na DTIC, o Diretor do departamento, Sr. Sergio Damiati, antes do início desse trabalho, toda ocorrência não possuía documentação e partia do princípio de “resolver depois que aparecer”, ou seja, como único funcionário, não sobrava tempo para implantação de soluções ou mesmo realizar a documentação das ocorrências, trabalhando apenas de forma reativa. Esse cenário se perpetuou desde 2002 até 2014, quando foi criado um novo concurso público para preenchimento de diversas vagas dentro da casa, pois não só na DTIC, mas toda organização carecia de funcionários. Entretanto, mesmo com o novo concurso foram criadas apenas três vagas para a DTIC, número inferior a demanda existente.
4.2 A Análise e Monitoramento Iniciado o planejamento, criamos um fluxograma a ser seguido para a instalação e consolidação do Zabbix, as etapas foram:
Escolha da ferramenta de monitoramento, neste caso o Zabbix, pelo motivo de já possuir conhecimento prévio na ferramenta e também, comparado com seus concorrentes (Nagios, CACTI e ZenOSS), o considerarmos mais completo e flexível;
Definição do Hardware em que seria implantado o Zabbix, baseando-se no tamanho do parque a ser monitorado. A escolha foi uma máquina virtual para a aplicação e outra para o banco de dados;
Implantação dos agentes dos ativos monitorados e criação de mapas, telas e templates personalizados para o ambiente;
Monitoramento e colheita de dados pelo Zabbix;
A figura 20 demonstra como o processo foi realizado:
67
Escolha da implantação do Zabbix
Definição do Hardware e Software Necessário
Desenvolvimento da Maquina Virtual e implantação do Zabbix
Instalação dos Agentes nos ativos a serem monitorados
Criação de telas e mapas personalizados
Análise dos dados monitorados e capturados
Validação da Ferramenta
Figura 23: Fluxograma de desenvolvimento do Zabbix na CMC Fonte: Elaborado pelo próprio autor
Em seguida, foi levantado quais itens o Zabbix iria monitorar, desde servidores, comutadores e outros ativos de rede, a lista levou em consideração quais servidores possuíam serviços que não poderiam ser interrompidos e críticos à instituição, como por exemplo os comutadores que interligam toda a rede da Câmara Municipal de Campinas, chegando na seguinte tabela de itens a monitorar:
68
ITEM 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
ATIVO VALINOR VALHALLA BIFROST HEIMDALL DHCP NS1 NS2 TVCAMARA RADIOCAMARA SAGL PORTAL AUDIT LIMESURVEY ZIMBRA PDC WBDC GPSERVER REDMINE GITLAB BACULA GLPI
22 23 24 25 26 27 28 29 30 31 32
GNUTECA OPENFIRE MYSQL-SRV POSTGRES-SRV MSSQL-SRV WEBSERVER COMUTADOR-01 COMUTADOR-02 COMUTADOR-03 COMUTADOR-04 COMUTADOR-07
DESCRIÇÃO Servidor de Virtualização XEN Servidor de Virtualização XEN IDS, Filtro de Pacotes, Router PFsense IPS, Squid, HTB TC Servidor de DHCP interno Servidor primário de DNS Externo Servidor secundário de DNS Externo Servidor de Streaming de vídeo Servidor de Streaming de áudio Sistema interno de Processo Legislativo Site e Intranet Servidor de logs centralizados Syslog-NG Sistema de pesquisa Servidor de E-mails Colaborativo Zimbra Active Directory e DNS Interno Active Directory e DNS Interno Servidor IIS interno Sistema de Gerenciamento de Projetos Sistema de repositórios GITHUB Servidor de Backups Sistema de Chamados Sistema de controle de Acervo bibliotecário Servidor Jabber Servidor de Banco de dados MySQL Servidor de Banco de dados PostgreSQL Servidor de Banco de dados MS-SQL Servidor de Web Apache Comutador Central Pilha de Comutadores Pilha de Comutadores Pilha de Comutadores Comutador DMZ
S.O CentOS 6.0 CentOS 6.0 FreeBSD 10.1 Ubuntu Server 14.04 Ubuntu Server 14.04 Ubuntu Server 14.04 Ubuntu Server 14.04 Ubuntu Server 12.04 Ubuntu Server 12.04 Ubuntu Server 14.04 Ubuntu Server 14.04 Ubuntu Server 15.04 Ubuntu Server 14.04 CentOS 7.0 Windows Server 2008 R2 Windows Server 2008 R2 Windows Server 2008 R2 Ubuntu Server 14.04 Ubuntu Server 14.04 Debian 7 Ubuntu Server 14.04 Ubuntu Server 14.04 Ubuntu Server 14.04 Ubuntu Server 14.04 Ubuntu Server 14.04 Windows Server 2008 R2 Ubuntu Server 14.04
Tabela 6: Tabela de ativos a serem monitorados pelo Zabbix Fonte: Elaborado pelo próprio autor
Decidimos não monitorar as impressoras da instituição por serem um serviço terceirizado, não sendo responsabilidade da DTIC prestar suporte. A escolha dos itens que constam na tabela 3 foi motivada por:
69
A instituição depende da Internet para muitas tarefas. Envio e recebimento de emails, disponibilidade de sistemas para o público, a Lei nº 12.527/2011, conhecida como LAI - Lei de Acesso à Informação24, regulamenta o direito, previsto na Constituição, de qualquer pessoa solicitar e receber dos órgãos e entidades públicos, de todos os entes e Poderes, informações públicas por eles produzidas ou custodiadas. Dessa forma é imprescindível que a conexão com a internet esteja sempre disponível;
A Câmara possui um sistema de e-mail colaborativo interno, o Zimbra25, que por sua vez é vinculado com o Servidor de autenticação interno, nele estão armazenadas todas as agendas eletrônicas dos funcionários, lista de contatos e tarefas. É interessante monitorar a disponibilidade e também listas de spams, evitando assim problemas como falhas de envios e vírus;
O Servidor de backups BACULA, por ser responsável pelo gerenciamento das rotinas de backup de todos os servidores, tanto físicos quanto virtuais da Câmara, deve ser monitorado em vários aspectos: Utilização dos discos, processamento, estado e integridade dos backups.
Tanto o servidor principal de autenticação (PDC) quanto o secundário (WBDC), devem também permanecer sempre disponíveis, pois praticamente todos os serviços de autenticação dos sistemas da Câmara se autenticam por ele. É interessante também monitorar os logs dos eventos do Active Directory, assim como a disponibilidade dos serviços neles rodando;
Os dois servidores físicos que comportam o cluster
26
de Servidores de
virtualização Xen, hosts das máquinas virtuais, são sem dúvida os ativos de maior importância para a Diretoria de TI da Câmara pois, caso um deles fique indisponível, as VMs (Máquinas Virtuais) também ficarão. Deve-se monitorar
24
http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2011/lei/l12527.htm
25
https://www.zimbra.com/
26
Cluster de alta disponibilidade: são clusters cujo objetivo é a redundância, todos os servidores trabalham como uma única entidade e, mesmo que haja alguma falha em alguns deles o sistema consegue permanecer ativo por um longo período de tempo e em plena condição de uso.
70
constantemente a disponibilidade desses dois servidores, assim como se seus serviços estão rodando e não apresentam falhas além de se não houve nenhum tipo de acesso sem permissão à eles;
Os comutadores da Câmara são todos gerenciáveis através do protocolo SNMP, sendo assim, podem ser monitorados pelo Zabbix, monitorando disponibilidade das portas dos comutadores, banda trafegada por cada porta, temperatura e carga do processador.
Uma questão importante é a quantidade de ataques de negação de serviço, DoS, que a Câmara recebe, o Zabbix precisa monitorar esses ataques, para saber quais serviços estão sofrendo com a Negação de Serviço. Levando esses pontos em consideração, o zabbix deve monitorar todos esses servidores. O esquema da estrutura está ilustrado na figura 21:
Nuvem DNS-01
DNS-02
TV Camara
Radio Camara
WEBSERVER
201.28.114.42
PFSENSE 172.13.0.1
DMZ
Squid3
ZIMBRA
172.13.0.2
NAS 01
Valinor
Valhalla
Core
PostgreSQL
Anexo
Rack 03
Rack 02
PCs
PCs
GLPI
PDC
WBDC
Rack 01 Intranet
PCs
SQLServer
PCs
LIMESUEVERY
MySQL
Zabbix
Contabil
Holerite
WIKI
GITLAB
GNUTECA
SAPL
Figura 24: Estrutura da Rede da Câmara de Campinas Fonte: Elaborado pelo autor
71
4.2.1 A implantação do Zabbix Como responsável pela coordenadoria de redes e infraestrutura da Câmara Municipal de Campinas, coube a mim a implantação da ferramenta Zabbix e, visto a quantidade pequena de profissionais da Diretoria de TI, não houve participação direta de outras pessoas. A Câmara tende a virtualizar, sempre que possível todos seus servidores, então optouse por realizar a implantação do Zabbix em uma Máquina Virtual; após um estudo interno, avaliando o tamanho do parque da Câmara e seguindo a orientação de (HORST, PIRES e DÉO, 2015), (LIMA, 2014) e (ZABBIX SIA, 2015) chegou se a conclusão que a configuração do Zabbix para suprir a demanda de monitoramento seria: 1 VM com a aplicação e o front-end, ou seja o Servidor Zabbix com: Disco Rígido 20 GB
Memória
Processador
Sistema Operacional
2 GB
2x 2.0 GHz
Ubuntu Server 14.04 LTS
Tabela 7: Configuração do Servidor Zabbix Fonte: Elaborado pelo autor
Para o banco de dados, foi escolhido o PostgreSQL, pois já havia um servidor de banco de dados, também em uma VM com a seguinte configuração: Disco Rígido 600 GB
Memória
Processador
Sistema Operacional
6 GB
6x 2.0 GHz
Ubuntu Server 14.04 LTS
Tabela 8: Configuração do Banco de Dados PostgreSQL Fonte: Elaborado pelo autor
A escolha do Sistema Operacional Ubuntu Server, deve-se ao fato de ele possuir um repositório para a instalação e atualização do Zabbix, além de possuir uma vasta documentação e ser o principal sistema utilizado nos servidores da Câmara. Após a instalação do Zabbix, surgiu uma questão importante, sua integração com o sistema de autenticação interno LDAP, o Active Directory, já existente na Câmara. Esse
72
modelo de autenticação evita ter que criar usuários e senhas para cada funcionário que venha a utilizar o Zabbix
Figura 25: Modelos de autenticação do Zabbix Fonte: Elaborado pelo próprio autor
Após a integração, foi definido quais funcionários que poderiam operar o Zabbix e, como já tinham usuários no servidor de autenticação (Active Directory), bastou sincronizar o login do Zabbix para que esses funcionários pudessem iniciar a utilização, como demonstrado na figura 22. 4.2.2 Pontos Analisados Diversos tipos de informações foram monitorados durante todo o estudo. Dados reais, alguns ocorridos de forma proposital e outros ao acaso. Por exemplo, dados de servidores web, firewall, proxy, serviços como dhcp, Active Directory, situação de servidores backup. Os dados foram demonstrados em telas personalizadas que são um recurso muito prático do Zabbix. É possível acrescentar diversos tipos de dados diferentes em uma única tela.
73
Figura 26: Monitoramento Zabbix - Log auth.log Fonte: Elaborado pelo próprio autor
O ZABBIX pode ser usado para o monitoramento de arquivos de logs. Como por exemplo, quando algum valor for impresso em um determinado arquivo de log, ele poderá disparar um alerta para o Administrador. Na figura 23, pode-se notar o Zabbix monitorando o arquivo auth.log, nele é possível verificar a quantidade de tentativas de ataques por força bruta que ocorrem, por exemplo. Neste caso, o servidor monitorado é o servidor de e-mails Zimbra. Nesta figura só há ações do próprio daemon do Zimbra agindo.
Figura 27: Monitoramento Zabbix - Espaço em disco Fonte: Elaborado pelo próprio autor
74
Os gráficos são dinâmicos, atualizados em tempo real, e permitem selecionar um período de tempo específico, como um mês ou apenas alguns dias. Com o Zabbix, conseguimos ver o crescimento do espaço utilizado em disco pelo BACULA, nosso servidor de backups, como mostrado na figura 24. Dessa forma foi fácil dimensionar como seriam realizados os backups, quais servidores mais utilizam espaço em disco e quando seriam feitos backups incrementais, diferenciais e full.
Figura 28: Monitoramento Zabbix - Active Directory Fonte: Elaborado pelo próprio autor
Já a figura 25, mostra os logs capturados de um dos servidores do Active Directory, é possível monitorar a saúde do sistema, verificando o estado de seus serviços, a situação do domínio de autenticação e sincronização. Pode-se observar como podemos trabalhar com o nível de severidade, recurso nativo do Zabbix. De maneira geral, ter todas essas informações centralizadas facilita o dia a dia da equipe de TI, pois não havia nada parecido antes da implantação do Zabbix.
75
Figura 29: Monitoramento Zabbix - Tráfego de internet Fonte: Elaborado pelo próprio autor
A figura 26 exibe uma das principais telas de monitoramento que foram criadas, nela há uma constante checagem de todos os links de internet, verificando suas disponibilidades, anomalias e largura de banda utilizada. Neste dia, por exemplo, houve interrupção do link principal da Câmara, demonstrado no lado superior esquerdo, pode-se notar também que outros dois links secundários foram automaticamente ativados devido a redundância. É possível ainda, monitorar proxies com o Zabbix, verificando o tamanho do cache de páginas, memória utilizada ou até mesmo quantidade de páginas bloqueadas.
Figura 30: Monitoramento Zabbix - DHCP Fonte: Elaborado pelo próprio autor
76
Na figura 27, consta outra tela importante: O DHCP, a abrangência de cada Vlan, bem como a utilização de cada uma. Esse monitoramento é importante pois a partir dele conseguese dimensionar o crescimento e o uso do serviço de DHCP, e qual Vlan utiliza mais faixas de IP’s para navegar. Nesta imagem nota-se o baixo uso de IP’s devido ao horário.
Figura 31:Monitoramento Zabbix - Mapa da Rede Fonte: Elaborado pelo próprio autor
Com o Zabbix já implantado foi possível observar falhas na rede, como demonstrado na figura 28, o alto nível de processamento do comutador 3, apresentando um risco de causar uma indisponibilidade em parte da rede. É possível adicionar em um mapa qualquer tipo de host, e em cada um, colocar uma legenda estática ou dinâmica (com dados em tempo real). Podemos ainda conectar diferentes hosts através de linhas, também colocando informações entre os dois. Ainda é possível programar a mudança da cor da linha, por exemplo, caso a conectividade entre dois roteadores seja interrompida, a linha entre os dois ficará vermelha.
77
Após a implantação do Zabbix, o fluxo de atividades para resolução de problemas tornou-se mais elaborado, como demonstra o fluxograma na figura 29:
Problema detectado pelo Zabbix
SIM
NÃO
Problema detectado manualmente Alerta Via Email e via Mensagens
Alertas na Tela e Avisos Sonoros
Análise da causa da falha Avaliação da Falha e busca na base de conhecimentos
Interna
Determinação da Responsabilidade
Externa
Não Adicionado o alerta ao Zabbix
Abertura de chamado interno e correção do problema
Acionamento dos responsáveis e abertura de chamado
Problema corrigido
Sim
Adicionado à base de conhecimentos
Figura 32: Fluxograma de resolução de falhas após a instalação do Zabbix Fonte: Elaborado pelo próprio Autor
78
Após um tempo, o banco de dados do Zabbix já possuía vasta quantidade de informações para geração de diversos relatórios e cruzamento de dados. Conseguimos verificar os principais problemas e falhas recorrentes e traçar metas de correção. Entretanto talvez a implementação da ferramenta fosse melhor aproveitada se tivesse sido realizada em um servidor externo, alguma solução em nuvem ou servidor fora da CMC, pois um dos principais problemas da CMC é a constante queda de energia e a baixa autonomia dos nobreaks, e sendo o Zabbix uma VM localizada dentro do datacenter da Câmara, uma queda de energia prolongada simplesmente inviabiliza qualquer monitoramento pois o mesmo também fica inacessível. O modelo ideal seria a instalação servidor estar localizada externamente e na Câmara apenas um proxy repassando os dados, dessa maneira mesmo com todos os demais serviços da CMC inativos o Zabbix continuaria enviando os sinais e alertas, como exemplificado na figura 33:
Internet Internet
Dispositivos Dispositivos SNMP SNMP
Servidor Servidor Zabbix Zabbix
Firewall Firewall
Zabbix Zabbix Proxy Proxy
Servidores Servidores Internos Internos Figura 33: Instalação com Zabbix Proxy Fonte: Elaborado pelo próprio autor
5
CONCLUSÃO O Software de gerenciamento, Zabbix, demonstrou ser essencial, principalmente no
que tange ao monitoramento de disponibilidade de ativos de rede, pois permitiu que a Diretoria de Tecnologia da Informação da Câmara de Campinas, deixasse de ser uma TI reativa para vir a ser uma TI proativa, conseguindo prever, minimizar, e localizar erros e falhas de segurança de maneira eficiente e antecipada.
79
5.1
Tempo de Resposta Evidentemente, com um sistema que informe em tempo real o estado de rede, assim
como os problemas que estão ocorrendo naquele momento, é possível diminuir significativamente o tempo de resposta aos incidentes. Mesmo que a solução da ocorrência não dependa diretamente da equipe de TI, é possível acionar com mais antecedência o responsável para reparo o quanto antes. Pelo fato de não haver dados para comparação passada, avaliar o ganho real de tempo em cada atendimento é uma tarefa difícil, entretanto é fato o ganho de produtividade e assertividade com o Zabbix.
‘ Figura 34: Monitoramento Zabbix - Dados em Tempo Real Fonte: Elaborado pelo próprio autor
A figura 30 demonstra dados sendo capturados e monitorados em tempo real pelo Zabbix, neste caso, dados sobre o estado da distribuição de IP’s pelo servidor DHCP da Câmara em suas respectivas Vlans.
5.2
Identificação dos Problemas Com o auxílio do sistema, em especial com o recurso de telas personalizadas e mapas,
a identificação da origem dos problemas de infraestrutura na rede fica muito mais evidente. Com a exibição de alertas para dispositivos específicos, e com mapas, como pode ser
80
observado na figura 31, que mostram o estado dos ativos de rede em tempo real, é possível saber exatamente a localização física e lógica do evento em questão. Conseguimos, por exemplo descobrir um gargalo no comutador-03 causado pela quantidade de novas máquinas e portas que foram a ele associadas, com os relatórios e gráficos que obtivemos com o Zabbix, conseguimos sustentação para pedido de compras de novos comutadores para toda a CMC.
Figura 35: Monitoramento Zabbix - Mapas e Telas Fonte: Elaborado pelo próprio autor
Também conseguimos verificar qual gabinete de vereador consumia mais banda e em qual horário, além da verificação de serviços não permitidos.
5.3
Finalizando O estudo foi realizado em ambiente de produção, ou seja, o Zabbix realmente foi
implantado pela Câmara Municipal de Campinas, e utilizando desde então. Pôde-se notar uma nítida melhora na obtenção de respostas sobre acontecimentos da rede, bem como a velocidade na solução do mesmo, uma vez que o Zabbix indicava exatamente quem, onde e qual era o problema.
81
Infelizmente não havia dados para comparar o tempo médio para descobrir um problema de rede e então solucioná-lo, entretanto, com o Zabbix, pode-se dizer que a descoberta do problema ocorre em tempo real e a solução varia conforme a dificuldade do problema ou falha. Foi mostrado a complexidade e a importância do monitoramento das redes de computadores sejam elas pequenas ou grandes. Como é importante ter a informação certa no momento certo e que é de primordial importância a captação de informações sobre o status dos dispositivos ativos na rede, evitando ou mitigando falhas de segurança e problemas que venham a aparecer. O Zabbix auxilia na obtenção de uma infinidade de informações, entretanto o Administrador precisa saber extrair a informação que procura. Com a ferramenta é possível descobrir falhas na segurança e vulnerabilidades na estrutura de TI, bem como verificar o status de integridade de arquivos através da análise de hash, por exemplo. Há também a possibilidade de monitorar acessos realizados por determinados usuários. Obviamente, o Zabbix não é uma ferramenta que irá suprir todos os requisitos de segurança de uma rede, entretanto, em conjunto com outras ferramentas e práticas é possível aumentar a segurança e ter um controle bem mais amplo de toda a rede graças a sua flexibilidade que permite, se configurado, monitorar qualquer tipo de informação. 5.4 Próximos Estudos Uma demanda levantada durante a implementação do Zabbix na CMC foi a falta de integração com ferramentas de Help Desk tanto nativamente quanto através de plug-ins. Uma vez que cada erro ou falha descoberta pelo Zabbix corresponde a um ticket de Help Desk que precisa ser aberto, diagnosticado e resolvido. Dessa maneira é necessário utilizar uma ferramenta de terceiros, no nosso caso o GLPI. No momento do desenvolvimento desta monografia, o Zabbix 3.0 está em desenvolvimento, de acordo com a documentação já disponível, haverá várias melhorias, principalmente nas telas e na velocidade de obtenção dos dados.
82
REFERÊNCIAS BIBLIOGRÁFICAS
ANDERSON, A.; BENEDETTI, R. Use a Cabeça! Redes de Computadores. Rio de Janeiro: Alta Books, 2011. BADGER, M. Zenoss Core Network and System Monitoring. Birmingham: Packt Publishing Ltd, 2008. BENINI, R. A.; DAIBERT, M. S. Monitoramento de Redes de Computadores - Trabalhando com a ferramenta Nagios. Infra Magazine, São Paulo, n. 1, 2013. BLACK, T. L. Comparação de Ferramentas de Gerenciamento de Redes. Porto Alegre: Universidade Federal do Rio Grande do Sul, 2008. BOSWORTH, S.; JACOBSON, R. V. Computer Secury Handbook. Hoobken: John Wiley & Sons, Inc, 2014. CARUSO, C. A. A.; STEFFEN, F. D. Segurança em Informática e de Informações. 3ª. ed. São Paulo: Senac, 2006. CERT.BR. Cert.br. Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil, 2014. Disponivel em: . Acesso em: 06 mar. 2015. COMPUTERWORLD. 7 ferramentas "matadoras" de código aberto para monitoramento. COMPUTERWORLD, 2014. Disponivel em: . Acesso em: 27 mar. 2015. FERREIRA, F. N. F. Segurança da Informação. Rio de Janeiro: Editora Ciência Moderna, 2003. FILHO, J. E. M. Análise de tráfego TCP/IP: Utilize tcpdump na análise de tráfegos em qualquer sistema operacional. 1ª. ed. São Paulo: NOVATEC, 2013. FRY, C.; NYSTROM, M. Security Monitoring. Sebastopol: O’Reilly Media, Inc, 2009. HORST, A. S.; PIRES, A. D. S.; DÉO, A. L. B. De A a Zabbix. [S.l.]: NOVATEC, 2015. KOCJAN, W. Learning Nagios 4. 2ª. ed. Birmingham: Packt Publishing Ltd, 2014. LAUREANO, M. A. P. Gestão de Segurança da Informação. Curitiba: PUC PR, 2005. LIMA, J. D. R. Monitoramento de Redes com Zabbix: monitore a saúde dos servidores e equipamentos de rede. 1ª. ed. Rio de Janeiro: Brasport, v. I, 2014. MAURO, D. R.; SCHMIDT, K. J. Essential SNMP. 2ª. ed. Sebastopol: O’Reilly Media, Inc., 2005. MICROSOFT TECHNET. O modelo TCP/IP. Microsoft TechNet, 2015. Disponivel em: . Acesso em: 01 mar. 2015. MOHR, R. F. Análise de Ferramentas de Monitoração de Código Aberto. Porto Alegre: Universidade Federal do Rio Grande do Sul, 2012. NAGIOS ENTERPRISES. Nagios Enterprises. Nagios, 2015. Disponivel em: . Acesso em: 05 jul. 2015.
83
NAKAMURA, E. T. Um Modelo de segurança de redes para ambientes cooperativos. Campinas: [s.n.], 2000. NIST. NIST Handbook. Washington: [s.n.], 1995. OLIVEIRA, W. J. D. Dossiê Hacker. São Paulo: Digerati Books, 2006. OLUPS, R. Zabbix 1.8 Network Monitoring. Olton: Packt Publishing, 2010. PAESSLER, D. O monitoramento e os altos custos da inatividade de rede. COMPUTERWORLD, 2015. Disponivel em: . Acesso em: 03 abr. 2015. SETH, S.; VENKATESULU, M. A. TCP/IP ARCHITECTURE, DESIGN, AND IMPLEMENTATION IN LINUX. New Jersey: John Wiley & Sons, Inc, 2008. SOUZA, R. M. D. Implantação de ferramentas e técnicas de segurança da informação em conformidade com as normas ISO 27001 e ISO 17799. Campinas: Pontifícia Universidade Católica de Campinas, 2007. STALLINGS, W. COMPUTER SECURITY - PRINCIPLES AND PRACTICE. 2ª. ed. New Jersey: Pearson Education, Inc, 2012. TANENBAUM, A. S. Redes de computadores. 4ª. ed. Rio de Janeiro: Elsevier, 2003. TCP/IP Simple Network Management Protocol (SNMP) Protocol. TCPIPGUIDE. Disponivel em: . Acesso em: 15 fev. 2015. TORRES, G. Redes de Computadores. 2ª. ed. Rio de Janeiro: NOVATERRA, 2014. ZABBIX SIA. Zabbix Documentation 2.4. Zabbix, 2015. Disponivel em: . Acesso em: 02 jan. 2015. ZANI, B. Canaltech Corporate. Desafios da segurança da informação no setor público, 2014. Disponivel em: . Acesso em: 11 mar. 2015. ZENOSS, INC. Zenoss Own IT. Zenoss, Inc, 2015. Disponivel em: . Acesso em: 06 jul. 2015.
84
ANEXO I – INSTALAÇÃO DO ZABBIX No que diz respeito a Hardware, tanto (ZABBIX SIA, 2015) como (LIMA, 2014) apontam para uma mesma recomendação mínima: O Zabbix requer um mínimo de 128 MB de memória RAM e 256 MB de espaço livre em disco. Entretanto, como se trata de um sistema que utiliza banco de dados e alimenta suas informações nele, há a necessidade de mais memória física e armazenamento em disco para o banco. Este ponto também é valido para o processador que será utilizado, tanto para o banco quanto para a aplicação. Aliás, é recomendável que o banco esteja em um servidor separado, para evitar concorrência de hardware e, claro, para uma maior flexibilidade na implantação e gestão do sistema. O Zabbix pode ser implantado de diversas maneiras e em vários Sistemas operacionais diferentes. Como o objetivo deste trabalho não é a instalação da ferramenta e sim a utilização dela, não será abordada a instalação a partir de compilação de pacotes. Para efeito didático foi definido uma nomenclatura para os servidores:
O Servidor do Banco de Dados será db-server
O Servidor da aplicação Zabbix será Zabbix-server
CONFIGURAÇÃO DA APLICAÇÃO Primeiramente deve-se adicionar o repositório: root@db-server:~ wget http://repo.zabbix.com/zabbix/2.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_2.41+precise_all.deb
Instalar o pacote através da ferramenta dpkg em distribuições baseadas em Debian. root@db-server:~# dpkg –i zabbix-release_2.4-1+precise_all.deb
Atualizar a lista de pacotes e Instalar o pacote do Zabbix Server com suporte a base do Postgres sem os pacotes de recomendações. root@db-server:~# aptitude update && aptitude install zabbix-server-pgsql –R
Durante a instalação e configuração dos pacotes, há uma pergunta: “Configurar base de dados para zabbix-server-pgsql com dbconfig-common?”, deve-se responder “não” para ela. Após a instalação o pacote zabbix-server-pgsql irá gerar três arquivos .sql para gerar a carga inicial do banco. root@zabbix-server :~ # ls/usr/share/zabbix-server-pgsql/ data.sql images.sql schema.sql
85
Esses três arquivos devem ser copiados para a máquina DB Server no diretório home do usuário postgres root@zabbix-server:~#scp/usr/share/zabbix-server-pgsql /*.sql 192.168.100.100:/var/lib/postgresql/
CONFIGURAÇÃO DO BANCO DE DADOS O Zabbix não utiliza recursos como o RRDTools para armazenar dados, ele faz uso apenas de um SGBD ou de um banco de dados mais simplório (como o sqlite) para armazenar configurações, hosts, templates, histórico, etc. Por isso é preciso selecionar um dos bancos nativos ou usar ODBC (este último não é recomendado). Neste caso foi escolhido o PostgreSQL, um SGBD livre e de alta performance capaz de manipular uma grande quantidade de dados. Apesar da maioria das instalações de Zabbix estar em MySQL, foi decidido pelo PostgreSQL. Embora não pareça a princípio, o banco de dados do Zabbix é de extrema valia para a empresa, pois ele contém todo o histórico de funcionamento de sua infraestrutura e através dele podemos coletar SLAs. Com o banco de dados instalado o próximo passo é criar uma base de dados e um usuário com as devidas permissões de acesso ao mesmo. O nome de ambos elementos é totalmente opcional, aqui o banco de dados se chamará zabbixdb e o usuário será zabbix. A instalação do PostgreSQL também deve ser feita no servidor de aplicação, no caso, o zabbix-server. Somente o superusuário do PostgreSQL, chamado postgres tem permissão de realizar a criação dos objetos citados acima, logo, para poder acessar o terminal de console do banco (psql) deve-se entrar como usuário postgres no Gnu/Linux e então usar o comando correto. root@db-server :~ # su – postgres
Em seguida deve-se criar o banco propriamente dito: postgres=# CREATE DATABASE zabbixdb ;
Após a criação do banco o próximo passo é criar o usuário e definir sua senha. Postgres=# CREATE ROLE zabbixpostgres = # \ password zabbix
O próximo passo é editar o arquivo pg_hba.conf do PostgreSQL para permitir a comunicação da aplicação e do front-end: root@db-server:~# vim/etc/postgresql/9.3/main/pg_hba.conf
86
host zabbixdb
zabbix
192.168.100.100/32
md5
Observando que deve-se colocar o IP do servidor front-end assim como do Back-end O próximo passo é realizar a carga inicial do Banco de dados com os três arquivos gerados durante a instalação do Zabbix Server root@db-server:~# su – postgres postgres@db-server :~ $ cat schema.sql | psql zabbixdb postgres@db-server :~ $ cat images.sql | psql zabbixdb postgres@db-server :~ $ cat data.sql | psql zabbixdb
Esses arquivos devem ser importados nessa ordem, após isso, há necessidade de conceder as permissões para o usuário zabbix no banco postgreSQL zabbixdb = # GRANT SELECT , UPDATE , DELETE , INSERT ON ALL TABLES IN SCHEMA public TO zabbix ;
INSTALAÇÃO DO FRONT-END O zabbix front-end é uma interface web que roda dentro de um servidor com suporte a PHP e Apache. Dessa forma, ele precisa também ser instalado. É nele que praticamente será feito todos os monitoramentos e configurações de ativos de rede. Primeiramente deve-se instalar o pacote: root@db-server :~ # apt-get install zabbix-frontend-php php5-ldap
Após essa etapa, se não houve nenhum problema, através do navegador, basta acessar o Front-End através do IP do db-server.
87
Figura 36: Instalação Zabbix – Tela Inicial Fonte: Elaborado pelo próprio autor
Após acessar a instalação via navegador, basta ir seguindo as telas e preenchendo as configurações como solicitado, o zabbix é bem intuitivo nesse aspecto, não havendo grandes dificuldades em sua instalação.
Figura 37: Instalação Zabbix – Checagem de pré-requisitos Fonte: Elaborado pelo próprio autor
88
O zabbix irá checar se todos os pré-requisitos foram aceitos, caso algum não tenha sido, basta alterar como informado no requerido.
Figura 38: Instalação Zabbix – Primeiro Login Fonte: Elaborado pelo próprio Autor
Após a instalação do Front-end concluída, será mostrada a tela de login, onde, conforme a documentação, o Username padrão é Admin e o Password é zabbix.
Figura 39: Instalação Zabbix – Dashboard Fonte: Elaborado pelo próprio autor
Após o login, a próxima tela é o Dashboard, onde fica, de forma consolidada, toda informação do sistema e dos hosts monitorados.
89
90
ANEXO II – QUESTIONÁRIO
Quanto tempo em média, a partir do momento de descoberta do problema, este demorava para ser corrigido? Quando o erro era encontrado ou informado havia uma pesquisa previa na internet sobre ele, que variava, dessa forma a correção variava sempre mesmo quando o erro era parecido. Qual era a quantidade de incidentes identificados por mês relacionados à segurança de redes e servidores? Não há um registro de contabilidade de erros Como era feita a documentação dos incidentes? Não havia documentação Que tipo de ferramenta era utilizada para monitoramento da rede da Câmara Municipal de Campinas? Não havia ferramenta de monitoramento Qual a quantidade de funcionários efetivos a Diretoria de Tecnologia possuía? 1 Apenas, esse cenário durou até 2014, hoje a quantidade de funcionários é de 4 Existia alguma metodologia adotada para o tratamento de incidentes? Não havia Qual era o tamanho do parque de computadores da Câmara Municipal de Campinas? Até 2015 a CMC possuía cerca de 250 computadores, hoje essa quantidade saltou para 600.
91
Lihat lebih banyak...
Comentários
