Proxy Transparente com Ubuntu

Apresento a seguir alguns passos para se configurar um proxy transparente com o Ubuntu. O objetivo é ter um ponto de monitoração das requisições à Internet feitas a partir dos computadores da rede doméstica. Não se trata de uma arquitetura de rede no estado-da-arte em segurança, principalmente em relação a ataques internos, mas estes não são uma grande preocupação no momento. Não tive custos em equipamentos adicionais, pois usei uma máquina antiga.

A rede que temos em casa é típica: um roteador wireless Linksys WRT54G atrás de um cable modem com Vírtua. Os computadores conectam-se ao roteador por cabo ou rede wireless, e usam o servidor DHCP do próprio roteador.

Olhando assim, já se tinha o ponto único de acesso à Internet: o WRT54G. Mas, apesar de ser um roteador doméstico espetacular, as funcionalidades de filtro, logging e monitoração são limitadas. Assim, a idéia foi usar um computador antigo como roteador, antes de passar pelo WRT54G. Estando configurado como um roteador, o PC poderia fazer análise, filtro e monitoração dos acessos.

Nesta configuração, usei um computador antigo com as seguintes características:

• AMD Duron 1.8 MHz
• 256 MB de RAM
• ASUS A7V266-M
• 80 GB de HD
• Uma placa de rede, ligada ao roteador WRT54G.

Instalei o Ubuntu Server 8.10 Intrepid. Após a instalação, baixei o pacote xubuntu-desktop pelo apt-get para poder usar os recursos básicos de GUI. Após a instalação, removi o teclado e o mouse, deixando apenas os cabos de rede e de força. Evita-se assim mais fios emaranhados pela casa, e os acessos são feitos por ssh -X.

IP Fixo no Roteador

O primeiro passo é configurar o IP fixo do servidor. O NetworkManager deu um certo trabalho então configurei manualmente, no /etc/network/interfaces:

auto eth0
iface eth0 inet static
address 192.168.1.50
gateway 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

Minha rede local é 192.168.1.X. O final 50 é o IP do roteador, cujo hostname é nets.O gateway padrão é o WRT54G (IP final 1).

É preciso configurar também o servidor DNS a ser usado pelo nets, no arquivo /etc/resolv.conf. Uso o proprio WRT54G:

joao@nets:/etc$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.1

O NetworkManager é meio metido a besta e às vezes sobrescreve o resolv.conf. Depois de um reboot, ele sobrescreveu o meu. Alterei manualmente novamente, rebootei e o NM não mexeu mais nele.

Neste ponto, estamos acessando a Internet normalmente a partir do nets.

Servidor DNS

O próximo passo é instalar o servidor DNS no nets. Isto não é realmente necessário para o meu setup, pois poderia usar o próprio WRT54G como servidor DNS. Mas, se, quem sabe, no futuro, desejar-se fazer uma DMZ, já temos um DNS na rede interna, que apenas delega as requisições para o WRT54G.

No Ubuntu, basta instalar o Bind:

sudo apt-get install bind9

Não precisei alterar nenhuma configuração e ele já saiu funcionando, delegando as requisições para o DNS server do /etc/resolv.conf. Para testar, pode usar o nslookup a partir de outro computador, digitando ‘server 192.168.1.50’ e depois consultando um domínio.

Servidor DHCP

A idéia principal da configuração do roteador no nets é que os computadores que usam DHCP tenham seu gateway configurado para o próprio nets. Então, desabilitei o servidor DHCP no WRT54G e instalei um no nets, que vai distribuir os IPs na rede, assim como as configurações de gateway e DNS. Para instalar o servidor DHCP, podemos usar:

sudo apt-get install dhcp3-server

O arquivo de configuração principal é o /etc/dhcp/dhcpd.conf, no qual fiz as seguintes alterações:

# Comentar as isto, para evitar configurações globais
#option domain-name "example.org";
#option domain-name-servers ns1.example.org, ns2.example.org;
...
# Descomentar e alterar a configuração da seguinte rede:
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.150 192.168.1.200;
option domain-name-servers 192.168.1.50, 192.168.1.1;
option domain-name "intra.delvalle.com";
option routers 192.168.1.50;
option broadcast-address 192.168.1.255;
default-lease-time 6000;
max-lease-time 72000;
}

Em resumo, estamos distibuindo IPs com final 150 a 200 para as máquinas. Estas usarão o nets e o WRT54G, nesta ordem, como servidores DNS. E o nets será o gateway padrão. Configurado isso, é preciso reiniciar o servidor DHCP:

sudo /etc/init.d/dhcp3-server restart

Para testar, pegamos um notebook que está conectado à rede wireless e fazemos a desconexão da rede, reconectando-o a seguir. O notebook deve pegar um IP como 192.168.1.150, com gateway e DNS apontando para 192.168.1.50 (nets). É interessante, pois quem está provendo a conexão na camada wireless (wi-fi) é o WRT54G, mas quem está distribuindo os IPs é o servidor nets.

Neste ponto, no entanto, não se consegue usar a Internet no notebook, pois o gateway 192.168.1.50 não está encaminhando os pacotes para a Internet.

IP forwarding

Para que o nets passe realmente a agir como um roteador, precisamos alterar um parêmetro do kernel. Apesar de soar grave, é bastante simples:

# descomente a seguinte linha, para habilitar o NAT no servidor
net.ipv4.ip_forward=1

Para que tome efeito, faça reboot do servidor (sudo shutdown -r now). É possível alterar isso sem rebootar, mas o reboot agora é útil porque já testa a persistência da configuração.

Após o reboot, o notebook – e outros clientes DHCP – já podem acessar a Internet.

Squid Proxy

O próximo passo agora é instalar e configurar o Squid, tradicional servidor de Proxy Web:

sudo apt-get install squid

Fiz três alterações no /etc/squid/squid.conf:

# Identificar a rede local em uma ACL
acl localnet src 192.168.1.0/24 # RFC1918 ...
...
# Descomentar para permitir acesso a partir da rede interna
http_access allow localnet
...
# Adicionar o transparent para permitir HTTP transparente
# para qualquer host e porta
http_port 3128 transparent

Alterado o arquivo, é preciso reiniciar o serviço:

sudo /etc/init.d/squid restart

Aqui, já se pode testar o Squid como proxy normal. No Firefox de um dos clientes DHCP, configure o servidor proxy apontando para o nets, porta 3128, para todos os protocolos. O navegação deve acontecer sem problemas e você pode acompanhar pelo log do squid:

joao@nets:/etc/squid$ sudo -i
root@nets:~# tail -f /var/log/squid/*

Depois do teste, lembre-se de desconfigurar o servidor proxy no Firefox. O objetivo é fazer um proxy transparente, ou seja, que não precisa de configurações na parte do cliente.

IPTables redirecionando para Squid

O Iptables já vem instalado por padrão no Ubuntu Server. Mas, para se assegurar que está em seu sistema, pode-se executar:

sudo apt-get install iptables

Ele vem configurado como “passa-tudo”. Ou seja, recebe o pacote (cujo encaminhamento já habilitamos no kernel) e libera o encaminhamento para o gateway. Para fazer com que o roteador direcione as requisições HTTP para o Squid, é preciso fazer uma alteração no Iptables:

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp  \\
     --dport 80 -j REDIRECT --to-port 3128

Ou seja os pacotes TCP que chegarem para a porta 80 deverão ser encaminhados para a porta 3128, onde está o Squid. É possível fazer isto também para outras – ou qualquer – portas. Mas, neste exemplo, só nos interessa o tráfego HTTP.

Para fazer com que estas configurações do Iptables não se percam no reboot, é preciso salvá-las:

joao@nets:/etc$ sudo -i
root@nets:~# iptables-save > /etc/iptables.rules

E criar um script de inicialização da interface de rede:

root@nets# echo '#!/bin/sh' > /etc/network/if-up.d/iptables
root@nets# echo 'iptables-restore < /etc/iptables.rules' >> /etc/network/if-up.d/iptables
root@nets# chmod +x /etc/network/if-up.d/iptables

Teste o reboot agora e depois verifique se a regra foi persistida no Iptables:

joao@nets:~$ sudo iptables -L -v -t nat
Chain PREROUTING (policy ACCEPT 4 packets, 471 bytes)
pkts bytes target prot opt in out source destination
0 0 REDIRECT tcp -- eth0 any anywhere anywhere tcp dpt:www redir ports 3128
...

Conclusão e próximos passos

Neste ponto, o notebook e os outros clientes DHCP devem estar navegando normalmente pela Internet, sem configuração especial de proxy. E o log disso pode ser acompanhado pelo Squid. Estando o tráfego passando pelo Squid, pode-se usar todo o seu poder para filtrar, acelerar, monitorar e fazer cache de conteúdo.

O ambiente está OK, mas há alguns pontos de melhoria, como, por exemplo, configuração dinâmica do servidor DNS no servidor DHCP, evitando que as requisições DNS dêem tantos pulos dentro da rede. Do ponto de vista de segurança, também seria interessante bloquear no WRT54G as requisições vindas de outros computadores que não o nets. Mas isso fica para outro dia.