[isalist] Re: DMZ Route vs NAT

It's tough with SMTP, as you know...  We used to be able to setup bridgeheads, 
but no more.  That being said, at least with SMTP, you can still apply the SMTP 
filter in an access rule, and just specify one-to-one, server-to-server rules.  
That way, even though a connection can be initiated from the DMZ to the 
internal, it can ONLY be initiated to the listening Exchange box, and the SMTP 
filter is applied.   Someone would have to compromise the Exchange box first to 
do anything useful (like use 25 for something else) and even if they did, they 
would have to go through the filter, so I've not really been that concerned 
with SMTP itself.   It's more the things like RDP that you don't really think 
about - you know, the "internal -> DMZ" stuff that basically creates a path 
inside without you thinking about it....

t

From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
Sent: Friday, January 01, 2010 1:50 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: DMZ Route vs NAT

De nada - evaluating ISA/TMG policy behavior can be a very twisted maze 
sometimes.
I know I've had to triple-and quintuple-check myself many times when I found 
thing happening that I thought shouldn't be.
99 times out of 10, it was user error...
:)

I've also discovered that ETRN/TURN is functionality removed from Exchange, 
apparently in favor of the edge role...
..now I need to see how this can be configured to satisfy the "outbound-only" 
context you're trying to create...


From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On 
Behalf Of Thor (Hammer of God)
Sent: Friday, January 01, 2010 12:18 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: DMZ Route vs NAT

Happy New Year!  I'm glad you replied... I was hoping for your input.

So, as always I yet again tested this to make sure I wasn't crazy, and 
apparently, I am.  This is the configuration I tested multiple times:

Internal: 192.168.1.0
DMZ:192.168.2.0
Network Relationship: Internal->DMZ; ROUTE
Rule: Allow SMTP Internal->DMZ
Behavior:             Connection initiated from Internal to DMZ via SMTP 
succeeds.
                                Connection initiated from DMZ to Internal via 
SMTP succeeds.

I saw the above behavior many times before, and actually counted on it.  
However, of course, I just tried it again to make sure, and sure enough, it 
doesn't work:  TMG honors the direction of the rule even with a ROUTE.  
Something else must have been applied, most probably a separate rule allowing 
the other side to connect that I wasn't paying attention to.

So, after all of that, "never mind."  However, thank you very much for the 
detailed and informative response:  just getting your take on the network and 
policy rules was worth me going through all of what I was doing :)

t




From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
Sent: Friday, January 01, 2010 10:42 AM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: DMZ Route vs NAT

You appear confusing the behavior of traffic policies vs. network relationships.

Specifically:

1.       "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" - is not an absolute truth.  Although it's 
true that a single access rule can be defined to satisfy the traffic from 
either network entity, in order to satisfy this statement (and assuming a 
single-rule policy), the access rule must have been defined such that the DMZ 
and Internal hosts are both listed in the "From" and "To" aspects of the rule.  
If the traffic requirements (such as bi-dir replication) dictate that both 
hosts initiate the connection, then your business needs have just trumped your 
security needs.  Since I know that you prefer to define the replication as 
"pull from internal", the access rule that satisfies this traffic requirement 
must be defined such that only the internal SQL is listed in the "From" set and 
the DMZ SQL is the only element in the "To" set. If you define the access rule 
this way, the DMZ SQL cannot initiate inbound connections through this access 
rule. the distinction I make in this context is important. If another rule 
allows the traffic, you might confuse that action with the rule you're working 
on.


2.       "In the case of SMTP, where it DOES have to initiate a DMZ-to-Internal 
connection," - is not an absolute truth, either. Although the most common 
deployments use this model, SMTP in and of itself doesn't dictate a 
single-direction traffic flow. If you configure your internal SMTP server to 
send TURN/ETRN<http://cr.yp.to/smtp/turn.html> to the DMZ host, you can enjoy a 
"pull" inbound email model. Granted, this isn't as dynamic as accepting inbound 
traffic from the DMZ as it's received there, but it is more secure strictly 
from a traffic policy standpoint. This is another case where business needs 
have to be balanced against traffic policies. It appears that this 
configuration has been removed from E14 (or it's just insanely hard to find now 
that the docs are all online) or perhaps it's limited to the edge role (that I 
don't have yet).

The relationship between policy rules and network rules is (I'll freely admit) 
confusing and this is because the firewall engine still retains some of the ISA 
2000 "one-way NAT" mentality.
For purposes of the following discussion, I'll use these abbreviations:
AR == Access Rule(s)
NR == Network Rule(s)
SPR == Server Publishing Rule(s)
WPR == Web Publishing Rule(s)
E-NAT == Enhanced NAT
ISPR == ISP Redundancy
NIS == Network Inspection System (AKA GAPA)

Network Rules 101:

1.       Although they are used in rule processing, NR are not part of the 
"firewall policy" as such, because they don't define "access rights" as do AR, 
SPR and WPR. Thus, they don't affect the "allow/deny" decision process other 
than to help the firewall engine determine whether a policy rule is valid in 
the context of the traffic being processed.

2.       NR can define either a NAT or Route relationship between IP-based 
network objects (computers, computer sets, networks, etc.). IOW, you cannot use 
name-based sets such as URLs, domain names, etc.)

3.       NAT relationships are uni-directional from source to destination (same 
as ISA 2000); that is:

a.       AR must be used to allow traffic initiated from hosts in the source 
side of the NR

b.      SPR must be used to allow traffic initiated from hosts in the 
destination side of the NR (just like ISA 2000)

c.       SPR listeners must be defined in the destination side of a NAT 
relationship. Thus, SPR cannot be used to allow access from the source to the 
destination side of the network relationship

d.      for traffic coming from the source network, the source IP will be 
changed to (ISA) the default IP or (TMG) the IP specified in the E-NAT 
configuration for that network rule. the destination IP is never changed

e.      for traffic coming from the destination network, the destination IP 
will be changed to the published internal host IP and the source-IP will be 
changed according to the publishing rule configuration (traffic

f.        application filters may adjust their behavior according to the policy 
rule context (SMTP and H.323, for instance)

g.       application filters may choose to terminate the session at ISA/TMG 
(SMTP, Web filter, etc.), creating an "application proxy" scenario

4.       Route relationships are bi-directional between source and 
destinations; that is:

a.       Access rules may be used to allow initiated traffic from either the 
source or destination networks

b.      Publishing rules do not create "listeners", because the client treats 
ISA/TMG as a next-hop router

c.       IP addresses are unchanged as the traffic crosses ISA/TMG boundaries 
(it's a filtering router)

5.       NIS doesn't care

6.       ISP-R doesn't care

7.       E-NAT requires a NAT relationship

Policy Rules 101:

1.       The firewall engine processes traffic according to:

a.       The network rules. IOW, the NR helps the firewall engine decide if the 
traffic is valid in the context of each rule as it is examined

b.      the 5-tuple (source/dest IP, transport, src/dest ports)

c.       relevant application or Web filters

d.      the existence of a current context for this traffic. This 
article<http://technet.microsoft.com/en-us/library/cc512655.aspx> goes into 
detail on this concept.

2.       Firewall rules allow:

a.       initiated traffic according to the associated protocol primary 
connections in a matched "allow" rule

b.      response traffic according to an established connection or as defined 
in the associated protocol secondary connections in a matched "allow" rule

3.       Firewall rules deny:

a.       Initiated traffic that meets the primary criteria (5-tuple) in a 
"deny" rule

b.      Initiated traffic that fails to meet the primary criteria (5-tuple) in 
any rule (e.g., default "deny" rule)

c.       Initiated or response traffic that meets the secondary (app-layer) 
criteria in an "allow" rule (e.g., HTTP filters in an allow AR or WPR)

d.      Initiated or response traffic that fails to meet the secondary 
(app-layer) criteria of an allow rule (e.g., host header, path, etc.)

4.       User authentication is part of the "secondary criteria" aspect of a 
policy rule.

Before anyone has a fit about how WPR appear to violate all of the network 
rules criteria  (WPR may publish in any direction), you need to remember that 
WPR have this capability because they take advantage of specific design choices 
in the Web Filter.  The HTTP protocol itself make this flexibility possible; 
where it is not for other protocols such as FTP or SMTP.

HTH,
Jim


From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On 
Behalf Of Thor (Hammer of God)
Sent: Thursday, December 31, 2009 11: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: