Resumo

Este artigo visa mostrar algumas das formas de uso do servidor proxy Squid, assim como as configuraes para os casos apresentados. No proposta analisarmos todas as possveis implementaes com uso do Squid, fato este impossvel de ser realizado, dado a grande flexibilidade que este software oferece, mas sim mostrar as maneiras mais comuns de sua utilizao e configurao.

1 - Objetivos
O objetivo principal deste documento proporcionar o entendimento do funcionamento do servidor proxy Squid e como so realizadas suas configuraes. No ser abordado aqui o processo de instalao, tendo em vista tratar-se de tarefa muito simples, j que estamos falando de um software muito popular e presente em praticamente todas as distribuies Linux atuais, portanto podendo ser instalado atravs de pacotes da prpria distribuio com muita facilidade. Mesmo que seja feita a escolha de instalao atravs do cdigo fonte, provavelmente no ser necessrio muito mais do que os comandos ./configure, make all e make install, j velhos conhecidos de todos. Falaremos do uso das ACL's, recurso que faz com que o Squid seja to flexvel e eficiente, apresentado alguns exemplos mais usados e possveis erros que podem ser cometidos na construo das regras de acesso. Ser abordado tambm a utilizao de softwares geradores de relatrios baseados na anlise dos logs gerados pelo Squid, dado ao fato deste tema ser muito importante para a abordagem do trabalho, j que tais softwares so fundamentais para o processo de administrao do servidor proxy. Esta no uma abordagem definitiva, que visa esgotar o tema ou apresentar todas as possibilidades de uso e configuraes, o que queremos apresentar formas de implementar um servidor proxy eficiente de maneira fcil, rpida e com qualidade. O sistema operacional Linux ser a base para o desenvolvimento deste trabalho, onde ser utilizada a distribuio nacional Conectiva, verso 9, com kernel 2.4.21-28872cl, e a verso 2.5.125760cl do Squid.

2 - O que o Squid?
Atualmente o acesso internet tem se tornado praticamente obrigatrio, principalmente no ambiente corporativo, tendo em vista o dinamismo que as novas tecnologias da comunicao podem trazer para este ambiente. Entretanto surgem vrios problemas quanto a definio de como implementar esse acesso de computadores das redes corporativas internet de forma segura e eficiente. No conjunto de medidas a serem tomadas para implementar esse acesso temos a utilizao de servidores proxy. Um servidor proxy funciona como um intermedirio no contato dos computadores da rede local com outras mquinas fora dela, como por exemplo na internet. Ele recebe as requisies de acesso externo dos hosts locais e as repassa a outros computadores fora da rede local, retornando as respostas aos computadores que as solicitaram. O Squid um dos servidores proxy mais utilizados no mundo, dado a sua robustez, segurana e recursos que oferece. Apesar dos poucos protocolos que ele consegue trabalhar, no caso apenas o HTTP, HTTPS, FTP e gopher, ainda uma alternativa muito interessante, j que estes so os principais protocolos da internet, e alm do mais, muitos dos aplicativos que usam outros protocolos tem capacidade de usar o Squid atravs de um dos protocolos suportados por ele. O proxy Squid funciona ouvindo requisies numa determinada porta padro, ou numa outra porta que pode ser configurada pelo administrador da rede.

O Squid um software livre, o que implica dizer que ele est licenciado nos termos da GPL (General Public License), com isso temos uma garantia a mais (ao nosso ver, sem sombras de dvidas muito mais seguro que ter o software nas mo de uma nica corporao que pode fechar as portas de uma hora para outra, como j vimos por vrias vezes) de que nenhuma corporao vai descontinuar o projeto e deixar os seus usurios sem rumo, j que a prpria comunidade de usurios que contribui com o desenvolvimento e avanos deste software.

3 - Porque usar o Squid

Alm da capacidade de intermediar o acesso internet, como j mencionado, o Squid tem outros recursos que o torna uma excelente alternativa para aproveitamento mais racional da comunicao. Dentre esses recursos podemos destacar: Cache - atravs desse recurso o Squid armazena em cache o contedo acessado, de forma que se algum host fizer novamente uma requisio ao mesmo contedo, que j se encontra armazenado, ele recebe diretamente do cache, sem a necessidade de efetuar uma nova busca dos dados na internet. O uso desse recurso pode trazer uma rapidez maior ao acesso internet, pois provavelmente o link do host com o proxy bem mais rpido do que deste com a internet; Autenticao - podemos restringir o acesso ao servidor proxy com o uso da autenticao de usurios, de forma que seja melhorada a segurana, j que somente usurios autorizados podero acessar a internet. Este recurso bastante flexvel e pode ser implementado de vrias maneiras, como uso do protocolo LDAP, SMB, mdulos PAM, etc; Registro de acessos - os acessos so registrados em arquivos de log, podendo esses serem utilizados para as mais diversas finalidades, que vo desde a anlise de performance do servidor, at a gerao de relatrios detalhados dos acessos internet. Existem vrios softwares analisadores de logs do Squid capazes de gerar relatrios to bons, que por si j justificariam o uso do Squid, em razo do controle proporcionado; Controle centralizado - com o uso do proxy temos a facilidade de um nico ponto centralizador do acesso internet, o que torna a gerncia da rede mais fcil e eficiente. Uma nica mquina capaz de prover acesso vrias outras; Segurana - como apenas o proxy est diretamente ligado internet, temos apenas uma (ou mesmo poucas, caso tenhamos mais de um servidor proxy) mquina potencialmente vulnervel. Desta forma fica mais fcil concentrar esforos na melhoria da segurana de apenas um ponto na rede. A base instalada do Squid hoje muito grande, sendo utilizado por empresas dos mais variados ramos e portes, vo desde instalaes para uso domstico at grandes corporaes, Governos, etc. Isso mostra a credibilidade que este software livre possui.

4 - Proxy transparente
Cada software que precise acessar a internet e esteja atraz de um proxy, precisa ter configuradas as informaes de endereamento e porta onde o proxy da rede esteja ``ouvindo''. Entretanto, usurios mais ``espertos'' podem querer fugir do controle do proxy e utilizar uma outra maneira de acesso internet, sem que este possa ser auditado e controlado. Caso as configuraes relativas ao proxy sejam retiradas do browser ou outro utilitrio pelo usurio, por exemplo, ele poder se utilizar de um outro meio para se conectar internet sem nenhum controle, colocando em risco a segurana da rede. Uma das maneiras mais eficientes de implementao de um proxy, levando-se em considerao a necessidade de controle, com uso da tcnica denominada proxy transparente. Isto feito com a utilizao de uma regra no firewall que efetua o redirecionamento das requisies destinadas internet ao servidor proxy. Esse redirecionamento faz com que no mais precisem ser configurados os softwares com as informaes do proxy, pois o firewall se encarrega de redirecionar as requisies redes externas para o Squid, independente da vontade ou configurao do usurio. Alm disso realizar a configurao dos parmetros do servidor proxy

