Protecting Your Linux System with FireStarter and Storm Firewall

By: Michael Hall
Friday, December 1, 2000 11:44:36 AM EST
URL: http://www.linuxplanet.com/linuxplanet/reports/2719/1/

Using a GUI to Configure a System

With the broadband explosion, there's no denying that demand is high for solutions to basic issues of Internet security.

Despite its relatively secure status when compared to some other operating systems, Linux is still somewhat problematic to deal with, especially as the userbase drifts more and more from experienced technical hands to hobbyists and less experienced users out to try something new. Considering the insecure way some distributions are still shipped, and the pervasive and obnoxious presence of homo scriptkiddeus on the net, there's a lot of room for simple, "out of the box" security solutions on Linux.

In the Windows world, there are several such shrinkwrap products that cost relatively little and provide a few bells and whistles. Linux, of course, has good firewalling functionality built-in or at least easily obtainable, and it will be better yet with the new kernel. At the same time, configuring that functionality is a bit daunting for new users.

We took a look at a pair of GUI-based firewalling solutions for Linux: one a commercial offering from Stormix Technologies (Storm Firewall), and the other a free software project that integrates with the GNOME desktop (Firestarter). Both provide graphical front-ends to ipchains, taking some of the pain out of building tailor-made firewalls for home networks.

It's always tempting to try to drum up a little interest with a false air of competition, but in this case it simply isn't appropriate: one is a tool that enables the harried network administrator or savvy (if deep-pocketed) home user to exercise fine-grained control of a full-fledged firewall, the other is a fast and easy way for a casual user (or network administrator with very simple needs) to toss up a fast firewall on a machine with little concern for the finer points of configuring things.

We used a fairly simple home network to test both pieces of software:

Internet connectivity was provided by a DSL connection to a Duron 650 running the Progeny Debian GNU/Linux beta (Linux kernel 2.2.18-pre15). Since the DSL connection uses PPP Over Ethernet (PPPOE), we took care to identify the ppp0 interface as our uplink to the Internet instead of eth0. eth1 on the gateway machine was connected to a five port hub which is, in turn, connected to a Celeron 400 running Windows 98 and a Dell Inspiron 3800 (Celeron 600) running Debian GNU/Linux 2.2. The only services running on the gateway machine were sshd and exim (an MTA).

Since it's hard to analyze the posture of a network from within, we took advantage of Gibson Research Corporation's Shield's Up! site to provide an outside portscan against which we could test each program. GRC's site reads the visiting machine's IP address and scans commonly exploitable services (POP3, Telnet, FTP, SMTP, NetBIOS, IMAP, Finger among others) on their commonly assigned ports and reports on the apparent disposition of each. Depending on the results from each scanned port, the site assigns a result of "open", "closed", or "stealth." Though the site isn't very clear on the difference between "open" and "closed", a result of "stealth" on a particular port indicates that the firewall is denying packets it filters instead of rejecting them, causing the port scanner to time out rather than reporting the rejected packet. The GRC site is a bit flamboyant at times, but it provides a useful service for verifying, at least, that a simple firewall is likely working.

Getting Firestarter

Firestarter is a free software project headed by Tomas Junnonen of Finland.

Firestarter can be downloaded from the project homepage <http://firestarter.sourceforge.net/>. Binary packages weighing in at around 120KB are available, including RPM's built against GNOME 1.0 or GNOME 1.2 and Red Hat, or a Debian package apparently built against the unstable tree of the project. A source tarball and a source RPM (about 345KB apiece) are also available.

Successful installation of the package from source requires a fairly full complement of GNOME 1.2's development libraries. With those libraries in place, though, the software compiled with no problems at all. The software also installed itself within the GNOME menu system with no problems, where it appears under Programs/Internet.

Using Firestarter

Firestarter can be started from the GNOME menus or from xterm. Root privileges are required to successfully manipulate the firewall, which means either running it as root (su -c firestarter) or setting the binary suid. The software is also designed to support PAM and should, apparently, prompt for root's password if executed by a non-privileged user, but this feature didn't work for us out of the box and we investigated no further.

Upon startup, users can select Run Firewall Wizard from the Firewall menu of the program's window. This launches a very simple installer that asks for the interface linked to the Internet, whether Firestarter should open on PPP connect, and whether the IP address is assigned via DHCP.

The wizard then asks for whether IP Masquerading will be used, what the machine's internal network interface is, what the address range is of the internal network, and whether any services should be exposed to the Internet. Eighteen services in all are listed on this window, including everything from Telnet and POP to NFS and Xwindow.

