During my job I am frequently discussing with people why they use NAT or why they believe that NAT adds any security to their networks, mainly some obscurity as NAT (PAT) hides the internal network structure. However, NAT does not add any real security to a network while it breaks almost any good concepts of a structured network design. To emphasize this thesis, here is a discussion:
The Intentional Purpose of NAT
(You should already know this part when reading this post. Otherwise: Wikipedia.)
Note that when I am using the term “NAT”, I am usually referring to NAT with port translation, called PAT, NAPT, NAT overload, dynamic NAT, IP masquerading, many-to-one NAT, or the like.
- Since the IPv4 address space in the global Internet gets exhausted, sites with many hosts can access the Internet through one single IPv4 address if they use NAT.
- If enterprises use the same private IPv4 address spaces, they need NAT if they want to communicate through VPNs with each other. (Probably without port translation.)
What NAT Breaks
The usage of NAT has several disadvantages, mainly because it breaks the end-to-end communication model which is essential for proper IP connections. For example, IPsec host-to-host tunnels cannot be used with NAT, the FTP protocol (active mode) does not work, VoIP (SIP) has troubles, and any other peer-to-peer protocols do not work out of the box if they need to establish connections to each other independently. (Refer to RFC 3027 “Protocol Complications with the IP Network Address Translator”.) To overcome this disadvantages, a few changes in the just mentioned protocols are proposed to use them also through NAT devices, called NAT traversal, e.g., IPsec NAT-T (RFC 3947, 3948), passive FTP (RFC 1579, 2428), etc.
Furthermore, the usage of NAT adds a burden to all (network) administrators that have to configure and administrate it. For vast installations, configuring and debugging connections that traverse several NAT devices is really difficult. With many Source-NATs and Destination-NATs, every intermediary firewall stores different IP addresses in its log files. Really hard to deal with.
NAT “Security” Considerations
Here comes the actual discussion concerning the “security” features NAT adds to a network. I always present a short description of common NAT “security” considerations and then refute it:
- “NAT hides the internal network structure which keeps my network more secure from attackers since they do not know which systems are available.” –> I have often heard this sentence. Administrators feel more secure if their network topology is hidden from the outside. However, an attacker is only able to do harmful activities if he has access to a device in the internal network. If he really wants to enter your network, he will find a way to do so, whether you are using NAT or not, e.g., via social engineering, phising e-mails, or malware at al. In that case he is even able to do network scans from the inside of the network. That is: NAT as a hiding feature is useless if the attacker is able to access any of the internal devices! Conversely: As long as the network is protected against attackers, it is no benefit to hide the internal network via a NAT device, since it is secured against malicious access anyway. The key sentence is:addressable≠ accessible. For a network, all devices should be directly addressable, while NOT accessible. To prohibit any kind of unwanted access, a firewall should be used. If a network administrator still wants to hide his networks, he must balance the reasons between the overall burden of NAT on the one side while hiding the internal infrastructure on the other side. However, for a company, information that reside on servers should be protected from malicious outside users and not the knowledge of their underneath topology.
- “External servers cannot distinguish between multiple inside clients. That is, we keep the privacy of our internal users.” –> It is sometimes said that NAT masks the internal hosts, i.e., a server on the Internet does not know how many devices reside behind the NAT device, nor can the server distinguish between them. However, this is not true since servers, Internet trackers, etc. count their users on more relevant information than simply the incoming IPv4 addresses. For example, they use the User-Agent ID from the HTTP header or several JavaScript variables to concretely identify each different client (web browser) on their server, independent whether many clients access the server from the same (NATed) IPv4 address or not. For example, Peter Eckersley describes in his paper “How Unique Is Your Web Browser?” that the uniqueness of browsers are over 90 %. That is: even if a company uses NAT to hide their internal users, Internet trackers are still able to track them since they use other browser-based information. If you want to check the “privacy” of your browser, use this analyzer at https://privacy.net/analyzer/.
- “A NAT router automatically creates a firewall. No new connections can pass to the inside network.” –> In fact, connections from the Internet cannot pass to a specific computer on the inside network through the NAT device since it does not know to which computer it should forward the packet. However, this function should not be counted as a firewall-feature! The NAT device is simply unable to forward these packets at all, even though some functions would need the forwarding of packets. Moreover, a real firewall only blocks certain connections based on concrete policies. A device that cannot forward packets since it is not able to process them correctly should not be called a firewall. If you want to block all incoming connections, you should acquire a firewall and apply a “deny any any” policy to it. That is: a network without any kind of NAT but with appropriate firewalls is at least as secure as a network behind a NAT device.
(Fun fact: NAT with PAT can even lead to a denial-of-service (DoS) attack if someone floods the NAT/PAT table with outgoing connections, prohibiting any further IP communication. That is: if the NATted source address has run out of free TCP/UDP source ports.)
What about IPv6?
I won’t start the whole “NAT for IPv6” discussion here. ;) Go for global-unicast IPv6 addresses and don’t do NAT! At least not for security. If you are an old school network administrator who used NAT for IPv4 simply for network functionalities, DO NOT transfer this knowledge to IPv6. You don’t need NAT anymore, that is: NAT66. For security policies you must use a firewall.
However, there are some exceptions: NPTv6 (Prefix Translation) must be used if a customer has no provider independent (PI) IPv6 space and wants to be flexible. In this case, they can use Unique Local Addresses (ULA) internally and must use NPTv6 for outgoing connections. Note that you MUST use a firewall as well for providing security since NPTv6 does NOT block any incoming connections by default! The other exception is NAT64, which is not an IPv6-IPv6 NAT but used as a transition method from IPv4 to IPv6.
For more information, watch this conversation:
Conclusion
If you keep your network secure, (that is: if no attacker can access to any device/service/etc.), it is no security leakage if the network is not hidden from the Internet by a NAT device. It is rather cumbersome that NAT breaks the end-to-end communication model and disrupts certain internet protocols.
However, I know that some people might disagree with me. So feel free to add comments! ;)
Featured image: “Was that Thunder?” by Matt Deavenport is licensed under CC BY-ND 2.0.
