Date: Wed, 02 Jul 2003 19:06:25 -0400 From: Chuck Swiger <cswiger@mac.com> Cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL Message-ID: <3F036571.8030609@mac.com> In-Reply-To: <3F0350C7.7010009@tenebras.com> References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <3F0331EE.6020707@mac.com> <3F0350C7.7010009@tenebras.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Sierchio wrote: > Chuck Swiger wrote: >> Many people are wrong, then. NAT is not a security feature. > > We simply disagree. To the extent that "security" is a matter of opinion, I guess that's all right: I'm not concerned if other people have different opinions than I do. To the extent that security is a testable, measurable, repeatable, and refutable subject-- that is to say, to the extent that security is a science with deals in facts, not opinions-- NAT plus a packet-filtering firewall (such as natd+ipfw) provides no better security than the packet-filtering firewall would alone. By itself, NAT provides no benefit to security, and some implementations actually reduce the security of the system compared with not running NAT. Let me pull out a couple of quotes from various people: "> I recognise what you are saying, but what I was trying to understand was, > are the low-end appliance 'firewalls' really providing much more security > than NAT? In a small office/home situation if people are going to use IRC, My point was that they're able to provide more security- but if you're going to align a security policy with a NAT device, then you're giving up a large part of the point of having a firewall. If we, as a community can get people to use *firewalls* for *firewalling* then we'll have done both ourselves and everyone else a better service than to say "oh, just use anything that'll let you connect." > they would just reconfigure their firewall to do so, after all they own it. > I was just trying to get all the 'block xyz outbound' issues out of the way. > > Can NAT sessions be hijacked or somehow abused to give access to the > internal network? There is the case of visiting a hostile website and > "inviting in" some problematic programs, but apart from that are the > appliance based firewalls doing more than that? In general, NAT based things aren't written for security, they're written for network re-mapping, so there can be things that escape the author that a firewall author shouldn't miss (or may have tested by a 3rd party for some level of assurance.[1]) Firewalls should handle things like source routed packets, overlapping fragments, etc. They also may handle things like VPNs, authentication, "enterprise" policy enforcement, etc. Paul [1.] Obviously, I'm highly biased about which certification program a firewall should pass to be on the market. My employer owns ICSA Labs, this list is hosted from there, etc. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@patriot.net which may have no basis whatsoever in fact." probertson@trusecure.com Director of Risk Assessment TruSecure Corporation" -- "I would add that a large number of these hospitals have elected to do NAT from their router/ Internet Gateway. Worst yet they depend on their router as THE FW. This is a bad choice for any network topology, which connects to the Internet, IMHO. Such topologies are vulnerable to Disclosure, Integrity and DDOS threats and place the majority of the raise the risk cost on the NAT/Router. This is a poor response to meet HIPAA compliance requirements. Sorry CISCO." -- "Since NAT actually adds no security, I'd put the nameservers on a DMZ of their own and not NAT between them and the Internet. For internal lookups, I'd use separate internal servers that forward to the DMZ servers for non-internal domains. Or use views to cause the DMZ servers to return different answers for queries from inside. You can still NAT between inside and outside if management insists." -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F036571.8030609>