Squid

Planejamento e Implantação de Proxy
WWW e FTP
Neander Larsen Brisola
Conectiva S.A. (http://www.conectiva.com.br)
Suporte à Rede Conectiva de Serviços
sup-rcs@conectiva.com.br
Marcio Malafaia Saliba

Conectiva S.A. (http://www.conectiva.com.br)
Índice
1. Objetivos da Solução............................................................................................................................................................ 5
2. Características Técnicas...................................................................................................................................................... 5
3. Clientes Potenciais ............................................................................................................................................................... 6
4. Cases e Cenários Típicos ..................................................................................................................................................... 7
5. Vantagens para o Cliente..................................................................................................................................................... 7
6. Operação e Administração da Solução .............................................................................................................................. 7
7. Atualizações dos Sistemas ................................................................................................................................................... 8
8. Gerenciamento da Solução.................................................................................................................................................. 8
9. Treinamento.......................................................................................................................................................................... 9
10. Soluções Relacionadas ....................................................................................................................................................... 9
11. Metodologia de Implantação........................................................................................................................................... 10
12. Requisitos de Tempo e Recursos Humanos ................................................................................................................... 11
13. Análise Técnica................................................................................................................................................................. 11
14. Implantação ...................................................................................................................................................................... 15
15. Documentação .................................................................................................................................................................. 39
16. Referências........................................................................................................................................................................ 40
Bibliografia ............................................................................................................................................................................. 41
3
4
Informações Gerais
Este documento descreve o Planejamento e Implantação de Proxy WWW e FTP, apresentando seus conceitos básicos, obje-
tivos, clientes potenciais, aspectos comerciais, e aspectos técnicos de planejamento e/ou implantação.
Criado por Neander Larsen Brisola, com base na versão anterior deste documento, feito por Márcio Malafaia Saliba e na
documentação do site oficial do software de proxy utilizado no Planejamento e Implantação de Proxy WWW e FTP, bem
como no LDP (Linux Documentation Project), no livro de Gerhard Mourani e no livro de Roberto Teixeira e Carlos Daniel
Mercer e nas listas de discussão vide seção bibliografia.
Este documento pode ser encontrado online no site da Diretoria de Serviços (http://dir-serv.conectiva)
Comentários sobre este documento devem ser enviados para a equipe de Suporte à RCS (mailto:sup-rcs@conectiva.com.br).
Este documento é de uso interno da Conectiva S.A. (http://www.conectiva.com.br) e da Rede Conectiva de Serviços (RCS).
A equipe de Suporte à RCS é responsável pelas atualizações deste documento. As sugestões e críticas devem ser enviadas
diretamente para a equipe de Suporte à RCS (mailto:sup-rcs@conectiva.com.br).
1. Objetivos da Solução
O Planejamento e Implantação de Proxy WWW e FTP, visa atender as necessidades de organizações que possuem ao menos
uma conexão com a Internet.
Abaixo seguem alguns dos objetivos a que se destina a Planejamento e Implantação de Proxy WWW e FTP:
• Eficiência e segurança no gerenciamento do tráfego de informações entre pontos distintos ou com a Internet;
• Economia dos links Internet de longa distância, por concentrar os acessos em um único ponto e redução do tráfego WWW
e FTP pois muito do que é freqüentemente acessado fica no cache do servidor, gerando uma otimização do tempo de
nagevação, disponibilizando mais recursos para atividades que exigem velocidade de acesso;
• Possibilitar acesso restrito a usuários e sites específicos, com possibilidade de controle de horários permitidos para acesso.
2. Características Técnicas
O Planejamento e Implantação de Proxy WWW e FTP tem algumas características onde observamos:
• Utiliza-se de um recurso chamado ACL (Access Control List) o qual possibilita que toda a URL(Universal Resource
Location) que passe pelo Proxy seja monitorada bem como restringida caso necessário, assim, pode ser feito um controle
do que é permitido acessar e quem faz o acesso;
• A solução de proxy e cache otimiza o tráfego originado da Internet, diminuindo o congestionamento e aumentando a
velocidade de navegação por parte dos clientes.
• Solução baseada em software de reconhecida eficácia, utilizado por uma infinidade de organizações e provedores Internet
5
espalhados ao redor do mundo;
• Diminui custos com links utilizando-se do sistema de proxy para compartilhar um recurso para muitos;
• Esta solução não atende somente ao item performance de rede, mas também na segurança, esta característica pode ser
explorada criando-se políticas de acesso à Internet, podendo ser aplicadas a toda a corporação, ou individualmente a cada
usuário ou grupo de usuários.
Com esta solução todos os funcionários da organização acessarão a Internet por meio do servidor de proxy e cache, como
mostra a figura acima tendo a ilusão que estão acessando diretamente o servidor externo.
Com esta configuração é possível ter um controle completo sobre os protocolos HTTP, FTP e GOPHER bem como aplicar
políticas especiais sobre o que pode ser visto, acessado e o que é permitido fazer download.
Pode-se utilizar esta solução de proxy juntamente com a solução de firewall que abranga filtros de pacotes de uma forma mais
refinada, assim, utilizando-se da solução de firewall pode-se criar uma solução transparente e segura, como pode ser visto na
figura acima, utilizando-se o mesmo servidor. O resultado é um poderoso sistema de acesso a Internet, que simultaneamente
pode proporcionar segurança, controle, e supervisão.
Estas duas soluções podem estar na mesma máquina ou em máquinas separadas utilizando-se do conceito de DMZ.
Em organizações de grande porte pode ser feito ainda uma hierarquia de proxys, que consiste de vários proxys interligados e
distribuídos de forma hierárquica.
3. Clientes Potenciais
O Planejamento e Implantação de Proxy WWW e FTP, destina-se ao uso em qualquer instituição que tenha conexões TCP/IP
e que acesse os serviços WWW e FTP.
A organização que tenha uma ligação com um determinado ISP (Internet Service Provider), e que interligue suas filiais
por meio dele, pode utilizar-se da solução de firewall para impedir o acesso de indivíduos vindos da Internet, que tentem
invadir sua rede corporativa, e com a solução de proxy pode-se fazer a filtragem do que pode ser acessado pelos usuários da
organização na Internet.
Esta solução abrange todas as categorias de organizações, ou seja, tanto uma pequena ou média organização podem usar esta
solução devido ao seu custo baixo e versatilidade como grandes organizações.
Organizações que forneçam acesso discado para seus funcionários, também podem permitir que estes funcionários possam
utilizar-se dos recursos de cache e proxy para acelerar a navagação na Internet, ou seja, o funcionário acessa de casa a Internet
e usa os recursos do cache como na organização, no seu computador de trabalho.
Nas instituições de ensino é de grande importância, porque a solução permite o controle dos usuários de forma que em
horários de aula em laboratório, o aluno não tenha acesso a serviços WWW e FTP. Ainda em instituições de ensino, pode-se
inibir o uso da Internet para fins maliciosos, acessando sites de conteúdo pornográfico.
Com a falta de endereços IPs na Internet pode-se adotar a solução de Proxy para criar uma rede privada.
Qualquer organização que tenha conexões HTTP e FTP como ferramenta de trabalho pode e deve usar o Planejamento e
Implantação de Proxy WWW e FTP. Isto com certeza tornará a organização competitiva no mercado, bem como reduzirá
6
substancialmente o custo com links de acesso mais rápido.
4. Cases e Cenários Típicos

Um caso típico do uso do Planejamento e Implantação de Proxy WWW e FTP seria em uma organização que possua uma
intranet, e que tenha acesso a Internet. Os acessos feitos em sites na Internet seriam acessados mais rápido pelos usuários
dos serviços WWW e FTP, com a utilização do recurso de cache, e todos os usuários ou alguns que precisassem acessar a
Internet, seriam controlados por conteúdo (ex: páginas de conteúdo pornográfico), ou de temas impróprios para uso dentro
da organização (ex: restringir qualquer um que tente entrar em sites que tenha expressões como Chat ou Sexo).
Nesta mesma organização poderia-se com o uso desta solução manter a rede corporativa de forma privada ou seja ninguém na
Internet teria acesso as máquinas da rede privada, e tudo que fosse acessado na Internet seria registrado para fins de controle
de utilização, previsão de atualização de links, servidores e outros equipamentos de rede.
Hoje em dia este perfil de utilização da Internet como ferramenta corporativa, encontra-se na maioria das organizações.
Desta forma faz-se necessário a utilização de uma solução adequada para satisfazer este perfil.
A Conectiva tem tido importante atuação no mercado corporativo, e uma lista de cases sobre esta e outras soluções pode ser
encontrada no página de cases (http://www.conectiva.com.br/cases/) da Conectiva. Seguindo a idéia da necessidade de existir
uma relação de todos os cases Conectiva, é imprescindível que propostas comerciais e contratos contenham os termos de
“Autorização para Divulgação do Case”, bem como o “Certificado de Qualidade na Prestação de Serviços”. Estes documentos
são essenciais como argumentos de venda em negociações com clientes.
5. Vantagens para o Cliente

O Planejamento e Implantação de Proxy WWW e FTP baseia-se em recursos de free software que são utilizados por várias
organizações do mundo todo, sem abrir mão da qualidade e segurança.
Esta solução providencia uma variedade de funções especiais para uma rede local. Primeiro, um servidor proxy oferece um
ganho de desempenho, por manter uma cópia dos sites frequentemente acessados no servidor facilitando o acesso para os
usuários.
Pode-se bloquear alguns dos protocolos mais utilizados na Internet tais como HTTP, FTP.
Outra vantagem para o cliente seria o compartilhamento de recursos de uma conexão com a Internet, para vários usuários da
organização.
O Planejamento e Implantação de Proxy WWW e FTP tem uma outra grande vantagem que é o pronto atendimento da equipe
de suporte da Rede Conectiva de Serviços, por técnicos altamente treinados e qualificados, isto com certeza é um diferencial
e uma segurança maior, haja vista que algumas organizações como um Banco ou a Bolsa de Valores não podem pensar
em ficar com seus serviços parados por algumas horas, muito menos alguns dias, certamente este ponto é fundamental, a
consequência, em alguns casos, pode trazer até a falência ou saída permanente da organização do mercado. Esta solução
pode ser o diferencial entre sua organização e seu concorrente.
7
6. Operação e Administração da Solução
O Planejamento e Implantação de Proxy WWW e FTP tem sua configuração baseada em um arquivo texto de forma centra-
lizada, a operação desta solução é de nível médio de dificuldade, faz-se necessário o conhecimento prévio dos fundamentos
de proxy e segurança em redes, baseados no Conectiva Linux.
Contudo está em desenvolvimento um módulo squid para a ferramenta linuxconf, já é possível ter configurações parciais do
squid, e em breve o squid poderá ser configurado em sua totalidade pelo linuxconf.
O conhecimento necessário para operar e administrar a solução, é detalhado na seção Treinamento deste documento.
Na seção Metodologia de Implatação veremos todos os passos necessários para implantar e configurar de forma adequada o
Planejamento e Implantação de Proxy WWW e FTP.
7. Atualizações dos Sistemas

A atualização do software da solução, pode ocorrer quando surgir a necessidade de corrigir um bug, ou quando for acrescen-
tado novas funcionalidades para melhorá-la.
A forma de atualizar é feita, usando-se a opção de upgrade do comando rpm (-Uvh) ou através do utilitário apt-get. Mas
lembrando que a atualização deve ser feita por uma pessoa apta para executar esta tarefa.
Toda e qualquer atualização de software que venha a ser feita, deve ser obtida a partir do site da Conectiva S.A. (http://www.conectiva.com
no Site de Anúncio de Atualizações da Conectiva (http://distro.conectiva.com.br/atualizacoes/).
Contudo deve-se observar, que a atualização pode ocasionar mudanças de alguns parâmetros no arquivo de configuração
da solução. Em caso de ocorrer tais mudanças, deverão ser feitos ajustes para manter o funcionamento da máquina onde a
solução está instalada. Embora a atualização não seja freqüente, o cliente deve ser informado sobre a possibilidade de que
haja atualização.
8. Gerenciamento da Solução
O processo de gerenciamento, está diretamente ligado aos registros feitos pela própria solução no decorrer do seu uso.
Com base nesses registros, o administrador poderá encontrar informações sobre o mau funcionamento da solução, para que
possíveis correções sejam efetuadas.
O Planejamento e Implantação de Proxy WWW e FTP possui um mecanismo de gerenciamento que chama-se cachem-
gr.cgi(cache manager), este utilitário é um script CGI (Common Gatway Interface) que gera um relatório de indicadores de
funcionamento da solução de proxy e de como ela está configurada, este gerenciamento é possível através de um simples
browser internet, contudo possui algumas limitações.
Para suprir as deficiências do item anterior, pode-se implantar uma solução de estatística de conteúdo (Planejamento e Im-
plantação de Estatística em Servidores de Conteúdo, solução 5.3), que pode gerar um relatório diário em formato html, bem
como encaminhar um e-mail ao administrador do sistema. Isso evita a necessidade de filtragem manual dos logs.
8
Pode-se adotar outra solução de gerenciamento com o propósito de controlar conteúdo que os usuários acessam, mas de
forma simples de gerenciar, que fornece um relatório de qual site foi acessado por qual usuário e em que horário, e nesta
solução também é contemplado uma base de vários sites e domínios de conteúdo impróprio ou de incentivo a pirataria e
invasões na Internet (Planejamento e Implantação de Controle de Acesso de Conteúdo, solução 5.5).
Considerando que os logs são muito importantes para o gerenciamento da solução, é recomendado se fazer os registros em
um servidor de log remoto.
Na seção de implantação veremos os passos necessários de como configurar e utilizar o cachemgr.cgi, para o gerenciamento
do Planejamento e Implantação de Proxy WWW e FTP.
9. Treinamento
Para garantir a boa administração da solução, o uso correto dos seus recursos e procedência adequada em eventuais casos de
emergência, o técnico designado pelo cliente deverá ter conhecimentos dos aspectos de segurança. Caso o técnico designado
não tenha os conhecimentos em segurança de redes necessários, o mesmo deverá ser submetido ao treinamento entitulado:
Serviços de Rede e Segurança, desenvolvido para administrar a solução no cliente.
O objetivo geral é passar ao técnico designado conhecimentos sobre o conceito de proxy, noções de segurança de redes. Este
treinamento dará fundamentos necessários para a administração da solução, bem como sua manutenção.
Veja o Treinamento abaixo que devem ser observado para o perfeito uso do Planejamento e Implantação de Proxy WWW e
FTP.
Treinamento em Segurança
• Objetivos: Demonstrar os conceitos de Firewall e ferramentas de segurança bem como fundamentos de proxy e sua im-
plantação, criação de políticas de segurança.
• Público-alvo: administradores envolvidos com a solução implantada, e outras soluções que envolvem Internet e segurança
em redes.
• Pré-requisitos: experiência a nível médio com sistemas UNIX e Linux, capacidade de administrar e operar um sistema
Linux típico, incluindo serviços tradicionais como Telnet, FTP, WWW e Email. É necessário, ter conhecimentos de nível
médio em TCP/IP (endereçamento, roteamento e subredes).
Veja maiores informações sobre o treinamento Segurança de Redes(http://treinamento.conectiva/profissional/seguranca/firewall/index.html)

que a Conectiva oferece.
10. Soluções Relacionadas

Existem algumas outras soluções que podem ser agregadas, por exemplo a solução de firewall (Planejamento e Implantação
de Firewall, solução 2.2), e a utilização de softwares de detecção de intrusos (Planejamento e Auditoria de Segurança em
Sistemas de Computação IDS, solução 5.4).
Outra solução seria, (Planejamento e implantação de Estatísticas em Servidores de Conteúdo, solução 5.3). Conforme visto
9
na seção de gerenciamento, a solução torna-se muito mais poderosa quando é adicionada de um sistema de monitoramento
constante. A solução de monitoramento, mantém o administrador informado sobre as condições da máquina que hospeda o
proxy, com relatórios de acessos.
Quando existe a necessidade de segurança da rede interna contra a rede externa (Internet), faz-se necessário o uso da solução
de Firewall, porque é feito um controle de entrada e saída de pacotes aplicando-se regras ou filtros nos protolos que a solução
suporta.
11. Metodologia de Implantação

Os seguintes métodos/passos são necessários para a implementação da solução:
1. Levantamento prévio junto ao cliente, sobre o endereçamento de todas as máquinas que estarão envolvidas com a solução
de uma ou outra maneira, para que sejam configuradas as ACLs corretamente.
E verificar se a solução vai ser instalada separada ou posta na DMZ (Zona Desmilitarizada, é usada por uma companhia
que quer hospedar seus próprios serviços, sem expor sua rede privada, a pessoas com acesso não autorizado. Tipicamente,
a DMZ contem dispositivos acessíveis na Internet, tal como servidores Web (HTTP), FTP, SMTP (e-mail), e servidores
de DNS).
2. Instalação do sistema operacional. Esse passo refere-se a (Instalação do Servidor Conectiva Linux, solução 1.1).
Instalar o servidor com a opção Roteador e Firewall, somente deverão ser instalados os pacotes básicos, e o particiona-
mento será manual, este perfil se encaixará melhor com a solução de proxy.
Contudo, pelo fato de que a máquina será utilizada para hospedar a solução de proxy, no item 14.1 da solução 1.1, onde
referencia o particionamento do disco, deve ser acrescentado uma partição extra para o cache.
Para definir quais tipo de discos vão ser utilizados, deve-se levar algumas coisas em consideração, tais observações serão
vistas, no item 13.1, seção pré-requisitos de hardware.
3. Configuração dos parâmetros da rede. Nesta etapa, faz-se a configuração lógica das interfaces de rede, designando-as en-
dereços IP, de acordo com as subredes com as quais elas estarão diretamente conectadas. Deve-se levar em consideração
que esta etapa poderá ser feita no item anterior na instalação.
4. Instalação do(s) pacote(s) necessários. Aqui verificamos e instalamos os pacotes necessários para a solução. Veja a lista
de requisitos de software no item a seguir 13.1 Levantamento de Pré-Requisitos, seção Software.
5. Aplicações das políticas levantadas junto ao cliente, considerando-se a origem e destino dos pacotes, onde origem ou
destino poderão ser a rede interna, a Internet ou a DMZ. Inserir as ACLs (Access Control Lists), no arquivo de configu-
ração próprio da solução.
6. Fazer as configurações dos browsers nas máquinas clientes.
7. Testes. Após a implantação das ACLs, faz-se testes de acesso para verificar o funcionamento das ACLs a fim de eliminar
falhas. Através da análise de log é possível identificar-se quaisquer ajustes necessários que não estejam bem visíveis na
prática.
8. Documentação da Implantação. Após a conclusão dos passos anteriores, é necessário que tudo seja documentado. Na
10
seção de documentação, você encontra uma ferramenta para este fim, a qual abrange a maioria dos ítens que precisam
ser documentados.
Com estes registros em mãos, as coisas serão mais fáceis para o próprio técnico em visitas futuras ao cliente.
12. Requisitos de Tempo e Recursos Humanos
Tabela 1. Cronograma de Implementação da solução
Tarefa Tempo Recurso

Levantamentos de endereços/máscaras das redes envolvidas e 2 horas e 30 minutos Consult
políticas do acesso do cliente.
Instalação do sistema operacional Baseado na solução 1.1 Baseado
Verificação/instalação de pacotes 30 minutos Técnico
Aplicação das políticas levantadas, que serão configuradas no 45 minutos Consult
Proxy, usando-se as ACLs.
Testes pós-instalação 45 minutos Consult
Documentação pós-instalação 15 minutos Técnico
13. Análise Técnica

Nesta seção vamos levantar as questões técnicas que precisam ficar claras antes da implantação. Veremos quais os requisitos
da solução e o que precisa ser analisado. Esta análise irá facilitar e fazer o próximo passo muito mais eficiente.
Um servidor Proxy atua de uma forma bem simples. Quando um cliente faz uma requisição de um dos protocolos supor-
tados pela solução ao servidor, este procura a informação requisitada e faz o download do que foi solicitado pelo browser
cliente. Estes arquivos são gravados (arquivados no disco do servidor) localmente em um diretório especificado no servidor,
(cache_dir). Os clientes então recuperam o arquivo diretamente do servidor. Caso as páginas sejam revisitadas, o servidor as
busca em seu cache, apenas atualiza-as se for necessário, antes de repassá-las ao cliente.
Uma vez instalada a solução, o servidor espera as requisições dos clientes em uma porta pré-determinada (normalmente
3128). Pode-se utilizar uma outra forma utilizando-se do recurso de proxy transparente, com algumas regras de firewall (Ver
Planejamento e Implantação de Firewall, solução 2.2), redirecionando as requisições da porta 80 (http) para a porta do Squid
3128. Referências de como utlizar este recurso ao final do documento no item 16 seção bibliografia de referência.
Sendo um serviço no servidor, o software da solução deve ser ativado durante o boot, para isto deve-se utilizar:
/sbin/chkconfig squid on
11
13.1. Levantamento de Pré-Requisitos
A seguir temos uma lista dos ítens necessários para a instalação da solução. Antes de dar o primeiro passo da instalação
verifique:
• HARDWARE:
O cache utiliza-se mais do hardware do que outros subsistemas. A chave para obter uma boa performance do cache,
baseia-se nos ítens dispostos abaixo em ordem decrescente de importância:
1 - Tempo de busca do disco (seek time);
2 - Quantia de sistema de memória;
3 - Carga suportada pelo(s) disco(s) (throughput);
4 - Poder de Processamento.
Estes tópicos acima não devem ser subprojetados, do contrário, a performance será afetada.
Para decidir sobre a máquina que será usada, é necessário ter uma idéia da carga que ela deverá suportar: o número do
pico de requisições por minuto. Este número indica o número de objetos que serão baixados em um minuto pelos clientes
(browsers), e pode ser usado para obter a carga do seu proxy.
DISCO
Existem várias coisas para se considerar quando for comprar os discos para o servidor, anteriormente mencionamos a
importância dos discos com um rápido tempo de busca aleatório (random-seek time), e com suporte a alta carga de dados.
Portanto ter um disco rápido somente, não garante a perfomance, se o disco não puder manipular uma grande quantia de
dados. O tempo de acesso é um dos mais importantes a se considerar, se o cache está se tornando carregado, quanto menor
for o tempo de busca melhor, isto é o tempo médio que as cabeças do disco se movem de uma trilha aleatória para outra
em milisegundos.
Um cache com apenas um disco, tem que fazer pelo menos uma busca por requisição (isto sem levarmos em conta cache
de RAM do disco e tempo de atualização de inodes). Se você tem somente um disco, a fórmula para encontrar o valor de
buscas por segundo (e daí o nome requisições por segundo), é bem simples:
requisições por segundo = 1000/tempo de busca (seek

time - Isto vem na documentação do HD)
O squid faz o balanço de carga de escrita de disco em múltiplos discos do cache, então se você tem mais de um disco, você
terá o tempo de busca por segundo bem menor. Na maioria dos sistemas operacionais, incrementarão a quantidade tempo
de acesso aleatório de uma forma semi-linear, ou seja a medida que se adiciona mais discos, o número de buscas aumenta
e o tempo de resposta destas buscas diminui.
Exemplo usando mais discos segue na fórmula abaixo:
requisições por segundo = 1000/(tempo de busca do

disco/número de discos)
12
Considerando um exemplo, onde temos 3 discos e tendo todos eles com 12ms de tempo busca. Teoricamente temos o
seguinte:
requisições por segundo = 1000/(12/3) = 1000/4 = 250

requisições por segundo.
Para saber quantos objetos podem ser armazenados em disco de tamanho X, pode-se utilizar desta fórmula:
Número de objetos = tamanho do HD em bytes / tamanho

médio de objeto
Para um HD de 8Gb pode-se armazenar cerca de 645.000 objetos.

Existem atualmente, HDs IDE com suporte a DMA (Acesso direto a memória), que possuem velocidade semelhante a dos
HDs SCSI, isto facilita o uso em soluções mais econômias para projetos menores.
Pode-se incrementar a performance do HD, utilizando-se um software chamado Hdparm, mas somente para HDs IDE.
RAM
O Squid mantém uma tabela de objetos na memória, esta é a maneira que o Squid usa para checar objetos que estão
armazenados em arquivo, acesso rápido a esta tabela é muito importante, o Squid fica mais lento quando partes da tabela
esta no swap.
Cada objeto armazenado em disco, usa aproximadamente 75 bytes de RAM no índice. O tamanho médio de um objeto na
Internet é cerca de 13kb, então se você tem 1Gb de espaço em disco, você provavelmente armazenará por volta de 80.000
objetos.
Com 75 bytes de RAM por objeto, 80.000 objetos requerem cerca de 6Mb de RAM. Se você tem 8Gb de disco, você
precisará de 48Mb de RAM, somente para o índice de objetos. É importante notar que isto exclui a memória gasta com o
sistema operacional, o binário do Squid, memória para objetos em trânsito e sobra de RAM para o cache do disco.
CPU
O Squid geralmente não usa CPU intensamente. Quando ele inicia pode usar bastante processamento de CPU, enquanto
trabalha o que está no cache, e uma CPU lenta pode demorar o acesso ao cache nos primeiros 5 minutos do início do
squid, pois ele deve por novamente na memória a tabela de objetos. Uma máquina Pentium 133 geralmente, funciona
praticamente desocupada, enquanto recebe 7 requisições TCP por segundo.
Uma máquina multiprocessada, geralmente não incrementa velocidade dramaticamente: somente certas porções do código
do squid utilizam-se de threads, ou seja são enfileiradas. Estas seções de código não são processadas intensamente, então
o ganho não será significativo.
Além disto uma máquina multiprocessada, geralmetne não reduz este tempo de espera: mais memória (para cache de
dados) e mais discos trarão um efeito maior.
Podemos ter como uma base uma máquina como a descrita abaixo, mas levanto em consideração o que vimos até este
momento isto pode ser modificado conforme a necessidade.
13
CPU: Pentium 200Mhz
Memória RAM: 64Mb
HD: 4 Gb
Lembre-se que é bom utilizar um hardware com recursos além do necessário, prevendo-se possíveis expansões no uso da
solução.
• Adaptador de rede. Embora os adaptadores estejam dentro dos requisitos de hardware, eles dependem de outro fator que é
a arquitetura a ser usada. Basicamente, a existência ou não da zona desmilitarizada. Com a DMZ, teremos três barramentos,
logo três adaptadores. E sem a DMZ só iremos utilizar dois;
• Cuidados com os cabos de força e conexões de rede: Verifique instalação do servidor, solução 1.1 no item 13.1 Levanta-
mento de Pré-Requisitos.
• SOFTWARE
Os seguintes são os requisitos de software:
• CD’s do Conectiva Linux 6.0 ou superior
• O pacote do sofware adotado na solução squid-2.3.3-09cl.rpm. Este é o pacote do servidor de Proxy em sí.
Juntamente com ele é instalado no diretório /etc/squid o arquivo squid.conf onde serão feitas as configurações necessá-
rias para o funcionamento da solução.
• Pacotes do Linuxconf. Nas versões 6.0 ou superior do Conectiva Linux cada módulo do Linuxconf está em um pacote
distinto, linuxconf-squid-1.24r2-6cl.i386.rpm.
• Recursos humanos. É necessário no mínimo uma pessoa bem capacitada para fazer a implantação da solução. O perfil da
pessoa a ser designada deverá ser no mínimo a de um técnico pleno. Este técnico deverá conhecer na teoria e na prática
o funcionamento de redes TCP/IP. Deverá conhecer os protocolos básicos, ter familiaridade com os conceitos de portas e
endereçamento IP. O técnico ou consultor deverá ter um bom nível de conhecimento sobre segurança de redes.
• Acesso às informações necessárias. Devido ao fato de que o Planejamento e Implantação de Proxy WWW e FTP envolverá
mudanças nos parâmetros de toda a rede, se o cliente já tiver sua rede em funcionamento, possivelmente será necessário
que a implementação da solução, seja feita fora do horário de expediente da organização.
Garanta que no momento da implementação você terá em mãos as informações sobre a política de segurança da organi-
zação, ou seja, quais serviços a rede interna pode utilizar da Internet ou da DMZ. Você precisa ter uma lista de todas as
máquinas da(s) rede(s) do cliente que farão uso ou que estarão num dos barramentos do proxy. Obtenha também as senhas
de cada máquina caso você precise efetuar logins.
Informações incompletas poderão fazer com que você tenha que interromper o trabalho e voltar outro dia.
14
13.2. Atividades de Planejamento
Antes de iniciar a implantação propriaments dita, é necessária a análise sobre alguns ítens importantes. São eles:
Política de segurança desejada. Umas das coisas que você deve ter em mãos, é a política de segurança do cliente, de uma
forma clara e completa. A política será formada pela lista de que sites e conteúdos que a organização vai conceder ou permitir,
e a lista negra ou seja o que será proibido o acesso por meio do Planejamento e Implantação de Proxy WWW e FTP.
Recomenda-se um planejamento das ACLs com cuidado, para que determinados sites que devem ser acessados, não sejam
proibidos por engano causando um transtorno e eventuais correções das ACLs.
Redes/máquinas existentes. Faça um levantamento dos dados de todas as subredes e seus dados que existam no sistema do
cliente. Levante dados como os endereços IP’s, máscaras, DNS e rota padrão.
Máquinas especiais. Procure saber se haverá qualquer máquina com menos restrições de acesso do que outras. Liste os
respectivos endereços destas máquinas que poderão acessar e que não serão cobertos pelas ACLs destinadas as redes as quais
esta(s) máquina(s) pertencem.
Escolher o horário adequado para a instalação da solução, para evitar paralisação no horário de trabalho dos usuários da
organização.
Após a implantação realizar os testes necessários, a fim de que qualquer ajuste necessário, possa ser feito ainda no local.
Partir para configuração do Gerenciamento de logs e mensagens para o Administrador, estabelecer softwares de gerencia-
mento da solução.
Preencher todos os campos do formulário da solução pós-instalação e fazer backup dos arquivos de configuração da solução,
bem como deixar cópia dos arquivos e da documentação com o cliente.
14. Implantação
Aqui inicia-se o processo de instalação da solução. Esse processo começa com uma preparação do ambiente seguido da
inserção das ACLs propriamente ditas, bem como ajustes no softwares de gerenciamento.
A preparação conciste na instalação física das das placas de rede, instalação do Conectiva Linux, configuração e certificação
de segurança da própria máquina do proxy.
14.1. Procedimentos de Instalação e Configuração.
O Conectiva Linux 6.0 inclui o pacote do squid 2.3.3-9cl. Uma observação deve ser feita, após a instalação do servidor e dos
pacotes da solução, deve-se verificar no site http://distro.conectiva.com.br/atualizacoes/ se existem atualizações necessárias
para fazer ao sistema operacional, bem como a solução.
15
14.2. Procedimentos de Instalação
A configuração no servidor deve ser feita no arquivo /etc/squid/squid.conf. Nos clientes, a configuração é feita no browser,
será explicada mais a frente.
14.3. Configurando o Servidor
O arquivo squid.conf
Este arquivo contém todas as configurações do servidor Squid. Aqui serão descritas as configurações necessárias. Conforme
dito anteriormente, este arquivo possui várias opções para se configurar o servidor. A maioria destas opções estão comen-
tadas, e apenas algumas são realmente necessárias, em uma instalação típica. Caso alguma opção precise ser modificada,
descomente a linha referente (retire o caracter “#” à frente da opção).
Seção NETWORK OPTIONS
http_port - A porta na qual o Squid irá atender as requisições feitas a ele. O default é 3128, caso precise alterar este valor,
descomente a linha e troque-o por alguma porta que não esteja sendo utilizada. Ex:
http_port 3000
As opções restantes nesta seção do arquivo (icp_port, htcp_port,etc) referem-se ao protocolo ICP (Internet Cache Protocol),
protocolo para a comunicação de caches entre si, para se construir uma hierarquia. Não será abordado aqui.
Seção OPTIONS WHICH AFFECT THE CACHE SIZE
cache_mem - O squid utiliza muita memória por razões de performance. Ele leva muito tempo para ler algo do disco rí-
gido, por isso o faz diretamente da memória. Por padrão, o servidor utiliza 8 MB de memória, para objetos em trânsito.
Provavelmente o processo do squid irá tornar-se 2 ou 3 vezes maior do que o exposto aqui.
Recomenda-se colocar 1/4 da quantidade de memória RAM de sua máquina neste campo, se não for um serviço dedicado
desta máquina. Se a máquina roda apenas o squid, pode-se colocar metade da memória para seu uso. Por exemplo, em uma
máquina com 64MB de memória:
cache_mem 32 MB
cache_swap_low , cache_swap_high - Aqui define-se valores mínimo e máximo para a reposição de objetos na cache. Quanto
mais próxima a utilização da cache do máximo definido, maior é a reposição dos objetos (objetos antigos são retirados da
16
cache para a entrada de novos).
Os valores deste campo são medidos em percentagem, com o default sendo 90% para cache_swap_low e 95% para ca-
che_swap_high. Se você tem um espaço muito grande para a cache em seu winchester, 5% poderiam ser centenas de MB. Se
este é o caso, pode-se setar estes números mais próximos.
cache_swap_low 90
cache_swap_high 95
maximum_object_size - medido em bytes, especifica o tamanho máximo dos arquivos a serem cacheados. Quaisquer objetos
maiores do que este tamanho _não_ são salvos no disco. O default é 4MB.
maximum_object_size 4096 KB
Seção LOGFILE PATHNAMES AND CACHE DIRECTORIES
cache_dir - diretórios de cache no servidor. Pode-se especificar múltiplas linhas cache_dir para dividir a cache entre diferentes
partições do winchester.
Uso: cache_dir Type Directory-Name Mbytes Level-1 Level-2
Type especifica o tipo de sistema de alocação que será usado. Geralmente é do tipo "ufs".
Directory é o diretório onde os arquivos da cache serão alocados. Pode-se especificar um mount-point aqui, caso queira-se
utilizar um disco inteiro. O diretório deve existir e ter permissão de escrita pelo processo do Squid. O Squid não cria este
diretório para você. Se nenhuma linha ’cache_dir’ é especificada, o default usado é: /var/spool/squid.
Level-1 e Level-2 são respectivamente o número de sub-diretórios de primeiro e segundo nível que serão criados abaixo de
’Directory’. Os defaults são 16 para Level-1 e 256 para Level-2.
Ex:
cache_dir ufs /var/cache 1000 16 256
Com isto, dizemos para o squid utilizar o diretório /var/cache , até 1000MB, criando 16 sub-diretórios e 256 sub-diretórios
abaixo destes últimos.
Pode utilizar um cálculo para adaptar os diretórios, conforme o espaço que vai se deixar para o cache. Abaixo segue a
fórmula:
L1 = (tamanho cache_dir * 2) / tamanho médio de objeto / L2

/ L2
17
Sendo L1 => valor que será posto no diretório de primeiro nível.
O número 2 é usado como um valor de segurança para a projeção, maiores informações veja seção de Referências no fim
deste documento.
Tamanho do cache_dir => Valor que será destinado para o diretório ou partição do cache.
Tamanho médio de objeto => Normalmente os objetos da Internet, tem 13Kb de tamanho médio.
Sendo L2 => diretórios de segundo nível, como mencionado o valor default é 256.
Um exemplo prático seria, tendo uma HD de 8Gb como seria a adaptação do diretório de primeiro nível:
L1 = (8000000 * 2) / 10 / 256 / 256
cache_access_log - arquivo no qual será gerado log dos acessos ao servidor. O default é /var/log/squid/access.log
cache_access_log /var/log/squid/access.log
cache_log - arquivo onde são guardadas informações gerais sobre o comportamento do cache. O default é /var/log/squid/cache.log
cache_log /var/log/squid/cache.log
cache_store_log - loga as atividades do gerenciador de alocação. Reporta quais objetos são retirados do cache, quais são
salvos e por quanto tempo. Este log pode ser desabilitado, colocando: cache_store_log none , pois não há realmente utilidade
para analisar estes dados. O default é /var/log/squid/store.log
cache_store_log none
pid_filename - arquivo que guarda o process-id do squid. Para desabilitar, altere o parâmetro para none:
pid_filename none
Seção OPTIONS FOR EXTERNAL SUPPORT PROGRAMS
Nesta seção pode-se especificar vários programas externos que o squid precisa utilizar. Apenas uma opção pode ser necessária
alterar, que é o autenthicate_program. Todas as outras pode-se deixar comentadas que o squid irá utilizar seus padrões.
autenthicate_program - é comum os administradores restringirem o acesso ao Proxy aos seus clientes. Para isto, pode-se
pedir usuário e senha ao usuário para poder navegar utilizando o Proxy. Este serviço é feito pelo autenthicate_program
(programa autenticador). O pacote do squid inclui um programa autenticador chamado ncsa_auth , o qual utiliza arquivos
de senhas no formato htpasswd do Apache (veja man 1 htpasswd). Pode-se utilizar algum outro programa, se quiser.
O executável do ncsa_auth está no diretório /usr/lib/squid< versão >. É preferível copiá-lo para um diretório de arquivos
binários (/usr/bin por exemplo). Uma linha típica de configuração seria:
18
autenthicate_program /usr/bin/ncsa_auth /etc/squid/squid_passwd
O arquivo /etc/squid/squid_passwd deve ser criado com o comando htpasswd:
#htpasswd -c /etc/squid/squid_passwd
#htpasswd /etc/squid/squid_passwd
Utilize htpasswd -c se o arquivo não existe e precisa ser criado, e somente htpasswd para atualizar o arquivo de senhas.
Por default, o programa autenticador não é utilizado. Se você utilizar o ncsa_auth (ou algum outro autenticador), deve existir
uma ACL do tipo proxy_auth para permitir ou não o acesso. ACLs(Access Control List) são detalhadas abaixo.
Existem outras maneiras de utilizar a autenticação usando o PAM e os módulos para NIS e SMB, eles encontram-se no
diretório /usr/lib/squid.
Seções OPTIONS FOR TUNING THE CACHE e TIMEOUTS
Estas duas seções não precisam ser modificadas. Pode-se alterar alguns valores de timeouts, porém raramente é necessário
mexer nas outras opções.
Seção ACCESS CONTROLS
Esta seção é uma das mais importantes do arquivo. Aqui definimos a política de segurança do squid, ou seja, quem vai
acessar, o que vai acessar e quando poderá ser acessado.
Definindo uma access list:
A forma geral de uma acl é : acl < nome> < tipo>

Existem vários tipos de access lists, alguns estão listados abaixo:
acl nome src ip/netmask (endereços IP’s de clientes)

acl nome src ender.1-ender.2/netmask (intervalo de IP’s)
acl nome dst ip/netmask (endereço IP de alguma URL)
acl nome srcdomain foo.com (IP)
acl nome dstdomain foo.com (servidor de destino da URL)
acl nome time [dia-abrev.] [h1:m1-h2:m2]
O squid define access lists padrões, as quais estão abaixo:
acl all src 0.0.0.0/0.0.0.0

acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
19
acl Safe_ports port 80 21 443 563 70 210 1025-65535
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
1. acl all src 0.0.0.0/0.0.0.0 : esta acl define todos os hosts da rede (0.0.0.0/0.0.0.0) com o nome "all".
2. acl manager proto cache_object : o campo “proto” nesta linha significa que a acl bloqueia um protocolo específico,
neste caso o protocolo “cache_object”. Poderia ser os protocolos FTP ou HTTP. Se você não conhece o protocolo
“cache_object”, não se preocupe - é um protocolo apenas do Squid que retorna informação para o servidor de como o
cache está configurado, ou como está funcionando.
3. acl localhost src 127.0.0.1/255.255.255.255 : esta acl define a máquina localhost, e é nomeada com o mesmo nome,
localhost.
4.
Estas access lists contém as portas consideradas seguras para o proxy. Todas as outras portas são consideradas inseguras,
e o acesso é negado.
5. acl CONNECT method CONNECT

Esta ACL contém o método de acesso aos arquivos na rede (GET,POST). O método CONNECT é usado tanto para GET
como para POST.
Vamos definir aqui também a access list referente ao controle de acesso dos usuários ao proxy:
acl password proxy_auth REQUIRED
Password é o nome da access list, a access list é do tipo proxy_auth (autenticação de usuários). O campo REQUIRED informa
ao Squid para procurar o nome/senha do usuário com todos os nomes/senhas existentes no arquivo /etc/squid/squid_passwd,
descrito anteriormente. Pode-se também colocar um a um os nomes de usuários a ser procurados no arquivo squid_passwd,
em vez do campo REQUIRED.
Agora que já temos as access lists, precisamos aplicá-las informando ao Squid se o acesso a elas será ou não permitido. O
campo http_access é responsável por esta tarefa.
Configuração padrão do campo http_access:
20
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
E mais abaixo:
http_access deny all
Descrição detalhada abaixo:
1) http_access allow manager localhost : dá acesso ao protocolo cache_object apenas para o próprio servidor (localhost).
2) http_access deny manager : nega o acesso ao protocolo cache_object para qualquer outra máquina.
3)
4)
http_access deny CONNECT

!SSL_ports
É perigoso permitir ao Squid conectar-se a certas portas. Por exemplo, foi demonstrado que pode-se usar o Squid comorelay
de SMTP (email). Relays de SMTP podem deixar brechas, para possíveis ataques do tipo "flood", isto é inundar os mailboxes
com milhares de e-mails. Para prevenir o relay de emails, o Squid nega requisições quando o número da porta da URL for 25
(porta SMTP). Outras portas também são bloqueadas. A regra 3 informa ao Squid para negar o acesso a qualquer porta que
não esteja na lista Safe_ports. A regra 4 nega qualquer conexão que não seja referente às portas seguras.
Por padrão, o Squid nega quaisquer outras requisições. Ao ser configurado, deve-se adicionar as access lists necessárias,
permitindo o acesso ao proxy.
Normalmente, apenas insere-se uma regra a mais:
http_access allow all
logo abaixo da última regra (http_access deny all). Porém, isto não restringe nem um pouco o acesso ao seu proxy. Pelo
contrário, permite o acesso ao proxy a partir de qualquer máquina na Internet. Podemos então, por exemplo, inserir a regra
referente ao controle dos usuários em vez desta última regra acima:
http_access allow password
Imediatamente antes da regra http_access deny all. Assim, apenas os usuários que estão cadastrados no arquivo de senhas
podem ter acesso ao proxy. Quando o cliente abre o navegador, é solicitado ao usuário, que informe login e senha para acesso
ao proxy. Se o cliente não tem senha, não consegue acessar nada via proxy.
Outra maneira de limitar o acesso é criar access lists contendo toda a rede da organização, e permitir acesso apenas para estas
access lists, sendo negado para qualquer outra máquina, fora desta regra.
21
A opção http_access tem um comportamento bem simples:
- Se não há nenhuma linha "http_access" presente, o default é permitir a requisição.
- Se nenhuma linha que possua "http_access" resolve a requisição, o default é o oposto da última linha na lista. Se a última
linha é "deny", então o acesso é permitido, e vice-versa. Por este motivo, é conveniente ter uma entrada "deny all" ou "allow
all" ao final de suas listas de acesso para evitar confusão.
proxy_auth_realm : especifica o nome que será reportado ao cliente para a autenticação do proxy, (parte do texto que o
usuário verá quando solicitado pelo seu login e senha). Pode-se alterar para o nome da organização, do servidor, o que for
melhor. Ex:
proxy_auth_realm Servidor Squid em

Conectiva
Seção ADMINISTRATIVE PARAMETERS
Esta seção é bem pequena, porém importante.
cache_mgr : Endereço de e-mail do gerenciador local da cache, que irá receber emails se ocorrerem problemas com o proxy.
O default é "webmaster".
cache_mgr webmaster
cache_effective_user e cache_effective_group : Se o usuário root inicializa o servidor proxy, ele irá mudar seu efetivo
UID/GID para o especificado abaixo, por questões de segurança. Geralmente se muda o UID/GID abaixo para nobody.
Se o Squid não é iniciado como o usuário root, o default é conservar o corrente UID/GID do processo.
cache_effective_user nobody
cache_effective_group nobody
visible_hostname : É possível apresentar um hostname "especial" em mensagens de erro e outras mensagens, especificando
aqui o "hostname". Se não for especificado, é usado o valor de retorno de gethostbyname(), (normalmente o próprio hostname
do servidor Proxy).
visible_hostname proxy.conectiva
Seção OPTIONS FOR THE CACHE REGISTRATION SERVICE
Esta seção não precisa ser alterada na configuração do Squid.
Seção HTTPD-ACCELERATOR OPTIONS
Se deseja-se rodar o Squid como acelerador web ou proxy transparente, deve-se alterar os valores das opções desta seção. Há
um tutorial de como configurar o squid para trabalhar como proxy transparente utilizando ipchains (deve-se inserir regras de
22
firewall no kernel para o proxy transparente funcionar). Está disponível em:
Transparent Proxy with Linux and Squid (http://www.unxsoft.com/transproxy-linux20-squid1.html)
Seção MISCELLANEOUS
Como o próprio nome diz, esta seção oferece opções extras, como configurar as mensagens de erro de acesso que aparecem
para os clientes, testes de DNS, configuração do diretório de ícones e de arquivos de mensagens de erro do squid, entre outras.
Nenhuma opção precisa ser modificada. A opção cachemgr_passwd é interessante. Existe um programa CGI chamado ca-
chemgr.cgi, que o pacote rpm do squid instala no diretório /usr/lib/squid. Pode-se utilizar este programa para verificar as
configurações feitas, o funcionamento do proxy, bem como parar ou iniciar o serviço, tudo via Web.
A configuração é da seguinte maneira:
1- Copiar o cachemgr.cgi do diretório /usr/lib/squid para o diretório /home/httpd/cgi-bin.
2- Editar o arquivo de configuração /etc/squid.conf
3- O squid já possui uma configuração default, a única coisa que é preciso fazer caso o servidor web esteja na mesma máquina
que o servidor de proxy, é descomentar na seção MISCELLANEOUS, os seguintes ítens.
cachemgr_passwd SUA SENHA shutdown (Senha para dar desligaro ser-

viço)
cachemgr_passwd SUA SENHA info stats/objects (Senha para acessar estatíti-
cas dos objetos)
cachemgr_passwd SUA SENHA all (Senha para acessar todos os re-
cursos)
Caso a máquina seja destinada somente para o proxy, pode-se copiar o cachemgr.cgi para o diretório cgi-bin de um servidor
web, e acessar as informações do servidor de proxy, além disto faz-se necessário a alteração nas configurações do proxy
acrescentando ACLs.
Na seção CONTROLS, deve-se acrescentar uma ACL nova, para que outras máquinas que são servidores web possam acessar,
isto porque não é o cliente que deve ser liberado para acesso e sim o servidor web deve ter este acesso, desta forma o squid
verifica na ACL que servidor pode acessar as estatísticas, abaixo segue:
acl all src 0.0.0.0/0.0.0.0

acl manager proto cache_object
acl Nova_Regra src ip/netmask (Linha nova onde é definido quais máquinas vão ter aces-
so, ao gerenciador)
acl localhost src 127.0.0.1/255.255.255.255
23
acl CONNECT method CONNECT
Na sequência alterar as seguintes linhas na mesma seção:
http_access allow manager localhost

http_access allow manager Nova_Regra (Linha nova onde é definido acesso para ge-
renciar "cache_objects", apenas às máquinas da ACL Nova_Regra)
http_access allow CONNECT !SSL_ports
Seção DELAY POOL PARAMETERS
Esta seção trata sobre Multicast e Cache Digest. Embora não utilizemos estes recursos, é interessante saber do que se tratam.
Multicast é a capacidade de enviar um pacote IP para múltiplos destinatários ao mesmo tempo. É utilizado por exemplo em
sistemas de vídeoconferência.
Cache Digest é um sumário dos componentes de um servidor de cache. Contém, em um formato comprimido, uma indicação
se determinada URL está ou não na cache. Deve ser utilizado em conjunto com caches irmãos/pais (hierarquia de caches).
Servidores proxy periodicamente trocam seus "digests" entre si. O funcionamento é simples: quando uma requisição para
uma URL é recebida de um cliente, o servidor cache, caso não possua o arquivo requisitado, pode enviar "digests" para os
outros caches definidos em sua hierarquia, afim de descobrir se algum deles contém o objeto. O servidor cache pode então
requisitar o objeto do cache mais próximo.
14.4. Configuração Avançada

Nesta seção veremos algumas funcionalidades de nível avançado da solução:
14.4.1. Configuração Automática de Cache
Como visto em sessões anteriores, os Browsers podem ter todas as opções configuradas de maneira manual, outra forma de
configurar seria baixando um arquivo de auto-configuração, onde há todas as informações referentes ao cache que deve ser
utilizado. E qualquer regra de acesso feita no proxy, fica transparente do ponto de vista do usuário.
Como é feito: O arquivo de configuração do proxy é feito em JavaScript, o arquivo precisa definir a função.
function FindProxyForURL(url, host)

{
24
return DIRECT;
}
Esta função será chamada pelo browser, todas as vezes que uma URL for requisitada, onde temos:
ret = FindProxyForURL(url, host);
onde:
• URL - É o endereço da URL completo;
• HOST - O nome do host é extraído da URL. Isto é somente para conveniência, isto é a mesma string como "://" e o
primeiro ":" ou "/" depois disto. O número da porta não é incluído neste parâmetro. Isto pode ser extraído da URL quando
necessário;
• RET - (O valor retornado) uma string descrevendo a configuração. O formato da string é definido abaixo:
Este exemplo abaixo, diz ao browser para conectar ao servidor cache chamado cache.dominio.exeplo na porta 3128. Se a
máquina estiver desativada ou parada por qualquer razão que seja, uma mensagem de erro será retornada ao usuário.
function FindProxyURL(url, host)

{
return "PROXY cache.dominio.exeplo:3128";
}
Pode-se ter a situação em que deseja-se, fazer conexão em um segundo proxy, caso o primeiro falhe e por fim se o segundo
falhar tentar uma conexão direta, caso isto esteja disponível.
function FindProxyURL(url, host)

{
return "PROXY cache1.dominio.exeplo:3128; PROXY cache2.dominio.exepl
}
Salvando o Arquivo de Auto-configuração e Configurando o tipo MIME

1. Deve-se salvar a função JavaScript em um arquivo com a extensão ".pac"; Por exemplo:
25
proxy.pac
Observação 1: Você prcisa salvar a função JavaScript somente, não embutida em um arquivo HTML.
2. Próximo, deve-se configurar seu servidor para mapear o arquivo ".pac", na seção de tipos MIME:
application/x-ns-proxy-autoconfig pac
Use a tag AddType no servidor web.

Existem várias funções que podem ser usadas, maiores detalhes podem ser encontrados em anexo neste documento na seção
de referências no item Proxy Client Autoconfig File Format.
14.4.2. Filtro com Squidguard
Esta ferramenta em combinação com o Squid, é capaz de:
• Faz controle por diferentes faixas de tempo (horas do dia (00:00-08:00 17:00-24:00), dias da semana (sa), datas (1999-05-
13), faixas (1999-04-01-1999-04-05), recurso de caracteres coringas (*-01-01 *-05-17 *-12-25), simplificando o controle;
• Permite especificar grupos de origem e destino, dividindo em categorias como "gerentes", "empregados", "professores",
"alunos", "clientes", "visitantes", baseando-se na combinação de faixas de endereços ips, lista de endereços, lista de domí-
nios, lista de usuários;
• Possibilita redirecionamento pela combinação de expressões regulares e URLS;
• Controle baseado em ACLs, permite criação de conjuntos de quem tem ou não acesso baseado em endereços de ori-
gem/destino, faixas de endereços ip, etc., com isto é possível criar conjuntos de regras
Instalação: abaixo segue os passos para a instalação do SquidGuard, respeitando as suas respectivas dependências, vale
lembrar que o Squid, já deve estar previamente instalado.
Primeiro deve-se instalar os pacotes do DB um sistema de banco de dados embarcado, é um conjunto de ferramentas que
providencia alta performance em suporte a bases de dados.
rpm -i db-2.7.7-6cl.i386.rpm
rpm -i db-devel-2.7.7-6cl.i386.rpm
A seguir deve-se proceder com a instalação do pacote do SquidGuard.
rpm -i squidGuard-1.1.4-15cl.i386.rpm
26
Configuração: O squidGuard por ser uma ferramenta de bloqueio de sites WWW e que funciona em conjunto com o servidor
proxy Squid, possui uma configuração que envolve as duas ferramentas, tal configuração é abordada na sequência abaixo.
Edite o arquivo: /etc/squid/squid.conf
Em seguida procure a linha "redirect_program none" esta linha por default está comentada. Troque esta linha por:
redirect_program /usr/bin/squidGuard -c /etc/squidGuard/squidGuard.conf
Para configurar o squidGuard afim de que atenda às suas necessidades no Conectiva Linux, edite o arquivo squidGuard.conf:
# Arquivo de Configuração do SquidGuard

#
dbhome /usr/squidGuard/db # diretório onde estão os bancos de da-

dos com os blacklists
logdir /usr/squidGuard/logs # diretório onde ficam localizados os logs do S
Nestas primeiras linhas ficam as configurações, relativas ao path dos arquivos com as listas de sites, URLs e domínios
que serão usados para filtrar, todos no formato B-tree este formato otimiza as consultas a estes arquivos. Esta configuração
também informa ao SquidGuard onde deve por os arquivos de log.
#
# REGRAS DE TEMPO:
#
# abreviaturas para os dias de semana:
# s = Domingo, m = Segunda, t = Terça, w = Quarta, h = Quinta, f = Sexta, a = Sábado
time workhours {
weekly mtwhf 08:00 - 18:00
date *-*-01 08:00 - 18:00
}
Nesta seção é possível definir faixas de tempo onde o acesso será permitido, desta maneira as acls relativas a tempo tornam-se
simplificadas.
27
Alguns exemplos de configuração de dias da semana, com opção de restrição por tempo para cada dia:
weekly {smtwhfa} [HH:MM-HH:MM]

ou
weekly dayname [...] [HH:MM-HH:MM]
onde s=sun, m=mon, t =tue, w=wed, h=thu, f=fri, a=sat.
e dia da semana pode ser posto como os exemplos abaixo:
"mon", "monday", "mondays", (sinônimos)
"tue", "tuesday", "tuesdays", (sinônimos)
"wed", etc.
De segunda a sexta, manhãs e noites:
weekly mtwhf 00:00-08:00

weekly mtwhf 17:00-24:00
e para sábados e domingos:
weekly as
ou
weekly saturday
weekly sunday
Hora do dia:
weekly * HH:MM-HH:MM
weekly * 00:00-08:00
weekly * 17:00-24:00
Máscaras para Data com restrições de tempo:
date YYYY-MM-DD [HH:MM-HH:MM ...]

ou
date YYYY.MM.DD [HH:MM-HH:MM ...]
onde YYYY, MM e DD podem ser um asterisco, "*".
Para todo primeiro dia do ano:
28
date *.01.01
Para maiores informações sobre declarações de nomes/rótulos, quebra de linhas longas, declaração de paths, espaços de
tempo, declarações de grupos origem e destino,Também são usados:
#
# REGRAS DE REESCRITA:
#
rew dmz {
s@://admin/@://admin.foo.bar.no/@i
s@://foo.bar.no/@://www.foo.bar.no/@i
}
Esta regra funciona semelhante ao comando "sed" para fazer reescrita, maiores informações sobre as expressões que podem
ser utilizadas, podem ser adquiridas em "http://www.squidguard.org/config/#Rewritegroups" e "http://www.squidguard.org/config/#Regular
expressions".
#
# ENDEREÇOS DE ORIGEM:
#
src admin {
ip 10.0.2.0 192.168.0.1 192.168.255.1
user root
within workhours
}
src classe_A {
ip 10.0.0.0/255.255.248.0
}
src classe_C {
ip 192.168.0.0/24 192.168.1.0/24 192.168.255.0/24
}
src default {
ip 10.0.0.0/255.255.248.0
}
Nesta seção pode-se separar em grupos as máquinas da rede para um gerenciamento melhor, como mostrado no exemplo
acima.
29
#
# CLASSES DESTINO:
#
dest good {
# Coloque aqui as regras de endereços cujo acesso é necessário
}
dest local {
# Coloque aqui os endereços cujo acesso deve ser permitido localmente no(s) servido
}
dest adult {
domainlist porn/domains
urllist porn/urls
expressionlist porn/expressions
}
dest ads {
domainlist ads/domains
urllist ads/urls
}
dest aggressive {
domainlist aggressive/domains
urllist aggressive/urls
}
dest audio-video {
domainlist audio-video/domains
urllist audio-video/urls
}
dest drugs {
domainlist drugs/domains
urllist drugs/urls
}
dest gambling {
domainlist gambling/domains
urllist gambling/urls
}
dest hacking {
domainlist hacking/domains
urllist hacking/urls
}
30
dest violence {
domainlist violence/domains
urllist violence/urls
}
dest warez {
domainlist warez/domains
urllist warez/urls
}
#acl {
# admin {
# pass any
# }
#
# foo-clients within workhours {
# pass good !in-addr !adult any
# } else {
# pass any
# }
#
# bar-clients {
# pass local none
# }
##}
#acl {
# default {
# pass !adult !ads !aggressive !audio-video !drugs !gambling !hac-
king !violence !warez all
# redirect http://<SEU-SERVIDOR>/cgi-bin/squidGuard.cgi?clientaddr=%a&clientnam
# }
# }
Na seção acima dando continuidade a idéia de grupos, também podemos observar que estes grupos de urls e dominios de
destinos previamente cadastrados, que possuem os seguintes conteúdos: violento, pirataria, drogas, pornográficos, etc. são
posteriormente utilizados na acl default.
Onde temos passagem permitida para tudo que for diferente destes grupos proibidos, uma vez que o usuário tente acessar
conteúdo proibido a função "redirect" faz com que o usuário receba um endereço diferente, com seus dados e um aviso de
proibição.
/etc/squidGuard/squidGuard.conf - Descomente a linha "redirect" no fi-

nal deste arquivo, insira o endereço do servidor onde hospedará o script squidGuard.cgi.
Se quiser, pode-se modificar este cgi (está em Perl), para aparecerem outros dados referentes ao usuário que tentou acessar
31
uma página proibida.
Para iniciar o servidor squid, rode os comandos:
[root@localhost]# cds
[root@localhost]# ./squid start
ou
[root@localhost]# service squid start
14.4.3. Cache Hierárquico
O squid é particularmente bom em comunicar-se com outros caches e proxies. Possui suporte a numerosos protocolos de
intercomunicação de proxies, incluindo ICP (protocolo de Inter-Cache), Cache-Digests, HTCP (Hyper-Text Cache Protocol)
e CARP (Cache Array Routing Protocol) e cada um deles possui qualidades e fraquezas específicas, sendo utilizados em
algumas circustâncias mais do que outros dependendo da ocasião.
Existe algumas vantagens em ter uma configuração hierárquica de caches:
• Reduzir a Latência da Rede;
• Evita duplicação de objetos no cache;
• Aumenta a taxa de requisições;
• Evita o gargalo na rede, ocasionado por um cache só com muito tráfego;
• Melhor aproveitamento dos HDs (Discos Rígidos) dos servidores cache;
• Economia poupando a largura de banda da Internet.
Configuração:A configuração de cache hierárquico será vista a seguir:

Faz-se necessário ao Squid, alguma informação básica sobre como falar com outra máquina, então usa-se a linha ca-
che_peercom os seguintes campos nome do host, o tipo de relacionamento usando parent, sibling, multicast, conjunto de
portas HTTP dos servidores de destino, e assim por diante.
Uma linha exemplicando o cache_peer é mostrada abaixo:
cache_peer domain.example parent 3128 3130 default
No caso desta configuração ser feita no servidor que deseja-se que atue no papel de cache pai, esta linha faria com que tal
servidor aceitasse requisições de servidores filhos, contudo esta configuração deveria ser feita nos caches filhos acrescentando
esta linha também, e no servidor pai não deve-se esquecer de configurar quais serão os seus cache(s) filho(s), como pode ser
32
observado abaixo:
Configuração necessária para um servidor pai cujo nome é father.domain.example e com um filho son.domain.example:
cache_peer father.domain.example parent 3128 3130

cache_peer son.domain.example sibling 3128 3130
No caso do servidor(s) filho(s) teríamos a seguinte configuração:
cache_peer father.domain.example parent 3128 3130
No quinto campo pode-se como no primeiro exemplo ter algumas opções: proxy-only, weight, ttl, no-query, default, round-
robin, multicast-responder, closest-only, no-netdb-exchange, no-delay, login, nesta solução comentaremos alguns dos mais
usuais.
proxy-only: Esta opção indica que dados recuperados desta máquina remota não serão armazenados localmente, mas recu-
perados novamente em qualquer requisição subsequente. Por default o Squid armazena objetos que foram requisitados de
outros caches. O uso desta opção implica em dois aspectos, primeiro aspecto seria de que uma vez que o objeto requisitado
seja armazenado no cache filho a latência diminui, segundo aspecto seria se o outro cache estiver no mesmo barramento
ethernet, isto poderia acarretar em um disperdício de largura da banda.
weight: Se mais de um servidor cache tiver um objeto (baseado no resultado de uma consulta ICP), o Squid decidirá obter
os dados do cache que responder mais rápido. Caso haja interesse em dar prioridade sempre a um cache específico, pode-se
utilizar desta opção weight, o funcionamento é o seguinte o cache que terá o valor mais alto configurado será o que terá a
preferência, pois o Squid verifica o tempo que leva cada requisição ICP (em milisegundos), e divide este tempo pelo valor
atribuído a opção weight, baseado nestes valores para cada cache terá um resultado, o cache que obtiver o menor resultado
será usado.
no-query: O Squid envia requisições ICP para todos os caches configurados. O tempo de resposta é mensurado e usado para
decidir a que pai enviar a requisição HTTP.
Existe outra função destas resquisições: se não existir resposta para uma requisição, o cache é marcado como desligado ou
inativo. Caso a comunicação seja feita com um cache que não suporta ICP isto ocorrerá, então pode-se utilizar esta opção
para que ele não use ICP, e para resolver o problema de saber se a máquina está ativa, pode-se no arquivo de configuração
apontar a porta ICP para a porta echo de número 7, vale lembrar que deve ser descomentada no arquivo inetd.conf para que
suporte a porta echo utilizando UDP, normalmente esta opção é utilizada com a opção default.
default: Esta opção configura o host, para ser o proxy que será o último recurso. Se nenhum cache combina com a regra (isto
é uma acl ou filtro de domínio), este cache é usado. No caso de existir apenas uma maneira de sair para a Internet e ela não
suportar ICP, pode-se utilizar a combinação das opções default e no-query, e em caso de estar desligado ou inativo o cliente
receberá uma mensagem de erro.
Para maiores detalhes pode-se consultar a URL "http://squid-docs.sourceforge.net/latest/html/x2193.htm", onde explica a
utilização de outros parâmetros.
Selecionando por Domínio de Destino: Esta opção é bastante interessante, porque dependendo do domínio a ser acessado,
pode-se direcionar para um determinado proxy fazer o atendimento da requisição, abaixo veremos um exemplo.
cache_peer_domain cache1.domain.example !.mydomain.example
33
Neste exemplo vimos que se for o destino diferente do domínio que termine com "mydomain.example", então utilize o
cache1.domain.example como proxy, isto foi feito usando o recurso cache_peer_domain melhorando a administração da
hierarquia de proxies. A seguir será mostrado um outro recurso baseado em ACLs para fazer o redirecionamento.
Selecionando com ACLs: O Squid pode fazer seleções de caches baseado no resultado das regras de uma ACL. Com a
utilização do recurso de cache_peer_access, podemos ter por exemplo uma regra que todas as requisições feitas por uma faixa
especifica de enderecos IP, sejam enviadas para um servidor cache especifico, podendo ser usado com fins de contabilização,
abaixo um exemplo prático.
acl myNet src 10.0.0.0/255.255.255.0 acl custNet src 10.0.1.0/255.255.255.0

acl all src 0.0.0.0/0.0.0.0 cache_peer cache.domain.example parent 3128 3130
cache_peer_access cache.domain.example allow custNet cache_peer_access
cache.domain.example deny all
Podemos ter um exemplo onde URLs suspeitas sejam enviadas a um cache que faça a filtragem
acl suspect_url url_regex "/usr/local/squid/etc/suspect-url-list" acl all src

0.0.0.0/0.0.0.0 cache_peer filtercache.domain.example parent 3128 3130
cache_peer_access filtercache.domain.example allow suspect_url # Todas as
outras requisições vão direto cache_peer_access filtercache.domain.example
deny all
A seguir veremos alguns mecanismos utilizados para que seja arbitrado o uso ou não do cache, conforme o domínio de
destino usando always_direct e never_direct.
As Tags Always_direct e Never_direct: O Squid verifica todas as tags always_direct antes de verificar qualquer tag ne-
ver_direct. Se uma combinação casa com uma tag always_direct encontrada, o Squid não verificará a tag never_direct, mas
decidirá com que cache falar imediatamente. O comportamento pode ser visto no exemplo abaixo.
cache_peer cache.otherdomain.example parent 3128 3130

acl all src 0.0.0.0/0.0.0
acl localmachines dstdomain intranet.mydomain.example
never_direct allow all
always_direct allow localmachines
Vamos considerar uma requisição destinada a um servidor web "intranet.mydommain.example", o Squid primeiro verificará
a linha com alway_direct, e como as duas tags são consideradas acl-operators, apenas uma será considerada. Então uma vez
que a tag always_direct for usada, o squid permitira que na máquina "intranet.mydomain.example", o acesso será permitido
diretamente sem passar pelo proxy.
Uma outra possibilidade caso o always_direct fosse marcado com deny, todas as máquinas sem exceção, terão que passar
pelo proxy, segue outro exemplo com a modificação da regra.
cache_peer cache.otherdomain.example parent 3128 3130

acl all src 0.0.0.0/0.0.0
acl localmachines dstdomain intranet.mydomain.example
34
never_direct allow all
always_direct deny localmachines
Outras informações podem ser adquiridas acessando a URL "http://squid-docs.sourceforge.net/latest/html/x2268.htm" .
14.4.4. Autenticação Eficiente e Flexível
Nesta nova forma de autenticação será abordado, a utilização do PAM (Pluggable Authentication Modules). A seguir veremos
os passos necessários para abilitarmos este método.
Uma vez que o Squid foi instalado, pode-se encontrar o arquivo pam_auth, que está no diretório /usr/lib/squid/pam_auth,
este caminho deve ser inserido no arquivo de configuração /etc/squid/squid.conf no ítem authenticate_program.
authenticate_program /usr/lib/squid/pam_auth
Outras configurações que podem ser utilizadas em conjunto são vistas abaixo:
authenticate_children 5
Esta opção é do número de processos autenticadores que serão criados. Dessa forma pode-se aumentar os processos conforme
a necessidade o padrão é 5.
authenticate_ttl 3600
Se habilitado esta opção a senha passada na autenticação do usuário, é mantida por tantos segundos forem configurados no
próprio cache o padrão é 3600, sem fazer uma nova consulta ao programa autenticador. Em caso de ser passado uma senha
errada o programa de autenticação é novamente acionado.
authenticate_ip_ttl 0
Esta opção trata de um controle na associação da autenticação com um determinado ip, pode-se configurar o tempo de
controle.
Normalmente utilizada para inibir o compartilhamento de usuário e senha entre usuários que fazem autenticação para acesso
pelo proxy.
Ou seja se for setado 0 não é feito nenhuma checagem, no entanto se for posto um valor por exemplo 60 (configurado em
segundos), durante 60 segundos após a autenticação originada de uma máquina, nenhum outro usuário poderá ser autenticado
com mesmo usuário e senha em outra máquina, no momento que isto ocorrer será fechada a conexão com os dois usuários e
35
ambos serão obrigados a fazer a autenticação novamente.
Pode-se perceber que isto não impede a utilização de dois ou mais usuários, com o memso usuário e senha, mas dificulta o
uso criando um sentimento de inibição pelo uso seguido das solicitações de autenticação.
Recomenda-se que para usuários dial-up, não utilize-se mais que 60 segundos e para usuários fixos valores maiores podem
ser usados.
14.4.5. Controle de Uso de Largura de Banda
A solução Conectiva Proxy Server - WWW e FTP, possui uma característica de controle de largura de banda, como o custo
deste recurso é elevado pode-se utilizar esta solução a fim de otimizar e racionalizar o uso dos links da organização.
Requisito: Neste ítem deve-se levar em consideração o requisito de software, deve ser baixado o pacote de atualização para o
Conectiva 6.0, acessando a URL "http://distro.conectiva.com.br/atualizacoes/", para o squid
O mecanismo utilizado pelo Squid é baseado em Delay Classes, este recurso é muito usado em locais onde a largura de banda
é muito cara. Este recurso pode proporcionar uma diferenciação no acesso, priorizando serviços mais necessários, bem como
a divisão equalitária pelos usuários da rede.
O uso de Delay Classes poderá assegurar que alguma largura de banda, estará disponível para trabalhos relacionados a
download. Podendo classificar os downloads em segmentos, e então alocar esses segmentos em uma certa quantia da largura
de banda (em bytes por segundo), e o link permanecerá descongestionado para o tráfego útil.
Uma acl-operator (delay_access) é usada para dividir requisições em pools. O uso das acls, pode ser usado por endereços de
origem, url de destino e mais.
Existem mais de um tipo (ou classe) de pool. Cada tipo de pool permite que se possa limitar a largura de banda de diferentes
maneiras.
First Pool Class
A primeira maneira de configurar leva em conta apenas um pool, no exemplo abaixo o pool será usado para todas as URLs
contendo a palavra "abracadabra".
acl magic_words url_regex -i abracadabra

delay_pools 1
delay_class 1 1
delay_parameters 1 16000/16000
delay_access 1 allow magic_words
Neste exemplo foi demonstrado a limitação da velocidade de download por uma palavra na URL. Onde temos na primeira
linha uma ACL padrão, que retorna true se a URL requisitada tem a palavra "abracadabra", a flag -i, é usada para fazer a
pesquisa utilizando o caso-insensitivo.
A variável delay_pools, diz ao Squid quantos delay pools existirão. No exemplo acima houve apenas um pool, por isto a
opção foi configurada para "1".
Na terceira linha é criado um delay pools(delay pool número 1, a primeira opção) da classe 1 (que é a segunda opção no ítem
36
delay_class).
A primeira delay class é simples: as taxas de download de todas as conexões na classe são adicionadas juntas, e o Squid
mantém esse valor agregado abaixo do que foi dado no valor máximo.
Na quarta linha, na opção delay_parameters permite que seja configurada a velocidade de cada pool. A primeira opção é o
número do pool no caso "1", a segunda opção possui dois valores: o restore e max, separados por uma (/).
O valor de restore é usado para configurar a velocidade de download, e o max é para definir o tamanho do arquivo, que
quando for do valor definido passe pelo processo de download mais lento. Com isso os arquivos pequenos não serão afetados,
somente aqueles cujo tamanho comprometem a largura de banca, vale lembrar que este valor está em bytes.
Então no exemplo temos que quando forem baixados arquivos maiores de 16000 bytes (16kb), transfira na velocidade de
16000 bytes por segundo (16000 * 8 = 128 kps).
Second Pool Class
Nesta nova forma de configuração é possível, que se tenha uma administração mais fácil e mais detalhada a nível de usuário.
Pode-se ter um exemplo disso abaixo:
acl all src 0.0.0.0/0.0.0.0

delay_pools 1
delay_class 1 2
delay_parameters 1 12500/12500 2500/2500
delay_access 1 allow all
Neste exemplo, foi trocado a classe do delay de "1" para "2" permitindo especificar uma agregação entre uso da largura de
banda e uso por usuário que está em uma determinada rede. Foram acrescentadas novas cadeias de opções para a variável
delay_parameters, onde além de ter a definição de restore e max para o link geral, também para cada endereço ip existem
um restore e max fazendo uma outra configuração.
Então o valor de 100kbps convertido para bytes temos 12500 bytes por segundo, e arquivos de até 12500 bytes, para fazer
uma divisão por ips, foram acrescentados uma 2.5kbps para cada usuário, ou seja, 2500 bytes por segundo para cada usuário
em arquivos de 2500 bytes.
Third Pool Class
Na última opção que disponhe o Delay Class Pool, há como controlar o uso da largura de banda, sobre o aspecto de velocidade
da taxa de download geral e tamanho de arquivo, bem como por rede e tamanho igualitário de uso da largura de banda por
usuário. Vale ressaltar que esta divisão de redes funciona somente para redes classe C.
Um exemplo prático será visto a seguir utilizando-se de um Third Pool Class, com mais de uma rede.
acl all src 0.0.0.0/0.0.0.0

delay_pools 1
delay_class 1 3
#56000*8 configura o limite total até 448kbps
#18750*8 configura o limite por rede até 150kbps
#500*8 configura o limte por usuário até 4kbps
37
delay_parameters 1 56000/56000 18750/18750 500/500
delay_access 1 allow all
Neste exemplo foi mudado a classe do delay para 3. a variável delay_parameters, agora leva quatro argumentos: número do
pool, taxa da largura de banda, taxa da de largura de banda por rede, e por usuário.
Neste exemplo foi assumido que haviam três faixas de endereços ips. Cada faixa precisa usar não mais que 1/3 de sua
dispobilidade de largura de banda.
Assumindo que o link da organização era de 512kpbs, e desejava-se deixar 64kps disponível para SMTP e outros protocolos.
Sobrariam uma taxa de download, de 448kpbs. Cada faixa de ips de classe C, deveriam utilizar aproximadamente 150kps.
Com 3 faixas de 256 endereços ips cada, haveriam uma média de 500 pc’s, com um acesso por volta de 0.869 kbps por
máquina. Levando em consideração que nem todas as máquinas usem a rede ao mesmo tempo, você pode provavelmente
alocar para cada máquina por volta de 4kbps (500 bytes por segundo).
Uma última observação se por exemplo, não fosse definido valor para o ítem max, tanto para o geral, ou para cada rede, ou
usuário, bastaria simplesmente por "-1", exeplo abaixo da linha.
delay_parameters 1 56000/56000 18750/18750 500/-1
Neste caso para o pool "1" seria defina um restore de 56000 e max de 56000 bytes para o geral, dividindo para cada rede um
restore de 18750 e max de 18750 bytes, e para cada usuário um restore de 500 bytes por segundo e o max para arquivos sem
limite de tamanho.
14.5. Testes Pós-Instalação

Após configurado o arquivo squid.conf, podemos inicializar o servidor, rodando o script do squid a partir do diretório
/etc/rc.d/init.d
/etc/rc.d/init.d/squid start
Para inicializar o squid, cada vez que a máquina faz o processo de boot, execute o seguinte comando:
/sbin/chkconfig squid on
Quando o serviço do Squid é inicializado, os seguintes processos entram em execução:
/usr/bin/squid -> servidor iniciado pelo root

(squid) -> servidor com o UID/GID efetivo
38
(unlinkd) -> daemon que deleta arquivos da cache
(ncsa_auth) -> se for usado o programa autenticador
Vamos utilizar o Netscape para testar o servidor Proxy. Para o Netscape utilizar um servidor proxy, devemos configurá-lo
em:
Editar -> Preferências -> Avançado -> Servidores Proxy ->

Configuração manual do proxy
Podemos usar Proxy para FTP, Gopher e HTTP, como dito anteriormente. Vamos colocar apenas para FTP e HTTP. Nos
campos "Proxy FTP" e "Proxy HTTP", inserimos o par IP/Porta onde está configurado o proxy, deve-se observar qual a porta
foi configurada anteriormente, se for mantido o padrão será 3128.
Pode-se configurar endereços que não serão acessados via proxy, como por exemplo servidores locais à rede do cliente. Para
isto, deve-se inserir os domínios ou intervalos de endereços IP/netmask, no campo "Não utilizar proxy para:"
Acesse alguma página na Internet, www.conectiva.com.br por exemplo.
O servidor proxy deve guardar os arquivos de cache da página acessada abaixo do diretório /var/spool/squid (ou outro dire-
tório que foi especificado na opção cache_dir do squid.conf). Repita o procedimento em outra máquina da rede, configurada
com o proxy. A página acessada será carregada rapidamente, haja vista que a mesma já encontra-se no cache do servidor
proxy.
14.6. Backup de Configurações

Para evitar perder as configurações, faz-se necessário copiar o(s) arquivo(s) de configuração, no caso o squid.conf e havendo
um arquivo separado para as ACLs, deve ser copiado de igual forma, sempre lembrando que estes arquivos devem ficar no
diretório /etc/squid. Nesta ação, pode-se utilizar um disquete para fazer a cópia.
15. Documentação
É importante deixar uma documentação para o cliente do que foi feito, mantendo um registro das informações básicas da
solução, isto também facilitará ao técnico em uma posterior visita.
Anexo na solução encontra-se um script proxy_doc.sh (../arquivos/proxy_doc.sh), preparado para fazer a coleta das informa-
ções pós-instalação, e gerar um formulário que deve ser preenchido pelo técnico, copiado em mídia eletrônica e impresso,
este material deve ser deixado com o cliente e o técnico também deve levar uma cópia de igual teor, todas as cópias devem
conter as assinaturas do cliente e do técnico.
39
A execução do script deve ser feita, utilizando-se o usuário root.
Além do formulário citado nos parágrafos acima, deverá existir uma documentação contratual que fale sobre as garantias da
solução. O cliente precisa estar ciente de que o Planejamento e Implantação de Proxy WWW e FTP não garante a segurança
abosoluta de seu sistema e a sua configuração pode sofrer modificações conforme a necessidade do cliente, mediante contato
com o Suporte da Conectiva.
É importante também, deixar claro em documento formal que, se o cliente fizer alterações na solução por sua própria conta,
e a solução tenha que ser reinstalada/reconfigurada, o próprio cliente terá que arcar com os encargos provenientes destes
serviços.
16. Referências
URL do Squid:
Squid Web Proxy Cache (http://www.squid-cache.org)
URL sobre servidores Proxy em geral:
Proxy
Servers (http://serverwatch.internet.com/proxyservers.html)
Página sobre a utilização de arquivos ".pac" para configuração automática:
Proxy
Client Autoconfig File Format (http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/
live.html)
Página sobre a utilização do Squid como Proxy transparente:
Transparent Proxy with Linux and Squid (http://www.unxsoft.com/transproxy-

linux20-squid1.html)
Treinamento em Segurança (em portugês)

(http://treinamento.conectiva/profissional/seguranca/firewall/index.html) (http://trei
http://home.iae.nl/users/devet/squid/
HOWTO’s indicados para leitura:
- Firewall-HOWTO
- IPCHAINS-HOWTO
- IPMASQUERADE-HOWTO
- NET-3-HOWTO
- Networking-Overview-HOWTO
40
O RPM do Squid versão 2.3.3-09clpode ser encontrado em:
ftp://ftp.conectiva.com.br/pub/conectiva/6.0/cd1/conectiva/RPMS/squid-2.3.3-09cl.i386.rp
Links Relacionados ao SquidGuard
http://www.squidguard.org/
Listas de discussão sobre o Squid:
http://www.squid-cache.org/mailing-lists.html
Bibliografia
Roberto Teixeira e Carlos Mercer, Guia do Servidor, , Conectiva S.A., 2000, ISBN 85-87118-29-3.
Gerhard Mourani, Securing and Optimizing Linux: ReadHat Edition., Versão 1.3, Open Docs Publishing, 1999-2000, ISBN
0-9700330-0-1.
41
42

Squid

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Squid

Uploaded by

Copyright:

Available Formats

Planejamento e Implantação de Proxy

Marcio Malafaia Saliba

3. Clientes Potenciais ............................................................................................................................................................... 6

4. Cases e Cenários Típicos ..................................................................................................................................................... 7

5. Vantagens para o Cliente..................................................................................................................................................... 7

6. Operação e Administração da Solução .............................................................................................................................. 7

7. Atualizações dos Sistemas ................................................................................................................................................... 8

10. Soluções Relacionadas ....................................................................................................................................................... 9

11. Metodologia de Implantação........................................................................................................................................... 10

12. Requisitos de Tempo e Recursos Humanos ................................................................................................................... 11

13. Análise Técnica................................................................................................................................................................. 11

14. Implantação ...................................................................................................................................................................... 15

15. Documentação .................................................................................................................................................................. 39

4. Cases e Cenários Típicos

5. Vantagens para o Cliente

7. Atualizações dos Sistemas

Veja maiores informações sobre o treinamento Segurança de Redes(http://treinamento.conectiva/profissional/seguranca/firewall/index.html)

10. Soluções Relacionadas

11. Metodologia de Implantação

6. Fazer as configurações dos browsers nas máquinas clientes.

12. Requisitos de Tempo e Recursos Humanos

Tabela 1. Cronograma de Implementação da solução

Tarefa Tempo Recurso

13. Análise Técnica

requisições por segundo = 1000/tempo de busca (seek

requisições por segundo = 1000/(tempo de busca do

requisições por segundo = 1000/(12/3) = 1000/4 = 250

Número de objetos = tamanho do HD em bytes / tamanho

Para um HD de 8Gb pode-se armazenar cerca de 645.000 objetos.

Memória RAM: 64Mb

• CD’s do Conectiva Linux 6.0 ou superior

14.1. Procedimentos de Instalação e Configuração.

14.3. Configurando o Servidor

Seção NETWORK OPTIONS

Seção OPTIONS WHICH AFFECT THE CACHE SIZE

Seção LOGFILE PATHNAMES AND CACHE DIRECTORIES

cache_dir ufs /var/cache 1000 16 256

L1 = (tamanho cache_dir * 2) / tamanho médio de objeto / L2

L1 = (8000000 * 2) / 10 / 256 / 256

Seção OPTIONS FOR EXTERNAL SUPPORT PROGRAMS

O arquivo /etc/squid/squid_passwd deve ser criado com o comando htpasswd:

Seções OPTIONS FOR TUNING THE CACHE e TIMEOUTS

Seção ACCESS CONTROLS

Definindo uma access list:

A forma geral de uma acl é : acl < nome> < tipo>

acl nome src ip/netmask (endereços IP’s de clientes)

O squid define access lists padrões, as quais estão abaixo:

acl all src 0.0.0.0/0.0.0.0

5. acl CONNECT method CONNECT

acl password proxy_auth REQUIRED

http_access deny all

Descrição detalhada abaixo:

http_access deny !Safe_ports

http_access deny CONNECT

http_access allow all

http_access allow password

proxy_auth_realm Servidor Squid em

Seção ADMINISTRATIVE PARAMETERS

Esta seção é bem pequena, porém importante.

Seção OPTIONS FOR THE CACHE REGISTRATION SERVICE

Esta seção não precisa ser alterada na configuração do Squid.

Seção HTTPD-ACCELERATOR OPTIONS

cachemgr_passwd SUA SENHA shutdown (Senha para dar desligaro ser-

acl all src 0.0.0.0/0.0.0.0