Mailinglist Archive: opensuse-security (556 mails)
| < Previous | Next > |
Re: [suse-security] automatic backups over ssh/scp
- From: Steffen Dettmer <steffen@xxxxxxx>
- Date: Sat, 8 Sep 2001 17:29:17 +0200
- Message-id: <20010908172917.A2309@xxxxxxxxx>
* Maarten J H van den Berg wrote on Fri, Sep 07, 2001 at 19:46 +0200:
> On Friday 07 September 2001 17:50, you wrote:
> > * Maarten J H van den Berg wrote on Fri, Sep 07, 2001 at 15:44 +0200:
[...rsync via ssh wrapper...]
[...command="rsync"...]
> > Well, actually it's like that. SSHD ignores the parameters of the
> > client command completely and uses the parameter list from
> > command="". sshd delivers the parameters in SSH_ORIGINAL_COMMAND
> > (or similar), openssh seems not to have that nice feature.
>
> Thanks for clearing that up. However, this IS in fact
> openssh... Or do you just mean that openssh does the same
> thing but does not provide the original command in
> SSH_ORIGINAL_COMMAND ?
Yep, this environment variable gets not set by OpenSSH. I cannot
imagine that this is a big task to supply argv through the
environment, I should make a patch, but time is missing as
always.
I have some wrapper scripts which evalute SSH_ORIGINAL_COMMAND.
By this, it's possible to allow a well defined set of parameters.
I used perl to filter that. If and only if the parameters are ok,
the action is taken. I thought about some generic wrapper, which
can be configured to allow a defined command set with some
parameters, i.e. the fourth parameter can be arbitary as long as
it's a number or whatever. Due to this, I still have some
machines running non-open SSH servers...
> ("Here is your server. To be totally sure, we just audited all of the
> kernelsources 2.4.9. We just thought it was a nice addition to the
> service-level you usually get from us. And ehm... here is your bill.")
:) hihi, or even:
"Here is your server. We just finished the audits of kernel
2.0.11 and printed a book with open issues which are not easy to
fix. We estimated to additional years to be able to offer you a
audited backup solution, but for now it's cheaper to use a DAT
for each host." :)
> > Ohh, really? I just look from time to time :)
>
> Hehehe. No, I myself insist on 200+ cron messages in my inbox daily ;-))
> (NOT)
Well, I think about a netsaint plugin for such purposes. Each
server could write a timestamp in a special file, i.e.
/root/current_timestamp (each 5 minutes or so), and the plugin
verifies the file inside the backup. It alerts if the timestamp
is older as i.e. 24 hours or so. Well, I think this would take a
few hours to implement...
> Yes... But if you think not in absolute terms ("totally secure") but
> relative terms ("one level more difficult to break than before"), every
> little bit can help. But like I said, someone determined...
You're right of course. After all it shows up in pracitise that
security through obscurity helps often against script kiddies.
> You know, that is *exactly* what my first approach to this problem was.
> Like taking a ls-lR list, feed that to some nice script that replays all
> chmod/chown commands neccessary to put things back to how they were.
I think this would be difficult to parse. I made a example perl
script which I attach to this mail. It gets a list of parameters
of filenames (i.e. find /path | xargs ./perm.pl). It processes
all files via lstat(2), puts some values into a hash. After that,
it stores that hash on disk (just example code). Then it deletes
the filelist and informations from memory. This is like on
backup operations.
After that, the scripts opens the disk file and load the hash
back (meant for restore operations). It prints out chmod ; chown
commands to restore the old state.
Well, this isn't for production since it does eval on the
permissions file ("filelist.dump"). This is dangerous if that
file contains other perl statements, and by this the permission
file is very security relevant :). But it's just an example.
What to do with it?
If someone would use such a thing, I would modify the script to
process filenames from stdin (or to use find internally). The
call could be "find /path -print0 | perl.pl -o filelist.dump". If
started with "-o" it stops after writing filelist to disk.
On restore, call "perl.pl -s filelist.dump" to set the saved
permissions. Maybe some control on which files that should apply
and so on. In this case, the script startes with reading
filelist.dump from disk and does not print the chown/chmod
commands but executes them.
Well, and I think I would add support for the times (mtime...)
which shouldn't be a problem, and some error handling of course.
This is not much code in such a case, I think 2 hours programming
(one of them for considerations) but 10 hours testing :)
Maybe I'll get some statements; if someone is interested in such
a script and if we find some tester I could implement it. Well,
drop me a note.
> In the end I could not find anything that does this, and I
> already told you about my limited programming skills so I
> dropped that idea. However, this is really something I'd like
> to see as a tool. Maybe someday, someone will write it... In
> that case, no more need for elevated priviledges for backups.
I'm not really sure if someone would use it, since if it's not
integrated into a tool like rsync it's additional work to put it
into the cronjobs. What do you think?
> > As long as adminstrated by a single person I don't see a
> > difference, but at least if they admin of the backup client has
> > no shell access to the baskupserver client pull is configurable
> > by him.
I meant "client push" in the last sentence of course.
> If it's root who does the backup, there is no real problem (but
> that may not be advisable). If it's an ordinary user who does
> the backups, it could create havoc on all the different
> permissions one has to set up.
What do you mean? I don't think it's possible to let an ordinary
user doing backups. I meant, there is rootA on backupserver which
is different from rootB on client B. In your case (client push)
rootA could configure access to some path, and rootB on client B
could manage the exclude lists or similar.
> One could also run scripts on the client and the server simultaneously,
> on the client side a root-cronjob copies & chowns some root-owned files
> to a special backup dir which is only readable by the backup daemon, and
> the server pulls them with a non-priviledged account. But it is doubtful
> that gives you any more security (or even, less!) The whole point of
> -for instance- /etc/shadow is that it is NOT readable by anyone...
Well, the backupuser don't need a shell account or password, so
it's not a bad security risk I think. But it's much efford to
copy all files local first, loseing all permissions. I think it's
the same as client push to backup user on backup host directly.
> Besides, a lot of things can break this setup. For instance, the machines
> have to be time-sync'ed for this to work well.
Well, ntp should run on every host all the time, my netsait
checks that :)
> Same here, It was very nice to exchange views on this subject.
> Speak to you later, I hope.
Thank you. Maybe we'll find the ideal solution? Hum. :) Someone
with time to patch rsync here? Shouln't be too much work: instead
of _doing_ "chmod mode, file" printf mode, file to some
permission file - or similar. But on restore? Just `permission
file` command substition? What with error handling... Well...
> Oh, and: Have a nice weekend !
Same to you and the list!
oki,
Steffen
--
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.
> On Friday 07 September 2001 17:50, you wrote:
> > * Maarten J H van den Berg wrote on Fri, Sep 07, 2001 at 15:44 +0200:
[...rsync via ssh wrapper...]
[...command="rsync"...]
> > Well, actually it's like that. SSHD ignores the parameters of the
> > client command completely and uses the parameter list from
> > command="". sshd delivers the parameters in SSH_ORIGINAL_COMMAND
> > (or similar), openssh seems not to have that nice feature.
>
> Thanks for clearing that up. However, this IS in fact
> openssh... Or do you just mean that openssh does the same
> thing but does not provide the original command in
> SSH_ORIGINAL_COMMAND ?
Yep, this environment variable gets not set by OpenSSH. I cannot
imagine that this is a big task to supply argv through the
environment, I should make a patch, but time is missing as
always.
I have some wrapper scripts which evalute SSH_ORIGINAL_COMMAND.
By this, it's possible to allow a well defined set of parameters.
I used perl to filter that. If and only if the parameters are ok,
the action is taken. I thought about some generic wrapper, which
can be configured to allow a defined command set with some
parameters, i.e. the fourth parameter can be arbitary as long as
it's a number or whatever. Due to this, I still have some
machines running non-open SSH servers...
> ("Here is your server. To be totally sure, we just audited all of the
> kernelsources 2.4.9. We just thought it was a nice addition to the
> service-level you usually get from us. And ehm... here is your bill.")
:) hihi, or even:
"Here is your server. We just finished the audits of kernel
2.0.11 and printed a book with open issues which are not easy to
fix. We estimated to additional years to be able to offer you a
audited backup solution, but for now it's cheaper to use a DAT
for each host." :)
> > Ohh, really? I just look from time to time :)
>
> Hehehe. No, I myself insist on 200+ cron messages in my inbox daily ;-))
> (NOT)
Well, I think about a netsaint plugin for such purposes. Each
server could write a timestamp in a special file, i.e.
/root/current_timestamp (each 5 minutes or so), and the plugin
verifies the file inside the backup. It alerts if the timestamp
is older as i.e. 24 hours or so. Well, I think this would take a
few hours to implement...
> Yes... But if you think not in absolute terms ("totally secure") but
> relative terms ("one level more difficult to break than before"), every
> little bit can help. But like I said, someone determined...
You're right of course. After all it shows up in pracitise that
security through obscurity helps often against script kiddies.
> You know, that is *exactly* what my first approach to this problem was.
> Like taking a ls-lR list, feed that to some nice script that replays all
> chmod/chown commands neccessary to put things back to how they were.
I think this would be difficult to parse. I made a example perl
script which I attach to this mail. It gets a list of parameters
of filenames (i.e. find /path | xargs ./perm.pl). It processes
all files via lstat(2), puts some values into a hash. After that,
it stores that hash on disk (just example code). Then it deletes
the filelist and informations from memory. This is like on
backup operations.
After that, the scripts opens the disk file and load the hash
back (meant for restore operations). It prints out chmod ; chown
commands to restore the old state.
Well, this isn't for production since it does eval on the
permissions file ("filelist.dump"). This is dangerous if that
file contains other perl statements, and by this the permission
file is very security relevant :). But it's just an example.
What to do with it?
If someone would use such a thing, I would modify the script to
process filenames from stdin (or to use find internally). The
call could be "find /path -print0 | perl.pl -o filelist.dump". If
started with "-o" it stops after writing filelist to disk.
On restore, call "perl.pl -s filelist.dump" to set the saved
permissions. Maybe some control on which files that should apply
and so on. In this case, the script startes with reading
filelist.dump from disk and does not print the chown/chmod
commands but executes them.
Well, and I think I would add support for the times (mtime...)
which shouldn't be a problem, and some error handling of course.
This is not much code in such a case, I think 2 hours programming
(one of them for considerations) but 10 hours testing :)
Maybe I'll get some statements; if someone is interested in such
a script and if we find some tester I could implement it. Well,
drop me a note.
> In the end I could not find anything that does this, and I
> already told you about my limited programming skills so I
> dropped that idea. However, this is really something I'd like
> to see as a tool. Maybe someday, someone will write it... In
> that case, no more need for elevated priviledges for backups.
I'm not really sure if someone would use it, since if it's not
integrated into a tool like rsync it's additional work to put it
into the cronjobs. What do you think?
> > As long as adminstrated by a single person I don't see a
> > difference, but at least if they admin of the backup client has
> > no shell access to the baskupserver client pull is configurable
> > by him.
I meant "client push" in the last sentence of course.
> If it's root who does the backup, there is no real problem (but
> that may not be advisable). If it's an ordinary user who does
> the backups, it could create havoc on all the different
> permissions one has to set up.
What do you mean? I don't think it's possible to let an ordinary
user doing backups. I meant, there is rootA on backupserver which
is different from rootB on client B. In your case (client push)
rootA could configure access to some path, and rootB on client B
could manage the exclude lists or similar.
> One could also run scripts on the client and the server simultaneously,
> on the client side a root-cronjob copies & chowns some root-owned files
> to a special backup dir which is only readable by the backup daemon, and
> the server pulls them with a non-priviledged account. But it is doubtful
> that gives you any more security (or even, less!) The whole point of
> -for instance- /etc/shadow is that it is NOT readable by anyone...
Well, the backupuser don't need a shell account or password, so
it's not a bad security risk I think. But it's much efford to
copy all files local first, loseing all permissions. I think it's
the same as client push to backup user on backup host directly.
> Besides, a lot of things can break this setup. For instance, the machines
> have to be time-sync'ed for this to work well.
Well, ntp should run on every host all the time, my netsait
checks that :)
> Same here, It was very nice to exchange views on this subject.
> Speak to you later, I hope.
Thank you. Maybe we'll find the ideal solution? Hum. :) Someone
with time to patch rsync here? Shouln't be too much work: instead
of _doing_ "chmod mode, file" printf mode, file to some
permission file - or similar. But on restore? Just `permission
file` command substition? What with error handling... Well...
> Oh, and: Have a nice weekend !
Same to you and the list!
oki,
Steffen
--
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.
| < Previous | Next > |