DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 20th January 2012
scrummie02 scrummie02 is offline
Port Guard
 
Join Date: Nov 2011
Posts: 27
Default Bridging firewall with OPenBSD 5.0

I have a switch with multiple VLANS with a DMZ. I nave some servers that need protecting within the DMZ so I've decided to implement an OpenBSD bridging/transparent firewall.

So far I'm connected and I can ping stuff from the internal network (i.e. I can ping my gateway and servers on the "other" side of the firewall), but I can't get to the internet from the servers or nodes behind the firewall.

For some clarification here is what I have:

ext-->ASA-->DMZ--->OBSD PF ---->Protected I.P.'s

They're all the same network (192.168.10.0/24). So I can easily connect to nodes on the other side of the OpenBSD firewall just not the internet.

Here is my pf.conf
Code:
int_if = "em1"
ext_if = "em2"

localnet = "192.168.0.0/24"



# we only want to filter one interface, so pass everything on the inside interface
pass in quick on $int_if all
pass out quick on $int_if all

# block everything by default on the external interface
block in log on $ext_if all
block out log on $ext_if all

# allow UDP DNS traffic
pass out log quick on $ext_if proto udp from $localnet to any port 53 keep state

# allow FTP, SSH, DNS and HTTP traffic to trusted networks
pass out log quick on $ext_if proto tcp from $localnet to any \
     port { 20, 21, 22, 53, 80, 81, 443 } modulate state

# allow incomming FTP, SSH, and HTTP traffic
pass in log quick on $ext_if proto tcp from any to $localnet \
     port { 80, 443 } modulate state

# allow pings
pass in log on $ext_if proto icmp from any to $localnet icmp-type 8 code 0 keep state
pass out log on $ext_if proto icmp from $localnet to any icmp-type 8 code 0 keep state
Also, I'm questioning whether a bridging firewall would be good as opposed to just a filtering firewall. Since all of the machines are already IP'ed I don't want to change any IP's and double NAT is messy.

Any help is appreciated.
Reply With Quote
  #2   (View Single Post)  
Old 20th January 2012
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

The classic setup for a DMZ firewall with pf is one with a box with three NIC's:
  1. external interface : connecting to the dangerous Internet
  2. DMZ interface - connection to the servers in the DMZ
  3. internal interface - connecting the internal LAN

Is this an option for your?
__________________
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 21st January 2012
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Quote:
Originally Posted by J65nko View Post
The classic setup for a DMZ firewall with pf is one with a box with three NIC's...
Heh. The best practice for a single DMZ is two firewalls, inner and outer, with a DMZ network in between. My current customer has many tiers, each with its own set of firewalls and each with unique rulesets.
Reply With Quote
  #4   (View Single Post)  
Old 21st January 2012
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

We don't have quite enough information to diagnose a root cause. Based on what little we know, bridge traffic on the LAN is passing correctly. If so, this means that ARP traffic is not blocked, and IP forwarding is enabled. But Internet destined packets don't get responses. Which tends to indicate a routing problem. And now I'm at a loss, because the ASA should be able to reach any device on the subnet, since ARP and IP packets should flow, and stateful processing is used in your PF configuration. All the devices, protected and unprotected, should appear to the ASA like one big happy Ethernet LAN and all devices are on the same IP subnet.

I do notice one two things in your pf.conf. 1) This comment doesn't agree with the rule. And 2) why are you permitting a public facing webserver to operate from your protected zone? When you do this, there is little value to having a DMZ at all, as webservers should sit in the DMZ ... that's what it's for.
Code:
# allow incomming FTP, SSH, and HTTP traffic
pass in log quick on $ext_if proto tcp from any to $localnet \
     port { 80, 443 } modulate state
These are in no particular order, except I will start with routing...
  • Is the ASA your gateway route for devices in your protected zone?
  • Does Internet DNS resolve for your protected IPs? If so, does your ASA device act as your DNS server, or do you point to external DNS servers at your ISP or elsewhere?
  • What does a tcpdump trace of your external interface show -- are there responses received at the interface for Internet-bound traffic?
  • I don't speak Cisco, so I do not know if you can get ARP tables to display on its console. If so, look to see if any of your protected devices are in the table. If not, you know you have an ARP problem as far as the Cisco device is concerned.
  • If you do have an ARP problem, trace those packets and see what component is dropping them.
  • Adding log to your block rules will allow you to use tcpdump with the pflog interface to trace blocked packets .. since you have a default deny ruleset, you can see what rules you may need to add.
  • Test the bridge with a simple pass all ruleset. If suddenly things start working, you'll know the source is your PF configuration and you will need to to log your block rules and trace blocked packets.

Last edited by jggimi; 21st January 2012 at 02:04 AM.
Reply With Quote
  #5   (View Single Post)  
Old 23rd January 2012
scrummie02 scrummie02 is offline
Port Guard
 
Join Date: Nov 2011
Posts: 27
Default

Quote:
Originally Posted by jggimi View Post
We don't have quite enough information to diagnose a root cause. Based on what little we know, bridge traffic on the LAN is passing correctly. If so, this means that ARP traffic is not blocked, and IP forwarding is enabled. But Internet destined packets don't get responses. Which tends to indicate a routing problem. And now I'm at a loss, because the ASA should be able to reach any device on the subnet, since ARP and IP packets should flow, and stateful processing is used in your PF configuration. All the devices, protected and unprotected, should appear to the ASA like one big happy Ethernet LAN and all devices are on the same IP subnet.

I do notice one two things in your pf.conf. 1) This comment doesn't agree with the rule. And 2) why are you permitting a public facing webserver to operate from your protected zone? When you do this, there is little value to having a DMZ at all, as webservers should sit in the DMZ ... that's what it's for.
Code:
# allow incomming FTP, SSH, and HTTP traffic
pass in log quick on $ext_if proto tcp from any to $localnet \
     port { 80, 443 } modulate state
These are in no particular order, except I will start with routing...
  • Is the ASA your gateway route for devices in your protected zone?
  • Does Internet DNS resolve for your protected IPs? If so, does your ASA device act as your DNS server, or do you point to external DNS servers at your ISP or elsewhere?
  • What does a tcpdump trace of your external interface show -- are there responses received at the interface for Internet-bound traffic?
  • I don't speak Cisco, so I do not know if you can get ARP tables to display on its console. If so, look to see if any of your protected devices are in the table. If not, you know you have an ARP problem as far as the Cisco device is concerned.
  • If you do have an ARP problem, trace those packets and see what component is dropping them.
  • Adding log to your block rules will allow you to use tcpdump with the pflog interface to trace blocked packets .. since you have a default deny ruleset, you can see what rules you may need to add.
  • Test the bridge with a simple pass all ruleset. If suddenly things start working, you'll know the source is your PF configuration and you will need to to log your block rules and trace blocked packets.
Okay, it appears not that traffic passes, but I can't seem to filter it as I need.

I have some web servers that need extra protection that's why 80/443 are open.

My pf.conf is as follows:
Code:
int_if = "em1"
ext_if = "em2"

localnet = "192.168.100.0/24"
set loginterface em2


# we only want to filter one interface, so pass everything on the inside interface
pass in quick on $int_if all
pass out quick on $int_if all

# block everything by default on the external interface
block in log on $ext_if all
block out log on $ext_if all

# allow UDP DNS traffic
pass out log quick on $ext_if proto udp from $localnet to any port 53 keep state

# allow FTP, SSH, DNS and HTTP traffic to trusted networks
pass out log quick on $ext_if proto tcp from $localnet to any port { 20, 21, 22, 53, 80, 443, } modulate state

# allow incomming FTP, SSH, and HTTP traffic
#pass in log quick on $ext_if proto tcp from any to $localnet port {20, 21, 22, 80, 81, 443 } modulate state

# allow pings
pass in log on $ext_if proto icmp from any to $localnet icmp-type 8 code 0 keep state
pass out log on $ext_if proto icmp from $localnet to any icmp-type 8 code 0 keep state
When I run TCP dump it looks like I'm passing netbios traffic - which is one of the reasons I implemented this thing..to stop broadcasts.
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
OpenBSD, PF, bridging and 10gE mbw OpenBSD Security 6 5th January 2012 08:51 PM
requesting help with "New" way to do Bridging in OpenBSD 4.7 mbw OpenBSD Installation and Upgrading 1 30th May 2010 12:06 AM
OpenBSD firewall with only one physical NIC idosch OpenBSD Security 5 25th April 2010 12:11 AM
DIY OpenBSD Firewall Appliance mikesg OpenBSD Security 34 6th January 2010 06:17 AM
OpenBSD firewall resources J65nko OpenBSD Security 0 1st June 2008 02:28 AM


All times are GMT. The time now is 03:46 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