Re: problemas com iptables
1- se eu fizer um FORWARD de portas, elas necessariamente "passam"
pelo firewall e são redirecionadas para a rede interna, corrreto?
Hum... Não entendi muito bem, mas essa história de redirecionar não
está ligada às regras da chain FORWARD, mas sim às regras que você
tiver na tabela NAT. Quero dizer, é alí que acontece a tradução de
endereços. Depois de trocados os endereços de destino/origem, quem
roteia os pacotes para dentro e fora da sua rede é o kernel, e nessa
etapa é que o pacote passa pela "corrente" FORWARD.
2 - se eu fizer um
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 22 -j DNAT
--to-destination 10.0.0.14
iptables -t nat -A POSTROUTING -s 10.0.0.14 -j SNAT --to-source 10.0.0.1
os pacotes vão direto para a máquina especificada da rede interna, sem
ao menos "passar" pelo firewall, ou seja, elas são redirecionadas,
certo ?
Os pacotes chegando pela no firewall pela interface eth0, na porta 22,
tem seu endereço de destino trocados para a estação dentro da rede.
Depois o kernel roteia.
Amigo, desculpa se for bobagem e eu estive boiando, mas porque essa
segunda regra, fazendo SNAT ? Você já não está fazendo MASQUERADE pra
rede toda? Isso basta para que você consiga estabelecer as conexões
com sua máquina interna e trabalhar normalmente.
3 - outra coisa, se eu crio as regras para conexão que passam pelo
firewall, para conexões que são redirecionadas pela firewall, e eu
preciso rodar um "apt-get update" e baixar atualizações para o próprio
firewall, eu tenho no caso que liberar uma porta em INPUT, correto ?
Pra você estabelecer conexões a partir do firewall, é suficiente a
regra que você tem que permite pacotes com estado RELATED,STABLISHED
entrem (chain INPUT).
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Isso se chama STATEFULL - você aceita tudo que chegar
STABLISHED,RELATED , porque pra isso, teoricamente tem que ter saído
um pacote NEW da sua máquina.
Sacou? Você permite que pacotes de conexões estabelecidas (STABLISHED)
ou pacotes em resposta a um pedido de conexão (RELATED) "entrem" na
sua máquina. Mas NEW você não permite, a não ser que seja de sua
vontade, para servir algum serviço.
Assim, quem pede uma conexão é você - e isso sai pela chain OUTPUT - e
depois você aceita o restante dos pacotes dessa conexão.
Tome cuidado pra não fazer DNAT de uma porta do servidor que você usa
pra algum daemon, porque quando um pacote chega nessa porta ele vai
ser redirecionado pra outra máquina, como você faz com as portas 21 e
22.
Agora, eu omiti um pequeno detalhe. Quando eu fui escrever um script
de firewall pra um servidor que montei, usando filtragem por
STATEFULL, dessa mesma maneira que você faz, tive um sério problema,
inexplicado até agora, e acabei resolvendo de uma maneira que me gera
uma certa falha de segurança.
Bom, o problema era que simplesmente a regra que permitia que pacotes
STABLISHED,RELATED trafegassem não era suficiente pra que eu
conseguisse fazer conexões do firewall pra fora.
Sim, eu conferi muito bem todas as regras, e simplesmente não fazia
sentido o que acontecia. Era como se o pacote mudasse de estado ao
tentar ser casado com as regras!!!
É, eu sei que não faz sentido, mas acabei largando pois não pude mais
testar e nem tive saco.
Resolvi adicionando duas regras no final da minha chain INPUT.
$IPTABLES -A INPUT -p tcp -m state --state ! ESTABLISHED,RELATED -j DROP
$IPTABLES -A INPUT -j ACCEPT
O que eu faço aí é bloquear tudo que não for STABLISHED nem RELATED, e
depois aceito tudo. Claro que a regra de aceitar tudo seria fatal se
antes não tivesse essa regra restritiva.
Enfim, é considerado uma falha de segurança, principalmente porque
essa última regra aí no final assusta, mas na minha situação veio a
calhar.
bom são algumas duvidas que gostaria de tirar
obrigado, abraço.
É isso. Se cometi algum erro, avisem-me, por favor.
--
Att,
Clayton Nogueira
Analista de Suporte
Linux User nro. #448808
Reply to: