Packet filter

The story of PF began in 2000 , when Darren Reed , the developer of the IPFilter firewall used at the time in OpenBSD, changed his license. Then ipf was excluded from the CVS repository, and its place for the release of OpenBSD 3.0 was taken by the PF written from scratch.

OpenBSD 3.3 introduced pfsync , a pseudo-interface that allows you to replicate information about the context of connections between two (and later more) hosts. When using CARP or other similar technology, pfsync allows, in particular, to create fault-tolerant configurations from several physical firewalls: if one host fails, the second will continue to process network traffic without disconnecting.

Initially, PF was pretty similar to IPFilter. A major redesign of interior architecture began in 2005 ^[5] with the efforts of Henning Brower and Ryan McBride . In the framework of this project, PF received support for a new kind of match rules, a new scheme for taking into account the context of connections ( English states in the original terminology). Also, a major change was the rejection of separation of rule sets by type: earlier, PF, like IPFilter, had separate rule sets for NAT and traffic filtering. Also, as part of the overall development of OpenBSD, PF received support for multiple tables and routing domains .

PF consists of two parts: the packet filter itself ^[6] and the pfctl utility, ^[7] which provides an interface for controlling the firewall. The filter works completely in the context of the kernel of the operating system ; interaction with it is carried out through the ioctl system call . ^[8] Therefore, pfctl, strictly speaking, is not a necessary part of PF.

PF was not originally designed for multi-threaded packet processing. On the other hand, the absence of locks has a positive effect on performance.

Optimization

PF can skip unnecessary checks while passing through the list of rules. For example, if two rules in a row apply only to the TCP protocol, then the packet of any other protocol (for example, UDP ), after it does not fit the first rule, will not be checked on the second. To do this, first, when compiling a set of rules pfctl, knowing the most optimal order of checks, can change the mutual order of several consecutive rules; then the prepared set is analyzed when loading in PF and for each rule a transition map is compiled for the mismatch of one or another parameter.

When optimizing the list of rules, PF can also take into account the accumulated statistics of the frequency of checks for rules, and adjust the transition map in accordance with these statistics.

The filter processes network packets in one (when sending a packet from the same computer on which the filter is installed to another computer, or vice versa) or two (when sending inside the computer or when the computer with the filter acts as a network gateway ) processing cycle.

Actually the processing of the package occurs according to a set of rules. At the end of processing, the packet is either discarded or skipped. Each rule consists of a set of conditions and a set of instructions that are executed when the set of conditions is satisfied. There are three types of rules:

match

If the package meets the conditions of the rule, then the instructions from this rule are executed instantly. match rules are commonly used for NAT, traffic logging, QoS, and so on.

block

If the packet does not satisfy the conditions of the rule, then it is marked as subject to blocking. PF allows you to either simply drop the packet or generate an ICMP error message.

pass

If the packet satisfies the conditions of the rule, then it is marked as to be skipped further.

Instructions recorded for block and pass rules are executed after completing a passage through a set of rules. If a corresponding mark is made for a block or pass rule, then if the package satisfies the conditions of this rule, the passage through the set of rules will be interrupted with the corresponding instructions. This order allows you to set a series of rules that gradually narrow the scope, which looks more natural than the reverse order. If no block or pass rule matches, the packet is skipped: this is a measure of protection against accidental errors when configuring a firewall.

Rules may include the following guidelines:

normalization

assembling fragmented packets and discarding deliberately incorrect packets, as well as other operations that simplify further processing;

broadcast

traffic redirection at levels 2 (finer than conventional routing tools can provide) and 3 OSI models , with support for NAT and destination address pools;

prioritization

forced billing of the package service type , placing the package in one or another ALTQ queue;

filtration

making the final decision to skip or block the network packet.

Filtering

PF can filter packets by the following parameters:

• Network address (for TCP and UDP also the port) of the source and destination of the packet
• The network interface (or group thereof) on which the package is processed, as well as on which it originally appeared in the system
• Correctness of the route from which the packet came (yes or no)
• Flags (for TCP)
• Service Type Bits ( ToS )
• ICMP Type and Code (for ICMP and ICMPv6 )
• Package Tags
• Local user ( socket owner)
• Various connection counters
• Probability

The last parameter allows you to create rules that work “sometimes”, which helps to deal with (sometimes unintentional) DDoS attacks .

Tags are assigned by PF rules. Each package can have no more than one tag. A rule can install / replace a tag, but you cannot remove an existing one. The tag is stored in the package for the entire time it passes through the network stack.

PF also allows you to override the routing table used, whereby packets can be transferred between routing domains. Of course, this makes sense only for incoming traffic, for which the route has not yet been determined by standard means.

You can specify labels for rules. One and the same label may correspond to several rules. Labels allow you to better identify rules from user space, as well as disable the built-in optimization of the ruleset for certain rules; the latter may be necessary, for example, for billing systems.

PF not only knows how to filter based on context, but supports three options for working in this mode (terminology from the original documentation):

keep state

simple mode, only matching pairs of network addresses and ports is remembered; This mode is applicable not only to TCP, but also to UDP.

modulate state

a more complex mode in which PF independently selects the initial values ​​of the TCP packet counters; this provides improved protection in cases where one of the parties chooses the values ​​of these counters that are bad in terms of the probability of guessing.

synproxy state

in this mode, PF independently establishes a TCP connection with the other side, and only after that the corresponding packets are sent to the initiator; this provides protection against SYN flood attacks with fake sender addresses.

By default, all pass-rules take into account the context (keep state), while those related to TCP also check the flags of the SYN packet. This is done because it allows you to significantly reduce the volume of rules (both in terms of their number and in terms of their description in the configuration file) in typical situations. At the same time, one can forcibly abandon these possibilities for a specific rule or their entire set. It should also be borne in mind that if a packet does not fall under any pass-rule, then no checks and context creation occurs.

One of the most interesting features of PF is working with address tables:

• Tables can contain both IPv4 and IPv6 addresses, together with a subnet mask for each;
• Entries in the table may be marked as an exception, which allows you to briefly describe a complex topology (see below);
• A table search is faster than a linear search on a set of addresses (and much faster than iterating over rules that differ only in addresses in the same parameter);
• Tables can be arbitrarily changed without having to reload rules;
• For each record in the table statistics can be kept;
• Using the overload filtering option, addresses that exceed certain restrictions on the number of connections can be placed in the selected table;
• Entries in tables can be automatically deleted upon reaching the specified time of their existence.

For example, in a table you can enter all private addresses ^{[9] [10] [11]} into a single table and then block attempts to connect from the outside from supposedly these addresses with just one rule.

Moreover, by using the notes on the exclusion of addresses (address ranges), you can specify the following configuration in only three entries in the table: the table includes the range 10.0.0.0/8 , except 10.0.3.192/26 , plus 10.0.3.211 also included. The corresponding entries in the table can be entered in any order, PF will use them in accordance with their prefixes (subnet mask).

Third-party programs through the ioctl system call or by calling the pfctl program can manage the contents of tables. For example, a dhcpd DHCP server from OpenBSD supports the use of up to three PF tables:

• table where IP addresses of new DHCP clients are added
• table from which exempted IP addresses are deleted
• table that maintains a list of temporarily banned IP addresses

Rules can be combined into blocks ( anchors in the original documentation). In this case, it is possible to set general parameters for each block that will be valid for all the rules in the block.

Blocks are processed on a par with the rules and can be nested together. Moreover, the contents of the blocks can be changed independently of each other, as well as from the general list of rules. The latter, in fact, is the same block.

Rule blocks are convenient for use in programs that somehow control traffic flows. Examples of programs:

• relayd , a proxy server for organizing automatic control of the list of running backend servers;
• authpf , a UNIX command shell that allows you to control access to network resources using user authentication through SSH .

• Michael Lucas Absolute OpenBSD . - No Starch Press , 2003 .-- 500 p. - ISBN 1-886411-99-9 . Archived July 24, 2003. Archived July 24, 2003 on the Wayback Machine
• Jacek Artymiak ( English Jacek Artymiak ). Building Firewalls with OpenBSD and PF. - 2nd ed. - No Starch Press , 2003 .-- 320 p. - ISBN 83-916651-1-9 .
• Brandon Palmer, Jose Nazario. Secure Architectures with OpenBSD. - Addison-Wesley Professional , 2004 .-- 520 p. - ISBN 0-321-19366-0 .

• A more complete list of books is available on the corresponding page of the OpenBSD website .
• Translation of a book about PF. The second edition is available here or here (inaccessible link) .

• Official documentation
• FreeBSD Handbook: PF, OpenBSD Firewall
• FreeBSD, OpenBSD, NetBSD, DragonFly Tutorial (BSDA Q & A): fw