Guia sobre Squid/Proxy Transparente

Guia sobre Squid/Proxy Transparente
-----------------------------------

Stéfano Martins

Versão 1.2 - sábado, 07 de agosto de 2004.


-------------------------------------------------------------------------------


Sobre o guia
------------

Este guia tem como seu objetivo ser o mais simples possível,
abordando o assunto nem de maneira superficial demais ou
aprofundada demais, sempre mantendo este nível. Estou escrevendo
pois estava sem fazer nada pela comunidade GNU/Linux, somente
sugando informação.
Como todos podem ver, o estilo do meu guia é similar ao do Guia
Foca Linux, que está disponível em
http://focalinux.cipsga.org.br. Fiz isso por quatro motivos:
1 - Eu gosto do estilo do guia;
2 - Aprendi mais com o autor daquele guia do que com a maioria
dos meus professores;
3 - Para os que já estavam acostumados a utilizar o Guia Foca
Linux, irão ficar mais entrosados;
4 - Porquê eu quis.
Não garanto que esse guia vá possuir inúmeras versões
melhoradas, mas é claro que de vez em quando eu posso
adicionar novos features nele, mas ele irá sempre continuar
com esse mesmo layout. Com um pouco de sorte quem sabe esse
guia passe de 50 páginas!

Nota: Nos últimos dias um amigo meu, Guilherme,
disponibilizou um espaço em seu servidor para a hospedagem
do guia, o endereço de tal servidor é
(http://www.facic.fuom.br/~guilherme/stefano). Grato
Guilherme!


Nota de Copyright
-----------------

Copyleft (C) 2004 - Stéfano Martins.

Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation
License, Version 1.1 or any later version published by the
Free Software Foundation; A copy of the license is included
in the section entitled "GNU Free Documentation License".


-------------------------------------------------------------------------------


Conteúdo
--------

1. Introdução
1.1. O que é Squid?
1.2. Proxy
1.3. Tipos de Proxy
1.4. Vantagens e desvantagens
1.5. Outros servidores Proxy para GNU/Linux e
Windows

2. Instalação do Squid
2.1. Instalação via pacotes .rpm
2.2. Instalação via código-fonte
2.3. Instalação via pacotes .deb
2.4. Instalação em freeBSD
2.5. Instalação em openBSD
2.6. Instalação em Microsoft Windows 2000

3. O arquivo squid.conf
3.1. Introdução
3.2. Limpando o arquivo squid.conf
3.3. Algumas das tags mais importantes
3.3.1. http_port
3.3.2. cache_mem
3.3.3. cache_dir
3.3.4. cache_access_log
3.3.5. cache_mgr
3.3.6. cache_effective_user
3.3.7. cache_effective_group

4. Access Control Lists (ACL's, aka Listas de Controle de
Acesso)
4.1. Introdução
4.2. Tipos de ACL's
4.3. Definindo ACL's
4.4. A tag http_access

5. Casos
5.1. Habilitando o Squid
5.2. Restringindo o acesso ao Squid
5.3. Bloqueando sites indevidos no proxy
5.4. Configurando o Squid para solicitação de
autenticação
5.4.1. O módulo de autenticação
nsca_auth
5.4.2. O módulo de autenticação
smb_auth
5.5. Restringindo o horário de acesso
5.6. O chefe pentelho
5.7. Utilizando Squid com Proxy Transparente
5.7.1. Squid com IPChains
5.7.2. Squid com IPTables
5.8. Redirecionamento de portas
5.9. Segurança

6. Relatórios
6.1. Criando um script de relatório simples
6.2. Utilizando o SARG
6.2.1. Instalação
6.2.2. Configuração
6.2.3. Gerando relatórios
6.2.4. Dica

7. Utilizando o Proxy Transparente
7.1. IP Masquerade
7.2. Configurando o Kernel
7.3. IP Masquerade com IPChains
7.4. IP Masquerade com IPTables
7.5. Utilizando o IPChains no Kernel 2.4

8. Configurando os clientes
8.1. Configurando um cliente Windows
8.2. Configurando um cliente GNU/Linux

9. Outros
9.1. Sobre esse guia
9.2. O que você precisa para utilizar esse guia?
9.3. Sobre o autor
9.4. Agradecimentos
9.5. Referências
9.6. Críticas? Sugestões? Ajuda?
9.7. Atualizações do guia
9.8. Alterações
9.9. ToDo


-------------------------------------------------------------------------------


1. Introdução
-------------

Hoje em dia, os servidores proxy deixaram de ser um simples
privilégio das empresas e se tornaram uma necessidade. Nesse
guia eu darei uma introdução ao assunto e explicarei como montar
os dois tipos de proxy existentes: o Proxy Transparente e o
Proxy Controlado.


1.1. O que é o Squid?
---------------------

O Squid foi originado de um projeto denominado Harvest entre
o governo americano e a Universidade do Colorado - para
saber mais, veja o FAQ do Squid no seu site oficial
(http://www.squid-cache.org).
Atualmente é o proxy mais popular, possuindo mais
co-projetos.
É geralmente disponibilizado por padrão pela maioria das
distribuições GNU/Linux, fornecendo todas as funcionalidades
apresentadas anteriormente, permitindo atuar como proxy para
os protocolos HTTPS, HTTP, FTP e gopher.

Por exemplo: Se o usuário X visita o site da GNU
(http://www.gnu.org), a página é exibida normalmente para
ele e armazenada em cache. Quando o usuário Y fr ver o mesmo
site, ele irá ver o site armazenado em cache, diretamente do
servidor Squid, não sendo feita outra requisição para a
internet.


1.2. Proxy
----------

A tradução de *proxy* para o português é *intermediário*. E é
exatamente isso que o Squid é, um _intermediário entre a rede
local e a _internet_.
Os proxies servem para conectar uma rede interna de computadores
à internet, compartilhando o acesso à ela. Imagine só se você
tivesse que pagar duas linhas ADSL em sua residência só porquê
você tem dois computadores? Foi para esse fim que surgiu o Squid.
Geralmente, nós podemos chamar o computador que está rodando o
Squid de _Gateway_, que é o nosso portão para a internet. Alguns
profissionais da área também consideram o Squid como uma espécie
de roteador, pois ele permite que duas redes diferentes
conversem e troquem informações entre si.


1.3. Tipos de proxy
-------------------

Existem basicamente dois tipos de proxy: o Proxy
Transparente e o Proxy Controlado. Veja a seguir as
diferenças:

Proxy Transparente
------------------
nele é simplesmente feito um repassamento de pacotes vindos da
internet para uma máquina que es´ta na rede interna.

Proxy Controlado
----------------
Essa é a categoria dos softwares especializados em agir como
servidores proxy, como o próprio Squid. Eles possuem mais opções
que o Proxy Transparente para facilitar o controle de quem pode
ou não utilizar o proxy, solicitação de autenticação, proxy para
SSL e o uso de listas de controle de acesso (ACL's) que nós
veremos mais à frente.

1.4. Vantagens e desvantagens
-----------------------------

Claro que dependendo do seu caso como um administrador de redes,
você vai ter que decidir qual tipo de proxy você vai utilizar.
Vão existir casos em que um Proxy Transparente vai lhe
oferecer o suficiente para fazer o que você quer fazer e vão
existir casos em que você vai precisar de funções que
somente um Proxy Controlado está disposto a lhe oferecer.
Conheça aqui algumas vantagens e desvantagens do Proxy
Transparente e do Proxy Controlado.

Proxy Transparente
------------------
É mais simples de ser configurado quando já está habilitado no
Kernel. O cliente é obrigado a passar pelo proxy, programas como
ICQ funcionam plenamente com ele e não precisa que as máquinas
clientes sejam configuradas.

Proxy Controlado
----------------
Com ele você pode utilizar listas de controles de acesso (ACL's)
para controlar quem usa e quem não usa o seu proxy, pode ser
utilizado para uso com SSL< pode servir para liberação de
internet mediante autenticação do usuário e, principalmente,
possui um sistema de caching, possuindo um desempenho na rede
geralmente melhor.

Agora as desvantagens:

Proxy Transparente
------------------
Possui menos recursos que um Proxy Controlado. Precisa de
configurações no Kernel e, em alguns casos, é necessária a
recompilação do Kernel do sistema. Não possui nenhuma segurança
de acesso e não possui um sistema de cachnig, o que o torna mais
lento em uma rede.

Proxy Controlado
----------------
Programas como ICQ e o protocolo SMTP não funcionam muito
bem com ele. Pode ocorrer dos usuários removerem as
configurações do proxy assim que você tiver saído da sala e
a sua configuração é bem mais complicada.


1.5. Outros servidores PRoxy para GNU/Linux e Windows
-----------------------------------------------------

É claro que o Squid não é o único servidor Proxy para
GNU/Linux. Aqui eu irei listas outros conhecidos tanto para
GNU/Linux e para Windows.

Delegate (http://www.delegate.org)
----------------------------------
Este também é um proxy interessante, de autoria de Yutaka Sato,
suportando uma variedade muito grande de protocolos (HTTP, FTP,
NNTP, POP, IMAP, SMTP, Telnet, Wais, X, LDAP, LPR, Socks, ICP,
SSL, etc). É um projeto mais recente que o Squid, pois surgiu em
1994, mas tem evoluído muito rapidamente.

OOPS! (http://zipper.paco.net/~igor/oops.eng/features.html)
-----------------------------------------------------------
É um proxy mais simples que o anterior, surgiu como uma
alternativa ao Squid.

Internet Connection Sharing (ICS)
---------------------------------
É o proxy oficial da Microsoft que é utilizado nos sistemas
operacionais Windows. Possui uma facilidade em sua utilização e
configuração, porém possui poucas opções e vários bugs que
prejudicam sua segurança e funcionamento. As vezes acontecem
problemas qeu você simplesmente não entende o que é.


-------------------------------------------------------------------------------


2. Instalação do Squid
----------------------

A instalação do Squid pode ser feita de várias maneiras. Tanto
pode ser feita por mei de compilação do código-fonte quanto pode
ser feita por pacotes disponíveis para a sua distribuição. Para
cada distribuição, podem existir pacotes que possuem uma
performance melhor ou que possuem patches de segurança próprios
para a mesma, por isso eu recomendo que você puxe sempre que
possível o pacote que é para a sua distribuição.


2.1. Instalação via pacotes .rpm
--------------------------------

As instalações que utilizam os pacotes .rpm, que possuem o
padrão Red Hat são feitas da seguinte maneira:

# rpm -ivh squid-x.y.z.rpm


2.2. Instalação via código-fonte
--------------------------------

As instalações via código-fonte possuem a vantagem de
compilações mais específicas como, por exemplo, se você
desejar utilizar o Squid junto com endereçamento MAC, o que
é muito útil se vocÊ está utilizando o Squid conjuntamente
com DHCP. A compilação básica é feita da seguinte maneira:

# cp squid-x.y.z-src.tar.gz /usr/local/src
# cd /usr/local/src
# tar xvfz squid-x.y.z-tar.gz
# cd squid-x.y.z
# ./configure
# make all
# make install


2.3. Instalação via pacotes .deb
--------------------------------

Este particularmente é o método mais fácil de se instalar
qualquer programa, porém só está disponível para a distribuição
Debian (http://www.debian.org).

# apt-get install squid


2.4. Instalação em freeBSD
--------------------------

Se você instalou o diretório de ports no freeBSD, a instalação
será simples, bastando utilizar os comandos abaixo:

# cd /usr/ports/www/squid25/
# make
# make all install

Ou por meio de um pacote pré-compilado:

# mount /cdrom #CD de instalação do freeBSD
# mkdir /usr/ports/distfiles
# cp /cdrom/packages/All/squid-x.y.z.tgz /usr/ports/distfiles/
# pkg_add -v /usr/ports/distfiles/squid-x.y.z.tgz

Detalhe: x.y.z é a versão do Software.


2.5. Instalação em openBSD
--------------------------

Baixe o pacote já compilado no site do openBSD
(http://www.openbsd.org) e depois:

# pkg_add squid-x.y.z.tgz


2.6. Instalação em Microsoft Windows 2000
-----------------------------------------

Baixe o setup do site do Cygwin (http://www.cygwin.com) e
selecione o pacote do Squid durante a instalação. Proceda como
faria qualquer instalação em plataforma Microsoft (Next, Next,
Finish).


-------------------------------------------------------------------------------


3. O arquivo squid.conf
-----------------------


3.1. Introdução
---------------

Quase todas as configurações do Squid permanecem nesse
arquivo. É um arquivo que, se olharmos por um ângulo
diferente, é um arquivo e também o manual dele mesmo. Ele
possui cerca de 2 mil linhas.


3.2. Limpando o arquivo squid.conf
----------------------------------

Pode parecer uma futilidade para a maioria dos
administradores, mas é recomendável ua limpeza no
squid.conf, pois ele vem com muitas opções e comentários
(que são as explicações das tags) e que geralmente não tem
tanta utilidade se você possuir um guia ao seu lado ou
simplesmente sabe o que está fazendo.
Para fazer uma limpeza no seu squid.conf, execute os
seguintes comandos:

# cp /etc/squid/squid.conf /etc/squid/squid.conf.default
# egrep -v "^#|^$" squid.conf.default > squid.conf


3.3. Algumas das tags mais importantes
--------------------------------------

Aqui eu vou descrever as tags mais básicas para o
funcionamento do Squid. Aqui ainda não serão citadas as
Listas de Controle de Acesso (ACL's). Quero lembrar que um
proxy que rode somente com essas configurações ainda não é
um proxy funcional.


3.3.1. http_port
----------------

Padrão: http_port 3128
----------------------
Este parâmetro define a porta em que o serviço Squid irá escutar
requisições. Por padrão esta opção estará comentada, não
necessitando ser descomentada caso não desejando alterá-la


3.3.2. cache_mem
----------------

Padrão: cache_mem 8M
--------------------
Este parâmetro define a quantidade de memória que o servidor
Squid usará. Caso sua máquina seja dedicada ao proxy, é
recomendável configurar esse valor para 50% de sua memória
física. Quanto maior a quantidade de memória disponível,
melhor será a performance do proxy.


3.3.3. cache_dir
----------------

Padrão: cache_dir ufs /var/spool/squid 100 16 256
-------------------------------------------------
Este parâmetro define o diretório onde o Squid alocará os
arquivos para cache. Nesse caso será o diretório
*/var/spool/squid*. A opção _ufs_ define uma forma de
armazenamento do cache, podendo se utilizar outros formatos,
somente por questões de otimização. Outra opção de formato
de cache é a _aufs_, esta última não é muito utilizada e
está disponível somente para algumas plataformas - veja
arquivo *squid.conf* para saber sobre outras opções de
formato. A opção _100_ define o tamanho máximo do diretório
e é dado em MB. A opção _16_ especifíca a quantidade de
sub-diretórios que o diretório */var/spool/squid* pode ter.
A opção _256_, por sua vez, especifíca a quantidade de
sub-diretórios que os explicados anteriormente poderão ter.


3.3.4. cache_access_log
-----------------------

Padrão: cache_access_log /var/log/squid/access.log
--------------------------------------------------
Define o arquivo de log do Squid. Caso queira saber quem
acessou determinada página da internet, é através deste
arquivo que descobrirá.


3.3.5. cache_mgr
----------------

Padrão: cache_mgr email
-----------------------
Este parâmetro tem a finalidade de especificar o e-mail do
administrador do proxy. CAso o serviço Squid venha a ser
terminado de forma anormal, o usuário do correio eletrônico
especificado será alertado através de um e-mail. Este e-mail
também é informado quando alguma página de erro é mostrada
ao usuário cliente.


3.3.6. cache_effective_user
---------------------------

Padrão: cache_effective_user squid
----------------------------------
Informa ao Squid com qual *nome de usuário* ele deve rodar.
É recomendável não utilizar qualquer tipo de servidor
rodando como o usuário root, uma vez que se o servidor for
invadido, o invador possuirá privilégios de root no sistema.
Nas últimas versões do Squid foi criado um bloqueio que
impede que o mesmo seja executado como root.


3.3.7. cache_effective_group
----------------------------

Padrão: cache_effective_group squid
-----------------------------------
Informa ao Squid com qual *grupo* ele deve rodar.


-------------------------------------------------------------------------------


4. Access Control Lists (ACL's, aka Listas de Controle de Acesso)
-----------------------------------------------------------------


4.1. Introdução
---------------

As Listas de Controle de Acesso (Access Control Lists) ou
simplesmente ACL's são os meios que o Squid nos dá para
fazerum filtro e um controle melhor dos "quem pode", "quem
não pode", etc.
É por aqui que nós iremos trabalhar melhor no nosso proxy,
filtrando os conteúdos e travando os usuários de verem sites
indevidos ou fazerem coisas que não deveriam na internet.
Conclusão: Dá pra fazer muita coisa legal com as ACL's.


4.2. Tipos de ACL's
-------------------

Existem vários tipos de ACL's, cada uma tendo uma finalidade
diferente, é claro. São essas as mais conhecidas:

src
---
Endereço IP de origem, utilizado para restringir quais
clientes podem fazer uso do proxy ou para identificar um
um host.

dst
---
Endereço IP de destino, utilizado para restringir quais
hosts remotos podem serem acessados ou para identificar um
host remoto.

dstdomain
---------
Domínio de destino, utilizado para restrinfir acesso à um
determinado domínio ou para identificar um domínio de
destino.

time
----
Hora e dia da semana, controla quando o proxy poderá ser
utilizado e quando não poderá.

port
----
Número da porta de destino, usado para restringir acesso a
determinada porta de um servidor.

url_regex
---------
Utilizado para restringir determinadas URL's de acesso, a
comparação de URL é baseada em expressão regular. Esse é um
tipo de ACL que você irá utilizar muito.

proto
-----
Protocolo de transferência.

ident
-----
Nome de usuário.

proxy_auth
----------
Utilizado para requerer autenticação dos usuários e para
especificar determinado suários dentro das ACL's.


4.3. Definindo ACL's
--------------------

Dentro do arquivo de configuração do Squid, o squid.conf,
você vai encontrar uma área que é a mais ideal para declarar
as suas ACL's. Este espaço é onde as ACL's começam a ser
definidas, facilmente identificada pela presença das mesmas.
Para declarar ACL's, a sintaxe básica é a seguinte:

acl "arquivo>"

Um exemplo prático de ACL:

acl palavra_proibida url_regex -i sexo

A ACL acima bloqueia todos os sites que contenham em seu
endereço a palavra "sexo".
Outros exemplos serão dados mais à frente, dependendo do
tipo da ACL.


4.4. A tag http_access
----------------------

É simplesmente inútil o uso de ACL's sem o uso da tag
http_access. É ela que trava ou libera o que a ACL está
estipulando.
Exemplo:

http_access deny proibido

Se nós considerarmos o conjunto ACL + http_access, ficaria:

acl proibido url_regex -i sexo
http_access deny proibido

O que o conjunto acima faz é proibir que qualquer site queq
possua em seu endereço a palavra "sexo" seja exibido para o
requisitante.
Nem sempre você vai utilizar um http_access para cada ACL
que você fizer, às vezes você pode combinar duas ACl's em um
único http_access.


-------------------------------------------------------------------------------


5. Casos
--------

Bom, aqu eu vou citar alguns casos e alguns modos principais
para se configurar o seu Squid. É nesse capítulo que nós
vamos entrar mais a fundo na prática do Squid.


5.1. Habilitando o Squid
------------------------

Essa é a coisa mais fácil a se fazer com o proxy, botar ele
para funcionar sem filtro nenhum. Claro que se você optou
por fazer isso, eu sugiro que você utilize um proxy
transparente.
Para botar o Squid para rodar, basta encontrar a linha
_http_access deny all_, alterar o "deny" para "allow" e
reiniciar o serviço entrando em */etc/init.d* e digitando o
seguinte comando:

# ./squid restart

Pronto! Seu Squid já está compartilhando a sua conexão!
Voilá!


5.2. Restringindo o acesso ao Squid
-----------------------------------

Se nós quisermos que somente uma rede da nossa empresa
acesse o proxy, nós podemos definir faixas de IP's ou redes
inteiras para a utilização do proxy. As opções de relay
serão tratadas na seção "5.9. Segurança".
Quando você encontrar a linha *http_access allow all*, ela
vai estar dizendo que todos os usuários estarão aptos a
utilizar o proxy, podemos controlar isso da seguinte
maneira:
Encontre a linha:

http_access allow all

Comente-a, adicionando uma cerquilha ou joguinho-da-velha
(#) antes do primeiro caractere, para que ela fique assim:

#http_access allow all

Agora crie uma nova ACL do tipo _src_ especificando a origem
da sua rede, desse modo:

acl redeinterna src 192.168.1.0/24

Agora autorize a ACL que você acabou de criar, por meio do
http_access:

http_access allow redeinterna

Como nós especificamos acima, somente os usuários da rede
local tesão direito a utilizarem o proxy.
Para determinar faixas de IP's, você pode fazer assim:

acl faixa_adm src 192.168.1.10-192.168.1.15/24
http_access allow faixa_adm


5.3. Bloqueando sites indevidos no proxy
----------------------------------------

Esse exemplo já foi citado lá em cima, mas de qualquer
jeito, vamos abrangê-lo um pouco mais.
O tipo de ACL *url_regex* serve para nós compararmos termos
dentro de uma URL para que possamos permitir que os usuários
acessem ou não determinada página.
Nós utilizamos muito isso quando desejamos queq sites
pornográficos não sejam vistos por clientes dentro de uma
empresa.
Vamos ao exemplo:
Adicione a seguinte ACL:

acl palavra url_regex -i sex

Agora bloqueie o acesso HTTP com o http_access:

http_access deny palavra

Com esse exemplo, todos os sites que possuam a palavra "sex"
no meio não serão abertos pelos clientes. O parâmetro
especificado (-i) serve para que ele não distingua entre
maiúsculas e minúsculas.
Mas você já parou para pensar: "E se eu quiser que uma lista
de palavras sejam bloqueadas?"? Então! Vamos olhar como se
faz:
Crie um arquivo de texto em "/etc/squid/blocked" e dê
permissões de leitura para ele:

# touch /etc/squid/lists/blocked
# chmod 755 /etc/squid/lists/blocked

Nele insira todas as palavras proibidas. Lembre-se que você
deve adicionar uma palavra por linha. Após isso nós criamos
a mesma ACL, só fazendo uma pequena modificação nela:

acl palavra url_regex -i "/etc/squid/blocked"

Agora bloqueie o acesso HTTP com o http_access:

http_access deny palavra

Simples, não é?
É importante saber que a leitura desse arquivo é feita de
cima para baixo, então deve-se prestar muita atenção na
ordem que são colocadas as ACL's. Sempre é interessante
raciocinar exatamente e interpretar a ordem das ACL's para
saber que a coisa está funcionando exatamente como deveria.
Às vezes quando você utiliza o controle por palavras no
proxy, são bloqueados alguns sites que não eram para serem
bloqueados, por conterem essas palavras. Imagine se voce
está bloqueando a palavra "sexo" (www.sexo.com.br) mas
também estará bloqueando o site (www.sexologia.org). Para
isso nós iremos criar uma excessão à regra.
Primeiramente, crie uma lista chamada *unblocked* e dê à ela
as mesmas permissões que você deu à lista *blocked*.

# touch /etc/squid/lists/unblocked
# chmod 755 /etc/squid/lists/unblocked

Nessa lista, você irá colocar todos os sites que são uma
excessão para as listas, portando inclua o
"www.sexologia.org" nele. Um site por linha, não se esqueça.
Após isso, você deverá criar a seguinte regra no seu
squid.conf:

http_access allow blocked !unblocked

E reinicie o serviço ou as configurações:

# ./squid restart
ou
# squid -k reconfigure

Pronto! Está funcionando!

5.4. Configurando o Squid para solicitação de autenticação
----------------------------------------------------------

Este é um caso muito interessante.
Acontece nesse caso que quando nós configuramos o Squid
dessa maneira, nós cadastramos os usuáris em um banco de
dados no servidor e sempre que o usuário abre o navegador, é
solicitado a ele o seu login e a sua senha, para que seja
liberada a navegação. Se o usuário fecha o navegador e abre
novamente, ele é obrigado a se autenticar novamente.
Geralmente isso é utilizado em ambientes acad}emicos ou
escritórios onde os usuáris não possuem um micro definido ou
podem optar por usar qualquer um.
O Squid, ao ser instalado, vem com um módulo chamado
*ncsa_auth*, que e o responsável por fazer essa
autenticação. Existem também outros módulos de autenticação,
como o smb_auth, que funciona conjuntamente com o Samba.
Quando o Samba está afindo como um PDC, o usuário ao se
logar no Windows já se loga no proxy também. Nós iremos
tratar de abos os métodos de autenticação nesse guia. Aqui
nós iremos utilizar também um simples exemplo de
autenticação, mas que é que é utilizado em 90% por dos
ambientes.


5.4.1. O módulo de autenticação ncsa_auth
-----------------------------------------

Para utilizar o módulo de autenticação ncsa_auth, execute os
seguintes passos:
Antes de mais nada, queria falar que dependendo do pacote
que você está utilizando e da distribuição, o módulo do
ncsa_auth pode estar já compilado ou não e sua localização
pode variar, portanto execute o comando *find* para
localizá-lo.

# find / -name ncsa_auth

Após encontrado, copie-o para o /bin:

# cp ncsa_auth /bin

Agora nós teremos queq editar o squid.cnf e adicionar três
linhas. Encontre a linha chamada *auth_param basic* (ela vai
ser uma linha que está comentada) e a altere para:

auth_param basic program /bin/ncsa_auth
/etc/squid/squid_passwd

Nota: A linha acima ocupa uma única linha.

O que essa linha nos indica é o seguinte: Nosso programa de
autenticação será o *ncsa_auth* que está localizado no */bin* e
nós utilizaremos o arquivo de senhas *squid_passwd* que se
encontra em */etc/squid*.
Agora nós iremos adicionar mais duas tags, que são a
*auth_param basic children* e a *auth_param basic realm*.
Elas funcionam respectivamente para dizer ao Squid quantos
processos de autenticação ele vai iniciar e uma mensagem que
vai ser mostrada para os seus clientes quando lhes forem
solitadas as autenticações.
Nestas duas linhas, vocE pode colocar o seguinte:

auth_param basic children 5
auth_param basic realm Digite o usuário e a senha

Agora nós teremos que adicinoar um usuário no arquivo,
utilizando o comando _htpasswd_:

# htpasswd -c /etc/squid/squid_passwd stefano

As próximas execuções do htpasswd não vão necessitar do
parâmetro "-c". O parâmetro "-c" serve para especificar a
criação de um novo arquivo de senhas. Após isso nós
utilizaremos o seguinte para a criação de usuários:

# htpasswd /etc/squid/squid_passwd cassio

Depois de feito isso, nós devemos adicionar uma ACL no
squid.conf:

acl autenticacao proxy_auth REQUIRED

E liberar utilizando:

http_access allow autenticacao

Essa ACL tem por finalidade permitir o uso do proxy somente
se a pessoa tiver executado uma autenticaão válida. Caso
contrario seu acesso é negado.
Após feito tudo isso, é necessário reiniciar o serviço,
entrando no diretório /etc/init.d e executando:

# ./squid restart

Nota: O Squid a princípio parece que funciona conjuntamente
com autenticação e Proxy Transparente, MAS NÃO FUNCIONA! Até
hoje eu espero que alguém me dê uma boa justificativa sobre
isso...


5.4.2. O módulo de autenticação smb_auth
----------------------------------------

Essa é uma opção um pouco mais complicada de ser
implementada, porém que funciona melhor quando você possui
um PDC - Controlador Primário de Dominio (no caso, o Samba).
Aqui eu não irei tratar da configuração do Samba nesse
aspecto e estou considerando que você já o configurou
corretamente.
Uma das principais vantagens disso é que o cliente não tem
que ficar se autenticando toda vez que fechar e abrir o
navegador e que isso nem vai ser perguntado, já que a
autenticação do Samba é a mesma autenticação do Proxy, você
tem uma administração mais fácil, pois só estará utilizando
uma mesma senha para ambos os serviços. Inclusive o usuário
pode alterar a sua senha do proxy sem o uso de cgi-bin's.
Para fazer a configuração, faça o seguinte:
Primeiramente crie um arquivo chamado *proxyauth* no
diretório especificado na seção [netlogon] do seu PDC.
Lembre-se que esse diretório deve ser criado no Windows ou
utilizando o *vi*. Se estiver utilizando o vi, em modo de
inserção digite o seguinte:

:set ff=dos

A seguir, você deverá adicionar nesse arquivo somente a
palravra "allow" (sem aspas) e nada mais.

Nota 1: Caso você possuia BDC's na sua rede, replique o
arquivo nos mesmos.
Nota 2: Quando você cria o arquivo no Windows, ele
infelizmente coloca a extensão .txt no final. Para consertar
isso, renomeie o mesmo no DOS da seguinte maneira:

ren proxyauth.txt proxyauth

Em seguida, adicione a permissão de leitura à todos os
usuários ou grupos que puderem acessar a internet através do
proxy.
Se você desejar o acesso de vários domínios ao proxy, repita
os passos acima para os outros domínios.

Agora vamos para as configurações que devem ser feitas no
squid.conf:
Localize a linha *auth_param basic program* e a deixe da
seguinte maneira:

auth_param basic program /usr/local/bin/smb_auth -W dominio
-U 192.168.1.1

Nota: As linhas acima são uma só.
O parâmetro -W é onde você especifica em qual domínio o
cliente irá se logar e o -U é o endereço do servidor PDC.
Você pode estipular o IP onde o Samba está rodando, mesmo
que seja na própria máquina. Se quiser saber as outras
opções que o smb_auth aceita, entre no seu site
(http://www.hacom.nl/~richard/software/smb_auth_pt_br.html).
Você não precisa especificar as tags *auth_param basic
realm* e *auth_param basic children*, já que a autenticação
será feita na hora que o usuário se logar na rede e que quem
vai gerar os processos de autenticação será o Samba, e não o
Squid.
Em seguida, você deverá jogar a ACl que força a autenticação
dos usuários para que eles possam utilizar o proxy:

acl autenticacao proxy_auth REQUIRED
http_access allow proxy_auth

Pronto! Está funcionando. Para mais informações sobre o
módulo de autenticação smb_auth, visite o seu site em
(http://www.hacom.nl/~richard/software/smb_auth_pt_br.html).


5.5. Restringindo o horário de acesso
-------------------------------------

Aqui é onde nós citamos outro tipo interessante de controle
que nós podemosimplementar em um escritório ou em um meio
acadêmico. O controle por meio de horário.
Para nós fazermos isso, nós fazemos uso da ACL de tipo
_time_.
Exemplo:

acl horariodeacesso time MTWHF 08:00-18:00
http_access allow horariodeacesso

Esta ACL diz para o Squid que o proxy só será liberado das
oito da manhã às seis da tarde nas segundas, terças,
quartas, quintas e sextas-feiras. Qualquer tentativa de
acesso ao proxy fora desse horário será negada.
Aqui nós estipulamos os dias da semana por siglas, que são:

S - Sunday (domingo)
M - Monday (segunda)
T - Tuesday (terça)
W - Wednesday (quarta)
H - Thursday (quinta)
F - Friday (sexta)
A - Saturday (sábado)


5.6. O chefe pentelho
---------------------

Acontece com todos. É fato. Nenhum chefe gosta de tentar acessar
uma página da internet e aparecer para ele um grande "Acesso
Negado" na cara dele. Para falar a verdade, nem eu gosto
muito. Pode acontecer também que você queira criar um
controle que, dependendo do login utilizado, o cliente possa
ver determinadas páginas que o outro usuário não possa e/ou
vice-versa. Vamos ver os dois casos.

Caso 1 - Seu chefe gosta de ver site proibido no trabalho
---------------------------------------------------------
Esse exemplo é quando você não utiliza autenticação e quando
o seu chefe gosta de ver alguns sites que estão proibidos em
uma "lista negra". Faça o seguinte:
Primeiro, crie uma ACL especificando o IP do computador do
seu chefe, no nosso exemplo, vamos supor que seja
192.168.1.50.

acl maodevaca src 192.168.1.50/24

Estou supondo que você já tenha declarado a sua ACL com a
lista negra e que ela se chama *blocked*.
A seguir, na hora que você for colocar o http_access, você
faz da seguinte maneira:

http_access allow blocked maodevaca

Em seguida, reconfigure o Squid ou reinicie o serviço da
seguinte maneira:

# squid -k reconfigure
ou
# ./squid -restart

Pronto! Funcionando! É recomendável que você posicione as
ACL's citadas aqui acima das demais, senão você vai acabar
liberando o seu bloqueio normal para todos os usuários.

Caso 2 - Estagiário só vê o site da empresa
-------------------------------------------
Nesse exemplo é quando o pessoal provavelmente não tem uma
máquina fixa e só tem acesso ao site da empresa. É um pouco
mais difícil de ser implementado, mas nada impossível.
Primeiramente, você deverá especificar o site da sua empresa
por via de ACL's.

acl sitedaempresa dstdomain zica.com.br

Logo após isso, você declara os usuários com uma ACL do tipo
proxy_auth:

acl raleh proxy_auth "/etc/squid/lists/raleh"

Depois você combina as duas ACL's com um único http_access:

http_access deny !sitedaempresa raleh

Veja que eu utilizei novamente o símbolo de exclamação, que
significa "excessão". Interpretando a regra ficaria mais ou
menos assim: "Bloquear todos os sites, COM EXCESSÃO ao site
da empresa para a ralé.".

5.7. Utilizando Squid com Proxy Transparente
--------------------------------------------

Como dito anteriormente, o Squid não sporta todos os
protocolos que são necessários para o pleno funcionamento da
sua rede, dependendo das necessidades que a mesma irá
possuir, como é o caso do ICQ e do protocolo SMTP.
para tanto, é necessário criar conjuntamente com o Squid um
Proxy transparente.
As requisições utilizando o protocolo SMTP serão tratadas
pelo Proxy Transparente enquanto as requisições HTTP serão
tratadas pelo Squid.
O método utilizado é bem simples e não é uma implementação
difícil de ser implementada, bastando para tanto seguir
alguns pequenos passos.


5.7.1. Squid com IPChains
-------------------------

Essa forma, utilizada nos Kernels da linha 2.2,
desenvolve-se da seguinte maneira.
Os comandos que você deve executar são os seguintes:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# ipchains -A input -j REDIRECT 3128 -p tcp -d 0/0 80 -l
# ipchains -A input -j REDIRECT 3128 -p udp -d 0/0 80 -l
# ipchains -A forward -s 192.168.10.0/24 -d 0.0.0.0/0 -j MASQ -l

É interessante colocar essas regras em um script de
inicialização.
Agora vêm as configurações que devem ser feitas dentro do
seu arquivo de configuração do Squid, o squid.conf:

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Pronto, o problema que você poderia estar passando com os
protocolos que o squid não abrange se foram.


5.7.2. Squid com IPTables
-------------------------

Essa forma, utilizada nos Kernels da linha 2.4 e 2.6,
desenvolve-se da seguinte maneira.
Os comandos que você deve executar são os seguintes:

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Nota: Eu estou supondo que eth0 seja a sua interface de
saída para a internet. A mesma pode ser alterada para eth1,
eth2, eth3, ppp0, etc, conforme a sua necessidade.
E faça com que as configurações dentro do seu squid.conf
fiquem desse jeito:

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Pronto, o problema que você poderia estar passando com os
protocolos que o Squid não abrange se foram.


5.8. Redirecionamento de portas
-------------------------------

Aqui está um recurso extremamente interessante. O
redirecionamento de porta é o que realmente garante que os
usuários irão passar pelo Proxy Controlado (no nosso caso, o
Squid), independente do que ele faça para não passar,
incluíndo trocar as configurações de proxy em seu navegador.
Isso acontece porque o redirecionamento de portas faz com
que todas as requisições com destino à porta 80 sejam
encaminhadas para a porta 3128, que é a porta do Squid (por
padrão). É um ótimo recurso para garantir a segurança da sua
rede e não ter que configurar todas as máquinas clientes da
sua rede.
Para a implementação de tal esquema, são necessários os
seguintes passos:
Primeiro, adicione as seguintes entradas no seu squid.conf:

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Nota: Para que você faça o redirecionamento de portas, é
interessante que você crie também o Proxy Transparente
conjuntamente com o seu Squid. Sendo assim, essas
configurações já estarão setadas.
Em seguida, você deverá executar a seguinte regra de
IPTables:

# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j
REDIRECT --to-port 3128

Nota 1: As linhas acima são uma só.
Nota 2: Caso você deseje que essa linha seja adicionada ao
iniciar a máquina, você deverá adicioná-la no seu script de
firewall, o qual será executado na inicialização. Na regra
acima, estou levando em consideração que a eth1 do seu
servidor é a niterface queq se comunica com a rede niterna,
podendo ser trocada conforme a necessidade.
Nota 3: Para que o redirecionamento de portas funcione
corretamente, setando a segurança desejada, o gateway
(gargalo para a internet) e o Squid deverão estar na mesma
máquina.
Nota 4: Não obti muito sucesso com os logs gerados pelo SARG
após a implementação do redirecionamento de portas.


5.9. Segurança
--------------

Todo servidor, independente de plataforma ou serviço que
executa, precisa de certas configurações de segurança. Ele
pode ser um servidor NFS, Samba, Apache, Squid, NIS, tanto
faz, ele irá sempre precisar de um ou outro macete de
segurança para que o mesmo não sofra ataques.
Ao longo do tempo que eu mexo com GNU/Linux, eu aprendi que
o mesmo é um sistema extremamente seguro. Eu ousaria dizer
que é quase impossível de ser invadido. Ineflizmente, por
mais perfeita que seja uma máquina, enquanto ela for
manuseada por um ser humano, sempre poderão haver problemas.
As máquinas podem ser à prova de falhas, mas nós humanos,
infelizmente não somos.
É por isso que eu digo que não adianta nada você ter um
canhã se você não sabe atirar. Do que adianta você ter um
dual Xeon de 3.06 GHz se você não sabe utilizar todo o poder
que ele pode te dar? É a mesma coisa com qualquer tipo de
servidor. Conheço pessoas que possuem servidores
poderosíssimos, porém com desempenho inferor a um K6-2 com
450 MHz e 64 de RAM. Tudo porque não sabiam configurar.
Mas, experiências de vida à parte, voltemos a falar de
Squid.
Aqui eu vou abordar somente quatro falhas de segurança, que
eu julgo serem mais importantes.
O Squid, como vários outros serviços, pode rodar tanto para
a internet quanto para a rede interna da sua empresa. É um
erro comum dos administradores não fechar o mesmo para ser
utilizado somente pela rede interna da empresa. Então
acontece de um belo da você receber um e-mail estranho do
seu provedor, avisando que pessoas estão reclamando de spams
que em seus cabeçalhos possuem o seu endereço IP como
endereço IP de envio daquele e-mail.
É essa a hora que você faz as seguintes perguntas ou
afirmações (não necessariamente nessa ordem):
"Meu Deus! Fui invadido!"
"Mas que diabos!?"
"Será que algum usuário está fazendo coisas que não deveria?"
"Mas como isso aconteceu?"
"Vou checar os logs!"
"Ah! Mas se eu descubro quem foi..."
Infelizmente, os administradores não enxergam o quadro
inteiro, alguns vão trabalhar em outras áreas e acabam nem
descobrindo o que aconteceu. Não sabem quqe, na realiade, o
que aconteceu ali foi quqe eles deixaram seus proxies
abertos para a internet e pintou algum abelhudo que passou
um portscanner em uma rede inteira para procurar um servidor
proxy em que o relay estivesse aberto. Essa tática é
conhecida como IP Spoofing, muito utilizada para disfarçar o
seu IP na internet.
Você deve estar pensando nesse exato momento: "Como é que eu
resolvo esse problema?".
Vamos antes de mais nada encontrar os problemas no arquivo
de configuração do Squid, o squid.conf:

Erro 1
------
http_port 3128
--------------

Aqui, para trancar o Squid para rodar somente na rede
interna, devemos falar para ele escutar somente no endereço
interno, então deveríamos trocar a tag *http_port 3128*
para:

http_port 192.168.1.1:3128

Isso resolveria qualquer problema que você poderia ter em
saber para onde o seu proxy está rodando. Se ainda lhe
restam dúvidas disso, passe um portscanner na sua máquina,
como o nmap (http://www.insecure.org/nmap).


Erro 2
------
acl all src 0/0
---------------
http_access allow all
---------------------

Preste atenção no que essas duas tags estão lhe falando.
Aqui elas estã falando que todos os IP's poderão ter acesso
a seu proxy, incluindo os IP's provenientes da internet.
A princípio, você poderá comentar essa linha, mas não
é necessário caso você tenha arrumado o primeiro erro.
Fique atento sempre nos seus arquivos de configuração.
Procure entendê-los acima de tudo, mesmo que pareçam sem
nexo total.


Erro 3
------
http_access deny all
--------------------

É importante sempre adicionar essa linha no final da parte
do arquivo squid.conf, onde estão descritos os http_access.
Isso é por causa do modo que o Squid interpreta os arquivos.
Ele lê todas as regras de cima para baixo.
Ele vai tentando encaixar as ocasiões dentro das ACL's.
Se ele nã encontrar uma regra que bata com a requisição, por
padrão ele permite o acesso, se a linha http_access deny all
não estiver presente no final de onde estão declarados os
http_access, o Squid irá aceitar qualquer conexão, vinda de
qualquer host da internet!


Erro 4
------

Muitas vezes, você se preocupa demais com o seu servidor e
esquece de algo MUITO, mas MUITO importante: OS CLIENTES.
Cerca de 70% dos ataques de invasão são executados por
funcionários ou ex-funcionários da empresa quqe, se tiverem
razoável conhecimento em informática, passarão por bloqueios
impostos com mais facilidade, por conhecerem o funcionamento
do sistema.
É muito comum que os usuários da empresa passem por cima das
configurações impostas pelo proxy, simplesmente alterando as
configurações do navegador, sobretudo quando um Proxy
Transparente é utilizado conjuntamente com o Squid.
Existem modos de você bloquear isso nos clientes.
O principal é alterando o registro ou utilizar o
redirecionamento de portas descrito anteriormente. No
primeiro caso, o que é feito é o travamento da possibilidade
do usuário estar mudando as configurações do proxy no
navegador. Não irei abordar isso à fundo, mas um ótimo link
é o site (http://www.regedit.com). Lá você encontrará
informações interessantes como bloquear e alterar várias
opções do Microsoft Windows.


-------------------------------------------------------------------------------

6. Relatórios
-------------

O Squid possui vários programas externos para uma
interpretação melhor do access.log, que é o arquivo onde é
registrado os acessos ao proxy.
Entre eles estão o Calamaris, o SARG e o Squid Graph.
Podemos também criar simples scripts com o uso de shell
script, filtrando os dados que mais nos interessam e
mandá-los para o nosso e-mail ou por SMS para os nossos
celulares.
Nesse capítulo, serão abordadas as utilizações de scripts
simples e o uso do SARG. Escolhi abordar o SARG por três
motivos:

1 - Foi feito por um brasileiro;
2 - É o melhor de todos os geradores de relatórios que eu já
vi;
3 - Porquê eu quis.


6.1. Criando um script de relatório simples
-------------------------------------------

Para a criação de um script de relatório que nos envie por
e-mail as últimas requisições negadas pelo porxy, devemos
criar um arquivo e branco:

# touch /bin/relatoriosquid.sh

E então escrever nele o seguinte:

#!/bin
#########################################################
# Script de relatório feito por Stéfano Martins para o #
# guia. Este script pode ser copiado, alterado, e #
# distribuído livremente, conforme a licença GPL, #
# disponível em (http://www.gnu.org). #
#########################################################
cat /var/log/squid/access.log | grep DENIED | tail -n 60 |
mail root

Nota do autor: As duas linhas acima são uma só.

Mude as permissões do arquivo para:

# chmod 700 relatoriosquid.sh

Mais interessante ainda é agendar a execução desse script no
crond para que o mesmo seja executado uma vez por dia:

# crontab -e
30 21 * * * relatoriosquid.sh

Pronto! Todos os dias às nove e meia da noite será gerado o
relatório de acessos negados pelo Squid e eles vão estar
dentro da caixa de e-mail do administrador do sistema.


6.2. Utilizando o SARG
----------------------

Desenvolvido pelo brasileiro Pedro Orso, ele gera uma página
HTML a partir do arquivo de log do squid (access.log por
default).


6.2.1. Instalação
-----------------

Para instalar o SARG, você precisa puxar do site oficial
(http://sarg.sourceforge.net) o pacote no formato mais
apropriado para a sua distribuição ou o código-fonte.


Instalando via pacote .deb
--------------------------

Execute o seguinte:

# dpkg -i sarg-x.y.z.deb


Instalando via pacote .rpm
--------------------------

Execute o seguinte:

# rpm -ivh sarg-x.y.z.rpm

Instalando via código-fonte
---------------------------

A compilação é feita da seguinte maneira:

# tar xvfz sarg-x.y.tar.gz
# cd sarg-x.y
# ./configure
# make
# make install


6.2.2. Configuração
-------------------

Por padrão, o SARG é instalado em /usr/local/sarg. Nesse
diretório nós encontramos o sarg.conf e entre muitas opções,
recomendo as seguintes:

* language Portuguese
* access_log /var/log/squid/access.log
* title "Relatório de uso da internet"
* temporary_dir /tmp
* output_dir /var/www/squid-reports
* resolve_ip no
* user_ip no
* topuser_sort_field BYTES reverse
* topsites_num 100
* max_elapsed 28800000

Sendo importante destacar:

* access.log - Indica o arquivo de log do Squid;
* output_dir - Indica onde será gerado o seu relatório. É
recomendável que seja um diretório onde o seu Apache tenha
acesso;
* reslve_ip - Habilita/desabilita a resolução de nomes;
* user_ip - Se você estiver utilizando um proxy autenticado,
coloque *yes*, caso contrário coloque *no*.
* topsites_num - Quantidade de sites que vocÊ deseja que
apareçam como os TOP de acessos.

Nota: Dependendo da distribuição, tal arquivo pode se
encontrar em outro lugar, bastando procurá-lo utilizando o
comando *find*:

# find / -name sarg.conf


6.2.3. Gerando relatórios
-------------------------

Essa é a parte mais simples, para gerar os relatórios, vocÊ
simplesmente executa o comando:

# sarg


6.2.4. Dica
-----------

Os relatórios do SARG ocupam um enorme espaço em disco,
principalmente por não possuir um rotate ou comprimir os
HTML's gerados. Para contornar esse problema, nós podemos
colocar os seguintes comandos para serem executados em um
determinado horário no crontab.

# find /var/www/squid-reports/ -name "*.html" -type f -mtime
+30 -exec bzip2 {}
# find /var/www/squid-reports/ -name "*.bzip2" -type f
-mtime +180 -exec rm -rf {}


------------------------------------------------------------------------------


7. Utilizando o Proxy Transparente
----------------------------------

Como eu já disse anteriormente, o Proxy Transparente não
necessita de nenhum programa externo para o seu
funcionamento. Você apenas define regras de firewall para
que os pacotes sejam repassados para uma determinada máquina
na rede. As vantagens principais são que com o Proxy
Transparente, você força as máquinas da sua rede à passarem
pelo proxy.


7.1. IP Masquerade
------------------

O IP Masquerade, também conhecido como NAT (Network Address
Translator), tem a finalidade de compartilhar a internet e
fazer com que todas as máquinas de uma rede interna se
conectem através de um servidor que possui um único IP
válido.
O NAT trabalha em outro nível da camada OSI, diferente do
Squid.
Nós sabemos que em uma rede interna, os endereços IP's
atribuídos não são válidos na internet, e ainda sabemos que
todo pacote no protocolo TCP/IP deve ser retornado até o
hospedeiro de origem, no sentido de estabelecer uma
comunicação. Logo nos questionamos: Como uma máquina na
internet retornaria um pacote para uma máquina em uma rede
interna que não possui endereço IP válido? Entre outras
funcionalidades, esta é uma função do IP Masquerade. Quando
um pacote é direcionado à internet, passará pelo gateway que
está provendo o NAT, então o pacote, na verdade, atinge o
hospedeiro de destino com o número da gateway que, por sua
vez, faz o repassamento do pacote para a máquina da rede
interna.
O IP Masquerade suporta perfeitamente serviços como WWW e
e-mail, o que explica o seu grande uso, pois estes serviços
são os mais utilizados. Entretanto, o IP Masquerade não
possui nenhuma funcionalidade de auditoria, autenticação e
segurança de acesso. o NAT pode ser utilizado sem o proxy,
simplesmente permitindo total acesso à internet.
O NAT tem a desvantagem de não prover um cache para o
serviço WEB e as ACL's.


7.2. Configurando o Kernel
--------------------------

Todo o processo de repassagem de pacotes é uma
funcionalidade do Kernel. Por isso às vezes temos que
recompilar o mesmo para habilitar essa funcionalidade. Estas
são as opções do Kernel que você deve habilitar:

1 - Em General Setup Networking, habilite o Sysctl support;
2 - Em Networking Options, habilite Network packet filtering
TCP/IP;
3 - Em Networking Options > IP: Netfilter Configuration,
habilite Connection tracking IP tables support Full NAT
REDIRECT target support;
4 - Em File Systems, habilite o /proc filesystem support.

Essas configurações são válidas somente para o Kernel 2.4 e
2.6, pois os mesmos utilizam IPTables. Caso o seu Kernel não
suporte essas opções ou seja um Kernel da linha 2.2,
recomendo que você pegue uma versão mais nova do mesmo e
compile-a.


7.3. IP Masquerade com IPChains
-------------------------------

A configuração do NAT com o IPChains é muito simples, para
falar a verdade, é muito mais simples configurar um proxy
utilizando NAt do que utilizando um Squid, tudo se resume a
três ou quatro comandinhos:
Aqui nós habilitamos o suporte a IP Forwarding:

# echo 1 > /proc/sys/net/ipv4/ip_forward

Aqui é onde nós inserimos a linha dentro do IPChains. É
importante ressaltar que o primeiro número IP que aparece
(no caso 192.168.1.0) deve ser o número IP da sua rede
interna.

# ipchains -A FORWARD -s 192.168.1.0/24 -d 0.0.0.0/0 -j MASQ

Para ver as regras de IPChains que estão ativas no momento,
digite o seguinte:

# ipchains -L

IMPORTANTE: Quando você reiniciar a sua máquina, essas
regras não mais estarão ativas. Portanto, nós devemos criar
um script para que essas regras iniciem junto com o
computador ou adicionar essas regras dentro do seu script de
firewall, se você já possuir algum.


7.4. IP Masquerade com IPTables
-------------------------------

A finalidade do IPTables é a mesma do IPChains, a diferença
é apenas a linha dos Kernels que eles utilizam. Enquanto
IPTables funciona para os Kernels mais novos, como o 2.4 e o
2.6, o IPChains só funciona para os Kernels da linha 2.2.
Não há excepcionais diferenças entre o IPChains e o IPTables
na hora de implementar um NAT, veja como se faz:
Carregue os módulos (se já não estiverem carregados):

# modprobe ip_tables
# modprobe iptable_nat

Ative o IP Forwarding:

# echo 1 > /proc/sys/net/ipv4/ip_forward

Agora adicione a regra do IPTables:

# iptables -t nat -A POSTOURING -o ppp0 -j MASQUERADE

Onde *ppp0* é a sua conexão com a internet. Você pode também
utilizar eth0, eth1, etc. Tudo depende do seu caso.
Para ver as regras de IPTables que estão ativas no momento,
digite o seguinte:

# iptables -t nat -L

Assim como o IPChains, o IPTables perde as suas regras assim
que a máquina é reinicializada. Portanto, você deverá criar
um script de firewall o adicionar os comandos acima em algum
script já existente.


7.5. Utilizando o IPChains no Kernel 2.4
----------------------------------------

Para configurar o IPChains no Kernel da linha 2.4, vocÊ deve
carregar o seu respectivo módulo:

# modprobe ipchains

A partir daí você já poderá utilizar o IPChains no Kernel
2.4.


-------------------------------------------------------------------------------


8. Configurando os clientes
---------------------------

No caso de você estar utilizando um Proxy Controlado sem o
redirecionamento de portas, você deverá também fazer uma
simplória configuração nos clientes:


8.1. Configurando um cliente Windows
------------------------------------

Abra o Internet Epxlorer;
Entre no menu "Ferramentas" > Opções da Internet;
Entre na guia "Conexões";
Clique em "Configurações da LAN";
Na nova janela que se abrirá, desmarque:

"Detecte automaticamente as configurações"
"Usar script de configuração automática"

E marque:

"Usar um serbvidor proxy para a rede local (estas
configurações não se aplicam a conexões dial-ip ou VPN)"

Preencha os campos com o IP do seu servidor Squid e sua
respectiva porta (por padrão 3128).

Desmarque a caixa:

"Não utilizar proxy para endereços locais"

Feche e abra o Internet Explorer e veja se está navegando.


8.2. Configurando um cliente GNU/Linux
--------------------------------------

Para configurar o proxy no GNU/Linux, eu vou utilizar o
exemplo do Netscape, porém, se você utiliza qualquer outro
navegador, as configurações são semelhantes.
Configurando:

Entre em:
Editar > Preferência > Avançado > Servidores Proxy

Marque a opção "Configuração Manual do Proxy" e clique em
Ver.

Na nova janela que vai se abrir:

Preencha o campo "Proxy HTTP" com o IP do seu servidor proxy
e o campo "Porta" com a respectiva porta (por padrão 3128).

Pronto1 Configurado! Feche e abra novamente o seu browser e
ele estará navegando na internet.


-------------------------------------------------------------------------------


9. Outros
---------

Aqui é onde eu irei colocar algumas informações sobre o guia,
em geral informações alheias ao assunto normal do mesmo.


9.1. Sobre esse guia
--------------------

Bom, eu comecei a escrever o guia porque eu estava em um
final de semana prolongado extremamente maçante. Além do
fato de eu não estar namorando na época, aquela versão do
guia foi carinhosamente apelidado de "Valentine's Day" pela
data em que foi lançado.
Tento nesse guia ser o mais simples possível, abordando
casos pelos quais eu já passei em carreira profissinoal.
Como alguns dos leitores devem ter notado (e notaram, se
estão lendo essa parte), esse guia é muito similar (no
aspecto de layout, não conteúdo, plágio é muito, muito feio)
ao Guia Foca Linux, escrito por Gleydson Mazioli da Silva.
Fiz isso para que os leitores que já leram aquele guia se
sentissem mais confortáveis lendo esse e porque o autor
ainda não havia lançado um guia falando exclusivamente sobre
Squid (pelo menos não até a data de publicação desse Guia).
Espero sinceramente que o meu guia se torne uma fonte de
referência para outras publicações, talvez mais bem
editadas.
A versão em texto puro do guia foi 100% escrita utilizando
VIM (Vi IMproved). A versão HTML foi escrita utilizando
txt2tags e VIM também.


9.2. O que você precisa para utilizar esse guia?
------------------------------------------------

Para utilizar esse guia você precisa:

* Saber ler em português (por enquanto, logo estarei
lançando uma versão em inglês);
* Ter um QI acima de 30;
* Ter uma noção sobre des em GNU/Linux, ainda que seja
modesta;
* Saber utilizar o sistema em si.


9.3. Sobre o autor
------------------

Para os que não me conhecem, meu nome é Stéfano Martins,
resido na cidade de Pindamonhangaba (UFA! Nominho grande
hein?) - SP e tenho 18 anos.
Tomo conta do servidor da Escola Técnica João Gomes de
Araújo, aqui na minha cidade, onde eu estudei e continuo
estudando.
Escrevo diariamente nos fóruns da underlinux
(http://www.underlinux.com.br) e na lista de discussão
debian-user-portuguese
(debian-user-portuguese@lists.debian.org), além de ser
Community Manager da "Debian GNU/Linux Brazil", comunidade
do Orkut (http://www.orkut.com) destinada à sanar as dúvidas
dos usuários que estão migrando ou que já utilizam a
distribuição Debian já faz algum tempo.
Palestrei algumas vez, sobretudo falando sobre
software-livre, projetos de migrações, redes e Debian.


9.4. Agradecimentos
-------------------

Cássio, meu irmão mais velho, que além de ser o melhor
programador em C/C++ que eu já conheci, é o meu melhor
amigo. FOi ele que me apoiou sempre que eu precisei, exceto
dessa vez, pois ele viajou para ver a namorada e nem sabe
que eu estou escrevendo o guia no computador dele.
Guilherme Mesquita, grande amigo e help-desk via ICQ, sempre
me ajuda qunado eu estou com algum problema aparentemente
insolúvel, sem falar que é o punk mais cult que eu já
conheci!
Yuri Kropotkin, o ucraniano que é o cara que eu mais ajudei
na internet. Você me ajudou a fixar os meus conhecimentos,
sem falar que é um ótimo amigo!
Thiago Klein, professor de GNU/Linux. Sinto que a partir de
um determinado ponto, deixamos de ser aluno e professor e
passamos a ser amigos!
Sofia, grande amiga, sempre me apoiou e sempre se preocupou
com o autor do guia, mesmo quando os dois estavam brigados.
Guaraná Piracaia, o qual eu bebi cerca de 30 litros enquanto
eu ia escrevendo esse guia.
Lista de discussão debian-user-portuguese
(debian-user-portuguese@lists.debian.org). Quer tirar uma
dúvida sobre Debian? É para lá que você tem que escrever!
Pessoal da underlinux (http://www.underlinux.com.br). Me
divirto à beça escrevendo no fórum!
Gleyson Mazioli da Silva, autor do Guia Focalinux, parabéns

<< Início