Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[-Hammer- <bhmccie () gmail com>]

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
>