PÓS GRADUAÇÃO EM SEGURANÇA DE REDES DE … · Aiming to aid IT managers, this paper shows the...
68
PÓS GRADUAÇÃO EM SEGURANÇA DE REDES DE COMPUTADORES Douglas Diego de Paiva Leonardo Medeiros Barbosa PROXY TRANSPARENTE COM AUTENTICAÇÃO GOIÂNIA 2009
Transcript of PÓS GRADUAÇÃO EM SEGURANÇA DE REDES DE … · Aiming to aid IT managers, this paper shows the...
PÓS GRADUAÇÃO EM SEGURANÇA DE REDES DE COMPUTADORES
Douglas Diego de Paiva Leonardo Medeiros Barbosa
PROXY TRANSPARENTE COM AUTENTICAÇÃO
GOIÂNIA 2009
PÓS GRADUAÇÃO EM SEGURANÇA DE REDES DE COMPUTADORES
Douglas Diego de Paiva Leonardo Medeiros Barbosa
PROXY TRANSPARENTE COM AUTENTICAÇÃO Monografia apresentada no curso de Pós Graduação em Segurança de Redes de Computadores da Faculdade de Tecnologia SENAI de Desenvolvimento Gerencial como requisito parcial para obtenção do grau de Especialista em Segurança de Redes de Computadores.
Linha de pesquisa: NatACL utilizando Squid em sistemas GNU/Linux
Professor Orientador: Prof. MSc. Rafael Leal Martins
GOIÂNIA 2009
Douglas Diego de Paiva
Leonardo Medeiros Barbosa
P167p Paiva, Douglas Diego de.
Proxy transparente com autenticação / Douglas Diego de Paiva, Leonardo Medeiros Barbosa. – Goiânia: SENAI/FATESG, 2009.
Trabalho de conclusão de curso (Pós Graduação em Segurança
de Redes de Computadores) – Faculdade de Tecnologia Senai de Desenvolvimento Gerencial.
Oritentador: Prof. Msc.Rafael Leal Martins. 1. Proxy. 2. Autenticação. 3. Squid. 4. NatACL (Software livre).
Título. II. Barbosa, Leonardo Medeiros.
CDD 005.18
Proxy Transparente com Autenticação
Trabalho de Conclusão de Curso, para obtenção do Título de Especialista em Segurança de Redes de Computadores, submetido à Faculdade de Tecnologia SENAI de Desenvolvimento Gerencial, Curso de Pós Graduação em Segurança de Redes de Computadores.
Aprovada em _____ de _____________________ de 200 ___.
Banca Examinadora
Prof. MSc. Rafael Leal Martins
(Orientador)
Prof° MSc. Ricardo de Andrade Kratz
(Membro)
Prof° MSc. Edio Cardoso de Paiva
(Membro)
AGRADECIMENTOS
Primeiramente agradecemos a Deus, por nos ter concedido forças para
chegar a esta etapa em nossas vidas, sabendo que esta fase é apenas o começo de
uma grande jornada tendo a certeza de que com Ele seremos mais que vencedores.
Agradecemos a todos aqueles, que de alguma forma, fizeram parte deste
estudo que consideramos uma das grandes etapas de nossas vidas. Etapa que
vencemos, mas que temos plena consciência de que apenas se inicia e que,
posteriormente, existirão outras.
Agradecemos ao nosso orientador Rafael Leal Martins, pela atenção e
carinho, pelas dicas e rumos da pesquisa, por conseguir nos ensinar que somos
capazes e, acima de tudo, pela paciência nessa fase tão curta, dura e cobrada.
Agradecemos a nossas famílias, pelo apoio e preocupação, em todos os
momentos que precisamos de vocês sempre estiveram ao nosso lado.
E, finalmente, agradecemos aos nossos professores e nossos coordenadores,
Professor Edio e Professor Joiran, que nos auxiliaram nessa parte de nossas vidas.
Obrigado pelos ensinamentos, paciência e dedicação de todos vocês.
LISTA DE ILUSTRAÇÕES
FIGURA 1 - Uma rede TCP/IP unindo-se a várias redes e tecnologias diferentes saindo para a internet através do Proxy .................................................................... 22
FIGURA 2 - Estrutura de rede da implementação do proxy transparente ................... 26
FIGURA 3 - Mensagem de erro apresentada após a instalação do Squid .................. 31
FIGURA 4 - Inicialização do Squid e criação da sua estrutura de diretórios ............... 33
FIGURA 5 - Bloqueio do acesso a site restritos pelo Squid ........................................... 35
FIGURA 6 - Log de acesso do Squid ................................................................................. 36
FIGURA 7 - Obtenção da lista de pacotes do auto-apt ................................................... 37
FIGURA 8 - Geração de lista dos pacotes instalados e geração da base de dados dos pacotes disponíveis ............................................................................................... 37
FIGURA 9 - Obtenção do MySQL ....................................................................................... 38
FIGURA 10 - Confirmação para a instalação de dependências no auto-apt ............... 40
FIGURA 11 - Processo final da compilação do NatACL ................................................. 40
FIGURA 12 - Geração do certificado digital ...................................................................... 41
FIGURA 13 - Alteração da senha de root do MySQL ...................................................... 41
FIGURA 14 - Certificado digital no Mozilla Firefox ........................................................... 45
FIGURA 15 - Confirmação de certificado no Mozilla Firefox .......................................... 45
FIGURA 16 - Certificado digital no Microsoft Internet Explorer ...................................... 46
FIGURA 17 - Tela de login do NatACL .............................................................................. 46
FIGURA 18 - Acesso negado no NatACL .......................................................................... 47
FIGURA 19 - Estrutura de rede da implementação do proxy transparente com autenticação no ambiente wireless ............................................................................. 49
FIGURA 20 - Desativando o recurso de DHCP no roteador wireless ........................... 51
FIGURA 21 - Configuração da rede sem fio do roteador wireless ................................ 51
FIGURA 22 - Instalação do DHCP ...................................................................................... 52
FIGURA 23 - Interface web do SARG ................................................................................ 56
FIGURA 24 - Relatório de acessos de um determinado usuário ................................... 57
FIGURA 25 - Tabela de usuários no phpMyAdmin .......................................................... 58
FIGURA 26 - Criação de usuário no phpMyAdmin .......................................................... 59
FIGURA 27 - Rede sem fio localizada ............................................................................... 60
FIGURA 28 - Endereço de IP fornecido pelo DHCP ........................................................ 60
FIGURA 29 - Usuários e senhas na base de dados ........................................................ 62
FIGURA 30 - Certificado Digital gerado ............................................................................. 63
LISTA DE ABREVIATURAS E SIGLAS
Siglas
BOOT
DHCP
DNS
IP
LAN
MAC
MAN
NAT
TCP
TCP/IP
TI
UDP
WAN
VOIP
Descrição
Partida no Computador (arranque)
Dynamic Host Configuration Protocol
Domain Name System
Internet Protocol
Local Area Network
Media Access Control
Metropolitan Area Network
Network Address Translation
Transmission Control Protocol
Transmission Control Protocol/ Internet Protocol
Tecnologia da Informação
User Datagram Protocol
Wide Area Network
Voz sobre IP
RESUMO
Com o objetivo de auxiliar aos administradores de Tecnologia da Informação
inserido nas empresas, este trabalho apresenta o uso da ferramenta de software
livre NatACL. A implementação desta ferramenta em conjunto com o serviço de
proxy provido pelo Squid é capaz de fornecer uma autenticação no acesso à internet
de forma transparente ao usuário, sem que seja necessário nenhum tipo de
configuração por sua parte. Este trabalho mostra os pacotes e as configurações
necessárias para implementar um ambiente transparente em autenticação de
usuários, além de testar esse ambiente para analisar sua viabilidade.
Palavras Chave: Proxy. Transparente. Autenticação. NatACL. Squid.
ABSTRACT
Aiming to aid IT managers, this paper shows the usage of the free software
tool NatACL. The implementation of this tool along with a Squid based proxy service
is capable to provide Internet access authentication in a transparent way to the user,
without need of any type of configuration from its part. This research explains the
software packages and configurations needed to implement a transparent users
authentication environment and test that environment to analise its viability.
Words Key: Proxy. Transparent. Authentication. NatACL. Squid.
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................................... 11
1.1 OBJETIVOS ....................................................................................................................... 12
1.1.1 OBJETIVO GERAL ........................................................................................................ 12
1.1.2 OBJETIVOS ESPECÍFICOS .......................................................................................... 13
1.2 JUSTIFICATIVA ............................................................................................................... 14
1.3 METODOLOGIA ............................................................................................................... 15
2 REVISÃO BIBLIOGRÁFICA .............................................................................................. 16
2.1 REDES E SISTEMAS CLIENTE-SERVIDOR ................................................................. 16
2.1.1 LAN, MAN E WAN ........................................................................................................ 16
2.1.2 PROTOCOLOS TCP/IP .................................................................................................. 17
2.2 SERVIDOR PROXY E SISTEMAS OPERACIONAIS ................................................... 19
2.3 SEGURANÇA (CONFIDENCIALIDADE, INTEGRIDADE E DISPONIBILIDADE) .. 21
2.4 PROXY TRANSPARENTE COM AUTENTICAÇÃO .................................................... 22
2.5 FERRAMENTAS LIVRES PARA AUTENTICAÇÃO COM PROXY TRANSPARENTE .................................................................................................................................................. 22
3 IMPLEMENTAÇÃO ............................................................................................................ 26
3.1 TECNOLOGIAS UTILIZADAS ....................................................................................... 26
3.2 CONFIGURAÇÕES INICIAIS .......................................................................................... 27
3.3 INSTALAÇÃO E CONFIGURAÇÃO DO SERVIÇO DE PROXY ................................. 30
3.4 PROXY TRANSPARENTE NO SQUID .......................................................................... 33
3.5 DEPENDÊNCIAS PARA A INSTALAÇÃO DO NATACL ............................................ 36
3.6 INSTALAÇÃO DO NATACL ........................................................................................... 39
3.7 CONFIGURAÇÃO DO NATACL .................................................................................... 42
3.8 AUTENTICAÇÃO EM PROXY TRANSPARENTE COM O NATACL ........................ 44
4 TESTES REALIZADOS ....................................................................................................... 48
4.1 PROXY TRANSPARENTE EM UM AMBIENTE WIRELESS ....................................... 48
4.2 TESTES DE SEGURANÇA .............................................................................................. 61
5 CONCLUSÃO ....................................................................................................................... 64
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................................... 66
11
1 INTRODUÇÃO
Este capítulo apresenta o objeto de estudo, o problema a ser estudado, a
justificativa, os objetivos e a estrutura da monografia.
Com a autenticação teremos uma segurança maior nas informações e a
transparência reduz o tempo de configuração, estas tecnologias juntas acabarão
com tráfego lento das redes e agilizará as transações na rede, diminuindo o tempo
de configuração em clientes e dando flexibilidade na autenticação da rede, e como é
uma plataforma baseada no software livre não haverá custos com licenciamento de
softwares e máquinas podendo ser colocado em quantos lugares e ter quantos
acessos for preciso.
O custo hoje é uma peça fundamental na vida estratégica de uma empresa, e
foi assim que fundamentamos nosso trabalho em ferramentas eficazes e de custo
zero em softwares, podendo ter uma economia e uma implementação viável ao
bolso de pequenas e médias empresas, pois utilizando sistemas operacionais
comerciais seria preciso além de da licença de uso do sistema a compra de um
programa para a finalidade de sustentar um serviço de proxy com transparência e
como vemos no mercado estes softwares além de pagos necessitam de aquisição
de licenças de acessos por quantidade de usuários.
12
1.1 OBJETIVOS
1.1.1 OBJETIVO GERAL
Apresentar vantagens e desvantagens da tecnologia de proxy transparente
com autenticação utilizando ferramentas livres, fundamentada em aspectos de
segurança, rapidez, customização e serviços que rodam via browser, utilizando
como plataforma o Linux Debian Etch 4.0 release 8 e os pacotes do projeto NatACL
20050305 com Squid 2.6. Implementar um sistema de autenticação segura de
usuários e transparente ao usuário, sem a necessidade de nenhuma configuração
por parte do cliente, somente o fornecimento de um usuário e senha previamente
cadastrado, para efetuar a sua autenticação, realizando assim a sua liberação à
internet.
13
1.1.2 OBJETIVOS ESPECÍFICOS
• Exibir as configurações do proxy transparente com autenticação utilizando
ferramentas livres no Linux;
• Descrever vantagens e desvantagens de se usar este Sistema Operacional
como plataforma;
• Considerações sobre o melhor uso da tecnologia na rede;
• Apresentar a tecnologia proxy transparente com autenticação baseada em
softwares livres utilizando o Linux Debian Etch 4.0 release 8;
• Mostrar o comportamento da solução e sua navegação na internet e intranet
utilizando esta tecnologia;
• Criar um experimento de cliente/servidor em um cenário de testes;
• Efetuar a instalação da aplicação Squid, para prover o serviço de proxy aos
seus clientes;
• Efetuar a instalação da aplicação NatACL 20050305, para prover a
autenticação transparente para o serviço de proxy;
• Efetuar a configuração da aplicação Squid, para o funcionamento correto do
serviço de proxy transparente;
• Efetuar a configuração no sistema de filtro de pacotes Iptables, para o
funcionamento correto do proxy e do sistema de autenticação;
• Efetuar a configuração da aplicação NatACL, para o implementar
autenticação no serviço de proxy transparente.
14
1.2 JUSTIFICATIVA
Atualmente, os sistemas computacionais estão cada vez mais aliados à
Internet, tornando os usuários cada vez mais dependentes deste recurso, tanto no
trabalho como em casa. Por isso, muitas pessoas, em alguns casos, abusam e
fazem mal uso deste recurso no ambiente de trabalho.
Ao falar em conceder acesso à Internet para colaboradores em uma empresa,
a primeira preocupação é com relação aos abusos cometidos, obrigando a empresa
a tomar algumas medidas para o controle de acesso.
Ao invés da utilização da Internet como instrumento de trabalho, ou para
obtenção de informações necessárias à execução de tarefas, pode acontecer que a
rede e até a internet seja usada para navegar por sites com conteúdos impróprios,
para a obtenção e instalação de programas piratas, além de músicas, fotos e outros
tipos de entretenimento. Podendo, ou não serem utilizados no ambiente de trabalho,
além da possibilidade de obtenção de arquivos maliciosos para a rede
comprometendo a sua segurança mesmo que de forma não intencional, abrindo
brechas e vulnerabilidades na rede interna de uma corporação.
Uma situação como esta, coloca em risco os sistemas e as informações da
empresa, além de interferir em serviços essenciais rodando na rede como, por
exemplo, e-mail e acesso a banco de dados, e também outros serviços que
precisam de qualidade no serviço de rede, como o VOIP, pois aumenta a
possibilidade de um estouro no consumo de banda pela navegação, além de perdas
financeiras e desperdício de tempo de trabalho do funcionário.
Torna-se necessário o controle de alguma forma do acesso concedido aos
usuários à Internet, e este trabalho busca alternativas para implementação deste
controle utilizando ferramentas livres e gratuitas, via autenticação de usuários,
concedendo somente a usuários autenticados o acesso à Internet.
Além da autenticação que é primordial para a segurança de uma empresa
utilizaremos a transparência de proxy para que haja a facilidade na configuração do
cliente.
15
1.3 METODOLOGIA
Esse estudo mostra uma visão da utilização de proxy transparente com
autenticação em sistemas operacionais livres utilizando ferramentas livres para os
administradores da área de TI (redes e segurança) através da realização de um
estudo de caso, metodologia experimental, levantamento bibliográfico e
documentações, mostrando novas tecnologias.
A princípio utilizou-se uma pesquisa teórica, visando conhecer novos meios
de interligação e comunicação de dados. Usando métodos de observação e
questionamento destas novas tecnologias de rede e softwares de gerenciamento.
Com o objetivo de conhecer esses novos modelos de implementação e
gerenciamento de rede, saber suas caracteristicas e como proporcionam essa
melhoria no desempenho da rede e na facilidade de administração.
Essa metodologia surge por intermédio de questões problemáticas no que
tange aos sistemas legados que se baseia em segurança, administração de banda,
autenticação de usuários e tráfegos da rede com gargalos constantes.
16
2 REVISÃO BIBLIOGRÁFICA
2.1 REDES E SISTEMAS CLIENTE-SERVIDOR
A medida que os computadores têm se tornado mais rápidos, mais poderosos
e mais baratos, os projetistas tem se afastado da arquitetura de sistemas
centralizados. [1]
As funcionalidades de interface com o usuário que costumavam ser
manejadas diretamente como a marcação de proxy, determinação de IP entre outras
funcionalidades estão, cada vez mais, sendo manejadas por computadores.
Uma rede de computadores é formada por um conjunto de módulos
processadores (MP’s – qualquer dispositivo capaz de se comunicar através do
sistema de comunicação por troca de mensagens) capazes de trocar informações e
compartilhar recursos, interligados por um sistema de comunicação. [2]
2.1.1 LAN, PAN, CAN, SAN, RAN, MAN E WAN
As redes de computadores podem ser divididas em vários tipos diferentes de
acordo com seu tamanho: as Redes Locais - Local Área Network (LAN) – são redes
privadas contidas em um único edifício ou campus universitário com até alguns
quilômetros de extensão. Possuem um tamanho restrito e possibilita o
compartilhamento de recursos, suas características mais marcantes são o tamanho,
a tecnologia de transmissão; as Redes Metropolitanas - Metropolitan Área Network
(MAN) – pode-se abranger ao tamanho de uma cidade, capaz de transportar dados
e voz, utilizam o padrão 802.6 (padrão do IEEE) ou dois barramentos de cabos; e as
Redes Geograficamente Distribuídas - Wide Área Network (WAN) - abrangem uma
ampla área geográfica, países ou continentes. Consiste em dois componentes: as
linhas de transmissão e o elemento de comutação. [3]
17
As Redes de Área Pessoal sem Fios – Personal Area Network (PAN)
permitem um intercâmbio de comunicação e informação entre computadores, PDAs,
impressoras, telefones móveis e outros dispositivos numa área de alcance limitada,
geralmente apenas alguns metros. As tecnologias PAN utilizadas mais utilizadas são
ligações de infravermelho e módulo Bluetooth de rádio freqüência.
As redes de campus - Campus Area Network (CAN) são redes que usam
ligações entre computadores localizados em áreas de edifícios ou prédios diferentes,
como em campus universitários ou complexos industriais.Deve também
sar links (ligações) típicos de LANs (Local Area Networks) ou perde-se seu caráter
de CAN para tornar-se uma MAN ou WAN, dependendo de quem seja o dono
do link usado.
Redes com área regional - Regional área network (RAN), são redes de dados
que interconectam negócios, residências e governos em uma região geográfica
específica. RANs são maiores que local area networks (LANs) e metropolitan area
networks (MANs), mas menores que wide area networks (WANs). RANs são
comumente caracterizadas pelas conexões de alta velocidade utilizando cabo
de fibra óptica ou outra mídia digital. Temos também Storage Area Network (área de armazenamento em rede) ou
SAN é uma rede projetada para agrupar dispositivos de armazenamento de
computador. Os SANs são mais comuns nos armazenamentos de grande porte [20]. As redes locais e metropolitanas (LAN e MAN) levam as considerações de
custo e tecnologia bastante diferentes das redes de longa distância. Nas redes
locais e metropolitanas podem ser usados meios de transmissão de alta velocidade,
de baixa taxa de erro, de baixo custo e privados. [2]
2.1.2 PROTOCOLOS TCP/IP
O nome TCP/IP se deve a dois dos principais protocolos da família: o
Transmission Control Protocol (TCP) e o Internet Protocol (IP).
A família de protocolos TCP/IP é organizada em quatro camadas: interface
com a rede, internet, transporte e aplicação.[3]
18
O TCP (Transmission Control Protocol / Protocolo de Controle de
Transmissão) faz a coleta de dados e seu particionamento de pacotes. Cada pacote
recebe caracteres de controle de erros do tipo soma de verificação (checksum).[3]
O IP (Internet Protocol / Protocolo Internet) ou endereço IP, de forma genérica,
pode ser considerado como um conjunto de números que representa o local de um
determinado equipamento (normalmente computadores) em uma rede privada ou
pública.[3]
Para um melhor uso dos endereços de equipamentos em rede pelas pessoas,
utiliza-se a forma de endereços de domínio, tal como "www.faculdade.edu.br". Cada
endereço de domínio é convertido em um endereço IP pelo DNS (Domain Name
System - serviço responsável pela conversão de domínio para IP e IP para domínio).
Este processo de conversão é conhecido como resolução de nomes de domínio.
O endereço IP, na versão 4 (IPv4), é um número de 32 bits escrito com quatro
octetos e no formato decimal (exemplo: 192.168.0.1). A primeira parte do endereço
identifica uma rede específica na inter-rede, a segunda parte identifica um host
dentro dessa rede. Devemos notar que um endereço IP não identifica uma máquina
individual, mas uma conexão à inter-rede. Assim, um gateway conectando à n redes
tem 'n' endereços IP diferentes, um para cada conexão.
Os endereços IP podem ser usados tanto para nos referirmos a redes quanto
a um host individual. Por convenção, um endereço de rede tem o campo
identificador de host com todos os bits iguais a 0 (zero). Podemos também nos
referir a todos os hosts de uma rede através de um endereço por difusão, quando,
por convenção, o campo identificador de host deve ter todos os bits iguais a 1 (um).
Um endereço com todos os 32 bits iguais a 1 é considerado um endereço por
difusão para a rede do host origem do datagrama. O endereço 127.0.0.1 é reservado
para teste (loopback) e comunicação entre processos da mesma máquina. O IP
utiliza três classes diferentes de endereços. A definição de classes de endereços
deve-se ao fato do tamanho das redes que compõem a inter-rede variar muito, indo
desde redes locais de computadores de pequeno porte, até redes públicas
interligando milhares de hosts.
Existe outra versão do IP, a versão 6 (IPv6) que utiliza um número de 128
bits. Com isso dá para utilizar 25616 endereços.
19
O endereço de uma rede (não confundir com endereço IP) designa uma rede,
e deve ser composto pelo seu endereço (cujo último octeto tem o valor zero) e
respectiva máscara de rede (netmask). [4]
2.2 SERVIDOR PROXY
Servidor proxy é um serviço de rede que atende requisições web em nome de
um servidor na Internet, é também conhecido como cache web. O cache web
armazena dentro dele cópias de objetos requisitados anteriormente. O browser de
um usuário ao fazer a requisição HTTP é dirigida primeiramente ao servidor proxy,
uma vez que configurado, cada uma das requisições de um objeto que o browser
estabelece uma conexão TCP com o proxy e envia a ele uma requisição, o proxy
verifica se tem uma cópia do objeto armazenada localmente, se houver envia o
objeto ao browser cliente dentro de uma mensagem de resposta HTTP, se não
houver o objeto, o proxy abre uma conexão TCP com o servidor de origem, isto é,
com o site e então envia uma requisição HTTP do objeto para a conexão TCP, após
receber esta requisição o servidor de origem envia ao servidor proxy guarda uma
cópia do objeto localmente e responde ao cliente com o objeto. Desta forma o
servidor proxy é tanto cliente como servidor pois solicita a resposta de outro servidor
para reencaminhar para o cliente.
O proxy tem sido utilizado amplamente por duas razões, a primeira é que com
ele o tempo de resposta é reduzido substancialmente, e em segundo com ele é
reduzido gargalos de rede, que com isso terá uma redução de custos com largura de
banda de internet. [5]
O proxy serve como compartilhador de conexão entre vários micros, servindo
como um intermediário entre eles e a internet. Usar um proxy é diferente de
simplesmente compartilhar a conexão diretamente, via NAT sendo a sigla de net
work addres translation, que transfere e encaminha os pacotes vindos de outra rede
para o destinatário interno.
Ao usar um proxy, além da configuração da rede, é necessário configurar o
navegador e cada outro programa que acesse a internet para utilizar o proxy, está é
20
uma tarefa tediosa e que acaba sendo árdua com o tempo, pois toda a vez que uma
máquina for adicionada na rede ou for preciso reinstalar o sistema, será preciso
fazer a configuração novamente. Ao usar um proxy transparente, você tem
basicamente uma conexão compartilhada via NAT, com a mesma configuração
básica nos clientes. Uma regra de firewall envia as requisições recebidas na porta 80
do servidor para o proxy, que se encarrega de responder aos clientes. Toda a
navegação passa a ser feita automaticamente através do proxy sem que você
precise fazer nenhuma configuração adicional nos clientes.
Entre as vantagens de se utilizar proxy estão a possibilidade de impor
restrições de acesso com base no horário, login, endereço IP da máquina e outras
informações, e bloquear páginas com conteúdo indesejado. Outra vantagem de usar
um proxy é que ele guarda logs de todos os acessos, ou seja, pode-se visualizar os
acessos posteriormente usando um gerador de relatórios por log, assim sabe-se
quem acessou quais páginas e em que horários, e também uma camada extra de
segurança exigindo autenticação no proxy, este recurso pode ser usado para
controlar quem tem acesso à internet e auditar os acessos em caso de necessidade.
[6]
É proposto que cada arquitetura de rede tem características próprias, e que
podem não corresponder a certas aplicações em particular, certas comparações não
podem ser feitas, pois seus atributos são muitos e complexos. Esses atributos são:
Custo: dividido em custos das estações, das interfaces, do meio de
comunicação e das conexões;
Retardo de Transferência: tempo decorrido desde o envio de uma mensagem
até sua chegada;
Desempenho: ligado diretamente ao custo e o retardo de transferência,
citados a cima;
Confiabilidade: ligada diretamente a qualquer falha que acontecer no sistema;
Modularidade: que traz bons benefícios à arquitetura de rede, como facilidade
de modificação, crescimento e uso de componentes básicos, dentre outros. [2]
Porém, propõe-se também que a segurança no acesso ao linux é muito forte
ou seja o serviço proxy em Linux é mais seguro, pois se dá por meio de uma
atribuição chamada máscara de proteção que é especifica ao modo de acesso,
leitura escrita ou execução.[1]
21
2.3 SEGURANÇA (CONFIDENCIALIDADE, PRIVACIDADE, INTEGRIDADE E
DISPONIBILIDADE)
A segurança do sistema é o mesmo que tentar minimizar as vulnerabilidades
existentes dos bens e recursos, ou seja, qualquer fraqueza que possibilite a violação
do sistema ou das informações existentes nele. Essa proteção é definida é termos
como: ameaças, riscos e políticas de proteção de segurança. [2]
A segurança teve focos diferentes depois do aparecimento de novas
tecnologias como a Internet e os sistemas de gestão empresarial ou Enterprise
Resouce Planning (ERP). A Internet proporcionou várias vantagens a nível de
conectividade, aumentando a quantidade de informações e também seu valor e
perigo de perdê-las. Um dos grandes problemas de segurança são as falhas
encontradas nos sistemas e aplicativos.
A segurança tem quatro aspectos considerados centrais:
Confidencialidade: ou capacidade de impedir a entrada de usuário não
autorizado;
Integridade: capacidade de o sistema impedir que uma informação seja
alterada sem autorização;
Disponibilidade: garantia de que o sistema estará sempre disponível.
Privacidade: dados pessoais não podem ser revelados. [21]
O risco que as aplicações, servidores e arquivos estão correndo é constate,
pois os famosos hackers ou piratas da internet estão sempre à procura de alguma
brecha ou porta aberta para eles possam entrar e fazer o que quiser com seus
sistemas.
Para proteger os sistemas, os administradores se preocupam com áreas pré-
definidas, buscando proteger, fechando portas e limitando acessos através de
senhas criptografadas.
A administração é dividida em tarefas a serem feitas em três áreas: a
primeira é a segurança do servidor, limitando o acesso a somente usuários
autorizados; segundo, a segurança do documento que devem estar visíveis somente
a um número mínimo de pessoas ou a um pequeno grupo; terceiro, a segurança do
22
usuário, este dever ter a certeza que quando fizer qualquer transação ninguém será
capaz de ler esse conteúdo a não ser a pessoa do seu destino. [4]
2.4 PROXY TRANSPARENTE COM AUTENTICAÇÃO
Proxy transparente com autenticação possibilita que o administrador de redes
possa gerenciar de forma centralizada todo o acesso a internet da sua rede, rodando
todos os serviços e ferramentas em um servidor ou pequeno grupo de servidores
eliminando com isso todas as configurações feitas nas máquinas clientes. O sistema
trabalha iniciando a comunicação entre o cliente e o servidor proxy, que se comunica
com o Windows ou Linux (cliente). Na figura 1 uma rede TCP/IP unindo-se a várias
redes e tecnologias diferentes e saindo para a internet através do proxy
transparente.
FIGURA 1 - Uma rede TCP/IP unindo-se a várias redes e tecnologias diferentes saindo para a internet através do Proxy – Fonte: Próprios Autores
2.5 FERRAMENTAS LIVRES PARA AUTENTICAÇÃO COM PROXY
TRANSPARENTE
23
A idealização deste projeto surgiu ao se deparar com a difícil decisão de
escolher a transparência ou a autenticação de usuários ao se trabalhar com o proxy
provido pelo Squid, principal ferramenta livre e gratuita para tal função. Desde o
começo, decidiu-se trabalhar com ferramentas que não tivessem nenhum custo para
a sua implantação, portanto ao ter que controlar o acesso de usuários à Internet
utilizando um proxy, este seria provido pelo Squid.
Na difícil decisão de se trabalhar com transparência ou com autenticação no
serviço de proxy, já que não é possível trabalhar com os dois apenas utilizando o
Squid, foi descoberto que era possível, através da implementação de uma
ferramenta adicional, que trabalharia em conjunto com o Squid, oferecer
autenticação de usuários em um cenário de proxy transparente. Dessa forma,
grande parte do tempo do projeto foi destinado a buscar uma solução adequada
para a implantação desse sistema de autenticação, já que para implementação de
um proxy transparente existia conhecimento suficiente para realizá-la.
Através das pesquisas realizadas, foram descobertas duas ferramentas que
poderiam ser usadas para em conjunto com o Squid, prover a autenticação em um
proxy transparente: o NatACL e o NoCatAuth.
O primeiro foi criado por Fabio Yasusi Yamamoto, era chamado inicialmente
de ProxyAuth, até ser renomeado para NatACL. Segundo seus próprios
desenvolvedores, ele é um daemon (serviço que roda em segundo plano) de
autenticação para NAT e proxy transparente, que “escuta” todas as solicitações
HTTP e força, através de uma tela de login, que usuários se autentiquem para
ganhar este acesso. [7]
O NatACL possui ainda um controle completo de NAT, podendo ser usado
como um controlador de políticas de grupos em firewall, permitindo a criação de
regras (ACLs) de NAT para os computadores pertencentes a rede que ele trabalha.
O NatACL pode ainda a partir de um servidor DHCP interno, força os usuários a
utilizá-lo, podendo bloquear endereços IPs estáticos por exemplo, aumentando seu
controle da rede.
Outra funcionalidade do NatACL é prover o serviço de autenticação em um
proxy transparente, a partir da interceptação de pacotes, feita com a ajuda do filtro
de pacotes Iptables (firewall para Linux). As requisições HTTP feitas pelos clientes
para sites externos (Internet) serão redirecionadas para o NatACL, que solicitará
24
uma credencial de acesso a partir de uma tela de login, e caso a credencial
fornecida esteja correta, o acesso à Internet será permitido. Funcionalidade buscada
para a implementação da autenticação em um proxy transparente.
A segunda ferramenta foi desenvolvida por Schuyler Erle e Robert Flickenger,
sua criação iniciou a partir de uma comunidade de suporte de rede sem fio e passou
a ser um projeto com o objetivo de incentivar a construção de rede comunitárias sem
fio. [8]
A principal funcionalidade do NoCatAuth é de capturar o tráfico da porta 80 e
desviá-lo para um servidor HTTP seguro, provido pela própria ferramenta, onde será
exibida uma página de login, assim como no NatACL.
O NoCatAuth trabalha com duas instâncias: o NaCatAuth Auth e o NocatAuth
Gateway, o módulo Gateway é responsável por receber o tráfego HTTP para a porta
80 e redirecionar para um outra porta (5280), o módulo Auth é responsável por
apresentar a tela de login e garantir que o acesso só será liberado aos usuários
autenticados. [9]
Portanto, ambas as ferramentas possuem funcionalidades muito similares, a
forma de prover a autenticação de usuários em um proxy transparente é a mesma, a
partir de uma página de login, autenticar o usuário que deseja acessar uma página
na Internet. Outras similaridades entre as ferramentas é o fato de usarem uma base
de dados MySQL para armazenarem os usuários com credenciais para
autenticação, e oferecerem uma interface segura para a autenticação de usuários,
através de protocolo HTTPS.
Ao buscar materiais de documentação e implementação das duas
ferramentas, para descobrir qual a solução mais viável para o projeto. Deparou-se
com a falta de documentação para ambas as ferramentas, inclusive a carência de
uma documentação oficial.
Os principais fatos que determinaram para a escolha do NatACL foram de que
esta ferramenta oferece recursos de controle de acesso relacionados a criação de
regras de NAT, que a princípio não é objetivo do projeto, mas que poderia ser usado
para aprimorar o serviço, recurso não oferecido pela ferramenta NoCatAuth. Outro
fator foi relacionado aos pacotes disponíveis para a implementação das ferramentas,
o NatACL teve seu último pacote estável disponibilizado em 11 de março de 2005(1)
– versão 20050311, enquanto o NoCatAuth, foi disponibilizado em 17 de maio de
25
2003(2) a versão 0.82. Portanto, foi priorizado uma versão mais recente, sabendo
ainda que o NatACL possui uma versão de testes ainda em desenvolvimento(3).
Durante o levantamento de material para a escolha da ferramenta a ser
implementada, foi encontrado um projeto final implementando NoCatAuth para
prover autenticação de usuários em proxy transparente, e não foi encontrado nada
relacionado ao NatACL, portanto a partir do projeto seria construído um material que
poderá ser usado como referência para a utilização da ferramenta.
___________________________________________________________________
(1) http://www.hostname.org/proxy_auth/download/
(2) http://nocat.net/downloads/NoCatAuth/
(3) http://sourceforge.net/projects/natacl/files/natacl/Beta%2015/NatACL.3.0.Beta15.tgz/download
26
3 IMPLEMENTAÇÃO
3.1 TECNOLOGIAS UTILIZADAS
Neste capítulo será apresentada uma estrutura básica para o funcionamento
de um proxy transparente com autenticação. Os equipamentos utilizados para a
implementação dos serviços foram:
• 01 Modem ADSL Siemens Speedstream 4200
• 01 Switch 8 Portas 3COM 100Mpbs
• 01 Computador com a seguinte especificação:
• Processador: Core 2 Quad Q6600 2.40 Ghz
• Memória RAM: 4 GB
• HD: 160 GB
• 01 Placa de rede onboard Realtek RTL8168C (eth0)
• 01 Placa de rede offboard Realtek RTL813 (eth1)
A estrutura física de rede para o funcionamento correto do proxy transparente
autenticado foi provida na forma apresentada pela Figura 02.
FIGURA 2 - Estrutura de rede da implementação do proxy transparente –Fonte: Próprios Autores
O computador será o servidor proxy, nele serão implementados o serviço de
proxy transparente, provido pelo Squid, e também o serviço de autenticação, provido
pelo NatACL. Este servidor receberá o acesso a internet provido pelo modem ADSL
27
ligado a uma de suas interfaces de rede, já a outra interface será ligada ao switch,
onde serão conectados computadores clientes que farão uso do serviço provido.
Este computador também irá trabalhar como um servidor de gateway, pois interligará
o acesso à internet provido pelo modem, e a rede interna ligada ao switch,
realizando o trabalho de transferência de dados entre o mundo externo (Internet) e a
rede interna.
Por exigirem um baixo uso de recursos de máquina, os serviços providos pelo
Squid e NatACL podem trabalhar juntos em um mesmo servidor, e serão assim
implementados.
O ambiente de implantação destes serviços foi realizado através do uso de
sistemas e serviços de código aberto, obtidos e distribuídos gratuitamente pela
internet. O servidor em que os serviços serão implementados roda sistema
operacional Linux, foi utilizada a distribuição Debian Etch 4.0 R8 e kernel 2.6.18-6-
686 [17], obtida gratuitamente através do endereço: http://cdimage.debian.org
/cdimage/archive/4.0_r8/i386/iso-cd/. A escolha desta distribuição se deu pela
grande quantidade de documentação encontrada na Internet e pelo seu gerenciador
de pacotes que facilita muito a implementação de serviços na mesma.
3.2 CONFIGURAÇÕES INICIAIS
Antes de se iniciar a instalação dos serviços previstos para prover o proxy
transparente com autenticação, se fizeram necessárias algumas configurações
iniciais, tais como a inclusão de repositórios para a obtenção dos pacotes
necessários para a instalação dos serviços, como também fixar os endereços de IP
nas interfaces para que estes endereços não se alterem ao longo da implementação
e a comprometam.
Portanto o primeiro passo realizado foi a inclusão dos repositórios. Um
repositório é um local de armazenamento, geralmente mantidos pelos
desenvolvedores dos softwares que o utilizam, ou por comunidades e terceiros, com
o intuito de prover pacotes, aplicações e serviços. Em sua grande maioria estão
acessíveis online (através da internet). Neste caso, os repositórios serão
28
importantes, pois o sistema operacional escolhido para trabalharmos fornece um
gerenciador de pacotes, conhecido como APT (Advanced Packaging Tool) ou
Ferramenta de Empacotamento Avançada. Este gerenciador de pacote fornece uma
interface simples de linha de comando (pode possuir também interfaces gráficas), no
qual é possível baixar e instalar pacotes de maneira simples, através do comando
“apt-get”. [10]
Para tanto, a busca dos pacotes é feita através dos repositórios existentes na
distribuição. Por padrão, no Debian nenhum repositório online está habilitado. Foi
feita então a inclusão de dois repositórios oficiais do Debian, um localizado na
Holanda e outro no Brasil. Para a inclusão dos repositórios na distribuição Debian é
necessária a edição do arquivo sources.list localizado dentro do diretório /etc/apt
através do seguinte comando:
# vi /etc/apt.sources
No final do arquivo foram adicionadas duas linhas contendo os repositórios:
deb http://ftp.debian.org/debian/ etch main contrib non-free
deb http://ftp.br.debian.org/debian etch main contrib non-free
Adicionados os repositórios, deve ser usado o comando abaixo para que seja
obtida a lista dos pacotes presentes nos repositórios adicionados, para uma futura
obtenção e instalação destes:
# apt-get update
Conforme visto na figura 02, o modem ADSL está pré-configurado com o
endereço de IP 192.168.254.254, portanto pertencente a rede 192.168.254.0/24.
Este modem oferece um recurso de distribuição de endereços IP através de um
DHCP interno, e para evitar futuros problemas com a troca do endereço de IP do
servidor, foi fixado o endereço IP 192.168.254.3 pertencente a rede do modem na
interface de rede onboard (eth0) do servidor proxy.
Segundo o ambiente apresentado, os computadores clientes que serão
interligados ao switch e farão o acesso a internet através do proxy a ser
implementado posteriormente, farão o uso de uma faixa de endereços de rede
diferente do apresentado acima, dessa forma será criada uma rede interna para os
computadores clientes, cujo endereço de gateway será a segunda interface de rede
do servidor (eth1). Portanto será fixado o endereço de rede 192.168.0.2 na interface
offboard eth1.
29
Para fixar os endereços IP nas interfaces de rede conforme previsto acima é
necessário editar o arquivo /etc/networking/interfaces, passando as interfaces do
modo dinâmico (dhcp) para o estado estático (static). No primeiro modo as interfaces
farão uma requisição em broadcast através de um pacote UDP, solicitando um
endereço IP a um servidor DHCP, e através da resposta a requisição será
encaminhado um endereço IP a ser usado pela interface, o cliente recebe ainda na
resposta a máscara de rede a ser usada, o endereço do gateway e de servidores
DNS a serem usados, fornecendo assim um modo de configuração dinâmico aos
terminais. Já no segundo modo, a interface utilizará o endereço IP e demais
parâmetros (máscara, gateway, etc) definidos no arquivo de configuração, dessa
forma a configuração será feita de forma estática com os valores e configurações
pré-definidas.
Para editar o arquivo de configuração das interfaces de rede foi utilizado o
seguinte comando:
# vi /etc/networking/interfaces
No arquivo de configuração foram inseridas as seguintes informações para as
duas interfaces de rede (eth0 e eth1):
auto eth0
iface eth0 inet static
address 192.168.254.3
netmask 255.255.255.0
broadcast 192.168.254.255
auto eth1
iface eth1 inet static
address 192.168.0.2
netmask 255.255.255.0
broadcast 192.168.0.255
Definimos assim a interface eth0 com o endereço IP estático 192.168.254.3 e
a interface eth1 com o endereço IP estático 192.168.0.2. No qual a interface eth0
estará ligada ao modem e a interface eth1 ligada ao switch, conforme descrito
anteriormente.
30
3.3 INSTALAÇÃO E CONFIGURAÇÃO DO SERVIÇO DE PROXY
O Squid é um servidor proxy com suporte a protocolos como o HTTP, HTTPS,
FTP, dentre outros. Foi escrito originalmente por Duane Wessels para rodar em
sistemas operacionais Unix. É um software de código-aberto, muitiplataforma, sob a
licença GNU GPL [6].
O Squid surgiu como um servidor cache web, ainda uma das suas principais
funções, armazenando requisições freqüentes de páginas web e informações já
acessadas, dessa forma, quando for feita uma requisição de uma página ou arquivos
já acessados, o proxy envia os dados guardados no cache, reduzindo assim a
utilização da banda e melhorando os tempos de respostas destas requisições.
Mas esta não é a sua única função, o Squid também é largamente utilizado
para compartilhar o acesso de vários computadores à internet, atuando como um
intermediário entre os computadores de uma rede local e a Internet, assim as
requisições à internet serão feitas pelos computadores para o proxy, que então irá
efetuar os mesmos pedidos ao exterior (Internet), privando da necessidade de que
todos os computadores devem ter um endereço válido na Internet, permitindo que
mais de uma máquina se conecte a ela. [6]
A partir deste compartilhamento possibilitado pelo Squid, ele pode ainda
prover alguns serviços como a autenticação de usuários, a liberação ou bloqueio de
conteúdos e o registro (através de logs) de todos os acessos realizados,
possibilitados pela análise de todo o tráfego que é feita por ele. Funcionalidade estas
que serão exploradas nessa implementação.
O Squid é composto de um único pacote. Para efetuar seu download e
instalação foi utilizado o seguinte comando:
# apt-get install squid
Com a utilização do comando acima foi automaticamente baixado e instalado
a versão 2.6 do Squid, porém após sua instalação foi apresentada um mensagem de
erro, indicando que não foi possível iniciar o serviço do Squid utilizando o arquivo de
configuração padrão, pois não foi informado um nome válido no parâmetro
visible_hostname do arquivo de configuração do Squid, conforme pode ser visto na
figura 03, campo este obrigatório para se iniciar o Squid.
31
FIGURA 3 - Mensagem de erro apresentada após a instalação do Squid – Fonte: Próprios Autores
O arquivo de configuração do Squid é encontrado no seguinte caminho:
/etc/squid/squid.conf. Este arquivo contém todas as configurações do Squid, e o
arquivo original que acompanha o pacote do serviço é muito extenso, repleto de
comentários e exemplos para praticamente todas as finalidades que o Squid pode
ser usada. Como a intenção da implementação não é explorar todas as
funcionalidades dos serviços providos pelo Squid, e sim, apenas prover um proxy
transparente, todo o conteúdo do arquivo de configuração inicial foi removido e
substituído por algumas linhas contendo as principais funções necessárias nessa
implementação.
Portanto foi removido o arquivo inicial e criado um novo arquivo de
configuração através dos seguintes comandos:
# rm –rf /etc/squid/squid.conf
32
# vi /etc/squid/squid.conf
O conteúdo adicionado ao arquivo de configuração foi o seguinte [6]:
http_port 3128
cache_mem 64 MB
cache_dir ufs /var/spool/squid 100 16 256
access_log /var/log/squid/access.log squid
cache_log /var/log/squid/cache.log
cache_store_log /var/log/squid/store.log
acl all src 0.0.0.0/0.0.0.0
acl proibidos url_regex "/etc/squid/listaproibidos.txt"
http_access deny proibidos
http_access allow all
cache_mgr [email protected]
error_directory /usr/share/squid/errors/Portuguese
visible_hostname proxy
Colocou-se no arquivo de configuração a porta padrão onde o serviço vai
rodar (3128), a quantidade de memória RAM destinada a cache (64MB), o diretório,
quantidade de pastas e subpastas da cache, locais onde ficarão os logs do Squid,
regras mostrando o local do arquivo de bloqueio, regra liberando o acesso a todos
os outros conteúdos (na parte de regras a ordem das regras fazem diferença, as
primeiras regras são as de maior prioridade), e-mail que receberá os erros do proxy,
diretório de erro e o nome que será visível no proxy.
Após a edição do arquivo de configuração, foi criado o arquivo contendo a
lista de sites a serem bloqueados pelo proxy, o arquivo foi criado e editado através
do comando:
# vi /etc/squid/listaproibidos.txt
Na edição do arquivo foi adicionada a palavra playboy em seu conteúdo,
portanto como a acl denominada “proibidos” sendo negada através do parâmetro
“http_access deny proibidos”, toda vez que houver a tentativa de acesso a uma
página web que contenha em seu endereço uma das palavras existentes no arquivo
citado, esta página terá seu acesso negado. Dessa forma, poderemos assim testar a
funcionalidade do proxy em bloquear acessos.
Após a edição do arquivo de configuração do Squid e da criação do arquivo
contendo as palavras que devem ser bloqueadas, o serviço já pode ser iniciado
através do comando:
# /etc/init.d/squid start
33
Iniciado o serviço do Squid será criada a sua estrutura de diretórios conforme
pode ser visto na figura 04, incluindo diretórios para armazenar os arquivos de cache
e também a criação dos arquivos de log, no qual serão armazenados todos os
acessos realizados.
FIGURA 4 - Inicialização do Squid e criação da sua estrutura de diretórios – Fonte: Próprios Autores
3.4 PROXY TRANSPARENTE NO SQUID
Implementado o serviço de proxy do Squid, o próximo passo foi transformá-lo
em um proxy transparente, para esta modalidade de serviço, a forma mais simples é
transformar o servidor do proxy também no gateway da rede, e através da inserção
de regras do Iptables, direcionar todas requisições destinadas a porta 80 para o
proxy, dessa forma, ele irá escutar e tratar todas as conexões na porta 80, forçando
sua utilização, mesmo que os clientes não o tenham configurado em seus
navegadores e outros serviços, e também como este servidor será o gateway da
rede, todas as requisições terão que ser repassadas a eles, portanto o proxy será
utilizado sem a necessidade de configurar o proxy manualmente em cada estação.
[6]
O primeiro passo para transformá-lo em um proxy transparente é alterar o
arquivo de configuração do Squid, adicionando à linha “http_port 3128” no início do
arquivo a palavra transparent, ficando da seguinte forma:
http_port 3128 transparent
34
Assim o Squid já passa a entender as requisições redirecionadas pelas regras
de Iptables que serão adicionadas posteriormente, e já possa trabalhar de forma
transparente.
Editado o arquivo de configuração, o segundo passo é adicionar as seguintes
regras de Iptables:
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT
--to-port 3128
# iptables -t nat -A PREROUTING -i eth1 -p udp --dport 80 -j REDIRECT
--to-port 3128
Estas regras basicamente dizem que serão adicionadas (parâmetro “–A”) a
tabela NAT do iptables (parâmetro “–t nat”), em que as requisições recebidas pela
interface eth1 (parâmetro “-i eth1”), utilizando protocolo TCP ou UDP (parâmetro “-p
tcp” ou “-p udp”), destinados a porta 80 (parâmetro “--dport 80”), serão
redirecionados (parâmetro “-j REDIRECT”) para a porta 3128 (parâmetro “--to-port
3128”), porta utilizada pelo serviço do Squid.
Portanto a adição do parâmetro transparent ao arquivo de configuração fará
com que o Squid passe a entender as requisições redirecionadas pelas regras, estas
que por sua vez farão o trabalho de redirecionar todas as requisições feita a porta 80
para a porta 3128, forçando a todas as estações a trabalharem com o proxy.
Por fim, como o servidor proxy irá trabalhar como o gateway da rede é
imprescindível que seja ativado o reencaminhamento de pacotes através dele. Este
reencaminhamento é provido pelo serviço IP Forwarding, e para ser ativado, basta
alterar seu conteúdo para o valor “1”, por padrão o serviço fica desabilitado e seu
conteúdo é “0”. Portanto basta utilizar o seguinte comando para ativá-lo:
# echo 1 > /proc/sys/net/ipv4/ip_forward
Implementado o serviço de proxy transparente e ajustado o servidor para
trabalhar como um gateway na rede, foram realizados testes para verificar a
eficiência dos serviços implantados até o momento.
Para tanto foi adicionado um computador cliente a rede, ligando-o diretamente
ao switch conforme a estrutura apresentada na figura 2. Neste computador foi
realizada a seguinte configuração de rede:
• Foi atribuído o endereço IP 192.168.0.254;
• Foi atribuída a máscara de rede 255.255.255.0;
• Foi atribuído o gateway padrão 192.168.0.2 (endereço IP do proxy);
35
• Foram atribuídos os endereços de DNS primário 208.67.222.222 e secundário
208.67.220.220;
Portanto o cliente foi adicionado à rede interna proposta na nossa estrutura
inicial, e o servidor proxy foi empregado como gateway para prover o
reencaminhamento e receber as requisições do cliente. Foram ainda adicionados
dois endereços de DNS válidos para a resolução de nomes.
No computador cliente foi feito o acesso ao site http://www.playboy.com.br
(figura 5). Por este endereço de site conter uma palavra negada na lista de bloqueio
criado no Squid, vista anteriormente, o acesso ao site foi negado conforme pode ser
visto na figura 5. Nesta figura é possível ainda verificar que o endereço de proxy não
foi configurado, portanto o modo transparente do Squid funcionou corretamente.
FIGURA 5 - Bloqueio do acesso a site restritos pelo Squid - Fonte: Próprios Autores
Foi possível acompanhar também a negação do acesso ao site através do log
de acesso do Squid, conforme pode ser visto na Figura 6, em que a informação
TCP_DENIED é exibida na tentativa de acesso ao site em questão.
Por padrão o arquivo /var/log/squid/access.log guarda os registros (logs) de
acesso do Squid, portanto para visualizar e acompanhar este log de acesso,
visualizando os acessos negados e autorizados, basta utilizar o comando:
36
# tail –f /var/log/squid/access.log
FIGURA 6 - Log de acesso do Squid - Fonte: Próprios Autores
3.5 DEPENDÊNCIAS PARA A INSTALAÇÃO DO NATACL
Antes da instalação do NatACL é preciso resolver e instalar algumas
dependências para a sua instalação. Todos os pacotes foram baixados e instalados
utilizando o gerenciador de pacote APT do Debian, o comando utilizado para a
obtenção dos pacotes via comando apt-get foi o seguinte:
# apt-get install gcc g++ libpcap-dev libssl-dev libmysql++-dev auto-
apt
Uma das dependências instaladas é o auto-apt, uma ferramenta que
possibilita a instalação de pacotes (dependências) durante a compilação de um
programa, portanto ao iniciar a instalação de um aplicativo a partir de seu fonte
(compilando), as dependências que surgirem e não forem encontradas no sistema
serão instaladas via o gerenciador de pacotes APT, interrompendo a compilação e
continuando após a instalação das dependências, facilitando muito as instalações
feitas a partir do fonte. [11]
Após a instalação do auto-apt é necessário atualizar sua base de dados, para
tanto será necessário a execução dos seguintes comandos:
# auto-apt update
# auto-apt update-local
# auto-apt updatedb
37
Dessa forma será obtida a lista de pacotes disponíveis nos repositórios
através do comando auto-apt update, conforme pode ser visto na Figura 07.
FIGURA 7 - Obtenção da lista de pacotes do auto-apt - Fonte: Próprios Autores
Em seguinda é gerada uma lista dos aplicativos instalados localmente a partir
do comando auto-apt update-local, e por fim gerada a base de dados dos pacotes
disponíveis através do comando auto-apt updatedb, como pode ser visto na figura
08.
FIGURA 8 - Geração de lista dos pacotes instalados e geração da base de dados dos pacotes disponíveis - Fonte: Próprios Autores
A utilização do auto-apt foi escolhida pelo fato do NatACL possuir um grande
quantidade de dependências, facilitando assim sua instalação. As dependências
instaladas antes do uso do auto-apt foram feitas sem seu uso, por se tratarem do
38
próprio pacote do auto-apt, de pacotes necessários para a compilação de programas
e também de pacotes que não foram instalados pelo auto-apt em uma pré-instalação
de teste.
Antes de proceder para a obtenção e instalação do NatACL é necessário
efetuar a instalação do servidor de banco de dados MySQL, já que o NatACL
gerencia os usuários através de um banco de dados MySQL. O MySQL foi obtido
através do uso do gerenciador de pacotes APT na sua versão 5.0, através do
comando:
# apt-get install mysql-server
Para a instalação do MySQL alguns pacotes são necessários, porém estes
pacotes já são automaticamente obtidos no uso do gerenciador de pacotes APT,
conforme pode ser visto na Figura 09.
FIGURA 9 - Obtenção do MySQL- Fonte: Próprios Autores
Finalizada a instalação do MySQL prosseguimos para a obtenção do NatACL
e sua compilação
.
39
3.6 INSTALAÇÃO DO NATACL
O pacote contendo o fonte para a instalação do NatACL foi obtido diretamente
no site do desenvolvedor [18], obtido através do uso do comando wget, a versão
baixada é a última versão estável produzida datada de 11 de março de 2005, depois
dessa versão outras foram apresentadas, porém todas em versão beta (versão de
testes), optamos por uma versão estável, mesmo que sua data de criação seja
relativamente antiga, os comandos utilizados para baixar o pacote contendo o fonte
e descompactá-lo foram: [12]
# wget
http://www.hostname.org/proxy_auth/download/NatACL.20050311.tar.gz
# tar –zxvf NatACL.20050311.tar.gz
# cd NatACL.20050311
Obtido e descompactado o pacote do NatACL, sua compilação foi feita
através da utilização da ferramenta auto-apt, apresentada anteriormente. Para
efetuar a compilação do NatACL foi utilizado o comando:
# auto-apt run make
Este comando tem a mesma função do comando make, utilizado para
compilar um programa a partir do seu fonte, porém com o uso do auto-apt, as
dependências que surgirem durante a compilação serão baixadas através do
gerenciador de pacotes APT, ou seja, no momento que a ferramenta se depara com
a falta de um pacote necessário para a compilação, esta é interrompida, o pacote é
baixado e instalado automaticamente, e depois a compilação continua com as suas
dependências resolvidas, conforme apresentado anteriormente.
No momento em que é encontrada uma dependência e o processo da
compilação é interrompido, no terminal é apresentado o pacote da dependência e
perguntando ao usuário se deseja instalar a dependência, conforme pode ser visto
na Figura 10, portanto durante a instalação é necessário confirmar a instalação das
dependências. Durante este processo de instalar as dependências, pode ser
apresentado algum erro relativo a compilação, caso uma dependência esteja sendo
baixado e a interrupção da compilação não ocorreu corretamente, fato presenciado
durante nossa implementação, caso ocorra, basta acionar novamente o comando
“auto-apt run make”, que a compilação ocorrerá normalmente [19].
40
FIGURA 10 - Confirmação para a instalação de dependências no auto-apt - Fonte: Próprios Autores
No processo de compilação do NatACL, alguns pacotes foram instalados
automaticamente por serem dependências que o próprio auto-apt resolveu e
instalou, foram elas:
• libglib1.2; libgtk1.2; libgtk1.2-common; libgtk-perl; pocketpc-binutils; pocketpc-
gas; pocketpc-sdk; pocketpc-gcc; libxml2-dev; perl-tk; libtie-array-sorted-perl;
openssl
Ao fim da compilação serão criados os diretórios do NatACL contendo os
módulos de autenticação e sua tela de login, conforme pode ser visto na Figura 11.
FIGURA 11 - Processo final da compilação do NatACL- Fonte: Próprios Autores
Se a compilação do NatACL ocorrer corretamente, o próximo passo é
responder algumas questões (Figura 12) para a criação do certificado digital a ser
usado para garantir a autenticidade do servidor, durante o processo de autenticação
dos usuários, já que a tela de login do NatACL utiliza o protocolo HTTPS.
41
FIGURA 12 - Geração do certificado digital - Fonte: Próprios Autores
Finalizada a instalação do NatACL e a geração do seu certificado, é
necessário criar a base de dados do NatACL no MySQL, para armazenar os
usuários a serem autenticados.
Antes da criação dessa base de dados foi feita a alteração da senha de root
do MySQL, através do comando:
# dpkg-reconfigure mysql-server-5.0
Após o comando será aberta uma interface solicitando a nova senha de root
do MySQL, conforme pode ser visto na figura 13, a senha informada foi root, essas
credenciais serão usadas posteriormente no arquivo de configuração do NatACL.
FIGURA 13 - Alteração da senha de root do MySQL- Fonte: Próprios Autores
42
Para a criação da base de dados do NatACL no MySQL, deve ser feita a
importação das tabelas através de um script denominado Mysql.DUMP, localizado
no diretório descompactado do pacote do NatACL. Portanto no diretório
descompactado do NatACL, foi efetuada a cópia do script Mysql.DUMP para o
diretório /var/lib/mysql, e a partir deste diretório foi realizada a importação das
tabelas do NatACL, os comandos utilizados para estas ações descritas foram: [12]
# cd /opt/NatACL/NatACL.20050311
# mv Mysql.DUMP /var/lib/mysql
# cd /var/lib/mysql
# mysql -u root -p < Mysql.DUMP
Feita a importação das tabelas do NatACL, efetuaremos a inserção de um
usuário para futuros testes de autenticação no proxy transparente, para tanto é
necessário acessar a base de dados do NatACL no MySQL e fazer a inserção
manual de um novo usuário, os passos para tais procedimentos foram:
# mysql –u root –p
> use NatACL
> insert into users (user, password, expire_type, expire_value)
values (“teste”, “teste”, 1, 0);
As credenciais do usuário criado foram:
- usuário: teste
- senha: teste
3.7 CONFIGURAÇÃO DO NATACL
O arquivo de configuração do NatACL é denominado NatACL.conf e está
localizado no diretório /usr/local/etc. Antes de iniciar o NatACL é imprescindível que
esse arquivo seja alterado e adaptado para a estrutura de rede em que será
utilizado. Para editá-lo basta utilizar o seguinte comando:
# vi /usr/local/etc/NatACL.conf
No arquivo de configuração foram feitas as seguintes alterações: [12]
- Na linha LAN_INTERFACE foi informada a interface de rede ligada a rede
local (eth1), no nosso caso ligado ao switch, e a faixa de endereço da rede local,
ficando da seguinte forma:
43
LAN_INTERFACE eth1 192.168.0.0/24
- Na linha WAN_INTERFACE foi informada a interface de rede ligada a rede
externa (eth0), no nosso caso ligado ao modem ADSL, e o endereço IP da interface,
ficando da seguinte forma:
WAN_INTERFACE eth0 192.168.254.3
- Na linha NAT_TYPE é definido como o NatACL vai atuar, ele pode tanto
atuar como um NAT ou como PROXY (caso da nossa implementação), portanto foi
feita a seguinte alteração:
NAT_TYPE: IPTABLES_PROXY
- Na linha SIMULTANEOUS_LOGON é definido se será permitido o login
simultâneo de um mesmo usuário, no nosso caso não será permitido:
SIMULTANEOUS_LOGON: NO
- Na linha PROXY_PORT é definida a porta em que o Proxy trabalha, no
nosso caso a porta padrão do Squid (3128):
PROXY_PORT: 3128
- Na linha AUTH_MYSQL são especificadas as informações para o acesso ao
MySQL, como este está instalado na mesma máquina do NatACL foi utilizado o
endereço IP de localhost (127.0.0.1), em seguida informada a database a ser
utilizada (NatACL) e as credenciais de acesso administrativo (root) ao MySQL,
ficando:
AUTH_MYSQL 127.0.0.1 NatACL root root
Ainda no arquivo de configuração são apresentadas as regras de iptables
para o funcionamento do módulo de proxy do NatACL, a primeira linha foi
comentada, pois sua função é limpar a tabela de Nat do iptables, o que iria intervir
nas regras adicionadas anteriormente para o funcionamento do proxy transparente e
de redirecionamento de pacotes (IP Forward) vistos anteriormente, portanto as
demais regras foram mantidas sem nenhuma alteração, somente comentada a
primeira regra, conforme pode ser visto a seguir:
#IPTABLES_PROXY START "/sbin/iptables -t nat -F"
IPTABLES_PROXY INIT "/sbin/iptables -t nat -I PREROUTING -i
[INTERFACE] -p tcp -s [LAN_INTERFACE] -d 0/0 --dport 80 -j DNAT --to-
destination [WAN_ADDRESS]:5121"
IPTABLES_PROXY INIT "/sbin/iptables -t nat -I POSTROUTING -p udp --
dport 53 -j SNAT --to-source [WAN_ADDRESS]"
44
IPTABLES_PROXY GRANT "/sbin/iptables -t nat -I PREROUTING -i
[INTERFACE] -p tcp -s [CLIENT_ADDRESS] --dport 80 -j DNAT --to-destination
[WAN_ADDRESS]:[PROXY_PORT]"
IPTABLES_PROXY REVOKE "/sbin/iptables -t nat -D PREROUTING -i
[INTERFACE] -p tcp -s [CLIENT_ADDRESS] -j DNAT --to-destination
[WAN_ADDRESS]:[PROXY_PORT]"
Todas as demais regras do arquivo de configuração foram comentadas. Em
sua grande maioria são relacionadas ao módulo de NAT do NatACL, portanto não
serão utilizados em nossa implementação.
Concluída as alterações no arquivo de configuração do NatACL, já podemos
iniciá-lo, para tanto basta utilizar o seguinte comando:
# NatACL &
3.8 AUTENTICAÇÃO EM PROXY TRANSPARENTE COM O NATACL
Para realizar os testes de autenticação de usuários em um Proxy
transparente, após a implementação do NatACL, utilizamos o mesmo computador
cliente empregado anteriormente no teste do proxy transparente, ainda sem a
implementação do NatACL.
Após a inicialização do NatACL, ao ser feita uma tentativa de acesso a um
site será apresentado o certificado digital gerado anteriormente para utilização de
uma conexão segura para a autenticação dos usuários, e após, a tela de login do
NatACL.
Como o certificado digital gerado não foi criado por uma autoridade de
certificação confiável, foi criado durante a instalação do NatACL, ele é apresentado
nos navegadores Web como um certificado não confiável, portanto é exibida uma
página de conexão não confiável, conforme pode ser vista na figura 14, onde
utilizamos o navegador Mozilla Firefox.
45
FIGURA 14 - Certificado digital no Mozilla Firefox - Fonte: Próprios Autores
Para continuar é preciso selecionar a opção “Entendo os riscos” na página
apresentada, e depois a opção “Adicionar exceção”. Será aberta uma nova janela,
nela deve-se selecionar a opção “Confirmar exceção de segurança”, como pode ser
visto na Figura 15.
FIGURA 15 - Confirmação de certificado no Mozilla Firefox - Fonte: Próprios Autores
46
Se o navegador utilizado for o Microsoft Internet Explorer, basta selecionar a
opção “Continuar neste site (não recomendado)”, conforme pode ser visto na figura
16.
FIGURA 16 - Certificado digital no Microsoft Internet Explorer - Fonte: Próprios Autores
Confirmado o certificado, é apresentada a tela de login do NatACL, para a
autenticação de usuários no proxy transparente, conforme pode ser visto na Figura
17.
FIGURA 17 - Tela de login do NatACL- Fonte: Próprios Autores
47
Neste momento, não é necessário definir manualmente o proxy nos
navegadores Web ou demais aplicativos, para a utilização do proxy, e todos os
acessos estarão sendo feitos a partir do proxy transparente.
Porém o acesso só será concedido ao usuário que efetuar a autenticação na
tela de login do NataCL, caso seja fornecido uma credencial errada será
apresentada uma tela de acesso negado, conforme pode ser visto na figura 18.
Caso as credenciais fornecidas sejam válidas, o acesso será permitido e a página
solicitada será apresentada.
Portanto, temos assim implementando um serviço de proxy transparente com
a autenticação de usuários.
FIGURA 18 - Acesso negado no NatACL - Fonte: Próprios Autores
48
4 TESTES REALIZADOS
4.1 PROXY TRANSPARENTE EM UM AMBIENTE WIRELESS
Após finalizar com sucesso a implementação do NatACL, cumpri-se o objetivo
principal do projeto: oferecer autenticação de usuários utilizando um proxy
transparente.
Dessa forma, passou-se a pensar nos possíveis cenários em que esta
implementação poderia ser usada, e o cenário mais oportuno seria um ambiente
sem fio.
O controle de usuários em um ambiente wireless é uma solução muito
interessante. Oferecer acesso à internet, exigindo uma forma de autenticação,
podendo controlar este acesso, de maneira totalmente transparente, não exigindo
nenhum tipo de configuração por parte do usuário e sem que seja necessário fazer
uma intervenção nos computadores dos mesmos, para que possam utilizar dos
recursos oferecidos, pode ser bastante atraente.
Poderíamos utilizar este cenário, por exemplo, em lan houses, aeroportos,
cafeterias, shoppings, restaurantes, hotéis e instituições de ensino, de forma que o
cliente ou usuário teria acesso à internet a partir de um laptop ou dispositivo portátil
qualquer, apenas se conectando na rede sem fio disponível, e a partir do proxy
transparente, sem que fosse necessário nenhum tipo de configuração ou
intervenção, com a posse de uma credencial de acesso (usuário e senha) ele teria o
seu acesso garantido, sem uma credencial válida este acesso não seria
disponibilizado mesmo que ele se conectasse a rede sem fio disponibilizada.
Outro importante cenário para a utilização dessa implementação de proxy
transparente com autenticação, poderia ser o fornecimento de internet através de
rádio ou uma rede sem fio de grande abrangência, em que os clientes e usuários
que pagassem uma mensalidade teriam uma credencial para utilização deste acesso
depois de autenticado, e a partir do bloqueio de login simultâneo, mesmo que esta
credencial seja compartilhada, somente um acesso simultâneo poderia ser feito.
Dessa forma, analisando estes cenários apresentados, resolve-se
implementar um ambiente sem fio utilizando proxy transparente com autenticação.
49
Para tanto, alguns outros serviços serão implementados, tais como: servidor DHCP,
análise de logs (Sarg) e administração de banco de dados (phpMyAdmin), provendo
assim um ambiente completo e funcional para a autenticação segura de usuários e
concessão de acesso à internet.
Os equipamentos utilizados para essa nova implementação, foram:
• 01 Modem ADSL Siemens Speedstream 4200
• 01 Roteador Sem Fio D-link DI-524
• 01 Computador com a seguinte especificação:
• Processador: Core 2 Quad Q6600 2.40 Ghz
• Memória RAM: 4 GB
• HD: 160 GB
• 01 Placa de rede onboard Realtek RTL8168C (eth0)
• 01 Placa de rede offboard Realtek RTL813 (eth1)
Basicamente foram mantidos os mesmos equipamentos da implementação do
NatACL, somente o switch onde eram conectados os clientes, foi substituído por um
roteador sem fio. Esta nova estrutura com o ponto de acesso sem fio está
apresentada na Figura 19.
FIGURA 19 - Estrutura de rede da implementação do proxy transparente com autenticação no ambiente wireless - Fonte: Próprios Autores
Conforme dito anteriormente a estrutura do ambiente sem fio é praticamente a
mesma da implementação do NatACL. O computador servidor foi mantido, portanto
todos os serviços já implementados serão conservados e utilizados no novo
50
ambiente, caso necessário, serão feitas alterações nas implementações originais
para adequá-las ao novo cenário.
Serão feitas também implementações de serviços adicionais, acrescentando
funcionalidades como o acompanhamento dos registros de acessos (logs), providos
pela ferramenta Sarg, também uma forma mais simples para a criação, edição e
remoção de usuários na base de dados do MySQL 5.0, através do uso da
ferramenta phpMyAdmin na versão 2.9.1.1.
No novo ambiente o acesso a internet continua a ser provido pelo modem
ADSL, ligado a uma interface de rede do servidor proxy, sua outra interface de rede
será ligada a uma das portas LAN do roteador wireless, este que irá prover uma rede
sem fio para a conexão dos clientes que farão uso do serviço oferecido
Cada cliente que for adicionado a este cenário wireless, deverá ter um
endereço IP exclusivo, que o identificará e fará com que ele esteja inserido na sub-
rede em que foi ligado, daí a necessidade de um servidor DHCP, que fará a
distribuição e gestão dos endereços IP nos clientes.
Na nova estrutura foram mantidos os endereços IP definidos anteriormente,
em que a interface eth0 ligada ao modem recebeu o endereço IP 192.168.254.3 e a
interface eth1 ligada agora ao roteador wireless recebeu o IP 192.168.0.2.
Por padrão, este modelo de roteador wireless vem de fábrica com o IP
estático 192.168.0.1, mas este endereço pode ser alterado. Manteremos este
endereço, porém algumas alterações em sua configuração foram feitas. Primeiro,
por ser roteador ele possui um serviço de DHCP interno para a distribuição de
endereços IP, este serviço será desativado, pois esta gestão será feita por um
serviço que será implementado posteriormente.
Portanto foi acessado sua interface de configuração através do navegador,
digitando na barra de endereço o seu endereço IP (http://192.168.0.1). E foi
desativado o recurso de DHCP conforme pode ser visto na Figura 20.
51
FIGURA 20 - Desativando o recurso de DHCP no roteador wireless - Fonte: Próprios Autores
A segunda alteração feita foi a configuração da rede sem fio que será
fornecida pelo equipamento. O nome de identificação (SSID) dado a rede foi “natacl”,
uitlizando o canal de comunicação “6”, segurança WPA2-PSK com algoritmo AES e
definida uma senha para esta rede (“projetofinal”), conforme pode ser visto na Figura
21.
FIGURA 21 - Configuração da rede sem fio do roteador wireless - Fonte: Próprios Autores
52
Salvas as configurações no roteador wireless, foi efetuada a instalação e
configuração do serviço de DHCP. Para efetuar a instalação deste serviço foi
utilizado o seguinte comando:
# apt-get install dhcp3-server
Durante a instalação do serviço de DHCP pode ser apresentado uma
mensagem avisando sobre a existência de um arquivo de configuração para o
serviço de DHCP, solicitando que seja informado se a instalação deve manter o
arquivo existente ou substituir pelo arquivo presente no pacote de instalação,
conforme pode ser visto na Figura 22.
FIGURA 22 - Instalação do DHCP - Fonte: Próprios Autores
Optou-se por substituir o arquivo de configuração existente no sistema, pelo
presente no pacote de instalação, mas logo em seguida foi removido este arquivo de
configuração e criado um novo, removendo assim todo o conteúdo do arquivo de
configuração inicial e substituído por algumas linhas contendo somente as funções
necessárias nessa implementação. Os comando utilizados foram:
# rm –rf /etc/dhcp3/dhcpd.conf
# vi /etc/dhcp3/dhcpd.conf
E o novo conteúdo do arquivo de configuração do DHCP passou a ser: [13]
option domain-name "natacl.com.br";
option domain-name-servers 208.67.222.222, 208.67.220.220;
option routers 192.168.0.2;
default-lease-time 3600;
53
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.100 192.168.0.254;
}
Definindo assim que a range de rede seria do endereço IP 192.168.0.100 ao
192.168.0.254, distribuídos aos clientes que fizerem uso do serviço de DHCP
(Distribuição de IP). Durante a distribuição do endereço IP automaticamente será
repassado o endereço de gateway 192.168.0.2, encaminhando o tráfego ao servidor,
e também os endereços de DNS do OpenDNS, um servidor de DNS gratuito, com
alta disponibilidade e proteção contra sites fraudulentos
Efetuada a configuração do serviço de DHCP, indicou-se que o serviço
escutará apenas a interface eth1, já que a mesma estará ligada ao roteador wireless
e na mesma sub-rede. Portanto alterou-se o arquivo dhcp3-server presente em
/etc/default, através do comando:
# vi /etc/default/dhcp3-server
E alteramos a linha interface:
INTERFACES=”eth1”
A partir desse momento o serviço já pode ser iniciado utilizando o seguinte
comando:
# /etc/init.d/dhcpd start
O servidor passa então a ser o responsável pela gestão e distribuição dos
endereços IP na sub-rede wireless e o próximo passo é implementar o serviço de
proxy transparente utilizando o Squid.
Foi utilizado o serviço de proxy transparente já implementado anteriormente
no servidor, e nenhuma alteração foi feita neste serviço antes implementado, porém
foi feita uma melhoria em relação as regras de iptables e de reencaminhamento de
pacotes (IP Forwarding) realizada anteriormente.
Em um cenário de produção ou em que não pode haver indisponibilidade dos
serviços oferecidos, é importante que todos os serviços sejam iniciados
automaticamente, pois caso seja realizado a reinicialização do sistema por exemplo,
este serviços devem estar disponíveis logo que restabelecido o sistema.
Portanto criou-se um script contendo as regras de iptables e o comando para
IP Forwarding, através do seguinte comando:
# vi /opt/firewall.sh
O conteúdo do script foi:
54
#!/bin/bash
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT -
-to-port 3128
iptables -t nat -A PREROUTING -i eth1 -p udp --dport 80 -j REDIRECT -
-to-port 3128
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Foi dada permissão de execução para o script através do comando:
# chmod +x /opt/firewall.sh
E o script foi adicionado a inicialização do sistema, portanto iniciado
automaticamente durante o boot do sistema, realizando a adição dos comandos
apresentados em seu conteúdo no sistema, provendo então o redirecionamento das
requisições através das regras de iptables e habilitando o reencaminhamento de
pacotes, necessários para o funcionamento correto do proxy no modo transparente.
Para adicionar o script na inicialização do sistema é necessário alterar o
arquivo /etc/rc.local, adicionando um linha ao final do arquivo contendo o comando
para se iniciar o script, portanto o comando utilizado para a edição do arquivo foi:
# vi /etc/rc.local
A linha adicionada:
/opt/firewall.sh
Com o Squid funcionando e o provendo o proxy transparente para o
ambiente, implementou-se o SARG (Squid Analysis Report Generator) em sua
versão 2.2.2, uma ferramenta que gera relatórios no formato HTML a partir dos
arquivos de log do Squid, fornecendo uma interface web com relatórios e gráficos
ricos em detalhes sobre os acessos realizados pelos usuários, registrados pelo
Squid. [15]
Porém antes de instalar o SARG, é necessário instalar o servidor HTTP
Apache e foi utilizada a versão 2.2.3-4-etch6, que será responsável por exibir os
relatórios gerados pelo SARG.
Para efetuar a instalação do Apache foi utilizado o comando:
# apt-get install apache2
E para iniciá-lo o comando:
# /etc/init.d/apache2 start
Não foi necessária nenhuma configuração no serviço de HTTP. E após a sua
inicialização, foi então realizada a instalação do SARG também através do
gerenciador de pacotes APT, utilizando o comando:
55
# apt-get install sarg
O arquivo de configuração do SARG chama-se sarg.conf e é encontrado no
diretório /etc/squid, este arquivo foi alterado através do comando:
# vi /etc/squid/sarg.conf
As linhas alteradas foram: [15]
language Portuguese
access_log /var/log/squid/access.log
output_dir /var/www/sarg
A primeira linha diz respeito ao idioma da interface web que será
apresentada, a segunda linha diz respeito ao arquivo de log de onde serão retiradas
as informações de acesso registradas pelo squid (por padrão,
/var/log/squid/access.log), e por fim a terceira linha que diz respeito ao diretório de
saída onde serão gerados os relatórios do SARG. Como este parâmetro foi alterado,
deve-se criar um diretório de mesmo nome para armazenar os relatórios:
# mkdir /var/www/sarg
Realizado os passos, basta executar o seguinte comando:
# sarg
Este comando irá gerar os relatórios com os acessos registrados no arquivo
/var/log/squid/access.log até o momento. Dessa forma, se faz necessário criar uma
forma de automatizar a geração destes relatórios de forma, que a interface web do
SARG conterá sempre informações atualizadas sobre os acessos dos usuários.
Incluímos então no agendador de tarefas do Linux, o cron, uma tarefa para
gerar os relatórios do SARG a cada 10 minutos, nos permitindo ter estas
informações de acesso sempre atualizadas.
Para acionar o gerenciador de tarefas cron basta utilizar o comando:
# crontab –e
E adicionar a linha:
0/10 * * * * sarg
No qual agendamos a cada 10 minutos a execução do comando sarg,
responsável pela geração dos relatórios.
Para acessar a interface do SARG e visualizar os relatórios de acesso, basta
através de um navegador Web acessar o endereço http://192.168.0.2/sarg, na figura
23 é apresentada a interface inicial do SARG, apresentando por data seus relatórios
de acesso.
56
FIGURA 23 - Interface web do SARG - Fonte: Próprios Autores
Selecionando uma data, serão apresentados os endereços IP dos clientes
que efetuaram pelo menos um acesso na data, selecionando um destes endereços é
apresentando um relatório detalhando de todos os acessos realizados, inclusive
apontando os acessos negados a sites bloqueados pelo Squid (marcados com a
palavra NEGADO, a frente do acesso), conforme pode ser visto na Figura 24.
O próximo passo na preparação do ambiente é realizar a instalação do
MySQL, para prover a base de dados do NatACL. Foi utilizada a implementação feita
anteriormente, porém para facilitar a manipulação de usuários na base de dados do
MySQL, efetuou-se a instalação do phpMyAdmin, uma ferramenta para auxílio na
administração de base de dados MySQL. Através de uma interface Web fornecida
pela ferramenta é facilmente possível criar, editar e deletar bases de dados, tabelas
e campos, além de outros recursos relacionados a gestão de banco de dados. [15]
Para efetuar a sua instalação utilizamos o seguinte comando:
# apt-get install phpmyadmin
Para efetuar a sua instalação utilizamos o seguinte comando:
# apt-get install phpmyadmin
57
FIGURA 24 - Relatório de acessos de um determinado usuário - Fonte: Próprios Autores
Depois de instalada a ferramenta já é possível administrar a base de dados
através do phpMyAdmin, para acessar a sua interface basta, através de um
navegador Web, acessar o endereço http://192.168.0.2/phpmyadmin.
Na interface web do phpMyAdmin, a primeira tela que será apresentada será
solicitando o nome de usuário e senha para acesso a base de dados do MySQL,
efetuado o login basta selecionar no canto esquerdo do gerenciador, o banco de
dados denominado “NatACL”, nesse momento será exibida a única tabela existente
nesta base de dados, que é a tabela “users” onde estão os usuários que poderão
autenticar no NatACL, para visualizar este usuários basta selecionar a tabela “users”
no lado esquerdo e selecionar a opção “Visualizar” no menu superior, será então
apresentado o conteúdo da tabela, permitindo assim visualizar todos os usuários
adicionados na base de dados do NatACL, conforme pode ser visto na Figura 25.
58
FIGURA 25 - Tabela de usuários no phpMyAdmin - Fonte: Próprios Autores
Para adicionar um novo usuário, basta estar na tabela “users” e selecionar a
opção “Inserir” no menu superior, conforme pode ser visto na Figura 26.
Neste momento serão exibidos alguns campos a serem preenchidos para a
criação do usuário. Os campos obrigatórios são:
- user: onde será informado o nome de usuário a ser adicionado;
- password: senha do usuário;
- expire_type: tipo de expiração;
- expire_valor: valor de expiração.
Os campos de id e address não são obrigatórios, o primeiro é seqüencial e
será completado automaticamente durante a criação de um novo usuário.
59
FIGURA 26 - Criação de usuário no phpMyAdmin - Fonte: Próprios Autores
O passo final da implementação é a instalação e configuração do NatACL,
implementação essa que será aproveitada do cenário anterior. As configurações
necessárias para o correto funcionamento do NatACL neste novo cenário são as
mesmas da implementação anterior.
Portanto somente foi realizada a reinicialização do serviço, finalizando seu
processo através do comando:
# killall NatACL
E o iniciando novamente:
# NatACL &
Para realizar os testes de autenticação de usuários em um proxy transparente
neste novo cenário, utilizou-se um laptop como computador cliente.
60
Utilizando a interface sem fio do laptop localizou-se a rede criada
anteriormente conforme pode ser visto na Figura 27, e conectou-se a ela.
FIGURA 27 - Rede sem fio localizada - Fonte: Próprios Autores
Ao conectar-se a rede, recebe-se automaticamente um endereço IP e as
configurações de gateway e DNS providas pelo DHCP implementado, conforme
pode ser visto na Figura 28.
FIGURA 28 - Endereço de IP fornecido pelo DHCP - Fonte: Próprios Autores
61
Ao efetuar uma tentativa de acesso a um site da internet, foi apresentado o
certificado digital para a utilização de uma conexão segura a tela de login do
NatACL.
Após a confirmação do certificado foi apresentada a tela de login do NatACL,
e após uma autenticação bem sucedida o acesso a página foi liberado.
Dessa forma, após as implementações mostradas anteriormente, criou-se um
cenário completo e funcional para a utilização de um proxy transparente autenticado.
Onde um cliente a se conectar em uma rede sem fio criada, automaticamente
receberá um endereço IP válido na rede interna, provido pelo serviço de DHCP, ao
realizar uma tentativa de acesso a Internet esse usuário utilizará uma credencial
para autenticar, de forma transparente, utilizar um serviço de compartilhamento à
internet, provido por um proxy (Squid). E, ainda, no mesmo cenário, o administrador
terá uma forma simplificada de gerenciamento de usuários, podendo facilmente criar,
editar ou excluir usuários em uma base de dados MySQL, através da ferramenta
phpMyAdmin, e por fim auditar e acompanhar todos os acessos dos usuários e
clientes dessa rede através dos relatórios HTML disponíveis no SARG, podendo
inclusive criar bloqueios a sites através do Squid.
4.2 TESTES DE SEGURANÇA
Após a criação do ambiente wireless, foram realizados alguns testes e
verificações referentes a questões de segurança envolvendo a implementação dos
serviços apresentados.
O primeiro teste realizado foi a configuração manual do proxy no navegador
de um cliente conectado a rede sem fio. Este cliente ao se conectar a rede sem fio,
recebeu um endereço do DHCP, e todos as suas tentativas de acesso a um site da
internet foram redirecionadas ao NatACL, que por sua vez apresentou a tela de login
exigindo a autenticação para a liberação do acesso. Ao efetuarmos a configuração
manual do proxy no navegador deste cliente, as requisições foram direcionadas
diretamente para o Squid, não apresentando assim a tela de login do NatACL. As
62
requisições foram tratadas pelo Squid, e os acessos foram concedidos sem que o
usuário precisasse autenticar.
Dessa forma, retirando a transparência do proxy, através da configuração
manual no cliente, abriu-se uma brecha permitindo a utilização do acesso a internet,
sem a necessidade de autenticação. Uma falha grave para qualquer tipo de cenário
que possa ser utilizada a ferramenta. Falha que poderia ser minimizada alterando-se
a porta do proxy (retirando a porta padrão do Squid), mas que não resolveria o
problema, somente dificultaria esta utilização, caso descoberto a nova porta e
efetuada a configuração manual do proxy, esta falha poderia ser explorada
novamente.
Outro teste realizado foi a verificação da senha dos usuários, armazenada na
base de dados do MySQL. Ao verificar a base de dados “NatACL” criada
anteriormente no MySQL, a tabela “users” contendo as informações dos usuários,
dentre elas a senha, foi constatado que estas senhas são armazenadas em texto
puro, não é feito nenhum tipo de criptografia, outra característica grave, que pode
gerar algum tipo de problema ao administrador do sistema, como é visto na figura
29.
FIGURA 29 - Usuários e senhas na base de dados – Fonte: Próprios Autores
Ao criar as regras do proxy, verificou-se a indisponibilidade de se criar regras
de controle de acesso (liberação ou bloqueio) baseadas em usuário ou grupo de
usuários, dessa forma, os únicos controles de acesso que podem ser criados, serão
aplicados a todos os clientes que fizerem serviço do proxy. Sendo assim, só é
possível utilizar as regras padrão do Squid trabalhando de forma transparente,
mesmo que em conjunto com o NatACL. . Esta limitação em um cenário como o de
uma lan house, restaurantes, hotéis, dentre outros, não seria tão grave, pois nestes
tipos de cenários, os usuários estão de passagem ou por períodos curtos, e portanto
não é muito viável ou praticável a criação de regras para usuários determinados,
63
bloqueia-se apenas sites indesejáveis ou prejudiciais, podendo ser bloqueado via acl
no squid, sendo praticável a todos os usuários que utilizarem o serviço. Caso deseja-
se criar regras específicas para usuários, a implementação do NatACL juntamente
com o proxy transparente do Squid, não é viável.
Em relação ao certificado digital apresentado durante a autenticação do
NatACL, dependendo do cenário utilizado, a aquisição de um certificado assinado
emitido por uma Autoridade Certificadora pode ser necessário, aumentado a
confiança do usuário no processo de autenticação. Durante o processo de
autenticação, conforme apresentando anteriormente, caso o certificado digital não
seja assinado, é necessário aceitar o certificado, pois os navegadores o apresentam
como um certificado não confiável, justamente pelo fato de não ser assinado por
uma Autoridade Certificadora, processo este que pode gerar insegurança nos
usuários e dificuldade durante este processo.
Sendo assim no momento da apresentação do certificado, verificou-se os
dados informados durante a instalação do NatACL, solicitando a visualização das
informações sobre o certificado, conforme pode ser visto na figura 30. O que torna a
conexão mais confiável devido a apresentação do certificado e a segurança provida
no momento da autenticação, porém conforme dito, em um cenário onde se seja
exigida maior segurança, a aquisição de um certificado pode ser importante.
FIGURA 30 - Certificado Digital gerado – Fonte: Próprios Autores
64
5 CONCLUSÃO
Com a utilização de ferramentas livres através da ferramenta NatACL
juntamente com Squid para promover a autenticação em um proxy transparente,
fundamentada em aspectos de segurança, rapidez e serviços que rodam via
servidor, isto foi alcançado no decorrer da pesquisa em que se mostrou ser uma
ferramenta bastante útil para o administrador de rede, capaz de cobrir todas as
preocupações que se estende com a economia, segurança e a rapidez da rede,
quanto maior for à troca de informação maior será o tráfego dos pacotes e mais
difícil a administração dos usuários com a internet. Sem uma auditoria e regras para
uso da rede e principalmente da internet, ocorrerão constantes perdas de pacotes e
lentidão da troca das informações, o proxy nos dá uma economia na banda de
internet, pois havendo regras ela se torna mais eficiente e eficaz garantindo a
disponibilidade.
Como apresentado anteriormente o NatACL mostra-se aplicável em
empresas, por centralizar em uma única máquina todo o serviço de distribuição da
internet, autenticação de usuários e também em conjunto com o Squid promovendo
a transparência, excluindo as várias configurações que precisariam anteriormente
serem feitas manualmente. Além disso, esta ferramenta possibilita que o trabalho de
autenticação dos usuários possa ser realizado via servidor não somente agilizando
suas conexões, mas também, deixando a rede “sem gargalos”, apesar de haver
algumas deficiências no projeto como a impossibilidade de se fazer regras baseadas
em usuários, a possibilidade de navegação sem autenticação com a marcação
manual do proxy e a gravação da senha dos usuários sem criptografia na base de
dados.
Acredita-se que para profissionais da área, esta ferramenta é muito útil e
importante para o gerenciamento de ambiente. Ela proporciona, não somente
segurança, como autenticação dos usuários. Além disso, a ferramenta oferece
também a transparência em configurações de proxy deixando a ferramenta melhor
adaptável a qualquer ambiente, proporcionando mais flexibilidade na rede, não
necessitando da utilização de configurações no cliente em toda a rede.
Por esta ferramenta não ter muito material de apoio, algumas empresas ainda
não a utilizam por desconhecimento ou acreditarem ser de valor elevado a
65
qualificação de profissionais para utilizá-la. Este estudo demonstra que a ferramenta
pesquisada possibilita, não somente a configuração de autenticação de forma
simples com transparência, o que torna menos dispendioso para a empresa, como
também, a própria ferramenta por ser livre tem um custo baixo na implementação
por não ser preciso licenças de uso de software. Sendo assim, torna-se
extremamente viável, por seu custo ser baixo, pela facilidade de instalação e
administração do ambiente de rede e, para a empresa ela proporciona agilidade no
seu sistema gestor, nas conexões de um modo geral, o que acarreta em melhoria no
trabalho dos usuários e, conseqüentemente, um maior aproveitamento da rede.
Como sugestões para trabalhos futuros há a possibilidade de
desenvolvimento de regras no controle de acesso por usuário ou grupo de usuário
assim facilitando a administração por usuários. Outra melhoria na segurança seria a
restrição de acesso através da marcação manual do proxy, em que mesmo o usuário
efetuando esta configuração seria necessário a autenticação.
Testes de desempenho seriam interessantes para mostrar a velocidade e
capacidade de minimização do trafego através do Proxy e sua utilização juntamente
com o NatACL.
O armazenamento da senha dos usuários de forma criptografada ou através
de hash na base de dados seria um interessante recurso a ser adicionado para
prover ainda mais segurança ao ambiente.
Outra sugestão seria a realização de algumas modificações e melhorias na
tela de login apresentada pelo NatACL, tornando-a assim mais atrativa e de
preferência personalizando-a de acordo com o cenário aplicado, por exemplo, em
um ambiente comercial adicionando informações sobre os provedores da solução.
Dessa forma, a utilização da ferramenta NatACL juntamente com o Squid é
uma solução bastante viável para prover a autenticação em um proxy transparente,
estas aplicações em conjunto provêm esta funcionalidade desejada de autenticação.
Porém algumas modificações e melhorias devem ser implementada para que esta
possa ser considerada como uma solução definitiva, tal como a proibição do acesso
caso seja realizada a marcação manual do proxy, fato que segundo os testes
realizados permitiu o acesso à internet sem a autenticação no proxy transparente.
66
REFERÊNCIAS BIBLIOGRÁFICAS
[1] SILBERSCHATZ, A.; GALVIN, P. ; GAGNE, G. Sistemas operacionais:
conceitos e aplicações. 1. ed. Rio de Janeiro: Campus, 2000.
[2] SOARES, L. F. G.; LEMOS, G.; COLCHER, S.. Redes de computadores: Das
lans, mans e wans as redes atm. 2.ed. Rio de janeiro: Campus, 2002.
[3] TANENBAUM, Andrew S. Redes de computadores. 4. ed. Rio de janeiro:
Campus, 1999.
[4] ALBUQUERQUE R.; Ribeiro, B. 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 : Módulo Security, 2002
[5] KUROSE, James F. ; ROSS, Keith W. Redes de computadores e a Internet.
Uma abordagem top-down. São Paulo: Person Addison Wesley, 2006
[6] MORIMOTO, Carlos E.; Configurando um servidor Proxy com o Squid Revista
Guia do Hardware.net, São Paulo: Guia do Hardware ano 1,nº7,p.75-96, ago.2007.
[7] ProxyAuth. Disponível em: http://www.hostname.org/proxy_auth/. Acesso em: 28
nov.2009.
[8] NoCat.net. Disponível em: http://nocat.net/. Acesso em: 28 nov.2009.
[9] RIBEIRO, Carlos Humberto. Implantação de um sistema integrado para
autenticação de usuários e permissão de acesso em um proxy transparente. 2007.
74 f. Monografia(Pós-Graduação em Administração em Redes Linux) – Universidade
Federal de Lavras, 2007.
67
[10] Advanced Packaging Tool. Disponível em: http://pt.wikipedia.org/wiki/Apt-get.
Acesso em: 28 nov.2009.
[11] Como compilar pacotes sobre demanada (auto-apt). Disponível em:
http://wiki.forumdebian.com.br/index.php/Como_compilar_pacotes_sobre_demanada
_%28auto-apt%29. Acesso em: 28 nov.2009.
[12] FELIX, Alexandro. Instalando natACL no Debian Etch (proxy autenticado).
Disponível em: http://www.vivaolinux.com.br/artigo/Instalando-natACL-no-Debian-
Etch-%28proxy-autenticado%29. Acesso em: 29 nov.2009
[13] DHCP Server Configuration in Debian. Disponível em:
http://www.debianhelp.co.uk/dhcp.htm. Acesso em: 28 nov.2009.
[14] Sarg – Gerador de relatórios do Squid – tutoriais, dicas e indicações. Disponível
em: http://www.zago.eti.br/squid/sarg.html. Acesso em: 28 nov.2009.
[15] COSTA, José Cláudio V. Configuração do SARG em 20 minutos. Disponível
em: http://www.vivaolinux.com.br/dica/Configuracao-do-SARG-em-20-minutos.
Acesso em: 28 nov.2009.
[16] MORRONE, Lucas. Instalado o phpMyAdmin no Debian Etch. Disponível em:
http://www.vivaolinux.com.br/artigo/Instalando-o-phpmyAdmin-no-Debian-Etch/.
Acesso em: 28 nov.2009.
[17] Linux Debian. Disponível em: http://www.debian.org.br. Acesso em: 28
nov.2009.
[18] Pacotes a serem baixados específicos do projeto NatACL. Disponível em:
http://www.hostname.org/proxy_auth. Acesso em: 28 nov.2009.
[19] Projeto Mundial NatACL site oficial. Disponível em: http://natacl.sourceforge.net.
Acesso em: 28 nov.2009.
68
[20] MORIMOTO, Carlos E.; Livro Redes. Guia Prático. São Paulo: Sulina, 2008
[21] UNIRAS. NISCC Technical Note 01/03: Understanding Database Security.
NISCC. 2004.
