| 1 |
> It's out of scope for file transfer protocols; it's a daemon/system-local |
| 2 |
> problem. Attach pre-event or post-event scripts serverside for any special |
| 3 |
> munging or protections you'd like to apply. (Such as triggering an LVM |
| 4 |
> snapshot, for example...) |
| 5 |
|
| 6 |
I must be going about this the wrong way. Am I the only one using |
| 7 |
automated backups? If not, how is it done properly? |
| 8 |
|
| 9 |
- Grant |
| 10 |
|
| 11 |
|
| 12 |
>> >>>>> And if I pull, none of my backed-up systems are secure because |
| 13 |
>> >>>>> anyone |
| 14 |
>> >>>>> who breaks into the backup server has root read privileges on every |
| 15 |
>> >>>>> backed-up system and will thereby "gain full root privileges |
| 16 |
>> >>>>> quickly." |
| 17 |
>> >>>> |
| 18 |
>> >>>> IMO that depends on whether you also backup the |
| 19 |
>> >>>> authentication-related |
| 20 |
>> >>>> files or not. Exclude them from backup, ensure different root |
| 21 |
>> >>>> passwords |
| 22 |
>> >>>> for all boxes, and now you can limit the infiltration. |
| 23 |
>> >>> |
| 24 |
>> >>> If you're pulling to the backup server, that backup server has to be |
| 25 |
>> >>> able to log in to and read all files on the other servers. Including |
| 26 |
>> >>> e.g. your swap partition and device files. |
| 27 |
>> >> |
| 28 |
>> >> What if I have each system save a copy of everything to be backed up |
| 29 |
>> >> from its own filesystem in a separate directory and change the |
| 30 |
>> >> ownership of everything in that directory so it can be read by an |
| 31 |
>> >> unprivileged backup user? Then I could have the backup server pull |
| 32 |
>> >> that copy from each system without giving it root access to each |
| 33 |
>> >> system. Can I somehow have the correct ownerships for the backup |
| 34 |
>> >> saved in a separate file for use during a restore? |
| 35 |
>> >> |
| 36 |
>> >> - Grant |
| 37 |
>> >> |
| 38 |
>> > |
| 39 |
>> > You could just as well use an NFS share with no_root_squash. It is |
| 40 |
>> > really more a question of finding the right combination of tools to |
| 41 |
>> > ensure proper separation of concern for server and client. |
| 42 |
>> > |
| 43 |
>> > In fact, I think we are intermixing three distinct problems: |
| 44 |
>> > 1. (Possible) limitations of rdiff-backup with regard to untrusted |
| 45 |
>> > backup servers or clients. |
| 46 |
>> |
| 47 |
>> The limitation is real unfortunately. All backups created by |
| 48 |
>> rdiff-backup more than a second ago can be deleted something like |
| 49 |
>> this: |
| 50 |
>> |
| 51 |
>> rdiff-backup --remove-older-than 1s backup@12.34.56.78::/path/to/backup |
| 52 |
>> |
| 53 |
>> > 2. The purely technical question which file transfer protocols protect |
| 54 |
>> > against write access from backup server to backup client and backup |
| 55 |
>> > client to older backups on the server. |
| 56 |
>> |
| 57 |
>> rdiff-backup doesn't provide those sort of protections. Do any file |
| 58 |
>> transfer protocols? |
| 59 |
>> |
| 60 |
>> > 3. The more or less organisational question what level of protection |
| 61 |
>> > backups need and how fast security breaks have to be detected. |
| 62 |
>> |
| 63 |
>> I think backups should be very well protected and security breaks |
| 64 |
>> should not have to be immediately detected. |
| 65 |
>> |
| 66 |
>> - Grant |
| 67 |
>> |
| 68 |
>> |
| 69 |
>> > I think push vs. pull is just a secondary concern with regard to the |
| 70 |
>> > second question and has practically no relevance to the third one. |
| 71 |
>> > |
| 72 |
>> > Regards, |
| 73 |
>> > Florian Philipp |
Archives