Sounds like CheckPoint's GUI, or even more like Cisco's Network
Configurator (not sure of the name, no one really uses it).
I have to admit I'm pretty ambivalent about changing focus. Firewall
configuration focusses on the router because it is a router. Call it a
packet filter or a firewall or a proxy or a bulkhead, it's supposed to act
as a permeable border between two or more areas.
A GUI (or even CLI) tool that attempts to abstract away from this idea is
destined to end up in the same penalty box as Linuxconf and its ilk.
Those who use it end up frustrated because it only works 80 or 90 percent
of the time, and because it seems to bear no relation to the help they get
from mailing lists (e.g., compare configuration of sendmail or apache via
linuxconf vs. configuration of sendmail or apache via the FAQs or mailing
lists for those programs). Admins and geeks simply won't use it, because
of the 10 or 20 percent of the time that it doesn't work right and because
it leads to sloppy habits and because they're proud of understanding the
"right" way to do it.
So I think it's better to concentrate on tools that make each router
easier to configure individually, then documentation that teaches people
to design and document the policy first, rather than diving directly into
configuration on a random router.
--
Jack Coates
Monkeynoodle: It's what's for dinner!
On Wed, 3 Jan 2001, Mike Sensney wrote:
> Here is my attempt at restating the problem.
>
> Charles mentions the various tools in current use, like Seawall and
> the extended scripts and what is wrong with them. (Not easily
> extended and/or modified beyond their original limited purpose.)
>
> Where I see the problem is that current routing/firewall design
> philosophy centers on the router. Instead the focus should be on
> subnets and how the various subnets in a network relate to each
> other. Then finally what routers are used to connect the subnets.
>
> Take a real world problem like Charles' TX facility. You should be
> able to describe the TX facility (or any other network) to our
> hypothetical compiler as one unified specification. Then the compiler
> should be able to generate the firewall/routing rules for each and
> every router on the network, including the Cisco from the one unified
> specification.
>
> At 08:30 PM 01/02/2001 -0600, Charles Steinkuehler wrote:
> >4 DMZ networks firewalled from each other (some specific services
> >allowed)
> >3 Internal networks firewalled from each other (again, sharing some
> >specific
> >services)
> >Appropriate connections between:
> > Internal networks and the DMZs
> > DMZs and the internet
> > Internal networks and the internet
> > remote networks and the internal networks (via VPN)
> >
> >This is actually a description of the TX facility, which is
> >implemented with
> >3 LRP boxes and a Cisco router...
>
>
> _______________________________________________
> Leaf-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/mailman/listinfo/leaf-devel
>
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel
