DMZs: NATing vs. Using Public Addresses
By Daniel Miessler on August 28th, 2006: Tagged as Information Security
Here’s a snip from a forum question that I’m getting ready to write a little piece on. My response is crude, but my next version of the response will be more intelligent.
So my question is: If you have plenty of public IP addresses, is there any reason (from a security perspective) that you should still NAT your host IP addresses?With private addresses you have an extra step that must actively be carried out. If you don’t do the NAT’ing it then by default nothing will make it to those hosts to the Internet.
In other words, with routable addresses, the default configuration takes Internet traffic to your DMZ hosts, whereas with NAT’ing there’s an extra piece that’s needed.
Think of it as two layers — knowing where to send Internet traffic, and determining whether it’s allowed or not. Well, with routable addresses any request to a port on a DMZ host knows where to go — right to the host. But if you use granular NAT rules you won’t have that. You can say, for example:
external1:80 –> internal1:80
Notice how specific that is. A connection to port 110 on external1 won’t take the traffic anywhere inside. :) With routable addresses, that traffic goes inside by default and it’s up to filtering to stop it.
I prefer it the other way, where you have to explicitly allow specific host:port translations. Perhaps he has a good point about the complexity not being worth it, though — it’s up to you guys to quantify the cost vs. benefit of doing this.
But to answer your question — yes, there is a benefit security-wise, but it’s mostly based on countering human weakness, i.e. poor configuration. You can attain the same security level using filtering; it’s just that that many don’t.
You guys have anything to add as far as benefits of using NAT vs. public IPs?
--
Very well said Daniel, this issue does not get enough attention in the security world.
Some considerations of course are there any applications that NAT will break, if any, should be few and far between in my experience, although Hide-mode NAT or Port address translation (PAT) can be troublesome.
Overall I agree that it would be more secure with private address in place, but as Daniel said, this is mainly due to the fact that if a configuration mistake is made or default configuration is over looked (Checkpoint’s any source to any destination rule for DNS and RIP for example) there is more room for error as the private address will be unreachable from the Internet by default requiring explicitly rules to allow traffic in via NATing on the firewall. This gives one more added layer of security (layered model or approach of security hardening). As with any security model it is better to deny all access then explictly allow via NATing with private addresses rather than allow all by using public internet routable address and then hope to that you deny all in your rules.
Possibly even more importantly, as penetrations will eventually occur, whether by inside employees downloading something malicous through 3rd party webmail or websites, browser exploits common to IE, laptops coming in from home bring the infection inside, or some other numerous means, Private NAT addressing also improves security by limiting outbound traffic if proplerly designed, as well (assuming all internal addresses are not just given a blanket dynamic NAT pool or PAT address for outbound access) therefore helping to prevent many worms, spyware, or other malware such as Botnets or rootkits from shoveling back door shells back out to the Internet or downloading the rest of the malware’s code to complete the (MSblast) the compromise.
Additional liability protection could be gained, as limiting outbound traffic can help contain any outbreaks/compromises that are successful from then attacking other companies or hosts on the internet from your network.
Comment by Steve Crapo — 8/29/2006 @ 1:19 pm