Configuring Multiple DMZs on the ISA Firewall (2004) – Part 1: Example DMZ and Perimeter Network Configuration

Got questions? Discuss this article over at
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=29;t=000029

The ISA 2004 firewall (ISA firewall) makes it easy to create multiple DMZ networks directly connected to the ISA firewall. In contrast to the ISA Server 2000 firewall, where you had a simple networking model of “internal versus external”, the ISA firewall’s new multinetworking feature allows you to configure multiple network types, and create Access Rules and routing rules between those networks. The new ISA firewall’s networking capabilities put it on par with just about any other network firewall on the market today.

This is great news to us ISA firewall fans. Now we can load up our ISA firewall with 3, or 6 or 9 or 20 network interface cards and create multiple internal and DMZs networks directly connected to the ISA firewall. The ISA firewall applies stateful filtering and stateful application layer inspection to all communications moving through all the ISA firewall’s interfaces. No two networks implicitly trust one another: you must create Access Rules that explicitly allow the traffic you want to allow between any two networks.

There are many possible DMZ networking topologies you can create with the ISA firewall. One topology that has worked very well for us is shown in the figure below. The ISA firewall DMZ configuration includes two ISA firewalls and four security zones.

The front-end perimeter firewall in this example is an ISA firewall. You can use any firewall as your perimeter firewall if the third party firewall provides features the ISA firewall cannot provide and you require them on your network, or if you already have a third party firewall in place. I do want to be very clear that the ISA firewall is quite capable of acting as a perimeter firewall, and I prefer to use it in that role unless there is a compelling, and fact based reason, not to do so.

Using ISA firewalls on the Internet perimeter and back-end also reduces the risk of network compromise because the most common reason for firewall related network compromise is firewall misconfiguration. Only very rarely is a network compromised because of a weakness in the network firewall itself to the extent that the firewall machine is “owned”. Therefore, we can actually improve security by using the same firewall on the Internet perimeter and on the back-end because a single administrator is much more likely to become expert with a single vendor’s firewall than trying to maintain a secure configuration will multiple firewall types.

The Honeypot DMZ/IDS systems DMZ segment lies between the front-end and back-end ISA firewalls. This can be either a public or private address DMZ segment. The honeypots are located on this segment and we can leverage the unique ability of the front-end ISA firewall to record user and application information for outgoing connections through the front-end ISA firewall. This provides a tremendous amount of useful information about what the attackers are doing on the honeypots in the DMZ, due of our ability to leverage the Firewall client, which we place on the honeypot machines in this DMZ.

You will be quite impressed at the information you can obtain about attacks and attackers when you correlate what you find on the honeypot machine itself and on the ISA firewall. This is another reason by I prefer the ISA firewall on the front-end; no other firewall can benefit from the intelligence gained from using the Firewall client application on the honeypots.

We also place our IDS systems on this DMZ segment. There’s no reason to incur IDS overhead by placing them on the ISA firewalls. We can easily place IDS systems on this network and gain information we need without impacting performance on any of the ISA firewalls.

The next security zone managed by an ISA firewall is the Anonymous Access DMZ. This is one of three networks directly connected to the back-end ISA firewall. You can see in the figure below that is a Public DNS server, an Anonymous SMTP Relay and an Outbound DNS Caching-only server are located on this security zone.

There two features characterizing this DMZ network:

• All connections to and from this network are unauthenticated
• All servers on this DMZ segment are Internet facing (Internet facing means that external users can create new inbound connections to these servers)

The Anonymous Access DMZ is what most firewall administrators consider to be a true DMZ segment. Anonymous connections are allowed to public facing servers. Machines on this segment are at significant risk of attack because anyone on the Internet can connect to them without authenticating. Authentication is not required for servers on this segment because it’s not feasible to require authentication on these servers:

  The Public DNS server is responsible for resolving names for domains you host. All Internet based hosts that need to connect to your hosted domains need access to your public DNS servers (technically, you are required to have two DNS servers when recording your authoritative DNS information with your domain registrar). This Public DNS server is technically a DNS advertiser. A DNS advertiser contains DNS zones for domains you host and authoritatively answers DNS queries for those domains. However, the DNS advertiser does NOT perform recursion. External (or internal) users will not be able to use this DNS server to resolve host names in other domains. In addition, this DNS server is hardened and configured to block DNS related exploits, such as cache poisoning attacks. The ISA firewalls on the front-end and back-end also perform stateful application layer inspection to prevent a number of DNS exploits from ever reaching the public DNS server. This public DNS server is a critical piece of your Access Anywhere plan because it hosts the public components of your split DNS infrastructure.

The anonymous SMTP relay accept incoming mail destined for your organization. Because there is no way for Internet-based SMTP server to forward mail to your organization via an authenticated connection, all incoming mail accepted by the inbound SMTP relay must be received by an anonymous connection. Anonymous inbound SMTP relays are protected by both the front-end and back-end ISA firewalls via the ISA firewall’s stateful application layer inspection filter. You also have the option of using the ISA firewall’s SMTP message screener on the back-end ISA firewall to screen out viruses, worms and spam. You can couple the SMTP message screener on the back-end ISA firewall with a industrial strength spam and virus/worm filter on the incoming SMTP relay. The anonymous SMTP relay will need for to be able to forward mail to the Exchange Servers on the Internal network.

