-5

Rsync is an awesome tool. But I think if one attacker is possible to intrude my server and take advantage of rsync for removing data of other server:

sudo rsync -avzP --delete /tmp/emptyfolder -e "ssh -p 22" <other_server_ip>:/

If I lose one server, I don't want the attacker use it to destroy other servers. How to prevent it ?

4
  • 5
    If they already have root, and you have ssh-keys without passwords, they can do this without using rsync. The solution is to secure your servers so that nobody can ssh in as root, especially not without passwords.
    – Jenny D
    Feb 4, 2015 at 9:59
  • What Jenny said. You're essentially worrying that someone who can already hack your server can hack your server.
    – Rob Moir
    Feb 4, 2015 at 10:43
  • We know the risk of remote access as root. we disabled root access, just allow some users with sudo permission. For more secure, we limited rsync from this server to some servers with ssh-key. But We are not sure all setup is perfect. In a disaster circumstance, for any reasons, a user with sudo permission lost passwd and sshkey. We mean How to prevent attacker to use permission and ssh key to destroy data on other server with rsync ? Is the answer 'no way' in the circumstance ? Feb 4, 2015 at 10:53
  • 2
    Again, rsync isn't the problem here. The attacker can do the same thing using e.g. rm, cp, mv, etc. Closing down one particular program that is being run on the remote side is not the way to go. You need an in-depth security - which is an issue too broad for a QA site.
    – Jenny D
    Feb 4, 2015 at 11:19

1 Answer 1

6

I can see three obvious possibilities right off the bat (and I am sure there are more that even I could think of if I spent some time considering this):

  1. Don't allow random users to run random commands, or commands that allow breaking out into an environment that will allow running random commands (such as an editor launching a subshell or saving files into /etc/cron.d), as root.

  2. Don't allow automatically-authenticated (password-less) logins as root on other machines, even from "trusted" machines. If you absolutely must allow automatically-authenticated logins as root, make sure those logins use separate keys which are locked down to only allow exactly what is needed, and consider whether the flow of jobs can be reversed such that jobs do not need superuser privileges to run.

  3. Have backups, and a disaster recovery plan. Make sure both are tested regularly.

Basically, these boil down to do your job as a sysadmin. A sane setup should employ all these tactics to protect against both the threat of an outside attacker as well as simple mistakes by otherwise authorized individuals or hardware/software failures.

Most attackers who are able to gain root privileges are more likely to use that to gain further access or to exfiltrate data, rather than to destroy the system. A destroyed system has no value to the attacker unless they are out to test your backups and disaster recovery procedures. A system that can be used as a springboard for further attacks has potentially significant value. Part of your job as a sysadmin is to ensure the security and confidentiality of the systems and data in your care.

4
  • 1
    +1 from me. If you absolutely must (and I do mean must) do (2), make sure the ssh keys are tied down so that each trusted key can only be used to execute the command that it personally needs to. But you will generally find that there is no reason to allow remote access as root; by reversing the command flow, jobs can generally be run without privilege.
    – MadHatter
    Feb 4, 2015 at 10:01
  • @MadHatter Good point! Incorporated.
    – user
    Feb 4, 2015 at 10:02
  • what does "reversing the command flow" mean ? Feb 4, 2015 at 11:02
  • 1
    @LukeNguyen To connect in the opposite direction, usually for the purpose of reducing required permissions for an "untrusted" side. For example, you don't want a backed up system to be able to wipe the copies that exist on the backup storage server, so you have the backup storage server initiate the connection rather than allowing every backed-up system connect willy-nilly to the backup storage server, potentially even as root (to preserve file ownership etc.).
    – user
    Feb 4, 2015 at 12:40

Not the answer you're looking for? Browse other questions tagged .