> > > > I would suggest some sort of watchdog feature. If the ssh link
> > > > breaks then revert to the previous configuration.
> > >
> > >I don't know about LRP 2.9.4 and its descendents, but LRP 2.9.7 and
> > >all descendents (including Oxygen) come with a watchdog daemon;
> > >Oxygen comes wit
Mike:
> > > I would suggest some sort of watchdog feature. If the ssh link
> > > breaks then revert to the previous configuration.
> >
> >I don't know about LRP 2.9.4 and its descendents, but LRP 2.9.7 and
> >all descendents (including Oxygen) come with a watchdog daemon;
> >Oxygen comes with it
At 08:50 AM 01/16/2001 -0600, David Douthitt wrote:
>On 16 Jan 2001, at 0:53, Mike Sensney wrote:
>
> > I would suggest some sort of watchdog feature. If the ssh link
> > breaks then revert to the previous configuration.
>
>I don't know about LRP 2.9.4 and its descendents, but LRP 2.9.7 and
>all d
On 16 Jan 2001, at 0:53, Mike Sensney wrote:
> I would suggest some sort of watchdog feature. If the ssh link
> breaks then revert to the previous configuration.
I don't know about LRP 2.9.4 and its descendents, but LRP 2.9.7 and
all descendents (including Oxygen) come with a watchdog daemon;
At 08:39 AM 01/15/2001 -0600, David Douthitt wrote:
>On 14 Jan 2001, at 20:21, Scott C. Best wrote:
>
> > Yes, agreed. Taking this to an extreme, you could wrap a user login
> > for, say, ~firewall, into a custom shell that had nothing *but*
> > compiled firewall configuration commands.
>
> > I'm
On Mon, Jan 15, 2001 at 08:39:26AM -0600, David Douthitt wrote:
> On 14 Jan 2001, at 20:21, Scott C. Best wrote:
>
> > Yes, agreed. Taking this to an extreme, you could wrap a user login
> > for, say, ~firewall, into a custom shell that had nothing *but*
> > compiled firewall configuration comman
David:
Hello! Some thoughts:
> > Yes, agreed. Taking this to an extreme, you could wrap a user login
> > for, say, ~firewall, into a custom shell that had nothing *but*
> > compiled firewall configuration commands.
>
> > I'm working with some others to build something like this now,
> >
On 14 Jan 2001, at 20:21, Scott C. Best wrote:
> Yes, agreed. Taking this to an extreme, you could wrap a user login
> for, say, ~firewall, into a custom shell that had nothing *but*
> compiled firewall configuration commands.
> I'm working with some others to build something like this now,
> t
Charles:
> I'm thinking whatever the firewall config language looks like, the parser
> (at least for LRP/leaf) will be primarily shell, with perhaps a few special
> commands (compiled...maybe added to busybox) to help with the parsing.
Yes, agreed. Taking this to an extreme, you could wr
> > It would be nice to have a general purpose programming language
> > available. I believe Dave plans to include Python as part of the
> > standard Butterfly disto.
>
> Worries me in two ways: extra size and giving anyone
> who does compromise the firewall a development environment.
Yeah, that'
Charles:
> It would be nice to have a general purpose programming language
> available. I believe Dave plans to include Python as part of the
> standard Butterfly disto.
Worries me in two ways: extra size and giving anyone
who does compromise the firewall a development environment.
> Th
> I'm still interested in a configuration file that uses objects and OO
> to create firewalls - someone called it a formatter; I'm beginning to
> consider it a sort of "firewall rules compiler" or something like
> that. Using ruby is quite tempting, even though it isn't big and
> normally won't b
David:
Sorry, let me try to clarify:
> > > In my mind, this is THE biggest problem with almost all Script
> > > Generators, whether from the command line or a GUI: if you make
> > > hand- tuned changes, then they will be lost next time the generator
> > > runs.
>
> > This speaks volumes
On 11 Jan 2001, at 18:13, Scott C. Best wrote:
[David Douthitt wrote:]
> > In my mind, this is THE biggest problem with almost all Script
> > Generators, whether from the command line or a GUI: if you make
> > hand- tuned changes, then they will be lost next time the generator
> > runs.
> This s
[EMAIL PROTECTED] wrote:
> ...
> ps2: XML parsers aren't that dificult to build, but it's a long work!
There are C parsers out there and ready to be used in the
applications, ie. James Clark's parser! It's pretty thin, and I believe
LRP can appreciate that.
Cheers,
Ly Vuong
>I was thinking along similar line, using XML as the configuration
> file. The front end (Menu/Script/GUI) can use this XML conf. file to
> display & allow for modifications. This also allows an external
> generator (script/utility...) to transform this XML file into specific
> rules file to b
I was thinking along similar line, using XML as the configuration
file. The front end (Menu/Script/GUI) can use this XML conf. file to
display & allow for modifications. This also allows an external
generator (script/utility...) to transform this XML file into specific
rules file to be consume
Pedro:
> > > IMNSHO, I think LEAF should specify exactly that .conf file
> > > format as one of its first objectives.
> > >
> > > -Scott
> > >
> >
> > My thoughts EXACTLY
> >
> > -Kenneth Hadley
> >
>
> pardon my intromission,
> but this is exactly the kind of use XML was made for, if you cre
> -Original Message-
> From: Kenneth Hadley [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 11, 2001 6:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Leaf-devel] Grand New Firewall Paradigm
>
>
> - Original Message -
> From: "Scott C
- Original Message -
From: "Scott C. Best" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 11, 2001 10:09 AM
Subject: Re: [Leaf-devel] Grand New Firewall Paradigm
> David:
>
> > > ...I might create the original config with the
David:
> > ...I might create the original config with the
> > script generator Then go poking around in the config file and make
> > some changes rerun the script generator and have recognize the
> > changes (it shouldnt even notice the difference) be at a remote
> > site and connect via SSH and
On 11 Jan 2001, at 16:53, Kenneth Hadley wrote:
> my biggest thought is that each method would need to follow the
> same guildlines of where and when the data is written to a
> configuration filethus allowing all three methods to access
> the same file aka I might create the original config w
> > (I was looking at http://www.crocodile.org/~vadim/fwbuilder/ for a
> > examplebut custom)
>
> That is FANTASTIC! Conceptually, I think this is a sort of what I
> had in mind, though not with the GUI. With a proper channel to
> getting the results over to the firewall box, this could be a
- Original Message -
From: "David Douthitt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 11, 2001 8:37 AM
Subject: Re: [Leaf-devel] Grand New Firewall Paradigm
> On 11 Jan 2001, at 6:43, Kenneth Hadley wrote:
>
> > just adding
On 11 Jan 2001, at 6:43, Kenneth Hadley wrote:
> just adding my own two cents but im wondering why not implementate all
> three methods (that I see)?
>
> 1) Question/menu based script generator
> 2) Editable Config file
> 3) GUI based editor
All of them have their place. Some prefer one over th
method of config is decided on you should be able to use
all three methods
-Kenneth Hadley
- Original Message -
From: "George Metz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 10, 2001 10:11 PM
Subject: Re: [Leaf-devel] Grand New Firewall Parad
On Wed, 10 Jan 2001, David Douthitt wrote:
> On 5 Jan 2001, at 8:31, George Metz wrote:
>
> Eeeeps, did I get you on a bad day?
No, it just amazes me that people fail to implement if-then logic in
common situations. =)
> Anyway, to answer your question:
>
> "I want to modify that special por
On 5 Jan 2001, at 8:31, George Metz wrote:
> Oh good gods. You mean that none of these morons that have been
> writing those scripts can't do simple if-then tree logic?
>
> Q: Do you want to build rules or modify?
>
> (IF $Q = Build, then goto NEW;
> ELSE goto Mod)
>
> A: Modify
>
> [Mod]
>
Mike:
Two excellent points:
> What if I have a static IP from my ISP? Then I don't use DHCP, PPPoE,
> etc. and won't have that DNS info.
>
> I may either need or prefer to use IPs in certain situations. If you
> don't allow me to define IPs I may perceive this as a barrier and I
> won
At 01:03 PM 01/05/2001 -0800, Scott C. Best wrote:
>Mike:
>
> > What about DNS servers? They are best referred to by IP.
> > Especially if they belong to your ISP.
>
> Hmm. I was working with the model that the firewall
>would be giving out DHCP leases to the clients on the LAN,
>and acti
Mike:
> What about DNS servers? They are best referred to by IP.
> Especially if they belong to your ISP.
Hmm. I was working with the model that the firewall
would be giving out DHCP leases to the clients on the LAN,
and acting as their DNS forwarder. As to what the firewall
forward
At 10:30 AM 01/05/2001 -0800, Scott C. Best wrote:
> > Just a thought, you could extend this a little by adding:
> > [SERVICE]_HOST_IP="xxx.xxx.xxx.xxx"
> > [SERVICE]_HOST_NAME="host.name"
> > This would add some extra design flexibility for the firewall
> > maintainer but should be easy t
> > First off...hello! My name is Scott Best, and I was
> >recently invited to this list by Mike Sensney. I hope I
> >can help contribute. :)
>
> Thanks for the credit, but I think it actually was Mike Noyes who
> invited you. :-) Glad to have you on the list.
Whoops! Mea culpa
Most people I know tend to write code first before they even know for
sure what the whole program is going to be. I do it that way myself.
The program grows in fits and starts. Design decisions are put off in
favor of coding the really fun parts of the program. The problem gets
worse if there
On Thu, 4 Jan 2001, David Douthitt wrote:
> > Ouch. So you're looking to do this on the fly without flushing and
> > recreating all the rules? Could be interesting...
>
> No, not really. See below.
>
> This is what I'm thinking of: the typical one-shot firewall rules
> generator goes like th
At 03:52 PM 01/04/2001 -0800, Scott C. Best wrote:
> First off...hello! My name is Scott Best, and I was
>recently invited to this list by Mike Sensney. I hope I
>can help contribute. :)
Thanks for the credit, but I think it actually was Mike Noyes who
invited you. :-) Glad to have you
First off...hello! My name is Scott Best, and I was
recently invited to this list by Mike Sensney. I hope I
can help contribute. :)
A quick though on something I read earlier from
one of David's emails:
> From: "David Douthitt" <[EMAIL PROTECTED]>
> Date: Thu, 4 Jan 2001 09:10:1
and of GTK+ -- I've used Ethereal under WinNT with winpcap.dll
--
Jack Coates
Monkeynoodle: It's what's for dinner!
On Wed, 3 Jan 2001, Mike Sensney wrote:
> From the Cygwin home page: "The Cygwin tools are ports of the
> popular GNU development tools and utilities for Windows 95, 98, and
> N
On 4 Jan 2001, at 4:15, George Metz wrote:
> On Wed, 3 Jan 2001, David Douthitt wrote:
> Ouch. So you're looking to do this on the fly without flushing and
> recreating all the rules? Could be interesting...
No, not really. See below.
This is what I'm thinking of: the typical one-shot firewa
From the Cygwin home page: "The Cygwin tools are ports of the
popular GNU development tools and utilities for Windows 95, 98, and
NT. They function by using the Cygwin library which provides a
UNIX-like API on top of the Win32 API." http://www.cygwin.com
I loaded Cygwin on my W2K box and have
On Wed, 3 Jan 2001, David Douthitt wrote:
>
> 1. They only generate ipchains on a one-shot deal; if you want to
> repeat you have to regenerate the script and rerun it. These
> utilities usually generate a shell script with all of the ipchains
> rules in it.
Which is why I suggested an init-sc
On Wed, 3 Jan 2001, David Douthitt wrote:
> > I don't think a secondary system is a requirement...you can do lots of
> > very powerful things in shell script, and the code is usually pretty
> > small. If necessary, some C code could be written to do things that
> > were too cumbersome (or imposs
On 4 Jan 2001, at 2:36, Charles Steinkuehler wrote:
> > One of the things that would be (almost) required is a secondary
> > system though; which is similar to either what Donovan was
> > suggesting - run it on a workstation, and copy the files to the
> > target system -
>
> I don't think a secon
On Wed, Jan 03, 2001 at 05:53:52PM -0600, David Douthitt wrote:
> On 3 Jan 2001, at 23:38, Donovan Baarda wrote:
>
> > Ummm, maybe I am out on my own, but what is wrong with having a bulky
> > fw-builder app that runs on a full machine to generate a light-weight
> > fw that can be loaded onto the
I didn't realize this till later, but perhaps we have something
useful already. at least *I* do :-)
I'm going to try this out and see just exactly what it does. I'm not
satisified entirely with the "watch the traffic and allow it"
approach to firewalling, but it may be a good quickstart,
On 3 Jan 2001, at 23:38, Donovan Baarda wrote:
> Ummm, maybe I am out on my own, but what is wrong with having a bulky
> fw-builder app that runs on a full machine to generate a light-weight
> fw that can be loaded onto the leaf machine?
What "full machine"? If I'm Mr. Home User with Windows 95
On Wed, Jan 03, 2001 at 09:31:01AM -0600, David Douthitt wrote:
> On 3 Jan 2001, at 2:32, Charles Steinkuehler wrote:
[...]
> What about things like Mason, which scan typical traffic and
> implement rules to match? Problem with Mason is it relies on Perl
> (not nice in an embedded context).
Um
> > Various scripts like sea-wall, Matthew Grant's scripts, and many
> > 'click the box & build a script' type programs. These solutions
> > can be very easy to use, and configurable (to an extent), but they
> > quickly run into problems when dealing with arbitrary situations
> > that were not pl
On 3 Jan 2001, at 4:08, George Metz wrote:
> Can we do this by defining strings?
>
> For example; if the high level definition were placed into the
> config util as:
>
> "I want my firewall to forward web connections from the world to
> my webserver."
>
> Could that be interpreted as:
>
> "I w
On 3 Jan 2001, at 2:32, Charles Steinkuehler wrote:
> Current solutions:
> Various scripts like sea-wall, Matthew Grant's scripts, and many
> 'click the box & build a script' type programs. These solutions
> can be very easy to use, and configurable (to an extent), but they
> quickly run into p
50 matches
Mail list logo
