1

I am concerned about attacks of the crypto malware which encrypts all storage reachable (for a ransom payment you get the key to decrypt). I use only Linux (Debian) and have a separate ARM computer to write each night a backup to disk.

What is better (more secure against attacks):

  • to mount the disk with the data to be backed up as read-only (remote mount) on the backup server
  • use a remote source for rdiff-backup

The backup server is on at all times but not directly accessible with ssh (only locally from computers which are accessible from outside).

How could an attacker get into the backup server (assuming it had gotten into one of the local machines)?

  • Use a solution where the server to be backed up can add new files to the backup but has no way of deleting prior backups. – André Borie Jul 3 '16 at 14:25
  • @AndréBorie That can in the end become bit of unmanageable when you want to "legally" delete a file. A better way is as I said in the answer, create a diff on the server, so if a ransomware or another malware, or you by mistake, deletes a file you want to keep, you just delete the latest diff or snapshot. While when you really WANT to delete a file, you just merge the snapshots manually at physical console after having verified they haven't been touched by a malware. – sebastian nielsen Jul 3 '16 at 14:47
  • You should probably clarify what machines you want to backup. It's not clear if the Debian machine is the one being backed up, or the backup server itself. – Alexander O'Mara Jul 3 '16 at 19:16
1

The best way to solve this, is to use LVM Snapshots, to create a "virtual" drive, that is then snapshotted incrementally with regular intervals. This virtual drive is then "shared" through Samba, iSCSI or similar tool to each Windows computer.

Of course, every client can use the same virtual drive.

IF a ransomware then encrypts the files on this "virtual drive", causing all files on the shared Samba/iSCSI disk to be encrypted, you simply delete the snapshot images (which are "diff"s of a drive) until the files are accessible again.

Of course, a good idea is to have the server secured by a firewall such as so it can only be accessed through its Samba/iSCSI ports over the network.

Any console access is to made physically, at the local console.

No other solution is better, as if you mount the drive readonly you must still enforce some sort of versioning on server side, else you will overwrite a perfectly good backup with encrypted rubbish if a ransomware happens to attack.

If you use rdiff, you must still make sure the diff versioning is enforced on server-side and not client-side, else the ransomware can bypass this and overwrite all the diff's.

The best way to enforce versioning on the server side, is to use LVM Snapshots and then just share a "flat iSCSI drive" or a "Samba share" to the client computer. The advantage, is that malware, cannot know that the drive in question is versioned on the server side.

The only disadvantage with a server-side versioned drive, is that you transfer all data over the wire, even unchanged data, but that shouldn't be a problem since you transfer regularly instead of transferring all at once.

  • Why recommend Windows software when OP said they are using Linux? – Alexander O'Mara Jul 3 '16 at 19:03
  • @AlexanderO'Mara My understanding of OPs post, is that the OP is using windows computers that connect to a Linux computer for backup, but the OPs server and backup system is only using Linux. Because, linux does not have any "ransomware"/"malware" problem what I know of, due to linux being so a uncommon platform that writing malware for that platform is not viable. – sebastian nielsen Jul 3 '16 at 19:10
  • Hmm, could be, the wording is really ambiguous. I took it to be a Debian machine (possibly a web server) that needs to backup to the ARM server. I believe there is some ransomware used on compromised Linux servers in the wild. I'll ask the OP to clarify. – Alexander O'Mara Jul 3 '16 at 19:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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