Which users (
user) and groups (
group) are allowed
to receive or send packets?
One very handy feature of
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:
Hint: User and group rules can only be used with TCP and UDP protocols.
Which TCP flags are allowed (
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,
recognizes the following TCP header flags:
(S)YN: synchronize sequence numbers
(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
# 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].
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
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
ICMPv4 packets are matched by
icmp-type keyword, while
ICMP IPv6 are matched by the
Both keywords are followed by the ICMP type number and the ICMP code
number, separated with the