HORUS: Sistema de Monitoramento de Eventos para Laboratórios de Informática

Transcrição

1 HORUS: Sistema de Monitoramento de Eventos para Laboratórios de Informática Trabalho de conclusão de curso apresentado ao Curso de Graduação em Tecnologia em Informática como requisito parcial à obtenção do grau de Tecnólogo em Informática. CURITIBA 2007

2 DARTANGHAN MICHEL VANI TOBIAS PAVOVSKI DE BRITO HORUS: Sistema de Monitoramento de Eventos para Laboratórios de Informática Trabalho de conclusão de curso apresentado ao Curso de Graduação em Tecnologia em Informática como requisito parcial à obtenção do grau de Tecnólogo em Informática. Orientadora Professora MSc. Ana Cristina Barreiras Kochem Vendramin Co-Orientador Professor Carlos Kazuhiko Hara CURITIBA 2007

3 HORUS: Sistema de Monitoramento de Eventos para Laboratórios de Informática Trabalho de conclusão de curso apresentado ao Curso de Graduação em Tecnologia em Informática como requisito parcial à obtenção do grau de Tecnólogo em Informática. Data aprovação: / / Banca examinadora: Profª. MSc. Ana Cristina Barreiras Kochem Vendramin (Orientadora) Universidade Tecnológica Federal do Paraná Prof. Carlos Kazuhiko Hara (Co-orientador) Universidade Tecnológica Federal do Paraná Prof. Milton Borsato Universidade Tecnológica Federal do Paraná Profª. Dra. Gilda Maria Souza Friedlaender Universidade Tecnológica Federal do Paraná CURITIBA 2007

4 AGRADECIMENTOS Agradecemos a conclusão deste trabalho aos nossos professores e colegas, que nos acompanharam e ensinaram durante o curso, especialmente à Professora Ana Cristina Barreiras Kochem Vendramin, professor Milton Borsato, e aos colegas Franciele da Cunha, Julio César Nardelli Borges e Leandro Piva, sem os quais não teríamos o mesmo sucesso na conclusão do curso e formação profissional.

5 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS ORGANIZAÇÃO DO DOCUMENTO SOFTWARES UTILIZADOS J2SE DEVELOPMENT KIT (JDK) ECLIPSE IDE NETBEANS IDE APACHE TOMCAT ORACLE XE ORACLE SQL DEVELOPER CVS BSCW JUDE COMMUNITY UML MODELING TOOL DB DESIGNER JAKARTA COMMONS PROJETO E IMPLEMENTAÇÂO CARACTERÍSTICAS DO SISTEMA HORUS SERVER Client Interface Sistema de Controle de Autenticações SQUID Parser Sistema de Cadastro de Processos Banco de Dados Sistema Horus Web Níveis de Acesso dos Administradores Monitoramento de Acessos a Sites Processos e Arquivos Bloqueio de Usuários Visualização de Logins Duplicados Cadastro de Máquinas e Usuários HORUS CLIENT HORUS-UPDATE HORUS-SYSTEM Comunicação Interna Armazenando Eventos Criando um Dispositivo de Coleta Child Process Process Manager Connection Adapter Pacote de Dispositivo (JARS) APLICABILIDADE RESULTADOS RESULTADOS OBTIDOS RESULTADOS DE DESEMPENHO Processamento Consumo de Memória CONCLUSÕES E TRABALHOS FUTUROS REFERÊNCIAS... 50

6 LISTA DE FIGURAS Figura 1 Diagrama de Casos de Uso do Sistema Horus Figura 2 Sistema Horus Server e estações Horus Client Figura 3 Sistema Horus Server e estações Horus Client Figura 4 Exemplo de log do Squid Web Proxy access.log Figura 5 Modelo do Banco de Dados do sistema Horus Figura 6 Tela de autenticação do administrador Figura 7 Menu de opções do sistema Web Figura 8 Diagrama de Classes do Sistema Web Figura 9 Tela de busca de sites por usuário Figura 10 Tela de resultados de sites mais acessados Figura 11 Tela de detalhes de processo executado Figura 12 Tela de logins duplicados Figura 13 Diagrama de Classes do sistema de coleta de dados e comunicação.. 36 Figura 14 Casos de Uso do Horus-Update Figura 15 Casos de Uso do Horus-System Figura 16 - Estrutura de um dispositivo Figura 17 - Medição de Processamento Figura 18 Quantidade utilizada de memória RAM pelo Horus Client... 48

