[isapros] Re: [isalist] Re: FW: Re: Re: Exchange Server 2010 Edge and TMG 2010 Integration
- From: Jerry Young <jerrygyoungii@xxxxxxxxx>
- To: isapros@xxxxxxxxxxxxx
- Date: Tue, 9 Feb 2010 12:26:18 -0500
Sorry,
A bit convoluted.
The following is the URL to the document that referenced the URL - as a
starting point - I just shared.
http://www.isaserver.org/tutorials/Installing-Configuring-Email-Hygiene-Solution-TMG-2010-Firewall-Part1.html
Here's the specific language that calls out to it:
"So, in defense of those who favor the RTFMLIAA (“read the freaking manual
later, if at all) approach, let us get started and see if we can pick up
where let off in the last
article<http://www.isaserver.org/tutorials/Installing_Threat_Management_Gateway_2010_RTM_Enterprise_Edition.html>.
In that article, we completed the installation of TMG Enterprise Edition on
a Windows Server 2008 R2 server that had two NICs. Now our next objective is
get the email protection features working."
If you click "last article", you're taken to the URL I originally provided.
After reviewing it again, I don't think this was necessarily written as all
of the same series so much as it was using a previously written document as
a basis for the Email Hygiene Solution series.
Still, taken together, you'd end up with Exchange Edge installed on a TMG DM
with Forefront Protection 2010 for Exchange installed.
On Tue, Feb 9, 2010 at 11:06 AM, Thor (Hammer of God)
<Thor@xxxxxxxxxxxxxxx>wrote:
> 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
>
>
>
>
> --
> Cordially yours,
> Jerry G. Young II
> Microsoft Certified Systems Engineer
> Young Consulting & Staffing Services Company - Owner
> www.youngcss.com
>
>
>
>
> --
> Cordially yours,
> Jerry G. Young II
> Microsoft Certified Systems Engineer
> Young Consulting & Staffing Services Company - Owner
> www.youngcss.com
>
>
>
>
> --
> Cordially yours,
> Jerry G. Young II
> Microsoft Certified Systems Engineer
> Young Consulting & Staffing Services Company - Owner
> 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:
