On Wed, 3 Jan 2001, Charles Steinkuehler wrote:
> > (Steps in holding up a REALLY LARGE Stop Sign)
>
> Where were you when a took that wrong turn in Alberqueque?!? :>
>
Ah Albuquerque, may I never see it again :-)
<lots of interesting discussion snipped>
> 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... :)
>
If you haven't had a chance to do so yet, I strongly suggest that you have
a look at the Check Point FireWall-1 GUI. The text that you're writing
sounds like pages from their Getting Started guide, and if the group is
serious about going in this direction it might be wise to be aware of what
a bunch of litigious and unfriendly Israelis (I used to work for an
OPSEC partner) have already done.
I continue to question this entire path though, because I've seen the
subtle errors that crop up when using such tools. It's better to
concentrate on making a single box's configuration easier to manage, then
letting the administrator continue to pound designs out on paper or in
Visio/Dia/whatever.
> 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
>
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel
