A Toolkit and Methods for Internet Firewalls

The purpose of an Internet firewall is to provide a point of defense and a controlled and audited access to services, both from within and without an organization ́s private network. This requires a mechanism for selectively permitting or blocking traffic between the Internet and the network being protected1. Routers can control traffic at an IP level, by selectively permitting or denying traffic based on source/destination address or port. Hosts can control traffic at an application level, forcing traffic to move out of the protocol layer for more detailed examination. To implement a firewall that relies on routing and screening, one must permit at least a degree of direct IP-level traffic between the Internet and the protected network. Application level firewalls do not have this requirement, but are less flexible since they require development of specialized application forwarders known as “proxies.” This design decision sets the general stance of the firewall, favoring either a higher degree of service or a higher degree of isolation. [1] As the number of businesses and government agencies connecting to the Internet continues to increase, the demand for Internet firewalls — points of security guarding a private network from intrusion — has created a demand for reliable tools from which to build them. We present the TIS Internet Firewall Toolkit, which consists of software modules and configuration guidelines developed in the course of a broader ARPAsponsored project. Components of the toolkit, while designed to work together, can be used in isolation or can be combined with other firewall components. The Firewall Toolkit software runs on UNIX® systems using TCP/IP with the Berkeley socket interface. We describe the Firewall Toolkit and the reasoning behind some of its design decisions, discuss some of the ways in which it may be configured, and conclude with some observations as to how it has served in practice. A proxy for a network protocol is an application that runs on a firewall host and connects specific service requests across the firewall, acting as a gateway. Figure 1 represents a minimal TELNET service proxy, in which the proxy forwards user ́s keystrokes to a remote system, and maintains audit records of connections. Proxies can give the illusion to the software on both sides of a direct point-topoint connection. Since many proxies interpret the protocol that they manage, additional access control and audit may be performed as desired. As an example, the FTP proxy can block FTP export of files while permitting import of files, representing a granularity of control that router-based firewalls cannot presently achieve. Router-based firewalls can provide higher throughput, since they operate at a Overview Computer networks by their very nature are designed to allow the flow of information. Network technology is such that, today, you can sit at a workstation in Maryland, and have a process connected to a system in London, with files mounted from a system in California, and be able to do your work just as if all of the systems were in the same room as your computer. Impeding the free flow of data is contrary to the basic functionality of the network, but the free flow of information is contrary to the rules by which companies and governments need to conduct business. Proprietary information and sensitive data must be kept insulated from unauthorized access yet security must have a minimal impact on the overall useability of the network. 1 Or, in general, between any two networks where one needs to be protected from the other. protocol level, rather than an application level, but practical experience running firewalls on modern RISC processors shows that with a T-1 connection, the bottleneck tends to remain the T-1 link rather than the firewall itself. Figure 1: An Application Proxy User's Workstation Telnet Application Proxy User keystrokes Telnetd