IPTables - Desvendando o mistério

O iptables é uma ferramenta muitas vezes não utilizada por administradores iniciantes, assim como eu, que temem as linhas de comando. Neste tutorial meu foco é explicar e desvendar todo o mistério dessas "linhas malucas", que desempenham um papel tão importante quando se trata de administração de servidores e desktops.

[ Hits: 80.469 ]

Por: Odir em 14/01/2009


A lógica do iptables



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.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução e história
   2. A lógica do iptables
   3. Comandos e exemplos
   4. Instalação e uso
   5. Proteções e conclusão
Outros artigos deste autor

Microsoft x Resto - A soma de todas as partes

Leitura recomendada

Firewall profissional

Gerenciando regras de Iptables com Firewall Builder

Shorewall, uma excelente opção para firewall Linux

Mandrake Firewall - Firewall com interface amigável

Autenticação no Iptables

  
Comentários
[1] Comentário enviado por thiagofanfoni em 14/01/2009 - 13:35h

Parabens odirneto, isto é um assunto que sempre me interessou, porém eu nunca havia entendido muita coisa.
Gostaria de encontrar mais documentações utilizando uma linguagem tão simples como esta, de maneira que, até um leigo como eu consiga entender alguma coisa da maneira que eu entendi agora.

[2] Comentário enviado por renato_pacheco em 14/01/2009 - 14:03h

Sem querer ser chato, mas o iptables não é um firewall (apenas), ele tb é servidor nat e servidor proxy. Na verdade, ele tem a função d filtrar os pacotes (tanto é q tem o nome d netfilter, iptables é apenas o front-end dele).

[3] Comentário enviado por edipo.magrelo em 14/01/2009 - 14:28h

Parabéns pelo artigo..muito boa explicação sobre o iptables,melhor impossivel,bem detalhado e bem escrito.nota 10
valew

[4] Comentário enviado por cesar em 14/01/2009 - 14:45h

Boaa...gostei já até imprimi ;)

Parabéns..

[5] Comentário enviado por renato_pacheco em 14/01/2009 - 14:53h

Eu não havia lido totalmente o artigo. Gostei muito e os leigos têm a oportunidade d entender mais sobre o assunto. Achei muito criativo suas analogias, pq a maioria das pessoas q começam a mexer com iptables tem problemas com relação às ordens das regras.

Parabéns!

[6] Comentário enviado por odirneto em 14/01/2009 - 15:12h

Logo mais trarei a segunda parte, com algumas proteções extras!

[7] Comentário enviado por odirneto em 14/01/2009 - 15:12h

@ renato_pacheco

Eu sei que ele tem mais funções. Mas, resumindo bastante, o iptables é muito utilizado como firewall. Esse tutorial é mais simplão sabe, num entrei muito nos detalhes para aumentar ele. Mas obrigado de qualquer forma pelo toque, é importante para mim esse tipo de feed back. Agradeço os elogios logo mais farei mais tutoriais de como colocar alguams outras coisinhas online, ok?

@ Quem gostou.

Fico agradecido, mesmo! Obrigadão galera, vou sempre contribuir com novas coisas aqui mais ou menos na mesma idéia. Espero que vocês apreciem mais e mais.

[8] Comentário enviado por percival em 14/01/2009 - 15:38h

Fantástico !

Já está no Favoritos.

[9] Comentário enviado por willinocencio em 14/01/2009 - 16:34h

Neste ponto ai ....

# Proteção contra ip spoofing
iptables -A FORWARD -s $ENDEREÇOREDELOCAL -i ! eth0 -j DROP
iptables -A FORWARD -s ! $ENDEREÇOREDELOCAL -i eth0 -j DROP
iptables -A FORWARD -s $ENDEREÇOREDELOCAL -j DROP
iptables -A FORWARD -s $ENDEREÇOREDELOCAL -j DROP

As regras ...

iptables -A FORWARD -s $ENDEREÇOREDELOCAL -j DROP
iptables -A FORWARD -s $ENDEREÇOREDELOCAL -j DROP

Estão repetidas .... Não seria ...

iptables -A FORWARD -s $ENDEREÇOREDELOCAL -j DROP
iptables -A FORWARD -s ! $ENDEREÇOREDELOCAL -j DROP

Por que vc repetiou as regras duas xx ?

DESDE JÁ PARABÉNS PELO ARTIGO .... MUITO BEM REDIGIDO

[10] Comentário enviado por paulloal em 14/01/2009 - 16:57h

