O conceito de ACL (Access Control Lists) é utilizado no Squid para estar controlando o que cada usuário acessa no navegador. A ACL é muito útil, por nos permitir trabalhar com níveis de acesso baseados em diversas informações.

Não é incomum que em uma instalação do Squid algumas situações podem acontecer, como exemplo poderíamos citar a diretoria que pode acessar qualquer site, a gerência que não pode acessar determinados sites e os funcionários da fabrica que pode acessar apenas o site da empresa e de parceiros. Graças ao uso de ACLs e um pouco de conhecimento, podemos fazer todas essas restrições.

Todas as configurações de usuários, grupos, horários e sites são configuradas em ACLs. A ordem em que as ACLs aparecem é muito importante, pois ao ser feita uma configuração no arquivo fonte do Squid ele respeita a regra que vem primeiro ou o arquivo de bloqueio, por isso a Acl que bloqueia os sites deve ser a primeira.

Outra função essencial no Squid e o suporte a autenticação que para isso se usa um recurso chamado de (ncsa_auth), que é a alternativa mais simples. Ele está disponível junto com o Squid e pode ser implementado rapidamente. É a solução ideal para pequenas e médias instalações e redes com arquitetura de grupo de trabalho.

1CGI: Consiste numa importante tecnologia que permite gerar páginas dinâmicas permitindo a um navegador passar parâmetros para um programa alojado num servidor web.

Este é um recurso bem interessante para controle pessoal de usuários, pois permite que você crie ACLs individuais e gere logs de qualidade bem superior.

Existem diversos métodos de autenticação, sendo interessante averiguar exatamente o que irá precisar com base no plano de regras.

Para controlar o acesso por usuários e grupos, podemos configurar o Squid como PDC. O (smb_auth) lê o arquivo (\netlogon\proxyauth) que por padrão e localizado no Linux, e em um dos controladores de domínio previamente informado. Se a leitura desse arquivo retorna um (allow) ou permitido , então o acesso é liberado. Caso contrário se for um (deny) o acesso é negado.

Crie um arquivo chamado (proxyauth) no compartilhamento NETLOGON de seu PDC (dê preferência ao primário). Esse arquivo deve conter unicamente a palavra (allow) e dê permissão de leitura para os grupos e usuários que deseja permitir o acesso.

O recurso de ACL externas é muito útil para um tratamento melhorado de algum recurso que não é compreendido por ACLs normais. Uma ACL externa pode ser escrita em qualquer linguagem. Ela deve sempre retornar um valor de confirmação para o (stdout) caso a condição seja satisfeita, ou retornar um erro para o (stdout), caso ela não seja satisfeita.

Para facilitar a vida dos usuários e do administrador, conforme citado por (Reguly 2006), podemos criar um arquivo de configuração automática que será colocado nos Browsers dos clientes. Dessa forma todos terão seu Proxy reconfigurado dinamicamente em caso de mudanças, sem a necessidade de intervenção em cada máquina. Esse arquivo deve ser acessível via Web e, via de regra, chama-se (proxy.pac).

A utilização de sistemas de cache, como o Squid, tem se mostrado excelentes para aliviar certos sintomas, reduzindo o tráfego na rede e, conseqüentemente, a latência da mesma ou seja a perda de banda. Toda a idéia por trás de um sistema de (caching) é criar um grande banco de dados onde os sites mais populares ou acessados recentemente sejam armazenados para futuras consultas. Isso significa que se 10 usuários da sua rede tentarem acessar um mesmo site ao mesmo tempo, somente uma das conexões realmente irá ser feita a esse site. Todas as outras 9 vão se aproveitar do primeiro acesso e utilizar a página já em memória. Isso é um enorme ganho de desempenho para seu backbone local e para o backbone do ISP1 onde o site está armazenado e também para o servidor que hospeda o mesmo.

Com todas essas configurações habilitadas e funcionando corretamente é possível diminuir consideravelmente o fluxo de informações na banda e controlar ao máximo o conteúdo acessado pelos usuários.

Podemos definir um Proxy ou cache da seguinte forma:

