Uso e configuração do Squid - Parte 2

6 - Principais TAG's do arquivo squid.conf

O arquivo de configuração do Squid garante um grau elevado de capacidade de customização deste servidor. Ele é composto por mais de 3000 linhas, entretanto não há com o que se preocupar, pois a maior parte delas se constitui de comentários referentes as funções de cada TAG e como deve-se utilizá-la. De tantos comentários ele parece mais um manual do que um arquivo de configuração.

Podemos ter um servidor configurado e funcional com apenas pouco mais de 30 linhas no arquivo, devemos considerar também que boa parte das opções configuradas como padrão no arquivo squid.conf não precisam ser alteradas, pois já representam a configuração mais adequada.

Desta forma vamos nos ater as configurações mais importantes e necessárias para que possamos ter um servidor proxy funcional. Abaixo mostraremos algumas destas opções, não querendo tornar isso um guia definitivo para configuração do Squid, mas sim um ponto de partida para implementação de um servidor proxy.

hierarchy_stoplist cgi-bin ?

- Esta opção vem habilitada por padrão no squid.conf e inclusive é recomendado o seu uso. Ela é responsável por dizer ao Squid que ele deve buscar os dados diretamente na origem, sem passar pelos vizinhos na hierarquia. Esta configuração se refere a conteúdo dinâmico, portanto se a URL contém o padrão aqui especificado, será tomada a atitude de ir direto a origem buscar o conteúdo;

acl QUERY urlpath_regex cgi-bin ? 
no_cache deny QUERY

- Esta ACL diz ao squid para não armazenar em cache o conteúdo dos CGI's, pois obviamente não é interessante por tratar-se de conteúdo dinâmico;

cache_mem 64 MB

- Nesta opção é definida a quantidade de memória que o Squid irá usar, mas é bom lembrar que o manual do Squid adverte que a memória aqui mencionada é referente a objetos em trânsito, objetos ``quentes'' e objetos com negativa de cache, ou seja, é a memória apenas para ele utilizar na manipulação dos seus objetos e não ao total de memória consumida por ele, que pode ser duas ou três vezes maior;

cache_dir ufs /var/cache/squid 300 64 64

- Esta TAG determina onde e como será feito o cache, neste caso o diretório de cache é /var/cache/squid, com o tamanho de 300 MB, tendo 64 diretórios com 64 outros diretórios em cada um deles;

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Servidor Proxy ARL
auth_param basic credentialsttl 2 hours

- TAG's referentes ao processo de autenticação.

refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320

- Estas opções são o padrão do Squid e configuram como serão tratados os tempos de vida dos objetos no cache, isto é, o Squid faz uso destes valores para verificar se os objetos armazenados são os mais recentes ou há a necessidade de atualizá-los. Não há necessidade de mudança nestes valores;

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563 acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

- Estas ACL's fazem parte da configuração padrão do Squid e é o mínimo recomendável para seu uso, não sendo necessária nenhuma alteração nas mesmas;

acl MINHA_REDE src 192.168.16.0/24 
acl USUARIOS proxy_auth REQUIRED 
acl PORNO url_regex -i ``/etc/squid/porn'' 
acl PORNO1 url_regex -i ``/etc/squid/porn1'' 
acl NAO_PORNO url_regex -i ``/etc/squid/noporn''

- Seção do arquivo com ACL's definidas pelo usuário, além das anteriormente comentadas que já vêm configuradas por padrão..

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

- Definição de regras de acesso referentes as ACL's da parte da configuração padrão do Squid, também não é necessária nenhuma alteração, portanto apenas acrescente as suas próprias regras a estas;

http_access allow USUARIOS NAO_PORNO MINHA_REDE
http_access allow USUARIOS !PORNO !PORNO1 MINHA_REDE

http_access deny all

- Esta regra de acesso é recomendada para uso como última regra da lista define o acesso ao proxy. Ela diz ao Squid que se nenhuma das regras anteriores for aplicada o acesso será então negado, portanto seu uso vai impedir acessos indesejados ao proxy. É muito importante que esta seja a última regra da sua lista, pois o Squid tem uma regra implícita que inverte a última regra da lista caso nehuma delas seja aplicada. Isto pode trazer consequências indesejáveis principalmente se for usado negação ou liberação explícita como por exemplo http_access deny PORNO ou http_access allow NAO_PORNO;

icp_access allow all

- Permite o acesso a porta icp de acordo com a configuração feita na ACL all, que no nosso caso representa qualquer origem. Está porta é usada para troca de informações entre servidores proxy;

cache_mgr  email_administrador

