Introduction
| Linux Embedded Appliance Firewall | |
|---|---|
| Summary | Free, extremely flexible and powerful Linux based firewall distro. Setup and configuration may be difficult for those unaccustomed to command-line interfaces |
| Update | 17 June 2004 – Corrected developer information |
| Pros | • Free • Fast (even with old CPUs) • Extremely configurable, including features and number of physical interfaces • Can run from single floppy |
| Cons | • Configuration and setup not for newbies |
|
Being connected to the Internet these days is like playing dodge ball when you were a kid – lots of people trying to hit you with something, preferably in a place where it will hurt or leave a mark. At least that’s the way we played it. The good news is that you can protect yourself from many Internet based attacks through the use of a good firewall.
So what does a firewall do? When you’re connected to any computer network like the Internet, communication takes place on different ports. A network firewall is basically a system that controls communications to and from you based on those ports. If you’re not running a web server for instance, then nobody from outside should be initiating a connection to you on port 80, so the job of a basic firewall then would be to block such requests, while still allowing you to surf the web, read your email, and so forth.
Sometimes what is commonly called a firewall goes beyond the basic “block out the bad stuff” functionality. Let’s say you have a small network with a connection to the Internet and you also run a web server exposed to the Internet. A firewall in this case would also need to include routing capabilities. It will need to provide a means of sharing a single connection to the Internet so that everyone on the local network can have access, and it will need to forward port 80 requests from the outside to your web server, all while keeping invalid requests out. In addition, a firewall/router system may also provide other features, such as DHCP service, DNS service, content filtering, packet sniffing, traffic shaping, VPN tunnels, web proxy, application proxy, and just about any other method devised to keep the local network running smoothly and the bad guys out.
What is commonly referred to as a firewall then, could be as simple and cheap as a piece of software installed on your local computer (like ZoneAlarm), or it could be a dedicated rack full of high end hardware that provides nearly every network defense strategy known to man. Today I’d like to introduce you to something that I like to think of as the best of both those worlds, an Open Source, Linux based firewall called LEAF-Bering uClibc. Cheap? Try free. High end? It’s as functionally rich as you want to make it. You provide a computer to install it on, and by using LEAF-Bering uClibc you can build a firewall/router that will rival some of the best firewall systems available.
Features and Architecture
LEAF-Bering uClibc traces its lineage back to what was once the “Linux Router Project”. The goal was to create an operating system, based on Linux, which would provide the same functionality as a hardware router. LEAF stands for “Linux Embedded Appliance Firewall”, and there have been (and still are) several variants, of which Bering-uClibc is probably the most current and actively developed, led by the LEAF-Bering uClibc team of Arne Bernin, Eric de Thouars, Eric Spakman, Luis Correia, KP Kirchdoerfer, and Martin Hejl.
LEAF-Bering uClibc (let’s just call it LBU from here on out) has many features, including compatibility with a wide variety of hardware, advanced routing capabilities, IPV6 compatibility, security, simplicity, and flexibility. The basic LBU system includes DHCP, DNS caching, and SSH services, among other things.
The core of LBU, besides the Linux kernel itself, is the Shorewall firewall system, from Tom Eastep. Shorewall is a highly evolved application that reads easily edited (and well commented) configuration files to control the Linux kernel’s Netfilter packet filtering system, and can therefore provide advanced routing functions, including stateful packet filtering.
In addition to the base packages that come with LBU, you can also download many extra packages (also Open Source and free) to extend or enhance the capabilities of the system. LBU is targeted mostly towards small or mid-sized networks, but it’s really only limited by your imagination.
When an LBU system starts up, what happens is that the boot process creates ram disks (virtual disks held in memory) and expands the entire operating system there. Once the boot process is complete, no actual hardware disks are used because everything is held in memory. Because of this design, the system is very flexible when it comes to installation.
The basic LBU system comes as a 1680K floppy disk image, but you can also put the system on a hard disk, a CDROM, or anything else that your hardware can boot from. You can even store the boot files on one media and configuration files on another if you’d like. This design also makes the system more secure.
For instance, once you get your system configured like you want, you can simply write protect the LBU floppy disk or take it out altogether, and then even if your firewall gets broken into and taken over (which would be extremely unlikely), all you’d have to do is reboot and be back in business.
Installation and Setup
I installed LEAF-Bering uClibc 2.1.1 on two separate network firewall systems:
- An old Dell PII 500 with about 128megs of RAM, a built-in 100BaseTX port, and 2 PCI 100BaseTX network cards.
- An even older Compaq P100 with about 56 megs of RAM, 2 PCI 100BaseTX network cards, and 1 ISA 10BaseT network card.
On both systems, the layout is basically the same. One network card (net zone) is connected to a cable modem and provides the Internet connection, a second card (loc zone) is connected to the local network hub or switch, and the third card (dmz zone) is connected with a crossover cable directly to a web server.
Obviously then, our new LBU firewall system’s job is to allow local users to access the Internet, forward requests for web pages to the web server, and keep the bad guys out. In addition, I like to run a few other services on my firewall, such as a DHCP server and DNS caching. Fortunately, LBU handles all these requirements (plus a few others) right out of the box.
One of the best things about LBU, and the Shorewall firewall, is the excellent documentation available. Since LEAF-Bering uClibc recently evolved from plain old LEAF-Bering, the documentation is currently made up of the original LEAF-Bering installation and user’s guides, and then separate LBU installation and user’s guides which outline the new or changed features.
Be sure to read these guides (I printed them out) before getting started, and maybe even join the LEAF user mailing list. It’s also a good idea to at least have a look at the extensive Shorewall documentation, especially the quick start guides. Once you boot the LBU floppy disk, you’ll be presented with the following text-based configuration utility.
Figure 1: Configuration Menu
In addition to the documentation I mentioned earlier, there’s even a brief online help system that you can access through the configuration utility, as shown below.
Figure 2: Packages Help Menu
Installation and Setup, Continued
One of the first things you’ll need to do is get your network interfaces working. This can be one of the trickiest parts of the whole installation. You’ll need to know what your network cards are and then figure out which driver they need to work. LBU also supports dialup, by the way, if you’re dealing with a phone modem.
While working out all of your hardware, “cat /proc/pci” and Google are your friends. Once you have the correct modules loaded, then you’ve got to figure out which interface has been assigned eth0, which has been assigned eth1, and so on. Sometimes it’s not the way you’d think. Finally, when you’ve got your network interfaces straightened out, then it’s time to configure the rest of the system. The LBU configuration utility is helpful, but mostly what it does is help you navigate to the configuration files, and then dump you into an editor, like this.
Figure 3: The Configuration Utility
Now I know that none of this looks very sexy to folks who are used to pointing-and-clicking their way through life, but this is a firewall, not a video game. As I mentioned before, most all of the configuration files are very well commented, so along with the installation and user’s guides I mentioned earlier, getting a basic working system up and running is fairly straightforward. Be sure to use the configuration utility, as shown below, to backup (save permanently) all your changes.
Figure 4: Backing up the Configuration
Since I personally just don’t trust floppy disks, I chose to store my LBU system on the firewall’s hard disk. It’s really just a matter of adding modules or a ready-made package to support IDE drives, and then moving everything to a MSDOS partition on the hard disk. The LBU documentation explains all of this.
Another one of the great things about LBU is the available extra packages. If you don’t like the default DHCP server, there’s another one you can try, or maybe you’d like to run an NTP server, or set up a VPN tunnel. New packages are easy to download, install, and try out, and just as easy to get rid of if you don’t like them.
Installation and Setup – Packages
So what packages do I use? Well initrd, root, config, etc, local, modules, iptables, shorwall, and ulogd are basic packages that most everyone will need. The interface connected to my cable modem is configured by dhcp, so I also need dhcpcd (DHCP client daemon).
LBU comes with dhcpd (DHCP daemon) and dnscache (a dns caching daemon), but I found that dnscache has a problem resolving parts of my banking institution’s online system. The same problem cropped up about a year ago with certain websites, notably weather.com [http://www.weather.com]. There was some discussion of this on the LEAF mailing list, and basically the problem boils down to the fact that dnscache is a very strict implimentation of DNS protocol, while some websites impliment DNS in a slightly non-standard way.
I found an alternative to dnscache that does seem to resolve even non-standard sites, by using the dnsmasq package, which also provides a DHCP server. The neat thing about dnsmasq is that it resolves local network names by using the /etc/hosts file and its own DHCP server, and it resolves the outside world by using servers listed in /etc/resolv.conf. Pretty slick. I believe that plans are for dnsmasq to replace dhcpd and dnscache in future versions of LBU.
The dropbear package (SSH server) is included with the base system, and is very handy for remote administration. The ezipupd package is an automatic updater for several dynamic name services, like dyndns.org [http://www.dyndns.org]. Finally, I run the ntpsimpl package (NTP server), which also requires the libm package.
In Use
OK, so you’ve got LBU all installed and working. Now what? From the local network, point your browser at the IP address of the firewall (by default, it’s 192.168.1.254).
Figure 5: LBU Status
(click on the image for a larger view)
Nice. Who says a firewall isn’t sexy? The LBU Weblet package, part of the base system, presents a nice looking status page with lots of clickable links to more information. From here, it’s easy to get a very good idea, from the comfort of your desktop web browser, of exactly what the firewall has been up to.
Notice that the firewall is showing a “warning” condition in the above screenshot? Nothing is wrong, it’s just been getting hit a lot lately by all the other systems on the Internet (probably infected with the latest virus) looking for their next victim. In other words, it’s doing the job it’s supposed to do. Want to know more? Just click a link. Here’s a look at the “pretty” Shorewall log:
Figure 6: Shorewall log
(click on the image for a larger view)
Yep, it’s pretty all right. You can find out just about anything you want to know about the firewall’s basic status by following links. Very cool. I’ve included a few more screen shots below of other status info you can get (click on any of them for a larger view).
|
|
|
 |
|
To provide for remote administration, the base LBU system includes an SSH server. If your desktop is a Windows system, you can download a free SSH client called PuTTY and use it to log into and configure your firewall system from your desktop. Of course, if your desktop is Linux, then you probably already have an SSH client installed.
When you log into your firewall remotely with SSH, you’re presented with the familiar LBU configuration utility shown earlier. Use it to make your changes, and then be sure to back up the affected packages. You can also use common Linux utilities like “cat” and “less” to read log files or even watch them in real time to help with troubleshooting. For instance, let’s say you think that the LBU firewall is blocking a local user’s computer, whose IP address is 192.168.1.10, when he tries to check his email. Simply SSH to the firewall and enter something like this:
tail -f /var/log/shorewall.log | grep 192.168.1.10
and then watch as your user tries to check his email. Shorewall itself also provides “monitor”, “logwatch”, and “show” functions that enable you to watch the firewall status in real time.
Performance
So how does LBU perform? The Linux kernel was built around networking, so it is highly efficient at handling network traffic. The “Why Use LRP FAQ” gives a general idea of what to expect, performance-wise, and there’s also a great review here of an earlier version’s performance. But how did LBU perform on my hardware?
To find out, I used several utilities including Qcheck and Netperf. Basically, the answer is that LBU can easily exceed the performance limits of most network hardware. Using Qcheck from a PII400 desktop system, testing throughput across the LBU firewall (the one running on the PII 500) to a server in the dmz zone, I recorded a tcp throughput speed of 62.5Mbps. Using Qcheck from a P4 2.66GHz machine, across the firewall to the same server, I recorded a tcp throughput of 93.023Mbps.
The results gave me the impression that the limiting factor in those tests could be the ability of the desktop system to spew out packets with Qcheck. So using Netperf, I set up 3 systems to blast everything they had across the firewall to my dmz zone server simultaneously. Amazingly, I recorded 57.2Mbps, 20.56Mbps, and 18.16Mbps on the 3 machines, which adds up to 95.92Mbps. But, you say the network cards are rated at 100Mbps? That’s true, but in real life the practical limits of 100BaseTX Ethernet are generally considered to be somewhere between 60 and 95 percent of that, depending on hardware, protocols, and who you talk to.
On my other LBU firewall, the one running on the P100 with the 10BaseT card, I used the same Netperf technique and saw 2.4Mbps, 3.52Mbps, and 1.04Mbps, for a total of 6.96Mbps, not bad for 10BaseT, and probably the limit of what that network card will do. The bottom line here is that with LBU running on both of these firewall platforms, the limiting factor is not the software.
As far as stability is concerned, I’ve been running versions of LEAF-Bering for several years now, many times on hardware that most folks would throw out, and I’ve yet to see it crash, hang up, or need rebooting unless there was a problem somewhere else. A LBU firewall is basically like an appliance – once it’s installed and properly configured, you can pretty much unplug the monitor and keyboard and forget about it.
Closing Thoughts
So why even bother with all this? Why not just go buy a hardware firewall from CompUSA and be done with it? It’s all about control, flexibility, and expense. The first Linux firewall I built was to replace a $200 hardware firewall. I needed to expose a web server to the Internet, but the only way to do it with that hardware firewall was to have the web server be part of the local network and tell the firewall to forward all(!) outside requests to it. Not a good idea.
Most hardware firewall/routers, even the really expensive high end systems made by companies like Cisco, are limited in some way as to what you can do with them. With LBU, you are in complete control of everything, and limited only by your hardware and imagination. For instance, what if you’d like to add another network interface? With most hardware firewalls, that may be difficult or impossible. But with LBU, it’s easy and cheap to add another network card, (assuming you’ve got an open card slot). Sure, it’s more work setting up an LBU firewall, but it’s well worth the effort if you demand the ultimate in control and flexibility, along with high performance and low cost.
In conclusion, LEAF-Bering uClibc is an Open Source and very powerful Linux based software tool that you can use to build a robust and feature-rich firewall system with standard computer hardware. The installation and configuration will require some effort on your part, but in the end you will have a system that should accommodate the needs of most any small to mid-sized network reliably and without breaking the bank.
Testing Details
When using Qcheck, all tests were done with TCP throughput set at 3 iterations of 1000Byte data sizes. All of the Qcheck tests were run from Windows boxes, the PII400 running Win2k and the P4 2.66GHz machine running WinXP Pro.
The server in the dmz that the Qcheck tests were run against is a P200 Debian Linux box, so I installed and ran the Qcheck “endpoint” Linux application on it during the tests. Unfortunately, since the Qcheck testing interface only runs on Windows, I couldn’t run more than one instance at a time without hauling computers all over the place and running new network cables.
As for Netperf, after installing the application, I set the same P200 Debian Linux box in the dmz to receive netperf tests. I also installed netperf on 3 other boxes in the local network: the first is another P200 Debian Linux box, the second is an ancient AMD 486 DX/4-WB also running Debian Linux, and the third is the same PII400 Win2k box running Win2k that I mentioned in the Qcheck testing above. From the Win2k box, I opened up a command line window and typed netperf -l 30 -f M -H 192.168.2.50 but did not hit enter yet.
NOTE: The netperf command I entered simply means to (-l) run the test for 30 seconds, (-f) format the results in megaBytes, and (-H) point the test at 192.168.2.50. The default netperf test length is 10 seconds, but I ran it for 30 to average out the very slight discrepancies in start time.
Then I used PuTTY to ssh to both of the Debian boxes and entered the same command without hitting enter. I then lined up the 3 windows on my desktop and very quickly clicked to each one and hit the enter key.
The throughput results, in megaBytes per second, were then added together and multiplied by 8 (1 megaByte = 8 megabits) to obtain megabits per second. I could have left the -f parameter out, but I just tend to think in terms of Bytes rather than bits.
It’s worth noting that the dmz server all these machines were blasting packets at was also busy running a web server and an email server (both exposed to the Internet) during the tests, so it’s very likely that the actual throughput across the dmz interface of the firewall was even slightly higher than what I recorded.
The same netperf technique was used on the other system I tested (the one with the 10baseT card), but of course the machine specs are different. The dmz server in that case is a K6II 233 running Debian Linux, the 2 systems I ssh’d to are both P75’s running Debian, and the desktop system I launched from is a P4 2.8GHz WinXP system.