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

Mon Nov 14 21:54:47 UTC 2011

Le lundi 14 novembre 2011 à 15:43 -0600, -Hammer- a écrit :
> 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.

I consider that a good way of looking a things. ;)

Cheers,
mh

> 
> -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 at 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
> >    