The merged interior and exterior router architecture, described in Chapter 6, 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.
This 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:
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.
How do we provide the basic Internet services with this architecture?
We have several options for providing internal users with access to the Web:
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.
As we discussed earlier, using packet filtering means either limiting the servers that people can access or permitting almost all outbound connections. It's an acceptable choice but places a lot of trust in the users. Running a simple proxy server, like SOCKS, on the firewall itself would give us extra logging and control without significantly limiting what users can do or putting a large load on the firewall. Running a caching proxy server on the firewall itself would probably be a mistake. Caching proxy servers are relatively complex, and they require disk space for the caching. However, caching proxy servers provide a lot of benefits, and we could safely put one on the internal services host.
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.
Here 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.
We 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.
We 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.
As 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.
At 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.
Because 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:
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.
Let'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:
Rule | Interface | RelativeDir. | Source Address | Dest. Address | Protocol | SourcePort | Dest.Port | ACKSet | Action |
|---|---|---|---|---|---|---|---|---|---|
Spoof-1 | Ext | Inward | Internal | Any | Any | Any | Any | Any | Deny |
Spoof-2 | Ext | Inward | Perimeter Net | Any | Any | Any | Any | Any | Deny |
Spoof-3 | Int | Inward | External | Any | Any | Any | Any | Any | Deny |
Spoof-4 | Int | Inward | Perimeter Net | Any | Any | Any | Any | Any | Deny |
Spoof-5 | Pmtr | Inward | External | Any | Any | Any | Any | Any | Deny |
Spoof-6 | Pmtr | Inward | Internal | Any | Any | Any | Any | Any | Deny |
Cross-1 | Ext | Inward | Any | Firewall Int | Any | Any | Any | Any | Deny |
Cross-2 | Ext | Inward | Any | Firewall Pmtr | Any | Any | Any | Any | Deny |
Cross-3 | Pmtr | Inward | Any | Firewall Int | Any | Any | Any | Any | Deny |
HTTP-1 | Ext | Inward | Any | Pmtr Services | TCP | >1023 | 80 | Any | Permit |
HTTP-2 | Ext | Outward | Pmtr Services | Any | TCP | 80 | >1023 | Yes | Permit |
HTTP-3 | Pmtr | Outward | Pmtr Services | Any | TCP | >1023 | 80 | Any | Permit |
HTTP-4 | Pmtr | Inward | Any | Pmtr Services | TCP | 80 | >1023 | Yes | Permit |
HTTP-5 | Int | Inward | Int Services | Any | TCP | >1023 | Any | Any | Permit |
HTTP-6 | Int | Outward | Any | Int Services | TCP | Any | >1023 | Yes | Permit |
HTTP-7 | Ext | Outward | Int Services | Any | TCP | >1023 | Any | Any | Permit |
HTTP-8 | Ext | Inward | Any | Int Services | TCP | Any | >1023 | Yes | Permit |
Telnet-1 | Int | Inward | Internal | Any | TCP | >1023 | 23 | Any | Permit |
Telnet-2 | Int | Outward | Any | Internal | TCP | 23 | >1023 | Yes | Permit |
Telnet-3 | Ext | Outward | Internal | Any | TCP | >1023 | 23 | Any | Permit |
Telnet-4 | Ext | Inward | Any | Internal | TCP | 23 | >1023 | Yes | Permit |
SSH-1 | Int | Inward | Int Services | Any | TCP | Any | 22 | Any | Permit |
SSH-2 | Int | Outward | Any | Int Services | TCP | 22 | Any | Yes | Permit |
SSH-3 | Ext | Outward | Int Services | Any | TCP | Any | 22 | Any | Permit |
SSH-4 | Ext | Inward | Any | Int Services | TCP | 22 | Any | Yes | Permit |
SSH-5 | Ext | Inward | Any | Int Services | TCP | Any | 22 | Any | Permit |
SSH-6 | Ext | Outward | Int Services | Any | TCP | 22 | Any | Yes | Permit |
SSH-7 | Int | Outward | Any | Int Services | TCP | Any | 22 | Any | Permit |
SSH-8 | Int | Inward | Int Services | Any | TCP | 22 | Any | Yes | Permit |
SSH-9 | Int | Inward | Internal | Pmtr Services | TCP | Any | 22 | Any | Permit |
SSH-10 | Int | Outward | Pmtr Services | Internal | TCP | 22 | Any | Yes | Permit |
SSH-11 | Pmtr | Outward | Internal | Pmtr Services | TCP | ANY | 22 | Any | Permit |
SSH-12 | Pmtr | Inward | Pmtr Services | Internal | TCP | 22 | Any | Yes | Permit |
SMTP-1 | Int | Inward | Int Services | Firewall Int | TCP | >1023 | 25 | Any | Permit |
SMTP-2 | Int | Outward | Firewall Int | Int Services | TCP | 25 | >1023 | Yes | Permit |
SMTP-3 | Int | Outward | Firewall Int | Int Services | TCP | >1023 | 25 | Any | Permit |
SMTP-4 | Int | Inward | Int Services | Firewall Int | TCP | 25 | >1023 | Yes | Permit |
SMTP-5 | Ext | Outward | Firewall Ext | Any | TCP | >1023 | 25 | Any | Permit |
SMTP-6 | Ext | Inward | Any | Firewall Ext | TCP | 25 | >1023 | Yes | Permit |
SMTP-7 | Ext | Inward | Any | Firewall Ext | TCP | >1023 | 25 | Any | Permit |
SMTP-8 | Ext | Outward | Firewall Ext | Any | TCP | 25 | >1023 | Yes | Permit |
SMTP-9 | Pmtr | Inward | Pmtr Services | Firewall Pmtr | TCP | >1023 | 25 | Any | Permit |
SMTP-10 | Pmtr | Outward | Firewall Pmtr | Pmtr Services | TCP | 25 | >1023 | Yes | Permit |
NNTP-1 | Int | Inward | Internal | NNTP server | TCP | >1023 | 119 | Any | Permit |
NNTP-2 | Int | Outward | NNTP server | Internal | TCP | 119 | >1023 | Yes | Permit |
NNTP-3 | Ext | Outward | Internal | NNTP server | TCP | >1023 | 119 | Any | Permit |
NNTP-4 | Ext | Inward | NNTP server | Internal | TCP | 119 | >1023 | Yes | Permit |
DNS-1 | Ext | Inward | Any | Firewall Ext | UDP | Any | 53 | [7] | Permit |
DNS-2 | Ext | Outward | Firewall Ext | Any | UDP | 53 | Any | [7] | Permit |
DNS-3 | Ext | Inward | Any | Firewall Ext | TCP | Any | 53 | Any | Permit |
DNS-4 | Ext | Outward | Firewall Ext | Any | TCP | 53 | Any | Yes | Permit |
DNS-5 | Int | Inward | Int Services | Firewall Int | UDP | Any | 53 | [7] | Permit |
DNS-6 | Int | Outward | Firewall Int | Int Services | UDP | 53 | Any | [7] | Permit |
DNS-7 | Int | Inward | Int Services | Firewall Int | TCP | Any | 53 | Any | Permit |
DNS-8 | Int | Outward | Firewall Int | Int Services | TCP | 53 | Any | Yes | Permit |
DNS-9 | Pmtr | Inward | Pmtr Services | Firewall Pmtr | UDP | Any | 53 | [7] | Permit |
DNS-10 | Pmtr | Outward | Firewall Pmtr | Pmtr Services | UDP | 53 | Any | [7] | Permit |
DNS-11 | Pmtr | Inward | Pmtr Services | Firewall Pmtr | TCP | Any | 53 | Any | Permit |
DNS-12 | Pmtr | Outward | Firewall Pmtr | Pmtr Services | TCP | 53 | Any | Yes | Permit |
FTP-1 | Int | Inward | Internal | Any | TCP | >1023 | 21 | Any | Permit |
FTP-2 | Int | Outward | Any | Internal | TCP | 21 | >1023 | Yes | Permit |
FTP-3 | Ext | Outward | Internal | Any | TCP | >1023 | 21 | Any | Permit |
FTP-4 | Ext | Inward | Any | Internal | TCP | 21 | >1023 | Yes | Permit |
FTP-5 | Int | Inward | Internal | Any | TCP | >1023 | >1023 | Any | Permit |
FTP-6 | Int | Outward | Any | Internal | TCP | >1023 | >1023 | Yes | Permit |
FTP-7 | Ext | Outward | Internal | Any | TCP | >1023 | >1023 | Any | Permit |
FTP-8 | Ext | Inward | Any | Internal | TCP | >1023 | >1023 | Yes | Permit |
Default-1 | All | Outward | Any | Any | Any | Any | Any | Any | Deny |
Default-2 | All | Inward | Any | Any | Any | Any | Any | Any | Deny |
[7] 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.
If 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:
- 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.
Just 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, and in comparison to the screened subnet architecture we configured in the first example.
You 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.
The 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.
The 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.
The 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.
You 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.
If 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.
There 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.
Although 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.
The 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.