[Previous: Traffic Redirection] [Contents] [Next: Logging]
Filter rules specify the criteria that a packet must match and the resulting action, either block or pass, that is taken when a match is found. Filter rules are evaluated in sequential order, first to last. Unless the packet matches a rule containing the quick keyword, the packet will be evaluated against all filter rules before the final action is taken. The last rule to match is the "winner" and will dictate what action to take on the packet. There is an implicit pass all at the end of a filtering ruleset meaning that if a packet does not match any filter rule the resulting action will be pass.
action direction [log] [quick] on int [af] [proto protocol] \
from src_addr [port src_port] to dst_addr [port dst_port] \
[tcp_flags] [state]
To create a default deny filter policy, the first two filter rules should be:
block in all
block out all
This will block all traffic on all interfaces in either direction from anywhere to anywhere.
Some examples:
# Pass traffic in on dc0 from the local network, 192.168.0.0/24,
# to the OpenBSD machine's IP address 192.168.0.1. Also, pass the
# return traffic out on dc0.
pass in on dc0 from 192.168.0.0/24 to 192.168.0.1
pass out on dc0 from 192.168.0.1 to 192.168.0.0/24
# Pass TCP traffic in on fxp0 to the web server running on the
# OpenBSD machine. The interface name, fxp0, is used as the
# destination address so that packets will only match this rule if
# they're destined for the OpenBSD machine.
pass in on fxp0 proto tcp from any to fxp0 port www
Keeping state has many advantages including simpler rulesets and better packet filtering performance. PF is able to match packets moving in either direction to state table entries meaning that filter rules which pass returning traffic don't need to be written. And, since packets matching stateful connections don't go through ruleset evaluation, the time PF spends processing those packets can be greatly lessened.
When a rule has the keep state option, the first packet matching the rule creates a "state" between the sender and receiver. Now, not only do packets going from the sender to receiver match the state entry and bypass ruleset evaluation, but so do the reply packets from receiver to sender. For example:
pass out on fxp0 proto tcp from any to any keep state
This allows any outbound TCP traffic on the fxp0 interface and also permits the reply traffic to pass back through the firewall. While keeping state is a nice feature, its use significantly improves the performance of your firewall as state lookups are dramatically faster than running a packet through the filter rules.
The modulate state option works just like keep state except that it only applies to TCP packets. With modulate state, the Initial Sequence Number (ISN) of outgoing connections is randomized. This is useful for protecting connections initiated by certain operating systems that do a poor job of choosing ISNs.
Keep state on outgoing TCP, UDP, and ICMP packets and modulate TCP ISNs:
pass out on fxp0 proto tcp from any to any modulate state
pass out on fxp0 proto { udp, icmp } from any to any keep state
Another advantage of keeping state is that corresponding ICMP traffic will be passed through the firewall. For example, if keep state is specified for a TCP connection and an ICMP source-quench message referring to this TCP connection arrives, it will be matched to the appropriate state entry and passed through the firewall.
It's important to note that stateful connections are limited to the interface they were created on. This is particularly important on routers and firewalls running PF, especially when a "default deny" policy is implemented as outlined above. If a firewall is keeping state on all outgoing connections on the external interface, those packets must still be explicitly passed through the internal interface.
Note that nat, binat, and rdr rules implicitly create state for matching connections as long as the connection is passed by the filter ruleset.
To have PF inspect the TCP flags during evaluation of a rule, the flags keyword is used with the following syntax:
flags check/mask
The mask part tells PF to only inspect the specified flags and the check part specifies which flag(s) must be "on" in the header for a match to occur.
pass in on fxp0 proto tcp from any to any port ssh flags S/SA
The above rule passes TCP traffic with the SYN flag set while only looking at the SYN and ACK flags. A packet with the SYN and ECE flags would match the above rule while a packet with SYN and ACK or just ACK would not.
Note: in previous versions of OpenBSD, the following syntax was supported:
. . . flags S
This is no longer true. A mask must now always be specified.
Flags are often used in conjunction with keep state rules to help control the creation of state entries:
pass out on fxp0 proto tcp all flags S/SA keep state
This would permit the creation of state on any outgoing TCP packet with the SYN flag set out of the SYN and ACK flags.
One should be careful with using flags -- understand what you are doing and why, and be careful with the advice people give as a lot of it is bad. Some people have suggested creating state "only if the SYN flag is set and no others". Such a rule would end with:
. . . flags S/FSRPAUEW bad idea!!
The theory is, create state only on the start of the TCP session, and the session should start with a SYN flag, and no others. The problem is some sites are starting to use the ECN flag and any site using ECN that tries to connect to you would be rejected by such a rule. A much better guideline is:
. . . flags S/SAFR
While this is practical and safe, it is also unnecessary to check the FIN and RST flags if traffic is also being scrubbed. The scrubbing process will cause PF to drop any incoming packets with illegal TCP flag combinations (such as SYN and FIN or SYN and RST). It's highly recommended to always scrub incoming traffic:
scrub in on fxp0
.
.
.
pass in on fxp0 proto tcp from any to any port ssh flags S/SA \
keep state
Wrong:
block in on fxp0 proto tcp from any to any port ssh
pass in all
In this case, the block line may be evaluated, but will never have any effect, as it is then followed by a line which will pass everything.
Better:
block in quick on fxp0 proto tcp from any to any port ssh
pass in all
These rules are evaluated a little differently. If the block line is matched, due to the quick option, the packet will be blocked, and the rest of the ruleset will be ignored.
PF offers some protection against address spoofing through the antispoof keyword:
antispoof [log] [quick] for interface [af]
Example:
antispoof for fxp0 inet
When a ruleset is loaded, any occurrences of the antispoof keyword are expanded into two filter rules. Assuming that interface fxp0 has IP address 10.0.0.1 and a subnet mask of 255.255.255.0 (i.e., a /24), the above antispoof rule would expand to:
block in on ! fxp0 inet from 10.0.0.0/24 to any
block in inet from 10.0.0.1 to any
These rules accomplish two things:
NOTE: The filter rules that the antispoof rule expands to will also block packets sent over the loopback interface to local addresses. These addresses should be passed explicitly. Example:
pass in quick on lo0 all
antispoof for fxp0 inet
Usage of antispoof should be restricted to interfaces that have been assigned an IP address. Using antispoof on an interface without an IP address will result in filter rules such as:
block drop in on ! fxp0 inet all
block drop in inet all
With these rules there is a risk of blocking all inbound traffic on all interfaces.
pass in quick on fxp0 all allow-opts
ext_if = "fxp0" int_if = "dc0" lan_net = "192.168.0.0/24" # scrub incoming packets scrub in all # setup a default deny policy block in all block out all # pass traffic on the loopback interface in either direction pass quick on lo0 all # activate spoofing protection for the internal interface. antispoof quick for $int_if inet # only allow ssh connections from the local network if it's from the # trusted computer, 192.168.0.15. use "block return" so that a TCP RST is # sent to close blocked connections right away. use "quick" so that this # rule is not overridden by the "pass" rules below. block return in quick on $int_if proto tcp from ! 192.168.0.15 \ to $int_if port ssh flags S/SA # pass all traffic to and from the local network pass in on $int_if from $lan_net to any pass out on $int_if from any to $lan_net # pass tcp, udp, and icmp out on the external (Internet) interface. # keep state on udp and icmp and modulate state on tcp. pass out on $ext_if proto tcp all modulate state flags S/SA pass out on $ext_if proto { udp, icmp } all keep state # allow ssh connections in on the external interface as long as they're # NOT destined for the firewall (ie, they're destined for a machine on # the local network). log the initial packet so that we can later tell # who is trying to connect. pass in log on $ext_if proto tcp from any to { !$ext_if, !$int_if } \ port ssh flags S/SA keep state |
[Previous: Traffic Redirection] [Contents] [Next: Logging]