Configuring Domain Members in a Back to Back ISA Firewall DMZ —
Part 1: Concepts in DMZ/Perimeter Networking and Security Zones
By Thomas W Shinder MD, MVP
|
Have Questions about the article? |
If you would like to read the other parts in this article series please go to:
A hot topic these days is DMZs. I’ve read lots of articles lately about the death of the DMZ, that DMZs are no longer required, that DMZs don’t provide any additional protection, that DMZs are unrealistic because the only real protection is host-based protection, and that DMZs aren’t required because firewalls themselves are ineffective and therefore aren’t required, and that there’s no difference (in a security context) between any Internet connected network (or any other network, for that matter).
I have to admit that all of these articles, talks and dissertations are interesting and sometimes even contain an idea that’s worthy of consideration. Almost all of them have entertainment value as the authors extend their wings for flights of fancy. But taken as a whole, the entire concept that DMZs (which are just security perimeters) are dead or don’t provide added vital protection and access control is 98.6% bunk.
DMZs Morph into Security Perimeters
The problem these security wonks have is that all DMZs are not created equal. Not all hosts belong to the same security zone. Hosts belonging to different security zones need to be separated by network access control devices to mitigate (notice I didn’t prevent) compromises in one security zone from quickly extending to other security zones. Ignoring this reality take more than a grain of salt – it takes a willing suspension of disbelief.
For example, there’s a reason why you can’t take your friends and family into the Pentagon War Room – you and your family belong to a different security zone than the War Room attendees, and there are multiple security devices that make sure there are access controls.
One thing many of these anti-firewall guys have right is that host-based security is the holy grail of computer security. The more secure and selective the host is about sending and receiving traffic, the easier it is for access control devices in front of the host to protect that host, and the more secure that host is against hosts in different and same security zones.
However, I am confident that host-based security Nirvana will not be seen in the next two to three decades (if ever), so perimeter devices interposed between security zone will continue to be required and popular. My confidence is borne from my experience in Medicine and knowledge of law enforcement. In medicine, viruses and bacteria mutate to defeat our efforts to come up with consistently effective antimicrobials, and law enforcement has been working on eliminating crime since the murder took place. Hackers and other network criminals are no different than harmful microbes or bag-men, they will continue to exist, and the better ones will evolve their methods and techniques to subvert even the most effective host-based security systems.
That’s why we’ll always need firewalls as perimeter security devices to provide defense in depth. Firewall will continue to evolve, and the future will certainly see the features of current day firewalls meld the features of stateful packet inspection, stateful application layer inspection, IPS and IDS integrated in a single device. The major hurdle is processing power, and we know from long experience that this problem will be solved in time. Marketing guys will certainly morph the term “firewall” into something else (since firewalls will be seen an superannuated devices by then), but they will be firewalls, regardless of the name marketeers and security wankers may give them.
Keep in mind that the perimeter is not the place where the corporate network meets the Internet. There is no perimeter, there are multiple perimeters. This is often hard to communicate to 1990s firewall admin who consider packet filtering-only devices as comprehensive security solutions and who think in terms of “opening a port” or “closing a port”. All but the most simple networks have multiple perimeters and an access control device (such as an ISA firewall) must be placed inline to separate these perimeters. This is one of the major reasons why I have such distain for unihomed ISA firewalls – unihomed ISA firewall’s provide an illusion of security, but since they are not inline devices, it’s a very simple task to bypass the unihomed ISA firewall.
Define Your Security Zones
A key concept in DMZ construction is to place machines in different security zones on different segments, where the segments are separated by a network security device, such as ISA firewall. Now, the trick is in defining your security zones. There are a number of methods you can use to define security zones. Some examples include:
- A zone could include all services providing a similar function
- A zone could include all machines belonging to the same Active Directory domain
- A zone could include all services that are interdependent on one another
- A zone could include all machines run by untrusted users
- A zone could include all devices managed by trusted partners
- A zone could include all Internet facing devices
It’s beyond the scope of this article to go into an in-depth discussion of security zone classification and segmentation, but I wanted to bring up the subject so that we could focus on one important method of defining security zone: placing Internet facing devices in a security zone separate and distinct from all devices that aren’t Internet facing.
The term Internet facing means that inbound connections can be made to these machines. Any device accepting connections from Internet hosts is considered Internet facing. Placing all Internet facing devices on network segments segregated from non-Internet facing devices is well known and universally accepted method of reducing your attack surface and mitigating some of the risks inherent in placing Internet facing devices on security zones that are not designed to accept incoming connections from Internet hosts.
There are several types of DMZ segments where you can place these Internet facing devices:
- Anonymous access DMZs – These DMZs allow anonymous users to connect to Internet facing devices in the DMZ and the servers in the DMZ allow anonymous connections to them. Inbound SMTP relays and public DNS servers are often found on anonymous access DMZs.
- Authenticated access DMZs – An authenticated access DMZ is significantly more secure than an anonymous access DMZ, because users are authenticated at the firewall and then authorized by the firewall before the connection is forwarded to the DMZ server. No anonymous connections are allowed to authenticated access DMZ, which eliminates the overwhelming majority of attacks that the DMZ server would otherwise be exposed to
- Mixed anonymous/authenticated access DMZs – These DMZs allow anonymous connections through the firewall, but servers on the DMZ require authentication. These servers could authenticate using a local user database, an Active Directory domain located only in the DMZ, or an Active Directory domain located on the corporate network, behind a back-end firewall
The figure below depicts multiple DMZ security zones. The red zone represents the anonymous access DMZ, where the back-end ISA firewall allows anonymous connections to services located on that segment. The Authenticated access DMZ (or perimeter network) represents a security zone where only authenticated users are allowed access to the zone itself; this requires that at least ISA firewall pre-authenticate the user prior to allowing access to resources in the zone itself. The servers within the zone may require authentication as well, but the key here is that connections must be pre-authenticated and pre-authorized prior to even getting to the point of being authenticated by the server. The honeypot DMZ represents a more traditional DMZ segment, where anonymous access to virtually any protocol from internal hosts, and most common protocols from external hosts, is allowed. You might put IDS/IPS and honeypot systems on that DMZ.
Figure 1
Have Questions about the article?
Ask at http://tinyurl.com/mflgw
Front-end Exchange Servers Should be Placed in a DMZ Segment
Notice that the front-end Exchange Server is placed in the authenticated access DMZ. This provides an extra layer of protection by removing the front-end Exchange Servers from the back-end Exchange Servers security zone. This is an excellent configuration because the back-end Exchange Servers are never Internet facing, while the front-end Exchange Servers often are.
A common thread that runs through each of these DMZ implementations is that Internet facing devices are segregated from devices that do not accept incoming connections from Internet hosts. It should be obvious that the attacker [sic] surface presented by the Internet is much larger than any potential attacker surface presented by hosts on only non-Internet facing networks. If for no other reason (and there are plenty of more reasons), you should always exercise due diligence and move Internet facing devices off of networks that are not strictly designed for Internet facing hosts.
One of the best examples of how to handle this problem is seen with the front-end/back-end Exchange Server solution. Because the front-end Exchange Server is typically an Internet facing host, the Internet facing front-end Exchange Server should always be in a DMZ segment, and should never be on the same network security zone or perimeter where the back-end Exchange Servers are located.
Placing the Internet facing front-end Exchange Server in a separate DMZ segment is a critical distinction and something you need to consider in your front-end/back-end Exchange Server deployments, especially in the light of some of the things I’ve read in the tech media recently which seem to imply that you can place your front-end and back-end Exchange Servers on the same security zone and have the same level of security you would have had you placed the front-end in an authenticated access DMZ. Think about it and decide which solution offers a superior security solution and I think you’ll agree with me about placing front-end Exchange Servers in a separate security zone.
Scenario Description
In this article we will focus on a back to back ISA firewall configuration where the back-end ISA firewall is a member of the corporate network domain and the front-end ISA firewall is not a domain member and belongs to its own workgroup. A Web server will be placed in the DMZ segment between the front-end and back-end ISA firewalls and that Web server will be a member of the corporate network domain. The domain controllers for the corporate network domain are located behind the back-end ISA firewall and intra-domain communications will be enabled between the Web server on the corporate network and a specific domain controller on the corporate network.
The figure below provides a high-level view of the example network used in this article.
Figure 2
If you’re familiar with our book Configuring ISA Server 2004 then you’ll recognize that we’re using the typical IP addressing and naming scheme that we’ve used throughout the book and also through the last two years at ISAServer.org.
There are several components of this solution that highlight interesting and important issues in configuring and managing ISA firewalls in a variety of scenarios:
- There is a route relationship between the default Internal Network behind the back-end ISA firewall and the DMZ segment
- Access Rules, not publishing rules, are used to control traffic sourcing from the DMZ Network and destined for the default Internet Network located behind the back-end ISA firewall
- Routing table entries are used to correctly route communications from the DMZ Network and the default Internal Network located behind the back-end ISA firewall
I will call out each of these issues within the body of this article series and provide the rationale for each of these decisions in the appropriate sections.
This article series will include four parts:
- Part 1 – Concepts in design and deployment of DMZs and network security perimeters
- Part 2 – Configuring the back-end ISA firewall
- Part 3 – Configuring the DMZ Web server and front-end ISA firewall
- Part 4 – Using RADIUS authentication on the front-end ISA firewall
The article series will discuss in detail the following topics:
- Configure the back-end ISA firewall with a DMZ ISA firewall Network
- Configure the back-end ISA firewall with a Network Rule setting a Route relationship between the back-end ISA firewall’s default Internal Network and the DMZ ISA firewall Network
- Create Access Rules enabling intra-domain communications between the DMZ server and the domain controller on the back-end ISA firewall’s default Internal Network
- Create Access Rules controlling outbound access from the back-end ISA firewall’s default Internal Network to the DMZ and the Internet
- Configure a routing table entry on the DMZ server
- Join the DMZ server to the domain located on the default Internal Network behind the back-end ISA firewall
- Configure the front-end ISA firewall’s default Internal Network
- Configure a routing table entry on the front-end ISA firewall
- Create an All Open Access Rule on the front-end ISA firewall
- Create a Web Publishing Rule on the front-end ISA firewall
- Configure RADIUS authentication on the front-end ISA firewall
- Test the solution
|
Have Questions about the article? |
Summary
In this, part 1 of a four part article series on configuring a back to back ISA firewall solution with a domain member in the DMZ segment, we discussed concepts in DMZ and perimeter network design. One of the key concepts discussed was that there is no such thing as a perimeter network because there are now multiple perimeters in most organizations that are defined by security zone boundaries. We also identified three common DMZ segment designs: the anonymous access DMZ, the authenticated access DMZ and the mixed authenticated/anonymous access DMZ. We then finished up with a discussion on why front-end Exchange Servers should be placed on perimeter/DMZ networks that are separate and distinct from security zones inhabited by back-end Exchange Servers.
If you would like to read the other parts in this article series please go to:
