Click for next page ( 294


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 293
H Types of Firewalls The four basic types of firewalls are packet filters, circuit relays, ap- plication gateways, and dynamic packet filters. Packet filter firewalls operate at the network layer, with occasional peeks at the transport-layer headers. The information used to make a pass/drop decision on a packet is contained in that packet; no state is maintained. Typical decision criteria include source address, destination addresses, and transport protocol port number (i.e., service) requested. Not all protocols are compatible with packet filters. For example, a com- mon security policy allows most outgoing calls but no incoming calls. A packet filter can implement this policy if and only if protocol headers contain fields that differentiate between requests and responses. In Trans- mission Control Protocol (TCP), a single bit value distinguishes the first packet of a conversation from all others, so it is possible to drop incoming packets that do not have this bit properly set. By contrast, User Datagram Protocol (UDP) lacks such a notion, and it is impossible to enforce the desired security policy. Packet filters normally associate several rules with each legal conversation. Not only must messages flow from the client to the server, but replies and even protocol-level acknowledgment packets also must flow in the other direction. The lack of state makes possible interactions between the different rules and that can allow cer- tain attacks for example, a legal acknowledgment packet may also be an illegal attempt to set up a new conversation. Circuit relays operate above the transport layer. They pass or drop entire conversations but have no knowledge of the semantics of what they 293

OCR for page 293
294 APPENDIX H relay. Circuit relays are generally considered to be more secure than packet filters, primarily because they terminate instantiations of the trans- port protocol. Interactions between rules is unlikely at the transport layer, and the same mechanisms that normally separate different circuits keep together the inbound and outbound packets for a given connection. Be- cause connections now terminate at an intermediate point (namely, the firewall), circuit relays generally require changes in application programs, user behavior, or both. This lack of transparency makes circuit relays unsuitable for many environments, where transparency and compatibil- ity are important. Applications gateways are closely tied to the semantics of the traffic they handle. Typically, a separate program (proxy) is required for each application. A mail gateway might rewrite header lines to eliminate ref- erences to internal machines, log senders and receivers, and so on. Appli- cation gateways can handle traffic whose characteristics render packet filters and circuit relays inappropriate enforcement mechanisms. For ex- ample, by default the File Transfer Protocol (FTP) (Poster and Reynolds, 1985) uses an inbound channel for data transfers, which packet filters cannot handle safely. An FTP proxy in an application gateway can keep track of when a given incoming call should be accepted, and thus can allow what would otherwise be a violation of normal security policies. Application gateways are also well suited for sites that require au- thentication of outgoing calls. Since few if any protocols are designed to provide authentication at an intermediate point like a firewall, a custom design is necessary for each application. One might require a separate log-in, entirely in-band; another might pop up a window on the user's terminal. Application gateways are generally considered to be the most secure type of firewall because a detailed knowledge of protocol seman- tics makes spoofing difficult. Dynamic packet filters, the last of the four firewall types, excel at transparency. They merge the packet filter and application gateway types of firewall. With a dynamic packet filter, most packets are accepted or rejected based solely on information in the packet. However, some pack- ets cause additional processing that modifies the rules that will be applied to subsequent packets. This enables the UDP problem mentioned above to be solved: the fact that an outbound query has been sent then condi- tions the firewall to accept the reply packet, a message that would other- wise have been rejected. More sophisticated processing can be done as well. For example, dynamic packet filters can be sufficiently aware of FTP to permit the incoming data channel call. Some dynamic packet filters are aware of the remote procedure call (RPC) (Sun Microsystems, 1988) and can mediate access to individual services. Even header address transla

OCR for page 293
APPENDIX H lion can be performed (Egevang and Francis ternal machines. REFERENCES 295 , 1994), further isolating in Egevang, K., and P. Francis. 1994. The IF Network Address Translator (NAT). RFC 1631. May. Postel,J., end d. Reynolds. 1985. File Transfer Protocol (FTP). RFC 959. October. Sun Microsystems. 1988. RPC: Remote Procedure Call Protocol Specification Version 2. RFC 1057.