HORUS:

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

CURITIBA 2007

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.

DARTANGHAN MICHEL VANI TOBIAS PAVOVSKI DE BRITO

HORUS: Sistema de Monitoramento de Eventos para Laboratórios de

Informática

Orientadora Professora MSc. Ana Cristina Barreiras Kochem Vendramin Co-Orientador Professor Carlos Kazuhiko Hara

CURITIBA

2007

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.

HORUS: Sistema de Monitoramento de Eventos para Laboratórios de

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

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.

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.

SUMÁRIO 1 INTRODUÇÃO .................................................................................................... 9

1.1 OBJETIVOS................................................................................................... 10 1.2 ORGANIZAÇÃO DO DOCUMENTO..................................................................... 11

2 SOFTWARES UTILIZADOS ............................................................................. 12 2.1 J2SE DEVELOPMENT KIT (JDK) 1.6............................................................... 12 2.2 ECLIPSE IDE ................................................................................................ 12 2.3 NETBEANS IDE 5 ......................................................................................... 12 2.4 APACHE TOMCAT 5.0.28 ............................................................................... 13 2.5 ORACLE XE ................................................................................................. 13 2.6 ORACLE SQL DEVELOPER ............................................................................ 13 2.7 CVS............................................................................................................ 14 2.8 BSCW 4.3.3................................................................................................ 14 2.9 JUDE COMMUNITY– UML MODELING TOOL.................................................... 14 2.10 DB DESIGNER .............................................................................................. 14 2.11 JAKARTA COMMONS...................................................................................... 15

3 PROJETO E IMPLEMENTAÇÂO ..................................................................... 16 3.1 CARACTERÍSTICAS DO SISTEMA ..................................................................... 18 3.2 HORUS SERVER ......................................................................................... 21

3.2.1 Client Interface........................................................................................ 22 3.2.2 Sistema de Controle de Autenticações................................................... 22 3.2.3 SQUID Parser......................................................................................... 22 3.2.4 Sistema de Cadastro de Processos........................................................ 24 3.2.5 Banco de Dados ..................................................................................... 24 3.2.6 Sistema Horus Web................................................................................ 25

3.2.6.1 Níveis de Acesso dos Administradores ........................................... 29 3.2.7 Monitoramento de Acessos a Sites ........................................................ 29

3.2.7.1 Processos e Arquivos ...................................................................... 31 3.2.7.2 Bloqueio de Usuários....................................................................... 32 3.2.7.3 Visualização de Logins Duplicados ................................................. 33 3.2.7.4 Cadastro de Máquinas e Usuários .................................................. 34

3.3 HORUS CLIENT ........................................................................................... 35 3.3.1 HORUS-UPDATE ................................................................................... 36 3.3.2 HORUS-SYSTEM................................................................................... 38

3.3.2.1 Comunicação Interna....................................................................... 40 3.3.2.2 Armazenando Eventos .................................................................... 41 3.3.2.3 Criando um Dispositivo de Coleta ................................................... 41 3.3.2.3.1 Child Process .................................................................................. 41 3.3.2.3.2 Process Manager ............................................................................ 42 3.3.2.3.3 Connection Adapter ......................................................................... 43

3.3.3 Pacote de Dispositivo (JARS)................................................................. 44 3.4 APLICABILIDADE............................................................................................ 45

4 RESULTADOS.................................................................................................. 46 4.1 RESULTADOS OBTIDOS .................................................................................. 46 4.2 RESULTADOS DE DESEMPENHO ..................................................................... 46

4.2.1 Processamento ...................................................................................... 47 4.2.2 Consumo de Memória ............................................................................ 48

5 CONCLUSÕES E TRABALHOS FUTUROS .................................................... 49 6 REFERÊNCIAS................................................................................................. 50

LISTA DE FIGURAS

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

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

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.

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.

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

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.

11

1.2 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.

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,

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 5.0.28

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).

14

2.7 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 4.3.3

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).

2.10 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).

15

2.11 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.

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

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.

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.

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.

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.

21

3.2 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.

22

3.2.1 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.

3.2.2 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 Hello1.

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.

3.2.3 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.

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 Stamp2 com precisão de

milésimos de segundo . Ex: 1171356445.613;

• Remote host: Endereço IP da máquina que gerou o evento, ex:

192.168.100.1. 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:

http://www.google.com.br/

• 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

24

3.2.4 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.

3.2.5 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 DAO3

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.

25

Figura 5 – Modelo do Banco de Dados do sistema Horus

3.2.6 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.

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.

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 MVC4 (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 CSS5 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.

28

Figura 8 – Diagrama de Classes do Sistema Web.

Seguem abaixo as funcionalidades do sistema web detalhadas por tópico:

29

3.2.6.1 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.

3.2.7 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

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.

31

Figura 10 – Tela de resultados de sites mais acessados.

3.2.7.1 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,

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.

3.2.7.2 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.

33

3.2.7.3 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

34

3.2.7.4 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.

35

3.3 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 Background6 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.

36

Figura 13 – Diagrama de Classes do sistema de coleta de dados e

comunicação.

3.3.1 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: 192.168.5.12) ou como endereço (ftp.alguma.coisa.com.br ).

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 65534. 9 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.

38

Figura 14 – Casos de Uso do Horus-Update.

3.3.2 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 tag11 idName) é uma

ChildProcess.

11 Tag: atributo de um arquivo com formato similar a XML.

39

Os campos encontrados no services.xml são:

• Nome completo da classe (className): é o pacote com o nome da classe

usado para instanciar um ChildProcess.

• Localização do arquivo no servidor (jarLocation): é onde o Horus-Update

busca pelo arquivo do dispositivo.12

• Nome do arquivo de dispositivo (jarName): é o arquivo que será baixado

pelo sistema de update.

• Tempo de intervalo (reloadTime): é o tempo, em segundos, de intervalo

entre cada execução de um dispositivo de coleta.

Toda a classe de dispositivo tem comportamentos previstos como criação,

comunicação e remoção. Destas, apenas a primeira é controlada integralmente pelo

Horus-System, as demais também são monitoradas porém executadas de acordo

com as necessidades dos outros dispositivos. Isto permite que um dispositivo

comunique-se com outro dispositivo ou que simplesmente finalize a execução de

outro dispositivo.

Um dispositivo é composto pelos seguintes itens:

- idName: pacote e nome completo e da classe principal do dispositivo.

- reloadTime: tempo, em segundos, de intervalo entre cada execução.

O idName é utilizado como chave na procura ou na comunicação com

determinado dispositivo e este será usado na hora de exibir os logs. Não podem

existir dois dispositivos com o mesmo idName na mesma máquina rodando ao

mesmo tempo.

12 Precisa iniciar com o caractere / e deve representar uma árvore de diretórios real

40

Figura 15 – Casos de Uso do Horus-System.

3.3.2.1 Comunicação Interna

A coleta de dados depende da comunicação das funcionalidades com um

sistema de comunicação com o servidor. A partir desta idéia, o Horus-System

permite que as funcionalidades troquem informações entre si, assim o aplicativo que

calcula o espaço da Home13 pode comunicar-se com o aplicativo que obtém dados

do usuário, incluindo a localização de sua Home, para executar seu serviço, por

exemplo.

Isso se deve graças a existência de um mapa de dispositivos dentro de um

dos controladores do Horus Client, o ProcessManager. Neste mapa cada dispositivo

é caracterizado pelo seu idClassName14 e pode acessar, através do controlador pai,

outro dispositivo. Esta técnica é utilizada na comunicação com o servidor, onde o

controlador de comunicação, responsável por mandar e receber pacotes do servidor,

também é um dispositivo.

13 Pasta pessoal do usuário. 14 Nome do pacote seguido do nome da classe.

41

3.3.2.2 Armazenando Eventos

Um local centralizado para armazenamento de eventos é uma estratégia

implementada através de logs controlados pelo sistema central para eventual falha

na comunicação com o servidor. Todas as funcionalidades têm acesso às funções

de logs e estas têm um único local de configuração, este pode ser uma saída de

texto em console ou um arquivo ASCII.

3.3.2.3 Criando um Dispositivo de Coleta

Visto a limitação do escopo e a futura necessidade de novas funcionalidades,

o desenvolvimento do Horus-System foi feito pensando em expansibilidade.

O sistema Horus contém todas as classes e interfaces necessárias para o

desenvolvedor criar seu próprio dispositivo de coleta de dados. Para tanto é

necessário que se saiba como funciona o fluxo de execução e alguns itens

importantes do sistema. As classes e interfaces que devem ser conhecidas para

criar o dispositivo são:

• org.utfpr.rle.horus.core.ChildProcess;

• org.utfpr.rle.horus.core.ProcessManager;

