Ransomware Protection & Secret Backup Server using Rsync

SrTweak

New Member


Messages: 2

Hi,

I need an advise and correct direction to my problem. I am a new FreeBSD user. Our recent Windows 10 machine was hit by a Ransomware and it spread to other machines on Network also.
To protect that in future, I added a new HDD on the system and installed FreeBSD 12.0 x64 using HyperV on it with specs:
2 Core Virtual CPU,
2 GB Ram,
1 internal host only network,
16GB Boot Drive and
4TB Data Single Drive physically attached formatted as ZFS.

I installed the base FreeBSD using minimal network install CD and installed Rsync PKG on it. My thought is to Rsync all the files on the machine using Windows Sub System for Linux. I do not want to expose any other networking service or anything other than Rsync from FreeBSD VM.

I need your help in:

1. Is this the correct strategy as even if any malware hits it cannot find the exposed ports. Are there any other ways or softwares.
2. How to setup Rsync Server as Daemon over SSH in freebsd. I installed Rsync as PKG but I need to login and then run it manually everytime. I want it to run automatically without any user login.
3. How can I add full disk encryption like Bitlocker to my entire data drive so it unlocks automatically at boot. Currently, I was not able to enable encryption with ZFS. Any step by step guide will help me a lot.
4. What permissions I need to setup on my Data Drive. Currently if I login as root then only Rsync is able to transfer files. If I login as non root user Rsync does not work.

Thank you
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 7,091
Messages: 29,244

  1. It depends how and when you do the rsync. Because you need to be careful you're not rsync'ing infected files to your backup. Those files will just sit there (they won't spontaneously infect the host) but might get sync'ed back when you're restoring the backup.
  2. No need for the daemon and ssh is used by default. Authentication can be done "password-less" using keys.
  3. Disk encryption isn't going to protect you in this case. Remember, the data is decrypted and accessible when the machine is running. Full disk encryption will only protect your data in case the disk itself gets stolen.
  4. Rsync to a destination directory the user can write to. Any directory will do, you just need to set the correct ownership and permissions on that destination directory.
 
OP
OP
S

SrTweak

New Member


Messages: 2

1. For that reason only I want to use ZFS so to take snapshots.
3. I want to use Disk Encryption as disk is ESata. So How can I do it ?
4. So what permission mask I set so any local user on that FreeBSD machine can read/write it.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 7,091
Messages: 29,244

1. snapshots have the same problem, as you don't know the file is infected you're going to snapshot an infected file. One of the worst things malware can do is slowly infect files by only changing a couple of files a few bytes at a time. By the time it gets noticed you will have backed up a truck-load of corrupted files going back weeks. Then you can go back each snapshot trying to find the original, clean, file again.
3. Any disk can be encrypted. That's one of the cool things of FreeBSD's GEOM, you can 'stack' layers on top of each other. But keep in mind you cannot do an "in-place" conversion. 17.12.2. Disk Encryption with geli
4. Something like 770 for the directory will do. Create a group called backup or something like it. Set the ownership of the directory to root:backup. Add each user to this backup group. Or use a single, dedicated, backup account for everything and store each individual user's backup in a subdirectory like /storage/backups/${someuser}/ and make sure the backup account owns the /storage/backups/ directory and has at least 700 permissions (rwx for the owner).
 

ralphbsz

Daemon

Reaction score: 933
Messages: 1,493

To begin with: the real problem is not taking backups, but security. Whatever bad security setups caused your Windows machine to be vulnerable needs to be understood and fixed. And in view of the fact that you already had one security incident, which is ultimately caused by you not being careful enough (which is the same as not following best practices) you need to review security for your FreeBSD machine also.

1. For that reason only I want to use ZFS so to take snapshots.
That will work, but is complicated.
If you have enough disk space and net, why not take separate rsyncs, and just keep them separate. In theory, you could turn dedup on in ZFS (then the extra rsync copies) will use very little space. But I've never used dedup on ZFS, and don't know how well it works (how much CPU and RAM it consumes, what the delays are, and so on).

3. I want to use Disk Encryption as disk is ESata. So How can I do it ?
Well, I want some icecream. But I know that it is not good for me, so I won't have it (pre-diabetes). Before you use full disk encryption, you need to explain the requirements for it. Why do you want it? What good thing would it do for you? You can use GELI, or if your disk hardware supports it, you can use SED = Self Encrypting Drives. Both are a hassle to set up and to operate, and are error-prone. You could lose your whole disk easily due to errors in key management. Speaking of key management: disk encryption is only as secure as the key management. If you store the key in the same machine that the disk is attached to, you probably have gained no security, since anyone who can take (remote or physical) control of one can get the other, and break in. Whole disk encryption only makes sense if you have a place to store the encryption key that is seriously secure (like a high-security system such as the old Kerberos servers in locked cages, or a human brain that is queried anytime you boot).

And as SirDice said above, whole disk encryption only helps against someone physically stealing the disk. If someone can get to your disk and take it, don't you have much bigger problems than the content of the disk? Like the fact that they could also hit you over the head with a stick?

4. So what permission mask I set so any local user on that FreeBSD machine can read/write it.
Why would you want that? You just made a giant hole in your security perimeter: once a bad actor gets into your FreeBSD machine, you have no protection against them any more. I like SirDice's idea from above better. I would like it even better if the FreeBSD machine were purely a disk backup machine, which normal users can't even get to at all: less security exposure.
 

the_snark

New Member

Reaction score: 2
Messages: 3

Your solution is to store backups on a VM hosted on the same machine with the victim as the host? No, this is a very bad solution. I don't know how HyperV works exactly but I assume that like any other hypervisor it loads data stored on a mounted drive. If your Windows host gets hit by ransomware, it could very well have the backup encrypted too.

If I were you, I would set up a server elsewhere and do roughly what you are proposing(using a tool to remotely back up). Storing it on the same machine is a mistake IMHO.
 

rufwoof

Active Member

Reaction score: 66
Messages: 204

I use a old single core celeron as my data server. All inbound ports are closed and it reverse sshfs mounts my desktop system whenever it detects it has been started. Only a single folder (and its sub-folders) is shared and I maintain multiple duplicate backups.

For intrusion detection (potential ransomware creep) I maintain mtree checksums. If the previously generated pretty much fully compares excepting the files I know have changed then I assume its clean of ransomware that might otherwise infect a multiple number of files. I based my mtree script on this web page https://calomel.org/ids_mtree.html but use a simpler script.

I also use a similar sort of mtree check on my desktop system, i.e. all bin/libs and I pre run a validation before applying any system updates to ensure everything looks ok, and then regenerate a new set of mtree checksums after applying system updates. So if a trojan or whatever is piggybacking on a bin/lib then the mtree checksum for that file will most likely be flagged as having been changed.

Personally I don't bother with backing up system files, only data and config .dot files ... as system files are easily replaced.
 
Top