Back to article
Protecting Your Linux System with FireStarter and Storm Firewall
Using a GUI to Configure a System
December 1, 2000
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