Microsoft doesn’t like to use the term DMZ in its own documents because of possible societal and ethnocultural issues surrounding the term. Instead, they like to use the term perimeter network and use these terms synonymously. The problem with this approach is that they lump all DMZ/perimeter networks together as if they are all created equal.

When most of us think of a DMZ segment, we think of a “no holds barred slugfest” where anonymous users, hackers, crackers and other cruising losers have access to resources on the DMZ network. If you’re a computer or other network device, the DMZ network is a very dangerous place to be, because you can expect to be hacked and your administrator’s goal is to mitigate the hacks and perform disaster recovery as quickly as possible.

On the other hand, a perimeter network is not the “Wild Wild West” like the DMZ network. Instead, a perimeter network has Internet facing servers that require some sort of authentication or encryption (or both) for all connections to and from them. The perimeter network isn’t quite as secure as the internal network (because the internal network has no Internet facing servers), but it’s a lot more secure than the anonymous access DMZ segment because no authenticated connections are allowed to hosts on the perimeter network.

The figure below shows examples of servers you could locate in a perimeter network segment. A front-end Exchange Serve could be placed in the perimeter network and all connections to each of the Exchange Server services (OWA/OMA/RPC over HTTP/SMTP/POP3/IMAP4) on the front-end Exchange Servers could be configured to require both authentication and an SSL/TLS encrypted session. You could also place a secure, authenticating SMTP relay on the perimeter network that your remote users can use to send incoming mail to not only your organization’s e-mail domains, but to other e-mail domains on the Internet.

Notice that the route relationship between the perimeter network and the internal network is routed. The main reason for this is that we want to be able to use IPSec to secure communications between hosts on the perimeter network and the Internal network. We need to route the connection instead of NAT because IPSec doesn’t work with NAT. This allows for end to end encryption. The connection is encrypted between the remote access client and the perimeter network server using SSL/TLS and then the connection from the servers on the perimeter network to the internal network can use IPSec transport mode.

The internal network contains your Active Directory domain, domain controllers, internal DNS servers, RADIUS servers, DHCP servers, certificate servers and other core infrastructure elements. The internal network should not contain Internet facing servers and no external host should ever be able it initiate a new incoming connection to a host on the internal network.

You can use either a route or a NAT relationship between the Internal network and the DMZ located between the front-end and back-end ISA firewalls. The advantage of NAT is that you hide the addresses on the Internal network from hosts on the DMZ segment.

One of the very good things about having a back to back ISA firewall configuration is that you can make the back-end firewall a member of the internal network domain. This allows you to leverage the advanced Firewall features that you can only get by using the Firewall client application.

The Firewall client application is a generic Winsock proxy client that intercepts all TCP and UDP communications from the machines configured as a Firewall client and sends them to the ISA firewall. User credentials are sent transparently to the ISA firewall. This allows you to control outbound access to the Internet for ALL TCP and UDP protocols on a user/group basis. Best of all, the Internet applications running on the Firewall client machines do not need to be configured to use the ISA firewall – the applications are completely unaware that they are connecting to the Internet through the ISA firewall’s Firewall service.

This makes the Firewall client a superior option to SOCKS proxies. When you use a SOCKS proxy, the application must be designed as a SOCKS proxy client. In addition, you must manually configure the SOCKS proxy client to connect to the Internet through a SOCKS proxy server. The ISA firewall does have a SOCKS proxy filter and will allow you to use applications that are designed to use a SOCKS proxy.

The fact is that you never need to configure applications as SOCKS clients when the machine is configured as a Firewall client. From the viewpoint of a firewall administrator, things don’t get much better than this!

The Firewall client allows you to record the user name and application the users use to access the Internet. This means you can query your ISA firewall’s log for applications such as kazaa.exe, Morpheus.exe, httptunnel.exe and any other application using the TCP or UDP protocols. And because you used the Firewall client, the user name of the user who used kazaa.exe to connect to the Internet is record. This allows you and Human Resources to take the appropriate corrective action.

There are other advantages to making the ISA firewall a domain member, most of them revolving around ease of use. There are no compelling reasons for not making the back-end ISA firewall a domain member, and many compelling reasons to do so. Even on single firewall networks, there are no significant security risks associated with making the ISA firewall a domain member. While there are theoretical concerns over an attacker taking over the firewall and leveraging its domain membership to take over the entire network, the fact is that if anyone were able to that deeply penetrate the ISA firewall’s defenses, then whether or not the ISA firewall is a domain member is immaterial.

In this article we discussed one approach to creating DMZ networks with the ISA firewall. We discussed the different security zones that each segment represents and the significant differences between the typical DMZ network and perimeter network segments. In the second part of this article, we’ll go over the procedures you need to carry out on the back-end ISA firewall to create the DMZ, perimeter, Internal and External networks.