In practice, the advantages of single-box architectures are not in their security but in other practical concerns. Compared to a multiple-layer system that's integrated with your network, a single-box architecture is cheaper, easier to understand and explain to management, and easier to get from an external vendor. This makes it the solution of choice for small sites. It also makes it a tempting solution for people who are looking for magic security solutions that can be put in once and forgotten about. While there are very good single-box firewalls, there are no magic firewalls, and single-box solutions require the same difficult decisions, careful configuration, and ongoing maintenance that all other firewalls do.
Some variations on the dual-homed host architecture use IP to the Internet and some other network protocol (for instance, NetBEUI) on the internal network. This helps to enforce the separation between the two networks, making it less likely that host misconfigurations will let traffic slip from one interface to another, and also reducing the chance that if this does happen there will be vulnerable clients. However, it does not make a significant difference to the overall security of the firewall.
The network architecture for a dual-homed host firewall is pretty simple: the dual-homed host sits between, and is connected to, the Internet and the internal network. Figure 6-2 shows this architecture.
On the other hand, dual-homed hosts aren't high-performance devices. A dual-homed host has more work to do for each connection than a packet filter does, and correspondingly needs more resources. A dual-homed host won't support as much traffic as an equivalent packet filtering system.
Since a dual-homed host is a single point of failure, it's important to make certain that its host security is absolutely impeccable. An attacker who can compromise the dual-homed host has full access to your site (no matter what protocols you are running). An attacker who crashes the dual-homed host has cut you off from the Internet. This makes dual-homed hosts inappropriate if being able to reach the Internet is critical to your business.
You are particularly vulnerable to problems with the host's IP implementation, which can crash the machine or pass traffic through it. These problems exist with packet filtering routers as well, but they are less frequent and usually easier to fix. Architectures that involve multiple devices are usually more resilient because multiple different IP implementations are involved.
A dual-homed host can provide services only by proxying them, or by having users log into the dual-homed host directly. You want to avoid having users log into the dual-homed host directly. As we discuss in Chapter 10, "Bastion Hosts", user accounts present significant security problems by themselves. They present special problems on dual-homed hosts, where users may unexpectedly enable services you consider insecure. Furthermore, most users find it inconvenient to use a dual-homed host by logging into it.
Proxying is much less problematic but may not be available for all services you're interested in. Chapter 9, "Proxy Systems", discusses some workarounds for this situation, but they do not apply in every case. Using a dual-homed host as your only network connection actually slightly eases some problems with proxying; if the host pretends to be a router, it can intercept packets bound for the outside world and transparently proxy them without anybody else's cooperation.
Proxying is much better at supporting outbound services (internal users using resources on the Internet) than inbound services (users on the Internet using resources on the internal network). In a dual-homed host configuration, you will normally have to provide services to the Internet by running them on the dual-homed host. This is not usually advisable because providing services to the Internet is risky, and the dual-homed host is a security-critical machine that you don't want to put risky services on. It might be acceptable to put a minimally functional web server on the dual-homed host (for instance, one that was only capable of providing HTML files and had no active content features, additional protocols, or forms processing), but it would clearly be extremely dangerous to provide a normal web server there.
The screened subnet architecture we describe in a later section offers some extra options for providing new, untrusted, or inbound services (e.g., you can add a worthless machine to the screened subnet that provides only an untrusted service).
No services are being provided to Internet-based users.
The network being protected does not contain extremely valuable data.
|5.5. Virtual Private Networks||6.2. Screened Host Architectures|
Copyright © 2002 O'Reilly & Associates. All rights reserved.