Icefusion

Na verdade este não é um artigo, é uma conversa no IRC que tivemos sobre firewall e o fallen nos deu essa excelente explicação no canal IRC #slackware-br da rede Freenode. Eu recomendo muito esta explicação pois foi muito esclarecedora para mim e outros admins que também fazem parte do canal.

<icefusion> fallen, A Chain Forward serve apenas para bloquear ou liberar o roteamento..quem faz o roteamento é o nat?

<fallen> icefusion: essa descricao usa palavras de sentido mto amplo ou ambiguo

<pksato> icefusion: para controlar o fruxo do roteamento.

<fallen> iptables nao eh feito pra roteamento

<fallen> embora ele possa interferir em roteamento

<fallen> vc sabe o q eh nat?

<icefusion> fallen, ele pode bloquear ou liberar acesso

<fallen> vamos por partes

<fallen> vc sabe o q eh nat?

<icefusion> sim

<fallen> icefusion: se sua definicao de nat eh essa, focalinux pra vc

<fallen> vc precisa saber os fundamentos das coisas

<icefusion> fallen, nat server para resscrever os ips de origem de um pacote q passam num roteador ou firewall para q um computador numa rede interna tenha acesso à rede externa

<icefusion> fallen, seria isso correto?

<fallen> ja comecou errado

<icefusion> fallen, hmm..entaum meu conceita está errado

<icefusion> *conceito

<fallen> nat e server eh como comparar laranjas com raiz quadrada

<fallen> nat eh um processo

<fallen> Network Address Translation

<icefusion> deculpe naum eh server eh serve

<fallen> por que se prender a ips de origem?

<fallen> vc nao pode reescrever ips de destino?

<icefusion> fallen, sim

<fallen> abra sua cabecinha e pare de pensar em computadores e rede interna, pensa no sentido amplo

<icefusion> fallen, hmm

<fallen> nat eh o processo de alterar cabecalhos dos pacotes

<icefusion> certo

<fallen> sua pergunta original era sobre pra que serve a chain forward

<icefusion> fallen, exato

<fallen> primeiro refaca-a da forma completa e correta: pra que serve a chain forward da tabela filter

<fallen> a arquitetura do netfilter trabalha com diversas tabelas – que representam as fases pelas quais o pacote passa ao entrar/sair da pilha do kernel

<fallen> a tabela de filter eh a que trabalha com filtragem (meio obvio, nao?)

<icefusion> certo..a mangle, filter e a nat

<fallen> tem as 3 chains basicas: input, output e forward

<fallen> entenda a pilha do kernel como uma caixa preta que manipula os pacotes de rede

<fallen> faz todas as coisas feias que precisa pro tcp/udp/ip/whatever funcionarem

<fallen> tudo o que esta entrando na pilha pra ser tratado – depois que as feiras de transporte de rede ja foram resolvidas – passam pela input

<icefusion> fallen, certo

<fallen> tudo que esta saindo da pilha pra voltar pro dispositivo de rede certo passa pela output

<fallen> e tudo o que passa pela pilha qdo esta esta em modo de gateway, passa pela forward

<fallen> gateway – um pacote que NAO eh pro kernel mas passa atravez dele pra ir pra outro lugar

<icefusion> fallen, certo…compreendi

<fallen> gateway = portal – tem q passar por ele

<icefusion> fallen, ponte para algum lugar

 

<fallen> a chain forward funciona tratando o trafego de “gateway”

<icefusion> fallen, xo ver se eu entendi…

<icefusion> fallen, ela trata toda a informação q naum eh pro kernel daquele dispositivo q ta tratando a informação

<fallen> quase isso

<fallen> tem q se expressar claramente, senao vc se confunde

<icefusion> hm

<fallen> a chain forward trata tudo que NAO eh diretamente “pra maquina”, mas que tem q passar por ela

<icefusion> entendi

<fallen> note que o kernel do linux NAO faz isso automagicamente: tudo que nao eh pra um endereco IP atribuido a uma placa, eh descartado

<fallen> pra isso tem que ativar ip_forward com aquele echo amigo no /proc ou via sysctl (q eh um jeito mais elegante de fazer a mesma merda)

<icefusion> fallen, vamos dizer q eu tenho um ssh numa máquina 192.168.1.2, porém meu firewall eh o 192.168.1.3, e eu vou acessar de casa, eh a forward q vai tratar isso

<fallen> o forward trata PARTE disso

<fallen> ele faz parte do FILTER

<icefusion> fallen, entendi

<fallen> pacote do 200.200.200.200 pra 192.168.1.2, ok, deixo passar

<fallen> vc vai precisar da ajuda de outra parte do netfilter pra fazer isso acontecer

<icefusion> fallen, ae q entra a tabela nat?

<fallen> se pensarmos nesse exemplo, o pacote nao vai pro 192.168.1.2, ele chega pro ip da placa do fw

<fallen> supondo que seu ip na net seja 200.10.10.10, vai chegar pra ele

<fallen> sim, ai que entra a tabela de nat

<fallen> que TRADUZ/TRANSLITERA os ENDERECOS do pacote

<fallen> address – translation

<fallen> na tabela de NAT do netfilter tem PREROUTING, POSTROUTING e OUTPUT

<fallen> PRE-routing = pre-roteamento – antes do kernel resolver o que vai fazer com o pacote

<icefusion> no caso internamente o nat trocaria o cabeçalho de destino velho pelo novo endereço internoo qual ele vai ser encaminhado

<fallen> nao confunda a palavra ROUTING nessas chains com o roteamento da maquina

<fallen> eh so pra dizer o que acontece antes ou depois do kernel fazer o roteamento

<icefusion> entendi

<fallen> isso

<icefusion> \o/

<icefusion> to fikando menos bobo

<fallen> o pacote chegou, ANTES que eu decida o que fazer com ele, eu consulto a tabela que diz que sob tais condicoes, eh pra eu traduzir o destino pro IP 192.168.1.2

<fallen> icefusion: vc entende o conceito de firewall stateful?

<icefusion> naum

<fallen> um sistema stateful – que entende ESTADOS dos pacotes e das conexoes – vai guardar uma informacao numa tabelinha dizendo que a conexao de ID tal esta sofrendo nat de destino pro IP tal

<fallen> qdo o sistema enxergar pacotes passando com esse id, ele vai cuidar de acertar origem e destino disso

<icefusion> fallen, certo

<fallen> sistema que eh stateless, a cada vez q o pacote passa pelo sistema, ele tem q passar pelas regras tudo de novo. no stateful, ele pula isso tudo qdo ja tem cache na tabelinha dele

<icefusion> certo

<icefusion> fallen, entaum roteadores saum stateful

<fallen> no caso do seu NAT de destino, vc pode REMOVER a regra do netfilter que continua funcionando a conexao ja estabelecida

<fallen> icefusion: defina roteadores

<fallen> vc esta se referindo ao elemento de rede “roteador” ou aos modens adsl chamados de roteadores

<icefusion> fallen, esses roteadores q interliga a internet

<icefusion> fallen, elemento de rede

<fallen> icefusion: de novo, vc precisa de clareza

<fallen> roteador NAO lida com conexao

<fallen> a principio, nao

<icefusion> hmm

<fallen> roteador lida com ROTAS

<fallen> (duh)

<fallen> pacotes pra ESSE ip, eu faco sair por essa rota pro proximo roteador, pacotes pra AQUELE ip, sai pela outra porta pra um outro roteador

<icefusion> fallen, soh tem tabela de roteamento e nada de filtragem nem nada entaum

<fallen> icefusion: o papel do roteador NAO eh filtrar – eh rotear. alguns equipamentos agregam funcoes, mas mantenha o foco em roteadores que so roteiam pra nao confundir as coisas

<icefusion> blz

<icefusion> entendi

<fallen> stateful ou stateless se refere a capacidade de rastrear o estado da conexao

<fallen> se esta aberto, fechado, se ESSA conexao usa alguma outra porta…

<icefusion> fallen, entaum o forward filtra o pacote para saber se ele eh permitido prosseguir, caso seja permitido ele eh tratado pela regra de nat

<fallen> o PRE-routing entra antes

* icefusion espera naum ter falado merda desta vez

<icefusion> lol

<fallen> veja soh

<icefusion> fallen, entendi

<fallen> pacotinho vindo do 200.200.200.200 pra 200.10.10.10

