[ previous ] [ next ] [ threads ]
 
 From:  "Mitch \(WebCob\)" <mitch at webcob dot com>
 To:  "Adam Nellemann" <adam at nellemann dot nu>, "Mitch \(WebCob\)" <mitch at webcob dot com>
 Cc:  "m0n0wall List" <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: Web gui / remote XML updates... WAS RE: [m0n0wall] Port Knocking?
 Date:  Sun, 8 Feb 2004 19:09:31 -0800
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.

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)

m/

> -----Original Message-----
> From: Adam Nellemann [mailto:adam at nellemann dot nu]
> Sent: Sunday, February 08, 2004 5:31 PM
> To: Mitch (WebCob)
> Cc: m0n0wall List
> Subject: Re: Web gui / remote XML updates... WAS RE: [m0n0wall] Port
> Knocking?
>
>
> Mitch (WebCob) wrote:
>
> > An interesting idea you raised... is there a way to trigger
> > monowall to reconfigure itself after receiving a new XML file?
> >
> > If so, people's concerns about coming up with an easy way to
> > configure gazillions of monowalls could be made simple... a cron
> > job on monowall can run rsync or fetch to pull down an XML file and
> >  a checksum form a remote web (with SSL?) or scp server and then
> > run "monowall reconfigure" to reconfigure...
> >
> > If we really wanted bullet proof, the cron job could verify
> > continuing remote connectivity after the reload and roll back to
> > the previous config if the update caused the box to lose it's
> > connection to the remote network.
> >
> > Just a thought - any comments on this - is the functinoality
> > already there somewhere?
>
> Yeah, I think this would be great! (And probably better than SNMP
> writing anyway!) Especially if this "cron job" could be controlled
> from the webGUI, so us *nix illiterates will also be able to use the
> feature!
>
> What about pushing the config instead of pulling it? (Unless this is
> too difficult to secure?) I guess one way would be to allow a http or
> ftp transfer of the new config.xml to m0n0wall (should be some way to
> limit which IPs are allowed to do this though, possibly with some
> additional security as well?) m0n0wall could then reconfigure as soon
> as the file was recieved (instead of having to wait for the cron job
> to take its next round!) Might a simple php script be able to
> acomplish this via http, without too much ado?
>
> I'm actually looking into making a "standalone editor" for the
> config.xml. I'm hoping this can be done with a few HTML and XSL files,
> so it will run in any XML capable browser (for true platform
> independance) and hopefully without needing a web server(*). The plan
> is to more or less "steal" the m0n0wall webGUI html, remove anything
> not config-related, and make it work on a specified config.xml file
> using XSL and JavaScript :)
>
> It would be cool if I could then expand this editor with an "upload"
> capability! It might even be expanded to handle multiple configs and
> m0n0walls, for those "bulk-configurations"!
>
> Adam.
>
> (*) This is assuming I can find some way of writing the changes made
> in the browser back to the config.xml file? Anyone know how this might
> be done (preferably using JavaScript, XML/XSL or if need be, a Java
> applet or somesuch?) Or perhaps someone knows a good forum to ask
> about this? It would be a pity if the few files needed to do this
> would have to be accompanied by an entire webserver :(
>
>