Changes in pf: Packet Filtering
Pages: 1, 2, 3, 4, 5, 6

Which users (user) and groups (group) are allowed to receive or send packets?

One very handy feature of pf(4) is its ability to filter packets based on user and group names of the users and groups who own the sockets on which packets are sent or received. The user and group IDs can be given in form of names or numbers and it is possible to specify ranges and lists of IDs. When you list ranges, it is possible to construct them using the operators described earlier in the section on source ports.

The user and group names are effective names, which may not be the same as the real name (as is the case with setuid and setgid processes). If you are having problems with these rules, remember that the user and group IDs are stored at the time a socket is created and they are not updated when the process creating a socket drops privileges (e.g., after a process binds to a privileged port as root, and then drops root privileges), so it may be that you need to use root ID in a rule instead of an unprivileged users's ID. Try this when you hit a stumbling block with rules user or group

In case of outgoing connections, the user IDs will match the user that opened the connection from the firewall itself. Similarly, for incoming connections, the user IDs will match the user that opened the socket for listening on the firewall. It is not possible to match usernames on connections forwarded with NAT rules. In case of forwarded connections, user or group IDs can match (or not match) a special username unknown. In this case, only two operators are allowed: = and !=.

Hint: User and group rules can only be used with TCP and UDP protocols.

Which TCP flags are allowed (flags)?

TCP packet headers contain a flag field which plays an important role in the process of establishing, maintaining, and closing connections. Flags are important from the point of view of security, because some attackers abuse the three-way-handshake mechanism and other uses of TCP flags in denial of service (DOS) attacks (see CERT-1996.21, CERT-2000.21) and other types of attacks aimed at hosts connected to the Internet.

As of OpenBSD 3.2, pf(4) recognizes the following TCP header flags:

• (S)YN: synchronize sequence numbers
• (A)CK: acknowledge
• (R)ST: reset
• (F)IN: finish
• (P)USH: push
• (U)RG: urgent pointer
• (E)CE: (ECN-Echo) explicit congestion notification echo
• C(W)R: congestion window reduced

The syntax for this portion of filtering rules is as follows: the flags keyword is followed by two lists of flags separated with a slash (/); the first is a list of flags from the second list that must be set. Those flags not on the first list must be unset. Flags not listed on the second list are ignored, and those flags from the second list missing from the first list may or may not be set.

# FIN must be set, ignore the rest
block in proto tcp all flags F/F

# FIN must be unset, ignore the rest
block in all flags /F 

# FIN must be set, the rest must be unset
block in all flags F 

# FIN must be set, ACK must be unset, ignore the rest
block in all flags F/FA

# FIN and ACK must be unset, ignore the rest
block in all flags /FA

TCP flags are described in RFC761 [Postel 1980], and RFC793 [Postel 1981]. A far more detailed discussion of TCP flags can be found in [Stevens, Wright 1994]. Note that [Stevens, Wright 1994] do not describe the ECE and CWR flags, as these were added to the TCP header after TCP/IP Illustrated was published. For more information on ECE and CWR read RFC3168 [Ramakrishann, Floyd, Black 2001] and RFC3360 [Floyd 2002].

The flags keyword makes sense only for TCP (proto tcp) packets.

Are you going to allow ICMP packets?

Bogus ICMP packets are another way attackers can make your site inoperable, which is why pf(4) has special syntax for dealing with these useful, but potentially dangerous packets. For more information about the havoc ICMP packets can wreak read this paper (pdf) from SANS [Jeon 2001] and the CERT-1996.26 advisory.

ICMPv4 packets are matched by icmp-type keyword, while ICMP IPv6 are matched by the ipv6-icmp-type keyword. Both keywords are followed by the ICMP type number and the ICMP code number, separated with the code keyword.

Explanations of ICMPv4 message types and codes can be found in RFC792 [Postel 1981], ICMPv6 message types and codes are discussed in RFC2463 [Conta, Deering 1998].

Pages: 1, 2, 3, 4, 5, 6

Next Page