Chapter 24. Two Sample Firewalls

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.

TIP: 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: the World Wide Web, terminal access, file transfer, electronic mail, Usenet news, and DNS.

24.1. Screened Subnet Architecture

The screened subnet architecture, described in Chapter 6, "Firewall Architectures", and shown in Figure 24-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.

Figure 24-1. Screened subnet architecture

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 8, "Packet Filtering".) We're going to use a two-router architecture as our example in this section because it is conceptually simpler.

This type of firewall includes the following components, presented originally in Chapter 6, "Firewall Architectures":

Perimeter network

Isolates your bastion host from your internal network, so a security breach on the bastion host won't immediately affect your internal network.

Exterior router

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

Interior router

Protects the internal network from the world and from the site's own bastion host.

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 10, "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 to use proxies or network address translation because you can't allow packets with those unassigned IP addresses onto the Internet; even if you did allow them, 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 Section 8.6.1, "Risks of Filtering by Source Address" in Chapter 8, "Packet Filtering".)

24.1.1. Service Configuration

Given the architecture we've just described, how do we provide the basic Internet services?

24.1.1.1. HTTP and HTTPS

We will want to provide two kinds of HTTP service. We'll want to allow our users to access other people's web sites, and we'll want to put up our own web site.

For outgoing HTTP and HTTPS (letting our users access other sites), we can use either packet filtering or proxy servers. Packet filtering will allow our users to access HTTP and HTTPS servers only on standard ports; proxying will allow them to reach all HTTP and HTTPS servers. Which approach should we take?

Standard browsers support HTTP and HTTPS proxying, so we don't need to worry about using customized clients with either approach. Proxying will increase configuration overhead, but that price seems fair for the increased abilities it offers.

On the other hand, we could simply allow internal hosts to create connections to port 80, port 443, and any port at or above 1024. That will allow access to almost any HTTP or HTTPS server and will also be useful for supporting FTP. It does add a significant amount of risk; internal users will be able to use any protocol above 1024, with no control from the firewall. If these users are ill intentioned or even careless, they could expose the site to all sorts of dangers. In addition, any Trojan horse programs they bring in will easily be able to send out data. However, we originally chose to trust the users, so this is not an issue. Using pure packet filtering this way would lose us only servers at nonstandard ports below 1024, and those ports are all supposed to be reserved anyway.

If we use a caching proxy server, we significantly improve HTTP performance for all of the following:

HTTP clients

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.

Non-HTTP clients

The HTTP clients won't be using so much of the bandwidth of our Internet connection, leaving more of it for other clients to use.

HTTP servers at other sites

They will get only one request from our site for a given page, rather than multiple requests.

HTTPS connections can't be cached because the encryption means that pages are different every time they're accessed, but a caching proxy server won't interfere with HTTPS service; it will simply act like a normal proxy.

ost caching servers will also allow us to provide HTTP service to external sites, so we can take advantage of that to publish our site's own public web pages. This configuration is not particularly secure; the security requirements for proxying and publishing are different, and ideally we would want to separate the two. However, in a configuration with only one bastion host, we can't provide much separation in any case.

Combining the proxying and publishing wouldn't be acceptable if we wanted to provide popular pages, or if we needed much security for the pages we were providing (for instance, if the web pages are used for electronic commerce). In either of those situations, we'd separate the outgoing cache from the public web server, putting them not only on different pieces of software but also on different computers. In fact, we might well choose to have the public web server on somebody else's network altogether, using a commercial web hosting service.

HTTP and HTTPS 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. On the other hand, it's a lot of trouble to install SOCKS just for HTTP and HTTPS; it's probably not worth it unless we have other applications that will 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 users 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 a proxying server) and packet filtering appear to be attractive and reasonable choices. Proxying is definitely preferable if we aren't going to provide 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 and HTTPS service to internal clients via a proxy server running on the bastion host, and that we're using the same server to publish our public web pages to the world. We will take special care to make sure that the proxy component is configured to prevent external users from using the proxy to access either our internal network or other external servers. Our reasons for using a proxy server are based mostly on the added efficiency, although it's also useful to make sure that users can reach HTTP and HTTPS servers on nonstandard ports below 1023.

24.1.1.2. SMTP

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 secured internal 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 as for incoming mail and keeps internal information away from the bastion host. Mail between internal users should not go through the bastion host.

We'll set up SMTP, as outlined in Chapter 16, "Electronic Mail and News", 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 internal mail server.
Configure the bastion host to send all incoming mail to a single internal mail server and to send outgoing mail directly to its destination.

For this example, we're going to assume that there is a single internal mail server for incoming and outgoing mail.

24.1.1.3. Telnet

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. 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 that 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, replacing it with SSH. That's what we'll do for this example.

24.1.1.4. SSH

Although incoming Telnet is unsafe, it's useful to be able to allow some form of remote access. The safest way to do so is to allow SSH. One way would be to allow SSH inbound to the bastion host only, forcing users to log into the bastion host and then go from there to their internal destination; this is effectively a form of proxying. Another option would be to allow SSH inbound to any host.

Forcing SSH to a single bastion host allows us to make sure that what's coming in is genuinely SSH and that the SSH server is safely configured. On the other hand, it requires us to have user accounts configured on the bastion host. If only a few users need to use SSH, it may be the best way to provide the service. However, with only a single bastion host, significant risks are involved in having user accounts around.

Allowing SSH inbound to all hosts avoids the problem with user accounts on the bastion host but opens up the possibility of having hosts running SSH servers that will do port forwarding, or running other servers altogether on the SSH port. As we discuss in Chapter 18, "Remote Access to Hosts", port forwarding across SSH is a significant risk, which may make your site vulnerable to people who are attacking the client. We will allow SSH inbound to all hosts (we're already trusting internal users).

For a more secure configuration, we would limit the hosts that were accessible via SSH, either by adding another bastion host on the screened network or by treating some internal hosts as screened hosts and allowing SSH to just those hosts.

Since we are allowing incoming SSH, we should also allow outgoing SSH; it would be unjust to ask people to use SSH to access our site but require our users to use insecure Telnet to access other sites. However, we will want to warn our users about the risks of remote port forwarding. Unlike outgoing Telnet, outgoing SSH opens us up to incoming attacks if port forwarding is turned on. (See Chapter 18, "Remote Access to Hosts", for more information about the risks of SSH port forwarding.) For more security, we might want to limit even outgoing SSH to a machine where we could control the clients in use and disallow remote port forwarding. Note that even when SSH is limited to a single machine, it is significantly difficult to prevent users from providing their own SSH clients.

24.1.1.5. FTP

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 9, "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 Internet Explorer -- do use passive mode without being modified, but then again, not all servers support it well.

A reasonable compromise would be to use both packet filtering and proxies, using a proxying gateway like ftp-gw from 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 instead.

As we've said, if we wanted to monitor FTP usage, we'd have to use proxying exclusively, but that's not the case here. If we were using an unassigned or unrouted network number, we'd have to do either proxying or network address translation. 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 by using a published address with an advertised reverse mapping -- 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. The proxy server we've selected requires users to modify their procedures, which makes sense in the configuration we're discussing 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 17, "File Transfer, File Sharing, and Printing".) 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, the ports you want to block probably include 6000 through around 6003 (assuming four or fewer real or virtual X11 servers per machine; see the discussion of X11 in Chapter 18, "Remote Access to Hosts"). Since we're allowing SSH, we also need to protect the virtual X11 servers that SSH creates, which start at 6010, so we'll extend this port range to 6020.

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 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 17, "File Transfer, File Sharing, and Printing", 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. Using another bastion host avoids overloading the main bastion host with risky and interacting services.

24.1.1.6. NNTP

As we've discussed in Chapter 16, "Electronic Mail and News", 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 requiring high maintenance on a bastion host.

For this example, we're going to assume a single external NNTP newsfeed.

24.1.1.7. DNS

As discussed in Chapter 20, "Naming and Directory Services", DNS is best provided across a firewall 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 that the DNS server on the bastion host is a secondary server for our domain, and that the primary server is on an internal host. We're not going to do any DNS information hiding.

24.1.2. Packet Filtering Rules

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 {XREF}). 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 8, "Packet Filtering" for a full discussion of packet filtering capabilities and the implications of not having particular capabilities.)

In the packet filtering rules presented in the following table, 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

TIP: In the following table, directions are shown relative to the site, as they have been in previous tables.

24.1.2.1. Interior router

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.

Rule

Dir.

SourceAddress

Dest.Address

Protocol

SourcePort

Dest.Port

ACKSet

Action

Spoof-1

In

Internal

Any

Any

Any

Any

Any

Deny

Spoof-2

Out

External

Any

Any

Any

Any

Any

