The decision to filter certain protocols and fields depends on the site security policy, i.e., which systems should have Internet access and the type of access to permit. The location of the firewall will influence the policy. For example, if the firewall is located at a site's Internet gateway, the decision to block inbound telnet access will still permit site systems to access other site systems. If the firewall is located at a subnet within the site, the decision to block inbound telnet to the subnet will prevent access from other site subnets.
Usually, the following services are blocked at a firewall [Bel89]:
These services are inherently open to abuse and therefore should be blocked directly at the firewall. Other services, whether inherently dangerous or not, are usually filtered and possibly restricted to only those systems that need them. These would include:
While some of these services such as telnet or ftp are inherently risky, blocking these services completely may be too draconian a policy for many sites. Not all systems, though, generally 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 or NTP may seem to pose no threat, however restricting these protocols to only 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.
UNIX systems, including System V and BSD-based, generally contain TCP/IP code or conventions derived from the original Berkeley UNIX distributions. The TCP/UDP port allocation scheme used by Berkeley is therefore common to most UNIX systems as well as most other non-UNIX TCP/IP implementations. This informal standard aids greatly in packet filtering schemes.
In the Berkeley scheme, port numbers between 0 and 1023 are privileged, that is, these ports are used to connect to services such as telnet, ftp, and SMTP daemons that require system-level privileges. Port numbers above 1023 are usually associated with processes that don't need special privileges.
An example may best illustrate the port allocation scheme. If a user on a remote system wishes to telnet to a local system, the remote system's telnet client allocates, on behalf of the user, an unprivileged port with number greater than 1023 (say, 2123). It then sends an initial packet containing port number 2123 to the telnet server's port on the local system. The telnet server, a privileged process, resides at port number 23. The local system, in accepting the telnet connection, would then respond back to the telnet client on the remote system by sending a packet to the client's port number 2123. The connection is thus established, and the client and server can proceed with exchanging data and keystrokes. Most other privileged services follow this scheme, with some exceptions, thus filtering on privileged port numbers can greatly simplify packet-filtering rules.
To illustrate how the Berkeley port allocation scheme can simplify packet filtering, a site that wishes to block inbound TCP/IP services could simply block all packets from outside systems with port numbers less than 1024. This, of course, would block all telnet, ftp, SMTP, and most other services from entering the site. To allow specific services to pass through, then, one can make exemptions for specific ports.
Although this scheme is relatively simple, there are a number of problems associated with it, the primary one being that not all privileged services use privileged ports. X Windows, Sun OpenWindows, and some ports allocated by the portmapper process all can be greater than 1023, thus filtering on specific port numbers above 1023 is still required to block these protocols. Another problem is that the Berkeley port allocation scheme is only a commonly-used convention, not a true standard. As a result, systems that do not follow this scheme may be able to evade packet-filtering rules. Fortunately, deviations from the scheme are relatively rare. The following section provides examples in more detail for filtering packets.