Re: Backward compatibility of next beta

[Patrik Dufresne]

Hello Derek,

Sorry for the delay of response. I wanted to take the time to properly 
answer your questions.

This design is built specifically for our Minarca clients. The  central 
server is not aware of the location of each client. Clients might be mobile 
behind a NAT, or firewall.

So our central server is receiving connections.

About the security conserns. We isolate each users repository based on the 
SSH keys.
If one client is compromised, only the associated repo is compromised. Any 
how, is the client is compromised, all the data is accessible to the 
hacker. 

To mitigate the repository corumptions, either because of a hack or any 
reason, we have zfs snapshot to recover.

In you case, a hacker could eventually, do modification to rdiff-backup 
code to corupmt the backup.



On Thu., Jan. 30, 2020, 11:01 a.m. Derek Atkins, <address@hidden> wrote:

> Patrik,
>
> On Thu, January 30, 2020 10:29 am, Patrik Dufresne wrote:
> >
> > I'm in the same boat as many of you, I have more than two hundred servers
> > using rdiff-backup directly or through Minarca and it's impossible to
> > migrate all of them at once. I've been thinking about a migration plan 
> for
> > some time now and I have a general idea that I can't wait to put in 
> place.
> > I'm planning to work on a solution end-February. The general idea is to
> > pre-compile rdiff-backup 1.2.8 and 2.0.0 as individual executable and
> > deploy both of them on the central server as rdiff-backup-1.2.8 and
> > rdiff-backup-2.0.0. Then reconfigure the SSH server using a script to
> > either call rdiff-backup-1.2.8 by default and call rdiff-backup-2.0.0
> > based
> > on some condition.
>
> I'm curious -- do you have each of your 200 servers call into the
> centralized backup server?  Or do you have your backup server "reach out"
> to the 200 servers?
>

Our deployment of rdiff-backup is solely based on Minarca as a centralized 
server. So all our "clients" are connecting to the centralized server. It's 
built this way because our clients are distributed, behind NAT, some of 
them are mobile and some of them are Windows. With these constraints, we 
can't have a centralized server reaching the clients.
 

>
> I actually have it set up so that the backup server reaches out to the
> servers being backed up.  I did it this way to limit the access to the
> backups themselves, and that the servers being backed-up could be "dumb"
> about their backups.  


It makes sense if the computer you are backing up are always reachable 
without NAT and if all of them are Linux.
 

> Specifically, all the "private keys" necessary to
> backup a device are sitting on the backup server and not on the servers
> being backed up (modulo that server's existing SSH key).


To ease the SSH key exchange, we provide Minarca Client to our users. After 
installing Minarca clients, the user must enter it username and password to 
establish a connection with the Minarca centralized server. During this 
process, it exchanges the SSH keys through a web service over Https with 
the Minarca Server.
 

> It would also
> prevent someone who "breaks in" to one server to gain access to the backup
> server and corrupt backups from other servers.
>

To mitigate this Minarca Server provide an SSH entry point that restricts 
each user into its own space. In other words, if one client gets 
compromised, only it's data get compromised. A malicious user cannot get 
access to other backup. I'm also looking for a way to add additional layers 
of security using containers.
 

> In my case, I could have a configuration that "knows" the version running
> on the server being backed up and calls the appropriate incarnation of
> rdiff-backup on the backup server.  But I would rather this be automated,
> so I don't have to pay that close attention and ensure both ends are
> properly synced manually.
>

I'm definitely looking toward a similar solution where it's seamless. The 
more I'm thinking of it, we may need to change the code in rdiff-backup to 
help us. What would really help is having rdiff-backup calling a different 
executable in the remote schema. Instead of calling "rdiff-backup" it 
should call rdiff-backup2.0.0. And rdiff-backup could be a symbolic link to 
the default version, either 1.2.8 or 2.0.0. That would really simplify the 
migration process for everyone.

@EricZolf <address@hidden> Do you think it's feasible ?
It would mitigate all the migration issue and API incompatibilities. We 
could also call "rdiff-backup2" (with only the major version) and bump the 
major version only when an API incompatibility get introduced in the code.

 

> -derek
>
> -- 
>        Derek Atkins                 617-623-3745
>        address@hidden             www.ihtfp.com
>        Computer and Internet Security Consultant
>
>