Should your ISA Server be in your domain? Film at 11!


So it would seem that a statement I made during TechEd US last week in Boston has mildly stirred a bit of controversy -- no surprise there, I guess, heh. One of my presentations gave an overview of what's new in ISA Server 2006 (download your copy of the release candidate or try it out in some virtual labs). An important new feature is expanded support for additional authentication methods on web listeners and web publishing rules. You can now select LDAP, SecureID, and other one-time password mechanisms, and finally make real use of client certificates through support for Service4User2Proxy in Windows Server 2003 Kerberos.


I made the statement that this additional flexibility makes it easier to build your ISA Server standalone -- rather than domain-joined -- and still enjoy the improved security benefits of authentication delegation. Tom Schinder, our beloved ISA Server MVP, prolific author, and host of the fine www.isaserver.org community site, attended the presentation. It was my apparent preference for standalone servers that Tom disagrees with -- and he wrote about it in a whitepaper on his site.


I have enormous respect for Tom. ISA Server's popularity and success is due in large part to his unflagging dedication and support. He's an entertaining writer, from whom you can not only learn something new but enjoy yourself while doing it. Plus, he advocates improved security that addresses modern threats and rails against the old guard unwilling to give up their stone knives and bearskins.


In this particular case, though, either Tom misunderstood my point or I misstated my point -- it doesn't really matter which. My preference is that, indeed, your ISA Servers should belong to your account domains. In his paper, Tom puts forth some very well-reasoned arguments for doing this -- arguments for which there is very little room to disagree. I don't believe I ever said "the ISA Server should never be a domain member" during the presentation, but honestly I don't remember now.


Yet there's a certain reality among many of the customers I work with, a reality that simply won't abide any firewall having access to account information. This reality is exactly the kind of fossilized thinking that Tom (and I) become so disgusted with. The fact is, ISA Server is one of the strongest, most resilient firewalls on the market. In the seven years since ISA Server 2000 was released, only ten security bulletins were issued for it, and of those, only three are marked critical. In the three years since ISA Server 2004 was released, zero security bulletins have been issued. ISA Server is some of the best code Microsoft has ever created. I have yet to learn of customers experiencing attacks that compromise either an ISA Server or a network protected by one.


Still, all this evidence isn't enough to convince the old guard. Very rarely do we see ISA Server replacing older, less capable firewalls in an organization. What we do see is a slow (too slow) migration toward using ISA Server in the DMZ, configured to publish resources in the internal network. And it is the intrusion of, yes, a Microsoft firewall into the realm of the "networking guys" that requires a delicate dance even still today. I've been advocating this architecture since 2002; you'd think these days we wouldn't even have to discuss DMZs as anything other than the paleo-networking artifacts they are, huh? (And I used to be one of those "networking guys.")


ISA Server's ability to remain standalone while still enabling authentication delegation solves two rather intractable problems: it protects internal web servers from attack while simultaneously existing in a configuration that the networking guys will grudgingly allow. Tom's excellent arguments in favor of domain membership reveal the deployment scenarios probably more common in his consulting work: using ISA Server as a forward proxy. The customers I have conversations with typically use that DMZ-located ISA Server only for reverse proxy. So it's from that viewpoint that I talk about standalone ISA Servers during presentations at conferences.


Tom, you and I are approaching the problem from different experiences, that's all. We are in violent agreement here, and that's a good thing. 🙂

Comments (10)
  1. Tom Shinder says:

    Hi Steve,

    Then we’ll have to just agree to agree. 🙂

    I deal with the same kind of customers that you deal with, and that’s what makes it so important to reinforce the security benefits of domain membership and try to disabuse the canaille from their flat earth approach to network security. I know hearts and minds are hard to change, but if you beat them over the head with a baseball bat, it at least tends to make them more malleable.

    BTW — I didn’t think authentication delegation would work when the ISA firewall is not a domain member in the constrained Kerb delegation scenario.

    Tom

  2. Tony Su says:

    Although not having had the privilege to attend TechEd and listen to your Talk but having had a read on Tom’s whitepaper and your response, are you not giving in too early?

    Although Tom’s paper <very> excellently describes the benefits of Domain membership, those are only functional issues mostly relating to convenience and lower costs of management. I don’t know that many of the things that can be done easily as a Member Server can’t also be done as a Standalone Server although with much work.

    Lower costs should always be considered as an issue separate from and should not be confused by including in the same discussion as security if your security needs are very high… And IMO that is the crux and justification for the type of scenarios Tom describes, that for most of us the level of security we require is not <that> high that we can assume a few more risks.

    There should not be any argument that despite the wonderful things Domain Membership enables, some fundamental "old school" principles are being broken:

    Separation of FW security from Corporate security. It’s one thing to extend security to an inner FW but to the edge? You have to be very confident the box cannot be owned, and some people will say that’s not a certainty although an improbability (again, using Tom’s words "Properly Configured"). But, we live in a world where people do things out of stupidity or ignorance, and these computing boxes are so damn complex can we really be assured bugs won’t be found? Some people will say that there is no such thing as a box that can’t be owned if it’s connected to a network, and it’s also pretty certain that if someone <really> knew how to break into ISA boxes through the front door he’d do everything possible to make sure the word doesn’t get out. On this topic, I’m surprised no one mentioned removing normal Domain Admin type accounts from the ISA box, and granting only individual special User accounts for interactive logon. The only Domain level credentials available on the box should be non-interactive Service accounts and communications which are hashed, to discourage capturing credentials which can instantly and completely compromise the core corporate network. The point is that although Domain credentials are not stored locally (assuming cached credentials have been disabled and the box is not also a DC), all encryption systems share a common vulnerability that decryption has to take place sometime to expose functionality and when a box is owned, all communications with that box could be at risk depending on whether schemes have been implement to rotate and change unpredictably or not… So as a Member Server it <will> increase the attack surface of your protected corporate network substantially if it becomes owned.

    The FW should not be the same OS as any other device or host in the corporate network. Again, this is consistent with the idea that no box can’t be owned. You want to create layers of defense that present new obstacles to the hacker. In this case you want sets of potential vulnerabilities to change with each layer, and different OS means the same exploit to compromise the peripheral device won’t likely work on the next. A Standalone ISA isn’t quite the same as a different OS, but the principle is the same.

    Both of these sound "traditional" principles are glossed over in Tom’s paper, but that’s not automatically a bad thing… It just depends on what you believe is sufficient security which any experienced Security SysAdmin knows is a subjective evaluation and subject to many variables.

    And, which camp you’ll fall into will depend on your a priori assumptions such as whether you should assume a box can be set up so it can never be owned.

    Tony

  3. Shan says:

    Well I’m just glad to hear my two prime sources of information on all things ISA aren’t actually at loggerheads. Just for the record, My shiny new ISA box IS a domain member for the first time, and it does make life a lot easier.

  4. Jim Harrison says:

    (to Tony)

    This is exactly the sort of "old guard" thinking that is being debunked by both Steve & Tom.

    The tired old "heterogeneous vs. homogenous" argument is irrelevant to the question of ISA domain membership, and in fact, only serves to confuse an already volatile issue.

    In fact, ISA services do *not* operate in any domain context and as such, offer *no* acceess to the domain.  Go back and read Steve’s response; while there have been some few security patches for ISA 2000 (now in extended support *hint*) and none for ISA 2004; the fact still remains that no ISA server has ever been compromised outside of a lab.

    You can argue theoretical ideas all you want; the fact remains that ISA installed on a domain member is no less "secure" than ISA installed on a WG machine.

  5. Paul Vincent says:

    Interesting topic. When I took the MCP on ISA 2004 (I never took the 2k exam), I could see a great number of advantages to running ISA in a domain. The authentication and authorisation benefits would appear to vastly outweigh what amounts to a perceived higher risk.

    Much of the criticism levelled at this configuration is what would happen *if* the ISA server was compromised, surely an easier passage to domain credentials would be possible?

    As Tom points out, no one has been able to explain exactly how this would happen, although to someone who doesn’t properly understand the issues involved, you can see how this point of view could be propagated.

    One thing I am getting frustrated with, is every time I speak to ‘firewall security specialists’ I get the same scornful laugh’s followed by a variety of comments such as ‘who in their right mind would put a Microsoft firewall as their perimeter defence’ and ‘ISA server doesn’t even proxy traffic properly’, a comment I still haven’t gotten to the bottom of today!

    As some of my respected colleagues at various pen test companies have said though, ‘when we come across a properly configured ISA server, very rarely do we manage a successful attack’.

    I guess at the end of the day, attitudes are hard to change, but by consistently delivering results and education, such as Steve Lamb, Steve Riley and Jesper, all of whom I immensely enjoy listening to, we may eventually overcome this barrier.

    Paul Vincent

    http://www.psvincent.co.uk

  6. steriley says:

    Maybe one day, when people stop viewing software and product selection as a religion, then the scornful laughs will disappear. Of course, that means that the "specialists" — or, more accurately, shamans — will have moved on to idyllic pastures populated only by sheep who never argue.

    Even your pen testers display some reluctance. They say, you write: "very rarely do we manage a successful attack" against "a properly configured ISA Server." I would be very curious indeed to learn of an attack that DOES succeed against a properly configured ISA Server…

  7. Jim Stagg says:

    Ok, I *was* one of the luddites who thought of DMZs as "the way, the truth and the light" to reducing our attack profile. I’m not sure their usefulness has completely departed, but I’m starting to see the benefits of ISA (and the IPSEC Server & Domain Isolation concept… Steve did a great selling job on that!).

    I must confess, though, my first impression of an ISA server is that it should be a DMZ bastion host. Both Steve and Tom are quickly pushing me away from that idea. The part about easier management really rings true. Complex models are frequently prone to breakage, and I don’t have to continue to derive self-worth from my ability to build and maintain (needless) complexity.

    I’m fortunate to work with a senior network & security guy who keeps the big picture firmly in focus, and who does not act as a Port Nazi. The flipside to that is he expects me to actually know how things work when we implement them, and that’s often more daunting than it would first seem! When Vendor XYZ says "the web server only needs to talk to the back-end server on port 666," we eventually end up in a Missouri-style debate until someone accedes to the "show me" demand.

    So, I’m sold on ISA as a concept and even as a product. I’m thinking about how to implement it as a reverse proxy for a homegrown web application that is currently located in our DMZ. We were going to move it to its own isolated forest (easier management across the bits in the DMZ). But, maybe ISA & membership in the same domain as the database server makes more sense.

    What I’m hoping to get is a pointer to some really ripping documents that deal in some detail with that sort of implementation. http://www.isaserver.org looks like a great starting point, but I’m also open to a good book suggestion.

  8. Patrick Muiruri says:

    When I read Tom’s white paper, I must admit that I was a little disturbed! "How could the two foremost authorities on ISA disagree on an issue I thought should not be moot", I asked myself. I have ‘known’ Tom from his isaserver.org forum and had the privilege to exchange a few e-mails with him whilst deploying my own ISA 2004 last year. Indeed, all my deployments are largely due to his whitepapers. As you will have guessed, the ISA servers are in the domain. I also attended the TechEd presentations by Steve and Jesper in Jo’burg last year, and boy, was I impressed!

    All I can say is that I am delighted that the two gurus (you really are) are reading from the same script. I am also looking forward to the next series of articles from Tom on how to properly configure an ISA server.

  9. Wolfgang (Wolf70) says:

    Hy,

    first i have to admit that i am still installing ISA as a Workgroup server in the DMZ. The main reason for this are endless discussions with "Security Consultant" companies and the old mindset (discussed above) they are bringing to my customers even today.

    The newest statement in my last discussions was: "nothing that talks to inside talks to the outside as well". I liked that statement, because if you want to sell ISA to your customer its quite good: ISA separates the  traffic. But if ISA would be installed as a domain member it would break this design. ISA would talk to the internal servers to get it’s machine password, etc but also talk to the outside to do the webpublishing.

    I dont know if i am the only one out there, but what i would really like to see would be some kind of "battle cards". This cards should not only include high level statements about how secure ISA is. They should really list in detail how attacks against ISA (or any other FW) are done today and how ISA prevents this. (e.g: Samples to get local machine access via HTTP and how you can move further to machines on the internal domain). ISA on W2k3 is a good product, so i dont see any reason why someone sould disagree by saying "I cannot tell the world how it can be done".

    This cards, KB,… would be even good to create a test plan for a secure ISA configuration   – especially for really concerned customers and IT Security guys.

    My 2 cent.

    //Wolfgang

    PS to Tom and Steve: Continue you good work!

Comments are closed.

Skip to main content