Re: ipv6 question

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

 



On Wed, 2011-01-05 at 17:26 -0500, Lamar Owen wrote: 
> On Tuesday, January 04, 2011 12:52:42 pm Marko Vojinovic wrote:
> > You have the exact same situation if you use IPv4 and NAT. The outside system 
> > has the IPv4 of your router, and can use that IP to scan for any open port on 
> > your inside machine. Namely, once your NAT-ed machine initiates the connection 
> > to the outside machine, NAT will happily accept any incoming connection from 
> > that outside machine, typically on all ports, translate to your local IP and 
> > forward back inside (at least in the default configuration). That's how NAT 
> > works, it translates the addresses from non-routable to routable and back, 
> > trying to keep the communication as open as possible, both ways. Didn't you 
> > know this?
> 
> This is incorrect for many implementations of NAT.
> 
> I refer in particular to Cisco IOS NAT, IOS 12.4(23) mainline on a
> 7206/NPE-G1, using NAT pools and overloading. Incoming packets
> addressed to the outside interface that don't match the flows that the
> router knows about get dropped. So if I connect to your website from
> inside my network, you can't randomly initiate a connection back to my
> box (that's what the overloading, allowing multiple internal IP's onto
> a single 'inside global' (using Cisco terms) IP, prevents). The only
> conduit through the NAT is using the specific
> source-address:source-port/destination-address:destination-port pair
> that the translation sets up.
> 
> If I have, say, 100 computers inside my network, and have 32 global
> addresses, and overload the dynamic translations onto three global
> addresses, you have no way of getting to the inside addresses except
> through the translations set up during the outgoing flow initiation.
> You have to jump through hoops to get things like H.323 to work (Cisco
> at least has support for connection tracking so the packets, mostly
> UDP, can get back to where they need to go). No ACL's necessary to
> create this behavior, at least with Cisco IOS NAT.
> 
> The same (or similar) is true for Smoothwall, at least, naming one
> firewall appliance/distribution that I use and that uses the Linux
> kernel.  Tested that one; you have to configure zone bridging and port
> forwarding to get the behavior you mention.

What you say is true but is equally true if you retain the stateful
firewall at the heart of the NAT engine and eliminate the NAT.  The NAT
is not what's giving you this protection.  It's the stateful nature of
THAT particular NAT which is the same as as a linear stateful firewall.
No difference.  And other forms of NAT do not enjoy this.

I know of one university that employs an n-on-m NAT to protect itself
from address exhaustion due to the number of mobile WiFi enabled
devices.  If you don't authenticate, you don't get out through the
firewall and you don't consume one of their public addresses from
their /16 pool.  If you do authenticate, they map one of their public
addresses to your private address and it's a complete stateless 1:1
mapping of all ports.  The big advantage to them in this setup is that
they don't need to maintain a massive university wide dynamic state
table managing a mapping of 4 million private addresses * 65 thousand
possible ports to 65 thousand squared public addresses/port combinations
and the processing and memory requirements it would require.  It also
doesn't break a lot of the things that require NAT helpers (like ftp,
etc) that dynamic port and address NAT requires.  In that configuration,
the fact that you are on a private address is providing you with ZERO
security even though you are NAT'ed.

NAT, in and of itself, is not providing the security.  It's the state
engine at the heart of most (but not all) NAT devices and all stateful
firewalls.  It's not the NAT, it's the firewall.

Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw@xxxxxxxxxxxx
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux