> > My reasons behind a timed pull vs. a push is for security and
> simplicity...
> > when managing lots of rmeote points, the addresses of the remote points
> > could vary, and so could the access to them. Making downloads
> of new configs
> > available from a central location is the same model bind used
> for years to
> > secure dns replication - the theory is that a notification
> triggering a new
> > download is less prone to hacking and exploits than an an interface that
> > allows one to push values from anywhere.
>
> Yes, I see your point. Still there would be many uses where there
> wouldn't be "lots of remote points", but rather a single one (ie. home
> users and small companies).
>
> You mention "a notification triggering a new download". In your post
> you talked about a cron job on m0n0wall, but I don't remember any
> mention of other ways to trigger the download? It sounds exiting (and
> possibly a usable alternative to pushing), how would this work?

In Bind (ISC's nameserver) a "master" server sends a notification message to
all it's slaves when it registers a change in the contents of a zone. The
slave is then responsible for querying the master (or potentially any of a
number of masters) to retrieve the updated config.

The benefit to this mechanisms are several:
- without any encryption overhead a relatively safe way of updating slaves
is ensured... even if the notification is spoofed, the slave always contacts
a known master for updates - a false notification just triggers an uneeded
confirmation of the current config.
- the slave doesn't have to be open to receiving and authenticating updates,
which means there is no mechanism to remotely change the slave - and if
there is no command path to do this, then a security bypass can't comprimise
the system... (they also allowed for remote updates with resulted in lots
more problems if not properly configured - it's always the case)


> I didn't imagine that it would necessarily be allowed to push the
> config.xml "from anywhere". Rather I thought it would be prudent to
> allow this from the LAN by default, perhaps with the posibility of
> specifying one or more IPs that had this privilege (the addition of an
> apropriate pass rule on the WAN IF might allow these to be external
> ones as well).
>
> I thought if only a LAN-side server were allowed to push the config,
> existing security measures for accesing such a server could be used to
> ensure a high level of safety if it is necessary to be able to change
> the config from the outside (ie. from a remote location the server
> could be made to push a config, either one that was already on the
> server or if needed, one could be transfered to it before asking it to
> do the push.) This way any level of security should be atainable?

I didn't think there would be much benefit for a single machine - I was
thinking interms of networks like I manage now... some with 10's or 100's of
individual firewall appliances to make VPN's. Centralized configuration
management would make that a lot easier.

 > You should be able to hack the existing php in monowall to edit configs
> > outside of monowall - the key is searching through monowall to
> see if there
> > is a script which initiates a "reload" or reprocessing of this
> file - look
> > at the startup process perhaps? rc.local? (I've been reading
> and planning,
> > but as yet haven't played with monowall, so forgive my ignorance)
>
> First of all: You can't possibly be as ignorant as I, which leads me
> to the following questions/comments:
>
> If I were to use php to do the config.xml editing (saving?) wouldn't I
> need a webserver to run the php? I'd rather avoid the need for a
> server, so the editor can (optionally of course) be run locally
> without requiring a webserver to be installed on the machine (and a
> php parser, and...)

Seems like a lot of work to avoid running PHP - which can be run from the
command line as well... I have used it as an alternative to PERL for
instance.

> When you talk about finding a script that "initiates a reload or
> reprocessing of [the config] file", isn't this something that the
> person implementing the config pull (or push) feature on m0n0wall
> would need, rather than I? Perhaps I wasn't very clear about what my
> "config editor" was intended to do:
>
> I want to be able to edit a (typically local) copy of the config.xml
> file (such as the one obtained by doing a bacup from the webGUI). Thus
> what I want to do (at least for starters) is just to make this easier
> to do, by way of a local webGUI, than editing the "raw" config.xml.
>
> That's why I imagine I can get there by simply making an apropriate
> XSL file (with the aid of a little JavaScript perhaps), making the
> config.xml appear in the browser in a more "human readable" form and
> with some form fields for the various editable items.
>
> This method hinges on the ability to write any changes made in the
> form fields back to the config.xml, which may be problematic when
> working with a local file, which was why I asked if anyone knew how to
> do this (I should think that JavaScript et.al. is specifically not
> allowed to do any local writing, as it is intended to run on web
> pages. Unless there is some workaround for this, I suspect a
> JavaPlugin would be needed?)

Hmmm - maybe I'm missing the point - Why would you go to this effort to make
a system to let you edit the file for a single box offline, just to have to
restore it to the box to run - what's the reason you are headed down this
path? Might help me refocus on your goals instead of mine ;-)

m/