numa meia dzia de mquinas pode ser fcil e rapidamente feito, mas isto no interessante quando temos uma rede com uma quantidade muito grande de mquinas a serem configuradas. Para implementarmos esse redirecionamento precisamos apenas inserir no Iptables, que o software para criao de firewall em Linux, a seguinte regra: Se o redirecionamento for para uma mquina diferente #iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.16.10:3128 Se o redirecionamento for para a mesma mquina #iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128 Estas regras dizem ao firewall que todas a requisies que entrarem pela interface eth0 (interface usada neste caso apenas como exemplo), no nosso caso esta a interface onde est ligada nossa rede interna, destinadas a porta 80, que a porta padro do servio WWW, e que o protocolo seja o TCP, devem ser redirecionadas para a porta 3128, que onde nosso servidor proxy est ouvindo. No primeiro caso como o Squid no est instalado na mesma mquina onde est o firewall este redirecionamento feito para a mquina com IP 192.168.16.10. Feito o redirecionamento o Squid assume o controle da conexo e aplica suas regras de forma que sejam liberados os acessos apenas de acordo com as regras nele definidas. Uma observao importante que este recurso de proxy transparente no funciona com a autenticao de usurio, portanto cabe uma anlise de qual dos dois ser mais interessante para cada caso, j que deveremos fazer uma escolha entre eles. Alm do mais, alguns navegadores podem no funcionar corretamente com o uso deste recurso, ento sua adoo deve ser avaliada antes da implementao, visto que alguns usurios podero ter problemas caso estejam usando estes navegadores que no atendem aos padres. Outro detalhe importante com relao ao fato de que mais barato em termos de ciclos de CPU e uso da memria ter os navegadores configurados explicitamente para usar um proxy, do que redirecionar o trfego como vimos. tambm mais barato em termos de ciclos de CPU e uso da memria bloquear a porta 80 ao invs de redirecionar o trfego. O bloqueio tem menos overhead que a redireo, e pode forar as pessoas a utilizar um proxy. O uso do proxy transparente deve sempre que possvel ser evitado e usado apenas se no houver uma outra maneira mais prtica e eficiente de se fazer o que se pretende com o uso deste recurso.

5 - Autenticao no Squid
Por padro, o controle de acesso feito por mquina, entretanto o Squid fornece mecanismos para ser efetuado um controle por usurio, dessa forma cada usurio que deseje ter acesso internet dever antes de tudo se autenticar no proxy, para que seu acesso seja liberado. A autenticao poder ser feita de vrias maneiras, como por exemplo, no formato NCSA (geralmente associado ao utilitrio htpasswd, o mesmo utilizado pelo Apache), ou ainda atravs de um servidor LDAP, um PDC Windows NT/2000, ou mdulos PAM, etc. A maneira mais comum de realizar autenticao com o uso do formato NCSA que usa o mdulo ncsa_auth. Para este trabalho nossa implementao foi baseada neste mtodo. O cadastro dos usurios para acesso ao Squid feito com o uso do utilitrio htpasswd, conforme podemos ver no exemplo abaixo, lembrando apenas que a opo -c deve ser usada apenas caso o arquivo de senhas ainda no exista, pois ela instrui o utilitrio a cri-lo. # htpasswd -c arquivo_de_senhas usuario Para que o Squid fornea suporte a autenticao devemos habilitar estas configuraes no arquivo squid.conf atravs da TAG auth_param. nela que so realizadas as mudanas necessrias para que o esquema de autenticao comece a funcionar, j que por padro ele no vem habilitado. No

prprio arquivo tem comentrios que mostram como isso deve ser feito para cada tipo escolhido. Como vamos utilizar o mtodo bsico, nossa configurao ficou assim. auth_param auth_param auth_param auth_param basic basic basic basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd children 5 realm Servidor Proxy Squid ARL credentialsttl 2 hours

A linha auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd especifica qual mdulo ser usado, no caso /usr/lib/squid/ncsa_auth onde se encontra o arquivo com os usurios e senhas gerado conforme comentado acima. Em auth_param basic children 5 estamos definindo quantos processos filhos do mdulo de autenticao podero existir, esse nmero o padro do Squid, entretanto em redes maiores pode haver a necessidade de um incremento deste, devido ao nmero provavelmente maior de usurios que precisaro se autenticar simultaneamente. Em auth_param basic realm Servidor Proxy Squid ARL configura-se a mensagem que aparecer na tela onde so fornecidas as informaes do usurio para autenticao. Esta opo interessante para que possamos personalizar este mensagem da tela de login do nosso servidor. E por ltimo auth_param basic credentialsttl 2 hours especifica a validade de uma autenticao bem sucedida. Com estas configuraes j temos nosso proxy habilitado a trabalhar com autenticao de usurios, bastando para isso que sejam feitas ACL's para isso e definidas as regras de acesso.

6 - Principais TAG's do arquivo squid.conf

O arquivo de configurao do Squid garante um grau elevado de capacidade de customizao deste servidor. Ele composto por mais de 3000 linhas, entretanto no h com o que se preocupar, pois a maior parte delas se constitui de comentrios referentes as funes de cada TAG e como deve-se utiliz-la. De tantos comentrios ele parece mais um manual do que um arquivo de configurao. Podemos ter um servidor configurado e funcional com apenas pouco mais de 30 linhas no arquivo, devemos considerar tambm que boa parte das opes configuradas como padro no arquivo squid.conf no precisam ser alteradas, pois j representam a configurao mais adequada. Desta forma vamos nos ater as configuraes mais importantes e necessrias para que possamos ter um servidor proxy funcional. Abaixo mostraremos algumas destas opes, no querendo tornar isso um guia definitivo para configurao do Squid, mas sim um ponto de partida para implementao de um servidor proxy. hierarchy_stoplist cgi-bin ? - Esta opo vem habilitada por padro no squid.conf e inclusive recomendado o seu uso. Ela responsvel por dizer ao Squid que ele deve buscar os dados diretamente na origem, sem passar pelos vizinhos na hierarquia. Esta configurao se refere a contedo dinmico, portanto se a URL contm o padro aqui especificado, ser tomada a atitude de ir direto a origem buscar o contedo; acl QUERY urlpath_regex cgi-bin ? no_cache deny QUERY - Esta ACL diz ao squid para no armazenar em cache o contedo dos CGI's, pois obviamente no interessante por tratar-se de contedo dinmico; cache_mem 64 MB - Nesta opo definida a quantidade de memria que o Squid ir usar, mas bom lembrar que o manual do Squid adverte que a memria aqui mencionada referente a objetos em trnsito, objetos ``quentes'' e objetos com negativa de cache, ou seja, a memria apenas para ele utilizar na manipulao dos seus objetos e no ao total de memria consumida por ele, que pode ser duas ou trs vezes maior;

cache_dir ufs /var/cache/squid 300 64 64 - Esta TAG determina onde e como ser feito o cache, neste caso o diretrio de cache /var/cache/squid, com o tamanho de 300 MB, tendo 64 diretrios com 64 outros diretrios em cada um deles; auth_param auth_param auth_param auth_param basic basic basic basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd children 5 realm Servidor Proxy ARL credentialsttl 2 hours

- TAG's referentes ao processo de autenticao. refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern . 0 20% 4320 - Estas opes so o padro do Squid e configuram como sero tratados os tempos de vida dos objetos no cache, isto , o Squid faz uso destes valores para verificar se os objetos armazenados so os mais recentes ou h a necessidade de atualiz-los. No h necessidade de mudana nestes valores; acl acl acl acl acl acl acl acl acl acl acl 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 to_localhost dst 127.0.0.0/8 SSL_ports port 443 563 acl Safe_ports port 80 # http Safe_ports port 21 # ftp Safe_ports port 443 563 # https, snews Safe_ports port 70 # gopher Safe_ports port 210 # wais Safe_ports port 1025-65535 # unregistered ports 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

- Estas ACL's fazem parte da configurao padro do Squid e o mnimo recomendvel para seu uso, no sendo necessria nenhuma alterao nas mesmas; acl acl acl acl acl MINHA_REDE src 192.168.16.0/24 USUARIOS proxy_auth REQUIRED PORNO url_regex -i ``/etc/squid/porn'' PORNO1 url_regex -i ``/etc/squid/porn1'' NAO_PORNO url_regex -i ``/etc/squid/noporn''

- Seo do arquivo com ACL's definidas pelo usurio, alm das anteriormente comentadas que j vm configuradas por padro.. http_access http_access http_access http_access allow manager localhost deny manager deny !Safe_ports deny CONNECT !SSL_ports

- Definio de regras de acesso referentes as ACL's da parte da configurao padro do Squid, tambm no necessria nenhuma alterao, portanto apenas acrescente as suas prprias regras a estas;

http_access allow USUARIOS NAO_PORNO MINHA_REDE http_access allow USUARIOS !PORNO !PORNO1 MINHA_REDE - Estas regras de acesso foram feitas com o uso das ACL's criadas anteriormente na rea designada ao usurio, como podemos observar elas foram feitas pelo prprio usurio;

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 ento 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 implcita que inverte a ltima regra da lista caso nehuma delas seja aplicada. Isto pode trazer consequncias indesejveis principalmente se for usado negao ou liberao explcita 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 configurao feita na ACL all, que no nosso caso representa qualquer origem. Est porta usada para troca de informaes entre servidores proxy; cache_mgr email_administrador

- Opo para configurao do e-mail do administrador do proxy que vai aparecer nas mensagens de erro. Isto importante para que os usurios tenham informaes de como interagir com o responsvel 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 contrrio o Squid vai tentar descobrir o nome. Deve ser registrado o FQDN do servidor e no apenas o hostname; error_directory /usr/share/squid/errors/Portuguese - Com o uso dessa opo podemos determinar em qual linguagem sero apresentadas as mensagens de erro. Seu uso recomendado, pois por padro as mensagens so em ingls. Em /usr/share/squid/errors/ existem vrios subdiretrios com as linguagens suportadas pelo Squid. E estas mensagens, inclusive, podem ser facilmente personalizadas, pois esto em arquivos no formato html; coredump_dir /var/cache/squid - Local onde o Squid gravar seus arquivos core em caso de falhas. Estes arquivos so comuns em sistemas UNIX e representam o estado do software no momento em que o erro que provocou sua finalizao ocorreu. Algumas outras opes tambm so interessantes, como no caso das apresentadas abaixo para serem usadas quando estamos com o recurso de proxy transparente habilitado. Estas opes vo fazer com que o Squid se comporte como um servidor web, de forma que o cliente no 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 vrias outras opes interessantes para serem exploradas, entretanto como no 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 eficincia do Squid, atravs 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 configurao de um servidor proxy Squid, pois se bem configuradas podem trazer um nvel de segurana muito bom para a rede, entretanto se mau configuradas podem ter resultado oposto, j que alm da falsa sensao de segurana no 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 esto sendo construdas as regras de acesso. As ACL's so case-sensitive, isto , site_porno diferente de Site_porno, portanto cuidado com isso. Caso seja usada o opo -i elas deixaro de ser casesensitive. Uma outra regra muito importante que caso uma das regras coincida, as demais no sero 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 so definidas da seguinte forma: acl nome tipo string | ``arquivo'' Existem vrios tipos de ACL que podemos utilizar, abaixo temos os mais comuns: src - tipo utilizado para indicar endereos IP de origem. Pode-se especificar um endereo de rede, como 192.168.16.0/24, um endereo de um determinado host, como 192.168.16.10/24 ou uma faixa de endereos, como 192.168.16.10-192.168.16.20/24; dst - semelhante ao tipo anterior, mas est relacionada ao endereo de destino; srcdomain - tipo indicado para verificar o domnio da mquina cliente. Os domnios sero obtidos por resoluo reversa de IP, o que pode causar atrasos para a resposta da requisio. A definio do domnio deve ser feita da seguinte forma: ``.meudominio.com.br'', no podendo ser esquecido o ``.'' (ponto) no incio; dstdomain - usado da mesma forma que srcdomain, entretanto com relao ao destino; srcdom_regex - avalia o domnio usando expresses regulares. Seu uso semelhante as duas anteriores, acrescentando a flexibilidade do uso da expresso regular; dstdom_regex - usado da mesma forma que srcdom_regex, entretanto com relao ao destino; time - usado para especificar dias da semana e horrios. Os dias da semana so definidos atravs de letras que os representam, e os horrios atravs de intervalos na forma hora:minuto_iniciohora:minuto_final. Os dias da semana so especificados assim: S - Sunday (Domingo), M Monday (Segunda-Feira), T - Tuesday (Tera-Feira), W - Wednesday (Quarta-Feira), H - Thursday (Quinta-Feira), F - Friday (Sexta-Feira) e A - Saturday (Sbado); url_regex - Este tipo percorre a URL a procura da expresso regular especificada. Deve ser observado que a expresso case-sensitive, para que seja case-insensitive deve ser usada a opo -i. o tipo mais comum de ACL dada a flexibilidade proporcionada pelo uso de expresses regulares; urpath_regex - Tipo semelhante a url_regex, mas procura a expresso 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 aps 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 tambm case-sensitive, para que seja case-insensitive deve ser usada a opo -i; port - Realiza o controle pela porta de destino do servidor, neste tipo deve ser especificado o nmero da porta; proto - Serve para especificar o protocolo, como por exemplo FTP ou HTTP; method - Especifica o tipo de mtodo usado na requisio, como por exemplo GET, CONNECT ou POST; browser - Usa uma expresso regular para tentar ``casar'' com os dados do cabealho HTTP e combinando ento com o navegador utilizado pelo cliente; ident - Realiza o controle de acesso baseado no nome do usurio. Este tipo requer um servidor Ident rodando na mquina do cliente; ident_regex - Semelhante a ident, mas utilizando expresso regular; proxy_auth - Tipo usado para implementar autenticao de usurios no proxy. A autenticao feita com uso de softwares externos. Podem ser passados os nomes dos usurios ou usada a opo REQUIRED para que seja autenticado qualquer usurio vlido; snmp_community - Tipo usado para especificar o nome da comunidade SNMP, para que se possa monitorar o Squid atravs deste protocolo; maxconn - Especifica um limite de conexes vindas de um determinado cliente, interessante para uso com outras ACL's de forma a limitar quantidades de conexes para determinados endereos especficos; req_mime_type - Especifica uma expresso regular para ser verificada no cabealho da requisio 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 endereo IP da placa, usa-se o seu endereo MAC.

7.2 - Construindo regras de acesso

Muitas so as possibilidades de construo de listas de acesso com o uso destes e outros tipos citados acima, mas o fato que para cada situao especfica vai ser necessrio o uso de uma ou mais ACL's, de um mesmo tipo ou de tipos diferentes, de forma que possa se chegar a uma situao ideal de controle. No existe uma regra rgida para criao de listas de acesso, portanto vai depender muito da necessidade e habilidade de cada um. Vamos descrever algumas situaes de como podemos construir listas de controle de acesso para atender a cada uma das situaes propostas, observando que se trata de uma das formas de resolver o problema e no a nica. interessante observar que o controle de acesso deve ser construdo em duas etapas, primeiramente so feitas as classes de ACL's e depois so construdas as regras de acesso com o uso destas ACL's, com o uso de operadores. Existem vrios 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 construo das regas devemos levar em considerao alm das observaes 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 includa como ltima linha das regra de acesso ``http_access deny all''. Desta forma no vamos deixar que esta inverso de regra

possa provocar algum dissabor, pois negaremos qualquer acesso que no tenha uma regra especfica. Apresentamos abaixo alguns exemplos de como construir regras de acesso: 1. Controlando acesso pela origem:

2. acl localnet src 192.168.16.0/24 3. http_access allow localnet http_access deny all
Com estas regras estamos especificando que requisies vindas da rede 192.168.16.0/24 sero aceitas, nos demais casos o acesso ser negado; 4. Controlando o acesso pelo destino:

5. acl outra_rede dst 192.168.17.0/24 6. 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; 7. Controlando acesso pela origem e destino:

8. acl localnet src 192.168.16.0/24 9. acl outra_rede dst 192.168.17.0/24 10. http_access allow localnet outra_rede http_access deny all
Aqui juntamos as duas anteriores e estamos especificando que requisies vindas da rede 192.168.16.0/24 e que sejam destinadas rede 192.168.17.0/24 sero aceitas, nos demais casos o acesso ser negado; 11. Controlando acesso pela nome de domnio de origem e destino:

12. acl meu_dominio srcdomain .meudominio.com.br 13. acl mundo_lafora dstdomain .lafora.com.br 14. http_access allow meu_dominio mundo_lafora http_access deny all
Estas regras so semelhantes as acima, onde usamos src e dst, entretanto aqui verificado o domnio, neste caso requisies vindas de .meudominio.com.br e com destino a .lafora.com.br sero liberadas, nos demais casos o acesso ser negado. muito importante no esquecer o ``.'' (isso mesmo, o ponto) antes do nome do domnio, sob pena da regra no funcionar; 15. Controlando o acesso usando autenticao de usurio:

16. acl usuarios proxy_auth REQUIRED 17. http_access allow usuarios http_access deny all
Esta regra faz com que o acesso seja liberado apenas para usurios que sejam vlidos, dado ao uso da opo REQUIRED, e que se autentiquem no Squid. Para que a autenticao 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 seo 5; 18. Controlando acesso pela origem, destino e autenticao de usurio:

19. 20. 21. 22.

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 requisies vindas da rede 192.168.16.0/24 e que sejam destinadas rede 192.168.17.0/24 sero aceitas, mas desde que os usurios sejam autenticados, nos demais casos o acesso ser negado; 23. Acrescentando controle de acesso pelo horrio:

24. 25. 26. 27. 28.

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 horrio. Veja tambm a ordem em que as ACL's so verificadas, observe que a verificao dos usurios feita por ltimo, pois no vamos forar o usurios a se autenticarem para s depois negar o acesso por um outro motivo. Isto no obrigatrio, apenas no nosso caso fica melhor desta forma, pois se, por exemplo, o horrio no est dentro do permitido, o acesso ser negado imediatamente sem nem mesmo tentar checar as outras ACL's;

29. Controlando o acesso por palavras chaves:

30. 31. 32. 33. 34. 35. 36.

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 dvida o tipo de controle mais usado, pois com ele podemos fazer o bloqueio de contedo considerado imprprio de maneira muito fcil. No nosso caso estamos fazendo o uso de arquivos que contm 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 no representam contedo imprprio, no caso /etc/squid/noporn. Por exemplo, nem sempre a palavra sexo representa necessidade de bloqueio, pois podemos ter sites de contedo 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. Ento aqui estamos fazendo o seguinte: primeiramente vamos liberar usurios que desejem acessar sites listados no arquivo /etc/squid/noporn e que pertenam a nossa rede, no caso 192.168.16.0/24 ou usurios que queiram acessar sites com contedos diferentes (! significa diferente) do listado nos arquivos /etc/squid/porn e /etc/squid/porn1 e que pertenam a nossa rede, em ambos os casos dever ser feita a autenticao.

7.3 - Erros mais comuns

Como j mencionamos, apesar da grande flexibilidade na construo das listas de acesso, devemos ter sempre em mente os problemas referentes a sua criao, para que o resultado seja o que realmente esperamos. O uso inadequado ou desconhecimento destas regras de como utilizar as ACL's podem tornar suas listas totalmente ineficientes e lhe trazer a sensao de que tudo est funcionando corretamente. Estes erros podem ser mais comuns quando o nmero de regras aumentam, portanto para que eles sejam evitados devemos nos lembrar sempre que:

As regras so sempre interpretadas de cima para baixo; As expresses regulares so case-sensitive, ou seja, maisculas so diferenciadas de minsculas, para que seja case-insensitive deve ser usada a opo -i; Se uma das regras da lista de acesso for aplicada, as demais sero ignoradas, isto , apenas uma das regras da lista vai ser aplicada por vez; As regras so interpretadas da seguinte forma: http_access allow ACL1 AND ACL2 AND ACL3 OR http_access allow ACL4 AND ACL5AND ACL1 OR ... Este o tipo mais comum de erro, por isso devemos ter sempre isto em mente ao montarmos nossas regras.

Existe uma regra implcita no Squid que utilizada caso nenhuma das regras da lista seja aplicvel 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 contrrio. extremamente recomendvel 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 inverso que o Squid faz.

Vejamos alguns casos de erros: 1. Queremos que o acesso seja restrito a determinada origem e destino simultaneamente, isto , a conexo dever ser originada na nossa rede e ter como destino uma rede especfica.

2. 3. 4. 5.

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 esto corretas, entretanto se forem analisadas com mais calma podemos verificar que elas no vo 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, no 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 queramos. Desta forma o correto seria ter apenas um operador escrito da seguinte maneira http_access allow localnet outra_rede;

6.

Queremos controlar o acesso pela origem e destino, como j visto no caso anterior, s que agora com o uso de autenticao de usurios.

7. acl localnet src 192.168.16.0/24 8. acl outra_rede dst 192.168.17.0/24 9. acl usuarios proxy_auth REQUIRED 10. http_access allow usuarios 11. http_access allow localnet outra_rede http_access deny all
Aqui foi cometido o mesmo erro do caso anterior, pois se o usurio conseguir se autenticar j ser suficiente para que o acesso seja liberado, ento a origem e o destino no sero mais verificados, pois uma regra j foi satisfeita;

12. Queremos controlar o acesso pela origem, com verificao de contedo imprprio atravs de expresses regulares, para usurios autenticados.

13. acl MINHA_REDE src 192.168.16.0/24 14. acl USUARIOS proxy_auth REQUIRED

15. 16. 17. 18. 19.

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 no foi feita a restrio com base na origem, est ento faltando a ACL MINHA_REDE, e sem isso caso o usurio 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 requisio.

8 - Analisando os logs do Squid

No poderamos falar do Squid sem que fossem analisadas algumas das muitas alternativas em software para anlise dos logs e gerao de relatrios com informaes mais ``legveis'' e amigveis das atividades do servidor. Existem vrias ferramentas para anlise e gerao de relatrios dos logs do Squid, dentre elas podemos destacar o Calamaris, SARG e Squid-graph, dentre muitas outras. Cada uma delas apresenta caractersticas e funcionalidades diferentes, entretanto o objetivo final fornecer uma maneira mais amigvel de se analisar as preciosas e detalhadas informaes que o Squid grava em seus logs. Neste trabalho, escolhemos estas trs ferramentas citadas para mostrarmos sua utilizao, conforme veremos nas subsees seguintes.

8.1 Calamaris
O Calamaris um software escrito em Perl que efetua a gerao de relatrios bem detalhados do uso da internet usando os arquivos de logs de vrios 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 relatrios gerados so bem simples na apresentao, entretanto muito ricos em detalhes extrados dos arquivos de logs, eles podem ser gerados no formato HTML ou mesmo em texto para ser enviado via e-mail. A utilizao deste software muito simples, primeiramente temos que baixar a verso mais recente dele emhttp://cord.de/tools/squid/calamaris/Welcome.html.en , descompactar o arquivo no diretrio de sua preferncia, no nosso caso /usr/local/calamaris, aps isso j podemos us-lo. Abaixo temos um exemplo simples de comando necessrio para gerao dos relatrios 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 gerao de relatrios excelentes da anlise dos logs. Neste caso usamos a opo -a que diz ao Calamaris para serem gerados todos os relatrios, -F html especifica o formato do relatrio 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 localizao do relatrio gerado, neste caso uma pasta na rvore do Apache de forma que possa ser analisado de qualquer estao da rede. O ideal que seja desenvolvido um script para que possamos programar a execuo do Calamaris pelo cron, mas isso no ser tratado aqui dado ao fato que isto dever ser feito de acordo com as necessidades da cada um, assim como o prprio software j traz alguns exemplos de como fazer isto.

8.2 - SARG

O SARG um dos mais usados e eficientes softwares para gerao de relatrios 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 autenticao, caso este recurso esteja sendo utilizado, listas de sites acessados por usurios e horrios em que foram acessados, etc. Alm do mais, cada um destes relatrios esto recheados de informaes como datas e horrios dos acessos, tempo de gasto na visita ao site, quantidades de dados trafegados e outras mais. Uma outra vantagem deste software que ele est disponvel em vrias lnguas, inclusive o portugus claro, alm do mais tem um arquivo de configurao relativamente simples e bem comentado, alm de est disponvel em pacotes da maioria das distribuies. No nosso caso utilizamos o pacote rpm disponvel na nossa distribuio, no caso a vero 9 do Conectiva. Mas caso voc opte por instalar usando os fontes no havero maiores problemas, siga apenas os passos tradicionalmente usados para instalao usando este mtodo, como mostraremos a seguir. Aps ter baixado a verso mais recente do sitehttp://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 gerao dos relatrios necessrio apenas a execuo do comando sarg. Assim como o Calamaris a execuo do SARG fica mais interessante se programada atravs 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 gerao de relatrios dirios, semanais e mensais, mas isso no quer dizer que no possamos extrair relatrios mais personalizados e de acordo com nossas necessidades.

8.3 - Squid-Graph
O Squid-Graph, assim como o Calamaris, escrito em Perl, entretanto como o prprio nome menciona, um gerador de grficos da utilizao do servidor proxy. Ele se atem a apresentar informaes mais sintticas dos acessos e transferncias de dados, mas nem por isso deixa de ser mais uma alternativa interessante e pode complementar o rol de ferramentas de administrao. Ele pode ser conseguido em http://squid-graph.securlogic.com/files/stable/squid-graph3.1.tar.gz, sendo esta a ltima verso disponvel neste momento. importante lembrar que necessrio que seja instalado o mdulo perl GD, que com certeza deve est nos CD's de sua distribuio favorita. O processo de instalao muito simples, pois trata-se apenas de descompactar os arquivos no diretrio escolhido, j que no 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/* A execuo do comando para gerao dos grficos vai depender de como e quais devero ser gerados, entretanto uma boa maneira de se executar este comando de maneira que seja gerados os grficos de forma cumulativa apresentada abaixo. #/usr/local/squid-graph/bin/squid-graph -c -n -o=/srv/www/default/html/squid-graph/ -title="Grfico de uso do proxy" < /var/log/squid/access.log No comando acima usamos a opo -c, desta forma estamos gerando os grficos cumulativos, isto , vamos ter dois grficos para os acessos e transferncias TCP, respectivamente, e mais dois grficos para os acessos e transferncias UDP. A opo -n faz com que no sejam ``ecoadas'' na tela as informaes do processamento do log do Squid, -o=/srv/www/default/html/squid-graph/

representa o local onde os arquivos sero gravados (html e imagens), -title=``Grfico de uso do proxy'' personaliza o ttulo da pgina html, onde so mostrados os grficos, e por fim temos o arquivo de log dos Squid. Existem outras opes interessantes, como gerar grficos para uma URL especfica ou um determinado usurio, 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/squidgraph -c -n -o=/srv/www/default/html/squid-graph/ --title="Grfico de uso do proxy" Para gerar um grfico dos acessos de um determinado usurio, precisaramos apenas substituir o comando grep mostrado acima, por grep ``192.168.16.3 '', supondo que 192.168.16.3 o IP do seu usurio. Podemos ainda usar o mesmo recurso para grficos de determinados tipos de arquivos, usando a extenso como parmetro, por exemplo grep ``.mp3 '' um bom comeo. 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 opes para seu uso, alm disso existem outras opes interessantes que no foram tratadas aqui.

9 - Concluso
A configurao e o uso de servidores proxy um assunto muito interessante e ao mesmo tempo muito extenso. Temos vrias maneiras de implementar solues deste tipo, que vo 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 utilizao do proxy Squid de modo que fosse possvel elaborar uma viso do processo de configurao e utilizao deste servidor proxy. Este sem dvidas um software livre com qualidade excepcional. A robustez e flexibilidade oferecidas pelo Squid um diferencial muito bom em relao a solues fechadas. Ao mesmo tempo podemos notar a facilidade no seu uso, o que faz dele uma excelente alternativa para uso em qualquer ambiente.

Referncias Bibliogrficas
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 Multimdia Ltda. Pearson, 2003 Pearson, O. (2003). Squid - A User's Guide. Qualica Technologies (Pty) Ltd. Sica et al., 2003 Sica, F. C., Ucha, J. Q., and Simeone, L. E. (2003). Administrao 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&atilde;o comentadas e algumas # foram mantidos os coment&aacute;rios originais # Defini&ccedil;&atilde;o da linguagem language Portuguese # Localiza&ccedil;&atilde;o do arquivo de log do squid access_log /var/log/squid/access.log # t&iacute;tulo do relat&oacute;rio title "Relat&oacute;rios de uso do proxy Squid" # Definicoes da est&eacute;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&oacute;rio tempor&aacute;rio temporary_dir /tmp # Local onde os relat&oacute;rios ser&atilde;o gravados output_dir /srv/www/default/html/sarg # e-mail para envio dos relat&oacute;rios output_email none resolve_ip no user_ip yes # classifica&ccedil;&atilde;o do relat&oacute;rio topuser topuser_sort_field BYTES reverse # classifica&ccedil;&atilde;o do relat&oacute;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&iacute;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&oacute;rios caso j&aacute; existam overwrite_report yes # o que fazer com registros sem usu&aacute;rio records_without_userid ignore # use_comma yes => 23,450,110 use_comma no => 23.450.110 use_comma no # utilit&aacute;rio usado para envio do e-mail com o relat&oacute;rio mail_utility mail # quantidade de sites mais visitados para listar no relat&oacute;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&oacute;digos HTTP para serem ignorados no relat&oacute;rio exclude_codes /etc/sarg/exclude_codes max_elapsed 28800000 # Tipo de Relat&oacute;rios # topsites - Mostra o site, conex&atilde;o e bytes

# sites_users - Mostra que usu&aacute;rios estavam # acessando um site # users_sites - Mostra sites acessados # pelo usu&aacute;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&ccedil;&atilde;o # site_user_time_date - Mostra os hor&aacute;rios que um # usu&aacute;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&aacute;rio e n&atilde;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

1. Entendendo como o squid l as ACLs

A cada caractere inserido no squid.conf lembre-se que o squid l as acls de cima para baixo e quando encontra alguma que se aplique ele pra. Parece meio complicado mas funciona assim: Vou criar trs acls. acesso_total, acesso_restrito e bloqueado. Estes arquivos tero os seguintes contedos: acesso_total = IPs dos clientes que tero acesso total internet. No passaro por nenhuma restrio do squid. acesso_rstrito = IPs dos clientes que passaro pelo bloqueio de sites estabelecido na acl seguinte. bloqueado = Lista de palavras que o squid bloquear se forem encontradas na URL. De posse detas trs acls, vamos declar-las no squid.conf desta maneira: acl acesso_total src "/etc/squid/acesso_total" acl acesso_restrito src "/etc/squid/acesso_restrito" acl bloqueado url_regex -i "/etc/squid/bloqueado" OBS.: A opo -i encontrada na linha que declara o bloqueio serve para NO fazer distino entre maisculas e minsculas. Agora que as regras foram declaradas vamos ativ-las dessa maneira: http_access http_access http_access http_access allow acesso_total deny bloqueado allow acesso_restrito deny all

Como o squid as l: A primeira regra que o squid l (http_access allow acesso_total) diz que ser LIBERADO acesso a quem estiver com o ip cadastrado no arquivo "/etc/squid/acesso_total". Ento, quem ele encontra aqui j liberado e no passa mais pelas outras acls seguintes. Por isso o acesso direto e total. A segunda regra que ele encontra (http_access deny bloqueado) diz que ser NEGADO o acesso s URLs que coincidirem com as palavras que esto no arquivo "/etc/squid/bloqueado". Se, por exemplo, neste arquivo tiver a palavra sexo qualquer site que tenha esta palavra na sua URL no ser acessado, como em www.uol.com.br/sexo, www.sexomais.com.br, etc. Mas ateno neste detalhe. O squid vem lendo o arquivo de cima para baixo e s chegar a segunda regra quem no cair na primeira, ou seja quem no tiver o ip cadastrado no arquivo de acesso total. A terceira regra que o squid l (http_access allow acesso_restrito) diz que ser LIBERADO acesso a quem tiver com o ip cadastrado no arquivo "/etc/squid/acesso_restrito". Como na terceira regra s chega quem no caiu na regra anterior, o acesso pode ser liberado tranquilamente. A quarta e ltima regra (http_access deny all) nega o acesso a qualquer ip de qualquer mscara (0.0.0.0/0.0.0.0), pois ela j vem declarada no incio das acls (acl all src 0.0.0.0/0.0.0.0). Voc deve estar se perguntando: Mas como pode negar acesso a todos os ips se tenho que liberar o meu? A resposta simples e est no que eu enfatizei at agora. O segredo est na sequncia como o squid l as acls. Se ele l a primeira (acesso_total) e ningum se aplicar a ela, ento passar para a segunda. Se nesta tb ningum se aplicar ele passar para a terceira. bvio concluir que se o cliente no est cadastrado no acesso_total, nem est no acesso_restrito ento ele no faz parte da rede e deve ser bloqueado. (Deve ser algum espertinho mudando de ip, hehehe!!!). S chegar a ltima quem no caiu em nenhuma das anteriores. Por issso, divida sua rede em quem pode ter acesso tota e restrito e cadastre os clientes em seus respectivos arquivos.

2. Montando uma rede baseada numa lista de bloqueios

Agora que voc j entendeu como funcionam as acls, vamos a um exemplo um mais complexo do que o anterior, mas no complicado entender. Neste exemplo vamos montar uma rede baseada numa lista de bloqueios e excees. Ou seja, o cliente s ter o seu acesso bloqueado se o site estiver previamente cadastrado na lista de bloqueios. A desvantegem desta montagem de acesso que se o cliente conhecer sites semelhantes aos bloqueados (com URLs diferentes) poder acessar. Fica ento a critrio do administrador da rede ter uma vasta lista do que no pode acesar. A regra deste tipo de restrio : QUALQUER SITE PERMITIDO, DESDE QUE NO ESTEJA NA LISTA. Veja um exemplo de uma rede funcionando assim: Arquivo: /etc/squid/acesso_total Contedo: 192.168.1.2 192.168.1.3 192.168.1.4 192.168.1.5 Descrio: Mquinas que tero acesso total internet. Arquivo: /etc/squid/acesso_restrito Contedo: 192.168.1.6 192.168.1.7 192.168.1.8 192.168.1.9 Descrio: Mquinas que tero acesso restrito internet. Passaro por bloqueios. Arquivo: /etc/squid/download Contedo: .exe$ .iso$ .avi$ .mp3$ .wmv$ .mpeg$ Descrio: Extenses de arquivos que tero download bloqueado. Arquivo: /etc/squid/bloqueado

Contedo: sexo hardcore ninfeta penis suruba playboy revistasexy Descrio: Palavras para restrio de urls. Arquivo: /etc/squid/liberado Contedo: abcdasaude sexoesaude medicinanatural uol.com.br/sexo Descrio: Excees aos bloqueios. O que for colocado aqui, mesmo que esteja na lista de bloqueios ser liberado.

Agora vamos prtica: Declare as acls: acl acl acl acl acl acesso_total src "/etc/squid/acesso_total" acesso_restrito src "/etc/squid/acesso_restrito" liberado url_regex -i "/etc/squid/liberado" download url_regex -i "/etc/squid/download" bloqueado url_regex -i "/etc/squid/blouqeado"

Depois de declarar, ative as acls na mesma sequncia doexemplo abaixo: http_access http_access http_access http_access http_access http_access allow acesso_total allow liberado deny download deny bloqueado alow aceso_restrito deny all

Agora vamos s explicaes e as anlises dos casos. Caso 1 - O cliente com ip 192.168.1.2 vai acessar o site www.uol.com.br. Por estar cadastrado no acesso total ele cair logo na primiera regra e ser LIBERADO o acesso a qualque site. Nenhuma das regras seguintes sero aplicadas a elee tanto o uol.com.br como qualquer outra pgina estar liberada. Caso 2 - O cliente com ip 192.168.1.6 vai acessar o site www.uol.com.br. Por estar no acesso restrito, ele "passar ileso" pela primeira regra. Encontrar ento a segunda (liberado), que so as excees dos bloqueios. Como o site www.uol.com.br no est na lista de excees ele tambm passar ileso por esta regra. Chegar ento, terceira regra (download) que limita os downloads. Nesta tambm no encontrar nada, pois no estamos fazendo download de nenhum arquivo. Chegar ento a quarta (bloqueado) e mais perigosa regra, mas como nela no tem nehuma restrio para o site uol ele tambm passar ileso. Cair ento na quinta regra,

onde o acesso ao seu ip (192.168.1.6) est LIBERADO (allow) podendo assim acessar o site www.uol.com.br. Caso 3 - O cliente com ip 192.168.1.6 vai acessr o site www.sexomais.com.br. Por estar no acesso restrito, ele passa pela primeira regra. Encontrar a segunda, na qual h excees para os bloqueios, mas noh nenhuma exceo para o site sexomais.com.br. Ento ele prossegue, passando ileso pelo download e caindo na regra bloqueado, pois o site sexomais.com.br contm uma palavra (sexo) que est na lista de bloqueios. Mesmo estando cadastrado no acesso_restrito este cliente no chegar a acl que lhe d permisso de acesso, pois antes ele j caiu no bloqueio de sites e (como j disse) o squid pra de ler quando aplica alguma regra. Caso 4 - O cliente com ip 192.168.1.6 vai acessar o site www.medicinanatural.com.br/sexo. (Mas que cara teimoso...) J sabemos que este cliente pular a primeira regra, pois sei ip do acesso restrito, mas cair logo na segunda, onde h uma exceo para acessar todo o contedo do site medicinanatural. Mesmo que em sua url (www.medicinanatural.com.br/sexo) tenha a palavra sexo, a regra de bloqueio no ser aplicada, pois antes mesmo de chegar nela foi encontrada uma adequao na regra de excees e o squid parou de ler o resto das regras para este ip. Caso 5 - O cliente com ip 192.168.1.6 (coitado dese cara...) vai acessar o site www.superdownloads.com.br. Ele pular a primeira regra. No se enquadrar na segunda, mas cair na terceira se tentar fazer qualquer download de arquivos com extenses definidas na lista /etc/squid/download. Se no tentar fazer downloads, poder navegar tranquilamente pelo site, afinal, no h nenhuma restrio para a URL dele. Espero que este exemplo tenha ficado claro. Na pgina seguinte montaremos um outro tipo de restries de acesso.

3. Montando uma rede baseada numa lista de excees

Este tipo de rede bem mais fcil montar que a antrior. NELA, TUDO BLOQUEADO, EXCETO O QUE VOC DEFINIR COMO EXCEO, ao contrrio da outra que tudo liberado, exceto o que voc definir nos bloqueios. Sua vantagem que o administrador da rede no precisa de uma enorme lista do que "no pode ser acessado". Em alguns casos mais fcil liberar apenas o que pode ser acessado do que bloquear tudo o que no poder ser acessado. A grande jogada esta a! Vamos ento a um exemplo prtico. Arquivo: /etc/squid/acesso_total Contedo: 192.168.1.2 192.168.1.3 192.168.1.4 192.168.1.5 Descrio: Mquinas que tero acesso total internet. Arquivo: /etc/squid/acesso_restrito

Contedo: 192.168.1.6 192.168.1.7 192.168.1.8 192.168.1.9 Descrio: Mquinas que tero acesso restrito internet. Passaro por bloqueios. Arquivo: /etc/squid/liberado Contedo: .gov. .edu. .org. ufc uece unifor minhaempresa.com.br bb.com.br bradesco.com.br Descrio: Excees aos bloqueios. Declare as acls: acl acesso_total src "/etc/squid/acesso_total" acl acesso_restrito src "/etc/squid/acesso_restrito" acl liberado url_regex -i "/etc/squid/liberado" Ative as acls: http_access http_access http_access http_access allow acesso_total allow liberado deny acesso_restrito deny all

Agora vamos ao estudo dos casos. A primeira regra LIBERA o acesso dos ips cadastrados no acesso_total. A segunda regra libera o acesso apenas aos contedos do arquivo /etc/squid/liberado. E as demias negam os acessos da rede local e de todos os outros ips tambm. Caso 1 - O cliente com ip 192.168.1.2 vai acessar o site www.uol.com.br. Por estar cadastrado no acesso total ele cair logo na primiera regra e ser LIBERADO o acesso a qualque site. Nenhuma das regras seguintes sero aplicadas a elee tanto o uol.com.br como qualquer outra pgina estar liberada. Caso 2 - O cliente com ip 192.168.1.6 vai acessar o site www.uol.com.br. Por no estar no acesso total, ele pular esta regra. Como no h nehuma exceo para o site www.uol.com.br ele tambm passar ileso pela segunda regra. Da terceira em diante ele no faz mais nada, pois elas negam qualquer tipode acesso. O site www.uol.com.br ser bloqueado para este ip. Caso 3 - O cliente com ip 192.168.1.6 vai acessar o site www.detran.ce.gov.br. J sabemos que ele pular a primeira regra. Encontrar ento a segunda, que em sua lista possui (.gov.) uma referncia URL que ele est tentando acessar. Como a regra est liberando (allow) o acesso a qualquer URL que contenha .gov. o cliente poder acessar normalmente todo o site

www.detran.ce.gov.br. Como vimos este exemplo bem mais simples que o anterior e a abrangncia dos bloqueios bem maior. ideal para escolas, bancos e instituies pblicas, onde o contedo da internet altamente restrito. Na ltima pgina mostrarei como redirecionar as pginas (para um aviso por exemplo) quando o cliente cair em algum bloqueio.

4. Redirecionando
Depois de montada a rede com o modelo de sua preferncia, falta apenas redirecionar as mensagens, afinal havero inmeras reclamaes de clientes dizendo que esto sem internet e na verdde esto tendo seus sites blouqeados. Nada mais bvio do que colocar um aviso informando isso, concorda? bem simples. Vamos ento prtica. Procure no seu squid.conf a linha error_directory. Ela informa o doretrio onde o squid vai buscar os arquivos html de erro. No meu conectiva, por exemplo, o referido diretrio fica em /usr/share/squid/errors/Portuguese. 1. Crie ento uma pgina html comum informando que o usurio est tentando acessar um site proibido. 2. Salve-a dentro do diretrio informado acima para que o squid a encontre quando algum for bloqueado. Procure no squid.conf a linha deny_info. Nesta linha voc define qual erro vai acionar qual pgina. Veja um exemplo: deny_info block.html bloqueado Neste exemplo o cliente ser redirecionado para a pgina block.html quando ocorrer algum bloqueio de sites. Voc pode tambm acrescentar outras pginas de acordo com a quantidade de bloqueios que voc possui. Para isso basta repetir as linhas, como no exemplo abaixo: deny_info block.html bloqueado deny_info down.html download deny_info all.html all Se quiser tambm pode redirecionar para um site: deny_info http://www.google.com.br bloqueado.

5. Final
Espero que este artigo possa ajudar algum de alguma forma. Escrevi pensando no que eu queria ter encontrado quando estava aprendendo a usar as acls, por isso acho que deva ter alguma utilidade. Procurei exemplificar nos mnimos detalhes para no deixar nenhuma dvida. Se mesmo assim, houverem dvidas, dicas ou sugestes estarei inteira disposio.

Configurao automtica de proxy nos clientes

Usar um proxy transparente a forma mais simples de fazer com que todas as estaes da rede utilizem o proxy, sem precisar configurar cada uma das mquinas manualmente. Entretanto, usar um proxy transparente est longe de ser uma soluo perfeita, pois o proxy s atende a requisies na porta 80 (ou seja, no funciona para FTP, HTTPS e outros protocolos) e usar o proxy transparente automaticamente impede que seja usada autenticao dos usurios. Se voc acha as limitaes de usar um proxy transparente pesadas demais, mas tambm no quer arcar com o trabalho de configurar cada estao para usar o proxy manualmente, existe a opo de usar um script PAC (Proxy Auto-Configuration), um arquivo que disponibilizado na rede local atravs de um servidor web. Os clientes so ento configurados para buscarem a configurao de proxy no script. Esta no exatamente uma configurao automtica (voc ainda tem o trabalho de configurar os clientes para utilizarem o script), mas um bom ponto de partida. A principal vantagem em relao configurao manual que ao usar o script voc pode alterar a configurao de proxy em todas as estaes simplesmente modificando o script, em vez de precisar reconfigurar cada estao manualmente. Para comear, voc precisa instalar um servidor web em algum servidor da rede, que ser usado para disponibilizar o arquivo. Para manter as coisas simples, voc pode utilizar o prprio servidor que est disponibilizando o proxy. Basta instalar o Apache usando o gerenciador de pacotes, como em: # apt-get install apache2 ou: # yum install httpd Em seguida, crie o arquivo "/var/www/wpad.dat" (no servidor), com o seguinte contedo: function FindProxyForURL(url, host) { return "PROXY 192.168.1.1:3128"; } No exemplo, o "192.168.1.1:3128" corresponde ao endereo do servidor proxy e a porta utilizada pelo Squid. O diretrio "/var/www" o diretrio raiz do servidor web, de forma que ao colocar o arquivo wpad.dat dentro dele, ele passar a ser disponibilizado atravs do endereo "http://ip-doservidor/wpad.dat", como em "http://192.168.1.1/wpad.dat". O arquivo contm um pequeno javascript que ser processado pelos clientes antes de cada requisio orientando-os a utilizarem o proxy. O arquivo wpad.dat pode incluir diversos outros parmetros. Aqui temos uma verso um pouco mais incrementada do arquivo, que inclui excees para o site da empresa (ou outro site qualquer, que voc defina) e para a faixa de endereos da rede local; endereos que devem ser acessados diretamente, sem passar pelo proxy: function FindProxyForURL(url, host) { if (shExpMatch(url,"*.gdhpress.com.br/*")) {return "DIRECT";} if (isInNet(host, "192.168.1.0", "255.255.0.0")) {return "DIRECT";} return "PROXY 192.168.1.101:3128"; } Voc pode ver uma lista com outros parmetros que podem http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html ser usados no:

Depois de disponibilizar o arquivo, falta apenas configurar os clientes para obterem a configurao de proxy atravs dele. No Firefox, o endereo vai no "Editar > Preferncias > Avanado > Rede > Configuraes > Endereo para configurao automtica de proxy", enquanto no IE vai no

"Ferramentas > Opes da Internet > Conexes > Configuraes da LAN > Usar script de configurao automtica":

Depois de feita a configurao, voc pode checar o uso do proxy pelos clientes monitorando o arquivo "/var/log/squid/access.log" do servidor. Voc ver vrias entradas referentes aos acessos feitos pelos clientes.

Essa a configurao mais elementar, onde os clientes so manualmente configurados para utilizarem o arquivo. O degrau seguinte o WPAD (Web Proxy Auto-Discovery protocol), que permite automatizar a configurao dos clientes, permitindo que eles localizem o arquivo automaticamente. Para usar o WPAD, precisaremos configurar tambm o servidor DHCP e o servidor DNS da rede para orientarem os clientes a utilizarem o arquivo. A alterao do servidor DHCP consiste em adicionar duas linhas no arquivo "/etc/dhcp3/dhcpd.conf", a primeira contendo a diretiva "code 252 = text" e a segunda contendo a localizao do arquivo wpad.dat: option wpad-url code option wpad-url "http://192.168.1.1/wpad.dat\n"; 252 = text;

A primeira linha includa na seo global da configurao, enquanto a segunda includa na seo correspondente subnet, como em: ddns-update-style default-lease-time max-lease-time authoritative; option wpad-url code 252 = text; subnet 192.168.1.0 netmask range 192.168.1.100 option routers option domain-name-servers option broadcast-address option wpad-url } none; 600; 7200; 255.255.255.0 { 192.168.1.199; 192.168.1.1; 208.67.222.222; 192.168.1.255; "http://192.168.1.1/wpad.dat\n";

O "/n" na ltima linha insere uma quebra de linha. Ele um workaround para um bug do IE 6.0, que no l a configurao se o \n no estiver presente. Depois de alterar o arquivo, no esquea de reiniciar o servio para que a alterao entre em vigor. Depois de configurar o DHCP, voc pode configurar os clientes com a opo "Detectar automaticamente as configuraes" na configurao do proxy, em vez de especificar a localizao do arquivo manualmente:

Atualmente, apenas o Internet Explorer compatvel com a configurao automtica via proxy. Voc pode selecionar a opo "Autodetectar as configuraes de proxy para esta rede" no Firefox, mas voc perceber que os clientes continuaro tentando acessar a web diretamente, sem lerem o arquivo wpad.dat e sem utilizarem o proxy:

Isso nos leva configurao do DNS, que complementa a configurao, atendendo a mquinas com o Firefox, Opera e outros navegadores. A configurao do DNS um pouco mais complexa, pois necessrio configurar tambm um domnio para a rede local e ajustar (novamente) tambm a configurao do servidor DHCP para que os clientes utilizem o domnio. Mais adiante teremos um captulo dedicado configurao de servidores DNS utilizando o Bind, onde veremos mais detalhes sobre a configurao de domnios. Por enquanto, vou apenas me limitar a uma receita rpida para que voc coloque o domnio no ar e possa assim ativar a configurao automtica do proxy. O primeiro passo instalar o Bind usando o gerenciador de pacotes, como em: # apt-get install bind O arquivo de configurao padro o "/etc/bind/named.conf". A configurao do domnio feita em duas partes. Primeiro adicionamos uma entrada referente ao domnio no arquivo principal, indicando a localizao de um arquivo externo (onde vai a configurao) e em seguida adicionamos a configurao propriamente dita neste segundo arquivo. Como estamos configurando um domnio local, voc pode especificar qualquer domnio, no necessrio que ele esteja realmente registrado. No exemplo, estou usando o domnio "gdhn.com.br". Comece adicionando a configurao referente a ele no final do arquivo "/etc/bind/named.conf" (no Debian voc pode tambm utilizar o arquivo "/etc/bind/named.conf.local", que carregado como um include): zone type file }; "gdhn.com.br" IN { master; "/etc/bind/db.gdhn";

Veja que na terceira linha especificamos o arquivo externo (db.gdhn), onde ir a configurao do domnio. Esse arquivo precisa ser criado na mesma pasta do arquivo principal, ou seja, ser o arquivo "/etc/bind/db.gdhn". O contedo do arquivo ser o seguinte (veja mais detalhes sobre o significado das opes no captulo sobre DNS): @ IN SOA etch.gdhn.com.br. hostmaster.gdhn.com.br. ( 2008030645 3H 15M 1W 1D ) NS etch.gdhn.com.br. gdhn.com.br. A 192.168.1.1 wpad IN A 192.168.1.1 O "etch" no exemplo o nome do servidor, enquanto o "192.168.1.1" o endereo IP usado por ele. Isso cria o domnio "gdhn.com.br" e o "wpad.gdhn.com.br", ambos apontando para o

endereo IP do servidor. Dessa forma, ao tentarem baixar o arquivo "http://wpad.gdhn.com.br/wpad.dat", os clientes baixaro na verdade o "http://192.168.1.1/wpad.dat". Depois de terminar, no esquea de reiniciar o Bind para que a alterao entre em vigor: # /etc/init.d/bind restart Naturalmente, para que o domnio seja utilizado, necessrio tambm configurar os clientes para utilizarem o servidor DNS interno que acabamos de configurar. Isso feito especificando o endereo IP do servidor como nico servidor DNS na opo "domain-name-servers" da configurao do DHCP e adicionando duas novas opes na seo global do arquivo: ddns-domainname option domain-name "gdhn.com.br."; "gdhn.com.br.";

Este um exemplo de arquivo "/etc/dhcp3/dhcpd.conf", depois das alteraes: ddns-update-style none; default-lease-time 600; max-lease-time 7200; authoritative; option wpad-url code 252 = text; ddns-domainname "gdhn.com.br."; option domain-name "gdhn.com.br."; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.100 192.168.1.199; option routers 192.168.1.1; option domain-name-servers 192.168.1.1; option broadcast-address 192.168.1.255; option wpad-url "http://192.168.1.1/wpad.dat\n"; } Com essa configurao, os clientes Linux recebero a seguinte configurao de DNS (salva no arquivo "/etc/resolv.conf") do servidor DHCP: search nameserver 192.168.1.1 gdhn.com.br.

Veja que includa a linha "search gdhn.com.br", que especifica que eles devem fazer pesquisas dentro do domnio e que o endereo do servidor usado como DNS primrio. Naturalmente, a mesma configurao fornecida aos clientes Windows configurados via DHCP. Veja um exemplo:

Com isso, voc pode configurar o Firefox para localizar o proxy automaticamente e, graas configurao do DNS, ele ser capaz de encontrar o arquivo wpad.dat e utilizar a configurao definida por voc. Uma pequena exceo fica por conta de verses antigas do Firefox para Linux, que possuem um bug na varivel usada para localizar o arquivo. Em vez de procurarem o arquivo wpad.dat no host "wpad" dentro do domnio da rede (que leva ao nosso servidor), elas tentam sempre baixar o arquivo a partir da URL "http://wpad/wpad.dat", sem respeitar a configurao do DNS.

Ao usar clientes Linux rodando alguma das verses afetadas pelo bug, voc ver uma srie de entradas como essa no log do Squid: 192.168.1.183 TCP_MISS/503 1479 GET http://wpad/wpad.dat - DIRECT/wpad text/html A soluo nesses casos editar o arquivo "/etc/hosts" nos clientes afetados, adicionando uma entrada relacionando o host "wpad" com o endereo do seu servidor, como em: 192.168.1.1 wpad Com isso, as requisies passam a ser destinadas ao endereo correto, solucionando o problema.