Creating Multiple Security Perimeters with a Multihomed ISA Firewall Part 1: DMZ Design Concepts and Why the Front-end Exchange Server is Placed in a DMZ

Creating Multiple Security Perimeters with a Multihomed ISA Firewall
Part 1: DMZ Design Concepts and Why the Front-end Exchange Server is Placed in a DMZ
by Thomas W Shinder MD, MVP



Have Questions about the article? 
Ask at: http://tinyurl.com/d36m9

If you missed the other articles in this series, check them out at:

The DMZ is not dead. It’s not even breathing hard. In fact, DMZs become more important every day. No longer can you have implicit trust in any network. Back in the days of yore, you could depend on two types of networks: the scary “untrusted” external (Internet) network and the safe and sane (trusted) internal network.

Pre-Cambrian network administrators put up packet filtering router boxes (that had their “router” decals removed and replaced with labels that said “firewall”) to separate and putatively protect the trusted internal network from the untrusted Internet. Some of those network admins still survive today and believe that “hardware” firewalls provide flawless, iron-clad security.

The concept of trusted versus untrusted networks was seen as valid up until the end of the 20th century. In fact, the ISA Server 2000 firewall was developed in the late 1990s and went RTM right about the beginning of the 21st century. The ISA Server 2000 firewall design was consistent with the popular notion of trusted internal networks and untrusted external networks. Unfortunately for ISA Server 2000 and other firewalls holding the trusted versus untrusted world view, the climate changed around them and made the trusted/untrusted dichotomy invalid.

While this is bad news for ISA Server 2000 and network admins who still run it, the good news is that ISA Server 2004 (subsequently referred to as the ISA firewall throughout this article series) was designed from the ground up with the fact that no networks, no hosts, no networked entities should be trusted implicitly. This explains why the ISA firewall is a network brick right after you complete installation. No connections move through or to the ISA firewall until you decide to allow them.

WARNING:
Almost all typical SOHO and SMB “firewalls” are simple stateful packet inspection devices that assume, out of the box, that the internal side of the network is trusted and come ready made to allow attackers free and clear outbound access from your network.

If all networks are untrusted, are all networks the same? Are all networks and hosts on those networks equally “untrustable”?  Are there varying layers of trust and distrust? Most would agree that while no network or host should be implicitly trusted, there are gradations of trust and that hosts situated within the same trust gradient belong to the same security zone. By segregating hosts belonging to the same security zone into separate logical or physical networks, you can limit the chance of an adverse network event in one security zone from affecting other security zones.

This is where the ISA firewall shines. Using the ISA firewall’s built-in multinetworking capability, you can create an unlimited number of network security zones and create strong access controls on what traffic moves to and from different security zones. Only traffic that’s required from one zone to another is required, all other traffic is dropped and logged.

My Long, Sad Tale about Front-end and Back-end Exchange Servers

I had an interesting discussion last week with a guy who’s smarter than me, about the best network design for the front-end/back-end Exchange Server configuration. He told me that he had read the recommendations from the Microsoft Exchange Server Web site on how to deploy the front-end/back-end Exchange Server scenario in a firewall environment.

He said that the Exchange Server team said you should put the front-end and back-end Exchange Servers on the same network, and implied that this network is the same network as the production network (the network containing the user workstations and other “free range” network devices).

When I asked him what he thought of this recommendation, he said it didn’t make much sense and that he noted it was a deviation from previous recommendations made by Microsoft’s Exchange Server Web site. He also said that it seemed sort of whack because of the ISA firewall’s new abilities to support front-end Exchange Servers in a DMZ segment.

THE BOTTOM LINE:
He was really confused and wasn’t sure what to do because there wasn’t much rationale included in the Exchange Server team’s documentation to explain why they would give a global recommendation to this infrastructure.

Front-end Exchange Servers in the DMZ Yesterday, Front-end Exchange Servers in the DMZ Tomorrow, but Never Front-end Exchange Servers Today

I have to agree with my perplexed friend. It makes no sense that they would recommend putting the front-end and back-end Exchange Servers on the same network segment. The front-end Exchange Server is an Internet facing device and accepts incoming connections from Internet hosts.

Internet facing devices are de facto in a different security zone than devices that are not Internet facing. While we might be able to argue that devices within the corporate network are at more risk of compromise than those that are only exposed to the Internet, the result of the debate doesn’t change the fact that the front-end and back-end Exchange Servers belong to different security zones.

Since the front-end and back-end Exchange Servers clearly belong to different security zones, does it make sense to put them on the same network? For years, I came up with contorted rationales to form a less than coherent apologia for ISA Server 2000’s the limited multinetworking capabilities and extolled the virtues and the elevated security wisdom of not putting domain members in DMZ segments. I always felt like crossing my fingers behind my back when saying this, because I know my primary motivation for giving this advice was that ISA Server 2000 did not support extending the domain into DMZ segments.

This was especially difficult because at the time that Microsoft Exchange Server Web site guidance clearly stated that the front-end Exchange Server should be placed in a DMZ segment between two firewalls. Of course, the back-end firewall should not be ISA Server 2000 because it didn’t support intradomain communications between internal and external networks. I can’t tell you how many times I had to field questions regarding the schism between the Exchange team’s guidance on firewall placement and front-end/back-end Exchange Server setups and the capabilities of the ISA Server 2000 firewall.

You can imagine my glee when ISA Server 2004 appeared with its advanced multinetworking capabilities enabling you to create a secure solution for intradomain communications between any two ISA firewall Networks. Finally! The day had arrived where I would no longer have to do St. Vitus’ dance while explaining why the front-end and back-end Exchange Servers should not be walled off by perimeter firewalls. Armed with the new ISA firewall, I could proudly and confidently say: the Exchange Server team’s recommendations were correct and good.

Of course, no good deed goes unpunished. Just when I was about to have a party over the new ISA firewall’s capabilities and its ability to support a more secure network design, the Exchange Server team pulls the rug out from under me and claims that the front-end and back-end Exchange Servers should be on the same network.

What? How could they do this to me! We now have a powerful stateful packet and application layer inspection firewall that fully supports intradomain communications through the firewall and now they state that “best practice” is to put them on the same network. Ack!

Not all DMZs are Created Equal — Why You Need Perimeter Firewalls and Bullet Proof Vests

I had to find out what the deal was with the change in recommendation, so I was able to buttonhole a few Exchange guys who might be able to provide a rationale for their decision. Their collective opinion was that “you have to make cheese out of the firewall to allow intradomain communications, or use an IPSec tunnel through the firewall, so there’s no sense in having a firewall there at all”.

What? There’s no sense in having a firewall at all? That’s like a cop saying “I don’t wear a bullet proof vest when I’m on the streets, since they can just shoot me in the head”. Yes, the scumbag could shoot you in the head, but the bullet proof vest provides a significant level of protection for a large area of physical vulnerability. No, it won’t protect you from head shots, neck shots, bleed outs from femoral artery leg shots, or pulmonary emboli secondary to shattering of the tibia. But the bullet proof vest still protects you from all the bad things that can happen if you weren’t wearing a vest, such as shots through the heart, lungs, liver, kidney, stomach, pancreas and intestines.

I ran this analogy through my ex-cop wife, Deb Shinder, and asked her if there were cops who thought the same way as the Exchange team in terms of their firewall recommendations for front-end and back-end Exchange Servers. She said are rookies who think the same way as the Exchange team, but they usually don’t last long. They either catch a slug in their center mass or they see their partner get hit. Either way, they don’t hit the streets again without their own “personal firewall”.

DMZs are Security Zones

At this point we can all agree that putting the front-end and back-end Exchange Servers in physically or logically distinct security zones is a good thing. The question is how can we create the best perimeterization scheme not only for our front-end and back-end Exchange Servers, but for all of our Internet facing resources.

The key concept to remember that all networks are not untrusted to the same degree. Some untrusted networks are more trustworthy than other untrusted networks. For example, the following lists different security zones of descending trustworthiness:

  • Network services segment

  • Developer users segment

  • General users segment

  • Authenticated access DMZ

  • Anonymous Wireless LAN segment

  • Unauthenticated access DMZ

Network Services Segment

The network services segment is the most trusted, because an army of network administrators, engineers, and security specialists put laser focus on machines on these segments. These machines are hardened to a greater extent than any other devices (except the firewalls) on the network and are closely monitored using centralized monitoring and reporting devices. A perimeter firewall closely monitors and logs all communications in and out of this segment, and quickly reports anomalous activity. If something goes wrong on the network services segment, it’s likely that multiple IT groups will be aware of the problem and provide a quick and decisive response.

Developer Users Segment

The developer users segment is likely to contain proprietary information about the company’s core assets. While the machines used to warehouse the code are probably locked down, the developers are often allowed to use whatever protocols and services they like when connecting to each other, and to the Internet. The code warehouse servers are likely to be very closely monitored, but the developers workstations are more likely to be managed by the developers themselves, or by lower level desktop admins. A perimeter firewall in front of the developers segment may severely limit incoming connections to developer workstations and code warehousing servers, but it’s most common to allow developers whatever they want outbound. This kind of unfettered access is a potential set-up for worms, viruses and other automated attacks. Targeted attacks are also possible via trojans, since outbound access is unfettered.

General Users Segment

The general users segment includes users workstations of all types, and does not contain network service servers. Only workstations are located in this security zone. These users are more likely to be naïve about network security and habitually click e-mail attachments, uncritically click on links in e-mail messages and Web pages, and use dangerous applications such as instant messaging and peer to peer apps. This segment is at higher risk of compromise because of the unsophisticated nature of the users. A perimeter firewall placed in front of this segment can be used to stop or mitigate spread of exploits that are likely to begin on this segment. The perimeter firewall can also be used to enforce least privilege on these users.

Authenticated Access DMZ

The authenticated access DMZ is a security zone containing Internet facing servers, such as front-end Exchange Servers. Users must authenticate via an encrypted link at either the ISA firewall or the server located on the authenticated access DMZ. Unauthenticated connections are dropped. We’ll talk more about the authenticated DMZ and how to leverage the ISA firewall’s stateful packet and application inspection skills later in this article.

Wireless LAN Segment

The wireless LAN security zone includes wireless devices that connect anonymously to the WLAN. These are often used for guest access to the Internet and possibly corporate network services (through secure VPN links). Devices on this segment fall outside corporate IT management and have unknown client health status. These are high-risk devices because they move from unknown network to unknown network and have likely been exposed to a wide variety of network worms, viruses, automated attacks and explicit intrusions. A perimeter firewall can be used to block all access to corporate network resources while allowing very limited anonymous access to Internet resources.

Network Services Segment

The least trusted security zone on the list is the unauthenticated DMZ. The unauthenticated DMZ has all the same characteristics as the anonymous wireless LAN security zone, except for the facts that there are many more users on the Internet representing a much larger “attacker surface” and that there is no exposure to any corporate managed network services on the wireless LAN segment. The anonymous access DMZ is likely to contain inbound SMTP relays, anonymous access Web and FTP servers, and advertising DNS servers.

Have Questions about the article? 
Ask at: http://tinyurl.com/d36m9

Drilling Down on the Authenticated and Anonymous DMZ Segments

Now let’s take a closer look at the authenticated and anonymous access DMZs, since these will be the main focus of the in depth coverage and step by step instructions included in subsequent articles in this series.

Scenario 1

Authenticated and anonymous access DMZs fit into multiple network scenarios. The figure below shows one such scenario. This network infrastructure includes a single ISA firewall with a router in front of the ISA firewall. The router can have packet filtering enabled to limit the incoming connections if you want. The ISA firewall has four network interfaces:

  • A network interface connecting the ISA firewall to the Internet.

  • A network interface connecting the ISA firewall to an authenticated access DMZ

  • A network interface connecting the ISA firewall to an anonymous access DMZ

  • A network interface connecting the ISA firewall to the corporate or “internal” network


Figure 1

The authenticated access DMZ allows only authenticated connections to servers on the authenticated access DMZ. Authentication can take place at the ISA firewall (pre-authentication), at the server on the authenticated access DMZ, or both. The key feature of the authenticated access DMZ is that no anonymous connects are allowed to the authenticated access DMZ, and all authentication must take place within an encrypted channel.

The front-end Exchange Server provides an ideal example of an authenticated access DMZ server. The ISA firewall can provide pre-authentication for incoming OWA, OMA, Exchange ActiveSync and RPC/HTTP connections to the front-end Exchange Server. When the ISA firewall performs pre-authentication, it can forward the authenticated user credentials to the front-end Exchange Server and the front-end Exchange Server confirms the user credentials. Only after the ISA firewall authenticates and authorizes the connection is the user allowed to access the front-end Exchange Server and connect to Exchange Server resources.

Users can also access the SMTP, POP3 and IMAP4 services on the front-end Exchange Server. With these protocols, the ISA firewall cannot perform pre-authentication, but the ISA firewall can be configured to allow force encrypted SMTP, POP3 and IMAP4 connections to the front-end Exchange Server. The encrypted connections insure that not only must users have the appropriate credentials, but those credentials are also secured when an encrypted TLS tunnel.

The front-end Exchange Server in the authenticated access DMZ then forwards the connections to the back-end Exchange Server on the corporate network. The ISA firewall is configured to allow only the required protocols to the required servers. For example, the front-end Exchange Server must be able to communicate with the Active Directory. The ISA firewall is configured to allow only the front-end Exchange Server to communicate with a domain controller on the corporate network in order to perform authentication using only the required protocols. The ISA firewall is also configured to allow the front-end Exchange Server to communicate with the back-end Exchange server; again, using only the protocols required between front-end and back-end Exchange Servers.

In addition to the stateful packet inspection the ISA firewall provides for all connections made through the firewall, the ISA firewall will perform deep application layer inspection on the HTTP, HTTPS (SSL), POP3, SMTP and RPC connections. This includes the connections made from the Internet host to the front-end Exchange Server, and the connections made from the front-end Exchange Server to the back-end Exchange Server and domain controllers on the corporate network.

Scenario 2

The first example was a relatively simple configuration that stacked the multiple security zones found on the internal network into a single corporate network. A much more secure configuration places network infrastructure services on a dedicated network services segment. Instead of placing the domain controllers, back-end Exchange Servers, file servers and other key networking services on the same network as the users of various types, the critical infrastructure services are placed on one or more network services segments.

The figure below shows one example of how you would configure such a network services segment firewalled by an ISA firewall. In this example, both internal and external users must traverse one or more ISA firewalls in order to reach the back-end Exchange Server and other networking services. Internet users must go through the edge ISA firewall to reach the front-end Exchange Server and then the front-end Exchange Server must go through both the edge ISA firewall and the network services perimeter ISA firewall to reach the back-end Exchange servers.


Figure 2

This design provides superior protection to the first example, because the back-end Exchange Servers, domain controllers and other vital network services should not only be protected from Internet users, but also require protection from users on the corporate network, since the network services clearly belong to a different security zone than end-user machines on the corporate network. The network services perimeter ISA firewall is also configured to allow connections only to allowed servers using specific protocols and only from users who required those connections.

Scenario 3

Figure 3 shows a variation of the back to back ISA firewall infrastructure. In this firewall design, there is an edge (front-end) ISA firewall and a back-end ISA firewall. The edge ISA firewall has three network interfaces: one to the Internet, one to an authenticated access DMZ located between the internal interface of the edge ISA firewall and the external interface of the back-end ISA firewall, and one connected to an anonymous access DMZ segment.

In this scenario, the anonymous connections never get near the back-end ISA firewall, and the front-end ISA firewall performs the required stateful packet and application layer inspection required to protect both the authenticated access and anonymous access DMZs.


Figure 3

Note that the front-end Exchange Server is still located on an authenticated access DMZ. The edge ISA firewall can still pre-authenticate the connections, using either integrated Windows authentication or RADIUS authentication. In the back to back ISA firewall scenario where the edge ISA firewall performs pre-authentication, we can make an exception to our ISA firewall best practice of making the firewall a domain member because the edge ISA firewall doesn’t perform transparent outbound authentication for Corpnet network clients.

In this case, RADIUS is an acceptable second best option. However, I often make the edge and back-end ISA firewall’s domain members, since no unauthenticated connections are allowed into the DMZ between the ISA firewalls.

There are other more complex and even more secure DMZ scenarios, but at this point it should be abundantly clear that not only is the DMZ not dead, its required more now than ever before. Fortunately, the ISA firewall provides the idea firewall platform to create a well designed multi-perimeter network that enforces strong access controls over what communications can traverse network security zones.

Scenario Used in this Article Series

In this article series we will cover the concepts and practices of using a multihomed ISA firewall to create multiple security zones using DMZs. The sample network used in the scenario covered in this series includes a single ISA firewall with four network interfaces installed. We use ISA firewall best practices and make the firewall a domain member, so that we can enhance the overall level of security provided by the ISA firewall. I will assume that you have already installed the ISA firewall using the parameter set forth in part two of this series.

The authenticated access DMZ will contain a front-end Exchange Server. The ISA firewall will be configured to allow incoming connections from the Internet to the front-end Exchange Server’s OWA, OMA, Exchange ActiveSync, RPC/HTTP, POP3S, IMAP4S and SMTPS services. The ISA firewall will also be configured to allow the front-end ISA firewall to communicate with the DC and back-end Exchange Server on the default Internal Network. No new primary connections will be allowed from the default Internal Network and the authenticated access DMZ segment.

The anonymous access DMZ segment will contain a single Windows 2003 server that acts as a DNS advertiser for out split DNS infrastructure, an inbound SMTP relay that accepts anonymous SMTP connections from Internet SMTP servers, and an anonymous FTP server. No authenticated connections are made to this server on the anonymous access DMZ. The ISA firewall will be configured to allow inbound connections to the SMTP, DNS and FTP services on the anonymous access DMZ server. The ISA firewall will also be configured to forward the inbound SMTP connections to the Exchange Server on the corporate network.

The corporate network contains a domain controller, a back-end Exchange Server, and a Windows XP client system. The ISA firewall will be configured to allow no outbound connections from the corporate network to the DMZ segments except for an RDP Access Rule allowing administrators to access DMZ servers on both DMZ networks. An “all open” Access Rule will be created to allow all administrators access to all protocols and all sites on the Internet. Another Access Rule will be created that allows all domain users to access the Microsoft Web site using only the HTTP protocol. This is a very simple firewall Access Policy used only for demonstration purposes. On a production network, you would create more granular user/group based access controls giving users access onto the sites and protocols required to do their work.


Figure 4

Have Questions about the article? 
Ask at: http://tinyurl.com/d36m9

Summary

In this article, part 1 of a multipart series of article on how to create multiple DMZs using a multihomed ISA firewall, we discussed key concepts in DMZ design and implementation. Special attention was given to the wisdom of putting the front-end Exchange Server in a dedicated DMZ segment, segregated from the back-end ISA firewalls. We finished up this article by covering several DMZ scenarios that support authenticated and anonymous access, again with special focus on increasing security for an Exchange Server organization by segregating the front-end and back-end Exchange Servers into different perimeters and security zones. In the next installment of this article we’ll turn our attention to configuring the ISA firewall with the appropriate ISA firewall Networks, create the Network Rules connecting the ISA firewall Networks, and creating the Access Rules required to allow the front-end Exchange Server to communicate with the back-end Exchange Server.

If you missed the other articles in this series, check them out at:


Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top