By DSCoe - 20 March 2016 11:44 PM
To protect one's backups against ransom-ware such as 'Locky', one must be careful to not have read/write access to the backup storage location with their main user account. (The one most likely to be infected.) Therefore, a separate set of credentials should be used by Reflect that allows R/W access for backup purposes.
Trying to implement this policy with Reflect however, means backups cannot be manually run from the main user account, since, by definition, that user really should not have R/W access to the destination, but Reflect requires this. On the other hand, with a scheduled backup using the Windows task scheduler, one can run Reflect under an administrative user account that has access to the source and destination files, however, I have found Reflect has one annoying idiosyncrasy:
If the local PC credentials used to run a scheduled task are valid, but only have ReadOnly privileges on the destination, then Reflect WILL NOT try any other credentials in its "Network logon credentials for server shares" configuration list (NLCFSS) and, as a result, the backup fails. So, you have to be careful to run the task with credentials that EITHER have full R/W at both ends OR are invalid for the destination in order to force Reflect to check its NLCFSS list for an alternate set of credentials. This is a fact that Macrium does not explain in their documentation and which cost me several hours of head-pounding!
The obvious solution (IMHO) would be to have the Reflect backup definition file contain credentials to be used for accessing the destination. In this way, both manual and scheduled backups would work in all cases. This is exactly how many other backup programs I have used over the years have worked. Alternately, Reflect could always use its NLCFSS list for both manual as well as scheduled backups. (and never attempt to connect to network shares with the credentials being used to run Reflect)
I hope Macrium will consider fixing this in a future release.
Thanks for reading,
D.Coe
|
By Drac144 - 21 March 2016 6:38 PM
The obvious solution to me, is what I do. I copy my backups to an external drive (for me once a week, but more or less often depending on your situation). The external drive is only connected to the computer when I am making the copies so there is no way for the files to get encrypted.
Of course, my backups are relatively small so the copy operation takes around 30 minutes (via USB 3).
I do not know how the encryption programs work, but I would think that they would ignore such things as permissions and get every file on the disk. This could be done using low level file access. In that case the account would not matter. What would matter is whether the drive containing the backups can be detected by the malware. An offline drive is not accessible so it is the safest option.
|
By johndoe89 - 23 March 2016 10:56 AM
I agree with D.Coe. This issue was driving me nuts as well the other day, because I couldn't understand why Reflect wouldn't use the network credential I had entered in the default options.
Even though Windows doesn't like creating multiple connections to the same share using different credentials, that can easily be worked around by using e.g. the server name for one connection (\\SERVER\share\) and the IP address for the other (\\192.168.1.1\share\).
I do not know how the encryption programs work, but I would think that they would ignore such things as permissions and get every file on the disk. This could be done using low level file access. In that case the account would not matter. What would matter is whether the drive containing the backups can be detected by the malware. An offline drive is not accessible so it is the safest option.
Of course, an offline USB drive is a good protection against ransom-ware ... at least until you connect it to an infected PC.
But the rest of the quote doesn't make a lot of sense. When you backup to an external NAS, and the share on the NAS only has write permissions for a certain user account, the ransom-ware has no way to "ignore such things as permissions and get every file on the disk". It would have to connect to that share using the write-enabled user credentials. There is no "low level file access" to network shares.
|
By Drac144 - 23 March 2016 8:30 PM
It is safe to connect an offline drive to an infected PC as long as the system is not running the Windows from that drive. So booting into a rescue media and using IT to run the restore is perfectly safe. And if a drive is already infected with ransomware it would be obvious so why would one connect the drive to the infected system while it is booted into Windows?
Again. I do not know how malware works. However all the Windows protections are in the registry which is on the LOCAL computer. All the malware has to do is change the registry settings for the user and it can get to the remote NAS without having to use low level writes directly to the NAS. In other words, use low level writes to make the current user an admin, then use that enhanced ability to access the NAS. Malware authors are pretty smart and Windows, is, well, not so smart. If that was not true, Malware would not be able to do all the things it can do.
All I am saying is that it is very possible that someone can figure out a way around any barrier created by the OS. If that has not already been done for the above scenario, it might be done next month. The ONLY safe protection for a drive is not having it connected to the computer.
|
By smk - 24 March 2016 11:33 PM
+x[quote]The obvious solution (IMHO) would be to have the Reflect backup definition file contain credentials to be used for accessing the destination. In this way, both manual and scheduled backups would work in all cases.
I was going to post the exact same request as I am looking at this issue right now for my backups as I have one home server which gets backups from all our machines. I am going to try a workaround of launching under with user account impersonation but this could easily be solved in Reflect itself as mentioned above.
|
By johndoe89 - 25 March 2016 11:20 AM
+xIt is safe to connect an offline drive to an infected PC as long as the system is not running the Windows from that drive. So booting into a rescue media and using IT to run the restore is perfectly safe. And if a drive is already infected with ransomware it would be obvious so why would one connect the drive to the infected system while it is booted into Windows? Again. I do not know how malware works. However all the Windows protections are in the registry which is on the LOCAL computer. All the malware has to do is change the registry settings for the user and it can get to the remote NAS without having to use low level writes directly to the NAS. In other words, use low level writes to make the current user an admin, then use that enhanced ability to access the NAS. Malware authors are pretty smart and Windows, is, well, not so smart. If that was not true, Malware would not be able to do all the things it can do. All I am saying is that it is very possible that someone can figure out a way around any barrier created by the OS. If that has not already been done for the above scenario, it might be done next month. The ONLY safe protection for a drive is not having it connected to the computer.
You know, you seem to have some very definitive opinions despite admitting to not knowing "how malware works". Of course that's perfectly fine ... everyone gets to do things their own way.
However, to avoid any misconceptions that might arise by reading your post:- Let's say your PC is infected with ransom-ware on Monday, and it starts doing its thing silently in the background. On Tuesday, before you're aware of the infection, you get out your USB drive and hook it up to the computer to do your backups. That will almost certainly be the death of all backups saved on that USB drive, since the trojan would recognize this new drive and start encrypting all its data.
- Of course, malware can root around in the local Windows registry as much as it likes, promoting users to Administrator and whatnot. But that doesn't mean anything to a (properly secured) NAS. A Windows Administrator doesn't automatically get any privileges on the NAS. To be able to write on network shares, they would have to use credentials that are known to the NAS and have write permissions on its shares.
So the "barriers" the ransomware would have to overcome in order to destroy backups saved on a network share (in the way being discussed here) are not put up by the (compromised) Windows OS, but by the (presumably clean) OS of the NAS. To circumvent those barriers, the malware would have to extract the proper credentials from whereever the backup tool stores them. Not necessarily an impossible task, but substantially more diffcult than simply employing the currently logged in user account.
But, to get back on point: Reflect is - at the moment - making it unneccessarily hard to secure remote backups against ransom-ware (and other things, like simple user error!).That should be remedied.
|
By Drac144 - 25 March 2016 8:53 PM
OK, I did say I did not know how ransomware works. That does NOT mean I do not know anything about it.
Here is a link specific to NAS drives. While this is ONE case of a NAS being affected, it is not the only case.
http://www.anandtech.com/show/8337/synology-advises-users-of-synolocker-ransomware
Here is the Synology solution: https://www.synology.com/en-global/solution/ransomware
Of course the best way to prevent infection is to keep all software and drivers up to date, avoid questionable websites, do not click on email attachments that are not from trusted sources, and, of course, keep frequent backups in a safe (not online) place.
|
By Stephen - 1 April 2016 1:33 PM
Hi D.Coe,
Thank you for your suggestion, I have raised a feature request for the development team to evaluate.
You may also be interested in this thread discussing ransomware and how to prevent an infection.
http://forum.macrium.com/FindPost6600.aspx
|
By Seekforever - 1 April 2016 6:26 PM
In the good old days we used to just push the physical "write-protect" switch on real disk and tape drives when we wanted to ensure nothing would write to the device.
I'm effectively doing the same thing with an old HD in a caddy, I turn it on (the PC sees it start up) and run my file incremental backup routine) then I switch it off. Of course I have the advantage that nothing needs to access this drive so it doesn't have to be live all the time.
|
By smk - 30 April 2016 9:15 AM
+xThank you for your suggestion, I have raised a feature request for the development team to evaluate.
Any news on whether this will happen and if so time frame?
I regularly see malware hitting some of our home email addresses and am planning changes to increase protection of backups on our home server. However I don't want to do all that only to find I could have done it slightly differently if this change gets implemented.
Thanks.
|
By Drac144 - 30 April 2016 8:51 PM
Just to put things in perspective, most (if not all) ransom programs do NOT encrypt image files (of course this could change at any time). So even if you do get infected, it is likely your backups will still be available to do a restore - even if they are not kept offline. Remember that MOST people do not back up their computers frequently so even if they had a backup it would not be very relevant.
This article may be of some interest (and may explain why Arvy is so prolific here): https://www.backblaze.com/blog/seniors-are-the-kings-of-data-backup/
|
By Nick - 30 April 2016 11:03 PM
@smk, @DSCoe, @johndoe89
Thanks for posting.
An update for backups to use the Macrium Reflect saved network credentials if the current access is read only will be added to the next update. This is scheduled to be released in the next week.
Hope this helps
|
By smk - 26 May 2016 1:38 PM
It's great this is now done.
However one issue though is after the backup a "net use" still shows the connection used for the backup using the specific credentials. Is this expected?
As Windows has a limitation on one set of credentials per remote server share connection (other than with alternate name/IP address approaches) leaving a connection can be troublesome for a server with other shares.
|
By Nick - 26 May 2016 6:53 PM
@smk
Thanks for posting.
However one issue though is after the backup a "net use" still shows the connection used for the backup using the specific credentials. Is this expected?
If your share is hosted on Windows then the connection persistence and auto disconnection is controlled by Windows. You can use the following command to set the auto disconnect time by running it in an elevated command prompt on the PC hosting the share:
net config server /autodisconnect:n
Where 'n' is the number of idle minutes before disconnection. The default value for Windows is 15 minutes, setting '-1' will disable auto disconnection and '0' will disconnect after a few seconds.
Note: Running 'net use' on the client to see if the share is connected may cause a connection attempt and restart the counter.
An alternative is for Macrium Reflect to disconnect shares that it connects to and authenticates when the backup starts. Unfortunately, if Macrium Reflect auto disconnects the share after the backup then it will prevent scripts or other applications from succeeding that require full access to the path directly after the backup completes, however, we intend to make this option configurable and include it in the next update.
|
By piran - 3 August 2016 10:34 PM
Some of the Synology NAS boxes have hardware encryption. I remotely mount/unmount the appropriate bundle of HDDs just before scheduling (eg as admin). Yes, the REFLECT user account needs R/W rights but not enough for mounting. It's akin to what I used to do physically with the toaster-style individual single HDD engineering cage but nowadays the NAS box has a bunch more drives. Admin is only used long enough to mount and, REFLECT should only be active on schedule. Use of the newly provided REFLECT config: <net config server /autodisconnect:0> will also reduce the [no pun intended] window of opportunity for the Windows net shares that might be (mis)used by whatever ransomware. My workstation also has two NICs - one for the intranet (which includes the NAS) and one for direct connection workstation to NAS's other NIC using a different subnet. Hopefully complex enough to keep out ransomware...
|
By DSCoe - 8 August 2017 4:11 AM
I'm very sorry for my extremely late (by a full year!) reply, but better late than never they say...
I would like to thank Stephen and the other folks at Macrium for instituting the fix I (and several others) requested. It's great to know that you are listening!
I have tried it and it works as advertised.
Cheers! - DSCoe
|
|