DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 7th August 2022
scottmlew scottmlew is offline
New User
 
Join Date: Aug 2022
Posts: 4
Default pf block rule matches, but doesn't match if changed to pass

I am seeing some behavior from pf that I do not understand.

I have a very simple ruleset:
Code:
block all
block quick log on vmx7 proto icmp
When I use this ruleset and look at pflog0, I see ping packets match the rule as expected:
Code:
Aug 07 16:18:03.188621 rule 1/(match) block in on vmx7: 10.0.60.200 > 10.0.40.10: icmp: echo reply
However, if I change the block to pass, I do not see any matches of the rule. In other words, leaving the same ping running, but with ruleset:
Code:
block all
pass quick log on vmx7 proto icmp
I get no logged rule matches.

How can this be? What am I missing? I distilled down to this example because traffic did not seem to be passing as I understand that it should with my full ruleset.
Reply With Quote
  #2   (View Single Post)  
Old 7th August 2022
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,128
Default

I also don't understand how this is possible.But I don't think it is the complete rule set

The simplest way to find out what gets blocked is to use something like block log (all)

pf.conf(5) describes the other options for logging:

Code:
     log (all | matches | to interface | user)
            The keywords all, matches, to, and user are optional and can be
             combined using commas, but must be enclosed in parentheses if
             given.

             Use all to force logging of all packets for a connection.  This
             is not necessary when no state is explicitly specified.

             If matches is specified, it logs the packet on all subsequent
             matching rules.  It is often combined with to interface to avoid
             adding noise to the default log file.

             The keyword user logs the UID and PID of the socket on the local
             host used to send or receive a packet, in addition to the normal
             information.
You could experiment with those.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #3   (View Single Post)  
Old 7th August 2022
scottmlew scottmlew is offline
New User
 
Join Date: Aug 2022
Posts: 4
Default

Quote:
Originally Posted by J65nko View Post
I also don't understand how this is possible.But I don't think it is the complete rule set
Yes, that is a full ruleset that shows the behavior I am seeing.

Quote:
Originally Posted by J65nko View Post
The simplest way to find out what gets blocked is to use something like block log (all)
In this case, I see my ICMP packets matched by the second rule when it is a block and the first rule (the "block log") when I change the second rule to a pass.
Reply With Quote
  #4   (View Single Post)  
Old 7th August 2022
scottmlew scottmlew is offline
New User
 
Join Date: Aug 2022
Posts: 4
Default

See sample output:

Code:
fw0# cat pf.conf-show-bug                                                                          
block all
block quick log on vmx7 proto icmp
fw0# pfctl -f pf.conf-show-bug                                                                     
fw0# tcpdump -nettt -i pflog0
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
Aug 07 17:12:45.132261 rule 1/(match) block in on vmx7: 10.0.60.200 > 10.0.40.10: icmp: echo reply
Aug 07 17:12:46.132197 rule 1/(match) block in on vmx7: 10.0.60.200 > 10.0.40.10: icmp: echo reply
Aug 07 17:12:47.132325 rule 1/(match) block in on vmx7: 10.0.60.200 > 10.0.40.10: icmp: echo reply
Aug 07 17:12:48.132275 rule 1/(match) block in on vmx7: 10.0.60.200 > 10.0.40.10: icmp: echo reply
^C
4 packets received by filter
0 packets dropped by kernel
fw0# nano pf.conf-show-bug      
fw0# cat pf.conf-show-bug                                                                          
block all
pass quick log on vmx7 proto icmp
fw0# pfctl -f pf.conf-show-bug  
fw0# tcpdump -nettt -i pflog0   
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
^C
0 packets received by filter
0 packets dropped by kernel
fw0# pfctl -f pf.conf
Reply With Quote
  #5   (View Single Post)  
Old 7th August 2022
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,128
Default

Code:
$ doas pfctl -vvf show-bug  

Loaded 714 passive OS fingerprints
@0 block drop all
@1 pass log (all) quick on egress inet proto icmp all icmp-type echoreq

$ ping -c2 192.168.222.10 
PING 192.168.222.10 (192.168.222.10): 56 data bytes
64 bytes from 192.168.222.10: icmp_seq=0 ttl=255 time=0.382 ms
64 bytes from 192.168.222.10: icmp_seq=1 ttl=255 time=0.302 ms

--- 192.168.222.10 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
In another xterm:
Code:
 $ doas tcpdump -eni pflog0
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG

00:52:48.840082 rule 1/(match) pass out on bge0: 192.168.222.242 > 192.168.222.10: icmp: echo request
00:52:48.840430 rule 1/(match) pass in on bge0: 192.168.222.10 > 192.168.222.242: icmp: echo reply
00:52:49.848824 rule 1/(match) pass out on bge0: 192.168.222.242 > 192.168.222.10: icmp: echo request
00:52:49.849088 rule 1/(match) pass in on bge0: 192.168.222.10 > 192.168.222.242: icmp: echo reply
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

Last edited by J65nko; 8th August 2022 at 02:34 AM.
Reply With Quote
  #6   (View Single Post)  
Old 7th August 2022
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,128
Default

Under the heading STATEFUL FILTERING pf.conf(5) states:

Code:
Furthermore, correct handling of ICMP error messages is critical to many
protocols, particularly TCP.  pf(4) matches ICMP error messages to the
correct connection, checks them against connection parameters, and passes
them if appropriate.  For example if an ICMP source quench message
referring to a stateful TCP connection arrives, it will be matched to the
state and get passed.
I think the behaviour you saw when you don't explicitly specify the ICMP type, has something to do with pf's 'smart handling' of ICMP in stateful connections.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #7   (View Single Post)  
Old 8th August 2022
scottmlew scottmlew is offline
New User
 
Join Date: Aug 2022
Posts: 4
Default

Quote:
Originally Posted by J65nko View Post
I think the behaviour you saw when you don't explicitly specify the ICMP type, has something to do with pf's 'smart handling' of ICMP in stateful connections.
Possibly. To eliminate this, I will go back to my real situation, which actually involves TCP (for debugging, I had tried to simplify my situation as much as possible, possibly to my detriment).

I will say that the behavior I was seeing is extremely unintuitive...
Reply With Quote
  #8   (View Single Post)  
Old 8th August 2022
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,128
Default

For testing you can generate manual or scripted TCP traffic with:
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
4.7 pf rule to block traffic from guest network mikesg OpenBSD Security 5 16th August 2015 11:04 AM
PF gets block rules not any pass Arenio OpenBSD Security 1 10th April 2014 11:44 PM
match vs pass (changes in 4.7), and inet vs inet proto mikesg OpenBSD Security 4 12th June 2010 02:35 AM
first match vs last match ruleset design (pf vs iptables) zelut FreeBSD Security 5 12th July 2009 08:13 AM
PF can't match on TOS? ivanatora FreeBSD General 1 15th February 2009 10:34 AM


All times are GMT. The time now is 04:56 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick