[isalist] Re: DMZ Route vs NAT

  • From: Greg Mulholland <greg@xxxxxxxxxxxxxx>
  • To: "isalist@xxxxxxxxxxxxx" <isalist@xxxxxxxxxxxxx>
  • Date: Thu, 31 Dec 2009 23:22:22 +0000

It's only really useful in the one-many example like replicating a sql box in 
the dmz to 10 on the lan. If the dmz box get compromised then your 10 lan boxes 
can also be attacked. With NAT it' not the same.

In a one-one dmz-lan scenario it's probably not as pertinent, but you already 
knew what i think.

Greg

From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On 
Behalf Of Thor (Hammer of God)
Sent: Friday, 1 January 2010 6:31 AM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: DMZ Route vs NAT

It's not about hiding IPs... Not interested in that.  A NAT relationship will 
prevent initiation of DMZ-to-Internal connections even when an access rule 
exists from the internal to the DMZ.  It makes it "one-way."   This would 
indeed "enhance" security on a number of different levels.  For example:

You've got a SQL box in the DMZ that you replicate to.  If you create an access 
rule on a route relationship, anyone can use any traffic on 1433 in or out if 
they compromise the DMZ.   The SQL box doesn't ever need to initiate a 
DMZ-to-Internal connection as replication is sourced internally, so you don't 
even need a publishing rule.  With a NAT relationship, only the internal box 
can initiate the connection- the DMZ box can't.

In the case of SMTP, where it DOES have to initiate a DMZ-to-Internal 
connection, you publish and apply the SMTP filter by default.  You might not go 
back and apply the filter to the access rule and I'm not sure how that would 
work anyway.   So even if the DMZ does get compromised, all traffic from DMZ to 
internal over 25 would be parsed by the application filter so you couldn't, 
say, run NetCat over it like you could in the above example.

Also, just in audits, I've noticed access rules tend to be more "global" than 
"specific," but only because of human nature.  Meaning, people put access lists 
to allow Internal to DMZ where you must publish server to server, thus even 
further mitigating potential exposure to other internal assets.

That's what I'm saying, and this is what I always do when publishing assets to 
a DMZ (except where I just noticed that my last network relationship was indeed 
a route, which I've already confessed to Steve after calling him a Scottish 
wanker for doing the same thing).

t

From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jerry Young
Sent: Thursday, December 31, 2009 10:07 AM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: DMZ Route vs NAT

I realize NAT is used to "enhance" security by adding a modicrum of obscurity 
to source IP addresses but wasn't its primary goal meant to get around the 
exhaustion of IPv4 addresses in an externally routed world-wide network?

And routing in and of itself doesn't allow for the passage of traffic through 
ISA, no?  Just because ISA knows where to route traffic, the traffic still 
needs to be allowed, yes?

Or, are you getting at something else entirely?
On Thu, Dec 31, 2009 at 12:59 PM, Thor (Hammer of God) 
<thor@xxxxxxxxxxxxxxx<mailto:thor@xxxxxxxxxxxxxxx>> wrote:
So, Steve and I were discussing network topologies the other day as we often 
do, and we were talking about the network relationship between the internal 
network and one's DMZ perimeter in regard to "best practices" and security.

I always like to set up a NAT relationship from the internal network to the DMZ 
perimeter and set publishing rules from the DMZ to internal if necessary, i.e. 
SMTP publishing.  I'll publish SMTP from the Internet to the DMZ edge, process 
mail, and then publish from the DMZ to the Internal Exchange box.

However, I think most people use a "route" for ease of management.  A route 
would be less secure since any compromise of a DMZ asset would result in any 
access rules automatically allowing access into the internal network.  
Typically,  a published service would have an application layer filter applied 
which would mitigate the leverage one could apply to such a compromise.

What are the group thoughts on this?  NAT is more difficult to manage given the 
"directional" aspects of the relationship as well as the added overhead of 
publishing anything where the DMZ unit must initiate connections to the 
internal network.

I just wondered what the rest of you guys/gals did.

T

____________________
Thor
thor@xxxxxxxxxxxxxxx<http://thor@xxxxxxxxxxxxxxx>
www.hammerofgod.com<http://www.hammerofgod.com/>

Error! Filename not specified.  Think Carbon Footprint.  Like mine on your ass 
if you print this you wasteful bastard!







--
Cordially yours,
Jerry G. Young II
Microsoft Certified Systems Engineer

Other related posts: