[isalist] Re: FW: Re: [isapros] Re: Exchange Server 2010 Edge and TMG 2010 Integration

  • From: "Thor (Hammer of God)" <Thor@xxxxxxxxxxxxxxx>
  • To: "isalist@xxxxxxxxxxxxx" <isalist@xxxxxxxxxxxxx>
  • Date: Fri, 22 Jan 2010 01:42:23 +0000

I meant in the DMZ, specifically for Exchange Edge deployments.

t

From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
Sent: Thursday, January 21, 2010 4:21 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: FW: Re: [isapros] Re: Exchange Server 2010 Edge and TMG 
2010 Integration

Agreed and this is where the fights inevitably start between the "must do" and 
"wanna do" requirements.

"What does domain membership buy you?" - in most cases; "transparent 
authentication". When the CxO dictates this requriement and fails to hear the 
arguments against it, you have no choice (especially given the current job 
market). This silliness is far more common than I care to admit. Granted, it's 
a terrible user experience to be forced to authenticate for every #$%^ 
advertising link on every site on the web; not to mention the content you 
actually want to see...

"What can you do with a DM that you can't do with a WG?" - again; we come to 
the issue of monitoring and management. Very few customers (especially those 
that manage many thousands of assets) want the additional overhead of having to 
maintain multiple set of credentials simply for the purpose of monitoring and 
management. In fact, many monitoring systems (SCCM, ferinstance) don't know 
diddly or squat for non-DM.

________________________________
From: isalist-bounce@xxxxxxxxxxxxx [isalist-bounce@xxxxxxxxxxxxx] on behalf of 
Thor (Hammer of God) [Thor@xxxxxxxxxxxxxxx]
Sent: Thursday, January 21, 2010 3:43 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] FW: Re: [isapros] Re: Exchange Server 2010 Edge and TMG 2010 
Integration

One must also take into account what other assets are in the DMZ.   The host is 
not only subject to direct attack, but to compromise in parallel from other 
assets in the same segment where there is typically no filtering (this is where 
the local host hardening comes in).    Add to that (again) the necessary 
allowed traffic for domain membership, and the box now has a much more exposed 
attack surface.

My opinion is somewhat skewed as there have been many engagements I've been on 
where owning one asset in the DMZ led to trivial internal compromise.  When you 
have a DMZ asset that is a domain member, you typically see domain admins or 
the equivalent "managing" the box.  Cached credentials, LSA secrets, and a host 
of other credential-based attacks coupled with a direct path to the internal 
network means total compromise.   Personally, I've yet to see any management 
trade off for that associated risk; but that doesn't mean they don't exist.  
The question I would ask you is this:  What does domain membership buy you?  
What can you do with a DM that you can't do with a WG?

t

From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jerry Young
Sent: Thursday, January 21, 2010 12:58 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: [isapros] Re: Exchange Server 2010 Edge and TMG 2010 
Integration

I suppose for me the crux is what "security" represents.  I currently see 
security as a means for mitigating risks.  While domain membership raises the 
risks identified here, risks to external threats are what I'm looking to 
mitigate.  To get into my internal network, an external attacker would have to 
compromise the server I have on the edge.  In this particular case, there is 
really only one way that could potentially happen - through SMTP (are there 
others?).  With TMG installed, use of the SMTP filter, and all other ports 
closed (plus another firewall in front of it), how might an attacker compromise 
the server?

Isn't that a better question to seek an answer to than attempting to address 
principle and "just-in-case" scenarios?

I've never been able to win an argument from purely a principle or 
"just-in-case" stance; I've always been required to have a concrete example.
On Thu, Jan 21, 2010 at 3:24 PM, Thor (Hammer of God) 
<Thor@xxxxxxxxxxxxxxx<mailto:Thor@xxxxxxxxxxxxxxx>> wrote:
As always, you make excellent points.   Indeed, design of structure without the 
business goals in mind could definitely bite the hand that feeds.

I tend to boil these types of discussions down to the technical merit, 
particularly in the absence of states business goals and the presence of "to 
join, or not to join" questions.

I would still assert that the same business goals could be met while meeting 
the security goals inherent in the question, but your more rounded "real life" 
approach is certainly valid.

t

From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx> 
[mailto:isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>] On 
Behalf Of Jim Harrison
Sent: Thursday, January 21, 2010 12:17 PM

To: isalist@xxxxxxxxxxxxx<mailto:isalist@xxxxxxxxxxxxx>
Subject: [isalist] Re: [isapros] Re: Exchange Server 2010 Edge and TMG 2010 
Integration

Apparently, I postulated poorly.

I don't use compliance as a security requirement, but as a business requirement 
(FSM help those who use it otherwise). Those who are tasked with the goal of 
"desigining a secure network path" must not determine network security goals 
and requirements without also considering the business goals and requirements.  
To do so is (IMHO) irretrievably stupid.  invariably, the network design will 
be altered to satisfy some aspect of the business needs that were missed prior 
to the actual deployment.  Reality (and Murphy) dictates that this is likely to 
happen anyway, but it's far worse if you miss them entirely in the initial 
design review.

We also agree that if the business requirements dictate that you fire an 8-GA 
traffic shotgun at your DMZ firewall, then that DMZ is rendered effectively 
moot and the DMZ consequently represents nothing so much as additional network 
admin overhead.

We agree that there is no such thing as "always" or "never" and that basing the 
deployment strictly on a single aspect of that deployment can only lead to 
disappointment and failure.

My point in this discussion is to disabuse anyone that any single deployment 
model is "the best you can possibly do". All of them are contextual and will 
necessarily be limited by the business requirements OR that the security 
requirements will impose adjustments to the business requirements. It all 
depends on which requirement source weilds the bigger stick.

HTH,
Jim

________________________________
From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx> 
[isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>] on behalf 
of Thor (Hammer of God) [Thor@xxxxxxxxxxxxxxx<mailto:Thor@xxxxxxxxxxxxxxx>]
Sent: Thursday, January 21, 2010 8:47 AM
To: isalist@xxxxxxxxxxxxx<mailto:isalist@xxxxxxxxxxxxx>
Subject: [isalist] Re: [isapros] Re: Exchange Server 2010 Edge and TMG 2010 
Integration
The "outbound only policy" is only applies when it makes sense - nothing I say 
is ever put as a  postulate.  If you can do it, do it, if you can't don't.  In 
regard to Exchange, as previously noted, the bi-directional properties of the 
rule are mitigated by the application filter, and I'm good with that.

I think this is where our disconnect came last time...  First, bringing in 
"compliance" in this discussion is non sequitur.  "Compliance" has nothing to 
do with security or the technical aspects of the question; let's not drop red 
herrings into this please.   I still fail to understand how one can "manage and 
patch" so much easier in a domain than in the DMZ as a WG member - I'd really 
like for you to elaborate on that...  If you are referring to push 
configurations and remote RPC based policy, then I would have to say that with 
the rules necessary to create a fully functional domain-based communications 
path to the system, you might as well not even have a DMZ, at least in respect 
to that system.

If one must compromise the integrity of the DMZ structure to accommodate 
management goals, then someone has lost sight of the purpose of a DMZ.  It 
would take a plethora of rules to deploy a fully managed domain member in the 
DMZ.  One must treat the DMZ as a "when it is owned" set of assets.  In this 
case, having systems fully managed from the internal network severely limits 
the strength of a DMZ.    I have a production Exchange Edge box in my DMZ that 
is not a domain member.  Once you configure the box, there isn't any management 
one needs to do, really.  Turn on auto updates and be done with it.  Having 
rulesets in place 24/7 to allow for remote management is far more of a 
threat/risk than even an unpatched box would be in a "proper" DMZ.

The main point is to start from a position of security, and design around that. 
 If you find that you absolutely have to destroy the integrity of a DMZ 
structure by supporting domain members, well, that's something you just have to 
do.  But to start off with "management and patching might outweigh the need for 
security" is back-asswards, and obviates the purpose of a DMZ in the first 
place.

t

From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx> 
[mailto:isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>] On 
Behalf Of Jim Harrison
Sent: Wednesday, January 20, 2010 5:04 PM
To: isalist@xxxxxxxxxxxxx<mailto:isalist@xxxxxxxxxxxxx>
Subject: [isalist] Re: [isapros] Re: Exchange Server 2010 Edge and TMG 2010 
Integration


I promise not to use references to thin cooking accoutrement headgear if you 
do... <oops; too late>
Tim and I agree in principle - it's where implementation comes into play that 
we find ourselves reshaping our headgear.

The question of domain vs. WG membership as a threat mitigation in and of 
itself typically ignores additional aspects of this question that an 
organization has to satisfy, such as compliance, management, patching, etc. 
Very frequently, the needs of the management outweigh the needs of the security 
or the traffic profile and its in these cases that you need to broaden your 
thoughts and do the "pro/con" checklist for yourself.

Tim's arguments that a properly-defined and -managed traffic policy can do 
great things with mitigating this threat are absolutely correct (as I said; we 
agree in principle).  Sadly, Tim's "outbound-only" traffic policy can't be used 
for Exchange  SMTP connections because the Exchange team dropped such nice toys 
as TURN and ETRN in Exchange 2007 (shame, that). There are likely plenty of 
other examples where you have to adjust your traffic and deployment policies to 
meet the limitations of the applications and organizational requirements and 
you'll need to understand these before you make your final decision (or leave 
yourself some wiggle room afterwards)..

Yes; absolutely seek opinions, options and technical thingies and weigh them 
all against your own requirements and limitations.  You are the only one that 
can make the decision for your deployment and if it's based solely on "he 
said", then you haven't done your homework.  None of the "reference folks" on 
this alias will intentionally steer you wrong, but neither can you base your 
decisions on these discussions alone.

Security is not a goal; it's a repeating task. There is no "silver bullet" and 
the search for one can only end in unplanned cranial follicle freedom.

