Pesquisar
Newsletter
| Explicação sobre Firewall |
|
|
|
| Escrito por icefusion | |
| Sex, 18 de Junho de 2010 11:37 | |
|
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 :D <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 :D <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 :D <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> :D <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 :D <fallen> mangle pode ser traduzido como mutilar <fallen> cortar, mudar, remexer, refazer o cabecalho do pacote <icefusion> entendi :D <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 :D <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
|










