Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Backup over SFTP - key chain
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Backup over SFTP - key chain

Hello,

I want to change my automated backup to SFTP. I think of using SFTP and passphrase-free keys. Is that secure? Should I make it that the client server connects to my backupserver over SFTP and uploads the backup or the other way round that my backupserver connects to the client servers and downloads the backup? Which way is more secure?

Regards and thank you :)

Comments

  • AbdussamadAbdussamad Member
    edited February 2014

    Use rsync + rsnapshot for this. Pull the backups into the backup server i.e. the backup server initiates the connection to the production server. Here's a guide:

    http://abdussamad.com/archives/361-Automating-incremental-backups-with-Rsnapshot.html

    And if you want to know about setting up public key authentication here's a guide for that:

    http://abdussamad.com/archives/365-CentOS-Linux:-Secure-password-less-SSH-access.html

    Just install the backup server's public key on the production server's authorized_keys file so that the backup server can connect without needing to provide a password.

  • Use rsync + keys, limit the key to only rsync server so even if your key is compromised the attackers can't do much harm.

    Thanked by 1Abdussamad
  • Personally, I prefer to push to my backup server. There's keys to my backup server sitting on my live servers. If somebody gets those keys, they have access to encrypted backup files.

    If I were to pull from my live servers, then I'd have to keep keys to my live servers on my backup server. If the backup server was compromised and somebody got those keys then they'd have access to my live servers (not good).

  • I go the push route too. As long as you put proper containment around your sftp drop zone, it tends to have a smaller OMG surface area. I'd reserve pull for intrinsically insecure systems like user workstations that are otherwise non-critical but where you may wish to have better control over scheduling.

  • Pull is recommended because the backup server usually runs just one thing and that is rsnapshot/rsync. So there are fewer ways anyone could potentially compromise the backup server. The production server OTOH runs a bunch of services like httpd, dns, mta etc. so there are more attack vectors there. If the production server is compromised the backups will also be compromised.

  • Thank you for all your suggestions.

    I prefer using my own backup script, at the moment I use tar to create backups and ftp to transfer them. I will change this to sftp for security reasons. The only question left is should I use pull (backup server connects to live servers and downloads newest achieve) or push (live servers connect to backup server and drop their newest achieve).

    Both have positive and negative aspects:
    pull:

    • live servers can't connect to backupserver, if they get infected my backups are safe
    • if backupserver gets infected they have access to all my live servers

    push:

    • if the live servers get infected, they have only access to the backups of the one live server
    • backup server runs less software so less security risks

    I tend to use the push method, as I think it's better for me to secure my live servers

Sign In or Register to comment.