Filtre o acesso
Aprenda como controlar melhor o seu servidor de proxy Squid
Um dos usos mais comuns de computadores com Linux em redes corporativas é no papel de elo de ligação entre os computadores locais e a Internet. Há muitas maneiras de configurar este serviço, e uma das mais populares é o uso de servidores proxy, que permitem o acesso aos serviços da Internet com segurança e economia de recursos.
Entre os servidores proxy disponíveis para Linux, o Squid é, sem dúvida, o mais popular. Com o Squid instalado em uma máquina Linux com acesso à Internet e acessível a partir das demais máquinas de sua rede, você pode compartilhar a WWW e os servidores FTP, com a possibilidade de controlar e restringir o acesso. Os computadores da rede local não precisam estar rodando Linux - de fato, todos os principais browsers do mercado permitem o acesso através de um servidor proxy baseado no Squid.
A plataforma de testes
Para os exemplos deste artigo, instalamos a configuração padrão do Conectiva Linux 7.0 servidor em um PC comum, ligado à Internet através de um cable modem e com conexão à rede local através de uma placa de rede PCI comum. A configuração da rede foi realizada de acordo com a documentação do provedor e da distribuição. Os procedimentos para outras distribuições são similares, e você pode contar com a documentação do Squid para auxiliar. (Veja o box Para saber mais).
O primeiro item a ser verificado é a instalação do próprio Squid. No caso do Conectiva Linux 7.0, ele está no CD número 1, e foi instalado através do comando rpm -ivh /mnt/cdrom/squid-2.4.1-1cl.i386.rpm. O arquivo de configuração default do Squid vem quase pronto para utilização (ao menos para nossos testes) - tudo o que você precisa é localizar a linha que diz http_access deny all e substituir por http_access allow all - assim seu proxy dará acesso irrestrito a qualquer página http. As outras opções são importantes também, mas não precisamos alterá-las agora.
Agora que já temos o Squid instalado e configurado, é hora de executá-lo. No Conectiva Linux, o comando é /etc/rc.d/init.d/squid start - ou utilize o ntsysv (ou o Linuxconf ou a ferramenta padrão de sua distribuição preferida) para configurar a inicialização automática a cada boot.
Configure seu browser para utilizar o servidor proxy (geralmente basta informar o endereço e a porta, que por padrão é 3128) e faça os testes - o acesso deve ocorrer normalmente. Em caso de problemas, revise os passos até tudo estar correto, antes de prosseguir.
Controlando o acesso
Para quem precisa de administração direta, com mais flexibilidade e recursos, o ideal é utilizar programas auxiliares, que utilizam a interface de redirecionamento do Squid para implementar listas de permissão e restrição baseadas em diversos critérios.
Há muitos programas neste estilo. Entre eles, o SquidGuard se destaca pelos recursos avançados, incluindo controle de acesso baseado no endereço de origem, de destino, na URL, no horário ou em combinações destes itens, além de vários tipos de redirecionamento, listas negras e outras preciosidades. Segundo o site oficial, o SquidGuard em um Pentium 500 atende a até 100.000 solicitações em 10 segundos, com uma lista de controle de acesso de mais de 13.000 itens - rápido o suficiente para a sua rede, não?
A compilação a partir do código fonte exige que você tenha a biblioteca db (disponível em www.sleepycat.com) instalada. Portanto, prepare-se para vários downloads e compilações - a não ser que sua distribuição já conte com uma versão pré-compilada do SquidGuard.
Depois de compilado e instalado de acordo com as instruções do site oficial, é hora de configurar. Acompanhe as explicações através das listagens de 1 a 3.
O primeiro arquivo a ser criado é o /etc/squidguard.conf (Listagem 1). Este arquivo diz quem pode acessar o que e quando. Vamos analisar cada uma de suas partes.
Listagem 1 - /etc/squidguard.conf
# /etc/squidguard.conf
# parte 1 - definições básicas
logdir /var/squidGuard/logs
dbhome /var/squidGuard/db
# 2 - define uma regra de horário
time horario_livre {
weekly * 00:00-08:00 18:00-24:00
}
# 3 - define um grupo interno
src sala_de_aula {
ip 10.10.200.0/24
}
# 4 - define um segundo grupo
src escritorios {
ip 10.9.0.0/16
}
# 5 - um grupo de destinos
dest porno {
domainlist porno/dominios
urllist porno/urls
}
# 6 - quem pode o que
acl {
# item (a) - escritorios, por horario
escritorios within horario_livre {
pass all
} else {
pass !porno all
}
# item (b) - sala de aula - nunca pornô!
sala_de_aula {
pass !porno all
}
# item (c) - se não for nenhuma origem conhecida, rejeitar
default {
pass none
redirect http://www.nossapagina.com.br/bloqueado.htm
}
}
A primeira parte traz as definições gerais, onde serão gravados os logs, e os arquivos de definições de destinos proibidos. No exemplo, escolhemos dois diretórios em /var/squidGuard - eles precisam ser criados manualmente, com permissão de leitura para todos.
A segunda parte define uma regra de horário, chamada horario_livre, que vai das 18:00 às 8 da manhã. Você pode ter múltiplas regras de horário, incluindo configurações baseadas em dias da semana ou do mês. Note que estamos apenas definindo nomes para as regras, sem dizer se neste horário vai ser permitido ou negado o acesso - esta parte vem mais tarde.
A terceira parte define um grupo interno de máquinas, chamado sala_de_aula. Este grupo é definido através do endereço IP, e sua máscara é 10.10.200.0/24 - ou seja, qualquer endereço IP que comece com 10.10.200. Se você não está em dia com a sua aritmética de máscaras IP, é uma boa hora para reler os manuais!
A parte 4 define um segundo grupo interno de máquinas, chamado escritorios, com a máscara 10.9.0.0/16 - qualquer IP que comece com 10.9.
A quinta parte é um pouco diferente: ela especifica um grupo de destinos, que toma a forma de dois arquivos texto (cujos conteúdos estão nas listagens 2 e 3). O primeiro indica um conjunto de nomes de domínio (exemplo: xporno.com), e o segundo contém fragmentos de URLs (exemplo: www.exemplo.org/legs) que iremos bloquear logo a seguir. Se você sabe usar expressões regulares, é possível definir um terceiro tipo de arquivo, contendo as expressões que deverão ser bloqueadas. O nome do nosso grupo de destinos é porno, mas você pode ter múltiplos grupos de destinos, para bloqueá-los de acordo com o horário e com a origem das requisições de acesso com o máximo de flexibilidade.
A última parte do arquivo é a que irá unir todas as definições acima, criando regras. Seguimos um exemplo do próprio site oficial do SquidGuard para demonstrar várias combinações possíveis.
O item (a) define as regras para o escritório. Dentro das horas definidas em horario_livre, todos os sites podem passar (pass all). Fora desse horário, vale a regra mais restritiva: exceto pornô, passa tudo (pass ! porno all).
O item (b) é uma regra mais simples: nas salas de aula, não importa o horário: passa tudo menos pornô (pass !porno all).
Se a origem não for nenhuma das duas acima, caímos no grupo (c) - o default. No caso, estamos negando todos os acessos: pass none. Além disso, nesta regra definimos o destino default a ser redirecionado toda vez que algum usuário tentar acessar uma página a que não tem acesso. Mas certifique-se de que essa página existe!
Listagem 2 - /var/squidGuard/db/porno/dominios
www.foo.com
xporno.com
zzgirls.net
Listagem 3 - /var/squidGuard/db/porno/urls
www.portalzz.com.br/safadas
www.exemplo.org/legs
Após criar este arquivo, crie os dois arquivos das listagens 2 e 3, e você já poderá configurar o Squid para utilizar o SquidGuard. Edite o /etc/squid.conf, acrescentando a seguinte linha (o path do SquidGuard pode ser diferente, dependendo de como você fez a instalação):
redirect_program /usr/bin/squidGuard
Reinicie o Squid (pode ser através do comando killall -HUP squid) e teste! Adapte a configuração para as suas necessidades e maximize a eficiência do uso de sua conexão à web. Uma sugestão extra é definir regras que bloqueiem os endereços dos banners dos sites mais freqüentados, evitando assim o tráfego gerado por eles.
Analisando os logs
Controlar o acesso pode não ser suficiente, se você não souber o que e como cortar. Felizmente o Squid mantém excelentes logs de acesso, e há ótimos programas capazes de analisar todos estes registros e gerar relatórios bastante coerentes.
Um dos mais simples de instalar e utilizar é o Calamaris. Ele lê os seus logs do Squid e gera relatórios por origem, por destino, e vários outros, contendo picos, médias e todas as outras métricas que você precisa para saber quem está usando seu servidor proxy, e de que forma. Os relatórios podem ser gerados em HTML, caso você queira publicá-los em sua Intranet, ou em texto puro, especial para ser enviado automaticamente por e-mail (que tal incluí-lo na cron para rodar todos os dias ao final do expediente?) ou consultado no console.
O Calamaris é em Perl, portanto sua instalação é extremamente simples: descompacte o arquivo .tar.gz e copie o executável (chamado 'calamaris', sem extensão) para o diretório /usr/bin. Aí, digite calamaris -- help para ver as opções deste programa, e use-o da seguinte forma:
cat /var/squid/logs/access.log | calamaris -a -m
Note que a localização do seu arquivo de log de acesso pode variar! A opção indica que queremos todos os relatórios (-a), em formato mail (-m). Ao invés do -m, poderíamos usar o -w para gerar em formato web. E há muitas outras opções disponíveis na documentação, esperando para serem descobertas e testadas.
O Squid é uma excelente ferramenta para liberar o acesso da sua rede interna à WWW e a servidores de FTP. Se bem configurado e controlado, ele permite que você defina exatamente quem pode acessar quais serviços e bloqueie sites indesejáveis. Com o controle por horários, você pode ajudar a evitar que o acesso à Internet comprometa a produtividade, sem ter que bloquear completamente o acesso à Internet - corte apenas os sites desnecessários!
O SquidGuard é uma excelente ferramenta para implementar as regras de controle de acesso, e o Calamaris permite que você possa acompanhar seus resultados. Seu efeito combinado é excelente para a eficiência de sua rede, e você não deve deixar de experimentar e aplicar estas duas ferramentas.
Para Saber Mais
Augusto Campos - brain@matrix.com.br
