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

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

    There are some methods of security that NAT has a good use for. We 
use NAT to prevent reachibility. In other words, not only does an ACL 
have to allow traffic thru the FW, but a complimenting NAT rule has to 
allow the actual layer 3 reachibility. If not, even with the ACL, the 
routing path won't be available. It is a great "safety" check when we 
implement FW rules because it forces almost every manual entry to have 
two specific steps.

    In our layered environments, we also use local routing in some of 
our DMZs. In other words, a server on a subnet will only be aware of 
it's local broadcast domain. Even with a default GW, if it doesn't have 
a NAT in the FW, it can't route thru it. So even if a server gets 
compromised, the bad guy doesn't have a method to reach beyond the local 
DMZ without also making adjustments on the FW.

I don't think this complicates our design to much and definitely keeps 
us in check from human errors.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/15/2011 09:00 AM, Owen DeLong wrote:
> > 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.
> >
> >      
> Perhaps this misunderstanding of the job of a firewall explains your
> errant conclusions about their failure modes better than anything else
> in the thread.
>
> I would say that your description above does not fit a stateful firewall, but,
> instead describes a packet-filtering router.
>
> A stateful firewall's job is to forward only those packets you have permitted.
> If ti stops doing it's job, it's default failure mode is to stop forwarding
> packets. Please explain to me how mutilating the packet header makes
> any difference in this.
>
>    
> > > 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.
> >
> >      
> It's a lovely hypothetical description of how those devices should work.
> IME, and, as has been explained earlier in the thread, it is not necessarily
> how they ACTUALLY work. Since security depends not on the theoretical
> ideal of how the devices should work, but, rather on how they actually
> work, perhaps it is worth considering that our addressing reality instead
> of theory is actually a feature rather than a bug.
>
>    
> > 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.
> >      
> I think that is what the discussion has been about all along.
>
> Owen
>
>
>