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 impossible) in shell-script, or possibly to
> > speed up digesting of the configuration files.
>
> In my mind, doing it on the firewall is a requirement. Take ours,
> for example - it doesn't have ftp, or ftpd, or telnet, or nc, or
> wget, or snarf, located on it anywhere. About the only way to get
> things there is either scp or by putting a disk in - and most of the
> time it will be the latter, as scp isn't installed on most stations
> here.
I'd overall prefer it this way anyways. Keeping it on the local system
creates potential security holes, but nothing that write-protecting the
floppy can't fix.
> Also, a firewall to me is a little more dynamic than you all seem to
> be implying - add FTP briefly, take it out, add SSH for a specific
> station, take it out, ... rules change. I'd hate to have to compile
> a new set of rules every time and then copy them to disk and....
Ouch. So you're looking to do this on the fly without flushing and
recreating all the rules? Could be interesting...
> 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.
Is there really a way around this though? I was thinking something like a
rulebuilder XML file - or whatever format gets chosen for the front-end -
being parsed by a startup script and building the ruleset at boot
time. (Or on a 'svi xxx restart' command, either way.) I suppose that you
could have a supplemental command file, or put together an 'onthefly.sh'
that will read input directly from the browser or whatever and apply it,
but how you'd do that is definitely beyond me.
> 2. They require great big things like Perl to run - and so won't run
> on a small system like LRP/Oxygen/EigerStein.
At least, not without making it a NON-small system first.
> 3. Rather than hide the rules, they tend to "create" them - there is
> no abstraction, just a rules generator.
Define here what you mean by abstraction, please? You managed to lose me
mostly here, as that's what I've been envisioning. Unless of course you
meant that they're nothing more than a formatter for the actual rulesets.
> My goals:
>
> * Abstract the firewall concepts sufficiently so a regular person can
> actually understand it (!)
That's always nice. How about Us Lowly Commercial Routing Engineers that
haven't gotten off their lazy butt to learn IPChains to an in-depth
level? =)
> * Use functions and whatever scripts to make "programming" easy for a
> regular person (!)
See above. =)
> * Use functions and whatever scripts to make firewall design simple
> and powerful in the hands of the expert
Ah. I was wondering when you were going to ask for the Holy
Grail. =) Always remember the old adage; "Fast, powerful,
user-friendly. Now pick any two."
> > it's a shame this couldn't happen
> > ITRW (the instant feedback & interaction when brain-storming is one of
> > the big things lost in e-mail or other written communication).
>
> Conference call?? Hmmm....
Distinct possibility, but I don't know how much I can get away with
abusing the WATS line at work. (Although, we ARE a telco as well as an
ISP...) I'd suggest LinuxWorld, but I have a feeling that I'm going to be
the only one easily positioned to actually get there - MA is a lot closer
to New York than Cali. Whatever happens with it, I'd be game.
--
George Metz
Commercial Routing Engineer
[EMAIL PROTECTED]
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel
