We've been using rsync since forever to back up all our servers and it's worked without a problem. But in a recent security review, we noted that our specific rsync backup host is using root keys to access the server, meaning that if the keys on the backup server were leaked/compromised in any fashion, that would provide r00t access to the servers being backed up.
Since this doesn't seem to be readily documented, I thought I'd provide it to the community.
After some playing around, we've found it is possible to set up rsync/ssh so that the connecting server can ONLY run rsync with a predetermined set of options.
// OBJECTIVES // 1) Make it so the backup server's SSH key can only be used A) in an rsync read-only. (no write capability to the production webserver) B) against a predetermined set of directories and with a predetermined set of options. 2) Limit the power of the webserver/backup account so that it cannot do anything other than a read-only rsync. 3) Limit access to the backup account to a specific IP address, EG: only the backup server can access the account.
# ON WEBSERVER (note: normal account!) ------------------------------------- [root] # adduser backupaccount;
# ON WEBSERVER in /home/backupaccount/.ssh/authorized_keys ("backupserver" must be the remote, publicly visible IP address of the backup server) ------------------------------------- from="backupserver" ssh-dss AAAAB3NzaC1kc3MAAACBAKLv/SNIP/ root@backupserver -------------------------------------
# ON BACKUPSERVER Verify that root@backupserver can log in normally via ssh without password: ------------------------------------- [root@backupserver] # ssh backupaccount@webserver
# ON WEBSERVER In /etc/passwd. (change the shell at the end of the line) ------------------------------------- backupaccount:x:514:514::/home/backupaccount:/usr/local/bin/backupaccount.sh
# ON WEBSERVER in /etc/sudoers ------------------------------------- backupaccount ALL=NOPASSWD: /usr/bin/rsync Defaults:backupaccount !requiretty -------------------------------------
# ON WEBSERVER And in /usr/local/bin/backupaccount.sh ------------------------------------- #! /bin/sh # look in this file to see what options were passed, if the rsync doesn't work. echo $* > /home/backupaccount/options.passed.sh # rsync -va backupaccount@WEBSERVER:/home/ /mnt/backup/home/ /usr/bin/sudo /usr/bin/rsync --server --sender -vlogDtpre.iLs . /home/ -------------------------------------
Note that in this solution, it doesn't matter what the backupserver specifies as the backup location, it will ALWAYS get /home/ and it may well break if you change the options any. EG: using "z" for compression, etc. If this happens, look in options.passed.sh to see what rsync on the backup server tried to pass and, if it makes sense, modify the backupaccount.sh script with these options, or modify backupaccount.sh so that it can take any of a number of source directories after appropriate validation.
Lists wrote:
We've been using rsync since forever to back up all our servers and it's worked without a problem. But in a recent security review, we noted that our specific rsync backup host is using root keys to access the server, meaning that if the keys on the backup server were leaked/compromised in any fashion, that would provide r00t access to the servers being backed up.
Since this doesn't seem to be readily documented, I thought I'd provide it to the community.
After some playing around, we've found it is possible to set up rsync/ssh so that the connecting server can ONLY run rsync with a predetermined set of options.
<snip> Yup. What we do is have keys for a specific program (in house written) that is called via crontab, and the keys for the backup server is *only* on the servers that are backed up by that system, and there's an in-house written script that restricts what that program can do. It does have to run as root, though, on both, to preserve ownership of home and project directories, etc.
mark
On 09/23/2013 01:02 PM, m.roth@5-cent.us wrote:
It does have to run as root, though, on both, to preserve ownership of home and project directories, etc.
Depending on how you interpret this statement, my documented process may present a (mild) improvement.
It has the backup account on the public server being a non-priviliged account only able to run a (tightly controlled) shell script which contains the sudo call. In this way, even if the backup account is compromised, it can't be used to "take down" the web server, only provide access to the data. Technically, the rsync command *is* being run as (sudo) root, but nothing else is, and the backup account has no ability to change the parameters of the rsync account.
On Mon, Sep 23, 2013 at 3:26 PM, Lists lists@benjamindsmith.com wrote:
Depending on how you interpret this statement, my documented process may present a (mild) improvement.
It has the backup account on the public server being a non-priviliged account only able to run a (tightly controlled) shell script which contains the sudo call. In this way, even if the backup account is compromised, it can't be used to "take down" the web server, only provide access to the data. Technically, the rsync command *is* being run as (sudo) root, but nothing else is, and the backup account has no ability to change the parameters of the rsync account.
Is there something that convinces you that sudo is better at handling the command restriction than sshd would be?
On 09/23/2013 01:50 PM, Les Mikesell wrote:
Is there something that convinces you that sudo is better at handling the command restriction than sshd would be?
In the context of a production server, the idea is to remove any ability from another host (EG: backup server) to run local arbitrary code or change local files. (read-only)
There is one (small) benefit to not using SSHD options: Even if the account is somehow accessed locally, (eg via password prompt) it still cannot be used for anything but a read-only rsync command. And by using a (read only) script to replace the normal shell and sudo, I'm able to not only limit the command being run (in this case rsync) but also limit all options passed to it.
You can disable the password on the backup account to achieve a similar effect using an SSHD option. If there's a better/simpler way to do this via SSHD option I'd love to hear about it!
Thanks,
-Ben
Lists wrote:
On 09/23/2013 01:50 PM, Les Mikesell wrote:
Is there something that convinces you that sudo is better at handling the command restriction than sshd would be?
In the context of a production server, the idea is to remove any ability from another host (EG: backup server) to run local arbitrary code or change local files. (read-only)
<snip>
You can disable the password on the backup account to achieve a similar effect using an SSHD option. If there's a better/simpler way to do this via SSHD option I'd love to hear about it!
Sure. You disable password authentication, and allow keys only, in /etc/ssh/sshd_config.
mark
On 09/23/2013 02:44 PM, m.roth@5-cent.us wrote:
Lists wrote:
On 09/23/2013 01:50 PM, Les Mikesell wrote:
Is there something that convinces you that sudo is better at handling the command restriction than sshd would be?
In the context of a production server, the idea is to remove any ability from another host (EG: backup server) to run local arbitrary code or change local files. (read-only)
<snip> > You can disable the password on the backup account to achieve a similar > effect using an SSHD option. If there's a better/simpler way to do this > via SSHD option I'd love to hear about it! > Sure. You disable password authentication, and allow keys only, in /etc/ssh/sshd_config.
This prohibits SSH logins via password, but does not strictly enforce what commands are allowed to be run (and all options allowed) by a specific which is what I was looking for.
Having done a bit more research, It does appear that you could use the "ForceCommand" option and disable passwords altogether for a user to achieve a similar effect with SSHD.
-Ben
Lists wrote:
On 09/23/2013 02:44 PM, m.roth@5-cent.us wrote:
Lists wrote:
On 09/23/2013 01:50 PM, Les Mikesell wrote:
Is there something that convinces you that sudo is better at handling the command restriction than sshd would be?
In the context of a production server, the idea is to remove any ability from another host (EG: backup server) to run local arbitrary
code or
change local files. (read-only)
<snip> > You can disable the password on the backup account to achieve a similar > effect using an SSHD option. If there's a better/simpler way to do this > via SSHD option I'd love to hear about it! > Sure. You disable password authentication, and allow keys only, in /etc/ssh/sshd_config.
This prohibits SSH logins via password, but does not strictly enforce what commands are allowed to be run (and all options allowed) by a specific which is what I was looking for.
Having done a bit more research, It does appear that you could use the "ForceCommand" option and disable passwords altogether for a user to achieve a similar effect with SSHD.
Right, but a) it very much limits who can get in. Another thing is that you can run the backups from a cron job as a push, instead of a pull.
And the other user still leaves the issue of ownership - only root can copy a user's home directory, or a project directory owned by that project, and keep it all the same.
And don't forget to save selinux contexts....
mark
A couple of weeks ago I found this breakdown of various approaches
https://techstdout.boum.org/EncryptedBackupsForParanoiacs/
We're currently using a variation of the push-backup system described (using rsync via duplicity).
K
Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd (w) +61 (0) 3 9008 5281
Suite 1415 401 Docklands Drive Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925
On Tue, Sep 24, 2013 at 7:58 AM, m.roth@5-cent.us wrote:
Lists wrote:
On 09/23/2013 02:44 PM, m.roth@5-cent.us wrote:
Lists wrote:
On 09/23/2013 01:50 PM, Les Mikesell wrote:
Is there something that convinces you that sudo is better at handling the command restriction than sshd would be?
In the context of a production server, the idea is to remove any ability from another host (EG: backup server) to run local arbitrary
code or
change local files. (read-only)
<snip> > You can disable the password on the backup account to achieve a similar > effect using an SSHD option. If there's a better/simpler way to do this > via SSHD option I'd love to hear about it! > Sure. You disable password authentication, and allow keys only, in /etc/ssh/sshd_config.
This prohibits SSH logins via password, but does not strictly enforce what commands are allowed to be run (and all options allowed) by a specific which is what I was looking for.
Having done a bit more research, It does appear that you could use the "ForceCommand" option and disable passwords altogether for a user to achieve a similar effect with SSHD.
Right, but a) it very much limits who can get in. Another thing is that you can run the backups from a cron job as a push, instead of a pull.
And the other user still leaves the issue of ownership - only root can copy a user's home directory, or a project directory owned by that project, and keep it all the same.
And don't forget to save selinux contexts....
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Am 23.09.2013 um 23:58 schrieb m.roth@5-cent.us:
This prohibits SSH logins via password, but does not strictly enforce what commands are allowed to be run (and all options allowed) by a specific which is what I was looking for.
Having done a bit more research, It does appear that you could use the "ForceCommand" option and disable passwords altogether for a user to achieve a similar effect with SSHD.
Right, but a) it very much limits who can get in. Another thing is that you can run the backups from a cron job as a push, instead of a pull.
Conceptually i wouldn't recommend this from a public server (as mentioned).
-- LF
This prohibits SSH logins via password, but does not strictly enforce what commands are allowed to be run (and all options allowed) by a specific which is what I was looking for.
I found this article series from 2002 (!) quite good.
http://www.hackinglinuxexposed.com/articles/20021211.html
The last in the series
http://www.hackinglinuxexposed.com/articles/20030115.html
introduces a method (via perl script) to control which commands can be run via ssh.
-
isdtor＠gmail.com -
Kahlil Hodgson -
Leon Fauster -
Les Mikesell -
Lists -
m.roth＠5-cent.us