Debunking the Myth that the ISA Firewall Should Not be a Domain Member

[patris1]

http://www.isaserver.org/tutorials/Debunking-Myth-that-ISA-Firewall-Should-Not-Domain-Member.html

In this white paper I will go over the advantages and disadvantages of making the ISA firewall array members part of a workgroup or an Active Directory domain

At last week’s TechEd I had the opportunity to view a number of sessions and one of those was about the new ISA firewall, ISA 2006, given by Steve Riley. If you haven’t had a chance to see Steve talk, you should do yourself a favor and make it a point to see one of his live presentations. Steve is a very dynamic and animated speaker and he really knows how to rile up the troops by hoisting up straw men for a knock down drag out fight. One thing I can always say about Steve’s talks is I always leave the room thinking about something I hadn’t thought about before entering the room that day.
However, sometimes Steve makes my life difficult because he gets ahead of himself. In the most recent rendition of Steve’s “what can I say today to make Tom’s life more difficult” he stated that “the ISA Server should never be a domain member”. When I heard that, my jaw dropped, my vision began to blur and turn black, images of man’s inhumanity to man came to mind and I had to be shaken back into a normal level of consciousness by good friend Chris Gregory.
Why did I have this cataclysmic reaction to what Steve said? For the last two years I’ve been trying to communicate to ISA firewall admins that a domain member machine is more secure and more flexible than a non-domain member machine and that they do themselves and their companies a disservice by not joining the ISA firewall to the domain. This is a significant issue and not something to be taken lightly because there is a serious security hit you take when you don’t join the ISA firewall to the domain.
This has inspired me to write a long winded, but detailed and thoughtful, analysis on the domain versus non-domain membership debate for ISA firewall arrays. I do this because I can’t get on stage and oracularly state “no ISA firewall should ever be a workgroup member”, get away with it, and then have Steve later answer to the 1000 attendees who say to him “I understand that the ISA firewall should NEVER be a workgroup member, how do I do X and Y and Z”.
I recently gave a talk to a group a high-powered firewall consultants on this issue and prepared some PowerPoint slides on this topic. Since I’m sitting in a cramped airplane seat right in front of the exit row (which means I can put my seat back), I’m going to copy and paste the PointPoint slides into this document so that I can remember the outline of my discussion
This white paper will discuss the advantages and disadvantages of domain and workgroup configurations for ISA firewall arrays. I’ll follow up with a second white paper and describe scenarios where ISA firewall arrays must be domain members, when they should be domain members, and when it doesn’t matter if they’re domain members or not. That paper will also include a description of some of the psychiatric and “layer 8” issues influencing whether or not the ISA firewall array is joined to the Active Directory domain.
Should ISA Firewall Arrays be Placed in a Domain or Workgroup?

Should the ISA firewall array be placed in a domain or a workgroup? That is the question. Is it nobler to place the ISA firewall in a workgroup where you can avoid the catcalls of clueless compliance managers, “hardware” firewall know-nothings, or “network guys” who think of network security as “port opening and closing”, or should you bear the slings and arrows of the same harridan housewives and carping screws for placing the ISA firewall in the domain, where you can get a higher level of overall security and substantially improve your security position?
Let’s look at the following:

• The advantages of domain membership
• The disadvantages of domain membership
• The advantages of non-domain (workgroup) membership
• The disadvantages of non-domain (workgroup) membership

In this article I’ll focus on the ISA firewall’s Enterprise Edition, as this version of the ISA firewall is more likely to be deployed in enterprise environments where the ISA firewall admin has to interface with IT infrastructure groups with antiquated and fossilized misconceptions about network security. In a future article I’ll discuss with you the serious problem we have today regarding the hijacking of network security by these “network guys” and how it harms every level of network information security today.
The Advantages of Domain Membership

There are many advantages to domain membership. These are outlined in the figure below.

Figure 1

• Granular User/Group based access control
  
  When the ISA firewall is a domain member, you can exert granular user and group based access controls over all communications moving to and through the ISA firewall. This includes all communications moving inbound and outbound to and from the corporate network. You can use domain groups and you don’t need to create Ad Hoc ISA firewall groups, which is what you need to do when using RADIUS authentication. While it’s true that ISA 2006 adds the ability to use LDAP authentication to enable Active Directory group enumeration, that feature only works for Web Publishing Rules, and does not enable the same function for outbound access control via ISA firewall Access Rules. LDAP authentication may also be problematic because it may increase the risk of account lockout. Without making the ISA firewall a domain member, you have to depend on the RADIUS kludge for outbound access control for Web protocols and you get no user/group based access control for any other protocols.
• No need to create array accounts for intra-array communications
  
  ISA firewall array members need to authenticate with one another for intra-array communications. This takes place transparently when the ISA firewall array members are part of the domain. When the ISA firewall array member isn’t a domain member, you need to create mirrored accounts on the array members. Since there is no password synchronization among workgroup members, you need to manually change the password of these accounts on each array member. If you have 4 ISA firewall arrays, each containing 31 members, you’ll have to make sure to reserve some time for password change day. Another problem is that you won’t be able to manage the machines from a remote workstation by transparently logging into the array; instead, you’ll need to enter your username and password each time, which will make the “shoulder surfers” in your organization quite happy. There are other problems too, as you’ll see later.
• Full support for user certificate authentication
  
  User certificate authentication (unfortunately referred to as “client” certificate authentication) enables a user to present a user certificate to authenticate to the ISA firewall in Web Publishing scenarios. This is a powerful authentication scheme, because these certificates can be installed on smart cards and other devices to prevent the need for transmitting user credentials over the wire. You have full support for user certificate authentication when the ISA firewall is a domain member. You have no support for user certificate authentication when the ISA firewall is not a domain member. I can hear what you’re thinking – I’ll create a separate domain for my ISA firewall array in the same forest as the user domain, and then create a one-way trust. This is a common physic applied to those wounded by the superstition of “domain members ISA firewalls aren’t secure” canard. While the physician of this solution may be applying a soft touch, that’s all you’ll get from it because you still won’t be able to use user certificate authentication in a workgroup configuration.
• Full support for Microsoft Operations Manager (MOM)
  
  MOM is a powerful tool for monitoring and reporting your ISA firewall’s heath and configuration status. While it’s possible to configure the MOM agent to work on non-domain members, there are installation, configuration and management issues that are problematic on non-domain members. On the other hand, monitoring domain member ISA firewalls with MOM is a no-brainer; it’s easy to setup, configure and manage. Easy setup, configuration and management means fewer errors while leads to better security.
• Full support for the Firewall Client
  
  I can’t say enough good things about the Firewall client. The Firewall client enables transparent remoting of connections to the ISA firewall for all network connections made by Winsock applications. Think of the Firewall client as a generic Winsock proxy. With the Firewall client you can log user name, application name, machine name, and much more for every connection made by a user for any protocol used to connect to a resource through the ISA firewall. The Firewall client provides you granular user/group based access control over any protocol and that information is stored in the ISA firewall’s log files for compliance management and network forensics. You can’t get this kind of information logged if you use any other firewall on the market today. But if you wish to avail yourself of the profound benefits the Firewall client provides, the ISA firewall has to be a domain member. If your ISA firewall is a workgroup member, then the Firewall client represents just a missed opportunity to secure your network infrastructure and be an IT hero because you won’t be able to use it.
• Full support for Group Policy Management
  
  Every Windows admin knows Group Policy is a key component of a well-managed and secure Windows network. When the ISA firewall arrays are members of an Active Directory domain, you can create Group Policy objects that control machine configuration on all members of an ISA firewall array. This makes it easy to centralize core OS security administration and configuration that would have to be otherwise manually configured on each array member. This is a significant benefit, as there can be literally thousands of machines participating in hundreds of ISA firewall arrays throughout the organization. Do you really want to do that configuration separately for each server in each workgroup? Without joining the ISA firewall’s to the domain, you lose out on centralized security management, which not only reduces your overall level of security but also increases administrative overhead. No good.
• Array admins can log in transparently from any Active Directory managed machine in the domain
  
  As mentioned earlier, when the ISA firewalls array members are part of the domain, you can manage that array from any workstation that is part of the same or trusted domain. This has two major advantages. First, it’s more convenient. Since it’s more convenient, you won’t avoid performing crucial ISA firewall management tasks that you might hesitate doing if typing in the 37 character ISA firewall admin password is a burden (this is a realistic scenario and one I’ve seen more than once) and second, you avoid having to type in the password multiple times per day, so that shoulder surfers don’t have a chance to figure out the password during one of your log on attempts.
• Infinitely easier to deploy and manage
  
  Easy is a double-edge sword, especially when we’re talking about security. On the one hand, there’s easy like a “hardware firewall” where they just let everything outbound and allow any kind of response from a remote server, as long as someone made an initial connection request to that server, or like SBS wizards that magically do stuff that try to mitigate the security nightmare that is the Internet facing SBS device. On the other hand, there is “easy” that simplifies complex and laborious configuration for the knowledgeable admin who might make a typo or a “click-o” somewhere along the way.

It is this version of “easy” that domain membership provides the ISA firewall admin that makes the configuration more secure. Domain member ISA firewall arrays are very simple to setup and secure. On the other hand, workgroup member ISA firewall arrays are very complex to setup and there are many steps where errors can be made and where a mistake in any one of those steps could compromise not only the ISA firewall array, but potentially the entire network. I’ll go through some of the configuration gymnastics required to make workgroup-mode work later in this article.
Disadvantages of Domain Membership

In spite of how often the phrase “it’s all good” is used, the fact is that nothing is all good. Some things are better than others, some things are mostly good, other things are almost all good, but nothing is all good. That’s true for domain membership for ISA firewall array members. The figure below summarizes the “not all good” features of domain membership.

Figure 2

• If someone compromises the Active Directory, they can own the ISA firewall
  
  You got to wonder where a person’s head is at when they confront you with this one. The domain membership naysayers claim that if the Active Directory is compromised, then the compromiser will be able to leverage that ownership of the Active Directory against the ISA firewall. Let me tell you, if your Active Directory is owned to that extent, I think the ISA firewall will be the least of your problems. Imagine the scenario where someone compromises the Active Directory and owns the domain admin account. That attacker now has access to all file servers, Web servers, database servers, Exchange Servers and whatever server you’d like to throw into the mix. Since the ISA firewall is likely configured to give members of the domain admins group HTTP access outbound, why would they need to do anything to the ISA firewall? They’ll download remote control software that works over HTTP to any server they like, do some neat tricks to determine what sites they need to impersonate to get through the ISA firewall’s list of trusted sites, and go to town. They’ll never need to touch the ISA firewall. Someone with legit domain credentials doesn’t need to mess with the ISA firewall (which would call undo attention to the wrong people – from the attackers point of view) to send out his ill-gotten gain if he owns the Active Directory.
• If the Firewall is owned, the Active Directory may become accessible
  
  This one is about as whack as the last one. If the ISA firewall is owned to the extent that they can leverage the machine’s domain membership to attack the corpnet, then it really doesn’t matter whether the machine is a domain member or not. What can someone who owns the ISA firewall do when it’s a domain member? OK, the attacker will have access to the intradomain protocols to the DC. What will he do with them? I don’t know, you tell me. Gather user names? So what? Passwords provide security, not user names. No one has been able to tell me what an attacker can do with access to the intradomain protocols.
  
  Sure, if the ISA firewall is owned, the attacker can change firewall policy to his heart’s content, but that’s true for workgroup mode ISA firewall’s as well, so the scenario doesn’t change based on domain membership. Also, unless the attacker is a script kiddie or click kiddie who’s interested in a worthless DoS attack (worthless from the point of view of stealing or destroying corporate information assets), the intruder wants to lie low and go under the ISA firewall’s radar. What the professional network criminal doesn’t want to do is call attention to himself by monkeying around with the ISA firewall, which is likely to be one of the most closely monitored devices on the network.
  
  However, the entire discussion is moot, because after over 6 years of worldwide deployment, there hasn’t been a single case of a compromised ISA firewall when the ISA firewall was properly configured. At this point I’m going to temporize on what a “correctly configured” ISA firewall is, as that’s a long discussion in itself, although one of the features is that the ISA firewall array is in the domain. A good fellow at TechEd last week brought up this topic and pointed out that I’ve never really described what a properly configured ISA firewall was, at least in this context. I promise to provide you that information in the very near future. Needless to say, at this point concerns over “owned” ISA firewalls are for the Chicken Little’s in the crowd and hardware firewall sales guys and their “hypmotized network guy” acolytes.
• Domain Admins can admin the ISA firewall
  
  It is true that domain admins can access and change the configuration of a domain joined ISA firewall array. Is this a real security issue? If you can’t trust your Active Directory domain administrators, who can you trust? Do you select domain admins off the street and slap a badge on them or do you do background checks, financial checks, criminal history checks, personal history checks, and whatever other checks you like to confirm that you can trust them since they hold the keys to the mint for all Microsoft networking servers and services at your company? I suppose that domain member SQL and Exchange Servers aren’t secure because domain admins can admin those servers. Only the most SANS infused kewl-ayd drinker would be concerned about this issue.

Advantages of a Workgroup

Just like nothing can be “all good”, nothing can be all bad. The same is true for workgroup mode, non-domain member ISA firewalls. The figure below summarizes the advantages of the non-domain member ISA firewall array.

Figure 3

• If the firewall is compromised, the attacker might not be able to get to the Active Directory
  
  This is the flip side of the previous discussion. The operational word is might. The attacker might not be able to access the Active Directory. It all depends on the location of the ISA firewall. If the ISA firewall is going to do any kind of authentication, even if deployed as a unihomed reverse proxy in a “hardware” firewall’s DMZ, the attack can potentially gather valuable user credentials. The attacker can install a network sniffer and other more advanced tools on the unihomed ISA firewall in the “hardware” firewall’s DMZ and harvest valuable information that can lead to the stealing of credentials. No, I’m not going to tell you how to do it, it’s enough to know that it’s possible. Now that he has this information he can easily use out-of-band methods to get into the network and leverage this information.
  
  Once again, remember that these are just flights of fancy, as there isn’t a documented case of a compromised ISA firewall that’s been properly configured and professional attackers (the ones you need to worry about) aren’t going to attack the ISA firewall because they need to do everything they can to remain unnoticed for as long as possible.
• Domain admins can’t admin the array
  
  In workgroup mode, you configure user accounts that are used to admin the ISA firewall array and these accounts are mirrored on each firewall array member. Since these accounts are unlikely to have the same user names and passwords as any of the Active Directory domain admins, your dangerous and reckless domain administrators won’t be able to subvert network security by playing around with your ISA firewall configuration. In reality, domain admins are neither dangerous nor reckless and they are the most trusted computer operators in the organization. If you can’t trust your domain admins, your organization has much larger problems than the fact that they can admin the ISA firewall array.
• If the Active Directory is owned, the firewall won’t be affected
  
  It’s true. If someone owns your Active Directory and the ISA firewall array is not a member of the domain, domain admin accounts won’t be able to change the ISA firewall configuration. Of course, he’s compromised and cratered your Exchange, SQL, SharePoint, and other Microsoft servers on the network, but the ISA firewall will keep humming. The workgroup mode ISA firewall array becomes the Nero of firewalls in the burning ashes of your network Rome and is the last man standing. At this point do you really care what the configuration of the firewall is? And if so, don’t you think that you’ll have pulled the plug on the Internet by the time you notice that all these servers are compromised? And will it really matter? The likelihood is that he’ll be able to leverage a valid user account to pass information outside the network without touching the ISA firewall configuration.

Disadvantages of Non-Domain Member ISA Firewalls

Now let’s get to the most interesting and important stuff – the disadvantages of the workgroup mode non-domain member ISA firewall array. Many of these are the converse of the advantages of the domain member advantages, but it’s worth restating things to make sure they sink in. The figure below summarizes these disadvantages (but doesn’t include all of them because there are more which I’ve included in the list under the figure).

Figure 4

• Requires server certificate on the CSS
  
  In order for workgroup mode machines to authenticate with the CSS, there must be a server certificate on the CSS. Each ISA firewall array member and the CSS must have the CA certificate of the CA issuing the server certificate installed in it’s Trusted Root Certification Authorities machine certificate store. You won’t be able to use the Certificates MMC to do this, because the MMC requires all machines be in the same domain. So you get the pleasure of figuring out how to use the Web enrollment site or some other mechanism to generate the certificate. Remember to get the common/subject name right on the certificates or else everything is going to fall apart, as I’ll detail in the next bullet point. None of this is particularly hard (for me), but if you’re not a PKI guy, then get ready for Mr. Toad’s wild ride.
• Requires convoluted DNS changes
  
  ISA firewall array members need to be able to resolve the name of the CSSs to communicate with them. However, the name of the CSS machine might not be the name on the certificate. For example, suppose you want to put the CSS on one of the workgroup mode ISA firewall array members. The firewall array members communicate with one another via the intra-array NIC. The firewall array member on which the CSS is installed already has his machine name registered in DNS and it resolves to the IP address on the internal interface of that machine. Since we can’t use the machine name, we need to use a common/subject name on the server certificate that is different than the machine name and enter a Host (A) record in the DNS for that name that resolves to the IP address on the intra-array NIC on that ISA firewall array member hosting the CSS. Not only that, but you’ll have to use the Windows Server 2003 Support tool, setspn, to register that name in the Active Directory. You don’t know about service principle names? Get ready to burn the midnight oil. Again, none is this is particularly hard to do (for me), but if you haven’t done this 500 times, it might be hard for you to remember all the moving parts.
• Must track certificate status to avoid expired certificates
  
  Certificates expire, and they expire at the worst times. Unlike machine accounts in the Active Directory that never expire, your certificate on the CSS will expire and you won’t be happy when you can’t figure out why the ISA firewall array can’t communicate with the CSS until you’ve beat your head against the problem for 8 hours and realized it was a certificate expiration issue.
• Must use RADIUS or SecurID for authentication for reverse proxy (LDAP in ISA 2006)
  
  Unlike the ISA firewall array that’s joined to the domain where you have a dizzying array of authentication options for reverse proxy authentication, with the workgroup mode ISA firewall, you get RADIUS and SecurID authentication (with ISA 2006 you’ll get RADIUS OTP and LDAP). When you have nothing to do, check out the ISA firewall logs for the number of RADIUS requests made during the average connection to your published OWA site. You won’t have to wonder why access to your OWA site is so slow. You’ve also introduced another point of failure if you introduce a dedicated RADIUS server (or even if the RADIUS service on a DC fails) or if the ACE server goes belly up. And remember with RADIUS you can’t leverage your domain groups for reverse proxy authorization; you’ll have to create your own ISA firewall Groups and populate them one user at a time in the ISA firewall console, or give up and just allow all authenticated users (not an ideal access control scenario).
  
  In ISA 2006 you’ll be able to leverage Active Directory groups by querying DCs, but as mentioned previously, there is potentially an increased risk of an account lockout DoS using LDAP (unconfirmed at this time). And if you allow LDAP from the ISA firewall to the DCs, won’t the network guy “port openers” get as apoplectic as they would with the ports that need to be opened for full domain member access (this applies to the unihomed ISA firewall in a “hardware” firewall DMZ scenario).
• Can only use RADIUS for forward proxy
  
  In a forward proxy scenario, the only authentication method available is RADIUS and that can only be used for Web connections. All other traffic must go through some other device which is unlikely to have the ISA firewall’s level of access and accountability controls. Now you’re at the mercy of whatever device is used to forward non-Web traffic outside the network. RADIUS for forward proxy scenarios suffers from the same limitations as mentioned above in the reverse proxy configuration.
• On-box accounts required for intra-array communications and firewall array management
  
  As I mentioned earlier, you need to create separate accounts in the local SAM of each ISA firewall array member for intra-array communication and for firewall administration. While this isn’t much of a problem if you have a single two-member array, the situation gets a little stickier when you have 31 members in your array and you have dozens of arrays throughout your distributed world-wide network. And then there’s all the other stuff I’ve mentioned earlier regarding shoulder surfers, delays in configuration changes because you don’t want to retype a 67 character password, administrative overhead of maintaining what is essentially a separate and distinct directory infrastructure dedicated to your firewall arrays. What you end up with in the workgroup ISA firewall array configuration is a significantly higher level of administrative overhead and an overall lower level of security.
• Can’t use user certificate authentication
  
  The inability to support user certificate authentication is one of the major security hits you take when installing the ISA firewall array in workgroup mode. If you want to avoid passing user name and password, you’re going to need to use SecurID, or if you’re on ISA Server 2006, then you can work with RADIUS one-time passwords. Lack of user certificate authentication is especially bad news for people who want to use user certificate authentication on their Windows Mobile devices.
  
  During TechEd last week, I had a great conversion with a couple of smart guys who wanted to know how to make sure that only their managed Windows mobile devices can connect to their network through the ISA firewall. I suggested user certificate authentication and mapping a global user certificate to a Windows mobile account. If they didn’t join their ISA firewall to the domain, they wouldn’t be able to do this and could be left out in the cold in their efforts to increase security for their Windows Mobile infrastructure.
• No support for VPN user mapping when users connect from non-Windows VPN clients
  
  ISA 2004 and 2006 have a very cool feature that allows you to map user authentication attempts from non-Windows VPN clients to user accounts contained in the Active Directory. For example, if you have a user logging in with a Apple VPN client, that user can log in with his AD user name and password and that log on attempt will be mapped to a user account in the Active Directory. As far as I know, no other VPN server supports this type of user account mapping. But if you install the ISA firewall array in workgroup mode, you’ll be like everyone else who doesn’t have an ISA firewall and VPN server and won’t have access to this exceptional ability to map VPN client connections to Active Directory user accounts for non-Windows clients.
• No support for user/group based outbound access control except for Web traffic
  
  This is a big one and a major reason why the workgroup mode configuration significantly reduces your overall security posture. A workgroup mode machine is essentially a simple forward and reverse Web proxy device, at least within the context of security. For non-Web protocols, you get no more security from the ISA firewall than what you would get with a typical “hardware” firewall, which we know isn’t very much. Even worse, like a typical hardware firewall, the information contained in the firewall logs isn’t very comprehensive, and if I were to audit a network with a typical hardware firewall or workgroup mode ISA firewall, I would have to ding them on the abysmally low amount of useful information contained in the firewall log files (although the ISA workgroup mode would be superior to the typical “hardware” firewall because at least you have some useful information in the Web proxy logs). User and group based outbound access control is no longer a convenience or optional security measure.
  
  If you are the victim of an inside job (which is the case for most network compromise scenarios), and you don’t have comprehensive logging of user name, machine name, application name information in your logs, you’re going to have to answer for your lack of due diligence and explain exactly why you can’t provide the authorities and investigator this information. If you do find yourself in this situation, don’t try to fool the examiners with explanations like “hardware firewalls are more secure” or “domain members aren’t secure” because their one-two punch will put your b*tt out to lunch.
• ONLY ONE CSS SUPPORTED!
  
  The configuration storage server (CSS) contains all the ISA firewall array configuration information. Information about ISA firewall array configuration is pulled from the CSS into the local registry of each firewall array member. All firewall configuration and management tasks are done at the CSS, not directly with any ISA firewall array member. If the ISA firewall array cannot contact a CSS, the ISA firewall array will continue to provide comprehensive stateful packet and application layer inspection, but you will not be able to make changes to the current configuration until the ISA firewall array can contact a CSS. When the CSS is installed in a workgroup (for example, when the ISA firewall array is in workgroup configuration and the CSS is installed on one of the firewall array members) you can install only a single CSS for the entire array. This could be problematic if you want to install an array of 31 ISA firewalls.
  
  In contrast, if the CSS were contained on a domain member, then you could configure multiple CSSs for failover and fault tolerance and avoid the embarrassing situation where you’re asked to make changes to the firewall configuration only to find yourself having to explain that you installed the CSS on a workgroup member in spite of comprehensive information on why you should have installed it on a domain member.

Summary

In this white paper I went over the advantages and disadvantages of making the ISA firewall array members part of a workgroup or an Active Directory domain. Through a careful analysis of these relative advantages and disadvantages, it became clear that making the ISA firewall array members part of the Active Directory domain provides a vastly more secure and more flexible firewall configuration than making the firewall array part of a workgroup. In the analysis we are able to come to the solid conclusion that the overall security posture provided by a domain member ISA firewall is higher than a workgroup mode ISA firewall. While this conclusion flies in the face of the average network infrastructure guy who doesn’t understand network and application security, it’s clear that when you take all the salient factors into account, we can’t justify the “tribal knowledge” on which the average network infrastructure IT group uses to come to their false conclusions regarding domain membership.

---

موضوعات مشابه:

• Microsoft Dynamics CRM, Customize the Default Member Type of a New Marketing List
• Configuring WPAD Support for ISA Firewall Web Proxy and Firewall Clients
• Configuring Domain Members in a Back to Back ISA Firewall DMZ
• مشكل در member of

---

[patris1]

http://blogs.technet.com/steriley/archive/2006/06/21/438111.aspx

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.
Published 21 June 06 04:21 by Steve Riley Filed under: access technologies, protection, TechEd, ISA Server, configuration


Comments

# Tom Shinder said on June 21, 2006 10:44 PM: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 said on June 21, 2006 11:09 PM:PingBack from Deb Shinder Blog Blog Archive Steve Riley Responds to Why the ISA Firewall Should Be in the Domain Article # Tony Su said on June 22, 2006 10:26 PM: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
# Shan said on June 22, 2006 11:25 PM: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. # Jim Harrison said on June 24, 2006 12:23 PMto 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.
# Paul Vincent said on June 29, 2006 9:12 AM: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
Cyber Security Ltd - Secure IT or lose it # Steve Riley said on June 30, 2006 11:13 AM: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... # Jim Stagg said on July 6, 2006 11:43 AM: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. Microsoft ISA Server Firewall Resource Site: Articles & Tutorials looks like a great starting point, but I'm also open to a good book suggestion.
# Patrick Muiruri said on July 18, 2006 7:07 AM: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.
# Wolfgang (Wolf70) said on August 7, 2006 7:42 AM: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!