is ZFS protected against "CRYPTO-WALL/LOCKER" ransomware virus infections?

[enemy85]

Good morning,
just wanted to report a situation I witnessed.
A person I know came in touch with this virus, that crypted all the files in his PC. I read that differrent versions of the virus are able to spread all over the partitions and the net folders.
Just wanted to know if ZFS is protected in case of a pc with automatic backups on a freenas system.
What do you think about it?

 

[cyberjock]

Your question is somewhat nonsensical.

ZFS is a filesystem. How would a file system be "protected" from a program that simply encrypts portions of file? Of course the question seems silly now, right?

But, you can use ZFS snapshots to help restore your data if you were to get hit with crypto-wall. Simply roll back the snapshot to prior to all of the encryption taking place. Since ZFS only stores the block changes, and crypto-wall only encrypts a small fraction of the files, the amount of data that will change is small, therefore the snapshots themselves are small.

If you search the forums you'll find that someone actually did precisely this to restore from crypto-wall/locker.

This, along with some other scenarios, is why I typically recommend doing daily snapshots and keeping them for at least a week for all zpools and all datasets. ;)

 

[enemy85]

The question was because i read the virus was able to spread across net even on servers, just if the hd is mapped.

Inviato dal mio LG-D855 utilizzando Tapatalk

 

[anodos]

The question was because i read the virus was able to spread across net even on servers, just if the hd is mapped.

Inviato dal mio LG-D855 utilizzando Tapatalk

The primary attack vectors for cryptowall are drive-by installs (web browsing) and spam emails. It will very happily encrypt files on mapped network drives, but not use them as an attack vector. I suppose in theory, someone could compromise an internal webserver and make it serve cryptowall malware, but then you'd have much bigger fish to fry. :)

To that end, protecting your computers from cryptolocker / cryptowall is not much different than protecting them against any other form of malware infection. My typical to-do list for cleaning up a small business includes the following:

• Take away local admin rights from regular users
• Uninstall java or flash unless needed for business purposes
• Verify that automatic updates are configured (for OS and applications)
• Install and configure EMET (if windows computers)
• Identify mission-critical computers and make sure that they are being backed up in a way that is not susceptible to network-based attacks
• If possible, configure WSUS and WDS (with standardized image of fresh windows install).

Then as time permits, start implementing the SANS Top 20. https://www.sans.org/critical-security-controls

 

[depasseg]

The question was because i read the virus was able to spread across net even on servers, just if the hd is mapped.

This my understanding as well. If an infected user has a freenas share mapped to a drive letter in Windows, then those files are at risk.

 

[enemy85]

This my understanding as well. If an infected user has a freenas share mapped to a drive letter in Windows, then those files are at risk.

But what if the pc has just an automated backup to the freenas? In that case only the transferred files would be compromised, but not all the nas right? It would not spread anymore into the nas? One would just roll back to a previous snapshot and everything would be ok right?

Inviato dal mio LG-D855 utilizzando Tapatalk

 

[anodos]

But what if the pc has just an automated backup to the freenas? In that case only the transferred files would be compromised, but not all the nas right? It would not spread anymore into the nas? One would just roll back to a previous snapshot and everything would be ok right?

Inviato dal mio LG-D855 utilizzando Tapatalk

Snapshots are read-only. You can just roll back, or copy the files out of a previous snapshot. It is important to catch the problem before your unaffected snapshots expire.

 

[depasseg]

But what if the pc has just an automated backup to the freenas? In that case only the transferred files would be compromised, but not all the nas right? It would not spread anymore into the nas? One would just roll back to a previous snapshot and everything would be ok right?

Inviato dal mio LG-D855 utilizzando Tapatalk

Correct.

 

[TXAG26]

I'm finally wading into snapshots and replication and was wondering what some best practices are to safeguard FreeNAS datasets against crypto-locker/ransomware type infections?

For example: someone has two FreeNAS Servers ----> FreeNAS-1 & FreeNAS-2.

Main dataset is on FreeNAS-1 = Tank1/Dataset1. Dataset1 is shared via CIFS and mapped to a drive letter in Windoze.
Second FreeNAS is FreeNAS-2 = Tank2/Dataset2.

FreeNAS-1 takes daily snapshots which are stored locally and replicated to FreeNAS-2, into Tank2/Dataset2/Dataset1.

Workstation-A becomes compromised with Cryptolocker and starts encrypting all of it's local HDD's and all network drives and locations (including all of the CIFS shared data on FreeNAS-1 (Tank1/Dataset1).

Questions:

(1) Will the local snapshots on FreeNAS-1 (Tank1/Dataset1) be "safe"? E.g. Cryptolocker hits on a Wednesday, but I have a snapshot from the day before (Tuesday). Can I simply "Rollback" the prior day's snapshot and be up and running again (minus any new data added within the last 24hrs)?

(2) What about the FreeNAS-1 snapshots that were replicated to FreeNAS-2 into Tank2/Dataset2/Dataset1? Is there any way these cryptolocker/ransomware infections can encrypt the replicated data in Tank2/Dataset2/Dataset1?

(3) The above-described setup was taken from how the FreeNAS Documentation page describes how to set up snapshots and replication. Are there changes that can be made to the replication target, i.e. "Pull" server (FreeNAS-2) to better fortify or harden it against these types of aggressive network threats?

 

[depasseg]

(1) Will the local snapshots on FreeNAS-1 (Tank1/Dataset1) be "safe"? E.g. Cryptolocker hits on a Wednesday, but I have a snapshot from the day before (Tuesday). Can I simply "Rollback" the prior day's snapshot and be up and running again (minus any new data added within the last 24hrs)?

The snapshots are safe. Yep, just roll back (and the last 24 hours of data will be lost in your example).

(2) What about the FreeNAS-1 snapshots that were replicated to FreeNAS-2 into Tank2/Dataset2/Dataset1? Is there any way these cryptolocker/ransomware infections can encrypt the replicated data in Tank2/Dataset2/Dataset1?

If you have shared and changed the dataset to not be read-only, then yes, the replication target could be vulnerable. But if you aren't sharing it, then you are ok.

(3) The above-described setup was taken from how the FreeNAS Documentation page describes how to set up snapshots and replication. Are there changes that can be made to the replication target, i.e. "Pull" server (FreeNAS-2) to better fortify or harden it against these types of aggressive network threats?

None that I'm aware of. By default all replicated datasets are readonly (some people manually change them to R/W). And by default they aren't shared.

 

[TXAG26]

Thanks @depasseg! I was hoping my understanding was correct. Thanks for the confirmation.

 

[ovizii]

The snapshots are safe. Yep, just roll back (and the last 24 hours of data will be lost in your example).

I think the most important part to realize is that snapshots are safe as they are read only (apparently even if accessed from a windows PC via "previous versions") while the windows snapshots aka shadow copies (previous versions) are not safe as most of these viruses simply delete them too if they are enabled to start with.

 

[anodos]

1. I think the most important part to realize is that snapshots are safe as they are read only (apparently even if accessed from a windows PC via "previous versions") while the windows snapshots aka shadow copies (previous versions) are not safe as most of these viruses simply delete them too if they are enabled to start with.

In a properly designed windows network, prevjous versions should not be affected by crypto-malware. Implement software restriction policies. Thet basically nip this sort of malware in the bud.

 

[ovizii]

https://nakedsecurity.sophos.com/2016/02/17/locky-ransomware-what-you-need-to-know/

Locky also removes any Volume Snapshot Service (VSS) files, also known as shadow copies, that you may have made.

So it seems previous versions are affected.

On the other hand, you are right, deletion only works with elevated user rights but my statement is still true: this won't work to delete zfs snapshots.

 

[anodos]

https://nakedsecurity.sophos.com/2016/02/17/locky-ransomware-what-you-need-to-know/

So it seems previous versions are affected.

On the other hand, you are right, deletion only works with elevated user rights but my statement is still true: this won't work to delete zfs snapshots.

I was reflecting on the idea of using ZFS snapshots as a mitigation strategy for malware. The reason why people are affected by this is because client computers are configured in a way that allows users to accidentally download and execute a malicious application. Yeah, it's better. You were lucky this time. Of course, a malware author could use the same techniques to compromise systems and exfiltrate data, and do all other sorts of nastiness. Some questions to ask yourself:

• Was the last hour of data was really important?
• Where are the weak points in my snapshot strategy?
• How much does downtime cost me or my company?

There are some fairly simple (and free) system hardening steps that can be performed that make these sorts of attacks much more difficult (or even impossible). See here:

• https://www.sans.org/security-resources/IAD_top_10_info_assurance_mitigations.pdf
• https://www.iad.gov/iad/library/reports/application-whitelisting-using-srp.cfm
• https://www.iad.gov/iad/library/ia-...on-whitelisting-using-microsoft-applocker.cfm

Just click through the https warnings. I wouldn't install the DoD root cert on my computer.

I'd say that the ability to easily edit local group policies is a definite win for the Pro editions of Windows. Especially for home users. In Windows 10, I believe MS decided that applocker was an 'enterprise-only' feature and so you'll have to stick to old-school SRP. I personally try to follow the above guidelines even on home computers (keeps things nice and stable).

 

[ovizii]

Thanks for the detailed reply and the links. I'll be reading them asap. It all makes sense, thanks for the details.

One thing to add is that the recent wave of these cryptolockers targets seemingly "normal" usage, so blocking it would be quite a burden to day-to-day office work. i.e. spreading through office documents and macros. Disabling macros company-wide in Office documents is quite a burden so one has to weigh advantages vs. disadvantages and possibly mitigate the attack vector by schooling users about the risks.

 

[anodos]

Thanks for the detailed reply and the links. I'll be reading them asap. It all makes sense, thanks for the details.

One thing to add is that the recent wave of these cryptolockers targets seemingly "normal" usage, so blocking it would be quite a burden to day-to-day office work. i.e. spreading through office documents and macros. Disabling macros company-wide in Office documents is quite a burden so one has to weigh advantages vs. disadvantages and possibly mitigate the attack vector by schooling users about the risks.

Schooling users doesn't really work. :D My experience is that macros in a company tend to be fairly static. People write them once and use them for ages after the author disappears from the workforce. They are mostly powered by wicca and employees are afraid to touch the actual code in the macro for fear of disrupting the magic circles contained therein.

If I need macros to work, I'd seriously look into setting up an internal CA / PKI for my company and sign those macros. Then set GPO to only allow signed macros. This may require writing / designing / documenting procedures for getting macros signed (especially 3rd party ones). An alternative and possibly acceptable solution is to only allow macros to execute from specific trusted paths (like \\freenas\share).

 

[Borja Marcos]

As long as the mechanism for ZFS snapshot manipulation is not available to the users/workstations, it's perfectly valid against crypto-malware, unless, of course, a specific strain can target FreeNAS using a specific security exploit, which would be unlikely.

If you are truly paranoid, make sure that your users do not have network access to the system administration, either the WWW interface or services such as ssh. If you are truly extra paranoid, set up a second server completely beyond the reach of the users and replicate the datasets. The second server is always a great idea anyway.

The key is: no matter what the malware can do to files, if it cannot manipulate ZFS snapshots, whenever you create a ZFS snapshot it becomes engraved in stone from the point of view of the users.

 

[joeschmuck]

I've seen Ransom Ware first hand on one of my employees computers. He has no idea how he got it, clicked on the wrong thing I suspect, and it only encrypted the files under "My Documents". He lost several months of data because he was not making routine backups like he should have been doing. The malicious code never spread to other shared drives thankfully. I can see the need for snapshots but there is no excuse for not using due diligence to head off these kinds of issues.

 

[anodos]

If you are truly paranoid, make sure that your users do not have network access to the system administration, either the WWW interface or services such as ssh. If you are truly extra paranoid, set up a second server completely beyond the reach of the users and replicate the datasets.

I'd say that isolated network security zones are best-practice rather than paranoia. :D

I personally prefer physically isolating management interfaces on a separate network from users, and set up a hardware KVM to switch between networks (among other things, this helps keep people from checking email on the admin workstation). A cheap gigabit switch, a hardware KVM, and a spare desktop computer are a fairly cheap buy-in / quick security win.