We have a small workgroup network of 10 PCs and an RN-424 serving shared data to all the PCs. All the PCs do image backups to a Share on the NAS as well as local image backups to s 2nd harddrive on each PC.
About a month ago we installed a "work from home" Chrome plugin that logged into a local PC through port 443 which we opened on our Cisco router. Two days later, that PC suffered a ransomware attack that encrypted most of the data files on the local machine, including the local image backups.
I believe I interupted the attack before it finished as a few local files were not encrypted that seemed to be vulnerable. A very few files on other machines were also infected through shortcut links.
We closed port 443, stopped using the remote software and restored the infected computer from an image backup that was on the NAS.
My question: What do I need to do to ensure that the NAS is protected from another Ransomware attack through one of our PCs.? Are there steps I can take to make sure the NAS is not vulnerable?
I am not aware of any ransomware that can attack a Linux based NAS directly. BUT, ransomware on a PC that uses the NAS can encrypt the data on the NAS using that PC's access. There are some things you can do to reduce it's chances of doing so:
Limit each users' access as much as practical to reduce the scope the ransomware will have on the NAS. If it is only used for backup, don't mount any NAS share as a drive on any PC or keep a folder on the NAS open. If possible, don't access the NAS directly from Windows Explorer at all. Definately don't save NAS credentials on the PC (don't check the "remember" box). Let the backup software directly access the share, if it can do that. If it can use a protcol other than SMB, even better (though I know of no decent PC backup software that does).. and then shut down SMB completely on the NAS. If you can put the NAS on a time schedule, that may give you time to intervene before it's even on, but I wouldn't count on this being especially effective.
Once the ransomware has done it's deed, the backup software may stop working. But in case it doesn't, insure your backup keeps at least one old copy on the NAS and that the NAS has snapshots enabled (custom gives you better control than "Smart") and enough space that all snapshots won't be deleted to make way for the next backup, which may be huge because the encrypted files are "new". Dont have "allow snapshot access" checked, so they are invisible to the PC.
If you have a backup NAS for this NAS (and you may not if it's only PC backups already), don't enable SMB on the backup computer -- use rsync only. Don't use "remove files deleted on source" (though that can get unruly if you don't have a process for deleting old files and have a lot of churn). Snapsots and a time schedule for this NAS may also help some in the same way as on the primary, BTW, a way to implement old file deletion on the NAS without an external process is to have one periodic backup that does delete files deleted on source. But you can get unlucky and have that one occur at the wrong time.
I think I understand your suggestion, but as well as backup our ReadyNAS is used for PC users to access shared files, your suggestion seems to be "don't do that" ?
I have been thinking about anti-ransomware precautions along these lines:
For backups, no access to backup shares from network PC's.
For shared files, backup frequently to a different share on the NAS, which also has no access from network PC's. (Data penalty here, but user files on our NAS are only a few 100's of GB)
I am not a ReadyNAS expert by any means, so would welcome comments on this as a strategy.
For shared files, backup frequently to a different share on the NAS, which also has no access from network PC's. (Data penalty here, but user files on our NAS are only a few 100's of GB)
I'd like to repeat the suggestion on using btrfs snapshots as part of your mitigation strategy. When the malware rewrites the files (encrypting them, and optionally scrambling their names), the original files will remain in the snapshots. That is more efficient than your frequent backup idea, and also should eliminate the need to stop the backups before the encrypted files poison the backup store. It would also give you the most recent copy of the unencrypted files.
If you are new to NAS, you should probably research how btrfs snapshots work generally. They also provide some ability to roll back to older file versions in response to user errors.
Another mitigation (which I use myself) is to deploy a backup NAS that uses rsync, and doesn't have SMB or other file sharing protocols enabled at all. This NAS runs on a power schedule, so it isn't on very often. This reduces the chance of the malware reaching it (especially in the scenario where I see the problem in time to simply disconnect that NAS from my network).
Cloud backup is another potential mitigation - many do have some ability to detect malware infections, and prevent them from spreading to the cloud backups. In some cases they offer unlimited retention, which would ensure that you can get back to uncorrupted files. And you might want cloud backup for disaster recovery anyway.
Looks like I need a few more TB to better utilize snapshots on our main server RN424. We do have two older NASs which we use for backup, a local NV+, and a remote RN104. Looks like I need to isolate those backups better and limit them to using rsync.
1. Is there a way to expand a 4 disk XRaid to larger but only 3 disks configuration? I understand a full backup to another device, add 3 new disks, restore from backup. But that presents some risk and takes a lot of time during which the NAS is mostly offline to users. Is there another option?
2. Following Stephen's idea of backing up user PC images to a non-accessible share sounds like a good idea. I'm wondering if an attached USB or eSata drive could be used in the same way. Would it have to be formated as btrfs or could it be NTFS so the enclosure could be moved to a local PC in order to restore a backup image?
3. Can 4 disks from an RN424 be moved to an RN104 successfuly if they are both using the same, latest firmware? That would eliminate having to do a full backup.
4. Are Read-Only NAS shares protected from a Ransomware encryption attack from a hacked, local PC that has mapped drived to that share with saved credentials?
Thanks.
Model: RN424|ReadyNAS 424 – High-performance Business Data Storage - 4-Bay
1. I posted a very complicated procedure for reducing the number of drives in an array. If you have sufficient Linux skills, it's here: Reducing-RAID-size-removing-drives-WITHOUT-DATA-LOSS-is-possible. That doesn't deal with multiple layers due to expansion, so I recommend reducing to 3 drives then replacing with larger ones if you go this route. Because it involves a lot of messing with MDADM and BTRFS as well as re-boots, doing it while files are being accessed is probably not a good idea. And honestly, if you have good backup, starting fresh is way better.
2. USB drives can be FAT, NTFS, or EXT (Linux native), they are never BTRFS. EXT drivers are available for Windows, but using NTFS is usually best unless the conversion of Linux permissions to NTFS don't work well for you. That allows you to access the drive directly from Windows.
3. Yes. The only limitation is installed apps. If you use any (and I suspect you don't), uninstall on the Intel system and re-install on the ARM one. Same limitation going the other way, BTW.
4. They should be, and I have no reason to doubt they are. Exception may be if that user has permission to change the share to read/write.
If you are new to NAS, you should probably research how btrfs snapshots work generally. They also provide some ability to roll back to older file versions in response to user errors.
No, not new to ReadyNAS but not an expert (yet..)
Regarding the use of snapshots...
We used to use snapshots, but found it made searching on the user shares very lengthy, and the results confusing as Windows would find all the versions of a given file.
Also just wondering... presumably the snapshot function would create a "delta" roughly equal to the size of the original file if malware tried to encrypt it. Unless a lot of space is reserved, what would happen if the drive ran out of space while malware was attempting to encrypt the contents: would the malware be brought to a halt (hopefully) or would btrfs give up on the snapshot totally, (hopefully not) or start deleting older snapshots (sounds plausible, at least for auto-created).
Are you aware of any studies carried out on this? Or are the answers obvious?
Meanwhile I am trying to work out a way to block users accessing files on other PC's, but let the ReadyNAS access the files for backup.
presumably the snapshot function would create a "delta" roughly equal to the size of the original file if malware tried to encrypt it.
Yes. All writes to the original file result in new blocks being allocated to the main copy, and the older block is retained in any snapshots. That includes malware encryption of the files.
Unless a lot of space is reserved, what would happen if the drive ran out of space while malware was attempting to encrypt the contents: would the malware be brought to a halt (hopefully) or would btrfs give up on the snapshot totally, (hopefully not) or start deleting older snapshots (sounds plausible, at least for auto-created).
The NAS will start deleting the snapshots automatically when the volume gets too full (~90%). There is a threshold for that you could set in the Admin Web UI.
As I suggested earlier, you'd want to keep the volume no more than 40% full if you want to use this strategy. Then if the malware rewrites every file, the space usage would double to 80%. Then there would still be 20% margin.
There is no study on this that I know of, but malware could defeat this approach simply by encrypting each file a second time. I guess there could be some malware that does this.
We used to use snapshots, but found it made searching on the user shares very lengthy, and the results confusing as Windows would find all the versions of a given file.
I don't allow the NAS to make the files visible in the share. I do enable show previous versions in Windows though.
Our first step, based on all the great information offered in this thread, is to expand the NAS storage from 4 x 3TB, XRaid, to 3 x 8TB, XRaid with 1 x 8TB Global Spare. We'll be putting the 4 x 3TB disks into our RN104 and setting up the RN424 with the new disks. Should have the data transferred to the RN424 over the weekend.
1. I find little info on setting up a Global Spare and how it would be used in practice to either replace a failing(ed) disk or to expand the capacity of the NAS at a later time. Can anyone elucidate? In the past, we've always just kept an extra disk on hand for any emergency failure and upgraded the entire array to increase capacity as needed. I'm thinking the Golbal Spare is a better route. Yes?
2. Our second effort will be to backup the local PC image backups to a non accessible share on a NTSF USB enclosure attached to the NAS. This should be safe from a Ransomware attack. The drive will also be easy to move to a local PC in order to restore an image. BTW - we use Macrium Reflect to create the PC images per defined schedules.
Any flaws in our thinking? Thanks.
Model: RN424|ReadyNAS 424 – High-performance Business Data Storage - 4-Bay
If the time period between failure and drive replacemnt could be long, then a global spare can be useful, since it will become the replacement immediatly upon failure.
If you are l;ikely to be able to manually swap the drive quickly after a fialure, there are a couple dis-advantages of using a global spare. First is that the dirve will accumulate hours toward eventual failure. manybe not as badly as one constantly moving the hears for ereads & writes, but wera nontheless. The other id that the sync of the spare will occur before you have a chance to make sure your other drives look healthy and the backup is in order in case another fails.
I've never added a global spare to expand an array, so can't help you there.
I've never added a global spare to expand an array, so can't help you there.
I don't use them either.
If you generally have access to the site, I think you are better off with a spare that isn't inserted into the NAS. But right now, a global spare could be good thing.