After configuration of basic networking and services, the wizard then asks about ICMP filtering, and offers eight different filters for ICMP packets.

Basic familiarity with your LAN and the services you're willing to leave hanging out on the Internet are enough to have the program up and running in under a minute. It took eight clicks to go from starting the wizard to a running firewall.

Once running, there's little to do but sit back and wait for prying little fingers. We were gratified that an unknown collaborator operating on a machine somewhere in Florida provided us with a quick look at Firestarter in action when we took a break, and the Firewall Hits tab of the program window dutifully reported his interest in locating an IMAP server. That, in turn, caused us to check out the program's Dynamic Rules tab, which allows for quick adjustments to the general complexion of the firewall by adding machines which must always or never be blocked, or designating services as open or closed against the entire Internet or only specific machines.

Despite the "live fire" exercise from our curious collaborator, we paid a visit to the Shields Up! site where we were comforted to note that the ports it scanned were, indeed, shielded by the firewall, which dutifully dropped packets into the ether without bothering to tell the portscanner.

Besides the running log and dynamic rules tab, there's little more to Firestarter than a green "start" button and a red "stop" button. Configuration options allow users to designate a sound to be played when packets hit the firewall, change the behavior of the program at startup and finish, or allow the user to designate which ports shouldn't be logged.

In addition to providing the GUI interface, Firestarter writes a reusable script (/usr/local/etc/firestarter/firewall.sh) users can insert in rc.local or link to in /etc/init.d to allow the firewall to be started at boot time, which means that once the program is run a single time, the user never need interact with it again unless a change is desired in the firewall's basic parameters.

Assessing Firestarter

Firestarter is a nice piece of software for simple needs, which makes it great as a small GNOME app. It doesn't offer a ton of "stuff," it just quickly and efficiently secures a machine and offers enough notification and information for users to decide how to react to apparent port scans or attacks. By providing a handy menu in the setup wizard, it's easy to open and close services selectively in no time. It's a great solution for someone looking to secure a LAN or single workstation without a lot of hassle, providing a little peace of mind for free. The script it generates, it should be noted, is annotated fairly clearly, too, which means someone looking to learn a little about what's going on underneath the GUI can.

Next, we looked at Storm Firewall, a commercial offering from Stormix Technologies, producers of the Storm Linux distribution, which is based on Debian GNU/Linux. Storm Firewall is quite a bit more elaborate than Firestarter.

Getting Storm Firewall

Storm Firewall is available from the Stormix Technologies site for $99.95 or from a number of online retailers for about $10 less. In addition to the firewall software itself, users get 60 days of phone and 90 days of e-mail installation support, a copy of Storm Linux 2000, and a printed manual 113 pages long.

System requirements for the package are somewhat limiting with regard to supported distributions: Red Hat 6.x, Storm Linux 2000, or Debian 2.2 are the only ones listed that the software is "known to run with". It installed with only a minor hitch on our Progeny Debian system via a simple text-based installer, and installed icons on our GNOME (and KDE) menus. The manual states that the installer will allow a user to go ahead and attempt installation even if the distribution in question isn't officially supported.

The hitch we encountered has, according to a spokesperson for the company we spoke to when first looking at the product several weeks ago, been corrected, but there was an apparent error in the order in which the installation tries to install the packages that comprise the firewall software itself and the components of the Storm Administration System (SAS) required to launch the configuration module. Users who get an older copy of the software can simply abort the installer when it encounters the error in question, install the needed package by hand from the CD using either rpm -ihv or dpkg -i, and then restart the installer. Again, this problem has been corrected according to Storm.

A Word About the Manual

We'll confess to a profound aversion when it comes to reading the fine manual with most products. In general, it's either something you figure out or you don't, and the manual is a last resort because technical writing is so often wearying. We were, however, very pleased with the quality of documentation provided with this product.

Not only is the installation and use of Storm Firewall outlined, but a very thorough introduction to networking and security basics is provided over the course of 42 pages before Storm Firewall itself is even mentioned. In a lot of ways, that 42 pages creates a lot of the value to be found in the package, providing much usable information that turns configuring the product into less of an exercise in blindly pointing and clicking through recommended options. With sections like "Understanding the Protocol Stack," brief explanations of UDP, TCP, packet fragments, and more, Storm has provided a useful tutorial that's fairly readable, as well. A final section details how to respond to possible attacks or hostile port scans in measured, reasonable tones.

Running Storm Firewall

Like Firestarter, Storm Firewall is a GUI front-end to ipchains. There's a lot of difference, though, in how the two programs go about building a firewall.

On startup, Storm Firewall presents a wizard that first asks for a default security stance. Users may select either "Default Allow," which allows for masquerading, performs automatic blocking of some common exploits, and allows traffic to move fairly freely across the protected interface unless it's specifically blocked during configuration. We spoke to Simon Kirby of Stormix, who said these settings are best for simple home use and assume that the machines behind the firewall are not running any services to speak of.

Users may also select a "Default Block" stance, which blocks all traffic across the interface unless it's specifically allowed during later configuration. This setting does exactly what it says, and isn't one for casual users looking to seal off a few services they happen to run across their LAN: it requires a fairly thorough knowledge of the system, and until it's set up correctly it will clobber all incoming and outgoing traffic.

Once a stance is selected, users must then select which network interface provides the uplink to the Internet, toggle masquerading, and configure the internal net mask. They may also opt to block IP spoofing and source routing, with an option to allow loose UDP masquerading for some games that would be blocked by a more strict configuration.

In each case where multiple options are offered, there are sensible possibilities presented by default, with other valid possibilities offered in a drop-down menu.

We were able to complete configuration via the wizard with less than a dozen clicks. Because of the nature of the product, however, there's plenty more to configure once the basic wizard has been run.

For instance, in a "default allow" stance which is one home/casual users are going to be most likely to adopt, provided they've taken the time to turn off any services their distro may have shipped running, there may still be a few potentially exploitable ports they may want to close off. Our test machine, for instance, was running an MTA we didn't want exposed to the rest of the world. Storm Firewall provides four configuration tabs to do the fine-tuning required. Two tabs cover incoming and outgoing protocols, two tabs cover incoming and outgoing services.

By selecting a protocol from the appropriate list, for instance, in a "default allow" stance, users then block all traffic of that protocol from passing into the LAN. It's possible, as a result, to selectively block everything from ICMP to VMTP packets. Once a protocol is blocked or allowed, it effectively blocks or allows any services using that protocol.

In addition to the incredible fine-grained control of protocols and services, Storm Firewall provides a rules editor that allows users to control in even more detail the way their firewall works, or to create their own chains. While it may not be a level of control the "average user" or even network administrators in many situations will need, it's there and it's a usable tool for managing what can often be complex schemes.

As with FireStarter, Storm Firewall produces a script, but it's automatically invoked in /etc/init.d by the Mid module at startup, which is placed there by the Storm Firewall installer.

Another element of the Storm Firewall package is the support itself. We encountered some difficulties during our use of the software. We placed a pair of calls--one to our contact person at the company who was out, and one to Stormix's technical support staff. The assistance we received was excellent: the person on the other end of the line was helpful and willing to explain things. When we got a call back from another employee about earlier queries, the information we received was equally helpful and competent. As it turned out, our "problems" weren't problems, but a misunderstanding of the way protocol and services settings interacted and what a "common exploit" was according to the program's configuration wizard. Though one of the employees we spoke to acknowledged that the software tends toward the slightly more complex, we'd maintain that complexity is a forgivable vice in a piece of software charged with protecting a network. In other words, any issues we had with getting the software up and running can't be blamed on the superior manual or fairly easy-to-understand basic settings.

Assessing Storm Firewall

We'll confess that our initial reaction to this product was a little chilly. $100 seems like a lot of money to lay down for a GUI front-end to a fairly well documented tool. A few things helped us warm up to it:

First, the included manual is superb. There are books on the shelves of the local booksellers selling for $40 or more that, while they may provide a lot more text, give more than we really need to know to feel comfortable with the subject matter on a working basis. The manual was just right. Second, the technical support was excellent. The representative we spoke to was competent and knowledgeable. Sixty days of support like that on a product may well be worth $100 to people with the burden of safeguarding a network from harm.

Storm Firewall still isn't going to be for everybody. $100 is a lot to pay for a home network with fairly static characteristics and few services to worry about. The complexity of the tool also moves it out of the comfort zone, since half its functionality is wasted on basic home users.

We'd still enthusiastically recommend it to professional users, though, who will probably not mind having their company pay the money to provide them with a tool that makes their lives a little easier or give them the cushion of solid technical support.

Parting Note

FireStarter and Storm Firewall are both great packages if deployed in the appropriate context. One thing we noticed both lacked, though, is an automated response system of any sort. It's up to the user to note a potential attack or hostile scan in the logs and specifically disable access by a host. To a certain extent, that's no big deal: if the firewall's sound, the kiddies can come and scratch at the door to no great effect. Both offer easy righ-click menus that allow the offending host to be dropped forever. According to Stormix's Simon Kirby, though, automated reactions to trigger events is under consideration for the next version of the product, due out early next year.