<fallen> o pre-routing traduz que na verdade, eh 200.200.200.200 pra 192.168.1.2

<icefusion> certo

<pksato> nao se esqueca que a comunicacao e bi direcional.

<fallen> ai vc libera ou nao pra atravessar

<icefusion> entendi

<icefusion> se fosse post, entaum ele filtraria primeiro

<icefusion> depois seria tratado pelo nat

<fallen> o post fica DEPOIS de filter

<fallen> pre-routing – filter – post-routing

<fallen> assim fica facil eu saber – no filter – quem esta falando com quem

<fallen> vc viu o caminho do pacotinho chegando

<fallen> agora pensa nele saindo

<fallen> de 192.168.1.2 pra 100.100.100.100 (por ex)

<fallen> como seu ip interno nao funfa na net, vc vai precisar fazer um nat – address translation – pra mexer na origem do pacote pra faze-lo parecer que saiu do fw, o dono do 200.10.10.10

<fallen> senao o camarada do outro lado nao sabe pra quem responder

<fallen> pensa agora q zona ficaria no filter se o POST-routing acontecesse antes dele

<fallen> ele so iria “enxergar” pacotes saindo do firewall e indo pro 100.100.100.100

<icefusion> entedi

<fallen> por isso ele so faz o nat de origem depois que ele ja fez a filtragem – assim vc sabe q eh o 192.168.1.2 tentando falar com o 100.100.100.100

<icefusion>

<icefusion> entendi..to fikando menos burro

<icefusion> haha

<fallen> so pra fazer o nat, a tabela OUTPUT do nat mexe com pacotes gerados pelo proprio kernel/maquina

<fallen> so pra fechar*

<icefusion> fallen, eu ia perguntar isso agora haha

<icefusion> fallen, pra que serve a output da nat

<fallen> a tabela mangle faz quase a mesma coisa que a de nat faz, so que com o resto das informacoes de cabecalho do pacotes fora origem/destino

<icefusion> entendi

<fallen> mangle pode ser traduzido como mutilar

<fallen> cortar, mudar, remexer, refazer o cabecalho do pacote

<icefusion> entendi

<fallen> mangle pode ser traduzido como mutilar

<fallen> cortar, mudar, remexer, refazer o cabecalho do pacote

<fallen> icefusion: agora sobre teoria de tcp/ip: vc sabe que cada pacote gera pelo menos 1 outro, certo?

<icefusion> fallen, nops

<icefusion> fallen, naum sabia até vc me dizer haha

<fallen> pilha tcp: ‘to mandando um pacote.’ —> ‘ok, recebi o pacote’

<icefusion> ah tah

<fallen> ‘quero abrir uma conexao pra porta 85 ai da sua maquina’ ‘ok, aberto’

<fallen> o host tem q responder e confirmar que recebeu e entendeu o pacote

