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
