Escolar Documentos
Profissional Documentos
Cultura Documentos
Resumo: Este artigo apresenta a ferramenta de proxy/cache Squid como uma alternativa para a implementacao de um controle de acesso a inter ` net, objetivando desta forma coibir o uso inadequado, principalmente em ambientes corporativos. Palavras-Chave: Squid, controle de acesso, proxy, cache.
Introducao
Com o aumento dos incidentes de seguranca da informacao e o r pido crescimento da in a ternet no meio corporativo, a preocupacao com seguranca da informacao e cada vez maior. A poltica de seguranca e uma peca chave quando queremos tornar um ambiente compu tacional mais seguro. Uma Poltica de Seguranca e um conjunto de leis, regras e pr ticas a que regulam como uma organizacao gerencia, protege e distribui suas informacoes e re cursos (UCHOA, 2003). Umas das preocupacoes que deve ser abordada na poltica de seguranca diz respeito ao controle de acesso, ou seja, o que o usu rio pode ou n o estar fazendo. Os mecanisa a mos para este controle n o devem ser abordados pela poltica de seguranca, mas devem a ser implementados de maneira que se faca cumprir o que nela e determinado. Mais deta lhes sobre poltica de seguranca podem ser encontrados em (NIC BR SECURITY OFFICE, 2003). Em se tratando de acesso a internet existem v rias formas de realizar o controle, a a e forma mais comum e o controle atrav s de rewalls baseados em ltro de pacotes e sis temas de proxy. O proxy e um programa que ca entre a rede local e a rede p blica u (internet), realizando o controle na comunicacao entre os dois lados (UCHOA; SIMEONE; SICA, 2003). O proxy trabalha como um intermedi rio entre cliente e o servidor, ou seja, ele recebe a as requisicoes e repassa aos servidores. Essa caracterstica pode gerar uma confus o com a o NAT Network Address Translation (SRISURESH; EGEVANG, 2001), por m o proxy, e diferente do NAT, trabalha baseado na aplicacao. Por trabalhar com uma aplicacao es pecca, o proxy permite um controle maior sobre v rias aplicacoes, como as que podem a usar qualquer porta, uma vez que ele trabalha em portas e aplicacoes pr -denidas (RU e FINO, 2002). O Squid e um poderoso servidor de proxy/cache que suporta os protocolos FTP (POSTEL; REYNOLDS, 1985) e HTTP (FIELDING et al., 1999), oferecendo suporte para os principais sistemas operacionais baseados em UNIX, dentre eles FreeBSD, OpenBSD,
68
SunOS, HP-UX, AIX e atualmente acompanha as principais distribuicoes de Linux. Li cenciado nos termos da GPL - GNU General Public License (FREE SOFTWARE FOUN DATION, 1991), o Squid e largamente utilizado para compartilhamento de acesso a WEB, possuindo caractersticas que permitem ainda trabalhar com outros objetivos como me lhoria de performance e controle de acesso. Nesse contexto, o objetivo deste artigo e abordar as principais conguracoes para a implementacao de um controle de acesso atrav s do uso do proxy/cache Squid. Para e isso, o texto encontra-se organizado da seguinte forma: nas Secao 2 e a Sec o 3 s o a a apresentados, respectivamente, os par metros e os mecanismos de controle de acesso no a a a Squid; os mecanismos de autenticacao de usu rios no Squid s o mostrados na Secao 4; na Secao 5, s o avaliadas duas ferramentas para an lise de logs do Squid, SARG e Calamaris. a a Por m, na Secao 6 e apresentado resultados obtidos com o uso de t cnicas apresentadas e neste trabalho.
O controle de acesso no Squid e congurado via arquivo de conguracao squid.conf, atrav s de alguns par metros, apresentados na Tabela 1. Esses par metros, em geral, e a a est o associadas a uma dada ACL (Access Control List Lista de Controle de Acesso), a que denem o contexto de um determinado controle de acesso. Como visto na Tabela 1, o par metro acl e utilizado para denir uma dada ACL. Exisa tem v rios tipos de ACLs, os mais importantes s o listados na Tabela 2. Sua sintaxe possui a a a forma: acl nome acl tipo da acl informacao. Detathes podem ser vericados em (VISOLVE.COM, 2002). a As listas de controle de acesso (ACLs) s o interpretadas pelo Squid de cima para ` baixo, portanto deve-se ter o cuidado no momento de estabelecer a ordem das regras. Ela e muito importante, pois encontrada uma regra que venha a coincidir com determinada a a acao, as demais regras n o ser o checadas. Alguns tipos s o pouco utilizados, como srcdomain, urlpath regex, port, proto, method, a browser, ident e arp, n o sendo listados na Tabela 2. Al m desses, existem variantes de a e alguns que permitem a utilizacao de express es regulares, como srcdomain regex, dstdo o main regex, ident regex e proxy auth regex.
O objetivo desta secao e apresentar alguns mecanismos de controle de acesso, ou seja, algumas implementacoes, utilizando os par metros vistos na Secao 2. a
3.1
acl LOCAL_NET src 192.168.10.0/24 http_access allow LOCAL_NET http_access deny all Esta regra e bastante simples, mas faz parte de praticamente toda conguracao segura do Squid. Ela garante o acesso da rede local (192.168.10.0/24). Na primeira linha, foi
Bazar: Software e Conhecimento Livres, Jul. 2006, N. 1, 67- 78 Tabela 1: Par metros do Squid a
69
miss access
Descricao ICP Internet Cache Protocol (WESSELS; CLAFFY, 1997) e um protocolo UDP que tem como objetivo permitir o compartilhamento de informacoes entre servidores cache. Quando se tem uma hierarquia de servidores cache congurados, uma das e possibilidades de comunicacao e atrav s do protocolo ICP. O icp access e respons vel por liberar ou n o o acesso ICP a uma a a determinada ACL. Assim como o icp access, o miss access e usado quando se trabalha dentro de uma hierarquia de servidores cache. Ele determina como ser atendida a solicitacao por um vizinho, de um a objeto que n o esteja armazenado localmente. Em (FONSECA, a 1998) s o apresentados mais detalhes e conceitos sobre hierara quias de servidores cache. Este par metro e utilizado para limitar ou mesmo direcionar uma a determinada ACL a um determinado servidor cache. Pode ser utilizado, por exemplo, quando se deseja que uma determinada rede utilize um servidor de cache especco. Quando se utiliza autenticacao no Squid, uma janela solicitando a a a nome de usu rio e senha ser apresentada para o usu rio. Nessa janela e apresentado a identicacao do servidor, congurada no par metro proxy auth realm (JUCA, 2003). a O par metro http access e respons vel por liberar ou n o o a a a acesso HTTP a uma determinada ACL. O par metro acl e o elemento principal das ACLs, sendo resa pons vel pela sua implementacao. a
` dada o nome de LOCAL NET a ACL e associada a ela todas requisicoes com origem na ` classe IP da rede local, utilizando o tipo src. Na segunda linha, foi liberado o acesso as requisicoes que coincidam com as caractersticas da ACL LOCAL NET; e, na terceira linha, negou-se o acesso a outras m quinas. a
3.2
acl SITES_PROIB dstdomain www.sexy.com.br http_access allow !SITES_PROIB http_access deny all
Neste exemplo, tem-se tr s recursos importantes sendo utilizados. O . (ponto) antes e da indicacao de um endereco indica nome de domnio, incluindo todos os seus servidores. O sinal de ! (exclamacao) funciona como uma negacao. No caso, ser permitido o a acesso a qualquer servidor, com excecao daqueles listados no par metro acl. Observe a
70
Cosa Controle de acesso atrav s do Squid e Tabela 2: Principais Tipos de ACLs no Squid
Tipo src
dst
dstdomain
time
url regex
proxy auth
Descricao Utilizado para indicar enderecos IP de origem (IP do cliente), po dendo indicar o endereco de um host, uma faixa ou mesmo uma classe de enderecos IP. Indica enderecos IP de destino, tamb m pode trabalhar com o e endereco de um host, uma faixa ou uma classe de enderecos IP. Antes de interpretar uma ACL deste tipo, o Squid faz uma consulta DNS para a identicacao do IP do endereco que vai no cabecalho da requisicao. ` Situacao semelhante a apresentada anteriormente, indica o domnio de destino. Neste caso, n o existe pesquisa reversa ao a servidor DNS para a identicacao do IP do cliente, por estar tra tando a regra do domnio de destino da requisicao. Este tipo permite que seja congurado regras de acordo com o dia a a da semana e o hor rio de acesso. Os dias da semana s o indicados por meio de iniciais do dia da semana em lngua inglesa. A indicacao do hor rio deve ser feita atrav s de um intervalo. a e Sua sintaxe e na forma: acl NOME time [dias da semana] [hh1:mm1-hh2:mm2] Pesquisa na URL pela express o regular indicada. Este tipo e case a sensitive, ou seja faz a diferenciacao entre strings de caixa alta e caixa baixa. Caso n o seja de interesse esta caracterstica, deve-se a us -lo com a opcao -i. a Este par metro faz com que o Squid entenda que deve traa balhar com autenticacao de usu rio atrav s de um sistema de a e autenticacao externo. Este tipo e utilizado para controlar o acesso ao Squid atrav s do e protocolo de gerenciamento SNMP (CASE et al., 1990). Este tipo permite controlar o n mero m ximo de conex es de um u a o determinado cliente. Para que seja possvel o uso deste tipo, deve a se ter a par metro client db ativo no arquivo de conguracao do a Squid, por padr o, encontra-se habilitado. Mais um tipo que faz uso da express o regular, neste caso para a identicar a string informada dentro do tipo MIME do cabecalho da requisicao.
ainda que foi informada uma lista de itens para o tipo dstdomain. Alguns administradores, ` inclusive, preferem criar essa lista em arquivo a parte, congurando a chamada de forma ` similar a:
path/para/arquivo
71
Nesse caso, path/para/arquivo e o caminho local do arquivo com a relacao de enderecos. Esse recurso pode ser utilizado em praticamente todos os tipos de ACLs no Squid.
3.3
acl EXEMPLO_T time MTWHF 11:00-13:00 acl EXEMPLO_M maxconn 4 http_access allow EXEMPLO_T EXEMPLO_M http_access deny all Neste exemplo, est sendo liberando acesso integral, com n mero m ximo de quatro a u a ` conex es simult neas, de Segunda a Sexta-Feira no intervalo que vai das 11 horas as 13 o a horas.
3.4
acl PROIBIDO url_regex -i $SQUID-HOME/etc/CONT_PROIBIDO http_access allow !PROIBIDO acl QUERY url_regex cgi{}-bin ? no_cache deny QUERY http_access deny all Neste tipo de controle, foi feito uso de um arquivo externo, no diret rio etc/ do o diret rio home do Squid, denominado CONT PROIBIDO. Nele, ser o colocadas as palavras o a que quando encontradas dever o barrar o acesso ao site. Al m disso, foi informado ao a e Squid para n o fazer cache de p ginas geradas dinamicamente via CGI. a a Observe que, em uma conguracao real, as ACLs s o, normalmente, declaradas no a incio, com regras em seguida. Neste exemplo, optou-se por uma forma alternativa de e a apresentacao (tamb m aceita pelo Squid), com nalidades did ticas.
3.5
acl EXEMPLO req_mime_type application/x-msn-messenger$ http_access deny EXEMPLO Muitos programas que utilizam a tecnologia P2P, como kazaa, MSN entre outros utilizam a porta 80 para realizarem a comunicacao, o que acaba dicultando seu blo queio atrav s do rewall. Uma forma de barrar este acesso e atrav s do tipo MIME do e e cabecalho, como mostrado no exemplo anterior, ele objetiva barrar a utilizacao da porta 80 o pelo MSN. Nesse exemplo, foram utilizadas express es regulares, para maiores detalhes sobre o uso desse tipo de recurso, ver (JARGAS, 2001).
72
Autenticacao no Squid
O Squid permite que seja realizado um controle de acesso baseado em usu rios, ou seja, a a os usu rios para conseguirem o acesso a internet devem, preliminarmente, se autenticar no servidor proxy. Essa autenticacao pode ser realizada de diversas maneiras, sendo as mais comuns o formato NCSA (o mesmo utilizado no servidor WEB apache), atrav s e e e o de um PDC Windows NT/2000/2003, atrav s de um servidor LDAP, atrav s de m dulos PAM, entre outros. Por padr o, o Squid n o traz conguracao de autenticacao habilitada, portanto devem a a ser realizados alguns ajustes no arquivo squid.conf, mais especicamente nas sess es o referentes a: par metros de autenticacao (auth param) e Lista de Controle (ACL). Para a a que o Squid passe a solicitar a autenticacao do usu rio, duas linhas devem ser acrescenta das na lista de controles, s o elas: a acl name proxy_auth REQUIRED http_access allow name E necess rio agora informar ao Squid a conguracao de autenticacao que a ACL acima a dever utilizar e para isso deve-se congurar a diretiva auth param, que ir especicar a a o o tipo de autenticacao utilizada. Observe que os m dulos de autenticacao devem ser compilados a parte, sendo encontrados no diret rio $SQUID-SRC/helpers/basic auth. o O processo de instalacao desse m dulo e extremamente simples, com boa documentacao. o O restante da secao apresenta detalhes de algumas formas de autenticacao. Para uma implementacao simples de autenticacao, utilizando-se o formato NCSA, as seguintes linhas devem ser implementadas no arquivo de conguracao: auth_param auth_param auth_param auth_param basic basic basic basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd children 5 realm Squid Proxy Server credentialsttl 4 hours
Na primeira linha, foi indicado o caminho do m dulo de autenticacao que ser utio a lizado e onde ser criado o arquivo de usu rios para autenticacao. Na segunda linha, a a congurou-se quantos processos lhos do m dulo de autenticacao poder o existir, n mero o a u que deve variar bastante de acordo com o tamanho da rede. Na terceira linha, e infor a a mado o ttulo da janela que ir solicitar a senha ao usu rio e, por m, na quarta, e indicado o tempo de vida de uma autenticacao bem sucedida. Para criacao e insercao de usu rios deve ser utilizado o comando htpasswd. Esse comando e o mesmo utilizado na a implementacao de autenticacao nos servidores apache. Para utilizar a autenticacao em servidores PDC (Windows ou SAMBA), e necess rio a atentar que, ap s a compilacao, dois arquivos ser o criados no diret rio etc/ do Squid: o a o msntauth.conf e msntauth.conf.default. O primeiro deve ser editado de acordo com a conguracao local. Segue-se um exemplo desse arquivo: # MSNT authenticator configuration file
73
# NT hosts to use. Best to put their IP # addresses in /etc/hosts. server pegasus pegasus eacosa.com #denyusers /usr/local/squid/etc/msntauth.denyusers #allowusers /usr/local/squid/etc/msntauth.allowusers Nesse arquivo, e indicado o PDC do domnio, bem como o BDC (caso exista). Caso se pretenda, e possvel ainda utilizar dois arquivos para controlar os usu rios que t m ou a e n o permiss o de acesso a este servico de autenticacao. Em nosso ambiente, testes foram a a realizados utilizando-se uma rede com apenas um PDC, por isso repetimos o nome do servidor na entrada referente ao BDC e no caso n o foram utilizados os arquivos de controle a de usui ros. Outro detalhe importante e que deve-se adicionar no arquivo /etc/hosts do a servidor Squid o endereco IP do PDC. Com relacao a lista de controles, a implementacao ` e similar a usada na autenticacao NCSA: auth_param auth_param auth_param auth_param basic basic basic basic program /usr/lib/squid/msnt_auth children 5 realm Squid Proxy Server credentialsttl 4 hours
Para utilizar PAM para a autenticacao dos usu rios, ap s a compilacao do m dulo, a o o e necess ria a conguracao do arquivo squid dentro de /etc/pam.d, com as seguintes a linhas: auth required /lib/security/pam_pwdb.so shadow nullok account required /lib/security/pam_pwdb.so ` No arquivo squid.conf, a implementacao e semelhante as implementacoes exempli cadas anteriormente, com uma pequena diferenca na primeira linha, onde e necess rio a indicar o arquivos de usu rios e senhas, no caso /etc/shadow. a auth_param auth_param auth_param auth_param basic basic basic basic program /usr/lib/squid/pam_auth children 5 realm Squid Proxy Server credentialsttl 4 hours /etc/shadow
T o importante como controlar o acesso e acompanhar e interpretar os logs gerados pelo a Squid. Com uso de ferramentas auxilares, e possvel analisar uma instalacao e os resul tados obtidos, possibilitando acompanhamento e renamento da conguracao. Em nosso conhecimento, destacam-se duas ferramentas: Calamaris e SARG. O Calamaris e uma ferramenta desenvolvida em Perl, sob licenca GPL, de uso bastante simples. Esta ferramenta permite a geracao de relat rios estatsticos ricos em detalhes em o diferentes formatos, entre eles HTML e TXT e a criacao de relat rios n o apenas para o o a
74
Squid, mas tamb m para outras ferramentas, entre elas: Netcache, Oops! Proxy Server, e Novell Internet Caching System, entre outros. Sendo desenvolvido em Perl, n o existe a a necessidade de compilacao para o uso. O download do arquivo, pode ser feito diretamente do site1 . O calamaris pode ser executado de duas maneiras: # cat /var/log/squid/access.log | /usr/bin/calamaris -a ou # /usr/bin/calamaris -a -F html /var/log/squid/access.log \ > /path/do/destino/ No primeiro caso, o Calamaris ir gerar todos os relat rios possveis e imprimi-los a o na tela do terminal. No segundo exemplo, e solicitado que ele gere todas as estatsticas (par metro -a) no formato html (par metro -F html), no diret rio indicado. E possvel a a o consultar exemplos de relat rios em formato TXT no endereco http://cord.de/tools/ o squid/calamaris/calamaris-2.out. O SARG Squid Analysis Report Generator e uma ferramenta desenvolvida em C, por um brasileiro, que permite acompanhar atrav s de relat rios os sites acessados pelo e o seus usu rios. a Os relat rios gerados pelo SARG s o de simples compreens o e bem completos no o a a que se prop e, al m do usu rio e do site acessado ele apresenta ainda informacoes como o e a total de conex es, bytes tr fegados, se o acesso a determinado site foi negado, data e o a hor rio de acesso e etc. Atualmente em sua vers o 2.0.4, tem opcao para mais de 18 a a idiomas, entre eles o Portugu s, sendo parte integrante das principais distribuicoes Linux e e considerado hoje uma das principais ferramentas de an lise de logs do Squid. a O download do SARG pode ser feito diretamente no site 2 . Sua conguracao tamb m e e simples, o unico arquivo de conguracao e bem documentado, facilitando a conguracao. A Figura 1 apresenta um exemplo de relat rio gerado pelo SARG. o
Com a contratacao de um link dedicado de 256 Kbps para acesso a internet e a liberacao do acesso a WEB para todos os computadores da rede local, incluindo mais de 50 computadores acessando deliberadamente a internet, foi identicado que a utilizacao da WEB a o n o estava sendo feita dentro dos prop sitos almejados pela empresa. A solucao identicada para implementar o controle no acesso e desta forma melhorar o uso dos recursos disponveis, evitando o uso inadequado, indiscriminado foi a implementacao de um servidor proxy. ` A escolha pelo Squid como solucao ocorreu devido as seguintes caractersticas: licenca GPL, documentacao satisfat ria na internet, facilidade no interc mbio de informacoes o a com outros usu rios atrav s de listas de discuss o, grande exibilidade no controle de a e a acesso a WEB. O Squid deveria atender ao seguinte escopo em suas ACLs:
1 Calamaris: 2 SARG:
http://cord.de/tools/squid/calamaris/Welcome.html.en http://sarg.sourceforge.net/
75
1. Acesso totalmente liberado para a diretoria, sem restricao de hor rios e sites; a 2. Acesso para ger ncia e supervisores, restrito ao hor rio de trabalho (Segunda a e a Sexta-feira das 07:00-19:00), com restricao a alguns sites; a 3. Acesso aos demais colaboradores restrito a sites de trabalho e restrito ao hor rio de trabalho; 4. Relat rios di rios de acesso de todas as m quinas. o a a As linhas de conguracao adicionadas na secao adequada do arquivo squid.conf para atender essas necessidades s o apresentadas na Figura 2. a acl all src 0.0.0.0/0.0.0.0 acl diretoria src 192.168.10.52-192.168.10.53/32 acl cargoconfianca src 192.168.10.54-192.168.10.64/32 acl sitesbloqueados url_regex /etc/sitesbloqueados acl sitesdetrabalho url_regex /etc/sitesliberados acl horariotrabalho time MTWHF 07:00-19:00 http_access allow diretoria http_access allow cargoconfianca horariotrabalho !sitesbloqueados http_access allow all horariotrabalho sitesdetrabalho http_access deny all
Figura 2: Linhas adicionadas ao squid.conf para o controle de acesso
76
` A estrat gia de implementacao denida junto a diretoria da empresa foi a seguinte: e em um primeiro momento foi implementada apenas a geracao dos relat rios di rios, onde o a foi acompanhado o acesso dos usu rios durante uma semana, relacionando os sites que a estavam sendo acessados e que deveriam ser bloqueados. Na semana seguinte foi implementado o bloqueio dos sites relacionados na semana anterior, acrescidos de uma relacao de sites disponvel na internet3 , criando uma lista negra de sites pr ria. Muitos usu rios o a caram surpresos ao tentarem acessar determinados sites e se depararem com uma p gina a a informando que o site estava bloqueado. A Figura 3 ilustra a p gina que era apresentada.
a No mesmo dia que iniciou o bloqueio dos sites, foi realizada uma reuni o com os respons veis pelos setores explicando que o acesso a internet estava sendo monitorado e a controlado, que todos deveriam relacionar os sites que costumam trabalhar e que a partir daquele momento novos sites que deveriam ser liberado a todos colaboradores deveriam passar pelo setor de tecnologia da informacao. Os resultados alcancados n o podiam ser melhores. Os relat rios que no incio apre a o sentavam in meros acessos bloqueados foram diminuindo com o tempo. Os relat rios u o continuaram a ser analisados, n o mais diariamene, mas semanalmente e por amostraa gem, mantendo a lista negra de sites que deveriam ser bloqueados sempre atualizada. Problemas com vrus que vinham nas mensagens recebidas atrav s de sistemas de web e mail, acessados para a consulta de e-mails particulares, se extinguiram com o bloqueio dos respectivos sites, minimizando os problemas com suporte. Um dos reexos diretos que foi observado pode ser exposto atrav s do gr co apree a sentando na Figura 4, fornecido pela operadora de telecomunicacoes4 . At o incio do e m s de janeiro o tr fego no link era pequeno e se mantinha dentro de um mesmo patamar, e a o que e justicado pela pouca popularidade da internet entre os colaboradores. Mas com a familiaridade com os novos recursos e a nova tecnologia, o acesso foi aumentando e mantendo um alto patamar de utilizacao do link. Ap s a implantacao do controle de acesso a o
de sites: http://www.squidguard.org/blacklist/ ` a a tr fego de sada apresentado no gr co refere-se a porta de sada do roteador da operadora de telecomunicacoes para o roteador da empresa, portanto indica o tr fego de entrada no roteador da empresa. a
4O 3 Blacklist
77
utilizacao do link voltou a car em patamares bem menores, como pode ser obeservado no gr co a partir do nal do m s de marco. a e
Estes fatos comprovam que antes do controle de acesso, a utilizacao dos recursos era feita indiscriminadamente e n o apenas para as nalidades a que se destinavam, o a a que acabava gerando transtornos e custos indiretos, como lentid o no link, chamados de suporte entre outros. Al m disso, os resultados obtidos comprovaram a ec cia do Squid e a ` para controle de acesso a internet.
Referencias
ANKLESARIA, F.; MCCAHILL, M.; LINDNER, P.; JOHNSON, D.; TORREY, D.; ALBERTI, B. The Internet Gopher Protocol (a distributed document search and retrieval protocol). Internet Engineering Task Force (IETF), March 1993. (Request for Comments: 959). Disponvel em: <http://www.ietf.org/>. CASE, J.; FEDOR, M.; SCHOFFSTALL, M.; DAVIN, J. A Simple Network Management
78
Protocol (SNMP). Internet Engineering Task Force (IETF), May 1990. (Request for Comments: 959). Disponvel em: <http://www.ietf.org/>. FIELDING, R.; GETTYS, J.; MOGUL, J. C.; FRYSTYK, H.; MASINTER, L.; LEACH, P.; BERNERS-LEE, T. Hypertext Transfer Protocol HTTP/1.1. Internet Engineering Task Force (IETF), June 1999. (Request for Comments: 2616). Disponvel em: <http://www.ietf.org/>. FONSECA, E. L. S. An lise de desempenho de servidores proxy cache www. In: a SPG98 - II Semana de P s-Graduacao em Ci ncia da Computacao. Belo Horizonte: o e DCC/UFMG, 1998. Disponvel em: <http://www.dcc.ufmg.br/pos/html/spg98% -/anais/erik/erik.html>. FREE SOFTWARE FOUNDATION. GNU General Public Licence Version 2. June 1991. Disponvel em: <http://www.gnu.org/licenses/gpl.html>. JARGAS, A. M. Express es Regulares Guia de Consulta R pida. S o Paulo: Novatec, o a a 2001. JUCA, H. L. Implementacao de Firewall em Linux. S o Paulo: Brasport, 2003. a NIC BR SECURITY OFFICE. Pr ticas de Seguranca para Administradores de Redes a Internet, Vers o 1.2. [S.l.], 16 de Maio 2003. Disponvel em: <http://www.nbso.nic.bra /docs/seg-adm-redes/seg-adm-redes.pdf>. POSTEL, J.; REYNOLDS, J. File Transfer Protocol. Internet Engineering Task Force (IETF), October 1985. (Request for Comments: 959). Disponvel em: <http://www.ietf.org/>. RUFINO, N. M. de O. T cnicas e Ferramentas de Ataque e Defesa de Redes de e Computadores. S o Paulo: Novatec, 2002. a SRISURESH, P.; EGEVANG, K. Traditional IP Network Address Translator (Traditional NAT). Internet Engineering Task Force (IETF), January 2001. (Request for Comments: 3022). Disponvel em: <http://www.ietf.org/>. UCHOA, J. Q. Seguranca em Redes e Criptograa. Lavras: UFLA/FAEPE, 2003. (Curso de P s Graduacao Lato Sensu (Especializacao) a Dist ncia em Administracao em o a Redes Linux). UCHOA, J. Q.; SIMEONE, L. E.; SICA, F. C. Administracao de Redes Linux. Lavras: UFLA/FAEPE, 2003. (Curso de P s Graduacao Lato Sensu (Especializacao) a o Dist ncia em Administracao em Redes Linux). a VISOLVE.COM. Squid Conguration Manual. [S.l.], May 2002. Disponvel em: <http://squid.visolve.com/squid/squid24s1/squid24s1.pdf>. WESSELS, D.; CLAFFY, K. Internet Cache Protocol (ICP), Version 2. Internet Engineering Task Force (IETF), September 1997. (Request for Comments: 959). Disponvel em: <http://www.ietf.org/>.