[ previous ] [ next ] [ threads ]
 
 From:  Henning Wangerin <mailinglists dash after dash 041101 underscore reply dash not dash possible at hpc dot dk>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Webcam and captive portal.
 Date:  Thu, 24 Feb 2005 13:14:37 +0100
On Thu, 2005-02-24 at 06:23, Chris Buechler wrote:
> On Wed, 23 Feb 2005 21:07:41 +0100, Henning Wangerin
> <mailinglists dash after dash 041101 underscore reply dash not dash possible at hpc dot dk> wrote:
> > 1) Setup the webcam on a static IP (dhcp for easy handling) and
> > firewalling so it only can connect to the ftp-server. The cam can be
> > setup to push new images to the ftp-server automatically.
> > *PRO
> > No extra load is cenerated on the server in case of no connection
> > *CON
> > the ftp-credentials can be found on air, and the mac/ip hijacked
> > 
> > 2) Setup the webcam on a static IP (dhcp for easy handling) and
> > firewalling so no connections out is possible, and let the server pull
> > information
> > *PRO
> > no credentials on air except eventually a readonly-access to the cam
> > *CON
> > the server has to do more error-handling in case of missing connection.
> > 
> 
> I'd say 2 is the more secure way, and probably the way I'd set it up. 
> The server wouldn't really have to worry about error handling.  If it
> fails, just give up.

Guess so too ;-)

Just need som locking to avoid new instances trying to pull while
another one is waiting for timeout.

> If 1 is easier, and you have good reason to be concerned about
> protecting the traffic and FTP server, just use a ftp user for only
> that purpose and chroot it into its home directory.  The worst

Sure the user will be a very restricted one, but my concern is also that
a hijacker _could_ delete the images, but they could ofcourse be moved
elsewhere by the server.

> somebody could do with those privileges is use it as a warez
> repository if it's publicly-accessible (assuming no configuration
> issues).  

The images _will_ be world accessible, but properbly via e filtering
script, so that wouldn't nessesarily be a problem.

Would it be possible to setup a write-only directory for the use?
Reading a file-list is ok/good, but if John Doe can write a file, but
not read it, it's not to much use for warez, i guess.

> Setting up disk quotas would minimize that risk.

Will not nessearyly work, as the archive could get very big. But a quota
on the upload dir, and a process moving/chowning then away form the
upload-dir to an archive dir could solve it.

-- 
Henning Wangerin <mailinglists dash after dash 041101 underscore reply dash not dash possible at hpc dot dk>