CIL.... Thomas W Shinder, M.D. Site: www.isaserver.org Blog: http://blogs.isaserver.org/shinder/ Book: http://tinyurl.com/3xqb7 MVP -- ISA Firewalls
> -----Original Message----- > From: Devin Ganger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 17, 2006 2:31 PM > To: Thor (Hammer of God); [EMAIL PROTECTED]; Focus-MS > Subject: Re: Front End/Back End communication > > 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. TOM: But this is the rub -- the configuration is not that complex, no more than the average PIX or Check Point. I'm not that smart and I can do it, so most enterprise or even mid sized biz admins can do it with the proper guidance. Of course this doesn't apply to SBS because it can't be secured. > 3) The more complex my security regime is, the more it costs > -- either in > materials or in time. TOM: Just a one-time cost of setup. Takes maybe an hour at the most to perform the actual config. Then you back it up and if something goes haywire, you restore from backup. Really, its not that hard, I know a number of orgs (those that I've set up and those others have set up) that use this kind of robust security zone segmentation. It take maybe a couple of hours in the lab to practice setting it up and getting familiar with the concepts and principles, but after that, you're in like Flynn. :) > 4) Admins never have enough time. TOM: The configuration is a one-off, and it isn't that difficult. Anyone who has deployed an Exchange organization that is more complex than a single front-end/back-end Exchange Server will find this setup to be child's play once they get the practice in their VM lab. How much time is a more robust security infrastructure worth? You can get up to speed in a few hours, better yet, go to Tim's and Jim's class and learn it from the masters. Remember to harass them for giving me some credit ;) > > 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. TOM: Yes, for a few hours of work you gain more than what you put in. Plus, you'd pass my compliance audit for placing Internet facing servers on a different security zone than non-Internet facing servers. > > 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) TOM: Keep in mind that the Internet facing FE server is on an AUTHENTICATED ACCESS DMZ. A lot of the "port openers" in the crowd think that DMZs are all created equal, but they're not (I know you already know that). In an authenticated access DMZ, no connections are made to the Internet facing server *until* those connections are pre-authenticated by the ISA firewall. This is separate and distinct from the anonymous access DMZ, where its party down on the published servers and you have to depend on any stateful packet and application layer inspection the ISA firewall can provide before the anonymous connections try to do what they can do to those servers. > > 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. TOM: From my assessment of the Microsoft Exchange Server network security recommendations (and unfortunately the ISA UE group picked up the same infection), they're all based on ease of use. Sure, its easier to but the FE and BE on the same security zone, but its not the best or most secure method. Putting an Internet facing device on the same security zone of a non-Internet facing device just isn't good policy. It would be like allowing your users or your internal DNS servers to perform recursion against Internet DNS servers, instead of using a caching-only DNS server in your anonymous access DMZ. > > 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. TOM: The problem is that if you use ISA, the security you get can be much better by segmenting the security zone. That's what I'd call good enough. I strongly believe that the ISA and Exchange PGs need to be up front and provide guidance for "good enough" and "preferred" security. > > 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. TOM: I'll keep that in mind when I talk to my neurosurgeon friends -- that all the extra measures they take to make sure something bad doesn't happen aren't required because they're just tweaks, and they probably will have only a very small effect on his morbidity and mortality rate. They draw their conclusions from a very small cohort and then make wide-sweeping conclusions. I think it works as a "feel good" measure, but I assert that every "tweak" that doesn't create a dysfunctional or non-functional system is worth making. If for no other reason is that you can't predict the future and anything can happen, so why not do what you can, with a minimal amount of effort, to improve your security? > > > 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. TOM: Actually, that list is not correct. Tim has worked out what is actually required and moves the configuration even closer to the goal of least privilege. But I'm not going to let the cat out of the bag since he teaches you that stuff in his class and he worked a long time over a hot NetMon to figure it out. Very good stuff -- and expands on the DMZ work I did for ISAserver.org. > > > 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. TOM: Yes, and ISA enables you to use least privilege and limit access to *only* the required posts. How many worms do you know of that use random ports that are outside of the handful of protocols that we actually require? That's what least privilege is all about. Also, remember that ISA firewall is the intermediator. With IPSec, ISA is not a third party intermediator, so if the FE and BE are compromised, you don't have an intermediator that says "nope, that's not allowed". And since the ISA firewall is the "hardest" machine on your network, no one is going to compromise it, since the FE and BE are much softer targets. OK, I'm tired of typing now. I don't like to get long winded unless someone is paying me for it :))) > > > 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/ > > > -------------------------------------------------------------- > ------------- > -------------------------------------------------------------- > ------------- > > > --------------------------------------------------------------------------- ---------------------------------------------------------------------------
