24.2. Merged Routers and Bastion Host Using General-Purpose HardwareThe merged interior and exterior router architecture, described in Chapter 6, "Firewall Architectures", and shown in Figure 6-10, is a lower security, lower cost alternative to the screened subnet architecture discussed in the previous section. It can be a very useful architecture for small sites that are facing significant cost constraints, particularly when it is built around a general-purpose computer that can provide not only routing but also flexible packet filtering and proxying. Figure 24-2 shows this architecture.
Figure 24-2. Merged routers using general-purpose hardwareThis architecture is typical of commercial single-box firewalls, where the perimeter network is often referred to as the services net.
In this example, there is a perimeter net but no interior and exterior routers. One machine provides routing and filtering and some normal bastion host functions as well. The perimeter net provides only external services, and there are no connections from the perimeter net into the internal network.
This architecture obviously reduces the cost of the firewall by requiring one router instead of two, but it provides other advantages as well. For instance, it requires only one assigned Internet-visible address; the merged router's external interface must be a legitimate address, but if the merged router can do network address translation, all the other addresses can be selected from private address space. This architecture also makes a clean separation between the firewall and the perimeter services host, allowing them to be managed by different people with different attitudes towards security and only minimal interaction with each other.
Although this architecture closely resembles a condensed version of the previous one, the constraints are significantly different. Because you are putting all the functions on the same machine, there are limits on what you can expect that machine to do. You're going to need to move all noncritical functionality off the firewall itself. On the other hand, you have much more flexibility in what you do on the perimeter services host because it is not critical to the security of the internal hosts (in the screened subnet architecture, the bastion hosts on the perimeter network were security-critical for internal hosts).
In this example, we're going to assume:
24.2.1. Service ConfigurationHow do we provide the basic Internet services with this architecture?
220.127.116.11. HTTP and HTTPSWe have several options for providing internal users with access to the Web:
By contrast, we don't want to publish web pages on an internal services host, which is full of our internal data. We don't want to publish them directly from the firewall either because a web server will add both significant risk and significant load. Publishing web pages will require a separate server on the perimeter network.
Therefore, we will use an HTTP server on the perimeter network to provide service to the Internet. For internal users accessing the Internet, we will use a caching proxy server on the internal services host. Packet filtering on the firewall will allow the caching proxy server to make requests.
We could use the perimeter net web server for HTTPS as well as HTTP; this would require only small changes to the filtering rules. On the other hand, there's no reason to do HTTPS on a simple, noninteractive web server, and a complex server that required HTTPS (e.g., a server that supported e-commerce) would almost certainly require other support services as well (e.g., a database). Since we aren't configuring those other servers in this example, there's no apparent reason to allow HTTPS to the perimeter net, and we will leave it disabled.
18.104.22.168. SMTPHere we have two reasonable choices. First, we could choose to use a dual-server setup like the one discussed previously, with a security-oriented SMTP server on the firewall and a mail server on the services host inside. This will require disk space on the firewall to spool the mail, as well as the CPU power to process it. Second, for more performance at slightly more risk, we could simply pass SMTP to the services host. (We could use an SMTP server on the perimeter net, but we don't consider that a reasonable choice because it would require the perimeter net to create connections to the internal net, which we don't want to allow.)
In order for SMTP to go directly to the services host, either the firewall needs to do network address translation, or the services host needs to have a valid externally visible address.
We will assume that the firewall has disk space and enough CPU power and run a security-oriented SMTP server on the firewall. All incoming mail will be directed (via DNS MX records) to the firewall, which will then pass mail to the internal services host. Similarly, outgoing mail will be sent from the internal services host to the security-oriented SMTP server on the firewall. As we've discussed previously, it's never advisable to let incoming mail go directly to all of your internal machines. Also, once you're directing incoming mail through a single point, it's actually easier -- not to mention safer -- to route outgoing mail through there than to send it direct.
22.214.171.124. TelnetWe allow only outgoing Telnet from the internal network to the Internet through packet filtering; incoming Telnet is too risky to allow at all. Instead, we will support incoming connections via SSH.
126.96.36.199. SSHWe can improve security somewhat over the screened subnet architecture by limiting inbound and outbound SSH to just the internal network services host. This will allow us to control the SSH servers and clients that people use, preventing the use of SSH tunneling.
We will also allow SSH from the internal network to the perimeter network, so that it can be used to administer servers there. It is the only connection between the internal network and the perimeter network, and it is a one-way connection (the perimeter network cannot create it). It is therefore a reasonably safe way to give people administrative access to servers. File transfer protocols like scp and rsync that can use SSH for transport can be used to load files on the server.
188.8.131.52. FTPAs in the screened subnet architecture, outgoing passive-mode FTP can be safely and conveniently provided via packet filtering from the internal network. Normal-mode FTP cannot because you would have to allow incoming connections. If you want to use normal-mode FTP, you will need an FTP proxy. That proxy should not run on the internal services host because in order to support the proxy there, we'd still need to allow incoming connections to a machine on the internal network. However, we could run an FTP proxy on the firewall, and many systems suitable for this kind of firewall will supply appropriate proxies.
For the sake of example, we'll assume that we don't have FTP proxying software on the firewall, and we'll use packet filtering to allow outgoing FTP, but only in passive mode. Since most FTP comes from web browsers, which use passive mode by default, this is unlikely to be a problem.
Incoming FTP is more difficult. Supporting incoming passive-mode FTP with pure packet filtering would require allowing all TCP connections from all Internet hosts on any port >1023 to the perimeter services host on any port >1023. For this architecture, it is an unacceptable risk to the perimeter services host. It is possible to safely support normal-mode FTP to the perimeter network, but as we mentioned previously, most FTP comes from web browsers, which will default to using passive mode and will not work. Unless the packet filtering system we are using supports a transparent proxy for FTP, we will not be able to offer FTP services to the Internet.
If the packet filtering system does support a transparent FTP proxy, then you could configure it to direct connections to a server on the perimeter net. We will assume that it does not and that we will not be providing incoming FTP service.
184.108.40.206. NNTPAt most sites this size, the best option (assuming that NNTP service is important) is to purchase NNTP from an external server and allow clients to connect directly to that server. Many Internet service providers will provide this service for a small surcharge. It would be possible to provide NNTP internally if we wanted to dedicate an internal machine to be an NNTP server. It would be unwise to make either the internal services host or the firewall an NNTP server; instead, we'd need to dedicate another internal services host. We will assume that an external Internet-based NNTP service will be used.
Unfortunately, this will keep us from having private newsgroups that are visible only to internal users, unless we set up a separate internal news server for only those groups. Many news clients (particularly those that are part of web browsers) can easily access newsgroups from multiple servers.
220.127.116.11. DNSBecause we wish to hide the internal addresses, we will need to have two DNS servers: one for the Internet and one for the internal users. The Internet-visible DNS server could go on the firewall or on the perimeter services host (the two places we put externally visible services). The internal DNS server could go on the firewall or on the internal services host (the two places we put internally visible services).
Putting the Internet-visible DNS server on the perimeter services host is not a good idea. The perimeter is an untrusted network, but DNS is critical to the functioning of the Internet connection. The Internet-visible DNS server should therefore be on the firewall.
The internal DNS server, on the other hand, should not be on the firewall for two reasons. First, putting it on the firewall will make internal hosts dependent on the firewall for otherwise internal functions, which we want to avoid. Second, we've already got the external DNS server there, and it's going to be complicated to administer them both on the same machine.
We'll assume the following configuration:
24.2.2. Packet Filtering RulesLet's look at the packet filtering rules necessary to support the configuration we've described in the previous sections. As in the first example of the screened subnet architecture, we're going to assume an "ideal" router. In this case, because we're providing services on the firewall itself and to a perimeter network, we need to consider the interfaces separately, so we have an extra column indicating which of the network interfaces the rule applies to. "Ext" is the interface to the external world, "Int" is the interface to the internal network, and "Pmtr" is the perimeter network.
"Internal" and "Perimeter" mean the range of IP addresses for those networks. "Int Service" and "Pmtr Service" are the IP addresses of the internal network and perimeter network services machines, respectively, while "Firewall Ext" is the firewall's external interface, "Firewall Int" is the firewall's internal interface, and "Firewall Pmtr" is the firewall's perimeter interface.
Because this firewall has multiple interfaces, we need to specify slightly different information from what we've been providing. On a two-interface firewall, it's clear exactly what happens to a packet that's going "In"; it goes from the Internet to the internal network. On a three-interface firewall, there are two possible routes for such a packet: it could be going from the Internet to the internal network, or from the Internet to the perimeter network. These two options need different rules.
In order to deal with this situation, we have to specify a direction for each interface, not for the whole firewall. A packet that crosses the firewall will go in on an interface and out on an interface, regardless of the direction it is traveling. Packets that come from the Internet to the internal network will be going "Inward" on the external interface and "Outward" on the internal interface; packets that go from the internal network to the Internet will go "Inward" on the internal interface and "Outward" on the external interface.
In general, when looking at the following table, you will notice that the "Inward" filtering rule for one interface will be identical to an "Outward" rule for another interface. This pairing of rules and interfaces ensures that the filtering rules are not dependent on packet routing decisions.
TIP: In the following table, directions are relative to the specific interface, not to the firewall as a whole. This is different from the other tables in the book, which do not show individual interfaces.The firewall needs the following rules to support the configuration we've outlined:
Here is some additional information about each set of rules in this table:
24.2.3. Other Configuration WorkIf you are using Linux and ipchains as your packet filtering system, you will also need to add rules for the FORWARD chain so that the system will forward packets between the interfaces. You could add a single allow rule to the FORWARD chain and rely on the specified interface rules to protect you. For a more secure but harder to maintain configuration, you could duplicate all the rules that pass traffic from one interface to another in the FORWARD chain.
In addition to setting up the packet filtering rules, we need to do various other kinds of configuration work, as follows:
24.2.4. AnalysisJust how good a firewall is this? It's not great, but it's functional. Let's consider it in relation to the strategies and principles discussed in Chapter 3, "Security Strategies", and in comparison to the screened subnet architecture we configured in the first example.
18.104.22.168. Least privilegeYou can see the principle of least privilege in action in some places in this setup. For example, configuring SMTP so that outgoing mail goes out via the internal network services host rather than directly to remote systems is an application of least privilege. Why? Because it lets you control more tightly how internal systems connect to external systems. (In this case, it makes it unnecessary for internal systems to talk directly to external systems in order to provide this service.)
Similarly, we've very carefully applied least privilege to the perimeter network, giving it the minimum access needed to provide web services to external hosts. On the other hand, merging the interior and exterior routers clearly fails to enforce least privilege, particularly when the resulting host also provides services like DNS and SMTP. In order to perform all of these functions, the routing host ends up with a very large number of privileges. To some extent, we've moved privilege from the perimeter to the firewall host.
We've also created an internal services host with multiple levels of privilege; it's providing several services, and it's sitting on the internal network, which is a kind of privilege in itself. This host is a second place where least privilege is violated.
The screened subnet architecture we described earlier in this chapter does a somewhat better job of applying the principle of least privilege than the architecture described in this section.
22.214.171.124. Defense in depthThe principle of defense in depth is almost missing from this setup. Internal hosts are protected from the outside world by the firewall host and the internal services host, but nothing protects them from the firewall host; if that one host is compromised, all of the internal hosts are compromised. A small amount of defense in depth is present in the separation between the services hosts and the router; the router protects the internal services host from the Internet and protects the internal hosts from the perimeter services host. However, the defense of the internal services host isn't all that good.
The screened subnet architecture we described earlier in this chapter does a much better job of applying the principle of defense in depth.
126.96.36.199. Choke pointThe principle of a choke point is clearly applied in this example because everything between internal clients and the Internet comes through at least the firewall host. Further, most of it comes through the internal services host via proxies.
The screened subnet architecture described earlier in the chapter does a slightly better job of applying the principle of a choke point, but not by much.
188.8.131.52. Weakest linkThe obvious weak link to attack in this architecture is the firewall host; the internal services host runs a close second because we allow incoming SSH. If either of these hosts is compromised, it is going to severely affect the security of the rest of the internal hosts because they are on the same network as the internal hosts and because nothing protects the internal hosts from them. With the screened subnet architecture, on the other hand, the interior router protects the internal hosts from the bastion host.
The screened subnet architecture presents a much stronger weakest link to an attacker.
184.108.40.206. Fail-safe stanceYou can see the principle of a fail-safe stance applied through the packet filtering rules specified for the merged routers architecture. In general, the rules specify what you're going to allow and deny everything else by default. This approach is fail-safe because if something unanticipated comes along (for example, a new service), it won't be allowed through your firewall, unless, of course, it mimics or is tunneled through some other service that you do allow.
However, the design of the architecture itself is not fail-safe. If the firewall or internal services hosts are compromised, your whole site's security is severely compromised. The screened subnet architecture is much better at implementing a fail-safe stance.
220.127.116.11. Universal participationIf this is your site's only connection to the Internet, you've got involuntary universal participation: everybody has to go through the firewall to get to the Internet. Voluntary universal participation would be better, but it would require some user education concerning the goals of and the need for your security measures.
In terms of the universal participation principle, there really isn't much difference between the first and second sample architectures.
18.104.22.168. Diversity of defenseThere are few opportunities here to apply the principle of diversity of defense because you pretty much have only one of everything: there is only one firewall host and only one internal services host.
22.214.171.124. SimplicityAlthough this firewall initially appears simpler than our first example, it actually adds complexity by combining functions. In particular, the packet filtering rules are more complex because we have chosen to use a single three-interface router and filtering system. For example, rather than being able to simply think about "in" and "out" relative to the site, we have to think about "inward" and "outward" relative to each of three interfaces; for packets inbound to the site, we have to set up an inbound filter on one interface and an outbound filter on another, which is tedious and error-prone. Another example of complexity is the decision to implement packet filtering, proxy servers, and application servers all on the same firewall host; there may be unexpected interactions and dependencies between these services, which an attacker can take advantage of. On the other hand, putting the external server on a perimeter network and preventing it from talking to the internal network significantly simplifies the configuration of that bastion host.
24.2.5. ConclusionsThe merged router architecture can be cheaper to implement than the screened subnet architecture, but it's less secure. There is little or no redundancy in the design, and it's not really fail-safe. On the other hand, it provides an effective way to use a single Internet address to provide reasonably safe and full-featured access to and from the Internet.
It may be cheaper than the screened subnet architecture, but not by much. The screened subnet architecture requires a minimum of three dedicated machines (two routers and a bastion host). This architecture really also requires a minimum of three dedicated machines (one firewall and two services hosts). One advantage of this architecture is that you can use similar hardware for the firewall host and the internal and perimeter network hosts. It is possible to build all of these systems using spare PC equipment and freely available software.
If you don't need to provide web service to external clients (for instance, if you choose to out-source your web site to a web hosting service), you could make this architecture significantly cheaper and simpler by eliminating the perimeter network altogether. Or, if you don't need to keep the price down, you could combine this architecture with the screened subnet architecture; to do so, you would put a perimeter network on a third interface on the external router in the screened subnet architecture. This extra network would be the untrusted network that handled services for clients on the Internet.
Copyright © 2002 O'Reilly & Associates. All rights reserved.