• Velocidade de acesso: A melhor forma de verificar se o seu cache está sendo eficiente é pela velocidade. Um sistema de cache que não agrega velocidade não está cumprindo o seu papel;
• Disponibilidade: De nada adianta um sistema veloz disponível apenas 2 horas por dia, ou mesmo que precise de um reboot a cada 2 semanas. Em casos de grandes instalações, ainda é preciso ir mais a fundo, buscando uma altíssima disponibilidade, como (Redundância de servidores, backup, eliminação de ponto único de falha);
• Transparência ou Ostensividade: São conceitos específicos e que se adaptam a cada caso. Grandes instalações, ISPs e empresas não preocupadas com que seus usuários vêem ou fazem na Internet devem preferir a transparência, onde o usuário desconhece ou não se sente afetado (exceto pelo ganho de velocidade) pela presença de um cache. Por outro lado, empresas com uma política de segurança mais rígida, órgãos com informações críticas, ou mesmo pais que queiram controlar o acesso de seus filhos a alguns sites, vão preferir a ostensividade;

1. ISP: serviço de acesso à internet, agregando a ele outros serviços relacionados, tais como "e-mail", "hospedagem de sites" ou blogs, entre outros.

• Capacidade de trabalhar com redes heterogêneas: Ele é capaz de trabalhar com diversos tipos de redes e não sendo necessário estar exclusivamente amarrado a de um fabricante de Software ou de hardware, sendo assim ele se adapta a qualquer situação. Isso é especialmente verdade quando não sabemos que tipo de plataforma iremos utilizar em nossa instalação;
• Simplicidade: Deixando um pouco de lado o usuário e focando no administrador, conforme citado por (Bastos 2006) é preciso ter consciência de que um sistema bom é um sistema fácil de administrar. O mais rápido, mais disponível e mais abrangente sistema de (caching) é totalmente inútil se somente uma pessoa no mundo souber lidar com ele.

Cache hierárquico é a extensão lógica do conceito de (caching). Um grupo de caches podem se beneficiar do compartilhamento de seus dados entre si de várias formas. Isso é facilmente explicável quando pensamos em termos regionais.

Como exemplo podemos citar o de uma empresa estabelecida em um prédio, pela qual os usuários desta empresa resolvem enviar uma requisição de acesso a um determinado site, então é repassado esta requisição ao Proxy mais próximo, na qual baixa-se diretamente as informações sem precisar sair para a Internet para baixá-la.

Fica fácil de visualizar que se todas as empresas interligassem localmente seus Proxies, todas sairiam ganhando. Na realidade, essa prática entre pequenas empresas não existe. Mas quando falamos de grandes empresas e grandes backbone, cada 1 MB economizado com (caching) é 1 MB ganho em outros serviços.

Além de trabalhar com o conceito de árvore conforme citado por (Bastos 2006), onde existe um cache principal e outros ligados a ele, o Squid trabalha também com um conceito parecido com grupo de trabalho, onde todos os servidores se consultam mutuamente. Toda a comunicação entre os caches é feita via ICP.

O ICP foi desenvolvido como parte fundamental do projeto Harvest (Pai do Squid). Seu objetivo é prover um método rápido e eficiente de obter-se comunicação entre servidores cache. O ICP permite que um cache pergunte a outro se ele tem uma cópia válida de um determinado objeto, aumentando a possibilidade de encontrar aquele objeto já (cacheado). Adicionalmente, o ICP permite que requisições trafeguem entre servidores filhos em uma estrutura de árvore.

Além do controle de cache, o ICP também gera indicações do estado da rede. O não recebimento de uma resposta ICP normalmente indica que a rota está congestionada ou que outro Host não está ativo. Além disso, a ordem de chegada de uma resposta ICP pode indicar quais hosts estão com uma distância lógica menor ou com menos carga. As mensagens ICP são geralmente bem pequenas, com cerca de 66 bytes. Em uma estrutura hierárquica, normalmente tem-se mais trocas de mensagens ICP do que HTTP.

Roteamento por domínio e outra características de configurações do Squid pode favorecer muito no desempenho.

A configuração seria assim:


Sendo que o cache 4 será o responsável por todos os domínios que não sejam os 3 anteriores.