..we now return you to your irregularly-scheduled discussions...
..so there; thpthpthpthp :-)

From: isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx> 
[mailto:isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx>] On 
Behalf Of Tim Mullen
Sent: Wednesday, January 20, 2010 9:37 AM
To: isapros@xxxxxxxxxxxxx<mailto:isapros@xxxxxxxxxxxxx>
Subject: [isapros] Re: Exchange Server 2010 Edge and TMG 2010 Integration

Jim and I recently had a rather "spirited" conversation around this.  Hopefully 
we'll leave out things like "tin foil hat" this time :) (I had to Jim).

My general though is to start with security in depth and least privilege in 
mind.   As such, I begin the design of an Exchange Edge deployment with the 
mindset that I will not have them as domain members, but rather, simply 
stand-alone servers in a workgroup.   I guess my first question would be, what 
makes you think it is more complex and that it requires a more difficult 
configuration?

The role of the Exchange Edge is to accept SMTP mail for your domains, and 
presumably, to filter for spam and malware.  This only requires SMTP to the 
perimeter and nothing else.  If you choose to filter for recipient information, 
you can create an account for ADAM synchronization, however, I think you will 
find that the EE anti spam options are severely lacking in that respect - the 
logic is backwards; you can allow all main in TO someone, but not FROM someone, 
which totally defeats the purpose.  I doubt you will use the feature at all, 
which means that ADAM sync is not necessary.

Irrespective of that, the purpose of isolating the exchange edge box is to 
mitigate exposure should the server become compromised.  If you DO make it 
domain member, then that box will have stored credentials for administrative 
access available to an attacker, as well as the necessary traffic rules to your 
DNS and domain controllers to fully compromise your entire network.   My main 
rule in designing DMZ structures where there is anonymous access to the public 
for services (SMTP) is that "no credentials may live on that box which may be 
used on the internal network).  Making that box a domain member breaks that.

Now, that being said, am I to understand that you also wish to provide OWA, OA 
functionality via the Edge box?  If so, I don't see why - access to those 
services requires authentication, and can further be limited to certificates, 
so direct publication via TMG to your Exchange front end is acceptable.  The EE 
box should only be used for SMTP inspection.

Here's how I do it:

I begin with a 3 leg TMG box (UAG in my case):  Internal, External, and DMZ.  I 
publish SMTP (with the filter) to the DMZ to the Exchange Edge box.  It does 
it's thing.  I then smart-host deliver mail via another publishing rule to the 
internal Exchange box.  Yes, double publishing, with SMTP filter on both.

OWA/OA is directly published via 443 to my Exchange box.  The EE box is a stand 
alone server with different credentials.  It is managed via a one-way RDP rule. 
  If the EE box is compromised, the ONLY path to the internal network is via 
the SMTP publishing rule which is protected by the SMTP filter.  I have full 
management capabilities, there is no internal credential exposure, and there is 
only a single protocol inbound to my network.   To me, it is FAR more complex 
to securely publish and manage a domain member in the DMZ than a stand alone 
server, and increases the risk of exposure tremendously and really has little 
benefit.  GPO need only be applied once on a role-based server, and can easily 
be applied via template.

That's my buck o' five.

t

From: isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx> 
[mailto:isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx>] On 
Behalf Of Jerry Young
Sent: Wednesday, January 20, 2010 9:01 AM
To: isapros@xxxxxxxxxxxxx<mailto:isapros@xxxxxxxxxxxxx>
Subject: [isapros] Exchange Server 2010 Edge and TMG 2010 Integration

I wanted to bounce a question off of the list regarding usage scenarios for 
integrating TMG 2010 with an Exchange 2010 Edge Server.  My goal is to also 
install Forefront for Exchange on the boxes, too.

My question, however, comes down to thoughts on domain membership and TMG 
utilization.

My current thought is to make the Exchange 2010 Edge Servers domain members, 
install TMG on both of them in an array, and then use that same TMG array to 
provide reverse proxy access to other resources (like OWA, OMA, OA, CWA, etc.) 
through publishing rules.

As in the past, the Exchange Product Group doesn't want the Edge Servers to be 
members of the forest in which the Exchange organization is hosted.  I ran 
across postings on the Internet that indicate this can be done but was 
wondering what the list has seen deployed so far to date.

While I could certainly dump the Edge Servers into their own perimeter network, 
that would require additional complexity, planning, and configuration for my 
client that they would like to avoid; they accept the risks presented by having 
the Edge Servers be domain members with the condition that TMG is used to 
mitigate those risks.

Thoughts?
--
Cordially yours,
Jerry G. Young II
Microsoft Certified Systems Engineer
Young Consulting & Staffing Services Company - Owner
www.youngcss.com<http://www.youngcss.com/>



--
Cordially yours,
Jerry G. Young II
Microsoft Certified Systems Engineer
Young Consulting & Staffing Services Company - Owner
www.youngcss.com<http://www.youngcss.com>

Other related posts: