Proposta de controle eficaz do acesso à Internet.

FACULDADE SALESIANA DE VITÓRIA
PÓS-GRADUAÇÃO EM SEGURANÇA DE
REDES DE COMPUTADORES
ROGÉRIO PEREIRA GUALBERTO
ROMMEL BAIA SILVA
Proposta de Controle Eficaz do Acesso à Internet
VITÓRIA
2007
ROGÉRIO PEREIRA GUALBERTO
ROMMEL BAIA SILVA
Proposta de Controle Eficaz do Acesso à Internet
Monografia apresentada ao Curso de Pósgraduação em Segurança de Redes de
Computadores da Faculdade Salesiana de
Vitória, como requisito parcial para obtenção do
título de Especialista em Segurança de Redes de
Computadores.
Orientador: Prof. M.Sc. Sérgio Teixeira
VITÓRIA
2007
Dados Internacionais de Catalogação-na-publicação (CIP)
(Biblioteca da Faculdade Salesiana de Vitória, Espírito Santo, Brasil)
G899p
Gualberto, Rogério Pereira, 1966
Proposta de Controle Eficaz do Acesso à Internet / Rogério Pereira
Gualberto, Rommel Baia Silva. – 2007.
54 f. : il.
Orientador: Sérgio Teixeira.
Monografia (pós-graduação em Segurança de Redes de
Computadores) – Faculdade Salesiana de Vitória.
1.Redes de Computadores - Segurança. 2. Controle de Acesso. 3.
Squid. I. Gualberto, Rogério Pereira. II. Teixeira, Sérgio. III. Faculdade
Salesiana de Vitória. IV. Título.
CDU: 004.7
ROGÉRIO PEREIRA GUALBERTO
ROMMEL BAIA SILVA
PROPOSTA DE CONTROLE EFICAZ DO ACESSO À
INTERNET
Monografia apresentada ao Curso de Pós-graduação em Segurança de Redes de
Computadores da Faculdade Salesiana de Vitória, como requisito parcial para obtenção do
título de Especialista em Segurança de Redes de Computadores.
Aprovada em 13 de agosto de 2007.
COMISSÃO EXAMINADORA
_____________________________________
Prof. M.Sc. Sérgio Teixeira
Orientador
_____________________________________
Prof. D.Sc. Tânia Barbosa Salles Gava
Co-orientador
_____________________________________
Prof. M.Sc. Rodrigo Bonfá Drago
Petróleo Brasileiro S.A. (PETROBRAS)
AGRADECIMENTOS
Ao Prof. Sérgio Teixeira, pela orientação durante esta jornada, à Profª Tânia Barbosa Salles
Gava que muito contribuiu na realização deste projeto, aos colegas de curso que de alguma
forma também são responsáveis por este trabalho, às nossas esposas pela compreensão e
incentivo, aos nossos pais que, mesmo distantes, também foram incentivadores e a todos que
direta ou indiretamente contribuíram para que pudéssemos realizar mais esta etapa da nossa
vida.
RESUMO
Este trabalho tem como objetivo apresentar uma proposta de implementação de uma solução
eficaz no controle de acesso à Internet, apresentando um conjunto de ferramentas com
funções complementares, no intuito de atingir um alto grau de segurança. Além disso, é
proposto um sistema hierarquizado de regras de controle de acesso à Internet através de uma
estruturação lógica.
Palavras-chave: Redes de Computadores - Segurança, Controle de Acesso, Squid.
ABSTRACT
This paper has as the objective to supply the reader the necessary agreement to allow the
implementation of an efficient solution in the access control to the Internet presenting a set of
systems with complementary functions between itself, in intention to reach one high degree of
security. Moreover we consider a hierarchic system of rules of control of access to the
Internet through a logical structure.
Keywords: Computer Networks – Security, Access Control, Squid.
LISTA DE FIGURAS
Figura 1 – Total de incidentes reportados ao CERT.br por ano..............................................12
Figura 2 – O serviço de Proxy ................................................................................................ 17
Figura 3 – Fluxo da requisição do cliente via Filtro de Conteúdo ........................................ 39
Figura 4 – Arquivos de configuração do Dansguardian......................................................... 42
Figura 5 – Relatório de acesso à Internet ...............................................................................47
SUMÁRIO
1 - INTRODUÇÃO ...........................................................................................................10
1.1 MOTIVAÇÃO.............................................................................................................13
1.2 OBJETIVOS................................................................................................................13
1.3 METODOLOGIA.......................................................................................................14
1.4 ORGANIZAÇÃO DO TRABALHO.........................................................................14
2 – CONCEITOS BÁSICOS DE PROXY........................................................16
2.1 CONTROLE DE ACESSO........................................................................................17
2.2 FILTRO DE CONTEÚDO.........................................................................................19
2.3 CONTROLADOR DE DOMÍNIO ...........................................................................20
2.4 AUTENTICAÇÃO DE USUÁRIOS..........................................................................21
3 – O MECANISMO DE CONTROLE DE ACESSO NO SQUID..................22
4 – PROPOSTA DE IMPLEMENTAÇÃO DO CONTROLE DE ACESSO
NO SQUID............................................................................................................................30
4.1 CRIAÇÃO DAS ACL’S..............................................................................................30
4.2 CRIAÇÃO DAS REGRAS DE ACESSO.................................................................34
5 - CONFIGURAÇÃO DO FILTRO DE CONTEÚDO NO
DANSGUARDIAN..............................................................................................................39
6 - IMPLEMENTAÇÃO DA ANÁLISE DE LOGS VIA SARG ......................46
6.1 CONFIGURANDO O SARG......................................................................................48
6.2 EXECUTANDO O SARG......................................................................................... 51
7 - CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS........................53
8 - REFERÊNCIAS BIBLIOGRÁFICAS.................................................................54
10
1 - INTRODUÇÃO
O controle no acesso à Internet proveniente de redes privativas é um tema bastante
controverso. Algumas pessoas insistem em dizer que os profissionais contratados por uma
empresa têm direito à privacidade no acesso a Internet, sem levar em consideração que um
contrato de trabalho foi assinado e que as atividades são exercidas em nome da empresa, em
seu ambiente físico, e utilizando-se de recursos da própria empresa.
Contudo, a alegação das empresas é bastante convincente: minimizar os riscos de vírus,
trojans1 e outras pragas da Internet e aumentar a produtividade. A fim de obterem uma base
legal, as corporações têm adotado fortemente a estratégia de embasarem-se em uma política
de segurança ou em um Termo de Compromisso assinado pelo funcionário, quando de sua
entrada na empresa, em que toma conhecimento e concorda com o procedimento.
Pesquisas realizadas nos últimos anos têm demonstrado pelo tipo de site acessado, que a
produtividade dos funcionários com acesso irrestrito à Internet em ambiente de trabalho é
baixa. A seguir, algumas estatísticas sobre o mau uso da Internet:
- Em média um terço do tempo gasto on-line na Internet nada tem a ver com trabalho;
- 75% das empresas citam os empregados como a principal causa, voluntária ou involuntária,
das invasões;
- 45% dos negócios informaram que acessos não autorizados são feitos de dentro da própria
empresa;
- Existe mais de 43 milhões de usuários utilizando MSN no horário de trabalho, para os fins
da empresa ou para fins pessoais, e apenas um quarto das companhias tem uma política clara
para o uso do MSN no trabalho;
1
trojans são arquivos impostores que afirmam ser desejáveis mas, na verdade, são mal-intencionados. Uma
distinção muito importante dos verdadeiros vírus é que eles não se reproduzem, como os vírus. São conhecidos
também como “Cavalo e Tróia”. Um exemplo clássico do Cavalo de Tróia é um objeto que faz a autenticação de
usuários e grava seu nome e sua senha em um arquivo.
11
- Próximo de 80% do uso de Mensagens Instantâneas é feito através de Serviços Grátis como
o AOL, MSN e Yahoo, expondo empresas a sérios riscos de segurança. Os hackers se
aproveitam dessas falhas para uma invasão;
- 73% de todas as pesquisas sobre filmes em redes de compartilhamento de arquivos foram
voltadas para a pornografia;
- 70% de arquivos pornôs são baixados (download) entre 9:00 e 17:00, ou seja, durante o
expediente normal de trabalho;
- 37% dos usuários de Internet visitaram um Site pornô na Web;
- Uma em cada três empresas detectou algum “Spyware2” em suas redes;
- Existem mais de 7.000 programas “spywares”. Eles são enviados por hacker interessado em
obter senhas de acessos a contas bancárias, por exemplo;
- 77% dos acessos às Rádios On-line (UOL, TERRA) são feitos entre 5:00 e 17:00 h;
- 44% dos empregados usam ativamente Música On-Line;
- Apesar de 99% das empresas usarem software antivírus, 82% delas foram atacadas por vírus
e worms3. A maioria dos ataques, com códigos maliciosos, usualmente eram para roubar
dados confidenciais.
O Gráfico da Figura 1 mostra o total de incidentes ocorridos em redes que foram
espontaneamente notificados ao CERT.br (Centro de Estudos, Resposta e Tratamento de
Incidentes de Segurança no Brasil). O CERT.br é responsável por receber, analisar e
responder a incidentes de segurança envolvendo redes conectadas à Internet no Brasil.
2
Spyware é um programa mal intencionado que visa a obtenção de dados confidenciais do usuário, muito
utilizado para a obtenção de senhas bancárias e coleta de hábitos de navegação
3
worms são programas que podem se propagar de um sistema para outro através de uma rede de computadores
sem usar um arquivo hospedeiro.
12
Figura 1 – Total de incidentes reportados ao CERT.br por ano.
Uma análise do gráfico da Figura 1 mostra que o número de incidentes tem aumentado muito
nos últimos anos, sendo que em 2006 esse número quase triplicou. Esse fato evidencia a
necessidade do aumento dos investimentos feitos em segurança de redes.
13
1.1 - MOTIVAÇÃO
Como visto anteriormente, o acesso irrestrito à Internet pode trazer prejuízos, principalmente
no âmbito de empresas. No entanto, existem soluções que podem minimizar ou até mesmo
solucionar este problema. Por exemplo, quando se tem um servidor que controla o acesso à
Internet, os computadores da rede local não precisam ter nenhuma forma de acesso direto à
rede mundial de computadores. Dessa forma, podem-se concentrar os esforços de segurança e
administração dos acessos externos nesse mesmo servidor.
Além disso, com esse controle centralizado, podem-se criar regras avançadas de restrição de
acesso, podendo definir que determinados computadores ou usuários poderão ter acesso
irrestrito. Outros poderão acessar apenas um determinado conjunto de sites. É possível
restringir um determinado conjunto de sites cuja URL4 possua uma determinada palavra ou
expressão regular. Estas regras podem variar de acordo com o horário, permitindo a criação
de regras que restrinjam o tráfego no horário de expediente e liberem nos horários de menor
demanda.
A necessidade de controlar o acesso à Internet proveniente da rede interna com o objetivo de
aumentar a produtividade da empresa e de diminuir os riscos associados ao acesso irrestrito à
rede mundial de computadores motivou a implementação desta solução baseada em software
livre
1.2 OBJETIVOS
O objetivo deste trabalho é propor uma solução de controle de acesso à Internet através da
utilização de softwares específicos, bem como a construção de um conjunto de regras
hierárquicas para controlar esse acesso de forma eficaz.
4
URL (Uniform Resource Locator) é o endereço de um recurso ou arquivo disponível na Internet
14
1.3 METODOLOGIA
Para a elaboração desse trabalho foi feita uma revisão bibliográfica aprofundada sobre o
software “squid”, que implementa o serviço de Proxy5 em uma rede de computadores. Em
seguida foi feito um estudo sobre os mecanismos existentes de controle de acesso, com ênfase
na “ACL” – Access Control List. Com isso, foi possível criar um conjunto de regras e
organizá-las de forma hierárquica.
Também foi analisada a utilização do software DansGuardian, de análise de conteúdo de
páginas web, e definido um conjunto de configurações básicas para seu funcionamento
adequado. O objetivo desta análise é detectar o assunto sobre o qual trata a página de Internet
solicitada, e classificar se a mesma é compatível com a política da organização.
Finalmente, foi exposta a forma adequada de se configurar e utilizar o software Sarg de
análise de logs6 do squid, de forma a se obter relatórios, claros e objetivos, de acesso à
Internet.
Com o desenvolvimento destas etapas foi possível encontrar uma solução para garantir um
acesso eficaz e ao mesmo tempo seguro à Internet.
1.4 ORGANIZAÇÃO DO TRABALHO
Esse trabalho segue a seguinte organização:
Capítulo 2 – Conceitos Básicos - Apresenta alguns conceitos necessários para entender o
funcionamento do Proxy na realização do controle de acesso à Internet. São apresentados os
conceitos de proxy, mecanismos de controle de acesso e filtro de conteúdo, controlador de
domínio e autenticação de usuário.
5
Proxy é um software que centraliza o acesso de todas as estações de uma rede à Internet, podendo assim
realizar várias tarefas como: armazenar localmente cópias das páginas mais acessadas para economizar banda;
normatizar o acesso por horário, usuário e tipo de página acessada, entre outras possibilidades.
6
Log é um arquivo que guarda informações passadas (registros). Existem registros/logs de erros, páginas
visitadas (”Histórico”), entre outros, que podem ajudar na identificação e solução de problemas
15
Capítulo 3 – Controle de acesso no Squid – Apresenta como é feito o controle de acesso no
software squid, detalhando a forma de construção e os tipos de ACL’s que serão utilizados na
solução apresentada. Apresenta também o funcionamento das regras de acesso e como elas
devem ser estruturadas.
Capítulo 4 – Implementação do controle de acesso no Squid – Apresenta detalhes da
implementação de uma solução que busca ser eficaz no controle de acesso no Squid, através
da definição das ACL´s e de uma hierarquização de regras.
Capítulo 5 – Configurando o filtro de conteúdo do Dansguardian – Apresenta a configuração
do software Dansguardian, que trabalha em conjunto com o Squid, realizando um filtro de
conteúdo nas páginas acessadas.
Capítulo 6 - Implementando a análise de logs Via Sarg – Apresenta a implementação de uma
ferramenta para analisar os logs do Squid de forma a fornecer um conjunto de relatórios
administrativos sobre a utilização da Internet.
Capítulo 7 - Considerações finais e trabalhos futuros – apresenta as considerações finais sobre
o trabalho e propostas de continuidade ao trabalho proposto.
Capítulo 8 - Referências Bibliográficas – Referências bibliográficas utilizadas na elaboração
do trabalho.
16
2 – CONCEITOS BÁSICOS DE PROXY
Este capítulo apresenta alguns conceitos que são necessários para que se possa entender a
proposta deste trabalho em apresentar uma solução para o controle de acesso à Internet,
centralizado em um servidor de rede.
O proxy tem a função de concentrar todas as requisições das mais diversas origens,
canalizando-as por uma mesma saída. Ele é que, efetivamente, faz a requisição ao destino.
Funciona como um intermediário entre o cliente e o servidor de destino. Esse intermediário
efetua tais requisições segundo regras, ou filtros, implementados pela ferramenta de proxy.
Tais filtros têm a função de proibir ou liberar acessos a sites, endereços identificadores de
máquinas e redes, strings e até limitar velocidade de acesso. Além disso, são capazes de coibir
o acesso através de regras que atuam sobre os clientes da rede interna: nomes de usuários,
grupos de usuários, endereços identificadores de máquinas etc.
Outra função bastante usual no proxy é o serviço de cache, na qual as páginas acessadas ficam
armazenadas em uma memória temporária, de forma que se houver um novo acesso à mesma
informação, o proxy fornecerá ao cliente a informação já armazenada, dispensando um novo
acesso aos servidores, com conseqüente redução no tempo de resposta. O serviço de cache
tem esse propósito: ganho de performance.
Soluções presentes no mercado contemplam a utilização dos serviços de proxy e cache juntos,
sendo que o tratamento da informação entre tais serviços é realizado automaticamente pela
aplicação sem a necessidade de intervenção do administrador.
A figura 2 mostra o esquema de funcionamento de um sistema de acesso à Internet baseado
em proxy.
17
Figura 2 – O serviço de Proxy
2.1 CONTROLE DE ACESSO
Para controlar, efetivamente, o acesso à Internet, são utilizadas várias ferramentas que
permitem identificar que usuário e/ou máquina da rede acessou determinado site em
determinada data e hora, gerando, assim, informações que podem ser utilizadas pela
gerência para tomar as devidas providências.
Os Mecanismos de Controle de Acesso se propõem a definir que usuários ou processos têm
acesso a que recursos do Sistema Computacional, e com que permissões. Estes mecanismos
podem ser aplicados em qualquer nível, desde a aplicação, definindo os acessos dos
usuários, dos processos e suas respectivas páginas de memória.
A próxima seção mostra os principais modelos de mecanismos de controle de acesso que
são utilizados para prevenir os acessos indevidos por usuários não autorizados.
18
2.1.1 Access Control List
O Access Control List, ou simplesmente ACL, é o mecanismo onde é criada uma lista para
cada objeto (recurso do sistema), com a identificação do usuário ou processo, e suas
permissões para aquele objeto especifico. A ACL é dito um mecanismo orientado a objeto.
As ACL’s tornam-se sobrecarregadas de forma gradativa à medida que a quantidade de
recursos compartilhados de um sistema aumenta. Por isso, é comum o agrupamento de
usuários de acordo com o seu perfil funcional. No entanto, isso representa uma
flexibilização perigosa no mecanismo de controle de acesso.
2.1.2 Capabilities
Este mecanismo, ao contrário da ACL, cria uma lista para cada usuário ou processo com a
identificação do objeto, e as permissões que o usuário ou processo possui sobre este objeto
específico. Este mecanismo é conhecido como orientado a usuário.
Este mecanismo resolve o problema da sobrecarga das ACL’s, tendo em vista que cada
usuário ou processo possui uma lista com as Capabilities somente para os objetos
compartilhados nos quais têm algum tipo de permissão de acesso.
2.1.3 Access Control Matriz
O Access Control Matriz, ou ACM, é o somatório dos dois mecanismos anteriores
formando uma estrutura equivalente a uma matriz, onde as linhas são compostas pelos
usuários, as colunas por objetos e os elementos são listas de permissões. Cada coluna de
uma ACM é uma ACL e cada linha é uma Capability.
19
2.2 FILTRO DE CONTEÚDO
O serviço de Proxy funciona muito bem para atender às necessidades para as quais foi criado:
intermediar requisições de clientes com destino a servidores na Internet, além de efetuar
filtros baseados em listas de controle de acesso capazes de bloquear o acesso a determinados
sítios.
Contudo, no que diz respeito à proibição de acesso a sítios na Internet, a capacidade de proibir
o acesso de acordo com o conteúdo de cada página acessada não pode ser implementada
exclusivamente através de servidores proxies. Tal necessidade é suprida por ferramentas
conhecidas como “filtros de conteúdo”.
Essas ferramentas percorrem cada página acessada antes de disponibilizá-la ao usuário e
efetuam uma verificação de termos, palavras e frases consideradas inadequadas, segundo a
base de dados de tais conteúdos. A maioria dessas aplicações permite ao administrador
informar dentre o conteúdo dessas listas, o que efetivamente será considerado termo indevido,
além de permitir acréscimo de conteúdo a serem bloqueados.
Segundo "Internet Filtering Alternatives White Paper" (SOFTWARE, 2003), os filtros de
conteúdo podem ser divididos nos seguintes tipos:
Appliances dedicados à filtragem : esta categoria inclui dispositivos especificamente
projetados para controle e monitoração do acesso à Internet;
Servidores pré-configurados para filtragem: esta categoria inclui soluções onde os
equipamentos servidores de propósito geral são configurados de fábrica com aplicação de
filtragem de conteúdo;
Aplicação de filtragem baseada em servidor: esta categoria inclui programas que trabalham
com sistemas operacionais em plataforma Windows NT ou Unix, ou como um plugin para
aplicações de servidores proxy;
20
Addons para serviço de filtragem nos firewalls7: serviços que podem ser adicionados ao
firewall ou a outros dispositivos de rede;
Aplicação de filtragem baseada no cliente: esta categoria inclui aplicações para Windows e
Macintosh e plugins de navegadores que são adicionados a tais características no computador
do usuário.
De uma forma mais específica, pode-se definir o filtro de conteúdo baseado em pesos com
uma nova categoria. Assim, é possível informar à aplicação que o simples aparecimento de
uma determinada palavra em um sítio não é suficiente para bloqueá-lo. No entanto, um outro
termo pode ser considerado indevido pelo fato de aparecer várias vezes no mesmo sítio.
2.3 CONTROLADOR DE DOMÍNIO
O uso de redes de computadores em ambientes de trabalho tem aumentado a cada dia. Isto é
facilmente percebido ao se analisar pequenas empresas que não têm a informática como área
fim. Essas empresas, que até bem pouco tempo utilizavam-se de máquinas de datilografia,
renderam-se à tecnologia. E, hoje, é muito difícil uma micro-empresa que não faça uso de
computadores no seu dia-a-dia.
Mesmo em ambientes mais restritos, com poucos computadores, tem-se percebido que a
utilização de redes ponto-a-ponto não se adequa muito bem, uma vez que as informações
associadas às atividades da empresa não estão localizadas em um ponto central, com todos os
cuidados necessários: backup das informações, controle de acesso, garantia de
disponibilidade, dentre outros.
A fim de prover um ambiente de rede mais adequado às atividades da corporação, além de
equipamentos servidores que mantenham a guarda das informações, faz-se necessário a
implementação de uma outra solução capaz de autorizar e autenticar os funcionários na rede
privativa da instituição: o controlador de domínio.
7
Firewall é o nome dado ao dispositivo de uma rede de computadores que tem por função regular o tráfego entre
redes distintas e impedir a transmissão e recepção de dados nocivos ou não autorizados de uma rede a outra.
21
A garantia de acesso dos usuários ao ambiente de rede da empresa permitirá associar as ações
realizadas na rede ao usuário que efetivamente a executou, sendo esse também o papel do
controlador de domínio.
Existem algumas soluções de controladores de domínio disponíveis no mercado. A maioria
delas é proprietária. Contudo, soluções baseadas em software livre também estão disponíveis
para uso e serão consideradas neste trabalho.
2.4 AUTENTICAÇÃO DE USUÁRIOS
A fim de obter acesso a uma rede, o usuário solicita sua autenticação informando nome na
rede e a senha de acesso. O sistema efetua a autenticação verificando se o nome de usuário e a
senha informada estão realmente associados àquele usuário específico e se estão corretos.
Quando um usuário obtém acesso à rede, isso significa que ele foi autenticado.
Porém, inúmeras aplicações utilizam-se do conceito de autenticação de usuários para seu
funcionamento. Algumas delas utilizam módulos adicionais para efetivar a autenticação
através de diferentes protocolos como Kerberos, LDAP e NTLM. Outras aplicações apenas
validam a autenticação efetuada anteriormente garantindo os acessos do usuário.
Para que a validação do usuário autenticado funcione a contento, algumas ferramentas
adicionais devem ser implementadas, algumas na própria aplicação e outras nos servidores
que executam as aplicações.
As redes em funcionamento nas instituições, atualmente, já implementam um esquema de
autenticação de usuários, quer seja em controladores de domínios proprietários, quer baseados
em software livre. Tais esquemas de autenticação devem ser incorporados a esta solução de
controle de acesso à Internet, fazendo, assim, a validação da autenticação do usuário. Vários
esquemas de autenticação são suportados pelas ferramentas utilizadas, dentre os quais podemse destacar: LDAP, NTLM, PAM, SMB e winbind.
22
3 – O MECANISMO DE CONTROLE DE ACESSO NO SQUID
Uma das melhores formas para se controlar o acesso à Internet é através da utilização de um
programa de proxy. Dentre os diversos proxies disponíveis no mercado, um dos mais
utilizados em todo o mundo é o Squid, que é um software livre e possui versões para
diferentes distribuições linux. Além disso, se destaca seu excelente desempenho e grande
flexibilidade de configuração.
O Squid tem um eficiente mecanismo de controle de acesso à Internet. Este mecanismo
permite a criação de listas capazes de filtrar desde simples domínios até tipos de conteúdos
específicos (myme types). Este controle é feito por ACL´s que são inseridas dentro do arquivo
/etc/squid/squid.conf.
As ACL's - (Access Control Lists) ou listas de controle de acesso, constituem-se na grande
flexibilidade e eficiência do Squid. É através delas que se podem criar regras para controlar o
acesso à Internet das mais diferentes formas. Praticamente todo o processo de controle do
Squid é feito com o seu uso.
O uso das listas de controle de acesso é a parte mais importante da configuração de um
servidor proxy Squid, pois se bem configuradas podem trazer um nível de segurança muito
bom para a rede. Entretanto se mal configuradas podem ter o resultado oposto, já que além da
falsa sensação de segurança não será aproveitada a principal funcionalidade do Squid.
As ACL's são definidas da seguinte forma:
acl nome tipo string | “arquivo”
onde:
-
acl é a palavra chave que identifica uma acl;
-
nome é o identificador único de cada acl;
-
tipo é a funcionalidade da acl;
-
string é um conjunto de palavras que farão parte do grupo definido pela acl;
-
arquivo é o endereço de um arquivo que conterá as palavras que farão parte do grupo
definido pela acl.
23
Existem vários tipos de ACL que podem ser utilizadas. A seguir serão detalhados os tipos
utilizados na proposta desse trabalho.
src - tipo utilizado para indicar endereços IP de origem. Pode-se especificar um endereço de
rede, como 192.168.16.0/24, um endereço de um determinado host, como 192.168.16.10/24
ou uma faixa de endereços, como 192.168.16.10-192.168.16.20/24;
dst - semelhante ao tipo anterior, mas está relacionada ao endereço de destino;
time - usado para especificar dias da semana e horários. Os dias da semana são definidos
através de letras que os representam, e os horários através de intervalos na forma
hora:minuto_inicial-hora:minuto_final. Os dias da semana são especificados assim: S Sunday (Domingo), M - Monday (Segunda-Feira), T - Tuesday (Terça-Feira), W Wednesday (Quarta-Feira), H - Thursday (Quinta-Feira), F - Friday (Sexta-Feira) e A Saturday (Sábado);
url_regex - Este tipo percorre a URL a procura da expressão regular especificada. Deve ser
observado que a expressão é case-sensitive, para que seja case-insensitive deve ser usada a
opção -i. É o tipo mais comum de ACL dada a flexibilidade proporcionada pelo uso de
expressões regulares;
urpath_regex - Tipo semelhante a url_regex, mas procura a expressão regular na URL sem
levar em conta o nome do servidor e o protocolo, isto quer dizer que a procura vai ser feita
apenas na parte da URL após o nome do servidor, como por exemplo, na URL
http://www.servidor.com.br/pasta/sexo.html a procura será realizada apenas na parte
/pasta/sexo.html. Ela é também case-sensitive, para que seja case-insensitive deve ser usada a
opção -i;
port - Realiza o controle pela porta de destino do servidor, neste tipo deve ser especificado o
número da porta;
proto - Serve para especificar o protocolo, como por exemplo FTP ou HTTP;
24
method - Especifica o tipo de método usado na requisição, como por exemplo GET,
CONNECT ou POST;
auth_param basic – Especifica o método a ser utilizado pelo squid caso este execute algum
tipo de autenticação externa em algum servidor LDAP, AD, entre outros. Nesse trabalho o
tipo de autenticação em um servidor AD através do programa msnt_auth.
proxy_auth - Tipo usado para implementar autenticação de usuários no proxy. A autenticação
é feita com uso de softwares externos. Pode ser passado o nome dos usuários ou usada a
opção REQUIRED para que seja autenticado qualquer usuário válido;
Se as ACLs do Squid são as listas de definições do squid, os operadores HTTP_ACCESS são
as correlações entre estas ACLs, que resultarão na liberação ou no bloqueio de acessos.
Existem diversos outros operadores, no entanto, como estes são os mais importantes, apenas
eles serão detalhados no texto.
A ordenação lógica das HTTP_ACCESS é a chave para que o Squid funcione de modo
confiável e seguro. Dessa forma, sua ordenação de maneira ilógica poderá trazer resultados
indesejados como bloqueios não necessários, ou pior, liberação de acessos inapropriados.
Para entender como ordenar as HTTP_ACCESS faz-se necessário primeiramente
compreender seu funcionamento. Sua estrutura geral é:
http_access allow | deny acl1 acl2 acl3 ...
O Squid faz a análise destas ACLs mediante as seguintes regras:
1. As regras são lidas “de cima para baixo”, ou “da primeira para a última”;
2. Uma vez que uma regra for atendida não haverá a analise das demais, não havendo
possibilidade de utilização de case ou if para redirecionar o Squid de uma regra para outra em
hipótese de atendimento de uma delas;
25
3. As regras são “case sensitive”, assim uma simples diferença entre minúsculas e
maiúsculas poderá anular a regra, pois não mais irão coincidir. A utilização da opção –i
contorna esta questão;
4. Caso nenhuma regra seja atendida, o Squid utilizará como regra geral o inverso da última
regra, assim, se nenhuma regra for atendida e a última regra for permitida (allow) o Squid
procederá a um acesso negado (deny) e vice versa.
Como resultado da aplicação das quatro regras acima, pode-se afirmar que numa ordenação
lógica do Squid as ACLs constantes de uma mesma regra serão tratadas entre si com um and e
as próprias regras serão tratadas entre si com um or, terminando com um else do inverso da
última expressão. Pode-se tomar com exemplo as regras abaixo:
http_access allow acl1 acl2
http_access deny acl1 acl3 acl4
Neste caso tem-se a seguinte estrutura lógica:
If (acl1 and acl2 : allow) or (acl1 and acl3 and acl4 : deny) else allow
Esta estruturação torna mais clara a forma como o Squid vai interpretar suas regras e, a partir
desta interpretação, pode-se concluir algumas normas fundamentais de ordenação das
HTTP_ACCESS:
1. As exceções deverão ser tratadas antes das regras, pois visto que as primeiras estão
sempre contidas nas segundas, caso sejam listadas as regras e depois as exceções, estas jamais
serão interpretadas;
2. Pelo mesmo motivo, caso haja uma “exceção da exceção”, esta deverá ser tratada antes da
exceção;
3. Regras específicas deverão ser tratadas antes de regras genéricas, mesmo que uma não
constitua exceção à outra;
4. Regras principais deverão ser tratadas antes de regras acessórias;
5. A menos que a política de acesso da organização diga o oposto, a última regra deverá ser
sempre de negação geral (http_access deny all) para evitar uma liberação indesejada,
conforme ocorreu no exemplo acima.
26
Vejamos, a seguir, como a inobservância das normas acima pode ocasionar os mais diversos
resultados indesejados e como proceder para evitá-los.
CASO 1 – Supondo uma organização de política restritiva de acesso à Internet onde somente
ao corpo gerencial é permitido o acesso, ficando a todos os demais funcionários negado o
mesmo. Neste caso, o arquivo de configuração do squid, o squid.conf, teria as seguintes
regras:
# define os logins dos gerentes
acl gerencia fulano beltrano cicrano
# solicita a autenticação dos usuários
acl usuarios proxy_auth REQUIRED
# regras de acesso
http_access deny usuarios
http_access allow gerência
http_access deny all
Aparentemente, a estruturação acima esta correta, pois está negando acesso a todos e
liberando a gerência. Ocorre que o grupo gerência é uma exceção do grupo de usuários.
Assim, se a regra de gerência for colocada após a regra geral dos usuários, a exceção jamais
será analisada, pois os gerentes também são autenticados, conseqüentemente, terão seu acesso
negado quando da análise da ACL de negação aos usuários.
A ordenação correta neste caso seria:
# define os logins dos gerentes
acl gerencia fulano beltrano cicrano
# solicita a autenticação dos usuários
acl usuarios proxy_auth REQUIRED
# regras de acesso
http_access allow gerência
27
http_access deny usuarios
http_access deny all
CASO 2 – Supondo uma organização cuja política libera o acesso aos sites das editoras de
revistas mais conceituadas, mas impede o acesso a qualquer site de conteúdo pornográfico.
Seu squid.conf poderia estar configurado da seguinte forma:
# define o arquivo que nomina os domínios das editoras liberadas
acl editoras url_regex –i “/etc/squid/bloqueios/editoras.domains”
# define o arquivo que nomina os domínios pornôs bloqueados
acl porno url_regex –i “/etc/squid/bloqueios/porno.domains”
# solicita a autenticação dos usuários
acl usuarios proxy_auth REQUIRED
# regras de acesso
http_access allow editoras
http_access deny porno
http_access deny all
Note que, neste caso, a regra de bloqueio de material pornográfico não constitui exatamente
uma exceção da regra de liberação dos sites de editoras. Porém, o fato é que existem sites de
revistas pornográficas dentro de sites de editoras conceituadas. Neste caso, se configurado
conforme acima, tais revistas pornográficas teriam seu acesso liberado, o que não é o objetivo
da organização. A regra de bloqueio de pornografia deve se sobrepor à de liberação de
editoras por ser mais primordial e, assim, deve ser listada antes.
A ordenação correta neste caso seria:
# define o arquivo que nomina os domínios das editoras liberadas
acl editoras url_regex –i “/etc/squid/bloqueios/editoras.domains”
# define o arquivo que nomina os domínios pornôs bloqueados
28
acl porno url_regex –i “/etc/squid/bloqueios/porno.domains”
# solicita a autenticação dos usuários
acl usuarios proxy_auth REQUIRED
# regras de acesso
http_access deny porno
http_access allow editoras
http_access deny all
CASO 3 – Supondo uma organização cuja política libera o acesso de determinados
funcionários e nega o de outros, conforme sua posição função dentro da organização. Seu
squid.conf poderia estar configurado da seguinte forma:
# define o arquivo que nomina os logins dos usuários liberados
acl liberados url_regex –i “/etc/squid/bloqueios/liberados.domains”
# define o arquivo que nomina os logins dos usuários bloqueados
acl bloqueados url_regex –i “/etc/squid/bloqueios/bloqueados.domains”
# solicita a autenticação dos usuários
acl usuarios proxy_auth REQUIRED
# regras de acesso
http_access allow liberados
http_access deny bloqueados
No caso acima, as regras aparentam estar corretas. Entretanto, numa situação onde um
funcionário recém contratado, cujo acesso não deveria ser liberado, por um erro qualquer, não
tiver seu nome incluído na lista de bloqueados, terá seu acesso liberado, pois nenhuma das
regras previstas casou com seu login. Como nenhuma regra foi cumprida, será utilizado o
inverso da última regra, que no caso é um deny. Sendo assim, este terá seu acesso liberado.
29
Para corrigir a situação acima, basta acrescentar ao final da lista de regras a seguinte regra:
http_access deny all
No próximo capítulo, é apresentado um exemplo de um arquivo de configuração squid
devidamente estruturado.
30
4 – PROPOSTA DE IMPLEMENTAÇÃO DE CONTROLE DE ACESSO
NO SQUID
Após um estudo detalhado das ACL’s e das regras de acesso existentes, este capítulo propõe
uma solução no controle eficaz de acesso à Internet. O primeiro passo na metodologia criada é
definir suas ACL´s.
4.1 – CRIAÇÃO DAS ACL’S
A seguir, será apresentado um conjunto de ACL´s necessárias para que o Squid efetue um
controle efetivo de acesso à Internet.
4.1.1 ACL´s referentes à autenticação
● acl autentica proxy_auth REQUIRED
Informa que será exigida autenticação para qualquer usuário válido.
•
auth_param basic program /usr/lib/squid/msnt_auth
Informa o qual o cominho do programa externo que efetuará a autenticação no Active
Directory.
•
auth_param basic realm Bem Vindo ao Servidor Proxy da Rede Local
Informa o cabeçalho da tela de solicitação de login e senha a ser solicitada.
•
auth_param basic children 5
Informa a quantidade de subprocessos de autenticação que poderão ser abertos
simultaneamente.
•
auth_param basic credentitalsttl 15 minute
Informa o tempo de checagem das credenciais do usuário junto ao servidor.
31
4.1.2 ACL´s padrões do squid, criadas durante a instalação e utilizadas para
regras de segurança.
● acl all src 0.0.0.0/0.0.0.0
Identifica todos os endereços ip
● acl localhost src 127.0.0.1/255.255.255.255
Identifica o computador local, no caso o computador onde o proxy está instalado.
● acl Safe_ports port 80 81 21 443 563 70 85 210 1022 1021 1025-65535
Identifica as portas consideradas seguras que poderão ser acessadas pelo proxy.
4.1.3 ACL´s com os grupos de usuários com acessos especiais
● acl gerencia proxy_auth gerente1 gerente2
Define o grupo de gerentes que terão acesso irrestrito aos sites. Este grupo é fundamental para
que os administradores de rede possam realizar o controle de quais sites poderão ou não ser
acessados.
● acl coordenacao proxy_auth coordenador1 coordenador2 coordenador3
Define o grupo de usuários que terão acesso a alguns sites específicos que poderão estar
bloqueados para os demais usuários em horários específicos.
● acl estagiarios proxy_auth estagiario, estagiario2
Define o grupo de funcionários que terão acesso em horário especial, ou seja, acessarão a
Internet num horário fora do horário padrão.
● acl banidos proxy_auth banido1 banido2 banido3
Define o grupo de usuários que não terão acesso a Internet.
32
4.1.4 ACL´s com os grupos que identificam as redes existentes
● acl RedePrincipal src 10.14.0.0/255.255.0.0
Define a faixa de endereçamento IP da rede principal.
● acl RedeRemota src 10.127.0.0/255.255.0.0
Define a faixa de endereçamento IP de uma remota que também poderá usar o proxy para
acesso à Internet.
● acl RedePrincial-Remota src 10.14.0.0/255.255.0.0 10.127.0.0/255.255.0.0
Define a faixa de endereçamento IP da rede principal e da rede remota.
4.1.5 ACL´s com os grupos de máquinas com acessos específicos
● acl MaqLibEspecificos src 10.14.27.118/255.255.255.255 10.14.27.119/ 255.255.255.255
Define o grupo de máquinas que terão acesso a sites específicos.
●acl
MaqServidores
src
10.14.1.4/255.255.255.255
10.14.1.5/255.255.255.255
10.14.1.6/255.255.255.255
Define o grupo de máquinas que terão acesso irrestrito à Internet (Servidores de rede).
● acl MaqIpbloq src 10.14.12.103/255.255.255.255 10.14.26.110/255.255.255.255
Define o grupo de máquinas que terão acesso bloqueado pelo IP.
4.1.6 ACL´s com os grupos de Horários de Acesso
● acl Hora_Expediente time MTWHF 12:00-20:00
Define o horário em que normalmente é permito o acesso à Internet (Neste caso de segunda à
sexta de 12:00hs às 20:00hs).
33
● acl Hora_Total time SMTWHFA 00:00-23:59
Define o horário em que é permito o acesso além do horário de expediente normal da
empresa.
● acl Hora_Rush time MTWHF 13:00-17:00
Define o horário de bloqueio dos sites que possuem um grande número de acessos e que não
são essenciais (Grandes Portais, etc).
● acl Hora_Especial time MTWHF 07:00-13:00
Define o horário em que é permitido o acesso para funcionários que trabalham em um período
especial, ou seja, um período diferente do horário de expediente padrão..
4.1.7 ACL´s com os grupos de arquivos
● acl Sites Informacoes url_regex "/etc/squid/bloqueios-squid/informacoes-domains"
Define o arquivo com palavras que identifiquem o endereço de sites que possuam um número
elevado de acessos e que não são essenciais ao trabalho da empresa.
● acl SitesAdultos url_regex "/etc/squid/bloqueios-squid/adultos-domains"
Define o arquivo com palavras que identifiquem os endereços de sites com conteúdo adulto
ou inapropriado.
● acl SitesLiberados url_regex "/etc/squid/bloqueios-squid/liberados-domains"
Define o arquivo com palavras que identifiquem os endereços de sites que serão liberados a
todos os usuários.
● acl SitesEspecificos url_regex "/etc/squid/bloqueios-squid/especificos-domains"
Define o arquivo com palavras que identifiquem os endereços de sites liberados a um grupo
de usuários específicos.
34
● acl SitesTemporarios url_regex "/etc/squid/bloqueios-squid/temporarios-domains"
Define o arquivo com palavras que identifiquem os endereços de sites liberados
temporariamente para todos os usuários.
● acl SitesNegadownload urlpath_regex -i "/etc/squid/negadownload”
Define extensões de tipos de arquivos que deverão ser bloqueados para download.
O arquivo deverá ter a seguinte estrutura:
\.mp3$
\.exe$
\.mpg$
\.avi$
Note que a barra que precede a extensão do arquivo não faz parte do nome real do mesmo.
Entretanto, tal precaução se faz necessária visto que o ponto é entendido pelo Squid como
sendo um metacaracter, e a utilização da barra força sua interpretação de modo literal.
4.1.8 ACL´s com os grupos de Domínios Locais
● acl DominiosLocais dst 10.14.0.0/255.255.0.0
Define os endereços que serão acessados sem utilização do proxy.
4.2 CRIAÇÃO DAS REGRAS DE ACESSO
A seguir, será definido o conjunto de regras de acesso que utilizarão as ACL’s criadas
anteriormente. Note que a hierarquização definida abaixo é o item mais importante para o
controle correto do que pode ser acessado.
4.2.1 – Regras de Segurança padrão do Squid
São regras que deverão preceder as regras de bloqueio principal.
35
● http_access allow manager localhost
Permite acesso ao “cache” ao computador local (proxy).
● http_access deny !Safe_ports
Impede a utilização de portas não seguras.
4.2.2 – Regra de redirecionamento dos acessos a sites internos
Determina que os acessos a sites localizados na rede local não utilizem o proxy, o acesso será
direto e sem autenticação.
● always_direct allow DominiosLocais.
4.2.3 Regras de bloqueios prioritárias.
Devem ser obrigatoriamente definidas antes de qualquer regra de liberação que não sejam as
regras de segurança do Squid e a regra de redirecionamento dos sites da rede interna. São
regras que não possuem exceções.
● http_access deny !RedePrincipal
Nega o acesso à Internet aos endereços ip´s que não estão definidos na ACL “RedePricipal”.
● http_access deny banidos
Impede o acesso dos usuários que estão definidos na ACL “Banidos”.
● http_access deny MaqIpbloq
Impede o acesso dos computadores cujos ip´s estão definidos na ACL “MaqIpbloq”.
36
4.2.4 – Regras de liberações específicas
São regras que devem preceder as regras normais de bloqueio, pois são exceções a estas
regras. Porém, estas regras devem ser obrigatoriamente definidas após as regras de bloqueio
prioritárias.
● http_access allow MaqServidores
Libera totalmente o acesso dos computadores cujos ip´s estão definidos na ACL
“MaqServidores” para permitir que os servidores de rede tenham acesso a todos os sites da
Internet em todos os horários.
● http_access allow MaqLibEspecificos SitesEspecificos Hora_Expediente
Libera os ip´s das máquinas, definidos na ACL “MaqLibEspecificos” para acessar os sites
cujos endereços contenham palavras listadas no arquivo definido na ACL “SitesEspecificos”
no horário definido na ACL “Hora_Expediente”.
● http_access allow Liberados Hora_Expediente
Libera o acesso a todos os sites cujos endereços contenham palavras listadas no arquivo
definido na ACL “SitesLiberados” horário definido na ACL “Hora_Expediente” para todos
os usuários.
● http_access allow gerencia
Libera o acesso a todos os sites para o grupo gerencia em qualquer horário.
● http_access allow SitesCoordenacao coordenacao
Libera o acesso aos sites cujos endereços contenham palavras listadas no arquivo do grupo
“SitesCoordenacao” para os usuários do grupo “coordenação” em qualquer horário
● http_access allow !SitesAdultos Hora_Especial estagiarios
Libera o acesso ao sites cujos endereços não contenham palavras listadas no arquivo definido
na ACL “SitesAdultos” no horário definido na ACL “Hora_Especial” a todos os usuários
definidos na ACL “estagiarios”. Se fosse o caso de liberar somente um conjunto de sites,
37
substituiria-se “!adultos” por uma ACL que representasse um arquivo com os sites específicos
que se desejaria liberar.
4.2.5 Regras gerais de bloqueios
Estas são as regras de bloqueio que serão aplicadas em todos os casos que não estejam
definidos anteriormente nas regras de liberação específicas. Em geral, aqui são definidas as
principais regras da sua empresa.
● http_access deny !Hora_Expediente
Restringe o horário de acesso à Internet ao horário definido na ACL “Hora_Expediente”.
● http_access deny SitesAdultos
Bloqueia o acesso aos sites cujos endereços contenham palavras listadas no arquivo do grupo
“Adultos” em todos os horários.
● http_access deny SitesInformacoes Hora_Rush
Bloqueia o acesso a todos os sites cujos endereços contenham palavras listadas no arquivo
definido na ACL “Informacoes” no horário definido na ACL “Hora_Rush”.
● http_access deny SitesNegadownload
Bloqueia o download de todos os arquivos cujas extensões estejam listadas no arquivo
definido na ACL “SitesNegadownload” em todos os horários.
4.2.6 Regra de liberação geral
● http_access allow autentica
Permite o acesso a todos os sites não bloqueados anteriormente a todas as máquinas mediante
autenticação. Esta regra é necessária para que acessos não bloqueados anteriormente possam
ser liberados a todos os usuários autenticados.
38
4.2.7 Regras de bloqueio total.
● http_access deny all
Bloqueia todos os outros casos não previstos anteriormente. Bloqueia qualquer acesso que não
tenha sido liberado nas regras anteriores.
39
5
–
CONFIGURAÇÃO
DO
FILTRO
DE
CONTEÚDO
NO
DANSGUARDIAN
O Dansguardian é um programa desenvolvido independentemente, destinado a trabalhar junto
com o Squid, implementando um filtro de conteúdo das páginas acessadas com o objetivo de
aumentar a segurança no controle de acesso à Internet.
O DansGuardian trabalha sobre o Squid, implementando suas políticas de acesso, mas
deixando que o próprio Squid faça o acesso à Internet, cache e autenticação. Ele inclui um
conjunto de regras prontas, que contém palavras, frases e tipos de arquivos freqüentemente
usados neste tipo de página e endereços de páginas conhecidas. Cruzando estas informações
ele consegue fazer um excelente trabalho, bloqueando quase todas as páginas indesejadas, em
várias línguas, com relativamente poucos falso-positivos. Ele difere da maioria das
ferramentas disponível no mercado pelo fato de não funcionar apenas como filtro de URL,
mas também como um efetivo filtro de conteúdos de páginas web, pois faz uma varredura do
conteúdo de cada página acessada por seus usuários e não somente uma liberação ou
proibição do nome do site ou da URL acessada. Este filtro de conteúdo não tem características
de Proxy, portanto, é obrigatório o uso de um servidor Proxy para que a ferramenta seja
implementada, podendo ser instalado em sistemas operacionais Linux, FreeBSD, OpenBSD,
NetBSD, Mac OS X, HP-UX, e Solaris
Na solução proposta o filtro de conteúdo receberá as requisições do navegador do usuário,
aplicará as restrições estabelecidas ou as exceções configuradas e, em seguida, passará a
requisição para o Proxy, conforme a Figura 3.
Figura 3 - Fluxo da requisição do cliente via Filtro de Conteúdo.
40
A integração do proxy com o filtro de conteúdo requer o uso de algumas configurações
avançadas do Squid como citado a seguir:
● http_access allow localhost
Permite o acesso do Dansguardian sem autenticação.
● always_direct allow localhost
Permite que as requisições vindas do Dansguardian não sejam reencaminhadas a ele.
O principal arquivo de configuração é o "/etc/dansguardian/dansguardian.conf". Algumas
opções devem ser verificadas após a instalação da ferramenta para o correto funcionamento
do Dansguardian . São elas:
● # UNCONFIGURED
Esta linha deve ficar comentada, indicando que o arquivo já foi configurado por você.
● language = 'portuguese'
Esta opção configura a língua em que as mensagens de acesso bloqueado serão mostradas aos
clientes.
● loglocation = '/var/log/dansguardian/access.log'
Aqui é a localização do arquivo de log do dansguardian, onde ficam armazenados os
endereços das páginas cujo acesso foi bloqueado. Serve tanto para verificar a eficiência do
filtro quanto para identificar falsos-positivos, ou seja, páginas legítimas que estão sendo
bloqueadas por engano.
● filterport = 8080
Identifica a porta onde o DansGuardian fica ativo. Ele sempre deve utilizar uma porta
diferente do Squid, pois são duas coisas separadas. O padrão é a porta 8080.
● proxyip = 127.0.0.1
Identifica o endereço IP do servidor proxy que será usado. Por padrão, ele vai utilizar uma
cópia do Squid ativa na mesma máquina, mas é possível utilizar outro servidor Squid
disponível na rede.
41
● proxyport = 3128
Identifica porta TCP onde o servidor Squid especificado na opção acima está ativo. Lembrese de que, por padrão, o Squid usa a porta 3128.
A filtragem de páginas funciona em dois níveis. Ao receber a requisição do cliente, o
DansGuardian verifica se o endereço a ser acesso está em uma das listas de URL´s ou IP’s
proibidos. Caso esteja, o cliente recebe a mensagem de erro e o acesso sequer é feito,
economizando banda. Se não existir nenhum bloqueio relacionado, a requisição é enviada ao
Squid e o acesso é realizado. Ao receber os arquivos da página, o DansGuardian verifica o
conteúdo da página, em busca de expressões e palavras "ruins", freqüentemente encontradas
em páginas indesejadas, e também palavras "boas", normalmente encontradas em páginas de
bom conteúdo. Cada termo, frase, site ou URL tem um peso associado e o bloqueio pode
ocorrer devido a soma dos pesos encontrados. Vale lembrar que existem pesos com valores
positivos e negativos. Os pesos com valores positivos são somados para gerar um valor total e
implementar um filtro, enquanto os pesos com valores negativos somados diminuirão na soma
total.
Caso o resultado ultrapasse um valor pré-definido a ser tolerado, o acesso será
bloqueado. Você define um índice máximo a ser tolerado no arquivo através da opção:
● naughtynesslimit = 160
Quanto mais baixo o número, mais severa é a censura, porém mais páginas boas acabam
sendo bloqueadas por engano. Os valores recomendados pelos desenvolvedores são "60" para
crianças pequenas, "100" para pré-adolescentes e "160" para adolescentes. Para um público
adulto, onde a principal preocupação seja não bloquear páginas boas, mesmo que isso faça
com que uma ou outra página inadequada passe pelo filtro de vez em quando, você pode
arriscar "200" ou mesmo "240".
Os
arquivos
contendo
proibições
e
exceções
estão
localizados
no
diretório
"/etc/dansguardian/” e o processamento deles segue uma ordem pré-estabelecida, conforme
a Tabela 1, que mostra os principais arquivos utilizados. Assim, é importante que o
administrador conheça tal fluxo de processamento a fim de que suas configurações funcionem
a contento.
42
Ordem de Processamento
Arquivo
1
exceptioniplist
2
exceptionuserlist
3
exceptionsitelist
4
exceptionurllist
5
bannediplist
6
banneduserlist
7
bannedregexpurllist
8
bannedurllist
9
bannedsitelist
10
bannedmimetypelist
11
bannedextensionlist
12
exceptionphraselist
13
bannedphraselist
14
weightedphraselist
Figura 4 – Arquivos de Configuração do Dansguardian
O tipo de bloqueio realizado pelos arquivos abaixo podem ser feitos de forma mais detalhada
pelo Squid através da criação de ACL´s e regras de acesso, conforme foi mostrado no capítulo
anterior.
/etc/dansguardian/exceptioniplist
Este arquivo contém a lista de endereços IP que não serão filtrados pelo Dansguardian. Entre
esses endereços pode-se colocar o IP do computador do administrador de rede, para que ele
possa realizar tarefas administrativas sem nenhuma restrição.
/etc/dansguardian/exceptionuserlist
Este arquivo contém a lista de usuários que não serão filtrados no momento da requisição.
/etc/dansguardian/exceptionsitelist
Este arquivo funciona como uma “white list”, contendo uma lista de páginas que sempre são
permitidas, mesmo que sejam encontradas palavras proibidas dentro do texto.
43
/etc/dansguardian/exceptionurllist
Este arquivo contém a lista de URL's que não serão filtrados no momento da requisição.
/etc/dansguardian/bannediplist
Este arquivo contém uma lista de endereços IP's que serão bloqueados no momento da
requisição.
/etc/dansguardian/banneduserlist
Este arquivo contém uma lista de usuários que serão bloqueados no momento da requisição.
/etc/dansguardian/bannedregexpurllist
Este arquivo contém uma lista de expressões regulares que não serão permitidas na url a ser
acessada. Ele pode ser usado para restringir o download de alguns tipos de arquivos como:
proteções de telas, executáveis entre outros.
/etc/dansguardian/bannedurllist
Este arquivo contém uma lista de URL´s que deverão ser bloqueadas, permitindo que você
bloqueie partes do site e não o site inteiro. Algo interessante que pode ser encontrado neste
arquivo são diretivas como “Include </etc/ dansguardian /blacklists/adults/urls>, por exemplo,
que fazem referência a um arquivo que foi baixado da Internet contendo uma lista de URL´s
catalogados como conteúdo adulto.
/etc/dansguardian/bannedsitelist
Este arquivo contém uma lista de sites que serão bloqueados no momento da requisição.
/etc/dansguardian/bannedmimetypelist
Este arquivo contém a lista de todos os tipos mime que não devem ser carregados. O bloqueio
pelo tipo MIME do arquivo, e não pela sua extensão, é uma vantagem do Dansguardian em
relação ao Squid, pois evita que arquivos “mascarados“ possam ser acessados ou baixados.
/etc/dansguardian/bannedextensionlist
Este arquivo contém a lista de todas as extensões de arquivos que não poderão ser baixados da
web. Um exemplo típico são os arquivos com extensões “.exe” e “.com”, que podem trazer
44
algum tipo de vírus. Também seria possível bloquear o download de arquivos com extensão
“.mpg”, “.avi”, “.wav” e “.mp3”, que são relacionados a músicas ou filmes.
A parte mais importante do filtro de conteúdo realizado pelo Dansguardian pode ser definida
nos arquivos abaixo. Eles referenciam itens, palavras ou termos encontrados nas páginas que
são devolvidas pelo Squid.
/etc/dansguardian/ exceptionphraselist
Este arquivo contém a lista de “termos” que não serão filtrados nas páginas acessadas. Os
termos devem estar entre “<” e “>”. Os termos podem conter espaços e devem ser informados
em letras minúsculas.
/etc/dansguardian/ bannedphraselist
Este arquivo contém a lista de “termos” que não serão permitidas nas páginas acessadas. Os
termos também devem estar entre “<” e “>”. Deve-se ser cuidadoso no bloqueio de palavras,
pois a utilização de <game> pode por exemplo bloquear páginas que contenha a palavra
julgamento visto que a primeira esta contida na segunda, imagine agora os efeitos disto sobre
um escritório de Advocacia ou num Tribunal. Uma forma de atenuar estes problemas é
colocar espaços antes e após a palavra, neste caso < game >. Note que a palavra game será
barrada, mas a palavra julgamento não, visto que os espaços não existem dentro dela.
Entretanto, isto deixa uma pequena brecha para que sites que usem variantes como
games1000 nao sejam barrados.
/etc/dansguardian/ weightedphraselist
Este arquivo contém a lista de palavras com seus respectivos pesos a serem considerados no
momento da filtragem de conteúdo. Tanto os termos quanto os valores devem estar entre “<”
e “>”. As linhas devem ser especificadas conforme os exemplos abaixo:
<sexo><100>
<jogos><60>
<download de musica> <50>
<governo><-20>
45
Por padrão, este arquivo vem configurado com a lista de palavras em inglês, que deixam
passar muitos sites nacionais. Você pode baixar um arquivo com listas em outras línguas,
incluindo português no site abaixo:
http://dansguardian.org/downloads/grosvenor/languages.tar.gz
Após a descompactação deste arquivo, basta adicionar diretivas para utilizar os novos
arquivos. Para isso adicione as linhas abaixo nos arquivos:
.Include</etc/squid/dansguardian/languages/weightedphraselist.pornsites.portuguese>
.Include</etc/squid/dansguardian/languages/weightedphraselist.pornwords.portuguese>
Note que nesses arquivos são especificados todos os arquivos de palavras que são utilizados.
Você pode adicionar novas palavras ou editar o peso de cada uma, editando diretamente o
arquivo.
Cabe ressaltar que o algoritmo de checagem de palavras proibidas é bem inteligente, sendo
capaz de verificar códigos HTML e espaços em branco.
46
6 – IMPLEMENTAÇAO DA ANÁLISE DE LOGS VIA SARG
A utilização dos softwares anteriormente demonstrados consegue prover um nível bastante
seguro de acesso a Internet. Entretanto, nenhum acesso, por mais bem configurado que seja,
consegue eliminar completamente os acessos indevidos ou garantir que nenhum acesso lícito
seja barrado. Em função disto, faz-se necessária a instalação de algum software de análise dos
logs do Squid para que o administrador da rede possa verificar, caso a caso, se o controle está
realmente agindo de forma consistente, além de providenciar a configuração de exceções que
porventura se fizerem necessárias.
Neste trabalho, é proposto o uso do Squid Analysis Report Generator, ou SARG, que
consegue de maneira extremamente simples e eficiente gerar um conjunto de relatórios
administrativos de utilização da Internet que, ao nosso ver, consegue abranger toda a gama de
informações que se fizerem necessárias para a gerência do acesso à rede.
Vale salientar que o Sarg é um software 100% livre, genuinamente nacional e de utilização
mundial, gozando de enorme sucesso em função de suas qualidades.
Ao contrário do Squid ou do Dansguardian, o Sarg não roda como um deamon ou serviço. Na
realidade, ele constrói os relatórios toda vez que acionado, conforme os parâmetros de
configuração inseridos em seu arquivo de configuração, que por default é o squid.conf.
A Figura 4 apresenta um dos relatórios gerados pelo SARG para auxiliar no controle à
Internet.
47
Figura 5 – Relatório de acesso à Internet.
48
6.1 – CONFIGURANDO O SARG
Embora existam grandes quantidades de parâmetros a serem configurados no Sarg, somente
os principais pontos a serem configurados no arquivo de configuração do Sarg, o sarg.conf,
serão detalhados.
● language Portuguese
Configura o idioma em que os relatórios serão emitidos.
● access_log /var/log/squid/access.log
Indica o caminho onde se encontra o arquivo de logs do squid, neste caso o default.
● title “Relatório de Acesso a Internet da Empresa S/A”
Configura o título dos relatórios.
● temporary_dir /tmp
Indica o caminho onde serão trabalhados os arquivos temporários.
● output_dir/var/www/html/squid-report/dia
Indica o caminho onde serão armazenados os relatórios gerados. Como os relatórios são
gerados em formato HTML normalmente este diretório encontra-se dentro da estrutura do
servidor de páginas Web da empresa. Ocorre que os relatórios do Sarg muitas vezes contêm
informações sigilosas, como por exemplo: quais sites certo funcionário acessou, e quando;
que funcionários acessaram certa página; quais páginas estão sendo acessadas e em que
intensidade. Assim, sugere-se que o acesso a tais relatórios seja o mais seguro possível,
evitando vazamento de informações que possam causar futuros problemas à empresa.
● topuser_sort_field BYTES reverse
Determina por qual critério será ordenada a lista de usuários que acessaram a Internet. Neste
caso, pela quantidade de bytes trafegados e em ordem reversa, do maior para o menor. As
opções são: USER pela ordem alfabética dos nomes dos usuários; BYTES pela quantidade de
bytes trafegados; CONNECT pela quantidade de conexões feitas; TIME pelo tempo
dependido durante a navegação.
49
● user_sort_fields BYTES reverse
Determina qual o critério de ordenação do relatório de sites acessados por cada usuário. É
análogo o item anterior, com a diferença que não existe a opção USER, e sim a opção SITE
que ordena pela ordem alfabética dos sites acessados.
● date_formate e
Informa o formato de data a ser utilizado, neste caso o nosso padrão. As opções são:
e=dd/mm/yy, u=mm/dd/yy, w=yy/ww.
● topsites_num 500
Informa a quantidade de sites a serem listados no relatório de sites mais acessados. A
quantidade aqui informada vai depender do tamanho da empresa e do tempo disponível para o
administrador proceder a análise dos relatórios. O número 0 indica que todos os sites deverão
ser listados. Entretanto a utilização deste critério nos parece desnecessária, visto que,
normalmente, uma quantidade relativamente pequena de sites é responsável pela maior parte
dos acessos, e uma relação com todos poderá ser bastante grande e de pouca valia.
● topsites_sort_order BYTES D
Determina qual a ordenação dos sites listados no relatório de mais acessados, neste caso pelo
volume de bytes recebidos e em ordem decrescente, do maior para o menor.
● report_type topsites sites_users users_sites date_time
Informa quais relatórios serão gerados. Existem vários, e serão listados apenas os mais
importantes:
•
Topsites: relação dos sites mais acessados ou com maior volume de dados;
•
Sites_users: relação de quais usuários acessaram cada site;
•
Users_site: relação de quais sites cada usuário acessou;
•
Date_time: relação da quantidade de bytes utilizados em cada momento.
50
● topuser_num 0
Diz quantos usuários serão listados no relatório de maiores usuários. O número 0, se
informado, determinará a listagem de todos os funcionários e é recomendado para fins de
controle de acesso a sites mais perigosos, exceto se a empresa possuir um número de usuários
que inviabilize este controle.
Saliente-se que ainda existem vários outros parâmetros de configuração disponíveis, nos quais
se pode determinar se existem usuários que não serão listados nos relatórios (ex: gerentes ou
root), quais máquinas não deverão ter seus acessos listadas (ex: servidores), e diversos
parâmetros de configuração de aparência dos relatórios. Para melhor domínio destes
parâmetros recomenda-se a leitura das referências bibliográficas citadas neste trabalho.
51
6.2 – EXECUTANDO O SARG
Conforme dito anteriormente, o Sarg não executa como “deamon” ou serviço, ele deverá ser
executado via linha de comando. A sintaxe é a seguinte:
/usr/sbin/sarg -f /etc/sarg/sarg.conf -d 18/04/2007-18/04/2007
Onde:
•
/usr/bin/sarg: é onde se encontra instalado o sistema;
•
-f /etc/sarg/sarg/sarg.conf: a opção –f indica o caminho do arquivo de
configuração. Note que em virtude desta opção, é possível ter diversos arquivos de
configuração para a geração de diversos relatórios diferentes;
•
-d 18/04/2007-18/04/2007: determina as datas inicial e final abrangida pelo
relatório a ser emitido.
No caso do comando acima, será gerado um relatório conforme configurado no sarg.conf
abrangendo apenas o dia 18/04/2007.
Ocorre que a geração destes relatórios de forma manual é tediosa e contraproducente. Assim,
sugere-se a criação de um script, conforme abaixo:
#!/bin/bash
HOJE=$(date --date "1 day ago" +%d/%m/%Y)
/usr/sbin/sarg -f /etc/sarg/sarg-dia.conf -d $HOJE-$HOJE
exit 0
Após a criação do script, o mesmo deverá ser incluído na cron como tarefa a ser executada, de
preferência, na primeira hora de cada dia, todos os dias. Como o script gera relatórios do dia
anterior ao corrente, o relatório de acesso de cada dia estará sempre disponível no dia seguinte
e, como os relatórios não se sobrepõem, o administrador terá relatórios detalhados de todos os
dias, podendo proceder sua análise somente quando julgar conveniente ou viável.
52
Se o sistema for configurado da forma como sugerida aqui, será gerado automaticamente,
todo dia, um relatório completo com os principais sites acessados, os sites que cada usuário
acessou, que usuários acessaram cada site e que horas aconteceram estes acessos. Vale
ressaltar que tais relatórios são emitidos em formato HTML, bastando ao administrador
acessá-lo via browser para verificar com riqueza de detalhes o uso efetivo de sua conexão de
Internet.
53
7 - CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
Atualmente, o acesso constante à Internet nas empresas é um fato, entretanto, controlar esse
acesso é uma tarefa que exige cuidados especiais. O controle deve ser feito por meio de da
definição e aplicação de políticas de seguranças. Diante disso, é necessário buscar soluções
alternativas capazes de permitir o acesso à rede mundial de computadores com restrições
eficazes.
Este trabalho resultou do estudo de ferramentas de software livre que pudessem controlar de
forma eficaz o acesso à Internet. A utilização das ferramentas aqui expostas, e configuradas
da forma que foi sugerida neste estudo, permitirá um controle de acesso seguro e eficiente à
Internet para redes de diversos tamanhos, e com baixos custos devido à utilização exclusiva
de softwares livres. Portanto, espera-se que este trabalho sirva como base para iniciativas
nesse sentido.
No estágio em que se encontram hoje, os sistemas mencionados neste trabalho dependem de
diversos arquivos de configuração que deverão ser editados individualmente, não havendo
nenhuma interface mais amigável que consiga integrar a gerências dos referidos arquivos.
Uma proposta de continuidade desse trabalho seria a criação de uma ferramenta, que funcione
em HTTP, que integre a edição, configuração e estruturação desses arquivos de forma
unificada, além de controlar os serviços relativos aos sistemas, iniciando, interrompendo ou
reiniciando os mesmos quando houver necessidade. Dessa forma, a manutenção seria mais
simples e segura, pois a ferramenta de administração dos arquivos de configuração poderia
evitar erros ou inconsistências que poderiam comprometer a segurança dos sistemas.
54
8 - REFERÊNCIAS BIBLIOGRÁFICAS
1. [cert] Disponível em <http://www.cert.br/stats/incidentes/>. Acesso em: 11 de março de
2007.
2. [dansguardian] Disponível em <http://dansguardian.org/>. Acesso em 5 abril de 2007.
3. [sarg] Disponível em <http://sarg.sourceforge.net/>. Acesso em 10 de abril 2007.
4. [smartunion] Disponível em <http://www.smartunion.com.br/estatisticasutilizacao.asp/>.
Acesso em 2 de abril de 2007.
5. [squid] Disponível em <http:// www.squid-cache.org/>. Acesso em 28 de março de 2007.
6. [wikipédia] Disponível em <http://pt.wikipedia.org/wiki/squid/>. Acesso em 8 de março
de 2007.
7. KUROSE, James F; ROSS, Keith W. Redes de Computadores e a Internet: uma
abordagem top-down/ James F. Kurose, Keith W.Ross. 3. ed. Editora Pearson Addison
Wesley, 2006.
8. RICCI, B. Squid – Solução Definitiva. Editora Ciência Moderna, 2006.
9. TANEMBAUM, Andrew S. Redes de Computadores. 4. ed. Editora Campus, 2003.
10. WESSELS, D. Squid: The Definitive Guide. [S.1.]: O’Reilly Media, Inc., 2004.