Securing replication

["Mark J. Reed" <ma...@gmail.com>]

I have a webapp acting as a security gateway/reverse proxy for other
webapps.  Its data therefore includes authorization data which itself
needs to be protected from unauthorized access.  Currently that data
lives in a localhost-only CouchDB, but I now want to distribute the
application across more than one server, so I'm going to have to open
up a hole to allow replication.  My current thoughts are:

1. Keep the Couch instances listening on localhost only, but open SSH
tunnels between them to use for the replication.
    Based on past experience with SSH tunneling, this seems somewhat
fragile, and probably more complex than is warranted.

2. Use iptables to lock down access on each server so that only the
other server can connect to the Couch instance.
   This is still moderately increases the complexity (there's an
external configuration to keep in synch with the Couch configs), but
it seems simpler and less likely to break than the SSH solution, while
still offering moderate security (in combination with configuring
Couch to require admin credentials).

Any other thoughts?  Advice welcome.


-- 
Mark J. Reed <ma...@gmail.com>

Re: Securing replication

[J Chris Anderson <jc...@gmail.com>]

On Jul 19, 2010, at 2:25 PM, Mark J. Reed wrote:

> I have a webapp acting as a security gateway/reverse proxy for other
> webapps.  Its data therefore includes authorization data which itself
> needs to be protected from unauthorized access.  Currently that data
> lives in a localhost-only CouchDB, but I now want to distribute the
> application across more than one server, so I'm going to have to open
> up a hole to allow replication.  My current thoughts are:
> 
> 1. Keep the Couch instances listening on localhost only, but open SSH
> tunnels between them to use for the replication.
>    Based on past experience with SSH tunneling, this seems somewhat
> fragile, and probably more complex than is warranted.
> 
> 2. Use iptables to lock down access on each server so that only the
> other server can connect to the Couch instance.
>   This is still moderately increases the complexity (there's an
> external configuration to keep in synch with the Couch configs), but
> it seems simpler and less likely to break than the SSH solution, while
> still offering moderate security (in combination with configuring
> Couch to require admin credentials).
> 
> Any other thoughts?  Advice welcome.
> 

these both sound sane. If the couches are not behind a firewall together I'd suggest ssh tunneling (or https) to prevent eavesdropping.

Chris

> 
> -- 
> Mark J. Reed <ma...@gmail.com>