O Squid é um servidor proxy. Ele permite compartilhar a 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.

Ao compartilhar via NAT os micros da rede acessam a internet diretamente, sem restrições. O servidor apenas repassa as requisições recebidas, como um garoto de recados. O proxy é como um burocrata que não se limita a repassar as requisições: ele analisa todo o trífego de dados, separando o que pode ou não pode passar e guardando informações para uso posterior.

Compartilhar a conexão via NAT é mais simples do que usar um proxy como o Squid sob vírios aspectos. Você compartilha a conexão no servidor, configura os clientes para o utilizarem como gateway e pronto.

Por exemplo, para compartilhar a conexão via NAT no Mandrake você usaria o "Compartilhar conexão com a Internet" dentro do Painel de Controle e configuraria os clientes para usar o endereço IP do servidor (192.168.0.1 por exemplo) como gateway. No Kurumin você usaria o àcone mígico no Iniciar > Internet > Compartilhar Conexão e Firewall.

http://www.guiadohardware.net/tutoriais/090/index_html_m3179b4cd.png

Ao usar um proxy, além da configuração da rede é necessírio configurar o navegador e cada outro programa que for acessar a internet em cada cliente para usar o proxy. Esta é uma tarefa tediosa e que acaba dando bastante dor de cabeça a longo prazo, pois cada vez que um micro novo for colocado na rede serí preciso fazer a configuração novamente.

A configuração do proxy muda de navegador para navegador. No Firefox por exemplo você encontra em Editar > Preferências > Geral > Proxy. No IE a configuração estí em Opções da Internet > Opções > Configurações da Lan > Usar um servidor Proxy.

http://www.guiadohardware.net/tutoriais/090/index_html_m3877eb7e.png

Além do navegador, outros programas, podem ser configurados para trabalhar através do proxy: Clientes de ICQ e MSN e até programas P2P.

As vantagens de usar um proxy são basicamente três:

1- É possàvel 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.

2- O proxy funciona como um cache de píginas e arquivos, armazenando informações jí acessadas. Quando alguém acessa uma pígina que jí foi carregada, o proxy envia os dados que guardou no cache, sem precisar acessar a mesma pígina repetidamente. Isso acaba economizando bastante banda na conexão com a Internet e tornando o acesso mais rípido sem precisar investir numa conexão mais rípida.

Hoje em dia os sites costumam usar píginas dinâmicas, onde o conteúdo muda a cada visita, mas mesmo nestes casos o proxy dí uma ajuda, pois embora o html seja diferente a cada visita, e realmente precise ser baixado de novo, muitos componentes da pígina, como ilustrações, banners e animações em flash podem ser aproveitadas do cache, diminuindo o tempo total de carregamento.

http://www.guiadohardware.net/tutoriais/090/index_html_236e323b.png

Dependendo da configuração, o proxy pode apenas acelerar o acesso às píginas, ou servir como um verdadeiro cache de arquivos, armazenando atualizações do Windows Update, downloads diversos e pacotes instalados através do apt-get por exemplo. Ao invés de ter que baixar o Service Pack XYZ do Windows XP ou o OpenOffice nos 10 micros da rede, você vai precisar baixar apenas no primeiro, pois os outros 9 vão baixar a partir do cache do squid.

3- Uma terceira vantagem de usar um proxy é que ele loga todos os acessos. Você pode visualizar os acessos posteriormente usando o Sarg, assim você sabe quem acessou quais píginas e em que horírios. Além de tudo, o Squid é dedo duro :-P

http://www.guiadohardware.net/tutoriais/090/index_html_m65bb8f79.png

Mesmo assim, você pode estar achando que as vantagens não vão compensar o trabalho de sair configurando micro por micro, programa por programa para usar o proxy e é mais fícil simplesmente compartilhar via NAT. Mas, existe a possibilidade de juntar as vantagens das formas de compartilhamento, configurando um proxy transparente como veremos adiante.

Ao usar um proxy transparente, você tem basicamente uma conexão compartilhada via NAT, com a mesma configuração bísica nos clientes. O proxy entra na história como uma espécie add-on.

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 (incluindo o negócio do cache dos arquivos do Windows update, downloads e do apt-get), sem que você precise fazer nenhuma configuração adicional nos clientes :-)

http://www.guiadohardware.net/tutoriais/090/index_html_m2fd47919.png

A algum tempo atrís, escrevi um script de configuração para o Kurumin, disponàvel no painel de configuração de servidores. Este script permite instalar o proxy, estabelescer algumas restrições de acesso e ativar o proxy transparente de forma simples:

http://www.guiadohardware.net/tutoriais/090/index_html_3a3d4dd4.png

Neste tutorial vou ensinar como fazer isso e criar regras mais elaboradas de restrição de acesso em qualquer distribuição.

Instalando o Squid

O Squid é composto de um único pacote, por isso a instalação é simples. Se estiver no Mandrake, instale com um:

# urpmi squid

Se estiver no Debian ou outra distribuição baseada nele, use o apt-get:

# apt-get install squid

Toda a configuração do Squid é feita num único arquivo, o /etc/squid/squid.conf.

Caso você esteja usando uma versão antiga do Squid, como a incluàda no Debian Woody por exemplo, o arquivo pode ser o /etc/squid.conf. Apesar da mudança na localização do arquivo de configuração, as opções descritas aqui devem funcionar sem maiores problemas.

O arquivo original, instalado junto com o pacote é realmente enorme, contém comentírios e exemplos para quase todas as opções disponàveis. Ele pode ser uma leitura interessante se você jí tem uma boa familiaridade com o Squid, mas de inicio é melhor começar com um arquivo de configuração mais simples, apenas com as opções mais usadas.

Em geral cada distribuição inclui uma ferramenta diferente para a configuração do Proxy, como o àcone mígico que incluà no Kurumin.

Uma das mais usadas é o Webmin. A função destas ferramentas é disponibilizar as opções através de uma interface grífica e gerar o arquivo de configuração com base nas opções escolhidas.

Em alguns casos estas ferramentas ajudam bastante, mas como elas mudam de distribuição para distribuição, é mais produtivo aprender a trabalhar direto no arquivo de configuração, que não é tão complicado assim.

Pra começar renomeie o arquivo padrão:

# mv /etc/squid/squid.conf /etc/squid/squid.conf.velho

e crie um novo arquivo /etc/squid/squid.conf, com apenas as quatro linhas abaixo:

--------

http_port 3128
visible_hostname kurumin
acl all src 0.0.0.0/0.0.0.0
http_access allow all

--------

Estas linhas são o suficiente para que o Squid "funcione". Como você percebeu, aquele arquivo de configuração gigante tem mais uma função informativa, citando e explicando as centenas de opções disponàveis. As quatro linhas dizem o seguinte:

- http_port 3128: A porta onde o servidor vai ficar disponàvel

- visible_hostname kurumin: O nome do servidor

- acl all src 0.0.0.0/0.0.0.0 e http_access allow all: Estas duas linhas criam uma acl (uma polàtica de acesso) chamada "all" (todos) incluindo todos os endereços IP possàveis e permite que qualquer um dentro desta lista use o proxy. Ou seja, ela permite que qualquer um use o proxy, sem limitações.


Para testar o Squid, habilite o servidor com o comando:

# service squid start

Se você estiver no Debian, use o comando:

# /etc/init.d/squid start

Se estiver no Slackware, o comando serí:

# /etc/rc.d/rc.squid start

Configure um navegador, no próprio servidor para usar o proxy, através do endereço 127.0.0.1 (o localhost), porta 3128 e teste a conexão.

Se tudo estiver ok você conseguirí acessar o proxy também através dos outros micros da rede local, basta configurar os navegadores para usarem o proxy.

Criando uma configuração bísica

O problema é que com apenas estas quatro linhas o proxy estí muito aberto. Se você deixar o servidor proxy ativo no próprio servidor que compartilha a conexão e não tiver nenhum firewall ativo, alguém na Internet poderia usar o seu proxy, o que naturalmente não é desejado. O proxy deve ficar ativo apenas para a rede local. Vamos gerar então um arquivo mais completo, permitindo que apenas os micros da rede local possam usar o proxy e definindo mais algumas polàticas de segurança.

Aqui eu jí aproveitei algumas linhas do arquivo original, criando regras que permitem o acesso a apenas algumas portas, e não a qualquer coisa como antigamente:

--------

http_port 3128
visible_hostname kurumin

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal

http_access deny all

--------

Veja que agora criei duas novas acl's. A acl "localhost" contém o endereço 127.0.0.1, você usa para usar o proxy localmente, a partir do próprio servidor e a acl "rede local" que inclui os demais micros da rede local.

Você deve substituir o " 192.168.1.0/24" pela a faixa de endereços IP e a míscara de sub-rede usada na sua rede local (o 24 equivale à mascara 255.255.255.0).

Depois de criadas as duas polàticas de acesso, vão duas linhas no final do arquivo que especificam que os micros que se enquadrarem nelas vão poder usar:

http_access allow localhost
http_access allow redelocal

Lembra-se da acl "all", que contém todo mundo? Vamos usa-la para especificar que quem não se enquadrar nas duas regras acima (ou seja, micros não autorizados, da internet) não poderí usar o proxy:

http_access deny all

Esta linha deve ir no final do arquivo, depois das outras duas. O ordem é importante, pois o squid interpreta as regras na ordem em que são colocadas no arquivo. Se você permite que o micro X acesse o proxy, ele acessa, mesmo que uma regra mais abaixo diga que não.

Se você adicionasse algo como:

acl redelocal src 192.168.1.0/24
http_access allow redelocal
http_access deny redelocal

Os micros da rede local continuariam acessando, pois a regra que permite vem antes da que proàbe.

Configurando o cache de píginas e arquivos

Outra coisa importante é configurar o cache do proxy. O squid trabalha com dois tipos de cache:

1- Um cache rípido, feito usando parte da memória RAM do servidor
2- Um cache um pouco mais lento porém maior, feito no HD

O cache na memória RAM é ideal para armazenar arquivos pequenos, como píginas html e imagens, que serão entregues instantâneamente para os clientes. O cache no HD é usado para armazenar arquivos maiores, como downloads, arquivos do Windows update e pacotes baixados pelo apt-get.

O cache na memória RAM é sempre relativamente pequeno. Num servidor não dedicado ou seja, uma míquina que é usada para fazer outras coisas, mas roda também o proxy, você vai reservar coisa de 16 ou 32 MB de RAM para o cache, para evitar que o cache do squid coma toda a memória RAM deixando o micro lento.

Se você tiver uma rede muito grande e preferir deixar um micro dedicado apenas para o Squid, então o cache pode ter até 1/3 da memória RAM do servidor. Não caia no erro de reservar quase toda a RAM para o cache, pois além do cache, o sistema vai precisar de memória para fazer outras coisas.

O cache no HD pode ser mais generoso, afinal a idéia é que ele guarde todo tipo de arquivos, principalmente os downloads grandes, que demoram para ser baixados. A única limitação neste caso é o espaço livre no HD.

A configuração do cache é feita adicionando mais algumas linhas no arquivo de configuração:


A configuração da quantidade de memória RAM dedicada ao cache é feita adicionando a opção "cache_mem", que contém a quantidade de memória que serí dedicada ao cache. Para reservar 32 MB, por exemplo, a linha ficaria:

cache_mem 32 MB

Abaixo vai mais uma linha, que determina o tamanho míximo dos arquivos que serão guardados no cache feito na memória RAM. O resto vai para o cache feito no HD. O cache na memória é muito mais rípido, mas como a quantidade de RAM é muito limitada, melhor deixa-la disponàvel para píginas web, figuras e arquivos pequenos em geral. Para que o cache na memória armazene arquivos de até 64 KB por exemplo, adicione a linha:

maximum_object_size_in_memory 64 KB

Em seguida vem a configuração do cache em disco, que armazenarí o grosso dos arquivos. Por default, o míximo são downloads de 16 MB e o mànimo é zero, o que faz com que mesmo imagens e arquivos pequenos sejam armazenados no cache. Sempre é mais rípido ler a partir do cache do que baixar de novo da web, mesmo que o arquivo seja pequeno.

Se você faz download de arquivos grandes e deseja que eles fiquem armazenados no cache, aumente o valor da opção maximum_object_size Isto é especialmente útil para quem precisa baixar muitos arquivos através do apt-get ou Windows update em muitos micros da rede. Se você quiser que o cache armazene arquivos de até 512 MB por exemplo, as linhas ficariam:

maximum_object_size 512 MB
minimum_object_size 0 KB

Você pode definir ainda a percentagem de uso do cache que farí o squid começar a descartar os arquivos mais antigos. Por padrão isso começa a acontecer quando o cache estí 90% cheio:

cache_swap_low 90
cache_swap_high 95

Depois vem a configuração do tamanho do cache em disco propriamente dita, que é composta por quatro valores. O primeiro, (/var/spool/squid) indica a pasta onde o squid armazena os arquivos do cache. Você pode querer alterar para uma pasta em uma partição separada por exemplo.

O "2048" indica a quantidade de espaço no HD (em MB) que serí usada para o cache. Aumente o valor se você tem muito espaço no HD do servidor e quer que o squid guarde os downloads por muito tempo.

Finalmente, os números 16 256 indicam a quantidade de subpastas que serão criadas dentro do diretório. Por padrão temos 16 pastas com 256 subpastas cada uma.

cache_dir ufs /var/spool/squid 2048 16 256

Você pode definir ainda o arquivo onde são guardados os logs de acesso do Squid. Por padrão o squid guarda o log de acesso no arquivo /var/log/squid/access.log. Este arquivo é usado pelo sarg para gerar as píginas com as estatisticas de acesso.

cache_access_log /var/log/squid/access.log

Mais uma configuração que você pode querer alterar é o padrão de atualização do cache. Estas três linhas precisam sempre ser usadas em conjunto. Ou seja, você pode alterí-las, mas sempre as três precisam estar presente no arquivo. Eliminando um, o squid ignora as outras duas e usa o default.

Os números indicam o tempo (em minutos) quando o squid irí verificar se um àtem do cache (uma pígina por exemplo) foi atualizado, para cada um dos três protocolos.

O primeiro número (o 15) indica que o squid verificarí se todas as píginas e arquivos com mais de 15 minutos foram atualizados. Ele só verifica checando o tamanho do arquivo, o que é rípido. Se o arquivo não mudou, então ele continua mandando o que não estí no cache para o cliente.

O terceiro número (o 2280, equivalente a dois dias) indica o tempo míximo, depois disso o objeto é sempre verificado. Além do http e ftp o Squid suporta o protocolo Gopher, que era muito usado nos primórdios da Internet para localizar documentos de texto, mas perdeu a relevância hoje em dia:

refresh_pattern ^ftp: 15 20% 2280
refresh_pattern ^gopher: 15 0% 2280
refresh_pattern . 15 20% 2280


Depois de adicionar estas configurações todas, o nosso arquivo de configuração jí ficarí bem maior:

--------

http_port 3128
visible_hostname kurumin

cache_mem 32 MB
maximum_object_size_in_memory 64 KB
maximum_object_size 512 MB
minimum_object_size 0 KB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /var/spool/squid 2048 16 256
cache_access_log /var/log/squid/access.log
refresh_pattern ^ftp: 15 20% 2280
refresh_pattern ^gopher: 15 0% 2280
refresh_pattern . 15 20% 2280

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal

http_access deny all

--------

Aqui jí temos uma configuração mais completa, incluindo um conjunto de regras de segurança, para que o proxy seja usado apenas a partir da rede local e a configuração do cache, uma configuração adequada para uso numa rede doméstica ou um pequeno escritório por exemplo.

Numa rede maior você provavelmente iria querer adicionar algumas limitações de acesso, limitando o acesso a algumas píginas, criando um sistema de autenticação ou limitando o uso com base no horírio por exemplo.

Adicionando restrições de acesso

Num ambiente de trabalho, a idéia é que os funcionírios usem a internet para comunicação, pesquisa e outras funções relacionadas ao que estão fazendo. Algumas empresas permitem que acessem os e-mails pessoais e coisas assim, mas sempre até um certo limite. Seu chefe não vai gostar se começarem a passar a maior parte do tempo no Orkut por exemplo.




Bloqueando por palavras ou domànios


Uma forma fícil de bloquear sites no Squid é criar uma lista de palavras, um arquivo de texto onde você adiciona palavras e domànios que serão bloqueados no Squid.

Bloquear um determinado domànio, como por exemplo "orkut.com" não gera muitos problemas, mas tome cuidado ao bloquear palavras especàficas, pois o Squid passarí a bloquear qualquer pígina que contenha a palavra em questão.

Se você bloquear a palavra "sexo" por exemplo, qualquer site ou artigo que mencione a palavra serí bloqueado. Ao bloquear por palavras você deve tentar ser especàfico, bloqueando apenas jargões e expressões que são encontradas apenas nos sites que você pretende bloquear.

Para adicionar o filtro de palavras, adicione as linhas:

acl proibidos dstdom_regex "/etc/squid/proibidos"
http_access deny proibidos

Aqui estamos criando uma acl chamada "proibidos" que é gerada a partir da leitura do arquivo "/etc/squid/proibidos", o arquivo de texto que iremos editar. O acesso a qualquer pígina que contenha palavras citadas no arquivo é bloqueada.

O arquivo deve conter as palavras e domànios bloqueados, um por linha:

http://www.guiadohardware.net/tutoriais/090/index_html_m2effdc9c.png

Depois criar o arquivo e adicionar as duas linhas no arquivo de configuração do squid, reinicie o serviço com um:

# service squid restart

ou

# /etc/init.d/squid/restart

A partir daà o bloqueio de palavras entra em ação e os clientes passam a ver uma mensagem de erro ao tentar acessar a pígina:

http://www.guiadohardware.net/tutoriais/090/index_html_m7d5f8eb.png

Este filtro de palavras pode levar a alguns erros inesperados. Se você o usa para bloquear o site "orkut.com" por exemplo, os usuírios não conseguirão ler por exemplo um artigo da Superinteressante que cita o endereço do site.

Existe uma opção mais adequada para o bloqueio de domànios, que é criar uma acl usando o parâmetro "dstdomain". Veja um exemplo:

acl bloqueados dstdomain orkut.com playboy.abril.com.br astalavista.box.sk
http_access deny bloqueados

Aqui eu criei uma acl chamada "bloqueados" que contém os endereços "orkut.com" "playboy.abril.com.br" e "astalavista.box.sk" e me seguida incluà a regra "http_access deny bloqueados" que bloqueia o acesso a eles.

Aqui estamos sendo mais especàficos. Ao invés de bloquear o termo "orkut.com" o squid vai bloquear apenas o acesso ao domànio em questão.

Existe uma última ressalva: alguns sites, como o orkut.com podem ser acessados tanto com o www quanto sem. Para o squid, "www.orkut.com" e "orkut.com" são duas coisas diferentes. Bloqueando o "orkut.com" os usuírios ainda conseguirão acessar o site através do "www.orkut.com". Para bloquear ambos, é preciso incluir as duas possibilidades dentro da regra, como em:

acl bloqueados dstdomain orkut.com http://www.orkut.com playboy.abril.com.br
http_access deny bloqueados

Você pode incluir quantos domànios quiser dentro da regra, basta separí-los por espaço e deixar tudo na mesma linha.

Não existe problema em combinar a regra que cria o filtro de palavras com esta que filtra baseado no domànio, você pode apelar para uma ou outra de acordo com a situação.

Depois de adicionar as novas regras, nosso arquivo de configuração ficaria assim:

--------

http_port 3128
visible_hostname kurumin

cache_mem 32 MB
maximum_object_size_in_memory 64 KB
maximum_object_size 512 MB
minimum_object_size 0 KB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /var/spool/squid 2048 16 256
cache_access_log /var/log/squid/access.log
refresh_pattern ^ftp: 15 20% 2280
refresh_pattern ^gopher: 15 0% 2280
refresh_pattern . 15 20% 2280

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

acl proibidos dstdom_regex "/etc/squid/proibidos"
http_access deny proibidos

acl bloqueados dstdomain orkut.com http://www.orkut.com playboy.abril.com.br
http_access deny bloqueados

acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal

http_access deny all

--------

Veja que coloquei as duas regras antes do "http_access allow redelocal", que abre tudo para a rede local. Como o squid processa as regras seqüencialmente, as píginas que forem bloqueadas pelas duas regras não chegarão a passar pela seguinte.




Bloqueando por horírio


Estas regras fazem com que o proxy recuse conexões feitas dentro de determinados horírios. Você pode definir regras peràodos especàficos e combiní-las para bloquear todos os horírios em que você não quer que o proxy seja usado.

Para que o proxy bloqueie acessos feitos entre meia-noite e 6:00 da manhã e no horírio de almoço por exemplo, você usaria as regras:

acl madrugada time 00:00-06:00
http_access deny madrugada

acl almoco time 12:00-14:00
http_access deny almoco

Estas regras iriam novamente antes da regra "http_access allow redelocal" no arquivo de configuração.

Agora imagine que você quer fazer diferente. Ao invés de bloquear o acesso na hora de almoço, você quer deixar o proxy aberto, para quem quiser ir no orkut ou acessar os e-mails poder fazer isso fora do horírio de trabalho. Neste caso você usaria uma regra como:

acl almoco time 12:00-14:00
http_access allow almoco

Esta regra entraria no arquivo de configuração antes das regras "http_access deny proibidos" e "http_access deny proibidos". Assim, os acessos que forem aceitos pela regra do almoço, não passarão pelas regras que fazem o bloqueio.

Proxy com autenticação

Você pode adicionar 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.

Quase todos os navegadores oferecem a opção de salvar a senha. Não seria muito legal se o usuírio tivesse que ficar digitando toda hora... ;-)

http://www.guiadohardware.net/tutoriais/090/index_html_m670cd62e.png

Para ativar a autenticação você vai precisar de u programa chamado "htpasswd". Se ele não estiver presente, instale o pacote apache-utils:

Em seguida crie o arquivo que serí usado para armazenar as senhas:

# touch /etc/squid/squid_passwd

Cadastre os logins usando o comando:

# htpasswd /etc/squid/squid_passwd kurumin
(onde o "kurumin" é o usuírio que estí sendo adicionado)

Depois de terminar de cadastrar os usuírios, adicione as linhas que ativam a autenticação no /etc/squid/squid.conf:

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd
acl autenticados proxy_auth REQUIRED
http_access allow autenticados

O "/usr/lib/squid/ncsa_auth" é a localização da biblioteca responsível pela autenticação. Eventualmente, ela pode estar numa pasta diferente dentro da distribuição que estiver usando. Neste caso use o "locate" ou a busca do KDE para encontrar o arquivo e altere a linha indicando a localização correta.

Estas três linhas criam uma acl chamada "autenticados" (poderia ser outro nome), que contém os usuírios que se autenticarem usando um login vílido.

Configurando um proxy transparente

Uma garantia de que os usuírios realmente vão usar o proxy e ao mesmo tempo uma grande economia de trabalho e dor de cabeça pra você é o recurso de proxy transparente.

Ele permite configurar o Squid e o firewall de forma que o servidor proxy fique escutando todas as conexões na porta 80. Mesmo que alguém tente desabilitar o proxy manualmente nas configurações do navegador, ele continuarí sendo usado.

Outra vantagem é que este recurso permite usar o proxy sem precisar configurar manualmente o endereço em cada estação. Basta usar o endereço IP do servidor rodando o proxy como gateway da rede.

Lembre-se que para usar o proxy transparente, você jí deve estar compartilhando a conexão no servidor, via nat. O proxy transparente apenas farí com que o proxy intercepte os acessos na porta 80, obrigando tudo a passar pelas suas regras de controle de acesso, log, autenticação e cache.

Se você ainda não compartilhou a conexão, pode fazer isso manualmente rodando estes três comandos:

# modprobe iptable_nat
# iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
# echo 1 > /proc/sys/net/ipv4/ip_forward

O "eth1" na segunda linha, indica a placa que estí conectada na Internet e serí compartilhada. Você pode checar a configuração da rede usando o comando "ifconfig" (como root).

Nem todas as distribuições instalam o iptables por padrão. No Mandrake por exemplo, pode ser necessírio rodar primeiro um "urpmi iptables".

Em seguida, rode o comando que direciona as requisições recebidas na porta 80 para o squid.

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

O "eth0" neste quarto comando indica a placa da rede local, onde o proxy recebe as requisições dos outros micros da rede e o "3128" indica a porta usada pelo squid.

Adicione os quatro comandos no final do arquivo /etc/rc.d/rc.local ou /etc/init.d/bootmisc.sh (no Debian) para que eles sejam executados durante o boot.

Finalmente, você precisa adicionar as seguintes linhas no final do arquivo squid.conf e restartar o serviço:

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Em resumo, você vai ter a conexão compartilhada via Nat no servidor e configurarí os clientes para acessar através dela, colocando o servidor como gateway da rede. Ao ativar o proxy transparente, a configuração dos clientes continua igual, a única diferença é que agora todo o trífego da porta 80 passarí obrigatoriamente pelo servidor Squid.

Isso permite que você se beneficie do log dos acessos e do cache feito pelo proxy, sem ter que se sujeitar às desvantagens de usar um proxy, como ter que configurar manualmente cada estação.


Depois de adicionar a regra que libera o acesso na hora do almoço, ativar a autenticação e o proxy transparente, nosso arquivo vai ficar assim:

--------

http_port 3128
visible_hostname kurumin

# Configuração do cache
cache_mem 32 MB
maximum_object_size_in_memory 64 KB
maximum_object_size 512 MB
minimum_object_size 0 KB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /var/spool/squid 2048 16 256

# Localização do log de acessos do Squid
cache_access_log /var/log/squid/access.log

refresh_pattern ^ftp: 15 20% 2280
refresh_pattern ^gopher: 15 0% 2280
refresh_pattern . 15 20% 2280

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

# Libera acessos na hora do almoço
acl almoco time 12:00-14:00
http_access allow almoco

# Filtros por palavras e por dominios
acl proibidos dstdom_regex "/etc/squid/proibidos"
http_access deny proibidos
acl bloqueados dstdomain orkut.com http://www.orkut.com playboy.abril.com.br
http_access deny bloqueados

# Autenticação dos usuírios
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd
acl autenticados proxy_auth REQUIRED
http_access allow autenticados

# Libera para a rede local
acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal

# Bloqueia acessos externos
http_access deny all

# Proxy transparente
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

--------

Usando o Sarg para monitorar o acesso

O Sarg é um interpretador de logs para o Squid, assim como o Webalizer e o Apache. Sempre que executado ele cria um conjunto de píginas, divididas por dia, com uma lista de todas as míquinas que foram acessadas e a partir de cada míquina da rede veio cada acesso.

Caso você tenha configurado o Squid para exigir autenticação. , ele organiza os acessos com base nos logins dos usuírios, caso contrírio ele mostra os endereços IP das míquinas.

A partir daà você pode acompanhar as píginas que estão sendo acessadas, mesmo que não exista nenhum filtro de conteúdo e tomar as medidas cabàveis em casos de abuso. Todos sabemos que os filtros de conteúdo nunca são completamente eficazes, eles sempre bloqueiam algumas píginas úteis e deixam passar muitas píginas impróprias. Se você tiver algum tempo para ir acompanhando os logs, a inspeção manual é sempre o método mais eficiente.

A partir daà você pode ir fazendo um trabalho incremental, de ir bloqueando uma a uma píginas onde os usuírios perdem muito tempo, ou fazer algum trabalho educativo, explicando que os acessos estão sendo monitorados e estabelecendo algum tipo de punição para quem abusar.

Aqui estí um exemplo do relatório gerado pelo Sarg. Por padrão ele gera um conjunto de píginas html dentro da pasta /var/www/squid-reports/ (ou /var/www/html/squid/, no Mandrake) que você pode visualizar através de qualquer navegador.

Os acessos são organizados por usuírio (caso esteja usando autenticação) ou por IP, mostrando as píginas acessadas por cada um, quantidade de dados transmitidos, tempo gasto em cada acesso, tentativas de acesso bloqueadas pelos filtros de conteúdo e outras informações.

http://www.guiadohardware.net/tutoriais/090/index_html_349ce920.png

O Sarg é incluàdo na maioria das distribuições atuais, em alguns casos instalado por padrão junto com o Squid.

No Debian e derivados ele pode ser instalado com um:

# apt-get install sarg

No Mandrake um "urpmi sarg" jí resolve.

Depois de instalado, basta chamar o comando "sarg" (como root) para que os relatórios sejam geradas automaticamente a partir do log do squid.

O Sarg não é um daemon que fica residente, você precisa apenas chama-lo quando quiser atualizar os relatório, se você quiser automatizar esta tarefa, pode usar o cron para que ele seja executado automaticamente todos os dias ou uma vez por hora por exemplo.

Você pode alterar a pasta onde são salvos os relatórios, limitar o acesso às estatàticas e alterar vírias opções cosméticas no arquivo de configuração do Sarg, que é o /etc/sarg/sarg.conf (no Mandrake) ou /etc/squid/sarg.conf (no Debian).

O arquivo é auto explicativo, nele você pode alterar os diretórios padrão, alterar o layout da Outro recurso interessante é o envio de uma cópia do relatório por e-mail sempre que o sarg for executado.

Fonte:
Guia do Hardware