Deprecated: Joomla\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /home/ylliagdo/public_html/libraries/vendor/joomla/input/src/Input.php on line 41

Deprecated: Return type of Joomla\Input\Input::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/ylliagdo/public_html/libraries/vendor/joomla/input/src/Input.php on line 170

Deprecated: Joomla\CMS\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /home/ylliagdo/public_html/libraries/src/Input/Input.php on line 31

Deprecated: Joomla\CMS\Input\Cookie implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /home/ylliagdo/public_html/libraries/src/Input/Cookie.php on line 21

Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /home/ylliagdo/public_html/libraries/src/Uri/Uri.php on line 141

Deprecated: Joomla\CMS\Input\Files implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /home/ylliagdo/public_html/libraries/src/Input/Files.php on line 21
Proxy Squid Completo
Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/models/item.php on line 121

Deprecated: preg_replace_callback(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /home/ylliagdo/public_html/plugins/content/dropfiles/dropfiles.php on line 78

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/models/itemlist.php on line 576

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/models/itemlist.php on line 576

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/models/itemlist.php on line 576

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/models/itemlist.php on line 576

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/models/itemlist.php on line 576

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/models/itemlist.php on line 576

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/models/itemlist.php on line 576

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/models/itemlist.php on line 576

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/models/item.php on line 121

Deprecated: preg_replace_callback(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /home/ylliagdo/public_html/plugins/content/dropfiles/dropfiles.php on line 78

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/views/item/view.html.php on line 309

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/models/item.php on line 121

Deprecated: preg_replace_callback(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /home/ylliagdo/public_html/plugins/content/dropfiles/dropfiles.php on line 78

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/views/item/view.html.php on line 350

Deprecated: Function strftime() is deprecated in /home/ylliagdo/public_html/components/com_k2/views/item/view.html.php on line 457

Deprecated: Constant FILTER_SANITIZE_STRING is deprecated in /home/ylliagdo/public_html/components/com_k2/views/item/view.html.php on line 523

Deprecated: Constant FILTER_SANITIZE_STRING is deprecated in /home/ylliagdo/public_html/components/com_k2/views/item/view.html.php on line 600

Deprecated: Constant FILTER_SANITIZE_STRING is deprecated in /home/ylliagdo/public_html/components/com_k2/views/item/view.html.php on line 625
Imprimir esta página

Proxy Squid Completo

Escrito por

Conceitos de Servidores Proxy

O objetivo principal de um servidor proxy é possibilitar que máquinas de uma rede privada possam acessar uma rede pública, como a Internet, sem que para isto tenham uma ligação direta com esta. O servidor proxy costuma ser instalado em

uma máquina que tenha acesso direto à internet, sendo que as demais efetuam as solicitações através desta. Justamente por isto este tipo é chamado de Proxy, pois é um procurador, ou seja, sistema que faz solicitações em nome de outros.

Um servidor proxy para o protocolo http, por exemplo, pode ter outras funcionalidades implementadas. Visto que todas as solicitações de páginas efetuadas pelas máquinas da rede privada serão feitas através dele, é muito útil armazenar localmente as páginas que foram solicitadas, permitindo que os próximos acessos, efetuados por quaisquer máquinas da rede, possam ser otimizados. Este conceito é chamado de caching, e vários servidores proxy na verdade são servidores proxy cache. Pelo mesmo motivo, também é possível implementar uma funcionalidade que permita controlar o que os clientes podem acessar e em que momento. Um servidor proxy também pode implementar o NAT (Network Address Translation – Tradução de Endereços de Rede). O NAT é tecnicamente a função de um portal de nível de rede, mas alguns fornecedores também incluem este recurso em seus produtos e servidores proxy.

 

Definição de Squid

Squid é um proxy-cache de alta performance para clientes web, suportando protocolos FTP, gopher e HTTP.

O Squid mantém meta dados e especialmente objetos armazenados na RAM, cacheia buscas de DNS e implementa cache negativo de requests falhos.

Ele suporta SSL, listas de acesso complexas e logging completo. Por utilizar o Internet Cache Protocol, o Squid pode ser configurado para trabalhar de forma hierárquica ou mista para melhor aproveitamento da banda.

Podemos dizer que o Squid consiste em um programa principal - squid -, um sistema de busca e resolução de nomes - dnsserver - e alguns programas adicionais para reescrever requests, fazer autenticação e gerenciar ferramentas de clientes.

Podemos executar o Squid nas principais plataformas do mercado, como Linux, Unix e Windows.

Benefícios de usar o proxy SQUID

 

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.

Redundância de servidores, backup, eliminação de ponto único de falha e disaster recover são uma exigência.

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 querendo controlar o acesso de seus filhos a alguns sites, vão preferir a ostensividade.

Capacidade de trabalhar com redes heterogêneas

Alguns sistemas de proxy/cache funcionam baseados com sistemas de autenticação especiais, feitos para rodar somente em uma plataforma, fazem integração com o serviço de diretórios daquele ou desse sistema ou exigem que o usuário esteja rodando a versão XYZ do fabricante ABC e deixam todos os outros a ver navios. Em uma instalação séria, é preciso que usuários de todas as plataformas que saibam como trabalhar com HTTP sejam bem atendidos.

Isso é especialmente verdade quando não sabemos que tipo de plataforma irá utilizar nossa instalação.

Simplicidade

Deixando um pouco de lado o usuário e focando no administrador, é 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.

Motivos pelo qual se deve utilizar um PROXY/CACHE:

Controle de acesso

 

Com a internet cada vez mais acessível a pequenas e médias empresas, um número imenso de pessoas está se interligando a internet. Além de todos os benefícios trazidos por ela, como informação em tempo real, comunicação mundial a baixo custo, contato com possíveis clientes e
fornecedores por todo o mundo, a mesma trouxe alguns problemas.

As pessoas tendem a passar cada vez mais tempo navegando por sites não relativos ao seu trabalho primário, acessam sites que não condizem com a política da empresa, utilizam a banda de internet destinada a serviços como WEB ou VPN e podem, em muitos casos, acabar infectando
toda a rede da empresa com vírus e worms que são adquiridos em sites impróprios. Isso sem contar na ameaça sempre presente de propagação de downloads de softwares piratas e músicas, fatores que podem complicar a vida de uma empresa durante fiscalizações.

De acordo com a Rede Nacional de Ensino e Pesquisa (RNP) , 65% da largura de banda das empresas é utilizada em navegação WEB. E esse número tende a crescer.

Performance

 

Como dissemos anteriormente, a internet está mais acessível para todos, fator causado pela ampla utilização das conexões de banda larga, como xDSL, Cable Modem, ISDN, etc.

Essas tecnologias são excelentes para pequenas e médias empresas, mas devido a suas características de velocidades diferentes de upstream e downstream (xDSL), compartilhamento de banda total (Cable Modem) ou baixo desempenho (ISDN), além da notável falta de qualidade das
operadoras, tornam-se quase inúteis para grandes empresas e provedores de internet (ISPs).

Essas empresas são então levadas a utilizar sistemas de maior qualidade, como links por fibra ótica, satélites e rádio. Mas como se pode esperar, qualidade tem preço, e, nesse caso, bem salgado.

Visando aproveitar ao máximo essa banda de qualidade, a utilização de PROXY/CACHE torna-se quase que obrigatória. Ainda de acordo com a Rede Nacional de Ensino e Pesquisa (RNP) - 2, a utilização de PROXY/CACHE pode gerar uma economia entre trinta e cinqüenta por cento nos horários de pico. Isso significa que para um link de 2 Mbps que está operando a plena carga e considerando uma redução de 30 %, o mesmo produziria um ganho na banda agregada de aproximadamente 600 Kbps. Ou seja, a simples implementação de um PROXY/CACHE bem ajustado gera uma economia da ordem de milhares de Reais por mês para a empresa.

Porque utilizar o SQUID?

O Squid está continuamente melhorando sua performance, além de adicionar novas features e ter uma excelente estabilidade em condições extremas.

Sua compatibilidade com várias plataformas e a imensa gama de software para analisar logs, gerar relatórios, melhorar o desempenho e adicionar segurança providos pela comunidade open source, combinados com ferramentas de administração simplificada e baseadas em web
agregam grande valor ao produto.

Podemos ainda citar a capacidade de clustering, transparent proxy, cache de FTP e, é claro, seu baixo custo.

Para os mais corajosos, ou para os melhores programadores, não podemos deixar de dizer que o sistema é totalmente aberto, possibilitando a sua otimização no nível de código, além da otimização via configuração.


Deprecated: MPFInput implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /home/ylliagdo/public_html/administrator/components/com_osmembership/libraries/mpf/input/input.php on line 23

Planos de Assinatura

 

Instalação do SQUID

 

O Squid pode ser instalado em uma imensa variedades de sistemas operacionais. Praticamente todos os Unixes com um bom compilador C/C++ pode gerar binários do Squid.

Sua popularidade, no entanto, nos poupa esse passo em muitas plataformas.

Instalando em um sistema baseado em Debian

O Debian sempre prezou pela facilidade de instalação a atualização de pacotes, com seu sistema apt, que facilita muito a vida dos administradores. Para instalar o squid basta executar o comando:

  # apt-get install squid

Comandos básicos

Resetando o cache do squid

Pode ocorrer do squid travar alguma vez. Para tentar resolver isso, pare o squid e execute:

  # squid -z

 

Reiniciando as configurações do squid

Se você mudou alguma ACL, atualizou a lista de sites ou qualquer coisa que exija refazer as regras do squid que está rodando, utilize:

  # squid -k reconfigure

 

Ativando os serviços do Squid

 

# /etc/init.d/squid stop

# /etc/init.d/squid start

 

Verificando as portas ativas

 

# netstat –atun | grep 3128

Entrando em modo Debug

Você pode modificar o Squid para modo Debug on the fly utilizando o seguinte comando:

  # squid -k debug

O resultado do modo debug estará no arquivo cache.log, dentro do diretório de logs.

ATENÇÃO: A quantidade de logs gerada por esse modo é muito grande e irá causar lentidão no sistema. Não deixe essa opção habilitada por default.

 

Baixando o código-fonte

Caso queira o controle de banda, que é um tópico avançado, instale o squid pelo fonte, de acordo com as instruções.

Verifique a versão mais recente em
http://www.squid-cache.org/Versions/

  # wget http://www.squid-cache.org/Versions/v2/2.6/squid-2.6.STABLE16.tar.gz  # tar zxvf squid-2.6.STABLE16.tar.gz   # cd squid-2.6.STABLE16   # ./configure --enable-removal-policies=”lru, heap” --enable-icmp --enable-delay-pools --enable-snmp --enable-ssl --enable-arp-acl --enable-htcp --disabled-http-violations --enable-kill-parent-hack --enable-linux-netfilter –enable-heap-replacement -- enable-cache-digests –disable-internal-dns  # make all   # make install   # cd auth_modules/NCSA   # make   # make install

Opções de compilação

--enable-useragent-log - adiciona o log do cabeçalho "useragent";--enable-referer-log - adiciona o log do cabeçalho "referer";--enable-removal-policies="heap lru" - habilita as políticas de remoção de cache em memória;--enable-err-languages="Portuguese English Spanish" - idioma das páginas de erro;--enable-default-err-language=Portuguese - usa como padrão o idioma pt_BR nas páginas de erro;--enable-linux-netfilter - adiciona suporte a proxy transparente;--enable-underscores - adiciona suporte a sublinhado;--enable-auth="basic digest ntlm" - habilita os esquemas de autenticação;--enable-basic-auth-helpers="PAM YP SMB SASL NCSA LDAP winbind" - habilita os módulos que poderão ser usados para autenticação.

Para mais informações consulte com o parâmetro:

# ./configure --help

 

Arquivo de configuração do Squid

O arquivo de configuração do squid é o squid.conf, normalmente ele se encontra em /etc/squid.conf ou em /usr/local/squid/etc/squid.conf. Caso não encontre o seu em nenhum desses lugares, procure-o com:

  # locate squid.conf        ou    # find squid.conf

Pode parecer fútil, mas uma limpeza inicial no arquivo squid.conf pode ser bem útil. O arquivo de configuração original tem, em média, 2000 linhas.

  # cp squid.conf squid.conf.original   # egrep -v "^#|^$" squid.conf.original > squid.conf  Detalhes

Entre várias opções de configurações do Squid, algumas merecem atenção especial, pois definem o funcionamento básico do programa.

http_port n - esta opção é utilizada para definir em quais portas (n) o squid espera por conexões http. A porta padrão é 3128, mas é possível especificar uma outra qualquer, dependendo da necessidade.

Exemplo: http_port 3128

cache_dir Tipo diretório Mbytes Nível-1 Nível-2 - esta opção serve para definir em quais diretórios serão armazenados os objetos. Tipo especifica o tipo de sistema de armazenamento a ser utilizado. Atualmente o tipo que pode ser utilizado com segurança é ufs.

Diretório especifica o nome do diretório onde há o arquivo que mantém os metadados dos objetos armazenados no disco. Este arquivo é utilizado para recriar o cache durante a inicialização do Squid. Mbytes especifica a quantidade de espaço em disco que deverá ser utilizada sob este diretório.

O valor padrão é 100 MB. Nível-1 e Nível-2 especificam o número de diretórios de primeiro e segundo nível, respectivamente, a serem criados, definindo na opção Diretório. Os valores padrão são 16 e 256, respectivamente. É possível ter vários diretórios para cache, inclusive em discos distindos.

Exemplo: cache_dir ufs /var/spool/squid 100 16 256

cache_mgr e-mail - esta opção permite especificar o e-mail do usuário do sistema que receberá uma mensagem caso o Squid venha a ser encerrado de forma anormal. Este endereço também é mostrado em páginas de erros retornadas aos usuários caso, por exemplo, a máquina remota não possa ser acessada.

Exemplo: cache_mgr Este endereço de email está sendo protegido de spambots. Você precisa do JavaScript ativado para vê-lo.

cache_efective_user usuarop, cache_efective_group grupo - estas opções servem para informar ao Squid com qual ID de usuário e de grupo, respectivamente, ele deve ser executado, caso seja iniciado como root, que é como ele costuma ser iniciado.

Exemplo:

cache_efective_user squid

cache_efective_group squid

cache_mem mem - o Squid utiliza muita memória por razões de desempenho. É muito mais demorado ler algo do disco do que diretamente da memória como todos sabem. Mas deve-se estar atento ao definir este valor, pois esse parâmetro não é o total de memória que o Squid usa, ele apenas põe um limite em um dos aspectos da memória. Mas ele usa memória para outras atividades, assim, é necessário reservar espaços para os outros processos.

Para verificar quanta memória o squid esta utilizando, podemos utilizar o comando top, por exemplo.

Exemplo: cache_mem 8MB

visible_hostname computador - esta opção define o nome do computador que aparece em mensagens de erro e em outras informações compartilhadas entre servidores cache. Colocar o nome do computador local.

Exemplo: visible_hostname micro_00

 

ACL (Access Control List)

 

Insert your own Rules (s)

 

            Essa é a parte fundamental do projeto. É onde será empregada todas as Access Control Lists (Também conhecidas como ACL's) da implementação da segurança da rede.

O controle de acesso do Squid tem recursos suficientes para definir com precisão quais tipos de serviços podem ser acessados por quais máquinas e em quais horários. As regras da lista de controle de acesso (Access Control List ou simplesmente ACLs) tem uma sintaxe bastante simples e são incluídas no arquivo squid.conf.

 

Tipos de elementos de ACL:

src: endereço IP de origem (cliente);

dst: endereço IP de destino (servidor);

srcdomain: um domínio de origem (cliente);

dstdomain: um domínio de destino (servidor);

srcdom_regex: padrão de texto, ou expressão regular, que conste no conteúdo da origem (cliente);

dstdom_regex: padrão de texto, ou expressão regular, que conste no conteúdo do destino (servidor);

time: Hora e dia da semana. Especifica um determinado horário.

url_regex: comparação de URL baseada em expressão regular. Utilizado para comparar uma string à uma URL inteira. Muito utilizado para fazer o bloqueio de sites indevidos.

urlpath_regex: Tem uma função semelhante à anterior, porém procura apenas em pedaços do caminho da URL. Muito utilizado para bloquear extensões, como veremos mais à frente.

port: número da porta do destino (servidor);  Usado para especificar acesso à determinada porta de um servidor.

myport: número da porta local na qual o cliente se conectou;

proto: especifica um protocolo de transferência (http, ftp, etc);

method: método http de requisição (get, post, etc);

browser: Comparação executada baseada no cabeçalho (header) do cliente (browser);

ident: nome do usuário;

src_as: número do Sistema Autônomo da origem (cliente);

dst_as: número do Sistema Autônomo do destino (servidor);

proxy_auth: Somente utilizada caso você esteja utilizando autenticação. Serve para especificar nomes de usuários. Filtro por usuários autenticados.

proxy_auth_regex: expressão regular que consta em uma autenticação de usuário via um processo externo;

snmp_community: string que indica o nome da comunidade SNMP;

maxconn: um número máximo de conexões de um mesmo endereço IP de cliente. Filtro por conexões.

arp: endereço Ethernet (MAC Address).

port: filtro por porta.

Nem todos os elementos de ACL podem ser usados com todas as listas de acessos (descritas a seguir). Por exemplo, snmp_community só terá significado quando usado com a lista snmp_access, bem como os elementos src_as e dst_as somente serão usados na lista cache_peer_access.

Cada elemento de ACL deve ser relacionado com somente um nome. Um elemento ACL com determinado nome consiste em uma lista de valores. Quando forem sendo feitos os testes, os múltiplos valores utilizarão o operador lógico OR. Em outras palavras, um elemento ACL será válido, quando qualquer um de seus valores for verdadeiro.

Você não pode dar o mesmo nome para diferentes tipos de elementos ACLs. Isto ocasionará um erro de sintaxe.

Você poderá colocar diferentes valores para a mesma ACL em diferentes linhas. O Squid os combinará em uma lista.

Lista de acessos

http_access: permite clientes http (browsers) acessarem a porta http. Esta ACL é a primária;

icp_access: permite caches "vizinhos" fazerem requisições ao seu cache através do protocolo ICP;

miss_access: permite a alguns clientes fazerem encaminhamento (forward) através de seu cache;

no_cache: define respostas que não deverão ser armazenadas no cache;

always_direct; controla quais requisições deverão ser sempre encaminhadas diretamente aos servidores de origem;

never_direct: controla quais requisições nunca deverão ser sempre encaminhadas diretamente aos servidores de origem;

snmp_access: controla acesso ao agente SNMP do squid;

cache_peer_access: controla quais requisições poderão ser encaminhadas a um servidor de cache vizinho. (peer)

Uma regra de lista de acesso consiste da palavra allow (permitir) ou deny (negar), seguido de uma lista de nomes de elementos ACL. Uma lista de acesso consiste em uma ou mais regras de acesso.

As listas de acesso são verificadas na mesma ordem em que foram escritas. A pesquisa na lista termina assim que uma requisição satisfazer uma regra.

Se uma regra possuir múltiplos elementos de ACL, esta usará o operador lógico AND. Em outras palavras, todos os elementos de uma regra precisarão ser validos para que esta regra seja válida. Isto significa que é possível escrever uma regra que nunca será válida. Por exemplo, um número de porta nunca poderá ser igual a 80 e 8000 ao mesmo tempo.

 

Alguns exemplos práticos:

Se você quiser impedir que qualquer usuário acesse páginas que contenham a palavra "sexo" na URL, acrescente as seguintes linhas no seu squid.conf:

acl proibir_cracker url_regex cracker

http_access deny proibir_cracker

 

E o bloqueio ainda pode ser para máquinas específicas. Imagine que o usuário da máquina cujo IP é 192.168.0.7 esteja ocupando muito a sua rede, transferindo arquivos de música em formato MP3. Para bloquear este usuário específico, use a regra como abaixo:

acl mp3 url_regex mp3

acl usr_ofensor src 192.160.0.7/255.255.255.255

http_access deny usr_ofensor mp3


Se quiser proibir todos os usuários de acessarem um determinado site:

acl site_proibido dstdomain .orkut.com
http_access deny all site_proibido

 

Também é possível permitir ou proibir o acesso em determinados dias e horários:

acl tempo_proibido time MTWHF 15:00-16:00
acl usr_ofensor src 192.168.0.7/255.255.255.255
http_access deny usr_ofensor tempo_proibido

 

A regra acima bloqueia o acesso à internet para o IP 192.168.0.7 durante o período das 15:00 às 16:00 horas. A opção MTWHF indica os dias da semana em inglês. Também podem ser utilizadas as opções A e S que equivalem ao sábado e ao domingo respectivamente.

Existem casos que uma empresa gostaria de liberar o acesso à internet apenas durante o horário de almoço. Para isso, a seguinte regra poderia ser aplicada:

acl funcionários src 192.168.0.0/0

acl acesso_almoco time MTWHF 12:00-13:00

http_access allow funcionários acesso_almoco

http_access deny funcionários

 

Dependendo do número de domínios ou de palavras-chave listadas em ACLs é aconselhável construir uma lista em um arquivo separado e indicá-lo no squid.conf. O arquivo com uma lista de domínios ou de expressões regulares a serem bloqueadas deve conter uma entrada por linha, como no exemplo:

Orkut
Sexo

Facebook
Blog
Fotolog

 

Caso o arquivo seja salvo em /etc/squid/sites_proibidos, por exemplo: podemos indicá-lo no arquivo de configuração do squid da seguinte maneira:

acl funcionários src 192.168.0.0/0

acl proibidos url_regex "/etc/squid/sites_proibidos"

http_access deny funcionários proibidos

 

Após incluir todas as suas regras restritivas, não se esqueça de incluir regras especificando que tudo o que não estiver expressamente proibido deve ser permitido. Na configuração original do squid.conf, as linhas serão como a que segue:

acl funcionários src 192.168.0.0/0

acl proibidos url_regex "/etc/squid/sites_proibidos"

http_access deny funcionários proibidos

 

Após incluir todas as suas regras restritivas, não esqueça de incluir regras especificando que tudo o que não estiver expressamente proibido deve ser permitido. Na configuração original do squid.conf, as linhas serão como a que segue:

acl rede_local src 192.168.0.0/255.255.255.0

http_access allow all rede_local

 

Observe que você deve definir a "rede_local" como conjunto de endereço IP e máscara que melhor descrevem a sua rede.

Normalmente o seu squid.conf virá com linhas como as que seguem:

#
# INSERT YOUR OWN RULE(S) HERE ALLOW ACCESS FROM YOUR CLIENTS
#
http_access deny all

 

Ela serve para bloquear o acesso ao Squid até que ele seja configurado, e é interessante você deixá-lo como última regra, pois desta forma, se a requisição não satisfazer nenhuma regra o squid irá bloqueá-la.

Examinando o squid.conf

Alterações bem feitas e pensadas podem trazer um grande ganho para a performance de seu cache, enquanto um erro de configuração pode impedir seu Squid de trabalhar ou remover muitas de suas funcionalidades.

É importante alterar as opções com cuidado e ter a certeza de que realmente necessita fazer a mudança planejada.

Tags da seção Network

Essa seção explica todos os parâmetros de endereços de redes relevantes para uma instalação do Squid.

http_port

O número da porta onde o Squid irá ouvir as requisições dos clientes.

O padrão é 3128. Essa opção será ignorada quando o squid é iniciado com a opção "-a" na linha de comando.

Você pode espeficicar múltiplas portas, em qualquer uma das três formas: somente a porta, por hostname e porta ou IP e porta. Se você espeficiar um hostname ou endereço IP, então o Squid irá ouvir naquele endereço especificado.

http_port porta

http_port ip:porta

hostname: porta

icp_port

Especifica o número da porta na qual o squid irá enviar e receber solicitações ICP de outros Cache Servers. Para desabilitar, basta colocar um 0. Padrão: 3130

Como já dito anteriormente, o ICP é usando para comunicação entre caches, provendo as funcionalidades necessárias para troca de informações sobre objetos armazenados.

icp_port porta

 

htcp_port

Especifica o número da porta através do qual o Squid irá receber e enviar requisições HTCP de e para caches vizinhos. Para desabilitar, colocar 0. O padrão é 4827.

Specify the port number through which Squid sends and receives HTCP queries to and from neighbor caches. To disable "0" is used (default = 4827).

htcp_port porta

 

mcast_groups

Especifica uma lista de grupos multicast, no qual seu servidor pode juntar-se para receber requisições ICP. Padrão = none

mcast_groups Endereço_IP

 

tcp_outgoing_address

É usado para conexões feitas em servidores remotos. Também é usado para comunicar-se com outros caches durante o uso de HTCP ou CARP.

Normalmente não deve-se especificar tcp_outgoing_address. A melhor opção é deixar o sistema operacional escolher um endereço. Padrão: 255.255.255.255

tcp_outgoing_address Endereço_IP

 

udp_incoming_address

É usado pelo socket ICP para receber pacotes de outros caches. Padrão: 0.0.0.0

udp_incoming_address Endereço_IP

 

udp_outgoing_address

É usado pelo socket ICP para enviar pacotes a outros caches. Padrão: 255.255.255.255

udp_outgoing_address Endereço_IP

 

 

Tags da seção Peer cache servers e Squid hierarchy

 

As tags dessa seção são relevantes quando rodando o Squid em uma rede com hierarquia.

 

cache_peer

Especifica outros caches na hierarquia. A opção cache_peer é dividida em 5 campos. O primeiro campo é o IP ou nome do servidor do cache que será pesquisado. O segundo indica o tipo de relacionamento. No terceiro configura-se a porta HTTP do servidor destino. No quarto campo configura-se a porta de requisição ICP e, finalmente, o quinto campo pode conter zero ou algumas palavras-chave.

cache_peer hostname tipo porta_http porta_icp [opções]


Parâmetros  -------- Descrição

 

Hostname (FQDN) ou endereço IP do cache a ser pesquisado.

tipo: especifica-se a hierarquia de cache definida. Opção importante para escolha de regras de vizinhança.

Opções:

Parent

sibling

multicast

porta_http - o número da porta onde o cache ouve as requisições http.

porta_icp - o número da porta onde o cache ouve as requisições http.

Opções

Descrição

proxy-only

Especifica que os objetos desse servidor não devem ser salvos localmente

Weight=n

Especifica o peso de um "pai". Deve ser um valor inteiro, sendo que o padrão é 1. Servidores com um peso maior tem preferência

ttl=n

Especifica o tempo de vida de um multicast

no-query

Essa opção será utilizando quando fazendo requisições a caches que não aceitam ou não suportam ICP. Caso utilize essa opção, configure o quarto campo como 0

default

Se esse cache será usado como uma última opção e ele não está configurado para trabalhar com ICP, entãp utilize essa opção. Ele não será o padrão, mas sim a última opção, apesar do que indica o nome da tag

round-robin

Define uma série de "pais" que podem ser usados baseados em algorítimo round-robin.

multicast-responder

Indica que o servidor indicado é membro de um grupo de multicast.

closest-only

Indica que, para uma resposta ICP_OP_MISS, nós somente iremos passar CLOSEST_PARENT_MISS e nunca FIRST_PARENT_MISS.

no-digest

Não faz requisições tipo digest para esse vizinho.

no-netdb-exchange

Desabilita requisições ICMP RTT desse vizinho

no-delay

Evita que esse vizinho seja influenciado por uma delay pool.

login=usuário:senha

Caso esse servidor exija autenticação.

connect-timeout=nn

Especifica o time out para essa conexão.

digest-url=url

Diz ao Squid para buscar o resumo do cache utilizando essa URL.

cache_peer_domain

Limita o domínio para qual cada vizinho será requisitado. É usado para enviar requisições para caches diferentes dependendo do domínio.

  • Colocar um '!' antes do domíno significa que o cache irá armazenar o que não for para tal.
  • Podemos colocar tantos domínios quanto necessário por cache, tanto na mesma linha como em linhas separadas.
  • Quando múltiplos domínios são dados para um único cache, o primeiro domínio é plicado.
  • Cache hosts sem domínio irão aceitar todos os pedidos

cache_peer_domain cache_host domínio [domínio]

neighbor_type_domain

Modifica o tipo do servidor vizinho dependendo do domínio. Você pode tratar domínios de forma diferente quando um servidor padrão é usado na tah cache_peer.

neighbor_type_domain parent|sibling domínio [domínio]

 

icp_query_timeout

Definição para o timeout de uma requisição ICP.

Visto que o Squid irá automaticamente determinar um valor ideal baseado em requisições recentes, é bom não alterar essa opção.

icp_query_timeout milisegundos

 

maximum_icp_query_timeout

Tempo máximo de expiração de uma requisição ICP. A resposta não será mais esperada depois desse tempo.

maximum_icp_query_timeout milisegundos

 

mcast_icp_query_timeout

Normalmente o Squid envia pacotes de teste para os endereços multicast para determinar quais servidores estão na escuta. Essa opção determina quanto tempo o Squid irá esperar por uma resposta.

Como o Squid fica aguardando resposta, não coloque um valor muito alto. O padrão está OK. 2000 ms.

mcast_icp_query_timeout milisegundos

 

dead_peer_timeout

Controla quanto tempo o Squid leva para declarar um servidor como morto. Se nenhuma requisição ICP for respondida nesse tempo, o Squid continuará mandando requisições ICP, mas não esperará por resposta. O servidor será novamente marcado como vivo depois que uma determinada seqüência de respostas for enviada. Padrão de 10 segundos.

dead_peer_timeout segundos

 

hierarchy_stoplist

Uma lista de palavras que, encontradas na URL, farão com que o objeto seja manipulado automaticamente por esse cache.

hierarchy_stoplist palavras

 

no_cache

Uma lista de elementos de uma ACL, onde, se encontrados, impedem o objeto de ser cacheado.

no_cache deny|allownomeacl

 

Tags da seção Cache size

Descreve os parâmetros relacionados ao tamanho da memória utilizada pelo cache, assim como a política de rotatividade na memória. O Squid suporte mais que uma política de rotatividade de memória.

 

cache_mem

Especifica o número ideal de memória usado para:

  • Objetos em trânsito
  • Objetos "quentes"
  • Objetos com negativa de cache

O tamanho dos dados para esses objetos são definidos em blocos de 4 KB. Esse parâmetro especifica o limite ideal para os blocos alocados.

Objetos em transito tem prioridade sobre os outros. Quando espaço adicional é necessário para novos dados, objetos "quentes" e com negativa de cache são liberados. Padrão de 8MB.

cache_mem 8MB

cache_swap_low

Especifica o limite mínimo para substituição de um objeto. A substituição começa quando o swap em disco está acima do limite mínimo. Padrão de 90.

cache_swap_low porcentagem

 

cache_swap_high

Justamente o oposto da opção anterior. Aqui se define o limite máximo. Padrão de 95.

cache_swap_high porcentagem

 

maximum_object_size

A definição dessa propriedade deve ser analisada com critério, visto que limitamos aqui o tamanho máximo de um objeto em cache. Objetos maiores do que o limite especificado não são salvos no disco.

Para definir como configurar o tamanho máximo nessa opção, deve-se levar em consideração que um número grande implica em maior economia de banda e perda de performance no cache local, enquanto um número menor não ajuda muito em ganho de banda, mas melhora a velocidade em tempo de resposta. Recomenda-se a utilização de uma valor entre 4 e 16 MB. No padrão será utilizado 4096 kB.

maximum_object_size bytes

minimum_object_size

Objetos menores do que esse valor não serão armazenado em cache. O valor padrão é 0, o que significa que todos os objetos serão armazenados.

minimum_object_size bytes

 

maximum_object_size_in_memory

A definição dessa propriedade deve ser analisada com critério, visto que limitamos aqui o tamanho máximo de um objeto em cache. Objetos maiores do que esse limite não são salvos em disco.

Para definir como configurar o tamanho máximo nessa opção, deve-se levar em consideração que um número grande implica em maior economia de banda e perda de performance no cache local, enquanto um número menor não ajuda muito em ganho de banda, mas melhora a velocidade em tempo de resposta. Recomenda-se a utilização de uma valor entre 4 e 16 MB.

maximum_object_size_in_memory bytes

 

ipcache_size

Especifica o tamanho do cache de ip.Padrão de 1024.

ipcache_size número_entradas

 

ipcache_low

Especifica o número mínimo de IPs cacheados. Padrão de 90.

ipcache_low porcentagem

 

ipcache_high

Especifica o número máximo de IPs cacheados. Padrão de 95.

ipcache_high porcentagem

 

fqdncache_size

Especifica o número máximo de FQDNs cacheados. Padrão de 1024.

fqdncache_size número_entradas

 

cache_replacement_policy

Define qual objeto será mantido na memória e qual será removido para criar espaço para novos objetos.

Opção

Descrição

LRU

A opção padrão utilizada pelo Squid. Mantém em cache objetos referenciados a recentemente, ou seja, começa removendo do cache o objeto que foi referenciado a mais tempo.

heap GDSF

Tem a filosofia de mantém em cache objetos menores, referenciados mais vezes, gerando uma maior possibilidade de fornecer um hit.

heap LFUDA

Mantém os objetos mais populares em cache, independente de seu tamanho.

heap LRU

Política LRU acrescida do uso de pilhas.

cache_replacement_policy política

memory_replacement_policy

Determina quais objetos são removidos da memória quando é preciso liberar espaço. Segue as mesmas políticas do cache_replacement_policy.

memory_replacement_policy política

 

Tags da seção Log file path names and cache directories

Descreve os parâmetros para configuração dos diretórios de cache e log em disco. Os arquivos de log são importantes não só para troubleshooting, mas também para geração de relatório e observação de anomalias.

É recomendável que você utilize-se de uma política de rotacionamento de log, como o log-rotate.

cache_dir

Diretório onde serão armazenados os objetos. É possível criar-se vários diretórios de cache, mas isso só irá fazer sentido se os mesmo forem em partições (ganho de espaço) ou discos (ganho de velocidade) separados.

Tipo: Especifica o tipo de arquivo a ser criado. Utilize o ufs. A opção aufs deve ser utilizada quando em um Linux ou Solaris com I/O Assíncrono.

tamanho_máx_obj: Refere-se ao tamanho máximo do objeto que será armazenado nesse diretório.

nome_diretório: É o raiz do diretório de cache. Caso esteja utilizando um disco separado para o cache, será o ponto de montagem. O diretório já deve existir previamente e o usuário do Squid deve ter direito a escrita nele.

Mbytes: Quantidade de espaço em disco ocupado por esse diretório. Definido em MB.

nível-1: Número de subdiretórios de primeiro nível criados sob o diretório principal.

nível-2: Número de subdiretórios de segundo nível que será criado abaixo de cada subdiretório de primeiro nível.

cache_dir tipo tamanho_máx_obj nome_diretório Mbytes nível-1 nível2

cache_access_log

Especifica o caminho para o arquivo de logs de acesso, o qual guarda todas as requisições e atividades de clientes. Os detalhes do log podem ser customizados como log_mime_hdrs, log_fqdnm client_netmask e emulate_httpd_log. Padrão: /var/log/squid/access.log.

cache_access_log path_diretório/nome_arquivo

cache_log

Configura o caminho para o log de cache. Esse arquivo irá conter informações gerais sobre o comportamento do Squid. Padrão: /var/log/squid/access.log.

cache_log path_diretório/nome_arquivo

cache_store_log

Diz qual o caminho do log de armazenamento. Esse arquivo contém detalhes sobre o processo de armazenamento em disco, podendo fornecer informações como quais arquivos foram removidos do cache, quais foram mantidos e por quanto tempo. Padrão: /var/log/squid/store.log.

cache_store_log path_diretório/nome_arquivo

cache_swap_log

Caminho para o arquivo swap.log. Esse arquivo contém metadados sobre objetos salvos em disco, podendo ser utilizado para dar um "rebuld" no cache durante a inicialização. Normalmente ele fica armazenado no primeiro diretório de cache, mas pode ter o caminho alterado com essa opção. Esse arquivo não pode ser rotacionado.

Se você tem mais de um cache_dir, então o seu arquivo de log de swap terá nomes como:

  • cache_swap_log.00
  • cache_swap_log.01
  • cache_swap_log.02

cache_ swap _log path_diretório/nome_arquivo

emulate_httpd_log on|off

O Squid tem a habilidade de emular o log de servidores web. Para utilizar essa opção, basta configurar com "on". Se você não tem nenhuma aplicação específica para utilização do log em formato web, a sugestão é que seja mantido no padrão do Squid, visto que será mais simples
encontrar ferramentas de análise de logs nesse padrão.

emulate_httpd_log on|off

log_ip_on_direct

Ativa/Desativa a opção de loggin para um IP destino em uma hierarquia quando o cache direciona a requisição de um servidor origem.

log_ip_on_direct on|off

mime_table

Configura a tabela MIME do Squid. Esse arquivo irá conter os tipos
MIME suportados pelo Squid.

mime_table path_diretório/nome_arquivo

log_mime_hdrs on|off

Grava tanto as requisições quanto as respostas MIME no cabeçalho de cada transação HTTP. Os cabeçalhos irão aparecer em 2 partes diferentes no access.log.

log_mime_hdrs on|off

user agent_log

Para utilizar essa opção, o Squid precisa ter sido compilado com a opção "--enable-useragent_log". Com isso será possível agravar em um log o User-Agent de todas as requisições http. Desabilitado por padrão.

useragent_log path_diretório/nome_arquivo

referer_log

Também necessita que o Squid tenha sido compilado com uma opção extra: "--enable-referer_log". Esse log irá guardar todas as referências das requisições HTTP. Desabilitado por padrão.

referer_log path_diretório/nome_arquivo

pid_filename

Especifica em qual arquivo será arquivado o PID dos processos do
Squid.

pid_filename path_diretório/nome_arquivo

debug_options

Como os logs são configurados por nível, podemos configurar o tanto de informações que o Squid irá gerar para nossa análise. Recomendo que utilize o padrão, exceto se estiver tendo algum problema que não possa ser facilmente diagnosticado. Quanto menor o nível de log, menos
informações serão geradas. Usando a palavra ALL, podemos configurar o nível de log em todos de uma única vez. Padrão: ALL, 1.

debug_options seção,nível

log_fqdn

Pode ser configurado como ON, se você deseja logar o FQDN no
access.log. Por padrão está desabilitado.

log_fqdn on|off

client_netmask

A máscara de rede para o endereço de clientes e saída do cachemgr.
Utilize o padrão como melhor opção.Padrão: 255.255.255.255.

client_netmask máscara_rede

 

Tags da seção Support for External functions

 

Solicita certas funções externas que não são parte do binário do Squid. Esse executáveis normalmente são relacionados a DNS, FTP, redirecionamento e autenticação.

Eles são chamados pelo Squid através de fork() ou exec() padrão. O número de forks filhos será especificados para cada processo externo.

Parâmetros relevantes para essa seção:

ftp_user

Essa tag é utilizada se você deseja que o login anônimo seja mais informativo. Coloque alguma informação significativa como Este endereço de email está sendo protegido de spambots. Você precisa do JavaScript ativado para vê-lo.. Padrão: Squid@.

ftp_user nome_usuário

ftp_list_width

O tamanho da largura da lista dos arquivos do ftp. Um número muito pequeno irá cortar nomes de arquivos grnades quando navegando em sites web. Padrão: 32


ftp_list_width número

ftp_passive

Se o seu firewall não permite que o Squid use conexões passivas, desligue essa opção.

ftp_passive on|off

cache_dns_program

Define-se aqui o caminho para o executável do dns lookup. Essa opção só está disponível se o Squid for compilado com a opção --disable-internal-dns.

O programa de dns externo usa as bibliotecas de resolução, provendo um cliente de dns muito mais amadurecido e confiável. Caso não haja nada de estranho com sua resolução de DNS do Squid, mantenha o resolver interno.

cache_dns_program programa

dns_children

Número de processos simultâneos para o serviço de DNS. Para servidores com grande load, pelo menos 10 filhos devem ser iniciados. O máximos fica em 32 filhos, sendo o padrão 5. Novamente é preciso ter compilado o Squid especialmente para suporte a DNS externo. Quanto mais rápida a resolução DNS, melhor o desempenho geral do sistema. Tendo isso em
mente, utilize 32 processos filhos.

dns_children número

dns_retransmit_interval

Tempo inicial que o DNS aguarda para retransmitir uma solicitação. O intervalo dobra cada vez que todos os DNS configurados são tentados.

dns_retransmit_interval segundos

dns_timeout

Timeout para requisições DNS. Se não houver resposta depois desse tempo, todos os DNS configurados para esse domínio são considerados indisponíveis.Padrão de 5 minutos.

dns_timeout minutos

dns_defnames

Normalmente o servidor de dns desabilita a opção de resolução RES_DEFNAMES. Isso impede que caches em uma hierarquia resolvam nomes de hosts localmente. Para utilizar essa opção, não esqueça de habilitar na hora da compilação.

dns_defnames on|off

dns_nameservers

Pode ser usada para especificar uma lista de servidores DNS no lugar no /etc/resolv.conf

dns_nameservers Endereço_IP

unlinkd_program

Especifica o caminho do programa unlinkd. Isso não é necessário se você estiver usando I/O assíncrono.

unlinkd_program path_diretório/nome_programa

diskd_program

Especifica a localização do diskd.

diskd_program path_diretório/nome_programa

pinger_program

Define o caminho do executável pinger.

pinger_program path_diretório/nome_programa

redirect_program

Diz qual o caminho do redirecionador de URL. Existem diversas aplicações que poderão ser utilizadas.

redirect_program path_diretório/nome_programa

redirect_children

Número de processos filhos para o programa de redirect.

redirect_children número

redirect_rewrites_host_header

Por padrão o Squid reescreve o header de host em requisições redirecionadas. Se você está rodando como proxy reverso, isso pode não ser desejado.

redirect_rewrites_host_headeron|off

redirector_access

Se definido, essa lista de acesso especifica quais requisições são enviadas para o processo de redirect. Por padrão, todas são.

redirector_access allow|deny

authenticate_program

Especifica o comando do autenticador externo. Esse programa lê uma linha contendo: "usuário senha" e devolve um OK ou ERR. Para utilizar o autenticador é preciso ter uma ACL relacionada.

authenticate_program path_diretório/nome_programa

path_diretório/arquivo_senhas

authenticate_children

Número de processos filhos do autenticador. Padrão de 5.

authenticate_children número

authenticate_ttl

Especifica o tempo de vida para uma autenticação bem sucedida permanecer em cache. Se uma combinação inválida de nome de usuário e senha é fornecida, o usuário é removido do cache e uma revalidação é exigida. Padrào de 3600 segundos.

authenticate_ttl segundos

authenticate_ip_ttl

Com essa opção você poderá especificar por quanto tempo a autenticação persistirá para um determinado IP. Se uma requisição usando a mesma autenticação da conexão já efetuada for utilizada em outra máquina, ambas terão acesso bloqueado e será exigida uma nova autenticação. Se você tem usuários com uma conexão discada conectando em seu Proxy remotamente, é recomendável que não tenha um número maior do que 60 segundos, visto que isso o impediria de conectar-se novamente durante esse tempo se a linha dele caísse. O padrão é de 0 segundos.

authenticate_ip_ttl segundos

authenticate_ip_ttl_is_strict

Essa opção faz com que a autenticação seja um pouco mais rígida. Ela impede que qualquer outra conexão seja feita com outros endereços IP enquanto o tempo de vida especificado anteriormente não expirar. Essa opção está ativada por padrão.

authenticate_ip_ttl_is_stricton|off

 

Tags da seção para tunning do Squid

Essa seção descreve importantes parâmetros para determinar a performance do Squid.

wais_relay_host / wais_relay_port

Define o servidor de relacionamento WAIS

wais_relay_host host

wais_relay_port porta

request_header_max_size

Especifica o tamanho máximo de um cabeçalho de uma requisição http. Como sabe-se que um cabeçalho HTTP deve ser pequeno (por volta de 512 bytes), limitar o tamanho do mesmo pode ser interessante no uso de proxy reverso, criando uma barreira a mais para ataques do tipo buffer overflow e denial of service. Padrão de 10K.

request_header_max_size kbytes

request_body_max_size

Especifica o tamanho máximo para o corpo de uma requisição HTTP. Ou seja, o tamanho máximo de um PUT ou POST. Essa opção pode ser interessante para empresas que queiram garantir que seus usuários não farão grandes uploads à partir da empresa. Padrão de 1MB..

request_body_max_size kbytes

reply_body_max_size

Tamanho máximo do corpo de um reply. Isso é útil para impedir que seus usuários baixem arquivos grandes. Padrão de 0.

reply_body_max_size kbytes

refresh_pattern

Essa opção deve ser usada com extremo cuidado. Se você não tiver nenhuma aplicação que exija explicitamente alterar essa TAG, sugiro que deixe-a inalterada. Um valor inadequado aqui fará com que seus usuários simplesmente não consigam mais acessar aplicações dinâmicas na web. Não seja levado pela idéia de que impedir os usuários de ficar dando reload em uma página irá economizar sua banda, pois a dor de cabeça gerada será muito mais cara do que sua banda.

Parâmetros

Descrição

mín

Tempo mínimo, em minutos, que um objeto sem um tempo de expiração explicitamente configurado será considerado válido. Utilize, impreterivelmente 0.

porcentagem

É a porcentagem da idade dos objetos, desde a última modificação, no qual esse será considerado válido, desde que não tenha um valor de expiração configurado.

Máx

É o tempo máximo, em minutos, que um objetos sem um tempo de expiração explicitamente configurado será considerado válido.

override-expire

Reforça o tempo mínimo de expiração de um objeto, ainda que o mesmo tenha sido enviado no cabeçalho.

override-lastmod

Reforça o tempo mínimo, ainda que o objeto tenha sido modificado recentemente.

reload-into-ims

Modifica solicitações do tipo "sem-cache" ou "reload" para "Se-modificado-desde-requisição"

ignore-reload

Simplesmente ignora as requisições "sem-cache" e "reload".

 

refresh_pattern [-i] regex mín porcentagem máx [opções]

reference_age

Como já discutido, o Squid atualiza sua memória baseado em políticas, normalmente removendo primeiro objetos mais antigos ou menos populares. Apesar disso ser feito dinamicamente, podemos configurar valores manualmente nessa opção, configurando o tempo máximo de permanência em memória. O valor padrão é de 1 ano.

reference_age tempo

quick_abort_min / quick_abort_max / quick_abort_pct

O cache pode ser configurado para continuar com o download de requisições abortadas. Ao mesmo tempo que isso pode ser indesejado em redes pequenas e com conexão lenta, pode ser útil em grandes instalações, onde quase certamente um outro usuário irá requisitar o mesmo objeto.

Quando o usuário aborta um download, o Squid verifica o valor da opção quick_abort e a quantidade de dados baixados até o momento. Se o transferido for menor do que o especificado, ele irá finalizar o download. Padrão: 16 KB

Se o transferido tiver mais do que o quick_abort_max, ele irá abortar a transferência. Padrão: 16 KB

Se uma porcentagem maior do que a configurada em quick_abort_pct tiver sido baixada, ele finaliza o download. Padrão de 95%.

quick_abort_min kbytes

quick_abort_max kbytes

quick_abort_pct porcentagem

 

negative_ttl

Tempo de vida para requisições falhas. Certos tipos de erros (como conexão recusada ou página não encontrada) são marcados como "sem-cache" por um determinado tempo. Padrão de 5 minutos.

negative_ttl tempo

positive_dns_ttl

Tempo de vida para resultados bem sucedidos de resolução DNS. Se você realmente precisar alterar esse valor, não deixe inferior a 1 minuto. Padrão de 6 horas.

positive_dns_ttl tempo

negative_dns_ttl

Tempo de vida de resoluções falhas de DNS.

negative_dns_ttl tempo

range_offset_limit

Configura um limite superior de até onde deverá ir a abrangência de uma requisição de arquivo em um pré-download. Se passar desse limite, o Squid encaminha a requisição como está e não cacheia o resultado.

range_offset_limit bytes

 

 

Tags da seção Timeouts

Parâmetros de time out podem ser baseados em tempo de conexão, conexão com host, por site ou domínio, por tipo de requisição, etc. Time outs bem configurados são essenciais para otimizar a performance do Squid. Os principais parâmetros estão listados abaixo:

connect_timeout

O tempo de espera que o Squid aguarda pela resposta do servidor de origem. Se esse tempo for excedido, o Squid responde com uma mensagem de "Connection timed out". Padrão de 120 segundos.

connect_timeout segundos

peer_connect_timeout

Especifica quanto tempo deverá ser aguardada uma resposta de um cache vizinho para conexões TCP. Diferentes limites podem ser configurados para vizinhos distintos. Padrão de 30 segundos.

peer_connect_timeout segundos

site select_timeout

Define o tempo de expiração para URN em seleção de múltiplas URLs. URN é um protocolo desenvolvido para resolução de nomes independente de localização. Padrão de 4  segundos.

siteselect_timeout segundos

read_timeout

Essa opção é usada em conexões server-side. Após cada leitura bem sucedida, o time out será aumentado nesse valor. Se nenhum dado for lido após esse tempo, a requisição é abortada e logada como ERR_READ_TIMEOUT. Padrão de 15 minutos.

read_timeout tempo

request_timeout

Diz ao Squid quanto tempo esperar após uma conexão HTTP ser aberta. Para conexões persistentes, o Squid irá aguardar esse tempo após o fim da requisição anterior. Default de 30 segundos.

request_timeout segundos

client_lifetime

Tempo máximo que um cliente poderá ficar conectado ao processo de cache. Entenda-se cliente como browser. Isso protege o cache de ter muitos sockets em estado CLOSE_WAIT devido a clientes que desconectam sem utilizar o procedimento adequado. Padrão de 1 dia.

client_lifetime tempo

half_closed_clients

Alguns clientes podem parar o envio de pacotes TCP enquanto deixam o recebimento em aberto. Algumas vezes o Squid não consegue diferenciar conexões TCP totalmente fechadas e parcialmente fechadas. Por padrão, conexões parcialmente fechadas são mantidas abertas até que haja um erro de leitura ou escrita no socket. Mudando essa opção para off fará com que o Squid imediatamente feche a conexão quando a leitura do socket retornar "sem mais dados para leitura".

half_closed_clients on|off

pconn_timeout

Aqui configura-se o timeout para conexões persistentes. Depois do tempo de inatividade determinado aqui, o Squid encerra as conexões persistentes. Caso você configure essa opção para menos de 10 segundos, a funcionalidade estará desabilitada. Padrão de 120
segundos.

pconn_timeout segundos

ident_timeout

Tempo máximo para para aguardar requisições IDENT. Se esse valor estiver muito alto e a opção ident_lookup ativada, existe a possibilidade de sujeitar-se a uma negação de serviço, por ter muitas requisições IDENT ao mesmo tempo. Padrão de 10 segundos.

ident_timeout segundos

shutdown_lifetime

Quando o Squid recebe um SIGTERM ou um SIGHUP, o cache é colocado em modo de "shutdown pendente" até que todos os sockets ativos sejam fechados. Qualquer cliente ainda ativo depois desse período irá receber uma mensagem de timeout. Default de 30 segundos.

shutdown_lifetime segundos

 

Tags da seção Access Control Lists

Sem dúvida a parte mais importante para os administradores. Com o uso de ACLs bem configuradas e planejadas, é possível não só manter seus usuários sob controle, mas também melhorar desempenho e facilitar a administração.

acl

Define uma lista de acesso. Quando usando um arquivo para buscar os dados, o mesmo deve conter uma informação por linha. Expressões regulares são case-sensitive - para fazê-las case-insensitive, utilize a opção -i.

acl nome tipo string1 ... | "arquivo"

src

Baseado em ip ou hostname de origem da requisição

acl nome src ip/máscara.

dst

Baseado em ip ou hostname de destino da requisição. A ACL só é interpretada depois que a resolução DNS for feita.

acl nome dst ip/máscara.

srcdomain

O domínio da máquina cliente. Os domínios serão obtidos por resolução reversa de IP, o que pode causar atrasos para a resposta da requisição.

acl aclname srcdomain nome_domínio

dstdomain

Mesmo que srcdomain, mas levando-se em conta o destino.

acl nome dstdomain nome_domínio

srcdom_regex

Expressão regular que é avaliada para tentar marcar um domínio requisitante.

acl nome srcdom_regex regex

dstdom_regex

Mesmo que srcdom_regex, mas com relação ao destino.

acl nome dstdom_regex regex

time

Dia da semana e hora

acl nome time [abreviação-do-dia] [h1:m1-h2:m2]

Onde:

  • S - Sunday (Domingo)
  • M - Monday (Segunda-Feira)
  • T - Tuesday (Terça-Feira)
  • W - Wednesday (Quarta-Feira)
  • H - Thursday (Quinta-Feira)
  • F - Friday (Sexta-Feira)
  • A - Saturday (Sábado)

h1:m1 - horário de início

h2:m2 - horário do término

url_regex

Essa ACL irá procura em na URL uma expressão regular que especificada. Opção case-sensitive

acl nome url_regex regex

urpath_regex

Essa acl irá fazer uma combinação de uma expressão regular com o caminho em um servidor que está se tentando acessar. Isso significa que o Squid irá ignorar o nome do servidor e o protocolo utilizado.

acl nome urlpath_regex regex

port

O acesso pode ser controlado pela porta do endereço do servidor requisitado.

acl nome port numero-porta

proto

Especifica o protocolo de transferência (http, ftp, etc).

acl nome proto protocolo

method

Especifica o tipo de método da requisição.

acl nome method tipo-método

browser

Expressão regular cujo padrão tentara combinar com o contido no cabeçalho HTTP de requisição do cliente, descobrindo assim o agente (browser) utilizado.

acl nome browser tipo

ident

Seqüência de caracteres que combinam com o nome do usuário. Requer um servidor Ident rodando na máquina do cliente.

acl nome ident nome_usuário

ident_regex

O mesmo que ident, mas utilizando-se de expressão regular.

acl aclname ident_regex pattern

src_as

Origem de um sistema autônomo

 

dst_as

Destino de um sistema autônomo

 

snmp_community

Comunidade SNMP.

acl snmppublic snmp_community public

maxconn

Limite máximo de conexões provenientes de um mesmo cliente. Útil para restringir número de usuários por IP, bem como fazer controle de uso da banda.

 

req_mime_type

Expressão regular que combina com o tipo de conteúdo contido no cabeçalho de requisição.

acl nome req_mime_type padrão

arp

MAC Address do cliente.

acl nome arp MAC_ADDRESS

 

http_access

Permite ou nega acesso ao serviço http baseado na lista de acesso (acl) definida. O uso de "!" indica que será a negação da acl.

Se nenhuma das acls configuradas se encaixar na requisição em curso, será então aplicada a última regra. É importante sempre criar uma acl chamada all (ou descomentar a linha já existente) e colocar um `http_access deny all'.

http_access allow|deny [!]nome ...

 

icp_access

Permite ou nega acesso à porta ICP, baseando-se nas listas de acesso.

icp_access allow|deny [!]nome ...

miss_access

Usado para forçar seus vizinhos a usar seu servidor como "irmão" ao invés de "pai".

miss_access allow|deny [!]nome...

cache_peer_access

Similar ao `cache_peer_domain', mas oferece mais recursos por utilizar-se da flexibilidade das acls. Sua sintaxe é idêntica ao `http_access'.

cache_peer_access cache-host allow|deny [!]nome ...

ident_lookup_access

Uma lista de elementos em uma ACL, os quais, se encontrados, irão gerar uma requisição IDENT.

ident_lookup_access allow|deny nome ...

Tags da seção auth_param

Uma das principais mudanças do Squid 2.4.x para o 2.5.x foi o sistema de autenticação. Todas as opções referentes a isso estão agoras sujeitas a opção auth_param. Vamos ver abaixo como ela funciona.

Formato geral

auth_param esquema parâmetro [opções]

program

Especifica o programa utilizado para autenticação. Tal programa irá ler uma linha contendo "usuário senha" e responder ao squid com um "OK" para sucesso ou um "ERR" para falha. Para utilizar um autenticador, é necessário uma acl do tipo proxy_auth. Por padrão,
utiliza-se o sistema de autenticação básico.

auth_param basic program /path/do/programa /path/do/arquivo/senhas

children

Número de processos filhos que o programa de autenticação poderá conter.

auth_param basic children número

realm

Texto que irá aparecer na caixa de diálogo de login. Não é necessário configurar, mas confere uma certa personalização ao servidor.

auth_param basic realm Texto de login

credentialsttl

Especifica por quanto tempo o Squid irá assumir que uma autenticação bem sucedida continuará válida.

auth_param basic credentialsttl tempo

 

Tags da seção parâmetros administrativos

O parâmetros configurados nessa seção permitem que o administrador do Squid especifique usuário e grupos no qual o Squid irá rodar, bem como hostname que irá aparecer quando houver erros, etc.

cache_mgr

Usando essa tag, nós podemos especificar o endereço de e-mail doadministrador do cache local, que será o responsável pela instalação dessa máquina. Esse usuário será notificado por e-mail caso o cache morra. (usuário local). Padrão: webmaster

cache_mgr usuário

 

cache_effective_user / cache_effective_group

Quando iniciado como root, o Squid irá procurar esse parâmetro para determinar o usuário e grupo no qual irá rodar. É importante ressaltar que iniciar o Squid com usuário não root fará com que ele não consiga abrir nenhuma porta abaixo de 1024 localmente. Ao configurar esse
parâmetro, tenha certeza de que o usuário escolhido terá as permissões necessárias para escrever no diretório de logs, cache e todos os necessários.

cache_effective_user usuário

cache_effective_group grupo

visible_hostname

Se você deseja apresentar uma mensagem de erro com um hostname específico, defina aqui essa opção. Do contrário o Squid irá tentar descobrir o hostname. Esse parâmetro não será necessário se você não tiver um grande cluster de Squids.

visible_hostname nomehost

hostname_aliases

Uma lista de outros nomes que seu cache possa ter. Essa opção é usada para detectar requisições internas quando um cache tem mais de um hostname em uso.

hostname_aliases nomehost

 

Tags da seção httpd-accelerator

O Squid pode ser usado como um balanceador de carga ou redutor de carga de um webserver em particular. Alguns caches podem trabalhar com requisições de cache e requisições http, fazendo deles também um servidor web. O desenvolvimento do Squid não optou por essa solução.

Entretanto, adicionando-se uma camada de tradução o Squid pode receber e interpretar requisições no formato web-server, as quais ele irá repassar ao servidor web real, situado atrás dele.

Nessa seção também configura-se o Squid para trabalhar de modo transparente.

httpd_accel_host

Configura o nome do host para o serviço acelerado. Se você tiver vários servidores, será necessário utilizar a palavra virtual ao invés de hostname.

httpd_accel_host hostname(IP)|virtual

httpd_accel_port

Porta para qual as requisições aceleradas serão enviadas.

httpd_accel_port porta


httpd_accel_single_host

Se você está utilizando o Squid como um acelerador web e tem somente um servidor no backend, configure essa opção para on. Isso fará com que o Squid mande as requisições para o servidor, independentemente do que o cabeçalho disser.

httpd_accel_single_host on|off

httpd_accel_with_proxy

Se a opção http_accel_host estiver ativada, então o Squid irá parar de trabalhar a funcionalidade de cache. É necessário configurar essa opção para que ambas as funcionalidades continuem ativas.

httpd_accel_with_proxy on|off

httpd_accel_uses_host_header

As requisições HTTP/1.1 incluem um cabeçalho relativo ao host, que basicamente contém o nome do mesmo na URL. O Squid pode ser um acelerador para diferentes servidores web através da analise do cabeçalho http. Entretanto, o Squid não checa os valores do cabeçalho do host, abrindo uma possível brecha de segurança. Mais uma vez, é recomendado utilizar essa tag com cuidado.

httpd_accel_uses_host_header on|off

 

Tags da seção Miscellaneous

Como o nome sugere, essa seção sobre alguns parâmetros que não podem ser explicitamente encaixados com nenhuma outra categoria. Iremos abranger:

  • Limite de crescimento de arquivos de log.
  • Mostrar informações customizadas sobre os clientes e erros.
  • Definir pools de memória para o Squid.
  • Gerenciamento por SNMP.
  • Coordernação com caches vizinhos através de WCCP.
  • Direcionar as requisições tanto para o servidor de origem como um cache vizinho.

dns_test names

O teste de DNS pára de ser executado tão logo ele consegue resolver a primeira busca de nome. Esse teste pode ser desabilitado iniciando-se o Squid com a opção -D na linha de comando.

dns_testnames URL

logfile_rotate

Especifica o número de rotações executadas quando da digitação de `squid -k rotate'. O padrão é 10, o que significa que o Squid criará extensões de 0 até 9. Configurar o log_rotate para 0 irá desabilitar o rotacionamento.

logfile_rotate número

append_domain

Anexa o nome do domínio local para hostnames sem nenhum ponto (.). Essa opção deve conter um domínio com ponto (.) no início.

append_domain nome_domínio

tcp_recv_bufsize

Tamanho máximo de um buffer TCP.

tcp_recv_bufsize bytes

err_html_text

Especifica o texto do HTML que será incluído nas mensagens de erro. Pode ser alguma mensagem sobre contato do administador, ou um link para a página da empresa.

err_html_text texto

deny_info

Essa opção pode ser usada para retornar uma página de erro para requisições que não passem pelas regras definidas em uma ACL. Você pode utilizar as páginas padrão de erro do Squid ou criar as suas próprias.

deny_info nome_pagina_erro acl

memory_pools

Se configurado, o Squid irá manter pools de memória alocada e livre para uso futuro.

memory_pools on|off

memory_pools_limit

Deve-se também determinar um valor para esse pool de memória em bytes.
Se não configurada, ou com valor igual a zero, o Squid irá guardar tanta memória quanto possível.

memory_pools_limit bytes

forwarded_for

Atualmente o padrão HTTP/1.1 não provê nenhuma forma de indicar o endereço de requisição de um cliente. Entretanto, como essa era uma feature requisitada, o Squid adiciona em suas requisições um cabeçalho do tipo "X-Forwarded-For". Se ativada essa opção o Squid irá mandar requisições com o IP de origem no cabeçalho. Caso contrário, o mesmo irá ter origem desconhecida.

forwarded_for on|off

log_icp_queries

Configurando-se essa opção como ativa, as requisições ICP passarão a ser logadas no access.log.


log_icp_queries on|off

icp_hit_stale

Se você deseja retornar um ICP_HIT para objetos estáticos cacheados, configure essa opção para `on'.

icp_hit_stale on|off

minimum_direct_hops

Se você utilizar ICMP, faça buscas diretas para sites que estejam a mais de um hop de distância. Esse parâmetro é útil para descobrir a latência da rede.

minimum_direct_hops número

minimum_direct_rtt

Se estiver utilizando ICMP, faça buscas diretas a sites que estejam a mais do que o número de milisegundos configurados aqui de distância. Padrão de 400.

minimum_direct_rtt tempo

cachemgr_passwd

Especifica a senha para operações de gerenciamento de cache.

cachemgr_passwd senha ação ação ...

Ações

5min events non_peers via_headers

60min filedescriptors objects vm_objects

asndb fqdncache pconn

authenticator histograms peer_select

cbdata http_headers redirector

client_list info refresh

comm_incoming io server_list

config ipcache shutdow

counters delay mem store_digest

digest_stats menu storedir

dns netdb utilization

store_avg_object_size (kbytes)

O tamanho médio de objetos é usado para estimar o número de objetos que seu cache pode manipular. Para fazer essa estimativa, basta calcular: Número de objetos = cache_swap/tamanho médio de objetos.

store_avg_object_size tamanho


store_objects_per_bucket

Número de objetos armazenados de uma única vez em uma tabela hash.

store_objects_per_bucket kbytes

client_db

Se você deseja desabilitar estatísticas por cliente, desabilite essa opção.

client_db on|off

netdb_low / netdb_high

Os limites mínimos e máximos da medição ICMP. Por padrão esses valores são 900 e 1000. Isso significa que quando o limite máximo é atingido, o banco de dados irá apagar registros até alcançar o limite mínimo.

netdb_low entradas

netdb_high entradas

netdb_ping_period

O tempo mínimo de medição de um site.

netdb_ping_period time-units

 

query_icmp

Se você deseja fazer com que as requisições ICP sejam também respondidas com informações ICMP pelos seus vizinhos, habilite essa opção. Lembre-se que é necessário que o Squid tenha sido especificamente compilado com suporte a icmp para que essa opção seja funcional.

query_icmp on|off

test_reachability

Quando habilitado, repostas ICP MISS serão interpretadas como ICP MISS NOFETCH se o host alvo não estiver na base de dados ICMP ou tiver um RTT zero.

test_reachability on|off

reload_into_ims

Habilitando essa opção, você fará com que uma requisição no-cache seja transformada em uma if-modified-since. Essa opção deve ser usada apenas em casos muitos específicos.

reload_into_ims on|off

always_direct

Pode utilizar elementos de uma ACL para especificar requisições que devem sempre ser encaminhadas para o servidor de origem. Isso normalmente é utilizado juntamente com a opção cache_peer.

always_direct allow|deny [!]nome ...

never_direct

É a regra oposta ao always_direct, funcionando da mesma maneira.

never_direct allow|deny [!]aclname ...

anonymize_headers

Substitui o antigo cabeçalho `http_anonymizer' por uma opção mais configurável. Agora é possível especificar quais cabeçalhos serão enviados ou removidos das requisições.

anonymize_headers allow|deny nome_cabeçalho ...

É possível utilizar essa opção permitindo que determinados tipos de cabeçalhos sejam vistos ou negando outros.

Para ter uma header igual ao `http_anonymizer', é preciso configurar da seguinte forma:

  • anonymize_headers allow Allow Authorization Cache-Control
  • anonymize_headers allow Content-Encoding Content-Length
  • anonymize_headers allow Content-Type Date Expires Host
  • anonymize_headers allow If-Modified-Since Last-Modified
  • anonymize_headers allow Location Pragma Accept
  • anonymize_headers allow Accept-Encoding Accept-Language
  • anonymize_headers allow Content-Language Mime-Version
  • anonymize_headers allow Retry-After Title Connection
  • anonymize_headers allow Proxy-Connection

fake_user_agent

Essa opção faz com que o Squid envie, como versão do browser, o parâmetro que for configurado.

fake_user_agent String

icon_directory

Especifica o diretório em que os ícones estão armazenados.

icon_directory path_diretório/nome_diretório

error_directory

Caso deseje customizar as mensagens de erro do Squid, basta indicar o diretório onde os htmls serão encontrados e cria-los de acordo com a padronização.

error_directory path_diretório/nome_diretório

minimum_retry_timeout

Especifica o tamanho mínimo de timeout, quando esse tempo é reduzido para compensar a disponibilidade de múltiplos endereços IP.Isso significa que quando uma conexão é iniciada com um host que tem múltiplos endereços IPs, o tempo padrão de timeout é então reduzido
dividindo-se esse valor pelo número de endereços.

minimum_retry_timeout segundos

maximum_single_addr_tries

Configura o número máximo de tentativas de conexões em um servidor que tenha somente um endereço.

maximum_single_addr_triesnúmero

snmp_port

O Squi tem a capacidade de fornecer informações sobre status e estatísticas via SNMP. Aqui configuramos a porta onde esse serviço irá escutar. Utilize 0 para desabilitar essa opção. Padrão: 3401.

snmp_port porta

snmp_access

Permite ou nega acesso à porta SNMP, baseando-se em uma acl.

snmp_access allow|deny [!]aclname ...

 

 

Tags da seção delaypool

Conceitualmente, as delay pools são limitantes de consumo de banda. Basicamente o que um delay pool faz é criar uma lentidão artificial para os clientes, gerando uma grande economia de banda. Com uma combinação bem feita de delay pools e acls, é possível fazer um grande
controle e limitação de banda.

delay_pools

Número total de delay pools que irão ser utilizadas. Isso significa que se você tiver uma delay pool de classe 2 e 4 de classe 3, esse número deverá ser 5.

delay_pools número

delay_class

Define a classe de cada delay pool. Deve haver exatamente uma classe
de delay para cada delay pool.

delay_class número(delay-pool number), número (delay class)

delay_access

Determina em qual delay pool uma requisição será encaixada. A primeira a combinar será utilizada, por isso verifique com cuidado suas acls.

delay_access allow|deny nomeacl

delay_parameters

Define os parâmetros para uma delay pool. Cada delay pool tem um número de alocação de tráfego associado.

  • delay_parameters pool agregado (delay_class 1)
  • delay_parameters pool agregado individual (delay_class 2)
  • delay_parameters pool agregado network individual (delay_class 3)
  • delay_initial_bucket_level

Determina qual a porcentagem colocada em cada alocação quando o Squid é iniciado.

delay_initial_bucket_levelbytes

 

incoming_icp_average / incoming_http_average / incoming_dns_average / min_icp_poll_cnt / min_dns_poll_cnt / min_http_poll_cnt

São descritos os algoritmos usados para as tags acima,

Tag Name número

Padrão:

incoming_icp_average 6

incoming_http_average

Planos de Assinatura


4 incoming_dns_average

4 min_icp_poll_cnt 8

min_dns_poll_cnt 8

min_http_poll_cnt 8

max_open_disk_fds

Especifica o número máximo de file descriptors que o Squid pode usar para abrir arquivos. Essa opção é usada para evitar gargalo de I/O e acesso a disco limitando o número de arquivos.

max_open_disk_fds número

offline_mode

Com essa opção ativada, o Squid nunca irá tentar validar objetos cacheados.

offline_mode on|off

uri_whitespace

A ação que será tomada quando uma URI contiver espaços em branco é decidida nessa tag.  Padrão é strip.

uri_whitespace opções

Opções

Descrição

strip

Os espaços em branco são removidas da URL, de acordo com o recomendado na RFC2616

deny

A requisição é negada e o cliente recebe uma mensagem de "Requisição Inválida"

allow

A requisição é aceita e os espaços em branco não são alterados.

encode

A requisição é aceita e os espaços são codificados de acordo com a RFC1738

chop

A requisição é cortada e mandada apenas até o espaço em branco

broken_posts

Uma lista de elementos de uma ACL que, se encontrados, irão fazer com que o Squid coloque um par extra de CRFL (Carriage return e Line Feed) em um PUT ou POST. Isso somente é utilizado junto a alguns servidores HTTP problemáticos que exigem essa modificação. Se não souber de nenhum caso específico, ignore essa opção.

broken_posts allow|deny nomeacl

nonhierarchical_direct

Por padrão, o Squid irá enviar qualquer requisição não hierárquica diretamente aos servidores de origem. Se você desabilitar isso, o Squid irá enviar isso para o cache "pai". Na maior parte dos casos, não é uma boa idéia desabilitar essa opção, visto que ela irá gerar uma latência desnecessária, sem necessariamente algum ganho.

nonhierarchical_direct on|off

prefer_direct

O comportamento normal do Squid é tentar utilizar seus "pais" na maior parte das requisições. Uma possível utilidade de habilitar uma busca direta ao invés disso, seria combinando as opções non hierarchical_direct off and prefer_direct on, fazendo basicamente dos "pais" uma rota backup em caso de erro em buscas diretas.

prefer_direct on|off

strip_query_terms

Para habilitar o log de todos parâmetros das requisições, é necessário habilitar essa opção. Caso contrário o Squid apenas dá forward das mesmas sem gerar um log completo.

strip_query_terms on|off

coredump_dir

Em caso de falhas, os sistemas Unix geram sempre um arquivo de core dos programas. O Squid normalmente guarda os arquivos de core gerados por ele no diretório de cache. Com essa opção é possível configurar onde será armazenado esse arquivo.

coredump_dir diretório

redirector_bypass

Quando habilitado, uma requisição não irá através dos redirecionadores se todos eles estiverem ocupados. Se estiver com essa opção estiver desativada e a fila começar a crescer muito, o Squid irá abortar e gerar um erro solicitando que a quantidade de redirecionadores seja
aumentada.

redirector_bypass on|off

ignore_unknown_nameservers

O Squid sempre verifica se uma resposta DNS está sendo recebida de um mesmo IP de origem para qual está sendo enviada a requisição. Caso não sejam os mesmos, o Squid irá ignorar a resposta e mandar uma mensagem no log. Recomendo que não desabilite essa opção, visto que é uma proteção a mais contra ataques baseados em DNS.

ignore_unknown_nameserverson|off

digest_generation

Aqui é possível controlar se o servidor irá gerar um resumo e o tipo de seu conteúdo. Para habilitar essa e todas as outras opções referentes a resumo, é necessário que o Squid tenha sido compilado com opção --enable-cache-digests.

digest_generation on|off

digest_bits_per_entry

Número de bits do resumo de cache do servidor, o qual será associado com a combinação de um dado tipo de método HTTP e URL.

digest_bits_per_entry número

digest_rebuild_period

Número de segundos para a reconstrução do resumo do cache. O padrão é de 1 hora.

digest_rebuild_period tempo

digest_rewrite_period

Tempo de espera entre escritas de resumo no disco. Como na opção anterior, o resumo é escrito a cada 1 hora.

digest_rewrite_period tempo

digest_swapout_chunk_size

Número de bytes do resumo a escrever de cada vez. Por padrão o Squid utiliza 4KB, que é o tamanho padrão de uma página de swap.

digest_swapout_chunk_size bytes

digesvt_rebuild_chunk_percentage

Configura-se aqui a porcentagem do resumo de cache que será verificada de cada vez. Por padrão está configurado para 10% do total.

digest_rebuild_chunk_percentage porcentagem

chroot

Devido a alguns procedimentos que necessitam de poderes de root, o Squid roda parcialmente como tal. Se você deseja rodar o Squid como chroot, é preciso habilitar essa opção. Isso fará com que o Squid rode os procedimentos necessários como root e depois abandone completamente esse privilégio. Lembre-se que para usar um chroot é necessário um chroot_dir.

chroot enable|disable

client_persistent_connections / server_persistent_connections

Suporte a conexões persistentes para clientes e servidores. Por padrão, o Squid irá usar conexões persistentes para comunicar-se com clientes e servidores.

client_persistent_connectionson|off

server_persistent_connectionson|off

pipeline_prefetch

Para melhorar o desempenho de requisições e fila, o Squid irá trabalhar com 2 requisições paralelamente.

pipeline_prefetch on|off

extension_methods

O Squid somente trabalha com requisições HTTP padrão. Apesar de métodos diferentes serem negados, é possível fazer com que eles sejam aceitos adicionando-os a uma lista. É possível incluir até 20 métodos diferentes.

extension_methods request método

high_response_time_warning

Se a média de falhas por minuto excede esse valor, o Squid manda um aviso de nível 0 no debug (normalmente gerando uma saída no syslog) de alerta.

high_response_time_warningmsec

high_page_fault_warning

Se a média de falhas por minuto excede esse valor, o Squid manda um aviso de nível 0 no debug (normalmente gerando uma saída no syslog) de alerta.

high_page_fault_warning time-units

high_memory_warning

Se o uso de memória excede o valor determinado, o Squid manda um aviso de nível 0 no debug (normalmente gerando uma saída no syslog) de alerta.

high_memory_warning número

store_dir_select_algorithm

O Squid pode trabalhar com 2 tipos de algoritmos para escolher entre vários diretórios de cache: least-load e round-robin. O padrão é leat_load.

store_dir_select_algorithm tipo_algoritmo

ie_refresh

O Microsoft Internet Explorer até a versão 5.5SP1 tem problemas ao trabalhar com proxy transparente, impossibilitando forçar um refresh. Ativando essa opção é possível corrigir parcialmente o problema, fazendo com que todos os pedidos de refresh vindo de um IE seja automaticamente interpretado como forçado. A melhor opção, quando possível, é atualizar os clientes.

ie_refresh on|off

 

Configurando um Servidor Proxy

 

O Squid na sua forma default, funciona sozinho após a instalação no Debian.

Editando o arquivo squid.conf e habilitando a porta 3128, porta padrão para acesso ao proxy. O squid trabalhará como servidor de cache apenas para conexões a partir da interface de rede local.

            No arquivo de configuração, vamos especificar o nome que será visualizado nas páginas de erro do Squid:

visible_hostname squid

            Neste caso, o nome squid foi especificado. Mas poderia ser especificado da seguinte maneira:

visible_hostname www.dominio.com.br

            O Squid, por padrão, se apresenta fechado para conexões de rede.

            Vamos colocar o squid para funcionar:

Localize esta linha: http_access deny all

Substitua a linha acima por esta: http_access allow all

            Com esta configuração, fica permitido que todos teram acesso ao squid independente da rede.

 


Estrutura de cache

                Habilitando uma estrutura de cache com 1024MB, 128 diretórios e 256 subdiretórios:

 

cache_dir ufs /var/spool/squid 1024 128 256

Nesta opção são configurados os números de diretórios, subdiretórios e tamanho do cache. Detalhes:

cache_dir - Nome da tag;

  • ufs - É a forma de armazenamento de cache. Existe também a opção aufs, mas que só está disponível para outras plataformas. Para mais informações, leia o squid.conf;
  • /var/spool/squid - Diretório onde o cache do Squid ficará armazenado;
  • 1024 - Espaço em disco que o cache do Squid poderá ocupar, contado em MB;
  • 128 - Quantidade de diretórios que o cache do Squid possuirá;
  • 256 - Quantidade de subdiretórios que o cache do Squid possuirá;

 

Especificando para não fazer cache de páginas seguras:

no_cache deny SSL_ports

 

 

Estrutura de logs

 

A norma de segurança recomenda que sejam gerados registros de atividades dos usuários e que os mesmos sejam mantidos por tempo definido dentro da corporação, possibilitando investigações futuras e também a monitoração do controle de acesso. Esses logs devem manter:

- Identificação dos usuários: Squid – por padrão, registra o IP, mas com autenticação teremos o login do usuário.

- Datas e horários de entrada do Squid: por padrão resgistrado.

- Identidade do terminal e se possível sua localização: Squid – por padrão registrado.

- Registro das tentativas de acesso aos aceitos e rejeitados: Squid – por padrão registrado.

- Registro das tentativas de acesso a outros recursos e dados aceitos e rejeitados: Squid – por padrão registrado.

 

            Apesar de ser padrão a estrutura de arquivos de logs sugerida acima, vamos definir no squid.conf sua estrutura de logs:

 

Arquivamento de informações, como: data e hora em que o cachê foi inicializado e o que foi armazenado:

cache_log /var/log/squid/cache.log

 

Arquivamento de registros de conexões http de clientes ativos no Proxy:

cache_access_log /var/log/squid/access.log

 

Registrando os objetos que foram armazenados (páginas, figuras e outros):

cache_store_log /var/log/squid/store.log

 

Filtro de conteúdo com ACLs

 

O filtro de conteúdo possibilita a filtragem do conteúdo web dos usuários. Podemos usar as seguintes ACLs para realizar essa configuração: src, time, urlpath_regex, url_regex, dstdomain, proxy_auth, arp, maxconn, proto e port.

 

Access Control Lists

 

            São listas que fazem o agrupamento dos objetos que serão negados ou liberados de acordo com as regras determinadas pelo administrador.

Sintaxe: acl nome_da_acl tipo tipo_de_argumento

 

Exemplos:

 

Acesso no horário do almoço:

acl almoço time 12:00-14:00

 

ACL para acesso exclusivo pela rede:

 

acl rede0 src 192.168.0.0/255.255.255.0

ou

acl suporte_net src 192.168.0.1-192.168.0.12/24

 

           

Atualmente as redes estão cheias de acessos não autorizados, indevidos e desconhecidos pelo administrador, se este não possuir nenhum filtro de acesso à internet.

Agrupar tudo que os usuários acessam é humanamente impossível, mas há como ter um controle eficaz.

Sintaxe:

à allow

http_access|            nome_da_acl

à deny

Exemplo:

Acl micro_01 src 192.168.0.1

Acl micro_02 src 192.168.0.2

Acl micro_03 src 192.168.0.3

Acl micro_04 src 192.168.0.4

Acl manha time 06:00-12:00

Acl almoco time 12:00-13:30

Acl tarde time 14:00-17:00

 

http_access allow micro_01 manha

http_access allow micro_02 manha

http_access allow micro_03 almoco

http_access allow micro_04 tarde

 

Existem situações que é desejável bloquear uma determinada palavra que faça de uma outra palavra, exemplo: deputados. Esta palavra possui uma string ao meio, que geralmente não é permitida.

Em uma situação como a apresentada na palavra deputados, a primeira opção é criar uma ACL que controle esses tipos de palavras. Observe que a palavra deputados ficará liberada. Ao colocar somente uma lista negra teremos problemas, porque fatalmente esse caso pode ocorrer com mais palavras. Fica impraticável trabalhar somente com uma blacklist sem ter uma whitelist.

Criando as ACLs:

Acl blacklist url_regex –i “/etc/squid/blacklist”

Acl whitelist url_regex –i “/etc/squid/whitelist”

Atenção: a url_regex trata string dentro de uma url completa. Se dentro do arquivo /etc/squid/blacklist tiver a palavra girl, toda url que existir com a palavra girl será bloqueada (www.girl.com.br, www.beachgirl.com, www.planetgirls.com.br). O parâmetro –i informa que qualquer palavra dentro do arquivo sofrerá tratamento de case sensitive.

            A ordem que essas listas são controladas por muitas vezes causam problemas. Partindo do princípio que temos uma ACL chamada all que trata todos os ips da rede:

http_access allow whitelist

http_access deny blacklist

 


Autenticação de usuários no Squid

É um recurso bem interessante para controle pessoal de usuários. Isso 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 você irá precisar. Na maioria dos casos, o ncsa_auth resolve o problema.

ncsa_auth

O ncsa_auth é 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.

Deve-se adicionar esta ACL antes de outra qualquer:

http_access allow password

 

ACL para ativar recurso de autenticação:

Acl password proxy_auth REQUIRED

Editando o squid.conf

Procure pela seção que fala sobre autenticação (TAG: authenticate_program) e insira as linhas:

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd  auth_param basic children 5auth_param basic realm digite_sua_autenticaçãoauth_param basic credentialsttl 2 hoursauth_param basic casesensitive off

Criando um arquivo de senhas

O arquivo /etc/squid/passwd não existe por padrão. Temos de cria-lo:

 # touch /etc/squid/passwd

Tempo de expiração da senha deve ser definido:

Autenticate_ttl 1 hour

 

Adicionar usuários

Para adicionar novos usuários basta fazer:

  # httpasswd –c /etc/squid/passwd usuario

Atenção:

O utilitário faz parte do pacte apache2-utils, caso não esteja instalado, instale-o.

É preciso confirmar a senha duas vezes.

Dependendo da sua distribuição, o ncsa_auth pode estar em vários lugares, como /usr/bin, /usr/sbin e assim por diante! Verifique onde está a sua e coloque as linhas acima de acordo!

Quanto ao authenticate_children 5, é o suficiente se sua rede não é muito grande. Mude o valor de acordo com suas necessidades.

Editando a ACL de nossa rede interna:

     acl rede_interna src 192.168.0.0/24    acl rede_interna proxy_auth REQUIRED

ACL estratégica

Acl final. Negando qualquer possibilidade que não se enquadre nas ACLs anteriores:

http_access deny all

 

Controle de banda

Criando as ACLs

 

acl extensoes url_regex -i .*

 

Esta acl que criamos está pegando tudo que é relacionado a ponto, ou seja, inclusive extensões html, jpeg, jpg, gif, php, png, htm, etc, que são usadas em páginas de internet.

Se você quer bloquear tudo menos estas extensões, faça assim:

acl extensoes url_regex -i .* !.html !.htm !.php !.jpeg !.jpg !.png !.gif

 

Foi bloqueado tudo, exceto as seguintes extensões. Mas se o seu interesse é bloquear arquivos como mp3, avi, faça o seguinte:

acl extensoes url_regex -i .exe .mp3 .vqf .tar.gz .gz .rpm .zip .rar .avi .mpeg .mpe .mpg .qt .ram .rm .iso .raw .wav .mov

 

Você também pode criá-las em um arquivo:

 

acl extensoes url_regex -i "caminho do arquivo"

 

Coloque as extensões dentro deste arquivo (mas apenas uma extensão por linha).

 

acl interno url_regex -i 192.168.0.1

 

delay_pools

Esta opção especifica o número de delay pools que você vai possuir, por exemplo, se você possui 2 delay pools, este número deve ser igual a 2, se você tem 3 delay pools, este número deve ser igual a 3 e assim por diante.

 

 

 

 

Exercitando as ACLs

Configurações básicas

Como comentado, toda a estrutura do Squid é baseada em listas de acessos.

Criando uma lista de acesso básica para nossos usuários.

Vamos supor que nossa rede interna seja 192.168.5.0/24. Crie a seguinte linha no squid.conf, na seção de ACLs (TAG: acl):

     acl rede_interna src 192.168.5.0/24

E a seguinte linha na seção de acesso (TAG: http_access)

     http_access allow rede_interna

 

Para declarar ACL's, a sintaxe básica é a seguinte:

acl <nome da acl> <tipo da acl> <string>|"<endereço de arquivo>"

 

Um exemplo prático de ACL:

 

acl palavra_proibida url_regex -i sexo

A ACL acima bloqueia todos os sites que contenham em seu endereço a palavra "sexo".

É simplesmente inútil o uso de ACL's sem o uso da tag http_access. É ela que trava ou libera o que a ACL está estipulando.

Exemplo:

http_access deny proibido

Se nós considerarmos o conjunto ACL + http_access, ficaria:

acl proibido url_regex -i sexo

http_access deny proibido

 

O que o conjunto acima faz é proibir que qualquer site que possua em seu endereço a palavra "sexo" seja exibido para o requisitante. Nem sempre você vai utilizar um http_access para cada ACL que você fizer, às vezes você pode combinar duas ACL's em um único http_access, como é visto em outros casos.

Ordem das ACL's

Esta é uma dúvida que é muito comum.

"Qual a ordem que devo utilizar as minhas ACL's? Porque eu estou colocando tudo certo e não está funcionando!".

A resposta para essa pergunta não é tão simples assim. Eis o que o Squid faz quando vai tratar das ACL's.

  • 1 - O Squid vai ler todas as ACL's e testar se todas as ACL's declaradas possuem uma sintaxe correta e se elas estão sendo referenciadas por algum http_access;
  • 2 - Depois disso, se ele iniciar normalmente (Pode ser que outros fatores impeçam isto), ele irá começar a testar todas as requisições que são feitas para ele e tentar casar as mesmas com as regras que as ACL's estipulam em conjunto com os http_access;
  • 3 - Caso uma URL case com uma ACL, ele ignorará todas as outras ACL's para aquela requisição.

Uma outra maneira mais prática de tentar implementar isso é fazer da seguinte maneira:

  • 1 - Primeiro coloque as ACL's que estipulam uma excessão à alguma regra de bloqueio que virá à seguir;
  • 2 - Depois coloque as suas ACL's que vão bloquear sites e tudo o mais;
  • 3 - Só então você coloca as suas ACL's liberando o acesso.

Restringindo o acesso ao Squid

Se nós quisermos que somente uma rede da nossa empresa acesse o proxy, nós podemos definir faixas de IP's ou redes inteiras para a utilização do proxy. Quando você encontrar a linha http_access allow all, ela vai estar liberando acesso à todos os hosts, Agora crie uma nova ACL do tipo "src", especificando a rede interna:

acl redeinterna src 192.168.0.0/24

Agora autorize a ACL que você acabou de criar por meio de um http_access:

http_access allow redeinterna

Como visto acima, estamos somente permitindo o uso ao proxy pela rede interna. Agora, caso você queira especificar uma range de IP's, faça assim:

acl faixa_adm src 192.168.0.10-192.168.0.50

http_access allow faixa_adm

 

Bloqueando sites indesejados

O tipo de ACL url_regex serve para nós compararmos termos dentro de uma URL para que possamos compará-la e saber se esta palavra está ou não liberada e se os usuários vão ou não, visualizar a página. Nós utilizamos muito isso quando desejamos que sites pornográficos não sejam vistos por usuários dentro de uma empresa.

Vamos ao exemplo:

Adicione a seguinte ACL:

acl palavra url_regex -i sex

Agora bloqueie o acesso com o http_access:

http_access deny palavra

 

Com este exemplo, todos os sites que possuam a palavra "sex" em seu endereço não serão visualizados pelos usuários. O parâmetro "-i" serve para que o Squid não distingua entre maiúsculas ou  minúsculas.

Porém neste momento você deve estar pensando que não é prático definir uma ACL para cada palavra que você deseje bloquear. E realmente não é. Por isso, vamos declarar listas inteiras de palavras negadas.

Eis o exemplo:

Vamos criar o arquivo texto que nos vai servir como lista de palavras bloqueadas e será dado a ela permissões de leitura:

# touch /etc/squid/lists/blocked.txt (criando uma lista com o nome  blocked)

# chmod 755 /etc/squid/lists/blocked.txt (atribuindo permissões à ela)

Nele insira todas as palavras proibidas. Lembre-se que você deve adicionar uma palavra por linha.

Após isto, nós criamos a ACL da seguinte maneira:

acl blocked url_regex -i "/etc/squid/lists/blocked.txt"

E bloqueamos o acesso com o http_access:

http_access deny blocked

 

Feito isto, todos os sites que contém em seu endereço palavras como "sex", "sexo", "sexologia" vão ser bloqueados, porém como no último exemplo, nem todos os sites que contém a palavra "sex" é um site pornográfico . Mas como distinguir os sites que podem ser liberados dos que não podem? Simples, vamos criar uma outra lista para as excessões como "sexologia".

Vamos seguir o mesmo procedimento.

Criando uma lista também para as palavras não bloqueadas:

# touch /etc/squid/lists/unblocked.txt

# chmod 755 /etc/squid/lists/unblocked.txt

 

Nesta lista nós também vamos colocar todos os sites que são excessões à regra, como "www.sexologia.org". Também um site por linha. Se você preferir colocar as palavras somente, tudo bem também. Depois você vai ter que juntar as duas ACL's em um único http_access, desta maneira:

http_access deny blocked !unblocked

 

Note a utilização do sinal de !, significando uma inversão no sentido da regra, este sinal é extremamente útil no seu dia-a-dia.

Utilizando IPs e redes

 

Isso é o básico das ACLs. Limitar por IP e/ou rede. Exemplos para simplificar:

acl ip_do_diretor src 192.168.0.5  acl ips_da_diretoria src 192.168.0.5 192.168.0.6 192.168.0.7 acl rede_do_rh src 192.168.0.7/24 acl rede_do_cpd src 192.168.0.6/255.255.255.0

 

Usando ACLs externas

O recurso de ACL externa é 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 OK para o stdout caso a condição seja satisfeita, ou ERR também para o stdout caso ela não seja satisfeita.

Vou mostrar aqui um exemplo onde a diretoria deve acessar qualquer coisa, mas os usuarios normais sao submetidos a certas restrições. Levo em consideração que o usuário já está autenticado.

  external_acl_type checa_diretoria %LOGIN /etc/squid/modulos/diretoria.sh  acl diretoria external checa_diretoria


Arquivo /etc/squid/modulos/diretoria.sh (deve ser executável)

        #!/bin/bash       while read linha       do               if [ `grep -i $linha /etc/squid/users/diretoria` ]              then                              echo OK               else                              echo ERR               fi       done

Esse script verifica se o usuário autenticado pertence à diretoria. Para que um usuário seja reconhecido como diretoria, seu username deve estar dentro do arquivo /etc/squid/users/diretoria.

Trabalhando com domínios

Esse tipo de ACL tem que ser utilizada com cuidado. Tentar bloquear o acesso a chat em portais com essa opção também pode acarretar em acesso negado a sites de notícias ou de interesse geral. Todos os sub-domínios e hosts abaixo do domínio principal são afetados pela ACL.

  acl GEOCITIES dstdomain geocities.com

 

Expressão regular na URL

Aqui podemos fazer milhares de coisas, desde que conheçamos muito bem expressões regulares. Para saber mais sobre elas, procure o livro "Expressões Regulares - Guia de Consulta Rápida" ou pesquise na internet.

     acl jogos url_regex jogos

 

 

Restringindo por horários

Para  fazer isto usarei a ACL do tipo time.

Exemplo:

acl horariopermitido time MTWHF 08:00-18:00

http_access deny !horariopermitido

 

O sinal de exclamação aparece, invertendo o sentido da regra. Interpretando a regra fica assim: negar o uso do proxy em todos os horários, COM EXCESSÃO do horário especificado na ACL horariopermitido.

O "MTWHF" na frente da ACL. Ela especifica os dias da semana conforme esta tabela:

  • S - Sunday (Domingo)
  • M - Monday (Segunda)
  • T - Tuesday (Terça)
  • W - Wednesday (Quarta)
  • H - Thursday (Quinta)
  • F - Friday (Sexta)
  • A - Saturday (Sábado)

Liberando e bloqueando um acesso específico

O chefe proibe as coisas para os usuários, mas ele quer ter o controle completo. Para contornar a situação, faça o seguinte:

Caso você utilize proxy convencional, sem autenticação:

acl chefe src 192.168.1.23

E permitir a lista de palavras negadas para ele, assim:

http_access allow blocked chefe

Caso você utilize proxy autenticado:

acl chefe proxy_auth nome_do_chefe

E permitir a lista de palavra negadas para ele, assim:

http_access allow blocked chefe

Uma outra maneira de se fazer ambos os bloqueios é definir o IP/login do seu chefe em uma ACL e na hora em que for declarar o http_access, definir acima das ACL's de bloqueio, assim:

http_access allow chefe

http_access deny blocked !unblocked

 

Acessando somente sites específicos 

Ao invés de especificar os sites negados, você vai especificar o site que ele vai poder acessar. Este exemplo também pode ser adaptado para outros sites, não somente para o site de bancos e caso sejam muitos sites, você pode especificá-los em uma lista também.

Caso você utilize proxy convencional, sem autenticação, faça assim:

Primeiramente, especifique os sites que eles irão poder acessar:

acl bancos url_regex -i "/etc/squid/lists/bancos"

Adicione os endereços dos bancos na lista e especifique também o IP do computador do usuário:

acl financeiro src 192.168.0.8

Então junte os dois em um único http_access, desta maneira:

http_access deny !bancos financeiro

Interpretando a regra, fica: Vamos bloquear todos os sites, COM EXCESSÃO DOS SITES ESPECIFICADOS NA LISTA DE BANCOS para o IP 192.168.0.8.

Caso você utilize proxy autenticado, o pensamento é praticamente o mesmo, mas como é sempre bom praticar, vamos explicar todo o procedimento novamente:

Primeiramente, especifique o login do usuário por meio de uma ACL:

acl financeiro proxy_auth nome_do_usuario

Depois especifique os endereços dos sites que você quer que o usuário  tenha acesso, desta maneira:

acl bancos url_regex -i "/etc/squid/lists/bancos"

 

Insira os endereços que você deseja que o usuário acesse na lista e não se esqueça de dar as permissões de leitura para o arquivo.

Depois, junte as duas ACL's com um único http_access:

http_access deny !bancos financeiro

 

Bloqueando MSN

 O MSN a partir da versão 6.x (in)felizmente passou a fazer conexões utilizando tunneling por http, ou seja, ele se conecta pela porta 80. Sendo assim, é muito difícil fazer o bloqueio do MSN se não utilizados softwares como o layer-7 ou o Squid, que tratam as requisições vindas pela porta 80. O layer-7 é um software muito interessante também, trabalhando na camada de aplicação da tabela OSI. O bloqueio do Squid é simples de ser feito, bastando adicionar o termo "gateway.dll" na sua lista de palavras negadas.

Bloqueando extensões e downloads de determinados

É incrível o número de pessoas que nos dias atuais se infectam com vírus contidos em arquivos de extensões conhecidas por conter programas maliciosos, como o .bat e o .pif. Você pode bloquear extensões que os seus usuários baixam no computador por meio de HTTP ou de FTP e de quaisquer outros protocolos que o Squid suporte, fazendo os seguintes passos:

Primeiramente, você deve criar uma lista e seta as permissões corretas:

# touch /etc/squid/lists/extensoes

# chmod 755 /etc/squid/lists/extensoes

Feito isto, você deve escrever as extensões que você quer bloquear da seguinte maneira no arquivo:

\.mp3$

\.wav$

\.pif$

\.bat$

Atenção: O "\" é um eliminador de metacaracteres e serve para cancelar a função do ".". Já o "$" serve para que seja analizado até o final de string.

Agora nós vamos adicionar a ACL no Squid que vai bloquear as extensões efetivamente, juntamente com o seu http_access:

acl extensoes urlpath_regex -i "/etc/squid/lists/extensoes"

http_access deny extensoes

Note que ao invés do url_regex, foi utilizado o urlpath_regex.

Linha 2850        visible_hostname squid.nomedodominio.com.br

Linha 3495        error_directory /usr/local/squid/share/errors/portuguese

 

  • Comando para gerar um cache no squid
  • Comando para iniciar o squid

 

 

MAC Address

Para utilizar essa opção, o Squid deve ser compilado com os parâmetros "--enable-arp-acl", como feito em nossa instalação via source.

     acl administrador arp XX:XX:XX:XX:XX:XX

Onde: XX:XX:XX:XX:XX:XX é o MAC Address da placa de rede do administrador.

 

Limitando o número de conexões por usuário

Se quiser limitar o número de sessões que cada usuário abre de uma única vez, podemos utilizar o recursos de máximo de conexões.

  acl CONEXOES maxconn 10  http_access deny CONEXOES rede_interna

 

Impedindo ou Limitando o tamanho de uploads

Diversas empresas tem a necessidade de impedir que seus usuários dêem upload de arquivos para webmails, discos virtuais ou algum outro tipo de repositório na internet. O grande problema é que o método utilizado para fazer estes uploads é o POST, também utilizado para preenchimento de formulários, pesquisas, logins e senhas, etc. Isso impede o bloqueio total do método. Como fazer?

A opção mais lógica seria limitar o tamanho de um POST para um número suficientemente grande para permitir seu funcionamento normal e suficientemente pequeno para impedir o upload de arquivos. Para isso será usado a tag request_body_max_size.

No entanto essa tag tem uma falha, por não ser compatível com ACLs, ela limitará todos os usuários no que for determinado, situação normalmente incômoda.

Um script que nos permite criar ACLs baseadas nesse parâmetro. Vamos chamá-lo de /etc/squid/modulos/size.sh

  #!/bin/sh  while read line; do    set -- $line    length="$1"    limit="$2"    if [ "$length" -le "$2" ]; then      echo OK     else      echo ERR     fi  done


Depois basta criar uma ACL assim:

 external_acl_type request_body %{Content-Length} /etc/squid/modulos/size.sh acl request_max_10KB request_body 10240

Com isso limitamos o tamanho do upload para 10KB, o que deve ser suficiente para preenchimento de um formulário, mas pouco para um upload.

 

Proxy Transparente

O uso de proxy transparente libera você do trabalho de configurar os browsers individualmente para trabalhar. Se você tem uma centena, ou um milhar, de usuários em sua rede, muitas vezes é uma dor de cabeça configurar cada browser para usar proxies -- ou para convencer os usuários para editar as preferências do browser e escrever aqueles símbolos que eles não entendem.

Ao usar um proxy transparente, você intercepta as solicitações de páginas da web e redireciona as mesmas através do proxy. Bonito e simples – aparentemente.

Porque não usar um proxy transparente

O uso de proxy transparente (também conhecido como sequestro de TCP -- "TCP hijacking") é parecido com o "Network Address Translation" (NAT) em alguns aspectos: deve ser evitado a todo custo, e somente usar se não houver, positivamente, nenhum outro jeito.

O proxy transparente não funciona bem com certos browsers web. Com a maioria dos browsers ele funciona bem, mas mesmo se um quarto de seus usuários está usando browsers mal comportados, você pode esperar que os custos de helpdesk excedam qualquer benefício que você pode ganhar com o proxy transparente. Infelizmente, estes browsers são largamente utilizados.

Estes browsers se comportam de forma diferente se sabem que há um proxy. Todos os outros browsers seguem o padrão, e a única alteração que eles fazem com um proxy é direcionar as solicitações para uma máquina e porta diferentes. Browsers que não se comportam bem deixam alguns cabeçalhos HTTP fora das solicitações, e só acrescentam os mesmos se sabem que há um proxy. Sem aqueles cabeçalhos, comandos de usuários como "reload" não funcionam se houver um proxy entre o usuário e a origem.

O proxy transparente também introduz uma camada de complexidade, que pode complicar transações que de outra forma seriam simples. Por exemplo, aplicações baseadas em web que pedem um servidor ativo não podem fazer o teste do servidor fazendo uma conexão -- eles serão conectados ao proxy em vez do servidor.

Teoria de um proxy transparente

Como funciona o proxy transparente?

Um firewall ou outro redirecionador captura as conexões TCP direcionadas a portas específicas em hosts remotos (normalmente a porta 80), e direciona as mesmas para o servidor proxy local. O servidor proxy usa os cabeçalhos HTTP para determinar para onde ele deve fazer a conexão, e faz a conexão.

Administradores de sistema são geralmente pedidos para fazerem proxy transparente de FTP e SSL, mas estes protocolos não podem passar por proxy transparente. O FTP é um protocolo mais complexo que o HTTP, e dá menos dicas sobre a origem da solicitação. O SSL é criptografado e não contém dados úteis sobre o destino. Tentativas de decodificar o SSL são exatamente o que o SSL é feito para evitar: decodificar o SSL para proxy transparente, isto é indistinguível de um "verdadeiro" ataque man-in-the-middle.

Para executar um proxy transparente, precisamos de um servidor entre o cliente e o destino. Este servidor deve ter as facilidades necessárias para combinar e redirecionar o tráfego, como o netfilter e o iptables. Qualquer sistema de firewall capaz de Network Address Translation e redireção de tráfego pode ser usado.

Você precisará configurar uma regra para capturar o tráfego destinado à porta 80 em hosts externos, e redirecionar este tráfego para a porta de um servidor proxy na máquina que está fazendo a interceptação.

Pode-se ter proxies que não estão na máquina que faz a interceptação, mas estes são mais complicados. Primeiro, o endereço de origem da solicitação não está mais disponível ao proxy, ele é perdido no processo de redireção. Você pode resolver este problema usando NAT (Network Address Translation) de destino, mas você terá que rotear o tráfego do proxy de volta para o servidor que faz a tradução. Se você tentar fazer o proxy passar a resposta HTTP de volta diretamente, o cliente ficará confuso e (corretamente) irá recusar comunicar com o proxy. O proxy não é a máquina que o cliente pensa estar falando com -- o cliente pensa que está fazendo a solicitação para o servidor de destino. O proxy precisa rotear de volta através do interceptador, de forma que os endereços possam ser convertidos novamente, e deixar o cliente acreditando que está falando diretamente com o servidor web.

O protocolo HTTP/1.1 tornou a vida mais fácil para os proxies transparentes, tornando obrigatório o cabeçalho de host. Este cabeçalho contém o nome da máquina (conforme informado na URL) e permite web hosting virtual baseado em nomes, permitindo que o servidor web use o cabeçalho do host para determinar com qual página deve responder.

Para os proxies transparentes, ele dá ao proxy o nome de host. Tendo recebido uma conexão à porta 80 que foi interceptada, o servidor proxy precisa entender que não está recebendo uma URI (Uniform Resource Identifier) absoluta completamente qualificada, mas uma URI relativa. Normalmente, um servidor proxy recebe http://host/path, mas se o cliente pensa que está falando diretamente com o servidor, e não um proxy, ele só pede por /path.

O servidor proxy usa o cabeçalho HOST para recuperar a URI completamente qualificada, e então checa seu cache e faz o serviço de proxy usual.

O Squid pode ser utilizado para proxy transparente por que ele também foi projetado para ser um proxy reverso (também conhecido como acelerador HTTP, ou "HTTP accelerator"), e pode ler estes cabeçalhos de solicitação abreviados. No modo acelerador, ele fica em frente ao servidor web verdadeiro e recebe solicitações como se fosse o servidor web, portanto foi projetado com a habilidade de reconstruir URIs relativas. Para usar o Squid como proxy transparente, este comportamento de acelerador web será habilitado.

Quando usar o Squid como acelerador HTTP, configure o nome de host e a porta que você quer que o proxy acelere. Isto previne que o Squid seja usado como um HTTP relay arbitrário. Quando estiver usando o Squid no modo acelerador como um proxy transparente, configure o host name para virtual e a porta para qualquer porta para a qual queremos fazer proxy transparente.

Para iniciarmos a configuração do Squid como proxy transparente, insira ou descomente as seguintes linhas no arquivo /etc/squid/squid.conf:

No arquivo squid.conf, configure estas opções:

httpd_accel_host virtual

httpd_accel_port 80

(Ou qualquer porta que você queira fazer proxy)

httpd_accel_with_proxy on

httpd_accel_uses_host_header on

Atenção: Observe que você não pode fazer proxy transparente de mais de uma porta por vez. O cabeçalho HTTP não contém informação de porta, de forma que o Squid não pode saber para que porta a solicitação foi feita uma vez que a solicitação tenha sido interceptada.

Configurando um proxy transparente

Interceptação de tráfego

Intercepte e/ou redirecione o tráfego para a porta escolhida. Ter o proxy na mesma máquina que faz a interceptação é preferível. O código exemplo usa o iptables como mecanismo de redireção, e a porta 8080 como a porta http_port do proxy.

Como root, execute o comando:
#  iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

ou

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

Neste exemplo acima utilizamos a interface de rede eth0 como se fosse a interface ligada na rede local. Você deve adaptar o exemplo à sua rede. O exemplo também assume que o iptables e o servidor proxy estão sendo executados na mesma máquina. Caso os serviços estejam em máquinas separadas, a linha de comando para o iptables é ligeiramente diferente:

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

ou

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to IP:8080

 

IP - Deve ser substituído pelo endereço IP da máquina onde o servidor Squid esta sento executado.

Para que esta regra esteja ativa logo após a inicialização do sistema operacional, execute em seguida os comandos:


# iptables --save > /etc/sysconfig/iptables

# chkconfig iptables on

Ao reiniciar o Squid ("service squid restart" ou "/etc/init.d/squid restart") os clientes já poderão navegar normalmente em necessidade de especificar no browser qual servidor proxy deve ser utilizado.

Dicas

  • Você pode perder o endereço origem da solicitação se o proxy também não é o interceptador de tráfego. Você pode corrigir isto utilizando NAT de destino em vez de redireção de pacotes, e certificando-se que o proxy faça roteamento de todos os pacotes de volta para o computador que faz a interceptação, incluindo o tráfego para os clientes (ou alternativamente faça que o proxy seja a máquina que faz a interceptação).
  • Alguns browsers não conseguem fazer refresh de conteúdo através de um proxy transparente. O cliente não consegue enviar cabeçalhos de cache coerentes, assumindo que está falando com um servidor web, e assumindo que não há proxy ou agente de cache (incluindo aceleradores web) no meio. Usuários destes browsers terão problemas e serão problemas para o IT helpdesk. Não tem correção conhecida para este problema, além de não usar estes browsers com qualquer tipo de proxy ou agente de cache.
  • É mais barato em termos de ciclos de CPU e memória ter os browsers configurados explicitamente para usar um proxy, do que redirecionar o tráfego. É mais barato em termos de ciclos de CPU e memória bloquear a porta 80 ao invés de redirecionar o tráfego. O bloqueio tem menos overhead que a redireção, e pode forçar as pessoas a utilizar um proxy.
  • Não esqueça de verificar os arquivos de log do Squid quando não estiver conseguindo resolver algum problema. O Diretório padrão de armazenamento dos arquivos de log é: /var/log/squid/. Os principais arquivos são cache.log, access.log e o squid.out, que armazenam respectivamente, informações sobre o cache do servidor proxy, os acessos feitos através do proxy e mensagens de erro emitidas pelo deamon do Squid.
  • Aqueles que preferem uma interface gráfica para configuração de servidores podem optar pelo Webmin, um gerenciador de sistema com interface web que contém um módulo para gerenciamento do Squid. O download do Webmin pode ser feito através do site http://www.webmin.com

 

Trabalhando com hierarquias

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 sobremaneira. Isso é facilmente explicável quando pensamos em termos regionais.

Exemplo: Sua empresa está estabelecida em um prédio junto com diversas outras. Nesse caso, quando um usuário da empresa 1 deseja acessar um site, ele vai até seu proxy, que busca o site e o armazena, agilizando a consulta de todos os outros usuários dessa mesma empresa. Isso acontece também na empresa 2, 3 e etc.

Fica fácil de visualizar que se todas as empresas interligassem localmente seus servidores proxy, todas teriam ganho.

Na realidade, a sinergia entre pequenas empresas não existe. Mas quando se fala de grandes empresas e grandes backbones, cada 1 MB economizado com caching é 1 MB ganho em outros serviços.

Além de trabalhar com o conceito de árvore, onde existe um cachê 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

Entendendo o 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 o outro host está morto. 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.

 

 

Fazendo roteamento por domínios

Essa solução, apesar de simples, pode melhorar muito o desempenho de grandes instalações.

Vamos imaginar um caso em que existam 1 cache principal ligado a 3 outros caches. Vamos dizer também que temos uma imensa massa de usuários fazendo requisições a 3 grandes portais e ao mundo em geral.

A configuração seria algo assim:

  cache_host_domain cache1 portalxpto.com  cache_host_domain cache2 portalxing.com  cache_host_domain cache3 portalling.com  cache_host_domain cache4 !portalxing.com ! portalxpto.com !portalling.com

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

Roteando por protocolo

Podemos também definir qual será a rota tomada baseando-se em protocolo.

  acl FTP proto FTP  acl HTTP proto http  cache_host_acl cache1 FTP  cache_host_acl cache2 HTTP

Servidor Pai e filho

O Caso exista um único servidor pai e diversos filhos, a configuração será:

cache_host cache1 parent 3128 3130 default

Servidores Pais e filho

Em uma situação ideal, existem diversos servidores. A escolha sobre qual utilizar será baseada no método round robin.

cache_host cache1 parent 3128 3130 round-robin no-query cache_host cache2 parent 3128 3130 round-robin no-query cache_host cache3 parent 3128 3130 round-robin no-query
Utilizando o Squid como proxy reverso

 

Uma solução muito útil, mas por vezes pouco explorada do Squid é sua capacidade de trabalhar com proxy reverso. Isso signifca que, além de armazenar objetos remotos, criando toda uma série de vantagens, ele também pode armazenar objetos de um servidor web interno, aliviando seu uso e provendo maior segurança. Aqui o Squid literalmente trabalha como se fosse um servidor web.

Essa solução se mostra muito útil quando temos um web server com load alto, exigindo a ampliação da máquina ou criação de um cluster. Também é útil quando o servidor web utilizado pela empresa é conhecidamente inseguro e se mostra como um ponto fraco na empresa. O mesmo será "protegido" em alguns aspectos pelos Squid.

No momento de desenvolvimento da página já é necessário planejar uma futura implementação de Squid, cuidando para nunca desenvolver conteúdo unfriendly para o web caching. Tanto conteúdo estático quando dinâmico pode ser utilizado. O conteúdo dinâmico não será armazenado, enquanto o estático e coisas como imagens ficarão no Squid, aliviando o tráfego no web server para o conteúdo dinâmico fluir melhor..

Configuração de proxy reverso

A configuração é simples. Siga os passos abaixo:

 http_port 80 httpd_accel_host 192.168.0.51 httpd_accel_port 80 httpd_accel_single_host on httpd_accel_uses_host_header off

Onde:

Parâmetro

Objetivo

http_port 80

Número da porta onde o Squid irá escutar

httpd_accel_host 192.168.0.51

IP do servidor Web interno

httpd_accel_port 80

Porta onde o web server está escutando

httpd_accel_single_host on

Ativa o squid para somente um web server atrás

httpd_accel_uses_host_header off

É importante manter essa opção OFF, visto que ela altera os headers

Gerando Relatórios

Utilizando o SARG

Instalação

O SARG (sigla para Squid Analysis Report Generator) é um gerador de relatórios que provê informações sobre a atividade dos usuários do squid com riqueza de detalhes e interface agradável. Se usa com sucesso o SARG para gerar relatórios completos do tráfego de todos os usuários da rede que acessam a Internet contendo informações como tempo on-line, bytes de tráfego, sites acessados, downloads realizados, entre outros.

Suas caracteristicas que mais chamam a atenção são o fato de a riqueza de detalhes dos relatórios e gráficos gerados permanecerem à disposição de uma forma fácil via web e a configuração permitir uma série de escolhas e personalizações. Sua interface é agradável na parte dos relatórios, permitindo uma navegação tranqüila.

A configuração do sistema é feita editando um arquivo-texto de configuração, e a geração dos relatórios é feita pela linha de comando, através do executável sarg, permitindo definição de período de abrangência do relatório, entre outras opções. Além disso, é possível configurá-lo através do webmin. Penso que o SARG é adequado especialmente para administradores que desejam ter um controle detalhado, preciso e fácil das aventuras pela Internet dos usuários do proxy squid existentes na rede.

Trata-se de, apesar de simples, uma útil e prática ferramenta livre e nacional (o autor é o brasileiro Pedro Orso) de administração. Sua função é retornar um relatório HTML consolidado com as atividades dos usuários do Squid. O site oficial pode ser acessado em Português, e há pacotes binários para diversas distribuições Linux e também para BSDs no próprio site. A ferramenta tem traduções para diversos idiomas, incluindo Português. O arquivo de configuração é simples e intuitivo, e não exige conhecimentos muito avançados. Quem for capaz de configurar o básico do squid, conseguirá configurar bem o SARG. Para usá-lo basta instalá-lo (o squid precisa estar instalado, obviamente) e executar o aplicativo. Uma página de relatório será gerada e colocada, por padrão, em /var/www/htdocs/squid-reports.

Para instalar o SARG, você pode tanto puxá-lo do site oficial (http://sarg.sourceforge.net/) ou instalá-lo através de pacotes. Caso você esteja compilando-o, execute os seguintes comandos:

# tar xvfz sarg-x.y.tar.gz

# cd sarg-x.y

# ./configure

# make

# make install

Ou

# aptitude install sarg

Configuração

Por padrão, o SARG é instalado em /etc/squid. Neste diretório encontra-se o arquivo de configuração do SARG, o sarg.conf. Dentre várias opções, recomenda-se setar as seguintes:

language Portuguese

access_log /usr/local/squid/var/logs/access.log

title "Relatório SARG"

temporary_dir /tmp

output_dir /var/www/squid-reports

resolve_ip no

user_ip no

topuser_sort_field BYTES reverse

topsites_num 100

max_elapsed 28800000

Sendo importante destacar:

access_log - Indica o arquivo de log do Squid;

output_dir - Indica onde será gerado o seu relatório. É recomendável que seja um diretório onde o seu httpd possa acessar;

resolve_ip - Habilita/desabilita a resolução de nomes;

user_ip - Se você estiver utilizando um proxy autenticado, coloque yes. Caso contrário coloque no;

topsites_num - Quantidade de sites que você deseja que apareçam como os TOP de acessos.

Gerando relatórios

Esta é a parte mais simples. Para gerar os relatórios, execute o comando:

 

# sarg

           

Verifique a página criada em /var/www/squid-reports e use-a em seu browser.

 

Otimizando o Squid

 

Serão listadas algumas dicas para tornar melhor o desempenho de seu Squid. Algumas delas são genéricas, como aumentar a memória alocada pelo Squid, outras são específicas, como utilizar um determinado sistema de arquivos no Linux.

Especificando o Hardware

Essa etapa é importante no início do projeto. O ideal é traçar um perfil de como é e como será em 1 ano o volume de uso desse hardware.

Procure sempre utilizar hardware que permita crescimento, especialmente em memória e armazenamento. Evite instalar servidores já com todos os bancos de memória usados ou no máximo.

Pequenas instalações dispensam HD (disco) SCSI, uma opção que já fica inviável em instalações maiores.

Ao utilizar RAID, prefira o nível 0 do que outros, visto que o mesmo é feito para desempenho.

Mais abaixo vamos estudar alguns casos de empresas de tamanhos e necessidades diferentes, com todo o perfil de hardware utilizado.

É interessante também possuir um HD separado para os dados e para os logs do Squid. Se isso não for possível, ao menos uma partição separada é extremamente recomendado. Como normalmente tanto os dados quanto os logs fica abaixo do diretório /var, esse é o ponto de montagem para essa partição.

Sistemas de arquivo

Alguns sistemas operacionais são capazes de trabalhar com diversos sistemas de arquivos, tendo cada um suas características próprias, prezando por estabilidade e por desempenho.

DNS

O desempenho das resoluções DNS também é um ponto crítico. Em uma situação ideal, deveria existir um cache de DNS na mesma máquina ou em uma máquina muito próxima, para diminuir ao máximo o tempo de resolução dos nomes.

Múltiplas rotas

Em instalações como ISPs pode ser vantagem definir suas rotas manualmente. Já em empresas médias ou grandes que utilizam links de baixo custo, como ADSL, o balanceamento de carga nos links é uma ótima opção.

Editando o squid.conf

Podemos também definir alguns parâmetros na configuração, de forma a obter o máximo do sistema.

  cache_mem bytes

Nessa opção dizemos ao Squid quanta memória ele pode consumir. Em uma máquina exclusiva para o cache, 80% a 90% da memória total da máquina deve ser definida aqui.

Por exemplo, em uma máquina com 512MB de RAM:

  cache_mem 410 MB cache_swap_low percentage

Aqui se especifica o limite mínimo para substituição de um objeto. A substituição começa quando o swap em disco está acima do limite mínimo.

Defina algo como:

  cache_swap_low 95 cache_swap_high porcentagem

Justamente o oposto da opção anterior. Aqui se define o limite máximo.

  cache_swap_high 98 maximum_object_size bytes

A definição dessa propriedade deve ser analisada com critério, visto que limitamos aqui o tamanho máximo de um objeto em cache. Objetos maiores do que esse limite não são salvos em disco.

Para definir como configurar o tamanho máximo nessa opção, deve-se levar em consideração que um número grande implica em maior economia de banda e perda de performance no cache local, enquanto um número menor não ajuda muito em ganho de banda, mas melhora a velocidade em tempo de resposta. Recomenda-se a utilização de uma valor entre 4 e 16 MB.

  maximum_object_size 16384 KB maximum_object_size_in_memorybytes

Objetos maiores do que o tamanho definido aqui não são mantidos em memória. O tamanho deve ser grande o suficiente para armazenar objetos muito populares, mas pequeno demais para armazenar informações desnecessárias.

  maximum_object_size_in_memory 20 KB cache_dir Type Maxobjsize Directory-Name Mbytes Level-1 Level2

Configuramos nessa opção o tamanho máximo dos objetos dentro do diretório, o nome do diretório, quantos MB armazenar e os níveis e sub-níveis.

É possível ter diversos diretórios de cache, mas isso só vai fazer sentido se estiverem em HDs separadas. Caso a partição onde o seu Squid faz cache venha a encher, é possível criar um diretório de cache em outra partição, sem com isso obter ganhos de performance significativos.

cache_dir ufs /scsi2/cache 5000 16 256 Bibliografia:

http://hermes.wwwcache.ja.net/servers/squids.html

http://www.squid-cache.org/ (Squid Web Proxy Cache)

 

 

Adonel Bezerra

- É Perito com computação;
Auditor Líder das Normas ISO 27001, 27701, 27002 e 37301;
Membro efetivo da APCF - Associação Portuguesa de Ciências Forenses;
Pós-graduação em pericia forense computacional;
Pós-graduado em teoria em educação a distância e docência do ensino superior;
Graduando em direito;
Graduado em processamento de dados;
Escritor;
Com atuação profissional no Brasil e na Europa atualmente;
Especialista em investigação digital;
Experiência em implantação e auditoria das normas ISO 9001 e 27001;
Experiência em adequação de empresas a LEI N 13.709, DE 14 DE AGOSTO DE 2018 (LGPD) e General Data Protection Regulation (GDPR);
Experiência em auditoria interna ISO 27001;
Foi assessor sênior de desenvolvimento de tecnologia da informação do Conselho regional de engenharia e agronomia;
Consultor de segurança de sistemas e redes com mais de trinta anos de experiência;
Professor de pós-graduação em Pericia Computacional;
Já ministrou treinamentos e palestras para milhares de profissionais no todo Brasil e Exterior;
Fundador do Clube do Hacker www.clubedohacker.org
Site pessoal www.adonelbezerra.com
Lattes: http://lattes.cnpq.br/3540462066550327

Mais recentes de Adonel Bezerra


Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /home/ylliagdo/public_html/plugins/system/membershipprosms/membershipprosms.php on line 206