- Opção para configuração do e-mail do administrador do proxy que vai aparecer nas mensagens de erro. Isto é importante para que os usuários tenham informações de como interagir com o responsável pelo servidor em caso de problemas, como por exemplo um acesso bloqueado de forma errada;

visible_hostname www.meu_seite.com.br

- Mostra o nome do servidor configurado nas mensagens de erro, caso contrário o Squid vai tentar descobrir o nome. Deve ser registrado o FQDN do servidor e não apenas o hostname;

error_directory /usr/share/squid/errors/Portuguese

- Com o uso dessa opção podemos determinar em qual linguagem serão apresentadas as mensagens de erro. Seu uso é recomendado, pois por padrão as mensagens são em inglês. Em /usr/share/squid/errors/ existem vários subdiretórios com as linguagens suportadas pelo Squid. E estas mensagens, inclusive, podem ser facilmente personalizadas, pois estão em arquivos no formato html;

coredump_dir /var/cache/squid

- Local onde o Squid gravará seus arquivos core em caso de falhas. Estes arquivos são comuns em sistemas UNIX e representam o estado do software no momento em que o erro que provocou sua finalização ocorreu.

Algumas outras opções também são interessantes, como no caso das apresentadas abaixo para serem usadas quando estamos com o recurso de proxy transparente habilitado. Estas opções vão fazer com que o Squid se comporte como um servidor web, de forma que o cliente não perceba que está ``conversando'' com um proxy.

httpd_accel_port 80
httpd_accel_host virtual
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Existem várias outras opções interessantes para serem exploradas, entretanto como não é nosso objetivo aqui dissecar cada uma delas, vamos deixar isso como proposta para uma outra oportunidade.

7 - ACL's

As ACL's - (Access Control Lists) ou listas de controle de acesso, constituem-se na grande flexibilidade e eficiência do Squid, é através delas que podemos criar regras para controlar o acesso à internet das mais diferentes formas. Praticamente todo o processo de controle do Squid é feito com o seu uso.

O uso das listas de controle de acesso é a parte mais importante da configuração de um servidor proxy Squid, pois se bem configuradas podem trazer um nível de segurança muito bom para a rede, entretanto se mau configuradas podem ter resultado oposto, já que além da falsa sensação de segurança não será aproveitada a grande capacidade e funcionalidade do Squid. Uma dica para se fazer boas ACL's é testar, testar e testar, e depois quando achar que está bom, continue testando e monitorando seus logs para identificar algum problema que possa ocorrer.

A primeira coisa que devemos saber é que o Squid interpreta as ACL's de cima para baixo, portanto é muito importante que seja observada esta regra no momento em que estão sendo construídas as regras de acesso. As ACL's são case-sensitive, isto é, site_porno é diferente de Site_porno, portanto cuidado com isso. Caso seja usada o opção -i elas deixarão de ser case-sensitive.

Uma outra regra muito importante é que caso uma das regras coincida, as demais não serão mais verificadas. Isso independe da quantidade de regras que ainda faltam para atingir o fim da lista.

7.1 - Tipos de ACL's

As ACL's são definidas da seguinte forma:

acl nome tipo string | ``arquivo''

Existem vários tipos de ACL que podemos utilizar, abaixo temos os mais comuns:

src - tipo utilizado para indicar endereços IP de origem. Pode-se especificar um endereço de rede, como 192.168.16.0/24, um endereço de um determinado host, como 192.168.16.10/24 ou uma faixa de endereços, como 192.168.16.10-192.168.16.20/24;

dst - semelhante ao tipo anterior, mas está relacionada ao endereço de destino;

srcdomain - tipo indicado para verificar o domínio da máquina cliente. Os domínios serão obtidos por resolução reversa de IP, o que pode causar atrasos para a resposta da requisição. A definição do domínio deve ser feita da seguinte forma: ``.meudominio.com.br'', não podendo ser esquecido o ``.'' (ponto) no início;

dstdomain - usado da mesma forma que srcdomain, entretanto com relação ao destino;

srcdom_regex - avalia o domínio usando expressões regulares. Seu uso é semelhante as duas anteriores, acrescentando a flexibilidade do uso da expressão regular;

dstdom_regex - usado da mesma forma que srcdom_regex, entretanto com relação ao destino;

time - usado para especificar dias da semana e horários. Os dias da semana são definidos através de letras que os representam, e os horários através de intervalos na forma hora:minuto_inicio-hora:minuto_final. Os dias da semana são especificados assim: S - Sunday (Domingo), M - Monday (Segunda-Feira), T - Tuesday (Terça-Feira), W - Wednesday (Quarta-Feira), H - Thursday (Quinta-Feira), F - Friday (Sexta-Feira) e A - Saturday (Sábado);

url_regex - Este tipo percorre a URL a procura da expressão regular especificada. Deve ser observado que a expressão é case-sensitive, para que seja case-insensitive deve ser usada a opção -i. É o tipo mais comum de ACL dada a flexibilidade proporcionada pelo uso de expressões regulares;

urpath_regex - Tipo semelhante a url_regex, mas procura a expressão regular na URL sem levar em conta o nome do servidor e o protocolo, isto quer dizer que a procura vai ser feita apenas na parte da URL após o nome do servidor, como por exemplo, na URL http://www.servidor.com.br/pasta/sexo.html a procura será realizada apenas na parte /pasta/sexo.html. Ela é também case-sensitive, para que seja case-insensitive deve ser usada a opção -i;

port - Realiza o controle pela porta de destino do servidor, neste tipo deve ser especificado o número da porta;

proto - Serve para especificar o protocolo, como por exemplo FTP ou HTTP;

method - Especifica o tipo de método usado na requisição, como por exemplo GET, CONNECT ou POST;

browser - Usa uma expressão regular para tentar ``casar'' com os dados do cabeçalho HTTP e combinando então com o navegador utilizado pelo cliente;

ident - Realiza o controle de acesso baseado no nome do usuário. Este tipo requer um servidor Ident rodando na máquina do cliente;

ident_regex - Semelhante a ident, mas utilizando expressão regular;

proxy_auth - Tipo usado para implementar autenticação de usuários no proxy. A autenticação é feita com uso de softwares externos. Podem ser passados os nomes dos usuários ou usada a opção REQUIRED para que seja autenticado qualquer usuário válido;

snmp_community - Tipo usado para especificar o nome da comunidade SNMP, para que se possa monitorar o Squid através deste protocolo;

maxconn - Especifica um limite de conexões vindas de um determinado cliente, interessante para uso com outras ACL's de forma a limitar quantidades de conexões para determinados endereços específicos;

req_mime_type - Especifica uma expressão regular para ser verificada no cabeçalho da requisição em busca de um tipo MIME que coincida com o especificado;

arp - Tipo usado para construir lista de acesso baseada no MAC Address da interface de rede do cliente, ou seja, em vez de endereço IP da placa, usa-se o seu endereço MAC.

7.2 - Construindo regras de acesso

Muitas são as possibilidades de construção de listas de acesso com o uso destes e outros tipos citados acima, mas o fato é que para cada situação específica vai ser necessário o uso de uma ou mais ACL's, de um mesmo tipo ou de tipos diferentes, de forma que possa se chegar a uma situação ideal de controle. Não existe uma regra rígida para criação de listas de acesso, portanto vai depender muito da necessidade e habilidade de cada um.

Vamos descrever algumas situações de como podemos construir listas de controle de acesso para atender a cada uma das situações propostas, observando que se trata de uma das formas de resolver o problema e não a única. É interessante observar que o controle de acesso deve ser construído em duas etapas, primeiramente são feitas as classes de ACL's e depois são construídas as regras de acesso com o uso destas ACL's, com o uso de operadores.

Existem vários operadores, dos quais o mais usado é o http_access. Com ele podemos construir regras de controle de acesso baseadas no protocolo HTTP e FTP. Dado ao fato deste ser o mais importante operador, vamos focar o nosso trabalho no seu uso.

No momento da construção das regas devemos levar em consideração além das observações que já foram feitas o fato de que se nenhuma das regas forem aplicadas, o Squid aplica o oposto da última regra da lista, portanto é muito importante que seja incluída como última linha das regra de acesso ``http_access deny all''. Desta forma não vamos deixar que esta inversão de regra possa provocar algum dissabor, pois negaremos qualquer acesso que não tenha uma regra específica.

Apresentamos abaixo alguns exemplos de como construir regras de acesso:

1. Controlando acesso pela origem:

   acl localnet src 192.168.16.0/24
   http_access allow localnet
   http_access deny all

   Com estas regras estamos especificando que requisições vindas da rede 192.168.16.0/24 serão aceitas, nos demais casos o acesso será negado;
2. Controlando o acesso pelo destino:

   acl outra_rede dst 192.168.17.0/24
   http_access allow outra_rede
   http_access deny all

   Com estas regras estamos limitando o acesso apenas à rede 192.168.17.0/24, desta forma qualquer acesso para outro destino será negado;
3. Controlando acesso pela origem e destino:

   acl localnet src 192.168.16.0/24
   acl outra_rede dst 192.168.17.0/24
   http_access allow localnet outra_rede
   http_access deny all

   Aqui juntamos as duas anteriores e estamos especificando que requisições vindas da rede 192.168.16.0/24 e que sejam destinadas à rede 192.168.17.0/24 serão aceitas, nos demais casos o acesso será negado;
4. Controlando acesso pela nome de domínio de origem e destino:

   acl meu_dominio srcdomain .meudominio.com.br
   acl mundo_lafora dstdomain .lafora.com.br
   http_access allow meu_dominio mundo_lafora
   http_access deny all

   Estas regras são semelhantes as acima, onde usamos src e dst, entretanto aqui é verificado o domínio, neste caso requisições vindas de .meudominio.com.br e com destino a .lafora.com.br serão liberadas, nos demais casos o acesso será negado. É muito importante não esquecer o ``.'' (isso mesmo, o ponto) antes do nome do domínio, sob pena da regra não funcionar;
5. Controlando o acesso usando autenticação de usuário:

   acl usuarios proxy_auth REQUIRED
   http_access allow usuarios
   http_access deny all

   Esta regra faz com que o acesso seja liberado apenas para usuários que sejam válidos, dado ao uso da opção REQUIRED, e que se autentiquem no Squid. Para que a autenticação funcione devem ser configuradas as TAG's que informam ao Squid como esta será feita, já que ela é realizada por softwares externos, mas isto já foi visto na seção  5;
6. Controlando acesso pela origem, destino e autenticação de usuário:

   acl localnet src 192.168.16.0/24
   acl outra_rede dst 192.168.17.0/24
   acl usuarios proxy_auth REQUIRED
   http_access allow localnet outra_rede usuarios
   http_access deny all

   Com estas regras estamos especificando que requisições vindas da rede 192.168.16.0/24 e que sejam destinadas à rede 192.168.17.0/24 serão aceitas, mas desde que os usuários sejam autenticados, nos demais casos o acesso será negado;
7. Acrescentando controle de acesso pelo horário:

   acl localnet src 192.168.16.0/24
   acl outra_rede dst 192.168.17.0/24
   acl usuarios proxy_auth REQUIRED
   acl expediente time MTWHF 8:00-18:00
   http_access allow expediente localnet outra_rede usuarios
   http_access deny all

   Apenas acrescentamos o controle baseado no horário. Veja também a ordem em que as ACL's são verificadas, observe que a verificação dos usuários é feita por último, pois não vamos forçar o usuários a se autenticarem para só depois negar o acesso por um outro motivo. Isto não é obrigatório, apenas no nosso caso fica melhor desta forma, pois se, por exemplo, o horário não está dentro do permitido, o acesso será negado imediatamente sem nem mesmo tentar checar as outras ACL's;
8. Controlando o acesso por palavras chaves:

   acl MINHA_REDE src 192.168.16.0/24
   acl USUARIOS proxy_auth REQUIRED
   acl PORNO url_regex -i "/etc/squid/porn"
   acl PORNO1 url_regex -i "/etc/squid/porn1"
   acl NAO_PORNO url_regex -i "/etc/squid/noporn"
   http_access allow USUARIOS NAO_PORNO MINHA_REDE
   http_access allow USUARIOS !PORNO !PORNO1 MINHA_REDE
   http_access deny all

   Este é sem dúvida o tipo de controle mais usado, pois com ele podemos fazer o bloqueio de conteúdo considerado impróprio de maneira muito fácil. No nosso caso estamos fazendo o uso de arquivos que contém as listas de palavras ou sites que consideramos inadequados, no caso /etc/squid/porn e /etc/squid/porn1 e outro arquivo com sites e palavras que podem ser barradas por alguma regra dos arquivos anteriores, mas que na verdade não representam conteúdo impróprio, no caso /etc/squid/noporn. Por exemplo, nem sempre a palavra sexo representa necessidade de bloqueio, pois podemos ter sites de conteúdo educativo que contenham essa palavra na sua URL, por exemplo www.ministeriodealgumacoisa.gov.br/sexoseguro.html. As palavras ou sites devem ser colocados no arquivo uma por linha.

   Então aqui estamos fazendo o seguinte: primeiramente vamos liberar usuários que desejem acessar sites listados no arquivo /etc/squid/noporn e que pertençam a nossa rede, no caso 192.168.16.0/24 ou usuários que queiram acessar sites com conteúdos diferentes (! significa diferente) do listado nos arquivos /etc/squid/porn e /etc/squid/porn1 e que pertençam a nossa rede, em ambos os casos deverá ser feita a autenticação.

7.3 - Erros mais comuns

• As regras são sempre interpretadas de cima para baixo;
• As expressões regulares são case-sensitive, ou seja, maiúsculas são diferenciadas de minúsculas, para que seja case-insensitive deve ser usada a opção -i;
• Se uma das regras da lista de acesso for aplicada, as demais serão ignoradas, isto é, apenas uma das regras da lista vai ser aplicada por vez;
• As regras são interpretadas da seguinte forma: http_access allow ACL1 AND ACL2 AND ACL3 OR http_access allow ACL4 AND ACL5 AND ACL1 OR ...

  Este é o tipo mais comum de erro, por isso devemos ter sempre isto em mente ao montarmos nossas regras.

• Existe uma regra implícita no Squid que é utilizada caso nenhuma das regras da lista seja aplicável ao acesso. Esta regra faz com que seja invertida a última regra da lista, de forma que se ela por exemplo for deny será transformada em allow e aplicada ao acesso, ou o contrário. É extremamente recomendável que a última regra da lista seja http_access deny all, pois com isso todo acesso que chegar até ela será negado, evitando surpresas com essa inversão que o Squid faz.

Vejamos alguns casos de erros:

1. Queremos que o acesso seja restrito a determinada origem e destino simultaneamente, isto é, a conexão deverá ser originada na nossa rede e ter como destino uma rede específica.

   acl localnet src 192.168.16.0/24
   acl outra_rede dst 192.168.17.0/24
   http_access allow localnet
   http_access allow outra_rede
   http_access deny all

   Aparentemente estas regras estão corretas, entretanto se forem analisadas com mais calma podemos verificar que elas não vão funcionar de acordo com o que esperamos. Os dois operadores deveriam na verdade ser apenas um, pois da forma que está se o acesso vier da rede 192.168.16.0/24 já é suficiente para que o aceso seja liberado, não sendo verificada a segunda regra que determina que o destino deve ser a rede 192.168.17.0/24. A segunda regra vai ser aplicada somente se a origem for diferente de 192.168.16.0/24, portanto um resultado totalmente diferente do que realmente queríamos. Desta forma o correto seria ter apenas um operador escrito da seguinte maneira http_access allow localnet outra_rede;

    

2. Queremos controlar o acesso pela origem e destino, como já visto no caso anterior, só que agora com o uso de autenticação de usuários.

   acl localnet src 192.168.16.0/24
   acl outra_rede dst 192.168.17.0/24
   acl usuarios proxy_auth REQUIRED
   http_access allow usuarios
   http_access allow localnet outra_rede
   http_access deny all

   Aqui foi cometido o mesmo erro do caso anterior, pois se o usuário conseguir se autenticar já será suficiente para que o acesso seja liberado, então a origem e o destino não serão mais verificados, pois uma regra já foi satisfeita;

    

3. Queremos controlar o acesso pela origem, com verificação de conteúdo impróprio através de expressões regulares, para usuários autenticados.

   acl MINHA_REDE src 192.168.16.0/24
   acl USUARIOS proxy_auth REQUIRED
   acl PORNO url_regex -i "/etc/squid/porn"
   acl PORNO1 url_regex -i "/etc/squid/porn1"
   acl NAO_PORNO url_regex -i "/etc/squid/noporn"
   http_access allow USUARIOS NAO_PORNO
   http_access allow USUARIOS !PORNO !PORNO1 MINHA_REDE
   http_access deny all

   Nestas regras apenas foi cometido um pequeno erro, pois na linha http_access allow USUARIOS NAO_PORNO não foi feita a restrição com base na origem, está então faltando a ACL MINHA_REDE, e sem isso caso o usuário consiga se autenticar e o site esteja na lista do arquivo /etc/squid/noporn já é suficiente para ter o acesso autorizado, independente de qual rede esteja sendo originada a requisição.

8 - Analisando os logs do Squid

Não poderíamos falar do Squid sem que fossem analisadas algumas das muitas alternativas em software para análise dos logs e geração de relatórios com informações mais ``legíveis'' e amigáveis das atividades do servidor.

Existem várias ferramentas para análise e geração de relatórios dos logs do Squid, dentre elas podemos destacar o Calamaris, SARG e Squid-graph, dentre muitas outras. Cada uma delas apresenta características e funcionalidades diferentes, entretanto o objetivo final é fornecer uma maneira mais amigável de se analisar as preciosas e detalhadas informações que o Squid grava em seus logs. Neste trabalho, escolhemos estas três ferramentas citadas para mostrarmos sua utilização, conforme veremos nas subseções seguintes.

8.1 Calamaris

O Calamaris é um software escrito em Perl que efetua a geração de relatórios bem detalhados do uso da internet usando os arquivos de logs de vários servidores proxy, como o NetCache, Inktomi Traffic Server, Oops! proxy server, Novell Internet Caching System, Compaq Tasksmart, Netscape/iplanet Web Proxy Server e é claro o Squid. Os relatórios gerados são bem simples na apresentação, entretanto muito ricos em detalhes extraídos dos arquivos de logs, eles podem ser gerados no formato HTML ou mesmo em texto para ser enviado via e-mail.

A utilização deste software é muito simples, primeiramente temos que baixar a versão mais recente dele em http://cord.de/tools/squid/calamaris/Welcome.html.en, descompactar o arquivo no diretório de sua preferência, no nosso caso /usr/local/calamaris, após isso já podemos usá-lo. Abaixo temos um exemplo simples de comando necessário para geração dos relatórios do log do Squid.

#/usr/local/calamaris/calamaris -a -F html /var/log/squid/access.log >/srv/www/default/html/calamaris/index.html

O comando acima já é suficiente para geração de relatórios excelentes da análise dos logs. Neste caso usamos a opção -a que diz ao Calamaris para serem gerados todos os relatórios, -F html especifica o formato do relatório que queremos, no caso em HTML, /var/log/squid/access.log é onde está localizado o arquivo de log do Squid e >/srv/www/default/html/calamaris/index.html a localização do relatório gerado, neste caso uma pasta na árvore do Apache de forma que possa ser analisado de qualquer estação da rede.

O ideal é que seja desenvolvido um script para que possamos programar a execução do Calamaris pelo cron, mas isso não será tratado aqui dado ao fato que isto deverá ser feito de acordo com as necessidades da cada um, assim como o próprio software já traz alguns exemplos de como fazer isto.

8.2 - SARG

O SARG é um dos mais usados e eficientes softwares para geração de relatórios dos logs do Squid. Ele foi escrito por um brasileiro e tem recursos muito interessantes, como listagem de sites mais visitados, sites que o acesso foi negado, falhas na autenticação, caso este recurso esteja sendo utilizado, listas de sites acessados por usuários e horários em que foram acessados, etc. Além do mais, cada um destes relatórios estão recheados de informações como datas e horários dos acessos, tempo de gasto na visita ao site, quantidades de dados trafegados e outras mais.

Uma outra vantagem deste software é que ele está disponível em várias línguas, inclusive o português é claro, além do mais tem um arquivo de configuração relativamente simples e bem comentado, além de está disponível em pacotes da maioria das distribuições. No nosso caso utilizamos o pacote rpm disponível na nossa distribuição, no caso a verão 9 do Conectiva.

Mas caso você opte por instalar usando os fontes não haverão maiores problemas, siga apenas os passos tradicionalmente usados para instalação usando este método, como mostraremos a seguir. Após ter baixado a versão mais recente do site http://web.onda.com.br/orso/, no nosso caso sarg-1.4.1.tar.gz e executar os comando abaixo na ordem apresentada, o SARG estará pronto para uso, quer dizer, para ser configurado para uso.

# tar zxvf sarg-1.4.tar.gz
# cd sarg-1.4/
# ./configure
# make
# make install

Para geração dos relatórios é necessário apenas a execução do comando sarg. Assim como o Calamaris a execução do SARG fica mais interessante se programada através do cron, isso pode ser implementado com o uso dos scripts que o acompanham (geralmente /usr/sbin/sarg.daily, sarg.weekly e sarg.monthly) e permitem automatizar a geração de relatórios diários, semanais e mensais, mas isso não quer dizer que não possamos extrair relatórios mais personalizados e de acordo com nossas necessidades.

8.3 - Squid-Graph

Ele pode ser conseguido em http://squid-graph.securlogic.com/files/stable/squid-graph-3.1.tar.gz, sendo esta a última versão disponível neste momento. É importante lembrar que é necessário que seja instalado o módulo perl GD, que com certeza deve está nos CD's de sua distribuição favorita.

O processo de instalação é muito simples, pois trata-se apenas de descompactar os arquivos no diretório escolhido, já que não precisamos compilar nada. No nosso caso instalamos em /usr/local/squid-graph/, conforme mostra o comando abaixo.

# tar xzvf squid-graph-3.1.tar.gz -C /usr/local/ # mv squid-graph-3.1 squid-graph # chmod +x /usr/local/squid-graph/bin/*

#/usr/local/squid-graph/bin/squid-graph -c -n -o=/srv/www/default/html/squid-graph/ --title="Gráfico de uso do proxy" < /var/log/squid/access.log

No comando acima usamos a opção -c, desta forma estamos gerando os gráficos cumulativos, isto é, vamos ter dois gráficos para os acessos e transferências TCP, respectivamente, e mais dois gráficos para os acessos e transferências UDP. A opção -n faz com que não sejam ``ecoadas'' na tela as informações do processamento do log do Squid, -o=/srv/www/default/html/squid-graph/ representa o local onde os arquivos serão gravados (html e imagens), -title=``Gráfico de uso do proxy'' personaliza o título da página html, onde são mostrados os gráficos, e por fim temos o arquivo de log dos Squid.

Existem outras opções interessantes, como gerar gráficos para uma URL específica ou um determinado usuário, como podemos ver com o uso do comando abaixo:

# cat /var/log/squid/access.log | grep "ginux.comp.ufla.br" | /usr/local/squid-graph/bin/squid-graph -c -n -o=/srv/www/default/html/squid-graph/ --title="Gráfico de uso do proxy"

Para gerar um gráfico dos acessos de um determinado usuário, precisaríamos apenas substituir o comando grep mostrado acima, por grep ``192.168.16.3 '', supondo que 192.168.16.3 é o IP do seu usuário. Podemos ainda usar o mesmo recurso para gráficos de determinados tipos de arquivos, usando a extensão como parâmetro, por exemplo grep ``.mp3 '' é um bom começo. Como já deu pra perceber, podemos combinar o uso do Squid-Graph com outros comandos do Linux, de forma que podemos ter uma infinidade de opções para seu uso, além disso existem outras opções interessantes que não foram tratadas aqui.

9 - Conclusão

A configuração e o uso de servidores proxy é um assunto muito interessante e ao mesmo tempo muito extenso. Temos várias maneiras de implementar soluções deste tipo, que vão apresentar um certo grau de complexidade de acordo com o porte, recursos e finalidade do que queremos usar. Nosso objetivo aqui foi apresentar algumas das maneiras de utilização do proxy Squid de modo que fosse possível elaborar uma visão do processo de configuração e utilização deste servidor proxy.

Este é sem dúvidas um software livre com qualidade excepcional. A robustez e flexibilidade oferecidas pelo Squid é um diferencial muito bom em relação a soluções fechadas. Ao mesmo tempo podemos notar a facilidade no seu uso, o que faz dele uma excelente alternativa para uso em qualquer ambiente.

Referências Bibliográficas

Bastos, 2003 Bastos, E. R. (2003). Configurando um squid ``ninja'' - http://www.linuxman.pro.br/squid/. Acesso em setembro/2003.

Campos, 2003 Campos, A. (2003). Linux in brazil - http://www.linux.trix.net. Acesso em setembro/2003.

Marcelo, 2003 Marcelo, A. (2003). Squid. Brasport Livros e Multimídia Ltda.

Pearson, 2003 Pearson, O. (2003). Squid - A User's Guide. Qualica Technologies (Pty) Ltd.

Sica et al., 2003 Sica, F. C., Uchôa, J. Q., and Simeone, L. E. (2003). Administração de Redes Linux. UFLA/FAEPE.

Vesperman, 2003 Vesperman, J. (2003). Installing and configuring squid - http://linux.oreillynet.com/pub/a/linux/2001/07/26/squid.html. Acesso em setembro/2003.

ViSolve.com, 2002 ViSolve.com (2002). Squid configuration manual. ViSolve.com.

Wessels, 2001 Wessels, D. (2001). SQUID Frequently Asked Questions. www.squid-cache.org.

A . Exemplo de arquivo Sarg.conf

# Inicio do arquivo sarg.conf
# sarg.conf
# Principais diretivas estão comentadas e algumas
# foram mantidos os comentários originais
# Definição da linguagem
language Portuguese
# Localização do arquivo de log do squid
access_log /var/log/squid/access.log
# título do relatório
title "Relatórios de uso do proxy Squid"
# Definicoes da estética do relatorio (cores, fontes)
font_face Arial
header_color darkblue
header_bgcolor blanchedalmond
header_font_size -1
background_color white
text_color black
text_bgcolor beige
title_color green
logo_image none
logo_text_color black
background_image none
password none
# diretório temporário
temporary_dir /tmp
# Local onde os relatórios serão gravados
output_dir /srv/www/default/html/sarg
# e-mail para envio dos relatórios
output_email none
resolve_ip no
user_ip yes
# classificação do relatório topuser
topuser_sort_field BYTES reverse
# classificação do relatório user
user_sort_field BYTES reverse
# arquivo com usuario que serao excluidos do relatorio
exclude_users none
# arquivo com usuario que serao excluidos do relatorio
# Ex.: ip 192.168.10.10, rede 192.168.10.0,
# host s1.acme.foo e domínio acme.foo
exclude_hosts none
useragent_log none
# formato da data: e (Europe=dd/mm/yy), u
# (USA=mm/dd/yy), w (Weekly=yy.ww)
date_format e
# TAG:  per_user_limit file MB
#       Save userid on file if download exceed n MB.
#
#       This option can be used to disable user access
#  if user exceed a download limit.
per_user_limit none
lastlog 0
remove_temp_files yes
index yes
# subscrever relatórios caso já existam
overwrite_report yes
# o que fazer com registros sem usuário
records_without_userid ignore
# use_comma yes => 23,450,110 use_comma no  => 23.450.110
use_comma no
# utilitário usado para envio do e-mail com o relatório
mail_utility mail
# quantidade de sites mais visitados para listar no relatório
topsites_num 100
# TAG: topsites_sort_order CONNECT|BYTES A|D
#      Sort for topsites report, where A=Ascendent,
#      D=Descendent
#
topsites_sort_order CONNECT D
# Arquivo de códigos HTTP para serem ignorados no relatório
exclude_codes /etc/sarg/exclude_codes
max_elapsed 28800000
# Tipo de Relatórios
#    topsites             - Mostra o site, conexão e bytes
#    sites_users          - Mostra que usuários estavam
#                           acessando um site
#    users_sites          - Mostra sites acessados
#                           pelo usuário
#    date_time            - Mostra quantidade de bytes
#                           usados por dia e hora
#    denied               - Mostra todos os sites negados
#                           com URL completa
#    auth_failures        - Mostra falhas de autenticação
#    site_user_time_date  - Mostra os horários que um
#                           usuário acessou determinado
#                           site
#
report_type topsites sites_users users_sites date_time denied 
   auth_failures site_user_time_date
# usado para mostrar o nome do usuário e não o ip
# formato: 192.168.10.1 claudio
usertab /etc/squid/usernames
# TAG: long_url yes|no
#      If yes, the full url is showed in report.
#      If no, only the site will be showed
#
#      YES option generate very big sort files and reports.
#
long_url no
# TAG: date_time_by bytes|elap
#      Date/Time reports will use bytes or elapsed time?
#
date_time_by bytes
# TAG: charset name
#      ISO 8859 is a full series of 10 standardized
#      multilingual
#      single-byte coded (8bit)
#      graphic character sets for writing in
#      alphabetic languages
#      You can use the following charsets:
#    Latin1     - West European
#    Latin2     - East European
#    Latin3     - South European
#    Latin4     - North European
#    Arabic
#    Greek
#    Hebrew
#    Latin5     - Turkish
#    Latin6
#    Windows-1251
#    Koi8-r
charset Latin1
# Fim do arquivo sarg.conf 
 

B . Exemplo de arquivo Squid.conf

# Inicio do arquivo squid.conf
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin ? no_cache deny QUERY
cache_mem 64 MB
cache_dir ufs /var/cache/squid 300 64 64
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Servidor Proxy da SEFIN
auth_param basic credentialsttl 2 hours
refresh_pattern ^ftp:    1440  20%  10080
refresh_pattern ^gopher:  1440  0%  1440
refresh_pattern .    0  20%  4320
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 80    # http
acl Safe_ports port 21    # ftp
acl Safe_ports port 443 563  # https, snews
acl Safe_ports port 70    # gopher
acl Safe_ports port 210    # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280    # http-mgmt
acl Safe_ports port 488    # gss-http
acl Safe_ports port 591    # filemaker
acl Safe_ports port 777    # multiling http
acl CONNECT method CONNECT
acl MINHA_REDE src 192.168.16.0/24
acl USUARIOS proxy_auth REQUIRED
acl PORNO url_regex -i "/etc/squid/porn"
acl PORNO1 url_regex -i "/etc/squid/porn1"
acl NAO_PORNO url_regex -i "/etc/squid/noporn"
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow USUARIOS NAO_PORNO MINHA_REDE
http_access allow USUARIOS !PORNO !PORNO1 MINHA_REDE
http_access deny all
http_reply_access allow all
icp_access allow all
visible_hostname www.meu_seite.com.br
error_directory /usr/share/squid/errors/Portuguese
coredump_dir /var/cache/squid
# Fim do arquivo squid.conf

Somente usuários registrados podem escrever comentários.
Por favor faça o login ou registre-se.

Powered by AkoComment 2.0!