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?
-
1Define "rsync account". Is this just an account on another server that you push backups to?– EEAAMay 29, 2011 at 1:36
-
yeah, but I have ssh and cron access.– IncognitoMay 29, 2011 at 2:40
Add a comment
|
3 Answers
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.
answered May 29, 2011 at 11:50
-
spot on, in my opinion. @Incognito: is there a reason you're not doing this already? May 29, 2011 at 13:30
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.
-
Can you clarify what you mean by "push to it from the web server"? May 29, 2011 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 ShawMay 29, 2011 at 12:15 -
how are you handling authentication to the backup server in this case? May 29, 2011 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 ShawMay 29, 2011 at 12:30
-
1I 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. May 29, 2011 at 12:38
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.
