Se você já entende bastante da lógica do iptables e não estiver afim de rir um pouco com alguns exemplos, passe para a próxima página.

Antes de eu começar a dar linhas e mais linhas de comandos como exemplo, vamos entender qual é a lógica de funcionamento do iptables. O iptables pode ser definido em três palavras: regras, tabelas e chains.

As regras são, basicamente, as instruções do iptables. São essas regras que dizem o que o iptables deve fazer ou deixar de fazer. As regras são, mais ou menos, o comando que você fala para o seu cachorro sentar: você diz "senta!", e o cachorro "senta". Essas regras são armazenadas no kernel, ou seja, se você reiniciar o seu computador perde tudo o que foi feito.

Para sobrepor esse "pequeno" empecilho, o que normalmente é feito é que são gravados em arquivos as regras do iptables, e esses arquivos são carregados na inicialização do sistema. Além disso as regras são entendidas na ordem de cima para baixo, como um bloco lógico de programação, para quem conhece e a primeira regra atendida, passa a próxima etapa.

Exemplificando um pouco melhor, as regras são atendidas assim. Vamos pegar a idéia do cachorro. Ele tem duas regras. Se uma das regras não for atendida, ele passa para a próxima checagem.

1. SENTAR, ao dizer SENTA se estiver sol - sentar;

2. DORMIR, sempre que disser DORME - ele apaga e não acorda mais.

Sendo assim, se você disser:

"Senta!"
"Dorme!"

O cachorro vai sentar caso esteja sol, a primeira regra foi atendida. Se estiver chovendo, ele não vai sentar, já que a primeira regra não foi atendida. Sendo assim, passamos a segunda regra. E essa é sempre atendida. Agora, se você disser...

"Dorme!"
"Senta"

O cachorro estará dormindo e não vai sentar. Exatamente nesse sentido que funcionam as regras do iptables. Você deve colocar as regras que são mais específicas para cima e que não pararam tudo (que nem o senta), porque elas serão as primeiras a serem lidas e executadas.

Da mesma forma as regras que proíbem tudo ou permitem tudo (o "dormir" do nosso exemplo) devem ser colocadas por último, porque senão o resto do script não terá efeito (depois que o cachorro dormiu, ele não fez mais nada). Pegaram?

Chains são, basicamente, os locais onde as regras se armazenam. Existem dois tipos de chains. O primeiro tipo são as que já pertencem ao sistema e o outro é o que o usuário pode criar. Além disso, existem as tabelas, que são "conjuntos" de chains de mesmo tipo, que são agrupadas. É mais ou menos o seguinte, ela seria meio que endereço de onde vai estar a regra.

Em uma analogia, imagine um avião voando. Digamos que esse avião fará uma trajetória São Paulo (Brasil) - Tokio (Japão). Para isso, ele terá que fazer uma série de conexões, por exemplo, em Dallas (EUA), em Paris (França), em Moscou (Rússia), para finalmente chegar a Tokio, no Japão. Cada local desses tem uma regra para você desembarcar e embarcar de novo em outro vôo para o seu próximo destino.

É exatamente assim que as chains funcionam, elas são os países onde as regras se aplicam. O conjunto de regra em cada país é diferente, assim como o país em si é. Além disso existem associações de países que definem regras diferentes, tal como o Mercosul e a União Européia. Vou tentar exemplificar...

TABELA FILTER - É a tabela padrão, ou seja, a organização padrão. Todos os países que não forem nada em especial, são esses aqui. É tipo uma ONU.

INPUT - Esse "país" trata tudo o que entra no computador. Ou seja, se chegar um pacote pela porta 80 no seu computador, com destino ao seu computador, é aqui que ele será tratado. No nosso exemplo, seria Tokio, que tem uma série de regras para quem possa entrar e permanecer no país;

OUTPUT - Esse "país" trata o que sai do computador. Ou seja, se você tentar pingar um outro computador, a requisição do seu ping será tratada aqui. Mais ou menos, essa chain seria São Paulo, que determina um série de condições para que o brasileiro saia do seu pais;

FORWARD - Esse "país" trata tudo o que passa por ele. No nosso exemplo, eles seriam as conexões de Dallas, Paris, Moscou etc. Você não entra efetivamente nesse país, apenas passa por ele, pegando outro rumo logo após o desembarque. No caso também existem regras que esses países definem para conexões (de avião);

TABELA NAT - Basicamente essa tabela trata os dados (aviões) que geram novas conexões. Essa organização seria dos países que fazem conexão para outros países. Ou seja, seria a junta de países que deixam os visitantes darem uma passadinha por eles, rumo a outro destino. O grupo de regras aqui.

PREROUTING - Basicamente aqui são tratadas as regras logo que chegam ao país. Ou seja, é como se revistassem os viajantes no avião, antes de desembarcarem no país;

POSTROUTING - É exatamente o contrário do exemplo de cima. Seria como se, ao subir no avião, a polícia saísse correndo atrás de você para revistar sua mala na saída.

OUTPUT - Basicamente esse grupo de regras entra em ação quando é necessário mexer em alguém que está saindo do Brasil, antes que ele seja encaminhado a um novo país, consultado para conexões que se originam de interfaces locais (lo, no Linux);

TABELA MANGLE - Essa tabela é um pouco diferente. Ela é feita para tratar de diferentes formas os pacotes baseando-se no serviço TOS. Por exemplo, para dar prioridade ao tráfego a pacotes originados na porta 80, afim de "acelerar" a internet. Seria mais ou menos como as classes do avião. Existe a primeira classe, a classe executiva, e a econômica. Cada uma dessas classes são tratadas de forma diferente: enquanto a primeira classe toma champanhe e come pato ao molho de laranja, a classe econômica toma água sem gás quente e come lasanha. Acho que não tem muito o que simplificar aqui, o melhor mesmo é roubar as palavras do mestre foca, de seu Guia Foca/Linux:

"INPUT - Consultado quando os pacotes precisam ser modificados antes de serem enviados para o chain INPUT da tabela filter.

FORWARD - Consultado quando os pacotes precisam ser modificados antes de serem enviados para o chain FORWARD da tabela filter.

PREROUTING - Consultado quando os pacotes precisam ser modificados antes de ser enviados para o chain PREROUTING da tabela nat.

POSTROUTING - Consultado quando os pacotes precisam ser modificados antes de serem enviados para o chain POSTROUTING da tabela nat.

OUTPUT - Consultado quando os pacotes precisam ser modificados antes de serem enviados para o chain OUTPUT da tabela nat"

Bom, acho que deu pra entender um pouco da lógica dessa bodega... agora vamos conhecer os comandos mesmo.