IPTABLES e suas principais características

[guioximitsu]

Antes de tratarmos do IPTABLES, vamos conhecer o netfilter. O netfilter é um framework dentro do KERNEL Linux com o qual outras coisas (como o módulo do iptables) podem conectar-se. Se você estiver na dúvida em relação a existência ou atividade do seu netfilter no KERNEL, pode checar a opção: 'Y (SIM)' para CONFIG_NETFILTER na sua configuração do KERNEL.
O IPTABLES é uma ferramenta de edição da tabela de filtragem de pacotes, ou seja, com ele você é capaz de analisar o cabeçalho (header) e tomar decisões sobre os destinos destes pacotes. O IPTABLES não é a única solução existente para controle desta filtragem, temos ainda as antigas ipfwadm e ipchains, dentre outros.
É importante saber que no Gnu/Linux a filtragem de pacotes está implementada diretamente no KERNEL. Por isso não trataremos de sua instalação neste artigo, pois a maioria das distribuições vem com ele habilitado como um modulo ou diretamente compilado no KERNEL.
O ideal é que seja usado um LINUX acima do 2.4, porque foi nesta versão que houve um duro trabalho na reedição do KERNEL junto ao IPTABLES.
O iptables é um firewall com estado, ou seja, um firewall stateful. Os anteriores eram stateless. O modo de filtragem 'Stateless' tende a tratar cada pacote roteado pelo firewall como pacotes individuais, sendo mais simples de implementar e por terem uma resolução mais rápida que um do tipo stateful, podem ser usados para obterem um desempenho melhor em determinadas situações onde existem regras de nível de rede bem simples.
O tipo de filtragem stateful (IPTABLES) cria um poderoso sistema de firewall que se "lembra" das conexões entrantes, evitando ataques do tipo Stealth Scans, que trazem flags especiais para técnicas de port scanning, como o uso da flag ACK para enganar tais firewalls. Não vamos entrar em detalhes sobre o funcionamento deste ataque ou do tipo stateful, porém podemos afirmar que usando stateful trataremos de forma mais inteligente as atividades da rede, indo até mais longe do que o conceito de filtro de pacotes (Packet Filter) devido a esta característica.
Rusty é o programador responsável e mantenedor do Linux IP Firewall e a WatchGuard (http://www.watchguard.com/) foi a empresa responsável por suprir as despesas deste programador para realizar este excelente trabalho ao lançar o IPCHAINS.

Um simples script do Rusty
Antes de começarmos a conhecer como funciona a filtragem, vamos ver este primeiro script feito pelo Rusty para as pessoas que utilizam uma simples conexão PPP com a Internet e não querem ninguém entrando em sua rede.

Código Selecionar Expandir

## Carregando módulos de acompanhamento de conexões (desnecessário se compilados diretamente no KERNEL).
# insmod ip_conntrack
# insmod ip_conntrack_ftp

## Cria CHAIN que rejeita novas conexões, exceto as vindas da rede interna.
iptables -N block
iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
iptables -A block -j DROP

## Saltar das chains INPUT e FORWARD para a CHAIN block.
iptables -A INPUT -j block
iptables -A FORWARD -j block


Este script nos apresenta a primeira idéia de como são estruturadas as regras de filtragem para o IPTABLES.

Conhecendo um pouco das tabelas

Esta filtragem funciona através de regras estabelecidas, o KERNEL traz a tabela "filter" como default, que contém 3 principais listas de regras conhecidas como CHAINS (correntes). São elas: INPUT, OUTPUT e FORWARD. Podemos dizer que elas são as situações possíveis depois que a análise de qual CHAIN irá tratar o pacote é concluída.
Neste momento vale lembrar que não existe apenas a tabela 'filter', mas 3 tabelas possíveis:

>filter: esta tabela é o default se não declarada em nenhuma regra, ou seja, ela permite a filtragem em regras de INPUT (para pacotes destinado a própria máquina), OUTPUT (para pacotes gerados localmente) e FORWARD (qualquer pacote que atravessa o firewall, oriundo de uma máquina e direcionado a outra).
>nat: utilizada quando há NAT (se você tem dúvidas sobre NAT, veja este artigo: Conceito de NAT detalhadamente) ou quando um pacote responsável por criar uma nova conexão é encontrado, ou seja, quando a "dport" (destination port) é diferente dos IPs conhecidos. Exemplo: passagem de dados de uma rede privada para a Internet. Admite as chains PREROUTING (para alterar pacotes recebidos antes do roteamento), OUTPUT (para alterar localmente pacotes gerados antes do roteamento) e POSTROUTING (para mudar o endereço de origem das conexões para algo diferente).
>mangle: serve para especificar ações especiais para o tratamento do tráfego que atravessa os chains. Nesta tabela existem dois chains: PREROUTING e OUTPUT. Opções com o Tipo de Serviço (TOS) são especificadas nesta tabela para classificar e aumentar consideravelmente a velocidade de tráfego considerados em tempo real.

Entendendo como os pacotes passam pelos filtros

Vamos levar em consideração a tabela filter e suas chains: INPUT, OUTPUT e FORWARD. Observe a organização das chains. Esta organização não vale para o KERNEL 2.0 e 2.2.



Diante deste diagrama podemos perceber que os círculos são as chains. Quando um pacote atinge a máquina em questão, o KERNEL define o tipo do roteamento interno escolhendo uma CHAIN. Ela que é examinada para verificar o destino do pacote, a CHAIN pode simplesmente rejeitar (DROP) ou aceitar o pacote (ACCEPT), se isso acontecer ele continua passeando no diagrama.
Para entender melhor este diagrama devemos saber que as chains são uma lista de regras que analisa o cabeçalho do pacote e diz o que deve ser feito com ele. Se uma regra desta CHAIN não tem relação com o pacote em questão, então uma próxima regra é analisada. Se não houver mais regras a consultar, o KERNEL analisa a política da CHAIN para decidir o que fazer. Na maioria dos casos uma boa solução para a política é rejeitar (DROP) o pacote.
Em etapas podemos colocar desta forma, que se encontra no manual oficial:
1-Quando o pacote chega, o KERNEL analisa o destino do pacote: isso é chamado roteamento (routing).
2-Se ele é destinado a própria máquina, o pacote desce no diagrama, indo para a CHAIN INPUT. Se ele passar pela CHAIN INPUT, então a máquina recebe o pacote.
3-Depois, se o KERNEL não tem suporte a forwarding, ou não sabe como repassar (forward) o pacote, este é descartado. Se há suporte a forwarding e o pacote é destinado a outra interface de rede (se você possui outra), o pacote vai para a CHAIN FORWARD. Se ele for aceito (ACCEPT), ele será enviado.
4-Finalmente, um programa rodando na máquina firewall pode enviar pacotes. Esses pacotes passam pela CHAIN OUTPUT imediatamente: se ela aceitar o pacote, ele continua seu caminho, caso contrários ele é descartado.

Diferenças entre iptables e ipchains

Primeiramente, os nomes das chains padrão passarão a ser escritos com MAIÚSCULAS em vez de minúsculas, porque as chains INPUT e OUTPUT apenas recebem pacotes destinados localmente e gerados localmente. Antes, essas chains visam todos os pacotes entrando e saindo, respectivamente.
A flag `-i' agora significa interface de entrada e apenas funciona nas chains INPUT e FORWARD. Regras nas chains FORWARD e OUTPUT que utilizavam `-i' devem ser alteradas para `-o'.
Portas TCP e UDP agora precisam ser descritas com as opções --source-port ou - sport (ou --destination-port/--dport), que devem se colocadas depois das opções `-p tcp' ou `-p udp', já que essas carregam as extensões TCP ou UDP respectivamente.
A flag TCP -y agora é --syn, e deve ser posicionada depois de `-p tcp'.
Finalmente o alvo DENY agora é DROP.
Zerar chains enquanto listando-as funciona.
Zerar chains padrão também apaga os contadores de suas políticas.
Listar as chains também mostra os contadores.
REJECT e LOG são agora alvos-extensões, ou seja, eles são módulos do KERNEL separados.
>Nomes das chains podem ter até 31 caracteres.
>MASQ agora é MASQUERADE e utiliza uma sintaxe diferente. REDIRECT, embora tenha mantido o nome, também sofreu uma mudança de sintaxe. Veja o NAT HOWTO para mais informações sobre como configurar ambos.
>A opção -o não é mais utilizada para mandar os pacotes para o dispositivo userspace (veja -i acima). Pacotes agora são mandados para o espaço do usuário com o alvo QUEUE.
Estas diferenças acima foram escritas por Rusty, acredito que não existe uma fonte melhor do que o próprio criador para listar algumas diferenças. Provavelmente quem já leu o manual do IPTABLES já deve conhecer.

Conteúdo totalmente retirado de:http://www.vivaolinux.com.br/