 | Chapter 9 Two Sample Firewalls |  |
| Chapter 9 Two Sample Firewalls | |
The screened host architecture, described in Chapter 4 and shown in Figure 9.2, is a lower-security, lower-cost alternative to the screened subnet architecture discussed in the previous sections. The screened host architecture is often used by very small sites that are facing significant cost constraints.
In a screened host architecture, there is no perimeter net, no interior router, and often no bastion host per se. (Obviously, there is a host that the outside world talks to, but this host is often not dedicated solely to that task.) What you have instead is a single router (most analogous to the exterior router in the dual-router screened subnet architecture) and a services host that provides Internet services to internal and external clients (and is often used for other tasks as well).
The router is there to protect and control access to the internal net, and the services host is there to interact with the outside world, much like a bastion host. We call it a services host, rather than a bastion host, because it's often fulfilling many other roles. For example, it's probably the mail server, Usenet news server, and DNS server for the site; it might possibly be a file server, print server, and so on, as well; it might even be the only machine the site has.
In this example, we're going to assume:
That the services host is the site's mail server, news server, and DNS server, but that it's not the only machine at the site.
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.
Also as in the previous example, that you're using proper IP addresses: addresses that have been properly assigned to your site and that are being properly routed and advertised to the rest of the Internet by your service provider.
How do we provide the basic Internet services with a screened host architecture?
Telnet can be safely and conveniently provided through packet filtering. For this example, that's what we're going to do. We've discussed in the previous sections how proxying Telnet is usually too expensive for its benefits in a larger configuration; it's that much sillier here in the screened host architecture. Similarly, providing incoming Telnet is difficult in the larger configuration, and verges on the suicidal here, where compromising the services host instantly compromises the entire network. Therefore, we will not provide incoming Telnet service.
As in the screened subnet architecture, FTP can be safely and conveniently provided via packet filtering if our internal FTP clients support FTP's passive mode. We'll need to set up an FTP proxy server on the services host if we wish to support clients that can't use passive mode. We can support both passive- and normal-mode FTP clients, if needed, but doing so is not as likely at a smaller site. At smaller sites, it's better to do one or the other, rather than try to keep track of both. In this example, we'll do only passive mode.
Be aware that in order to use an FTP proxy server on your services host, your filtering router would have to allow TCP connections from port 20 on external systems to ports above 1023 on your services host. For a regular bastion host, this wouldn't be a problem, because nothing should be using such ports. For a services host that's also serving other purposes, however, that may not be true.
Incoming user FTP goes the same way as incoming Telnet in any configuration. Because we've already decided to deny incoming Telnet, we'll deny incoming user FTP as well.
As we've seen with the screened subnet architecture, incoming anonymous FTP is an acceptable risk when it's going to a bastion host. However, it's not an acceptable risk going to the services host, with confidential data and full access to the internal network right there. We will therefore deny it.
In this architecture, there is probably only one good way to set up SMTP. Incoming mail should be directed (via DNS MX records) to the services host, and outgoing mail should go out via the services host. There really is no feasible alternative. As we've discussed above, 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.
As with SMTP, there is probably only one good way to set up NNTP in the screened host architecture, and that is to make another internal machine a Usenet news server and allow NNTP directly to it. We could, if forced to do so, make the services host a news server. However, it might be better to forgo news altogether, given how much of a load news places on a machine and how critical the services host is.
As we've discussed in the previous example, HTTP can be provided directly via packet filtering or indirectly via a proxy server. However, it makes the most sense to provide HTTP indirectly via a caching proxy server such as the CERN HTTP server. There is one good reason for this: better performance due to caching.
For this example, we're going to assume we're providing HTTP service via a CERN proxy server running on the services host. Once again, we decide to deny service to external clients due to the risks (which are further compounded by the sensitive position of the services host).
As with most of the other services, there is really only one good place to put the DNS server in the screened host architecture: on the services host. For this example, we're going to assume that:
The services host is your primary DNS server.
You have an external DNS secondary server for your domain, e.g., one of your service provider's machines.
You're not going to do any DNS information hiding: you can't if the services host is your internal and external primary server.
Let's look at the packet filtering rules necessary to support the screened host configuration we've described in the previous sections. As in the earlier example of the screened subnet architecture, we're going to assume an "ideal" router. The router needs the following rules to support the configuration we've outlined.
| Direc- | Source | Dest. | Pro- | Source | Dest. | ACK | ||
|---|---|---|---|---|---|---|---|---|
| Rule | tion | Address | Address | tocol | Port | Port | Set | Action |
Spoof | In | Internal | Any | Any | Any | Any | Any | Deny |
Telnet-1 | Out | Internal | Any | TCP | >1023 | 23 | Any | Permit |
Telnet-2 | In | Any | Internal | TCP | 23 | >1023 | Yes | Permit |
FTP-1 | Out | Internal | Any | TCP | >1023 | 21 | Any | Permit |
FTP-2 | In | Any | Internal | TCP | 21 | >1023 | Yes | Permit |
FTP-3 | Out | Internal | Any | TCP | >1023 | >1023 | Any | Permit |
FTP-4 | In | Any | Internal | TCP | >1023 | >1023 | Yes | Permit |
SMTP-1 | Out | Services | Any | TCP | >1023 | 25 | Any | Permit |
SMTP-2 | In | Any | Services | TCP | 25 | >1023 | Yes | Permit |
SMTP-3 | In | Any | Services | TCP | >1023 | 25 | Any | Permit |
SMTP-4 | Out | Services | Any | TCP | 25 | >1023 | Yes | Permit |
NNTP-1 | Out | News server | NNTP feed server | TCP | >1023 | 119 | Any | Permit |
NNTP-2 | In | NNTP feed server | News server | TCP | 119 | >1023 | Yes | Permit |
NNTP-3 | In | NNTP feed server | News server | TCP | >1023 | 119 | Any | Permit |
NNTP-4 | Out | News server | NNTP feed server | TCP | 119 | >1023 | Yes | Permit |
HTTP-1 | Out | Services | Any | TCP | >1023 | Any | Any | Permit |
HTTP-2 | In | Any | Services | TCP | Any | >1023 | Yes | Permit |
DNS-1 | Out | Services | Any | UDP | 53 | 53 | [3] | Permit |
DNS-2 | In | Any | Services | UDP | 53 | 53 | [3] | Permit |
DNS-3 | In | Any | Services | UDP | Any | 53 | [3] | Permit |
DNS-4 | Out | Services | Any | UDP | 53 | Any | [3] | Permit |
DNS-5 | Out | Services | Any | TCP | >1023 | 53 | Any | Permit |
DNS-6 | In | Any | Services | TCP | 53 | >1023 | Yes | Permit |
DNS-7 | In | Any | Services | TCP | >1023 | 53 | Any | Permit |
DNS-8 | Out | Services | Any | TCP | 53 | >1023 | Yes | Permit |
Default-1 | Out | Any | Any | Any | Any | Any | Any | Deny |
Default-2 | In | Any | Any | Any | Any | Any | Any | Deny |
[3] UDP packets do not have ACK bits.
Here is some additional information about each set of rules in this table:
Blocks incoming packets that claim to have internal IP addresses, that is, forged packets, presumably sent by an attacker.
Allow outgoing Telnet connections.
Allow outgoing passive-mode FTP connections. The FTP-1 and FTP-2 rules allow the command channel, and the FTP-3 and FTP-4 rules allow the data channel. In fact, FTP-3 and FTP-4 allow any TCP connection to be opened from the services host to any host on the Internet, as long as the port numbers used on both ends are above 1023.
Allow outgoing mail from the services host to the outside world.
Allow incoming mail from the outside world to the services host.
Allow Usenet news both ways between your news server and your service provider's news server.
Allow the services host HTTP proxy server to connect to the HTTP servers on any machine on the Internet. Actually, these rules allow any TCP client program on the services host using a port above 1023 to contact any server program on any host on the Internet using any port. This is done so that the HTTP proxy server can contact HTTP servers on nonstandard port numbers (i.e., other than port 80). As broad as these rules are, it's important that these rules allow only outgoing connections; they can do this by examining the ACK bit. Note the overlap between these rules and rules FTP-3 and FTP-4; removing either set would still allow both FTP and HTTP clients access to most servers.
Allows UDP-based DNS queries and answers from the services host DNS server to DNS servers in the outside world.
Allows UDP-based DNS queries and answers from Internet DNS servers to the services host DNS server.
Allow external UDP-based DNS clients to query the DNS server on the services host, and it to answer them.
Allow TCP-based DNS queries from the services host to DNS servers on the Internet, as well as answers to those queries. Also allow zone transfers in which the services host DNS server is the secondary server and an external DNS server is the primary server.
Allow TCP-based DNS queries from the outside world to the services host DNS server, as well as answers to those queries. Also allow zone transfers in which the services host DNS server is the primary server and an external DNS server is the secondary server.
Block all packets not specifically allowed by one of the preceding rules.
Just how good a firewall is this? The short answer is, "not very." 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 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.)
On the other hand, having the services host fulfill so many roles (and thus requiring it to have the aggregate set of privileges required for all those roles) is definitely not in accord with the principle of least privilege. The services host has far too much privilege for most of the services it needs to provide.
The screened subnet architecture we described earlier in this chapter does a somewhat better job of applying the principle of least privilege than the screened host architecture described in this section.
The principle of defense in depth is almost completely missing from this setup. Internal hosts are protected from the outside world by the filtering router and the services host, but nothing protects them from the services host if it is compromised. The filtering router and the services host are providing separate protection, not backing each other up. If either one is compromised, the entire site is compromised.
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 of a screened host architecture, because everything between internal clients and the Internet comes through at least the filtering router. Further, much of it comes through the 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 the screened host architecture is the services host. A compromised services host is going to severely affect the security of the rest of the internal hosts, because it's on the same network as these internal hosts and because there is nothing to protect them from it. With the screened subnet architecture, on the other hand, the interior router protects the internal hosts from the bastion host.
Further, because of the multitude of services being provided by the services host, it's more likely an attacker will be able to find a way to break in than with the bastion host in the screened subnet example.
All in all, 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 screened host architecture. In general, the rules specify what you're going to allow, and deny everything else by default. This is a fail-safe approach, 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 screened host architecture itself is not fail-safe. If the services host is compromised, your whole site's security is severely compromised. The screened subnet architecture is much better about this.
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 that 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 screened subnet and screened host 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 router on which to set up filtering and only one services host.
This is another area in which the screened subnet architecture is superior to the screened host architecture.
The screened host architecture may be cheaper to implement than the screened subnet architecture, but it's much less secure. There is little or no redundancy in the design, and it's not really fail-safe. Even so, it is providing fewer services than the screened subnet architecture, and it can't increase either the security or the services.
To do a screened host architecture right, you pretty much need to dedicate a machine to being the services host and nothing else; you essentially need a bastion host. At that point, if you compare the equipment between a screened subnet architecture and a screened host architecture, you see that the only difference in equipment is either:
For a two-router screened subnet architecture - a second router.
For a one-router screened subnet architecture - a third interface on your single router.
The cost of a suitable second router really isn't that much: a couple of thousand dollars. The cost of an additional interface for a router is often much less: a few hundred dollars difference in price between a two-interface and a three-interface model of the same router. The incremental cost might actually be nothing if you already have a suitable spare PC lying around, and if you can use one of the PC-based filtering packages freely available off the Internet (such as Drawbridge or KarlBridge, described in Appendix B, Tools).
The difference between the screened subnet architecture and the screened host architecture is gigantic in terms of security, scalability, and services. You can't reasonably offer inbound services of even the most limited type in a screened host architecture. You can't increase anything, even the number of supportable machines, without making an architecture change.
|  | |
| 9.1 Screened Subnet Architecture |  | 10. Authentication and Inbound Services |