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

> 
> On 15 Nov 2011, at 15:36, "Owen DeLong" <o...@delong.com> wrote:
> 
>> 
>> On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote:
>> 
>>> 
>>> 
>>> On 14 Nov 2011, at 18:52, "McCall, Gabriel" 
>>> <gabriel.mcc...@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


Reply via email to