February 23, 2019

Protecting Your Linux System with FireStarter and Storm Firewall - page 5

Using a GUI to Configure a System

  • December 1, 2000
  • By Michael Hall
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.

Most Popular LinuxPlanet Stories