The next two features we’ll discuss, scrub and antispoof, share a common theme: They provide automated protection against potentially dangerous clutter in your network traffic. Together, they are commonly referred to as tools for “network hygiene,” because they sanitize your networking considerably.
In PF versions up to OpenBSD 4.5 inclusive, the scrub keyword enables network traffic normalization. With scrub, fragmented packets are reassembled, and invalid fragments such as overlapping fragments are discarded, so the resulting packet is complete and unambiguous.
Enabling scrub provides a measure of protection against certain kinds of attacks based on incorrect handling of packet fragments.[45] A number of supplementing options are available, but the simplest form is suitable for most configurations.
scrub in
In order for some services to work with scrub, specific options must be set. One commonly cited example is some NFS implementations, which will not work with scrub at all unless you use the no-df parameter to clear the do not fragment bit on any packets that have the bit set. Some combinations of services, operating systems, and network configurations may require some of the more exotic scrub options.
In OpenBSD 4.6, scrub was demoted from stand-alone rule material to become an action you could attach to pass or match rules (the introduction of match rules being one of the main new PF features in OpenBSD 4.6). One other important development in the same rewrite of the scrub code was that the numerous packet-reassembly options were eliminated in favor of the new reassemble option, which simply turns reassembly on or off.
With the new scrub syntax, you need to supply at least one option in parentheses. The following works quite well for several networks in my care:
match in all scrub (no-df max-mss 1440)
This clears the do not fragment bit and sets the maximum segment size to 1440 bytes.
Other variations are possible, and even though the list of scrub options shrank somewhat for the OpenBSD 4.6 version, you should be able to cater to various specific needs by consulting the man pages and doing some experimentation.
If you find yourself needing to debug a scrub-related problem, study the pf.conf man page and consult the gurus on the relevant mailing lists.
There are some very useful and common packet-handling actions that could be written as PF rules, but not without becoming long, complicated, and error-prone rule set boilerplate. Thus, antispoof was implemented for a common special case of filtering and blocking. This mechanism protects against activity from spoofed or forged IP addresses, mainly by blocking packets that appear on interfaces traveling in directions that are not logically possible.
With antispoof, you can specify that you want to weed out spoofed traffic coming in from the rest of the world and any spoofed packets that (however unlikely) were to originate in your own network. Figure 9-1 illustrates the concept.
To establish the kind of protection depicted in the diagram, specify antispoof for both interfaces in the illustrated network with these two lines:
antispoof for $ext_if antispoof for $int_if
These lines expand to complex rules. The first one blocks incoming traffic when the source address appears to be part of the network directly connected to the antispoofed interface but arrives on a different interface. The second rule performs the same functions for the internal interface, blocking any traffic with apparently local network addresses that arrive on other interfaces than $int_if. However, keep in mind that antispoof is not designed to detect address spoofing remotely for networks that are not directly connected to the machine running PF.
[45] Some notable attack techniques, including several historical denial-of-service setups, have exploited bugs in fragment handling that could lead to out-of-memory conditions or other resource exhaustion. One such exploit, which was aimed at Cisco’s PIX firewall series, is described in the advisory at http://www.cisco.com/en/US/products/products_security_advisory09186a008011e78d.shtml.