<icefusion> tipo, vc manda um pacote e obtem uma resposta (seria os 2 pacotes no mínimo

<fallen> esse pacotinho de volta eh popularmente conhecido por “ack” de “acknowledge”

<icefusion> isso

<fallen> icefusion: eh a funcao do tcp ip: manter uma conexao e certificar-se que os pacotes chegam integros

<fallen> TRANSFER CONTROL PROTOCOL – protocolo de controle de transferencia

<icefusion> fallen,eh mesmo …eu esqueci das aulas de rede :#

<fallen> por vezes, uma mensagem IP eh quebrada em pedacos – fragmentada – e a pilha do outro lado precisa coloca-los em ordem antes de passar pra frente pros aplicativos lidarem com a informacao

<fallen> nem semrpe eles chegam em ordem

<fallen> nem sempre chegam integros

<fallen> ai q o ack entra na jogada

<icefusion> fallen, por isso tem o ack

<guax> nem sempre chegam

<fallen> entendeu a funcao dele, pelo menos por cima?

<icefusion> fallen, sim sim

<fallen> tambem, nem sempre chegam

<icefusion> e o ack nem sempre chega tb?

<fallen> entao, qdo vc faz regras de iptables/netfilter tem q levar isso em conta

<guax> icefusion, não

<fallen> icefusion: se o ack nao chegar, o host manda de novo

<icefusion> entendi

<fallen> eh a funcao da pilha tcp: cuidar dessa bagunca

<icefusion> fallen, hmmmmmmmmm

<fallen> icefusion: novamente entra a funcao stateful

<fallen> se o iptables NAO fosse stateful, vc precisaria de uma regrinhas liberando o caminho de volta pros ACKs chegarem pra quem mandou

<fallen> como ele EH stateful, basta vc falar pra ele assim oh oh: se vira negao

 

<icefusion> fallen, ele ja “grava o caminho do pacote para o retorno”

<icefusion> seria isso?

<fallen> olha a magica: -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT

<fallen> (tanto INPUT qto forward e output)

<fallen> viu ali “-m state”?

<icefusion> fallen, sim

<fallen> icefusion: eh o modulo “state” do netfilter que cuida disso: ele consulta as tabelas de conntrack – connection tracking

<fallen> aquela linha ta dizendo “se o pacote ja tiver estado no cache, e for ou de uma conexao estabelecida ou relacionada, deixa passar”

<fallen> ai vc pergunta: como pode uma conexao estar RELACIONADA a outra?

<fallen> icefusion: hein hein hein, como uma conexao se relaciona com a outra?

<NoFX_SBC> fallen, quando o servico usa mais de uma porta por exemplo!?!?

<fallen> ouieah!

<fallen> exemplo mais simples do mundo: ftp!

<fallen> qdo vc conecta no ftp, ele abre uma conexao na porta 21 do servidor

<fallen> ate ai, facil facil

<icefusion> fallen, entendo

<fallen> ai qdo vc da um “ls”, a magica acontece: o servidor fala assim: ok, te mando os dados do ls, mas vc vai ter q abrir uma porta pra eu mandar de volta ai

<fallen> em geral, o servidor espera que VOCE abra a porta 20 na sua maquina pra ele conectar e mandar a saida do ls

<fallen> e ai, como fica o firewall na jogada? como ele vai adivinhar que a porta 20 eh pra ser direcionada pra vc?

<fallen> mesmo que vc redirecione a porta 20 no fw pra sua maquina, e ai? ninguem mais usa ftp na rede?

<icefusion> fallen, udontknow

<icefusion> fallen, num sei…fikei em duvida

<fallen> o conntrack eh esperto. ele fica ouvindo conexoes de protocolos que ele conhece – como o ftp – e fica esperando o comando pra abrir a porta no ftp

* estranho has quit (Read error: Connection reset by peer)

<fallen> nesse momento, ele sai da tocaia e pula em cima do pacotinho, e muda a linha pra corresponder ao IP dele

<fallen> ip e porta certa

<icefusion> fallen, ele ja sabe a porta q vai enviar a resposta sabendo a conexão q esta vindo

<fallen> alem de fazer o forward necessario pra aquela conexao especifica

<fallen> sim!

<fallen> ai eh que entra o RELATED: a abertura de conexao nao eh um estado novo no firewall, eh uma conexao relacionada a outra

<icefusion> entendi

<fallen> essa era a boa noticia: a mah noticia eh que o conntrack precisa conhecer E interpretar o protocolo

<icefusion> fallen, hehe

<fallen> se vc olhar nos modulos do iptables/netfilter, tem um modulo pra cada protocolo que o conntrack entende

<fallen> nf_conntrack_ftp.ko por ex

<fallen> esse eh o camaradinha que mantem o estado do firewall atualizado com as reviravoltas da conexao – quem conectou aonde, quem esta esperando uma abertura de porta pra mandar informacao…

<icefusion> fallen, caso eu mude a porta do ftp q eu vou conectar de 21 para seri-la 8888

<fallen> tem um OUTRO camaradinha q eh o irmao gemulo desse: nf_nat_ftp.ko

<icefusion> fallen, mesmo assim ele sabera pois ele conhece o protocolo

<fallen> ele cuida de abrir quaisquer conexoes de volta que o protocolo precisa

<fallen> icefusion: sim, eh especifico pra cada protocolo

<icefusion> q massa

<fallen> se vc mudar a porta do protocolo, precisa informar ao modulo que vc mudou

<fallen> da um modinfo nf_conntrack_ftp

<fallen> q vc vai ver que tem paramentros pra passar pro modulo