So many replies, such little time. :) Will start
with this one:
On Fri, 2 Feb 2001, Eric Wolzak wrote:
> >
> > > 1. To make UI design easier for everyone, it'd be *nice* if the user's
> > > intentions for the firewall were stored on the firewall in XML format.
> > > A firewall.conf, as it were.
> > >
>
> I do agree about the description of the firewall in XML (see my
> mail) but why does this description has to be physical on the
> Firewall ?
> because the Firewall as a machine and the description belong
> formally together as a kind of source code ?
Yes. I gave it all of 5 minutes thought, but that's where
I ended up with it. The firewall.conf file is what would/could make
a firewall unique, and so it should be uniquely stored on the
firewall itself.
> As nr 2 is not on the Firewall itself the output from 2 which is
> machine /project dependant is the real effector. and has to be on
> the machine itself. if #2 is too big, too complex or whatsoever that
> we decide not to run it on the box itself why should the "source
> code be on the box
I'm thinking #2 could be either on the firewall itself
(a typically script-based tool like Seawall leaps to mind), or
could be something remote, like on a win-client or a remote
server. It's *output* is what actually affects the firewall, so
that piece has to get back onto the firewall machine. But the
output doesn't have to stick-around either: the output could be
an bash script filled with ipchains commands that just deleted
itself after it ran, for instance.
In general, though, the most robust thing to do is to put #1
and #2 on the same machine. I'm not aware of anything that *doesn't* do
that right now, in fact. As I was writing these three up, and thinking
about how *I* intend to make #3 remote (which has clear advantages
regarding eliminating a byte-heavy GUI from a CPU and storage-constrained
embedded system), I just started to wonder if #2 could become remote as
well. Apologies for the confusion. :)
-Scott
> > > 2. Given this firewall.conf file, a middleware process/app/script would
> > > be needed to turn this data into the OS-specific firewall commands
> > > (e.g. ipchains, ipfwadm, netfilter, etc). This middleware piece could
> > > produce either a root-executable script, install the rules directly,
> > > or even do both.
> > >
> > > 3. Given #2, you don't care *how* #1 gets updated. It could be thru a
> > > command-line console interface, a LAN-based Windoze app, or a remote
> > > server running some ASP scripts connected via an SSH session. Or
> > > just vi.
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
