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

  • From: Steve Moffat <Steve@xxxxxxxxxx>
  • To: "isapros@xxxxxxxxxxxxx" <isapros@xxxxxxxxxxxxx>
  • Date: Tue, 9 Feb 2010 18:33:33 +0000

Plus, good luck configuring the anti spam bit.....

From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Thor (Hammer of God)
Sent: Tuesday, February 09, 2010 2:10 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: [isalist] Re: FW: Re: Re: Exchange Server 2010 Edge and 
TMG 2010 Integration

Apparently not ;)

Of course, she's talking about installing it on the firewall itself, which I 
would never do.  Of course, I would never use the default configuration of the 
SMTP Protection either since there is no filtering of SMTP and you basically 
have a full ESMTP server running bits you don't control unfiltered that is 
reachable by everyone on the globe without filtering.

As I understood your config, you were publishing to a separate machine in the 
DMZ that is running the Edge role of Exchange as a domain member, not loading 
up everything on your edge firewall.

t

From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jerry Young
Sent: Tuesday, February 09, 2010 10:00 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: [isalist] Re: FW: Re: Re: Exchange Server 2010 Edge and 
TMG 2010 Integration

Did I misread?

First paragraph of the article:

"You might or might not know it, but the TMG firewall was designed to be a 
comprehensive edge email hygiene solution for your network. You can install the 
Exchange Edge server on the TMG firewall to get the email control features 
included with the Exchange Edge solution, and you can also install Microsoft 
Forefront Protection for Exchange on the TMG firewall. The combination of 
Exchange Edge and Forefront Protection for Exchange is a mighty one-two punch 
against spam, malware, and information leakage for your organization."

And the screenshots show Exchange Edge being selected as the Exchange Server 
Role to be installed.
Am I somehow looking at the wrong document?
On Tue, Feb 9, 2010 at 12:50 PM, Thor (Hammer of God) 
<Thor@xxxxxxxxxxxxxxx<mailto:Thor@xxxxxxxxxxxxxxx>> wrote:
Not sure where you get Exchange Edge from in any of that.  She's talking about 
TMG SMTP Protection, which is something else entirely.

t

From: isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx> 
[mailto:isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx>] On 
Behalf Of Thor (Hammer of God)
Sent: Tuesday, February 09, 2010 8:06 AM

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

Was that the right article you referenced?  That was Deb talking about 
installing TMG.   I didn't see anything about EE....

t

From: isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx> 
[mailto:isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx>] On 
Behalf Of Jerry Young
Sent: Tuesday, February 09, 2010 5:56 AM

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

Tim,

I still do plan on getting back to this topic.  Things have been hectic, thus 
my delay in a response.

In the meantime, though, to add fuel to the fire here, take a look through this 
series of articles.  I missed this piece initially, otherwise I may not have 
even started this thread.  I'm glad I did, though.

http://www.isaserver.org/tutorials/Installing_Threat_Management_Gateway_2010_RTM_Enterprise_Edition.html

It talks precisely about installing Exchange Edge on a TMG DM.

Once I get some time (building out a completely new infrastructure at the 
moment), I'll respond with some thought behind the responses and try to bring 
the conversation to a middle ground where we can prescribe the best way to 
secure an environment where Exchange Edge is installed on a TMG DM.
On Mon, Jan 25, 2010 at 11:17 PM, Thor (Hammer of God) 
<Thor@xxxxxxxxxxxxxxx<mailto:Thor@xxxxxxxxxxxxxxx>> wrote:
I went back and read your original question just to make sure I didn't miss 
something obvious - I took the spirit of the question initially to mean "What 
are your thoughts on Exchange Edge in a DM."  I gave you those, which I assumed 
meant "vs a workgroup."  You already having made up your mind to have it a DM 
renders all my previous points moot.  Had I realized this in the beginning, my 
entire response would have been quite different.

That being said, I've got some responses inline:

From: isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx> 
[mailto:isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx>] On 
Behalf Of Jerry Young
Sent: Monday, January 25, 2010 11:42 AM
To: isapros@xxxxxxxxxxxxx<mailto:isapros@xxxxxxxxxxxxx>

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

I had to take my time in thinking about how to respond to this one because this 
response, in particular, I found considerably vexing.
On Fri, Jan 22, 2010 at 12:17 AM, Thor (Hammer of God) 
<Thor@xxxxxxxxxxxxxxx<mailto:Thor@xxxxxxxxxxxxxxx>> wrote:
I find that short sighted - mitigating risk doesn't start and stop with the 
attack vector.
You realize this statement essentially invalidates my question?  I never, ever, 
said mitigating risk starts and stops with the attack vector.  An attack vector 
is part of the overall security anatomy and understanding it, why it exists, 
and how it can be leveraged and exploited are very crucial bits of information 
when determining mitigation strategies.  The question was anything but 
short-sighted; rather, it was incredibly focused, with an eye toward the larger 
picture.  Think of it as a game of Chess, if you will.  I asked how (inversely) 
a Pawn might take a King.  This statement is essentially saying, "don't worry 
about the Pawn, just protect the King".

T:  Actually, no - if anything we've got this backwards.  You were totally 
focused on SMTP as the only vector, and how it specifically can be used.  
That's simply not the way to look at it - the point is that you DON'T KNOW what 
the vectors are.  Are you trusting the 10-year-old Trend Micro code base to be 
secure?  How do you know that putting the Edge Components on the server don't 
actually introduce more vulnerabilities that can be triggered with some 
particular virus pattern?  You don't.   You have no idea what vulnerabilities 
are in any of the products you are putting on the server.  You don't know that 
TMG doesn't have some vulnerability somewhere.  In fact, if you decide to 
implement  SMTP Protection on the TMG install you put on the edge server, then 
you've completely obviated the SMTP filter and have an "open" ESMTP server 
anonymously available.  "Understanding it and why it exists" presumes knowledge 
of the exploit/vector in the first place, which again, you don't have and will 
never have.   I'm not saying anything of the sort regarding "don't worry about 
the Pawn, just protect the King," in fact, I'm saying "yes, knowing the rules 
you know, protect the King and the Pawn" (unless you are worried about the Pawn 
taking the King via 'en passant' which it can't do of course), "but also 
consider what happens when the dog knocks over the board."


I call bollocks on that and will reassert that understanding how an attack 
vector can be used is just as every bit important as understanding defense in 
depth and least privilege concepts.

T: Maybe I wasn't being clear - understanding how the vector can be used should 
be obvious to you and shouldn't really be part of this conversation.  
Protecting against the known is academic; it is creating a structure that 
resists or mitigates unknown attacks that one should concentrate on.

If an attacker is savvy enough to hack into an Exchange Edge server through 
SMTP, then *my* assumption is that they're going to be savvy enough to hack 
their way further into my network, regardless of whether or not that box is a 
domain member (DM).  And since it has to deliver SMTP somewhere inside, what's 
to say that the same hack that compromised the Exchange Edge won't compromise 
the internal box?

T:  Who says it has to be savvy?  You don't know what vulnerabilities exist.  
For all we know, you might be able to type in "Open Sesame" in Hindu after 42 
NOOP commands and get Local System.   More on that later...

Security in depth and least privilege should be exercised where possible to 
limit what can be done AFTER a compromise.
As I said before, and multiple times, I agree with you.  I will point out, 
however, the key phrase: "exercised where possible".  I indicated from the 
onset that I wouldn't be able to do this by putting the boxes in a workgroup 
(WG).  Ergo, the follow up question logically then becomes what can I do when 
the boxes are DMs to maximize security and mitigate as much risk as possible.

T: Again, I wish I had understood this from the beginning.   The following 
presupposes that one has something of "value" to protect, obviously, as would 
be the case in the first place.   First off, you make sure the required rules 
are on a box-to-box basis:  meaning, you only domain-based and management 
traffic to/from the DCs and not "everywhere."  If possible, create one rule 
that supports this traffic, which could range from LDAP, RPC, CIFS, NETBIOS, 
DNS, Kerberos, etc and disable the rule when you don't need to be managing the 
system.  As I've said before, your "management" needs to the Exchange Edge box 
are going to be minimal.  I call horse hockey on the "ease of management 
dictates a DM" mindset as you can easily manage the entire box with a single 
RDP rule in a WG, but that again is a moot point.  Given the wide-range of 
attacks one could leverage against your DCs using the "on-box" credentials, and 
given the lack of need for domain/management protocol rules to be active 24/7, 
what I have done in the past is use a simple script to enable the rule via WMI, 
launch RPD, do my business, and disable the rule again.   But it depends on 
what you are protecting if you want to go through that trouble.  I do it 
because I *know* what I've done in the past given DM membership in DMZs during 
audits.


In this case, irrespective of the membership disposition of the server, your 
initial attack vector is identical:  SMTP.  A vulnerability in the Exchange 
smtp engine could result in server compromise: I bring to mind the XLINK2STATE 
vulnerability.
Which could possibly result in a DoS attack or an attacker being able to run 
malicious code in the security context of the SMTP service, which has become 
stricter in Exchange iterations (from Local System to Network Service).  
Indeed, in order to exploit this in Exchange 2003, the attacker would have had 
to have been authenticated with the equivalent rights of another Exchange 
server in the organization.

T: That was just an example.  You have no idea what the next attack may be, 
what the authentication requirements are, or how it will be exploited.
Granted, TMG application filtering would have mitigated that attack, which is 
great, but we just don't know what vulnerabilities lie in wait.
While you may not know what is lying in wait, you can at least conjecture as to 
what would be required to allow an attacker to use an Exchange Edge server as a 
platform from which to launch subsequent attacks against internal resources.

T: Indeed!  The basis of that conjecture would be the difference between a DM 
or WG.  In a DM, you've got admin credentials on the box and an uninhibited 
direct path to your domain controllers for immediate compromise of the entire 
infrastructure.  In a WG, you only have SMTP going through the ISA filter.   
Seems like a no brainer to me.  But, as Jim has said, if you are bound by some 
"policy" or other force to make it a DM, no matter how stupid it may be, that's 
what it is.  That's why I said pull out metasploit and see how many different 
attacks there are when you have domain/management traffic open as opposed to 
SMTP only.

So, assuming the worst case scenario of an attacker managing to get 
administrator access to the local box over SMTP, completely ignoring how such a 
feat was accomplished, what needs to occur after that for the attacker to 
launch their attack further inward?

T: NOW we are getting somewhere.... I'll answer that one below.

Wouldn't they need data back?  How would they get that?  Wouldn't an ASA with 
an ESMTP filter running on inbound SMTP (and outbound SMTP) traffic pick up 
anomalies in the SMTP traffic, even if TMG stopped paying attention, dropping 
packets that didn't conform to the filtering requirements?  How would the 
compromised server talk back to the attacker's system if only established 
inbound SMTP sessions and outbound SMTP traffic were allowed on both the TMG 
server and the ASA?  How might each manner of leverage be countered?

T: They would get traffic back any way they wanted to.   If I'm executing code 
on the server in admin context, I can do whatever I want.  I can add rules to 
the TMG install.  I can stop the Exchange service altogether and connect back 
to 25.  I can uninstall TMG.  I can load a kernel mode root kit and monitor 
every email going in and out for the next year if I wanted to.   I would only 
be limited to my imagination.
Given that, you must look at what extent one may leverage server compromise in 
that case.  TMG protecting the unit won't do any good when you have full 
(required) protocol support for remote manageability and domain membership.   A 
system level compromise on a domain member server would lead to almost 
immediate compromise of the entire internal network.  A workgroup would not.  
It's as simple as that.
And again, I will raise the question that if an attacker could compromise a 
server over SMTP, what would stop them from doing the same thing with your 
internal box without ever leveraging potential vulnerabilities in domain 
membership and remote management protocols?  To take the argument to the 
extreme, why even trust a Microsoft-based platform in your DMZ at all?  Aren't 
all Microsoft operating systems just as inherently insecure (note tongue in 
cheek)?

T: Depends on how the systems are configured.  If you use the SMTP Protection 
on Edge, then you don't use the filter by default.  However, your publishing to 
the internal box very well may be using the SMTP filter would could obviate the 
same attack.  You are actually making my point for me in regard to WG vs DM.   
If I own that box, and you have traffic open for DM/Remote, then you've made my 
job trivial.   If the same exploit could be leveraged over SMTP even in light 
of the filter, then you are screwed.   Oh well, we tried.  That's how this 
stuff works.  You do the best you can do.


That aside, if I were the attacker and I had developed a zero-day exploit that 
could do all this, I would certainly continue to try to utilize it; precisely 
because I know it hasn't been seen before.  Why risk discovery more than 
absolutely necessary to accomplish my goals?

T: If I won the lottery last night, I wouldn't be replying to this email.  I 
don't try to think for hackers or other people.  Who know why they would do 
what they would do?  The way it would really work is that at some point, the 
0day would become known, and many many people would not patch against it, and 
script kiddies would start using it.   I don't really understand your point 
here or how it is relevant.

Additionally, the services required to be running and assessable on the server 
if a domain member actually open up additional attack vectors as I've 
previously noted.  Look through Metasploit for attacks against CIFS, admin 
shares, authentication services, RPC, LDAP, etc etc that would be open to 
attack from parallel systems in the DMZ.
Simple mitigation strategy: Put in segregated DMZ subnet.  Voila, no parallel 
systems in the DMZ.

T: But you've got shotgun blasts in your firewall for remote management and 
domain traffic.  Wala, pwned.   This is the exact type of question that makes 
me yell "WTF?"  You'll go through all the freaking trouble of creating rules 
for domain and management traffic, creating the DMZ segment itself, loading TMG 
on the Exchange Edge box itself, and then creating your segregated DMZ segment 
just so that you can have it a DM and less secure?   I fail to understand how 
one can arrive at that logic.

None of those services would be necessary on a stand alone server.  You could 
turn off everything, and only allow RDP in for admin.
As I've said before, yup, I agree with you.  What does one do when that 
argument isn't good enough for TPTB to allow what they see as greater 
complexity, configuration, and management overhead?  What does one do when one 
is told to simply mitigate the identified risks as best as one can (answer 
coming to that, though ;))?
So, I'll ask the question again:
What does making your Exchange Edge server in the DMZ a domain member buy you?
Centralization and ease of management. Plug and play integration with current, 
well understood processes. Single account management.

T:  The infrastructure you have created that gives you centralized and easy 
management, plug and play integration and single account logons is, by its very 
design, extended to your attacker.   You've just made their job much, much 
easier and bought yourself nothing you can't do over RDP.
What can you do that you couldn't do otherwise as a stand alone box?
Implement immediately without any changes to the networking infrastructure to 
support such a separation.  Manage immediately without defining a new, 
unfamiliar process for stand alone boxes.  Use current admin accounts for 
management.

T:  This is going to sound crass, but if the membership disposition of an 
asset, more specifically, an asset that is a WG member as opposed to a DM 
requires you to define new processes or presents "unfamiliar processes" to your 
administrators, then you've hired the wrong people.  Phrasing the answer like 
that tells me that you've never even tried.  One should not implement processes 
that exponentially increase security risk based on inexperience or because it's 
"easy."  Not and get paid for it, anyway.
Is your intent to simply open the Exchange Management Console from the internal 
network and manage the box in the DMZ?
Nope.
This isn't arguing a model - this is identifying concrete risks and benefits.
I indicated I understood the risks and benefits of deploying a WG over a DM.  
Multiple times.  Nicely, too! :P  My question was how can I secure best as a 
DM, to which the answer has been, make it a WG.  That seems argumentive to me.

T: My bad.  I didn't see your multiple iterations indicating your understanding 
of the risks and benefits.  I only saw the question of what we thought of 
deploying the system as a DM.
What CAN'T you do if you make it a WG?
Implement immediately without any changes to the networking infrastructure to 
support such a separation.  Manage immediately without defining a new, 
unfamiliar process for stand alone boxes.  Use current admin accounts for 
management.

T:  See my smart-ass answer above about making the hackers job easier ;)
And yes, the forgone conclusion is that the Exchange Edge server will be 
compromised - if not, then why are you putting it in a DMZ to begin with?
To gradually move us in the right direction.
Why even have Edge?
It's a step in the right direction and better than not having an Edge.

T:  Well said, and I totally agree.  The next step is to make it stand alone 
:)))))))
If you are not concerned with server compromise, then just publish SMTP 
directly to your internal Exchange box and be done with it.
That's being done now (external to IronMail - notice not Windows; IronMail 
directly to internal "SMTP gateway" servers); I'm trying to move them away from 
it.
Let's talk about the administrative and management needs  you have, and then 
bring the argument in for a domain member since it should be painfully obvious 
that a DM is far less secure than a stand alone.
You're still arguing the model, using the point of the end trumps the means.  
Up until just recently, the means have been trumping the end.  And ultimately, 
if they're connected to the network, they're both equally insecure for the very 
reasons I stated earlier.  I will add only this: if you accept the eventuality 
of your DMZ box being compromised as a given, then you must also accept the 
eventuality of *any* internally connected box being compromised as a given.
The argument here should be "why make it a DM" which I'm still waiting to hear 
about.
Centralization and ease of management. Plug and play integration with current, 
well understood processes. Single account management.

I must happily report, however, that I was able to convince the CIO to move 
forward with a WG security model not by arguing for it (that didn't work in the 
past) but rather by arguing against it - reverse psychology at its best. :)  
And I broached the subject by presenting that which vexed me most about this 
message: the preceived invalidation of my question regarding the SMTP attack 
vector.

T:  Excellent!  Please let us know how that works for you.  While Jim's 
comments are indeed applicable and valid, I believe the "policy" of a DM 
requirement is mostly based on perceived benefits rather than actual.  Please 
let me know any administrative or management challenges that you come across 
that might make them say "screw it, make it a DM" and I'll be happy to help.

That being said, I still think we should explore this as I know there are going 
to be others out there that won't be as successful as I was in influencing 
management's (re)direction.

T:  Totally.  I'm more interested in the ACTUAL methods of management that are 
perceived to be "easier" rather than "because it's easier" as a general 
postulate.  Let's continue on from there.

I'll be more than happy to continue to humbly play the devil's advocate.
t

From: isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx> 
[mailto:isapros-bounce@xxxxxxxxxxxxx<mailto:isapros-bounce@xxxxxxxxxxxxx>] On 
Behalf Of Jerry G. Young II
Sent: Thursday, January 21, 2010 6:22 PM
To: isapros@xxxxxxxxxxxxx<mailto:isapros@xxxxxxxxxxxxx>
Subject: [isapros] Re: [isalist] Re: FW: Re: Re: Exchange Server 2010 Edge and 
TMG 2010 Integration

So, the foregone conclusion is that the Exchange Edge server will be 
compromised?

How might that happen over SMTP on a box that has TMG installed?

Admin carelessness?  Zero-day exploit?

What are the most likely breach scenarios?

Greg's right; we can argue models all day.  But the same argument can be had 
about how to prevent yourself from being run over by a car while walking along 
a sidewalk paralleling a street.

I respect the principle.  I need concrete risks, however, not simply just 
potential, possible, postulative risks.

I need to understand how the initial breach could happen, not how bad it could 
get if it did.

I'd like to discuss that.

Sent from my iPhone.

On Jan 21, 2010, at 8:50 PM, "Thor (Hammer of God)" 
<Thor@xxxxxxxxxxxxxxx<mailto:Thor@xxxxxxxxxxxxxxx>> wrote:
Just to be clear - I'm fully aware of the benefits of DM, obviously.  I'm 
talking about DMZ assets.

t

From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx> 
[mailto:isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>] On 
Behalf Of Thor (Hammer of God)
Sent: Thursday, January 21, 2010 5:42 PM
To: isalist@xxxxxxxxxxxxx<mailto:isalist@xxxxxxxxxxxxx>
Subject: [isalist] Re: FW: Re: [isapros] Re: Exchange Server 2010 Edge and TMG 
2010 Integration

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

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 4:21 PM
To: isalist@xxxxxxxxxxxxx<mailto: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<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 3:43 PM
To: isalist@xxxxxxxxxxxxx<mailto: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> 
[mailto:isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx>] On 
Behalf Of Jerry Young
Sent: Thursday, January 21, 2010 12:58 PM
To: isalist@xxxxxxxxxxxxx<mailto: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/>



--
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/>



--
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: