[146546] in North American Network Operators' Group
Re: Arguing against using public IP space
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Nov 15 15:25:03 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <8B492826-660E-466A-A31D-11616E5805A4@ukbroadband.com>
Date: Tue, 15 Nov 2011 12:23:26 -0800
To: Leigh Porter <leigh.porter@ukbroadband.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>, "McCall,
Gabriel" <Gabriel.McCall@thyssenkrupp.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Nov 15, 2011, at 9:14 AM, Leigh Porter wrote:
>=20
> On 15 Nov 2011, at 15:36, "Owen DeLong" <owen@delong.com> wrote:
>=20
>>=20
>> On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote:
>>=20
>>>=20
>>>=20
>>> On 14 Nov 2011, at 18:52, "McCall, Gabriel" =
<Gabriel.McCall@thyssenkrupp.com> wrote:
>>>=20
>>>> 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.
>>>=20
>>>=20
>>> 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!
>>>=20
>> This is not true.
>>=20
>> If your firewall is not working, it should not be passing packets.
>=20
> And of course, things always fail just the way we want them to.
>=20
Your stateful firewall is no more likely to fail open than your =
header-mutilating
device.
>>=20
>> 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.
>=20
> 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.=20
>=20
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.
>=20
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.
>=20
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.
>=20
>=20
>>=20
>>> As somebody else mentioned on this thread, a NAT box with private =
space on one side fails closed.
>>>=20
>>=20
>> So does a firewall.
>=20
> If it fails just how you want it to.
>=20
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