7 LISTA DE SIGLAS ASCII - American Standard Code for Information Interchange Bash Bourne Again Shell DAO Data Access Objects FTP File Transfer Protocol HTTP Hypertext Transfer Protocol IDE Integrated Development Environment IP Internet Protocol J2EE Java 2 Enterprise Edition JAR Java Archive JDBC Java Database Connection JDK Java Development Kit JSP Java Server Pages JSTL Java Server Pages Standard Tag Library MVC Model View Controller SQL Structured Query Language SSH Secure Shell TFTP Trivial File Transfer Protocol UML Unified Modeling Language XML Extensible Markup Language WAR Web Archive

8 RESUMO Este trabalho tem por objetivo construir um sistema para monitorar eventos em laboratórios de informática de instituições de ensino. A finalidade do sistema, denominado Horus, é automatizar a coleta de dados e facilitar as operações administrativas nas redes de computadores. O sistema concentrará informações dos clientes em um servidor central, e manipulará os dados capturados de modo a fornecer relatórios relevantes aos administradores da rede em uma interface web intuitiva e funcional. Outra característica do sistema é tornar possível a integração ou criação de sistemas externos, independentemente da linguagem de programação, que utilizem os dados coletados, possibilitando um reaproveitamento das informações do sistema desenvolvido e permitindo maiores controles sobre as ações dos usuários e características da rede. Palavras-chave: Linux, Java, Monitoramento de Redes.

9 ABSTRACT This work intends to construct a system to monitor events in computer science laboratories at educational institutions. The aim of the system, named Horus, is to automatize the collection of data and to facilitate the administrative operations of computer networks. The system will provide to its administrators information in a central server, and will manipulate the captured data in order to supply reports through an intuitive and functional web interface. Another characteristic of the system is to make the integration or creation of external systems possible, independently of programming language, which use the collected data, making it possible reuse information of the system and thus allowing better control of user actions and network characteristics. Keywords: Linux, Java, Network Monitoring.

10 9 1 INTRODUÇÃO Um grande problema encontrado por administradores de redes de computadores é a dificuldade em controlar a utilização dos recursos disponíveis. Muitos usuários não respeitam as regras relativas à navegação e acesso à rede. Em redes de computadores, recursos de hardware e largura de banda são limitados. O uso destes recursos para atividades não pertencentes aos fins da instituição prejudica a utilização da rede para os outros usuários. Exemplos de má utilização de recursos são o download de vídeos e arquivos, jogos em rede, e execução de scripts cuja finalidade é apenas prejudicar o processamento dos computadores da rede. O presente trabalho propõe a construção de um sistema denominado Horus que, ao contrário de outros sistemas disponíveis no mercado, fornece uma interface web para a visualização de relatórios e estatísticas, e também possibilitará a customização dos dados a serem coletados. Foram analisados softwares como o SQUID, que oferecem informações de acesso a sites, e aplicativos como o TOP, que mostram detalhes da execução de processos. Porém estes aplicativos não fornecem uma maneira integrada de monitorar o acesso de usuários. O sistema Horus oferece a informação de qual usuário acessa as máquinas e quais sites e aplicativos ele utiliza. Isto torna muito mais fácil para o administrador controlar os recursos, sem precisar executar terminais remotos em cada máquina, verificando apenas um usuário por vez. Este projeto trará consigo a possibilidade de diferentes dados serem coletados em diferentes laboratórios e ser criado, inicialmente, com foco para a solução dos problemas reportados pelos administradores dos laboratórios. Todo o projeto será construído primando pelo uso da linguagem de programação Java e terão como ambiente de execução e desenvolvimento o Linux. Em cada máquina da rede é instalado um cliente que abastece o banco de dados do servidor com informações sobre autenticações de usuários e controle de processos executados. No lado do servidor, as informações coletadas são processadas e armazenadas. As informações de autenticação são relacionadas aos logs do Squid

11 10 Web Proxy (SQUID, 2006) para fornecer uma informação detalhada de cada acesso a site que acontece na rede. Através do controle de autenticações é possível determinar se um usuário está logado em duas máquinas da rede ao mesmo tempo, caracterizando o empréstimo de logins para usuários não autorizados, ou tentativas de danificação do sistema de outro usuário através de terminal remoto SSH (Secure Shell). Outra funcionalidade do sistema Horus é bloquear logins de usuários da rede, em períodos definidos pelo administrador. Para fins de teste, o sistema será implantando na RLE (Rede Local de Ensino) da UTFPR (Universidade Tecnológica Federal do Paraná) no campus de Curitiba. O sistema facilitará a administração das redes de ensino, pois, através de uma interface web, podem ser obtidos relatórios e estatísticas de acessos a sites indevidos, monitoramento de processos executados além de controle de autenticações. De posse destas informações, o administrador da rede pode tomar as ações necessárias para bloquear os usuários que cometam irregularidades e conciliar o bom uso dos recursos do laboratório. 1.1 Objetivos O objetivo do projeto é desenvolver um sistema flexível e expansível que possa obter dados relevantes das máquinas de uma rede local, facilitando o trabalho dos administradores. Este sistema deve executar no ambiente linux, com o mínimo de requisitos de hardware possível para os clientes e deve conter uma base central de dados com todas as informações coletadas. As informações devem ser processadas e exibidas de forma legível e compreensível para os administradores e/ou responsáveis pela administração da rede. Estas também devem estar protegidas por algum sistema de segurança onde cada usuário pode ter acesso restrito a algumas funções.

12 Organização do Documento Este trabalho está dividido em três capítulos, sendo este utilizado para mostrar os objetivos do sistema e as motivações para o desenvolvimento do mesmo. O segundo capítulo mostra as tecnologias utilizadas para o desenvolvimento da aplicação e para o ambiente de execução. O terceiro capítulo, Projeto e Implementação, detalha as metodologias utilizadas para o desenvolvimento da aplicação e é dividido em dois módulos: Horus Server e Horus Client. O primeiro apresenta os componentes do servidor e suas funcionalidades, o segundo, mostra o funcionamento do software cliente instalado nas estações da rede para coleta de dados e como desenvolver novos métodos de coleta. Finalmente, são apresentadas as conclusões sobre o projeto e as propostas para trabalhos futuros.

13 12 2 SOFTWARES UTILIZADOS Para o desenvolvimento do trabalho, foram utilizados softwares de desenvolvimento e modelagem, além de um sistema de banco de dados, um servidor de aplicação e ferramentas de apoio. Segue abaixo a relação das tecnologias utilizadas. 2.1 J2SE Development Kit (JDK) 1.6 O Java Standard Edition Development Kit é um conjunto de ferramentas disponibilizadas pela Sun Microsystems que inclui uma máquina virtual para executar aplicações Java, e ferramentas para compilação de software da plataforma Java (JAVA, 2006). 2.2 Eclipse IDE O Eclipse IDE é um software que permite o fácil e ágil desenvolvimento de aplicações em diversas linguagens de programação, tendo suporte mais amplo para aplicações Java. Possui ferramentas que auxiliam na depuração, compilação e execução de programas, além de várias facilidades para ajudar no desenvolvimento, como realce de erros de compilação e geração automática de código (ECLIPSE, 2006). 2.3 NetBeans IDE 5 O NetBeans IDE é uma ferramenta free e open-source para desenvolvedores de software, que pode ser executado em várias plataformas e sistemas operacionais. Esta ferramenta tem um ótimo suporte para aplicações desktop,

14 13 aplicações web e enterprise. O NetBeans também possui boa integração com sistemas de versionamento e fácil integração com web containers (NETBEANS, 2006). 2.4 Apache Tomcat O Tomcat é um Container WEB que é a implementação de referências oficial para Java Servlets e Java Server Pages. O Tomcat é disponibilizado gratuitamente no site da Fundação Apache (TOMCAT, 2006). 2.5 Oracle XE O banco de dados escolhido foi o Oracle Database 10G Express Edition, versão livre para desenvolvimento e distribuição (ORACLE, 2006). O Oracle XE possui uma ótima ferramenta de acesso web para gerenciamento do banco de dados que facilita e agiliza diversas operações administrativas, como criação de usuários, criação e alteração de tabelas, inserção de dados e gerenciamento de permissões de acesso. 2.6 Oracle SQL Developer Para dar apoio à codificação de métodos que fazem acesso ao banco de dados, fazer testes de consultas SQL e visualizar meta dados sobre as tabelas foi utilizado o Oracle SQL Developer. É uma ferramenta livre com grande integração com bancos de dados Oracle (SQLDEVELOPER, 2006).

15 CVS O CVS (Concurrent Version System) é um sistema de versionamento que permite que se trabalhe com diversas versões de arquivos organizados em um diretório remoto, mantendo-se versões antigas e histórico de quem manipulou os arquivos (CVS, 2006). 2.8 BSCW Durante o desenvolvimento do projeto foram utilizados os recursos do BSCW (Basic Support for Cooperative Work) (BSCW, 2006). Este software permite que através de uma interface web, seja possível adicionar documentos relativos a um projeto, criar versões para a documentação, inserir notas e discussões sobre tópicos de um projeto, e obter informações sobre quais colaboradores do projeto já visualizaram determinado arquivo. 2.9 JUDE Community UML Modeling tool O JUDE é uma ferramenta de modelagem UML (Unified Modeling Language) orientada a objetos. O JUDE possui uma versão livre (Jude Community) e foi utilizado para modelar os diagramas de casos de uso e diagramas de classe (JUDE, 2007) DB Designer O DB DESIGNER foi o software utilizado para fazer o Modelo do banco de dados do sistema Horus Server. É uma ferramenta open-source com versões para Linux e Windows (FABFORCE, 2006).

16 Jakarta Commons O projeto Jakarta Commons, sustentado pela Apache Software Foundation, é responsável por disponibilizar, desenvolver e otimizar bibliotecas para ações e necessidades comuns entre sistemas (APACHE, 2006). Para facilitar o desenvolvimento do sistema Horus e garantir que este tenha consistência em suas ações, as seguintes bibliotecas do projeto Jakarta Commons foram utilizadas: Jakarta Commons Net: contêm diretivas e funcionalidades para comunicação através da rede. A principal funcionalidade utilizada foi à comunicação com o servidor FTP (File Transfer Protocol); Jakarta Commons Bean-Utils: utilizada para obter dados de forma consistente e prática além de facilitar na criação de tarefas no sistema; Jakarta Commons Logging: esta biblioteca foi utilizada para garantir uma forma consistente e única de armazenamento de mensagens e resultados de processamento; Jakarta Commons Collection: a fase de transformação de objetos em texto e texto em objetos foi facilitada por esta biblioteca, auxiliando na transformação de objetos em mapas e vice-versa.

17 16 3 PROJETO E IMPLEMENTAÇÂO O início do projeto deu-se com o levantamento das necessidades dos administradores dos laboratórios. Nesta etapa, parte dos administradores foi questionada sobre quais tarefas eram onerosas e poderiam ser facilitadas com o sistema de coleta de dados proposto. As necessidades levantadas e fixadas foram: Capacidade de atualização: o sistema deve estar apto a atualizar-se automaticamente a fim de eliminar o trabalho dos administradores de inspecionar versões nas máquinas; Sistema de comunicação: o sistema deve manter uma base de dados consistente e atualizada. Isto só será possível com uma comunicação eficiente e um dispositivo que proporcione a geração de um histórico offline para envio posterior; Coletar usuários logados no sistema: as máquinas que contiverem o software devem capturar os usuários logados e notificar o servidor. A data, horário, máquina e login de acesso devem fazer parte da notificação; Coletar processos dos usuários logados: os processos em execução de cada usuário autenticado devem ser monitorados e a linha de comando, nome de processo e data de execução devem ser enviados a uma base centralizada juntamente com o usuário que os executou; Visualizar dados de acesso dos usuários: deve existir uma interface intuitiva e amigável para a visualização do login, data, horário e computador de cada usuário que se autenticou; Controlar dados de usuários: o sistema deve proporcionar uma interface para visualização e edição de dados do usuário, como: turma, curso e nome; Visualizar processos executados: deve ser possível visualizar os dados dos processos coletados como nome do processo, usuário executor e o comando utilizado para a execução; Controle de processos proibidos: é necessário um dispositivo para marcar quais processos estão proibidos ou não. Esta função deve ser exposta na

18 17 pesquisa de processos executados, a fim de facilitar a identificação de processos executados indevidamente; Controle de usuários autenticados simultaneamente: o sistema deve proporcionar uma forma de visualizar os usuários que autenticaram simultaneamente em máquinas diferentes; Listagem de sites e acessos: para centralizar os dados dos usuários, o sistema deve fazer uma relação entre o horário de login e o acesso a sites. Com isto deve ser criada uma ferramenta de pesquisa, na qual possa ser recuperada a relação entre usuário e sites acessados. Partindo das informações coletadas, foi elaborada uma modelagem inicial para facilitar a visualização dos requisitos. A Figura 1 exibe, em forma de diagrama UML, as funcionalidades requisitadas pelos administradores e a forma de interação entre elas.

19 18 Figura 1 Diagrama de Casos de Uso do Sistema Horus 3.1 Características do Sistema O sistema desenvolvido prima por facilitar as atividades de administração de laboratórios de informática, disponibilizando dados relevantes coletados das máquinas da rede e sistemas externos. Estes dados podem ser utilizados para a geração de relatórios facilitando o controle sobre os recursos de rede e permitindo o monitoramento de ações dos usuários para garantir a segurança e manter as normas de uso específicas do laboratório de informática.

20 19 As seguintes funcionalidades são providas pelo sistema Horus: Controle de acesso a sites: tornar possível o armazenamento de informações sobre os acessos a sites originados na rede, obtidos do log do servidor web proxy (SQUID) e correlacionar estas informações com o horário e usuários responsáveis por estes acessos. Permitir buscas diferenciadas por critérios como a sites mais visitados e visitas por usuário em determinados períodos; Controle de simultaneidade de usuários logados: controlar o uso de logins do sistema para que sejam registrados acessos de um mesmo usuário em máquinas diferentes em um mesmo dia e horário. Esta ação previne que usuários emprestem seu nome de usuário e senha para que pessoas nao autorizadas utilizem o laboratório, ou tentem utilizar seu login em várias máquinas da rede para executar scripts maliciosos; Expansibilidade: permitir que novos sistemas possam ser agregados a este no futuro, tornando-o mais robusto, ou mesmo que novos sistemas utilizem os dados coletados sobre a rede através do banco de dados compartilhado; Controle de Processos: verificar quais os processos que estão sendo utilizados nas máquinas do laboratório para pesquisa de softwares proibidos como jogos, clientes de bate-papo e scripts maliciosos; Ações administrativas: permitir que o administrador do laboratório tenha a possibilidade de programar o bloqueio de login de acesso de usuários que cometeram ações que infringem as normas do laboratório. Ao levantar as necessidades dos administradores do laboratório e definir as funcionalidades a serem desenvolvidas, foi definido que o Horus seria um sistema dividido logicamente em dois módulos: Horus Server e Horus Client. O primeiro, responsável por administrar os dados e repassá-los de forma legível aos administradores. O segundo é encarregado por obter os dados e enviá-los ao servidor. O Horus Server compreende o Servidor Web, a aplicação de interpretação de logs do Squid, a aplicação ClientInterface, que recebe os dados coletados, o sistema de cadastro de processos executados e o sistema de controle de autenticações.

21 20 O Horus Client é a aplicação instalada em todas as estações de trabalho da rede e é responsável pelo monitoramento dos processos executados e usuários autenticados nas máquinas, enviando estas informações ao servidor. O relacionamento entre as estações de trabalho contendo o Horus Client e o Horus Server, é ilustrado na figura 2. Figura 2 Sistema Horus Server e estações Horus Client.

22 HORUS Server Os componentes do Horus Server (ver Figura 3) são detalhados nas próximas seções. Figura 3 Sistema Horus Server e estações Horus Client.

23 Client Interface O Sistema ClientInterface é a aplicação que recebe pela rede as mensagens dos clientes (Horus Client) e encaminha estas mensagens para o Sistema de Controle de Autenticações ou para o Sistema de Cadastro de Processos, de acordo com o tipo da mensagem recebida Sistema de Controle de Autenticações O Sistema de controle de autenticações recebe mensagens dos clientes da rede com informações do usuário logado em uma estação. As mensagens contêm o endereço IP da máquina, o usuário que está logado e um código de autenticação. Estas mensagens funcionam como mensagens Hello 1. O sistema de controle de autenticações utiliza estas mensagens para verificar a existência de logins simultâneos na rede, situação em que um usuário emprestou sua senha para outro usuário não autorizado, ou um usuário está logado em várias máquinas para possivelmente executar scripts maliciosos na rede. As mensagens de autenticação são armazenadas no banco de dados na tabela de autenticações e compõem informação essencial para a geração de relatórios de acesso a sites e relatórios de processos executados SQUID Parser Todas as requisições HTTP (Hyper Text Transfer Protocol) feitas pelos clientes da rede passam pelo Squid Web Proxy (SQUID). 1 As Mensagens Hello são enviadas dos clientes para os servidores para indicar que o cliente ainda está ativo.

24 23 O Squid gera um log com as seguintes informações detalhadas sobre cada requisição. Os seguintes campos são utilizados pelo Sistema Horus: Time: Horário de acesso no formato Unix Time Stamp 2 com precisão de milésimos de segundo. Ex: ; Remote host: Endereço IP da máquina que gerou o evento, ex: Pode ser configurado para mostrar o nome do host; Cache result code: Resultado da busca pelo recurso solicitado. Ex: TCP_MISS O objeto requisitado não está no cache, TCP_HIT Uma cópia válida do objeto foi encontrada no cache; Código de status HTTP: Status de retorno da requisição HTTP. Ex: 200 para sucesso, 404 para recurso não encontrado e 500 para erro interno do servidor; Method: Método HTTP utilizado na requisição. Ex: HEAD, GET ou POST; Recurso solicitado: Endereço do recurso solicitado. Ex: Tipo de conteúdo: Tipo de conteúdo (content-type) do recurso solicitado. Ex: Imagem no formato GIF: image/gif, página HTML text/html: Um exemplo de saída do log do arquivo access.log é mostrado na figura 4. Figura 4 Exemplo de log do Squid Web Proxy access.log O Squid Parser é o módulo do sistema Horus que lê as informações do log do Squid e as persiste no banco de dados. Estas informações, em conjunto com os dados gerados pelo sistema de controle de autenticações, permitem a criação dos relatórios de acesso a sites disponíveis no sistema web. 2 A data no formato Unix Time Stamp representa o número de segundos transcorridos desde as 0:00:00 de 1 de janeiro de 1970 GMT

25 Sistema de Cadastro de Processos O sistema de cadastro de processos é responsável por receber as mensagens contendo cada processo executado pelos usuários da rede e persistir estas informações no banco de dados. O Horus Client manda apenas uma vez cada processo que é iniciado. Estas informações são utilizadas pelo sistema web para a geração de relatórios Banco de Dados O Banco de dados armazena as informações de autenticações, processos, máquinas, usuários, administradores, bloqueios e seus relacionamentos (ver figura 5). Os dados são acessados pelo sistema Web através das classes do pacote DAO 3 e também são acessados por outros módulos do sistema que recebem os dados do Horus Client e fazem atualizações na base de dados. 3 Data Access Object, é um padrão de projeto que sugere a especialização de uma ou mais classes no acesso aos dados do sistema de armazenamento.

26 25 Figura 5 Modelo do Banco de Dados do sistema Horus Sistema Horus Web O sistema web é a interface desenvolvida para que o administrador do laboratório de informática tenha uma fácil interação com o sistema. Primeiramente, é necessário autenticar-se no sistema conforme ilustra a Figura 6. Há níveis de acesso diferenciados para os administradores. Administradores comuns podem, basicamente visualizar dados e gerar relatórios. Os super administradores podem tomar ações como bloquear usuários do laboratório e cadastrar ou remover administradores do Sistema Horus Web.

27 26 Figura 6 Tela de autenticação do administrador. Depois de autenticado, o administrador pode escolher uma das seguintes categorias: acesso a sites, processos e arquivos, e máquinas, conforme ilustra a Figura 7. Em cada uma das áreas, podem ser feitas buscas específicas e buscas com filtros. É possível, por exemplo, trazer resultados agrupados por data ou por usuário. Também há links para o cadastro e alteração de informações sobre as máquinas dos laboratórios, além do cadastro de programas que não são permitidos, como jogos e programas de bate-papo. Estes dados ficam armazenados em um banco de dados e podem ser utilizados por outras aplicações.

28 27 Figura 7 Menu de opções do sistema Web. O Sistema Horus Web foi desenvolvido utilizando a especificação Java Enterprise Edition (J2EE) utilizando uma arquitetura baseada em MVC 4 (MVC, 2006) e design patterns como DAO e Façade, tornando o sistema mais escalável e facilitar a manutenibilidade. As páginas utilizam JavaScript para validações e CSS 5 para efeitos visuais. O Diagrama de Classes do Sistema Web é mostrado na Figura 8. 4 Model View Controller (MVC) é um padrão de desenvolvimento de software que propõe a divisão do sistema em camadas. A camada denominada VIEW responsável exibir os resultados e requisições do sistema,outra camada CONTROLLER responsável por organizar as entradas e saídas do sistema e a camada MODEL responsável pela lógica de negócio. 5 Cascading Style Sheet: padronização utilizada para tornar flexível a edição dos componentes visuais de um documento html.

29 28 Figura 8 Diagrama de Classes do Sistema Web. Seguem abaixo as funcionalidades do sistema web detalhadas por tópico:

30 Níveis de Acesso dos Administradores Os administradores do laboratório são classificados em administradores comuns e super administradores. Os administradores comuns podem realizar as seguintes tarefas: Busca de sites acessados filtrados por data e usuário; Busca de site específico acessado; Cadastro de processos (programas) proibidos; Busca de processos executados, filtrados por data e usuário; Busca de processos específicos executados; Cadastro de máquinas com informações de nome, IP, hardware e laboratório. As buscas acima citadas trazem informações completas do usuário que fez os acessos, data, máquina e horário de acesso. As respostas das consultas vêm ordenadas com os sites e processos mais acessados no topo da lista, mostrando a quantidade de acessos. Os super administradores podem realizar, além das tarefas do administrador comum: Bloqueio de usuários, determinando a data de início e fim do bloqueio; Consulta de usuários bloqueados; Cadastro, alteração e exclusão de administradores do sistema Monitoramento de Acessos a Sites O sistema de monitoramento permite que sejam feitas consultas detalhadas sobre os sites acessados nas dependências do laboratório. Uma das funções é fazer a busca dos sites mais acessados dentro de um determinado período. O administrador escolhe a data inicial e final e o sistema gera uma listagem dos sites mais acessados, ordenados por número de acesso. Também é possível incluir, além

31 30 da data inicial e final da busca de acessos, o login de um usuário da rede, para filtrar apenas os sites acessados por este usuário. A Figura 9 ilustra a tela de busca de sites por usuário. Figura 9 Tela de busca de sites por usuário A lista de sites mais acessados é muito útil para descobrir sites proibidos que estão sendo utilizados pelos usuários. Pela quantidade de acessos, pode-se encontrar sites de jogos, conteúdo adulto, proxy servers, e sites de bate-papo que estão sendo executados indevidamente, consumindo os recursos da rede do laboratório. A lista de sites mais acessados possui um link para cada site que permite visualizar o login do usuário que fez o acesso, a data do acesso e a máquina que o usuário se encontrava logado (ver Figura 10). De posse destas informações, o administrador do sistema pode optar por medidas administrativas como bloquear o site acessado através do gateway internet e tomar ações punitivas, bloqueando o usuário que entrou no site proibido, por um período determinado.

32 31 Figura 10 Tela de resultados de sites mais acessados Processos e Arquivos O administrador pode buscar a lista de processos que foram executados por cada usuário do sistema. Estes processos são listados ordenados pela quantidade de execuções. Assim, os processos mais executados são facilmente identificados. Através da análise de processos mais executados, é possível descobrir novos programas proibidos que estão sendo executados pelos alunos como jogos, emuladores, sniffers de rede, e scripts maliciosos. Na tela que lista os processos, há um link que dá mais detalhes sobre o processo, que abre uma janela mostrando informações completas sobre o usuário que fez o acesso, detalhes da execução,

33 32 data e máquina que o usuário se encontrava logado. A tela de detalhes do processo é mostrada na figura 11. Figura 11 Tela de detalhes de processo executado Bloqueio de Usuários O Sistema Horus Web conta com uma tela que permite o bloqueio de usuários. Esta tela é acessada somente por um super administrador, que decide bloquear o usuário por um período informado, no caso de desrespeito às normas do laboratório. O Administrador informa o login, a data inicial e data final do bloqueio. Esta informação é gravada no banco de dados, e o bloqueio/desbloqueio do usuário é feito automaticamente pelo sistema Horus, sem a intervenção do administrador.

34 Visualização de Logins Duplicados O administrador pode verificar se em um determinado momento, um único par login/senha foi utilizado para autenticação em máquinas distintas (ver Figura 12). Esta informação fornece um meio de verificar usuários que fornecem seu login e senha para amigos que não estão autorizados a utilizar o laboratório. Também é útil para verificar se algum usuário está logado em várias máquinas por terminal remoto (SSH) para executar scripts maliciosos na rede. Figura 12 Tela de logins duplicados

35 Cadastro de Máquinas e Usuários Nesta área o administrador cadastra todos os usuários que utilizam o sistema e as máquinas de cada laboratório. Os usuários possuem atributos como login, nome e curso matriculado. Estas informações são necessárias para que os componentes do Horus Server possam relacionar os recebidos do sistema de coleta de dados (Horus Client) e fazer a geração de relatórios completos. O cadastro de máquinas pode ser utilizado também para incluir informações adicionais de hardware e periféricos de cada máquina do laboratório, sendo útil para um controle de equipamentos.

36 HORUS Client O módulo do sistema responsável pela coleta de dados (Horus Client) trabalha constantemente nas estações de trabalho dos laboratórios. Esta aplicação é dividida basicamente em três módulos: Pacotes de dispositivos (JARs): funcionalidades ou sistemas de coleta obtidos do servidor FTP. Estes componentes são responsáveis por obter os dados do cliente e se comunicarem com o servidor. As funcionalidades podem trocar informações entre si; Horus-Update: sistema de download de funcionalidades sob demanda. Esta pequena ferramenta conecta-se ao servidor FTP e busca os dispositivos a serem executados no aplicativo; Horus-System: pequeno aplicativo que executa os JARs responsáveis pela coleta de dados no cliente, ele também contém os modelos e as regras para a criação de novos coletores; Os três módulos citados acima trabalham em conjunto e são executados em Background 6 sendo iniciadas pelo super-usuário, logo sua execução não pode ser interrompida por usuários que não sejam administradores. Uma descrição mais detalhada dos três módulos do sistema no cliente é fornecida nas próximas seções. Na figura 13 é mostrado o diagrama dos elementos do sistema de coleta de dados, comunicação e de download de novas funcionalidades. 6 Aplicativo executado em modo silencioso sem anunciar sua execução e evitando interação com o usuário.

37 36 Figura 13 Diagrama de Classes do sistema de coleta de dados e comunicação HORUS-UPDATE Para obter os pacotes, existe um programa chamado Horus-Update que se conecta ao servidor e baixa os pacotes juntamente com o arquivo services.xml que contém uma lista de dispositivos que devem ser executados (conforme ilustra a Figura 14). Nesta tarefa de obter os dispositivos o Horus-Update utiliza um arquivo chamado server.xml que contém os seguintes atributos: IP do servidor de dispositivos (ip): é o endereço do servidor que contém os JARs a serem baixados. 7 7 Pode ser escrito como ip (ex: ) ou como endereço (ftp.alguma.coisa.com.br ).

38 37 IP do servidor de comunicação (commserver): contém o endereço do servidor de comunicação, para onde os dispositivos mandarão mensagens. Não necessariamente é o mesmo servidor da aplicação WEB. Porta de comunicação (defaultcommport): é a porta que os dispositivos se conectarão ao servidor de comunicação. 8 Pasta de dispositivos (jarfolder): é a pasta onde os dispositivos se encontram no servidor, é lá que o Horus-Update vai buscá-los. Esta pasta pode ser diferente para diversos clientes visando disponibilizar diferentes funcionalidades a cada um. 9 Login e senha (login / pass): representa o login e a senha do servidor que contém os JARs, no caso base do servidor de FTP. 10 O processo de update se dá de forma simples iniciado-se pela carga do arquivo server.xml para a memória. Com este arquivo carregado o sistema utiliza os campos ip, login, pass e jarfolder para conectar-se no servidor FTP e localizar o arquivo services.xml. Concluída esta etapa passamos para o processo final onde o sistema de update baixa o arquivo XML e carrega-o para a memória fazendo uma iteração entre a lista de dispositivos inscritos nele. Para cada dispositivo descrito neste arquivo o Horus-Update busca o JAR correspondente no servidor e joga-o na pasta jars na máquina cliente. O sistema de Update possui apenas um argumento facultativo que é a pasta onde os arquivos devem ser salvos, este se omitido será considerado como a pasta corrente. 8 É um número positivo entre 0 e Precisa iniciar com o caractere / e deve representar uma árvore de diretórios real. 10 A senha deve ser visível e não criptografada.

39 38 Figura 14 Casos de Uso do Horus-Update HORUS-SYSTEM O núcleo de coleta do sistema Horus é o Horus-System. Esta parte do sistema é responsável por iniciar, manipular e finalizar todos os dispositivos carregados pelo Horus-Update. O fluxo deste processo, como demonstra a figura15, é iniciado pela leitura do arquivo services.xml que contém os dados necessários para carregar cada um dos JARs obtidos pelo módulo de update. Para o sistema cada JAR obtido é um dispositivo e sua principal classe (caracterizada pela tag 11 idname) é uma ChildProcess. 11 Tag: atributo de um arquivo com formato similar a XML.