Deny

HTTP-1

Out

Internal

Bastion

TCP

>1023

80

Any

Permit

HTTP-2

In

Bastion

Internal

TCP

80

>1023

Yes

Permit

Telnet-1

Out

Internal

Any

TCP

>1023

23

Any

Permit

Telnet-2

In

Any

Internal

TCP

23

>1023

Yes

Permit

SSH-1

Out

Internal

Any

TCP

Any

22

Any

Permit

SSH-2

In

Any

Internal

TCP

22

Any

Yes

Permit

SSH-3

In

Any

Internal

TCP

Any

22

Any

Permit

SSH-4

Out

Internal

Any

TCP

22

Any

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-6020

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 SMTP server

Bastion

TCP

>1023

25

Any

Permit

SMTP-2

In

Bastion

Internal SMTP server

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

DNS-1

Out

Internal DNS server

Bastion

UDP

53

53

[180]

Permit

DNS-2

In

Bastion

Internal DNS server

UDP

53

53

[180] 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

Rule	Dir.	SourceAddress	Dest.Address	Protocol	SourcePort	Dest.Port	ACKSet	Action
Spoof-1	In	Internal	Any	Any	Any	Any	Any	Deny
Spoof-2	Out	External	Any	Any	Any	Any	Any	Deny
HTTP-1	Out	Internal	Bastion	TCP	>1023	80	Any	Permit
HTTP-2	In	Bastion	Internal	TCP	80	>1023	Yes	Permit
Telnet-1	Out	Internal	Any	TCP	>1023	23	Any	Permit
Telnet-2	In	Any	Internal	TCP	23	>1023	Yes	Permit
SSH-1	Out	Internal	Any	TCP	Any	22	Any	Permit
SSH-2	In	Any	Internal	TCP	22	Any	Yes	Permit
SSH-3	In	Any	Internal	TCP	Any	22	Any	Permit
SSH-4	Out	Internal	Any	TCP	22	Any	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-6020	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 SMTP server	Bastion	TCP	>1023	25	Any	Permit
SMTP-2	In	Bastion	Internal SMTP server	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
DNS-1	Out	Internal DNS server	Bastion	UDP	53	53	[180]	Permit
DNS-2	In	Bastion	Internal DNS server	UDP	53	53	[180]	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

[180]UDP has no ACK equivalent.

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

Spoof-1 and Spoof-2

Spoof-1 blocks incoming packets that claim to come from internal IP addresses (that is, forged packets presumably sent by an attacker). Spoof-2 blocks outgoing packets that claim to come from external IP addresses (these reflect either bad misconfiguration of machines or an attacker's operating inside your network). Spoof-2 may be difficult to implement on some packet filtering systems because it 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 it in this situation; it is mostly there to protect other people, not to protect your site.

HTTP-1 and HTTP-2

Allow internal HTTP clients to connect to the HTTP proxy server on your bastion host. Clients can use their HTTP connection to the proxy server to request services with any protocol the proxy server will support; the connection from the client to the proxy server will be over port 80, while the connection from the proxy server to the destination server will be over the appropriate port for the desired protocol. Therefore, these rules will support HTTPS as well as HTTP.

Telnet-1 and Telnet-2

Allow outgoing Telnet connections.

SSH-1 and SSH-2

Allow outgoing SSH connections. 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-3 and SSH-4

FTP-1 and FTP-2

Allow outgoing command-channel connections to FTP servers, for use by passive-mode internal clients that are interacting with those servers directly.

FTP-3 and FTP-4

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.

FTP-5 and FTP-6

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.

FTP-7 through FTP-9

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.

SMTP-1 and SMTP-2

Allow outgoing mail from your internal mail server to the bastion host.

SMTP-3 and SMTP-4

Allow incoming mail from the bastion host to your internal mail server.

NNTP-1 and NNTP-2

Allow outgoing Usenet news from your news server to your service provider's news server.

NNTP-3 and NNTP-4

Allow incoming Usenet news from your service provider's news server to your news server.

DNS-1

Allow UDP-based DNS queries and answers from the internal DNS server to the bastion host DNS server.

DNS-2

Allow UDP-based DNS queries and answers from the bastion host DNS server to the internal DNS server.

DNS-3 and DNS-4

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.

DNS-5 and DNS-6

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.

Default-1 and Default-2

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.

24.1.2.2. Exterior router

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

The differences between the rules for the interior router and the exterior router all have to do with the bastion host. That's because the bastion host sits "outside" of the interior router (i.e., on the side of the interior router towards the Internet), but it sits "inside" of the exterior router (i.e., on the side of the exterior router away from the Internet).

If you can set up filtering on the exterior router, it's a good idea to do so. If nothing else, it 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.

Rule

Dir.

SourceAddress

Dest.Address

Protocol

SourcePort

Dest.Port

ACKSet

Action

Spoof-1

In

Internal

Any

Any

Any

Any

Any

Deny

Spoof-2

In

Perim.

Any

Any

Any

Any

Any

Deny

Spoof-3

Out

External

Any

Any

Any

Any

Any

Deny

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

Telnet-1

Out

Internal

Any

TCP

>1023

23

Any

Permit

Telnet-2

In

Any

Internal

TCP

23

>1023

Yes

Permit

SSH-1

Out

Internal

Any

TCP

Any

22

Any

Permit

SSH-2

In

Any

Internal

TCP

22

Any

Yes

Permit

SSH-3

In

Any

Internal

TCP

Any

22

Any

Permit

SSH-4

Out

Internal

Any

TCP

22

Any

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

Any

6000-6020

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

DNS-1

Out

Bastion

Any

UDP

53

53

[181]

Permit

DNS-2

In

Any

Bastion

UDP

53

53

[181] Permit

DNS-3

In

Any

Bastion

UDP

Any

53

[181] Permit

DNS-4

Out

Bastion

Any

UDP

53

Any

[181] 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

Rule	Dir.	SourceAddress	Dest.Address	Protocol	SourcePort	Dest.Port	ACKSet	Action
Spoof-1	In	Internal	Any	Any	Any	Any	Any	Deny
Spoof-2	In	Perim.	Any	Any	Any	Any	Any	Deny
Spoof-3	Out	External	Any	Any	Any	Any	Any	Deny
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
Telnet-1	Out	Internal	Any	TCP	>1023	23	Any	Permit
Telnet-2	In	Any	Internal	TCP	23	>1023	Yes	Permit
SSH-1	Out	Internal	Any	TCP	Any	22	Any	Permit
SSH-2	In	Any	Internal	TCP	22	Any	Yes	Permit
SSH-3	In	Any	Internal	TCP	Any	22	Any	Permit
SSH-4	Out	Internal	Any	TCP	22	Any	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	Any	6000-6020	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
DNS-1	Out	Bastion	Any	UDP	53	53	[181]	Permit
DNS-2	In	Any	Bastion	UDP	53	53	[181]	Permit
DNS-3	In	Any	Bastion	UDP	Any	53	[181]	Permit
DNS-4	Out	Bastion	Any	UDP	53	Any	[181]	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

[181]UDP has no ACK equivalent.

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

Spoof-1 and Spoof-2

Block incoming packets that claim to have internal or perimeter net source IP addresses -- that is, forged packets presumably sent by an attacker. Rule Spoof-1 is the same as the Spoof-1 rule on the interior router; rule Spoof-2 is unique to the exterior router.

Spoof-3

Block outgoing packets that claim to have external source IP addresses. These are either forged packets from an attacker on your network or symptoms of bad network misconfigurations. Spoof-3 may be difficult to implement on some packet filtering systems because it 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 it in this situation; it is mostly there to protect other people, not to protect your site.

HTTP-1 and HTTP-2

Allow the bastion host HTTP proxy server to connect to the HTTP and HTTPS 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.

HTTP-3 and HTTP-4

Allow external clients to contact the bastion host HTTP server. There are no equivalent rules on the interior router because no HTTP servers are on the internal network that external clients can access.

Telnet-1 and Telnet-2

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

SSH-1 and SSH-2

SSH-3 and SSH-4

Allow incoming SSH connections. 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. These are the same as the corresponding rules on the interior router. If there is a need to allow administrators to reach the bastion host with SSH for remote administration, we will need to add another pair of rules. As it is, administrators can use SSH to an internal host and then connect from there to the bastion host, but this is somewhat fragile (if the interior router is down, there will be no way to administer anything remotely).

FTP-1 through FTP-4

Allow outgoing passive-mode FTP connections and are identical to the corresponding rules on the interior router.

FTP-5 and FTP-6

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

FTP-7 through FTP-9

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 other servers on the bastion host are 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.

FTP-10 through FTP-15

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 no FTP servers are on the internal network that external clients can access.

SMTP-1 and SMTP-2

Allow outgoing mail from the bastion host to the outside world.

SMTP-3 and SMTP-4

Allow incoming mail from the outside world to the bastion host.

NNTP-1 to NNTP-4

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.

DNS-1

Allows UDP-based DNS queries and answers from the bastion host DNS server to DNS servers in the outside world.

DNS-2

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.

DNS-3 and DNS-4

Allow external UDP-based DNS clients to query the DNS server on the bastion host and it to answer them.

DNS-5 and DNS-6

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.

DNS-7 and DNS-8

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.

Default-1 and Default-2

Block all packets not specifically allowed by one of the preceding rules, just as the corresponding rules do on the interior router.

24.1.3. Other Configuration Work

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

On all of the internal machines

Configure electronic mail so that outgoing mail gets sent to the internal mail server. We're also going to need to install passive-mode FTP clients if they're available. We may want to install SSH clients and servers, configured to disable port forwarding.

On the internal mail server

Install a trusted SMTP server.

On the internal (primary) name 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).

On the bastion host

Do all the standard bastion host configuration tasks (removing unused servers, adding logging, and so on), as discussed in Chapter 10, "Bastion Hosts". We need to install TIS FWTK and configure FTP proxying, a trusted SMTP server, and anonymous FTP service from it. We also need to install the HTTP server and configure it to do proxying, as well as to serve the HTTP pages we want to show the outside world.

24.1.4. Analysis

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

24.1.4.1. Least privilege

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

24.1.4.2. Defense in depth

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

24.1.4.3. Choke point

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, SSH, and FTP are provided in ways that leave them relatively open. These services could have been better choked by using proxies everywhere.

24.1.4.4. Weakest link

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 much when it comes to attacking the internal systems; not that many connections are allowed from the bastion host to internal systems. Some of the weakest links you can see remaining in this setup include incoming SSH, proxy FTP, combining a public HTTP server with the outgoing caching proxy server.

Allowing inbound SSH to every host is another candidate for the weakest link; it is the point where we put the most trust in the users. Users who choose poor passwords or set up SSH tunnels can easily undermine the security of the firewall. This could be strengthened significantly by restricting SSH to a dedicated bastion host, which could help enforce password and tunneling restrictions. Users could still connect from that host to internal hosts.

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.

Combining incoming and outgoing HTTP service has several drawbacks. First, the server program itself is more complicated; it is trying to enforce different restrictions for internal and external users, and bugs or misconfigurations may inappropriately mix the two, allowing external users to use the server to attack internal machines or third parties. Second, public HTTP servers attract attackers, who you do not want to concentrate on a machine that is important to your site's functioning. You could address this problem by moving the public HTTP server to a dedicated machine, or even using an outside web hosting service to remove it from your site altogether.

As discussed in Chapter 3, "Security Strategies", there are two reasons for knowing what the weakest links in your firewall are. The first reason is so that you can fix them, if possible; we've already talked about things you might change in this firewall to strengthen some of the weak links. The second reason is so that you can monitor those links which you cannot eliminate for one reason or another. For instance, to address the risks posed by allowing SMTP from the bastion host to the internal mail server, you can't practically disallow incoming SMTP; that would cut off incoming mail from the outside world, which probably isn't appropriate. Since you can't eliminate that weak link, you should instead monitor it closely to make sure that an attacker doesn't take advantage of it (i.e., you should monitor the internal mail server for attacks from the bastion host via SMTP, by monitoring the SMTP logs and reports on the internal mail server).

You can keep playing the 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").

24.1.4.5. Fail-safe stance

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.

24.1.4.6. Universal participation

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, SSH, 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.

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.

24.1.4.7. Diversity of defense

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 this setup. Even a less secure but different 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.

24.1.4.8. Simplicity

Simplicity is another important security strategy. This particular firewall configuration provides simplicity by separating components so that each component is as simple and comprehensible as possible. We've made a number of decisions specifically to simplify the configuration; for example, the decision to use separate interior and exterior routers (rather than a single three-interface router) simplifies the packet filtering rules and makes them easier to understand.

24.1.5. Conclusions

A lot of advantages are offered by a scheme such as the one we've described in the previous sections. 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. The solution would be a little more complex because you'd have to merge the two separate filtering sets described previously, 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, SSH, and 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 force the extra protocols 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.


23.2. Games		24.2. Merged Routers and Bastion Host Using General-Purpose Hardware