Merged Routers and Bastion Host Using General-Purpose Hardware

Figure 24-2. Merged routers using general-purpose hardware

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:

• That the firewall is not the only server at the site. In particular, another machine is located on the perimeter network that provides public HTTP and, if the filtering software is adequate, FTP services. There is also a system on the internal network to accept SMTP (possibly providing mailbox services) and to provide internal network DNS service.
• As in the previous example, that internal users are trusted not to actively try to circumvent the firewall, and that we have no particular need to monitor or log their Internet activities.
• That an address that has been properly assigned to your site and that is being properly routed and advertised to the rest of the Internet by your service provider is available for the external interface on the firewall. (If the firewall supports network address translation, private address space can be used for both the perimeter network and the internal network.)
• That the perimeter net is untrusted, and that it is unacceptable to make connections from it to the internal net.
• That we wish to hide internal addresses (this could be because they're private, unroutable addresses or just because we're paranoid).
• That we do not want internal machines to be dependent on the firewall for anything except Internet access; the internal network should continue to function if the firewall stops working.

Service Configuration

HTTP and HTTPS

• We could simply allow them to go out directly, using packet filtering.
• We could run a simple proxy server.
• We could run a caching proxy server.

'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.

SMTP

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.

Telnet

SSH

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.

FTP

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.

NNTP

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.

DNS

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:

• The firewall is the primary external DNS server for your domain.
• You have an external DNS secondary server for your domain, (e.g., one of your service provider's machines).
• The internal services host is the primary internal DNS server.

Packet Filtering Rules

"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 tutorial, which do not show individual interfaces.

[182]UDP has no ACK equivalent.

Here is some additional information about each set of rules in this table:

• Spoof-1 and Spoof-2
• Block packets from the Internet that claim to have source IP addresses that you are using at your site -- that is, forged packets, presumably sent by an attacker.
• Spoof-3 and Spoof-4
• Block packets from the internal network that claim to have source addresses on an external network or the perimeter network. Spoof-3 may be difficult to implement on some packet filtering systems because they can be easily written only if you can use negation on source addresses (to specify addresses that are not in the internal range). It would be acceptable to omit them in this situation; they are mostly there to protect other people, not to protect your site.
• Spoof-5 and Spoof-6
• Block packets from the perimeter network that claim to have source addresses on an external network or the internal network. Spoof-5 may be difficult to implement on some packet filtering systems because they can be easily written only if you can use negation on source addresses (to specify addresses that are not in the internal range). It would be acceptable to omit them in this situation; they are mostly there to protect other people, not to protect your site.
• Cross-1 through Cross-3
• Block packets sent from the outside world to the firewall's internal and perimeter interfaces. These addresses would otherwise be considered legitimate addresses in the ranges for the internal and perimeter networks, and rules that were meant to allow traffic to these networks would also allow the firewall to be attacked on those ports. Rather than excluding the interfaces explicitly for each rule that allows traffic to those networks, we will make a blanket exclusion for traffic that's trying to cross the firewall. Should the perimeter network services host be compromised, there is a rule that prevents it from being used to attack the internal interface of the firewall. (If the internal network is compromised, it can be used to attack the perimeter network; since the internal network is more security-critical than the perimeter network, this is not a major problem, but you could easily add a Cross-4 to prevent it.)
• HTTP-1 through HTTP-4
• Allow incoming HTTP to the perimeter network services host. These rules allow traffic from the Internet to the site's public HTTP service. Because each interface has a separate default deny rule, we need to explicitly permit the traffic on each interface that it crosses. HTTP-1 and HTTP-3 both permit the same incoming traffic, while HTTP-2 and HTTP-4 are both required to permit the responses.
• HTTP-5 through HTTP-8
• Allow outgoing HTTP and HTTPS from the internal services host. These rules allow the HTTP proxy to contact any Internet host on any port. Depending on the HTTP proxy server, this could allow users to circumvent firewall rules preventing direct TCP connections (for example, direct delivery of SMTP mail). Some HTTP proxy servers can be configured to prevent the connection to certain port numbers.
• Telnet-1 through Telnet-4
• Allow outgoing Telnet from any internal host.
• SSH-1 through SSH-4
• Allow outgoing SSH connections from the internal network services host. We have the client port set to "Any" (instead of ">1023" like most of the other protocols) because some forms of authentication require SSH clients to use ports at or below 1023.
• SSH-5 through SSH-8
• Allow incoming SSH connections to the internal network services host. We have the client port set to "Any" (instead of ">1023" like most of the other protocols) because some forms of authentication require SSH clients to use ports at or below 1023.
• SSH-9 through SSH-12
• Allow outgoing SSH connections from the internal network to the perimeter network for administration.
• SMTP-1 through SMTP-4
• Allow electronic mail between the firewall and the internal services host. SMTP-1 and SMTP-2 permit mail to the firewall, while SMTP-3 and SMTP-4 permit mail from the firewall.
• SMTP-5 through SMTP-8
• Allow electronic mail between the firewall and the Internet.
• SMTP-9 and SMTP-10,
• Allow electronic mail only from the perimeter network to the firewall host. We do not allow mail to be delivered to the perimeter network services host.
• NNTP-1 through NNTP-4
• Allow your clients to reach your service provider's news server.
• DNS-1 through DNS-4
• Allow external UDP- and TCP-based DNS clients to query the DNS server on the firewall host, and it to answer them. In the process, they also permit the server-to-server queries, which are always from port 53 to port 53. These rules also allow the DNS server on the firewall host to make DNS queries to the Internet and to support secondary DNS servers to perform zone transfers.
• DNS-5 through DNS-8
• Allow the internal services host to make UDP- and TCP-based DNS queries to the firewall DNS server. The DNS service on the internal services host is configured as a forwarder to the firewall host.
• DNS-9 through DNS-12
• Allow the perimeter network services host to make UDP- and TCP-based DNS queries to the firewall DNS server. The DNS service on the perimeter network services host is configured as a forwarder to the firewall host.
• FTP-1 through FTP-8
• Allow outgoing passive-mode FTP connections. The FTP-1 through FTP-4 rules allow the command channel, and the FTP-5 through FTP-8 rules allow the data channel. In fact, FTP-5 through FTP-8 allow any TCP connection to be opened from the internal machines to any host on the Internet, as long as the port numbers used on both ends are above 1023.
• Default-1 and Default-2
• Block all packets not specifically allowed by one of the preceding rules.

Other Configuration Work

In addition to setting up the packet filtering rules, we need to do various other kinds of configuration work, as follows:

• On all of the internal machines
• Configure electronic mail so that it gets sent to the internal services host. We're also going to need to install passive-mode FTP clients, if they're available, and configure web browsers to use the proxy server on the internal services host.
• On the internal services host
• Configure the mail server to send mail to the firewall. Set up a caching HTTP proxy server. Set up the internal DNS server.
• On the firewall
• Set up the externally visible DNS server.
• On the perimeter services host
• Set up the externally visible web server.

Analysis

Least privilege

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.

Defense in depth

The screened subnet architecture we described earlier in this chapter does a much better job of applying the principle of defense in depth.

Choke point

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.

Weakest link

The screened subnet architecture presents a much stronger weakest link to an attacker.

Fail-safe stance

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.

Universal participation

In terms of the universal participation principle, there really isn't much difference between the first and second sample architectures.

Diversity of defense

Simplicity

Conclusions

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.