View
0
Download
0
Category
Preview:
Citation preview
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
Recommended