On Tue, 2 Jan 2001, 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 problems
> when dealing with arbitrary situations that were not planned for by the
> script writers. For instance, the following network:
...is a nightmarish FrankenNetwork. Hence EigerStein perhaps? I applaud
you for making it work well. =)
> Other problems with the general firewall scripts I've seen include:
>
> Extensions to add functionality are typically difficult, and may have global
> security implications that are not immediately obvious
What follows doesn't necessarily fix this, but by being a high-level
application for configuring and implementing existing rulesets, it does
cut down.
> 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.)
> 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. As a side thought, would this
work for the purposes of configuring an entire LEAF/LRP system with a
little bit of extension?
> So what's to be done???
>
> First, forget about ipchains, netfilter, ACL's, packet filter rules, etc.
> These are all simply tools. The correct application of these tools will
> follow directly from a clear and concise definition of the problem at hand,
> which is creating a firewall.
Forgotten.
> So, what is a firewall? Obviously, many different things to different
> people. My needs are certainly different than yours, yet it seems there are
> large areas of overlap, where it would be desirable to share development,
> peer review, etc. How can this be done?
>
> 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?
> 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. =)
> 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.
> 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.?)
> This is about the only thing I've come up with that is arbitrarily
> expandable, allows users to share development/configuration across
> dissimilar firewalls, and has the benefit of targeting multiple end-targets.
I like it. If I didn't, I wouldn't be interrogating. =)
> 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.
> Again, the real work is in a clear and concise definition of the problem
> (what does my firewall do). If we can create a simple firewall modeling
> language, firewall construction set, or whatever you want to call it,
> converting the generated specification to an actual ruleset is pretty
> straight-forward. I think shell-script is more than capable enough to parse
> and process the hierarchal tree of object based configuration documents
> (more buzz-word compliance :>), and we could even leverage <steal> an
> existing object-based text language (like XML or somesuch), as long as the
> actual requirements of defining a firewall are clearly defined and well
> understood.
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 want <targetSystem> to <forward><80_tcp> from <extNet> to
<192.168.0.15:80>."
..and the variables be defined as beginning setup questions, and then
saved for future configs? I don't know how well this could be done going
from an HTML/XML form entry to shell scripting - I'm lagging behind on my
reading - but if it could be done easily and well, then not only do we
have a way to define things in common language terms for people, but get
it done so that they can continue to play with the firewall without
re-entering everything.
> Anyway, this is the sort of thing I'd write for making firewalls if I was
> doing it from scratch and had enough time <yeah, like that's going to
> happen>
Hey, you never know. I'm getting a computer in two days that isn't slow,
and I've been waiting for that for close to 10 years now. =)
> 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? =)
--
George Metz
Commercial Routing Engineer
[EMAIL PROTECTED]
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel
