First off...hello! My name is Scott Best, and I was
recently invited to this list by Mike Sensney. I hope I
can help contribute. :)

        A quick though on something I read earlier from
one of David's emails:

> From: "David Douthitt" <[EMAIL PROTECTED]>
> Date: Thu, 4 Jan 2001 09:10:19 -0600
> 
> [snip]
>
> I'm envisioning this:
> 
> 1. Edit text configuration file
>
> 2. Find line that says:
> 
>    allow smtp from any-inside to 10.1.1.1
> 
> 3. Change line to
> 
>    allow smtp from any-inside to 10.9.7.7


        I've been looking at solving a related problem, I
believe, and maybe what I've come up with will help. Or,
maybe what I've come up with is riddled with flaws that
I haven't noticed yet. :)
        I've been trying to setup a firewall environment that
well-manages portfw'ds to an internal server, when that
internal server *may* be setup to get it's IP# from a DHCP
lease. So, of course, it could change quite frequently,
making the firewall ruleset not only disfunctional but maybe
even dangerous.
        What I've done, then, is to break the standard firewall 
script up into three components: the firewall ruleset, a
.conf file, and a supervisory script. In the .conf file, I
setup an definition like:

[SERVICE]_HOST_MACID="00:00:39:12:ae:1a"

        ...where [SERVICE] is replaced with SMTP, or HTTP,
or NAPSTER, or whatever. Then there's another line in the
.conf file:

WANTED_SERVICES="HTTP SMTP NAPSTER"

        The last piece is in the rules file itself, where
the "service specific" rule is commented out using the
*same prefix* that's listed in the WANTED_SERVICES definition.
So a line for SMTP might look something like:

#SMTP#$IPMASQADM portfw -A -p tcp -d $IP_EXT/32 25 -d $SMTP_HOST 25

        Here's where (I think) is the good idea. The supervisory
script iterates thru $WANTED_SERVICES and, since everything uses
the same prefix, it's easy to check to see if [SERVICE]_HOST_MACID 
is defined. If it is, it scans the arp table to find that MAC 
address. If it finds one, then it sets [SERVICE]_HOST to that IP#, 
and then sed's out the #[SERVICE]# comment to activate the
service. Finally, it invokes the ruleset file.
        The upshot is...it doesn't matter what the IP# of the
host is, it is in fact transparent to the user. They just indicate 
the machine on which they want to host the service, and everytime 
the supervisory firewall script is run, it finds that machine and 
sets up the portfw "automatically". The only place I can see it
not working is if the arp table is stale. To address that, I use
Ray Olszewski's 'gatping' utility which wakes up the whole private
address space in about two seconds.

        From a user interface point of view (I'm building a web
based GUI, but you could do it with a clever bash script), all
the end user needs to do is to identify the service they want
to support, and the machine they want to host it. The UI then
sets the MAC address into the .conf file, and it's done.
        A working example (called EchoWall) is available on my 
ftp servers at www.echogent.com, in the EchoWare directory.
It's wrapped up in the whole EchoWare tarball, but it's not
very hidden.

        Anyhow, hope it proves useful. Looking forward to the
progress of LEAF. :)

-Scott
        





_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel

Reply via email to