From UnderLinux Wiki

Entendendo o iptables, saiba o que não fazer

Resolvi escrever este artigo porque tenho visto muitas pessoas no forum tento problemas com o firewall, principalmente por utilizar regras incompletas, que acabam afetando o funcionamento do sistema. Não pretendo falar de todas as opções do iptables, até porque elas são muitas, e você pode ver isso em um de nossos projetos: http://iptables.underlinux.com.br, ou ainda em nossos artigos: Proxy/Nat/Firewall. Vou começar mostrando um exemplo de como as regras NÃO devem ser feitas, neste exemplo suponha que iremos utilizar como politíca padrão BLOQUEAR tudo que não foi EXPLICITAMENTE liberado.

Exemplo do que não fazer

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to 3128
iptables -A INPUT -p tcp --syn -s 192.168.0.0/255.255.255.0 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP 

O que tem de errado nas regras? São vários detalhes que podem passar desapercebidos:

• 1) O mais "grave" é a última regra: "-A INPUT -p tcp --syn -j DROP", Esta regra quer dizer o seguinte, todos os pacotes que entrarem com a flag SYN devem ser bloqueados. O problema dessa regra eh que ela está sendo utilizada como se fosse a responsável por barrar todos os pacotes, e ela não está fazendo isso.
• 2) Agora a penúltima regra "-A INPUT -p tcp --syn -s 192.168.0.0/255.255.255.0 -j ACCEPT", essa tem um problema muito sério também, Ela está liberando apenas os pacotes SYN originados da rede 192 entrarem no servidor. 3) Não chega a ser um erro, mas a regra de REDIRECT apenas redireciona as portas 80(http) para o squid(3128), faltaria criar a regra para redirecionar a porta 443(https).

Agora você deve estar me xingando ai do outro lado "Mas essas regras funcionam aqui!" Primeiro tenha em mente que deixar os pacotes trafegarem não é funcionar! O intuito do firewall é proteger, então ele deve ser bem implementado. Essas regras funcionam ai justamente porque a ultima regra só bloqueia os pacotes SYN, e a penúltima somente libera os pacotes SYN, ou seja uma anula a outra! Quer outro problema? Basta alguém de fora utilizar um portscan do tipo FYN ou XMAS para descobrir o que você tem rodando, justamente porque essas regras só estão bloqueando os pacotes SYN! Já que a política era BLOQUEAR TUDO QUE NÃO FOSSE EXPLICITAMENTE LIBERADO essas regras estão totalmente furadas!

Agora que você entendeu os problemas, darei alguns exemplos de como essas regras deveriam estar:

Exemplo do que fazer

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to 3128
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to 3128
iptables -P INPUT DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT 

Onde está a diferença aqui? Esta regra: "-P INPUT DROP" seta a política padrão do iptables para DROP, agora nada entra a não ser que eu crie uma regra liberando. Esta regra: "-m state --state RELATED,ESTABLISHED", já que está tudo bloqueado precisamos liberar que conexoes internas que já tenham sido estabelecidas com a rede externa não sejam bloqueados. É meio estranho no começo mas depois você se acostuma, lembre-se apenas de que TUDO QUE NÃO FOI EXPLICITAMENTE LIBERADO NÃO ENTRA!. Última regra: "INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT", essa regra é "opcional", ela está liberando que a rede interna possa se conectar no servidor em qualquer porta com qualquer flag.

Precisa liberar algum serviço externo? Também é muito simples, se você seguiu as regras que propus, basta adicionar esta:

iptables -A INPUT -p tcp -i ppp0 --dport PORTA --syn -j ACCEPT

Para quem não entendeu ela quer dizer o seguinte: Libere os pacotes que entrarem pela interface ppp0(modem) com porta destino PORTA mas SOMENTE o flag SYN. Porque o somente SYN? Porque já temos a regra "-m state --state RELATED,ESTABLISHED", e ela é a responsável por liberar o trafego de conexoes estabelecidas.

Agora um último exemplo:

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to 3128
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to 3128
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT 
iptables -A INPUT -j DROP

A única diferença aqui é que ao invés de setar a política padrão "-P DROP", criamos as regras que liberam o tráfego e depois uma regra pra bloquear qualquer outro pacote. Não gosto muito de utilizar assim, mas isso é meio pessoal.

ATENÇÃO: Vou explicar melhor que tem muita gente entendendo errado, SQUID NÃO SUPORTA TRANSPARÊNCIA PARA PROXY HTTPS, não criei as regras de transparência para facilitar a vida do usuário, mas sim para obrigar ele a passar pelo proxy. Aquela regra de redirect da porta 443 é somente para evitar que algum engraçadinho tente tirar o proxy para acessar os sites, usando esse redirect vai fazer com que o https não funcione!. Se você não tem necessidade de controlar tudo, não use a regra de redirect da porta 443.

Conclusão:

As aparências enganam ;) Não é porque você consegue navegar, ou porque tentou se conectar externamente no seu servidor e foi bloqueado, que sua máquina está "protegida" ou as regras estão "certas". Existem milhares de maneiras de se implementar um firewall, aqui mosttrei apenas um exemplo simples e rápido. Infelizmente essas regras não são o tipo de coisa que você irá aprender apenas lendo, tem que testar, testar e testar várias vezes, de várias maneiras diferentes.

Para que as coisas fiquem um pouco mais claras recomendo que leiam:

http://iptables.underlinux.com.br

Netfilter > Documentação Oficial com vários exemplos

http://www.insecure.org/ > Página oficial do nmap (portscan)

Rafael M. Capovilla - iceman NOSPAM underlinux com br