On 2022-12-27, Otto Moerbeek wrote:
> On Tue, Dec 27, 2022 at 04:23:13AM +, Shadrock Uhuru wrote:
>
>> hi everyone
>> viewing my pf logs with
>> tcpdump -nettt -i pflog0 there are lines with no rule numbers
>> just rule def on the line instead,
>> i've tried googling without success,
>> need to know if they are wolf,sheep or misconfigurations causing them,
>> and against which rule do i match them up with.
>>
>> the following is a snippet showing the rules
>> thanks shadrock
>>
>> Dec 27 03:00:40.557716 rule 7/(match) block in on em0: 192.168.1.1 >
>> 224.0.0.1: igmp query [tos 0xc0] [ttl 1]
>> Dec 27 03:00:59.495834 rule 35/(match) block in on pppoe0:
>> 167.248.133.160.60037 > 88.97.5.79.12473: S 904362479:904362479(0) win 1024
>>
>> Dec 27 03:00:59.813362 rule def/(match) pass in on pppoe0:
>> 198.252.206.25.443 > 10.2.1.79.13522: P 3251931305:3251931366(61) ack 27080
>> 26055 win 63
>> Dec 27 03:00:59.820893 rule def/(match) pass out on pppoe0:
>> 88.97.5.79.14256 > 198.252.206.25.443: P 4273536371:4273536410(39) ack 334
>> 5204755 win 256 (DF)
>> Dec 27 03:00:59.823015 rule def/(match) pass out on pppoe0:
>> 88.97.5.79.14256 > 198.252.206.25.443: P 39:78(39) ack 1 win 256 > timestamp 380012019 1163664932> (DF)
>> Dec 27 03:00:59.825388 rule def/(match) pass out on pppoe0:
>> 88.97.5.79.14256 > 198.252.206.25.443: P 78:117(39) ack 1 win 256
>> (DF)
>> Dec 27 03:00:59.900318 rule def/(match) pass in on pppoe0:
>> 198.252.206.25.443 > 10.2.1.79.13522: . ack 40 win 63 > 1163665020 380012019>
>> Dec 27 03:00:59.902502 rule def/(match) pass in on pppoe0:
>> 198.252.206.25.443 > 10.2.1.79.13522: . ack 79 win 63 > 1163665022 380012019>
>> Dec 27 03:00:59.904998 rule def/(match) pass in on pppoe0:
>> 198.252.206.25.443 > 10.2.1.79.13522: . ack 118 win 63 > 1163665024 380012019>
>> Dec 27 03:01:03.661072 rule 35/(match) block in on pppoe0:
>> 45.64.84.24.27789 > 88.97.5.79.23: S 1482753359:1482753359(0) win 30613 > 1440>
>> Dec 27 03:01:11.480942 rule 35/(match) block in on pppoe0:
>> 205.185.127.238.40598 > 88.97.5.79.60001: S 1843251311:1843251311(0) win
>> 65535
>> Dec 27 03:01:11.935746 rule 7/(match) block in on bge0: 0.0.0.0 >
>> 224.0.0.1: igmp query [len 12] [tos 0xc0] [ttl 1]
>> Dec 27 03:01:25.422772 rule 38/(match) pass in on pppoe0:
>> 145.131.132.84.443 > 10.2.1.79.42434: P 5666:5697(31) ack 1264 win 244
>>
>> Dec 27 03:01:25.422795 rule 38/(match) pass in on pppoe0:
>> 145.131.132.84.443 > 10.2.1.79.42434: F 5697:5697(0) ack 1264 win 244
>>
>> Dec 27 03:01:25.424055 rule 38/(match) pass out on pppoe0: 88.97.5.79.8748
>> > 145.131.132.84.443: . ack 5698 win 255 > 3399431690> (DF)
>> Dec 27 03:01:28.600657 rule 37/(match) pass in on pppoe0: 93.184.220.29.80
>> > 10.2.1.79.12939: . ack 481 win 131
>> Dec 27 03:01:28.601419 rule 37/(match) pass out on pppoe0: 88.97.5.79.31263
>> > 93.184.220.29.80: . ack 575 win 256 > 235524325> (DF)
>>
>
> def is the default rule. From pf.conf(5):
>
> Each time a packet processed by the packet filter comes in on or goes out
> through an interface, the filter rules are evaluated in sequential order,
> from first to last. For block and pass, the last matching rule decides
> what action is taken; if no rule matches the packet, the default action
> is to pass the packet without creating a state. For match, rules are
> evaluated every time they match; the pass/block state of a packet remains
> unchanged.
...and: you don't normally want to see this, it means you pass some traffic
without keeping state, which can result in problems with TCP window scaling.
I'd recommend using "block all" or "block log all" at the start of your
ruleset, then allow whichever traffic you want afterwards, _even if that
is "pass all"_, so you can be sure that all "pass"ed traffic has state
table entries created.
