SGS:Log Sistema Integrado de Análise e Acompanhamento - PDF
SGS:Log Sistema Integrado de Análise e Acompanhamento
Download "SGS:Log Sistema Integrado de Análise e Acompanhamento"
Vagner Pinhal Neves
1 UNIVERSIDADE ESTÁCIO DE SÁ Larissa Esteves Cardoso Paula da Silva Cortasio Reuther SGS:Log Sistema Integrado de Análise e Acompanhamento Petrópolis 2013
2 UNIVERSIDADE ESTÁCIO DE SÁ Larissa Esteves Cardoso Paula da Silva Cortasio Reuther SGS:Log Sistema Integrado de Análise e Acompanhamento Monograa apresentada à Universidade Estácio de Sá como requisito parcial para a obtenção do grau de Bacharel em Sistemas de Informação. ORIENTADOR: Prof. Luís Rodrigo de Oliveira Gonçalves Petrópolis 2013
3 Larissa Esteves Cardoso Paula da Silva Cortasio Reuther SGS:Log Sistema Integrado de Análise e Acompanhamento Monograa apresentada à Universidade Estácio de Sá como requisito parcial para a obtenção do grau de Bacharel em Sistemas de Informação. Aprovada em 10 de Dezembro de BANCA EXAMINADORA Prof. M.Sc. Luís Rodrigo de O. Gonçalves Universidade Estácio de Sá / Laboratório Nacional de Computação Cientíca Prof. M.Sc. Fábio Lopes Licht Universidade Estácio de Sá / Laboratório Nacional de Computação Cientíca Prof. M.Sc. Matheus Bousquet Bandini Universidade Estácio de Sá / Laboratório Nacional de Computação Cientíca
4 Dedicatória Dedico este trabalho primeiramente a Deus, sem Ele, nada seria possível. Ele me ouviu e apareceu com suas sábias respostas na hora em que estáva precisando. Fui guiada por Ele e consegui chegar onde cheguei. Aos meu pai, Carlos de Souza Cardoso (in memorian) e minha mãe, Heloisa Esteves, aos meus lhos Matheus Esteves Cardoso e Júlia Esteves Cardoso, por toda paciência e carinho investidos em mim durante a trajetória. Sei que não foi fácil, mas valeu a pena esperar. A minha família e a todos os meus amigos que participaram direta ou indiretamente nessa fase da minha vida. Não posso deixar de dedicar, novamente a minha mãe, que sofreu, riu e chorou junto comigo no desenvolvimento de todo o projeto e todo o curso. Mãe, muito obrigada por tudo. Sem você, nada disso seria possível. Larissa
5 Dedicatória Dedico este trabalho primeiramente a Deus que iluminou o meu caminho por esta longa tragetória. A minha mãe Dalva Maria da Silva, meu marido Ricardo Simões Reuther e a minha tia Rosária de Fátima Cortasio, que sempre me deram força, coragem e constante apoio nessa caminhada. A minha família, pela companhia constante e tão querida, pelas orações, palavras, abraços e carinhos. Ao meus amigos de perto e de longe, pelo amor e preocupações demonstradas através de s, ligações, palavras. Paula
6 Agradecimentos Agradeço ao MCTI (Ministério da Ciência, Tecnologia e Inovação) e ao LNCC (Laboratório Nacional de Ciência e Tecnologia) pela oportunidade de minha integração como estagiária em uma instituição de alto nível, seja em conhecimento e infra-estrutura. Agradeço aos coordenadores Paulo Cabral Filho e Wagner Vieira Léo e a todos do CSR (Coordenação de Sistemas e Redes) pelo apoio. Agradeço ao meu pai Paulo Sergio Cortasio, a minha tia Rosária de Fátima Cortasio, aos meus irmãos Lorem da Silva Cortasio e João Paulo da Silva Cortasio, aos meus cunhados Andreza Lahr, Rodrigo dos Santos e Alessandro Reuther, à minha concunhada Paula Reuther, ao meus sobrinhos Mariana Cortasio e Lucas Reuther, aos meus sogros Paulo Renato Reuther e Maria Terezinha Reuther e toda minha família por fazerem parte dessa minha jornada, pelo apoio, incentivo e paciência. Ao meu orientador Luis Rodrigo pela a oportunidade de trabalho no LNCC, por me ajudar com seus conhecimentos, pelos incentivos e pelas palavras sábias na hora certa. A Larissa Esteves por ter acreditado em mim, que sempre me ouviu paciênte ao longo desta jornada. A todos os professores que zerem parte da minha formação. A todos os companheiros de trabalho e amigos que zeram parte desta minha longa caminhada: Alexandre Esteves, Erik Guimarães, Felipe Vieira, Fernada Motta, Gustavo Ferreira, Jaqueline Bertelli, Josânia Pitzer, Larissa Esteves, Luciana Pereira, Mirian Portela, Robson do Carmo, Suzana Mattos e Theo Brazil. Em especial, a minha mãe Dalva Maria da Silva, porque sem ela não seria capaz de realizar esta longa caminhada e ao meu marido Ricardo Reuther pela paciência e compreensão prestados durante este período. Obrigada a todos que, mesmo não estando citados aqui, zeram parte da conclusão desta etapa. Paula
7 Agradecimentos Agradeço ao MCTI (Ministério da Ciência, Tecnologia e Inovação) e ao LNCC (Laboratório Nacional de Ciência e Tecnologia) pela oportunidade em participar como estagiária nessa instituição de alto nível. Obrigada pelo conhecimento. Agradeço aos coordenadores Paulo Cabral Filho e Wagner Vieira Léo e a todos do CSR (Coordenação de Sistemas e Redes) pelo apoio. Agradeço a minha mãe, por se importar tanto comigo e me fortalecer nas horas em que achava estar caindo. Agradeço aos meus lhos por entender minha ausência e por participarem de forma tão inuente, entendendo que estou fazendo isso por eles. Agradeço o meu grande amigo, mestre e orientador Luis Rodrigo de Oliveira Gonçalves, por acreditar em mim e, com muita diculdade, me auxiliar a chegar onde cheguei. Suas incansáveis tentativas em me acalmar, nas mais diversas situações, foram de grande apreço. A equipe SGS, que me acolheu durante o estágio, me inuenciando a ser sempre uma pessoa melhor, e me incentivando a querer sempre mais. Principalmente ao Alexandre Esteves e Suzana Mattos. A Mirian Portela, ao Théo Brazil, ao Robson Carmo e ao Felipe Vieira, que com suas brincadeiras, conseguiam descontrair os momentos de estresse. A minha grande amiga Paula Cortasio, que lutou comigo desde o começo, e que no nal, se mostrou uma grande guerreira. Aos meus grandes amigos Gustavo Ferreira e Marcus Furtado, que conversando conseguiam me acalmar e dizer que tudo daria certo. A equipe da NTL, principamente minha gerente Gisele Zukowski, que teve muita paciência comigo na reta nal. A todos os meus amigos, familiares e instrutores que por acaso não venham a ser citados, o meu muito obrigado! Larissa
8 Resumo O protótipo SGS:Log foi criado com o intuito de monitorar os logs descrevendo o processo dos registros de eventos num sistema operacional e nas redes de computadores, como em conexões cabeadas, redes wireless, acessos VPN, entre outros. A principal funcionalidade do protótipo, é dividir os logs em níveis de coletas, onde poderá também denir qual o tipo de mensagem será buscada. O sistema poderá vericar se houve a queda de um host, as portas envolvidas, o timestamp do horário do log, os protocolos utilizados e os dados que foram enviados para o servidor. A infra-estrutura do projeto SGS:Log é composta com quatro tipos de servidores: (i) o Servidor de Log, (ii) o Servidor de Hora, (iii) o Servidor de Banco de Dados e (iv) o Servidor de Aplicação, cada um com suas funcionalidades especícas, que serão detalhadas no Capítulo 1.
9 Abstract The prototype SGS:Log was developed aiming to monitor the logs describing the event register process main operating system and on computers networks, as wired connections, wireless networks, access VPN, among others. The main of prototype functionality, is to split the logs at various levels of collections, in where it will also be able to dene what type of message will be searched. The system will allow verify if there was oine a host, the ports involved, the timestamp of log time, protocols used and the data with were sent to the server. The infrastructure of the project SGS:Log is composed witch four types of servers: (i) the Server Log, (ii) the Server Time, (iii) Server Database and (iv) the Server Application, on with their specic functionalitys, which will be detail in Chapter 1.
10 Sumário 1 Introdução Motivação O Projeto SGS - Sistema de Gerência de Segurança O módulo SGS:Log Servidor de Log Servidor de Banco de Dados Servidor de Hora Servidor da Aplicação Infraestrutura de Log Conceitos Básicos Tipos/Formatos de Logs Serviço de Log e Servidores de Log Centralizados Monitoramento Local Serviço de log centralizado Rsyslog Facilitys Severity Destination Banco de Dados Syslog Monitoramento Local utilizando o Rsyslog Ferramentas no Mercado Splunk Kiwi Syslog Server LogZilla Tabela Comparativa Modelagem Modelagem Casos de Uso Descrição dos Casos de Uso DER: Diagrama de Entidade e Relacionamento
11 4.1.4 DD: Dicionário de dados do Banco de Dados Diagrama de Sequência Metodologias e Implementação do protótipo SGS:Log Metodologias HTML CSS Python Mod_python JavaScript Highcharts jquery Postgres Implementação do protótipo do SGS:Log Instalação e conguração do servidor de NTP Ambiente de Log Instalação e conguração do Daemon do Rsyslog Deploy do Protótipo Deploy da Camada de Persistência Deploy do Front-End Deploy do Back-End Python Python-pygresql Python-psycopg Subversion Rsyslog Dia Aptana Komodo Dropbox PhpPgAdmin PgAdmin DbVisualizer Astah Web2py O Protótipo SGS:Log O objetivo Principais funcionalidades Monitoramento das conexões P2P Monitoramento da rede Wireless Monitoramento dos certicados VPN Monitoramento dos Servidores
12 6.3 As três camadas do Módulo O Front-end Servidores P2P Wireless A Camada de Persistência O Back-end Conclusão Trabalhos Futuros Anexo As Redes de Computadores Década de 1950 e Década de Década de Década de Década de 2000 até os dias atuais Protocolos TCP/IP Camada de Aplicação Camada de Transporte Camada de Rede Camada de Enlace Camada Física Referências 126
13 Lista de Abreviaturas ARPA ARPANET BD CSS DARPA DD DER DOM EUA FTP HTML IDE IETF IP LAN LNCC MAN MVCC NSF NSFNET NTP OSI P2P PSP SGBD SGS SGS:CAD SGS:Ctrl SGS:Log SGS:Mon SGS:SNMP SSH SVN TCP/IP UML VOIP VPN Advanced Research Projects Agency Advanced Research Projects Agency Network Banco de Dados Cascading Style Sheets Defense Advanced Research Projects Agency Dicionário de Dados Diagrama de entidade realacionamento Document Object Model Estados Unidos da América File Transfer Protocol HyperText Markup Language Integrated Development Environment Internet Engineering Task Force Internet Protocol Local Area Network Laboratório Nacional de Computação Cientíca Metropolitan Area Network Multi Version Concurrency Control Network File System National Science Foundation Network Network Time Protocol Open System Interconection Peer-To-Peer Python Server Pages Sistema de Gestão de Banco de Dados Sistema de Gerência e Segurança Sistema de Gerência e Segurança: Cadastro Sistema de Gerência e Segurança: Controle Módulo de Monitoramento de Logs do Projeto SGS Sistema de Gerência e Segurança: Monitoramento Simple Network Management Protocol Secure Shell Subversion Transmission Control Protocol Internet Protocol Unied Modeling Language Voice Over Internet Protocol Virtual Private Network
14 Lista de Abreviaturas - cont W3C WAL WAN WHATWG WWW XHTML World Wide Web Consortium Write-Ahead Logging Wide Area Network Web Hypertext Application Technology Working Group Word Wide Web Extensible HyperText Markup Language
15 Lista de Figuras 3.1 Tela do Splunk - Gráco [44] Tela do Splunk - Textual [5] Tela do Kiwi Syslog [37] Tela do Kiwi Syslog - Web [24] Tela do LogZilla - Tabela [10] Tela do LogZilla - Gráco [11] Diagrama de Caso de Uso DER: Visão Geral Visão Parcial Visão parcial Visão Parcial Visão Parcial Visão Parcial Diagrama de Sequência - Login Diagrama de Sequência - Cadastro Diagrama de Sequência - Relatório Tela da ferramenta "Dia" Tela da ferramenta "Aptana" Tela da ferramenta "Komodo" Tela da ferramenta "Dropbox" Tela da ferramenta "PhpPgAdmin" Tela da ferramenta "PgAdmin 3" Tela da ferramenta "DbVisualizer" Tela da ferramenta "Astah" Tela da ferramenta "Web2py" [39] Tela Inicial - Informações do Protótipo Tela Inicial - Login Tela Inicial - Servidores Log dos servidores Identicação dos hosts Tela Inicial - P2P
16 6.7 Tela SGS:Log:P2P - Resumo Diário Tela SGS:Log:P2P - Dados Host Tela SGS:Log:P2P - Relatório Mensal Geral Tela SGS:Log:P2P - Relatório Mensal Diário Tela SGS:Log:P2P - Relatório por Hosts Tela SGS:Log:P2P - Relatório por Rede - Diário Tela SGS:Log:P2P - Relatório por Rede - Intervalo de dias Tela SGS:Log:P2P - Relatório por Rede - Todas - Diário Tela SGS:Log:P2P - Relatório por Rede - Todas - Intervalo Tela Inicial Wireless SGS:Log:Wireless - Relatório Diário SGS:Log:Wireless - Relatório Diário - Cont SGS:Log:Wireless - Relatório Mensal SGS:Log:Wireless - Relatório Mensal - Cont SGS:Log:Wireless - Dados dos Usuários SGS:Log:Wireless - Cadastro dos Usuários Tela Inicial - VPN Sgs:Log: VPN Sgs:Log: VPN - Dados sobre os certicados Sgs:Log: VPN - Dados sobre os certicados Camada de Persistência - Postgres Back-End - Script
17 Lista de Tabelas 2.1 Tabela das Facilitys Tabela das Prioritys Tabela systemevents Tabela systemeventsproperties Tabela Comparativa Dicionário de dados da tabela wireless_bloco Dicionário de dados da tabela wireless_local Dicionário de dados da tabela wireless_coleta Dicionário de dados da tabela wireless_essid Dicionário de dados da tabela log_vpn_certicados Dicionário de dados da tabela LogP2PLocal Dicionário de dados da tabela hosts Dicionário de dados da tabela hosts_tipos Dicionário de dados da tabela salas Dicionário de dados da tabela coordenacao Dicionário de dados da tabela redes Dicionário de dados da tabela redes_tipo Dicionário de dados da tabela usuario Dicionário de dados da tabela systemevents Modelo da pilha TCP/IP
18 Capítulo 1 Introdução Neste capítulo serão apresentados a motivação para o desenvolvimento do Projeto SGS e do módulo SGS:Log. Estes provêm um conjunto de ferramentas de gerência e monitoramento que visam atender às necessidades do Laboratório Nacional de Computação Cientíca. 1.1 Motivação Atualmente a maioria dos softwares geram durante sua execução, ou durante o seu ciclo de vida, uma elevada quantidade de mensagens de controle denominadas de logs. Desta forma, os logs são os registros de atividades relevantes relacionadas ao funcionamento de um sistema. Esses registros podem ser utilizados para restabelecer o estado inicial de uma máquina, conhecer o seu comportamento no passado e principalmente detectar os mais variados tipos de anomalias e eventos que podem ocorrer em um ambiente computacional. Logo, percebe-se que é fundamental aos administradores de um ambiente computacional, a possibilidade de extrair informações a partir dos registros de logs, principalmente aqueles 11
19 CAPÍTULO 1. INTRODUÇÃO 12 relacionados à rede, aos seus ativos e seus hosts. Através da coleta e análise desses registros, pode-se vericar, por exemplo, o tempo que um host cou inoperante e o motivo dele ter permanecido nesse estado. Além disto, é possível (i) vericar a qualidade de sinal dos vários AP's Wireless, (ii) os acessos realizados através da VPN (Virtual Private Network), (iii) vericar a validade dos certicados, (iv) acompanhar as tentativas de acesso, com privilégio administrativo, de usuários não autorizados. Desta forma, o desenvolvimento deste trabalho foi motivado, principalmente, pela diculdade e pela necessidade de extrair informações relevantes a partir de um ambiente de log que centralize seletivamente as mensagens geradas pelos vários equipamentos conectados à uma rede. 1.2 O Projeto SGS - Sistema de Gerência de Segurança O projeto SGS - Sistema de Gerência e Segurança visa atender às necessidades do Serviço de Redes do Laboratório Nacional de Computação Cientíca [21]. Um dos objetivos deste projeto é a modelagem e o desenvolvimento de um sistema complexo cuja nalidade é auxiliar a equipe do laboratório em diversos aspectos relacionados: (i) à gerência, (ii) ao monitoramento e a (iii) segurança do ambiente computacional [21]. Visando facilitar o desenvolvimento e o processo de manutenção, o projeto SGS é dividido em vários módulos, cada qual com uma função especíca, porém, todos relacionados com alguma necessidade especíca. Dentre os módulos do projeto destacam-se [21]: SGS:Ctrl - Módulo para controle de banda em redes. SGS:SNMP - Módulo de gerência baseado no protocolo SNMP. SGS:Mon - Módulo de monitoramento de rede.
20 CAPÍTULO 1. INTRODUÇÃO 13 SGS:Log - Módulo de acompanhamento de Log. SGS:Inventário - Módulo de controle de inventário. SGS:Cad - Módulo de controle de funcionários. Estes módulos, em conjunto, auxiliam no monitoramento, gerência e implantação de políticas de segurança da informação e controle da rede de dados [21]. Os módulos SGS:Ctrl e SGS:SNMP já estão em fase de implementação e teste, enquanto a versão 2 do módulo SGS:Mon e os módulos SGS:Log e SGS:Inventário se encontram em modelagem e desenvolvimento [21]. Atualmente encontra-se em estudo a viabilidade de dois novos módulos, SGS:Security, que proverá uma série de funcionalidades focadas em garantir a aderência do ambiente computacional do LNCC, a sua Política de Segurança e as principais normas de segurança da informação e o SGS:Firewall e Hotspot, que facilitará a construção de regras de rewall, aplicacão das mesmas nos hosts da rede, assim como proverá os meios para implementar os hotspots para a rede sem o do LNCC [21]. 1.3 O módulo SGS:Log O protótipo SGS:Log foi criado com o intuito de monitorar as mensagens de log geradas pelos hosts de uma rede e encaminhados à um servidor centralizado e a partir do servidor centralizado realizar a análise do conteúdo das mensagens. Nesta fase do projeto, o protótipo está focado na análises dos logs relacionados aos acessos realizados por meio do servidor de VPN, na análise das mensagens de log geradas pelas bridges, que estão relacionadas ao uso do protocolos P2P e na análise do log da
21 CAPÍTULO 1. INTRODUÇÃO 14 aplicação, que monitora a rede Wireless. Dependendo do tipo da mensagem, ela é encaminhada a um dos servidores centralizados e em seguida é armazenada em um banco de dados, permanecendo nele por um determinado intervalo de tempo, denido pelo administrador. Estas mensagens são tratados de forma a facilitar o entendimento das ocorrências registradas pelo ambiente de log. A principal funcionalidade do protótipo, é dividir os logs em níveis de coletas, onde também podemos denir qual o tipo de mensagem será buscada e tratada. Desta forma, é possível vericar se houve a queda de um host, as portas envolvidas, o timestamp do horário do log, os protocolos utilizados e os dados que foram enviados para o servidor. A infra-estrutura do projeto SGS:Log é composta com quatro tipos de servidores: (i) os Servidores de Log, (ii) o Servidor de Hora, (iii) os Servidores de Banco de Dados e (iv) o Servidor de Aplicação Servidor de Log Os Servidores de Log serão o núcleo do protótipo da aplicação. Eles recebem todos os logs dos demais servidores e dos ativos de rede. Os registros gerados pelos logs serão tratados e enviados ao servidor de Banco de Dados Servidor de Banco de Dados O Servidor de Banco de Dados receberá os dados tratados pelo servidor de log e os armazenará de forma segura. Esse servidor será a camada de persistência. A partir dos dados armazenados nas tabelas do banco de dados, o administrador poderá visualizar o que está ocorrendo na rede e nos equipamentos conectados à ela.
22 CAPÍTULO 1. INTRODUÇÃO Servidor de Hora Para investigar os incidentes de segurança, existe a necessidade do horário dos dispositivos envolvidos na análise permanecerem sincronizados para que possam ser coletados e armazenados de forma sincronizada com todos os servidores em questão. O Servidor de Hora permitirá que a hora seja atualizada de forma automática. Graças ao uso deste tipo de serviço, é possível manter o horário de todos os equipamentos conectados em rede devidamente sincronizados. Deste modo, no ambiente proposto, todos os outros servidores do ambiente de log devem atualizar seus relógios com este servidor. O servidor de hora será constantemente atualizado com a hora legal brasileira utilizando o protocolo NTP - Network Time Protocol Servidor da Aplicação O Servidor da Aplicação armazenará todo o código fonte e os scripts do protótipo. Pela aplicação, o administrador e os usuários devidamente autenticados e autorizados, terão acesso às funcionalidades deste componente do projeto SGS. A partir das aplicações instaladas neste servidor, os logs serão separados e identicados. O administrador poderá visualizar, através dos grácos, o que de fato está ocorrendo na rede. No próximo capítulo serão apresentados os principais conceitos relacionados aos mecanismos de registros das mensagens de log e relacionados ao syslog, um dos principais protocolos utilizados para esta nalidade.
23 Capítulo 2 Infraestrutura de Log Este capítulo destina-se a apresentar os conceitos básicos relacionados aos logs e sua aplicação em um ambiente de rede. 2.1 Conceitos Básicos Atualmente, a maioria dos softwares geram, durante sua execução ou durante o seu ciclo de vida, uma elevada quantidade de mensagens de controle que denominamos de logs. Desta forma, os logs são mensagens que registram as atividades relevantes relacionadas ao funcionamento de um sistema. Esses registros podem ser utilizados para restabelecer o estado inicial de uma máquina, determinar o seu comportamento no passado e principalmente detectar os mais variados tipos de anomalias e eventos que podem ocorrer em uma ambiente computacional Tipos/Formatos de Logs Os formatos de logs existentes, denem a origem da mensagem. Nos logs originados pelo rsyslog, eles são apresentados na seguinte forma [13]: 16
24 CAPÍTULO 2. INFRAESTRUTURA DE LOG 17 Data Hora Máquina daemon mensagem No caso de um log originado por um cliente baseado em sistemas da microsoft, os registros serão apresentados na seguinte forma [35]: Data Hora Usuário host Identificação Origem priority categoria No caso de um log originado por um servidor apache, o log será representado da seguinte forma [19]: Data e Hora priority do erro host do cliente mensagem de erro Dentre os formatos que podem ser utilizados para o armazenamento dos logs destacamse: (i) Arquivo de texto, (ii) Arquivo Binário, (iii) Arquivo Binário Circular, (iv) Arquivo de Rastreamento Sequencial e (v) Banco de Dados SQL [34] Arquivo de texto Dene que todos os logs serão armazenados em um arquivo de texto puro. Caso esse arquivo não exista, ele poderá ser criado. Essa opção armazena todos os logs recebidos pelas congurações iniciais, mas não identicam qual a prioridade da visualização, dicultando a análise. Este é o formato default utilizado pelos (i) Deamon Rsyslog do Unix e pelos ativos de rede Arquivo Binário Esta opção dene o uso de um arquivo de log sequencial em formato binário. Geralmente utilizado para registrar instâncias de dados intermitentes, ou seja, parando e continuando depois de iniciada a execução do log.
25 CAPÍTULO 2. INFRAESTRUTURA DE LOG 18 O Linux utiliza este tipo de formato para registar o processo de autenticação. Sempre que um usuário consegue se autenticar, uma mensagem é gerada e enviada para um arquivo especíco. O mesmo ocorre quando um usuário tenta se conectar mas não fornece corretamente os dados da credencial Arquivo Binário Circular Possui a mesma denição do item acima, porém, registra os dados de forma contínua, substituindo os registros anteriores por novos dados quando o arquivo atingir seu tamanho máximo. Esta solução evita que ocorra um estouro no consumo de espaço em disco, o que pode causar a paralisação de todo o sistema Arquivo de Rastreamento Sequencial Dene um arquivo de log de rastreamento sequencial que coleta dados até alcançar um limite denido pelo administrador, e em seguida, fecha o arquivo e inicia outro. Apesar de não ser suportado, por padrão, pelo Linux, o seu funcionamento pode ser simulado utilizando a aplicação logrotate, disponível na maioria das distribuições Banco de Dados SQL Esse formato é o mais adequado para o armazenamento e posterior análise dos logs. [33]. Dependendo do sistema de log utilizado, ele pode prover suporte ao Sistema de Gerenciamento de Banco de Dados. Por exemplo o deaemon Rsyslog, que é o padrão do Linux, possui suporte ao MySQL Server, ao Postgresql dentre outros. Independentemente do SGDB utilizado, quando o rsyslog é congurado para encaminhar as mensagens para um banco SQL, este banco deve possuir pelo menos duas tabelas, que serão apresentadas com detalhe na seção Rsyslog. A instalação e conguração do ambiente Rsyslog será apresentada no Capítulo 8.
26 CAPÍTULO 2. INFRAESTRUTURA DE LOG Serviço de Log e Servidores de Log Centralizados Esta seção aborda as várias formas de como se pode tratar e registar os as mensagens de log através dos serviços especializados oferecidos pela maioria dos sistemas operacionais, sejam eles para desktop, servidores ou ativos de rede Monitoramento Local O sistema de registro local armazena os dados gerados pelo sistema no próprio sistema. Esses logs podem ser armazenados em arquivos de texto ou em um banco de dados. Será utilizado quando houver a necessidade da vericação dos logs locais. Todo sistema Unix Like, já vem devidamente congurado para funcionar desta forma, assim como alguns ativos de rede também possuem suporte a esta funcionalidade. Sua instalação e conguração seguem os mesmos padrões do monitoramento centralizado, porém não é muito utilizado quando tratamos de uma rede com vários hosts. A instalação e conguração do monitoramento local em um ambiente Linux serão apresentadas no Capítulo 8. À medida que a quantidade de serviços e hosts a serem monitorados aumenta, a quantidade de mensagens cresce proporcionalmente. Quando os serviços estão centralizados em um único host e passam a ser hospedados em várias máquinas, o armazenamento local das mensagens de log começam a ser menos ecientes e uma nova solução deve ser encontrada, como um armazenamento centralizado Serviço de log centralizado Quando a quantidade de mensagens de logs a ser gerenciada aumenta ou quando os serviços a serem monitorados estão distribuidos na rede surge a necessidade da criação
27 CAPÍTULO 2. INFRAESTRUTURA DE LOG 20 de um ambiente centralizado de log, que não impede o armazenamento local. Com um ambiente centralizado além da detecção de incidentes isolados podem ser detectados e trata incidentes e eventos distribuídos. Geralmente em um ambiente centralizado de log, as mensagens serão redirecionadas para um ou vários servidores, o que irá facilitar a consulta dos enventos ocorridos na rede. O monitoramento centralizado tem por nalidade armazenar, em um único servidor, todos os dados enviados por um grupo de hosts que possuem alguma relação, como por exemplo, os ativos da rede, as bridges de segurança e rewalls, os servidores de um determinado projeto. Em um ambiente com servidores de log centralizados, além da conguração padrão, necessita-se que seja realizada a adição de regras no arquivo de conguração dos clientes. Uma vez que os clientes estejam devidamente congurados, todos os logs, ou apenas alguns tipos, serão enviados para o servidor especíco, onde as mensagens podem ser salvas em um Banco de Dados, que pode ser criado e congurado pelo próprio syslog. Esses logs, geralmente, são armazenados em um SGBD para facilitar a sua análise e vericação. Uma das vantagens da utilização de um servidor de log centralizado está em facilitar o gerenciamento e a análise das mensagens armazenadas. Essas mensagens serão agrupadas e analisadas, de forma que facilite a detecção de incidentes isolados ou distribuídos. Geralmente quando há um ataque, os logs, caso estejam armazenados localmente, podem ser facilmente apagados, dicultando a descoberta da origem do ataque, ou até mesmo quais os sistemas que foram comprometidos. Para evitar que a rede seja inundada com pacotes contendo as mensagens de log, em alguns casos pode-se implementar um cenário de duas redes, uma com os dados dos usuários
28 CAPÍTULO 2. INFRAESTRUTURA DE LOG 21 e outra para controle onde trafegará as mensagens de log. Para a instalação e conguração de um servidor de log centralizado, verique as especicações contidas no item "Monitoramento Centralizado". [20] 2.3 Rsyslog O Rsyslog é um padrão criado pela IETF (Internet Engineering Task Force) para a transmissão de mensagens de log em redes baseadas na pilha de protocolo IP. O termo identica tanto o protocolo de rede quanto aplicação ou biblioteca de envio de mensagens. Esse protocolo é tipicamente usado no gerenciamento e na auditoria de sistemas, garantindo a visualização das mensagens geradas pelos sistemas. [32] Todos os sistemas estão aptos a realizar uma coleta pelo syslog, basta que seja realizada a conguração detalhada no Capítulo 8. O arquivo de conguração possui o seguinte formato: "facility.priority destination". A seguir, um exemplo da coleta realizada pelo rsyslog e uma breve descrição das opções para armazenamento das mensagens :25: :25: peach Warning: backward compatibility layer added to fo... 1 rsyslogd: :25: :25: peach Could not create tcp listener, ignoring port rsyslogd-2077: Facilitys Em um ambiente Unix Like, o campo facility pode especicar o tipo de programa, ou o daemon que está enviando a mensagem ao serviço de log. Neste caso os principais valores
29 CAPÍTULO 2. INFRAESTRUTURA DE LOG 22 para este campo estão sendo demonstrados na tabela 3.1. Generalizando o campo facility, ele pode assumir qualquer valor entre 0 e 23, e o seu signicado irá depender do tipo de sistema que o gerou. Desta forma, podemos perceber que um sistema de gerência de log deve levar em consideração não apenas as mensagens de forma individual, mas sim em um contexto mais amplo, no qual a origem e outros campos alem do corpo da mensagem sejam analisados. Número Chave Descrição 0 kern Mensagens do kernel do sistema. 1 user Armazena as aplicações e o processo dos usuários 2 mail Armazenará as mensagens eletrônicas 3 daemon Armazena as mensagens do daemon do sistema 4 auth Armazena os comandos de autenticação e autorização no sistema 5 syslog Armazena as mensagens internas geradas pelo próprio syslog 6 lpr Armazena a linha de impressão e enleiramento 7 news Armazena mensagens de notícias da rede (desatualizado) 8 uucp Armazenará mensagens do subsistema de UUCP 9 - Armazenará informações relativas ao relógio do daemon 10 authpriv Armazenará mensagens de autorização que não são do sistema. 11 ftp Armazena os daemons de FTP do sistema Armazenará informações relativas ao protocolo ntp 13 - Armazenará os logs de auditoria de sistemas 14 - Armazenará os logs de alerta do sistema 15 cron Armazenará informações relativas ao relógio do daemon do sistema 16 local0 Armazenará informações internas locais (use 0 (local0)) 17 local1 Armazenará informações internas locais (use 1 (local1)) 18 local2 Armazenará informações internas locais (use 2 (local2)) 19 local3 Armazenará informações internas locais (use 3 (local3))
30 CAPÍTULO 2. INFRAESTRUTURA DE LOG local4 Armazenará informações internas locais (use 4 (local4)) 21 local5 Armazenará informações internas locais (use 5 (local5)) 22 local6 Armazenará informações internas locais (use 6 (local6)) 23 local7 Armazenará informações internas locais (use 7 (local7)) Tabela 2.1: Tabela das Facilitys Severity Para complementar o signicado da mensagem, há o campo Severity que pode assumir oito valores diferentes. Desta forma, para cada facility, existe a possibilidade de indicar oito níveis de severidade ou importância das mensagens. O campo Severity pode assumir tando um valor decimal quanto um texto para representar seu nível de importância. A Tabela 3.2, apresenta os oitos valores, a palavra chave e a denição, que segundo a RFC 5424, será assumida na seguinte forma: Número Chave Descrição 0 emerg O sistema cará fora de operação se não for resolvido. 1 alert Será necessária uma ação imediata. 2 crit Situação crítica. Necessita ser avaliada. 3 err Condições de erro 4 warn Erros recuperáveis. 5 notice Situação inesperada que precisa ser investigada. 6 info Mensagem de informação. 7 debug Dados detalhados para o desenvolvimento e testes. Tabela 2.2: Tabela das Prioritys
31 CAPÍTULO 2. INFRAESTRUTURA DE LOG Destination O campo destination dene o local do armazenamento dos logs, ou seja, dene onde e como as mensagens serão armazenadas. Uma determinada mensagem pode ter mais do que um destino. Este campo pode assumir um dos valores abaixo: nome_do_arquivo - O rsyslog enviará os logs para o arquivo especicado. - Pipe - O rsyslog enviará os logs através de um, desta forma as mensagens podem ser tratadas por interpretadores externos, como por exemplo - O rsyslog enviará os logs para um computador remoto, utilizando um hostname ou ip; além de enviar para um host remoto, esta opção permite o envio das mensagens para módulos externos do rsyslog, como por exemplo enviando o resultado da coleta para um servidor centralizado. user1, user2 - O rsyslog enviará as mensagens de logs para os usuários especicados e caso haja mais de um usuário, os logins devem estar separados por vírgulas. * - O rsyslog enviará os logs para todos os usuários logados utilizando o comando wall Banco de Dados Syslog Além de permitir que as mensagens de logs sejam enviadas para arquivos especícos, o rsyslog, por meio de módulos adicionais permite que as mensagens sejam armazenadas em um banco de dados. Por padrão, quando instadado e congurado um sistema de gerenciamento de banco de dados para que armazene as mensagens de logs, ele cria um banco de dados Syslog e 2(duas) tabelas, systemevents e systemeventsproperties.
32 CAPÍTULO 2. INFRAESTRUTURA DE LOG 25 Na tabela systemevents são armazenadas as mensagens de logs originados dos clientes, como será detalhado na Tabela 3.3.
33 CAPÍTULO 2. INFRAESTRUTURA DE LOG 26 Coluna Descrição receivedat Armazena o horário do recebimento da mensagem devicereportedtime Armazena o tempo relatado pelo dispositivo facility * Armazena o nível das facilitys priority * Armazena o nível das prioritys fromhost Armazena o host que gerou a mensagem message Armazena a mensagem recebida ntseverity Armazena a severidade da mensagem importance Armazena a importância da mensagem eventsource Armazena a origem do evento eventuser Armazena o evento do usuário eventcategory Armazena o evento da categoria eventid Armazena a identicação do evento eventbinarydata Armazena os dados binários do evento maxavailable Armazena a mensagem máxima disponível currusage minusage Armazena o uso mínimo maxusage Armazena o uso máximo infounitid Armazena a identicação da unidade syslogtag Armazena a tag do syslog eventlogtype Armazena o tipo de log do evento genericlename Armazena o nome genérico do arquivo systemid Armazena a identicação do sistema Tabela 2.3: Tabela systemevents Na tabela systemeventsproperties, conforme exibido na Tabela 3.4, armazenam as propriedades dos eventos no sistema, que no caso do protótipo SGS:Log, ela não é necessária.
34 CAPÍTULO 2. INFRAESTRUTURA DE LOG 27 Coluna Descrição id Armazena a id da propriedade systemeventid Armazena a id do evento do sistema paramname Armazena o nome dos parâmetros paramvalue Armazena o valor dos parâmetros Tabela 2.4: Tabela systemeventsproperties As vantagens do uso de ferramentas como o Rsyslog, é facilitar o processo de registro e armazenamento das mensagens de logs, consequentemente, estas informações podem ser facilmente localizadas. Utilizando-se o Rsyslog, é possível realizar dois tipos de monitoramento, um localmente e outro no qual as mensagens são enviadas para um servidor, geralmente dedicado. A seguir são apresentadas as duas opções Monitoramento Local utilizando o Rsyslog O monitoramento local registra as mensagens de saída do kernel e todas aquelas enviadas ao syslog. O daemon syslog controla o registro de logs do sistema e alguns outros. Este daemon permite que seja especicado para qual, ou quais arquivos as mensagens devem ser redirecionadas. Em sistemas baseados no Unix, estes arquivos geralmente cam armazenados no diretório /var/log. Para realizar a instalação e conguração do Rsyslog, realize os passos descritos no capítulo 8. No próximo capítulo serão apresentadas algumas ferramentas atualmente disponíveis para gerência e monitoramento de ambientes de Logs baseados no Rsyslog.
35 Capítulo 3 Ferramentas no Mercado Neste capítulo serão apresentadas algumas das aplicações atualmente disponíveis para gerência e monitoramento de ambientes de Logs baseados no Rsyslog. 3.1 Splunk Esse aplicativo é um armazenador das mensagens dos dados gerados pelas máquinas. Tem como funcionalidade principal coletar e armazenar os dados do tráfego da rede, servidores web, aplicativos, servidores de aplicativos, sistemas de GPS, mídias sociais e banco de dados estruturados. O sistema armazena os resultados em arquivos com assinatura e auditoria de dados opcionais para comprovar a integridade dos dados. Como vantagem, cada transação do Splunk é autenticada, inclusive as atividades dos usuários através da interface web, interface de linha de comando e atividades dos sistemas por meio de uma API integrada [22]. O Splunk está atualmente na versão 4.3 e por um período de 60 dias permite indexar 500 megabytes de dados por dia. Após esse prazo, para que o usuário continue utilizando todos os benefícios, deverá ser adquirida uma licença Enterprise. 28
36 CAPÍTULO 3. FERRAMENTAS NO MERCADO 29 A gura 3.1 exibe uma tela gráca de uma coleta realizada pelo splunk e a gura 3.2 exibe as coletas em forma textual. Figura 3.1: Tela do Splunk - Gráco [44]
37 CAPÍTULO 3. FERRAMENTAS NO MERCADO 30 Figura 3.2: Tela do Splunk - Textual [5] 3.2 Kiwi Syslog Server Kiwi Syslog Server oferece um servidor de log para administradores de rede. Possui visualização dos registros, alertas sobre o logs recebidos pelo syslog, mensagens do protocolo SNMP e mensagens coletadas dos dispositivos como roteadores, switchs, servidores Linux e Unix. Realiza o monitoramento em tempo real, envia um aos administradores e centraliza os resultados para rápida identicação do problema. O software não possui limites de clientes cadastrados, armazena várias mensagens simultâneas e possui um geren-
38 CAPÍTULO 3. FERRAMENTAS NO MERCADO 31 ciador dos arquivos de logs, onde o administrador pode cadastrar o sistema para criptografar, renomear, mover e excluir regras [43]. Foi desenvolvido para sistemas microsoft, podendo somente o cliente ser baseado em sistemas Linux e Unix. O software está na versão e possui uma versão trial por apenas 14 dias, custando a partir dessa data $ 295,00. A gura 3.3 exibe os resultados da coleta em um display acoplado ao software e a gura 3.4 exibe os resultados armazenados em um servidor. Figura 3.3: Tela do Kiwi Syslog [37]
39 CAPÍTULO 3. FERRAMENTAS NO MERCADO LogZilla Figura 3.4: Tela do Kiwi Syslog - Web [24] É um fornecedor global de gerenciamento de eventos armazenados pelo syslog. Através da coleta, o aplicativo fornece pesquisas, monitoramentos e relatórios em tempo real. Pode detectar e rastrear comportamento suspeito evitando incidentes, proporciona o regulamento dos dados e operações de rotina. Fornece resultados por indexação em segundos, pode receber logs de até hosts, ignora mensagens duplicadas e oferece serviços baseados em nuvem, permitindo ao usuário o envio dos logs para o datacenter, não necessitando servidor próprio. Possui visualização em formatos grácos e textuais [45].
40 CAPÍTULO 3. FERRAMENTAS NO MERCADO 33 O licenciamento é baseado no número de hosts e nas mensagens que são armazenadas, e de acordo com os valores aproximados de registro das mensagens de todos os hosts do laboratório que devem ser cadastrados, o valor caria próximo dos $3.600,00 [29]. A gura 3.5 exibe uma coleta, onde os resultados são armazenados em uma tabela. A gura 3.6 exibe o resultado em formato gráco. Figura 3.5: Tela do LogZilla - Tabela [10]
41 CAPÍTULO 3. FERRAMENTAS NO MERCADO Tabela Comparativa Figura 3.6: Tela do LogZilla - Gráco [11] A Tabela 3.1 representa uma comparação entre as ferramentas analisadas e o projeto SGS:Log. Descrição SGS:Log Splunk Kiwi Syslog Server LogZilla Envio de - - X X Servidor interno X - - X Fácil conguração X - X - Sistemas Unix X X - - Sistemas Microsoft - X X X Sistemas Apple X - - X Front-End amigável X X X - Armazenamento em BD X - - X Tabela 3.1: Tabela Comparativa
42 CAPÍTULO 3. FERRAMENTAS NO MERCADO 35 Com a comparação realizada entre as ferramentas analisadas e o sistema proposto, identicamos a necessidade do desenvolvimento do protótipo SGS:Log, para que atendesse todas às necessidades do laboratório. No próximo capítulo será apresentando a modelagem do protótipo, assim como suas tabelas, seus casos de uso e seus diagramas.
43 Capítulo 4 Modelagem Neste capítulo serão apresentadas a metodologia e a modelagem utilizada no desenvolvimento do protótipo SGS:Log. 4.1 Modelagem A modelagem foi utilizada para facilitar o entendimento, o comportamento e o desenvolvimento do projeto. Essa parte do projeto evitará erros na programação, no andamento do projeto e em seu próprio funcionamento. Essa modelagem deverá atender o ponto de vista do desenvolvedor, agregar detalhes na implementação e demonstrar como os dados são sicamente armazenados Casos de Uso Esta seção é composta pelos casos de uso que descrevem o login do usuário, o cadastro dos dados, a edição e exclusão dos dados do sistema, a vizualização e criação dos relatórios. A gura 4.1 sumariza os casos de uso do protótipo SGS:Log. 36
44 CAPÍTULO 4. MODELAGEM 37 Figura 4.1: Diagrama de Caso de Uso
45 CAPÍTULO 4. MODELAGEM Descrição dos Casos de Uso Caso de Uso da tela: Login Descrição : Envia ao sistema o requerimento de autenticação para acesso. Pré-Condições : Necessário que o usuário possua um login cadastrado no sistema. Atores : Todos os usuários cadastrados no sistema. Cenário Principal : 1. Ator - Acessar o sistema 2. Sistema - Exibir a tela de login 3. Ator - Fornecer seu login 4. Ator - Fornecer a senha 5. Ator - Clicar no botão de acesso ao sistema 6. Sistema - Validar o login do usuário 7. Sistema - Exibir usuário logado Cenário Alternativo : 1. Ator - Acessar o sistema 2. Sistema - Exibir a tela de login 3. Ator - Fornecer login errado 4. Ator - Fornecer senha errada 5. Ator - Clicar no botão de acesso ao sistema 6. Sistema - Validar login do usuário e retornar mensagem de erro de acesso ao sistema 7. Sistema - Retornar aos passos 3 e 4 do Cenário Principal
46 CAPÍTULO 4. MODELAGEM Caso de Uso da tela: Cadastro de dados Descrição : Realizar o cadastro de dados no sistema. Pré-Condições : Estar logado no sistema. Atores : Administradores Cenário Principal : 1. Ator - Fazer os passos do caso de uso ; 2. Sistema - Exibir tela de cadastro; 3. Ator - Inserir dados a serem cadastrados; 4. Ator - Clicar no botão cadastrar; 5. Sistema - Validar dados inseridos pelo usuário; 6. Sistema - Exibir mensagem de cadastro realizado; Cenário Alternativo : 1. Ator - Fazer passos 1, 2, 3 e 4 do cenário principal; 2. Sistema - Validar os dados informados e informar um erro; 3. Sistema - Voltar aos passos 3 e 4 do cenário principal; Caso de uso da tela: Editar dados do sistema Descrição : Editar dados no sistema. Pré-Condições : Estar logado no sistema e ter dados a serem alterados. Atores : Administradores Cenário Principal : 1. Ator - Fazer os passos do caso de uso ;
47 CAPÍTULO 4. MODELAGEM Sistema - Exibir tela de cadastro com os dados a serem editados; 3. Ator - Editar dados a serem alterados; 4. Ator - Clicar no botão salvar; 5. Sistema - Validar dados inseridos pelo usuário; 6. Sistema - Editar realizado; Cenário Alternativo : 1. Ator - Fazer passos 1, 2, 3 e 4 do cenário principal; 2. Sistema - Validar os dados informados e informar um erro; 3. Sistema - Voltar aos passos 3 e 4 do cenário principal; Caso de uso da tela: Excluir dados do sistema Descrição : Excluir dados no sistema. Pré-Condições : Estar logado no sistema e existir dados no sistema. Atores : Administradores Cenário Principal : 1. Ator - Fazer os passos do caso de uso ; 2. Sistema - Exibir botões e ícones de exclusão dos dados; 3. Ator - Clicar no botão ou ícone para excluir dados; 4. Sistema - Conrmar exclusão dos dados; Cenário Alternativo : 1. Ator - Não clicar em excluir dados;
48 CAPÍTULO 4. MODELAGEM Caso de uso da tela: Visualizar relatórios Descrição : Visualizar relatórios do sistema. Pré-Condições : Estar logado no sistema. Atores : Todos os usuários cadastrados no sistema Cenário Principal : 1. Ator - Fazer os passos do caso de uso ; 2. Sistema - Mostrar tela dos relatórios; Cenário Alternativo : 1. Sistema - Erro ao mostrar relatórios; Caso de uso da tela: Criar relatórios Descrição : Criar relatórios no sistema. Pré-Condições : Estar logado no sistema. Atores : Todos os usuários cadastrados no sistema Cenário Principal : 1. Ator - Fazer os passos do caso de uso ; 2. Sistema - Mostrar tela de criação dos relatórios; Cenário Alternativo : 1. Ator - Não entrar na tela de criação de relatórios;
49 CAPÍTULO 4. MODELAGEM DER: Diagrama de Entidade e Relacionamento Esta seção apresenta o Diagrama de Entidade e Relacionamento do banco de dados e as tabelas utilizadas pelo protótipodo SGS:Log. A gura 4.2, contém todas as tabelas e relacionamentos do banco de dados. A gura 4.3 por sua vez apresenta as tabelas hosts, hosts_tipos, salas, contato e redes. A gura 4.4, apresenta as tabelas wireless_coleta, wireless_essid, wireless_local, wireless_bloco e wireless_usuarios. A gura 4.5, apresenta as tabelas log_vpn_certicados e logp2plocal. A gura 4.6, apresenta as tabelas usuario e coordenacao e nalmente a gura 4.7 a tabela systemevents. Figura 4.2: DER: Visão Geral
50 CAPÍTULO 4. MODELAGEM 43 Figura 4.3: Visão Parcial 1
51 CAPÍTULO 4. MODELAGEM 44 Figura 4.4: Visão parcial 2
52 CAPÍTULO 4. MODELAGEM 45 Figura 4.5: Visão Parcial 3
53 CAPÍTULO 4. MODELAGEM 46 Figura 4.6: Visão Parcial 4
54 CAPÍTULO 4. MODELAGEM 47 Figura 4.7: Visão Parcial DD: Dicionário de dados do Banco de Dados Esta seção descreve todas as tabelas necessárias para o funcionamento do protótipo do módulo SGS:Log, bem como os campos que as compõem.
55 CAPÍTULO 4. MODELAGEM Tabela wireless_bloco A tabela 4.1 armazena a identicação dos blocos que compõem a estrutura do campus do LNCC em Petrópolis. Coluna Tipo (Tamanho) Descrição cod_bloco Integer Armazena código do bloco bloco Char(50) Armazena o bloco das salas Tabela 4.1: Dicionário de dados da tabela wireless_bloco Tabela wireless_local A tabela 4.2 armazena a listagem das salas pertencente a tabela wireless_bloco é possível determinar a sua localização Coluna Tipo (Tamanho) Descrição cod_local Integer Armazena o código do local descricao Char(50) Armazena o nome do responsável cod_bloco Integer Armazena o código do bloco Tabela 4.2: Dicionário de dados da tabela wireless_local
56 CAPÍTULO 4. MODELAGEM Tabela wireless_coleta A tabela 4.3 armazena os dados das coletas realizadas. Coluna Tipo (Tamanho) Descrição id Integer Armazena o id do usuário data Char(10) Armazena a data da coleta hora Char(10) Armazena a hora da coleta strength Char(100) Armazena o strength bssid Char(100) Armazena o bssid bitrates Char(50) Armazena o bitrates essid Char(100) Armazena o ESSID qualidade Char(100) Armazena a qualidade do sinal canal Char(100) Armazena canal de acesso modo Char(100) Armazena o modo de acesso cod_essid Char(100) Armazena o número do código essid criptograa Char(100) Armazena o modo de criptograa local Char(100) Armazena o local da conexão cod_local Integer Armazena o código do local cod_essid Integer Armazena o código do ESSID Tabela 4.3: Dicionário de dados da tabela wireless_coleta
57 CAPÍTULO 4. MODELAGEM Tabela wireless_essid A tabela 4.4 tem como nalidade armazenar informações referentes aos equipamentos da rede wireless. Coluna Tipo (Tamanho) Descrição cod_essid Integer Armazena nome do usuário sala Char(20) Armazena a sala do usuário responsavel Char(100) Armazena o nome do responsável timestamp_primario Char(100) Armazena o timestamp inicial timestamp_recente Char(100) Armazena o timestamp nal essid Char(50) Armazena o nome do ESSID Tabela 4.4: Dicionário de dados da tabela wireless_essid Tabela log_vpn_certicados A tabela 4.5 tem por nalidade armazenar as informações dos certicados de acesso utilizados pelas VPN s do LNCC. Coluna Tipo (Tamanho) Descrição codigo Integer Armazena codigo dos certicados servidora Char(30) armazena as chaves de acesso arquivo Char(30) armazena o local do arquivo na servidora login Char(30) armazena o login de acesso Char(30) armazena o e mail de acesso validade_str Char(40) armazena a validade de acesso validade_tm Char(15) armazena o timestamp do acesso validade_dias Integer armazena a data pra vencimento do acesso status Integer armazena se login está ativo ou inativo
58 CAPÍTULO 4. MODELAGEM 51 Tabela 4.5: Dicionário de dados da tabela log_vpn_certicados Tabela LogP2PLocal A tabela 4.6 tem por nalidade o armazenamento do sumário dos logs relacionados aos pacotes P2P que passaram pela rede. Coluna Tipo (Tamanho) Descrição codigo Integer Armazena código data Char(11) Armazena a data origem Char(16) Armazena o host gerador do acesso P2P pacotes Interger Armazena a quantidade de pacotes Tabela 4.6: Dicionário de dados da tabela LogP2PLocal
59 CAPÍTULO 4. MODELAGEM Tabela hosts A tabela 4.7 armazena as informações referentes às máquinas conectadas à rede da instituição. Coluna Tipo (Tamanho) Descrição codigo Integer Armazena o código do host fqdn_sala Character varying (135) Armazena o fqdn do host cdrede Interger Armazena o código da rede cdtipohost Interger Armazena o código do tipo do host cdhosthospedeiro Interger Armazena o código do host hospedeiro vlip Interger Armazena o Ip do host status Interger Armazena o status do host statusanterior Interger Armazena o status anterior do host statussnmp Interger Armazena o status snmp cdsnmp Interger Armazena o código do snmp statusmonitoramento Interger Armazena o status do monitoramento statusalerta Interger Armazena o status de alerta parenthost Interger Chave estrangeira da tabela host cdsistema Interger Armazena o código do sistema operacional statusvarreduraportas Interger Armazena o status da varredura de portas
60 CAPÍTULO 4. MODELAGEM 53 tminicial Numeric Armazena o timestamp inicial do host tmatual Numeric Armazena o timestamp antual do host tmanterior Numeric Armazena o timestamp anterior do host cdcontato Interger Armazena o código do contato cdgrupocontato Numeric Armazena o código do grupo do contato cdsala Interger Armazena o id da sala descricao Character varying (135) Armazena a descrição do host cdgrupodehost Integer Armazena o código do grupo do host patrimonio Character varying (135) Armazena o patrimônio do host alias Character varying (135) Armazena o alias do host fqdn_novo Character varying (135) Armazena o novo fqdn do host Tabela 4.7: Dicionário de dados da tabela hosts
61 CAPÍTULO 4. MODELAGEM Tabela hosts_tipos A tabela 4.8 armazena as informações pertinentes aos tipos de hosts que podem estar conectados à rede. Coluna Tipo (Tamanho) Descrição codigo Integer Armazena o código do tipo do host nome Character varying Armazena o nome do host img Character (100) Armazena a imagem do host descricao Character varyng Armazena a descrição do host parent Integer Armazena se a máquina é um Parenthost Tabela 4.8: Dicionário de dados da tabela hosts_tipos Tabela salas A tabela 4.9 armazena as informações referentes às salas existentes nos blocos do campus do LNCC. Coluna Tipo (Tamanho) Descrição id_sala Integer Armazena o id da sala nome_sala Character varying Armazena o nome da sala id_coordenacao Integer Armazena o id da coordenação Tabela 4.9: Dicionário de dados da tabela salas
62 CAPÍTULO 4. MODELAGEM Tabela coordenacao A tabela 4.10 armazena as informações referentes as coordenações e serviços do LNCC. Coluna Tipo (Tamanho) Descrição id_coordenacao Integer Armazena o id da coordenação nome_coordenacao Character varying (50) Armazena o nome da coordencação Tabela 4.10: Dicionário de dados da tabela coordenacao Tabela redes A tabela 4.11 armazena todas as informações referentes a rede. Coluna Tipo (Tamanho) Descrição codigo Integer Armazena o codigo da rede ip Character varying Armazena o ip da rede mascara Character varying Armazena a mascara da rede cidr Character varying (3) Armazena o cidr da rede descricao Character varying (135) Armazena a descrição da rede status Integer Armazena o status da rede cdinstituicao Integer Armazena o código da instituição gateway Character varying (15) Armazena o gateway da rede dns Character varying (15) Armazena o dns da rede wins Character varying (135) Armazena o wins da rede cdtiporede Integer Armazena o codigo do tipo da rede cdcontato Integer Armazena o código do contato cdgrupocontato Integer Armazena o código do grupo de contato Tabela 4.11: Dicionário de dados da tabela redes
63 CAPÍTULO 4. MODELAGEM Tabela redes_tipo A tabela 4.12 armazena as informações sobre os tipos de rede existentes na instituição. Coluna Tipo (Tamanho) Descrição codigo Integer Armazena o codigo do tipo da rede nome Character varying (135) Armazena o nome da rede descricao Character varying (200) Armazena a descricao da rede Tabela 4.12: Dicionário de dados da tabela redes_tipo Tabela usuario A tabela 4.13 armazena os dados referentes aos usuários e suas autorizações de acesso ao front-end do protótipo do SGS:Log Coluna Tipo (Tamanho) Descrição id_usuario Integer Armazena o id do usuário nome Character varying Armazena o nome do usuário Character varying Armazena o do usuário id_coordenacao Interger Armazena o id da coordenação login Character (20) Armazena o login do usuário senha Character varying Armazena a senha do usuário status Integer Armazena o status do usuário nivel Character varying Armazena o nivel do usuário Tabela 4.13: Dicionário de dados da tabela usuario
64 CAPÍTULO 4. MODELAGEM Tabela systemevents A tabela 4.14 armazena as mensagens de logs. Coluna Tipo (Tamanho) Descrição id Integer Armazena o id do log customerid Bigint Armazena o id do cliente receivedat Timestamp Without Time Zone Armazena o horário do recebimento da mensagem devicereportedtime Timestamp Without Time Zone Armazena o tempo relatado pelo dispositivo facility Smallint Armazena o nível das facilitys priority Smallint Armazena o nível das prioritys fromhost Character varying(60) Armazena o host que gerou a mensagem message Text Armazena a mensagem recebida ntseverity Integer Armazena a severidade da mensagem importance Integer Armazena a importância da mensagem eventsource Character Varying(60) Armazena a origem do evento eventuser Character Varying(60) Armazena o evento do usuário eventcategory Integer Armazena o evento da categoria eventid Integer Armazena a identicação do evento eventbinarydata Text Armazena os dados binários do evento maxavailable Integer Armazena a mensagem máxima disponível
65 CAPÍTULO 4. MODELAGEM 58 currusage Integer Armazena a mensagem corrente minusage Integer Armazena o uso mínimo maxusage Integer Armazena o uso máximo infounitid Integer Armazena a identicação da unidade syslogtag Character varying(60) Armazena a tag do syslog eventlogtype Character varying(60) Armazena o tipo de log do evento genericlename Character varying Armazena o nome genérico do arquivo systemid Integer Armazena a identicação do sistema Tabela 4.14: Dicionário de dados da tabela systemevents Diagrama de Sequência Esta seção apresenta os Diagramas de Sequência do protótipo. A Figura 4.8, representa o diagrama de sequência relacionado ao processo de autenticação (login) dos usuários. A Figura 4.9, representa o diagrama de sequência dos vários cadastros que podem ser realizados através do front-end e a Figura 4.10 representa o processo de emissão dos relatórios disponíveis no protótipo
66 CAPÍTULO 4. MODELAGEM 59 Figura 4.8: Diagrama de Sequência - Login Figura 4.9: Diagrama de Sequência - Cadastro
67 CAPÍTULO 4. MODELAGEM 60 Figura 4.10: Diagrama de Sequência - Relatório No próximo capítulo serão apresentadas as ferramentas utilizadas no desenvolvimento do protótipo e o processo de implementação do mesmo, no qual foram envolvidas todas estas tecnologias.
68 Capítulo 5 Metodologias e Implementação do protótipo SGS:Log Neste capítulo são apresentadas as ferramentas utilizadas no desenvolvimento do protótipo SGS:Log e a implementação do mesmo. 5.1 Metodologias Nesta seção será apresentado a metodologias que foram utilizadas para o desenvolvimento do prótipo SGS:Log HTML O HTML que é uma abreviação de Hyper Text Markup Language. É uma linguagem criada para modernizar o desenvolvimento de aplicações e a apresentação de conteúdo do WWW. Essa tecnologia foi resultado da união dos padrões HyTime e SGML. HyTime é um padrão para a representação estruturada de hipermídia e conteúdo baseado em tempo. Já SGML é um padrão de formatação de texto [30]. Em 2004, o WHATWG iniciou o trabalho para o desenvolvimento do novo padrão do HTML, pois, em 1998, a W3C havia decidido congelar o HTML na sua versão 4.01 para 61
69 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 62 investir na linguagem XHTML. Em 2009, a W3C decidiu parar o estudo sobre o XHTML e se unir ao WHATWG para juntos promoverem o desenvolvimento do HTML5. A versão nal do HTML5 está prevista para o nal de Com a evolução desta linguagem pretende-se que seja eliminada a necessidade, em navegadores, da utilização de plugins pelas aplicações multimídia. [26] No desenvolvimento do protótipo, foi utilizada a versão 5 do HTML em todo o Front-end junto à linguagem PSP - Python Server Pages CSS O CSS, que signica Cascading Style Sheets é uma "folha de estilo"composta por camadas e utilizada para denir a apresentação das páginas da internet que adotam para o seu desenvolvimento as linguagens de marcação como XML, HTML e XHTML. O CSS dene como serão exibidos os elementos contidos no código de uma página, e sua maior vantagem, é separar o formato e o conteúdo do documento. Um dos principais avanços trazidos pelo CSS está na melhoria na apresentação de transições e efeitos para a criação de animação de vários tipos [38]. Esse estilo foi escolhido devido às suas inovações, e a versão utilizada no desenvolvimento do projeto foi o CSS Python Python é uma linguagem de programação de alto nível muito utilizada em Linux e em sistemas baseados em Unix por ser de fácil aprendizado. A sintaxe é organizada e suporta vários objetos.
70 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 63 Foi criada por Guido Van Rossum em 1991, onde o objetivo principal era a produtividade e a legibilidade. Essa linguagem foi escolhida pelo fato de ser composta por uma vasta biblioteca padrão, possibilitando a realização de várias tarefas, como por exemplo o acesso a banco de dados e a construção de interfaces grácas para visualização do usuário. No desenvolvimento do protótipo, a linguagem foi utilizada no desenvolvimento dos scripts para que pudessem coletar informações relacionadas ao ambiente de log, suas mensagens e seus hosts Mod_python O Mod_python é um módulo que é adicionado ao servidor Apache, o qual permite a integração do servidor Web com a linguagem Python. Mod_python é originado de um projeto chamado Httpdapy (1997). Por um longo tempo, o Httpdapy não foi chamado de mod_python, porque não era para ser especíco para o servidor apache. Inicialmente foi escrito para o servidor Netscape e sua concepção é uma combinação de extensibilidade, simplicidade e eciência. Sempre que for solicitado ao Apache o acesso à uma página escrita utilizando a linguagem Python, o servidor Web encaminha o pedido ao módulo que irá interpretar o conteúdo Python e retornará ao usuário uma página HTML [46]. A linguagem PSP, foi escolhida porque é rapidamente interpretada e possui um desenvolvimento ágil. O Mod_python está sendo utilizada no protótipo junto com as linguagens Python, CSS3 e Html5, realizando o desenvolvimento de todo Front-end.
71 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG JavaScript JavaScript é uma linguagem de programação baseada em scripts e padronizada pela ECMA - European Computer Manufacturers Association, que é uma empresa baseada em padronização de sistemas de informação. Foi desenvolvido por Brendan Eich da Netscape em 1995 como linguagem de script client-side. É uma liguagem dinâmica, orientada a objetos e criada com sintaxe similar a linguagem C. Apesar de conter Java no nome, é distinta da linguagem Java e apresenta recursos não disponibilizados em Java ou C++. Tem a funcionalidade de ser executada no interior de programas de outras linguagens. Essa linguagem foi escolhida para que as páginas pudessem ser acessadas e validadas de acordo com as solicitações enviadas pelas informações dos usuários [1] Highcharts A Highcharts é uma biblioteca utilizada para geração de grácos dinâmicos e interativos utilizando somente a linguagem JavaScript. Essa biblioteca suporta vários tipos de grácos como linha, área, barras, torta entre outros. Para visualização dos resultados das coletas, utilizamos os grácos em barra, em linha e em formato de torta. Funciona em todos os navegadores, incluindo Iphone e Internet Explorer. É uma biblioteca open-source, baseada em tecnologias cross-browser e não necessita de plugins [6]. O Highcharts foi utilizado por ser de fácil manipulação e por aceitar valores dinamicamente para geração de todos os grácos do protótipo.
72 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG jquery A jquery é uma biblioteca JavaScript criada em 2006 por John Resig. Pode ser utilizada e modicada de todas as formas cabíveis no desenvolvimento de qualquer protótipo. Ela consegue abstrair do desenvolvedor a programação exigida nos recursos de interatividade nos front-ends. Com essa biblioteca, o programador pode criar rapidamente interações ajax, animações, manipulação de eventos e manipulações da árvore DOM, do HTML. É aderente aos padrões Web da W3C, é independente do navegador, permite fazer aplicações não obstrusivos e suporta os seletores da CSS3 [9]. O jquery foi utilizado para a criação de eventos, como hora e data para facilitar as consultas no protótipo Postgres Postgres é um gerenciador de banco de dados desenvolvido como projeto de software livre. É o resultado de uma ampla evolução que se iniciou com o projeto Ingres, desenvolvido na Universidade de Berckey, na Califórnia. Um projeto pós-ingres poderia resolver problemas com o moledo de banco de dados relacional, onde a principal incapacidade era compreender os "tipos"de combinações de dados simples. Postgres foi o projeto resultante orientado a introduzir a menor quantidade possível de funcionalidades para completar o suporte a "tipos". Com essa inovação, o banco de dados compreendia as relações e podia obter informações de tabelas relacionadas usando regras. Postgres foi escolhido por ser um SGBD de alto nível e por possuir funcionalidades que seriam imprescindíveis no desenvolvimento do protótipo.
73 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG Implementação do protótipo do SGS:Log O SGS:Log é o protótipo de um software para gerência e o monitoramento de logs, relacionado principalmente com o processo de registro dos eventos da redes e de computadores, como por exemplos as informações das conexões cabeadas, redes wireless, acessos VPN, entre outros. Nesta seção serão apresentadas as ferramentas utilizadas para o desenvolvimento do projeto. Como o protótipo foi desenvolvido para ser executado em ambientes Linux, as congurações a seguir foram baseadas nesse sistema, mais especicamente nas distribuições Debian e Ubuntu Instalação e conguração do servidor de NTP Antes de iniciar todo processo de instalação e conguração dos servidores e clientes de Log, houve a necessidade da instalação de um servidor de NTP, que passa a fornecer a marcação de hora para todos os hosts da rede. Com o auxílio deste serviço, todas as máquinas poderão ter seus relógios sincronizados, o que é fundamental para o processo de registro dos logs e futuras auditorias nos sistemas Ambiente de Log Esta seção trata da instalação e conguração do ambiente de log que foi utilizado como base para a implementação deste protótipo. Esta seção representa os passos executados em uma ambiente real e que está em produção Instalação e conguração do Daemon do Rsyslog Em todas as máquinas baseadas no sistema operacional Linux e cujas mensagens de log estão sendo gerenciadas, foi instalado o Daemon do rsyslog, que é a versão mais recente do syslog. Essa implementação é mais segura e conável, e ainda permite que as mensagens
74 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 67 sejam armazenadas em vários formatos incluíndo diversos sistemas de gerência de bancos de dados, como por exemplo o Rsyslog. Para realizar a instalação do Rsyslog, nas distribuições Debian e Ubuntu, deve-se seguir os passos descritos abaixo. Primeiro, utilize o comando abaixo para vericar se o rsyslog está instalado: aptitude search rsyslog Caso o aplicativo não esteja instalado, realize o próximo procedimento: sudo aptitude install rsyslog Para realizar a ativação e permitir o envio das mensagens de log para um servidor remoto, edite o arquivo "/etc/default/rsyslog". Verique se a linha abaixo este presente no arquivo de conguração, caso não esteja adicione-a RSYSLOGD="-r" Salve as congurações e feche o arquivo. Para que as congurações sejam habilitadas, o Daemon do Rsyslog deve ser reiniciado, para isto, utilize o comando abaixo: invoke-rc.d rsyslog restart Depois de instalar o daemon, deve-se determinar qual será a função do host, ou ele será um servidor de log ou será uma das máquinas que publicarão suas mensagens de log em um dos servidores.
75 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG Conguração do Servidor Centralizado Depois da instalação básica, deve-se congurar, nos servidores de log, o Daemon do Rsyslog, de modo que ele possa receber as mensagens que serão encaminhadas a partir das demais máquinas. Dependendo do ambiente pode haver mais do que um servidor de Log. No caso do ambiente no qual o SGS:Log está sendo desenvolvido, há vários servidores, e cada um recebendo os logs de um grupo de hosts, que foram agrupados segundo sua utilização ou função dentro do ambiente como um todo. Para que os logs gerados pelos hosts rede sejam recebidos pelo servidor servidor centralizado, é necessário que após a instalação e conguração básica do rsyslog, o servidor seja congurado para aceitar conexões a patir da porta 514/TCP e em seguida encaminhá-las ao daemon do rsyslog. Para habilitar o recebimento dos logs, deve-se editar o arquivo "/etc/rsyslog.conf"e vericar se a porta 514 está habilitada. Caso não esteja, descomente as seguintes linhas: $ ModLoad imudp \$ UDPServerRun 514 Em seguida salve o arquivo e reinicie o daemon do rsyslog, para isto utilize o comando abaixo: invoke-rc.d rsyslog restart Conguração dos Clientes Com os servidores centralizados congurados, os próximos a serem congurados, são as estações que irão enviar as mensagens de log aos servidores, nestes hosts o primeiro passo é vericar se o rsyslog está instalado. Caso não esteja, realize o procedimento inicial descrito
76 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 69 anteriormente. Para que os clientes publiquem seus logs no servidor centralizado, serão necessárias algumas congurações. Inclua no arquivo "/etc/rsyslog.conf"as seguintes linhas: *.* Onde: o endereço IP e a porta do servidor que receberá as mensagens de log. Em seguida salve o arquivo e reinicie o daemon do rsyslog, para isto utilize o comando abaixo: invoke-rc.d rsyslog restart Se o daemon tiver sido carregado corretamente, as mensagens já devem estar sendo direcionadas para a máquina remota. Deve-se ressaltar que o envio das mensagens de log para um servidor remoto não evita que as mesmas continuem sendo armazenadas localmente. Ou seja, todas as mensagens serão duplicadas, cando uma cópia armazenada localmente e outra no banco de dados do servidor centralizado Deploy do Protótipo Esta seção descreve os procedimentos necessários para realizar o deploy do protótipo e de seus três componentes básicos Deploy da Camada de Persistência No servidor que hospedará a camada de persistência do projeto, ou seja o servidor que hospedará o gerenciador de banco de dados, é necessário a instalação do Postgresql e de alguns outros pacotes que permitem a administração do banco de dados através de uma
77 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 70 interface web. Para realizar a instalação destes pacotes deve-se executar os comandos abaixo: sudo apt-get update sudo apt-get install -f sudo aptitude install postgresql Após estar devidamente instalado, necessitamos congurá-lo para que o acesso seja permitido. Digite o comando abaixo, am de que você possa permitir o acesso ao banco de dados. Caso necessite de uma senha, será a mesma utilizada na instalação do pacote. su postgres Acesse o módulo psql, para que seja criado um usuário. psql Para criar um usuário, digite o comando a seguir. CREATE USER <usuario> SUPERUSER password 'senha'; Para que o Postgres seja visualizado no navegador, necessitamos alterar uma linha dentro do arquivo "/etc/postgresql/9.1/main/postgresql.conf ": Procure por esta linha: #listen_addresses = 'localhost' Altere para que que dessa forma: listen_addresses = '*' Finalizando essas congurações, seu banco de dados estará pronto para que sejam criados os bancos e as tabelas necessárias para o projeto.
78 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG Deploy do Front-End Esta seção descreve os processos de instalação e conguração necessários ao funcionamento do Front-end do protótipo do SGS:Log. Dentre os pacotes a serem instalados e congurados destacam-se: Apache2 - Servidor web utilizado responsável por servir as páginas aos usuários. libapache2-mod-python - Módulo do apache2 utilizado para gerar as páginas web a partir de códigos baseados em PSP (Python Server Pages) python - É um módulo que consiste de código-fonte contido em um arquivo denominado com a extensão.py. python-pygresql Módulo do python utilização para fazer conexão com uma banco de dados PostgreSQ L. python-bcrypt - Módulo do python utilizado na geração das senhas criptografadas. subversion - Sistema de controle de versão responsável por versionar o projeto. Para instalar os pacotes deve-se executar os comandos abaixo: sudo apt-get update sudo apt-get install -f sudo apt-get install python python-pygresql apache2 libapache2-mod-python Com os pacote básicos instalados deve-se preparar o local onde o protótipo será sincronizado com o repositório SVN. E em seguida obter os arquivos a partir do repositório. Para isto utilize os comandos abaixo: mkdir -p /opt/projetosgs cd /opt/projetosgs svn checkout svn://svn.sre.lncc.br/sgslog
79 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 72 Uma vez realizada a sincronização com o repositório e todos os arquivos necessários para o funcionamento do protótipo já estão disponíveis, deve-se iniciar a conguração do Apache. Este processo consiste na construção de um arquivo contendo as linhas abaixo: Alias /sgslog "/opt/projetosgs/sgslog/sgsweb" <Directory "/opt/projetosgs/sgslog/sgsweb"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order deny,allow Deny from all Allow from / AddHandler mod_python.psp PythonHandler mod_python.psp PythonDebug On PythonPath "sys.path+['/opt/projetosgs/sgslog/sgsweb']" DirectoryIndex index.html index.psp index.htm index.php #AuthName "SGS:Log - Controle de Acesso" #AuthType Basic AuthUserFile /opt/projetosgs/sgslog/config/htpasswd. sgslog.users #require valid-user
80 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 73 </Directory> Como este arquivo já está disponível no repositório, para ativar as congurações basta executar os comandos abaixo: cd /etc/apache2/conf.d/ ln -s /opt/projetosgs/sgslog/config/sgslog-apache-www.sgs.lncc.br.conf Finalmente, o Apache já está devidamente congurado, mas as congurações ainda não estão ativas. Para ativá-las, basta reiniciar o daemon do servidor web com o comando abaixo: service apache2 restart A partir deste ponto o Front-End já pode ser acessado de qualquer navegador, basta apontar para a pasta sgslog do servidor web. Por exemplo, para acessar o protótipo que está instalado na máquina deploy.sgs.lncc.br, pode-se utilizar a url abaixo: Deploy do Back-End Para que o deploy do back-end seja nalizado, alguns pacotes são necessários para o perfeito funcionamento da ferramenta. São eles: python - Linguagem de programação utilizada pelo back-end. python-pygresql - Biblioteca utilizada para criar a conexão com o Postgres. python-psycopg2 - Biblioteca para a conexão do P2P com o Postgres. subversion - Biblioteca para controlar o versionamento do protótipo.
81 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 74 rsyslog - Pacote predenido para o gerenciamento de log Python Como o protótipo foi baseado em um sistema Linux, a biblioteca python já vem instalada e congurada. Para saber mais detalhes sobre a linguagem, vide capítulo 7, subitem Python-pygresql A biblioteca python-pygresql faz a interface entre os scripts em python e o banco de dados. Ele adiciona ao PostgreSQL uma biblioteca de consulta ao banco de dados pela linguagem python. Para a instalação da biblioteca python-pygresql, utilize o comando abaixo. sudo aptitude install python-pygresql Python-psycopg2 A biblioteca python-psycopg2 vincula o banco de dados com a linguagem python. Sem a instalação desse pacote, o protótipo não consegue acessar o banco de dados. Para a instalação da biblioteca python-psycopg2, utilize o comando abaixo. sudo aptitude install python-psycopg Subversion É um sistema de controle de versão open-source, que tem como função gerenciar arquivos e diretórios, gravando cada modicação em um repositório, permitindo que o usuário recupere, analise e compare diferentes versões dos seus arquivos. Para a instalação da biblioteca subversion, utilize o comando abaixo. [23]
82 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 75 sudo aptitude install subversion Rsyslog Para realizar a instalação do rsyslog e sua conguração, vide Capítulo 3.
83 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 76 Durante o desenvolvimento do projeto, vericou-se a necessidade da utilização de outras ferramentas que pudessem auxiliar na criação do protótipo. A seguir, cada ferramenta será detalhada, assim como o motivo pela qual ela foi escolhida Dia É uma ferramenta utilizada para o desenvolvimento de diagramas como UML, diagramas de uxos e diagramas de rede. Foi escolhido por ser uma ferramenta capaz de exportar os diagramas em vários formatos e por ser de fácil manipulação. A gura 5.1 exibe uma tela do aplicativo. Figura 5.1: Tela da ferramenta "Dia" Aptana É uma IDE de fonte aberta para desenvolvimento integrado para aplicações WEB. Foi criado baseado no Software Eclipse, e suporta HTML5, CSS3, JavaScript, Ruby, Rails, PHP e Python. É distribuído em multiplataforma e é possível integrá-lo com o Eclipse
84 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 77 através de um plugin. [4] Aptana foi escolhido para o desenvolvimento do protótipo por ser open-source e por ter suporte ao SVN que possibilita a sincronização do projeto agilizando o desenvolvimento. A gura 5.2 exibe uma tela do aplicativo. Figura 5.2: Tela da ferramenta "Aptana" Komodo Komodo também é um IDE para o desenvolvimento de aplicações web que suporta várias linguagens como HTML5, CSS3, JavaScript, Ruby, Rails, PHP, Perl e Python. [2] Ela foi escolhida por conter bibliotecas inclusas e ser de fácil conguração, facilitando o desenvolvimento do projeto.
85 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 78 A gura 5.3 exibe uma tela do aplicativo. Figura 5.3: Tela da ferramenta "Komodo"
86 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG Dropbox Dropbox é um serviço para armazenamento e compartilhamento de arquivos. Ele utiliza o conceito de Computação nas Nuvens (cloud computing), onde os dados, arquivos e aplicações são hospedadas em um servidor físico ou virtual. Pode ser acessado por qualquer dispositivo compatível [16]. O Dropbox foi escolhido por ser de fácil instalação e manuseamento, facilitando assim, o acesso compartilhado aos scripts. A gura 5.4 exibe uma tela do aplicativo.
87 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 80 Figura 5.4: Tela da ferramenta "Dropbox" PhpPgAdmin É uma ferramenta para a administração do banco de dados Postgresql via web. Permite uma apresentação prática das principais tarefas de administração e conguração dos banco de dados. Foi escolhida por conter funcionalidades pertinentes ao projeto e por ser um gerenciador de banco de dados de alto nível. A gura 5.5 exibe um tela da aplicação.
88 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 81 Figura 5.5: Tela da ferramenta "PhpPgAdmin" PgAdmin 3 É uma interface gráca do PostgreSQL, através da qual podemos criar os mais diversos tipos de objetos no banco de dados, como tablespaces, banco de dados, esquemas, tabelas e visões. Foi escolhido para facilitar a inclusão de novas tabelas que foram surgindo no decorrer do desenvolvimento do protótipo. A gura 5.6 exibe uma tela do aplicativo.
89 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 82 Figura 5.6: Tela da ferramenta "PgAdmin 3" DbVisualizer É uma ferramenta de banco de dados universal para desenvolvedores e administradores de banco de dados. Pode ser usado em todos os principais sistemas operacionais e acessa uma grande variedade de banco de dados [15]. A interface do aplicativo facilita a utilização do projeto, já que todas as opções estão em uma única barra de tarefas. Essa ferramenta foi escolhida para facilitar a visualização e criação dos diagramas do protótipo. A gura 5.7 exibe uma tela do aplicativo.
90 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG Astah Figura 5.7: Tela da ferramenta "DbVisualizer" Trata-se de um software para as modelagens UML. Com ele, foi possível a criação, edição e manipulação do banco de dados do protótipo. Possui uma interface amigável, contendo abas para facilitar a administração do banco. Ele pode exportar as guras da modelagem do projeto. Foi escolhido por ser de fácil manuseamento e entendimento do seu propósito. A gura 5.8 exibe uma tela do aplicativo.
91 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 84 Figura 5.8: Tela da ferramenta "Astah" Web2py Foi uma linguagem criada em 2007 por Massimo Di Pierro. É um framework de aplicações web de código aberto escrito em Python. Foi projetado para reduzir as tarefas no desenvolvimento, como por exemplo, a criação de formulários desde o início. Inicialmente foi concebido como uma ferramenta de ensino, com ênfase na facilidade de uso e implantação. Foi inspirado em Ruby on Rails e alguma coisa em Django. Segue um modelo MVC, facilitando a estrutura e o desenvolvimento do projeto. [39] É livre e gratuito, e seu principal objetivo é proporcionar agilidade no desenvolvimento das aplicações, baseadas em banco de dados. Essa linguagem foi utilizada nos script de coletas do Rsyslog. Por ser uma liguagem relativamente nova, ela foi utilizada somente nos scripts de coletas do Rsyslog, pois facilitaria as buscas e os relatórios. A gura 5.9 exibe uma tela do aplicativo.
92 CAPÍTULO 5. METODOLOGIAS E IMPLEMENTAÇÃO DO PROTÓTIPO SGS:LOG 85 Figura 5.9: Tela da ferramenta "Web2py" [39] O próximo capítulo irá abordar todo o protótipo SGS:Log, assim como suas funcionalidades e suas 3 camadas.
93 Capítulo 6 O Protótipo SGS:Log Neste capítulo será apresentado o protótipo da ferramenta de gerência de log e suas principais funcionalidades e características. 6.1 O objetivo O principal objetivo do desenvolvimento do projeto SGS:Log, é a construção de uma ferramenta especíca para análise e monitoramento das mensagens de Log, de forma que seja possível acompanhar o funcionamento dos hosts de uma rede, sejam estes hosts estações de trabalho, servidores ou ativos de rede. Mais precisamente, o objetivo é a implementação de uma solução que atenda as necessidades do Laboratório Nacional de Computação Cientíca (LNCC). Antes da implementação do protótipo, foram realizados alguns estudos sobre ferramentas open-source relacionadas ao tema, de modo que pudessem ser conguradas e implantadas de acordo as necessidades do laboratório quanto a visualização dos logs, porém, de todas as ferramentas analisadas, nenhuma atendia às necessidades do LNCC. Logo, surgiu a motivação para o desenvolvimento de um novo sistema, e a criação do módulo SGS:Log. 86
94 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 87 O módulo SGS:Log será responsável por monitorar os logs gerados pelos vários hosts da rede do LNCC e futuramente poderá ser utilizado por outros órgãos. 6.2 Principais funcionalidades O módulo SGS:Log é responsável por coletar, armazenar e analisar várias informações relacionadas aos logs gerados pelos hosts e pelos seus daemons. As principais funcionalidades contidas no protótipo SGS:Log são: Monitoramento das conexões P2P, com os relatórios diários, mensais ou por host. Monitorar as conexões das redes Wireless com relatórios diários ou mensais. Monitorar certicados VPN. Monitorar as mensagens registradas em um dos servidores de log centralizado Monitoramento das conexões P2P As redes ponto-a-ponto tem sido cada vez mais utilizadas para a troca de dados. Da mesma forma que podem ser utilizadas de forma benéca, podem ser utilizadas também para ns ilegais. O monitoramento dos protocolos P2P visa identicar os hosts que estão utilizando esse tipo de aplicação. O protótipo tem por nalidade analisar as informações sobre os pacotes que passaram pelas bridges. Estas controlam os perímetros da rede da organização. As bridges enviam as informações sobre os pacotes P2P para um dos servidores de log centralizado. As coletas foram separadas de forma a facilitar a busca, podendo ser visualizada com a utilização de alguns ltros especícos. Os relatórios são apresentados em forma gráca, facilitando a visualização. Uma tabela exibe os primeiros resultados, onde pode ser vericado quem é o responsável pela máquina.
95 CAPÍTULO 6. O PROTÓTIPO SGS:LOG Monitoramento da rede Wireless O Laboratório Nacional de Computação Cientíca possui uma série de Ap's instalados que não possuem nenhum tipo de administração interna, poluindo o canal de dados utilizado pelos equipamentos ociais. Depois de uma análise detalhada, foi sugerido que fosse realizada uma varredura dos equipamentos, para acompanhar a utilização desses equipamentos no LNCC. Essa coleta gera um arquivo e logo após é inserida em um banco de dados. O monitoramento da rede Wireless verica a qualidade do sinal originado pelos equipamentos alocados nas dependências do laboratório. Como esses equipamentos são monitorados, precisamos manter um cadastro de usuários, para que o controle seja realizado da forma correta. Esses cadastros possuem validade de acesso pelo período de 1 ano, logo, monitoramos a validade dos cadastros dos usuários Monitoramento dos certicados VPN O LNCC possui a Rede Virtual Privada para realizar a interconexão da rede por um meio público, oferecendo aos seus colaboradores condencialidade e intengridade no tranporte das informações. Os usuários poderão estar conectados a rede interna, sem que estejam sicamente no laboratório. O certicado utiliza um par de chaves para realizar o processo de autenticação e criptograa do canal de comunicação. O monitoramento dos certicados VPN verica a validade do certicados dos usuários. Estes certicados possuem validade de acesso de 1 ano, logo surgiu a necessidade do monitoramento dos mesmo, para que, se houver a necessidade, sejam renovadas antes do prazo de expiração, evitando que o acesso seja negado.
96 CAPÍTULO 6. O PROTÓTIPO SGS:LOG Monitoramento dos Servidores O monitoramento dos servidores armazenará todos os logs gerados pelos ativos de rede e servidores da instituição. Esses logs estarão armazenando informações como por exemplo, o acesso root as máquinas, tanto como login, tanto como logo, o nível de severidade das mensagens e o horário da mensagens. Com a visualização desses logs, pode vericar, no caso de uma falha no sistema, quem foi a última pessoa logada no mesmo. Podendo vericar o que foi realizado, utilizando os ltros especicados. 6.3 As três camadas do Módulo O protótipo SGS:Log é baseado em três camadas: (i) o Front-end, (ii) a Camada de Persistência de Dados e (iii) o Back-end, que serão detalhadas a seguir O Front-end O Front-end, é a camada do sistema com a qual os usuários poderão interagir diretamente. Esta camada é a interface entre o usuário e a Camada de Persistência de Dados do projeto SGS:Log. Sua nalidade é apresentar as informações de forma clara e objetiva, fazendo com que o usuário interaja ecientemente com o protótipo da ferramenta. Dentre as funcionalidades oferecidas nesta camada, destaca-se o processo de análise dos dados armazenados na Camada de Persistência de Dados, onde será possível expor aos administradores as informações relacionadas sobre as conexões P2P, redes Wireless, certicados VPN e os logs armazenados pelo servidor centralizado, com apresentação de relatórios e geração de grácos. Para ter acesso as funcionalidades do Front-end, o usuário deverá estar, por padrão, logado no sistema e com a devida autorização para acesso ao módulo. Caso o usuário
97 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 90 não esteja autenticado, ele só poderá visualizar uma breve descrição do protótipo, como apresentado na gura 6.1. Figura 6.1: Tela Inicial - Informações do Protótipo Tendo como base a política de segurança da instituição e para preservar a segurança dos dados e do sistema, deniu-se que somente os usuários do perl administrador poderão cadastrar novos usuários. A gura 6.2 exibe a tela de login do usuário previamente cadastrado. Figura 6.2: Tela Inicial - Login
98 CAPÍTULO 6. O PROTÓTIPO SGS:LOG Servidores A gura 5.3 representa o que poderá ser visualizado nos submenus dos Servidores. Esse item apresentará os logs gerados pelos ativos de redes e dos servidores alocados nas dependências do LNCC. Esse mesmo item foi subdividido por hosts, Logs Recentes e Filtro. No item Toad01 serão exibidos os logs dos ativos de rede CISCO. No item Toad02 serão exibidos os logs das bridges. No item Toad03 serão exibidos os logs dos servidores da equipe SSI. No item Toad04 serão exibidos os logs dos servidores do SRE. No item Toad05 serão exibidos os logs dos servidores Cisco Asa. No item Toad06 serão exibidos os logs dos ativos de rede da Enterasys. A gura 6.3 está exibindo esses itens com seus respectivos submenus. Figura 6.3: Tela Inicial - Servidores A gura 6.4 exibe uma tela que possui um formulário onde pode vericar os logs dos servidores, realizando a busca pelo host, data, Facility e Priority.
99 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 92 Figura 6.4: Log dos servidores A gura 6.5 exibe uma tela com a idencação de cada host, onde é exibido o host, timestamp, fqdn, endereço ip e a descrição dos servidores. Na tabela apresentada, o usuário poderá visualizar, editar e excluir os dados dos hosts. Figura 6.5: Identicação dos hosts
100 CAPÍTULO 6. O PROTÓTIPO SGS:LOG P2P De acordo com a gura 6.6 o usuário poderá selecionar os relatórios relacionados aos pacotes P2P que estão passando pela rede. Esses relatórios foram separados por (i) relatório diário, (ii) relatório mensal geral, (iii) relatório mensal diário, (iv) relatório por host e (v)relatório por rede. A gura 6.6 exibe os itens pertencentes às coletas P2P. Figura 6.6: Tela Inicial - P2P Relatório Diário A gura 6.7 exibe uma tela que possui um formulário onde pode vericar a quantidade de hosts que apresentaram uxo de pacotes utilizando o protocolo P2P, realizando uma busca por data. Na tabela apresentada, o usuário poderá visualizar a informação do responsável pelo hosts.
101 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 94 Figura 6.7: Tela SGS:Log:P2P - Resumo Diário A gura 6.8 exibe uma tela com os dados do host.
102 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 95 Figura 6.8: Tela SGS:Log:P2P - Dados Host Relatório Mensal Geral A gura 6.9 exibe uma tela com uma busca mensal, onde pode analisar o host que apresentou maior uxo P2P no mês solicitado.
103 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 96 Figura 6.9: Tela SGS:Log:P2P - Relatório Mensal Geral Relatório Mensal Diário A gura 6.10 exibe uma tela com uma busca realizada por mês, porém separando-as por dias, acusando os hosts que apresentaram uxo do protocolo P2P diariamente.
104 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 97 Figura 6.10: Tela SGS:Log:P2P - Relatório Mensal Diário
105 CAPÍTULO 6. O PROTÓTIPO SGS:LOG Relatório por hosts A gura 6.11 exibe uma tela com uma coleta realizada utilizando um ltro por host especíco. De acordo com o protótipo, pode ser determinado um intervalo entre datas. Figura 6.11: Tela SGS:Log:P2P - Relatório por Hosts
106 CAPÍTULO 6. O PROTÓTIPO SGS:LOG Relatório por rede O item Relatório por Rede foi dividido em subitens para facilitar a visualização. A tela exibida na gura 6.12 facilita a visualização do resultado das coletas que foram originadas por todas as redes do laboratório que utilizaram o protocolo P2P. Figura 6.12: Tela SGS:Log:P2P - Relatório por Rede - Diário
107 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 100 A gura 6.13 exibe uma tela que permite que seja selecionado um intervalo entre datas e a rede em questão. O resultado será apresentado com um gráco, apresentando os valores diários. Figura 6.13: Tela SGS:Log:P2P - Relatório por Rede - Intervalo de dias A gura 6.14 exibe uma tela com o resultado da coleta utilizando como base todas as redes do laboratório.
108 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 101 Figura 6.14: Tela SGS:Log:P2P - Relatório por Rede - Todas - Diário A gura 6.15 exibe uma tela com o resultado da coleta utilizando um intervalo de datas tendo como base todas as redes do laboratório.
109 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 102 Figura 6.15: Tela SGS:Log:P2P - Relatório por Rede - Todas - Intervalo Wireless De acordo com a gura 6.16 o usuário poderá selecionar os relatórios relacionados a rede Wireless e os usuários cadastrados no sistema. Esse relatórios foram separados por (i) relatório dirário e (ii) relatório por mês.
110 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 103 Figura 6.16: Tela Inicial Wireless A gura 6.17 exibe uma tela onde pode realizar uma busca utilizando como ltro uma data especíca, o canal, o local e o nome da rede sem o. Essa coleta verica as redes wireless que estão conectados no canal dos equipamentos ociais. Figura 6.17: SGS:Log:Wireless - Relatório Diário
111 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 104 A gura 6.18 exibe uma continuação do relatório relacionados aos acessos à rede sem o. Com esse gráco pode ser visualizado qual bloco que mais possui equipamentos não ociais. Figura 6.18: SGS:Log:Wireless - Relatório Diário - Cont.
112 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 105 A gura 6.19 exibe uma tela onde poderá realizar uma busca utilizando como ltro o mês e o ano. Essa coleta verica as redes wireless que estão conectados no canal dos equipamentos ociais. Figura 6.19: SGS:Log:Wireless - Relatório Mensal
113 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 106 A gura 6.20 exibe uma continuação do relatório relacionados aos acessos à rede sem o. Com esse gráco pode ser visualizado qual bloco que mais possui equipamentos não ociais. Figura 6.20: SGS:Log:Wireless - Relatório Mensal - Cont.
114 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 107 A gura 6.21 exibe uma tabela com os usuários cadastrados no sistema. Com esse ltro, pode ser vericado a validade dos cadastros dos usuários. Figura 6.21: SGS:Log:Wireless - Dados dos Usuários
115 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 108 A gura 6.22 exibe a tela de cadastro para que os usuários tenham acesso à rede wireless. Figura 6.22: SGS:Log:Wireless - Cadastro dos Usuários VPN O item ao qual se refere a gura 6.23 mostra a opção que poderá ser selecionada para a visualização do relatório dos usuários assim como a validade dos certicados. Figura 6.23: Tela Inicial - VPN A gura 6.24 está exibindo uma tabela com as informações dos usuários.
116 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 109 Figura 6.24: Sgs:Log: VPN A gura 6.25 está exibindo a tela onde as informações do certicado VPN poderão ser editadas. Figura 6.25: Sgs:Log: VPN - Dados sobre os certicados A gura 6.26 está exibindo a tela onde o certicado VPN poderá ser excluído.
117 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 110 Figura 6.26: Sgs:Log: VPN - Dados sobre os certicados A Camada de Persistência A Camada de Persistência de Dados é responsável por manter e gerenciar todas as informações necessárias para o funcionamento do protótipo, seu objetivo é gerenciar o acesso, manipular e organizar dos dados. No projeto SGS:Log, a Camada de Persistência de Dados é representada por um banco de dados armazenado e gerenciado pelo PortgreSQL. Este banco será utilizado para o gerenciamento de todos os dados coletados, e somente os administradores poderão ter acesso direto os dados coletados e armazenados. As congurações e estruturas do banco de dados utilizados pelo protótipo serão apresentadas e descritas em detalhes no Capítulo 8, que trata sobre a implementação do protótipo. O banco de dados, suas tabelas e seus campos são descritos no Capítulo 6, onde detalhamos a modelagem do protótipo SGS:Log. Como mostra a gura 6.27, há um exemplo da estrutura de uma tabela gerenciada pela Camada de Persistência dos Dados.
118 CAPÍTULO 6. O PROTÓTIPO SGS:LOG O Back-end Figura 6.27: Camada de Persistência - Postgres A camada do Back-end é composta por uma série de scripts responsáveis pelas coletas dos dados dos certicados VPN, dos logs relacionados à rede sem o, da análise dos logs gerados pelas bridges de segurança e a inserção das informações referentes as conexões P2P no banco de dados do projeto. Nessa camada, estão todos os códigos-fonte que fornecem a visualização no front-end e às buscas na Camada de Persistência.
119 CAPÍTULO 6. O PROTÓTIPO SGS:LOG 112 Em linhas gerais a principal função desta camada é recolher as informações e tratá-las de forma que sejam ltradas e armazenadas na Camada de Persistência de Dados. As principais linguagens utilizadas nessa camada no desenvolvimentos dos scripts foram o Python, o PSP e o ShellScript, e foram escolhidas por serem linguagens de alto nível. A gura 6.28 exibe um pequeno trecho do código utilizado no desenvolvimento do projeto.