Firewall Architecture Review

Firewall architectures can be defined as the placement of firewalls in relation to other machines on the corporate network. A variety of firewall architectures exist as well as a number of ways to classify them. In this section, we take a look at some of the more common firewall architectures.

Screening Router

A screening router is a router that is placed on the edge of the corporate network. The router is configured to allow inbound and outbound packets based on policies you have created on the router. The screening router is usually a packet filtering router and does not perform advanced firewall functions.

Routers can be configured to route all traffic to and from the Internet. However, you can significantly improve security by having a well-thought-out security plan; you should consider in advance which type of packets you need to allow inbound and outbound.

For example, do you need to allow all types of traffic inbound through the router? Or, can you limit the types of traffic allowed through the packet filtering router? For example, if the only new inbound connections you require are to a Web server on the internal network or DMZ segment, the only inbound connection you need to allow is TCP port 80. All other inbound new connection attempts can be dropped by the router.

The screening router is typically a packet-filtering route with circuit layer features. The circuit layer features allow the router to evaluate the Transport layer header when making allow and deny decisions. However, it's best to be judicious when configuring access policies on the router because performance is adversely affected with the number of rules you consider on the screening router. It's best to not get too granular when configuring access policies on the screening router.

Multihomed Firewall

The Multihomed firewall has two or more network interfaces. The Multihomed firewall is typically placed behind the screening router. This firewall usually has one interface directly connected to the internal network and another interface to the Internet. The external interface could also be connected to a DMZ segment that lies between the firewall and the router. The Multihomed firewall can have additional interfaces act as either DMZ segments or additional internal network segments.

The most common deployment of the Multihomed firewall is to place it behind a router. The router in front of the Multihomed firewall can perform an initial screening of packets before they reach the Multihomed firewall. When packets reach the Multihomed firewall, the firewall can make more complex decisions regarding whether packets are allowed or denied.

Screened Subnet or DMZ Segment

A Screened Subnet or DMZ Segment is a network segment that is under the corporation's administrative control, but is not part of the internal private network's security zone. The DMZ segment is considered to be part of the public network, and public network hosts can access resources on the DMZ segment (see Figure 5.3).

In a typical DMZ, there is a packet-filtering router and a firewall. The packet-filtering router has an interface directly connected to the Internet and a second interface connected to the DMZ segment. The firewall has an interface connected to the DMZ segment and another interface connected to the internal network. There may be multiple firewalls, depending on the organization's requirements.

The DMZ segment is used to host resources that are accessible by Internet hosts. Such resources might include a public Web server, an SMTP mail relay server, an FTP server, or an NNTP server. All of these servers can be accessed by Internet hosts and typically provide services to anonymous users, although anonymous access is not a requirement.

An important point to keep in mind, and one that is often forgotten or ignored by network administrators, is that the resources contained on the DMZ segment should belong to a completely different security zone from resources on the internal, private network. The goal of a well-designed DMZ segment configuration is that if hosts on the DMZ are compromised, no deleterious effects will be noticed on the internal network. The internal network should not be affected because resources on the internal network do not trust machines or accounts located on the DMZ segment.

For example, you might want to create a Windows 2000 domain to store the accounts used on servers in a DMZ segment. There is nothing wrong with this configuration, but you must not allow any form of trust between the DMZ network domain and the internal network domain. The DMZ and the internal network must represent completely different security partitions.

A common error that some network administrators make is to configure servers on the DMZ segment to take advantage of the user accounts database on the internal network. There are a number of reasons why neophyte administrators might want to do this, but such a configuration has the net effect of violating the partition between the DMZ and internal network security zones. This violation can have a disastrous effect on the network security infrastructure.

Another important issue that you should address is documentation of router and firewall configurations. The initial router and firewall configuration should be documented. Any changes to that initial configuration should likewise be documented. This type of change management system prevents configuration errors from creating back doors into the router or firewall.

Machines on a DMZ segment are the most likely machines to be attacked by Internet intruders. To prevent machines on the DMZ segment from being compromised too quickly, the machines on the DMZ segment should be configured as Bastion hosts. We consider the subject of Bastion hosts in the next section.

Bastion Hosts

A Bastion host is a machine that allows Internet hosts to communicate with it. Bastion hosts are at high risk of intrusion because any machine that allows untrusted hosts to connect to it has the potential to be compromised by an Internet intruder. Bastion hosts typically lie on DMZ segments and are the first computers under corporate control to be compromised.

Constant exposure argues persuasively that all Bastion host computers will be compromised at some time or another. That time might be tomorrow or a year from now. The reason you must assume that the Bastion host will be compromised is that these are the computers upon which intruders focus their attention and will be the ones that provide the highest possible return for the Internet intruder.

Although there is no such thing as “perfect security,” you can do some things to delay a successful compromise of your Bastion hosts. Just because you assume that these machines will be compromised at some point in the future does not mean you must take that situation lying down!

The ideal Bastion host is configured to provide only the services required to perform its functions. For example, a Web server should be able only to serve Web pages and run any required Web services. The Web server does not need to run FTP, SMTP, NNTP, IMAP, POP3, CIFS/SMB, SNMP, or any other service. The likelihood of a successful attack against a Bastion host increases with the number of services installed and running on the computer. The fewer services, the fewer avenues for attack thereby lowering the chance of a successful compromise by an Internet intruder.

Some operating systems lend themselves to be configured as Bastion hosts more easily than others. Unix-based operating systems typically ship or install in a locked-down mode that requires the administrator to manually enable required services. Microsoft servers suffer from their LAN-based file- and print-sharing heritage, and come with a large number of services available to network clients. It takes more work to lock down a Windows server than a Unix-based server.

In addition to removing or disabling all services not in active use on the Bastion host, you should also remove all management tools from that machine. The optimal configuration of a Bastion host makes it impossible to manage the machine with tools and applications located on the server itself. All tools and applications can be supplied on disk or CD when the server administrator needs to manage that machine.

All administrators will balk at the prospect of a Bastion host configured in this way. This “stripped-down” machine configuration makes it impossible to manage the machine remotely. The server administrator must be at the machine console and manage it interactively. The decision on whether such a highly secure server configuration is required should be based on the network security policy, and not on administrative convenience.

REVIEW BREAK Keep in mind that the firewall architectures are not mutually exclusive. All the firewall architectures discussed can be used in the same network environment. For example, all hosts on a DMZ segment should be configured as Bastion hosts. The DMZ segment should be protected by a screening router, and if the DMZ abuts the internal network, a Multihomed firewall should be in place between the private network and the DMZ.