Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE GERENCIAMENTO DE DOMÍNIOS VIA WEB
Área de Redes
por
Adriano Marcolin
Carla Merkle Westphall, Dra. Orientador
Fabrício Bortoluzzi, Mestre Co-orientador
Itajaí (SC), novembro de 2005
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE GERENCIAMENTO DE DOMÍNIOS VIA WEB
Área de Redes
por
Adriano Marcolin Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Carla Merkle Westphall, Dra.
Itajaí (SC), novembro de 2005
i
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................iv
LISTA DE FIGURAS ...............................................................................v
LISTA DE TABELAS..............................................................................vi RESUMO .................................................................................................vii ABSTRACT ............................................................................................viii 1. INTRODUÇÃO.....................................................................................1 1.1. OBJETIVOS ........................................................................................................ 3 1.1.1. Objetivo Geral ................................................................................................... 3 1.1.2. Objetivos Específicos ........................................................................................ 3 1.2. METODOLOGIA................................................................................................ 3 1.2.1. Etapas................................................................................................................. 4 1.3. ESTRUTURA DO TRABALHO ....................................................................... 4
2. FUNDAMENTAÇÃO TEÓRICA .......................................................6 2.1. SEGURANÇA DE COMPUTADORES............................................................ 6 2.1.1. Ameaças, vulnerabilidades e ataques.............................................................. 7 2.1.2. Políticas e mecanismos de segurança ............................................................ 12 2.2. CONTROLE DE ACESSO BASEADO EM PAPÉIS ................................... 15 2.2.1. Modelo RBAC core ......................................................................................... 17 2.2.2. Modelo RBAC hierárquico ............................................................................ 18 2.2.3. Modelo RBAC com restrições........................................................................ 19 2.3. SOFTWARE LIVRE......................................................................................... 20 2.3.1. Propriedade intelectual .................................................................................. 21 2.3.2. Licenças de software ....................................................................................... 21 2.4. SISTEMA OPERACIONAL LINUX .............................................................. 23 2.4.1. Composição e serviços .................................................................................... 24 2.4.2. DNS................................................................................................................... 24 2.4.3. FTP ................................................................................................................... 27 2.4.4. HTTP................................................................................................................ 28 2.4.5. Apache.............................................................................................................. 29 2.5. FERRAMENTAS DE ADMINISTRAÇÃO DE SERVIDORES.................. 30 2.5.1. Webmin ............................................................................................................ 30 2.5.2. Cpanel .............................................................................................................. 32 2.5.3. Webtools........................................................................................................... 33 2.5.4. Comparação entre as ferramentas ................................................................ 34 2.5.5. Trabalhos científicos relacionados ................................................................ 36
3. PROJETO............................................................................................37 3.1. A EMPRESA GRUPOW .................................................................................. 37
3.2. SISTEMA DE GERENCIAMENTO DE DOMÍNIOS VIA WEB ............... 39
4. TECNOLOGIAS UTILIZADAS.......................................................43 4.1. COLDFUSION................................................................................................... 43 4.2. MYSQL............................................................................................................... 44 4.3. SHELL................................................................................................................ 45
5. DESENVOLVIMENTO .....................................................................45 5.1. MODELAGEM.................................................................................................. 45 5.1.1. Diagrama de Use-Case.................................................................................... 45 5.1.2. Dicionário de dados......................................................................................... 50 5.2. TELAS DO SISTEMA ...................................................................................... 54 5.3. INTEGRAÇÃO WEBTOOLS E SGD WEB .................................................. 59 5.4. SEGURANÇA.................................................................................................... 59 5.4.1. Autenticação .................................................................................................... 59 5.4.2. Validação.......................................................................................................... 60 5.4.3. Sudo (Linux) ................................................................................................... 60 5.4.4. Compilação ...................................................................................................... 60 5.4.5. Components ..................................................................................................... 61 5.4.6. Sessão................................................................................................................ 61 5.4.7. SSL (Secure Socket Layer)............................................................................. 62 5.4.8. RBAC ............................................................................................................... 62 5.5. TESTES E RESULTADOS .............................................................................. 63
6. CONCLUSÕES...................................................................................65
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................66
ANEXO I – Exemplo da estrutura RBAC no código implementado. .69
iii
LISTA DE ABREVIATURAS
ATM Asynchronous Transfer Mode CFC ColdFusion Component CGI Common Gateway Interface DNS Domain Name Service FTP File Transfer Protocol GNU General Public License HTML Hyper-text Markup Language HTTP Hyper-text Transfer Protocol ICMP Internet Control Message Protocol IETF Internet Engineering Task Force IP Internet Protocol LAN Local Area Network MIB Management Information Base RBAC Role-Based Access Control RFC Request for Comments SSL Secure Socket Layer TCC Trabalho de Conclusão de Curso TCP Transmission Control Protocol UDF User Defined Function UDP User Datagram Protocol UNIVALI Universidade do Vale do Itajaí WWW World Wide Web
LISTA DE FIGURAS
Figura 1. Incidentes Reportados no Brasil no período de Janeiro a Março de 2005............................8 Figura 2. Tipos de ataques....................................................................................................................8 Figura 3. Exemplo de controle de acesso à Internet utilizando um firewall. .....................................14 Figura 4. Visão geral do RBAC. ........................................................................................................16 Figura 5. RBAC Core.........................................................................................................................17 Figura 6. RBAC Hierárquico. ............................................................................................................18 Figura 7. RBAC com Separação Estática de Tarefas.........................................................................19 Figura 8. RBAC com Separação Dinâmica de Tarefas. .....................................................................20 Figura 9. Árvore de localização de domínios.....................................................................................26 Figura 10. Tela de controle de acesso dos usuários. ..........................................................................31 Figura 11. Tela de controle dos serviços WEB..................................................................................31 Figura 12. Visão da tela de acesso aos serviços disponibilizados......................................................32 Figura 13. Visão geral do controle de FTP. .......................................................................................33 Figura 14. Etapas para a administração atual do servidor GrupoW...................................................38 Figura 15. Funcionamento atual da ferramenta WEBTOOLS..........................................................40 Figura 16. Etapas para o funcionamento do sistema SGD Web. .......................................................42 Figura 17. Diagrama use-case do funcionamento do sistema ............................................................46 Figura 18. Diagrama físico do banco de dados. .................................................................................52 Figura 19. Tela de login do apache ...................................................................................................54 Figura 20. Tela de login .....................................................................................................................55 Figura 21. Tela de visualização dos dados de um usuário .................................................................55 Figura 22. Tela de criação de um novo usuário .................................................................................56 Figura 23. Tela de atribuição das permissões ao papel ......................................................................57 Figura 24. Tela de visualização dos logs de acesso ...........................................................................58 Figura 25. Tela de visualização dos domínios ...................................................................................58
v
LISTA DE TABELAS
Tabela 1. Comparativo entre o Webmin, Cpanel e Webtools. ...........................................................34 Tabela 2. Descrição da administração atual do servidor GrupoW.....................................................39 Tabela 3. Descrição do funcionamento da ferramenta WEBTOOLS. ...............................................40 Tabela 4. Descrição do funcionamento do sistema SGD Web. .........................................................42 Tabela 1. Use case Autenticar. ..........................................................................................................46 Tabela 6. Use case Gerenciar Usuários. .............................................................................................46 Tabela 7. Use case Gerenciar Permissões. .........................................................................................47 Tabela 8. Use case Gerenciar Logs. ...................................................................................................48 Tabela 9. Use case Listar Domínios...................................................................................................48 Tabela 10. Use case Editar Domínio. .................................................................................................48 Tabela 11. Use case Excluir Domínio................................................................................................49 Tabela 12. Use case Cadastrar Domínio. ...........................................................................................49 Tabela 13 Classe User ........................................................................................................................50 Tabela 14 Classe User_Role ..............................................................................................................50 Tabela 15 Classe Role ........................................................................................................................50 Tabela 16 Classe Operation................................................................................................................50 Tabela 17 Classe Role_Permission_Set .............................................................................................51 Tabela 18 Classe Log .........................................................................................................................51 Tabela 19 Modelo físico do banco de dados. .....................................................................................52 Tabela 20 configuração ......................................................................................................................64 Tabela 21 Resultados .........................................................................................................................64
RESUMO
MARCOLIN, Adriano. Sistema de Gerenciamento de Domínios Via Web. Itajaí, 2005. 89 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2005. Em dias de economia globalizada, as empresas estão sob pressão constante, seja dos fornecedores que querem obter mais lucros, seja dos clientes que querem comprar pagando o mínimo possível. Qualquer diminuição que se consiga obter, no tempo ou nos custos, buscando-se uma política de desenvolvimento de softwares personalizados que aumentem a produtividade da empresa, pode ser fundamental para manter o funcionamento e agilizar o atendimento aos clientes. O sistema desenvolvido neste trabalho tem como objetivo melhorar o processo de gerência de domínios em um servidor Web. O sistema foi desenvolvido para ser executado na plataforma Linux, utilizando o modelo de controle de acesso RBAC para controlar os usuários e fornece logs para possíveis auditorias. São utilizadas as tecnologias Coldfusion, Shell para programação e MySQL para armazenar as informações sobre usuários e acessos em banco de dados. Os dados para análise são provenientes da empresa GrupoW e das ferramentas similares existentes: Webmin, Cpanel e WEBTOOLS. O sistema fornece as funcionalidades do software WEBTOOLS e acrescenta novas abordagens de funcionamento, como a interface Web e o acesso multiusuário. O sistema permite a criação, edição, exclusão e listagens dos domínios cadastrados no servidor Web, bem como o controle de acesso dos usuários. Este sistema é voltado para usuários com pouco conhecimento dos processos envolvidos na configuração de um domínio em um servidor e para empresas de hospedagem de pequeno e médio porte, que necessitam de facilidade no controle de suas tarefas. Palavras-chave: Redes. Segurança. Internet.
ABSTRACT
Nowadays, with the Globalized Economy, the Companies are under constant pressure, either from suppliers, who want to increase profits, or from costumers, who want to buy paying as low as possible. Any obtainable decrease, either on time or prices, searching for a personalized software development policy that increases the productivity of the Company, could be essential to keep the productivity and improve costumer support. The system developed in this work intends to speed up the domains management process in a web server. The system was developed to be executed in the Linux platform and it uses the RBAC access control model to manage users and provide logs for possible auditorships. The technologies are used the programming languages Coldfusion, CGI and Shell for the programming process and MySQL Database to manage the database and store the information about users. The data for analysis will be provided by the Company GrupoW and existing similar tools as Webmin, Cpanel and WEBTOOLS. The system will offer the functionalities of the software WEBTOOLS and will add new methods of functionality, as the Web interface and the multi-user access. The system allows the creation, edition, exclusion and listings of the domains registered in the Web server, as well as the user access control. The System is intended for users with little knowledge of the processes involved in the configuration of a domain in a web server and for small and medium size companies that need agility and control in their tasks. Keywords: Nets. Security. InterNet.
viii
1. INTRODUÇÃO
A grande necessidade da distribuição de informações de forma segura e rápida passou a ser
um dos principais requisitos do processo do negócio entre empresas. Nesse contexto, a Internet
provê um meio de baixo custo e de alta velocidade para a troca de informações. Estas informações
que circulam pela rede são armazenadas em servidores, que utilizam diversos tipos de sistemas
operacionais (TANENBAUM, 1997).
Devido a grande complexidade envolvida no processo de distribuição das informações, cada
vez mais se faz necessário à existência de profissionais qualificados para a gerência e para a
manutenção dos servidores onde as informações são armazenadas. Esta qualificação exige
treinamento e muito conhecimento, o que torna alto o custo do profissional especializado, que
normalmente é representado pelo administrador do sistema operacional e de rede.
O gerenciamento de domínios é o processo de criação e configuração de um espaço no
servidor, alocado para um usuário, que pode carregar arquivos e informações sobre os websites nele
hospedados, acessíveis via internet. Para gerenciar um domínio o usuário administrador deve
modificar vários arquivos e serviços disponíveis no servidor. Estas modificações incluem alterações
no servidor de nomes (DNS), no servidor de páginas (HTTP) e no servidor de arquivos (FTP). Por
isto a configuração deve ser feita de forma segura e correta, para não ocasionar problemas em
outras partes do sistema.
Dentre os sistemas operacionais disponíveis no mercado pode-se destacar a família Linux.
De acordo com (LINUX, 2005), o Linux é um sistema operacional similar ao Unix, desenvolvido
pelo finlandês Linus Torvalds. Para realizar o gerenciamento dos servidores Linux, já existem
algumas ferramentas com código disponível (WEBMIN, 2005), (WEBTOOLS, 2005) e também
ferramentas proprietárias (CPANEL, 2005). Normalmente, as ferramentas já existentes são
genéricas e possuem uma grande variedade de recursos. Os programas desenvolvidos para a
gerência de servidores utilizam as linguagens de scripts do sistema operacional, como a linguagem
Shell ou CGI, para intermediar o acesso do usuário ao sistema.
O objetivo deste trabalho de conclusão de curso é o desenvolvimento de um sistema de
gerenciamento de domínios via Web. Este projeto, diferente das ferramentas já existentes, será
limitado ao serviço de gerenciamento de domínios em um servidor Linux, implementando uma
política de controle de acesso baseado em papéis (role-based access control – RBAC)
Este sistema de gerenciamento de domínios via Web prevê uma interface funcional e com
usabilidade. De acordo com (MARTINEZ, 2003), a usabilidade é um conceito chave em IHC
(Interação Humano-Computador). Está relacionada a tornar os sistemas mais fáceis de aprender e de
usar.
Assim, o sistema desenvolvido poderá ser utilizado por profissionais menos qualificados,
reduzindo custos do gerenciamento de servidores Linux, já que o administrador com alta
qualificação ficará liberado para realizar outras tarefas de maior prioridade. Dessa forma, o tempo
necessário para executar o gerenciamento de domínios será menor, já que uma variedade maior de
pessoas terá possibilidades de usar o sistema de gerenciamento de domínios via Web.
Algumas iniciativas de pesquisa nesse assunto já podem ser identificadas na literatura
científica. O Trabalho MINC – Ferramenta de Gerenciamento e Monitoramento de Hosts (MINC,
2004), foi desenvolvido a partir das dificuldades em encontrar uma ferramenta de monitoramento e
gerência de máquinas Linux que atendesse as necessidades do DCC FESURV (Departamento de
Ciência da Computação da Universidade de Rio Verde). Devido às dificuldades apresentadas, foi
feita a criação de uma ferramenta personalizada que atendesse aos objetivos específicos esperados.
Já o trabalho FACil-DiretoGNU (FACIL-DIRETOGNU, 2002) descreve uma ferramenta para a
configuração e administração do serviço de e-mails e usuários em um servidor Linux. A ferramenta
foi desenvolvida utilizando como base a ferramenta já existente Webmin, com a adição de novos
módulos. Isto possibilitou a personalização e modularidade da ferramenta desenvolvida.
O assunto a ser tratado por esse trabalho de conclusão de curso é pesquisado pela sua
importância prática no cotidiano da administração de servidores Linux. A criação de um sistema
próprio é justificada pelas limitações e problemas de segurança existentes nas ferramentas
disponíveis (SECURITYFOCUS, 2005 e SECUNIA, 2005). A personalização gráfica e funcional
serão uns dos principais diferenciais entre o sistema desenvolvido nesse TCC e as ferramentas já
existentes no mercado. Dessa forma, acredita-se que o tema e a abrangência da pesquisa são
adequados para um Trabalho de Conclusão de Curso para o curso de Ciência da Computação.
2
1.1. OBJETIVOS
1.1.1. Objetivo Geral
O objetivo geral deste trabalho de conclusão de curso é o desenvolvimento de um sistema de
gerência de domínios (configuração de DNS) em um servidor Linux, utilizando uma interface Web.
Este gerenciamento poderá ser feito a partir de qualquer ponto com acesso a internet, utilizando um
navegador que é uma interface amigável.
O sistema de gerenciamento de domínios terá regras de segurança baseadas no controle de
acesso baseado em papéis (RBAC – Role Based Access Control) para que as operações possam ser
realizadas por diferentes usuários e permissões e que não prejudiquem os demais serviços utilizados
pelo servidor.
1.1.2. Objetivos Específicos
Os objetivos específicos desse trabalho que podem ser citados são os seguintes:
• Pesquisar os fundamentos e conceitos sobre segurança e serviços de servidores Linux;
• Pesquisar e analisar soluções similares;
• Determinar os requisitos exigidos pelo sistema;
• Compreender os fundamentos e metodologias para desenvolvimento de projetos;
• Realizar o projeto conceitual do sistema;
• Desenvolver o software, utilizando mecanismos de segurança adequados e suficientes
para o gerenciamento de domínios.
1.2. METODOLOGIA
Foram estipuladas dez etapas a fim de executar este projeto. As cinco primeiras etapas foram
efetivadas no TCC I e compreenderam a análise das tecnologias envolvidas e o projeto do sistema.
As etapas restantes foram efetivadas no TCC II e compreendem a modelagem, desenvolvimento,
validação e documentação do sistema.
3
1.2.1. Etapas
• Coletar informações sobre os assuntos de relevância ao trabalho;
• Tomar conhecimento sobre quais serviços são necessários no gerenciamento de
domínios;
• Buscar e analisar ferramentas e trabalhos científicos relativos ao projeto;
• Definição do projeto;
• Estudar as linguagens a serem utilizadas no projeto;
• Modelagem do projeto;
• Desenvolvimento do sistema;
• Análise dos resultados e testes;
• Coletar os resultados e validar o sistema;
• Documentação do sistema.
1.3. ESTRUTURA DO TRABALHO
O trabalho está dividido em quatro capítulos: Introdução, Fundamentação Teórica, Projeto e
Conclusões.
No Capítulo Fundamentação Teórica é exposto o conteúdo teórico do trabalho
fundamentado nas bibliografias indicadas no próprio texto. Este capítulo está dividido em cinco
sessões:
• Segurança de computadores: Descrição sobre os aspectos da segurança dos
computadores;
• Modelo RBAC de controle de acesso: Características sobre o modelo de controle de
acesso baseado em papéis;
• Software livre: Informações sobre funcionamento das licenças de software;
• Sistemas Linux: Informações sobre funcionamento do sistema operacional Linux.
• Ferramentas existentes: uma descrição sobre as ferramentas Webmin, Cpanel e
Webtools, bem como um comparativo das mesmas.
4
No Capítulo Projeto é apresentada a proposta de desenvolvimento do sistema. Este capítulo
está dividido em sete sessões:
• Empresa GrupoW: Descrição sobre a empresa, etapas do funcionamento atual e
problemas encontrados.
• O sistema de gerenciamento: Descrição das funcionalidades do sistema.
• Linguagens Utilizadas: Informações sobre as linguagens utilizadas para o
desenvolvimento do sistema.
• Modelagem: Descrição dos diagramas use-case e dicionário de dados.
• Telas do sistema: Descrição das telas e funcionalidades.
• Documentação: Informações sobre as técnicas utilizadas para aumentar a segurança e
confiabilidade do sistema.
• Testes: Descrição dos testes realizados
No Capítulo Conclusões são expostas algumas considerações gerais sobre o trabalho
desenvolvido.
5
2. FUNDAMENTAÇÃO TEÓRICA
Esse TCC é fundamentado em livros, conteúdo digital em sites e principalmente em
monografias e artigos publicados em eventos científicos.
2.1. SEGURANÇA DE COMPUTADORES
Ao se conectar um computador a uma rede, são necessárias providências para se certificar
que esta nova máquina conectada possa não vir a ser um “portão” que servirá de entrada para
invasores, ou seja, de pessoas que estão mal intencionadas, procurando prejudicar alguém ou até
mesmo paralisar a rede inteira. (SOARES, 1995).
Embora haja sistemas que conseguem fornecer um grau de segurança elevado, mesmo sendo
bem configurado ainda estará vulnerável.
Aparentemente englobando tanto aspectos físicos quanto lógicos, essa definição sintetiza
bem o enfoque normalmente dado à segurança de computadores.
Diferentes pessoas possuem diferentes conceitos do que seja segurança computacional.
Como exemplo pode-se destacar a segurança da informação que busca reduzir os riscos de
vazamentos, fraudes, erros, uso indevido, sabotagens, roubo ou qualquer outra ameaça que possa
prejudicar os sistemas de informação ou equipamentos de um indivíduo ou organização.
Segundo Krause (1999) e Albuquerque (2002) um computador (ou sistema computacional) é
dito seguro se este atende a três requisitos básicos relacionados aos recursos que o compõem:
• Confidencialidade: garante que os usuários do sistema só podem ler informações para os
quais estejam autorizados; uma violação da confidencialidade é chamada de revelação
não autorizada ou vazamento de informação.
• Integridade: garante que o sistema não corrompa informações nem permita que elas
sejam modificadas de forma não-autorizada, independentemente do caráter malicioso ou
acidental das modificações.
• Disponibilidade: garante que os recursos do sistema estejam disponíveis para os seus
usuários legítimos; a violação da disponibilidade é chamada de negação de serviço.
Para garantir tais propriedades, meios de obtenção da segurança, ou seja, procedimentos
e/ou métodos empregados para capacitar um sistema a executar um serviço de acordo com a
especificação, também são descritos na literatura referente à tolerância à falhas. Dois grandes
grupos podem ser identificados (WEBER, 1996): técnicas de prevenção de falhas e técnicas de
tolerância à falhas. Os métodos do primeiro grupo visam impedir, a ocorrência ou introdução de
falhas no sistema. O segundo grupo é formado por técnicas com o objetivo de fornecer, a despeito
da ocorrência de falhas, um serviço que atenda às especificações do sistema onde as mesmas são
aplicadas. Fica claro que, pelo aspecto eminentemente defensivo da segurança, grande parte das
técnicas empregadas hoje para garantir a segurança dos sistemas está colocada no primeiro grupo
citado, como firewalls e sistemas criptográficos, por exemplo. Por outro lado, os atuais sistemas de
detecção de intrusão, são melhor enquadrados no segundo grupo.
2.1.1. Ameaças, vulnerabilidades e ataques
A detecção de intrusão é uma das áreas de maior expansão, pesquisa e investimento na
segurança em redes de computadores (LANDWEHR, 2001). Com o grande crescimento da
interconexão de computadores em todo o mundo, materializado pela Internet, é verificado um
conseqüente aumento nos tipos e no número de ataques a esses sistemas, gerando uma
complexidade muito elevada para a capacidade dos tradicionais mecanismos de prevenção.
Uma ameaça a um sistema computacional consiste em uma ação possível que, uma vez
concretizada, produziria efeitos indesejáveis sobre os dados ou recursos do sistema. Já
vulnerabilidade é definida como uma falha no projeto ou implementação de um software ou sistema
operacional, que quando explorada por um atacante resulta na violação da segurança de um
computador. Existem casos onde um software ou sistema operacional instalado em um computador
pode conter uma vulnerabilidade que permite sua exploração remota, ou seja, através da rede.
Portanto, um atacante conectado à Internet, ao explorar tal vulnerabilidade, pode obter acesso não
autorizado ao computador vulnerável. Por fim, um ataque a um sistema é uma ação tomada por um
intruso malicioso (ou, em alguns casos, um erro de operação por parte de um usuário inocente) que
envolve a exploração de determinadas vulnerabilidades de modo a concretizar uma ou mais
ameaças.
A figura 1 e a figura 2 informam em valores numéricos a quantidade de ataques ocorridos no
Brasil no período de Janeiro a Março de 2005, que foram reportados ao NIC BR Security Office,
7
entidade mantida pelo Comitê Gestor da Internet no Brasil, que responde aos ataques com
procedimentos legais de investigação.
Figura 1. Incidentes Reportados no Brasil no período de Janeiro a Março de 2005.
Fonte: NBSO (2005).
Figura 2. Tipos de ataques.
Fonte: NBSO (2005).
8
2.1.1.1. Engenharia social
A Engenharia Social é um termo utilizado para descrever um método de ataque, onde
alguém faz uso da persuasão, muitas vezes abusando da ingenuidade ou confiança do usuário, para
obter informações que podem ser utilizadas para ter acesso não autorizado a computadores ou
informações (WATER, 2000). O seguinte exemplo representa um caso de Engenharia Social: o
usuário recebe uma mensagem e-mail, onde o remetente é o gerente ou o departamento de suporte
do seu banco. Na mensagem ele diz que o serviço de Internet Banking está apresentando algum
problema e que tal problema pode ser corrigido se for executado o aplicativo que está anexado à
mensagem. A execução deste aplicativo apresenta uma tela análoga àquela utilizada para ter acesso
à conta bancária, aguardando a digitação da senha. Na verdade, este aplicativo está preparado para
furtar a senha de acesso à conta bancária e enviá-la para o atacante.
Este caso mostra um ataque típico de engenharia social, pois os discursos apresentados no
exemplo procuram induzir o usuário a realizar alguma tarefa e o sucesso do ataque depende única e
exclusivamente da decisão do usuário em fornecer informações sensíveis ou executar programas.
2.1.1.2. Hackers, crackers e intruders
O termo hacker é definido pela RFC 2828 (SHIREY, 2000), como sendo alguma pessoa
com um grande interesse e conhecimento em tecnologia, não utilizando eventuais falhas de
segurança descobertas em benefício próprio. O termo é usado erroneamente, especialmente pelos
jornalistas, como alguém que efetue crimes cibernéticos. O termo cracker ou intruder, esse sim, é
definido pela mesma RFC 2828 como sendo alguém que tente quebrar a segurança ou ganhar
acesso a sistemas de outras pessoas sem ser convidado. Não é obrigatoriamente uma pessoa com
grande conhecimento de tecnologia como um hacker.
Com o passar dos anos e a evolução da tecnologia, percebe-se uma grande mudança no
perfil do cracker. Segundo Ulbrich e Della Valle (2003) no passado, na sua maioria eram
especialistas em informática, com alto grau de conhecimento em sistemas operacionais, redes e
tecnologia em geral. Atualmente, devido a vários fatores como a grande facilidade de troca de
informações pela Internet, o enorme aumento de servidores na Internet sem o devido preparo quanto
à segurança, o surgimento das ferramentas automatizadas para invasão entre outros, percebe-se uma
grande diminuição do conhecimento técnico necessário para realizar um ataque ou uma invasão.
9
2.1.1.3. Vírus
Para os usuários em geral, qualquer tipo de código malicioso que apague os dados ou
atrapalhe o funcionamento dos computadores, é chamado de vírus. Mas atualmente, os chamados
vírus de computador são classificados em vários tipos, cada um com suas particularidades de
funcionamento, formas de contágio e disseminação (OLIVEIRA, 2000).
Os vírus propagam-se de várias maneiras: por disquetes ou CDs infectados, por downloads
feitos na Internet, executando-se arquivos anexos de e-mail e, ultimamente, apenas lendo-se um e-
mail infectado. Seus malefícios podem ser desde uma simples mensagem de protesto na tela do
computador infectado, a perdas totais dos dados gravados ou a sobrecarga da rede, impedindo seu
funcionamento ou gerando lentidão (REGGIANI, 2001).
2.1.1.4. Flood e nuke
O Flood é uma técnica utilizada para gerar lentidão ou até mesmo tornar um serviço
indisponível, ainda mais se o servidor alvo for de pequeno porte. Essa técnica consiste em enviar,
sem interrupções, diversos disparos de pacotes para o servidor com objetivo de causar um
“congestionamento” (WATER, 2000).
Já o Nuke é o nome que é dado para pacotes TCP, UDP, ou IP com anomalias, onde este
tipo de pacote pode fazer com que o servidor alvo se torne lento ou até mesmo chegue a travar
devido à dificuldade em conseguir identificar ou tratar corretamente o pacote.
2.1.1.5. Dns spoofing e sniffers
A idéia básica deste tipo de invasão é fazer com que o servidor DNS permita que máquinas
não autorizadas, que neste caso são as máquinas do invasor, passem a ser vistas pelo servidor DNS
como máquinas confiáveis à rede. Para este objetivo ser alcançado, o invasor deve ter controle do
host servidor de DNS, e saber o nome de uma máquina que o alvo confia. A partir disso, altera-se o
registro do DNS que mapeia o endereço IP da máquina confiável para o seu nome, modificando-o
para que tenha o endereço da máquina do invasor. A partir de então, o invasor terá acesso aos
serviços baseados em autenticação feita por nome (WATER, 2000).
Na grande maioria das redes, os pacotes são transmitidos para todos os computadores
conectados ao mesmo meio físico, e cada máquina é programada para somente tratar os pacotes
10
destinados a ela. Entretanto, é possível reprogramar a interface de rede de uma máquina para que
ela capture todos os pacotes que circulam pelo meio, não importando o destino. A interface de rede
neste caso opera em modo promíscuo, e esta técnica é denominada sniffing.
2.1.1.6. Falta de padrões técnicos
À medida que a internet passou a ser mais comercial, a IETF (Internet Engineering Task
Force) tornou-se mais indefinida. Esse órgão é responsável por definir diretrizes para a internet.
Cada vez mais fornecedores estão propondo suas versões proprietárias de produtos e tecnologias,
sem que haja uma homologação oficial da IETF (IETF, 2005). O objetivo dessas empresas é colocar
no mercado produtos com tecnologias proprietárias, o que garante um grande retorno financeiro.
2.1.1.7. Vulnerabilidades de produtos e software
Segundo Bernstein (1997) muitos produtos já vêm com falhas ainda não documentadas, seja
software ou hardware, o que pode vir a facilitar as tentativas de invasão. As falhas podem ser nos
projetos dos produtos, onde pode não ter havido uma preocupação com a segurança.
Muitos administradores optam pelas instalações padrão dos softwares, sem se darem conta
das possíveis falhas que essa instalação pode ter, como por exemplo, habilitar portas ou fornecer
privilégios a usuários que não os deveriam possuir.
Outro problema é a complexidade da instalação e da configuração, o que pode confundir ou
até mesmo passar despercebidos pelo administrador detalhes que seriam de vital importância para a
segurança do sistema. Deve-se ficar atento à documentação que geralmente acompanha a
distribuição dos produtos (HUGHES, 1995).
Umas das vulnerabilidades consideradas mais sérias são as causadas pelos usuários. Senhas
simples, de fácil adivinhação, nomes de parentes ou até senhas repetidas, são algumas das
vulnerabilidades. Contas inativas e não eliminadas do sistema podem ser entradas para ataques
hackers.
11
2.1.2. Políticas e mecanismos de segurança
Vários mecanismos de proteção são utilizados atualmente, desde medidas simples, como a
criação de cópias de segurança, até ferramentas complexas de detecção de intrusão. Segundo Weber
(1996) vale ressaltar que, assim como nenhum sistema é totalmente seguro, nenhum mecanismo de
segurança é perfeito. É muito importante o balanceamento de vantagens e desvantagens das
diferentes abordagens.
A política de segurança de um sistema computacional corresponde ao conjunto de regras que
estabelecem os limites de operação dos usuários no sistema; uma política sempre se aplica a um
sistema específico, e não a uma classe geral de sistemas. Já os mecanismos de segurança são
elementos responsáveis pela implantação de uma determinada política de segurança. Por exemplo,
uma política de segurança pode exigir que todos os usuários de um sistema sejam identificados
unicamente para fins de contabilidade; mecanismos para implantar esta política incluem o uso de
senhas, de cartões magnéticos e de dispositivos de reconhecimento de impressões digitais.
2.1.2.1. Logs
Todos os servidores Web têm a capacidade de registrar, em um arquivo de log, a sua
interação com os clientes. Toda vez que um servidor responde a uma solicitação HTTP, ela é
registrada no arquivo de log. Apesar de um registro ser feito para cada requisição, o servidor está
atendendo várias solicitações de vários usuários simultaneamente (OLIVEIRA, 2000).
Por isso, as entradas para uma sessão particular (todas as requisições feitas por um usuário),
não são contíguas. Os registros individuais de uma sessão estarão espalhadas por todo o arquivo de
log do servidor.
2.1.2.2. Criptografia
Um dos mecanismos de segurança mais antigos, utilizado cada vez mais nos dias de hoje, é
a criptografia. Surgida há mais de 2000 anos atrás, reapareceu como impulsionadora dos
computadores modernos, durante a 2a. Guerra Mundial. Desde então, métodos computacionais
eficientes foram desenvolvidos para garantir a confidencialidade das informações trocadas entre
duas entidades - a garantia de que somente as duas partes envolvidas consigam compreender os
dados transmitidos - e a autenticidade dessas entidades - a garantia de que as partes envolvidas não
terão suas identidades forjadas por uma terceira (LANDWEHR, 2001).
12
2.1.2.3. Certificado digital
O Certificado Digital, também conhecido como Certificado de Identidade Digital associa a
identidade de um titular a um par de chaves eletrônicas (uma pública e outra privada) que, usadas
em conjunto, fornecem a comprovação da identidade. É uma versão eletrônica (digital) de algo
parecido a uma Cédula de Identidade - serve como prova de identidade, reconhecida diante de
qualquer situação onde seja necessária a comprovação de identidade (PANETTA, 2001).
O Certificado de Identidade Digital é emitido e assinado por uma Autoridade Certificadora
Digital (Certificate Authority). Para tanto, esta autoridade usa as mais avançadas técnicas de
criptografia disponíveis e de padrões internacionais (norma ISO X.509 para Certificados Digitais),
para a emissão do selo digital dos Certificados de Identidade Digital.
2.1.2.4. SSL (secure socket layer)
O SSL fornece criptografia de dados, autenticação de servidor e integridade de mensagem
para transmissão de dados pela Internet. O SSL versão 2.0 suporta apenas autenticação de servidor,
ao passo que a versão 3.0 suporta a autenticação tanto de cliente como de servidor (SSL, 2005).
Os dados protegidos pelo protocolo envolvem o uso de codificação e decodificação dos
dados transmitidos, portanto, o uso do SSL envolve uma carga extra. Seu uso aumenta a quantidade
de dados transmitidos, tornando mais lenta à transmissão de informações entre o servidor e o
browser (navegador). Entretanto, ele pode ser implementado no nível da página da Web. Ou seja,
não é necessário implementar proteção do protocolo para cada página de um site na Web que
forneça proteção de SSL. O método mais comum da sua implementação para aplicações de
comércio eletrônico é proteger com o SSL apenas aquelas páginas que contêm informações
confidenciais e sensíveis, tais como informações pessoais e de cartão de crédito
(COMPUTERWORLD, 2005).
2.1.2.5. Firewall
Outro mecanismo muito importante e difundido é o chamado firewall (ZWICKY, 2000). O
objetivo básico da implementação de um firewall é defender a organização de ataques externos.
Como efeito secundário, ele também pode ser utilizado para regular o uso de recursos externos
pelos usuários internos. Entretanto um firewall não pode proteger contra ataques internos ou mesmo
13
contra vírus. A figura 3 mostra o funcionamento básico de um firewall, onde todo o tráfego de
entrada e saída de rede utiliza um computador “filtro” (firewall) para transmissão das informações.
Figura 3. Exemplo de controle de acesso à Internet utilizando um firewall.
Fonte: Adaptado de ACME (2005)
Mecanismos de autenticação são, também, imprescindíveis na segurança de uma
organização. Sua função é fornecer formas seguras de identificação, tanto para usuários como para
hosts. Soluções como o uso de senhas comuns, senhas não reusáveis (one time passwords),
criptografia assimétrica, dentre outras, são exemplos de implementações desses mecanismos.
2.1.2.6. Auditoria
Como parte da estratégia de segurança geral, deve-se determinar o nível de auditoria
apropriado para o ambiente. A auditoria deve identificar ataques, com êxito ou com falha, que
representem uma ameaça para a rede ou que estejam voltados para recursos considerados valiosos
na avaliação de riscos. Ao decidir os critérios da auditoria, quanto mais detalhada for a auditoria,
mais eventos serão gerados e aumentará a dificuldade para identificar os eventos críticos (DIAS,
2000).
Os eventos de auditoria podem ser divididos em duas categorias: eventos com êxito e
eventos com falha. Um evento com êxito indica que um usuário conseguiu obter o acesso a um
recurso; um evento com falha indica que o usuário tentou, mas fracassou.
14
Os eventos com falha são muito úteis para rastrear tentativas de ataques no ambiente, mas a
interpretação dos eventos com êxito é muito mais difícil. Embora a grande maioria dos eventos de
auditoria com êxito sejam simplesmente indicações de atividade normal, um atacante que consegue
obter acesso a um sistema também gerará um evento com êxito. Com freqüência, um padrão de
eventos é tão importante quanto os eventos em si. Por exemplo, uma série de falhas seguidas por
um êxito pode indicar uma tentativa de ataque que, por fim, teve êxito.
2.1.2.7. Administrador de segurança
Em um mundo onde a dependência da informática cresce dia a dia, onde o número de vírus
aumenta constantemente e os casos de invasões de crackers crescem exponencialmente, cresce a
importância do Security Officer (Administrador de Segurança). Esse profissional é definido pela
RFC 2828 (SHIREY, 2000) como sendo a pessoa responsável pela aplicação ou administração da
política de segurança aplicada ao sistema.
Lopes (2001) acrescenta, definindo o Security Officer: departamento independente da
corporação, ligado diretamente à diretoria. Não está ligado nem ao setor de informática nem ao
setor de auditoria. Acrescenta também que a função do Security Officer é a de "manter e garantir
que a política de segurança da empresa esteja sendo realmente seguida pela companhia".
Atualmente, este tipo de cargo é ocupado principalmente por gerentes de tecnologia que se
aperfeiçoam em segurança com cursos de especialização ou provas de certificação.
2.2. CONTROLE DE ACESSO BASEADO EM PAPÉIS
O conceito de controle de acesso baseado em papéis (role-based access control - RBAC)
surgiu com os primeiros sistemas computacionais multiusuários interativos, no início da década de
70. Nos últimos anos, o RBAC vem sendo reconhecido como uma forma de controle de acesso
diferenciada dos tradicionais esquemas discricionário e obrigatório.
Estudos conduzidos nos Estados Unidos pelo NIST (National Institute of Standards and
Technology) no início da década de 90 (FERRAIOLO, 2001) mostram que boa parte das
organizações deseja que o controle de acesso à informação seja feito segundo uma política
centralizada e de forma flexível, possibilitando fácil adaptação a novos requisitos que surgem
naturalmente com a evolução organizacional.
15
Para Ferraiolo (2001), o RBAC é composto por quatro elementos básicos:
1. Usuários - pessoa responsável pelo uso do sistema;
2. Permissões - são as regras (aprovações) que o usuário recebe para utilização do sistema;
3. Papéis - função relacionada à responsabilidade de um usuário;
4. Sessão - mapeamento entre o usuário e os papéis relacionados a ele.
Partindo do princípio fundamental do RBAC, mostrado na figura 4, permissões de acesso
são associadas a papéis, e estes papéis são associados a usuários. Papéis são criados de acordo com
os diferentes cargos ou funções em uma organização, e os usuários são associados a papéis de
acordo com as suas responsabilidades e qualificações. Este esquema possibilita que um usuário
possa ser membro de vários papéis, e um papel pode ter vários usuários. Da mesma forma, um papel
pode ter muitas permissões e as mesmas permissões podem estar associadas com vários papéis.
Figura 4. Visão geral do RBAC.
Fonte: Adaptado de Ferraiolo. (2001)
O modelo RBAC oferece um controle mais flexível do que os modelos discricionários e
obrigatórios para o estabelecimento de políticas de autorização. Possui uma série de funcionalidades
e propriedades não cobertas pelos modelos tradicionais de controle de acesso. Se isto por um lado
aumenta a riqueza e a capacidade da descrição de políticas de segurança, por outro lado aumenta a
complexidade da formalização do próprio modelo. Esta característica cria a necessidade de
refinamentos e de divisão do modelo em submodelos, para que seja possível explorar as várias
dimensões do RBAC.
16
O NIST definiu quatro tipos de componentes distintos de modelos RBAC, os quais são
(FERRAIOLO, 2001): RBAC Core, RBAC Hierárquico, RBAC com Restrições e RBAC Simétrico.
2.2.1. Modelo RBAC core
Dentre os quatro componentes definidos pelo NIST, o RBAC Core é o mais simples pelo
fato de definir apenas os elementos mínimos do modelo RBAC. No entanto, isto não quer dizer que
ele seja menos seguro ou menos eficiente. O que diferencia todos os componentes são as opções de
gerenciamento de atribuições de papéis e permissões, como também outros mecanismos adicionais
de restrição de acesso.
A escolha do componente para a implementação de um sistema depende fundamentalmente
das necessidades da política de segurança a ser adotada e, conseqüentemente, das funcionalidades
que cada componente oferece.
Este componente inclui a atribuição de papéis a um usuário e a atribuição de permissões a
um papel, as quais são características fundamentais do modelo RBAC, conforme pode ser visto na
figura 5. Além destas características, ele possui o conceito de ativação de papéis através da sessão
do usuário no sistema.
Figura 5. RBAC Core.
Fonte: Adaptado de Ferraiolo. (2001)
As especificações funcionais do RBAC são funções necessárias para a criação e manutenção
dos componentes do modelo RBAC Core. Segundo Ferraiolo (2001), existem três categorias de
funções para o modelo RBAC: a) Funções Administrativas b) Funções de Suporte ao Sistema e c)
Funções de Revisão. Cada componente do RBAC possui, dentro destas três categorias, um conjunto
específico de funções.
17
2.2.2. Modelo RBAC hierárquico
RBAC hierárquico adiciona exigências para suportar hierarquias do papel. Uma hierarquia é
matematicamente uma ordem parcial que define uma relação da descendência entre papéis, por
meio de que os papéis com mais privilégio adquirem as permissões dos papéis inferiores. Este tipo
de hierarquia permite a agregação de permissões de diferentes papéis em um outro papel;
entretanto, ela não possibilita o compartilhamento de permissões através de um papel.
A figura 6 mostra um exemplo de hierarquia geral, o Gerente Pessoa Física tem, além de
suas próprias permissões, as permissões herdadas de Contas P. Física e Poupança P. Física. O
Gerente de Agência tem as suas permissões e mais as de Gerente Pessoa Física e Gerente Pessoa
Jurídica. Neste caso, tanto a agregação quanto o compartilhamento de permissões são possíveis.
Figura 6. RBAC Hierárquico.
Fonte: Adaptado de Ferraiolo. (2001)
O RBAC Hierárquico exige que a atribuição usuário-papel do RBAC Básico seja estendido
para suportar hierarquias de papéis. Neste modelo, a atribuição deve permitir a identificação tanto
dos papéis associados diretamente a um usuário (definidos pelo administrador de segurança) como
dos papéis associados indiretamente ao usuário (cuja associação se dá através de herança)
(FERRAIOLO, 2001).
18
2.2.3. Modelo RBAC com restrições
Para que seja possível respeitar a separação de tarefas, é necessário atender o princípio do
mínimo privilégio na definição dos papéis, ou seja, para que a separação de tarefas seja atingida
através do RBAC, os papéis têm que estar associados ao mínimo de permissões necessárias ao
cumprimento de suas tarefas. A separação de tarefas é suportada pelo modelo RBAC com
Restrições.
2.2.3.1. Separação Estática de Tarefas
A separação estática de tarefas (SET) é usada para reforçar o conflito de políticas de
interesse. O conflito de interesse em um sistema baseado em papel pode gerar conseqüências para
um usuário que ganha a autorização para as permissões associadas com papéis não atribuídos a ele.
Nesta abordagem, usuários associados a um papel não podem ser associados a um segundo papel,
de acordo com restrições definidas pelo administrador de segurança, e estas restrições se propagam
através de uma hierarquia de papéis, conforme visto na figura 7.
É importante salientar que, para que seja possível respeitar a separação de tarefas (ST), é
necessário atender o princípio do mínimo privilégio na definição dos papéis, ou seja, para que a
separação de tarefas seja atingida através do RBAC (OBELHEIRO, 2001), os papéis têm que estar
associados ao mínimo de permissões necessárias ao cumprimento de suas tarefas.
Figura 7. RBAC com Separação Estática de Tarefas.
Fonte: Adaptado de Ferraiolo. (2001)
19
2.2.3.2. Separação Dinâmica de Tarefas
A separação dinâmica de tarefas (SDT), em relação à SET, limita as permissões que estão
disponíveis a um usuário. Entretanto as relações da SDT diferem das relações da SET pelo
contexto em que estas limitações são impostas, conforme visto na figura 8. Nesta abordagem, os
usuários podem ser associados a papéis que só constituem um conflito de interesse quando ativados
simultaneamente, isto é, é perfeitamente possível e seguro que um usuário ative mais de um papel
do conjunto, desde que esta ativação não seja simultânea (FERRAIOLO, 2001).
Pode-se ter como exemplo, um usuário ser associado aos papéis Contador e Contador-Chefe,
onde o Contador lança os registros contábeis e o Contador-Chefe pode efetuar correções em lotes de
lançamentos ainda não consolidados. Se um usuário agindo como Contador tentasse ativar o papel
Contador-Chefe, ele teria que desativar primeiro o papel Contador, forçando a consolidação dos
lançamentos antes que o indivíduo assumisse o papel Contador-Chefe.
Figura 8. RBAC com Separação Dinâmica de Tarefas.
Fonte: Adaptado de Ferraiolo. (2001)
2.3. SOFTWARE LIVRE
Software Livre (Free Software) é o software disponível com a permissão para qualquer
usuário usá-lo, copiá-lo, e distribuí-lo, seja na sua forma original ou com modificações, seja
gratuitamente ou com custo. Em especial, a possibilidade de modificações implica em que o código
fonte esteja disponível. Se um programa é livre, potencialmente ele pode ser incluído em um
sistema operacional também livre (GNU, 2005). É importante não confundir software livre com
software grátis porque a liberdade associada ao software livre de copiar, modificar e redistribuir
20
independe de gratuidade. Existem programas que podem ser obtidos gratuitamente, mas que não
podem ser modificados, nem redistribuídos.
2.3.1. Propriedade intelectual
Todo produto de software é derivado de atividade intelectual, e como tal, é protegido por um
conjunto de leis que tratam de propriedade intelectual, ou copyright. O conceito fundamental do
copyright é simples: o autor original do trabalho determina a forma pela qual sua obra será
utilizada. Mais especificamente, copyright permite ao autor determinar direitos de uso, cópia,
modificação e distribuição (incluindo aluguel, empréstimo e transmissão), entre outros
(ENGELFRIET, 2002).
O copyright tem um prazo de validade, após o qual o uso da obra se torna completamente
irrestrito (o chamado domínio público). As condições e direitos específicos do autor são
determinados pela legislação de copyright de cada país, grande parte deles sendo membros da
World Intellectual Property Organization (WIPO, 2005), a organização que consolida as diretrizes
internacionais de copyright.
2.3.2. Licenças de software
É comum o uso de licenças de software para determinar mais especificamente a forma como
um software pode ser usado. A licença é um documento (não necessariamente registrado ou
validado com nenhum órgão ou organização) veiculado junto ao software, que determina as
condições pelas quais pode ser utilizado. Baseiam-se integralmente nos termos especificados pelas
leis de copyright, e normalmente é elaborada por alguém que tenha boa compreensão dos aspectos
legais envolvidos (ENGELFRIET, 2003).
2.3.2.1. Graus de Restrição em Licenças de Software
Segundo GNU (2005) e Hexsel (2002) os softwares podem ser classificados como:
• GPL A Licença Pública Geral é a licença que acompanha os pacotes distribuídos pelo
Projeto GNU, e mais uma grande variedade de software, incluindo o núcleo do sistema
operacional Linux. A formulação da GPL é tal que ao invés de limitar a distribuição do
software por ela protegido, ela de fato impede que este software seja integrado em
21
software proprietário. A GPL é baseada na legislação internacional de copyright, o que
deve garantir cobertura legal para o software licenciado com a GPL.
• Debian A licença Debian é parte do contrato social celebrado entre a Debian e a
comunidade de usuários de software livre, e é chamada de Debian Free Software
Guidelines (DFSG). Os critérios para uso são: (a) a redistribuição deve ser livre; (b) o
código fonte deve ser incluído e deve poder ser redistribuído; (c) trabalhos derivados
devem poder ser redistribuídos sob a mesma licença do original; (d) pode haver
restrições quanto à redistribuição do código fonte, se o original foi modificado; (e) a
licença não pode discriminar contra qualquer pessoa ou grupo de pessoas, nem quanto a
formas de utilização do software; (f) os direitos outorgados não podem depender da
distribuição onde o software se encontra; e (g) a licença não pode 'contaminar' outro
software.
• Open Source A licença do Open Source Initiative é derivada da Licença Debian, com
as menções à Debian removidas.
• BSD A licença BSD abrange as distribuições de software da Berkeley Software
Distribution, além de outros programas. Esta é uma licença considerada 'permissiva'
porque impõe poucas restrições sobre a forma de uso, alterações e redistribuição do
software licenciado. O software pode ser vendido e não há obrigações quanto à inclusão
do código fonte, podendo o mesmo ser incluído em software proprietário. Esta licença
garante o crédito aos autores do software, mas não tenta garantir que trabalhos derivados
permaneçam como software livre.
• Software em Domínio Público Software em domínio público é software sem copyright.
Alguns tipos de cópia, ou versões modificadas, podem não ser livres porque o autor
permite que restrições adicionais sejam impostas na redistribuição do original ou de
trabalhos derivados.
• Freeware O termo freeware não possui uma definição amplamente aceita, mas é usado
com programas que permitem a redistribuição, mas não a modificação, e seu código
fonte não é disponibilizado. Estes programas não são softwares livre.
• Shareware Shareware é o software disponibilizado com a permissão para que seja
redistribuído, mas a sua utilização implica no pagamento pela sua licença. Geralmente, o
código fonte não é disponibilizado e, portanto modificações são impossíveis.
22
• Software Proprietário Software proprietário é aquele cuja cópia, redistribuição ou
modificação são proibidos pelo seu proprietário. Para usar, copiar ou redistribuir deve-se
solicitar permissão ao proprietário, ou pagar para poder fazê-lo.
• Software Comercial Software comercial é o software desenvolvido por uma empresa
com o objetivo de lucrar com sua utilização. A maioria do software comercial é
proprietário, mas existe software livre que é comercial, e existe software não-livre não-
comercial.
2.4. SISTEMA OPERACIONAL LINUX
O Linux é um sistema operacional originalmente desenvolvido em 1991 por Linus Torvalds,
um finlandês do Departamento de Ciência da Computação da Universidade de Helsinki. Linux não
é um software de domínio público, mas é distribuído sob a GNU General Public License, que
preserva a disponibilidade do seu código fonte. Ou seja, o código fonte do Linux deve estar sempre
disponível para usuário. Pode-se cobrar pela cópia do Linux, se desejar, desde que, com isso, não
limite a distribuição do mesmo.
Os sistemas operacionais Linux são disponibilizados através de “distribuições” que é o
nome dado a um conjunto de programas constituído por um kernel (núcleo) do Linux e uma
variedade de outros softwares para esta plataforma, chamados "pacotes", normalmente distribuídos
de uma forma personalizada pela empresa ou grupo distribuidor. Existem diversas distribuições,
dentre elas pode-se citar: Slackware, Red Hat, Conectiva Linux, S.U.S.E e Debian. Cada
distribuição tem suas particularidades, umas são mais amigáveis, outras menos, outras são mais
fáceis de instalar ou atualizar, outras mais complicadas. Estas distribuições geralmente
desenvolvem programas instaladores e configuradores personalizados, de forma a tornar mais fácil
e amigável as tarefas no Linux, porém o núcleo do sistema é o mesmo para todas elas.
Por ser um software aberto, alertas para qualquer possível problema de segurança ou falha
nos programas são distribuídos imediatamente pela Internet em busca de soluções, não sendo
necessário esperar meses para que um fabricante ou desenvolvedor crie uma solução. Além disso,
algumas outras vantagens são visíveis na utilização de sistemas Linux (BALL e DUFF, 2003):
23
• Flexibilidade – Por ter acesso ao código fonte, ele é facilmente personalizável.
• Confiabilidade - Seus problemas são corrigidos rapidamente pelos usuários que possuem
acesso ao código livre, e sua arquitetura fundamental o torna mais confiável.
• Economia – Por ser código aberto não é preciso pagar para adquiri-lo.
Segundo Ball e Duff (2003), os principais usos do Linux são como servidor de páginas da
Web, servidor FTP, servidor de e-mail, servidor de nomes (DNS) ou roteador (gateway) entre
LANs e a Internet.
2.4.1. Composição e serviços
No Linux existe o conceito de permissões de acesso. Como ele é desenvolvido para um
ambiente multiusuário (rede), foram criadas permissões para que determinados usuários e serviços
tenham acesso somente aquilo para o qual podem ter acesso, e estas permissões estão ligadas à
contas, onde uma conta é a maneira com a qual o usuário se identifica no sistema. Toda esta
interligação de usuários, contas e permissões, possibilita o funcionamento dos chamados Serviços
(programas responsáveis por tarefas específicas) e do Sistema Operacional.
O núcleo do sistema operacional (kernel) é o responsável por gerenciar todas as tarefas do
sistema. O kernel de um sistema operacional apesar de ser o principal programa em um
computador, não caracteriza um sistema operacional completo (FSF, 2005). Ele faz o principal
trabalho, administrando os recursos de hardware (CPU, memória, discos, etc.). Mas outros
programas denominados aplicativos, são os responsáveis pelas tarefas "visíveis" aos usuários
(editores de texto, compiladores, navegadores, e etc.).
2.4.2. DNS
O DNS (Domain Name System - Sistema de Nomes de Domínios) é um sistema de
gerenciamento de nomes hierárquico e distribuído e opera segundo duas definições: a primeira é
examinar e atualizar seu banco de dados e a segunda, reproduzir a informação do banco de dados
entre servidores.
DNS começou quando a Internet era uma pequena rede estabelecida pelo Departamento de
Defesa para propósitos de pesquisa. O endereçamento dos computadores nesta rede era
24
administrado por um único arquivo de hosts localizado em um único servidor central. Cada rede que
precisasse solucionar nomes de hosts em outras redes carregava este arquivo. Como o número de
hosts na Internet cresceu, o tráfego gerado pelo processo de atualização bem como o tamanho do
arquivo de hosts também, com isso, surgiu à necessidade de um novo sistema que oferecesse
características como a escalabilidade aliada à administração descentralizada.
O DNS originalmente estava baseado nas RFCs 882 (Conceitos de Domínio e instalações) e
883 (Implementação de Domínio e Especificação) que foram substituídas depois pelas 1034
(Conceitos de Domínio e Instalações) e 1035 (Implementação de Domínio e Especificação).
Existem outras que descrevem a segurança, implementação e partes administrativas do DNS
(INTERNIC, 2005).
O DNS existe porque as aplicações utilizam endereços IP, porém os usuários preferem
identificar as máquinas através de nomes ao invés de números. Assim é necessário um banco de
dados que permita a uma aplicação encontrar um endereço, dado que ela conhece o nome da
máquina com a qual se deseja comunicar. Um conjunto de servidores de nomes mantém o banco de
dados com os nomes e endereços das máquinas conectadas à Internet. Os servidores de nome
formam uma árvore, correspondendo à estrutura institucional. Os nomes também adotam uma
estrutura similar. Um exemplo típico é o nome www.exemplo.com.br. Para encontrar seu endereço
na Internet, pode ser necessário o acesso a até quatro servidores de nomes. Inicialmente deve ser
consultado um servidor central, denominado servidor raiz, para descobrir onde esta o servidor
correspondente ao país solicitado (servidor .br). O servidor br é o responsável pela gerência dos
nomes das instituições/empresas brasileiras ligadas a Internet (DNS, 2005).
A figura 9 mostra as abreviações existentes e são reservadas para uso através de
organizações. Existem também no último nível de abreviações, antes dos nomes das entidades
finais, abreviações contendo de dois a três caracteres que representam os países.
25
Figura 9. Árvore de localização de domínios.
Fonte: Adaptado de Santos (2004)
O Software BIND (Berkeley Internet Name Domain) é um sistema cliente/servidor, usado
pelas diversas distribuições Linux e Unix, atualmente a versão do BIND está na 9.3.1, porém muitas
pessoas ainda utilizam a versão 4 do BIND, o que não é aconselhável, já que diversos bugs já foram
encontrados nessa versão mais antiga do BIND.
O cliente do BIND é denominado Resolver, cuja função é estruturar solicitações de
hostnames e envia–las até um servidor DNS. O servidor do BIND é denominado Named, um
processo distint, cuja função é responder as solicitações enviadas pelo Resolver.
A estrutura do arquivo named.conf é similar à um código fonte em C, as instruções
terminam em (;), entradas relacionadas ficam dentro de chaves {} e instruções exatas ficam entre
aspas “”.
26
Algumas instruções e suas respectivas funções podem ser vistas a seguir:
• acl Define uma lista de controle de acesso aos endereços IP
• zone Define a zona
• include Define a inclusão de um arquivo no arquivo de configuração
• options Define as opções globais
• server Define as características de um servidor remoto
• logging Define o que será logado e onde será logado
• key Define chaves para autentificação
2.4.3. FTP
O serviço FTP (File Transfer Protocol) é o serviço padrão da Internet para a transferência de
arquivos entre computadores. A partir dele usuários podem obter ou enviar arquivos de ou para
outros computadores da Internet. O funcionamento do FTP se baseia no estabelecimento de uma
sessão limitada entre o cliente FTP local e o servidor FTP do equipamento remoto. Esta sessão é
autenticada de forma semelhante ao serviço Telnet, possuindo apenas comandos referentes à
manipulação de diretórios e arquivos. O usuário pode pesquisar a estrutura de arquivos do
equipamento remoto antes de executar as transferências desses arquivos (POSTEL e REYNOLDS,
1985).
A utilização mais comum do serviço FTP na Internet é a de obtenção de programas ou
informações a partir de servidores de domínio público ou comercial, serviço conhecido como FTP
Anônimo (Anonymous FTP). Para esse serviço, o servidor FTP oferece uma conta especial (conta
anonymous como nome de login) com autenticação flexível (normalmente a senha é apenas o
endereço de correio eletrônico do usuário). Uma sessão de FTP anônimo possui acesso restrito aos
arquivos que podem ser consultados ou transferidos para o computador do usuário (POSTEL e
REYNOLDS, 1985).
O protocolo data de 1971, antes da popularização da Internet, mas continua muito utilizado,
sendo considerado o padrão da Internet para transferência de arquivos. Os objetivos do FTP são:
27
• Promover o compartilhamento de arquivos (como programas de computadores e/ou
dados);
• Encorajar o uso remoto de computadores;
• Tornar transparente para os usuários as variações nos sistemas de arquivos nos diversos
computadores;
• Transferir dados eficientemente.
2.4.4. HTTP
O protocolo HTTP (Hypertext Transfer Protocol – Protocolo para Transferência de
Hipertexto) é o protocolo padrão para a World Wide Web (WWW). Definido pela RFC 2616 (IETF,
2005), tem como objetivo principal transportar documentos HTML. Devido ao aumento do uso da
Web, várias aplicações têm usado este protocolo como meio de comunicação entre o servidor e o
cliente da aplicação. Em grande parte das aplicações, é necessário que haja um mecanismo de
autenticação que permita a identificação de usuários aptos a usarem a aplicação.
O HTTP é um sistema de busca e obtenção de informações onde os caminhos de navegação
não são baseados nos títulos dos documentos e sim embutidos nesses documentos, mecanismo
conhecido como navegação por hipertexto. O HTTP cria a imagem de uma teia que interliga
documentos através da Internet (HTTP, 2005).
Os documentos componentes da Web podem conter também imagens e recursos de
multimídia, sendo também denominados como documentos hipermídia. A composição desses
documentos é estruturada na linguagem HTML (HiperText Markup Language), baseada em
diretivas em formato ASCII, que permitem definir o formato do documento e as ligações com
outros documentos (hiperlinks).
Um documento HTML ou uma outra informação é localizada na WWW através de um
identificador conhecido como URL (Universal Resource Location). A URL identifica o tipo de
servidor a ser acessado, o endereço do equipamento onde a informação reside, e a sua localização
nesse equipamento.
28
Para obtenção de um documento HTML ou outro tipo de informação, o cliente WWW
interage com o servidor WWW do equipamento onde reside a informação via o protocolo HTTP.
Uma vez obtido o documento, o cliente WWW é o responsável pela sua interpretação e visualização.
Os browsers Web normalmente interagem também com outros servidores de informação
(news, ftp, etc.), obtendo deles informações e as apresentando como se fossem documentos
hipertexto. Como exemplo de navegadores Web comumente usados tem-se programas: Internet
Explorer e Netscape Navigator; os servidores WWW mais comuns são: Apache e IIS (Microsoft)
(HTTP, 2005).
2.4.5. Apache
O Apache é o servidor Web mais utilizado no mundo em ambiente Linux que teve sua
origem de um projeto desenvolvido pela NCSA (National Center for Supercomputing Applications)
da Universidade de Illinois em 1995. Entretanto, a NCSA não desenvolveu muito o projeto, o que
levou alguns desenvolvedores insatisfeitos com isso a se juntarem e começarem a desenvolver uma
série de inovações em cima do código original do Web Server da NCSA. Disso surgiu o Apache,
que se tornou o servidor Web mais popular do mundo (APACHE, 2005).
Algumas características técnicas:
• Suporte a Secure Socket Layer (SSL) para transações seguras;
• Suporte a autenticação baseada em HTTP;
• Logs customizáveis;
• Configuração rápida e simples.
Aliada a sua extrema qualidade e robustez, o Apache tem uma vantagem que o torna muito
atraente: é gratuito. Por ser um software livre, seu código fonte também é livre e pode ser instalado
em vários servidores diferentes.
29
2.5. FERRAMENTAS DE ADMINISTRAÇÃO DE SERVIDORES
Apesar da necessidade dos administradores de redes e serviços, não são encontradas muitas
ferramentas para auxiliar na administração de servidores. Nas pesquisas realizadas foram
encontrados softwares que auxiliam os administradores localmente, e softwares de administração
remota. Os softwares encontrados estão divididos em duas categorias, a de software livre e a de
softwares proprietários e pagos.
Na seqüência, serão analisados dois softwares livres, (Webmin e Webtools) e um
proprietário (Cpanel).
2.5.1. Webmin
O Webmin é uma ferramenta de desenvolvimento livre criada para gerenciar sistemas
(servidores) UNIX, baseada numa interface web (WEBMIN, 2005). Com este utilitário pode-se
administrar máquinas pela rede através de um navegador Web comum. Ele é bem completo,
possuindo módulos para configuração de várias ferramentas para gerenciamento total de um
servidor Linux, como por exemplo, gerenciamento de servidores DNS, WEB, contas dos usuários,
acompanhamento e configuração do hardware.
Algumas das tarefas que podem ser realizadas utilizando o Webmin atualmente são
(WEBMIN, 2005):
• Mudar senhas, configurar o agendador de tarefas, configurar scripts de inicialização,
backup, configuração do autenticador, quotas, gerência de processos, pacotes, usuários e
grupos;
• Configurar e administrar servidores de e-mail, compartilhamento de arquivos, banco de
dados, acesso remoto apache, IPs dinâmicos, DNS, MySQL;
• Configurar rede, exportações NFS, NIS, PPP, túneis SSL;
• Administração de impressoras, gerenciadores de boot, cd-roms, gerenciamento de
discos, partições, clustering;
• Além de outras coisas como terminais via web, gerenciador de arquivos, módulos perl.
A figura 10 mostra a tela de controle de usuários. Nela pode-se definir quais áreas
administrativas e serviços cada usuário poderá manipular e ter acesso.
30
Figura 10. Tela de controle de acesso dos usuários.
Fonte: Adaptado de Webmin (2005)
A figura 11 mostra a tela de controle dos serviços WEB. Nela pode-se configurar domínios,
direcionar onde estarão localizados no servidor, e controlar o acesso WEB.
Figura 11. Tela de controle dos serviços WEB.
Fonte: Adaptado de Webmin (2005)
31
O Webmin é um software de administração de servidor, com todas as suas funcionalidades
voltadas para a administração remota, utilizando como interface um navegador (browser). Sua
interface é pouco amigável (requer conhecimento do usurário), divididas em setores e possui
diversos ícones para a configuração de serviços, verificação de logs, monitoramento a utilização do
disco entre outras. Com este software é possível realizar várias tarefas que um administrador faz
localmente.
2.5.2. Cpanel
Cpanel é um software onde o administrador e usuários comuns administram serviços de um
servidor. No Cpanel os usuários têm controle total dos recursos utilizados. Este controle é possível
através de senhas, e da definição das áreas de acesso do usuário, o que permite visualizar as
estatísticas do site, criar subdomínios (http://subdominio.seusite.com.br), criar domínios adicionais,
gerenciar arquivos, gerar backup e instalar scripts prontos (CPANEL, 2005).
A figura 12 mostra a tela de acesso às opções do programa. Nela pode-se ter acesso aos
serviços configurados para o usuário.
Figura 12. Visão da tela de acesso aos serviços disponibilizados.
Fonte: Adaptado de Cpanel (2005)
32
A figura 13 mostra a tela de controle do serviço de FTP. Nela pode-se ter acesso aos dados
de FTP do usuário, como senhas, diretórios e espaço utilizado.
Figura 13. Visão geral do controle de FTP.
Fonte: Adaptado de Cpanel (2005)
Por ser um software para usuários comuns e administradores, sua interface é bem elaborada
e de fácil acesso. Para utilizá-lo é necessário comprar licenças que variam de acordo com as
necessidades de utilização. Os valores destas licenças variam entre $100.00 a $1,500.00.
2.5.3. Webtools
Webtools é um pacote de ferramentas (scripts) que visam facilitar a administração de um
Servidor UNIX. Ele contém 15 scripts desenvolvidos, os quais têm o objetivo de gerenciar
servidores WEB, DNS e FTP (WEBTOOLS, 2005). O pacote webtools possui scripts interativos e
com parâmetros (tipo linha de comando).
É totalmente GPL, ou seja, pode ser livremente alterado e repassado, desde que os créditos
do autor sejam preservados, e todas as ferramentas podem ser modificadas e melhoradas, conforme
a vontade do administrador.
O Webtools não possui um pacote de instalação, porém é de fácil instalação tendo que
executar apenas quatro comandos. Seu problema é que auxilia o administrador em poucos serviços,
e funciona apenas localmente necessitando de outro serviço de conexão remota para ser executado.
33
2.5.4. Comparação entre as ferramentas
Todas as ferramentas analisadas cumprem as tarefas a que são designadas, porém cada uma
possui suas particularidades de instalação e requisitos de funcionamento. Estas restrições
prejudicam um nível maior de personalização e até mesmo de segurança.
A Tabela 1 mostra um comparativo das funcionalidades avaliadas, nas ferramentas Webmin,
Cpanel e Webtools.
Tabela 1. Comparativo entre o Webmin, Cpanel e Webtools.
Webmin Cpanel Webtools Plataformas Família UNIX e BSD, Sun
Java Desktop System, Mac OS X, IBM AIX, Solaris
Família UNIX e BSD Família UNIX e BSD
Requisitos de sistema
Pentium III 300 MHz 4 GB de espaço em disco 256 MB RAM
Pentium III 266 MHz 3 GB de espaço em disco 256 MB RAM
Pentium II 200 MHz 100 MB de espaço em disco 256 MB RAM
Valor Gratuito Pago $100,00 a $1.500,00. Gratuito Método de controle de acesso
RBAC Não especificado Controle pelo sistema operacional
Interface Gráfica, via web Gráfica, via web Modo texto, via terminal Funcionamento CGI CGI Código Shell (linha de
comando) Instalação Compilação/configuração dos
módulos. Compilação/configuração dos módulos.
Possui instalador
Versão Atual 1.21 9.0 1.4 Problemas (BUGS) Corrigidos pelo desenvolvedor
nas novas versões / ou pelas atualizações dos módulos.
Corrigidos pelo desenvolvedor nas novas versões.
Não possui suporte
Gerência Possibilita a gerência remota total do servidor, através da instalação de módulos para cada serviço. Cada usuário possui um login de acesso.
Possibilita a gerência dos serviços no servidor. Cada usuário recebe um login de acesso às áreas definidas pelo administrador.
Possibilita apenas o gerenciamento dos serviços de DNS, FTP e WEB.
Segurança Possui alguns problemas relativos a vulnerabilidades dos serviços e dos módulos (SECURITYFOCUS, 2005) (SECUNIA, 2005)
Possui alguns problemas relativos a vulnerabilidades de acesso (SECURITYFOCUS, 2005) (SECUNIA, 2005)
Segundo desenvolvedor pode haver problemas não detectados.
Usabilidade Interface confusa e complexa, para pessoas sem conhecimento.
Interface simples de utilizar Comandos via terminal, sem muita interação.
Personalização Pouco nível de personalização. Somente pessoas especializadas e habilitadas realizam alterações.
Sem personalização. Pode-se pagar para adquirir novos módulos.
Totalmente personalizável, fácil de ser adaptado.
34
Baseado nas análises realizadas sobre as ferramentas existentes, pode-se extrair algumas
conclusões sobre seus pontos fortes e fracos. O Webmin geralmente é utilizado pelo administrador
do servidor para auxiliá-lo nas tarefas de administração. Sua utilização requer algum conhecimento
e possui uma abrangência quase total dos serviços em funcionamento no servidor. Isto o torna
complexo. O Cpanel por ser uma ferramenta comercial, sua interface é voltada para usuários leigos
e administradores. Ele é de fácil utilização, permite gerência de vários serviços no servidor, porém
não permite personalizações e é pago. Já o Webtools é uma ferramenta de uso não comercial,
simples e de fácil adaptação, porém não possui um sistema com interface para o gerenciamento.
Também é bastante limitada na sua utilização.
Após o estudo de todos os fundamentos relativos à segurança de computadores, mecanismos
de controle de acesso, sistemas Linux e os serviços a ele relacionados, pode–se compreender o
complexo funcionamento das ferramentas de administração de servidores existentes no mercado.
Por serem escassas e de difícil desenvolvimento, as ferramentas existentes procuram atender de uma
forma global, todas as necessidades do usuário, o que às vezes as tornam complexas e com
problemas de segurança.
É freqüente encontrar falhas de segurança nas ferramentas Webmin e Cpanel, que muitas
vezes são logo corrigidas pelos desenvolvedores. Alguns exemplos de falhas podem ser verificados
na ferramenta Webmin, onde foi descoberta uma falha que por ataques remotos, o usuário consegue
burlar as regras de segurança e tem acesso a leitura aos arquivos de configuração dos módulos.
Também foi encontrado um problema no qual o sistema não analisa gramaticalmente determinados
conjuntos de caracteres, o que permite que os atacantes remotos conduzam um ataque de força bruta
para descobrir os usuários e senhas (SECURITYFOCUS, 2005).
Já na ferramenta Cpanel um problema encontrado no Apache (servidor Web) quando
atualizado pelo módulo do Cpanel permite que todo o usuário execute um código arbitrário como
qualquer outro usuário (SECURITYFOCUS, 2005).
Para usuários que necessitam de ferramentas personalizadas, a única opção é recorrer a
empresas especializadas que desenvolvam a ferramenta específica para o usuário. Todavia nem
sempre estas ferramentas personalizadas serão desenvolvidas seguindo os princípios de controle e
segurança desejados pelo usuário.
35
2.5.5. Trabalhos científicos relacionados
Durante a pesquisa de projeto, algumas iniciativas de pesquisa nesse assunto foram
identificadas na literatura científica.
O Trabalho MINC – Ferramenta de Gerenciamento e Monitoramento de Hosts (MINC,
2004), foi desenvolvido, levando em consideração a necessidade de monitoramento e
gerenciamento de redes de computadores, e a dificuldade de encontrar ferramentas que adaptem de
maneira objetiva as necessidades de ambientes organizacionais. A ferramenta MINC disponibiliza
serviços de sincronização de data, transferência e instalação de pacotes, cadastramento de usuários,
coleta de informações sobre o uso das estações que possibilite a geração de estatísticas, reinício e
desligamento das estações.
Já o trabalho FACil-DiretoGNU (FACIL-DIRETOGNU, 2002) é um produto de Software
Livre que implementa um sistema corporativo de correio, agenda e catálogo. O sistema foi
implementado, testado e avaliado em um ambiente de produção, demonstrando a vantagem desta
abordagem integrada e gráfica. A ferramenta foi desenvolvida utilizando como base a ferramenta já
existente Webmin, com a adição de novos módulos. Isto possibilitou a personalização e
modularidade da ferramenta desenvolvida.
No trabalho WebMan (AZAMBUJA, 2000) a busca pela disponibilização de informações de
gerenciamento para os usuários da rede METROPOA (região metropolitana de Porto Alegre) no
âmbito do laboratório da PUCRS, motivou a criação de um sistema para gerenciamento do tráfego
de seus switches. Isto foi possível devido a integração entre as linguagens de programação Web e os
principais parâmetros disponíveis nas MIBs de um switch ATM. A interface baseada na Web
também provou ser de total aceitação e facilidade para os usuários, tanto a nível de aprendizado
quanto ao acesso.
36
3. PROJETO
Neste trabalho desenvolveu-se uma aplicação para automatização e gerenciamento de
domínios em um servidor LINUX via Web, projetado para suprir as necessidades da empresa
GrupoW. O Sistema de Gerenciamento de Domínios via Web, chamado de forma simplificada de
SGD Web, objetiva automatizar todos os passos do gerenciamento - a criação, edição, visualização e
exclusão de domínios - sendo desenvolvido para simplificar a interação do usuário com o servidor.
O SGD Web é voltado para usuários com pouco conhecimento dos processos envolvidos na
configuração de um domínio em um servidor e para empresas de hospedagem de pequeno e médio
porte, que necessitam de agilidade e controle em suas tarefas.
É importante ressaltar que o SGD Web será um módulo inicial de um sistema de maior
porte. O sistema de maior porte contará com implementações de módulos adicionais para controlar
outros serviços oferecidos em um servidor Web como FTP, HTTP e E-mail.
3.1. A EMPRESA GRUPOW
O GrupoW é uma empresa situada na cidade de Balneário Camboriú / SC que realiza
serviços na área da Internet, desenvolvendo soluções para websites, intranet, extranet, e-business, e-
commerce, manutenção e hospedagem de web-sites.
A empresa está presente no mercado desde 1999 e tem como forte diferencial oferecer
soluções com alta qualidade em design de interface e preocupação de usabilidade e clareza nas
interfaces desenvolvidas. Atualmente a empresa conta com 14 colaboradores que atuam nas mais
diversas funções: programação, design, administração, comercial, financeiro, suporte e
administração de servidores.
Com mais de 100 clientes no mercado de Santa Catarina e São Paulo, atualmente ela
gerencia 200 domínios e 1100 contas de e-mails configurados em seus servidores Linux de alto
desempenho, localizados nos Estados Unidos.
Atualmente, todo o serviço de manutenção de domínios e dos servidores é realizado por um
único profissional da empresa. O tempo gasto na manutenção do servidor feita por este profissional
especializado poderia estar sendo aplicado em outras tarefas mais produtivas. Dessa forma, a
empresa economizaria na manutenção do servidor, alocando um profissional de custo mais baixo
para essa tarefa.
A figura 14 e a Tabela 2 exemplificam os passos necessários para o gerenciamento dos
domínios (DNS, FTP e HTTP) na empresa atualmente.
Figura 14. Etapas para a administração atual do servidor GrupoW.
38
Tabela 2. Descrição da administração atual do servidor GrupoW.
1. O administrador do servidor conecta-se no servidor localmente ou via terminal remoto.
2. Para acessar o servidor, o administrador precisa de um usuário válido e a senha de super-
usuário do servidor.
3. Uma vez dentro do servidor, o administrador deve saber onde ficam os arquivos de
configuração dos domínios, e ter o conhecimento do que deve ser alterado.
Problemas
1. O responsável precisa estar localmente no servidor, ou possuir um programa seguro para
conexão remota.
2. Por utilizar a senha de super-usuário deve-se tomar muito cuidado nas alterações. Se a senha
for divulgada para pessoas mal intencionadas, a mesma pode causar danos irreversíveis ao
servidor.
3. Se uma pessoa sem conhecimento alterar algum arquivo erroneamente, isto pode até causar
o bloqueio de todos os serviços no servidor.
4. Qualquer tipo de erro deve ser analisado utilizando os logs do servidor.
5. O administrador interage com o sistema até o terceiro nível (nível de configuração dos
arquivos de configuração dos serviços).
3.2. SISTEMA DE GERENCIAMENTO DE DOMÍNIOS VIA WEB
O SGD Web é baseado em algumas das funcionalidades das ferramentas já existentes, mas
possibilita modificações personalizadas no funcionamento e controle do sistema.
O sistema é executado na plataforma Linux e utiliza como base a ferramenta WEBTOOLS.
Entretanto, o SGD Web estende a ferramenta WEBTOOLS, adicionando duas novas
funcionalidades: a interface Web e o controle de acesso aos usuários com a criação de logs
utilizando o modelo de controle de acesso baseado em papéis (RBAC).
Atualmente o WEBTOOLS é uma ferramenta de funcionamento simples e restrito. A figura
15 e a Tabela 3 exemplificam as etapas para funcionamento atual da ferramenta.
39
Figura 15. Funcionamento atual da ferramenta WEBTOOLS.
Tabela 3. Descrição do funcionamento da ferramenta WEBTOOLS.
1. O administrador do servidor conecta-se no servidor localmente ou via terminal remoto.
2. Para acessar o servidor, o administrador precisa de um usuário válido e a senha de super-
usuário do servidor.
3. Uma vez dentro do servidor, o administrador deve executar os scritps, que executam as
tarefas de gerenciamento de domínios desejadas.
4. Estes scripts são executados via terminal, utilizando a passagem de parâmetros de
configuração.
5. Após a execução os scripts retornam mensagens de erro ou confirmação da realização da
tarefa desejada.
40
Problemas
1. O responsável precisa estar localmente no servidor, ou possuir um programa seguro para
conexão remota.
2. Por utilizar a senha de super-usuário deve-se tomar muito cuidado nas alterações. Se a senha
for divulgada para pessoas mal intencionadas, a mesma pode causar danos irreversíveis ao
servidor.
3. O administrador interage com o sistema até o segundo nível (execução dos scripts “linhas de
comando”).
4. A interface com o usuário é muito pobre.
Após o estudo do funcionamento atual da ferramenta Webtools e da rotina de trabalho da
empresa Grupow, foi feita a definição dos requisitos necessários para a criação da ferramenta SGD
Web. O sistema SGD Web deverá:
• Permitir o controle das operações efetuadas pelos usuários do sistema;
• Definir um ambiente multi-usuário com controle de acesso baseado no papel que o usuário
exerce na empresa Grupow (administrador, programador, estagiário);
• Ter uma interface simples que seja acessível para usuários leigos;
• Gerenciar o cadastro, edição, exclusão e consulta de domínios;
• Gerenciar o serviço de DNS envolvido no processo e que esta instalado no servidor Linux;
• Possibilitar a integração de futuros módulos.
41
A figura 16 e a Tabela 5 exemplificam as etapas para o funcionamento do sistema SGD
Web.
Figura 16. Etapas para o funcionamento do sistema SGD Web.
Tabela 4. Descrição do funcionamento do sistema SGD Web.
1. Por ser desenvolvida em uma plataforma Web o sistema pode ser acessado por qualquer
computador que possua um browser e um acesso à internet.
2. O administrador do servidor gerencia os usuários do sistema (fornecendo um login e senha),
atribuindo papéis e permissões (utilizando o modelo RBAC de controle de acesso).
3. Todas as informações de gerenciamento, permissões e controle de acesso são gerenciadas
por um banco de dados.
4. Cada operação realizada pelo usuário fica gravada para possíveis consultas.
5. Os usuários somente interagem com a interface Web “nível 1”. As demais interações são
42
realizadas pela interface Web e a ferramenta WEBTOOLS (ficando transparente para o
usuário), ou seja, o usurário não precisa saber quais serviços e arquivos estarão envolvidos
no processo.
6. A validação dos parâmetros passados ao sistema é tratada pela interface Web, reduzindo a
probabilidade de erros. O usuário não precisa possuir conhecimentos profundos dos
processos que envolvem o gerenciamento de domínios.
7. O administrador interage com o sistema até o primeiro nível (interface Web).
4. TECNOLOGIAS UTILIZADAS
Para o desenvolvimento do projeto, foram utilizadas as tecnologias: Coldfusion (web)
(MACROMEDIA, 2005); MySQL (Banco de dados) (MySQL, 2005) Shell (servidor) (SHELL,
2005).
As linguagens escolhidas foram definidas de acordo com suas atribuições, facilidade de uso,
conhecimento do desenvolvedor.
4.1. COLDFUSION
ColdFusion é um nome utilizado para designar, normalmente, o conjunto de servidor de
aplicações e interpretador da linguagem CFML (ColdFusion Markup Language), da Macromedia.
Isto é, ColdFusion é comumente utilizado para referenciar o produto ColdFusion Application Server
da empresa Macromedia.
Porém, hoje em dia ColdFusion é algo mais abrangente: a CFML é Open Source e diversos
produtos que trabalham de forma semelhante ao ColdFusion Application Server da Macromedia
surgiram no mercado - como o Blue Dragon, da empresa New Atlanta, que tem versão gratuita para
uso não comercial.
Como um dos primeiros programas a integrar HTML com acesso a banco de dados (o
ColdFusion completou em julho/2005 10 anos no mercado), dentre outras funções que ajudaram a
Internet comercial a consolidar-se, o ColdFusion é extremamente utilizado em portais, comércio
43
eletrônico e aplicações em geral que se beneficiam da Internet e do uso de “renderizadores” HTML
(navegadores) para interagir com a aplicação.
As vantagens são múltiplas e conhecidas de todos que têm ou tiveram necessidade de
utilizar aplicações nesse formato: é possível escrever uma aplicação que funcione sem diferenças
em computadores totalmente diferentes, desde processador até uso de memória e métodos de
armazenamento. Havendo um interpretador HTML e uma conexão de rede que possibilite acesso ao
servidor onde a aplicação está, via porta HTTP, já é suficiente.
Assim, o ColdFusion é usado por uma variada gama de empresas, corporações e grupos,
desde o Exército norte-americano até igrejas, governos municipais (Balneário Camboriú, por
exemplo), estaduais e nacionais. Diversas aplicações em servidores nacionais executam código
CFML e um dos exemplos mais conhecidos é o website dos Correios.
Além do poder e flexibilidade já citados, o ColdFusion tem sido a escolha de diversos
desenvolvedores e empresas por ser um ambiente de desenvolvimento rápido de aplicativos (Rapid
Application Development).
4.2. MYSQL
MySQL é um servidor de banco de dados multiusuário e multi-tarefa que utiliza a
linguagem SQL (Structured Query Language) que é uma linguagem de banco de dados popular e
padronizada. MySQL é uma implementação cliente/servidor que consiste de um servidor mysql
com várias bibliotecas e programas clientes diferentes.
As principais características do MySQL são velocidade, robustez e facilidade de uso.
MySQL foi originalmente desenvolvido porque a empresa fabricante do MySQL, necessitava de um
servidor SQL que pudesse administrar bancos de dados muito grandes, de forma mais rápida em um
hardware não muito caro (MySQL, 2005).
O MySQL é composto de várias ferramentas. As funções de acesso ao banco de dados
devem ser descritas no programa, que faz a interface com o servidor de banco de dados através de
uma API (Application Programming Interface). Esta API consiste em um conjunto de funções que
disponibilizam ao programa cliente acesso aos dados de um computador servidor.
44
O processo de manipulação de dados do MySQL através de um programa cliente ocorre em
quatro etapas: (1) programa cliente conecta ao banco de dados; (2) programa cliente envia uma
query de consulta ou atualização do banco de dados; (3) servidor de banco de dados analisa a query,
verifica regras e dependências. Se ocorrer um erro, o banco de dados retorna um código de erro ao
programa cliente, caso contrário, retorna o resultado da query; (4) programa cliente fecha a conexão
com o banco de dados.
4.3. SHELL
Shell é a linha de comando do Linux (e UNIX). É o Shell quem interpreta a linha de
comandos digitada pelo usuário no terminal e chama os programas desejados. O Shell nada mais é
que o responsável entre a comunicação do usuário com o núcleo do sistema operacional. Para isso,
basta que o usuário conheça os comandos e sintaxes apropriadas (SHELL, 2005).
Shell é uma ferramenta muito poderosa para desenvolver scripts e programas rápidos para
automatizar tarefas do dia-a-dia. Assim como serve para fazer scripts de 5 ou 10 linhas, ele é
versátil e completo o suficiente para que grandes programas sejam feitos.
Uma outra vantagem é que ao trabalhar com o Linux, podemos escolher qual o Shell
(interpretador de comandos) que será utilizado. Este recurso é nativo ao Linux, herdado dos
sistemas Unix.
5. DESENVOLVIMENTO
5.1. MODELAGEM
O sistema foi modelado seguindo as orientações da UML e a modelagem foi realizada
utilizando a ferramenta Enterprise Architect versão 5.0. A modelagem do sistema proposto foi
desenvolvida utilizando os seguintes diagramas: diagrama use-case e dicionário de dados.
5.1.1. Diagrama de Use-Case
O diagrama de use-case do sistema é representado pela Figura 17. As Tabelas 5 a 12 fazem
descrição dos cenários.
45
Figura 17. Diagrama use-case do funcionamento do sistema
Tabela 1. Use case Autenticar.
UC01.01 - Autenticar 1 - Administrador informa seu 'usuário' e 'senha'; 2 - Sistema verifica se usuário e senha coincidem; 3 - Sistema libera acesso. Login inválido {Exceção}. No passo 2, se 'usuário' e/ou 'senha' não estiverem corretos, apresenta mensagem de erro
Tabela 6. Use case Gerenciar Usuários.
UC01.02- Gerenciar Usuários Restrições Aprovar Pré-condição. O usuário deverá estar logado no sistema (UC01.01 Autenticar). Usuário deve ter permissão para gerenciar usuários. Cenários Cadastrar usuário {Principal}. 1 - Usuário informa nome de usuário, login, senha e função (papel); 2 - Sistema verifica se usuário já não está cadastrado;
46
3 - Sistema cadastra usuário. Usuário já cadastrado {Exceção}. Se no passo 2 o usuário já estiver cadastrado, informa erro e volta para o passo 1 Senha incorreta {Exceção}. Se no passo 2 os campos senha e confirma senha não coincidirem, informa erro e volta para o passo 1 . Editar usuário. 1 - Usuário seleciona o usuário desejado; 2 - Usuário pode alterar a senha ou modificar a função (papel) do usuário; 3 - Sistema cadastra usuário. Senha incorreta {Exceção}. Se no passo 2 a senha e confirma senha não coincidirem, informa erro e volta para o passo 2. Excluir usuário. 1 - Usuário seleciona o usuário desejado; 2 - Usuário remove o cadastro; 3 - Sistema solicita confirmação; 4 - Sistema exclui usuário. Senha incorreta {Exceção}. Se no passo 3 o usuário cancela, volta para o passo 1.
Tabela 7. Use case Gerenciar Permissões.
UC01.03- Gerenciar Permissões Restrições Aprovar Pré-condição. O usuário deverá estar logado no sistema (UC01.01 Autenticar). Usuário deve ter permissão para gerenciar permissões. Cenários Editar Permissões {Principal}. 1 - Usuário seleciona um papel para editar suas permissões; 2 - Sistema cadastra as permissões para o papel selecionado.
47
Tabela 8. Use case Gerenciar Logs.
UC01.04- Gerenciar Logs Restrições Aprovar Pré-condição. O usuário deverá estar logado no sistema (UC01.01 Autenticar). Usuário deve ter permissão para visualizar logs. Cenários Visualizar Logs {Principal}. 1 - Usuário seleciona o nome do usuário no qual quer visualizar os logs de acesso; 2 - Sistema lista todas a ações do usuário (IP, data, hora, descrição).
Tabela 9. Use case Listar Domínios.
UC01.05- Listar Domínios Restrições Aprovar Pré-condição. O usuário deverá estar logado no sistema (UC01.01 Autenticar). Usuário deve ter permissão para visualizar domínios. Cenários Visualizar domínios {Principal}. 1- Sistema lista todos os domínios cadastrados no servidor.
Tabela 10. Use case Editar Domínio.
UC01.07- Editar Domínio Restrições Aprovar Pré-condição. O usuário deverá estar logado no sistema (UC01.01 Autenticar). Usuário deve ter permissão para editar domínio. Cenários Visualizar domínios {Principal}. 1 - Usuário seleciona qual domínio quer editar; 2 - O usuário pode remover e adicionar HOSTS as zonas primárias; 3 - O usuário pode atualizar os números seriais as zonas primárias; 4 - Sistema executa a opção desejada.
48
Tabela 11. Use case Excluir Domínio.
UC01.08- Ecluir Domínio Restrições Aprovar Pré-condição. O usuário deverá estar logado no sistema (UC01.01 Autenticar). Usuário deve ter permissão para excluir domínio. Cenários Visualizar domínios {Principal}. 1 - Usuário seleciona qual domínio quer excluir; 2 - Sistema solicita confirmação da remoção; 3 - Sistema apaga as configurações do domínio selecionado.
Tabela 12. Use case Cadastrar Domínio.
UC01.06- Cadastrar Domínio Restrições Aprovar Pré-condição. O usuário deverá estar logado no sistema (UC01.01 Autenticar). Usuário deve ter permissão para cadastrar domínio. Cenários Cadastrar domínio {Principal}. 1- Usuário digita o domínio desejado; 2- Sistema verifica a sintaxe do domínio (de acordo com as normas da Fapesp); 3- Sistema verifica se o domínio já existe no servidor; 4- Sistema cadastra o domínio no servidor. Sintaxe incorreta {Exceção}. No passo 2, se 'domínio' não estiver correto, apresenta mensagem de erro. Domínio já existe {Exceção}. No passo 3, se 'domínio' já existe, apresenta mensagem de erro.
49
5.1.2. Dicionário de dados
A tabela 13 descreve a estrutura dos dados da tabela user, onde estão os dados dos usuários.
Tabela 13 Classe User
Nome Descrição Tipo Tamanho user_idpk Código identificador do usuário int 11 user_nome Nome do usuário varchar 250 user_data Data de criação do usuário date user_login Identificação do usuário no sistema varchar 20 user_senha Senha do usuário varchar 250
user_senha_cf Senha do usuário varchar 250 user_acesso Quantidade de acesso do usuário int
user_ultimo_acesso Data do último acesso do usuário datetime
A tabela 14 descreve a estrutura dos dados da tabela user_role, onde ao usuário é atribuída
uma função (papel).
Tabela 14 Classe User_Role
Nome Descrição Tipo Tamanho user_role_idpk Código identificador do registro int 11
user_idpk Código identificador do usuário int 11 role_idpk Código identificador da função (papel) int 11
A tabela 15 descreve a estrutura dos dados da tabela role, as funções (papéis) são
cadastradas.
Tabela 15 Classe Role
Nome Descrição Tipo Tamanho role_idpk Código identificador da função (papel) int 11 role_nome Nome da função (papel) varchar 250
A tabela 16 descreve a estrutura dos dados da tabela operation, onde são definidas todas as
operações (regras) que poderão ser associadas às funções (papéis).
Tabela 16 Classe Operation
Nome Descrição Tipo Tamanho operation_idpk Código identificador da operação
(permissão) int 11
operation_nome Nome da operação (permissão) varchar 250
50
A tabela 17 descreve a estrutura dos dados da tabela role_operation_set, onde são atribuídas
quais operações (regras) que serão associadas às funções (papéis).
Tabela 17 Classe Role_Permission_Set
Nome Descrição Tipo Tamanho role_permission_set_idpk Código identificador do registro int 11
operation_idpk Código identificador da operação (permissão)
int 11
role_idpk Código identificador da função (papel) int 11
A tabela 18 descreve a estrutura dos dados da tabela log, onde serão armazenados os dados e
ações dos usuários.
Tabela 18 Classe Log
Nome Descrição Tipo Tamanho log_idpk Código identificador do registro int 11 user_idpk Código identificador do usuário int 11 log_data Data e hora da ação datetime
log_descricao Descrição da ação varchar 255 log_ip Endereço da máquina onde partiu o acesso varchar 50
A figura 18 e a tabela 19 mostram como forma montadas as estruturas do banco de dados.
As estruturas foram desenvolvidas seguindo o modelo RBAC, onde usuários são associados a
papéis e papéis estão associados a permissões.
51
Figura 18. Diagrama físico do banco de dados.
Tabela 19 Modelo físico do banco de dados.
# # Table structure for table 'log' # CREATE TABLE `log` ( `log_idpk` int(11) NOT NULL auto_increment, `user_idpk` int(11) default NULL, `log_data` datetime default NULL, `log_descricao` varchar(255) default NULL, `log_ip` varchar(50) default NULL, PRIMARY KEY (`log_idpk`) ) TYPE=MyISAM; # # Table structure for table 'operation' # CREATE TABLE `operation` ( `operation_idpk` int(11) NOT NULL auto_increment, `operation_nome` varchar(250) default NULL,
52
PRIMARY KEY (`operation_idpk`) ) TYPE=MyISAM; # # Table structure for table 'role' # CREATE TABLE `role` ( `role_idpk` int(11) NOT NULL auto_increment, `role_nome` varchar(250) default NULL, PRIMARY KEY (`role_idpk`) ) TYPE=MyISAM; # # Table structure for table 'role_permission_set' # CREATE TABLE `role_permission_set` ( `role_permission_set_idpk` int(11) NOT NULL auto_increment, `operation_idpk` int(11) default NULL, `role_idpk` int(11) default NULL, PRIMARY KEY (`role_permission_set_idpk`) ) TYPE=MyISAM; # # Table structure for table 'user' # CREATE TABLE `user` ( `user_idpk` int(11) NOT NULL auto_increment, `user_nome` varchar(250) default NULL, `user_data` date default NULL, `user_login` varchar(20) default NULL, `user_senha` varchar(250) default NULL, `user_senha_cf` varchar(250) default NULL, `user_acesso` int(11) default '0', `user_ultimo_acesso` datetime default NULL, PRIMARY KEY (`user_idpk`) ) TYPE=MyISAM; # # Table structure for table 'user_role' # CREATE TABLE `user_role` ( `user_role_idpk` int(11) NOT NULL auto_increment, `user_idpk` int(11) default NULL, `role_idpk` int(11) default NULL, PRIMARY KEY (`user_role_idpk`) ) TYPE=MyISAM;
53
5.2. TELAS DO SISTEMA
Esta seção apresentará o funcionamento do sistema descrevendo a interface do sistema com
o usuário final e o conjunto de algumas telas do sistema SGD Web.
A primeira tela para efetuar o acesso no sistema mostrada na Figura 19, é onde o usuário
informa um login e senha padrão que liberará o acesso para a próxima tela de autenticação no
sistema. Esta autenticação é configurada no servidor HTTP (Apache), onde pode-se definir IPs que
terão acesso ao sistema.
Figura 19. Tela de login do apache
A tela para efetuar o acesso no sistema, mostrada na Figura 20 é onde o usuário informa sua
identificação e sua senha para verificar se ele tem acesso às demais funcionalidades de sistema.
54
Figura 20. Tela de login
As Figuras 21 e 22 mostram respectivamente a visualização e criação de um usuário. Nelas
o administrador tem controle sobre as funções (papéis) do usuário, dados sobre o usuário e acesso.
Figura 21. Tela de visualização dos dados de um usuário
55
Na criação de um novo usuário, é solicitado uma identificação do usuário no sistema (Login
- único no sistema), senha e a confirmação da mesma. Nesta mesma tela é definida a função deste
usuário (papel), que seguindo o modelo RBAC definirá as áreas que o usuário terá acesso.
Figura 22. Tela de criação de um novo usuário
Na figura 23 o usuário deve definir quais são as permissões que um uma função (papel)
deve receber.
56
Figura 23. Tela de atribuição das permissões ao papel
Para manter um controle sobre todas as operações realizadas no sistema, as ações realizadas
pelos usuários são gravadas em um banco de dados. Como pode ser visto na figura 24, selecionado
um usuário pode-se verificar cada passo do que ele realizou no sistema (data / hora, IP e o que foi
feito).
57
Figura 24. Tela de visualização dos logs de acesso
A figura 25 mostra a listagem de todos os domínios cadastrados no servidor. É a partir desta
listagem que o usuário tem acesso a edição e exclusão dos domínios.
Figura 25. Tela de visualização dos domínios
58
5.3. INTEGRAÇÃO WEBTOOLS E SGD WEB
Para integração e desenvolvimento do projeto algumas das funcionalidades dos scripts
WEBTOOLS foram modificadas e adaptadas. Estas modificações visaram à adequação da formação
dos arquivos no servidor. Abaixo segue a relação dos scripts utilizados:
• adddns -Script para adicionar ZONAS primárias ao NAMED.
• deldns - Script para remover ZONAS primárias e configurações para as mesmas.
• dnsrecords - Script para verificar, remover e adicionar HOSTS às ZONAS primárias
criadas com adddns.
• secondary - Script para verificar, adicionar e remover ZONAS secundárias do
Named.
• updatezone - Script para fazer atualização de números seriais de ZONAS primárias
criadas com adddns.
• zonecheck - Script para verificar a existência de ZONAS primárias no Named.
Para a interação dos scripts com a interface Web foi utilizada a função nativa do ColdFusion
- “CFEXECUTE”. Para a função CFEXECUTE são enviados o script a ser executando e os
parâmetros necessários. Esta função executa os scripts no servidor, desde que os scripts e o
ambiente de execução do ColdFusion possuam permissão de execução.
5.4. SEGURANÇA
5.4.1. Autenticação
Foram utilizadas a função “hex_sha1” para gerar um resumo (hash) da senha e a função
interna “encrypt”, nativa do Macromedia ColdFusion, para gerar a cifragem da senha para o
usuário, que será gravada no banco de dados.
A função “encrypt” criptografa uma string utilizando outra string como semente, a partir de
um algoritmo simétrico baseado em XOR, com uma chave pseudo-randômica de 32 bits. A
59
segurança deste tipo de criptografia depende da semente manter-se secreta – o mesmo algoritmo,
quando fornecida a semente, pode decifrar a string (utilizando a função nativa “decrypt”).
5.4.2. Validação
A cada chamada para uma página (template) do sistema, o ColdFusion verifica a existência
de um arquivo chamado Application.cfm, que deve estar localizado no mesmo diretório da página
chamada ou em qualquer diretório acima na árvore de diretórios.
A utilização deste arquivo no diretório raiz de um sistema é padrão para definições que são
gerais para a aplicação e também para validação do acesso. Como a cada chamada para uma página
este arquivo é executado antes da execução do código da página, é seguro verificar os direitos de
acesso do usuário e também renovar sua sessão no Application.cfm, que é a abordagem utilizada
neste projeto.
5.4.3. Sudo (Linux)
O comando sudo foi o recurso utilizado para manter a integridade e segurança do servidor.
Isso porque através dele, foram definidos quais comandos de super-usuário podem ser executados
pelo sistema.
O uso do sudo foi implementado porque o usuário não precisa saber a senha do root, apenas
terá a permissão para usar determinados comandos pelo sudo. Além disso, o sudo permite registrar
em um arquivo de log todas as atividades efetuadas.
5.4.4. Compilação
O ColdFusion utiliza páginas pré-compiladas em bytecode (código intermediário,
independente de plataforma). Quando utilizando a versão PROFESSIONAL é possível configurar
a segurança de acesso a funções e diretórios para todo o servidor – esta foi a versão utilizada neste
projeto. Já a versão ENTERPRISE permite criação de sandboxes (áreas reservadas, por onde
passam todos os dados antes de chegarem aos programas), com configurações de segurança
variadas por aplicação/diretórios. Esta é a versão indicada para hostings (serviço de armazenamento
de sites em um servidor), tanto para execução segura do SGDWEB quanto para hospedagem segura
em ColdFusion. A versão PROFESSIONAL só é indicada para intranets ou servidores fechados –
isto é, onde todo código ColdFusion executado no servidor provém de uma única e confiável fonte.
60
O código-fonte é criptografado utilizando basicamente o mesmo código da função
“encrypt”, já descrita anteriormente. Esta camada de segurança visa evitar problemas com
servidores mal-configurados, que podem retornar o código ColdFusion para um acesso normal,
comprometendo assim a segurança de toda a aplicação.
5.4.5. Components
Os CFCs (ou ColdFusion Components) são uma inovação da versão MX do ColdFusion. A
partir desta versão, o ColdFusion passou a suportar encapsulamento de código, simulando muitas
características da programação baseada em objetos – indo além da sua idéia original, isto é, de ser
uma linguagem interpretada.
No projeto, foi utilizado apenas um CFC (_funcoes.cfc) que encapsula o código de UDFs
(funções definidas pelo programador, na sigla em inglês) utilizadas em todo o sistema. As UDFs
tratam desde validação/formatação de data e hora até a verificação de direitos de acesso e re-
validação da sessão do usuário.
5.4.6. Sessão
Um dos maiores problemas com aplicações web é acompanhar o mesmo usuário dentro do
sistema. Uma vez que o acesso à página é assíncrono, torna-se necessário um mecanismo próprio
para identificar o usuário unicamente em sua sessão de acesso.
Isto é, uma vez validado o usuário, para que o sistema saiba nas chamadas futuras que este é
o mesmo usuário que já foi validado, utiliza-se a sessão ColdFusion – um conjunto de três
variáveis - CFID, CFTOKEN e JSESSIONID. Embora a criação ou não destas variáveis seja
controlada pelo servidor e também pela configuração da aplicação, sempre existirá ao menos um
cookie (arquivo rastreador gravado no computador do usuário, com acesso limitado ao IP/domínio
que criou o arquivo).
A criação destas variáveis na maioria dos casos se dá diretamente pelo servidor ColdFusion,
sem necessidade de programação adicional. O CFTOKEN e o JSESSIONID são strings únicas
criadas e controladas pelo ColdFusion, com funcionamento limitado à aplicação em que foram
criadas.
61
Assim, mesmo que um usuário A tente utilizar a sessão do usuário B, o usuário A terá um
dos seguintes problemas:
1. Os valores das três variáveis combinadas não coincidem;
2. O valor (gerado aleatoriamente) não é igual ao armazenado pelo servidor;
3. A sessão que ele está usando pertence à outra aplicação.
Em qualquer um dos casos, a aplicação deverá retornar um erro e redirecionar o acesso para
a tela de autenticação.
5.4.7. SSL (Secure Socket Layer)
Para maior segurança do sistema, foi implantado no servidor Linux o SSL. Sua proposta é
permitir a autenticação de servidores, cifragem de dados, integridade de mensagens e, como opção,
a autenticação do cliente, operando nas comunicações entre aplicativos de forma interoperável. Visa
garantir a segurança criptográfica para o estabelecimento de uma ligação segura entre duas
máquinas/aplicativos, assegurando a privacidade na conexão, com a utilização de algoritmos
simétricos que negociam uma chave secreta na primeira fase do handshaking (usando chaves
públicas – assimétricas).
5.4.8. RBAC
O modelo RBAC foi utilizado neste projeto para garantir a separação de deveres, abstração
dos dados e para facilitar a administração da política de controle de acesso. O modelo RBAC foi
construído usando o banco de dados e o conceito de sessão da linguagem ColdFusion. As tabelas do
banco de dados criadas seguiram o modelo RBAC Core, no qual um usuário é associado a um papel
que possui permissões no sistema. Assim, em tempo de execução, o sistema valida as permissões do
usuário utilizando as funções (Temdireito e Tempermissão) ANEXO I.
O modelo RBAC Core define algumas operações e mapeamentos que devem existir em uma
implementação do modelo, que são (FERRAIOLO, 2001):
62
Funções de controle de acesso
• CreateSession;
• AddActiveRole;
• DropActiveRole;
• CheckAccess;
Funções de verificação
• AssignedUsers;
• AssignedRoles;
• RolePermissions;
• UserPermissions;
• SessionRoles;
• SessionPermissions;
Na implementação do SGD Web, estas operações são implementadas através da
programação web e através da estrutura de banco de dados (user, user_role, operation, role,
role_permission_set).
5.5. TESTES E RESULTADOS
O sistema está em fase de testes em um ambiente real e funcional da empresa GrupoW.
Neste período de testes, foram realizados testes de segurança, confiabilidade, funcionalidade e
funcionamento do sistema. Para garantir o bom funcionamento do sistema recomenda-se utilizar as
configurações de software/servidor utilizadas nos testes.
As tabelas 20 e 21 mostram os resultados obtidos nos testes, bem como a configuração do
ambiente onde o sistema está sendo executado. O sistema pode ser acessado no endereço
https://sgdweb.grupow.com.br (login: admin e senha 12345). Por motivo de segurança os módulos
de criação edição e exclusão dos domínios foram desativados.
63
Tabela 20 configuração
Servidor redhat enterprise linux 3.2.3-42 coldfusionmx 6.1.0.0 bind 9.2.5-1 httpd 2.0.52-3 kernel 2.4.21-20.EL vsftpd 2.0.1-5 mysql 4.1.11
Tabela 21 Resultados
Domínios testados Foram utilizados para o teste 205 domínios válidos cadastrados no servidor web (.com, .com.br, .net, .odo.br).
Problemas encontrados 1- Foi detectada uma diferença no modelo de atualização do número serial do servidor DNS (BIND) entre script WEBTOOOLS e os arquivos já existentes. 2- Os arquivos de configuração das ZONAS tiveram que ser incluídos no named.conf ( pois pelo padrão WEBTOOOLS eles são criados separadamente e divididos em ordem alfabética). 3- Para padronização dos domínios existentes, todos foram recadastrados utilizando o novo sistema. 4- Atualmente, as ZONAS secundárias são cadastradas na mesma máquina (ou seja o servidor precisa ter dois IPs válidos)
Resultados Obtidos Após o cadastro dos domínios no sistema, os mesmos foram sincronizados na FAPESP, sem acusar nenhum tipo de erro. Não foi encontrado nenhum problema na segurança ou integração dos scripts com a interface Web
Após o uso do sistema, foi observado que as funcionalidades definidas no projeto e
desenvolvimento executaram de forma correta. O sistema foi utilizado por alguns usuários leigos da
empresa, que emitiram opiniões favoráveis quanto à simplicidade e entendimento do funcionamento
do sistema, até quando comparado com ferramentas similares. Outros testes ainda serão realizados,
já que o sistema será utilizado no dia a dia para a realização do gerenciamento de domínios.
64
6. CONCLUSÕES
O estudo realizado no trabalho apresentado possibilitou uma ampla compreensão da
complexidade no desenvolvimento e gerência de serviços e “programas” nos sistemas operacionais
Linux.
Na fase de pesquisa levou-se em consideração todo o estudo sobre segurança de
computadores e o funcionamento de servidores Linux. Todos os objetivos nesta fase foram
atingidos, o que proporcionou uma visão geral dos procedimentos envolvidos no processo.
Já na fase da análise das ferramentas existentes, observou–se a escassez de ferramentas
disponíveis. Das três ferramentas analisadas (WEBMIN, 2005), (WEBTOOLS, 2005) e (CPANEL,
2005), duas procuram abranger a gerência geral de um servidor enquanto WEBTOOLS tem o foco
no serviço de gerenciamento de domínios. Vários problemas foram encontrados nas ferramentas
analisadas, como complexidade na utilização e problemas de segurança.
Devido às pesquisas realizadas, e com base em outros projetos similares, este projeto foi
desenvolvido. Ele objetiva automatizar todos os passos do gerenciamento - a criação, edição,
visualização e exclusão de domínios - sendo desenvolvido para simplificar a interação do usuário
com o servidor. O sistema é executado na plataforma Linux e utiliza como base a ferramenta
WEBTOOLS. Entretanto, o SGD Web estende a ferramenta WEBTOOLS, adicionando duas novas
funcionalidades: a interface Web e o controle de acesso aos usuários com criação de logs utilizando
o modelo de controle de acesso baseado em papéis (RBAC).
Do ponto de vista acadêmico, este trabalho foi uma ótima oportunidade de demonstrar na
prática os conhecimentos desenvolvidos durante o Curso de Ciência da Computação, possibilitando
aplicar os conteúdos vistos durante as disciplinas e com a complementação de pesquisas.
O resultado deste trabalho será melhorado através da adição de outros módulos para
gerenciamento de novos serviços como FTP, HTTP e e-mail, adaptados às necessidades da empresa
GrupoW.
65
REFERÊNCIAS BIBLIOGRÁFICAS
ACME. Computer security research. Disponível em: <http://www.acme-ids.org/>. Acesso em 25 mar. 2005.
ALBUQUERQUE, Ricardo; RIBEIRO, Bruno. Segurança no desenvolvimento de software – Como desenvolver sistemas seguros e avaliar a segurança de aplicações desenvolvidas com base na ISO 15.408. Rio de Janeiro. Campus, 2002.
APACHE. Software foundation. Disponível em: <http://www.apache.org>. Acessado em:15 maio 2005.
AZAMBUJA, M. WebMan - Uma Ferramenta WWW de Gerência SNMP. Workshop RNP2. SBRC 2000 - XVIII Simpósio Brasileiro de Redes de Computadores. Anais do II Workshop RNP2
BALL, Bill; DuFF, Hoyt. Red Hat Linux 9 unleashed sams. Bk&CD-Rom edition (May 8, 2003).
BERNSTEIN, Terry; et. Alli; Segurança na internet. Rio de Janeiro: Campus, 1997.
COMPUTERWOLD. Ensuring end-to-end security with SSL. Disponível em: <http://www.networkworld.com/details/473.html> Acessado em: 03 maio 2005.
CPANEL. WebHost manager. Disponível em: <http://www.cpanel.net/>. Acessado em: 01 maio 2005.
DIAS, Claudia. Segurança e auditoria da tecnologia da informação. Axcel Books, 2000.
DNS. The domain name system. Disponível em: <http://www2.rad.com/networks/1995/dns/dns.htm> Acessado em:12 jun. 2005.
ENGELFRIET, A. Choosing a software license. 2003. Disponível em: <http://www.iusmentis.com/computerprograms/licenses/pcactive0203/> Acesso em 30 mar. 2005.
ENGELFRIET, A. Crash course on copyright. 2002. Disponível em: <http://www.iusmentis.com/copyright/crashcourse/>. Acessado em 30 mar. 2005.
FACIL-DIRETOGNU. Uma ferramenta para a configuração e administração do DiretoGNU. BRANDENBURGER, Filipe; VARGAS, Patrícia Kayser; FERRARI, Débora Nice; DUTRA, Inês de Castro; GEYER, Cláudio F. R. III Workshop sobre Software Livre (WSL 2002), 2-3 de maio de 2002. Porto Alegre - RS.
FERRAIOLO, D. F.; SANDHU , R.; GAVRILA, S.; KUHN , D. R., and CHANDRAMOULI, R.. Proposed NIST standard for role-based access control. ACM Transactions on Information and System Security (TISSEC), 4(3):224-274, 2001.
FSF. Free software foundation. Disponível em: <http://www.fsf.org>. Acessado em:18 jun. 2005.
GNU, The free software foundation. Categories of Free and Non-Free Software. 2005. Disponível em: <http://www.gnu.org/philosophy/categories.html>. Acessado em: abr. 2005.
HEXSEL, Roberto A. Propostas de ações de governo para incentivar o uso de software livre. Relatório Técnico do Departamento de Informática da UFPR, 004/2002, out02.
HTTP. Hypertext transfer protocol. Disponível em: <http://www.w3.org/Protocols/>. Acessado em:12 maio 2005.
HUGHES, Larry J. Actually useful internet security techniques, New Riders Publishing, Indianapolis, 1995.
IETF. The internet engineering task force. Disponível em: <http://www.ietf.org>.Acessado em 25 mar. 2005.
INTERNIC. The public information regarding internet domain name registration services Disponível em: <http://www.internic.net/>. Acessado em: 20 abr. 2005.
KRAUSE, Micki e TIPTON, Harold F. Handbook of information security management. Auerbach Publications, 1999.
LANDWEHR, Carl E., "Computer security," International Journal of Information Security 1 (1): 3-13 (2001).
LINUX. Disponível em: <http://www.linux.org/> Acessado em: 22 maio 2005.
LOPES, Alexandre. Segurança redobrada - protegendo seus negócios: fique de olho na segurança, 2001. Disponível em <http://www.timaster.com.br>. Acessado em 26 Abr 2005.
MARTINEZ, Maria Laura. Workshop: Sociedade da informação: Benção ou Maldição. São Paulo, 22 de novembro de 2003. Organização: Fundação Konrad-Adenauer e Depto de Jornalismo e Editoração - ECA - USP.
MINC – Ferramenta de gerenciamento e monitoramento de hosts. Huander Leão1, Leandro Anchieta Thomas1, Rodrigo Cândido Borges1, Welter Martins de Almeida Júnior1, Maxweel Silva Carmo1 VI Encontro de Estudantes de Informática do Estado do Tocantins – ENCOINFO 2004 – 4 e 5 de novembro de 2004 CEULP/ULBRA – Curso de Sistemas de Informação – Palmas – TO
MySQL. MySQL AB. Disponível em: < http://www.mysql.com/>. Acessado em:12 maio 2005.
NBSO. Nic BR security office. Disponível em <http://www.nic.br>. Acessado em: 18 jun. 2005.
OBELHEIRO, Rafael R.. "Modelos de segurança baseados em papéis para sistemas de larga escala: a proposta RBAC-JaCoWeb". Dissertação de Mestrado. PPGEEL-UFSC, Florianópolis, SC, mar. de 2001.
OLIVEIRA, Gorki Starlin Costa. Segurança completa contra hackers. Book Express, 2000.
PANETTA, Nelson. Criptografia. Security Magazine. São Paulo, n.6, p. 10-16, ago. 2000.
POSTEL, J; REYNOLDS J. File transfer protocol (FTP). October 1985. Disponível em: <http://www.w3.org/Protocols/rfc959/> Acessado em: 05 maio 2005.
67
REGGIANI, Lucia. A escalada insuportável dos vírus. Revista Info Exame, São Paulo, p. 48-57, nov. 2001.
SANTOS, Luiz. C. Como funciona o DNS. Disponível em: <http://www.clubedasredes.eti.br/rede0006.htm> Acessado em: 12 jun. 2005.
SECUNIA Monitors and vulnerabilities. Disponível em: http://secunia.com/search/?search=webmin Acessado em: 21 maio 2005.
SECUNIA Monitors and vulnerabilities. Disponível em: http://secunia.com/search/?search=cpanel Acessado em: 22 maio 2005.
SECURITYFOCUS. Security and vulnerabilities. Disponível em: <http://www.securityfocus.com/swsearch?sbm=%2F&metaname=alldoc&query=webmin&x=15&=5 > Acessado em: 21 maio 2005.
SECURITYFOCUS. Security and vulnerabilities. Disponível em: <http://www.securityfocus.com/swsearch?sbm=%2F&metaname=alldoc&query=cpanel&x=15&y=7> Acessado em: 22 maio 2005.
SHIREY, R. Internet security glossary. May 2000. Disponível em: <http://www.ietf.org/rfc/rfc2828.txt?number=2828> Acessado em: 05 maio 2005.
SOARES, Luiz F. G.; LEMOS, Guido; COLCHER, Sérgio. Redes de computadores: das LANs, MANs e WANs às redes ATM. Rio de Janeiro: Campus, 1995.
SSL. SSL specification. Disponível em: <http://wp.netscape.com/eng/ssl3/> Acessado em: 08 maio 2005.
TANENBAUM, Andrew S. Redes de computadores. Rio de Janeiro, RJ: Campos 1997.
ULBRICH, Henrique César; DELLA VALLE James, Universidade hacker: Desvende Todos os Segredos do Submundo. São Paulo, SP: Digerati Books 2003.
WATER, Black. Invasão hacker. Editora Book Express, 2000.
WEBER, Taisy S.; JASCH-PÔRTO, Ingrid; WEBER, Raul. Tolerância a falhas: conceitos e técnicas, aplicações, arquitetura de sistemas confiáveis - Notas de aula. Porto Alegre: Instituto de Informática, UFRGS, 1996.
WEBMIN. A web-based interface for system administration for unix. Disponível em: <http://www.webmin.com/> Acessado em: 05 maio 2005.
WEBTOOLS. Sistemas alternativos. Disponível em: <http://webtools.linuxsecurity.com.br> Acessado em: 10 maio 2005.
WIPO. World intellectual property organization 2005. Disponível em: <http://www.wipo.int/portal/index.html.en> Acessado em: 30 mar. 2005.
ZWICKY, Elizabeth. “Construindo firewalls para a internet”. 2ª edição. São Paulo, SP – Brasil. Campus, 2000.
68
ANEXO I – EXEMPLO DA ESTRUTURA RBAC NO CÓDIGO IMPLEMENTADO.
<!--- Metodo para verificar se a sessao expirou --->
<cffunction name="verificaSessao" output="No" returntype="void" access="public">
<!--- Verifica se as variaveis de sessao estao definidas --->
<cfif not isDefined("session.usuIdpk") OR not isDefined("session.usuNome") OR not isDefined("session.usuUltimoAcesso") OR
not isDefined("session.usuAcessos") OR not isDefined("session.usuPermissoes")>
<!--- Se entrou aqui e porque esta errado. Retorna falso! --->
<cflocation url="#application.basedir#erro/sessao.cfm" />
</cfif>
</cffunction>
<!--- Funcao para verificar se o usuario tem direito de acesso --->
<cffunction name="temDireito" output="No" returntype="void" access="public">
<!--- Recebe o direito de acesso --->
<cfargument name="area" required="Yes" type="string" />
<!--- Recebe a lista de permissoes --->
<cfargument name="permissoes" required="Yes" default="#session.usuPermissoes#" />
<!--- Configura a variavel de retorno --->
<cfset var retorno = 0 />
<!--- Verifica as permissoes de area --->
<cfquery datasource="#application.dsn#" name="qPermissoes">
SELECT
69
role.role_idpk
FROM
user_role, role
WHERE
user_idpk = <cfqueryparam cfsqltype="cf_sql_integer" value="#session.usuIdpk#" />
AND
user_role.role_idpk = role.role_idpk
</cfquery>
<cfif qPermissoes.role_idpk is arguments.permissoes>
<cfquery datasource="#application.dsn#" name="qPermissoesSet">
SELECT
operation_idpk
FROM
role_permission_set
WHERE
role_idpk = <cfqueryparam cfsqltype="cf_sql_integer" value="#qPermissoes.role_idpk#" />
</cfquery>
<cfif len(trim(qPermissoesSet.operation_idpk))>
<cfset variables.perm = "#valueList(qPermissoesSet.operation_idpk)#">
<cfelse>
<cfset variables.perm = "0">
</cfif>
<!--- Verifica se area e uma lista ou uma variavel so --->
<cfif arguments.area contains ",">
<!--- Loop atraves das areas para conferir o direito de acesso --->
70
<cfloop list="#arguments.area#" index="areaAtual">
<!--- Verifica se tem direito de acessar a area --->
<cfif listFind(variables.perm, areaAtual)>
<!--- Marca como OK --->
<cfset retorno = 1 />
</cfif>
</cfloop>
<cfelse>
<!--- Verifica se tem direito de acessar a area --->
<cfif listFind(variables.perm, arguments.area)>
<!--- Marca como OK --->
<cfset retorno = 1 />
</cfif>
</cfif>
</cfif>
<!--- Verifica o retorno e redireciona, caso necessario --->
<cfif not retorno>
<!--- Redireciona para a pagina de erro --->
<cflocation url="#application.basedir#erro/permissao.cfm" />
</cfif>
</cffunction>
<!--- Metodo para verificar se o usuario tem direito de acesso --->
<cffunction name="temPermissao" output="No" returntype="boolean" access="public">
<!--- Recebe o(s) direito(s) de acesso --->
<cfargument name="permissao" required="Yes" type="string" />
<!--- Recebe a lista de permissoes --->
71
<cfargument name="permissoes" required="No" default="#session.usuPermissoes#" />
<!--- Configura a variavel de retorno como verdadeira --->
<cfset var retorno = 0 />
<!--- Configura a variavel para loop na lista --->
<cfset var permissaoAtual = "" />
<!--- Verifica as permissoes de area --->
<cfquery datasource="#application.dsn#" name="qPermissoes">
SELECT
role.role_idpk
FROM
user_role, role
WHERE
user_idpk = <cfqueryparam cfsqltype="cf_sql_integer" value="#session.usuIdpk#" />
AND
user_role.role_idpk = role.role_idpk
</cfquery>
<cfif qPermissoes.role_idpk is arguments.permissoes>
<cfquery datasource="#application.dsn#" name="qPermissoesSet">
SELECT
operation_idpk
FROM
role_permission_set
WHERE
role_idpk = <cfqueryparam cfsqltype="cf_sql_integer" value="#qPermissoes.role_idpk#" />
</cfquery>
72
<cfif len(trim(qPermissoesSet.operation_idpk))>
<cfset variables.perm = "#valueList(qPermissoesSet.operation_idpk)#">
<cfelse>
<cfset variables.perm = "0">
</cfif>
<!--- Verifica se area e uma lista ou uma variavel so --->
<cfif arguments.permissao contains ",">
<!--- Loop atraves das areas para conferir o direito de acesso --->
<cfloop list="#arguments.permissao#" index="areaAtual">
<!--- Verifica se tem direito de acessar a area --->
<cfif listFind(variables.perm, areaAtual)>
<!--- Marca como OK --->
<cfset retorno = 1 />
</cfif>
</cfloop>
<cfelse>
<!--- Verifica se tem direito de acessar a area --->
<cfif listFind(variables.perm, arguments.permissao)>
<!--- Marca como OK --->
<cfset retorno = 1 />
</cfif>
</cfif>
</cfif>
<!--- Retorna verdadeiro ou falso --->
<cfreturn retorno />
</cffunction>
73
