On Sat, Jun 25, 2011 at 1:58 PM, Rüdiger Meier <sweet_f_a < at > gmx.de> wrote:
On Saturday 25 June 2011, Nico Kadel-Garcia wrote:
On Fri, Jun 24, 2011 at 5:50 AM, Ruediger Meier <sweet_f_a < at > gmx.de>
wrote:
That's what the 'validate-rsync.sh' tool is designed for.
[...] What it lacks, for this case, is an
integrated parsing of the target directories tied to the incoming key
(or the host of the incoming connection, authorized with that key)
and
That's why I told you about "rrsync". It's a comfortable perl script to
restrict ssh login to rsync (rw or ro) to a specified target/source
dir. You can find it within support directory of the rsync source tar
ball.
Thanks. The Debian system I was looking at, for whatever reason,
stores that as "rrsync.gz". I'll look into it ASAP.
Pulling the backup makes you able to harden your backup host which
is probably your most important one. Of course there are also some
good reasons to push instead.
And it opens your backup clients wide open to anyone who obtains the
central key,
Yup, but the central key is only available at one place (the server)
whereas your solution requires 100 keys (at 100 clients). I think it's
Yeah, it's a trade-off. That's why I'm looking at restricting the
clients to access only their host-specific rsync target directories.
more likely an attacker will find a hole in 1 of 100 clients rather
than in your specialized hardened backup server. (Probably even your
cleaning lady has physical access to some of your clients or maybe one
of your client admins is the attacker himself.). In this likely case
you have to _hope_ that your chroot and validate-rsync.sh stuff on the
server is secure.
True. But see above. If they're in as root already on the client, they
already have access. And for host-specific public keys, those can be
parsed, and reported on, by other means.
If server is pulling then there is no need to have a single open port on
the pulling server! And probably less cleaning ladys around the server
room. So there is less hope needed.
There might even be *fewer* unauthorized staff. That sort of thing is
why I'm looking at the "write-only" model, though.
including material which the client systems may not wish
to transmit to the backup system. That's a noticeable potential
issue.
This is solved by rrsync plus a file "/.rsync-filter" on the client host
(see rsync manpage).
What? No, unless the ssh key used to access to the client machines has
'-F' forced into the command line arguments. Feasible, but awkward.
It relies on the restraint of the central server to avoid
backing up inappropriate data to the shared backup pool, and forces
configuration updates to occur on the central server.
/.rsync-filter is controlled by client's admin only.
And requires the '-F' option. It's not enabled by default, according
to the man page.
You ever tried that stunt? It's..... tricky. It seems feasible with a
directory full of "validate-rsync" scripts, one for each client host,
but running those all as root..... hmmmm. Let me think about that
one.
No, there is only need for one "validate-rsync.sh" (or rrsync) - just
different arguments (target dir) for each client.
Which have to be enforced in the SSH key management, or have
enforcement added to the script. Othewise, successfully replacing the
individual client host key on the server could create.... risks.
The script could be executed by login to a restricted non-root user. At
the point in that script when $SSH_ORIGINAL_COMMAND is validated to be
ok it could finally run
sudo $SSH_ORIGINAL_COMMAND
(In rrsync it looks a bit different.)
At this point you could even enter a chroot.
Thanks, with rrsync in hand, I'll look more deeply at the options.
Did you considered to push backups to a non-root user and saving
the original file stats separately? For example you could run
metastore on client before backup starts. Then just inlude the
resulting file within the backup.
That's at risk of race conditions and resulting discrepancies
between the file transmission and the metastore ansmission. Not
inconceivable for basic recovery purposes, but a potential issue for
edge cases. I'd need to think about whether that is good enough
rsync is never atomic. If you write to file while rsyncing then it might
be broken anyway. Permissions and ownership race is IMO less fatal.
Much smaller risk, though. It only takes one directory with 200,000
files in it on an older file system to really extend the duration of
rsync operations, even if the files are not individually large.
(Maildir: oh, dear lord, Maildir for people who delete nothing......)
That would set.... interesting time discrepancy issues between the
primary data and the metadata.
The underlying problem is porting metastore around to all the client
systems. I can guarantee the presence and compatibility of "rsync",
but not of metastore on the variety of platforms.
You just need some way to store stats into a file. Could be different
way for different platforms. Maybe even rsync itself can do this, see
man rsync "BATCH MODE".
cu,
Rudi
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
