> (Steps in holding up a REALLY LARGE Stop Sign)
Where were you when a took that wrong turn in Alberqueque?!? :>
> Not picking on you Mike, but you're the first to step out into the open on
> this issue, and the first to do more than hint about the possibility.
>
> Are we looking at a rewrite of how firewalling configuration is done? Or
> are we looking at redoing firewalling altogether? The latter seems to me
> like reinventing the fifth wheel. I don't see it going that way
> necessarily, but failing to clarify this right now in the early phases
> could lead to a lot of misunderstandings and "wasted" work.
See below...
<snip>
> Realise too, that if we want to get technical and
> proper, LRP DOESN'T firewall, it filters packets.
Quite correct...
> > 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.
>
> Ideally, yes. The problem there lies with how exactly you get the program
> to understand what it's looking at. It's a lot easier to write a program
> that parses a text file for keywords and changes them into IPChains,
> Netfilter, ipfwadm, or Cisco ACL commands than it is to get the same
> program to understand basic and intermediate level networks intelligently
> enough to be able to turn a diagram into a fully-functioning and effective
> firewall.
>
> Personally, I'd like this more than just the firewall builder, because it
> would then mean that you could quite easily configure the entire LRP
> system.
>
> 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 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.
> or possibly
> something along the lines of modmaker, where you go to a website and
> configure it for your network there. Personally, I'd rather see something
> that can run via a small webserver like Charles' weblet stuff, but that's
> me.
OK, my perspective on some of the above:
I want something more than some handy shortcuts for building lists of
packet-filter rules. There are lots of these already around, some of them
quite sophisticated (do a search for firewall on freshmeat). None of these
systems, however, really seem to help in the task of abstracting a firewall,
they just create some notational shorthands to save on typing. You could
argue that the calling of procedures (or rule snippits, or whatever) is an
aid to understanding, which it is, but no more so than putting appropriate
white space and comments into your rule-list, which we all do anyway, right?
;-) The big benifit is to the environment, as we cut down fewer trees to
make the paper to print the rules out if they are grouped in callable
procedures, rather than all listed in-line. :/
I'm looking at the 'firewall' as a black box. There are several network
connections, with packets coming and going. I'm looking for a clear,
concise method of describing what happens to packets as they traverse the
black box, which is a functional definition of the 'firewall'. Listing a
huge set of packet filter rules implemented in ipchains is one way of
describing the behavior of the black box, but I'm not convinced it's the
best way. It certianly doesn't seem very intuitive if you don't spend a lot
of time with packet filters.
Pretty much all networking related configuration could be directly generated
from an appropriate functional description of the black box, including
interface setup, proxy-arp, static-NAT, QOS, and anything else that happens
inside the box (I don't want to do this all right now, but it should be
considered). I'm just looking for a way to describe the functionality in a
clearer and more consistent manner than the conventional startup scripts and
multiple config files...
Usually, I mull this sort of thing over for a while in the back of my brain,
and at some random point, a solution will pop out. The alternate
perspectives provided by everyone here is quite helpful to me in this
brain-storming process...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). I guess we'll all have to crawl out
of our holes once in a while for face-to-face contact, at least until
computers get more creative than we are... :)
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
Thought for the day: The speed difference between today's personal computer
and the first personal computers (early IBM, Apple or similar) is greater
than the difference between your walking speed and the speed of the
Concorde, which flys at about 1300 Mph (remeber, computers do more than one
thing per clock now, and used to take several clocks per instruction, adding
to the MHz speed difference)
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel
