[146486] in North American Network Operators' Group
Re: Ok; let's have the "Does DNAT contribute to Security" argument
daemon@ATHENA.MIT.EDU (-Hammer-)
Mon Nov 14 16:46:51 2011
Date: Mon, 14 Nov 2011 15:43:26 -0600
From: -Hammer- <bhmccie@gmail.com>
To: nanog@nanog.org
In-Reply-To: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
There really is no winner or "right way" on this thread. In IPv4 as a
security guy we have often implemented NAT as an extra layer of
obfuscation. In IPv6, that option really isn't there. So it's a cultural
change for me. I'm not shedding any tears. We've talked to our FW
vendors about various 6to6 and 4to6/6to4 options and we may consider it
but given the push in the IPv6 community for native addressing I really
am hesitant to add NAT functionality given that no one really knows what
the IPv6 future holds.
-Hammer-
"I was a normal American nerd"
-Jack Herer
On 11/14/2011 02:55 PM, Jay Ashworth wrote:
> Kill this subject if you're sick of it.
>
> ----- Original Message -----
>
>> From: "Gabriel McCall"<Gabriel.McCall@thyssenkrupp.com>
>>
>
>> 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.
>>
> 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 that
> 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 want,
> if it stops doing it's just as a firewall, it's likely to keep on doing it's
> other job: passing packets. It certainly depends on the fundamental design
> of the firewall, which I can't speak to generally... but you proponents of
> "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. And IME, the people who think NAT provides no security rarely if
> ever seem to address that aspect of the issue.
>
> And, for what it's worth, I'm discussing the common case: 1-to-many incoming
> DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
> other ports.
>
> Cheers,
> -- jra
>
