In line: >> Initially, the benefits of the FE Exchange Server in the DMZ are >> counter-intuitive. I think this is because, ironically enough, one strives >> to totally protect all "trusted" assets- thus the default instinctive action >> to "bring the FE into our protected network." It for this very reason that >> I believe we should further protect the FE Exchange Server: if that asset is >> compromised, the potential risk of further internal compromise is greatly >> escalated due to its trusted role in the infrastructure - particularly when >> the FE is located on the internal network with typical full-stack access to >> the rest of the network. > > I whole-heartedly agree with this in theory. However, security is about risk > management, because of the following real-world limiting conditions: > > 1) There is no such thing as security perfection. I can't set things up once > and walk away, because attacks and attackers evolve. > 2) The more complex my security regime is, the more it limits usability. > 3) The more complex my security regime is, the more it costs -- either in > materials or in time. > 4) Admins never have enough time.
Well, this is applied- it is not theory. This is almost exactly how my corporate topology is set up and working on an everyday "real-world" basis. And I never said anything about setting it up and walking away, or about "perfect security." Regarding complexity, that is a matter of one's view. This really isn't that complex. It is when discussing it and flushing out all of the ideas behind it, but in application it really comes down to setting up the Perimeter network and configuring the appropriate rules. > Therefore, here's my question to you and the other readers to consider: does > this architecture protect me from enough risk to warrant the additional cost > and loss of functionality? Note that by risk I mean not just a potential > threat, but from a threat whose likelihood has been judged to be high enough > to warrant the expense of preventing or mitigating it. That all depends on what you are protecting. In this case, the additional "loss of functionality" is by design. The goal of this topology is to deliver a full-functioning OWA interface in a least-privileged environment. The only lost functionality is remote admin via CIFS or RPC. That's fine for me, as I accomplish that in a FAR more secure way via RDP. But if you NEED that, then set your ruleset appropriately- its still better than allowing such an integrated asset a full-stack shot at your entire internal network. >> Since we, by design, offer OWA access from the web, >> we basically extend an interface from an untrusted network to an asset on >> the internal network in the standard publishing model (even given the >> "non-swiss cheese" application filters used in ISA publishing) > > I would disagree with this characterization. ISA isn't merely filtering and > relaying communications from untrusted networks to trusted networks. It is a > true application proxy when configured to publish Exchange. Attackers have > to compromise both ISA's filtering/proxying code *as well as* the Exchange > SMTP code in order to successfully exploit a vulnerability -- and they are > two different codebases. Well, that depends on how it is published. If a direct SSL server publication, it can't inspect the traffic. If you are doing an SSL bridge, then it can. But that doesn't matter where the attack is valid HTTP. I'm aware of how ISA functions in publishing models and what it does and doesn't do-- in either case, the FE is published through ISA anyway - I'm not taking any of that out of the design (I already stated that in the earlier example). The FE is just being further restricted by a perimeter network segment, thus providing more protection to the internal network. And I'm not quite sure what you mean by having to "compromise Exchange's SMTP code" - SMTP doesn't come into play at all in the FE to BE OWA traffic model. The user uses HTTPS to hit the FE. The FE uses Kerb-Sec to authenticate the user to the DC's and LDAP to retrieve BE info. The FE then uses HTTP to the BE to transfer mail data to the FE OWA interface. >> The "real-world" communication requirements for "proper" (meaning "secure") >> FE operations are quite overstated, even in the Microsoft documentation. > > Understand that the Microsoft documentation isn't trying to necessarily > attain the maximum restrictions necessary. They're trying to define to > maximum restrictions necessary to adequately guard against the likely risks > (as judged by the product team, who gets the feedback from a lot of > customers and from their own IT deployment) to an Exchange organization, > while allowing the customers who deploy this configuration to continue to > maintain and administer their Exchange machines using supported > methodologies and procedures. I disagree. The recommendations have nothing to do with "likely risks." They have everything to do with what is required for your "standard," and more importantly, *supported* Exchange Server 2003 configurations, and what traffic is required for full functionality. I'm talking about what is required for OWA to function properly in a least-privileged environment. THAT is where one addresses likely risks. > In other words, they're striking a balance between maximum security and the > ability for the inexperienced admin to gain a "good enough" degree of > security while still having a supported configuration that can be properly > maintained and updated. I disagree again. They are not doing anything of the sort- it is a "hardening guide," and nothing NEAR "maximum security." Further, your inexperienced admin wouldn't go within 10 feet of that KB. > Steve Riley, one of Microsoft's security gurus, makes a very compelling > argument that a lot of security measures end up being nothing more than > tweaks. He and Jesper Johansson (writing together in "Protect Your Windows > Network From Perimeter to Data", Addison-Wesley, ISBN 0-321-33643-7) point > out that many of the major security incidents in the last several years > aren't stopped by configuration tweaks because they're really exploits of > unpatched vulnerabilities. Therefore, the process of keeping your systems > secure necessarily includes making sure they can be updated quickly and as > easily as possible -- preferably in an automated fashion. I've worked with both dudes on projects within Microsoft. Neither one of them would call this a "configuration tweak." And both of them would applaud measures that extend the concepts of security-in-depth and least privilege. One of the first things someone would do after popping a FE OWA server would be to try to get root, add themselves to the domain, leverage shares, or exploit other vulnerabilities on the network. Start from a popped box: in the "FE is on the internal network model," you are completely and immediately screwed right off the bat. In the topology described here, the attacker is *severely* limited in what they can do and what other assets they can hit. Again, I'm not busting on your recommendation- I think it is a GREAT recommendation, and one that many people should follow. And, for those people who are deploying a FE OWA server, which extends services of a trusted network to an untrusted network, and want to further mitigate the risks of doing so, that the "FE in a DMZ Perimeter Network" design is a powerful way of doing that... > Note that the Exchange Server 2003 Security Hardening Guide > (http://go.microsoft.com/fwlink/?LinkId=25210) gives you a precise list of > which services need which ports incoming and outgoing. Right. And I've given a precise list of what is *really* required to support OWA functionality with the FE in a DMZ perimeter. > Well, that's not all it breaks. Many environments today worry about > regulatory compliance and must be able to track messages through their > Exchange organization. In order to use Message Tracking, I have to enable > port 445 traffic on that FE server... Why? Track on the back end. I have full message tracking enabled and configured, and do not (and would not) enable 445 on the FE server. And what regulatory compliance documentation tells you how to configure your FE servers? Look, there are a million ways someone can argue to do things the simple, easy, no headache way. "Regulatory compliance" is one of those ways. This is a real-world method of gaining a much better security posture when deploying OWA. > Sometimes I can't allow people to RDP into a box and have to allow MMC > management. "You should" is great in a perfect world, but there are plenty > of good reasons why management and security administrators won't do things > that way. Why wouldn't I want admins on the box? Well, regulatory compliance > is a big one again; if I let all of my admins log into the box, instead of > just a small subset, I have potentially magnified my risks. How do I audit > their actions? How do I protect against a junior admin doing something to > gain escalated access? Ask all of those questions when comparing a box with full-stack access to the entire internal network, and one where only Kerb and LDAP can hit only the DC's and only HTTP can hit the BE Exchange servers. THAT is where the comparison should be made. > It's a great configuration, yes -- if the extra expense and effort solve the > problems you're trying to solve. Unfortunately, it adds quite a bit of > complexity. It doesn't address, in my mind, one of the biggest problems with > the FE architecture, which is that a successful compromise of the FE server > potentially leaves the attacker with really good access to my entire AD > infrastructure. Unfortunately, that's an artifact of the current FE/BE > design and there's not really anything I *can* do about that. That is EXACTLY what this addresses! If they pop the FE server, they are severely restricted to what they can do. That's the whole point! > I can solve the issue of using the FE as a jump point into the rest of my > network by using Group Policy to distribute IPSec filters that prevent the > rest of my machines from accepting inbound connections from my servers. > Defense in depth is a good thing. I'm going to be looking at these filters > regardless of my DMZ configuration... But do you? Do you actually have IPSec rules that prevent the rest of your machines from accepting inbound connections from your servers? How does that work? That seems like an impossible-to-manage configuration there... The FE in the Perimeter isn't as complex or expensive as you might think. Once you get into it, it's pretty easy to handle and manage. > Dang, I'm long-winded; I guess I need to contact the Church of Security As A > Process and see if they have any job openings for evangelists. :) As am I ;) Good conversations.... t --------------------------------------------------------------------------- ---------------------------------------------------------------------------
