DNAT iptables bug or connection tracking issue?

DNAT iptables bug or connection tracking issue?

[Irmãos Bocchi & CIA Ltda]

Dear friends

I have a question, and I need your help to solve.

1) I have two routers in two different networks: one is a FreeBSD 7.0 
router, here called "Router A" and another is a Debian 4.0 router, here 
called "Router B"
2) The Router A uses pf to make the firewall rules, with standard 
installation. The Router B have the kernel 2.6.25.4 and iptables 1.4.0
3) In the first router, I have a rule to access my vnc server in a 
windows machine. To make these, I need to create this rule
rdr on sk0 proto tcp from any to <my external addr> port 5900 -> <my 
internal addr> port 5900
nat on sk0 proto tcp from <my internal addr> port 5900 to any -> sk0

In resume: I need to create a rule to make the redirection and, after 
these, I need to insert a rule to make the nat

4) In the second router, only adding this rule
iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 5900 -j DNAT 
--to-destination <my internal addr> port 5900

THE RULES WORK PERFECTLY!

It's a bug? Because, in my vision, I need to create the two rules, the 
DNAT rule and the MASQUERADE rule to these work.
Another point of view: If I need to permit only the machines A, B and C 
to access the VNC, in BSD, I only need to create these rules

my_servers="{ server_a_addr, server_b_addr, server_c_addr }"
rdr on sk0 proto tcp from any to <my external addr> port 5900 -> <my 
internal addr> port 5900
nat on sk0 proto tcp from <my internal addr> port 5900 to $my_servers -> sk0

or

rdr on sk0 proto tcp from $my_servers to <my external addr> port 5900 -> 
<my internal addr> port 5900
nat on sk0 proto tcp from <my internal addr> port 5900 to any -> sk0

How I can make these in iptables?

Thanks for your answer

-- 
+------------------------------------------
| Att                                      
| Lucas Willian Bocchi
| Departamento de Tecnologia da Informação
| Setor de Redes, Suporte e Desenvolvimento
| Irmãos Bocchi & CIA Ltda
+-------------------------------------------



------------------------------------------------
Os e-mails enviados por este domínio são verificados
por sistemas antivírus e antispam, visando a proteção
dos usuários e dos equipamentos de nossa empresa, bem como
para proteger o conteúdo e o trabalho de outros que
por ventura venham receber e-mails deste domínio.

O Grupo Bocchi se reserva no direito de, a qualquer
momento, bloquear ou inutilizar conteúdo de e-mails
que venham a ser prejudiciais para o ambiente de trabalho.

Caso este e-mail não possua conteúdo que seja relevante
à sua atividade profissional, ou a do usuário que a enviou,
por favor, delete-o imediatamente.

O Grupo Bocchi não se responsabiliza por qualquer dano 
ou prejuízo que a utilização indevida deste e-mail
possa causar a você ou sua empresa.

Em caso de dúvidas, favor entrar em contato.
---------------------------------------------


Grupo Irmãos Bocchi & Cia Ltda

http://www.ibocchi.com.br

Re: DNAT iptables bug or connection tracking issue?

[Josh Cepek]

[-- Attachment #1: Type: text/plain, Size: 3769 bytes --]

Irmãos Bocchi & CIA Ltda wrote:
> 1) I have two routers in two different networks: one is a FreeBSD 7.0 
> router, here called "Router A" and another is a Debian 4.0 router, 
> here called "Router B"
> 2) The Router A uses pf to make the firewall rules, with standard 
> installation. The Router B have the kernel 2.6.25.4 and iptables 1.4.0
> 3) In the first router, I have a rule to access my vnc server in a 
> windows machine. To make these, I need to create this rule
> rdr on sk0 proto tcp from any to <my external addr> port 5900 -> <my 
> internal addr> port 5900
> nat on sk0 proto tcp from <my internal addr> port 5900 to any -> sk0
>
> In resume: I need to create a rule to make the redirection and, after 
> these, I need to insert a rule to make the nat
>
> 4) In the second router, only adding this rule
> iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 5900 -j DNAT 
> --to-destination <my internal addr> port 5900
>
> THE RULES WORK PERFECTLY!
>
> It's a bug? Because, in my vision, I need to create the two rules, the 
> DNAT rule and the MASQUERADE rule to these work.

Typically when you have a LAN behind NAT you use either MASQUERADE or 
SNAT on all packets going out the public interface.  It doesn't make 
sense to do so only for certain packets; if you intend to filter traffic 
to prevent it from going out to the Internet you should do so in the 
filter table, not by preventing NAT from occurring (which won't 
necessarily stop the packet from being forwarded.)

> Another point of view: If I need to permit only the machines A, B and 
> C to access the VNC, in BSD, I only need to create these rules
>
> my_servers="{ server_a_addr, server_b_addr, server_c_addr }"
> rdr on sk0 proto tcp from any to <my external addr> port 5900 -> <my 
> internal addr> port 5900
> nat on sk0 proto tcp from <my internal addr> port 5900 to $my_servers 
> -> sk0
>
> or
>
> rdr on sk0 proto tcp from $my_servers to <my external addr> port 5900 
> -> <my internal addr> port 5900
> nat on sk0 proto tcp from <my internal addr> port 5900 to any -> sk0
>
> How I can make these in iptables?

The easiest way is probably to create a user-defined chain containing 
tests for the IP's you want to allow to connect to this port.  If you 
include a rule to allow ESTABLISHED traffic prior to the jump to 
vnc_access only the first packet in the connection will need to traverse 
the list of IP's to allow.  Something like this should accomplish the 
task (along with the NAT rule you listed above):

iptables -N vnc_access
iptables -A vnc_access -s server_a_addr -j ACCEPT
iptables -A vnc_access -s server_b_addr -j ACCEPT
iptables -A vnc_access -s server_c_addr -j ACCEPT
iptables -A vnc_access -j DROP

[... other rules may go here ...]

iptables -A FORWARD -d <internal addr> -p tcp --dport 5900 -j vnc_access

If you have many IP's you want to add to the vnc_access chain, another 
way to write that first portion by using a bash for-loop might be as 
follows:

my_servers="server_a_addr server_b_addr server_c_addr"
iptables -N vnc_access
for ip in $my_servers; do
    iptables -A vnc_access -s $ip -j ACCEPT
done
iptables -A vnc_access -j DROP

For many hundreds or thousands of IP's you probably want to look at 
ipsets for a performance increase when processing that many rules.

Finally, note that this will only cause packets to be dropped that are 
sourced from IP's not in your list.  The standard VNC protocol has 
inherently weak security and would still be vulnerable to a 
man-in-the-middle attack potentially exposing your VNC password.  An 
encrypted tunnel such as a VPN or ssh port-forwarding would secure the 
VNC data cryptographically.

-- 
Josh



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: DNAT iptables bug or connection tracking issue?

[challado]

Hello, Josh! How are you? :)

..
Typically when you have a LAN behind NAT you use either MASQUERADE or 
SNAT on all packets going out the public interface.  It doesn't make 
sense to do so only for certain packets; if you intend to filter traffic 
to prevent it from going out to the Internet you should do so in the 
filter table, not by preventing NAT from occurring (which won't 
necessarily stop the packet from being forwarded.) 
..

Ok, I understand. Really, is intetional that the packets pass without filter by the firewall, because I use the tcpdump to discover a "little tricks" in the ISP,
because the ISP administrator block intetionally any ports and we have problems with these... I need these to make a test. Problably, when I change my ISP, I'll write
more efficient rules in FORWARD table to block all traffic and only pass the really important traffic.

But, my question is: how the DNAT rule works, in the kernel level, to do the NAT without the MASQUERADE rule?
It's automatic? Because I won't insert the nat rule... I only insert the DNAT rule and all works!
This is the question that I can't understand!

..
The easiest way is probably to create a user-defined chain containing 
tests for the IP's you want to allow to connect to this port.  If you 
include a rule to allow ESTABLISHED traffic prior to the jump to 
vnc_access only the first packet in the connection will need to traverse 
the list of IP's to allow.  Something like this should accomplish the 
task (along with the NAT rule you listed above):

iptables -N vnc_access
iptables -A vnc_access -s server_a_addr -j ACCEPT
iptables -A vnc_access -s server_b_addr -j ACCEPT
iptables -A vnc_access -s server_c_addr -j ACCEPT
iptables -A vnc_access -j DROP

[... other rules may go here ...]

iptables -A FORWARD -d <internal addr> -p tcp --dport 5900 -j vnc_access

If you have many IP's you want to add to the vnc_access chain, another 
way to write that first portion by using a bash for-loop might be as 
follows:

my_servers="server_a_addr server_b_addr server_c_addr"
iptables -N vnc_access
for ip in $my_servers; do
    iptables -A vnc_access -s $ip -j ACCEPT
done
iptables -A vnc_access -j DROP

For many hundreds or thousands of IP's you probably want to look at 
ipsets for a performance increase when processing that many rules.
..

YEAH! Here, in my city, the people always say:

"If you know, you know. If you won't know, you are nothing..." 
I work with iptables for long years. I never see this easily and intelligent way to write the firewall.
This little example shows the necessity to READ THE FUCK MANUAL, to all of us! If I read with attention and patience the manual, I believe that I'll find these
way to to the job. Sorry so much. I'm stupid, I agree... :'(

..
Finally, note that this will only cause packets to be dropped that are 
sourced from IP's not in your list.  The standard VNC protocol has 
inherently weak security and would still be vulnerable to a 
man-in-the-middle attack potentially exposing your VNC password.  An 
encrypted tunnel such as a VPN or ssh port-forwarding would secure the 
VNC data cryptographically.

Yeah, I understand. Really, I have very much vpn's along these server, and only few servers in this network can access the server. I know that this protocol is unsecure, and
I only access my machines using vnc under VPN connections.

Thanks a lot for your attention in these question.


------------------------------------------------
Os e-mails enviados por este domínio são verificados
por sistemas antivírus e antispam, visando a proteção
dos usuários e dos equipamentos de nossa empresa, bem como
para proteger o conteúdo e o trabalho de outros que
por ventura venham receber e-mails deste domínio.

O Grupo Bocchi se reserva no direito de, a qualquer
momento, bloquear ou inutilizar conteúdo de e-mails
que venham a ser prejudiciais para o ambiente de trabalho.

Caso este e-mail não possua conteúdo que seja relevante
à sua atividade profissional, ou a do usuário que a enviou,
por favor, delete-o imediatamente.

O Grupo Bocchi não se responsabiliza por qualquer dano 
ou prejuízo que a utilização indevida deste e-mail
possa causar a você ou sua empresa.

Em caso de dúvidas, favor entrar em contato.
---------------------------------------------


Grupo Irmãos Bocchi & Cia Ltda

http://www.ibocchi.com.br