Estrutura do Iptables

Ao contrário de outros artigos e tutoriais sobre iptables, este não se dispõe a ensinar sua sintaxe, como construir regras e como bloquear este ou aquele tipo de pacote. Artigos meus futuros poderão passear por este caminho, muito embora já se tenha muito material na Internet sobre isto.

Ele se destina a explicar a origem dos termos “tabelas” do iptables, o que é e para que servem as tabelas nat, filter e mangle. Onde, ou seja, em qual tabela se deve colocar as regras para este ou aquele objetivo.

Este artigo aproveita também para esclarecer algumas diferenças interessantes, como para que serve o REJECT e qual a diferença dele para o DROP?

Algumas definições serão relevantes e merecem serem citadas antes da leitura:

Quando falo de “nível” no artigo (ex: nível de Enlace) estou me referindo ao modelo de camadas TCP/IP, composto por apenas QUATRO camadas e não SETE como no modelo OSI. No modelo TCP as camadas são o ENLACE, onde se tem na sua imensa maioria o padrão de rede Ethernet como referência:

• O nível de REDE, responsável pelo roteamento, onde se tem o IP na sua versão 4 como mais significativo;
• O nível de TRANSPORTE, com seus pacotes UDP e TCP, dentre outros;
• O o nível de aplicação, com os protocolos FTP, HTTP, etc;
• O nível FÍSICO não faz parte do modelo de camadas TCP/IP, pois é restrito ao fabricante da placa.

Em termos de nomenclatura geralmente se generaliza chamando tudo de pacote. Porém, quando se quer deixar mais específico em qual nível estamos lidando, pode-se se usar a nomenclatura “quadro” para o nível de Enlace, “datagrama” ip para o nível de rede e “pacote” para o de transporte (sendo que o TCP muitas vezes usam a palavra “segmento”). Na aplicação o que tem são dados.

Mas como o iptables atua em princípio nas camadas de rede, ip de origem ou de destino, e na de transporte (porta origem e destino), o pacote pode ser considerado, neste artigo, como um termo genérico (OBS: é certo que o iptables também permite atuar no enlace e até mesmo na aplicação, com os devidos módulos adicionados).

O iptables, presente no Linux a partir do kernel 2.4, usa o conceito de “ganchos” do netfilter, permitindo avaliar um datagrama em alguns pontos dentro do kernel.

Conforme pode ser observado na Figura 1, um datagrama IP dentro do kernel do Linux passa por várias etapas. Basicamente um datagrama IP é de um dentre três tipos:

1. O datagrama chegou por uma de suas interfaces, o nível de enlace viu o seu mac address no quadro ethernet. Contudo o datagrama não é destinado ao número IP desta máquina. Se a máquina não for configurada para atuar como roteador, o datagrama é descartado. Se a máquina estiver atuando como roteador, o datagrama deve ser roteado por ela.
2. O datagrama chegou por uma de suas interfaces, o nível de enlace viu o seu mac address no quadro ethernet e ele é destinado ao IP desta máquina, logo deve ser entregue a um de seus processos locais (se for HTTP, por exemplo, deve ser entregue ao apache).
3. O datagrama IP foi gerado por um de seus processos locais, por um cliente de email por exemplo, e deve ser repassado a outra máquina.
   Cada datagrama passa por uma etapa de roteamento, onde o kernel decide para onde ele vai. Nesta etapa é que são consultadas, se for o caso, as tabelas de roteamento. Os do tipo 1 devem serem roteados para fora da máquina, que no caso deve estar atuando como roteador, sendo que na etapa de roteamento o kernel decide qual o próximo ponto de rota que deve ser usada. Se for para o IP desta máquina, é o roteamento que verifica isto (isto é, recebe o datagrama, vê que é local e entrega ao nível de transporte, que irá repassá-lo ao processo correspondente).

   Da mesma forma, pacotes os gerados por processos locais também passam pelo roteamento para serem encaminhados. Logo, todos os datagramas passam, de uma forma ou de outra, pela etapa de roteamento.

   Caso ele precise ser repassado a outra máquina (somente se ela estiver atuando como roteador IP), a etapa de “repasse de pacotes” realiza as alterações necessárias, como a reescrita total do cabeçalho de enlace (trocando o MAC origem para o seu), atualização do TTL, etc. Evidente que isto após a decisão de roteamento, pois a escrita do cabeçalho de enlace leva em conta o destino.

