Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf ·...

50
UNIVERSIDADE S ˜ AO FRANCISCO Curso de Ci ˆ encia da Computac ¸˜ ao JOHN LENON CARDOSO GARDENGHI UM ESQUEMA DE AUTENTICAC ¸ ˜ AO SEGURA PARA O SQUID PROXY-CACHE: UM ESTUDO DE CASO BASEADO EM NOVELL(R) EDIRECTORY(TM) Itatiba 2011

Transcript of Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf ·...

Page 1: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

UNIVERSIDADE SAO FRANCISCOCurso de Ciencia da Computacao

JOHN LENON CARDOSO GARDENGHI

UM ESQUEMA DE AUTENTICACAO SEGURA PARA OSQUID PROXY-CACHE: UM ESTUDO DE CASO BASEADO

EM NOVELL(R) EDIRECTORY(TM)

Itatiba2011

Page 2: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

JOHN LENON CARDOSO GARDENGHI - R.A. 002200800362

UM ESQUEMA DE AUTENTICACAO SEGURA PARA OSQUID PROXY-CACHE: UM ESTUDO DE CASO BASEADO

EM NOVELL(R) EDIRECTORY(TM)

Monografia apresentada ao Curso de Cienciada Computacao da Universidade Sao Francisco,como requisito parcial para a obtencao do tıtulode Bacharel em Ciencia da Computacao.

Orientador: Prof. Marcelo Augusto GoncalvesBardi

Itatiba2011

Page 3: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

Ao meu pai, que sempre

investiu e acreditou em mim.

Page 4: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

AGRADECIMENTOS

Agradeco, acima de tudo, a Deus, pela forca e coragem que recebi de sua parte e pela

alegria proporcionada pelos frutos destes anos de trabalho.

Ao Prof. Marcelo Augusto Goncalves Bardi, meu orientador e amigo, por seus valiosos

conselhos e sugestoes no decorrer deste projeto, que sem duvida foram essenciais para sua

concretizacao e que levarei como exemplo para minha carreira profissional.

Aos demais professores do curso de Ciencia da Computacao, cuja colaboracao foi

indispensavel para que este projeto se tornasse realidade.

Por fim, aos bons amigos que tive o fortunio de conhecer ao longo destes anos que

passei na Universidade Sao Francisco, todo o esforco dispendido por todos nos, em contraste

ao nosso animo e vontade, estarao sempre em minhas lembrancas.

Page 5: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

RESUMO

O processo de identificacao de um usuario em ambientes de rede e muito importante, ja que

consiste em conhecer quem esta utilizando um recurso e, assim, agrega seguranca e inte-

gridade ao ambiente, permitindo seu uso controlado. Entretanto, a diversificacao de recursos

em rede implica no emprego de varias, e muitas vezes distintas, credenciais por um mesmo

usuario, o que significa uma desvantagem do ponto de vista de usabilidade. Uma solucao

potencial para este problema sao sistemas de autenticacao Single Sign-On (SSO), em que

usuarios se autenticam apenas uma vez e sao automaticamente autorizados a acessar to-

dos os demais recursos que precisam. Neste contexto, a proposta deste trabalho consiste

em desenvolver um esquema de autenticacao segura para o Squid proxy-cache, com forte

apoio na estrategia SSO, com o principal objetivo em otimizar usabilidade e seguranca no uso

deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente fa-

voravel para o desenvolvimento do mecanismo de autenticacao SSO. Por fim, uma interface

de autenticacao segura foi implementada, baseada em uma base de usuarios com suporte a

LDAP e estudada tambem para o caso particular de rede Novell. Com isso, um sistema de

autenticacao seguro customizavel para o Squid foi desenvolvido, eliminando a interacao direta

do proxy-cache com o usuario.

Palavras-chave: autenticacao. single sign-on. Squid proxy-cache. Novell eDirectory.

Page 6: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

ABSTRACT

The identification process in network environments is a very important issue, it consists of

knowing who is using a resource and thereby it aggregates security and integrity to this envi-

ronment, enabling its controlled use. However, the diversification of network resources implies

in the use of many distinct credentials by a same user, which means a disadvantage from the

usability point of view. A potential solution for this problem is Single Sign-On (SSO), a me-

chanism whereby users authenticate themselves only once and are automatically authorized

to access any further resource they need. In this context, the proposal of this work consists of

developing an scheme of secure authentication for Squid proxy-cache, with strong support in

SSO strategy, with the main goal in optmize usability and security in the use of this resource. A

case study applied to Novell networks was done, a favorable environment to the development of

SSO mechanism. Finally, a secure interface was implemented, it was based in any LDAP user

database, particularly studied for Novell network’s use case. Thereat, a customizable secure

authentication system for Squid was developed, eliminating the direct interation between the

proxy-cache system and the end user.

Key words: authentication. single sign-on. Squid proxy-cache. Novell eDirectory.

Page 7: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

Lista de Figuras

FIGURA 1 Ambiente de Autenticacao . . . . . . . . . . . . . . . . . . . . . . . . . 16

FIGURA 2 Esquema de autenticacao descentralizada . . . . . . . . . . . . . . . . 17

FIGURA 3 Pseudo-SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

FIGURA 4 SSO verdadeiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

FIGURA 5 Soquetes de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

FIGURA 6 Janela para autenticacao no navegador de internet . . . . . . . . . . . 26

FIGURA 7 Esquema geral da solucao proposta . . . . . . . . . . . . . . . . . . . . 28

FIGURA 8 Diagrama de classes do Servidor SSO . . . . . . . . . . . . . . . . . . 30

FIGURA 9 Interface de logon do Novell Client . . . . . . . . . . . . . . . . . . . . . 33

FIGURA 10 Icone de bandeja do Cliente SSO . . . . . . . . . . . . . . . . . . . . . 33

FIGURA 11 Informacoes do certificado no navegador de internet . . . . . . . . . . . 40

FIGURA 12 Diagrama de sequencia para acesso a internet com SSO . . . . . . . . 42

FIGURA 13 Diagrama de sequencia para acesso a internet sem SSO . . . . . . . . 42

FIGURA 14 Capturas do Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Page 8: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

Lista de Siglas

API Application Programming Interface

ASP Authentication Service Provider

DIB Directory Information Base

DIT Directory Information Tree

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

ICP Internet Cache Protocol

ISP Internet Service Provider

LAN Local Area Network

LDAP Lightweight Directory Access Protocol

LDAPS Lightweight Directory Access Protocol over SSL

MD5 Message-Digest algorithm 5

NDS Novell Directory Services

NIS Network Information Service

NNS Netware Name Service

NSF National Science Foundation

NTLM NT Lan Manager

OTP One-Time Password

PAM Pluggable Authentication Modules

PIN Personal Identification Number

POP3 Post Office Protocol Version 3

RMI Remote Method Invocation

RPC Remote Procedure Call

SASL Simple Authentication and Secure Layer

SMB Server Message Block

SSL Secure Sockets Layer

SSO Single Sign-On

TCP Transmission Control Protocol

UDP User Datagram Protocol

WAN Wide Area Network

Page 9: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

Sumario

1 INTRODUCAO 10

2 DESENVOLVIMENTO 122.1 FUNDAMENTACAO TEORICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.1 Autenticacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.1.1 Fatores de seguranca . . . . . . . . . . . . . . . . . . . . . . . . 122.1.1.2 Controle de acesso . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.1.3 Terminologia de infraestrutura de autenticacao . . . . . . . . . . 15

2.1.2 Evolucao de sistemas de autenticacao . . . . . . . . . . . . . . . . . . . . 162.1.3 Sistemas de autenticacao SSO . . . . . . . . . . . . . . . . . . . . . . . . 182.1.4 Servicos de diretorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.5 Sistema proxy-cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.6 Comunicacao interprocessos . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.7 Aplicacao cliente-servidor: soquetes de rede . . . . . . . . . . . . . . . . 24

2.2 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.1 O problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.2 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.3 Solucao proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.3.1 O servidor SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.3.2 O cliente SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.3.3 A interface web para logon do usuario . . . . . . . . . . . . . . . 342.2.3.4 A interface de comunicacao com o Squid . . . . . . . . . . . . . 34

2.2.4 Preparacao do ambiente computacional . . . . . . . . . . . . . . . . . . . 352.2.4.1 Configurando o Squid e o Servidor SSO . . . . . . . . . . . . . 352.2.4.2 Configurando o Apache . . . . . . . . . . . . . . . . . . . . . . . 372.2.4.3 Consideracoes desta implementacao . . . . . . . . . . . . . . . 40

2.3 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 CONCLUSOES 44

REFERENCIAS 45

APENDICES 46

A Script Perl para comunicacao com o Squid 47

B Arquivo de configuracao do Squid 48

C Arquivo de configuracao vhost-ssl.conf 49

D Capturas do Wireshark 50

Page 10: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

10

1 INTRODUCAO

Assim como na vida real temos uma identidade, unica, que nos distingue das demais

pessoas e elementos, o uso de recursos1 em rede tambem requer uma identificacao de quem

esta solicitando servicos. Essa identificacao e importante pois deve-se conhecer quem esta

solicitando acesso de forma a aplicar de regras de acesso, permissoes e registro de acoes.

A maneira mais comum de identificacao e a autenticacao. Autenticacao e o processo de

verificacao que compara uma entrada do usuario (dita credenciais) com dados de identificacao

armazenados eletronicamente, supostamente associados biunivocamente. Se as credenciais

apresentadas forem validas, entao e concedido acesso ao recurso solicitado para o usuario

autenticado, conforme polıticas de acesso. O metodo mais simples de autenticacao que

existe e a apresentacao do par usuario e senha, entretanto metodos mais sofisticados sao

constantemente desenvolvidos e aprimorados, como identificacao por biometria e tokens de

autenticacao.

Entretanto, em um ambiente de rede, a diversificacao de recursos implica um conjunto

de credenciais para um unico usuario, cada uma concedendo acesso a um recurso especıfico.

Esse gerenciamento de identidades tornou-se um problema crıtico, amplamente discutido atu-

almente. A saıda mais comum, adotada hoje em dia, e o uso das mesmas credenciais para

todos os recursos, e a saıda mais simples e aplicavel, um trade off entre seguranca e usabili-

dade.

Uma solucao potencial para o problema em questao e o Single Sign-On (SSO). SSO e

uma tecnica em que um usuario se autentica apenas uma vez e e automaticamente autorizado

a outros sistemas que requerem autenticacao, sem a necessidade de interacao manual [1, 2].

Seu uso aumenta a usabilidade em rede, diminui erros humanos e centraliza o gerenciamento

de usuarios.

Neste trabalho, sera abordado o problema de autenticacao para um sistema proxy-

cache, do ponto de vista de usabilidade e seguranca. A proposta e implementar um sistema

de autenticacao que englobe a estrategia SSO e um mecanismo de autenticacao seguro con-

tra uma base de usuarios com suporte a LDAP, de forma a funcionar como um auxiliador

de autenticacao externo para o Squid proxy-cache. Como caso de uso, essa proposta sera

implementada em redes Novell, todavia seu uso pode ser facilmente adaptado para outras in-1Neste trabalho, um recurso pode ser qualquer entidade de rede que prove algum tipo de servico ao usuario –

por exemplo, instant messenger, e-mail, sistema de arquivos e sistemas ERP – e qualquer informacao que agregue

valor ao negocio ou finalidade em questao.

Page 11: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

11

fraestruturas. Com isso, o objetivo principal deste trabalho e implementar um sistema capaz de

prover autorizacao transparente ao proxy-cache Squid baseado nas credenciais de usuarios

do sistema de diretorios Novell eDirectory.

Nesse contexto, almeja-se desenvolver um sistema cliente-servidor de autenticacao

single sign-on capaz de:

• Fazer a autorizacao SSO de usuarios autenticados na Novell;

• Oferecer uma interface de autenticacao segura para usuarios nao autenticados na Novell,

com consulta de validacao de credenciais na propria base de usuarios da Novell.

Page 12: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

12

2 DESENVOLVIMENTO

2.1 FUNDAMENTACAO TEORICA

Este trabalho engloba aspectos teoricos e uso de ferramentas que valem ser detalha-

das. Essa secao objetiva apresentar este detalhamento, que servira como base e motivacao

para o entendimento da proposta e desenvolvimento deste trabalho. Nas Secoes 2.1.1 a 2.1.3,

sao apresentados conceito referentes a sistemas de autenticacao, que serao usados durante

o decorrer desde projeto. Nas Secoes 2.1.4 a 2.1.7, sao apresentadas ideias inerentes as

ferramentas que serao usadas no desenvolvimento deste projeto, isto e, tecnologias para com-

putadores em rede.

2.1.1 Autenticacao

Como ja introduzido na Secao 1, o processo de autenticacao e muito importante em

um ambiente de rede. Nesta secao, serao apresentados alguns conceitos com relacao ao

processo de autenticacao do ponto de vista de seguranca e algumas terminologias que serao

utilizadas adiante.

2.1.1.1 Fatores de seguranca

Do ponto de vista de seguranca, autenticacao e essencial. Em um ambiente de rede,

um recurso e um fator crucial por representar alguma especie de valor para o negocio ou

finalidade de uso em questao. Neste contexto, o recurso possui um dono, que pode ser

um indivıduo ou um grupo de indivıduos. Compete a gestao de seguranca e tecnologia da

informacao a protecao deste, de forma que apenas indivıduos autorizados sejam capazes de

ter acesso ao recurso desejado. Em geral, a protecao de recursos e fundamentada em tres

pilares [3]:

1. Confidencialidade: cuida para que o recurso nao seja acessıvel para indivıduos ou

grupos de indivıduos nao autorizados;

2. Integridade: garante que o recurso esteja ıntegro, isto e, nao seja alterado acidental ou

intencionalmente de forma que perca sua validade;

Page 13: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

13

3. Disponibilidade: o recurso deve estar acessıvel sempre que houver necessidade do

usuario.

Portanto, um ambiente seguro ideal seria aquele que atendesse a esses tres requisitos

sem falhas ou ameacas. Qualquer ameaca a um desse fatores e chamada de risco. Por

conseguinte, e necessario que profissionais de seguranca conhecam bem as necessidades

de seguranca do ponto de vista desses tres requerimentos e, da mesma forma, conheca os

riscos associados.

Vale destacar que todos os fatores de seguranca apresentados nessa secao baseiam-

se no uso de recursos por indivıduos definidos. Ao processo que analisa requisicoes e as

valida a fim de tomar a decisao de concessao da-se o nome de controle de acesso.

2.1.1.2 Controle de acesso

O controle de acesso e o principal fator na protecao de recursos. E atraves dele que

e possıvel conceder ou declinar acesso ao recurso solicitado. Em geral, o controle de acesso

compreende tres processos [3]: autenticacao, autorizacao e auditoria, que serao expostos

a seguir.

Autenticacao

Como a grande maioria das entidades em computacao, um usuario e abstraıdo em um

objeto que o identifique, caracterizado por um identificador de usuario (ID de usuario). Um ID

de usuario e associado a um unico usuario, e o objeto abstrato, em geral, possui informacoes

deste (como nome, telefone e caracterısticas pertinentes ao sistema em questao). A partir

deste objeto que a autenticacao e feita e, da mesma maneira, o controle de acesso.

O processo de autenticacao e composto por duas etapas [3]: identificacao e

autenticacao em si.

A identificacao consiste em dar uma identidade ao usuario que esta se autenticando.

Essa identidade e o proprio ID do usuario. Nesta etapa, o sistema de autenticacao procura por

todos os objetos e identifica o usuario tendo em vista os privilegios com relacao ao recurso

que ele esta solicitando acesso.

A autenticacao em si, por sua vez, valida a identificacao do usuario feita na etapa

anterior. Essa validacao e feita atraves da apresentacao de uma evidencia que certifica que

essa pessoa que esta solicitando acesso em nome deste usuario identificado e realmente o

Page 14: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

14

dono desta identificacao. Essa evidencia e chamada credencial e pode ser:

• Algo que o usuario sabe: e um segredo compartilhado entre as duas partes (usuario e

recurso). O mais comum e o par usuario e senha, mas temos outras formas como os

PINs (Personal Identification Number).

• Algo que o usuario possui: e baseado em uma posse do usuario, certificado pela auto-

ridade de autenticacao. Como exemplos, vale citar chaves de carro, tokens, que geram

uma OTP (One-time Password) ou qualquer outro mecanismo que exija a posse de um

dispositivo ou codigo dinamico.

• Algo que o usuario e: consiste na autenticacao embasada na biometria do solicitante,

como impressao digital, analise de voz, reconhecimento de face, retina e ıris, e qualquer

outra estrategia que use de caracterısiticas fısicas do usuario.

Autorizacao

A autorizacao e o processo de conceder acesso a um determinado recurso para um

usuario ja identificado e autenticado, portanto, e responsavel por prover acesso autenticado

ao recurso solicitado.

Do ponto de vista pratico, as fases de autenticacao e autorizacao nao sao tao distin-

tas. Em linhas gerais, a autenticacao compete apurar a identidade do cliente, enquanto a

autorizacao compete determinar permissoes de acesso frente a identidade, ja validada, do

solicitante.

Diante dessa interdependencia, o padrao que sistemas operacionais e aplicacoes em

geral costumam seguir e o processo de logon do usuario. Neste metodo, o usuario fornece

suas credenciais, iniciando o processo de autenticacao. Depois de autenticado, a aplicacao

gera um estrutura para este usuario, chamado de token de acesso. Sempre que o usuario

solicitar acesso a um recurso dentro da aplicacao, ela verifica o token do usuario e faz o

controle de acesso, constituindo o processo de autorizacao. Assim, o token de acesso e a

interface entre autorizacao e autenticacao, pois ele e gerado na fase de autenticacao e usado

nas fases de autorizacao.

Auditoria

A partir do momento que um usuario e autenticado e autorizado a acessar um recurso,

Page 15: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

15

e necessario que este recurso proveja um mecanismo de registro de acoes do usuario, para

que seja possıvel saber de que maneira esses clientes estao usando o recurso. Por outro lado,

e necessario ainda que este recurso seja capaz de registrar tentativas de acesso indevidos.

Neste contexto, a funcao da auditoria e registrar todas as acoes dos usuarios diante de

um recurso. Do ponto de vista de seguranca, a auditoria e muito importante, pois e ela que

possibilita determinar os acessos (devidos e indevidos) ao recurso e registrar as acoes dos

usuarios autenticados.

2.1.1.3 Terminologia de infraestrutura de autenticacao

No processo de autenticacao, geralmente temos envolvidas as seguintes partes [3]:

Solicitante e a parte que provera suas credenciais. Pode ser uma pessoa ou um software,

geralmente referidos como cliente ou usuario.

Autenticador e a parte que prove recursos ao solicitante, por isso precisa validar sua identi-

dade. Em geral, e dito servidor.

Autoridade/Banco de Seguranca e a parte que contem as informacoes de credenciais e,

muitas vezes, os mecanismos de identificacao e autenticacao. Pode ser desde um ar-

quivo, um sistema de diretorios, uma base centralizada de usuarios ou um conjunto de

servidores de autenticacao.

Desta forma, de De Clercq [1], encontramos as seguintes terminologias de autenticacao:

Servidores de Autenticacao sao as maquinas que realizam tarefas de autenticacao, diz res-

peito a parte fısica;

Autoridades de Autenticacao sao as entidades confiaveis que fazem a autenticacao em si,

diz respeito a parte logica;

Infraestrutura de Autenticacao e o conjunto de servidores e autoridades de autenticacao,

diz-se que esse conjunto prove os servicos de autenticacao.

Em um ambiente de rede, cada recurso que exige identificacao possui uma autoridade

de autenticacao associada. Como exemplo, podemos citar domınios de rede (em arquiteturas

Windows, cuja autoridade de autenticacao e o servidor Active Directory) ou uma arvore (em

arquitetura Novell, cuja autoridade de autenticacao e o servidor Novell eDirectory).

Em um processo de autenticacao padrao, o usuario submete suas credenciais a autori-

dade de autenticacao, que ira validar tais credenciais baseada em seu banco de usuarios. Se

Page 16: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

16

FIGURA 1: Ambiente de Autenticacao. Nesta ilustracao, podemos destacar a infraestrutura de

autenticacao, composta por um servidor de autenticacao e uma autoridade de autenticacao

(Novell eDirectory).

as credenciais forem validadas, entao diz-se que elas sao autenticas, e ao usuario e conce-

dido acesso ao recurso solicitado conforme permissoes de controle de acesso e processos de

autorizacao. Em geral, autoridades de autenticacao cedem ao usuario um token que o identi-

fica como usuario autenticado. Vale destacar que o processo de autenticacao apenas concede

ou nega acesso a um determinado recurso, mas nao dispoe regras de acesso. As regras de

acesso sao filtros que, a partir de uma credencial, determina o que um usuario pode ou nao

fazer com o recurso a que se autenticou. O processo de autenticacao e ilustrado na Figura 1.

2.1.2 Evolucao de sistemas de autenticacao

Quando sistemas de computadores foram introduzidos, a computacao era centralizada,

isto e, os usuarios usavam terminais conectados a computadores centrais, os chamados main-

frames. Nesta fase, a autenticacao era feita de forma centralizada, o unico computador “inte-

ligente” era o computador central. Com o passar dos anos, a computacao foi evoluindo e

microcomputadores foram sendo incorporados a uma rede computadores, que se comunica-

vam entre si por protocolos de redes, como o TCP/IP. Com isso, o esquema de autenticacao

foi mudando, tornando-se descentralizado, pois os recursos em rede foram sendo distribuıdos

e seu uso, se diversificando. Deste modo, para cada recurso a que o usuario precisava ter

acesso, ele tinha uma credencial associada.

Diante disso, muitos sistemas de autenticacao foram criados. Um boa referencia nesta

area e o livro do Todorov [3]. Em linhas gerais, os sistemas de autenticacao dividiram-se em

dois grandes grupos: sistemas de autenticacao centralizados e descentralizados.

Page 17: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

17

Os sistemas de autenticacao descentralizados surgiram gracas a diversificacao de

recursos em rede. Neste modelo, cada recurso possui sua propria base de usuarios para

autententicacao e polıticas de controle de acesso.

FIGURA 2: Esquema de autenticacao descentralizada.

O sistema de autenticacao descentralizado apresenta sua primeira desvantagem do

ponto de vista de usabilidade. Um mesmo usuario precisa ter uma porcao de credenciais e

se autenticar para todos os recursos aos quais precisa ter acesso. Alem disso, se o usuario

quiser manter a mesma senha para todos os recursos, por exemplo, ele precisa mudar todas

quando mudar alguma delas. Do ponto de vista de administracao, a descentralizacao tambem

nao apresenta vantagens, pois ha varias bases de usuarios distintas a serem mantidas.

Sistemas de autenticacao centralizados, por sua vez, possuem toda a base de usuarios

e polıticas centralizadas em uma unica autoridade de autenticacao. A grande vantagem disso

e que os clientes se autenticam apenas uma vez para ter acesso a todos os recursos. Aos

administradores, por sua vez, a manutencao e facilitada, visto que ha apenas uma base a ser

gerenciada. Do ponto de vista de seguranca, sistemas de autenticacao centralizados apre-

sentam a desvantagem de que, se uma entidade mal intencionada descobre as credenciais de

um usuario, por ser unica, essa entidade tera acesso a todos os recursos disponıveis a esse

usuario. A centralizacao e um nome generico para sistemas de autenticacao Single Sign-On

(SSO), e o que sera apresentado na proxima secao.

Page 18: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

18

2.1.3 Sistemas de autenticacao SSO

O Open Group [4] define SSO como sendo o mecanismo pelo qual uma unica acao de

autenticacao e autorizacao do usuario concede acesso a todos os computadores e sistemas

aos quais ele tem acesso, sem a necessidade de fornecer multiplas senhas.

Por ser um metodo muito interessante por representar um bom trade-off entre seguranca

e usabilidade, muitos sistemas de autenticacao SSO surgiram. Nesta secao, sera apresentado

uma classificacao basica de sistemas SSO, baseada na taxonomia desenvolvida em Pashala-

dis e Mitchell [2].

Essencialmente, temos dois tipos de sistemas SSO: pseudo-SSO e SSO verdadeiro.

O pseudo-SSO e um sistema que apenas executa os mecanismos de autenticacao

dos recursos aos quais prove acesso a partir das credenciais armazenadas, ditas identidades

SSO. Neste caso, o usuario efetua a autenticacao no sistema pseudo-SSO, dita autenticacao

primaria, e, cada vez que acessa um recurso em rede, e autenticado automaticamente pelo

pseudo-SSO. Esse esquema de autenticacao implica que o sistema pseudo-SSO armazena

identidades para acesso a recursos especıficos, portanto, deve armazenar, no mınimo, n iden-

tidades para acesso a, no maximo, n recursos. Por isso, a relacao entre identidade e recurso

e dita n : 1: e necessario uma ou mais identidade(s) no pseudo-SSO para acesso a um unico

recurso. A autenticacao pseudo-SSO e ilustrada na Figura 3.

FIGURA 3: Pseudo-SSO.

O SSO verdadeiro, por sua vez, e constituıdo por entidades chamadas ASP (Authen-

tication Service Providers). O ASP possui uma integracao com recursos aos quais provera

acesso, dada por uma comunicacao segura; neste caso, ao contrario do pseudo-SSO, o

unico processo de autenticacao que e feito e entre o usuario e o ASP. O ASP, por sua vez,

apenas notifica ao recurso em questao sobre a autenticacao do usuario, dito declaracao de

Page 19: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

19

autenticacao. Com isso, a relacao entre identidade e recurso e dita n : m, isto e, alem de

poder existir varias identidades SSO para um unico recurso, como e o caso do pseudo-SSO,

e possıvel ainda que o ASP use a mesma identidade SSO para prover acesso a mais de um

recurso. O metodo SSO verdadeiro e ilustrado na Figura 4. Por ser responsavel pelo arma-

zenamento das identidades, em geral um ASP armazena as credenciais de maneira segura,

usando criptografia, por exemplo.

FIGURA 4: SSO verdadeiro.

2.1.4 Servicos de diretorio

Ate agora, foram discutidos metodos de protecao e autenticacao para uso de recursos

em rede. Tendo em vista o foco deste trabalho, onde serao usados servicos de diretorios,

em particular o Novell eDirectory, como autoridades de autenticacao e o recurso alvo sera

o Squid proxy-cache, nesta e na proxima secao serao apresentados conceitos referentes a

essas estruturas, onde apresentamos as ferramentas abordadas neste trabalho.

Um diretorio e um repositorio de informacoes sobre objetos, organizados segundo um

criterio que facilite sua consulta [5]. A definicao de diretorio e muito ampla, nao se restringe

ao escopo deste trabalho, mas possui aplicacoes diversas. Em geral, um diretorio contem

informacoes diversas sobre um usuario, e pode ser aplicado em varios contextos. Por exem-

plo, vamos considerar um site de e-commerce. Na segunda vez que e acessado, podemos

perceber que o site comeca a construir paginas personalizadas para o usuario, baseado em

seus interesses de compra. Isso e feito porque o site obtem informacoes do usuario a par-

tir dos cookies armazenados de navegacoes anteriores e, a partir de informacoes sobre este

usuario armazenadas em seu diretorio constroi uma pagina personalizada.

O servico de diretorio [5, 6], por sua vez, e uma entidade de gerenciamento seguro

Page 20: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

20

de informacoes interrelacionadas entre si, suporta a replicacao de informacoes e e otimizado

para busca e leitura. Na pratica, servicos de diretorios provem uma tecnologia poderosa de

gerenciamento de dados, oferecendo administracao centralizada e replicacao das informacoes

em um ambiente de computacao distribuıda. Alem disso, a informacao e organizada de ma-

neira hierarquica e armazenada de maneira segura. O tipo de informacao armazenada em um

diretorio varia de acordo com sua aplicacao. No contexto de autenticacao e rede de computa-

dores, o diretorio armazena informacoes sobre pessoas, grupos, recursos e servicos.

Um servico de diretorio e composto, basicamente, por alguns elementos:

Objeto e o item mais simples do diretorio, e uma estrutura de dados, com atributos (ou pro-

priedades) e sintaxe proprios que define as entradas de dados do diretorio;

Esquema define, internamente, o conteudo do diretorio. Define, ainda, as propriedades de

objetos e a sintaxe que define seus valores. Por fim, o esquema determina como o

diretorio e estruturado;

DIT do ingles, Directory Information Tree, ou simplesmente arvore do diretorio, e a organizacao

hierarquica das informacoes em um diretorio. Existem objetos em um diretorio que sao

ditos conteineres, sao responsaveis por agrupar outros objetos do diretorio e constituem

os nos da arvore do diretorio. A DIT prove uma organizacao logica e visual dos objetos

que facilitam a administracao do diretorio.

DIB do ingles, Directory Information Base, a DIB e o banco de dados que contem as

informacoes do diretorio armazenadas. A DIB e dividida em particoes, para suportar

diretorios geograficamente distribuıdos e melhorar o desempenho de busca e leitura.

Por isso, servicos de diretorios suportam replicacao de dados, onde as DIBs sao copi-

adas para multiplos servidores de diretorio. A replicacao e importante pois aumenta a

tolerancia a falhas pela redundancia e melhora o desempenho de busca em sistemas

distribuıdos (visto que servidores geograficamente distribuıdos possuem uma copia dos

dados do diretorio).

Com a popularizacao dos sistemas de diretorios e sua grande utilidade, muitas

aplicacoes foram surgindo desde meados dos anos 1990. Como exemplos, podemos citar

o Microsoft Active Directory, o ApacheDS, o OpenLDAP, o Open Directory, entre outros. Neste

trabalho, vamos abordar o Novell eDirectory.

O Novell eDirectory e um servico de diretorio muito usado atualmente e amplamente

desenvolvido. Antes de sua introducao em 1993 no Novell Netware 4.0, a Novell usava um

Page 21: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

21

servico de gerenciamento de usuarios, nao tao complexo, chamado bindery, que nao supor-

tava nem replicacao de dados. Com o crescimento do uso de redes, a Novell lancou um add-on

para o Netware 3.0 chamado NNS (Netware Name Services), em 1990, agregando replicacao

e sincronizacao de dados entre grupos de servidores bindery chamados de domınio. Entre-

tanto, o NNS apresentava uma serie de deficiencias e limitacoes. Em 1993, a Novell intro-

duziu o chamado NDS (Netware / Novell Directory Services), substituindo o NNS em 1994

e tornando-se, com o passar dos anos, uma ferramenta robusta para gerenciamento de di-

retorios. Em 2001, com o lancamento da versao 8, o NDS passou a chamar-se simplesmente

eDirectory.

Atualmente, o eDirectory apresenta o grande diferencial dos demais servicos de di-

retorios por ter sido portabilizado para rodar em varias plataformas. Hoje, em sua versao 8.8

SP6, funciona perfeitamente em Windows, Netware, Linux e Solaris.

2.1.5 Sistema proxy-cache

Um sistema proxy-cache – ou web cache – e uma entidade de rede que responde

por solicitacoes HTTP no lugar de um servidor Web [7]. E geralmente instalado em um ISP

(Internet Service Provider). Por exemplo, em uma empresa, instala-se um servidor proxy-cache

em sua sede e configura-se todos os browsers para usar este servidor. O mesmo acontece

em um ISP maior, como a Telefonica, por exemplo. O servidor proxy armazena solicitacoes

Web localmente. Essa armazenacao local e chamada de caching, por isso e dito proxy-cache,

pois armazena um cache de todas as respostas de solicitacoes que recebe.

O uso de um servidor proxy se da mediante a configuracao no browser do cliente.

Uma vez configurado, todas as solicitacoes HTTP serao encaminhadas ao servidor proxy ao

inves de ser encaminhada diretamente ao servidor web. Ao receber uma solicitacao HTTP, o

proxy verifica se nao possui o objeto solicitado armazenado localmente em seu cache. Se ele

possuir o objeto, entao retorna-o ao cliente atraves de uma resposta HTTP, senao ele obtem

o objeto atraves de uma conexao TCP (Transmission Control Protocol) com o servidor web em

questao e encaminha o objeto ao cliente, que apenas se conecta com o servidor proxy. Vale

ressaltar que, neste ultimo caso, o proxy armazena uma copia do objeto recebido antes de

reencaminhar para o cliente, construindo assim seu cache. Nesse contexto, cabe dizer que o

proxy atua ora como servidor, quando responde as solicitacoes HTTP de clientes, e ora como

cliente, quando obtem objetos atraves da conexao TCP com servidores web.

As vantagens de se utilizar um proxy-cache em uma rede sao evidentes. Uma porque

Page 22: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

22

eventualmente reduz o tempo de resposta de uma requisicao HTTP de um cliente, caso te-

nha o objeto requisitado em seu cache, isso devido a velocidade de conexao em uma rede

LAN (Local Area Network) ser muito superior a da rede WAN (Wide Area Network). Outra e

consequencia direta da primeira: ha com isso uma reducao substancial do fluxo de acesso a

internet, otimizando assim o uso da banda e aumentando o desempenho de aplicacoes que

usam a internet.

Atualmente, sistemas proxy-cache, alem de prover a funcionalidade de web caching,

tambem oferecem mecanismos de controle de acesso, baseado na autenticacao de usuarios.

Com isso, varias vantagens surgem, desde princıpios legais, onde uma empresa, por exemplo,

pode impedir o uso de seu recurso de internet para acesso a conteudos inapropriados, ate re-

gistro de acessos, onde e possıvel, ao administrador de rede, acompanhar o que cada usuario

acessa, o tempo de conexao, a banda consumida, entre outros.

Um dos sistemas mais usados e o Squid [8, 9, 10], um proxy-cache para HTTP 1.0 com

recursos de controle de acesso, autorizacao e registro de acesso, atualmente em um projeto

coordenado por Duane Wessels, que e o desenvolvedor e esta envolvido desde o inıcio de sua

implementacao.

No comeco, chamava-se CERN HTTP Server. Foi o primeiro servidor proxy a realizar

web cache. Em 1994, Wessels juntou-se ao projeto Harvest, que tinha por objetivo ser “um

conjunto integrado de ferramentas para reunir, extrair, organizar, pesquisar, fazer cache e re-

plicar informacoes da Internet“. Neste perıodo, o entao CERN teve tres grandes melhorias:

uso mais rapido do sistema de arquivos, uma arquitetura baseada em um unico processo e

hierarquia de cache usando o ICP (Internet Cache Protocol) [10]. Em 1995, o projeto Harvest

tornou-se comercial, ate 1996, em que Wessels, patrocinado pela NSF (National Science Fun-

dation) comecou a trabalhar no projeto IRCache, publicando o Harvest cache, com o nome de

Squid, sob a licenca GNU.

O projeto IRCache estendeu-se ate 2000. Desde entao, o projeto Squid e mantido

por uma comunidade de desenvolvedores voluntarios e mantido por doacoes e financiamentos

arbitrarios de empresas que usam ou se beneficiam de alguma forma com o Squid.

Hoje, o Squid e amplamente usado como uma alternativa eficaz para web caching,

gratuito. Vem no repositorio da grande maioria de distribuicoes Linux, como Ubuntu e Novell

SuSE Linux Enterprise Server.

Por ser uma ferramenta para controlar acesso a internet, que e considerado um re-

curso, ao Squid se aplicam os conceitos de protecao expostos na Secao 2.1.1. Desta forma,

vamos apresentar como o Squid faz esse controle de acesso pelo uso de um mecanismo de

Page 23: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

23

autenticacao.

Quando um cliente solicita acesso a internet, o Squid o identifica por uma serie de

caracterısticas, algumas intrınsecas e outras que dependem da interacao do solicitante. De

forma geral, o controle de acesso poderia ser feito apenas por enderecos IPs, mas isso nao

e muito utilizado, porque exigiria um controle paralelo relacionando os usuarios com seus

respectivos enderecos IPs e que tambem todos seus enderecos IPs fossem fixos. Portanto, na

grande maioria das vezes, o controle e feito por nomes de usuario. Deste modo, a autenticacao

no Squid e feita da seguinte forma: o cliente (o navegador de internet, por exemplo) envia as

credenciais do usuario, que ele inseriu em uma janela de dialogo, em um campo chamado

Authentication no protocolo HTTP. Quando o Squid recebe o pacote, tenta decodificar o

conteudo deste campo e passa o conteudo decodificado a um programa que chamaremos de

auxiliar de autenticacao. Portanto, ao Squid compete o processo de autorizacao, enquando o

auxiliar de autenticacao e responsavel pelo processo de identificacao e autenticacao.

Neste contexto, o Squid suporta quatro metodos de autenticacao [8]:

1. Basic: e uma das formas mais usadas, entretanto uma das mais inseguras, pois o

conteudo do campo Authentication vem em formato Base-64, por isso, e facilmente

interceptado por um sniffer de pacotes. O metodo Basic da suporte a autenticacao sobre

um banco de dados, arquivos com padrao NCSA, NIS, LDAP, SMB, PAM, MSNT (contra

domınios Microsoft e Samba), SASL, POP3 e RADIUS.

2. Digest: e uma melhoria sobre o metodo Basic, em que as credenciais sao passadas com

encriptacao MD5. Suporta autenticacao sobre um arquivo texto e sistemas com suporte

a LDAP.

3. NTLM: e um protocolo de autenticacao proprietario desenvolvido pela Microsoft. Essen-

cialmente, o NTLM autentica um conexao TCP (e nao o usuario em si) e e um protocolo

binario, o que implica que apenas domınio Microsoft podem ser usados.

4. Negotiate: este e o metodo mais seguro desenvolvido. E um protocolo usado em am-

bientes que tem por autoridade de autenticacao o Microsoft Active Directory, e tambem

depende de versoes atualizadas de navegadores web, a saber, Internet Explorer, Mozilla

Firefox e Google Chrome. Neste metodo, as credenciais dos usuarios sao trocadas com

o Squid usando o protocolo Kerberos.

Para todas essas estrategias, ha um auxiliar de autenticacao associada. Neste traba-

lho, de maneira geral, estamos desenvolvendo um auxiliar de autenticacao, entretanto que nao

exija nenhuma interacao do usuario.

Page 24: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

24

2.1.6 Comunicacao interprocessos

Em sistemas computacionais, os processos2 estao sempre se comunicando entre si

para que possam executar uma tarefa em comum.

Essa comunicacao pode acontecer em duas instancias [7]. Quando os processos

estao em execucao no mesmo sistema final, a comunicacao e feita usando metodos es-

pecıficos definidos pelo sistema operacional usado, por exemplo, piping, filas de mensagens

e memoria compartilhada. Processos em execucao em diferentes sistemas finais, por sua

vez, comunicam-se entre si trocando mensagens atraves da rede pela qual estao interligados,

atraves de mecanismos como soquetes, RMI (Remote Method Invocation) e RPC (Remote

Procedure Call).

Pela natureza desta proposta, vamos dar enfase a comunicacao em rede, usando so-

quetes, seus principais conceitos e caracterısticas de implementacao.

2.1.7 Aplicacao cliente-servidor: soquetes de rede

Uma aplicacao em rede consiste essencialmente em um par de processos que trocam

mensagens entre si. Como exemplo, podemos tomar um navegador Web e um site qualquer

da internet que, embora seja simples, contem todos os conceitos a serem abordados nessa

secao. A grosso modo, quando o usuario solicita acesso a um determinado site, o navega-

dor de internet envia uma mensagem ao servidor Web que hospeda o site, que por sua vez

responde com uma informacao padronizada de tal maneira que o navegador seja capaz de

entende-la e exibı-la.

A partir desse exemplo, podemos destacar dois pontos essenciais em qualquer aplicacao

distribuıda: um processo que inicia uma requisicao e outro que responde com uma informacao

organizada e padronizada. Ao processo que inicia a requisicao, da-se o nome de cliente. Ao

processo que responde, da-se o nome de servidor. A organizacao e padronizacao aplicada a

informacao enviada pelo servidor da-se o nome de protocolo.

Por isso, uma aplicacao em rede e dita aplicacao cliente-servidor. Todas as mensagens

trocadas entre uma aplicacao cliente-servidor sao organizadas segundo um protocolo, isto e,

um conjunto de regras que define o formato do conteudo da mensagem de tal maneira que ela

seja inteligıvel a ambas as partes envolvidas na troca de mensagens.2Processo e um programa em execucao, os recursos por ele alocados e todas as informacoes que estao sendo

manipuladas por ele.

Page 25: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

25

Para enviar e receber mensagens, as aplicacoes cliente-servidor usam uma interface

de software chamada soquete. Os soquetes sao uma API entre a aplicacao e o meio de

transmissao, sao responsaveis por intermediar a comunicacao de dados entre o programa e

a rede. A Figura 5, adaptada de Kurose e Ross [7], ilustra muito bem o papel de um soquete

e como a aplicacao e o transporte se comunicam entre si. Por ser uma interface entre eles,

o soquete possibilita ao desenvolvedor um controle amplo sobre os elementos inerentes a

aplicacao, entretanto um controle mınimo no que diz respeito ao transporte: apenas a escolha

do protocolo e o ajuste de alguns de seus parametros.

FIGURA 5: Aplicacoes, soquetes e transporte.

Cada protocolo de transporte escolhido determina o tipo de soquete a ser utilizado.

Neste contexto, vamos abordar apenas soquetes TCP/IP, que compreende essencialmente

dois tipos: soquetes de fluxo, que usam o protocolo TCP, e soquetes de datagrama, que usam

o protocolo UDP (User Datagram Protocol). Como a aplicacao cliente-servidor desenvolvida

sera multiplataforma, isto e, o cliente sera executado em um sistema operacional (no caso,

Windows), enquanto o servidor sera executado em outro (no caso, Linux), duas linguagens

de programacao serao abordadas no ambito de implementacao de soquetes: C [11, 12] e

Java [13].

2.2 METODOLOGIA

Nesta secao, sera apresentada a metodologia de desenvolvimento do trabalho, desde

a apresentacao do problema, um esquema da solucao proposta, um detalhamentos das partes

da solucao e as ferramentas e ambiente computacional utilizados.

Page 26: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

26

2.2.1 O problema

Neste trabalho, sera abordado o caso de autenticacao e autorizacao para acesso a

internet, o Novell eDirectory como base de usuarios, apresentado na Secao 2.1.4, e o Squid

proxy-cache como recurso em questao, apresentado na Secao 2.1.5.

Como discutido na Secao 2.1.1, a autenticacao e um fator importante e indispensavel

no uso de recursos em rede, para que se possa fazer sua protecao e tambem a auditoria de

uso. O controle de acesso a internet e um caso tıpico, e uma das finalidades de uso do Squid

e justamente proporcionar o controle de acesso e auditoria de uso da internet.

O primeiro problema diz respeito a usabilidade, dado que e necessario que o usuario

forneca suas credenciais sempre que precisar usar a internet, seja pelo navegador de internet,

seja por um programa de e-mail ou qualquer outro software que faca uso da internet por HTTP.

Isso acarreta problemas secundarios, como loops de autenticacao (quando o navegador, por

exemplo, comeca a pedir usuario e senha varias vezes) e programas que usem internet e nao

suportam mecanismos de passagem de usuario e senha. Um exemplo dessa solicitacao e

ilustrado na Figura 6, usando o navegador Mozilla Firefox. Essa janela aparece sempre que o

usuario abrir o navegador de internet.

FIGURA 6: Janela para autenticacao no navegador de internet.

Por outro lado, na Secao 2.1.5, discutimos a maneira que o Squid faz a autenticacao

dos clientes, e os metodos de autenticacao suportados. O metodo mais usado e o Basic,

entretanto nele encontramos o primeiro problema: as credenciais sao passadas ao servidor

de maneira insegura. Isso e extremamente preocupante, pois se estamos usando uma base

de usuarios unica. Para resolver esse problema temos apenas uma alternativa: usar o metodo

de autenticacao Digest. Ambas enviam as credenciais do usuario pelo protocolo HTTP usando

um campo chamado Authentication.

Neste contexto, a proposta deste trabalho e desenvolver um esquema de autenticacao

que extermine de uma vez por todas qualquer duvida de seguranca presente na transmissao

de credenciais pelo protocolo HTTP e eliminar o dialogo de solicitacao de credenciais apre-

Page 27: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

27

sentados periodicamente por softwares que usam acesso a internet usando HTTP, como na-

vegadores de internet.

2.2.2 Ferramentas

Para o desenvolvimento do cliente SSO, utilizamos a linguagem C, a API da Novell para

comunicacao com o Novell Client, a API para threads da biblioteca windows.h e a biblioteca

para soquetes de rede winsock2.h. Para o desenvolvimento do servidor SSO, adotamos a lin-

guagem Java e a IDE de desenvolvimento Eclipse Helios (v3.6), munidos da API para soquetes

de rede da linguagem Java. Para a comunicacao entre o servidor e o Squid, estamos usando

a linguagem Perl, e para autenticacao web, a linguagem PHP e configuracoes de seguranca

usando certificados RSA.

Alem disso, as demais ferramentas sao:

• SuSE Linux Enterprise Server 10;

• Squid 2.5 stable 12;

• eDirectory 8.8 SP6;

• Apache 2.2.3.

2.2.3 Solucao proposta

Embora o proprio Squid ja possua um metodo de passagem de credenciais seguro (o

Digest, alem dos metodos para Microsoft, o NTLM e o Negotiate), a solucao proposta neste

trabalho procura contribuir para a usabilidade, usando uma estrategia de autenticacao SSO,

de forma que possa ser adaptada para qualquer infraestrutura de autenticacao que suporte

comunicacao por LDAP.

Primeiramente, vale observar em que se baseiam os metodos de controle de acesso

que o Squid possui. Quando uma requisicao de acesso e enviada, o Squid e capaz de controlar

o acesso baseado em varias caracterısticas dessa requisicao. As principais sao endereco IP

de origem e destino, domınio de origem e destino, endereco MAC de origem, porta de destino,

horario e, por fim, usuario solicitante. Esta ultima exige interacao do usuario, de forma que

forneca suas credenciais a serem validadas por um auxiliar de autenticacao do Squid (veja

Secao 2.1.5). A maneira mas comum e abstrata de fazer, portanto a mais usada, e baseada

em usuario solicitante. Daı surge a necessidade de uma estrategia de autenticacao.

Page 28: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

28

Todavia, o objetivo deste trabalho e eliminar os dois problemas apresentados na secao

anterior, a saber:

• Interacao do usuario para fornecimento de credenciais;

• Envio de credenciais pelo protocolo HTTP.

Um problema complementa o outro. Analisando a situacao, se nao houver interacao do

usuario, nao havera envio de credenciais por HTTP. Por conseguinte, o objetivo consiste em

usar uma outra caracterıstica, presente na solicitacao do cliente sem sua interacao, para fazer

a autenticacao contra uma base de usuarios.

Diante disso, vamos usar o endereco IP do solicitante, por ser uma caracterısitica sa-

tisfatoria e que pode ser utilizada para varios fins. A proposta consiste no desenvolvimento

de uma aplicacao externa, que vamos chamar de Servidor SSO, responsavel por fazer a

associacao entre endereco IP e usuario autenticado. Com isso, o Squid nao implementaria

nenhum metodo de autenticacao, ao inves disso usaria um metodo externo que respondesse

como se fosse um auxiliar de autenticacao. Essa proposta e ilustrada na Figura 7.

FIGURA 7: Esquema geral da solucao proposta.

Assim, nao serao usados os metodos de autenticacao do Squid apresentados na

Secao 2.1.5, ao inves disso, o servidor SSO fornecera um nome de usuario mediante um

endereco IP, que sera usado pelo Squid para controle de acesso.

Do ponto de vista de usabilidade, a solucao proposta consiste em duas partes:

1. Uma aplicacao cliente para SSO: o servidor SSO sera uma aplicacao servidora, que se

comunicara com um cliente por soquetes de rede, a fim de implementar uma aplicacao

pseudo-SSO (veja Secao 2.1.3).

2. Uma interface segura para logon do usuario: sera uma interface web, usando HTTPS,

atraves da qual o usuario fornecera seu usuario e sua senha, isto e, fara o logon. Esse

logon possuira um TTL (Time to live): dentro deste perıodo, o usuario nao precisara for-

necer suas credenciais em nenhum momento, ao contrario do que acontece nos metodos

Page 29: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

29

de autenticacao do Squid, em que o usuario precisa fornecer suas credenciais sempre

que um programa solicita acesso a internet.

Em vista da solucao proposta, podemos identificar entao algumas partes:

• O servidor SSO;

• Uma aplicacao cliente (para realizacao do SSO) que chamaremos de cliente SSO;

• Uma interface web para autenticacao segura no servidor SSO;

• Uma interface para comunicacao com o Squid (um auxiliar de autenticacao).

Essas partes e a estrategia de implementacao serao detalhadas nas proximas secoes.

2.2.3.1 O servidor SSO

O servidor SSO e uma aplicacao, feita em Java, com o objetivo de receber solicitacoes

do Squid contendo o endereco IP do solicitante e retornar o nome de usuario autenticado

naquele IP. Para obter essa informacao, o servidor SSO tera por base duas fontes:

1. O cliente SSO: baseado na estrategia de SSO, alguns clientes podem ter uma aplicacao

sendo executada em suas estacoes de trabalho. Essa aplicacao sera responsavel por

retornar ao servidor SSO o usuario autenticado nesta estacao. Vale ressaltar que nao

ha a necessidade do uso do cliente SSO para que o servidor SSO funcione, ele pode se

basear apenas no cache de usuarios, que sera apresentado a seguir.

2. Um cache de usuarios: O usuarios que nao tiverem o cliente SSO em suas estacoes

farao logon por uma interface web segura, usando credenciais de uma base LDAP con-

figurada, que sera responsavel por efetuar os processos de autenticacao e autorizacao.

Depois de devidamente autenticado, o servidor SSO armazena um cache em memoria e

em arquivos do usuario, seu respectivo endereco IP e a hora de seu logon, que servira

por base para um tempo util de vida de logon (o TTL). Isto funciona como se o usuario

estivesse se autenticando no servidor SSO.

Com isso, o servidor SSO e capaz de associar enderecos IPs com usuarios autentica-

dos. O cliente SSO e um modulo independente, que pode ser personalizado para funcionar

com qualquer infraestrutura de autenticacao. Neste trabalho, fizemos um estudo de caso para

funcionar em uma infraestrutura de autenticacao com Novell, baseado no sistema de diretorios

Novell eDirectory. Na Secao 2.2.3.2, sera detalhado melhor esse uso.

Page 30: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

30

A Figura 8 contem o diagrama de classes do servidor SSO. A seguir, uma explicacao

mais minuciosa do que faz cada classe e qual sua importancia no funcionamento da aplicacao.

FIGURA 8: Diagrama de classes do Servidor SSO.

SquidComm

E a classe principal, e instanciada logo que a aplicacao e inicializada. Contem um loop

infinito, responsavel por ficar a escuta de solicitacoes do Squid. Na verdade, as solicitacoes

nao sao recebidas diretamente do Squid, mas de um script escrito em Perl que e usado como

auxiliar externo. Esse script sera apresentado adiante. As solicitacoes do Squid sao recebidas

com o uso de soquetes de rede, neste caso, e usado um soquete UDP na porta 3025.

RespThread

E uma classe privada da classe SquidComm. E uma implementacao da interface Run-

nable do Java para uso de threads. Ela e responsavel por processar as solicitacoes recebidas

na classe SquidComm. Usa threads para que haja concorrencia entre essas solicitacoes. E

nesta classe que e feita comunicacao com o cliente SSO e busca no cache de usuarios autenti-

cados pela interface web. Seu construtor recebe dois parametros, que representam o soquete

da solicitacao recebida do Squid na classe SquidComm.

E nesta classe que e feito o processamento principal da aplicacao e, por conseguinte,

e dado o retorno ao Squid. Esse retorno pode ser: (1) uma String contendo o nome do usuario

ou (2) uma String contendo a sequencia de caracteres ERR, que e a resposta que o Squid

Page 31: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

31

espera caso nao seja encontrado nenhum usuario autenticado.

Esta classe contem uma regiao crıtica, isto e, uma parte do codigo que duas threads

nao podem usar ao mesmo tempo. No caso, o uso simultaneo causa o travamento de uma das

threads, e acontece quando o servidor SSO contata o cliente SSO: apenas um contato pode

ser feito por vez. Para solucionar esse problema, foi adotada a estrategia de exclusao mutua

usando semaforos. Esse e um semaforo estilo binario, isto e, ou a thread pode acessar ou

nao pode acessar. Ele e representado pelo atributo sem da classe ClientComm.

ClientComm

Esta classe e responsavel pela comunicacao com o cliente SSO, quando houver um.

Dado um certo endereco de IP, representado pelo parametro do metodo comunicaCliente,

essa classe tenta abrir um contato com esse endereco IP usando um soquete UDP na porta

3024. A resposta esperada e uma String contendo o nome de usuario autenticado na estacao

contatada. Caso o tempo limite de conexao expire (isto e, nao haja um cliente SSO sendo

executado no endereco IP dado), a classe retorna a String ERR.

CacheComm

A esta classe compete o processamento do cache de usuarios do servidor SSO. Este

cache consiste nos usuarios que se autenticaram no servidor SSO usando a interface web,

que sera apresentada adiante.

A representacao deste cache e feito de duas formas: na memoria volatil, ela e armaze-

nada como uma lista no servidor SSO (essa lista e o parametro ArrayList<Usuario> presente

em ambos os metodos da classe), e na memoria nao volatil, como arquivos com a seguinte

estrutura: o nome do arquivo e o endereco IP do cliente (no formato decimal) e o conteudo do

arquivo e o nome do usuario e o seu horario de logon. Neste contexto, existem dois diretorios

que armazenam esses arquivos: um chamado cache, que o servidor SSO processa em sua

inicializacao, e outro chamado queue, que sera processado durante a execucao do servidor

SSO. Os metodos processaCache e processaQueue processam o conteudo desses diretorios,

respectivamente, e armazenam na lista de usuarios.

Page 32: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

32

IpConv

Essa classe e usada na conversao de enderecos IPs do formato de texto (represen-

tados por 4 octetos) para o formato decimal ou do formato decimal para o formato de texto.

Armazenar os enderecos IPs em formato numerico e nao em texto facilita a busca. A con-

versao e feita da seguinte forma:

1. Texto para Decimal: Feito pelo metodo IpToDec, dado um endereco IP ip = a.b.c.d no

formato texto, ele ira converter para o decimal dec da seguinte forma:

dec = a ∗ 224 + b ∗ 216 + c ∗ 28 + d

2. Decimal para Texto: E funcao do metodo DecToIP essa funcao, e a operacao inversa da

conversao anterior, pode ser modelada pelo seguinte algoritmo:

Dados o decimal dec, o endereco IP correspondente na forma ip = oct[1].oct[2].oct[3].oct[4]

pode ser obtido pelo algoritmo:

(a) Defina i = 1 e fator = 224;

(b) Faca oct[i] =

⌊dec

fator

⌋;

(c) Defina dec = dec− (fator ∗ oct[i]);

(d) Defina fator =fator

28, incremente i e volte para o Passo 2b se i ≤ 4.

Usuario

E a representacao do cliente. Possui apenas atributos, a saber: (1) nome – seu ID

de usuario, (2) ip – o endereco IP em que efetuou logon e (3) horaLogin – a hora em que o

usuario efetuou logon. Vale ressaltar que esta classe e usada apenas para representar a lista

de usuarios do cache, portanto nao e usada no SSO.

2.2.3.2 O cliente SSO

O cliente SSO e uma aplicacao cujo intuito e ser executada em clientes que estao

autenticados em alguma infraestrutura de autenticacao. Por isso o nome, pois e ele quem

fara o SSO para acesso a internet. Isto significa que o ID de usuario com o qual o cliente

se autenticou na infraestrutura de autenticacao existente sera reaproveitado para o acesso a

internet.

Page 33: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

33

Deve ser uma aplicacao que permaneca em execucao e fique na escuta para receber

solicitacoes do servidor SSO.

Neste trabalho, abordamos a infraestrutura de autenticacao da Novell, usando o Novell

eDirectory. Um cliente se autentica na Novell usando um programa chamado Novell Client,

ilustrado na Figura 9. No ato do logon, o cliente SSO sera inicializado sem a intervencao do

usuario, por login script, um mecanismo que executa comandos no ato de logon do usuario.

FIGURA 9: Interface de logon do Novell Client.

Neste contexto, foi implementado um cliente SSO usando a linguagem C para sistemas

Windows, incorporando as APIs de threads e soquetes da Microsoft e as da Novell para lin-

guagem C. O cliente SSO e executado em segundo plano, e possıvel ver seu ıcone na bandeja

do Windows, como ilustrado na Figura 10. Quando recebe a solicitacao do servidor SSO, ele

retorna o ID de usuario da Novell que esta autenticado, realizando assim o SSO de quem esta

autenticado na infraestrutura da Novell.

FIGURA 10: Icone de bandeja do Cliente SSO.

Personalizacao do cliente SSO

Por ser uma aplicacao padrao, e por nao interessar ao servidor SSO qual a fonte de

usuarios que o cliente SSO esta consultando mas sim o ID do usuario propriamente validado,

o cliente SSO e uma aplicacao que pode ser personalizada e desenvolvida de acordo com a

infraestrutura de autenticacao da rede em questao.

O cliente SSO deve ser capaz de retornar o ID de usuario autenticado na estacao

Page 34: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

34

em questao. Quando e iniciado, o cliente SSO deve ficar aguardando uma conexao na porta

3024 UDP. Quando o servidor iniciar o dialogo com uma saudacao, e o cliente deve enviar

o ID de usuario do cliente autenticado localmente, tambem pela porta 3024 UDP. Como a a

comunicacao nao e orientada por conexao, nao ha inıcio nem encerramento da conexao.

2.2.3.3 A interface web para logon do usuario

Esta interface web tem por objetivo minimizar a interacao com o usuario para que possa

se autenticar no servidor proxy quando o SSO nao estiver disponıvel. E uma aplicacao escrita

em PHP, que possuira apenas dois campos, para que o usuario possa inserir seu ID de usuario

e sua senha. A aplicacao entao faz o processo de identificacao e autenticacao do usuario

contra um servidor LDAP pre-configurado.

Quando o usuario efetua o logon, suas credenciais sao enviadas via HTTPS encrip-

tadas usando criptografia assimetrica com certificados RSA. Para consulta LDAP, o PHP faz

uma conexao segura usando LDAPS com a base de usuarios pre-configurada.

Se o processo de autenticacao for bem sucedido, a aplicacao gera um arquivo de cache

na pasta queue para que o servidor SSO possa processar o novo usuario autenticado (veja

Secao 2.2.3.1).

Essa aplicacao e composta por dois arquivos: a interface do usuario, e o index.php, e

a aplicacao PHP em si, chamada de verifica_senha.php. Este e o responsavel por efetuar o

processo de identificacao e autenticacao do usuario e redireciona-lo para a pagina desejada,

se for o caso. Portanto, e esta aplicacao que e responsavel por fazer validar as credenciais do

usuario e autentica-lo no servidor SSO.

2.2.3.4 A interface de comunicacao com o Squid

Esta interface serve como auxiliar de autenticacao para o Squid (veja Secao 2.1.5),

todavia serve aqui como um autenticador externo, isto e, nao se baseia em nenhum metodo

de autenticacao existente do Squid (Basic, Digest, NTLM e Negotiate). Seu principal objetivo e

encaminhar a solicitacao do Squid para o servidor SSO e retornar sua resposta para o Squid.

E um script escrito usando a linguagem Perl. Ele e inserido na configuracao do Squid

como uma aplicacao externa, assim e possıvel invocar essa aplicacao passando alguns

parametros suportados pelo Squid. Como discutido na Secao 2.2.3, o parametro escolhido

foi o endereco IP do solicitante. Neste contexto, a aplicacao envia o endereco IP recebido

do Squid para o servidor SSO, logo em seguida, recebe sua resposta, que pode ser o ID de

Page 35: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

35

usuario autenticado no endereco dado ou a cadeia ERR, que significa que nao ha usuario au-

tenticado. Essa comunicacao e feita usando comunicacao nao orientada a conexao, isto e,

UDP, pela porta 3025.

Como o codigo deste script e mais curto, ele e apresentado no Apendice A. Nesta

versao do script, ele retorna ao Squid apenas qual usuario esta autenticado (no formato

OK user=ID) ou a cadeia ERR caso nao tenha encontrado ninguem autenticado no endereco

dado. Possıveis alteracoes neste script incluem manipulacoes com o usuario, como, por exem-

plo, contato com um servidor LDAP para verificar participacoes em grupo.

2.2.4 Preparacao do ambiente computacional

Nesta secao, o objetivo e descrever a maneira que todas as partes descritas ate aqui

interagem entre si e como sao configuradas. Todas as configuracoes, caminhos e versoes de

programas descritos aqui sao baseados em servidores SuSE Linux Enterprise Server 10 mas,

como todo Linux, pode ser facilmente adaptado para outras distribuicoes.

As configuracoes necessarias incluem:

• Configurar o Squid e o Servidor SSO;

• Configurar o Apache;

Algumas configuracoes que serao apresentadas nao sao obrigatorias, podem ser modi-

ficadas sem afetar o funcionamento do sistema. Todavia, o que e apresentado aqui foi testado

e esta em funcionamento. Vamos comecar pelas configuracoes necessarias no Squid.

2.2.4.1 Configurando o Squid e o Servidor SSO

O primeiro passo e adaptar a estrutura de diretorios do Squid para o funcionamento do

Servidor SSO.

A pasta dos arquivos de configuracao do Squid se encontram em /etc/squid. Neste

diretorio, sera criado um subdiretorio chamado sso, que contera:

1. O diretorio cache, onde ficarao os arquivos do cache do servidor SSO:

mkdir /etc/squid/sso/cache

2. O diretorio queue, onde ficarao os arquivos do cache do servidor SSO que ainda nao

foram processados:

mkdir /etc/squid/sso/queue

Page 36: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

36

3. O diretorio htdocs, onde ficara a aplicacao web para autenticacao do usuario contra uma

base de diretorios LDAP:

mkdir /etc/squid/sso/htdocs

No diretorio /etc/squid/sso deve estar o arquivo de configuracao do servidor SSO,

nomeado sso.conf, que possui os seguintes campos, ja comentados:

cachePath = /etc/squid/sso/cache # caminho do cache

queuePath = /etc/squid/sso/queue # caminho da queue

logPath = /var/log/squid/sso # caminhos de logs

clientTimeout = 1000 # timeout de conex~ao com o cliente SSO

logonTTL = 21600 # time-to-live do logon pela web

sso = true # existencia do cliente SSO

Caso seja ocultado algum campo deste arquivo ou seu valor seja deixado em branco,

os valores padrao sao os apresentados neste exemplo, e serao assumidos pelo servidor SSO.

Depois, e importante verificar as permissoes de acesso dos diretorios recem criados.

Neste caso, como o servidor SSO sera executado pelo usuario root, nao teremos problemas

com os diretorios cache e queue, todavia o diretorio htdocs e acessado pelo usuario da dae-

mon do apache (em nosso caso, o usuario wwwrun pertencente ao grupo www), portanto e

necessario certificar-se que o diretorio possui ao menos permissao de leitura para outros ou

atribuir propriedade da pasta ao usuario wwwrun, da seguinte forma:

chwon -R wwwrun.www /etc/squid/sso/htdocs

Por fim, vamos criar um diretorio:

mkdir /etc/squid/sso/bin

que contera o executavel do servidor SSO. E um arquivo jar compilado pelo Eclipse. Para

rodar, basta entrar no terminal:

java -jar /etc/squid/sso/bin/sso.jar &

Isto conclui a instalacao do servidor SSO.

Agora, e necessario configurar o Squid para funcionar com o servidor SSO. O arquivo

de configuracao segue no Apendice B. Dele, vale destacar as clausulas:

1. external_acl_type SquidSSO ttl=0 %SRC /usr/sbin/squid_ip.pl

Esta clausula e responsavel por usar o auxiliar externo escrito em Perl, neste caso no

diretorio /usr/sbin, que e a interface de comunicacao entre Squid e servidor SSO apre-

sentada na Secao 2.2.3.4, criando uma acl interna do Squid chamada SquidSSO. A

Page 37: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

37

variavel %SRC contem o endereco IP do solicitante e e passada para o script nesta cha-

mada.

2. acl autenticado external SquidSSO

Esta clausula cria uma regra de acesso do Squid simplesmente chamando a aplicacao

interna criada na clausula do Item 1.

3. http_access allow autenticado all

Esta clausula define que qualquer usuario que esteja autenticado conforme a aplicacao

externa definida no Item 1 tem permissao para acessar qualquer pagina HTTP. Na pratica,

o acesso e irrestrito, e apenas e sera registrado o nome de usuario retornado pelo auxiliar

externo.

4. deny_info ERR_TESTE all

Esta e uma clausula chave nesta configuracao. A clausula deny_info e chamada quando

o acesso e negado ao objeto especificado, neste caso, all, como definido na clausula do

Item 3. O primeiro parametro desta clausula define o que sera invocado quando o acesso

for negado. Neste caso, como ha simplesmente um nome, a pagina de erro exibida se

encontra em:

/usr/share/squid/errors/English/

e seu conteudo e simplesmente:

<meta

http-equiv="refresh"

content="0; url=https://<endereco_servidor>/ssologin/index.php?url=%U"

>

Isto significa que, sempre que o usuario obtiver um acesso negado, ele sera redirecio-

nado a pagina de logon da aplicacao web, apresentada na Secao 2.2.3.3. As questoes

de seguranca (repare que e chamado por https) e caminho da aplicacao serao discu-

tidos nas configuracoes do Apache. Merece destaque a variavel %U: ela contem a URL

solicitada pelo usuario, desta forma e possıvel redireciona-lo para sua pagina requisi-

tada caso sua autenticacao seja bem sucedida. Para mais variaveis disponıveis nesta

clausula, basta acessar a documentacao online do Squid [9].

2.2.4.2 Configurando o Apache

Tendo configurado o Squid, devemos configurar o Apache para:

Page 38: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

38

1. Usar seguranca HTTPS;

2. Configurar o diretorio /etc/squid/sso/htdocs como diretorio de paginas valido.

Configurando a seguranca HTTPS

Para o funcionamento das configuracoes que serao apresentadas nesta secao, e indis-

pensavel que o modulo SSL do Apache esteja ativado. Para isso, basta entrar no terminal:

a2enmod ssl

Para configurar a seguranca, antes de tudo e necessario gerar e assinar os certifica-

dos. Usaremos o openssl, uma implementacao livre para gerar e assinar certificados RSA.

E importante lembrar que este metodo nao e recomendavel. Para grandes empresas e inte-

ressante que o certificado nao seja autoassinado, mas que seja assinado por uma autoridade

reconhecida, como a Verisign3 e a Thawte4.

Para gerar e assinar os certificados:

1. Primeiro, deve-se criar a chave privada:

openssl genrsa -out server.key 2048

2. Em seguida, deve-se gerar a requisicao de certificacao. Se fossemos usar uma autori-

dade de certificacao, como a Verisign, pararıamos aqui e enviarıamos o arquivo gerado

nesta etapa. Durante esse processo, sao solicitadas diversas informacoes, que devem

ser corretamente informadas, entretanto nao ha problema ao ignorar o pedido de senha

em challenge password:

openssl req -new -key server.key -out req.csr

3. Por ultimo, vamos assinar e gerar o certificado (este comando deve ser digitado em uma

unica linha). Este certificado sera valido por 10 anos:

openssl x509 -req -days 3650 -in req.csr -signkey server.key -out server.crt

Depois de gerados, a chave e o certificado devem ser copiados para os seguintes

diretorios, respectivamente:3Para mais informacoes, basta acessar http://www.verisign.com.br/.4Para mais informacoes, basta acessar http://www.thawte.com/.

Page 39: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

39

cp server.key /etc/apache2/ssl.key

cp server.crt /etc/apache2/ssl.crt

Por fim, basta configurar o Apache. Para isso, basta criar um arquivo chamado:

/etc/apache2/vhosts.d/vhost-ssl.conf

O conteudo deste arquivo encontra-se no Apendice C. Depois de configurado, basta

reiniciar o servico do Apache e o acesso seguro por HTTPS estara disponıvel para qualquer

diretorio do servidor web.

Personalizando o caminho de diretorios de paginas do Apache

Agora, sera exposto como configurar o Apache para resolver o endereco:

https://<endereco_servidor>/ssologin

para o diretorio /etc/squid/sso/htdocs configurado na Secao 2.2.4.1 que contem a interface

web para logon do usuario.

Esta configuracao e feita usando um mecanismo do Apache chamado Alias. Para isso,

basta editar o arquivo /etc/apache2/default-server.conf e inserir:

Alias /ssologin "/etc/squid/sso/htdocs"

<Directory "/etc/squid/sso/htdocs">

Order allow,deny

Allow from all

AllowOverride All

</Directory>

Depois, e interessante que ainda que o solicitante tente acessar o endereco usando

HTTP seja automaticamente redirecionado para HTTPS. Isso pode ser feito usando o meca-

nismo Rewrite do Apache. E importante que o modulo de rewrite esteja ligado, usando-se o

comando:

a2enmod rewrite

Depois, basta inserir no arquivo /etc/apache2/default-server.conf as seguintes li-nhas:

<IfModule mod_rewrite.c>

RewriteEngine on

Rewritecond %{SERVER_PORT} ^80$

RewriteRule ^/ssologin/(.*) https://%{HTTP_HOST}/ssologin/$1 [NC,R,L]

</IfModule>

Page 40: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

40

Depois de configurar esses mecanismos no Apache, quando o usuario acessar a URL:

http://<endereco_servidor>/ssologin

ele sera automaticamente redirecionado para o protocolo HTTPS e, se clicar nas informacoes

do certificado, podera ver o certificado gerado nesta secao como ilustrado na Figura 11.

FIGURA 11: Informacoes do certificado no navegador de internet.

2.2.4.3 Consideracoes desta implementacao

Essa implementacao envolve uma riqueza de configuracoes, embora seja da maneira

mais simples possıveis. De maneira geral:

1. A interface de comunicacao do Squid fica mais interessante se for alterada para que

manipule o ID de usuario recebido do servidor SSO e, a partir de outros parametros re-

cebidos do Squid, seja capaz de retornar outros resultados. Uma alteracao interessante,

por exemplo, seria alterar esse script para que, a partir do ID de usuario e de um nome

de grupo recebido do Squid, seja capaz de fazer uma consulta LDAP ao servidor de di-

retorios para verificar se ha participacao deste usuario no grupo. Com isso, o controle de

Page 41: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

41

acesso seria mais centralizado, feito por grupos e nao por usuarios diretamente.

2. As configuracoes feitas no Apache foram esquematizadas para a distribuicao em questao,

o SuSE Linux Enterprise Server 10. Todavia, pode ser facilmente adapatada para ou-

tras distribuicoes, pois o Apache que roda naquela e a mesma que nestas. A principal

mudanca seria que todas as configuracoes feitas, sem excecoes, seriam realizadas di-

retamente em um arquivo chamado httpd.conf. E que no SuSE essa distribuicao de

arquivos e desenhada para organizar as configuracoes, todavia o Apache por padrao le

as configuracoes do arquivo httpd.conf, que esta em /etc/apache2/httpd.conf.

3. As configuracoes de seguranca por HTTPS garantem que as credenciais de logon do

usuario serao transmitidas usando criptografia assimetrica (RSA), portanto de maneira

segura.

2.3 RESULTADOS

A implementacao realizada apresentou bons resultados. O sistema SSO foi implemen-

tado de maneira bem sucedida, sendo que a aplicacao a infraestrutura de autenticacao da

Novell apresentou boas funcionalidades. Os resultados vieram como esperados.

Frente ao esquema de autenticacao proposto neste trabalho, temos duas instancias de

uso, descritas a seguir.

Com o uso de SSO

Isso acontece se houver uma infraestrutura de autenticacao presente e se houver um

cliente SSO implementado e sendo em clientes autenticados nessa infraestrutura. Em geral,

o fluxo de autenticacao e ilustrado no diagrama de sequencia da Figura 12.

Page 42: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

42

FIGURA 12: Diagrama de sequencia para acesso a internet com SSO.

Sem o uso de SSO

Isso acontece quando o usuario faz logon no servidor SSO pela interface web, sem fa-

zer logon em uma infraestrutura de autenticacao diretamente. Neste caso, o fluxo de autenticacao

e ilustrado na Figura 13.

FIGURA 13: Diagrama de sequencia para acesso a internet sem SSO.

Neste contexto, e importante ressaltar que nem sempre e necessario que haja o logon

do usuario no servidor SSO. Este logon tem um tempo de vida, isto e, enquanto ele for valido,

o servidor SSO retorna o ID do usuario sem que este precise se autenticar novamente.

Por fim, cabe aqui analisar os resultados do ponto de vista dos problemas analisados.

Os problemas eram:

1. Interacao do usuario para fornecimento de credenciais

A solucao proposta foi bem sucedida na resolucao deste problema. No caso com SSO,

Page 43: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

43

a interacao do usuario foi eliminada completamente, enquanto no caso sem SSO a

interacao foi minimizada ao maximo sendo que ha dependencia de interacao do usuario

apenas quando acessar a internet pela primeira vez e quando expirar o TTL de sua

autenticacao, definida pelo administrador na configuracao do servidor SSO (veja

Secao 2.2.4.1).

2. Envio de credenciais pelo protocolo HTTP

A solucao para esse problema tambem foi alcancada. No Apendice D, ilustramos captu-

ras feitas com o sniffer de rede Wireshark. E ilustrado o caso de autenticacao Basic do

Squid na Figura 14(a), em que as credenciais sao transmitidas sem nenhuma seguranca

por HTTP. Ja na Figura 14(b), e apresentado o caso de autenticacao depois do uso do

servidor SSO. Como o processo de autenticacao e troca de credenciais e toda feita entre

o servidor SSO e a autoridade de autenticacao (veja Figuras 12 e 13), no cliente nao

ha nenhuma transmissao de credenciais, a nao ser no momento da autenticacao pela

interface web, em que a transmissao e feita usando HTTPS.

Page 44: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

44

3 CONCLUSOES

A implementacao atendeu aos requisitos iniciais, resolvendo os dois principais proble-

mas que foram tratados na Secao 2.2.1: o usuario nao precisa mais digitar a senha sempre

que abrir o navegador – nao precisa digitar a senha nunca se estiver autenticado na Novell –

e nao e mais possıvel capturar o usuario e senha do usuario, ja que nao e mais necessario o

metodo de autenticacao basico dos navegadores. Neste contexto, a aplicacao resolveu os pro-

blemas propostos e ate alguns que nao foram previstos. Por exemplo, aplicacoes que acessam

a internet mas nao sao preparadas para pedir usuario e senha (como um software chamado

Conectividade Social, da Caixa Economica Federal5) sao capazes de acessar a internet sem

problemas, visto que o pedido de autenticacao era o problema, e isto nao e mais necessario.

O trade-off conhecido entre seguranca e usabilidade em sistemas de autenticacao

SSO, como exposto na Secao 2.1.3, foi realmente constatado neste projeto. Sua aplicacao

num sistema proxy-cache foi adequado, visto que e imprescidıvel autenticacao neste caso.

O uso de soquetes de rede, expostos na Secao 2.1.7, tambem foi adequado: possibilitou a

distribuicao do sistema, isto e, permite que cada uma de suas partes estejam em maquinas

fısicas diferentes.

5Para mais detalhes, veja http://downloads.caixa.gov.br/_arquivos/fgts/conectividade_social/

Manual_Configuracao_CSE.pdf

Page 45: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

45

Referencias

[1] De CLERCQ, J. “Single sign-on architectures”. In: DAVIDA, G.; FRANKEL, Y. & REES, O.Infrastructure Security, Lecture Notes in Computer Science. Springer Berlin / Heidel-berg, 2002. Vol. 2437, pp. 40-58.

[2] PASHALIDIS, A. & MITCHELL, C. “A taxonomy of single sign-on systems”. In: SAFAVI-NAINI, R. & SEBERRY, J. Information Security and Privacy, Lecture Notes in ComputerScience. Springer Berlin / Heidelberg, 2003. Vol. 2727, pp. 219-219.

[3] TODOROV, D. Mechanics of User Identification and Authorization: Fundamentals ofIdentity Management. Florida: Auerbach, 2007. 728 p.

[4] THE OPEN GROUP. Disponıvel em http://www.opengroup.org. Acesso em 18/11/2011.

[5] MACHADO, E.S. & MORI Jr., F.S. Autenticacao Integrada Baseada em Servico deDiretorio LDAP. 2006, 78 f. Trabalho de Conclusao de Curso – Ciencia da Computacao,Universidade de Sao Paulo, Sao Paulo, 2006.

[6] SHERESH, B. & SHERESH, D. Understanding Directory Services. 2. ed. Indianapolis:SAMS, 2002. 621 p.

[7] KUROSE, J.F & ROSS, K.W. Computer Networking: a top-down approach. 5. ed. NewYork: Addison-Wesley, 2010. 862 p.

[8] SAINI, K. Squid Proxy Server 3.1: Beginner’s Guide. Birmingham: Packt Publishing,2011. 308 p.

[9] SQUID ORG. Squid Documentation. Disponıvel em: http://www.squid-cache.org.Acesso em: 18/11/2011.

[10] WESSELS, D. Squid: the definitive guide. O’Reilly Media, 2004. 464 p.

[11] STEVENS, W. R.; FENNER, B.; RUDOFF, A.M. Programacao de rede UNIX: API parasoquetes de rede. 3. ed. Porto Alegre: Bookman, 2005. 901 p. ISBN 85-363-0470-7 (v. 1).

[12] DONAHOO, M.J.; CALVERT, K.L. TCP/IP Sockets in C: Pratical Guide for Programmers.2. ed. Burlington: Elsevier, 2009. 192 p.

[13] CALVERT, K.L.; DONAHOO, M.J. TCP/IP Sockets in Java: Pratical Guide for Program-mers. 2. ed. Burlington: Elsevier, 2008. 177 p.

Page 46: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

46

Apendices

Page 47: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

47

A Script Perl para comunicacao com o Squid

#!/usr/bin/perl

use IO::Socket::INET;

$SSOSERVER = ’192.168.56.1’;

$SSOPORT = 3025;

$| = 1;

while( <> ) {

$sock = new IO::Socket::INET->new( PeerAddr=>$SSOSERVER,

PeerPort=>$SSOPORT,

Proto=>’udp’ );

$sock->send( $_ );

$sock->recv( $resp, 1024 );

if( $resp eq "ERR" ) {

print "$resp\n";

}

else {

print "OK user=$resp\n";

}

close( $sock );

}

Page 48: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

48

B Arquivo de configuracao do Squid

hierarchy_stoplist cgi-bin ?

acl QUERY urlpath_regex cgi-bin \?

no_cache deny QUERY

external_acl_type SquidSSO ttl=0 %SRC /usr/sbin/squid_ip.pl

refresh_pattern ^ftp: 1440 20% 10080

refresh_pattern ^gopher: 1440 0% 1440

refresh_pattern . 0 20% 4320

acl all src 172.20.1.0/24

acl autenticado external SquidSSO

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255

acl to_localhost dst 127.0.0.0/8

acl SSL_ports port 443 563

acl Safe_ports port 80 # http

acl Safe_ports port 21 # ftp

acl Safe_ports port 443 563 # https, snews

acl Safe_ports port 70 # gopher

acl Safe_ports port 210 # wais

acl Safe_ports port 1025-65535 # unregistered ports

acl Safe_ports port 280 # http-mgmt

acl Safe_ports port 488 # gss-http

acl Safe_ports port 591 # filemaker

acl Safe_ports port 777 # multiling http

acl CONNECT method CONNECT

http_access allow manager localhost

http_access deny manager

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localhost

http_access allow autenticado all

deny_info ERR_TESTE all

http_access deny all

coredump_dir /var/cache/squid

Page 49: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

49

C Arquivo de configuracao vhost-ssl.conf

<IfDefine SSL>

<IfDefine !NOSSL>

<VirtualHost _default_:443>

SSLEngine on

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

SSLCertificateFile /etc/apache2/ssl.crt/server.crt

SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

<Files ~ "\.(cgi|shtml|phtml|php3?)$">

SSLOptions +StdEnvVars

</Files>

<Directory "/srv/www/cgi-bin">

SSLOptions +StdEnvVars

</Directory>

SetEnvIf User-Agent ".*MSIE.*" \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

CustomLog /var/log/apache2/ssl_request_log ssl_combined

</VirtualHost>

</IfDefine>

</IfDefine>

Page 50: Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf · deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente

50

D Capturas do Wireshark

(a) Captura do Wireshark para o caso de autenticacao Basic do Squid. Repare que as credenciais sao

transmitidas pelo protocolo HTTP, neste caso, de maneira insegura.

(b) Captura do Wireshark para o caso de autenticacao usando o servidor SSO. Nao ha transmissao de

credenciais, em nenhum dos casos, nem com ou sem o uso do cliente SSO.

FIGURA 14: Capturas do Wireshark.