O Squid um servidor Proxy e cache que permite tanto compartilhar o acesso Web co m outros PCs da rede, quanto melhorar

ar a velocidade de acesso atravs do cache. Mas, o Squid suporta apenas os protocolos HTTP e FTP, ou seja, no oferece acesso completo, ape nas navegao (o protocolo Gopher tambm suportado, o difcil encontrar quem ainda use isto hoje em dia). Outros protocolos podem ser suportados, caso voc manualmente a bra as portas utilizadas por eles e estabelea regras de acesso, mas isso pode ser feito mais facilmente utilizando o Nat no Iptables. 1.1. 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 r acional 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 rec ebe diretamente do cache, sem a necessidade de efetuar uma nova busca dos dados na i nternet. 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 intern et; Autenticao - podemos restringir o acesso ao servidor proxy com o uso da autenticao d e 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 d e 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 programas analisadores de logs do Squid capazes de gerar relatrios to bons, que po r 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 eficie nte. Uma nica mquina capaz de prover acesso vrias outras;

a. Baixe os binrios utilizados no Windows no seguinte endereo: http://squid.acmeconsulting.it/downl...ABLE16-bin.zip b. Descompacte o contedo do arquivo zipado na raiz do Windows. c. Entre no diretrio c:\squid\etc e crie uma cpia dos arquivos com os nomes conforme descrito abaixo: squid.conf.default => squid.conf mime.conf.default => mime.conf

cachemgr.conf.default => cachemgr.conf d. Abra o prompt de comando acesse o diretrio cd c:\squid\sbin e digite os comand os abaixo: squid i n squid => comando que instala o servio chamado squid no SO squid z => comando utilizado para criar a cache do squid e. Acesse o menu iniciar e em executar digite no comando services.msc para carregar o gerenciador de servios, localize o servio squid clique com o boto direito e mande inicializar o servio. 1.3. 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 s eu 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 utilitri o a cri-lo. # htpasswd -c arquivo_de_senhas usuario Para que o Squid fornea suporte a autenticao devemos habilitar estas configuraes no arquivosquid.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 basic program c:/squid/libexec/ncsa_auth c:/squid/etc/passwd auth_param basic children 5 auth_param basic realm Servidor Proxy Squid CET auth_param basic credentialsttl 2 hours A linha auth_param basic program c:/squid/libexec/ncsa_auth c:/squid/etc/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 mdul o 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 CET 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. As configuraes do Squid esto concentradas no arquivo c:\squid\etc\squid.conf. 1.4. 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 refer entes s

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 linh as 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 mai s 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 pon to 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 ori gem, 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 diret o 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 po r 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 e m cada um deles; auth_param basic program c:/squid/libexec/ncsa_auth c:/squid/etc/passwd auth_param basic children 5 auth_param basic realm Servidor Proxy Squid CET auth_param basic 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 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 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https

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 configurao padro do Squid e o mnimo recomendvel para seu uso, no sendo necessria nenhuma alterao nas mesmas; acl MINHA_REDE src 192.168.16.0/24 acl USUARIOS proxy_auth REQUIRED acl PORNO url_regex i /etc/squid/poracl acl PORNO1 url_regex i /etc/squid/porn1 acl 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 allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports -Definio de regras de acesso referentes s 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 n a 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 ace sso ao proxy. Ela diz ao Squid que se nenhuma das regras anteriores for aplicada o aces so 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 i mplcita que inverte a ltima regra da lista caso nehuma delas seja aplicada. Isto pode tra zer 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 u m 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 Squ id vai tentar descobrir o nome. Deve ser registrado o FQDN do servidor e no apenas o hos tname; 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 suportada s pelo Squid. E estas mensagens, inclusive, podem ser facilmente personalizadas, pois e sto 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 e rro 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 par a uma outra oportunidade. 1.5. 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 con trolar o acesso internet das mais diferentes formas. Praticamente todo o processo de co ntrole 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 pode m trazer um nvel de segurana muito bom para a rede, entretanto se mau configuradas p odem 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 t estar, testar e testar, e depois quando achar que est bom continue testando e monitorand o 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 se ndo construdas as regras de acesso. As ACL's so case-sensitive, isto , site_porno difer ente de Site_porno, portanto cuidado com isso. Caso seja usada o opo -i elas deixaro de ser case-sensitive. Uma outra regra muito importante que caso uma das regras coincida, as demais no s ero mais verificadas. Isso independe da quantidade de regras que ainda faltam para a tingir o fim da lista. 1.6. 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 en dereo 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 re quisio. 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 s 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 defini dos atravs de letras que os representam, e os horrios atravs de intervalos na forma hora:minuto_inicio-hora: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 v ai 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 part e /pasta/ sexo.html. Ela tambm case-sensitive, para que seja case-insensitive deve ser usad a 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 programas 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, intere ssante para uso com outras ACL's de forma a limitar quantidades de conexes para determin

ados 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 interfa ce de rede do cliente, ou seja, em vez de endereo IP da placa, usa-se o seu endereo MAC. 1.7. Construindo regras de acesso Muitas so as possibilidades de construo de listas de acesso com o uso destes e outr os tipos citados acima, mas o fato que para cada situao especfica vai ser necessrio o u so de uma ou mais ACL's, de um mesmo tipo ou de tipos diferentes, de forma que poss a 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 ac esso 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 AC L'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 qu alquer acesso que no tenha uma regra especfica. 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 requisies vindas da rede 192.168.16.0/2 4 sero 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 f orma 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 requisies vindas da r ede 192.168.16.0/24 e que sejam destinadas rede 192.168.17.0/24 sero aceitas, nos dem ais

casos o acesso ser negado; 4. Controlando acesso pela nome de domnio 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 so semelhantes as acima, onde usamos src e dst, entretanto aqui veri ficado 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 importa nte no esquecer o . (isso mesmo, o ponto) antes do nome do domnio, sob pena da regra no funcionar; 5. Controlando o acesso usando autenticao de usurio: acl usuarios proxy_auth REQUIRED http_access allow usurios 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 feit a, j que ela realizada por programas externos; 6. Controlando acesso pela origem, destino e autenticao de usurio: 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/2 4 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; 7. Acrescentando controle de acesso pelo horrio: 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 usurios 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; 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 dvida o tipo de controle mais usado, pois com ele podemos fazer o bloque io 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 inadequ

ados, 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 represen tam contedo imprprio, no caso /etc/squid/noporn. Por exemplo, nem sempre a palavra sex o representa necessidade de bloqueio, pois podemos ter sites de contedo educativo q ue contenham essa palavra na sua URL, por exemplo http://www.ministeriodealgumacoisa.g...exoseguro.html. As palavras ou sites deve m ser colocados no arquivo uma por linha. Ento aqui estamos fazendo o seguinte: primeiramente vamos liberar usurios que dese jem 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 (! si gnifica diferente) do listado nos arquivos /etc/squid/porn e /etc/squid/porn1 e que pert enam a nossa rede, em ambos os casos dever ser feita a autenticao.