Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 2 down vote favorite
1

Right now I backup my website/server daily using rsync with cron. What I'm worried about is someone hacking into my server and then gaining access to my rsync account and deleting everything. How do I go about protecting myself from this?

share|improve this question
1  
Define "rsync account". Is this just an account on another server that you push backups to? – EEAA May 29 '11 at 1:36
yeah, but I have ssh and cron access. – Incognito May 29 '11 at 2:40

3 Answers

up vote 4 down vote accepted

As I understand, the main problem is that you've configured the rsync process to be initiated from the "wrong side". Your backup server should be the one initiating the connection and having an account on your production server, not vice versa.

This way you would not need an account on the backup server which is accessible from (and which credentials or access tokens are stored on) the more exposed production server.

Of course, this raises the question of the possible impact of a break into the backup server, but there you can just limit the backup user's ability of breaking things - using an rsync daemon on the production server with a read-only share for the things to back up would be an easy option to do so.

share|improve this answer
spot on, in my opinion. @Incognito: is there a reason you're not doing this already? – Eduardo Ivanec May 29 '11 at 13:30
up vote 1 down vote

There are a few layers of security that you can build in.

Don't allow access from vulnerable servers to secure servers

The web server should be considered vulnerable, therefore you should limit the possibility of outbound access from your web server to your backup server. The data retrieval should be initiated from the backup server using a read-only, limited account.

Limit the attack surface

You want to have as few services and access points on your web server as possible. One approach is to create a staging point: push data from the web server to a staging server (which should also be considered vulnerable), then pull that data to your backup server to secure it.

share|improve this answer
Can you clarify what you mean by "push to it from the web server"? – gravyface May 29 '11 at 12:04
Run the rsync daemon on the backup server. Then, on the web server, use rsync /local/directory rsync://backupserver:/remote/directory. The (worse) alternative would be to execute the rsync command on the backup server. – Tom Shaw May 29 '11 at 12:15
how are you handling authentication to the backup server in this case? – gravyface May 29 '11 at 12:17
@gravyface: username/password using a password file. Sure, this allows someone who has pwned the webserver to also delete the backups, but that can be mitigated as described. The key point is that the webserver is the high-value target. It's more important to reduce the attack surface of the webserver itself (i.e. an attack via the backup server or rsync user). – Tom Shaw May 29 '11 at 12:30
1  
I look at this completely differently: my backup server is my high-value target and is more secure by default, because it's not exposed to the Internet at all. In security planning, I often plan around the fact that my webserver will get owned, and how I go about mitigating that risk and responding to those threats is part of the process. That's why I'd rather my backup server pull backups from my webserver with a purpose-built/limited account (with key pairs, never username/password for any account on the webserver) that has read-only privileges on the webroot. – gravyface May 29 '11 at 12:38
show 1 more comment
up vote 0 down vote

I dont know what hardware you have available but there are several options. The 1st would be to put the data on a tape or some other form of media that can be set aside offline. It may not always get you back the the most recent revision but you would have the data somewhere offline in the case of an attack. The 2nd option would be a secondary "backup" system that keeps a copy of the data. You could remotely rsync the data "down" to that box so if someone did get in, they could not easily get to your backup (keep the passwords, keys, etc. different on both systems and keep up with patches). Both of these assume you can get some more hardware (or even a virtual server in option 2). Anything on the same system would have to be considered suspect if it was compromised.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.