Re: Firewall administration.

[Bennett Todd <bet () rahul net>]

On Tue, Oct 07, 1997 at 09:15:12PM -0500, Rick Smith wrote:
> [...] Actually, I mean something a bit different. We need to assume that
> users *won't* have a good understanding of what they're doing. So the GUI
> needs to present choices that clearly relate to what the customers need
> to control, and "under the hood" perform the necessary connections and
> restrictions for them. A trivial example would be to give customers the
> ability to manipulate "services" instead of "port numbers."
>
> Also, keep in mind that I'm speaking from the point of view of someone who
> wants to get as many people as possible using firewalls correctly, even if
> they're not experts in networking or security.

Hmm. I really like this goal. Combine these thoughts with other threads that
have been dangling --- including Brent Chapman's packet filtering paper which
I hit chasing a link from the Sinus Firewall docs, and mjr's remarks in this
forum about canned security stances --- and we have the makings of a nice tidy
small project.

Linux+ipfw+fwtk has all the bits you need to assemble a nice firewall. So what
someone needs to do is roll up a handful of nice boilerplate configs ---
``security stances'' --- and then whip up a nice user-friendly front-end that
offers a choice among the stances, with high-level descriptions to help the
user pick the nearest match to their needs, then uses the chosen stance as an
initial state for a gui front-end, which offers enable/disable choices on
services, with explanations of risks that pop up whenever you try to enable
something to tell you why you might not want to.

Wouldn't even require running X on the firewall; this could all be done with
e.g. dialog(1).

Config options that it sets can be documented, by having nice blocks of
comments in any config files it edits, and having it generate an annotated log
of the commands it issues to make the config changes take effect.

Base it on a minimal Red Hat install, and it'll be easy to add and remove
chunks of software with RPM, and to support updating to track new versions.

-Bennett