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

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

Tom Shinder — Thu, 22 Jun 2006 05:44:35 GMT

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

Thomas Shinder Blog » Blog Archive » Steve Riley Responds to Why the ISA Firewall Should Be in the Domain Article

Thu, 22 Jun 2006 06:09:44 GMT

PingBack from http://blogs.isaserver.org/shinder/2006/06/21/steve-riley-responds-to-why-the-isa-firewall-should-be-in-the-domain-article/

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

Tony Su — Fri, 23 Jun 2006 05:26:32 GMT

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

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

Shan — Fri, 23 Jun 2006 06:25:55 GMT

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.

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

Jim Harrison — Sat, 24 Jun 2006 19:23:27 GMT

(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.

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

Paul Vincent — Thu, 29 Jun 2006 16:12:02 GMT

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
www.psvincent.co.uk

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

Steve Riley — Fri, 30 Jun 2006 18:13:23 GMT

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...

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

Jim Stagg — Thu, 06 Jul 2006 18:43:15 GMT

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. www.isaserver.org looks like a great starting point, but I'm also open to a good book suggestion.

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

Patrick Muiruri — Tue, 18 Jul 2006 14:07:42 GMT

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.

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

Wolfgang (Wolf70) — Mon, 07 Aug 2006 14:42:33 GMT

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!