Practical Guide to Software Quality Management (Artech House Computing Library)

 < Day Day Up > 

The BSD-based operating systems make great platforms for firewalls. However as we have seen already, there are usually important differences between FreeBSD and OpenBSD that will affect your decision regarding which one to choose. Firewalls are no different.

8.3.1. IPFW

FreeBSD's primary firewall is called IPFW (Internet Protocol Firewall). IPFW is composed of two parts: a kernel-level packet filter engine and a userland utility for controlling firewall functionality. IPFW has been part of FreeBSD since FreeBSD 2.0. During the summer of 2002, however, IPFW went through a major overhaul as part of FreeBSD 5 development. This "new" IPFW became known as IPFW2. However, for the sake of sanity, we will refer to IPFW2 simply as IPFW.

8.3.2. PF

OpenBSD utilizes a firewall mechanism called PF (packet filter). Like FreeBSD's IPFW, PF is made up of a kernel-level packet filter and a userland utility for control of the firewall functionality. Unlike FreeBSD, PF is exposed via a device node, /dev/pf.

PF is a newcomer to the OpenBSD world. For a number of years, OpenBSD utilized a firewall called IPFilter. In 2001, however, the author of IPFilter had a licensing dispute with the maintainers of OpenBSD. The end result was that IPFilter was removed from OpenBSD, and a new packet filter had to be developed. PF was created to fill the void left by IPFilter. PF has been designed from day one to integrate cleanly into OpenBSD, and as such, is very usable and flexible.

There is also a port of PF to FreeBSD for those that prefer PF functionality to that offered in IPFW. However, like OpenSSH, PF is an OpenBSD project primarily and ports to other operating systems are a secondary concern. Therefore some PF functionality available in the latest release of OpenBSD may not exist yet in the FreeBSD PF. Prior to FreeBSD 5.2.1, PF was available in the ports tree. With the release of FreeBSD 5.3, PF is included in the core operating system.

8.3.3. Differences

There are major differences between IPFW and PF. From an administration perspective, the first thing you'll notice is that IPFW is list-based while PF is much more object-oriented. A PF configuration is broken into many different parts, while IPFW configurations are generally shell scripts with rules processed in order. Both firewalls support stateful and stateless processing of connections.

In IPFW, the first rule in a ruleset that matches a packet "wins." That means, if a ruleset has a rule to allow traffic to port 80 before a rule that denies all traffic, the packet destined to port 80 will be allowed. In PF, the exact opposite is true; the last rule that matches "wins." In the same example, the packet to port 80 would be denied by the firewall. While counterintuitive at first, this functionality actually lends itself to very complex yet readable configurations. If you really need to have a packet match a rule and then be processed in PF, you can use the quick keyword to force the issue.

In IPFW, denied packets are logged through the syslog facility. In PF, denied packets are logged to a special interface called pflog0. This interface is actually a BPF (Berkeley Packet Filter) interface that allows utilities like tcpdump(8) to sniff logged packets directly. This feature can be used by IDS engines and monitoring tools to analyze the firewall's activity without having to directly interact or affect the firewall processing.

PF implements Network Address Translation (NAT) and Quality of Service (QoS) directly into the firewall. In IPFW, these features are provided by userland programs. There are pros and cons to each approach, but in general, there is no functional difference. The integration in PF makes administration a bit easier as all configuration is done in one file.

Network Address Translation

Network Address Translation is a mechanism for many IP addresses behind a network device to share a smaller number of addresses (usually one) on the other side. NAT was originally created as a mechanism for IP address conservation. For instance, your ISP would give you only one IP address, but using NAT you can have many hosts online behind your router going to the ISP. All the internal IP addresses get translated to the one IP address on the other side, and the router or firewall keeps track of whose traffic belongs to whom.

Over the years, NAT has also taken on a security slant. NAT allows security engineers to "hide" a network behind one IP address, nearly completely limiting an external attacker's ability to connect to internal hosts. While some would argue the security advantages versus a normal, non-NATing firewall, the utility of NAT has proven itself over the years.

Under the hood, PF performs more aggressive optimization than IPFW. In PF, large lists of rules are compressed into a table. So while the configuration file for PF may still have list-like properties, the core processing engine of PF treats the rules in a more efficient manner. This ultimately results in a tree data-structure for the rules making even huge rulesets rapidly searchable.

Finally, PF has the capability to force reassembly and normalization of fragmented packets before sending them through the firewall. This prevents fragmentation attacks behind the firewall. This is a very convenient feature, as it prevents other applications on the firewall (such as an IDS sensor) from having to deal with fragments.

It may seem that PF is the weapon of choice when building a firewall. If you need the flexibility and scalability that PF offers, it is definitely a worthy firewall. However, for smaller-scale deployments, such as a small or home office, IFPW's simple interface and straightforward administration may be a better bet.

     < Day Day Up > 
    Related

    Категории