Marcelo Gondim (gondim@databras.com.br)
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.
________
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.
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
gondim@databras.com.br
Rio de Janeiro - RJ
O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação) notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter histórico, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.