Links
Freebsd.org
OpenPacket Blog
Arquivos
30/08/2005
03/09/2005
06/09/2005
09/09/2005
10/09/2005
03/10/2005
GCC CFLAGS
Estas flags são para gcc-3.x e igualmente (para 3.0, 3.1.1 e 3.2). Você pode checar a versão de seu gcc usando:
# gcc --version
Voce pode saber qual CPU você tem usando:
# cat /proc/cpuinfo
Esta página é para aqueles que não querem experimentar, querem um sistema estável, mas ainda otimizado para seu processador. Tome cuidado, usando estas flags, seus arquivos binários poderão não funcionar em outra maquina. Estão, se você compilar com as flags de P4, voce não poderá mandar um tbz2 ou compartilhar seu disco com um amigo seu que tem um Pentium MMX.
i386 (Intel), você realmente quer instalar o gentoo nele?
CHOST="i386-pc-linux-gnu"
CFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"
i486 (Intel), você realmente quer instalar o gentoo nele?
CHOST="i486-pc-linux-gnu"
CFLAGS="-march=i486 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i486 -O3 -pipe -fomit-frame-pointer"
Pentium 1 (Intel)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=pentium -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium -O3 -pipe -fomit-frame-pointer"
Pentium MMX (Intel)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=pentium-mmx -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium-mmx -O3 -pipe -fomit-frame-pointer"
Pentium PRO (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentiumpro -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentiumpro -O3 -pipe -fomit-frame-pointer"
Pentium II (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"
Celeron (Mendocino), aka Celeron1 (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"
Pentium III (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
Celeron (Coppermine) aka Celeron2 (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
Celeron (Willamette?) (Intel) CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
Pentium 4 (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
Eden C3/Ezra (Via)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=i586 -m3dnow -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i586 -m3dnow -O3 -pipe -fomit-frame-pointer"
Nota : o ezra nao suporta nenhuma especificação especial que possa otimizar o desempenho, apenas considere que é um K6-3, basicamente um P2 sem 3DNOW.
K6 (AMD)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer"
K6-2 (AMD)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=k6-2 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k6-2 -O3 -pipe -fomit-frame-pointer"
K6-3 (AMD)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=k6-3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k6-3 -O3 -pipe -fomit-frame-pointer"
Athlon (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon -O3 -pipe -fomit-frame-pointer"
Athlon-tbird, aka K7 (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-tbird -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-tbird -O3 -pipe -fomit-frame-pointer"
Athlon-tbird XP (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
Athlon 4(AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-4 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-4 -O3 -pipe -fomit-frame-pointer"
Athlon XP (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
Athlon MP (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer"
603 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fsigned-char"
CXXFLAGS="-O3 -pipe -fsigned-char"
603e (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fsigned-char"
CXXFLAGS="-O3 -pipe -fsigned-char"
604 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fsigned-char"
CXXFLAGS="-O3 -pipe -fsigned-char"
604e (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fsigned-char"
CXXFLAGS="-O3 -pipe -fsigned-char"
750 aka as G3 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-mcpu=750 -O3 -pipe -fsigned-char -mpowerpc-gfxopt"
CXXFLAGS="-mcpu=750 -O3 -pipe -fsigned-char -mpowerpc-gfxopt"
Nota: não use -march=
7400, aka G4 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-mcpu=7400 -O2 -pipe -fsigned-char -maltivec -mabi=altivec -mpowerpc-gfxopt"
CXXFLAGS="-mcpu=7400 -O2 -pipe -fsigned-char -maltivec -mabi=altivec -mpowerpc-gfxopt"
Nota: não use -march=
Nota: -O3 é instável no G4
7450, aka G4 second generation (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-mcpu=7450 -O2 -pipe -fsigned-char -maltivec -mabi=altivec -mpowerpc-gfxopt"
CXXFLAGS="-mcpu=7450 -O2 -pipe -fsigned-char -maltivec -mabi=altivec -mpowerpc-gfxopt"
Nota: não use -march=
Nota: -O3 é instável no G4
PowerPC (se você não sabe qual)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fsigned-char -mpowerpc-gfxopt"
CXXFLAGS="-O3 -pipe -fsigned-char -mpowerpc-gfxopt"
Sparc
CHOST="sparc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer"
Sparc 64
CHOST="sparc64-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer"
<< Início
Guia sobre Squid/Proxy Transparente
# gcc --version
Voce pode saber qual CPU você tem usando:
# cat /proc/cpuinfo
Esta página é para aqueles que não querem experimentar, querem um sistema estável, mas ainda otimizado para seu processador. Tome cuidado, usando estas flags, seus arquivos binários poderão não funcionar em outra maquina. Estão, se você compilar com as flags de P4, voce não poderá mandar um tbz2 ou compartilhar seu disco com um amigo seu que tem um Pentium MMX.
i386 (Intel), você realmente quer instalar o gentoo nele?
CHOST="i386-pc-linux-gnu"
CFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"
i486 (Intel), você realmente quer instalar o gentoo nele?
CHOST="i486-pc-linux-gnu"
CFLAGS="-march=i486 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i486 -O3 -pipe -fomit-frame-pointer"
Pentium 1 (Intel)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=pentium -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium -O3 -pipe -fomit-frame-pointer"
Pentium MMX (Intel)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=pentium-mmx -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium-mmx -O3 -pipe -fomit-frame-pointer"
Pentium PRO (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentiumpro -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentiumpro -O3 -pipe -fomit-frame-pointer"
Pentium II (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"
Celeron (Mendocino), aka Celeron1 (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"
Pentium III (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
Celeron (Coppermine) aka Celeron2 (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
Celeron (Willamette?) (Intel) CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
Pentium 4 (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
Eden C3/Ezra (Via)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=i586 -m3dnow -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i586 -m3dnow -O3 -pipe -fomit-frame-pointer"
Nota : o ezra nao suporta nenhuma especificação especial que possa otimizar o desempenho, apenas considere que é um K6-3, basicamente um P2 sem 3DNOW.
K6 (AMD)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer"
K6-2 (AMD)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=k6-2 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k6-2 -O3 -pipe -fomit-frame-pointer"
K6-3 (AMD)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=k6-3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k6-3 -O3 -pipe -fomit-frame-pointer"
Athlon (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon -O3 -pipe -fomit-frame-pointer"
Athlon-tbird, aka K7 (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-tbird -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-tbird -O3 -pipe -fomit-frame-pointer"
Athlon-tbird XP (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
Athlon 4(AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-4 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-4 -O3 -pipe -fomit-frame-pointer"
Athlon XP (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
Athlon MP (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer"
603 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fsigned-char"
CXXFLAGS="-O3 -pipe -fsigned-char"
603e (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fsigned-char"
CXXFLAGS="-O3 -pipe -fsigned-char"
604 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fsigned-char"
CXXFLAGS="-O3 -pipe -fsigned-char"
604e (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fsigned-char"
CXXFLAGS="-O3 -pipe -fsigned-char"
750 aka as G3 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-mcpu=750 -O3 -pipe -fsigned-char -mpowerpc-gfxopt"
CXXFLAGS="-mcpu=750 -O3 -pipe -fsigned-char -mpowerpc-gfxopt"
Nota: não use -march=
7400, aka G4 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-mcpu=7400 -O2 -pipe -fsigned-char -maltivec -mabi=altivec -mpowerpc-gfxopt"
CXXFLAGS="-mcpu=7400 -O2 -pipe -fsigned-char -maltivec -mabi=altivec -mpowerpc-gfxopt"
Nota: não use -march=
Nota: -O3 é instável no G4
7450, aka G4 second generation (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-mcpu=7450 -O2 -pipe -fsigned-char -maltivec -mabi=altivec -mpowerpc-gfxopt"
CXXFLAGS="-mcpu=7450 -O2 -pipe -fsigned-char -maltivec -mabi=altivec -mpowerpc-gfxopt"
Nota: não use -march=
Nota: -O3 é instável no G4
PowerPC (se você não sabe qual)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fsigned-char -mpowerpc-gfxopt"
CXXFLAGS="-O3 -pipe -fsigned-char -mpowerpc-gfxopt"
Sparc
CHOST="sparc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer"
Sparc 64
CHOST="sparc64-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer"
<< Início
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 "
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
Debian UML step-by-step
-----------------------------------
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
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
Setting up the host
Kernel Options
TUN/TAP
bridging
Skas Mode
tmpfs
Host configuration
Running UML
Get a root fs
starting it up
sans devfs
/etc/init.d/uml
Configuring Guest
configuring guest's network
basic stuff
Issues
HOSTFS
Links
How to set up several User Mode Linux instances running on one box each with a real external ip and access to the internet.
host: the real machine which will host the virtual user mode linuxes. In our example the real machine is ibis.riseup.net (216.162.217.194)
guest: the user mode linux (uml) running on the host. In our example, the uml is stork.riseup.net (216.162.217.193).
Setting up the host
Kernel Options
Assumes you run "make menuconfig"
TUN/TAP
choose "Universal TUN/TAP device driver support" under "Network Device Support"
This is needed to get virtual network between host and uml. there are other ways, but this is easiest. If run as module, then insmod on startup. Also, this works best with devfs installed too (actually, I can't get it to work otherwise, need to mknod something something.).
bridging
Choose "802.1d Ethernet Bridging" (in "Networking options")
Skas Mode
Skas mode is much faster than normal tt mode, but requires a patch in the host's kernel. If the host has the patch installed, then the UML will go into skas mode automatically.
The patch can be downloaded from the UML website's download section.
tmpfs
User Mode Linux createas a tmp file as big as the RAM you allocate the UML instance. It's placed in your environment's TMPDIR path. One useful strategy is to use the tempfs filesystem for your TMPDIR.
For example:
> mkdir /tmp/uml
> mount -t tmpfs -o mode=1777,size=512M none /tmp/uml
> TMPDIR=/tmp/uml linux mem=512M ...
or
/etc/fstab
tmpfs /tmp/uml tmpfs defaults,size=7168M 0 0
UML unlinks the tmp file right after creating it. So, an ls -al /tmp/uml is going to show an empty directory. Use "lsof" to check if it is used.
Host configuration
host> apt-get install bridge-utils uml-utilities user-mode-linux devfsd
host> useradd -m uml
host> chown root:uml /dev/net/tun
host> chmod 660 /dev/net/tun
note: do you need to add user 'uml' to group 'uml-net'?
create file host:/etc/init.d/bridge:
#!/bin/sh
# configuration
HOST_IP="216.162.217.194"
HOST_NETMASK="255.255.255.0"
HOST_GATEWAY="216.162.217.1"
HOST_IFACE="eth0"
case "$1" in
start)
echo -n "Setting up fancy dancy bridge networking"
ifconfig $HOST_IFACE 0.0.0.0 promisc up
brctl addbr umlbridge
brctl setfd umlbridge 0
brctl sethello umlbridge 0
brctl stp umlbridge off
ifconfig umlbridge $HOST_IP netmask $HOST_NETMASK up
route add default gw $HOST_GATEWAY
brctl addif umlbridge $HOST_IFACE
# first UML instance
tunctl -u uml -t tap0
ifconfig tap0 0.0.0.0 promisc up
brctl addif umlbridge tap0
# second UML instance
# tunctl -u uml -t tap1
# ifconfig tap1 0.0.0.0 promisc up
# brctl addif umlbridge tap1
# and so on...
echo "."
;;
stop)
echo -n "Stopping networking bridge"
# add more tab1,tab2, etc as needed
ifconfig umlbridge down
brctl delif umlbridge $HOST_IFACE
brctl delif umlbridge tab0
brctl delbr umlbridge
tunctl -d tab0
ifconfig $HOST_IFACE $HOST_IP netmask $HOST_NETMASK up
echo "."
;;
esac
exit 0
Do not put any networking stuff in host:/etc/network/interfaces. Instead, run this at startup (e.g. run rcconf to add this script to the boot sequence).
Running UML
Get a root fs
Here set up a folder for our virtual machine 'guest' and a root filesystem.
host> su uml
host> cd /home/uml
host> mkdir guest
host> cd guest
host> wget http://people.debian.org/~mdz/uml/Debian-3.0r0.ext2.bz2
host> bunzip2 Debian-3.0r0.ext2.bz2
make it bigger (512mb):
host> dd if=/dev/zero of=Debian-3.0r0.ext2 bs=1 count=0 seek=536870912
host> /sbin/e2fsck -f Debian-3.0r0.ext2
host> /sbin/resize2fs -p Debian-3.0r0.ext2
starting it up
host> su uml
host> cd /home/uml/guest
host> linux ubd0=Debian-3.0r0.ext2 devfs=mount
If something goes wrong, you can pass boot options to the linux command, like this:
host> linux ubd0=Debian-3.0r0.ext2 devfs=mount single
which will boot in single user mode.
Once that is working, try it with networking:
host> linux ubd0=Debian-3.0r0.ext2 devfs=mount eth0=tuntap,tap0
tap0 is the name of the tap device created in the bridge script by the command "tunctl -u uml -t tap0". If you have multiple umls, then you would have a unique tap device for each one.
Here is an example startup script:
NAME="stork"
TAP="tap0"
MYOPTIONS="mem=128M ubd1=disk2"
OPTIONS="$MYOPTIONS ubd0=root_fs devfs=mount eth0=tuntap,$TAP umid=$NAME"
case $1 in
"-d")
screen -S $NAME -d -m linux $OPTIONS con=null con0=fd:0,fd:1
echo "Starting machine $NAME..."
echo
echo "management console:"
echo " uml> uml_mconsole $NAME"
echo
echo "terminal console:"
echo " uml> screen -r $NAME"
;;
*)
linux $OPTIONS
;;
esac
sans devfs
The debian root filesystem image that is available from the package maintainer of uml uses devfs. If, for whatever reason, you don't want devfs in your uml, you can build your own root filesystem or modify it to remove devfs naming from the config files. To do this, boot your uml in single user mode and then edit guest:/etc/inittab and guest:/etc/fstab to be the non devfs form (ie ttys/0 becomes tty0, /dev/ubd/0 becomes /dev/ubd0, etc).
/etc/init.d/uml
Here is an example uml startup script:
GUESTS='stork egret'
UML_USER='uml'
if [[ ! -z $2 ]]; then
GUESTS=$2
fi
case "$1" in
start)
for host in $GUESTS; do
if [[ ! -e /home/$UML_USER/.uml/$host ]]; then
echo "Starting $host..."
cd /home/$UML_USER/$host
su $UML_USER -c "./start -d" > /dev/null
echo " done"
else
echo "$host is already running"
fi
done
;;
stop)
for host in $GUESTS; do
echo "Stopping $host..."
if [[ -e /home/$UML_USER/.uml/$host/mconsole ]]; then
su $UML_USER -c "uml_mconsole $host sysrq s; uml_mconsole $host sysrq u; uml_mconsole $host sysrq e; uml_mconsole $host halt"
echo " done.";
else
echo " error: file not found /home/$UML_USER/.uml/$host/mconsole"
fi
done
sleep 4 # not sure if the uml_mconsole commands wait until completed before they return.
;;
restart)
echo "not supported";
;;
*)
echo "Usage: $0 {start|stop} {machine}" >&2
exit 1
;;
esac
exit 0
Configuring Guest
When you boot up, things are pretty minimal. Login as root.
Guest sample configuration:
hostname: stork
ip address: 216.162.217.193
configuring guest's network
edit /etc/network/interfaces:
auto lo
iface lo inet loopback
# eth0
auto eth0
iface eth0 inet static
address 216.162.217.193
netmask 255.255.255.0
network 216.162.217.0
broadcast 216.162.217.255
gateway 216.162.217.1
Then bring it up:
guest> ifup eth0
You should now be connected to the internet like any other machine. Note that this is funky, because the guest machine got to pick its own IP address. Supposedly, here is how to prevent this:
ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
basic stuff
Set a hostname:
guest> echo stork > /etc/hostname
guest> hostname stork
get some packages:
guest> apt-get update
guest> apt-get install ssh less
Issues
HOSTFS
We don't want the UML virtual machine to be able to mount the host's filesystem, so that means we can't compile hostfs support into the UML Kernel. Unfortunately, someone could still compile and install hostfs support as a kernel module, so that means we must build our UML Kernel without module support.
Links
www.theshore.net/~caker/uml/
<< Início
Usando o UML no Debian (Criando Root_FS Woody)
Kernel Options
TUN/TAP
bridging
Skas Mode
tmpfs
Host configuration
Running UML
Get a root fs
starting it up
sans devfs
/etc/init.d/uml
Configuring Guest
configuring guest's network
basic stuff
Issues
HOSTFS
Links
How to set up several User Mode Linux instances running on one box each with a real external ip and access to the internet.
host: the real machine which will host the virtual user mode linuxes. In our example the real machine is ibis.riseup.net (216.162.217.194)
guest: the user mode linux (uml) running on the host. In our example, the uml is stork.riseup.net (216.162.217.193).
Setting up the host
Kernel Options
Assumes you run "make menuconfig"
TUN/TAP
choose "Universal TUN/TAP device driver support" under "Network Device Support"
This is needed to get virtual network between host and uml. there are other ways, but this is easiest. If run as module, then insmod on startup. Also, this works best with devfs installed too (actually, I can't get it to work otherwise, need to mknod something something.).
bridging
Choose "802.1d Ethernet Bridging" (in "Networking options")
Skas Mode
Skas mode is much faster than normal tt mode, but requires a patch in the host's kernel. If the host has the patch installed, then the UML will go into skas mode automatically.
The patch can be downloaded from the UML website's download section.
tmpfs
User Mode Linux createas a tmp file as big as the RAM you allocate the UML instance. It's placed in your environment's TMPDIR path. One useful strategy is to use the tempfs filesystem for your TMPDIR.
For example:
> mkdir /tmp/uml
> mount -t tmpfs -o mode=1777,size=512M none /tmp/uml
> TMPDIR=/tmp/uml linux mem=512M ...
or
/etc/fstab
tmpfs /tmp/uml tmpfs defaults,size=7168M 0 0
UML unlinks the tmp file right after creating it. So, an ls -al /tmp/uml is going to show an empty directory. Use "lsof" to check if it is used.
Host configuration
host> apt-get install bridge-utils uml-utilities user-mode-linux devfsd
host> useradd -m uml
host> chown root:uml /dev/net/tun
host> chmod 660 /dev/net/tun
note: do you need to add user 'uml' to group 'uml-net'?
create file host:/etc/init.d/bridge:
#!/bin/sh
# configuration
HOST_IP="216.162.217.194"
HOST_NETMASK="255.255.255.0"
HOST_GATEWAY="216.162.217.1"
HOST_IFACE="eth0"
case "$1" in
start)
echo -n "Setting up fancy dancy bridge networking"
ifconfig $HOST_IFACE 0.0.0.0 promisc up
brctl addbr umlbridge
brctl setfd umlbridge 0
brctl sethello umlbridge 0
brctl stp umlbridge off
ifconfig umlbridge $HOST_IP netmask $HOST_NETMASK up
route add default gw $HOST_GATEWAY
brctl addif umlbridge $HOST_IFACE
# first UML instance
tunctl -u uml -t tap0
ifconfig tap0 0.0.0.0 promisc up
brctl addif umlbridge tap0
# second UML instance
# tunctl -u uml -t tap1
# ifconfig tap1 0.0.0.0 promisc up
# brctl addif umlbridge tap1
# and so on...
echo "."
;;
stop)
echo -n "Stopping networking bridge"
# add more tab1,tab2, etc as needed
ifconfig umlbridge down
brctl delif umlbridge $HOST_IFACE
brctl delif umlbridge tab0
brctl delbr umlbridge
tunctl -d tab0
ifconfig $HOST_IFACE $HOST_IP netmask $HOST_NETMASK up
echo "."
;;
esac
exit 0
Do not put any networking stuff in host:/etc/network/interfaces. Instead, run this at startup (e.g. run rcconf to add this script to the boot sequence).
Running UML
Get a root fs
Here set up a folder for our virtual machine 'guest' and a root filesystem.
host> su uml
host> cd /home/uml
host> mkdir guest
host> cd guest
host> wget http://people.debian.org/~mdz/uml/Debian-3.0r0.ext2.bz2
host> bunzip2 Debian-3.0r0.ext2.bz2
make it bigger (512mb):
host> dd if=/dev/zero of=Debian-3.0r0.ext2 bs=1 count=0 seek=536870912
host> /sbin/e2fsck -f Debian-3.0r0.ext2
host> /sbin/resize2fs -p Debian-3.0r0.ext2
starting it up
host> su uml
host> cd /home/uml/guest
host> linux ubd0=Debian-3.0r0.ext2 devfs=mount
If something goes wrong, you can pass boot options to the linux command, like this:
host> linux ubd0=Debian-3.0r0.ext2 devfs=mount single
which will boot in single user mode.
Once that is working, try it with networking:
host> linux ubd0=Debian-3.0r0.ext2 devfs=mount eth0=tuntap,tap0
tap0 is the name of the tap device created in the bridge script by the command "tunctl -u uml -t tap0". If you have multiple umls, then you would have a unique tap device for each one.
Here is an example startup script:
NAME="stork"
TAP="tap0"
MYOPTIONS="mem=128M ubd1=disk2"
OPTIONS="$MYOPTIONS ubd0=root_fs devfs=mount eth0=tuntap,$TAP umid=$NAME"
case $1 in
"-d")
screen -S $NAME -d -m linux $OPTIONS con=null con0=fd:0,fd:1
echo "Starting machine $NAME..."
echo
echo "management console:"
echo " uml> uml_mconsole $NAME"
echo
echo "terminal console:"
echo " uml> screen -r $NAME"
;;
*)
linux $OPTIONS
;;
esac
sans devfs
The debian root filesystem image that is available from the package maintainer of uml uses devfs. If, for whatever reason, you don't want devfs in your uml, you can build your own root filesystem or modify it to remove devfs naming from the config files. To do this, boot your uml in single user mode and then edit guest:/etc/inittab and guest:/etc/fstab to be the non devfs form (ie ttys/0 becomes tty0, /dev/ubd/0 becomes /dev/ubd0, etc).
/etc/init.d/uml
Here is an example uml startup script:
GUESTS='stork egret'
UML_USER='uml'
if [[ ! -z $2 ]]; then
GUESTS=$2
fi
case "$1" in
start)
for host in $GUESTS; do
if [[ ! -e /home/$UML_USER/.uml/$host ]]; then
echo "Starting $host..."
cd /home/$UML_USER/$host
su $UML_USER -c "./start -d" > /dev/null
echo " done"
else
echo "$host is already running"
fi
done
;;
stop)
for host in $GUESTS; do
echo "Stopping $host..."
if [[ -e /home/$UML_USER/.uml/$host/mconsole ]]; then
su $UML_USER -c "uml_mconsole $host sysrq s; uml_mconsole $host sysrq u; uml_mconsole $host sysrq e; uml_mconsole $host halt"
echo " done.";
else
echo " error: file not found /home/$UML_USER/.uml/$host/mconsole"
fi
done
sleep 4 # not sure if the uml_mconsole commands wait until completed before they return.
;;
restart)
echo "not supported";
;;
*)
echo "Usage: $0 {start|stop} {machine}" >&2
exit 1
;;
esac
exit 0
Configuring Guest
When you boot up, things are pretty minimal. Login as root.
Guest sample configuration:
hostname: stork
ip address: 216.162.217.193
configuring guest's network
edit /etc/network/interfaces:
auto lo
iface lo inet loopback
# eth0
auto eth0
iface eth0 inet static
address 216.162.217.193
netmask 255.255.255.0
network 216.162.217.0
broadcast 216.162.217.255
gateway 216.162.217.1
Then bring it up:
guest> ifup eth0
You should now be connected to the internet like any other machine. Note that this is funky, because the guest machine got to pick its own IP address. Supposedly, here is how to prevent this:
ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
basic stuff
Set a hostname:
guest> echo stork > /etc/hostname
guest> hostname stork
get some packages:
guest> apt-get update
guest> apt-get install ssh less
Issues
HOSTFS
We don't want the UML virtual machine to be able to mount the host's filesystem, so that means we can't compile hostfs support into the UML Kernel. Unfortunately, someone could still compile and install hostfs support as a kernel module, so that means we must build our UML Kernel without module support.
Links
www.theshore.net/~caker/uml/
<< Início
Running Debian inside of Debian with User-Mode Linux
You can find the newest version of this text on http://www.eggdrop.ch/texts/uml/index.htm.
23.07.04: Version 1.0
Introduction
This text describes how to install Debian GNU/Linux (http://www.debian.org) inside of itself with User-Mode Linux (http://user-mode-linux.sourceforge.net/).
Contents:
Preparing the host system
Creating the UML machine
Links
Preparing the host system
You don't need to download UML from http://user-mode-linux.sourceforge.net/ because it's in APT:
# apt-get install wget user-mode-linux uml-utilities bridge-utils debootstrap realpath
Make sure you have the following options set in the kernel:
CONFIG_TUN
CONFIG_BRIDGE
CONFIG_BLK_DEV_LOOP
Create a new user uml and add it to the group uml-net (the group should be already created). Make sure this user can write to /dev/net/tun:
# adduser uml
# adduser uml uml-net
# chgrp uml-net /dev/net/tun
# chmod 660 /dev/net/tun
You can use the following script to set up networking on the host (download: uml-bridge) - the script is basically from [1]:
#!/bin/sh
# your IP address
HOST_IP="192.168.0.3"
# netmask
HOST_NETMASK="255.255.255.0"
# your internet gateway
HOST_GATEWAY="192.168.0.1"
# internet interface
HOST_IFACE="eth0"
# name of the bridge
UML_BRIDGE="br0"
# the syntax of UML_IFACES is as follows:
# UML_IFACES=":[ :[...]]"
#
# for instance you have two UMLs, the first runs as user 'tom'
# and the second as 'uml':
# UML_IFACES="tap1:tom tap2:uml"
UML_IFACES="tap1:uml"
###############
if [ "x$1" = "x-v" ]; then
VERBOSE=1
shift
else
VERBOSE=0
fi
e() { test $VERBOSE = 1 && echo $@; $@; }
case "$1" in
start)
echo -n "Setting up UML bridge"
test $VERBOSE = 1 && echo
# set up the bridge
e ifconfig $HOST_IFACE 0.0.0.0 promisc up
e brctl addbr $UML_BRIDGE
e brctl setfd $UML_BRIDGE 0
e brctl sethello $UML_BRIDGE 0
e brctl stp $UML_BRIDGE off
# add the host interface
e ifconfig $UML_BRIDGE $HOST_IP netmask $HOST_NETMASK up
e route add default gw $HOST_GATEWAY
e brctl addif $UML_BRIDGE $HOST_IFACE
# and the UML interface(s)
for ITMP in $UML_IFACES; do
IFACE=`echo $ITMP | cut -d ':' -f 1`
IUSER=`echo $ITMP | cut -d ':' -f 2`
test `echo $ITMP | grep ':'` || IUSER=root
e tunctl -u $IUSER -t $IFACE > /dev/null
e ifconfig $IFACE 0.0.0.0 promisc up
e brctl addif $UML_BRIDGE $IFACE
echo -n " $IFACE"
done
echo "."
;;
stop)
echo -n "Removing UML bridge"
test $VERBOSE = 1 && echo
e ifconfig $UML_BRIDGE down
e brctl delif $UML_BRIDGE $HOST_IFACE
for ITMP in $UML_IFACES; do
IFACE=`echo $ITMP | cut -d ':' -f 1`
e brctl delif $UML_BRIDGE $IFACE
e tunctl -d $IFACE > /dev/null
echo -n " $IFACE"
done
e brctl delbr $UML_BRIDGE
e ifconfig $HOST_IFACE $HOST_IP netmask $HOST_NETMASK up
e route add default gw $HOST_GATEWAY
echo "."
;;
reload | force-reload | restart)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}"
esac
Remember to adjust the settings at the beginning of the script. Put the script into /etc/init.d/uml-bridge or something similar and run it:
# /etc/init.d/uml-bridge start
Setting up UML bridge tap1.
If you get some errors, try to run the script with the -v option.
To set up the bridge automatically at startup, you have to create some symlinks:
ln -s /etc/init.d/uml-bridge /etc/rc0.d/K99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc1.d/K99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc2.d/S99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc3.d/S99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc4.d/S99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc5.d/S99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc6.d/K99uml-bridge
Creating the UML machine
Now let's create a UML machine. I made the following shell script (download: create_uml):
#!/bin/sh
### functions
f() { echo "Failed."; exit; }
setup_net()
{
echo "Configuring network"
while :; do
echo -n "IP address of the UML machine (e.g. 192.168.0.100) > "
read nw_ip
if [ "x$nw_ip" != "x" ]; then
break
fi
done
while :; do
echo -n "Network (e.g. 192.168.0.0) > "
read nw_network
if [ "x$nw_network" != "x" ]; then
break
fi
done
while :; do
echo -n "Broadcast address (e.g. 192.168.0.255) > "
read nw_bcast
if [ "x$nw_bcast" != "x" ]; then
break
fi
done
while :; do
echo -n "Netmask (e.g. 255.255.255.0) > "
read nw_netmask
if [ "x$nw_netmask" != "x" ]; then
break
fi
done
while :; do
echo -n "Your internet gateway (e.g. 192.168.0.1) > "
read nw_gw
if [ "x$nw_gw" != "x" ]; then
break
fi
done
while :; do
echo -n "Host interface (e.g. tap1) > "
read nw_if
if [ "x$nw_if" != "x" ]; then
break
fi
done
echo ""
echo "You entered:"
echo " IP address: $nw_ip"
echo " Network: $nw_network"
echo " Broadcast address: $nw_bcast"
echo " Netmask: $nw_netmask"
echo " Gateway: $nw_gw"
echo " Host interface: $nw_if"
while :; do
echo -n "Is this correct? [y/n]: "
read nw_ok
case "$nw_ok" in
y | yes)
break
;;
n | no)
setup_net
return
break
;;
*)
echo "Please enter 'y' or 'n'"
esac
done
}
### our script begins here
if [ "`id -u`" != "0" ]; then
echo "I won't run as user. I need root."
exit 1
fi
if [ "x$1" = "x" ]; then
echo "Enter the name of the UML machine or press CTRL+C to abort:"
echo -n "> "
read name
fi
if [ "x$name" = "x" ]; then
echo "Aborting."
exit 1
fi
echo
echo ==============================
echo Downloading Debian base system
echo ==============================
echo
if [ -f "basedebs.tar" ]; then
echo "The base system seems to be already downloaded. Skipping."
else
wget --passive-ftp ftp://ftp.debian.org/debian/dists/woody/main/disks-i386/base-images-current/basedebs.tar || f
fi
echo
echo ==============================
echo Creating file system
echo ==============================
echo
if [ "x$1" = "x" ]; then
echo "Enter the size of your root partition in MB"
echo -n "> "
read size
fi
if [ "x$size" = "x" ]; then
echo "Aborting."
exit 1
fi
mkdir $name || f
# print this so the user does not think that the script is hanging
echo dd if=/dev/zero of=$name/root_fs count=$size bs=1M
dd if=/dev/zero of=$name/root_fs count=$size bs=1M || f
/sbin/mke2fs -F $name/root_fs || f
mkdir $name/install || f
mount -o loop $name/root_fs $name/install || f
echo
echo ==============================
echo Installing the base system
echo ==============================
echo
debootstrap --unpack-tarball `realpath basedebs.tar` woody $name/install || f
echo
echo ==============================
echo Configuring the base system
echo ==============================
echo
echo '# /etc/fstab: static file system information.
#
#
/dev/ubd0 / ext2 defaults 0 0
proc /proc proc defaults 0 0' \
> $name/install/etc/fstab
echo '# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $
# The default runlevel.
id:2:initdefault:
# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS
# What to do in single-user mode.
~~:S:wait:/sbin/sulogin
# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
# Action on special keypress (ALT-UpArrow).
#kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work."
# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop
# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
#:::
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty'\''s go ahead but skip tty7 if you run X.
#
0:1235:respawn:/sbin/getty 38400 console linux
#1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6
# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
# Example how to put a getty on a modem line.
#
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3' > $name/install/etc/inittab
echo $name > $name/install/etc/hostname
# set up apt
cp /etc/apt/sources.list $name/install/etc/apt/sources.list || f
# install SSH
while :; do
echo -n "Do you want to install SSH? [y/n]: "
read nw_config
case "$nw_config" in
y | yes)
chroot $name/install apt-get -y update || f
chroot $name/install apt-get -y install ssh || f
break
;;
n | no)
break
;;
*)
echo "Please enter 'y' or 'n'"
esac
done
# network
while :; do
echo -n "Do you want to configure the network? [y/n]: "
read nw_config
case "$nw_config" in
y | yes)
nw_config=1
break
;;
n | no)
nw_config=0
break
;;
*)
echo "Please enter 'y' or 'n'"
esac
done
if [ "$nw_config" = "1" ]; then
setup_net
echo '# Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
# /usr/share/doc/ifupdown/examples for more information.
auto lo
iface lo inet loopback
# eth0
auto eth0
iface eth0 inet static
address '$nw_ip'
netmask '$nw_netmask'
network '$nw_network'
broadcast '$nw_bcast'
gateway '$nw_gw > $name/install/etc/network/interfaces
fi
# clean up
umount $name/install
rmdir $name/install
echo
echo ==============================
echo Creating start script
echo ==============================
echo
while :; do
echo -n "Enter the amount of memory for the UML machine in MB: "
read mem
test $mem && break
done
if [ "$nw_config" = "1" ]; then
echo '#!/bin/sh
MEMORY="'$mem'M"
HOST_IFACE="'$nw_if'"
linux mem=$MEMORY eth0=tuntap,$HOST_IFACE' > $name/run
else
echo '#!/bin/sh
MEMORY="'$mem'M"
linux mem=$MEMORY' > $name/run
fi
chmod +x $name/run
echo
echo ==============================
echo Finished
echo ==============================
echo
echo To launch UML, type:
echo cd $name
echo ./run
echo
echo Have a lot of fun!
echo
Run this script as root and follow the instructions (or type in the commands by hand: see [2], how to create the image). You need at least ~ 150 MB space for the root partition.
After launching the UML (cd && ./run), it should be possible to log in through SSH:
ssh root@ip.address.of.uml
If you have any problems, try to search the internet.
Have a lot of fun!
Links
Here are some useful links:
[1] http://deb.riseup.net/miscellaneous/uml/
[2] http://www.huckstep.uklinux.net/mle/uml-woody.html
--------------------------------------------------------------------------------
Zurück zu www.eggdrop.ch | Back to www.eggdrop.ch
Last update: 23.07.04
Copyright (C) 2004 by Thomas "tom" S.
This work belongs to http://www.eggdrop.ch/ and is licensed under a Creative Commons License.
Link Original http://www.eggdrop.ch/texts/uml/index.htm
<< Início
Policy Routing IPFILTER FreeBSD
You can find the newest version of this text on http://www.eggdrop.ch/texts/uml/index.htm.
23.07.04: Version 1.0
Introduction
This text describes how to install Debian GNU/Linux (http://www.debian.org) inside of itself with User-Mode Linux (http://user-mode-linux.sourceforge.net/).
Contents:
Preparing the host system
Creating the UML machine
Links
Preparing the host system
You don't need to download UML from http://user-mode-linux.sourceforge.net/ because it's in APT:
# apt-get install wget user-mode-linux uml-utilities bridge-utils debootstrap realpath
Make sure you have the following options set in the kernel:
CONFIG_TUN
CONFIG_BRIDGE
CONFIG_BLK_DEV_LOOP
Create a new user uml and add it to the group uml-net (the group should be already created). Make sure this user can write to /dev/net/tun:
# adduser uml
# adduser uml uml-net
# chgrp uml-net /dev/net/tun
# chmod 660 /dev/net/tun
You can use the following script to set up networking on the host (download: uml-bridge) - the script is basically from [1]:
#!/bin/sh
# your IP address
HOST_IP="192.168.0.3"
# netmask
HOST_NETMASK="255.255.255.0"
# your internet gateway
HOST_GATEWAY="192.168.0.1"
# internet interface
HOST_IFACE="eth0"
# name of the bridge
UML_BRIDGE="br0"
# the syntax of UML_IFACES is as follows:
# UML_IFACES="
#
# for instance you have two UMLs, the first runs as user 'tom'
# and the second as 'uml':
# UML_IFACES="tap1:tom tap2:uml"
UML_IFACES="tap1:uml"
###############
if [ "x$1" = "x-v" ]; then
VERBOSE=1
shift
else
VERBOSE=0
fi
e() { test $VERBOSE = 1 && echo $@; $@; }
case "$1" in
start)
echo -n "Setting up UML bridge"
test $VERBOSE = 1 && echo
# set up the bridge
e ifconfig $HOST_IFACE 0.0.0.0 promisc up
e brctl addbr $UML_BRIDGE
e brctl setfd $UML_BRIDGE 0
e brctl sethello $UML_BRIDGE 0
e brctl stp $UML_BRIDGE off
# add the host interface
e ifconfig $UML_BRIDGE $HOST_IP netmask $HOST_NETMASK up
e route add default gw $HOST_GATEWAY
e brctl addif $UML_BRIDGE $HOST_IFACE
# and the UML interface(s)
for ITMP in $UML_IFACES; do
IFACE=`echo $ITMP | cut -d ':' -f 1`
IUSER=`echo $ITMP | cut -d ':' -f 2`
test `echo $ITMP | grep ':'` || IUSER=root
e tunctl -u $IUSER -t $IFACE > /dev/null
e ifconfig $IFACE 0.0.0.0 promisc up
e brctl addif $UML_BRIDGE $IFACE
echo -n " $IFACE"
done
echo "."
;;
stop)
echo -n "Removing UML bridge"
test $VERBOSE = 1 && echo
e ifconfig $UML_BRIDGE down
e brctl delif $UML_BRIDGE $HOST_IFACE
for ITMP in $UML_IFACES; do
IFACE=`echo $ITMP | cut -d ':' -f 1`
e brctl delif $UML_BRIDGE $IFACE
e tunctl -d $IFACE > /dev/null
echo -n " $IFACE"
done
e brctl delbr $UML_BRIDGE
e ifconfig $HOST_IFACE $HOST_IP netmask $HOST_NETMASK up
e route add default gw $HOST_GATEWAY
echo "."
;;
reload | force-reload | restart)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}"
esac
Remember to adjust the settings at the beginning of the script. Put the script into /etc/init.d/uml-bridge or something similar and run it:
# /etc/init.d/uml-bridge start
Setting up UML bridge tap1.
If you get some errors, try to run the script with the -v option.
To set up the bridge automatically at startup, you have to create some symlinks:
ln -s /etc/init.d/uml-bridge /etc/rc0.d/K99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc1.d/K99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc2.d/S99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc3.d/S99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc4.d/S99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc5.d/S99uml-bridge
ln -s /etc/init.d/uml-bridge /etc/rc6.d/K99uml-bridge
Creating the UML machine
Now let's create a UML machine. I made the following shell script (download: create_uml):
#!/bin/sh
### functions
f() { echo "Failed."; exit; }
setup_net()
{
echo "Configuring network"
while :; do
echo -n "IP address of the UML machine (e.g. 192.168.0.100) > "
read nw_ip
if [ "x$nw_ip" != "x" ]; then
break
fi
done
while :; do
echo -n "Network (e.g. 192.168.0.0) > "
read nw_network
if [ "x$nw_network" != "x" ]; then
break
fi
done
while :; do
echo -n "Broadcast address (e.g. 192.168.0.255) > "
read nw_bcast
if [ "x$nw_bcast" != "x" ]; then
break
fi
done
while :; do
echo -n "Netmask (e.g. 255.255.255.0) > "
read nw_netmask
if [ "x$nw_netmask" != "x" ]; then
break
fi
done
while :; do
echo -n "Your internet gateway (e.g. 192.168.0.1) > "
read nw_gw
if [ "x$nw_gw" != "x" ]; then
break
fi
done
while :; do
echo -n "Host interface (e.g. tap1) > "
read nw_if
if [ "x$nw_if" != "x" ]; then
break
fi
done
echo ""
echo "You entered:"
echo " IP address: $nw_ip"
echo " Network: $nw_network"
echo " Broadcast address: $nw_bcast"
echo " Netmask: $nw_netmask"
echo " Gateway: $nw_gw"
echo " Host interface: $nw_if"
while :; do
echo -n "Is this correct? [y/n]: "
read nw_ok
case "$nw_ok" in
y | yes)
break
;;
n | no)
setup_net
return
break
;;
*)
echo "Please enter 'y' or 'n'"
esac
done
}
### our script begins here
if [ "`id -u`" != "0" ]; then
echo "I won't run as user. I need root."
exit 1
fi
if [ "x$1" = "x" ]; then
echo "Enter the name of the UML machine or press CTRL+C to abort:"
echo -n "> "
read name
fi
if [ "x$name" = "x" ]; then
echo "Aborting."
exit 1
fi
echo
echo ==============================
echo Downloading Debian base system
echo ==============================
echo
if [ -f "basedebs.tar" ]; then
echo "The base system seems to be already downloaded. Skipping."
else
wget --passive-ftp ftp://ftp.debian.org/debian/dists/woody/main/disks-i386/base-images-current/basedebs.tar || f
fi
echo
echo ==============================
echo Creating file system
echo ==============================
echo
if [ "x$1" = "x" ]; then
echo "Enter the size of your root partition in MB"
echo -n "> "
read size
fi
if [ "x$size" = "x" ]; then
echo "Aborting."
exit 1
fi
mkdir $name || f
# print this so the user does not think that the script is hanging
echo dd if=/dev/zero of=$name/root_fs count=$size bs=1M
dd if=/dev/zero of=$name/root_fs count=$size bs=1M || f
/sbin/mke2fs -F $name/root_fs || f
mkdir $name/install || f
mount -o loop $name/root_fs $name/install || f
echo
echo ==============================
echo Installing the base system
echo ==============================
echo
debootstrap --unpack-tarball `realpath basedebs.tar` woody $name/install || f
echo
echo ==============================
echo Configuring the base system
echo ==============================
echo
echo '# /etc/fstab: static file system information.
#
#
/dev/ubd0 / ext2 defaults 0 0
proc /proc proc defaults 0 0' \
> $name/install/etc/fstab
echo '# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $
# The default runlevel.
id:2:initdefault:
# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS
# What to do in single-user mode.
~~:S:wait:/sbin/sulogin
# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
# Action on special keypress (ALT-UpArrow).
#kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work."
# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop
# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
#
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty'\''s go ahead but skip tty7 if you run X.
#
0:1235:respawn:/sbin/getty 38400 console linux
#1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6
# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
# Example how to put a getty on a modem line.
#
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3' > $name/install/etc/inittab
echo $name > $name/install/etc/hostname
# set up apt
cp /etc/apt/sources.list $name/install/etc/apt/sources.list || f
# install SSH
while :; do
echo -n "Do you want to install SSH? [y/n]: "
read nw_config
case "$nw_config" in
y | yes)
chroot $name/install apt-get -y update || f
chroot $name/install apt-get -y install ssh || f
break
;;
n | no)
break
;;
*)
echo "Please enter 'y' or 'n'"
esac
done
# network
while :; do
echo -n "Do you want to configure the network? [y/n]: "
read nw_config
case "$nw_config" in
y | yes)
nw_config=1
break
;;
n | no)
nw_config=0
break
;;
*)
echo "Please enter 'y' or 'n'"
esac
done
if [ "$nw_config" = "1" ]; then
setup_net
echo '# Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
# /usr/share/doc/ifupdown/examples for more information.
auto lo
iface lo inet loopback
# eth0
auto eth0
iface eth0 inet static
address '$nw_ip'
netmask '$nw_netmask'
network '$nw_network'
broadcast '$nw_bcast'
gateway '$nw_gw > $name/install/etc/network/interfaces
fi
# clean up
umount $name/install
rmdir $name/install
echo
echo ==============================
echo Creating start script
echo ==============================
echo
while :; do
echo -n "Enter the amount of memory for the UML machine in MB: "
read mem
test $mem && break
done
if [ "$nw_config" = "1" ]; then
echo '#!/bin/sh
MEMORY="'$mem'M"
HOST_IFACE="'$nw_if'"
linux mem=$MEMORY eth0=tuntap,$HOST_IFACE' > $name/run
else
echo '#!/bin/sh
MEMORY="'$mem'M"
linux mem=$MEMORY' > $name/run
fi
chmod +x $name/run
echo
echo ==============================
echo Finished
echo ==============================
echo
echo To launch UML, type:
echo cd $name
echo ./run
echo
echo Have a lot of fun!
echo
Run this script as root and follow the instructions (or type in the commands by hand: see [2], how to create the image). You need at least ~ 150 MB space for the root partition.
After launching the UML (cd
ssh root@ip.address.of.uml
If you have any problems, try to search the internet.
Have a lot of fun!
Links
Here are some useful links:
[1] http://deb.riseup.net/miscellaneous/uml/
[2] http://www.huckstep.uklinux.net/mle/uml-woody.html
--------------------------------------------------------------------------------
Zurück zu www.eggdrop.ch | Back to www.eggdrop.ch
Last update: 23.07.04
Copyright (C) 2004 by Thomas "tom" S.
This work belongs to http://www.eggdrop.ch/ and is licensed under a Creative Commons License.
Link Original http://www.eggdrop.ch/texts/uml/index.htm
<< Início
BSDnews
Issue #1?May 15, 2003
Home Issue #1 Archives About Contribute Guidelines Contact RSS Policy Routing with IPFilter on FreeBSD
by Alex Popa
Policy Routing
Policy routing is the process of forcing packets to take a certain route, often different from the default route, based on certain packet attributes (source, type of packets, interface, etc.).
The need for policy routing arises for multi-homed hosts (hosts having two network connections to different ISPs), that cannot use a single default route. Having a central Internet connection for multiple private networks can require policy routing. It is most useful in case you have multiple networks connected behind a FreeBSD host with more than one connection to the Internet, when each network needs to use a different outgoing route.
Also, policy routing should be employed when you need to separate traffic by certain criteria, such as source, destination or protocol
When Not to Use Policy Routing
Policy routing can be extremely useful, but it is not always needed. A frequent case of misuse is when configuring a tunnel as a default route. Instead of using the first gateway as the default, then injecting all the other traffic in the tunnel, use more specific routes. For example, if the tunnel ends at 10.10.10.10, the ip of the other end inside the tunnel is 1.2.3.4, and the gateway your provider gave you (and don't actually want to use) is at 2.2.2.2, you can use these routes in /etc/rc.conf:
static_routes=?tunnel_end?
route_tunnel_end=?-host 10.10.10.10 2.2.2.2?
defaultrouter=?1.2.3.4?Since policy routing does involve a certain overhead on the system, do think of a different solution first. Specific routes can be very useful, but policy routing is the only solution for certain cases.
Configuring Policy Routing
The easiest way of doing policy routing with FreeBSD is by using IPFilter. It comes by default with all recent versions of FreeBSD, and it can be easily enabled by adding this line to /etc/rc.conf:
ipfilter_enable=?YES?Be advised that the IP addresses used in this article are fictional, and I have mixed public IP addresses with private ones (see RFC1918). You might find those in private networks, but they will almost never be assigned to you by an ISP.
Example 1 - Multi-homed Host
Suppose you have a host that is connected to two networks, via two interfaces: fxp0, with an IP address of 192.168.100.100, and fxp1, with an IP address of 192.168.200.200, both with the default classful netmask of 255.255.255.0. On both those networks, the gateways are located at 192.168.*.1. I'll assume that the default route is out fxp0.
Now suppose the host receives a ping (an ICMP echo request packet) from host 1.1.1.1, to its IP address 192.168.200.200. The reply will be generated with a source address of 192.168.200.200, and sent to 1.1.1.1. But if the host has no specific route to 1.1.1.1, it will use the default route out fxp0, and try to send the reply via the gateway at 192.168.100.1. If a stateful firewall is in place on the gateway, the packet will most probably be dropped, as the request came via the other gateway (in the 200 network). Also, if egress filtering (filtering of outbound traffic) is configured on the 100 network gateway, the reply will be blocked because it is coming from a different network (and possibly logged as a spoofing attempt). This will also affect other types of packets, like TCP and UDP.
The solution for this problem is rather simple: use policy routing to force packets from the 192.168.200.200 address to leave via the network they belong to. This is line in /etc/ipf.rules will do just as I have described:
pass out quick on fxp0 to fxp1:192.168.200.1 from 192.168.200.200 to any This rule says ?force packets from my fxp1 address to exit via the gateway on fxp1 (not my default gateway on fxp0)?.
Example 2 - Asymmetric Traffic
This is similar to Example 1, but with a different purpose. Let's assume that one of the links, fxp0, is an ADSL link with a static IP address. The fxp1 link is a cable modem, with a dynamic IP. You want to have a web server, so you put it on the static IP. But the cable link has better bandwidth, so you want to take advantage of that.
Web traffic in inherently asymmetric, with a small request from the client to the server, and a larger reply from the server to the client. So receiving the request on the ADSL link will not hurt, and it has the added benefit of having a static IP address. So you decide to send the replies via the bigger bandwidth link.
What you need to do is allow requests to the web server on your static IP address to come in via the ADSL link, but policy route the reply, diverting it to the cable link. Here is a configuration that does that:
pass in quick on fxp0 proto tcp from any to 192.168.100.100
pass out quick on fxp0 to fxp1:192.168.200.1 proto tcp from 192.168.100.100 port = 80 to any The gateway on fxp1 (192.168.200.1 in this example) is assigned by DHCP, and you can find it out by running this command:
# grep routers /var/db/dhclient.leasesThis will not work if your ISP on the cable link implements egress filtering. For a web request to complete successfully, the reply must come from the host the request went to. Since you will be sending the reply via another link (possibly belonging to a different ISP than the one who owns the fixed IP address), the cable ISP might choose not to forward your packets, and make this setup inoperable.
Example 3 - Routing for Multiple Networks
Another scenario is a network that has access to two different ISPs, and has assigned addresses from each of those. The interfaces connecting to those ISPs are fxp0 at 10.0.0.2, using the gateway at 10.0.0.1, and fxp1 at 20.0.0.2, using the gateway at 20.0.0.1. The networks assigned by those two ISPs are 192.168.100.0/24, and 192.168.200.0/24. Traffic originating from the 100 network belongs to the 10.0.0.1 ISP, and the other network to the 20.0.0.1 ISP. The interfaces connecting those two nets are de0 and de1.
This needs a simple configuration in /etc/ipf.rules. But we do have to take care and not shoot packets out to the ISP that are intended for the FreeBSD machine (which we'll suppose is at .254 on both those networks).
# accept packets to us, don't forward them
pass in quick on de0 from 192.168.100.0/24 to 192.168.100.254
pass in quick on de1 from 192.168.200.0/24 to 192.168.200.254
# other packets should be handled by their respective ISP
# ISP1
pass in quick on de0 to fxp0:10.0.0.1 from 192.168.100.0/24 to any
# ISP2
pass in quick on de1 to fxp1:20.0.0.1 from 192.168.200.0/24 to anyAdditional Resources
Egress filtering - Keeping the Internet Safe from Your Systems
Anatomy of a Stateful Firewall
- Alex
Alexandru Popa is a CCNA studying for a CCNP, and is actively involved in the FreeBSD community in his spare time. He also maintains cvsup.ro.freebsd.org out of a basement in a deserted building, using a large hamster array for power.
Copyright © 2003, BSDnews. All rights reserved.
Graciously hosted by LayeredTech.com
Link Original: http://www.bsdnews.org/01/policy_routing.php
<< Início
Issue #1?May 15, 2003
Home Issue #1 Archives About Contribute Guidelines Contact RSS Policy Routing with IPFilter on FreeBSD
by Alex Popa
Policy Routing
Policy routing is the process of forcing packets to take a certain route, often different from the default route, based on certain packet attributes (source, type of packets, interface, etc.).
The need for policy routing arises for multi-homed hosts (hosts having two network connections to different ISPs), that cannot use a single default route. Having a central Internet connection for multiple private networks can require policy routing. It is most useful in case you have multiple networks connected behind a FreeBSD host with more than one connection to the Internet, when each network needs to use a different outgoing route.
Also, policy routing should be employed when you need to separate traffic by certain criteria, such as source, destination or protocol
When Not to Use Policy Routing
Policy routing can be extremely useful, but it is not always needed. A frequent case of misuse is when configuring a tunnel as a default route. Instead of using the first gateway as the default, then injecting all the other traffic in the tunnel, use more specific routes. For example, if the tunnel ends at 10.10.10.10, the ip of the other end inside the tunnel is 1.2.3.4, and the gateway your provider gave you (and don't actually want to use) is at 2.2.2.2, you can use these routes in /etc/rc.conf:
static_routes=?tunnel_end?
route_tunnel_end=?-host 10.10.10.10 2.2.2.2?
defaultrouter=?1.2.3.4?Since policy routing does involve a certain overhead on the system, do think of a different solution first. Specific routes can be very useful, but policy routing is the only solution for certain cases.
Configuring Policy Routing
The easiest way of doing policy routing with FreeBSD is by using IPFilter. It comes by default with all recent versions of FreeBSD, and it can be easily enabled by adding this line to /etc/rc.conf:
ipfilter_enable=?YES?Be advised that the IP addresses used in this article are fictional, and I have mixed public IP addresses with private ones (see RFC1918). You might find those in private networks, but they will almost never be assigned to you by an ISP.
Example 1 - Multi-homed Host
Suppose you have a host that is connected to two networks, via two interfaces: fxp0, with an IP address of 192.168.100.100, and fxp1, with an IP address of 192.168.200.200, both with the default classful netmask of 255.255.255.0. On both those networks, the gateways are located at 192.168.*.1. I'll assume that the default route is out fxp0.
Now suppose the host receives a ping (an ICMP echo request packet) from host 1.1.1.1, to its IP address 192.168.200.200. The reply will be generated with a source address of 192.168.200.200, and sent to 1.1.1.1. But if the host has no specific route to 1.1.1.1, it will use the default route out fxp0, and try to send the reply via the gateway at 192.168.100.1. If a stateful firewall is in place on the gateway, the packet will most probably be dropped, as the request came via the other gateway (in the 200 network). Also, if egress filtering (filtering of outbound traffic) is configured on the 100 network gateway, the reply will be blocked because it is coming from a different network (and possibly logged as a spoofing attempt). This will also affect other types of packets, like TCP and UDP.
The solution for this problem is rather simple: use policy routing to force packets from the 192.168.200.200 address to leave via the network they belong to. This is line in /etc/ipf.rules will do just as I have described:
pass out quick on fxp0 to fxp1:192.168.200.1 from 192.168.200.200 to any This rule says ?force packets from my fxp1 address to exit via the gateway on fxp1 (not my default gateway on fxp0)?.
Example 2 - Asymmetric Traffic
This is similar to Example 1, but with a different purpose. Let's assume that one of the links, fxp0, is an ADSL link with a static IP address. The fxp1 link is a cable modem, with a dynamic IP. You want to have a web server, so you put it on the static IP. But the cable link has better bandwidth, so you want to take advantage of that.
Web traffic in inherently asymmetric, with a small request from the client to the server, and a larger reply from the server to the client. So receiving the request on the ADSL link will not hurt, and it has the added benefit of having a static IP address. So you decide to send the replies via the bigger bandwidth link.
What you need to do is allow requests to the web server on your static IP address to come in via the ADSL link, but policy route the reply, diverting it to the cable link. Here is a configuration that does that:
pass in quick on fxp0 proto tcp from any to 192.168.100.100
pass out quick on fxp0 to fxp1:192.168.200.1 proto tcp from 192.168.100.100 port = 80 to any The gateway on fxp1 (192.168.200.1 in this example) is assigned by DHCP, and you can find it out by running this command:
# grep routers /var/db/dhclient.leasesThis will not work if your ISP on the cable link implements egress filtering. For a web request to complete successfully, the reply must come from the host the request went to. Since you will be sending the reply via another link (possibly belonging to a different ISP than the one who owns the fixed IP address), the cable ISP might choose not to forward your packets, and make this setup inoperable.
Example 3 - Routing for Multiple Networks
Another scenario is a network that has access to two different ISPs, and has assigned addresses from each of those. The interfaces connecting to those ISPs are fxp0 at 10.0.0.2, using the gateway at 10.0.0.1, and fxp1 at 20.0.0.2, using the gateway at 20.0.0.1. The networks assigned by those two ISPs are 192.168.100.0/24, and 192.168.200.0/24. Traffic originating from the 100 network belongs to the 10.0.0.1 ISP, and the other network to the 20.0.0.1 ISP. The interfaces connecting those two nets are de0 and de1.
This needs a simple configuration in /etc/ipf.rules. But we do have to take care and not shoot packets out to the ISP that are intended for the FreeBSD machine (which we'll suppose is at .254 on both those networks).
# accept packets to us, don't forward them
pass in quick on de0 from 192.168.100.0/24 to 192.168.100.254
pass in quick on de1 from 192.168.200.0/24 to 192.168.200.254
# other packets should be handled by their respective ISP
# ISP1
pass in quick on de0 to fxp0:10.0.0.1 from 192.168.100.0/24 to any
# ISP2
pass in quick on de1 to fxp1:20.0.0.1 from 192.168.200.0/24 to anyAdditional Resources
Egress filtering - Keeping the Internet Safe from Your Systems
Anatomy of a Stateful Firewall
- Alex
Alexandru Popa is a CCNA studying for a CCNP, and is actively involved in the FreeBSD community in his spare time. He also maintains cvsup.ro.freebsd.org out of a basement in a deserted building, using a large hamster array for power.
Copyright © 2003, BSDnews. All rights reserved.
Graciously hosted by LayeredTech.com
Link Original: http://www.bsdnews.org/01/policy_routing.php
<< Início