DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 2nd October 2008
schrodinger's Avatar
schrodinger schrodinger is offline
Fdisk Soldier
 
Join Date: May 2008
Location: Ireland
Posts: 69
Default PF Blocking

Was checking to see what traffic was being blocked by my PF ruleset. Firstly here is a quick diagram of my LAN at home.



Noticed that the odd packet from my laptop was being blocked:

Code:
Oct 02 17:05:03.931875 rule 7/(match) block in on ral0: 192.168.1.125.36105 > 207.46.27.19.1863: [|tcp]
However I have "pass quick on $INTIF all" in my ruleset so unsure why this is being blocked.
__________________
It was a new day yesterday, but it's an old day now.

Last edited by schrodinger; 10th October 2009 at 04:32 PM.
Reply With Quote
  #2   (View Single Post)  
Old 2nd October 2008
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 8,052
Default

Rule #7 is your block drop in log all.

Your incoming packet does not match the only pass rule above it, which is rule #0:

$piq on $V4EXTIF from $worf to ($V4EXTIF).

It is very hard to read your pf.conf, but it obviously does not match any quick or slow rule following rule #7.

Last edited by jggimi; 2nd October 2008 at 08:16 PM.
Reply With Quote
  #3   (View Single Post)  
Old 2nd October 2008
schrodinger's Avatar
schrodinger schrodinger is offline
Fdisk Soldier
 
Join Date: May 2008
Location: Ireland
Posts: 69
Default

Thank you jggimi, something that just obviously never occured to me when I was writing it. I've moved some rules around and made sure the black drop in log all is at the top. Would having the management rule about the block for the blacklist table matter either? Sorry about the format of the ruleset I'll attach or paste links in the future.
__________________
It was a new day yesterday, but it's an old day now.
Reply With Quote
  #4   (View Single Post)  
Old 3rd October 2008
schrodinger's Avatar
schrodinger schrodinger is offline
Fdisk Soldier
 
Join Date: May 2008
Location: Ireland
Posts: 69
Default

I moved things around and still the same problem, packets continue to match the default deny.

Code:
Oct 03 01:07:02.634952 rule 0/(match) block in on ral0: 192.168.1.125.15401 > 84.53.177.18.80: [|tcp] (DF)
Oct 03 01:07:03.684990 rule 0/(match) block in on ral0: 192.168.1.125.32995 > 216.73.84.103.80: [|tcp] (DF)
Oct 03 01:07:03.685663 rule 0/(match) block in on ral0: 192.168.1.125.17317 > 216.73.84.103.80: [|tcp] (DF)
New Ruleset:
http://www.konundrum.org/pf.df
__________________
It was a new day yesterday, but it's an old day now.
Reply With Quote
  #5   (View Single Post)  
Old 3rd October 2008
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 8,052
Default

The code-wrapped pf.conf was not the problem; my difficulty was deciphering your many macros.

I will try and review your new configuration file, but I fear the same result on my part.
Reply With Quote
  #6   (View Single Post)  
Old 3rd October 2008
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,167
Default

Could you run tcpdump on pflog0 with a greater snap lenght, so we can see whether the initial packet of the 3-way TCP handshake gets blocked or one after the connection has been setup?
Code:
# tcpdump -n -s512 -i pflog0
With this simple pf.conf
Code:
# pfctl  -vf block.pf   
block drop log all
pass out quick on re0 inet proto udp from any to any port = domain keep state
pass out quick on re0 inet proto udp from any to any port = ntp keep state
tcpdump shows
Code:
# tcpdump -ni pflog0 
tcpdump: listening on pflog0, link-type PFLOG
06:08:18.770421 192.168.222.20.27256 > 83.149.97.13.80: [|tcp] (DF)
06:08:20.255487 192.168.222.20.32520 > 83.149.97.13.80: [|tcp] (DF)
With an increases snap length
Code:
# tcpdump -n -s512 -i pflog0
tcpdump: listening on pflog0, link-type PFLOG
06:09:07.793215 192.168.222.20.21686 > 83.149.97.13.80: S 2005153514:2005153514(0)
nop,wscale 0,nop,nop,timestamp 3057449203 0> (DF)
We see the TCP flag S. The initial packet of the 3-way TCP handshake is the only TCP packet that only has a single 'S(yn)" flag. Other packets have S(yn) and A(ck).

Try moving the pass quick on $INTIF all rule to the top of your ruleset (directly after the block rule)
And please change that block rule to
Code:
block log all
__________________
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 6th October 2008
schrodinger's Avatar
schrodinger schrodinger is offline
Fdisk Soldier
 
Join Date: May 2008
Location: Ireland
Posts: 69
Default

looks like moving the pass rule down sorted things out, thanks for all the help.
__________________
It was a new day yesterday, but it's an old day now.
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
Blocking MySpace roddierod Other OS 3 12th April 2009 09:39 PM
PF Blocking VPN Traffic plexter OpenBSD Security 6 23rd January 2009 05:25 PM
Firewall Blocking Good Traffic plexter OpenBSD Security 6 8th January 2009 05:58 PM
pf blocking php mail ijk FreeBSD Security 7 30th October 2008 08:33 PM
Blocking remote desktop apps bichumo General software and network 3 30th September 2008 08:14 PM


All times are GMT. The time now is 12:34 AM.


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