> > For instance, the following network:
>
> ...is a nightmarish FrankenNetwork. Hence EigerStein perhaps? I applaud
> you for making it work well. =)
Who said it worked well? :>
> > The complexity level of configuration grows dramatically as the scripts
are
> > 'generalized' to try and do more and more things.
>
> This is easily worked around. For LRP - as a rather appropriate example -
> you simply do multiple scripts for a base point. If Frank were to set up a
> home system with this, he'd choose "Basic Masqueraded Home Firewall" as a
> starting point, with descriptive text to the effect of, "This is a basic
> home firewall situation where you want to use multiple computers, but only
> have one IP address. Typical setups for this include cablemodem, DSL, or
> dialup." (That's a rough idea, but a starting point.)
I think you continue to run into a bunch of the same problems. You've got
some pre-defined things that are easy to use, and possibly even somewhat
customizeable. Once you get beyond the functionality initially planed for,
however, you're thrown directly into coding your own rulesets at a very
low-level. There's currently no in-between that I'm aware of.
> > It is typically difficult to re-use work (configurations or
customizations)
> > done in one environment in other environments.
>
> Again, basic scripts can help remedy this.
Enlighten me...I've banged my head against the limitations of:
Matthew's firewall scripts
My extended scripts (1.0)
My extended scripts (1.1)
My hacked extended scripts (currently unreleased)
About the best I've done so-far is the addition of a few "If this file
exists, execute it" lines in the scripts, which allow me to patch new rules
into the scripts by hard-coding some ipchains commands. Not real
user-friendly, and lots of problems for the unwary...
> As a side thought, would this
> work for the purposes of configuring an entire LEAF/LRP system with a
> little bit of extension?
It's quite possible...
Perhaps the "Firewall Description Language" can include enough info about
network configuration that it could also configure the interfaces. It sure
seems like the linux world could use a good network config standard (and
probably a lot of the rest of the world, as well).
> > What I alluded to previously, and am rapidly warming to the more I think
> > about it, is an object oriented mechanism for building firewalls. Sort
of a
> > firewall construction kit, but very much in the abstract.
>
> Careful there. It SOUNDS like you may be trying to implement a pretty
> large software package. How OO do you mean? Are we talking like Visual
> Basic Object Orientation? Or just modular implementations?
Modularity is MANDATORY, along with the ability to re-use modules in
multiple locations, and a heirchial scheme (modlues can be made of other
modules). Modules should also be configurable on instantiation. (This is
sounding very OO :> ).
> > Networks would be defined, and assigned basic classes (like DMZ,
masqueraded
> > internal net, routed internal net, external net, etc). There would be
> > default interactions between different classes of networks, which could
be
> > overridden by modifying the basic class, the specific instance of that
class
> > for a particular network, or the creation of entirely new access classes
> > (possibly by modifying or combining existing classes).
> >
> > All very object-oriented and buzzword-compliant :>
>
> Sounds here like you're referring to modularity. If so, cool. =)
Modularity, but I'd like to see some level of inheritance and the ability to
customize, as well.
> > Once the overall policy was defined, some low-level routines would be
> > responsible for building rules that implement the desired result. This
> > would probably be the easy part, and I think such a system could easily
> > target ipchains rulesets, netfilter rulesets, Cisco rulesets, or just
about
> > any other system that comes along.
>
> Careful there. I can think of several examples where this would be
> nightmarish to apply - Namely Flowpoints, Ascend/Lucent Pipeline routers,
> and Netopias. The latter two have menu-driven interfaces with a
> supplemental CLI, and Flowpoint has the DSL Tools, but interfacing with
> them is a royal bitch. As a note, I'm assuming that ipfwadm will work just
> as well for the purposes of those using stock 2.9.8 images on 486s.
ipfwadm would be a reasonable target, as would any system that supported
arbitrary IP packet filtering. There are many systems that do not support
arbitrary firewall rule creation...these systems would probalby not be
supportable (at least easily) as targets. In addition, some high-level
features (masquerading, static-NAT, stateful packet filtering, ip-helper,
etc.) may or may-not work on your chosen target...this would be handled by
the 'back-end' responsible for converthing your firewall specification to
acutal rules.
> > Some features (like stateful packet
> > filtering) may not be fully implemented on all target systems (like IP
> > chains) but this would be handled by the low-level 'compiler'. It might
be
> > possible to make a close approximation (-j ACCEPT ! -y), you could throw
an
> > error, or anything else your heart desired (the translation from
high-level
> > specification to low-level rules would also be very object based). This
> > would all be abstracted the same way the basic filter specifications
are, so
> > if Joe created "Joe's way-kewl ipchains packet-filter routines", anyone
else
> > who thought the rules were pretty neat could easily incorporate them
into
> > their own custom firewall, likely by simply grabbing Joe's rule files
and
> > changing a couple words in a high-level config file.
>
> This is where things get really cool, really interesting, and EXTREMELY
> dangerous. Too easy for someone to distribute a file that people will look
> at the description for and just implement, thereby cracking their firewall
> open for Joe and anyone else he gives the info to. Any way to make a
> warning for anything that might make it LESS secure? (IE, opening ports,
> forwarding services that weren't forwarded before, etc.?)
Warnings and errors will be a mandatory part of the basic system, especially
since it's quite possible to (perhaps unknowingly) request confilcting rules
by combining differnet modules (objects). There should be some sort of
easy-to-read firewall summery generated for verification of the generated
ruleset, but this is probably not going to do anything to help the folks who
download "Captain X's hot gamer ruleset" and blindly install it...
> > With the complexity of creating firewall rules, and the amount of money
> > being thrown around in the networking arena, I can't believe there isn't
> > something kind of like this available already (please someone send me a
link
> > so I don't have to start coding!).
>
> I haven't seen one, and I've looked a bit. There are options, such as the
> EchoWare stuff that Scott Best has been doing, but that requires a
> client-server relationship with a website via SSL to configure. I'd prefer
> something a little more local on all levels.
I'm beginning to think of this as a "fireall description language", with the
goal of creating clear, consise, descriptions of any arbitrary firewall,
without having to worry (in most cases) about the low-level packet-filtering
details. Like other computer languages, it could be 'compiled' to a variety
of targets. Also in common with other computer languages, is the desire to
allow us humans to work in a distilled, structured environemnt, where the
details of exactly what's happening are clear, while the computer takes care
of translating our high level code into detailed, specific instructions.
Again, with all the money and resources spent on networking, I'm amazed that
most firewalls are written in what is in essence, 'assembly code', with all
the non-portability, potential for human error, and other drawbacks that
entails.
> 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."
I think the language will need to be a bit more structured than this, but it
should still be quite readable to most folks (certianly more so than a big
list of IPChains rules). The other big problem with 'natural language' is
that not everyone speaks the same one...
I think the lanugage structure will evolve from the requirements of defining
a firewall. The actual syntax to implement this structure can be
arbitrarily created, but should be consise and easily 'human readable'
> > Let me know if I'm way off in left field (or orbiting mars...maybe left
the
> > solar-system...)
>
> Should've taken that left turn at Albuquerque, eh? =)
I knew I did something wrong when I drove back from 'Vegas :>
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel
