DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 28th July 2010
mikesg's Avatar
mikesg mikesg is offline
I can has a title?
 
Join Date: Aug 2009
Posts: 28
Thanked 1 Time in 1 Post
Default 4.7 pf rule to block traffic from guest network

I had this working in 4.6 and earlier, and I feel I'm missing something really silly but I'm stumped. I have three interfaces on my firewall/gateway. I have a public AP on the third NIC, and as such want to block traffic going to the internal network from there. int_if and pubwi_if are on separate private subnets (192.168.1.x and 2.x respectively).
Code:
ext_if =   "fxp0"
int_if =   "xl0"
pubwi_if = "xl1"

set skip on { lo enc0 }

match in all scrub (no-df)

match out on $ext_if from !$ext_if nat-to $ext_if

block in on $ext_if all
pass out on $ext_if all

# Block public wi-fi traffic from internal net
block in quick on $int_if proto { tcp, udp } from $pubwi_if:network to $int_if:network

pass in log on $ext_if inet proto tcp from any to $ext_if port ssh label "ssh"
pass in inet proto icmp all icmp-type echoreq
Yet I can ping through and browse SMB shares while connected to the public AP. Whad I miss?
__________________
Mike
Reply With Quote
  #2   (View Single Post)  
Old 6th August 2010
rocket357's Avatar
rocket357 rocket357 is offline
Real Name: Jonathon
Wannabe OpenBSD porter
 
Join Date: Jun 2010
Location: 127.0.0.1
Posts: 404
Thanked 9 Times in 9 Posts
Default

Since 4.7's big nat re-write, nat rules are no longer separate from other rules, and rules that come after nat see the nat redirect ip, not the original source ip. (hxxp://marc.info/?l=openbsd-misc&m=125181847818600&w=2) (sorry for the hxxp, this is my second post haha)

Have you tried tagging the wifi packets and explicitly dropping those tagged packets on the internal interface?

Last edited by rocket357; 6th August 2010 at 03:48 PM.
Reply With Quote
  #3   (View Single Post)  
Old 2 Weeks Ago
mikesg's Avatar
mikesg mikesg is offline
I can has a title?
 
Join Date: Aug 2009
Posts: 28
Thanked 1 Time in 1 Post
Default

Hey old thread I know. But it's mine and I wanted to make sure there was a solution posted. I didn't have the need for this right after posting, but did again recently and I followed the advice here to tag the packets. Now that the new 4.7 pf.conf syntax is more well known, I wanted to know if this is still the best method for achieving what I want, which is basically blocking traffic between subnets. In my case, a guest network blocked from seeing the office network.
Code:
pass quick on $pubwi_if all tag PUBLIC
block quick on $int_if tagged PUBLIC
Is this sane?
__________________
Mike
Reply With Quote
  #4   (View Single Post)  
Old 2 Weeks Ago
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 4,494
Thanked 214 Times in 189 Posts
Default

Welcome back.

Looking at your initial ruleset from five years ago, I believe I can see the error. If I'm reading it correctly, the rule is limited to inbound traffic on the wrong interface, which is why it failed. The apparent error is highlighted below:
Code:
block in quick on $int_if proto { tcp, udp } from $pubwi_if:network to $int_if:network
Your two line revision looks fine to me.

I'm not a proponent of quick rules, unless necessary. I prefer last-matching-rule wins, allowing my rulesets to start with the general cases, then apply specific exceptions in later rules. But this is a personal preference.
Reply With Quote
  #5   (View Single Post)  
Old 2 Weeks Ago
mikesg's Avatar
mikesg mikesg is offline
I can has a title?
 
Join Date: Aug 2009
Posts: 28
Thanked 1 Time in 1 Post
Default

Thanks for your reply. I'm curious about your comment though. Don't I want to block inbound traffic on the int_if interface from the pubwi_if? I know that's what I want spoken in plain English, but I realize a rule to accomplish this may be very different. You highlighted the error but didn't offer a corrected version. Are you stating that had there been no such error, I wouldn't need to two lines in my second post?
__________________
Mike
Reply With Quote
  #6   (View Single Post)  
Old 2 Weeks Ago
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 4,494
Thanked 214 Times in 189 Posts
Default

Every packet will have a from and to address. PF uses these addresses in rule matching for every match/pass/block rule. PF rules can use individual IP addresses, network blocks, lists, tables, or the explicit or implied keyword any, but every rule can be matched or ignored, based on these two addresses in the packet.

However, a packet being forwarded by a router must first arrive on some interface, then be routed via some interface. These two steps may have different rules, via PF direction matching -- the in or out directives. And rules may have the additional restriction: interface matching -- the on directive.

Let's look at your rule once more. There are two restrictions: on $int_if, which will be on xl0 when the rule is loaded, and in, meaning only inbound packets. Combined, PF will only look at packets arriving on the xl0 interface from somewhere, and then it will compare from and to addresses.

And, that will never be from your public subnet -- those packets arrive at this system on a different interface: xl1. The rule is syntactically correct, but operationally invalid, because no packets will ever match the rule.

Last edited by jggimi; 2 Weeks Ago at 11:05 AM. Reason: clarity
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
VMWare Workstation 7 with MacOS 10.6.x guest There0 Guides 0 27th December 2009 07:38 AM
PF rule to disable icmp? cyanide_christ OpenBSD Security 6 15th October 2009 05:35 AM
pf: why is that rule not working? ivanatora FreeBSD General 14 11th December 2008 09:32 AM
qemu + guest os winxp - very slow.. DNAeon FreeBSD Ports and Packages 19 21st November 2008 10:00 AM
pf.conf brute force rule ijk FreeBSD Security 6 11th August 2008 04:54 PM


All times are GMT. The time now is 10:34 PM.


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