| 1 |
On Thursday 25 February 2010 17:15:36 Ward Poelmans wrote: |
| 2 |
> On Wed, Feb 24, 2010 at 21:51, Neil Bothwick <neil@××××××××××.uk> wrote: |
| 3 |
> > It looks interesting, and no program is that good that alternatives |
| 4 |
> > should never be considered, but I really like the way BaclupPC works. |
| 5 |
> > Everything is handled by the server, all you need to do on each client is |
| 6 |
> > copy the backuppc user's public key to /root/.ssh/authorized_keys. |
| 7 |
> |
| 8 |
> Well, that's one of the things i don't like. Is there backup software |
| 9 |
> where the client does the backup to the server and not the server |
| 10 |
> fetching the backup from the client? I can't find a good way to take |
| 11 |
> regular backup's from laptop that come and go. |
| 12 |
|
| 13 |
|
| 14 |
Never mind the massive security issues resulting from the backup server |
| 15 |
logging into the clients with a passphrase-less key, AS ROOT. |
| 16 |
|
| 17 |
Which means you now have to open up root logins over ssh on the clients. |
| 18 |
|
| 19 |
And someone gets into your backup server, BANG! instant pwnage of every single |
| 20 |
machine on your network. Heck, you don't even have to try and compromise the |
| 21 |
local root account, you already have full unfettered access to everything |
| 22 |
anyway. Worse, I'll bet the server software runs as an unpriviledged user, so |
| 23 |
you can just bypass the bit where you have to compromise root there as well. |
| 24 |
|
| 25 |
It all looks like a classic case of sacrificing any and all security in the |
| 26 |
name of mere convenience. I have the same running battle at work, some idiot |
| 27 |
(probably in marketing getting a kickback) wants me to run a frigging JAVA |
| 28 |
backup app on my mission critical servers, the ones with 500+ users on them |
| 29 |
most of them chancers of the first order. They didn't understand the irony |
| 30 |
when I suggested I should just dispense with passwords and keys altogether and |
| 31 |
chmod -R 777 / |
| 32 |
|
| 33 |
A much better way is to run a dedicated agent on the client. If the server |
| 34 |
needs to schedule backups, it can ask the agent to do so using regular tcp |
| 35 |
traffic. The client can then do it's backup and rsync it over to the server |
| 36 |
when it's done, and that push can be done as a regular user on both ends. The |
| 37 |
actual backing up on the client must be done by root of course, no other user |
| 38 |
has the necessary access. |
| 39 |
|
| 40 |
|
| 41 |
|
| 42 |
-- |
| 43 |
alan dot mckinnon at gmail dot com |
Archives