[elmore]

I didn't write this I just found it, I have setup plenty of IP less bridges with OpenBSD < 3.0 and I have setup a couple bridges with OpenBSD > 3.0. This article will definately get you on the right track with setting up an IP-less bridge with OpenBSD 3.0 or 3.1

-elmore-

Introduction
In today's world of broadband Internet technologies such as cable and DSL, IP addresses are often assigned in limited quantity by an ISP. Many of us would like a robust firewall to protect our network, but would rather not waste precious IP addresses. In this article we are going to build a robust, stateful packet filter that uses no IP addresses. Thankfully, OpenBSD provides built-in support for this "invisible firewall" via the bridge interface and the new packet filter, pf.

The Scenario
Let's assume that we currently have cable internet access from an ISP that has provided us with a small number of IP addresses. Because we need all of the addresses for a few workstations and servers, our network is unprotected at this point, with CAT5 cabling running directly from our cable modem to the hub where the workstations and server are connected.

The following diagram (thanks Marek!) shows the inclusion of a regular PC running OpenBSD (our "invisible firewall") that has been inserted inline between the cable modem and the hub.

Requirements
The minimum requirements for the OpenBSD machine are as follows:

133MHz or higher x86 class processor
64 MB of RAM
1 GB hard drive
2 NICs (High quality recommended, e.g., Intel, 3Com)
OpenBSD 3.0 or higher
Because our device will not have any interfaces with IP addresses, administration will need to be performed via console, either with a monitor connected to a video card or via serial.

This article assumes that the user is familiar with installing OpenBSD. Please see the OpenBSD website for questions regarding installation or upgrading. A default OpenBSD 3.0 or higher install with the GENERIC kernel will support the bridge/pf configuration.

Bridge Configuration
Once the OpenBSD installation is finished, remove any IP address information that you may have configured during the install. OpenBSD's bridging support is highly evolved: while the bridge operates solely at Layer 2, Layers 3 and 4 can still be filtered and manipulated while in transit through the bridge interfaces by pf.

For more specific information on OpenBSD bridging, please see the man page for bridge.

Setting up the bridge
First, we need to enable ip forwarding between the two network interfaces. Edit /etc/sysctl.conf and uncomment the line that reads: net.inet.ip.forwarding=1

Assuming the 2 bridge interfaces are fxp0 and fxp1 (if your interface names are different, change the interface names accordingly), create the following files with these parameters:

# ifconfig fxp0 delete
# echo 'up' > /etc/hostname.fxp0

# ifconfig fxp1 delete
# echo 'up' > /etc/hostname.fxp1

# echo 'add fxp0 add fxp1 up' > /etc/bridgename.bridge0

Reboot and verify that the bridge is up by running ifconfig -a. You should see output that includes this entry:
bridge0: flags=41 <UP,RUNNING> mtu 1500

Your bridge is now up and running and we can begin to configure the ruleset for pf.

pf Configuration
pf (Packet Filter) is the packet filtering system in OpenBSD 3.0 and later. Its syntax and functionality are very similar to ipf in both FreeBSD, NetBSD, and earlier versions of OpenBSD. If you are familiar with ipf ruleset syntax, pf syntax should be readable.

Enable pf filtering
In /etc/rc.conf, pf is disabled by default. Use pf=YES to enable. (pf will not actually be enabled until you reboot the machine once again.)

Building the ruleset
Because this is a home network, our ruleset will reflect functionality for a mixed Unix and Windows environment.

Our example filtering requirements:

All ssh and https traffic will be allowed from the Internet to any machine on the network.
All http traffic will be allowed from the Internet to our webserver (1.2.3.4)
Microsoft RDP (Terminal Services) will be allowed from our office laptop (2.2.3.4) to our home Windows 2000 server (1.2.3.5)
All UDP domain (for DNS lookups) and ntp will be allowed in.
ICMP echo request/reply (ping) will be allowed.
All access out from our network to the Internet will be allowed.
We want to keep state on all inbound connections.
We want to keep state on all outbound connections.
We want to log all dropped packets.
The default rules in /etc/pf.conf are to allow everything to pass through the filter. We want to narrow this down a bit as seen in the following example /etc/pf.conf. This example assumes your two network interfaces are named fxp0 and fxp1.
################################################## #######################
# OpenBSD bridged packet filter /etc/pf.conf example
#
# Some changes will likely be required for your specific setup!

#### Interface aliases
# Interface aliases should be created for ease of administration.

ext_if = "fxp0" # Untrusted (from cable modem) side
int_if = "fxp1" # Trusted (to hub/switch) side

#### External Bridge interface rules (allow all in - filter on internal)
# In bridge mode, we only filter on one interface.

pass in quick on $ext_if all
pass out quick on $ext_if all

#### Internal Bridge interface rules (main ruleset)
# Rule order does not matter

# Block (Deny) and LOG everything IN by default
block in log on $int_if all

### IN RULES

# Allowed incoming tcp services (ssh, https)
pass in on $int_if proto tcp from any to any port \
{ ssh, https } \
keep state

# Allow http traffic to our webserver
pass in on $int_if proto tcp from any to 1.2.3.4 port = http keep state

# Allow MS RDP (TCP 3389) from work to win2k server
pass in on $int_if proto tcp from 2.2.3.4 to 1.2.3.5 port = 3389 keep state

# Allow Certain UDP services IN (DNS, NTP)
pass in on $int_if proto udp from any to any port \
{ domain, ntp } \
keep state

# Allow ICMP (ping) IN
# pass out/in certain ICMP queries and keep state (ping)
pass in on $int_if inet proto icmp all icmp-type 8 code 0 keep state

### END of IN RULES

### OUT RULES

# Allow ICMP (ping) OUT
pass out on $int_if inet proto icmp all icmp-type 8 code 0 keep state

# Pass (Allow) all UDP/TCP OUT and keep state
pass out on $int_if proto udp all keep state
pass out on $int_if proto tcp all modulate state

### END of OUT RULES
################################################## ######################

More information and ruleset examples can be found in the pf.conf man page.

Loading and viewing the ruleset
The pfctl command controls the loading and viewing of the rules, as well as a number of other rule-related items (e.g., viewing state tables).

The example /etc/pf.conf is loaded like this:

# pfctl -R /etc/pf.conf

To view the loaded rules:
# pfctl -s rules


Logging and Testing
Because we added a log parameter to the block rule in the above example, we can use tcpdump to view traffic on the pf log interface (pflog0) in real time to see the traffic that is being dropped.

To view pf logged traffic in real time:

# tcpdump -i pflog0

Real-time logging will be shown, which can be extremely helpful in ruleset configuration or any problems that may occur.

One other helpful troubleshooting test that you can run with tcpdump will read the pf logfile (/var/log/pflog) and show you accepted and rejected packets along with a matching rule number.

# tcpdump -n -e -ttt -r /var/log/pflog

These methods will prove invaluable as you develop more complex rulesets and enable more sophisticated logging.

Thoughts and Conclusion
That's it. We now have an "invisible firewall" capable of stateful packet inspection and advanced capabilities without using any of our precious IP addresses. From a security standpoint this is nearly the perfect firewall solution because of its stealth. It cannot be compromised over the network, cannot be portscanned and doesn't waste IP space. To someone on the outside of your network, denied packets simply mysteriously "disappear" for no apparent reason.

There are many other uses for this kind of invisible or stealth packet filtering, from segmenting flat corporate networks to building a portable invisible traffic monitoring device. You might even add another NIC to it and create an addressed interface that plugs into a secure management VLAN for ease of administration... the possibilities are vast.

I hope this article has been helpful, and I hope that you will find a myriad of ways to incorporate this solution into your particular networking environment.

The original link is here:

http://ezine.daemonnews.org/200207/transpfobsd.html

This isn't exactly how I'd setup my ruleset but it isn;t a bad ruleset for sure.

-elmore-

[illusion]

Thanks to elmore I have been running an IP-less bridge for several months. It really is the way to go. I sleep at night!!!!

[schotty]

spape, is it that much simpelr to deal with? At work, I use OBSD for my gateway and firewall for both DSL lines we have. It works very well. I havent had to worry about that server much at all. I have one routing issue, but thats different. Thats me, not the unit :oops: Do you reccomend making a separate unit for doing just firewalling?

[illusion]

I only run the IP-less bridge since I have an actual router as my gateway. Since you are using your OBSD firewall as a gateway I would suggest installing an IP-less bridge in between. I used an old P133 to do the trick. I works just fine.
:idea:

[datamike]

This write up was a huge help. Schotty turned me on to it after asking his advice on linuxjunior.org. Anyway. I was thinking, can you just use

brconfig bridge0 add fxp0 add fxp1 up

instead of:

# ifconfig fxp0 delete
# echo 'up' > /etc/hostname.fxp0

# ifconfig fxp1 delete
# echo 'up' > /etc/hostname.fxp1

# echo 'add fxp0 add fxp1 up' > /etc/bridgename.bridge0

I am new at this so I could be wrong but it just seemed like less to type for me.

[elmore]

I don;t see any reason that wouldn't work.

[schotty]

Sounds good spape! Thanks!

[datamike]

I hope someone can help me. This is my pf.conf file. I basically ripped off the how to. My problem is I cant get to the internet or log into my mail server through a client. I CAN ping inside and outside my network though. Anyone see why?? One more question. I pulled my IP's and hostnames out of /etc/host but my box is still called the same hostname.(dienasty) It boots up and say bad route:dienasty. Could this be a problem? I am new at BSD sorry.


ext_if = "sis0" # Untrusted (from cable modem) side
int_if = "sis1" # Trusted (to hub/switch) side

#### External Bridge interface rules (allow all in - filter on internal)
# In bridge mode, we only filter on one interface.

pass in quick on $ext_if all
pass out quick on $ext_if all

#### Internal Bridge interface rules (main ruleset)
# Rule order does not matter

# Block (Deny) and LOG everything IN by default
block in log on $int_if all

### IN RULES

# Allowed incoming tcp services (ssh, https)
pass in on $int_if proto tcp from any to any port \
{ ssh, https } \
keep state

# Allow Certain UDP services IN (DNS, NTP)
pass in on $int_if proto udp from any to any port \
{ domain, ntp } \
keep state

# Allow ICMP (ping) IN
# pass out/in certain ICMP queries and keep state (ping)
pass in on $int_if inet proto icmp all icmp-type 8 code 0 keep state

### END of IN RULES

### OUT RULES

# Allow ICMP (ping) OUT
pass out on $int_if inet proto icmp all icmp-type 8 code 0 keep state

# Pass (Allow) all UDP/TCP OUT and keep state
pass out on $int_if proto udp all keep state
pass out on $int_if proto tcp all modulate state

### END of OUT RULES

[elmore]

Your running a bridge right? No IP's. I.E. no routes no lookups possible. If you are trying to bind something to an interface it most likely won't work.

I have an IPless bridge here at my house on my cable modem setup, the diagram works like this:



Internet-------CableModem------IPless-Bridge-------FireWall/VPN-----IntNet


My ruleset for my bridge is a follows:


# Set up some variables

extif="fxp0"
intif="dc0"
admin="le1"
corp="xxx.xxx.xxx.xxx/32"
web="xxx.xxx.xxx.xxx/32"
spoofed="{ 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32, 127.0.0.1/32 }"

# loopback rules

pass in quick on lo0 all

#Management interface

pass in quick on $admin all
pass out quick on $admin all

#Scrub packets

scrub in all

#Allow udp replies back from name servers

pass in on $extif proto udp from any to any port = domain keep state
pass in on $intif proto udp from any to any port = domain keep state

#Block inherently bad packets coming in from the outside world.

block in log quick on $extif proto tcp from any to any flags FUP
block in log quick on $extif proto tcp all flags SF/SFRA
block in log quick on $extif proto tcp all flags /SFRA
block in log quick on $extif proto tcp all flags F/SFRA
block in log quick on $extif proto tcp all flags U/SFRAU
block in log quick on $extif proto tcp all flags P

#block non-routable IP'z, stop leaks from our net

block in log quick on $extif from $spoofed to any
block in log quick on $intif from $spoofed to any
block out log quick on $extif from $spoofed to any
block out log quick on $intif from $spoofed to any

#Block all incoming TCP traffic connections to known services, returning an RST

block return-rst in log on $extif proto tcp from any to any flags S/SA
block return-rst in on $extif proto tcp from any to any port = auth flags S/SA

#Let ISAKMP work!

pass in quick on $extif proto udp from any to any port = 500
pass in quick on $intif proto udp from any to any port = 500
pass in quick on $extif proto esp from any to any
pass in quick on $intif proto esp from any to any

# Block everything else

block in log quick on $extif from any to any

# keep states
pass out on $extif from any to any keep state
pass out on $intif from any to any keep state


This is a ruleset that I wrote when pf was firast released, my bridge is OBSD 3.0. There have been many improvements since that time and my ruleset isn;t quite right. I know this. However it works. One thing I would point out to you is notice the use of the keyword "quick".

I also have a third interface on my firewall, It has an IP assigned in my private net range, Anyways, make sure your bridge is up and activated.
and that you are indeed passing packets, when I did the pf rules for my bridge I referenced this article:


http://www.openlysecure.org/openbsd/how-to/invisible_firewall.html


Hope this can help you, let me know if there's anything else I can do.

[frisco]

I was thinking, can you just use

brconfig bridge0 add fxp0 add fxp1 up

instead of:


what are you trying to do?

the brconfig command will work if you run it and the interfaces are already up, but if you reboot the machine then you have to run that command again. The other commands (rewriting /etc/hostname.* and /etc/bridgename.bridge0) allow the system to configure its nics and the bridge upon boot up, no intervention required.

While you could put that brconfig line (along with the appropriate ifconfig's) into /etc/rc.local, this would be counterintuitive. /etc/netstart (which runs at boot) looks for files /etc/hostname.* and /etc/bridgename.bridge* and uses these to configure NIC's and bridges. Edit those files instead and you will be ready for the next time you reboot that system.

[schotty]

Well, I just implemented the bridge tutorial, and it works word for word here (well, I didnt quite use the same pf ruleset).

Thanks again Elmore!

[elmore]

No problem Schotty glad to see it helped you out.

[cod3fr3ak]

I have a question regarding this type of setup. At home I have a Celeron 866 w/128m ram and two nics. I have set this machine up to be a silent bridge per this and other documents I have found on the web. The bridge itself works very well. However I have setup a secure log server, using syslog-ng and stunnel at work, and I would like to do the same thing here at home.
Question - how dangerous is it to create a virtual interface to allow passage of log data?
Question - How do I pass the log data out to a server in my intranet?
I can not add another network card since this is a 1U machine (yes I have a half-rack in my condo!)
I was thinking of two options:
1. purchase a dual head nic. stick it in the single PCI slot and bridge on that. use the motherboards built-in nic for admin stuff.
2. More of a thought... is it possible to tell pf to route all packets coming in to lo0 (127.0.0.1 - will it translate?) with a destination inside my intranet - pass thur. doesn't sound like it'd work to me, but I am just throwing things out there.
Thanks for any and all help. And once again Elmore & Screaming E team - Great job on the site!!!!

[thedude]

I too was thinking of implementing this between my (mandatory) PIX firewall and my internal network. How's it coming with yours?

[cod3fr3ak]

Not weel at all. I had to scratch the invisi bridge project because I couldn't get the firewall to pickup a dhcp address while the bridge was online. never figured out why.