Configuração de Proxy Cache no Linux (Squid)

Olá Pessoal.

Neste artigo o leitor irá aprender a configurar o Squid 3.5 no Linux (distribuições Debian-based) para implementar um servidor proxy/cache. Um servidor de proxy/cache é fundamental nas empresas porque sua presença implica em economia de banda no link WAN (um recurso importante e caro) e em maior desempenho da Internet, uma vez que há diminuição de latência no acesso aos conteúdos populares da Internet que passam a ficar armazenados em cache no próprio servidor. 

Assim que um conteúdo popular na Internet é acessado pela primeira vez por alguma máquina da rede local, o servidor proxy trata de manter uma cópia desse conteúdo em cache local. A partir de então as demais máquinas que tiverem interesse em acessar esse mesmo conteúdo não precisam mais atravessar toda a Internet para buscá-lo, de forma que basta um acesso local ao servidor proxy/cache mais próximo. Para o usuário o resultado é uma melhor experiência de navegação e para a empresa o resultado é redução de custos. Enfim, todos saem ganhando! :-)

Assim como nos artigos anteriores, estou considerando que o servidor está instalado com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote denominado squid3 para que o Linux possa ser posteriormente configurado como servidor proxy/cache (web). Essa terafa é simples e rápida através do APT:

root@proxy:/# apt-get install squid3

Depois de instalado, as configurações do Squid são realizadas no arquivo de configuração que fica localizado em "/etc/squid3/squid.conf". O arquivo de configuração é extenso, mas bastante organizado e todo comentado para facilitar sua manipulação. Na sequência trago as principais linhas desse arquivo com alguns destaques (em amarelo) que comentarei na sequência.

01. ###--- em /etc/squid3/squid.conf
02. #---------------------------------------------------------------
03. # ACL SIMPLES (PERMITE TODA REDE LOCAL)
04. #---------------------------------------------------------------

05. acl localnet src 192.168.221.0/24

06. http_access allow localhost
07. http_access allow localnet
08. http_access deny all
09. #---------------------------------------------------------------
10. http_port 3128 
11. maximum_object_size_in_memory 512 KB
12. cache_mem 64 MB
13. maximum_object_size 96 MB
14. cache_dir ufs /var/spool/squid3 1024 16 256
15. access_log /var/log/squid3/access.log squid
16. cache_log /var/log/squid3/cache.log
17. connect_timeout 2 seconds
18. cache_mgr shbbrito@labcisco.com.br
19. visible_hostname proxy.labcisco.com.br

A linha 05 faz referência à rede local (LAN) que fará uso do proxy, sendo que o conteúdo nas linhas 05 a 08 definem controles de acesso à Internet. Nessa configuração básica estamos apenas permitindo nossa rede local e negando qualquer outra origem (reparem que o allow vem antes do deny). As regras de controle de acesso devem ser bem detalhadas para atender as necessidades da sua empresa, mas deixaremos para discorrer mais sobre ACLs na próxima seção do artigo.

O parâmetro http_port (linha 10) define em que porta o Squid será executado (padrão=3128/TCP). O conteúdo do cache precisa ser armazenado em algum local e essa definição é configurada no parâmetro cache_dir (linha 14) do arquivo de configuração. É importante ter em mente que a qualidade do disco físico certamente irá influenciar no desempenho do servidor (velocidade de input/output), além disso é comum separar uma partição lógica de cache exclusiva para evitar que o armazenamento saia de controle e eventualmente comprometa a execução do SO instalado no servidor. O primeiro número do parâmetro cache_dir faz referência ao tamanho máximo (em MB) permitido para armazenamento de cache, sendo que o padrão é apenas 100MB. Os outros dois números dizem respeito à quantidade de subdiretórios que podem ser criados no diretório de cache, algo importante para a dinâmica do Squid que "quebra" o armazenamento em diversos grupos menores para melhorar o tempo de acesso aos dados em disco. No geral, os valores default são suficientes para a maioria dos casos...

Obs.: Por padrão o Squid faz o cache em memória principal (cache_mem), por isso o ideal é limitar esse parâmetro e informar um diretório em disco secundário (cache_dir) para fins de cache. Outra observação é que o administrador pode criar um novo arquivo apenas com as configurações trazidas acima para ter como resultado um arquivo de configuração mais limpo e menos extenso, no entanto recomenda-se que seja feito o backup do arquivo original.

# Listas de Controle de Acesso (ACLs)

A enorme flexibilidade do Squid em relação à escrita de ACLs para filtrar o conteúdo do tráfego entre as máquinas da rede local e os servidores na Internet é definitivamente um dos maiores pontos positivos dessa ferramenta. O Squid, além de proxy cache, permite transformar a máquina em firewall de nível de aplicação capaz de analisar o conteúdo do payload dos pacotes, ou seja, um firewall muito superior aos tradicionais firewalls de nível de rede que apenas analisam o conteúdo dos cabeçalhos dos pacotes. Esse tópico é extenso o suficiente para dar origem a vários outros artigos, por isso estarei exemplificando algumas das funcionalidades mais comuns e bastante úteis no cotidiano do profissional da área, tomando por base a topologia abaixo.

01. ###--- em /etc/squid3/squid.conf

02. #---------------------------------------------------------------
03. # EXEMPLO DE REGRAS ACL PARA RESTRICAO DE ACESSO
04. #---------------------------------------------------------------
05. acl localnet src 192.168.221.0/24
06. acl whitelist url_regex "/etc/squid3/filter/whitelist.squid"
07. acl blacklist url_regex "/etc/squid3/filter/blacklist.squid"
08. acl vip src 192.168.221.11 192.168.221.12
09. acl hora_almoco time MTWHF 12:00-13:00
10. acl recepcao src 192.168.221.101 192.168.221.102
11. 
12. http_access allow localhost
13. http_access allow vip
14. http_access allow whitelist
15. http_access deny  blacklist 
16. http_access allow recepcao hora_almoco
17. http_access deny  recepcao
18. http_access allow localnet
19. http_access deny  all
20. #---------------------------------------------------------------

O arquivo blacklist.squid contém uma relação de conteúdo que deve ser bloqueado, seja esse conteúdo uma extensão de arquivo, uma palavra-chave ou mesmo uma URL. Assim, para bloquear o download de arquivos ".exe", para bloquear qualquer URL com a palavra "facebook" e para bloquear especificamente o site com endereço "www.site.com.br", basta criar uma lista simples em /etc/squid3/filter/:

root@proxy:/# mkdir /etc/squid3/filter
root@proxy:/# touch /etc/squid3/filter/blacklist.squid
root@proxy:/# touch /etc/squid3/filter/whitelist.squid
(...)
root@proxy:/# cat /etc/squid3/filter/blacklist.squid
\.exe$
facebook
www.site.com.br

Obs.: O administrador pode escolher qualquer outro diretório de sua preferência. A whitelist que precede a blacklist deve ser uilizada para permitir exceções dentro das regras de restrição inseridas na blacklist. Por exemplo, uma negação à palavra "hot" na blacklist irá implicar no bloqueio da palavra "hotmail", logo a palavra "hotmail" pode ser previamente permitida na whitelist.

Na sintaxe do Squid, as linhas iniciadas em acl criam correspondências (ou matches) que na sequência são utilizadas pelas linhas iniciadas em http_access para permitir (allow) ou negar (deny)  o acesso à Internet. Cabe observar que a ordem da permissão ou negação é importante e faz toda a diferença. Por exemplo, reparem que na linha 13 estamos permitindo que o grupo vip tenha acesso irrestrito à Internet antes de aplicarmos a negação ao conteúdo da blacklist (linha 15). Reparem, ainda, que na linha 16 estamos permitindo o acesso à Internet para as máquinas do grupo recepcao somente no horário de almoço, sendo que na sequência (linha 17) estamos negando todo acesso à Internet para as máquinas do grupo recepcao. Antes de ser possível permitir ou negar, tivemos que criar as correspondências ao horário do almoço (linha 09) e ao grupo recepcao (linha 10).


# Autenticação do Usuário

Através de uma ACL especial do tipo proxy_auth o Squid é capaz de solicitar credenciais de autenticação dos seus usuários (authentication header). No entanto, o processo de autenticação em si é realizado por alguma ferramenta externa ao Squid, por isso essa ferramenta complementar deve estar instalada e ser informada no arquivo de configuração squid.conf. Uma opção simples, dentre outras que fazem parte do atual pacote squid3, é o módulo NCSA (destaque em amarelo). Para utilizá-lo basta incluir as seguintes linhas em /etc/squid3/squid.conf:

