Professional Documents
Culture Documents
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
2. Características Técnicas...................................................................................................................................................... 5
8. Gerenciamento da Solução.................................................................................................................................................. 8
9. Treinamento.......................................................................................................................................................................... 9
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.
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.
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).
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.
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.
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.
/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:
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:
12
Considerando um exemplo, onde temos 3 discos e tendo todos eles com 12ms de tempo busca. Teoricamente temos o
seguinte:
Para saber quantos objetos podem ser armazenados em disco de tamanho X, pode-se utilizar desta fórmula:
13
CPU: Pentium 200Mhz
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:
• 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.
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.
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).
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.
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
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:
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:
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:
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
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
#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.
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.
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.
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.
acl SSL_ports port 443 563
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
Estas access lists contém as portas consideradas seguras para o proxy. Todas as outras portas são consideradas inseguras,
e o acesso é negado.
Vamos definir aqui também a access list referente ao controle de acesso dos usuários ao proxy:
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:
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)
É 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:
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:
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:
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 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.
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:
23
acl CONNECT method CONNECT
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.
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.
24
return DIRECT;
}
Esta função será chamada pelo browser, todas as vezes que uma URL for requisitada, onde temos:
onde:
• 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.
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.
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
• 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;
• 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
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.
Em seguida procure a linha "redirect_program none" esta linha por default está comentada. Troque esta linha por:
Para configurar o squidGuard afim de que atenda às suas necessidades no Conectiva Linux, edite o arquivo squidGuard.conf:
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 as
ou
weekly saturday
weekly sunday
Hora do dia:
weekly * HH:MM-HH:MM
weekly * 00:00-08:00
weekly * 17:00-24:00
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.
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
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:
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:
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.
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.
Podemos ter um exemplo onde URLs suspeitas sejam enviadas a um cache que faça a filtragem
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.
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.
34
never_direct allow all
always_direct deny localmachines
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.
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.
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".
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).
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:
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.
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.
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.
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.
/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
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:
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.
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:
Proxy
Servers (http://serverwatch.internet.com/proxyservers.html)
Proxy
Client Autoconfig File Format (http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/
live.html)
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
http://www.squidguard.org/
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