Some of the random stuff that arrives at a host is garbage. If a packet is shorter than the IP header, it can’t be a real IP packet, and if a TCP packet is too short to include a full TCP header, it can’t be a real packet.

If the packet length doesn’t match the length given in the header, it’s somehow corrupt. PF has no way to figure out where these packets came from, or if they’re maliciously damaged or just corrupted in transit. Since the kernel can’t do anything with them, PF automatically drops them.

Before the packet filter can decide how to handle a packet, the packet should be free of ambiguities and random weirdness. Reassembly cleans up these ambiguities, and the default reassembly settings are suitable for most environments. You get reassembly when you enable PF.

Sometimes you need to modify packets. These days, PF handles everything for most environments. If you need to modify packets, such as clearing the “do not fragment” bit on fragmented UDP packets, see the scrub keyword in pf.conf(5).

Another classic IP attack is sending packets that appear to come from the private network to a firewall, in an attempt to evade the packet filter. Most firewalls today block this type of attack, so attackers rarely bother, but you should still protect against spoofed attacks. Just because everyone else has had their measles shot doesn’t mean you should go without one.

For an antispoofing rule, use antispoof for and an interface name.

antispoof for fxp0

When fed into the packet filter, the rules would look something like this:

block drop in on ! fxp0 inet from 192.0.2.5/28
block drop in inet from 192.0.2.5 set ( prio 0 )

The first rule drops any traffic that arrives from an address local to interface fxp0 on any interface other than fxp0. Packets from an address local to interface fxp0 should always arrive on your system via fxp0.

The second rule drops any traffic that comes from the address of interface fxp0. Packets with that source address should never arrive from the outside world. If the system needs to communicate with itself, it uses interface lo0.

You could use interface groups instead of interface names, but I don’t recommend doing so. If you have multiple egress interfaces, using antispoofing rules on the egress group won’t block outside packets that arrive at the wrong egress interface. Take the time to enumerate your interfaces in your antispoofing rules.

Instead of listing a single interface, you can also use a list or a macro.

antispoof for {lo0, fxp0, em0}

Antispoofing rules can mess with packets passed over the loopback interface. I recommend skipping filtering on lo0, although PF includes special built-in protection for 127.0.0.0/8 addresses.

Now that you have basic packet filtering, let’s consider some of PF’s core settings.