[isalist] Re: DMZ Route vs NAT
- From: Jerry Young <jerrygyoungii@xxxxxxxxx>
- To: isalist@xxxxxxxxxxxxx
- Date: Mon, 4 Jan 2010 12:30:21 -0500
Yippie!
I got one right - although not nearly as verbose as Jim. :)
On Fri, Jan 1, 2010 at 5:11 PM, Thor (Hammer of God)
<thor@xxxxxxxxxxxxxxx>wrote:
> 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…
>
> J
>
>
>
> 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 J
>
>
>
> 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> 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*
>
> *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
>
--
Cordially yours,
Jerry G. Young II
Microsoft Certified Systems Engineer
Other related posts:
