Iptables

iptables
Autor	Paul "Rusty" Russell
Desenvolvedor	Netfilter Core Team e colaboradores.
Plataforma	Multiplataforma
Modelo do desenvolvimento	Software livre
Lançamento	1998 (26–27 anos)
Versão estável	1.8.11 (8 novembro 2024)
Escrito em	C
Sistema operacional	Linux
Tipo	Firewall
Licença	GPLv2
Estado do desenvolvimento	Ativo
Página oficial	netfilter.org

O iptables é um programa escrito em C, utilizado como ferramenta que configura regras para o protocolo de internet IPv4 na tabela de filtragem de pacotes, utilizando os módulos e framework do kernel Linux (versão 2.3.15 ou posterior). As configurações de firewall feitas ficarão guardadas no kernel, logo serão perdidas quando o sistema for reiniciado. O iptables-save e iptables-restore ficam responsáveis por salvar as configurações e restaurá-las.

O ip6tables é similar ao iptables mas atua com o protocolo de internet mais atual, o IPv6. Podendo ser definidas multiplas tabelas diferentes. Cada uma contém uma série de cadeias embutidas e pode também conter cadeias definidas pelo usuário. Cada cadeia é uma lista de regras que podem combinar um conjunto de pacotes. Cada regra especifica o que fazer com um pacote que corresponde. Isso é chamado de 'target', que pode ser um salto para uma cadeia definida pelo usuário na mesma tabela.

Principais características

• listar o conteúdo do conjunto de regras de filtragem de pacotes
• Adicionar/remover/modificar regras no conjunto de regras de filtragem de pacotes
• listar/zerar contadores por regra do conjunto de regras de filtragem de pacotes

Visão geral

O iptables permite que o administrador do sistema defina tabelas contendo cadeias de regras para o tratamento de pacotes. Cada tabela é associada a um tipo diferente de processamento de pacote. Pacotes são processados seguindo sequencialmente as regras na cadeia. Uma regra na cadeia pode realizar uma operação “go-to” ou saltar para uma cadeia diferente, e isso pode ser repetido quantas vezes for desejado, aninhando operações. (Um salto seria como uma chamada que se lembra do ponto de onde se saltou.) Cada pacote da rede chegando ou saindo do computador atravessa pelo menos uma cadeia.

Cada regra em uma cadeia contém as especificações de quais pacotes ela corresponde. Uma regra também pode ter um alvo (”target”, em inglês), utilizado por extensões, ou um veredito (”veredict”, em inglês), que já vem com o iptables. Conforme um pacote atravessa uma cadeia, cada regra é examinada. Se a regra não se aplica ao pacote, ele é passado para a próxima regra. Se a regra se aplica, ela tomará uma ação definida pelo alvo/veredito, que resultará no pacote sendo autorizado a continuar atravessando a cadeia ou não.

Um alvo é uma ação que acontecerá com o pacote se ele corresponder a uma regra. Os alvos principais são:

• ACCEPT: O pacote é aceito pela cadeia e passa para o próximo nível de processamento.
• DROP: Abandona o pacote e não envia nenhuma informação para nenhum outro dispositivo. Quando este alvo é acionado, o pacote não passará por mais nenhuma outra cadeia, e o sistema interpreta como se ele nunca tivesse existido.
• REJECT: Abandona o pacote, como o alvo DROP, porém envia uma mensagem de erro de volta ao dispositivo que enviou o pacote abandonado.
• LOG: É utilizado especificamente para armazenar informações detalhadas sobre os pacotes. É principalmente utilizado para detectar bugs ou, pode vir logo antes de um alvo DROP, para que o administrador do sistema tenha logs sobre as tentativas de acesso a pacotes bloqueados.
• RETURN: Faz com que o pacote saia da cadeia atual e volte para a cadeia original/anterior.

A origem do pacote determina qual cadeia ele irá atravessar primeiro. Existem 5 cadeias pré-definidas (que mapeiam os 5 ganchos disponíveis pelo Netfilter), porém, uma tabela pode não ter todas as 5 cadeias. Cadeias pré-definidas tem uma política padrão, que é um alvo que será aplicado a um pacote que chegue até o final da cadeia sem que nenhuma regra tenha se aplicado.

Uma cadeia não existe por si só, ela pertence a uma tabela. Existem 3 tabelas principais: nat, filter, e mangle. Um comando iptables sempre automaticamente aloca uma regra à tabela filter, a não ser que o comando seja precedido pela opção -t. Por exemplo, o comando iptables -L -v -n, que mostra algumas cadeias e suas regras, é equivalente a iptables -t filter -L -v -n. Para mostras as regras da tabela nat, o comando seria iptables -t nat -L -v -n.

O administrador do sistema pode criar quantas outras cadeias for desejado. Essas cadeias não terão uma política padrão; se um pacote chegar ao fim da cadeia, ele retornará à cadeia que o invocou. Uma forma de simular uma política padrão seria adicionando uma regra sem requerimentos para correspondência ao final de uma cadeia com o alvo sendo a “política padrão”, assim, se um pacote não tiver correspondido nenhuma das regras da cadeia, a última regra será aplicada nele. Uma cadeia pode estar vazia.

Cadeias pré-definidas:

• PREROUTING: Pacotes entrarão nesta cadeia antes que uma decisão acerca de seu roteamento seja tomada.
• INPUT: Pacotes cujo destino é a máquina local. Pacotes aqui já foram roteados mas ainda não foram processados pela máquina.
• FORWARD: Pacotes que foram roteados mas cujo destino final não é a máquina local atravessarão esta cadeia.
• OUTPUT: Pacotes enviados pela própria máquina para um destino externo passarão nesta cadeia.
• POSTROUTING: Pacotes que já foram roteados e estão prestes a serem encaminhados para o hardware em si.

Correspondências são a maior parte dos conjuntos de regras, já que elas contém as condições às quais os pacotes são testados. Isso pode acontecer em qualquer camada do protocolo OSI, como por exemplo, os parâmetros --mac-source e -p tcp --dport, e há também correspondências que são independentes de protocolos, como o -m time.

O pacote continuará a atravessar a cadeia até que:

1. uma regra corresponda ao pacote e decida o seu destino, por exemplo, chamando o ACCEPT ou DROP, ou algum outro módulo com um destino final; ou
2. uma regra chame o veredito RETURN, que fará o pacote retornar à cadeia original/anterior; ou
3. o pacote chegue ao fim da cadeia; assim, o pacote voltará a atravessar a cadeia original/anterior (como se o RETURN tivesse sido usado), ou será aplicado a política padrão da cadeia, que é um destino final.

Funcionamento das tabelas

mangle

A tabela mangle faz um processo similar a uma “marcação” que coloca uma marca especial no pacote para algum processamento futuro. Diversos recursos podem interpretar essas marcações, eles conseguem identificar características de um pacote através dessas marcações e processá-lo corretamente. As marcações mangle só existem no contexto do roteador e não são transmitidas pela rede. A funcionalidade do mangle também pode alterar alguns campos no cabeçalho IP do pacote, como TOS (Type of Service) e TTL (Time to Live).

nat

A tabela nat se refere a operações realizadas com relação à Tradução de Endereços de Rede (”Network Address Translation”, em inglês). Somente o primeiro pacote de um fluxo de pacotes será “processado” por essa tabela, os outros pacotes relacionados da sequência receberão o mesmo tratamento decidido pelo processamento do primeiro pacote automaticamente.

Essa tabela pode alterar o SNAT (endereço de origem) e o DNAT (endereço de destino) de um pacote. Ela também pode ter como alvo MASQUERADE, que possibilita que o firewall funcione corretamente com endereços de IP dinamicamente alocados através de um DHCP.

raw

As funções da tabela raw são diretamente relacionadas a marcar pacotes que não se deseja rastrear a conexão (Connection Tracking). Essa tabela só contém as cadeias de PREROUTING e de OUTPUT, já que não faria sentido usar outras cadeias pois elas dependem do Connection Tracking.

filter

A tabela filter é onde realmente se filtra pacotes, especificando regras que podem corresponder ou não e aplicando os alvos DROP ou ACCEPT, por exemplo. É essa tabela que realmente foi feita para filtragem e que geralmente se usa para quaisquer cadeias de regras que se deseje criar, as outras tabelas são mais relacionadas a funções de pré-filtragem.

História

O autor inicial e chefe do netfilter/iptables foi Paul "Rusty" Russell. Que mais tarde, veio a se juntar a um grupo de pessoas, que juntas formaram a equipe principal do Netfilter (Netfilter Core Team) e mantiveram o projeto netfilter/iptables como um esforço conjunto.

Mas o netfilter/iptables não seria o que é hoje se não fosse pelas inúmeras contribuições de desenvolvedores de software independentes, a quem chamamos de colaboradores. Era costume manter um placar como recompensa para as pessoas que nos ajudavam muito - mas ultimamente tornou-se muito esforço manter esse placar. Assim, foi desativado até novo aviso.

No início do desenvolvimento, algumas pessoas contribuíram com algum código, mas nenhuma delas se tornou colaboradora de longo prazo. Depois de considerar o problema, Rusty decidiu tentar manter um placar de pessoas que contribuíram com patches e relatórios de erros. Foi esse processo de quantificação das contribuições que chamou a atenção a quantidade e a qualidade do trabalho produzido pelo apaixonado canadense francês Marc Boucher, e Rusty decidiu que era hora de iniciar uma Equipe Principal, da qual Marc se tornaria o segundo membro.

A equipe principal (Core Team) realmente começou logo depois que Rusty, em uma viagem a SF em novembro de 1999, fez um desvio para Montreal, para conhecer e discutir alguns grandes problemas de design. Rusty e Marc passaram a noite inteira no escritório de Marc, concebendo a estrutura de múltiplas tabelas (multiple tables framework) que levou à morte do ipnatctl (uma ferramenta separada usada para controlar o NAT nas primeiras versões do Netfilter), generalização do iptables e nascimento dos módulos iptable_{filter, nat, mangle}.

Depois que tudo isso foi poderosamente implementado (e o ip_conntrack reescrito) por Rusty, O projeto começou a receber algumas boas contribuições de James Morris ("louco por filas de links de rede e espaço de usuário", vivendo como Rusty).

Na primavera de 2000, Marc viajou para a Austrália para participar de algumas conferências e passar algum tempo em Canberra trabalhando com Rusty no Linuxcare no netfilter/iptables (corrigindo vários bugs, implementando módulos adicionais e mesclando tudo na árvore oficial do Linux).

Na Sydney Linux Expo, conhecemos James Morris pessoalmente, e sua incrível frieza nos convenceu a convidá-lo para se tornar o terceiro membro da equipe principal do Netfilter, por volta do início de junho.

Após a assimilação de James no coletivo, nossos esforços foram direcionados principalmente para os preparativos para o lançamento do Netfilter como parte do próximo kernel 2.4. Era o início da terceira era do firewall do Linux. Grandes comunidades foram fundadas, "civilizações antigas foram perdidas e novas alianças foram formadas". As missões de James durante esse período incluíram a perversão contínua do código de rede, de modo que agora era possível carregar um analisador ASN.1 no kernel e infligir terror grave aos pacotes SNMP desavisados; e estender a pilha de IP para o espaço do usuário com o Perl. Agora, olhando diretamente para o abismo, notamos as boas ações de um jovem guerreiro do núcleo chamado Harald Welte, que parecia realmente entender o código NAT.

Consequentemente, seu caráter distintivo foi acrescentado ao coletivo. Com o equilíbrio restaurado, o netfilter estava livre para ser lançado no mundo novo do Linux 2.4 e enfrentar o seu maior desafio: os usuários.

A primeira contribuição (de código) de Harald ao projeto Netfilter foi o módulo de rastreamento de conexão do IRC. Depois disso, ele trabalhou em algumas coisas menores, como módulos de correspondência e destino TTL, bem como portabilidade de IPv6. O destino ULOG, incluindo o daemon ulogd, foi o próximo marco. Depois de ser incluído na equipe principal do Netfilter em setembro de 2000, ele assumiu grande parte do trabalho administrativo, como lançamentos, manutenção de listas de SCM, TODO, etc. e se envolveu cada vez mais com questões fundamentais de design.

No momento da redação deste texto, essa é principalmente a nova estrutura conntrack/Nat helper para várias expectativas relacionadas, a nova interface do kernel/espaço de usuário nfnetlink, bem como o novo mundo do espaço de usuário com base em lib-iptables.

No primeiro workshop de desenvolvimento de filtros de rede em novembro de 2001, Jozsef Kadlecsik foi convidado a ingressar no Core Team como seu quinto membro. Jozsef é um colaborador ativo de longa data do filtro de rede. Entre suas contribuições estão: alvo REJECT, código de rastreamento de janelas TCP, desenvolvimento contínuo da API new-nat e a tabela bruta.

No segundo workshop de desenvolvimento de filtros de rede, em agosto de 2003, Martin Josefsson foi convidado a se juntar à equipe do core team. Martin fez muitos trabalhos úteis, especialmente no que diz respeito às otimizações no código de rastreamento de conexão.

Nesse momento, a equipe (Netfilter Core Team) também decidiu eleger formalmente um presidente que recebe a chamada final em todas as decisões. Decidiu-se ainda que os membros da equipe que não contribuem mais ativamente com o código podem se tornar membros eméritos.

Em janeiro de 2004, Patrick McHardy foi convidado a ingressar na equipe do core team por causa de suas contínuas contribuições importantes para a base de código do projeto netfilter. Infelizmente, Patrick foi suspenso em junho de 2016 por não assinar os Princípios da aplicação da GPL orientada para a comunidade.

Em outubro de 2005, Yasuyuki Kozakai foi convidado a ingressar na equipe de corretores, especialmente no que diz respeito ao seu trabalho de longa data no nf_conntrack e ao ip6_tables.

Em fevereiro de 2007, Pablo Neira Ayuso foi convidado a participar da equipe core team, especialmente em relação ao ctnetlink e conntrackd.

Em outubro de 2012, Eric Leblond e Florian Westphal juntaram-se à equipe de funcionários por suas contribuições de longa data e os colegas hackers Harald Welte, Martin Josefsson e Yasuyuki Kozakai entraram oficialmente como membros emérito. Arturo Borrero tornou-se membro da core team em julho de 2017 por suas excelentes contribuições ao nf_tables e ao conntrack-tools.

Durante o Netfilter Workshop 2013 em Copenhague, Pablo Neira Ayuso tornou-se oficialmente o chefe da equipe, embora ele já sirva como co-mantenedor desde 2011.

Implementação

O iptables está disponível por padrão na maioria das distribuições modernas do Linux, por exemplo: Ubuntu, Fedora Linux e Arch Linux. Para implementar a ferramenta iptables é necessário um kernel que possua a infraestrutura netfilter implementada; netfilter é um framework dentro do kernel Linux com o qual outras coisas (como o módulo do iptables) poderão conectar-se. Isso significa que você precisa do kernel 2.3.15 ou posteriores, e responder `Y (SIM)' para CONFIG_NETFILTER na sua configuração do kernel.

Ver também

• O repositório Git do projeto.
• Snapshots do desenvolvimento do projeto.
• kernel Linux
• Netfilter
• Outros módulos do iptables

Ligações externas

• Sítio oficial