O netfilter introduziu “ganchos”, pontos ao longo do ciclo de vida de um datagrama onde o mesmo pode ser avaliado por regras de firewall. A Figura 2 destaca estes pontos.

Pode-se observar pela Figura 2, que:

• Um datagrama destinado ao processo local:
  • Pode ser capturado para avaliação ao entrar na Interface, pelo gancho 1, chamado pelo kernel de PREROUTING.
  • Pode ser capturado para avaliação pelo gancho 4, chamado pelo kernel de INPUT.
• Um datagrama gerado por um processo local:
  • Pode ser capturado para avaliação pelo gancho 5, chamado pelo kernel de OUTPUT.
  • Pode ser capturado para avaliação pelo gancho 3, chamado de POSTROUTING.
• Um datagrama que esteja apenas passando por esta máquina, não gerada e não destinada ao ip ela:
  • Pode ser capturado para avaliação ao entrar na Interface, pelo gancho 1, chamado pelo kernel de PREROUTING.
  • Pode ser capturado para avaliação pelo gancho 2, chamado pelo kernel de FORWARD.
  • Pode ser capturado para avaliação pelo gancho 3, chamado de POSTROUTING.

Por existirem estes ganchos e a possibilidade de avaliar um datagrama e tomar decisões de firewall sobre ele nestes pontos, o iptables introduz filas de regras (listas) nestes pontos. Cada gancho pode possuir um ou mais conjuntos de regras.

Ao todo são três as tabelas mais importantes do iptables:

• filter
• nat
• mangle

A tabela filter deve conter apenas regras que determinam se um pacote deve ser aceito ou não. Nesta tabela não é possível colocar regras para alterar algum parâmetro, como ip ou porta.

A tabela nat serve para realizar operações de tradução sobre IP e/ou porta, tanto de origem como de destino, muito embora também permita recusá-lo (não será abordada neste artigo).

Por fim a tabela mangle serve para realizar alterações mais profundas e bizarras nos pacotes, como alterar o TTL, TOS, etc (não será abordada neste artigo).

As ações operadas sobre um pacote basicamente podem ser recusá-lo ou deixá-lo passar, mas o iptables possui várias maneiras de “recusar” e ainda permite realizar logs. Como dito, operações de alteração de pacotes, seja IP ou porta, não pode ser realizada na tabela filter, mas sim na nat ou mangle.

Em termos de filtragem, para impedir que pacotes que não queremos entrem na máquina, é a tabela filter que nos interessa.

Entram nesta tabela o conjunto de regras com finalidades gerais, como bloquear, negar, realizar logs. As regras existentes nesta tabela não tem poder de alterar as configurações dos pacotes. Basicamente todas as regras de filtragem estão nesta tabela, pois ela é de uso geral.

Para inserir uma regra em uma lista, pode-se usar -A para APPEND, inserindo-a no final, ou -I para INSERT, inserindo-a NO INÍCIO (a sintaxe profunda das regras não é o foco deste artigo).

A tabela filter possui três conjuntos de regras, ou seja, três listas sendo que cada uma delas está associada a um gancho:

• INPUT: esta fila de regras recebe este nome justamente por ser aplicada aos pacotes na posição do gancho 4. Logo apenas os pacotes destinados ao ip da máquina atual serão avaliados por eventuais regras existentes nesta tabela. Sintaticamente para inserir regras nesta lista usa-se os parâmetros de iptables (o comando está incompleto):

  iptables -t filter -A INPUT [regra]

• OUTPUT: esta fila de regras recebe este nome justamente por atuar no gancho 5 (também chamado pelo kernel de OUTPUT). Logo serão avaliados pelas regras presentes nesta lista apenas os pacotes originados por processos locais da máquina. Sintaticamente para inserir uma regra nesta lista usa-se o comando:

  iptables -t filter -A OUTPUT [regra]

• FORWARD: esta fila de regras recebe este nome justamente por atuar no gancho 2 (também chamado pelo kernel de FORWARD). Logo serão avaliados por estas regras os pacotes que estão sendo repassados por esta máquina, não são para ela e nem originados por ela. Sintaticamente para inserir uma regra nesta lista usa-se o comando:

  iptables -t filter -A FORWARD [regra]

A tabela filter é a tabela básica do iptables e são em suas listas que devem ser inseridas regras de filtragens gerais, que não são complexas, como proibir ou permitir ips, portas, etc. Na Figura 3 pode ser observado a atuação do conjunto de regras desta tabela sobre os ganchos.

Cada regra pode realizar uma determinada ação ao pacote (representado graficamente por -j), sendo que na filter as seguintes ações são possíveis:

• REJECT: o pacote, uma vez que casou com a regra, é rejeitado. Demais regras existentes são ignoradas e o pacote definitivamente já teve seu destino selado: será descartado. Se for usado REJECT o remetente do pacote será avisado com uma mensagem de erro, normalmente um ICMP de “porta inatingível” (mas o iptables permite ao usuário mudar o tipo de retorno se ele quiser). Em termos de segurança pode não ser interessante devolver uma resposta ao remetente, pois isto iria inevitavelmente dar a conhecer a ele o número IP do firewall.
• DROP: o DROP tem o mesmo efeito do REJECT e a mesma aplicação, com a diferença de que não é retornado nenhuma mensagem de erro ao remetente (ele não saberá o que aconteceu com o pacote). Em se tratando de FORWARD (repasse) pode ser conveniente usar DROP ao invés de REJECT para que um possível atacante não saiba o IP do firewall que rejeitou o seu pacote. Mas isto deve ser bem analisado, pois se o remetente não souber o que ocorreu, ele poderá ficar ainda tentando várias vezes até desistir por time out. Se o teu firewall é o roteador principal, não tem porque escondê-lo, pois ele é um ponto de rota mesmo. Mas se ele for transparente (atuando em modo bridge), aí pode ser uma boa estratégia não dar nada ao remetente.
• ACCEPT: Aceita um pacote, deixando que ele siga o seu percurso. O ACCEPT, como os anteriores, causa o término de teste nesta tabela, ou seja, o pacote já foi aceito e não será mais testado por nenhuma outra regra posterior nesta tabela (mas ainda poderá ser testado por outra tabela, como pela mangle ou nat, por exemplo. Acredito que o único exemplo onde isto possa acontecer é ele ser ACEITO no filter FORWARD, mas ser DROPADO no nat POSTROUTING, já que o nat tem também o poder de realizar DROP).
• LOG: realiza um log deste pacote no sistema (geralmente no /var/log/syslog ou messages). Ao contrário das demais ações (DROP, ACCEPT e REJECT), ao aplicar um log no pacote o mesmo ainda continua sendo testado pelas regras seguintes da fila atual. Uma ação do tipo LOG não causa o término do teste. Caso seja do interesse do usuário ele pode configurar uma mensagem de log que aparecerá nos logs facilitando a análise.

Este artigo teve como motivação apenas mostrar a estrutura interna do iptables e não ensinar a escrever regras sintaticamente corretas e poderosas.

Através do entendimento correto de como o iptables atua, pode-se determinar onde e de que forma pacotes devem ser filtrados:

• Se estou configurando um firewall pessoal, na minha máquina desktop ou no meu servidor, sendo que ela não é roteador: as regras para filtrar o conteúdo deverão ir na tabela filter, na lista INPUT para filtrar o que está entrando na minha máquina, destinada ao IP dela e na tabela filter, lista OUTPUT para os pacotes gerados pela minha máquina.
• Se estou configurando um firewall de rede, que filtra todo o conteúdo que entra e sai da minha rede para o mundo: as regras irão todas na tabela filter, lista FORWARD. Para representar o destino (está entrando ou está saindo) posso usar o parâmetro -i interface ou -o interface (o FORWARD é o único que permite -i e -o na mesma regra, querendo dizer, se estiver entrando por aqui e saindo por ali…).
• Se meu firewall é um firewall de rede, mas também possui alguns serviços nele, como proxy ou de email, devo inserir regras tando no filter INPUT/OUTPUT para definir a política dele enquanto servidor, como no filter FORWARD para proteger minha rede. Regras adicionadas no filter FORWARD não atuam sobre pacotes destinados ao número IP de uma máquina.
• Se desejo alterar características de ip ou porta, trocando-as, devo usar a tabela nat e para isto preciso aguardar o próximo artigo. 😀