• org.utfpr.rle.horus.core.connection.ConnectionAdapter;

• Pacote de dispositivo;

Elas são encontradas dentro do pacote HorusSystem.jar do aplicativo.

3.3.2.3.1 Child Process

Todo o dispositivo (processo) gerenciado pelo Horus é um ChildProcess e,

por conseqüência, as classes destes dispositivos estendem ChildProcess. Esta

classe disponibiliza algumas das funcionalidades vitais para qualquer dispositivo de

coleta, como:

42

• Sistema de logs: disponibilizado para centralizar todos os resultados de

eventos ou de ações do dispositivo;

• Tempo de re-execução: todo o ChildProcess tem um tempo de re-

execução. Este tempo é definido, em segundos, por reloadTime e consiste

na reinicialização do processo de coleta;

• Controle de vida útil: a fim de tornar os processos mais dinâmicos, um

sistema de controle de vida útil é disponibilizado. Este é usado acessando

o processo pai (ProcessManager) e obtendo o ChildProcess desejado. Um

dispositivo pode encerrar a vida de outro ou iniciar um novo;

• Execuções concorrentes: a comunicação entre os dispositivos e a

possibilidade de controle de vida útil em runtime15 deve-se ao fato de

todos os ChildProcess serem uma THREAD;

Para utilizar a classe ChildProcess o desenvolvedor deve fornecer a

codificação para os seguintes métodos:

• processStart: método que contém o ciclo de coleta. Não é necessário que

este método contenha toda a estrutura do dispositivo, mas este será o

método chamado pelo ProcessManager ao iniciar um dispositivo;

• processStop: alguns processos podem abrir muitas conexões com o

servidor, ou executar tarefas onde sejam necessárias finalizações de

outros objetos. Este método é chamado ao fim do ciclo de vida de um

dispositivo, se for necessário fechar sockets, finalizar edições em arquivos

ou qualquer outra tarefa de finalização insira-a neste método;

Os métodos descritos acima podem ser acessados por qualquer outro

dispositivo.

3.3.2.3.2 Process Manager

A classe ProcessManager é considerada o maestro do Horus-System. Ela é

responsável pela coordenação e instanciação dos processos. Esta classe é

15 Em tempo de execução.

43

chamada através do método getPai() de um ChildProcess e disponibiliza as

seguintes funcionalidades:

• Obter dados do arquivo services.xml: a necessidade de saber o estado

inicial do sistema pode ser necessária a um ChildProcess. Logo, o

ProcessManager disponibiliza a lista de processos iniciais que estão

contidas no services.xml;

• Recuperar um processo em específico: através de um sistema de controle

baseado em Map é possível obter do ProcessManager um processo em

execução conhecendo apenas seu idClassName;

• Utilizar o sistema de comunicação: o ProcessManager disponibiliza uma

classe chamada ConnectionAdapter que é utilizada para fazer

comunicação com o servidor de dados;

• Finalizar um processo: a classe de controle permite a finalização de

qualquer dispositivo apenas conhecendo o seu idClassName;

3.3.2.3.3 Connection Adapter

A classe ConnectionAdapter é uma implementação do Design Pattern Adapter

(ADAPTERPATTERN, 2006). Ela concentra as funcionalidades de um ChildProcess

e de uma ConnectionBluePrint16. Sua principal finalidade é possibilitar a

comunicação com o servidor de dados, disponibilizando métodos para leitura e

escrita de textos e objetos.

Esta classe pode ser obtida pelo ProcessManager utilizando o método

getConnectionManager() e pode ser utilizada por qualquer ChildProcess. Ela

também pode ser finalizada ou reinicializada a qualquer momento.

16 É a interface detentora das declarações dos métodos de comunicação. Qualquer classe que queira ser uma

classe comunicadora deve implementar esta interface.

44

3.3.3 Pacote de Dispositivo (JARS)

Todos os JARs obtidos do servidor não passam de arquivos compactados por

um aplicativo distribuído junto com a JDK17.

A estrutura do arquivo exige apenas que o pacote Java esteja na raiz como

mostra a Figura 16.

Figura 16 - Estrutura de um dispositivo.

Dentro destes arquivos estão localizados todos os arquivos com código fonte

das funcionalidades juntamente com os ByteCodes18 para a execução.

17 JDK: Java Development Kit, conjunto de aplicativos distribuídos para desenvolvimento de

