On 5/16/06 9:23 PM, "Thor (Hammer of God)" <[EMAIL PROTECTED]> wrote:
> Consider the following illustration: <snip the FE perimeter description> > 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. 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. I'll get to my thoughts on that in a minute. > 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. > Thus, it stands to reason that an asset important enough to be protected by > the internal "protected network" should be even better protected in an > environment where only the necessary services/protocols are allowed in to > the "real" network. Particularly when the service is extended to the web. > 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. 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. 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. > Rules to support *only* the Perimeter network box to *only* the internal > Domain Controllers object for: > > DNS (both TCP 53 and UDP 53 as Exchange uses both for DNS lookups) > Kerberos-Sec* (UDP 88) > [*This is the big one. Most documents will have you open up Kerberos-Adm > (both UDP and TCP 749), Kerberos-Sec TCP (88), Kerberos-IV (UDP 750) as well > as CIFS and RPC in BOTH freaking directions. None of this is required.] 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. > LDAP (TCP and UDP 389) > LDAP GP* (TCP 3268) > [LDAP is only necessary if you need Global Catalog access from the box] All Exchange 2000/2003 servers require GC access. If you cut off an Exchange server from a GC, you can suffer any number of errors, from subtle impossible-to-diagnose glitches to message routing errors to flat-out services not starting, depending on your configuration. > This minimal rule-set will allow the FE Exchange Server to function > perfectly without having to allow all the other authentication/NetBIOS > traffic in/out. NOTE: This will not allow you to manage the FE Exchange > Server from the internal network via the Services Manager MMC (or any other > means) as no OUTBOUND traffic for these protocols is allowed. This is a > _good_ thing... You *NEVER* want to allow authentication protocols to > *leave* your network. That's just silly. You should manage the box via > RDP (requires an OUTBOUND only rule to just that box) outbound. The creds > are encrypted, and all traffic is on your RDP port (typically 3389.) 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... 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? > Now, you need rules to support *only* the Perimeter network box to *only* > the internal back-end Exchange servers that house the mailboxes the OWA > users must access: it is a "good news, bad news" scenario. Please don't forget that OWA isn't the only reason to use FE servers. There are still people using POP3 and IMAP, and other people have their FE server do double-duty as bridgeheads. These will all increase the number ports required. > There is detailed information regarding this topology on ISASERVER.ORG, > which rocks. Additionally, Jim Harrison and I are leading a 2 day training > at the Vegas Blackhat specifically on ISA configurations for those who are > interested. 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. 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... So don't take this as me knocking the extra DMZ architecture you describe. There are lots of networks that it's a good configuration for, but it brings an elevated set of challenges with it (how do I get patches to my box? How do I address specific compliance concerns?). That's why I usually recommend the ISA-in-the-DMZ approach; it makes the fewest assumptions about their existing network configuration and security measures, gives good value for the amount of effort that is required to implement it, provides adequate protection for the vast majority of risks, and is simple enough for overworked admins (and their non-tech managers) to fully understand (so they don't later end up compromising some of their protection because they don't realize the implications of something they just did). 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. :) -- Devin L. Ganger Email: [EMAIL PROTECTED] 3Sharp LLC Phone: 425.882.1032 x 109 15311 NE 90th Street Cell: 425.239.2575 Redmond, WA 98052 Fax: 425.702.8455 (e)Mail Insecurity: http://blogs.3sharp.com/blog/deving/ --------------------------------------------------------------------------- ---------------------------------------------------------------------------
