On Nov 14, 2011, at 11:32 AM, William Herrin wrote:
On Mon, Nov 14, 2011 at 1:50 PM, McCall, Gabriel <Gabriel.McCall@thyssenkrupp.com> wrote:
Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.
The fact that consumer cpe's typically do both nat and stateful firewalling does not mean that those functions are inseparable.
Gabriel,
This is not accurate.
First, many:1 NAT (sometimes also called PAT) is not separable from a stateful firewall. You can build a stateful firewall without many-to-one NAT but the reverse is not possible.
Actually, you can. You need a state machine, but, several recent incidents have proven that the state machine in many of the lower-end consumer appliances is not, in fact, a firewall. This has been explained earlier in the thread, so I won't repeat it here.
Second, while a security benefit from RFC 1918 addressing combined with 1:1 NAT is dubious at best, the same is not true for the much more commonly implemented many:1 NAT.
Repeating this fallacy still doesn't make it true.
With RFC1918 plus many:1 NAT, most if not all functions of the interior of the network are not addressable from far locations outside the network, regardless of the correct or incorrect operation of the security apparatus. This is an additional boundary which must be bypassed in order to gain access to the network interior. While there are a variety of techniques for circumventing this boundary no combination of them guarantees successful breach. Hence it provides a security benefit all on its own.
If the security apparatus malfunctions, nothing prevents it from malfunctioning in a way that passes packets to the RFC-1918 addressed hosts.
You would not rely on NAT+RFC1918 alone to secure a network and neither would I. However, that's far from meaning that the use of RFC1918 is never (or even rarely) operative in a network's security process.
RFC-1918 and NAT as a security measure is, at best, a locking screen door deployed in front of a vault door. If you take away the vault door, the screen door really doesn't do much. If the vault door is still there, the presence or absence of the screen door is largely irrelevant. Owen