aplicações em Java. 18 Código java compilado, resultante da execução do aplicativo Javac distribuído com a JDK.

45

3.4 Aplicabilidade

Graças à possibilidade de desenvolver novos módulos e utilizar recursos

internos, é possível obter uma gama enorme de dispositivos para o Horus. Uma das

funcionalidades imaginadas seria um sistema de controle remoto, onde o

administrador pudesse ver o que acontece na tela do cliente e este, ativamente,

enviaria ScreenShots19 de sua área de trabalho ao servidor.

Outra possibilidade seria o desenvolvimento de um sistema de Shutdown20

remoto, onde, de um computador da administração, pudesse ser enviado uma

solicitação a um número definido de máquinas e estas executassem o processo de

desligamento.

A implantação do Sistema Horus para o monitoramento de redes Windows

também seria possível. Seria necessário adicionar os módulos (JARs) codificados

para esta plataforma com o uso do Java SE 6 21 que é mais eficiente e possui novas

funções de interação com o sistema operacional.

Este sistema tem a maleabilidade necessária para que os administradores

personalizem seu sistema de segurança e obtenham os dados de forma fácil e

confiável.

19 Foto da tela. 20 Processo de desligamento de uma máquina. 21 Java SE 6 –O Java Standard Edition 6 possui melhorias na performance e acesso a funções como

o uso do espaço em disco.

46

4 RESULTADOS

Esperava-se obter dados consistentes de uso de processos, de usuários

logados e uma relação de acesso à sites. Além dos resultados, o impacto sobre a

performance do sistema também era um aspecto a ser observado.

O sistema, tanto servidor quando cliente, foi testado durante alguns dias e em

parte de um dos laboratórios para estimar o impacto na performance da rede.

4.1 Resultados obtidos

Após o período de coleta de dados ter terminado, a base de dados contava

com um total de aproximadamente vinte usuários distintos salvos e sem acessos

duplicados. Os processos obtidos dos usuários foram muito semelhantes. Tal

semelhança dá-se pelo fato de todos utilizarem o mesmo ambiente gerenciador de

janelas e que dele derivam uma mesma hierarquia de processos.

No aspecto de sites acessados, quase todos os acessos foram a sites

rotineiros. Apenas um site foi repreendido, este era uma alternativa para acessar

indiretamente um dos sites de relacionamentos bloqueados.

4.2 Resultados de Desempenho

Como variáveis de desempenho os seguintes itens foram estabelecidos:

processamento e consumo de memória.

47

4.2.1 Processamento

O cálculo de processamento foi efetuado nas máquinas clientes, com o objetivo

de medir o impacto sobre as operações dos usuários.

A Figura 17 expressa o consumo de processamento demandado pelo sistema

Horus Client durante quatro minutos de execução.

0

10

20

30

40

50

60

70

80

0 20 40 60 80 100

120

140

160

180

200

220

Tempo (Seg)

Proc

essa

men

to (%

)

Figura 17 - Medição de Processamento

Pode-se observar que o Horus Client utilizou, em média, um quinto do poder

de processamento para sua tarefa de coleta de dados e processos de usuários.

Observou-se também, que os picos de processamento coincidem com a revalidação

dos dados coletados pelo sistema, ou seja, coincidem com a verificação dos dados

armazenados em buffer pelo sistema de coleta e o reenvio dos dados alterados.

A fatia de processamento exibida, apesar de expressiva, está sujeita a

interferência de outros processos em execução no momento, reduzindo assim a

média de processamento utilizada.

48

4.2.2 Consumo de Memória

Nos testes de consumo de memória, foi observado que houve um limite de

quinze megabytes de uso, como expressa a Figura 18.

Memória usada pelo Horus Client

0

5

10

15

20

0 20 40 60 80 100

120

140

160

180

200

220

240

Tempo (segundos)

Mem

ória

(Meg

abyt

es)

Figura 18 – Quantidade utilizada de memória RAM pelo Horus Client

O pico inicial de aproximadamente vinte megabytes é resultante do início dos

dispositivos de coleta e da obtenção dos pacotes do servidor.

Existem algumas alternativas para reduzir ainda mais o uso de memória. A

solução mais aceitável é limitar a memória ao executar o aplicativo, enviando para a

virtual machine um comando estipulando o limite de memória desejado.

49

5 CONCLUSÕES E TRABALHOS FUTUROS

Com o presente trabalho pretende-se realizar um forte controle sobre a

