Arguing against using public IP space

Tue Nov 15 20:23:26 UTC 2011

On Nov 15, 2011, at 9:14 AM, Leigh Porter wrote:

> 
> On 15 Nov 2011, at 15:36, "Owen DeLong" <owen at delong.com> wrote:
> 
>> 
>> On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote:
>> 
>>> 
>>> 
>>> On 14 Nov 2011, at 18:52, "McCall, Gabriel" <Gabriel.McCall at 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.
>>> 
>>> 
>>> Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure!
>>> 
>> This is not true.
>> 
>> If your firewall is not working, it should not be passing packets.
> 
> And of course, things always fail just the way we want them to.
> 

Your stateful firewall is no more likely to fail open than your header-mutilating
device.

>> 
>> If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a
>> failure of the network implementor and the address space will not have any impact whatsoever
>> on your lack of security.
> 
> This is not really a well made point, sorry. It's about a firewall failing, perhaps due to software error or hardware issue or because somebody failed to correctly configure a firewall rule. 
> 

The assertion I was countering is that a header-mangling device is inherently more secure than
a stateful firewall that does not mangle headers. I believe that the above paragraph addresses
the fact that both are equally likely to fail in an open manner. The problem I was primarily attempting
to convey is that many people confuse packet filtering routers for firewalls. Routers have many
ways in which they tend to fail open. Their default unconfigured mode is to pass all traffic.

This is not the case with a properly designed stateful firewall.

> The point about private space is that is forces security in a way in which public space and a firewall does not.
> 

And my point is that it does not actually do so. If your header-mutilating device breaks or is
badly designed or misconfigured, it is just as likely to pass traffic to your private-addressed
internal hosts as a badly designed or misconfigured firewall. The only difference is the
trivial difference in what it takes to get said traffic to the appliance in question.

> With private space, you are forces to explicitly configure NAT holes or VPN connections whereas with public space your boxes by default are accessible by the whole Internet. By default, on a private space network, nothing can get to it.
> 

Or deliver packets already addressed to the internal host to the external mac address of
the header-mutilating device, or own the internal host through other means and have it
create a tunnel which the header-mutilating device happily mistakes for a permitted
stateful outbound flow, or...

I realize you like to live in this fantasy land where private space makes things more secure
because it allows you to be lazy about your security posture in other areas. This is a common
fallacy that is well liked by many an IT department in the world.

It's still a fallacy, and, arguably one that has systematically reduced security overall.

> 
> 
>> 
>>> As somebody else mentioned on this thread, a NAT box with private space on one side fails closed.
>>> 
>> 
>> So does a firewall.
> 
> If it fails just how you want it to.
> 

If the firewall's default state is don't forward anything, the likelihood of it failing closed
is just as high as the theoretical likelihood that a header-mutilating device will do so.
In fact, arguably more so.

Owen