[isapros] Re: [isalist] Re: FW: Re: Re: Exchange Server 2010 Edge and TMG 2010 Integration
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Wed, 10 Feb 2010 21:29:07 -0600
Yo boyz,
I would argue that the combo of FSE and Exchange Edge on the TMG
firewall is a far more secure solution that just the SMTP filter. While
the SMTP filter has it value, the FSE/ExchEdge combo is pretty
impressive and I don't think it's going to subject the firewall to a
"party down on TCP port 25" scenario that Tim describes.
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Jim Harrison
Sent: Tuesday, February 09, 2010 1:00 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: [isalist] Re: FW: Re: Re: Exchange Server 2010
Edge and TMG 2010 Integration
I know you miss your NOOP demo (and it does impress the attendees), but
you're overstating the problem.
"there is no filtering of SMTP " - while you don't have the same
filtering level you enjoy for server publishing (TSu expressed similar
complaints during the SBS heyday, and no, this is not a comparison
between you), to say that TMG provides "no filtering" in this case is
false. The problem you correctly identify is the loss of the publishing
context from the SMTP filter where the SMTP verbs are evaluated by the
SMTP app filter. the co-location of TMG and Exch Edge forced some
decisions; one of which was wether to use access rules or server
publishing for Internet connections. Access rules were chosen to keep
the traffic path simple. As a result, the "server" context of the SMTP
filter was not used. TANSTAAFL, folks.
"reachable by everyone on the globe without filtering" - Does the lack
of the "server" context change the way the SMTP filter performs traffic
evaluation for co-located Exch Edge? Yes. Does it completely eliminate
SMTP filtering? No. TMG may not apply the SMTP app filter the way
you've become accustomed, but this hardly leaves the local SMTP service
"naked to the Internet". You still have NIS and TMG Flood Mitigation to
help protect the TMG-local mail services.
Is it possible to secure a DM Exch Edge? Yes. Is it better to have it as
a WG deployment? If the prevailing opinion is "WG is more secure than
DMZ", then the answer is "yes" and the Exch team produced this role
specifically to serve this need.
Whether the results of a co-located TMG/Exch Edge meet with your
definition of "secure" is something that has to be taken in the context
of the environment where this deployment is operating. If your Exch Edge
requires deployment on a WG, but your TMG deployment requires DM, then
you have no choice but to separate them from one another.
HTH,
Jim
________________________________
From: isapros-bounce@xxxxxxxxxxxxx [isapros-bounce@xxxxxxxxxxxxx] on
behalf of Thor (Hammer of God) [Thor@xxxxxxxxxxxxxxx]
Sent: Tuesday, February 09, 2010 10:08 AM
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> 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]
On Behalf Of Thor (Hammer of God)
Sent: Tuesday, February 09, 2010 8:06 AM
To: 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]
On Behalf Of Jerry Young
Sent: Tuesday, February 09, 2010 5:56 AM
To: 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> 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]
On Behalf Of Jerry Young
Sent: Monday, January 25, 2010 11:42 AM
To: 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> 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 J))))))
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] On Behalf Of Jerry G. Young II
Sent: Thursday, January 21, 2010 6:22 PM
To: 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> 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] On Behalf Of Thor (Hammer of God)
Sent: Thursday, January 21, 2010 5:42 PM
To: 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] 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> 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] On Behalf Of Jim Harrison
Sent: Thursday, January 21, 2010 12:17 PM
To: 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
[isalist-bounce@xxxxxxxxxxxxx] on behalf of Thor (Hammer of God)
[Thor@xxxxxxxxxxxxxxx]
Sent: Thursday, January 21, 2010 8:47 AM
To: 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] On Behalf Of Jim Harrison
Sent: Wednesday, January 20, 2010 5:04 PM
To: 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] On Behalf Of Tim Mullen
Sent: Wednesday, January 20, 2010 9:37 AM
To: 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 J (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] On Behalf Of Jerry Young
Sent: Wednesday, January 20, 2010 9:01 AM
To: 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
Other related posts:
