The very, very first rule in my pf ruleset is part of a fairly vanilla
anti-spoof/sanity check set, intended to catch incoming bogon/martian
packets:
table <unroutable_ips> const { 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16, !$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4, 255.255.255.255/32
}
block drop in log quick on ! lo0 inet from <unroutable_ips> to any
label "block unroutable ip"
I can see it being evaluated using "pfctl -v -s rules", but so far
(~40hrs uptime) it hasn't matched anything yet. That would normally
not be of concern, except I'm seeing stuff like this in the pflog that
I think it should have caught - but had to get caught by a later,
fail-safe rule at the bottom of the ruleset. In particular, I'm seeing
lots of bootp packets from badly-configured Windows clients:
Mar 26 19:22:05.85 rule 49/(match) [uid 0, pid 2590] block in on
em0: 0.0.0.0.68 > 255.255.255.255.67: xid:0x64f14f [|bootp] (DF) [tos
0x10] (ttl 64, id 0, len 330)
So:
- Is there something wrong with my first rule that I'm not seeing that
causes these 0.0.0.0 bootp packets to miss it, OR
- Is there something special about the bootp packets [remember, bootp
uses UDP] that they won't match that rule, even though the source is
in the unroutable_ips table?
Thanks for any insight, or other debugging ideas I can test.
/d/
PS: Notice the "quick" keyword in the block rule - this isn't a "last
rule that matches" issue, in case you're tempted to reply with
something about that - I would think a packet from 0.0.0.0 should hit
the rule, match, and then due to "quick" undergo no further
evaluation, end of story.
