Diferen�as no Fluxo de Dados entre ipfwadm, ipchains e iptables
Marcelo Gondim ([EMAIL PROTECTED])
Este documento tem o objetivo de esclarecer algumas diferen�as em rela��o a
filtro de pacotes e suas mudan�as desde o Kernel 2.0 at� o �ltimo Kernel
2.4. O documento n�o � muito extenso mas acredito esclarecer principalmente
as diferen�as nos Fluxos de Dados entre esses Kernels. Traz tamb�m uma
amostra de como pode ser feito o NAT 1:1 e o STATEFUL PACKET com o iptables.
Fluxo com IPFWADM e IPCHAINS (Kernel 2.0 e 2.2 respectivamente)
INPUT
________
INPUT | | INPUT
-------> |FIREWALL| <-------
|________|
dados eth0 eth1 dados
Quaisquer pacotes de dados cujo sentido seja o Firewall � considerado como
INPUT n�o importando de onde venham.
As regras de INPUT s�o consideradas as mais importantes regras em um
Firewall e que normalmente a configuramos como sendo DENY por default. Pois
sempre ser� mais seguro negar tudo no filtro e apenas liberar as portas e
IPs que se deseja utilizar e nunca o inverso.
FORWARD
________
| |
|FIREWALL|
|________|
eth0 eth1
^ ^
|dados|
+-----+
FORWARD
Quaisquer passagens de pacotes entre interfaces no Firewall, � considerado
como sendo FORWARD, n�o importando o sentido do pacote e sim a mudan�a de
interface.
O curioso � que n�o existe regra para se restringir acesso entre interfaces
no FORWARD. Ex.: n�o posso criar uma regra que negue determinado acesso
vindo pela interface eth0 e que cujo destino seja a interface eth1. As
minhas regras s�o limitadas apenas a IPs, portas e protocolos em um FORWARD.
Veremos que isso ir� mudar com o iptables.
Tamb�m costumamos defini-lo por default como sendo DENY.
Obs.: n�o existem regras de FORWARD para maquinas que possuam apenas uma
interface de rede conectadas ao micro, mas pode passar a existir se nessa
mesma m�quina for utilizado um modem para acesso remoto a outra rede. Ex.:
eth0 - interface de rede // ppp0 - interface representada pelo modem. Nesse
caso passo a ter duas interfaces e com isso um poss�vel FORWARD. Podemos at�
admitir que na m�quina onde haja roteamento entre redes poderemos
implementar regras de FOWARD.
OUTPUT
________
OUTPUT | | OUTPUT
<------- |FIREWALL| ------->
dados |________| dados
eth0 eth1
O mesmo acontece com qualquer sa�da de pacote de dados do Firewall, todas as
sa�das s�o consideradas OUTPUT.
As regras de OUTPUT nem sempre s�o utilizadas pois s�o as �ltimas regras do
filtro pelos quais os pacotes de dados passam antes de �rem para a rede.
Nesse momento alguns administradores admitem terem filtrado ao m�ximo os
dados que passaram pelas regras de INPUT e FORWARD do Firewall.
Fluxo com IPTABLES (Kernel 2.4)
FORWARD
NAT dados NAT
(PREROUTING ) <------------------------------------> (PREROUTING )
(POSTROUTING) ^ | ________ | ^ (POSTROUTING)
| | INPUT | | INPUT | |
dados | +------> |FIREWALL| <------+ | dados
+--------- |________| ---------+
OUTPUT eth0 eth1 OUTPUT
Como podemos observar, temos algumas fases que n�o existiam no IPFWADM e
IPCHAINS e as que existiam tiveram o seu fluxo de dados alterado. Vamos
ent�o analis�-los:
Para os administradores que sonhavam com NAT(Network Address Translation)
agora podem implement�-lo com o IPTABLES no kernel 2.4. Vamos � alguns
exemplos:
_______ ________
| | | |
| | | |
| HTTP | |Firewall| _________
| Server| | | | ROUTER | <==> INTERNET
| |-------------| |------|_________|
|_______| |________| 200.222.5.254
192.168.0.2 192.168.0.1 200.222.5.1
200.222.5.2
Firewall:
eth1 = 192.168.0.1
eth0 = 200.222.5.1
eth0:0 = 200.222.5.2
NAT = 192.168.0.2 <==> 200.222.5.2
Com o NAT podemos trocar o IP n�o p�blico(192.168.0.2) pelo IP
p�blico(200.222.5.2) e vice-versa. Todo pacote que vir pela INTERNET para
acessar o servidor 200.222.5.2, passa pela regra PREROUTING do Firewall e
logo em seguida � feito um DNAT(destination NAT) que troca o IP destino
200.222.5.2 por 192.168.0.2 e em seguida o pacote � encaminhado para o
filtro, verificado nas regras de FORWARD e a� ent�o chega ao servidor
destino. Quando sa�r um pacote do IP 192.168.0.2 com destino a INTERNET, o
mesmo passa novamente pelas regras de FORWARD e logo em seguida passa para o
POSTROUTING que faz o SNAT(source NAT) onde � trocado o IP 192.168.0.2 pelo
IP 200.222.5.2 e a� sim vai para a INTERNET. O nome dado a esse tipo de
acesso � NAT 1:1.
Como puderam perceber os pacotes tanto de entrada quanto de sa�da n�o
passaram pelas regras de INPUT e OUTPUT, porque essas regras s� dizem
respeito a pocotes direcionados ao Firewall.
Qualquer pacote cujo destino seja o Firewall ent�o o mesmo passa pelas
regras de INPUT do Firewall e todo pacote que sair do Firewall passa pelas
regras de OUTPUT do mesmo.
Dessa forma temos como proteger mais ainda o Firewall pois podemos usar DENY
para qualquer regra INPUT pois isso n�o afetaria o acesso ao servidor HTTP
mostrado acima.
Para todos os pacotes de dados que passam de uma rede para outra atraves do
Firewall, passam pelas regras de FORWARD e agora com o iptables, podemos
especificar regras que controlem pacotes que entrem por uma interface em
espec�fico e saiam por outra interface.
Ex.: iptables -A FORWARD -p tcp --dport 80 -s 0/0 -i eth0 -o eth1 -j ACCEPT
O "-i" indica interface de entrada(input) e o "-o" interface de
sa�da(output). Lembrando que esses parametros n�o funcionam com o FORWARD do
IPCHAINS e IPFWADM.
Para fazer o NAT acima bastariam 2 regras:
iptables -A PREROUTING -t nat -d 200.222.5.2/32 -j DNAT --to 192.168.0.2
iptables -A POSTROUTING -t nat -s 192.168.0.2/32 -j SNAT --to 200.222.5.2
Obs.: N�o esquecam de criar o alias eth0:0 no Firewall com o IP 200.222.5.2
sen�o, n�o ir� funcionar. :)
Al�m disso o novo filtro traz o t�o esperado STATEFUL PACKET utilizado por
programas como o Firewall-1. Com esse recurso o filtro consegue gerenciar,
por exemplo, as conex�es feitas pelas esta��es e assim n�o deixar aberturas
para scanners atuarem como acontecia com o t�o conhecido protocolo FTP e
outros.
Exemplo:
Antigamente se fazia uma regra assim no Firewall para permitir que esta��es
pudecem acessar p�ginas na INTERNET:
ipchains -A input -p tcp -s 0/0 80 -d 0/0 1024: ! -y -j ACCEPT
Ou seja isto diz ao Firewall para aceitar qualquer pacote cuja porta origem
seja a 80/tcp que n�o seja do tipo SYN e isso pode ser muito bem utilizado
por scanners que utilizam pacotes ACK para checarem servi�os ativos.
Com o novo filtro ficaria assim:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Dessa forma o Firewall soh aceita conex�es estabelecidas pelas esta��es e
n�o precisamos deixar em aberto acessos vindos da porta 80/tcp, pois o
Firewall recusaria. Dessa forma os scanners foram anulados e podemos
respirar novamente com nossos servidores. :) Podemos tamb�m trabalhar com o
FTP em modo ativo, pois para cada conex�o 21/tcp o Firewall espera uma outra
conex�o 20/tcp de retorno, o filtro vai gerenciar isso.
Existem outras features no iptables mas essas eu achei as mais importantes e
por isso estou comentando-as aqui.
Desculpem qualquer erro, corre��es e sugest�es ser�o muito bem vidas e
servir�o para enriquecer.
O objetivo foi citar algumas diferen�as entre esses filtros e n�o ensinar a
us�-los.
Marcelo Gondim
[EMAIL PROTECTED]
Rio de Janeiro - RJ
----- Original Message -----
From: Threads <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 24, 2001 4:03 PM
Subject: (linux-br) substitui��o do ipmasqadm portfw por iptables
> Colegas da Lista, sds !
>
> Pelo que tenho observado nas d�vidas desta lista, houve mudan�as no que
diz
> respeito as regras de ipchains, ou melhor, houve uma substitui��o do
comando
> pelo iptables.
> Pude acompanhar alguns comandos de aplica��o de regras de iptables na
> Revista PC Master n� 49, por�m nada encontrei sobre a substitui��o do
> "ipmasqadm portfw" que venho utilizando com o RH 6.2 . Preciso fazer NAT e
> antes de atualizar o RH para o 7.1, preciso aprender mais sobre o
iptables.
> Por favor, algu�m pode me dar um help ?
>
> Agrade�o muito !
>
> Wagner Cavesso
>
>
>
>
Assinantes em 25/08/2001: 2265
Mensagens recebidas desde 07/01/1999: 129551
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
