Premissions and CryptoLocker

The simplest way to protect the NAS shares is not to map them as network drives. Create shortcuts instead. Blocking write access might also work.
http://www.bleepingcomputer.com/virus-r ... nformation

Thank you for your reply.

In a commercial environment with task oriented workers with low technology knowledge and rudimentary skills, mapped drives are the only practical approach I have encountered. In a larger environment with actual Domains and group policies, more could be done but in the peer network environment we need to live with mapped drives.

You are correct, blocking write access will work for thwarting the CryptoLocker process. What I am seeking is some guidelines or advice on how to accomplish that task for the actual backup directory/files. An example might be running a batch file that changes permissions during the backup process and then changes them back after the backup has been completed.

This forum is filled with knowledge, I am hoping someone can provide me guidance.

Are you using PC backup tools, or Frontview backup?

We have standardized on Genie Backup Manager -- http://www.genie9.com/Default.aspx

Product is good, uses Microsoft Shadow Copy capability, and reasonably priced for the mid-market consumer with more modest needs. We typically recommend against cloud based backup because the Internet speed (rural America) is too slow and often limited by ISP.

The backup program runs on the 'fastest' workstation and in turn backs up critical files and workstation related information nightly. The backup is encrypted and directed to the fastest workstation secondary drive banks in addition to the NAS.

Backup manager seems to support ftp/ftps. So you could enable ftps to the backup share, and limit SMB access to read-only.

SMB access is essential for most task orient functions. Disabling SMB access is not practical with task oriented workers with low technology knowledge and rudimentary skills. The firm needs to keep making and selling their widgets. This stuff is to be a tool to help, not an impediment.

******** Below is a short discussion of the issue and a possible work-around **************

CyberLocker and ReadyNAS Setup

CyberLocker malware is currently causing substantial issues with client/server configurations. Generally speaking, CyberLocker
• Currently only infects Windows based systems with CIFS type networks.
• Runs the ‘chain’ of available drives, both locally and mapped drives, looking for documents that it then encrypts using a RSA 256 bit algorithm.
• Because the use of mapped drives is often the only practical manner of sharing information on a network most networks are vulnerable to this attack.
• All popular documents are encrypted based on their respective file extension – music, pictures, Office documents (Word, Excel, Powerpoint, etc.), most any document that contains user created content.
• Apparently the malware process avoids unknown document types in attempt to make the system appear functional until most/all of the user documents are encrypted.
• The system still boots and has web access – that is how the user is able to pay the ransom.
• After sufficient numbers of documents have been encrypted the user is informed that the event has occurred via prominent screen display and they can either pay a ransom for the RSA key to unencrypt them or leave them encrypted.
• Early versions of the malware gave an absolute 72 hour deadline prior to destroying the key so that no documents could be recovered. Recent antidotal discussions have indicated that there is more flexibility in the timeframe but the cost of the recovery key after the initial 72 hour timeframe is escalated approximately six-fold.
• Actual removal of the malware is fairly straight-forward and most AV tools in use can do it readily. The issue is how to recover the encrypted data.

By all standards this is very disruptive but from the standpoint of the malware infecting organization, it is effective as the only recourse is to pay them or loose documents.

If the user has good backup then the high probability is that that backup will remain unencrypted. That said, it is only a matter of time before the malware recognizes these document types and in turn encrypts them.

If the backup was removed from the environment, either physically or logically, then its contents are safe from encryption.

Following up on that alternative is the idea to ‘hide’ the backup files such that the malware cannot locate them.

The ReadyNAS device allows the creation of a share in the traditional manner using RAIDar but if the CIFS “Hide this share when a user browses the ReadyNAS for available shares” option box is checked box then the data is essentially hidden from the Windows environment. Quoting from the option description “If enabled, users will not see the share unless they explicitly specify the share name in the browse path. Please note that enabling this option will disable access to the share from other file protocols.”
• This is about as good as it gets from the perspective of the CyperLocker defense. The malware must know the ReadyNAS device name and also know the specific directory name containing the data that is being hidden.
• There is no mapped drive to lead the malware to the data.
• The data can remain mounted online and available for the knowledgeable individual to access.
• Drive mapping from the Windows environment is restricted to those individuals who have access to and need to know about the backup data location use UNC naming conventions.
• Most backup software is able to deal with UNC naming conventions for the purposes of data storage and retrieval.
Depending on the capability of the backup software used, it may be possible to set permission level authority on the actual process doing the backup in addition to other types of restrictions. The Windows security model has adequate capabilities, it is a function of the backup software to use those capabilities.

Can't you give write permission only to one user (the backup-operator or administrator user under whose account the backup program runs) and mount the network drive read-only for everyone else?

That is a good idea in a perfect world. That said it is a function of the OS version and also the capability of the backup software.

Unfortunately in a peer level network and with low to mid-range backup software it may not be possible. I am still investigating the Genie product regarding permissions and ability to isolate the process to a particular user account. I will update in the future when I have that answer.

I wasn't suggesting that you disable SMB. I was suggesting that you could use FTPS for the backup, giving it write permissions, but lock down the SMB access to the folder to read-only - which was your original ask.

Though based on your posting pattern, I am not sure that you actually want advice.

I did not understand your notion but with your explanation it is a good idea that makes sense. That said, the workstation backup software is the tail that wags this dog. The NAS is the repository for the backup data that both resides on the NAS itself and from the workstations. I can establish a nightly backup of the 'public' NAS data to a 'hidden' area on the same or different NAS. As I understand the backup capability of the ReadyNAS it is not possible for the ReadyNAS to 'reach out' to the various workstation shares and grab their data. The workstation backup software has to initiate that process and it does not have any FTP client capability.

Possibly I do not understand your suggestion.

I am still checking with the workstation backup software supplier to see if they will support some version of UNC network addresing.