 | Chapter 9 |  |
| Chapter 9 | |
In this chapter, we describe two sample configurations for basic firewalls. Almost any real firewall is going to be more complex than those described in this chapter, but this presentation should give you some idea of the tasks involved in building a firewall and how the various pieces fit together.
NOTE: We want to emphasize that these examples are just that: examples. You shouldn't blindly implement one of these examples, without first taking the time to understand your own needs, your environment, and the implications and complications of the services you want your firewall to provide.
The services that we're going to provide through these sample firewalls are just the basics: terminal access, file transfer, electronic mail, Usenet news, the World Wide Web, and DNS. See Chapter 8, Configuring Internet Services for a full discussion of these and other services.
The screened subnet architecture, described in Chapter 4, Firewall Design and shown in Figure 9.1, is probably the most common do-it-yourself firewall architecture. This architecture provides good security (including multiple layers of redundancy) at what most sites feel is a reasonable cost.
There are two-router and single-router variations of the screened subnet architecture. Basically, you can use either a pair of two-interface routers or a single three-interface router. The single-router screened subnet architecture works about as well as the two-router screened subnet architecture, and is often somewhat cheaper. However, you need to use a router that can handle both inbound and outbound packet filtering on each interface. (See the discussion of this point in Chapter 6, Packet Filtering.) We're going to use a two-router architecture as our example in this section because it is conceptually simpler.
The components of this type of firewall include the following:
Perimeter network
Exterior router
Interior router
Bastion host
Let's review briefly the purposes of these various components, presented originally in Chapter 4.
Isolates your bastion host from your internal network, so a security breach on the bastion host won't immediately affect your internal network.
Connects your site to the outside world. If possible, the exterior router also provides at least some protection for the bastion host, interior router, and internal network. (This isn't always possible, because some sites use exterior routers that are managed by their network service providers and are therefore beyond the site's control.)
Protects the internal network from the world and from the site's own bastion host.
Serves as the site's main point of contact with the outside world. (It should be set up according to the guidelines in Chapter 5, Bastion Hosts.)
In addition to the machines that make up the firewall itself, assume there are machines on the internal network (internal hosts) that fulfill the following roles. (Note that any given internal machine might fill any, or even all, of these roles.)
Mail server
Usenet news server
DNS server
Client for various Internet services
Each of these internal services is provided directly (via packet filtering) or indirectly (via proxy servers running on the bastion host).
We're going to assume (at least for the purposes of this example) that internal users in our system are trusted not to actively try to circumvent the firewall, and that there is no particular need to monitor or log their Internet activities.
We're also going to assume that you are using properly assigned and routed IP addresses (that is, addresses assigned to your site, and properly routed and advertised to the rest of the Internet by your service provider) for your internal and perimeter networks. If you aren't, you have no choice but to use proxies, because you can't allow packets with those unassigned IP addresses out onto the Internet; even if you did, replies would have no way to come back to you.
Finally, we're going to assume you're using separate network numbers for your perimeter net and internal net, so that you can detect forged packets easily. (See the discussion in "Risks of Filtering by Source Address" in Chapter 6.)
Given the architecture we've just described, how do we provide the basic Internet services?
Outgoing Telnet could be provided through packet filtering or through proxies. Which approach should we use?
Proxying will require either modified clients or modified user procedures; either one will be tedious to implement for somebody. Proxying would allow us to restrict or monitor Telnet usage by user by forcing our users to authenticate to a proxy server before completing their requests. However, remember that we have decided to assume internal users are trustworthy, so there is no need for authentication. Proxying would be necessary if we were using unassigned or unadvertised IP addresses internally, but that's not the case here, either. Because we have trustworthy users and proper IP addresses, proxying for Telnet doesn't provide any advantage over packet filtering, and it's more difficult to set up and maintain. Therefore, for this example we're going to provide outgoing Telnet via packet filtering.
Incoming Telnet is considerably more difficult to provide safely and conveniently. If it were necessary, incoming Telnet could be provided on the bastion host using extra authentication. However, for a site that is looking for a simple configuration, the reasonable thing to do is to disallow incoming Telnet altogether. That's what we'll do for this example.
Unlike Telnet, FTP doesn't lend itself to a pure packet filtering solution. Because normal mode FTP requires an incoming connection to an arbitrary port over 1023, trying to allow it without doing anything else gives attackers access to all kinds of services running on our internal systems. That leaves us two choices:
Support passive mode via packet filtering
Support normal mode via proxies
In either case, the standard FTP clients shipped with UNIX operating systems, and most of the popular, publicly available clients for personal computers, won't work the normal way. If we use the TIS FWTK ftp-gw proxy gateway (described in Chapter 7, Proxy Systems), we can use unmodified clients, but at the cost of teaching the users to follow special procedures. Some popular FTP clients - the ones built in to Web browsers like Netscape Navigator or Mosaic - do use passive mode without being modified, but then again, not all servers support it well.
A reasonable compromise would be to use packet filtering and proxies, using a proxying gateway like ftp-gw from the TIS FWTK that doesn't require modification of the clients. Clients that support passive mode will work via the packet filters. On platforms where we can easily replace the provided clients, we can provide passive mode clients; on platforms where we can't easily replace the clients, we can modify user procedures.
As we've said, if we wanted to monitor FTP usage, or if we were using an unassigned or unrouted network number, we'd have to do exclusively proxying, but that's not the case here. We also might want to use proxying exclusively if we decided to hide DNS data - it would save us the trouble of faking data for double-reverse lookups - but hiding DNS data is more trouble than it's worth. In a situation where proxying is used exclusively, we'd have to reconsider which proxy server to use. Requiring users to modify their procedures makes sense here, because there are no other options. The balance might come out differently if everybody were proxying.
Be aware that in order to use the TIS FWTK ftp-gw proxy server on your bastion host, your packet filtering will have to allow TCP connections from ports above 1023 on your bastion host to ports above 1023 on internal hosts, and from port 20 on external hosts to ports above 1023 on your bastion host, for FTP data channels. (See the discussion of FTP in Chapter 8.) This means that someone who breaks in to the bastion host could easily connect to any server on any internal host that uses a TCP port above 1023 (for example, an X11 server on port 6000). Further, any servers that are using such ports (that is, TCP ports above 1023) on the bastion host itself are also vulnerable. For this reason, if you allow these FTP data connections at all for proxying, you probably want to explicitly block access to internal systems to TCP ports above 1023 where you know, or have good cause to suspect, that servers might be listening. At the very least, such ports probably include 6000 through around 6003 (assuming four or fewer real or virtual X11 servers per machine; see the discussion of X11 in Chapter 8).
Keep in mind, however, that blocking specific ports, rather than blocking all ports by default and then allowing specific ports, is generally a dangerous strategy. It's hard to develop and maintain a complete list of ports that need to be blocked at your site. It would be better to block everything by default and then allow only specific ports, but you can't do that with standard (nonpassive) FTP, because of the way it works.
Allowing passive-mode FTP with packet filtering is a fairly liberal approach, because it allows pretty much any connection to go through as long as it is initiated by the inside. The number of servers above port 1023 is very large. This has some advantages (it lets users access nonstandard HTTP servers, for example), but it may also allow users to access all kinds of services that are unsafe. In allowing it, we're assuming that our users are not only well-intentioned, they're also capable of telling the difference between a safe and an unsafe connection, or at least avoiding the temptation to do unexpected things.
Because we've denied incoming Telnet, it makes sense to deny incoming user FTP as well. Both services require approximately the same security measures, and making one of them available would make configuring the other trivial.
Incoming anonymous FTP is a different matter, and we'll provide it. Because we're not a major Internet service provider, and because we're using the TIS FWTK already anyway, we can go for security over features and use the TIS FWTK anonymous FTP server. If we were going to provide major anonymous FTP, we'd probably want to use the more feature-filled wuarchive FTP server (see Chapter 8 for a description of its capabilities), and run it on a machine that was not the main bastion host but that was still a bastion host on the perimeter network.
There aren't many options for SMTP in any configuration. We want all external SMTP connections to go to a single machine with a secured SMTP server, and we don't trust random internal machines to have safe SMTP servers. That means we'll put a secured SMTP server on the bastion host and use DNS MX records to direct all incoming mail to the bastion host, which will then pass all the incoming mail to a single internal secured SMTP server.
What other options do we have? We could put a secure SMTP server on the internal mail server and direct incoming mail to it, but if that SMTP server were compromised, the entire internal net would then be at risk. Alternatively, we could have the bastion host send mail directly to machines on the internal network, but once again, we'd be increasing our vulnerability if the SMTP server on the bastion host were compromised. The compromised bastion host would be speaking to untrustworthy internal SMTP servers, and compromise of the internal net would quickly follow. If the bastion host can speak only to the internal mail server, that narrows the possible attacks it can make; the internal mail server can run a secured SMTP server. Furthermore, by making this choice, messy maintenance tasks are transferred from the security-critical bastion host to the less vulnerable internal mail server.
How about outgoing mail? It would probably be safe to allow internal machines to send mail directly to the outside world, but doing so creates a maintenance headache. (You have to watch the mail configuration on all the internal machines.) Besides, doing this opens another direct connection between the internal and external networks. There aren't any known ways for an SMTP server to attack an SMTP client, but stranger things have happened.
Allowing internal machines to send mail directly to the outside world doesn't seem to bring much advantage either. The only difference it makes is that we'd be able to send mail (but not receive it) when the bastion host is down.
No matter what decision we make, we'll have to configure our mail clients. (Unlike FTP and Telnet, SMTP does not work as installed without modifying configuration files.) In addition, the work to direct the mail to a server is less than the work to correctly send it to the external universe.
The only real question is whether to direct the outgoing mail from the internal machines to the internal mail server or to the bastion host. Directing it to the internal mail server has the same advantages for incoming mail, but the advantages are much smaller. Sending outgoing mail presents little risk to start with, so reducing the risk isn't worth much. Sending outgoing mail also doesn't involve configurations that change often enough to make it worrisome to maintain the bastion host. On the other hand, the cost of going through the internal mail server - in complexity, possible points of failure, and delay - is just as high for outgoing mail as for incoming mail. It no longer looks like an attractive bargain, so we'll direct the outgoing mail to the bastion host without using the internal mail server as an intermediary.
We'll set up SMTP, as outlined in Chapter 8, with the bastion host acting as a middleman for incoming and outgoing mail. Here's what to do:
Publish DNS MX records that direct incoming mail for the site to the bastion host.
Configure internal machines to send all outgoing mail to the bastion host.
Configure the bastion host to send all incoming mail to a single internal mail server and to send outgoing mail directly to destination machines.
For this example, we're going to assume there is a single internal mail server for incoming mail, and that internal machines send their outgoing mail directly to the bastion host (rather than indirectly via the mail server).
As we've discussed in Chapter 8, the most practical way to set up NNTP across a firewall is to allow your NNTP service provider(s) to talk directly to your internal Usenet news host, and vice versa. We'd need an overwhelming reason to do something else, and it's hard to imagine one. Even if we didn't have an existing internal news host, building one isn't any harder than building a news server on the bastion host, and it's safer by a vast margin. News servers fail with dreary regularity; while the problems usually aren't security-related, you still don't want to install anything high-maintenance on a bastion host.
For this example, we're going to assume a single external NNTP newsfeed.
As with the other services, for HTTP we can use either packet filtering or proxy servers to provide service to internal clients. Packet filtering will allow our users to access HTTP servers only on standard ports; proxying will allow them to reach all HTTP servers. Which approach should we take?
For Telnet and FTP, the major drawback of proxying was that it required special clients; for HTTP, though, standard browsers support HTTP proxying. Proxying will increase configuration overhead, but that price seems fair for the increased abilities it offers. On the other hand, we've already decided to allow internal hosts to create outgoing connections to any port at or above 1024 in order to allow passive-mode FTP directly from internal hosts to external hosts. That will allow access to almost any HTTP server (any one using a port at or above 1024, anyway). Using pure packet filtering would lose us only HTTP servers at nonstandard ports below 1024, and those ports are all supposed to be reserved anyway.
If we use the CERN HTTP server as our proxy server, the server can also cache Web pages. Doing so can significantly improve performance for all of the following:
They obtain pages from the cache over the internal network, rather than from the original server over our Internet connection, which is probably much slower.
The HTTP clients won't be using so much of the bandwidth of our Internet connection.
They will only get one request from our site for a given page, rather than multiple requests.
The CERN server will also allow us to provide HTTP service to external sites, so we'll take advantage of that to publish our site's own public WWW pages.
HTTP proxying is also trivial to add once you have other things proxied via SOCKS or TIS FWTK. If we had SOCKS running, it would be very tempting to simply proxy through it, because SOCKS is one of the systems that many of the browsers support. All of the proxy servers we've already decided to run are part of the TIS FWTK, however, and we'd have to install SOCKS just for HTTP if we wanted to use it. If we used the TIS FWTK HTTP proxy, we'd have to get the users to modify URLs they use. In this case, the proxy servers wouldn't be able to cut and paste out of their electronic mail when people tell them about cool new things. Neither SOCKS nor TIS FWTK makes an attractive option in this situation.
However, both proxying (through the CERN server) and packet filtering appear to be attractive and reasonable choices. Proxying would definitely be preferable if we weren't already providing passive-mode FTP directly (which gives our users the ability to talk to servers on any TCP port above 1023). On the other hand, packet filtering would definitely be preferable if we wanted to use clients that didn't come with built-in support for proxying, or if we wanted not to provide an HTTP server and had no other services being proxied.
For this example, we're going to assume that we're providing HTTP service to internal clients via a CERN proxy server running on the bastion host, and that we're using the same server to publish our public WWW pages to the world.
As discussed in Chapter 8, DNS across a firewall is best provided with a pair of servers: one on the bastion host, the other on an internal host. Like NNTP, DNS presents a situation in which the number of rational solutions is clearly limited. We need to decide whether to use separate internal and external servers to do information hiding, or whether we should allow the external world to see all of our host data. By deciding to allow direct passive-mode FTP, we've already made that decision indirectly. Direct passive-mode FTP would require intricate DNS setup to support information hiding and still provide valid data for the internal hosts that are FTP clients.
For this example, we're going to assume the DNS server on the bastion host is a secondary server for our domain, and the primary server is on an internal host. We're not going to do any DNS information hiding.
Based on the configuration decisions we've made in the previous sections, let's look at the packet filtering rules necessary to support this configuration. We assume an "ideal" router (as discussed in "Choosing a Packet Filtering Router" in Chapter 6). If our router were less than ideal in terms of capabilities, we'd need to modify these rules accordingly, probably at the cost of security. We might have to rethink several crucial decisions entirely. For example, if we couldn't filter on the ACK bit, direct outbound passive-mode FTP would no longer be acceptably safe, and a lot of our other decisions have used that as a major factor. (See Chapter 6 for a full discussion of packet filtering capabilities, and the implications of not having particular capabilities.)
In the packet filtering rules presented below, we assume that the filtering system:
Can distinguish between incoming and outgoing packets
Can filter on source address, destination address, packet type (TCP or UDP), source port, and destination port
Can filter on whether or not the ACK bit is set (for TCP packets)
Applies rules in the order listed
The purpose of the interior router is to protect the internal network from the Internet and from your own bastion host. The interior router needs the following rules to support the outlined configuration. Explanations of each rule follow the table.
| 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 |
FTP-5 | Out | Internal | Bastion | TCP | >1023 | 21 | Any | Permit |
FTP-6 | In | Bastion | Internal | TCP | 21 | >1023 | Yes | Permit |
FTP-7 | In | Bastion | Internal | TCP | Any | 6000-6003 | Any | Deny |
FTP-8 | In | Bastion | Internal | TCP | >1023 | >1023 | Any | Permit |
FTP-9 | Out | Internal | Bastion | TCP | >1023 | >1023 | Yes | Permit |
SMTP-1 | Out | Internal | Bastion | TCP | >1023 | 25 | Any | Permit |
SMTP-2 | In | Bastion | Internal | TCP | 25 | >1023 | Yes | Permit |
SMTP-3 | In | Bastion | Internal SMTP server | TCP | >1023 | 25 | Any | Permit |
SMTP-4 | Out | Internal SMTP server | Bastion | TCP | 25 | >1023 | Yes | Permit |
NNTP-1 | Out | Internal NNTP server | NNTP feed server | TCP | >1023 | 119 | Any | Permit |
NNTP-2 | In | NNTP feed server | Internal NNTP server | TCP | 119 | >1023 | Yes | Permit |
NNTP-3 | In | NNTP feed server | Internal NNTP server | TCP | >1023 | 119 | Any | Permit |
NNTP-4 | Out | Internal NNTP server | NNTP feed server | TCP | 119 | >1023 | Yes | Permit |
HTTP-1 | Out | Internal | Bastion | TCP | >1023 | 80 | Any | Permit |
HTTP-2 | In | Bastion | Internal | TCP | 80 | >1023 | Yes | Permit |
DNS-1 | Out | Internal DNS server | Bastion | UDP | 53 | 53 | [1] | Permit |
DNS-2 | In | Bastion | Internal DNS server | UDP | 53 | 53 | [1] | Permit |
DNS-3 | Out | Internal DNS server | Bastion | TCP | >1023 | 53 | Any | Permit |
DNS-4 | In | Bastion | Internal DNS server | TCP | 53 | >1023 | Yes | Permit |
DNS-5 | In | Bastion | Internal DNS server | TCP | >1023 | 53 | Any | Permit |
DNS-6 | Out | Internal DNS server | Bastion | 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 |
[1] 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 connections to FTP servers, for use by passive-mode internal clients that are interacting with those servers directly.
Allow the FTP data channel connections from passive-mode internal clients to external FTP servers. Note that these rules actually allow all connections from internal TCP ports above 1023 to external TCP ports above 1023. That may be more than you want to allow, but there's no way to cover passive-mode FTP with anything less broad, and connections are at least restricted to those opened from the inside.
Allow normal (nonpassive-mode) internal FTP clients to open an FTP command channel to the proxy FTP server on the bastion host. Note that these rules are actually redundant if you have rules FTP-1 and FTP-2 in place earlier in the list, because "Bastion" as a source or destination (covered by rules FTP-5 and FTP-6) is a subset of "All" (covered by rules FTP-1 and FTP-2). Having these redundant rules is going to impose a slight performance cost, but makes the rule set easier to understand. It also makes it possible to change rules FTP-1 and FTP-2 (e.g., if you decide you don't want to support passive-mode clients) without accidentally breaking normal-mode client access to the proxy server.
Allow FTP data connections from the proxy server on the bastion host to nonpassive internal clients. The FTP-7 rule prevents an attacker who has gained access to the bastion host from attacking internal X11 servers via the hole created by rules FTP-8 and FTP-9. If you have other servers internally listening for connections on TCP ports above 1023, you should add similar rules for them. Note that trying to list things that should be denied (as in rule FTP-7) is generally a losing proposition, because your list will almost always be incomplete somehow (e.g., because you overlooked or didn't know about some internal service, or because the service was added after the filters were established). However, it's the best you can do in this situation to support normal-mode FTP clients.
Allow outgoing mail from internal hosts to the bastion host.
Allow incoming mail from the bastion host to your internal mail server.
Allow outgoing Usenet news from your news server to your service provider's news server.
Allow incoming Usenet news from your service provider's news server to your news server.
Allow internal HTTP clients to connect to the HTTP proxy server on your bastion host.
Allows UDP-based DNS queries and answers from the internal DNS server to the bastion host DNS server.
Allows UDP-based DNS queries and answers from the bastion host DNS server to the internal DNS server.
Allow TCP-based DNS queries from the bastion host DNS server to the internal DNS server, as well as answers to those queries. Also allow zone transfers in which the bastion host DNS server is the secondary server and the internal DNS server is the primary server.
Allow TCP-based DNS queries from the internal DNS server to the bastion host DNS servers, as well as answers to those queries. Also allow zone transfers in which the bastion host DNS server is the primary server and the internal DNS server is the secondary server.
Block all packets not specifically allowed by one of the preceding rules.
How you translate these abstract rules into specific rules for your particular filtering system depends on the syntax used by your system. Some systems allow you to enter the rules as a single table, much as we show here in this table. Other systems require you to specify rules for incoming and outgoing packets in separate rule sets. Splitting these rules between incoming and outgoing packets is not a problem, as long as you preserve the order for rules of each type; that is, as long as all the incoming rules stay in the same order relative to each other, and all the outgoing rules stay in the same order relative to each other.
The purpose of the exterior router is twofold:
To connect the perimeter net (and thus your site) to the outside world
To protect the perimeter net and the internal net against the outside world
In many circumstances, only the former purpose is possible, because the exterior router is often provided and managed by your network service provider. That provider may be unable or unwilling to set up and maintain packet filtering rules on the exterior router (and unable or unwilling to let you do it yourself).
If you can set up filtering on the exterior router, it's a good idea to do so. If nothing else, this can serve as a backup to some of the filtering on the interior router. For this example, you would need to establish the following rules:
| Direc- | Source | Dest. | Pro- | Source | Dest. | ACK | ||
|---|---|---|---|---|---|---|---|---|
| Rule | tion | Address | Address | tocol | Port | Port | Set | Action |
Spoof-1 | In | Internal | Any | Any | Any | Any | Any | Deny |
Spoof-2 | In | Perim. | 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 |
FTP-5 | Out | Bastion | Any | TCP | >1023 | 21 | Any | Permit |
FTP-6 | In | Any | Bastion | TCP | 21 | >1023 | Yes | Permit |
FTP-7 | In | Any | Bastion | TCP | 20 | 6000-6003 | Any | Deny |
FTP-8 | In | Any | Bastion | TCP | 20 | >1023 | Any | Permit |
FTP-9 | Out | Bastion | Any | TCP | >1023 | 20 | Yes | Permit |
FTP-10 | In | Any | Bastion | TCP | >1023 | 21 | Any | Permit |
FTP-11 | Out | Bastion | Any | TCP | 21 | >1023 | Yes | Permit |
FTP-12 | Out | Bastion | Any | TCP | 20 | >1023 | Any | Permit |
FTP-13 | In | Any | Bastion | TCP | >1023 | 20 | Yes | Permit |
FTP-14 | In | Any | Bastion | TCP | >1023 | >1023 | Any | Permit |
FTP-15 | Out | Bastion | Any | TCP | >1023 | >1023 | Any | Permit |
SMTP-1 | Out | Bastion | Any | TCP | >1023 | 25 | Any | Permit |
SMTP-2 | In | Any | Bastion | TCP | 25 | >1023 | Yes | Permit |
SMTP-3 | In | Any | Bastion | TCP | >1023 | 25 | Any | Permit |
SMTP-4 | Out | Bastion | Any | TCP | 25 | >1023 | Yes | Permit |
NNTP-1 | Out | Internal NNTP server | NNTP feed server | TCP | >1023 | 119 | Any | Permit |
NNTP-2 | In | NNTP feed server | Internal NNTP server | TCP | 119 | >1023 | Yes | Permit |
NNTP-3 | In | NNTP feed server | Internal NNTP server | TCP | >1023 | 119 | Any | Permit |
NNTP-4 | Out | Internal NNTP server | NNTP feed server | TCP | 119 | >1023 | Yes | Permit |
HTTP-1 | Out | Bastion | Any | TCP | >1023 | Any | Any | Permit |
HTTP-2 | In | Any | Bastion | TCP | Any | >1023 | Yes | Permit |
HTTP-3 | In | Any | Bastion | TCP | >1023 | 80 | Any | Permit |
HTTP-4 | Out | Bastion | Any | TCP | 80 | >1023 | Yes | Permit |
DNS-1 | Out | Bastion | Any | UDP | 53 | 53 | [2] | Permit |
DNS-2 | In | Any | Bastion | UDP | 53 | 53 | [2] | Permit |
DNS-3 | In | Any | Bastion | UDP | Any | 53 | [2] | Permit |
DNS-4 | Out | Bastion | Any | UDP | 53 | Any | [2] | Permit |
DNS-5 | Out | Bastion | Any | TCP | >1023 | 53 | Any | Permit |
DNS-6 | In | Any | Bastion | TCP | 53 | >1023 | Yes | Permit |
DNS-7 | In | Any | Bastion | TCP | >1023 | 53 | Any | Permit |
DNS-8 | Out | Bastion | 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 |
[2] UDP packets do not have ACK bits.
Here is some additional information about each set of rules in this table.
Block incoming packets that claim to have internal or perimeter net IP addresses - that is, forged packets presumably sent by an attacker. Rule Spoof-1 is the same as the Spoof rule on the interior router; rule Spoof-2 is unique to the exterior router.
Allow outgoing Telnet connections. These are identical to the corresponding rules on the interior router (as are all rules on the exterior router that involve internal and external hosts, but nothing on the perimeter net).
Allow outgoing passive-mode FTP connections and are identical to the corresponding rules on the interior router.
Allow the FTP proxy server on the bastion host to open an FTP command channel to FTP servers on the Internet. Note that, unlike the corresponding rules on the interior router, these rules are not redundant if you have rules FTP-1 and FTP-2 in place earlier in the list. Why? Because "Bastion" as a source or destination (covered by rules FTP-5 and FTP-6) is not a subset of "Internal" (covered by rules FTP-1 and FTP-2).
Allow FTP data connections from external FTP servers to the proxy server on the bastion host. The FTP-7 rule prevents an attacker from attacking X11 servers on the bastion host via the hole created by rules FTP-8 and FTP-9. If you have other servers on the bastion host listening for connections on TCP ports above 1023, you should add similar rules for them. Note that trying to list things that should be denied (as in rule FTP-7) is a losing proposition, because your list will almost always be incomplete, e.g., because you overlooked or didn't know about some service, or because the service was added after the filters were established. However, it's the best you can do in this situation, if you must support normal-mode FTP.
Allow passive- and normal-mode FTP from external clients to the anonymous FTP server on the bastion host. There are no equivalent rules on the internal router because there are no FTP servers on the internal network that external clients can access.
Allow outgoing mail from the bastion host to the outside world.
Allow incoming mail from the outside world to the bastion host.
Allow Usenet news both ways between your Usenet news server and your service provider's news server. These rules are identical to the corresponding rules on the interior router.
Allow the bastion 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 bastion 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 they allow only outgoing connections, by examining the ACK bit.
Allow external clients to contact the bastion host HTTP server. There are no equivalent rules on the internal router because there are no HTTP servers on the internal network that external clients can access.
Allows UDP-based DNS queries and answers from the bastion host DNS server to DNS servers in the outside world.
Allows UDP-based DNS queries and answers from Internet DNS servers to the bastion host DNS server. Note that rule DNS-2 (which allows server-to-server communication) is redundant if rule DNS-3 (which allows client-to-server communication) is present.
Allow external UDP-based DNS clients to query the DNS server on the bastion host and it to answer them.
Allow TCP-based DNS queries from the bastion host to DNS servers on the Internet, as well as answers to those queries. Also allow zone transfers in which the bastion 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 bastion host DNS server, as well as answers to those queries. Also allow zone transfers in which the bastion 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 as the corresponding rules do on the interior router.
In addition to setting up the packet filtering rules, we need to do various other kinds of configuration work, as described below.
Configure electronic mail so that it gets sent to the bastion host. We're also going to need to install passive mode FTP clients if they're available.
Install the smap and smapd programs from the TIS FWTK and an up-to-date mailer release so that we have a trusted SMTP server.
Put in an MX record for every A record, pointing incoming mail to the bastion host; further MX records may be necessary for the internal mail server to direct the traffic internally. We also need to configure the bastion host as a recognized secondary name server, and remove any TXT or HINFO records we don't want the external world to see (i.e., pretty much any records the external world could possibly make any sense of).
Do all the standard bastion host configuration (removing unused servers, adding logging, and so on), as discussed in Chapter 5. We need to install TIS FWTK and configure FTP proxying, smap and smapd, and anonymous FTP service from it. We also need to install the CERN HTTP server and configure it to do proxying, as well as to serve the HTTP pages we want to show the outside world.
Just how good a firewall is this one we've configured? Let's consider it in relation to the strategies and principles discussed in Chapter 3, Security Strategies.
The principle of least privilege is that an object (a program, a person, a router, or whatever) should have the minimum privileges necessary to perform its assigned task and no more. A corollary of this principle is that systems should be configured so they require as little privilege as possible. You can see this principle in action in several places in this setup. For example, configuring SMTP so that outgoing mail goes out via the bastion host (rather than directly to remote systems) is an application of least privilege, 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.)
The principle of defense in depth is something else that you can see in the setup we've described. For example, internal hosts are protected from the outside world by the exterior and interior routers. Similarly, the bastion host is protected against attack both by its own careful configuration and by the exterior router.
Several times, we've explicitly made decisions to increase the depth of defense. For example, that's one of the main purposes of using an internal mail server between the bastion host and the internal clients. The interior and exterior routers often deny the same packets. Defense in depth is almost the only reason for having the interior router deny packets that it supposedly can't receive (because they've already been denied by the exterior router).
The principle of a choke point is clearly applied in our setup, because everything between internal clients and the Internet comes through the perimeter net. Further, much of it comes through the bastion host, via proxies. Only Telnet and FTP are provided in ways that leave them relatively open. These services could have been better choked by using proxies everywhere.
There is no single obvious weak link to attack in this configuration. Probably the weakest link is the bastion host, but even a completely compromised bastion host isn't going to help an attacker when it comes to attacking the internal systems; there just aren't that many connections allowed from the bastion host to internal systems. Some of the weakest links you can see remaining in this setup include proxy FTP and SMTP from the bastion host to the internal mail server.
The proxy FTP setup we've described would allow an attacker who has compromised the bastion host to attack servers on ports above 1023 (if there are any) on internal hosts. How can you address this vulnerability? Obtain and use only passive-mode FTP clients internally, don't run proxy FTP, and remove the rules allowing proxy FTP from the filters.
Similarly, the SMTP setup we've described would allow an attacker who has compromised the bastion host to attack your mail server via SMTP. How can you address this vulnerability? Improve the security of the SMTP server on your mail server, e.g., by using an up-to-date version of Sendmail, and by using the TIS FWTK smap package.
You can keep playing this game of thinking "If I were an attacker, what would I do?", and then addressing the problems you discover ad nauseam, or until you run out of time or money. At some point, though, you (or your management) will probably decide you've done enough (based on your own site's definition of "enough").
You can see the principle of a fail-safe stance applied through the packet filtering rules. 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 (a new service, for example), it won't be allowed through your firewall; unless, of course, it mimics or is tunneled through some other service you do allow. The redundant router rules also provide a fail-safe against failure of one router or the other. If filtering accidentally or temporarily gets turned off on one router (causing it to pass all packets), the other still does most of the same filtering, at least as far as the outside world is concerned.
If this is our site's only connection to the Internet, we have involuntary universal participation; everybody has to go through the firewall to get to the Internet. Of course, we'd be much better off with voluntary universal participation, but that may require some user education about the goals of and the need for the security measures we're adopting.
To some extent, we're relying on voluntary universal participation. We've granted free Telnet and FTP access, and in the process we've allowed any outbound connection to ports at or above 1024 (which is plenty of rope for the users to hang us with). FTP is by no means the only service above 1024, and Telnet is a perfectly good client to use to get to many of them.
In particular, we've assumed that this is your sole connection to the Internet and that internal users aren't just going to bypass the firewall entirely by setting up their own Internet connections. All it takes is one joker with a modem, a PPP software package, and an outside phone line, and you too could have an unprotected back door into your network.
There are opportunities in this configuration to apply the principle of diversity of defense, e.g., using routers from different vendors for the interior and exterior packet filtering systems. Most sites will probably conclude that such an approach is not worth the hassle. However, even if you use similar or identical hardware, you still might get some diversity by having different people do at least the initial configuration of the different filtering systems, and then having them cross-check each other's work.
Using different SMTP servers on the internal mail server and the bastion host would be a fairly major advance in this configuration, because that's one of the main weak points of your setup. Even a less secure SMTP server on the internal mail server is arguably better than one that's going to yield to the exact same attack that just succeeded on the bastion host. The more vulnerable the SMTP server you're using, the more important an issue this is.
There are a lot of advantages offered by a scheme such as the one we've described in the sections above. The main potential disadvantages we can see are cost and complexity; but we don't think that the configuration we've presented is too expensive for most sites, and we think that it presents the minimum necessary level of complexity.
What if you really need to save some money? It would be feasible to construct a screened subnet architecture using a single three-interface router, instead of the pair of two-interface routers we've described above. The solution would be a little more complex, because you'd have to merge the two separate filtering sets described above, but doing so shouldn't be too difficult.
It would also be relatively easy to construct a more secure configuration with the same basic architecture. A less trusting site would force all Telnet and all FTP through proxies, which would allow much better logging and remove the nagging holes created by allowing every outbound connection to ports above 1024. Once you'd forced Telnet and FTP through proxies, you'd also find that DNS information hiding would be both more practical and more reasonable. However, the price of this increased security would be a more complex and fragile configuration, and one that presents more annoyance to the users.
It would also be possible to increase the services offered without major architecture changes. For example, incoming Telnet and incoming user FTP could be supported relatively easily for a few users on the bastion host or on a dedicated host on the screened network. Serious anonymous FTP service or HTTP service could be provided by configuring extra machines on the screened network. Similarly, you could scale up the firewall to support a second Internet connection or redundant bastion hosts to provide more reliable service or service for a much larger internal network.
|  | |
| 8.18 Analyzing Other Protocols |  | 9.2 Screened Host Architecture |