utilização do laboratório. Monitorar a ação dos usuários, para fazer com os quais

não respeitam as regras de utilização recebam advertências ou suspensões e

permitir que os usuários que fazem um bom uso do laboratório tenham os recursos

disponíveis com uma melhor qualidade são os principais objetivos do sistema Horus.

Durante a elaboração do trabalho foram utilizadas diversas técnicas que

envolvem diversas áreas de sistemas de informação; desde o acesso aos eventos

do sistema operacional até os padrões de projeto de alto nível para uma melhor

manutenibilidade do sistema web.

O Sistema Horus, implementado na Rede Local de Ensino da Universidade

Tecnológica Federal do Paraná possui diversas funcionalidades que também podem

ser utilizadas em um sistema de monitoramento comercial. Serão feitas pesquisas

pela demanda por sistemas de monitoramento deste porte e, caso os estudos sejam

satisfatórios, surge a perspectiva de venda do sistema para outros laboratórios de

informática e empresas. Já é sabido que algumas empresas que terceirizam o

suporte e a administração dos setores de informática sofrem com a reinstalação e

configuração de algumas estações de trabalho. O Horus poderia se tornar uma

ferramenta para automatizar as instalações, onde ele mesmo baixasse os módulos a

serem instalados e os configurasse. Imagina-se o Horus, no futuro, como uma

ferramenta instalada que, colocada em vários clientes, tornaria possível a locação de

servidores de dispositivos e serviços de monitoramento.

50

6 REFERÊNCIAS

ADAPTERPATTERN Adapter Pattern. Disponível em:

<http://en.wikipedia.org/wiki/Wrapper_pattern >. Acesso em 15 Out. 2006.

BSCW BSCW Home Page. Disponível em:

<http://bscw.fit.fraunhofer.de/>. Acesso em 10 de Maio 06.

CVS Cuncurrent Version System. Disponível em:

<http://pt.wikipedia.org/wiki/CVS/>. Acesso em 21 Out. 2006.

FABFORCE General Information - What is DBDesigner 4? Disponível em:

<http://fabforce.net/dbdesigner4/>. Acesso em 19 Nov. 2006.

ECLIPSE Eclipse – An open development Platform. Disponível em:

<http://www.eclipse.org/>. Acesso em 3 Out. 2006.

JAVA The source for Java Developers. Disponível em:

<http://java.sun.com/>. Acesso em 10 Dez. 2006.

APACHE Jakarta Commons. Disponível em:

<http://jakarta.apache.org/commons/>. Acesso em 10 Out. 2006.

JUDE JUDE Community. Disponível em:

<http://jude.change-vision.com/jude-web/product/community.html/>. Acesso em 8

Jan. 2007.

MVC Model View Controller - MVC. Disponível em:

<http://pt.wikipedia.org/wiki/MVC/>. Acesso em 3 Fev. 2006.

NETBEANS NetBeans IDE. Disponível em:

<http://www.netbeans.org/>. Acesso em 3 Out. 2006.

51

ORACLE Oracle Database Express Edition. Disponível em:

<http://www.oracle.com/technology/products/database/xe/> Acesso em 5 Nov. 2006.

SQUID Squid Web Proxy Cache. Disponível em:

<http://www.squid-cache.org/>. Acesso em 15 Dez. 2006.

SQLDEVELOPER Oracle SQL Developer. Disponível em:

<http://www.oracle.com/technology/products/database/sql_developer>

Acesso em 5 Nov. 2006.

TOMCAT Apache Tomcat. Disponível em:

<http://tomcat.apache.org/index.html/>. Acesso em 10 Out. 2006

Autorização

Autorizamos a reprodução e/ou divulgação total ou parcial da presente

obra, por qualquer meio convencional ou eletrônico, desde que citada a

fonte.

Nome do autor: Dartanghan Michel Vani

Assinatura do autor: ____________________________

Instituição: Universidade Tecnológica Federal do Paraná

Local: Curitiba, Paraná

Endereço: Rua Natálio Fagundes, n. 34

E-mail: dartanghan@gmail.com

Nome do autor: Tobias Pavovski Brito

Assinatura do autor: ____________________________

Instituição: Universidade Tecnológica Federal do Paraná

Local: Curitiba, Paraná

Endereço: Rua Brasílio Itiberê, n. 1812, ap. 14 bl. D

E-mail: tobiasbrito@gmail.com