Oww.. gostei do artigo hein.. muito bom mesmo...
hehe.. legal seus exemplos...

[11] Comentário enviado por edsonmsj em 14/01/2009 - 17:31h

Até que enfim artigos com analogia, muito raros hoje em dia!

[12] Comentário enviado por tsanches em 14/01/2009 - 17:45h

Excelente artigo Odir, comecei segunda feira fazer o curso de iptables, e seu artigo me deu um norte, um rumo para chegar la e não ser tão "Cru".
Parabéns pela iniciativa, continue contribuindo!
Um grande abraço.
TSANCHES

[13] Comentário enviado por odirneto em 14/01/2009 - 17:51h

@ willinocencio

Na verdade isso foi um erro de digitação meu, eu copieo para montar as regras acimas dessas 2.. mas deu pau na hora e eu num vi. Só vi depois que publiquei. Vou entrar em contato com mod para ver se ele altera. Ok?

Obrigado pelo elogio =]

[14] Comentário enviado por renato.leite em 14/01/2009 - 20:37h

otimo artigo, ta de parabéns.

[15] Comentário enviado por smrabelo em 15/01/2009 - 11:42h

Parabéns! Ficou muito bem explicado e objetivo.
Que venha a parte 2!
=]

[16] Comentário enviado por gersonraymond em 15/01/2009 - 18:05h

Muito bom o Artigo !!! Super esclarecedor e meus parabéns pela forma, pela qual esclarece os processos do Iptables.

[17] Comentário enviado por elgio em 15/01/2009 - 18:59h

Parabéns pelo artigo, no entanto:

# Proteção contra syn flood
iptables -A FORWARD -p tcp --syn -m limit --limit 2/s -j ACCEPT

ISTO É UM ENGODO.
Não apenas não resolve como torna a negação de serviço MUITO MAIS FÁCIL!

Tenho lutado para que ninguém mais coloque esta FALSA proteção em seu Linux.

Só existe uma única maneira realmente 100% eficiente para Syn flood e ela se chama Syn cookie.
AS demais são inócuas ou, PIOR, como no caso desta, são um TIRO NO PÉ!

http://www.vivaolinux.com.br/artigo/Iptables-protege-contra-SYN-FLOOD/
http://rfc-editor.org/rfc/rfc4987.txt

[18] Comentário enviado por elgio em 15/01/2009 - 18:59h

Alias, inclusive o guia avançado foca traz esta sugestão de proteção. Cansei de enviar emails ao autor solicitando que ele corrija, todos SEM RESPOSTA. Considero um erro de altíssima gravidade, ate por que o Guia Foca é tido como uma referência... Lamentável..

[19] Comentário enviado por odirneto em 16/01/2009 - 00:19h

@ elgio

Peço desculpas, coloquei um exemplo, que realmente talves não seja funcional, como fizeram lá no proprio guia do foca. Mas enfim, peço desculpas por isso... nem precisava se exaltar não com isso.. era só me manda um e-mail se quisesse que eu teria todo o prazer em te atender.

Agora, você falou com um desdem tão feroz do meu tutorial.. com esse Lamentavel ou seu tiro no pé.. que eu to até envergonhado de ter postado ele aqui. Mal ae cara, da proxima vez eu guardo meus guiazinhos para mim mesmo, e deixo gente realmente muito mais experiente fazer tutoriais excelentes, tais como os seus ok?

Desculpa novamente.
Odir

[20] Comentário enviado por jose.freitas.rj em 16/01/2009 - 09:33h

Graaaaaaaaaande Odir! Cara, adorei seu post. Muito show! Estou aprendendo iptables tem alguns meses e pelo que vi seu post foi 1 dos melhores se não o melhor! :D :P
Agora, sobre o post a cima do nosso amigo geek " elgio", não é a primeira vez que ele comenta sobre esse "erro" do iptables num post aqui no VOL e não é a primeira vez que ela comenta dessa forma com uma pessoa que como eu, está aprendendo e que com o pouco de conhecimento que tem, quer passar a diante para outras pessoas aprenderem o iptables...
Não deixe de postar meu querido!

Vou deixar uma mensagem que diz o seguinte:

SE SUA ESTRELA NÃO BRILHA, NÃO TENTE APAGAR AS DOS OUTROS!

[21] Comentário enviado por elgio em 16/01/2009 - 09:54h

Explicar o que se diz é temerário...

Podia editar meu post anterior, mas convém explicá-lo:

1) Tiro no pé: a regra iptables para syn flood. E o é mesmo. Como não é você que inventou ela o tiro no pé não é o seu artigo, até porque o seu artigo não é sobre syn flood mas sobre configurações iptables.

2) Comecei meu comentário dando-lhe os parabens pelo artigo.

3) O "Lamentável" está (leia novamente!) ao final do meu comentário sobre o guia foca. Lamentável o guia foca ensinar isto. Lamentável o seu autor não o corrigir.

[22] Comentário enviado por odirneto em 16/01/2009 - 11:13h

Acho que foi um mal entendido então né elgio? Talves seu post não tenha ficado muito claro. Eu tava tentando fazer o meu melhor, as dicas, copiei direto do guia do foca e, de verdade, me esqueci dessa regra. Eu inclusive ja tinha lido o seu artigo sobre isso elgio, mas me falhou a memoria na hora de postar.

Sobre o seu parabens, eu agradeço. É que a proporção parabenização/reclamação ficou tão diferente que parece que só reclamou, sem falar a nota que voce deu né? Mas ta tudo bem. Muito obrigado de qualquer jeito, como disse, estou aprendendo, foi meu primeiro artigo. Espero que vocês tenham gostado.

Odir

[23] Comentário enviado por elgio em 16/01/2009 - 11:52h

Nota que eu dei?
Não dei nota alguma ao seu artigo (nem boa e nem ruim). Alias, não costumo dar notas aos artigos até porque não acredito muito neste sistema de notas do VOL.

[24] Comentário enviado por odirneto em 16/01/2009 - 11:59h

Então foi coincidencia, bem apos o teu comentario caiu um pouco minha nota. Acho que me enganei. Desculpe.

[25] Comentário enviado por elgio em 16/01/2009 - 12:07h

...

[26] Comentário enviado por elgio em 16/01/2009 - 12:08h

Alias, Ordir, este é o meu jeito. raramente compreendido.

Não costumo escrever linhas e linhas melosas elogiando isto ou aquilo.
Sou mais do estilo critico, pois acho que receber criticas de forma construtiva é o desejo de todo o autor.

Veja, eu li todo o seu artigo. Só me chamou a atenção esta do syn flood, um equívoco não seu e que não está relacionado com o artigo já que é apenas um exemplo.

Teu artigo é da linha dos que acho essenciais, pois não é a (chatérrima) receita de bolo do tipo "Faça um firewall mega power extreme em 5 segundos". Ensinar a pescar...

Quanto as notas, eu não acredito nelas pois os critérios de quem vota são duvidosos. Alguém só vota ou porque amou muito (e dá 10) ou porque odiou demais (e dá ZERO). E como muitos, infelizmente, querem mesmo receber as coisas de BARBADA e tem preguiça de aprender, tenho observado que as tais receitas de bolo são sempre bem votadas... :-D

[27] Comentário enviado por viniciuspedra em 16/01/2009 - 12:12h

opa! gostei mto do artigo! parabens.

[28] Comentário enviado por odirneto em 16/01/2009 - 12:19h

Entendi elgio... Sem problemas cara =]

Eu concordo com você, acredito que seja meio falho isso tambem.. Mãããs, eu não sou adm daqui hehehe.

Po cara, depois me passa um e-mail seu, vamos trocar umas 'figurinhas' =]

meu email é odirneto@petmais.net

[29] Comentário enviado por tuxSoares em 18/01/2009 - 00:04h

Olá,

parabéns pelo seu artigo, como ele possui uma linguagem simples e objetiva fica fácil de entender os passos básicos de como funciona "essa encrenca" de iptables.
Trabalho com o iptables a 4 anos, se quando comecei tivesse encontrado um artigo desse nível as coisas teriam sido muito mais descomplicadas, por isso minha felicitação ao seu artigo, parabéns mesmo.

Grande abraço.


[30] Comentário enviado por vaini em 21/12/2009 - 21:17h

beleza de artigo...esse alem dos favoritos, vai pra impressora tb...valew

[31] Comentário enviado por julio_hoffimann em 22/02/2010 - 11:55h

Valeu Odir!

O artigo me ajudou bastante, não sou da área e pude entender claramente o que foi dito.

Obrigado!

[32] Comentário enviado por abelfrancia em 25/04/2012 - 16:31h

Obrigado pelo artigo! Me ajudou muito, a tempos queria subir um firewall nem que seja com um script básico de segurança (contra ping da morte e lá vai).

E graças seu artigo isso foi possivel, tks!

Abraços,


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts