Re: DNAT iptables bug or connection tracking issue?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux