4. Policy in Practice

The aim of the preceding "what-if" stage of policy-making is to arrive at a suitable network-service access policy and a firewall-design policy. To assist in this process we have outlined some common issues that need to be addressed in the policies associated with firewall use. We begin with some specifics and then move on to more general considerations.

Packet Filtering
All firewalls perform some sort of IP packet filtering, usually by means of a packet-filtering router. The router filters packets as they pass between the router's interfaces, implementing a set of rules based on your firewall policy. A packet-filtering router usually can filter IP packets based on some or all of the following criteria:

· source IP address,

· destination IP address,

· TCP/UDP source port, and

· TCP/UDP destination port.

Not all packet-filtering routers can filter the source TCP/UDP port. Some routers can examine at which of the router's network interfaces a packet arrived and then use this as a further filtering criterion. Some UNIX hosts provide packet-filtering capability, although most do not. Filtering can be used to block connections from or to specific hosts or networks and also to block connections to specific ports. A site might wish to block connections from certain addresses, such as from hosts or sites that it considers to be hostile or untrustworthy. Alternatively, a site may wish to block connections from all addresses external to the site (with certain exceptions, such as with SMTP for receiving e-mail).

Adding TCP or UDP port filtering to IP address filtering results in a great deal of flexibility. Servers such as the TELNET daemon usually reside at specific ports (port 23 for TELNET). If a firewall can block TCP or UDP connections to or from specific ports, then one can implement policies that call for certain types of connections to be made to specific hosts, but not others. For example, a site may wish to block all incoming connections to all hosts except for several firewalls-related systems. At those systems, the site may wish to allow only specific services, such as SMTP for one system and TELNET or FTP connections to another system (see diagram in Figure 3). With filtering on TCP or UDP ports, this policy can be implemented in a straightforward fashion by a packet-filtering router or by a host with packet-filtering capability.

Figure 3: Packet Filtering on TELNET and SMTP [Wack]

As an example of packet filtering, consider a policy to allow only certain connections to a network of address 123.4.*.*. TELNET connections will be allowed to only one host, 123.4.5.6, which may be the site's TELNET application gateway, and SMTP connections will be allowed to two hosts, 123.4.5.7 and 123.4.5.8, which may be the site's two electronic mail gateways. NNTP (Network News Transfer Protocol) is allowed only from the site's NNTP feed system, 129.6.48.254, and only to the site's NNTP server, 123.4.5.9, and NTP (Network Time Protocol) is allowed to all hosts. All other services and packets are to be blocked. For more detailed discussion of this example see [Wack]. This is a very basic example of packet filtering. Actual rules may permit more complex filtering and greater flexibility.

Policing Protocols
It is the network services access policy which determines which protocols and fields are filtered, that is, which systems should have Internet access and the type of access to permit. The following services are inherently vulnerable to abuse and are usually blocked at a firewall from entering or leaving the site [Chap92], [Garf92]:

· tftp, port 69, trivial FTP, used for booting diskless workstations, terminal servers and routers, can also be used to read any file on the system if set up incorrectly.

· X Windows, OpenWindows, ports 6000+, port 2000, can leak information from X window displays including all keystrokes (intruders can even gain control of a server through the X-server).

· RPC, port 111, Remote Procedure Call services including NIS and NFS, which can be used to steal system information such as passwords and read and write to files.

· rlogin, rsh, and rexec, ports 513, 514, and 512, services which, if improperly configured, can permit unauthorized access to accounts and commands.

Other services, whether inherently dangerous or not, are usually filtered and possibly restricted to only those systems that need them. These would include:

· TELNET, port 23, often restricted to only certain systems.

· FTP, ports 20 and 21, like TELNET, often restricted to only certain systems.

· SMTP, port 25, often restricted to a central e-mail server.

· RIP, port 520, routing information protocol, can be spoofed to redirect packet routing.

· DNS, port 53, domain names service zone transfers, contains names of hosts and information about hosts that could be helpful to attackers, could be spoofed.

· UUCP, port 540, UNIX-to-UNIX CoPy, if improperly configured can be used for unauthorized access.

· NNTP, port 119, Network News Transfer Protocol, for accessing and reading network news.

· gopher, http, ports 70 and 80, information servers and client programs for gopher and WWW clients, should be restricted to an application gateway that contains proxy services.

Although some of these services, such as TELNET or FTP, are inherently risky, blocking access to these services completely may be too drastic a policy for many sites. However, at many sites, not all systems require access to all services. For example, restricting TELNET or FTP access from the Internet to only those systems that require the access can improve security at no cost to user convenience. Services such as NNTP may seem to pose little threat, but restricting these services only to those systems that need them helps to create a cleaner network environment and reduces the likelihood of exploitation from yet-to-be-discovered vulnerabilities and threats.

System managers should also be aware that there are services available through which users can obtain access to FTP and other Internet services through e-mail. For example, the Unix Mail Robot allows Web documents to be retrieved through e-mail and at least two sites provide Internet services such as FTP via e-mail. If especially tight security demands that such access be restricted, there may be additional controls to impose on outgoing and incoming e-mail.

Packet Filters as Firewalls
So, if a packet-filtering router is configured to enforce the network services access policy, is it a firewall? If so, can it be an effective firewall? Yes, although some people might say it depends on how effective you need your firewall to be. Some vendors might then reply "Have you looked out our routers lately?" Certainly, there are packet-filtering routers that meet Cheswick's three-point firewall cited earlier and products from several router vendors have passed the NCSA's firewall certification process. In the first edition of this guide we may have given the impression that firewalls have "evolved" from packet filters to application gateways and beyond. Although there are several categories of firewall and some firewall technologies were developed quite recently, it would be wrong to characterize this as evolution if this implied that newer is necessarily better.

It is true that, historically, packet-filtering routers were hard to configure and maintain, but improved software and user interfaces have made these tasks easier. Packet-filtering rules are inherently complex to specify and if no testing facility is provided for verifying the correctness of the rules, other than by exhaustive testing by hand, then mistakes are more likely. Again, some products have rectified this. Earlier routers lacked logging capability, so that if the rule set were to let dangerous packets through, they might not have be detected until a break-in occurred. Clearly it is helpful to add logging features to a packet-filtering router. One more recent addition is internal address translation and masking, in which the addresses of internal systems are hidden, so that only the router's address is seen by the outside network. This allows unlimited use of internal IP addresses that do not need to be sanctioned or assigned (thus avoiding the current shortage of addresses).

When evaluating packet-filtering routers as firewalls you also have to look at factors such as performance, suitability and cost. For a small office network with limited Internet connectivity, a packet-filtering router that has a good interface and suitable testing and logging features may be entirely adequate. Furthermore, it will not slow down internetwork traffic, since the process of packets through filters has been optimized in router designs for some time. Finally, since a router is required to make the internetwork connection possible, using it as a firewall as well saves money.

We do not wish to minimize the drawbacks to packet-filtering routers. Even with a good interface, maintaining a rule set that is both effective and appropriate is a serious task. Exceptions to rules will often need to be made to allow certain types of access that normally would be blocked, but exceptions to packet-filtering rules can make the filtering rules so complex as to be unmanageable. For example, it is relatively straightforward to specify a rule to block all inbound connections to port 23 (the TELNET server). If exceptions are made, that is, if certain systems need to accept TELNET connections directly, then a rule for each system may need to be added (some packet-filtering systems do allow you to treat the sequential order of the filter rules as being significant, which means you can have an exception PERMIT to a specific system, followed by a DENY for all systems). Sometimes the addition of certain rules may complicate the entire filtering scheme. Some packet-filtering routers do not filter on the TCP/UDP source port, which can make the filtering rule set more complex and can open up holes in the filtering scheme.

Application Gateways
To counter some of the weaknesses associated with packet-filtering routers, software applications were developed to forward and filter connections for services such as TELNET and FTP. Such applications are referred to as proxy services, while host machines running the proxy services are referred to as application gateways. Working together, application gateways and packet-filtering routers have the potential to provide higher levels of security and flexibility than either alone. For example, consider a site that blocks all incoming TELNET and FTP connections using a packet-filtering router. The router allows TELNET and FTP packets to go to one host only, the TELNET/FTP application gateway. A user who wishes to connect inbound to a site system would have to connect first to the application gateway, and then to the destination host, as follows:

1. user first telnets to the application gateway and enters the name of an internal host,

2. the gateway checks the user's source IP address and accepts or rejects it according to any access criteria in place,

3, the user may need to authenticate herself (possibly using a one-time password device),

4. the proxy service creates a TELNET connection between the gateway and the internal host,

5. the proxy service then passes bytes between the two connections, and finally

6. the application gateway logs the connection.

You can see that proxy services allow only those services through for which there is a proxy. In other words, if an application gateway contains proxies for FTP and TELNET, then only FTP and TELNET may be allowed into the protected subnet and all other services are completely blocked (see Figure 4). For some sites, this degree of security is important, as it guarantees that only those services which are deemed trustworthy are allowed through the firewall. It also prevents other untrusted services from being implemented behind the backs of the firewall administrators.

Figure 4: Proxies on an application gateway

Another benefit to using proxy services is that the protocol can be filtered. Some firewalls, for example, can filter FTP connections and deny use of the FTP put command, which is useful if one wants to guarantee that users cannot write to, say, an anonymous FTP server. Application gateways have a number of general advantages over the default mode of permitting application traffic directly to internal hosts. These include:

A. Information hiding, in which the names of internal systems need not necessarily be made known via DNS to outside systems, since the application gateway may be the only host whose name must be made known to outside systems.

B. Robust authentication and logging, in which the application traffic can be authenticated before it reaches internal hosts and can be logged more effectively than if logged with standard host logging.

C. Cost-effectiveness, because third-party software or hardware for authentication or logging need be located only at the application gateway.

D. Less-complex filtering rules, in which the rules at the packet-filtering router will be less complex than they would if the router needed to filter application traffic and direct it to a number of specific systems. The router need only allow application traffic destined for the application gateway and reject the rest.

Of course, there is seldom gain without pain. In the case of client-server protocols such as TELNET, application gateways require two steps to connect inbound or outbound, which can be viewed as a disadvantage or an advantage, depending on whether the modified clients make it easier to use the firewall. A TELNET application gateway would not necessarily require a modified TELNET client, however it would require a modification in user behavior: the user has to connect (but not login) to the firewall as opposed to connecting directly to the host.

A modified TELNET client could make the firewall transparent by permitting a user to specify the destination system (as opposed to the firewall) in the TELNET command. The firewall would serve as the route to the destination system and thereby intercept the connection, and then perform additional steps as necessary such as querying for a one-time password. Users don't have to change their behavior; however, the price is that a modified client has to run on each system.

In addition to TELNET, application gateways are used generally for FTP and e-mail, as well as for X Windows and some other services. Some FTP application gateways include the capability to deny put and get commands to specific hosts. For example, an outside user who has established an FTP session (via the FTP application gateway) to an internal system such as an anonymous FTP server might try to upload files to the server. The application gateway can filter the FTP protocol and deny all puts to the anonymous FTP server. This would ensure that nothing can be uploaded to the server and would provide a higher degree of assurance than relying only on the correct setting of file permissions at the anonymous FTP server.

An e-mail application gateway serves to centralize e-mail collection and distribution to internal hosts and users. To outside users, all internal users would have e-mail addresses of the form user@emailhost where emailhost is the name of the e-mail gateway. The gateway would accept mail from outside users and then forward mail along to other internal systems as necessary. Users sending e-mail from internal systems could send it directly from their hosts, or in the case where internal system names are not known outside the protected subnet, the mail would be sent to the application gateway, which could then forward the mail to the destination host. Some e-mail gateways use a more secure version of the sendmail program to accept e-mail.

Packet Inspection
Some Internet firewalls use a combination of a packet-filter screening computer or a hardware router for controlling the lower layers of communication, and use application gateways for the enabled applications. But there may be limits on transparency, flexibility, and connectivity with this arrangement, which may also get expensive in terms of setup, management, and expertise. Another approach is to inspect packets rather than just filtering them; that is, to consider their contents as well as their addresses. Firewalls of this type employ an inspection module, applicable to all protocols, that understands data in the packet intended for all other layers, from the network layer (IP headers) up to the application layer. This strategy can provide context-sensitive security for complex applications and may be more effective than technologies which only have data in some of the layers available to them. For example, although application gateways have access only to the application layer and routers have access only to the lower layers, the packet-inspection approach integrates the information gathered from all layers into a single inspection point.

The speed at which packets can be handled by the inspection module is typically faster, for a given unit of processing power, than an application gateway. This can translate into positive cost implications (cheaper hardware to run the firewall). Some inspection firewalls also take into account the state of the connections they handle, so that, for example, a legitimate incoming packet can be matched with the outbound request for that packet and allowed in. Conversely, an incoming packet that is masquerading as a response to a non-existent outbound request, can be blocked. This takes the so-called stateful inspection approach well-beyond packet filtering.

Inspection firewalls can provide address translation and hiding, as well as provide other services, such as virus scanning, that are also being added to application gateway firewalls. However, some experts contend that, because "allowed" packets travel through an inspection firewall, inspection firewalls are less secure than application proxies, through which no "allowed" packet passes (the packet is created by the proxy). Proponents of inspection firewalls dismiss this argument but, as a prospective firewall user, you should be aware of it. You should also be aware of another area of debate, the speed with which different types of firewalls can respond to changes.

Firewalls and Flexibility
You can see that any security policy which deals with Internet access, Internet services, and network access in general, has to be flexible because the Internet itself is in flux. Consider how quickly World Wide Web traffic eclipsed FTP once Web browsers became popular. Furthermore, the organization's needs may change as the Internet offers new services and methods for doing business, such as secure transactions and live video.

New protocols and services are emerging on the Internet. Using them may benefit the organization, but they may result in new security concerns. For example, within a few months of its release, hundreds of thousands of people were using the RealAudio sound player for the Web, yet users behind UDP-blocking firewalls found that the program wouldn't work properly, leading some to remove restrictions from the port. Thus, a policy needs flexibility to reflect and incorporate new concerns. But flexibility is also important given the rapid changes in business today. New partnerships and alliances may bring new network connections and new risks. Few organizations are likely to remain static.

When it comes to adapting your firewall to changes, you will want to be able to accommodate new applications as soon as possible. Proponents of inspection firewalls argue that their technology provides the quickest way to allow new services, for example an innovative video-conferencing protocol, to pass through the firewall. They point out that such a service would be denied by an application gateway until a proxy were available. Advocates of application proxies approach counter in several ways. First, they note that major vendors, such as Intel, now work very closely with firewall vendors to make proxy applications readily available (a process facilitated by NCSA's Firewall Product Developers' Consortium). Second, they note that, although inspection firewalls can allow a new service very easily, the inspection module will need to be fine-tuned to provide maximum safety (we do not wish to enter this debate, but you need to be aware of it). In practice, commercial firewalls may use a mixture of technologies to accomplish their task. Packet filtering is often combined with packet inspection and proxies for standard services.

Remote User Advanced Authentication Policy
Remote users are those who initiate connections to a site's system from elsewhere on the Internet. These connections could come from any location on the Internet, from dial-in lines, or from authorized users traveling or working from home. All such connections should use the advanced authentication service of the firewall to access systems at the site. Policy should reflect that remote users may not access systems through unauthorized modems placed behind the firewall. There must be no exceptions to this policy, as it takes only one captured password or one uncontrolled modem line to enable a backdoor around the firewall.

Of course, such a policy has its drawbacks. For a start, there is the increased user training for using advanced authentication measures. There is added expense if remote users are supplied with authentication tokens or smart cards, together with increased overhead in administering remote access. But it does not make sense to install a firewall and at the same time fail to control remote access, especially when secure authentication tokens now cost less than $30 (US) per user per year (excluding host software licenses).

Dial-in/out Policy
A useful feature for authorized users is to have remote access to the systems when these users are not on site. A dial-in capability allows them to access systems from locations where Internet access is not available. However, dial-in capabilities add another avenue for intruder access. Authorized users may also wish to have a dial-out capability to access those systems that cannot be reached through the Internet. These users need to recognize the vulnerabilities they may be creating if they are careless with modem access. A dial-out capability may easily become a dial-in capability if proper precautions are not taken.

The dial-in and dial-out capabilities should be considered in the design of the firewall and incorporated into it. Forcing outside users to go through the advanced authentication of the firewall should be strongly reflected in policy. Policy can also prohibit the use of unauthorized modems attached to host systems and to personal computers at the site if the modem capability is offered through the firewall. A strong policy and effective modem service may limit the number of unauthorized modems throughout the site, thus limiting this dangerous vulnerability as well.

Remote Network Connections
In addition to dial-in/dial-out connections, the use of Serial Line IP (SLIP) and Point-to-Point Protocol (PPP) connections needs to be considered as part of the policy. Users could use SLIP or PPP to create new network connections into a site protected by a firewall. Such a connection is potentially a backdoor around the firewall, and may be an even larger backdoor than a simple dial-in connection. It is possible to locate dial-in capability so that dial-in connections have to pass through the firewall. This sort of arrangement can also be used for SLIP and PPP connections; however, this restriction would need to be set forth in policy. As usual, the policy would have to be very strong with regard to these connections (given that workers at NASA's Kennedy Space Center can be suspended for introducing unauthorized floppy disks into the workplace, it is reasonable for your policy to specify something equally severe for setting up un-sanctioned Internet connections).

Information Server Policy
A site that is providing public access to an information server may want to incorporate this access into the firewall design. Although the information server itself creates additional and specific security concerns, the information server should not reduce the existing security of the protected site. Policy should reflect the philosophy that the security of the site shall not be compromised in order to provide an information service. A typical example of this is a Web server intended to provide access for Internet users. This machine may not need to be behind the firewall at all. If the information dished up by the Web server resides on that machine itself, rather than being drawn from systems on the internal network, it can be operated as a "sacrificial lamb" with no connections except an external one to the Internet. As long as the machine is regularly backed up it can operate unencumbered by a firewall and simply be restored from backups if it is attacked.

If you need to accept information submitted by users of a Web server, for example, when they fill oput a form on a Web page, then you will want to protect that information and the channel by which it is communicated to your internal network. Allowing such data to accumulate on the Web server itself is risky because it could be compromised if the Web server were attacked. Transmission of the information from the server to the internal network needs to be via a firewall. The same policy applies to any valuable information that you want to dish up via Web pages. If you are supplying responses to questions that draw from internal databases then you should put the systems that hold these databases behind a firewall. Several configurations are shown in Figure 5.

Figure 5: Web servers relative to firewalls

One can make a useful distinction that information-server traffic--the traffic concerned with retrieving information from an organization's information server--is fundamentally different from other "conduct of business" traffic such as e-mail (or other information server traffic for the purposes of business research). The two types of traffic have their own risks and do not necessarily need to be mixed with each other. Screened subnet and dual-homed gateway firewalls allow information servers to be located on a screened subnet and in effect be isolated from other site systems. This reduces the chance that an information server could be compromised and then used to attack site systems.

Multiplication Problems
Cheswick and Bellovin identify one area of particular difficulty for firewall policy developers under the title of joint ventures [Ches94]. This includes situations where two or more companies agree to work together on a specific project while remaining competitive in other areas. This produces policy dilemmas similar to those that arise when companies wish to let support staff from vendors connect to a site in order to diagnose problems, or when suppliers connect to share ordering information. Here are some suggested policies:

1. Shared machines require protection from outsiders.

2. System administrator must assume that partners do not trust each other 100%.

3. Users have legitimate need for high-quality access to the shared machines plus their respective home machines.

There are several solutions that can be implemented to address these policies [Ches94] but this is an inherently challenging area of firewall policy.