• Abstract and Figures
• Public Full-text

USENIX Association Proceedings of the BSDCon 2002 Conference San Francisco, California, USA February 11-14, 2002 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2002 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Flexible Packet Filtering: Providing a Rich Toolbox Kurt J. Lidl Deborah G. Lidl Paul R. Borman Zero Millimeter LLC Wind River Systems Wind River Systems Potomac, MD Potomac, MD Mendota Heights, MN [email protected] [email protected] [email protected] Abstract The BSD/OS IPFW packet filtering system is a well engineered, flexible kernel framework for filtering (accepting, rejecting, logging, or modifying) IP packets. IPFW uses the well understood, widely available Berkeley Packet Filter (BPF) system as the basis of its packet matching abilities, and extends BPF in several straightforward areas. Since the first implementation of IPFW, the system has been enhanced several times to support additional functions, such as rate filtering, network address translation (NAT), and traffic flow monitoring. This paper examines the motivation behind IPFW and the design of the system. Comparisons with some contemporary packet filtering systems are provided. Potential future enhancements for the IPFW system are discussed. 1 Packet Filtering: An Overview might choose to copy only this data. Packet filtering and packet capture have a long history A packet must be parsed to determine if it matches a on computers running UNIX and UNIX-like operating given set of criteria. There are multiple ways of doing systems. Some of the earliest work on packet capture this parsing, but a great deal of it amounts to looking on UNIX was the CMU/Stanford Packet Filter [CSPF]. at a combination of bits at each network layer, before Other early work in this area is the Sun NIT [NIT] device the examination of the next layer of the packet. There interface. A more modern, completely programmable are multiple data structures designed for efficient repre- interface for packet capture, the Berkeley Packet Filter sentation of the parsing rules needed to classify packets. (BPF), was described by Steve McCanne and Van Ja- BPF uses a control flow graph (CFG) to represent the cri- cobson [BPF]. BPF allows network traffic to be cap- teria used to parse a packet. The CFG is translated into tured at a network interface, and the packets classified a BPF machine language program that efficiently prunes and matched via a machine independent assembly pro- paths of the CFG that do not need to be examined during gram that is interpreted inside the kernel. the parsing of a packet. Ultimately, a standard BPF program decides whether 1.1 BPF: An Overview a packet is matched by the program. If a packet is matched by the program, the program copies the spec- BPF is extremely flexible, machine independent, rea- ified amount of data into a buffer, for return to the user sonably high speed, well understood, and widely avail- program. Whether or not the packet was matched, the able on UNIX operating systems. BPF is an interpreted, packet continues on its normal path once the BPF pro- portable machine language designed around a RISC-like gram finishes parsing the packet. LOAD/STORE instruction set architecture that can be efficiently implemented on modern computers. BPF also has a limited facility for sending packets out network interfaces. BPF programs using this fa- BPF only taps network traffic in the network interface cility must bind directly to a particular network inter- driver. One important feature of BPF is that only pack- face, which requires that the program know what inter- ets that are matched by the BPF program are copied into faces exist on the computer. This allows for sending any a new buffer for copying into user space. No copy of type of network packets directly out an interface, with- the packet data needs to be made just to run the BPF out regard to the kernel’s routing table. This is how the program. BPF also allows the program to only copy rarpd and dhcpd daemons work on many types of enough of a packet to satisfy its needs without wasting UNIX computers. time copying unneeded data. For example, 134 bytes is sufficient to capture the complete Ethernet, IP, and TCP BPF, as originally described, does not have a facil- headers, so a program interested only in TCP statistics ity for rejecting packets that have been received. BPF, capabilities would allow for a single BSD/OS computer although described as a filter, can match packets, copy acting as a router to protect any other computers behind them into other memory, and send packets, but it cannot the filter. drop or reject them. 3 Need for Flexibility 2 Motivation An early design decision for IPFW was that the sys- tem should present as flexible a matching and filtering The need for a powerful and flexible packet matching framework as possible. As few filtering rules as possi- and filtering language had been evident for a long time. ble should be directly embedded in the kernel. As much The basic ideas for the BSD/OS IPFW system were the as possible, filtering configuration and policy should be result of several years of thought about what features and installed into the kernel at runtime, rather than compiled functions a packet filtering system must provide. Having into the system. This decision has reaped many bene- highly flexible packet filtering for an end system would fits during the lifetime of this system. Because IPFW be mandatory, and that same filtering system should be is extremely flexible, it has been applied to many prob- applicable for filtering traffic that was being forwarded lems that were not in mind at the time it was designed. through a computer. To borrow Robert Scheifler’s quote about the X Window The immediate need for a flexible packet filtering System Protocol, IPFW is “intended to provide mecha- framework came from a desire to run an IRC client in nism, not policy.” [RFC1013] a rigidly controlled environment. This environment con- sisted of a daemon that could be run in a chroot’d direc- 4 Other Packet Filters tory structure, as well as a highly restrictive set of packet As was noted earlier, there were several other packet filters. These filters could not just prevent unwanted filtering technologies when IPFW was first envisioned. inbound packets, but perhaps more importantly, could In the years since, other filtering technologies have been also discard unwanted outbound packets. The BSD/OS developed, some specific to a particular operating sys- IPFW system was thus originally intended to filter both tem and others available on a variety of platforms. A the inbound and outbound traffic for a particular host. comparative analysis with these other packet filters al- Many of the most popular contemporary packet fil- lows one to more fully appreciate the flexibility of IPFW. tering systems of the initial design era (circa 1995) One of the most important differences between IPFW were incapable of filtering packets destined for the lo- and these other filtering systems is that IPFW actually cal computer or originating from the local computer. downloads complete programs to be evaluated against The available filtering systems concentrated on filtering the packets. The other filtering systems are all rules- traffic that was being forwarded through the computer. based. By evaluating an arbitrary program, an entirely Other major problems with the existing packet filter- new methodology of packet filtering can be installed ing systems were the inability to do significant stateful without rebooting the system. In a rules based system, packet forwarding and unacceptably low performance any new type of rules requires code changes to the fil- [screend]. screend does keep track of IP fragments, tering system, as well as a reboot to make it active. Dy- which is a limited form of stateful packet filtering. namic loadable kernel modules can approximate the pro- Further motivation for a flexible packet filtering sys- gram download facility as modules could be replaced tem was the lack of any other standard packet filtering with new filtering rule capabilities without requiring a in the stock BSD/OS system of that era. There was system reboot. customer demand for a bundled packet filtering system, which was not fully met by the other widely available 4.1 Darren Reed’s ipfilter packet filtering systems [ipfilter]. screend,themost The ipfilter package is available on many versions of widely available contemporary packet filtering system, many UNIX-like operating systems, from BSD/OS to provided many good lessons in packet filtering technol- older systems such as IRIX to small-footprint systems ogy. The BSD/OS IPFW system was designed with the like QNX to frequently updated systems like FreeBSD. lessons learned from screend in mind. It supports packet filtering, provides a Network Ad- A consideration for the implementation of a new, dress Translation (NAT) implementation, and can per- flexible packet filtering framework was the realization form stateful packet filtering via an internal state table. that as the Internet grew, the number of attacks from Like the other examined packet filters, ipfilter is a rules other locations on the Internet would also grow. Hav- based system. It can log packet contents to the pseudo- ing a powerful matching language tied to the filtering device “ipl.” [ipfilter] [ipfilterhowto] 4.2 FreeBSD’s ipfirewall System it does not have an established track record, and is still undergoing change.

Load more

  13

Copy Link