[146485] in North American Network Operators' Group
Re: Ok; let's have the "Does DNAT contribute to Security" argument
daemon@ATHENA.MIT.EDU (Rubens Kuhl)
Mon Nov 14 16:21:40 2011
In-Reply-To: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
Date: Mon, 14 Nov 2011 19:21:29 -0200
From: Rubens Kuhl <rubensk@gmail.com>
To: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
For the common good it doesn't matter if the "NAT is good" guys are
right or the "NAT is useless" guys are right, as they both fail to
decrease the numbers of their opposing parts. We must get IPv6 done
for both of them.
It seems that application reverse-proxies can make "NAT is good" guys
happy, so let's get it or some other solution on the market (both
commercial and open-source) and move on with what really matters,
getting v6 done.
Rubens
On Mon, Nov 14, 2011 at 6:55 PM, Jay Ashworth <jra@baylink.com> wrote:
> Kill this subject if you're sick of it.
>
> ----- Original Message -----
>> From: "Gabriel McCall" <Gabriel.McCall@thyssenkrupp.com>
>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0If 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.
>
> This assertion is frequently made -- it was made a couple other times
> this morning -- but I continue to think that it doesn't hold much water,
> primarly because it doesn't take into account *the probability of various
> potential failure modes in a firewall*.
>
> The basic assertion made by proponents of this theory, when analyzed,
> amounts to "the probability that a firewall between a publicly routable
> internal network and the internet will fail in such a fashion as to pass
> packets addressed to internal machines is of the same close order as the
> probability that a DNAT router will fail in such a fashion as to allow
> people outside it to address packets to *arbitrary* internal machine IP
> addresses (assuming they have any way to determine what those are)."
>
> Hopefully, my rephrasing makes it clearer why those of us who believe tha=
t
> there is, in fact, *some* extra security contributed by RFC 1918 and DNAT
> in the over all stack tend not to buy the arguments of those who say that
> in fact, it contributes none: they never show their work, so we cannot
> evaluate their assertions.
>
> But in fact, as someone pointed out this morning in the original thread:
> even if you happen to *know* the internal 1918 IP of the NATted target,
> the default failure mode of the NAT box is "stop forwarding packets into
> private network at all".
>
> Certainly, individual NAT boxes can have other failure modes, but each of
> those extra layers adds at least another 0 to the probability p-number,
> in my not-a-mathematician estimation.
>
> On the other hand, since a firewall's job is to stop packets you don't wa=
nt,
> if it stops doing it's just as a firewall, it's likely to keep on doing i=
t's
> other job: passing packets. =A0It certainly depends on the fundamental de=
sign
> of the firewall, which I can't speak to generally... but you proponents o=
f
> "NAT contributes no security" can't, either.
>
>> That makes sense, but I'm wondering if that should be considered correct
>> behavior. Obviously a non-consumer grade router can have rules defining
>> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
>> everything coming from the outside in to either a) match up with
>> something in the translation table, b) be a service the router itself is=
hosting
>> (http, etc), or c) be a port it explicitly forwards to the same inside
>> host.
>
>> Anything not matching one of those 3 categories you'd think could be
>> dropped. Routing without translating ports and addresses seems like
>> the root of the issue.
>
> It is. =A0And IME, the people who think NAT provides no security rarely i=
f
> ever seem to address that aspect of the issue.
>
> And, for what it's worth, I'm discussing the common case: 1-to-many incom=
ing
> DNAT; rerouting specific TCP or UDP ports to internal machines, possibly =
on
> other ports.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Baylink =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 jra@baylink.com
> Designer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The Things I Think =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RFC 2100
> Ashworth & Associates =A0 =A0 http://baylink.pitas.com =A0 =A0 =A0 =A0 20=
00 Land Rover DII
> St Petersburg FL USA =A0 =A0 =A0http://photo.imageinc.us =A0 =A0 =A0 =A0 =
=A0 =A0 +1 727 647 1274
>
>
