On Wed, 3 Jan 2001, Charles Steinkuehler wrote:
> > > 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? :>
Works well enough that they're keeping it, neh? =)
> 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.
Currently, no. My thought on this was "Use File A with Network Type A,
File B with Network Type B, etc." and include a call to customized sets
somewhere appropriate in the base files. I'll try to describe in more
detail shortly.
> 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)
Ah, but see above. I'm talking a basic script as the end-result of your OO
Firewall design. Designing a script that does everything - as you've tried
to do with the extended scripts(and not done too badly) - creates a
painful experience the first time someone tries to make sense of it cold
turkey. Regardless of what anyone may say, there ARE typical Network
setups. If you use a baseline setup for each one of the typical networks,
then it frees you to figure out how you can mesh the two without worrying
about the mess of one big file to do it all. (ASCII ART!)
User---fwBuilder-----
|
|
------------------------
| | |
MASQ DMZ ProxyArp
| | |
masq.sh dmz.sh parp.sh
/ | \ / | \ / | \
/ | \ / | \ / | \
masq masq masq dmz dmz parp parp
+ custom + custom + custom +
parp dmz parp masq
mods mods mods mods
Look at it as a bit of a circle.
Each main branch is a network type - MASQ, DMZ, and ProxyArp. User defines
these in fwBuilder. fwBuilder then chooses the path that it will take from
there.
masq.sh, dmz.sh, and parp.sh are all rulesets designed to work WELL with
their network type only. Any changes to the base firewall configuration
would be placed in a file called $NETWORK.custom and would be executed at
the end (beginning? middle?) of the base firewall script. If User defines
a Network set with MASQ and DMZ, then the masq+dmz.mods file would be
called - probably by a variable in masq.sh that gets set by fwBuilder - to
activate the DMZ in such a way as it would play nice with the Masq'd
network. That way you can chain the config files, and no one file would be
doing all the work. If a function is DMZ only, or Proxy ARP only, it goes
in the right basefile. If it's designed to, say, allow internal machines
on a Masq'd network to access the DMZ without doing split-horizon local
DNS or somesuch, then it would go into the masq+dmz.mods file. It keeps
everything categorized and organized and allows interoperability with the
many different types of networks out there.
And I think I hit upon the problem here. I'm working bottom-up from the
LEAF/LRP perspective, rather than top-down. So sue me for taking
architecture classes in school. =)
> 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...
If not implemented correctly, yes. If there's a unified interface for
editing these files, and all the files are designed to do specific things,
then it becomes user-friendly, and the unwary are removed from the
equation because the front-end will place things where necessary. Still
doesn't prevent HSF - Human Stupidity Factor - but we're working with
computers here, not AIs. =)
> > 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).
Heh. You aren't kidding. Although, with the types of networks out there,
it could get messy. I forsee problems the first time a graphics shop tries
to use an IP/Ethernet based configuration util to configure Appletalk for
their graphics network. =)
> > 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 :> ).
Okay, see above. =) That's the low-end for LRP, as an example. the front
side of things being modular, I leave to people with a clue as to how to
code. =)
> Modularity, but I'd like to see some level of inheritance and the ability to
> customize, as well.
Again, see above. Smack me if I'm missing what you're referring to.
> 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.
Cisco is easy to implement for stuff like this; you just need to lay out
the command structure correctly, then tftp the file into the
router/firewall/switch. Alternately, you can copy and paste into a telnet
connection, although I'm thinking that there's a few minor problems with
anyone doing either without checking them first, as Ciscos are fairly
fickle and can really break something without a bit of oversight from a
cluefull individual.
> 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...
As much as I wince to say this from a security standpoint, if they wanna
do something like that, let them. Anyone who does ANYTHING blindly in
regards to network security should be smacked. I do suggest a splash
screen with a disclaimer when someone adds a ruleset, but beyond that,
there's nothing we can do. =P
> 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.
This sounds like a simple enough procedure. Create the high-level firewall
configs, and have a shell-script parser that is independent of the rest of
it so that you need to download the right version for your firewall
system. Boot time rolls around, and the parser kicks in, checks for the
files needed, parses the language of the files, and outputs to IPChains,
ipfwadm, or netfilter as appropriate.
As a totally irrelevant side-note, Netfilter no longer uses the incoming,
forward, and outgoing chains the same way. If it's destined for a machine
other than the router, it ONLY passes through the Forward chain. Anything
destined for the machine only hits Incoming, and anything leaving the
machine locally hits outgoing. Might make for some interesting
possibilities, as you can secure the network AND the router with totally
different sets of rules that won't get tangled up. I'm still reading up on
the netfilter/iptables stuff though.
> 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...
True. That was mostly an example off the top of my head to make sure I was
thinking along the same lines as you were, which it appears I was.
> 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'
I'll leave that to someone who, unlike me, can code more than a simple and
bloated diceroller in BASIC. =)
--
George Metz
Commercial Routing Engineer
[EMAIL PROTECTED]
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel
