[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 08:55:41 -0500
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
Other related posts: