Hi,
here is the setup ( I saw this on 5.0, 5.1, 5.1-current).
On a fresh installation.
/etc/pf.conf:
block log all
I send to the machine an UDP packet to port 0. I used from another machine:
nmap -Pn -sU -pU:0 target_ip
pf will log the packet as pass.
... rule def/(short) pass in on ...
I tried to debug the code.
I see the packet is dropped (pf_test() returns PF_DROP), but
pflog_packet() doesn't know it.
Here is what I saw:
in net/pf.c:6557 pf_setup_desc() decides to return (PF_DROP); because
uh->hu_dport==0. (reason PFRES_SHORT).
in net/pf.c:6716: action = pf_setup_desc(); is set and goto done;
then in net/pf.c:6954
PFLOG_PACKET(&pd, reason, r, a, ruleset) is called.
pflog_packet() gets the 'reason' code, but doesn't get the 'action'
value set in net/pf.c:7616, also there is no rule match ( goto done;
right after setting action=PF_DROP), so 'r' still points to
pf_default_rule (which has a default PF_PASS).
The outcome is: I read a pass in the logs, while the packet is blocked
instead.
I tried to think to possible solutions, but this is the first time I
look into the OpenBSD kernel, so I'm just not aware of the code
interconnections and how things should be.
For example: why UDP destintation port 0 doesn't match 'block log all'
rule in the first place?
Anyway I say what I think:
- could it be possible to add the 'action' variable to pflog_packet()
arguments and then if 'r' points to pf_default_rule, 'action' is considered?
- could make sense specialize the pf_default_rule default action based
on the reason code? ( in this case, PF_SHORT should imply a PF_DROP)
(maybe using a switch(reason) in net/if_pflog.c:233 )
Another thing I noticed; in net/pf.c:6950 happen the logging, but after
that there are other assignments to action. So I suppose there could be
other ways to log a packet as block or pass with a different effective
action.
Leonardo.
