On 11/14/11 20:54, Grant wrote:
If you're intent on making a two-stage pull work; you can do it by
creating a 'backups' user on your servers, and then using filesystem
ACLs to grant backups+r to every file/directory you want to back up.
That way, an attacker on the backup server can't decide
And if I pull, none of my backed-up systems are secure because anyone
who breaks into the backup server has root read privileges on every
backed-up system and will thereby gain full root privileges quickly.
IMO that depends on whether you also backup the authentication-related
files or not.
And if I pull, none of my backed-up systems are secure because anyone
who breaks into the backup server has root read privileges on every
backed-up system and will thereby gain full root privileges quickly.
IMO that depends on whether you also backup the authentication-related
files or not.
It's out of scope for file transfer protocols; it's a daemon/system-local
problem. Attach pre-event or post-event scripts serverside for any special
munging or protections you'd like to apply. (Such as triggering an LVM
snapshot, for example...)
(sorry for the top post; in-line can be done in
It's out of scope for file transfer protocols; it's a daemon/system-local
problem. Attach pre-event or post-event scripts serverside for any special
munging or protections you'd like to apply. (Such as triggering an LVM
snapshot, for example...)
I must be going about this the wrong way. Am
Then I could have the backup server pull
that copy from each system without giving it root access to each
system. Can I somehow have the correct ownerships for the backup
saved in a separate file for use during a restore?
If you're intent on making a two-stage pull work; you can do it by
You identified a flaw in the system as you were using it. You're right,
those are flaws. However, you can fix those flaws by applying some magic
as a sysadmin. That's why several posts in the thread have mentioned
versioning your backups in some fashion. I've mentioned lvm a couple times.
I think
You identified a flaw in the system as you were using it. You're right,
those are flaws. However, you can fix those flaws by applying some magic
as a sysadmin. That's why several posts in the thread have mentioned
versioning your backups in some fashion. I've mentioned lvm a couple times.
I
Sure, but you've noted that rdiff-backup is insecure if the source box is
violated. What you need, then, is a layer of versioning not subject to that
vulnerability.
ZZ
On Nov 14, 2011 9:34 PM, Grant emailgr...@gmail.com wrote:
You identified a flaw in the system as you were using it. You're
Sure, but you've noted that rdiff-backup is insecure if the source box is
violated. What you need, then, is a layer of versioning not subject to that
vulnerability.
Does it exist?
- Grant
You identified a flaw in the system as you were using it. You're right,
those are flaws. However,
On Nov 15, 2011 9:49 AM, Grant emailgr...@gmail.com wrote:
Sure, but you've noted that rdiff-backup is insecure if the source box
is
violated. What you need, then, is a layer of versioning not subject to
that
vulnerability.
Does it exist?
Quick and dirty:
TARGDIR=/home/versions/$(date
On Tue, November 15, 2011 3:32 am, Grant wrote:
You identified a flaw in the system as you were using it. You're right,
those are flaws. However, you can fix those flaws by applying some
magic
as a sysadmin. That's why several posts in the thread have mentioned
versioning your backups in
And if I pull, none of my backed-up systems are secure because anyone
who breaks into the backup server has root read privileges on every
backed-up system and will thereby gain full root privileges quickly.
IMO that depends on whether you also backup the authentication-related
files or not.
Am 13.11.2011 19:03, schrieb Grant:
And if I pull, none of my backed-up systems are secure because anyone
who breaks into the backup server has root read privileges on every
backed-up system and will thereby gain full root privileges quickly.
IMO that depends on whether you also backup the
On 11/13/11 13:03, Grant wrote:
And if I pull, none of my backed-up systems are secure because anyone
who breaks into the backup server has root read privileges on every
backed-up system and will thereby gain full root privileges quickly.
IMO that depends on whether you also backup the
On 11/13/11 13:03, Grant wrote:
Then I could have the backup server pull
that copy from each system without giving it root access to each
system. Can I somehow have the correct ownerships for the backup
saved in a separate file for use during a restore?
If you're intent on making a
A little while ago I set up an automated backup system to back up the
data from 3 machines to a backup server. I decided to use a
push-style layout where the 3 machines push their data to the backup
server. Public SSH keys for the 3 machines are stored on the backup
server and restricted to the
On Fri, Nov 11, 2011 at 12:55 PM, Grant emailgr...@gmail.com wrote:
[snip]
The problem with my current push-style layout is that if one of the 3
machines is compromised, the attacker can delete or alter the backup
of the compromised machine on the backup server. I can rsync the
backups from
On Nov 12, 2011 12:58 AM, Grant emailgr...@gmail.com wrote:
A little while ago I set up an automated backup system to back up the
data from 3 machines to a backup server. I decided to use a
push-style layout where the 3 machines push their data to the backup
server. Public SSH keys for the
[snip]
The problem with my current push-style layout is that if one of the 3
machines is compromised, the attacker can delete or alter the backup
of the compromised machine on the backup server. I can rsync the
backups from the backup server to another machine, but if the backups
are
On Fri, Nov 11, 2011 at 1:27 PM, Grant emailgr...@gmail.com wrote:
[snip]
The problem with my current push-style layout is that if one of the 3
machines is compromised, the attacker can delete or alter the backup
of the compromised machine on the backup server. I can rsync the
backups from
A little while ago I set up an automated backup system to back up the
data from 3 machines to a backup server. I decided to use a
push-style layout where the 3 machines push their data to the backup
server. Public SSH keys for the 3 machines are stored on the backup
server and restricted to
On Nov 12, 2011 1:39 AM, Grant emailgr...@gmail.com wrote:
A little while ago I set up an automated backup system to back up the
data from 3 machines to a backup server. I decided to use a
push-style layout where the 3 machines push their data to the backup
server. Public SSH keys for
Am 11.11.2011 19:56, schrieb Pandu Poluan:
On Nov 12, 2011 1:39 AM, Grant emailgr...@gmail.com
mailto:emailgr...@gmail.com wrote:
A little while ago I set up an automated backup system to back up the
data from 3 machines to a backup server. I decided to use a
push-style layout where
On 11/11/2011 12:55 PM, Grant wrote:
The problem with my current push-style layout is that if one of the 3
machines is compromised, the attacker can delete or alter the backup
of the compromised machine on the backup server. I can rsync the
backups from the backup server to another machine,
The problem with my current push-style layout is that if one of the 3
machines is compromised, the attacker can delete or alter the backup
of the compromised machine on the backup server. I can rsync the
backups from the backup server to another machine, but if the backups
are deleted or
On Nov 12, 2011 9:29 AM, Grant emailgr...@gmail.com wrote:
The problem with my current push-style layout is that if one of the 3
machines is compromised, the attacker can delete or alter the backup
of the compromised machine on the backup server. I can rsync the
backups from the backup
On Nov 12, 2011 2:17 AM, Florian Philipp li...@binarywings.net wrote:
Just an illustration: My employer will soon do a PoC/Live Demo of this
product:
http://www.atempo.com/products/liveBackup/features.asp
Only an 'agent' lives inside the employee's workstation. It pushes all
writes
On 11/11/2011 09:22 PM, Grant wrote:
So if I push, I don't really have backups because anyone who breaks
into the backed-up system can delete all of its backups like this:
rdiff-backup --remove-older-than 1s backup@12.34.56.78::/path/to/backup
And if I pull, none of my backed-up systems
On 11/11/2011 10:20 PM, Pandu Poluan wrote:
And if I pull, none of my backed-up systems are secure because anyone
who breaks into the backup server has root read privileges on every
backed-up system and will thereby gain full root privileges quickly.
IMO that depends on whether you also
On Nov 12, 2011 11:23 AM, Michael Orlitzky mich...@orlitzky.com wrote:
On 11/11/2011 10:20 PM, Pandu Poluan wrote:
And if I pull, none of my backed-up systems are secure because anyone
who breaks into the backup server has root read privileges on every
backed-up system and will thereby
31 matches
Mail list logo