###--- em /etc/squid3/squid.conf
auth_param basic program /usr/lib/squid3/basic_ncsa_auth /etc/squid3/passwd.squid
auth_param basic realm "Squid Proxy Server"
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

Outra configuração importante, assumindo que o módulo de autenticação esteja devidamente operacional no servidor, consiste em inserir uma ACL do tipo proxy_auth para que as credenciais do usuário sejam solicitadas antes de liberar a navegação.

###--- em /etc/squid3/squid.conf
acl senha proxy_auth REQUIRED
(...)
http_access deny !senha
(...)
http_access allow localnet
http_access deny all

Obs.: A opção REQUIRED indica que todos os usuários devem ser autenticados. A autenticação poderia ser aplicada apenas para alguns usuários através da ACL: acl nome proxy_auth username1 username2

Antes de reiniciar o serviço Squid precisamos criar o arquivo com a relação de usuários que será inspecionado para validar a nevagação dos clientes. Uma boa opção para gerar o arquivo com a relação de usuários/senhas é a tradicional ferramenta htpasswd (utilizada pelo Apache). Caso o usuário não tenha o Apache no sistema, é necessário instalar o pacote apache2-utils (apt-get install apache2-utils). Agora a ferramenta htpasswd pode ser utilizada para criar os usuários que serão autenticados pelo Squid.

touch /etc/squid3/passwd.squid
htpasswd /etc/squid3/passwd.squid username
(...) informar senha do username

# Páginas de Erro Personalizadas

As tradicionais páginas de erro do Squid que substituem as páginas de erro dos navegadores podem ser personalizadas com mais informações sobre a empresa e suas políticas de uso da Internet. É possível criar várias páginas de erro personalizadas para as diversas ocorrências de erro. No exemplo abaixo a página error-content.htm é exibida quando algum conteúdo cai no filtro da blacklist (linha 07), enquanto que a página denominada error-time.htm é exibida quando as máquinas do grupo recepção têm acesso negado à Internet no horário de almoço (linha 08). Por fim, na linha 09, criamos um página padrão para qualquer outra ocasião de erro no acesso à Internet.

01. ###--- em /etc/squid3/squid.conf
02. 
03. #---------------------------------------------------------------
04. # EXEMPLO DE PAGINAS DE ERRO PERSONALIZADAS
05. #---------------------------------------------------------------
06. error_directory /etc/squid3/error
07. deny_info error-content.htm black_list
08. deny_info error-time.htm recepcao
09. deny_info error.htm all
10. #---------------------------------------------------------------

Obs.: No exemplo acima optei por armazenar as páginas de erro em /etc/squid3/error/. As páginas podem ficar em outros diretórios, incluindo seus arquivos complementares (figuras e scripts). 

# Proxy Transparente

O Squid pode ser configurado para agir de maneira transparente, de forma que seus usuários não tenham que fazer nenhuma configuração adicional nos navegadores para informar a presença do servidor proxy. Essa modalidade resolve um dos grandes problemas de servidores proxy/cache, que é a necessidade de configuração individual de todos os navegadores das máquinas da empresa, uma vez que os usuários normalmente não sabem fazer essa configuração. Para implementar o proxy transparente basta compartilhar a Internet e escrever uma regra de redirecionamento no iptables do servidor, fazendo com que todo o tráfego web destinado à porta 80 seja antes redirecionado para o servidor proxy que está em execução na porta 3128. 

iptables -t nat -A POSTROUTING -o $ifWAN -s 192.168.221.0/24 -j MASQUERADE
iptables -t nat -A PREROUTING -i $ifLAN -p tcp --dport 80 -j REDIRECT --to-port 3128

Obs.: No exemplo acima estou considerando que a variável $ifWAN é a interface que possui saída para a Internet, enquanto que a variável $ifLAN é a interface que é gateway da rede local.

Além de utilizar o iptables como ferramenta complementar para implementar o proxy transparente, também é importante informar esse modo de operação no arquivo de configuração do Squid através de um parâmetro adicional no http_port:

http_port 3128 intercept

Por fim, vale reforçar que o proxy tranparente e o recurso de autenticação são excludentes, ou seja, não é possível implementar autenticação se você estiver utilizando o proxy transparente. Façam seus testes...

Samuel.