main | openbsd :: how-to :: invisible_firewall

Invisible Firewalling How-To Posted by wes on Sep 6, 2001 Memoirs of an Invisible Firewall Setting up the system Setting the config files Activating the bridge Making your bridge permanent Firewalling Main Page Memoirs of an Invisible Firewall In the stone age of firewalling, a firewall was a fairly complicated device that was less-than-trivial to factor into your network. It needed an IP address on it's outside, and another on the inside. This immediately created subnetting problems, forcing wasted IP allocation and overall disquietude amongst the cognoscenti. It also meant that your firewall was very visible to the world, and its function was rather obvious and easy to deduce. There had to be a better way. And now there is... Dream with me for a moment: A black box, shimmering in the soft LED-green glow of the network cabinet. You take the network cable from your router, which previously went into a switch, and stick it in one of the snappy plugs in the back of the box. There's one more plug on the black box, so you grab another cable and hook the box up to the switch. You step back, and suddenly: everything looks the same. You go to all your computers. As far as you can tell from inside and outside the network, the box doesn't exist. It does nothing. A few minutes later, you have a monitor and keyboard hooked up to the back of the box. You quickly and easily begin to tweak a file that gives you fine grained control over access to your network. You shut off all access to your mailserver from the outside world except on port 25. Back to the testing bench -- once again, you can't find any indication that this box exists. From inside the network, everything works fine. But inexplicably, your mailserver simply is unreachable on any port other that 25. There's simply no response... in fact, your packets seem to vanish into the ether. You're experiencing the power and ease of a transparent bridging firewall. It doesn't require any reconfiguration of your network (other than pluging it between your router and your network) yet allows you to completely control network access with the full power of the IPFilter firewalling system. And the best part? The firewall is invisible and inaccessible from anywhere other than the console. This means a hacker can't possibly break into your firewall. It just doesn't exist. How does this box get built? Well here's a hint: under OpenBSD it is relatively easy to bridge two network interface cards together. What does this mean? It means that every packet that appears on one card will be sent to the other. It essentially turns your computer into a $.50 piece of connecting cable ... with one key difference: as the packets move from one card to another, the computer can inspect and filter them. So how does this give us the black box? To start, you can now use the firewalling abilities of OpenBSD (the excellent IPFilter package) to control the dataflow between the interfaces. But the great part about a bridge is that it doesn't need IP addresses. The interfaces are "promiscuous", so to speak. They just grab every packet they see on the wire, regardless of where it's going, and send it across to the other side. Combine these two great tastes that go great together and you've got a kickass network prophylactic. Setting up the system You'll want to do a bare-bones install of OpenBSD, as discussed on this site in the OpenBSD installation guide. Don't worry about configuring the network, unless you plan on upgrading/patching various stuff from the Net. If you do config the network, just config one interface temporarily so that you can get to the external files. Eventually you'll be wiping this config, so don't sweat it. Setting the config files There's a few changes you need to make to the two main system config files: /etc/sysctl.conf and /etc/rc.conf. /etc/sysctl.conf uncomment the line beginning with: #net.inet.ip.forwarding=1 --> net.inet.ip.forwarding=1 if you're using IPv6 already, you might want to uncomment the following line, which enables IPv6 forwarding. #net.inet6.ip6.forwarding=1 --> net.inet6.ip6.forwarding=1 /etc/rc.conf change the following lines from NO to YES: ipfilter=NO --> ipfilter=YES ipnat=NO --> ipnat=YES Reboot to activate the changes. Activating the bridge First let's make sure your network is in a state that we can work with. Execute the following commands. Damn the torpedoes and ignore any error messages. ifconfig dc0 delete ifconfig dc1 delete ifconfig dc0 up ifconfig dc1 up This gets rid of any prior configuration of your interfaces and just sets them both to UP, with nothing else configured. This way an old IP address setting doesn't cause a mysterious conflict later. Now let's add the interfaces to the bridge: brconfig bridge0 add dc0 add dc1 up Guess what? You're bridging... that's all there is to it! Of course, now the fun part: testing to make sure this actually works. To test your config, you'll need two machines and two crossover cables. Using the crossover cables, hook the machines up to dc0 and dc1. Give each machine a different IP address in the same subnet, for example dc0 gets a machine with 10.0.0.1, and dc1 gets 10.0.0.2. Can you ping from one to the other? Theoretically, you should be able to do this, if all went well. If not, check your cables -- the indicator lights on all the network cards should be lit. Other sources of errors: the configuration on the test machines... make sure they can talk to one another without the bridge (just connect the two of them together with a crossover cable -- one should be able to ping the other... if they can do this, the problem is with your bridge). If that fails, run a TCP dump: tcpdump -i dc0 -l and then: tcpdump -i dc1 -l This will show you want packets are arriving on the dc0 and dc1 interfaces, respectively. You can use this to help figure out where the problem is. If you've played with the ipf.rules file at all, you should do an ipf -Fa to flush the rules to the pass-all state. Any rules at this point could cause problems. Now let's test the firewalling abilities. Create a quick ipf.rules file that says: /etc/ipf.rules block in on dc0 all block in on dc1 all now do: ipf -Fa -vf /etc/ipf.rules and try pinging again. Should be dead. If so, good. Otherwise, refer to the online firewall installation and configuration guides found on this site to help troubleshoot the problem. Making your bridge permanent In order to keep your bridge through reboots, you'll need to change a few more files. Each of these three files should have just one line: /etc/hostname.dc0 up /etc/hostname.dc1 up /etc/bridgename.bridge0 add dc0 add dc1 up /etc/mygate should be empty. /etc/myname should be a name for the bridge that you find particularly apropos... some popular suggestions: london, brooklyn, rubber, notrump, nosebump, etc. Firewalling This is the easy part -- just add rules to the ipf.rules file. You can follow any of the sample rule set instructions found on this site -- although the set for "Highest Security" will be particularly applicable. Some key gotchas: Bridging under OpenBSD has a constraint: filter rules only work for the "in" direction. A "block out" statement will have no effect. Of course, you can accomplish almost anything you'd want to do with an outbound rule with an equivalent inbound rule on the opposite interface. For example: pass out on dc0 proto tcp/udp all keep state is one way to ensure that connections initiated from the inside are allowed back in through a firewall that blocks all connections from the outside. This particular rule won't work in your bridge -- it can't handle the "out". But this rule could equally be written as: pass in on dc1 proto tcp/udp all keep state Now we're catching the same packet, moving from internal to external network... except instead of catching it as it leaves for the big, dangerous unknown on the external interface (after passing through the filters), we bag it/tag it as it first goes into the bridge on the internal interface. Easy, eh? Remember -- this machine has NO IP address, so it can't be reached from anywhere other than the console. Test ALL of your rules thoroughly before officially activating this thing and leaving for the week. This also means you can't reach any other machines from the bridge -- so don't freak when "ping" or "telnet" fails to connect with a machine that's directly connected to the bridge. Regardless of the direct connection, nothing will be able to talk with the bridge other than at the ARP level. Likewise, IPNat ain't gonna work neither. So don't even bother. <hr> <!-- hhmts start --> Last modified: Thu Aug 24 04:59:52 EDT 2000 <!-- hhmts end --> Notify me whenever the openbsd section of this site is updated Email this page to a friend or colleague Show a printer-friendly version of this page