2024-07-23
Seeing and matching pf rules when using tcpdump on OpenBSD's pflog interface
Last year I wrote about some special tcpdump filtering options
for OpenBSD's pflog interface, including the
'rnr <number>' option for matching and showing only packets blocked
by a specific rule. You might want to do this if, for example, you
temporarily throw brute force attacker IPs into a table and want
to take them out soon after they stop hitting you.
Assuming that you're watching live, the way you do this is to find
the rule number with 'pfctl -vv -s rules | grep @ | grep <term>'
for a suitable term, such as the table name (or look through the
whole thing with a pager), and then run 'tcpdump -n -i pflog0 "rnr
<number>"'. However, looking up rule numbers is annoying and a
clever person might remember that the OpenBSD tcpdump can print the pf rule information
for pflog packets, through the '-e' option (for pflog, this is
considered the link-level header). So you might think that the easy
way to achieve what you want is 'tcpdump -n -i pflog0 | grep
<term>', which is to say you're dumping all pflog packets and then
picking out the ones that matched your rule.
Unfortunately, the pflog 'link-level header' doesn't actually tell you this. What it has is the rule number, whether the packet was blocked or not (you can log without blocking), which direction the block was (in or out), and what interface (plus that the packet was blocked because it matched a rule):
21:20:43.525222 rule 231/(match) block in on ix1: [...]
Quite sensibly, you don't get the actual contents of the rule that blocked the packet, so you can't grep for it and my clever idea was not so clever. If you read all the way to the Link Level Headers section of the OpenBSD tcpdump manual page, it explicitly tells you this:
On the packet filter logging interface pflog(4), logging reason (rule match, bad-offset, fragment, bad-timestamp, short, normalize, memory), action taken (pass/block), direction (in/out) and interface information are printed out for each packet.
So don't be like me and waste your time with the 'grep the tcpdump output' approach. It isn't going to work and you're going to have to do it the hard way.
As far as I know there's no way to attach some sort of marker to rules in your pf.conf that will make them easy to pick out in pflog(4) packets. Based on the pflog(4) manual page, the packet format just doesn't have room for that. If you absolutely need to know this sort of thing for sure, even over rule changes, I think your only option is to log the packets to a non-default pflog(4) interface and then arrange for something to receive and store stuff from that interface.