Proxy

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 [email protected]

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, objetivos, 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:[email protected]). 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:[email protected]).

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 centralizada, 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 acrescentado 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 cachemgr.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 Implantaçã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 implantaçã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 particionamento 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 endereç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 configuraçã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 Levantamentos de endereços/máscaras das redes envolvidas e políticas do acesso do cliente. Instalação do sistema operacional Verificação/instalação de pacotes Aplicação das políticas levantadas, que serão configuradas no Proxy, usando-se as ACLs. Testes pós-instalação Documentação pós-instalação

Tempo 2 horas e 30 minutos Baseado na solução 1.1 30 minutos 45 minutos 45 minutos 15 minutos

Recurso

Consult

Baseado

Técnico

Consult

Consult

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 suportados 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 Levantamento 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 organizaçã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 gerenciamento 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 comentadas, 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 cache_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 acl acl acl acl acl nome nome nome nome nome nome src src dst srcdomain dstdomain time ip/netmask (endereços IP’s de clientes) ender.1-ender.2/netmask (intervalo de IP’s) ip/netmask (endereço IP de alguma URL) foo.com (IP) foo.com (servidor de destino da URL) [dia-abrev.] [h1:m1-h2:m2]

O squid define access lists padrões, as quais estão abaixo: acl acl acl acl all src 0.0.0.0/0.0.0.0 manager proto cache_object localhost src 127.0.0.1/255.255.255.255 SSL_ports port 443 563 19

acl acl acl acl acl acl

Safe_ports port 80 21 443 563 70 210 1025-65535 Safe_ports port 280 # http-mgmt Safe_ports port 488 # gss-http Safe_ports port 591 # filemaker Safe_ports port 777 # multiling http 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 acl acl acl acl acl SSL_ports port 443 563 Safe_ports port 80 21 443 563 70 210 1025-65535 Safe_ports port 280 # http-mgmt Safe_ports port 488 # gss-http Safe_ports port 591 # filemaker 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. 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 http_access http_access http_access E mais abaixo:

allow manager localhost deny manager deny !Safe_ports deny CONNECT !SSL_ports

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) http_access deny !Safe_ports 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 cachemgr.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 viço) cachemgr_passwd SUA SENHA info stats/objects cas dos objetos) cachemgr_passwd SUA SENHA all cursos) (Senha para dar desligaro ser(Senha para acessar estatíti(Senha para acessar todos os re-

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 acesso, ao gerenciador) acl localhost src 127.0.0.1/255.255.255.255 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 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 gerenciar "cache_objects", apenas às máquinas da ACL Nova_Regra) http_access deny !Safe_ports 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-0513), 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 origem/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 dos com os blacklists logdir /usr/squidGuard/logs # diretório onde estão os bancos de da-

# 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 user within } src classe_A { ip } src classe_C { ip } src default { ip }

10.0.2.0 root workhours

192.168.0.1

192.168.255.1

10.0.0.0/255.255.248.0

192.168.0.0/24

192.168.1.0/24

192.168.255.0/24

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 urllist expressionlist } dest ads { domainlist urllist } dest aggressive { domainlist urllist } dest audio-video { domainlist urllist } dest drugs { domainlist urllist } dest gambling { domainlist urllist } dest hacking { domainlist urllist }

porn/domains porn/urls porn/expressions

ads/domains ads/urls

aggressive/domains aggressive/urls

audio-video/domains audio-video/urls

drugs/domains drugs/urls

gambling/domains gambling/urls

hacking/domains hacking/urls

30

dest violence { domainlist urllist } dest warez { domainlist urllist }

violence/domains violence/urls

warez/domains 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 !hacking !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 final 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 cache_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, roundrobin, 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 recuperados 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 never_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 (squid) -> servidor iniciado pelo root -> servidor com o UID/GID efetivo 38

(unlinkd) (ncsa_auth)

-> daemon que deleta arquivos da cache -> 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 diretó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/transproxylinux20-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