In the previous tip we explored the basics of choosing a firewall topology. We covered the differences between bastion hosts, screened subnets and combining multiple firewalls for maximum security. Once you have decided which topology best suits your IT infrastructure, you need to decide where to place individual systems within the chosen topology.
As we discuss this topic, we'll use the concept of security zones to further define our requirements. For our purposes, consider a security zone to be all of the systems connected to a single interface of a firewall – either directly or through network devices other than firewalls.
Bastion host
First, let's look at the simplest case: the bastion host. In this scenario, all traffic entering or leaving the network passes through the firewall and it has only two interfaces: a public interface directly connected to the Internet and a private interface connected to the intranet. This leaves us with two security zones, making it fairly easy to place systems. We simply put all systems that we would like protected in the private zone!
In the case of a bastion host topology, we're assuming that you are not planning to offer any public services to the Internet. If you do need to offer public services (such as DNS, SMTP or HTTP), you should seriously consider the use of an alternate topology. If that is not possible, you have a difficult decision to face: should you place your public servers in the public or private zone? If you place them in the public zone, they don't gain any protection from the firewall and are more vulnerable to attack. On the other hand, placing them in the private zone raises the possibility that other, more sensitive systems, may be compromised if the public server falls victim to an attack. You need to carefully weigh the risks and benefits when making this decision.
Figure 1: Bastion host
Screened subnet
The screened subnet scenario, the most commonly deployed firewall topology, is also somewhat straightforward. We add an additional zone – the screened subnet (or DMZ) – that contains all hosts offering public services. In this case, the public zone is directly connected to the Internet and contains no hosts controlled by the organization. The private zone contains systems that Internet users have no business accessing, such as user workstations, internal file servers and other nonpublic applications. The DMZ contains all systems that are intended to provide services to the Internet. This zone contains your public Web server, SMTP server, DNS servers and other similar systems. Your IMAP/POP server may or may not reside in this zone, depending upon your security policy.
Figure 2: Screened subnet
Multi-homed firewall
The final scenario, a multi-homed firewall with more than three interfaces, poses the most interesting challenge. In this case, you have more than three zones, so you have the luxury of further subdividing systems. You'll need to make these subdivisions based upon the specific security objectives of your organization. One division you might want to make is to place workstations into different zones to provide isolation for sensitive systems. For example, you might place all systems belonging to accounting into one zone, executive workstations in another zone and other workstations in yet a third zone. You also may wish to subdivide systems offering services to the Internet. For example, systems that provide services to the general public (such as a company Web site) may be placed in a different zone than systems that offer services only to authenticated users (such as a Web mail server).
Figure 3: Multi-homed firewall
In the end, the choices are yours to make. Now that you've read this tip, you should have plenty of ideas running through your mind. Sit down and commit them to paper, discuss the options with your colleagues and develop a system placement strategy suitable for your organization.
FIREWALL ARCHITECTURE TUTORIAL
Introduction
How to choose a firewall
Choosing the right firewall topology
Placing systems in a firewall topology
Auditing firewall activity
ABOUT THE AUTHOR:
|
|
Mike Chapple, CISSP is an IT Security Professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles including the CISSP Prep Guide and Information Security Illuminated.
|
|
