Proxy Squid - 7

Trabalhando com hierarquias

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

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

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

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

Além de trabalhar com o conceito de árvore, onde existe um cachê principal e outros ligados a ele, o Squid trabalha também com um conceito parecido com grupo de trabalho, onde todos os servidores se consultam mutuamente.

Toda a comunicação entre os caches é feita via ICP

Entendendo o ICP

O ICP foi desenvolvido como parte fundamental do projeto Harvest (Pai do Squid). Seu objetivo é prover um método rápido e eficiente de obter-se comunicação entre servidores cache.

O ICP permite que um cache pergunte a outro se ele tem uma cópia válida de um determinado objeto, aumentando a possibilidade de encontrar aquele objeto já cacheado. Adicionalmente, o ICP permite que requisições trafeguem entre servidores filhos em uma estrutura de árvore.

Além do controle de cache, o ICP também gera indicações do estado da rede. O não recebimento de uma resposta ICP normalmente indica que a rota está congestionada ou que o outro host está morto. Além disso, a ordem de chegada de uma resposta ICP pode indicar quais hosts estão com uma distância lógica menor ou com menos carga.

As mensagens ICP são geralmente bem pequenas, com cerca de 66 bytes. Em uma estrutura hierárquica, normalmente tem-se mais trocas de mensagens ICP do que HTTP.

 

 

Fazendo roteamento por domínios

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

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

A configuração seria algo assim:

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

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

Roteando por protocolo

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

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

Servidor Pai e filho

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

     cache_host cache1 parent 3128 3130 default

Servidores Pais e filho

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

  cache_host cache1 parent 3128 3130 round-robin no-query
  cache_host cache2 parent 3128 3130 round-robin no-query
  cache_host cache3 parent 3128 3130 round-robin no-query
 


Utilizando o Squid como proxy reverso

 

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

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

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

Configuração de proxy reverso

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

 http_port 80
 httpd_accel_host 192.168.0.51
 httpd_accel_port 80
 httpd_accel_single_host on
 httpd_accel_uses_host_header off

Onde:

Parâmetro

Objetivo

http_port 80

Número da porta onde o Squid irá escutar

httpd_accel_host 192.168.0.51

IP do servidor Web interno

httpd_accel_port 80

Porta onde o web server está escutando

httpd_accel_single_host on

Ativa o squid para somente um web server atrás

httpd_accel_uses_host_header off

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


Gerando Relatórios

Utilizando o SARG

Instalação

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

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

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

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

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

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

# cd sarg-x.y

# ./configure

# make

# make install

Ou

# aptitude install sarg

Configuração

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

language Portuguese

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

title "Relatório SARG"

temporary_dir /tmp

output_dir /var/www/squid-reports

resolve_ip no

user_ip no

topuser_sort_field BYTES reverse

topsites_num 100

max_elapsed 28800000

Sendo importante destacar:

access_log - Indica o arquivo de log do Squid;

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

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

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

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

Gerando relatórios

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

 

# sarg

           

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


Otimizando o Squid

 

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

Especificando o Hardware

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

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

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

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

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

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

Sistemas de arquivo

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

DNS

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

Múltiplas rotas

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

Editando o squid.conf

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

  cache_mem bytes

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

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

  cache_mem 410 MB
 
cache_swap_low percentage

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

Defina algo como:

  cache_swap_low 95
 
cache_swap_high porcentagem

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

  cache_swap_high 98
 
maximum_object_size bytes

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

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

  maximum_object_size 16384 KB
 
maximum_object_size_in_memorybytes

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

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

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

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

  cache_dir ufs /scsi2/cache 5000 16 256

 


Bibliografia:

 

http://squid.visolve.com/squid24s1/contents.php

http://freshmeat.net/search/?q=squid§ion=projects

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

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

http://www.zago.eti.br/squid/A-menu-squid.html

Adonel  Bezerra

Pós-graduado em Teoria em Educação a Distância e Docência do Ensino Superior;

MBA Executivo em Coaching;

Coordenador de cursos de pós-graduação.

Experiência em Gestão de Negócios, envolvendo-se com as áreas administrativa, financeira, comercial, produção e logística;

Experiência de mais de 20 anos como professor conferencista na área de segurança da informação;

Sólida experiência na gestão de negócios e tecnologia da informação;

Sólida experiência no meio acadêmico; 

Consultor de Segurança da informação com mais de vinte anos de experiência;

Treinamentos e palestras ministrados para milhares de profissionais em todo o Brasil;

Livro publicado pela Editora Ciência Moderna e diversos artigos publicados.

 

ALGUMAS PARTICIPAÇÕES COMO CONFERENCISTA OU PALESTRANTE

Centro Universitário do Maranhão – UniCeuma/2009 – Apresentação “O MERCADO DE CONSULTORIA EM SEGURANÇA DE INFORMAÇÃO. 

Universidade de Fortaleza|UNIFOR – Apresentação “TÉCNICAS HACKERS PARA TESTES DE INVASÃO”.

Faculdades Integradas do Ceará – FIC/2010 – Apresentação “ SEGURANÇA DA INFORMAÇÃO”.

Escola de Gestão Pública do Estado do Ceará – /2012 – Apresentação “ SEGURANÇA DA INFORMAÇÃO COM SOFTWARE LIVRE”.

Faculdade La Salle – 2013 – Apresentação “ESPIONAGEM INTERNACIONAL”.

Estácio|FIC/2013 – Apresentação “ ANÁLISE DE VULNERABILIDADES COMO FATOR PRIMORDIAL NAS ORGANIZAÇÕES”.

Estácio|FIC/2015 – Apresentação “PROVA DE CONCEITO”.

Devry Brasil|FANOR Salvador/BA, Fortaleza/CE, Belém/PA, Caruaru/PE, Recife/PE, Teresina/PI    - Apresentação “ VULNERABILIDADES DE SISTEMAS COMPUTACIONAIS”.

 

PROJETO PESSOAL – 1998 – Até o momento

- Fundador e Mantenedor de um dos maiores portais de Segurança de sistema do Brasil, o portal Clube do Hacker; www.clubedohacker.com.br

Fundador e mantenedor da Academia Linux www.academialinux.com.br

Fundador da BUCOIN – www.bucoin.com.br