9.2.1.1 Telnet

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.

9.2.1.2 FTP

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.

9.2.1.3 SMTP

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.

9.2.1.4 NNTP

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.

9.2.1.5 HTTP

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

9.2.1.6 DNS

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.

9.2.3.1 Least privilege

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.

9.2.3.2 Defense in depth

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.

9.2.3.3 Choke point

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.

9.2.3.4 Weakest link

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.

9.2.3.5 Fail-safe stance

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.

9.2.3.6 Universal participation

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.

9.2.3.7 Diversity of defense

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.