This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I am requesting the community to evaluate and criticize this approach to CyberLocker
We are basically a Windows shop and we are scared to death about the CyperLocker virus.
From what I read, it is almost impossible to detect the virus/malware and it infects lots of systems because workers are curious, naive, or dumb. Our judgement is that we will get hit eventually.
Mapped drives are the essence of our internal networking strategy for all of our locations. All of the mapped drives in the Windows workstations point to shares on the ReadyNAS device. As far as I can tell we are perfect candidates for CyberLocker to scramble our data.
StephenB provided a good idea in a prior 2013 exchange on this topic -- use file read only folder permissions to repel CyberLocker changes for the backup folders which are located on a local workstation. It was a great idea and we have been using that approach for the past two years. Now, the trade press is discussing how the malware has evolved -- one reviewer said it looked like a software business with revisions and point releases and a collections department. As the capability gets better storage of backups within the workstation environment seems less appropriate since changing file permissions is fairly trivial in the Windows environment.
In order to avoid the issue we are now considering upgrading our ReadyNAS units to include another set of disks (RAID 1) and using them for backup instead of having the backup stored on a robust workstation. The idea is to use the ReadyNAS backup capability to copy the data to non-mapped areas that are created with the “hide directory” option enabled -- a CIFS designation. This would establish a set of a set of hidden folders in the Windows environment that still could be accessed if the precise device/folder UNC path was specified in File Explorer.
We would use the ReadyNAS backup capability for night-time backup. In case of infection by CyberLocker we would have a recent backup that is not encrypted.
An additional precaution is to create seven (or more) ReadyNAS backup jobs – one for each day of the week. That way we would have the essential equivalent of a seven day backup cycle in case the most recent backup fails.
Any comments would be appreciated.
BTW, we have implemented off-site storage for the case of theft or destruction of the NAS unit. That component of our backup is not considered in this discussion.
Let's summarize this thread. I will open a new thread regarding the Netgear implementation/use of the rsync command.
CryptoLocker and its variants are ‘in the wild’ and using an infected PC to encrypt most files as well as the file and directory names. The malware chases all local drives and any mapped drives as it encrypts the data. Once encrypted users are told to pay a ransom of between $700 and $70,000 dollars in bitcoins or never recover their data.
Currently the only way to feasibly recover the data is either pay a ransom or restore the data from backup files. The backup files should be on a ReadyNAS share that does not have SMB access enabled so the malware cannot detect the data – it is not part of a mapped drive.
The intention is to have backup of various Windows files and directories on a ReadyNAS that are the object of drive mapping in local PC network.
The backup share should be established without SMB protocol enabled. Turn SMB off in the Network Access tab in the file properties
The rsync protocol should be enabled and Read/Write access should be allowed. Use the Network Access tab in the file properties.
Now there is a location for file backups that will not be discovered by CryptoLocker.
The next step is to establish a backup job(s) to copy the ‘live’ mapped data to the essentially hidden data area.
CryptoLocker was shut down in the June 2014, and the encryption key was broken in August 2014 (https://en.wikipedia.org/wiki/CryptoLocker). Though of course malware generally is getting more and more sophisticated over time.
Since hidden files and folders can easily be seen in windows (just by choosing the right explorer option), it might not be a very effective countermeasure by itself. Though it does no harm, and could be helpful.
I think you can do better though - keeping the 7 daily shares completely inaccessible from windows (SMB turned off, at least most of the time).
I'm thinking that you back up the PCs to share X daily (say at 0100). Share X is hidden SMB. Then create 7 backup jobs (one for each day of the week) in frontview. Have them start after the daily PC backup normally finishes - say 1300. Each would use incremental rsync. On Monday, back up X to the Monday share; on Tuesday back up X to the Tuesday share, etc.
Thanks for the response. I am looking for ideas and I am not anything close to a UNIX expert and have limited understanding – do not laugh at my questions.
Here is some more of my thinking…
CryptoLocker is running on the Windows workstations or servers.
It only knows about the ReadyNAS file data because it was ‘introduced’ to the device location by drive mapping.
Unlike the predecessor versions it also encrypts directory and file names so confusion reigns supreme during the initial problem evaluation.
The hidden files on The ReadyNAS need to be specifically addressed by a precise UNC address. Guessing would be equivalent of a brute force attack and probably unlikely for this malware..
The malware has to go for the low hanging fruit so sophistication probably is not embedded in the code at this time. Doing packet inspection and other techniques is probably not part of its operation.
You said disable SMB for these hidden shares most of the time. That sounds like a great idea since those shares would not need to be accessed except in case of an emergency and the setting could be turned on at that time. In its place would I just use RSYNC as the file protocol??
You described the backup as I envisioned it – multiple days each independent of the other using the ReadyNAS backup capability – disk to disk operation.in our case within the same cabinet.
Just a point of clarification CryptoLocker has not been shut down; Version 3 is now infecting client systems. The June 2014 ‘capture’ was good but it is now history with a substantially more robust version with different distribution. The Wikipedia article is outdated. Additionally the payments now range from $700 to over $70,000 all payable in bitcoins.
Thanks for clarifying the cryptolocker info. As your links point out there is other ransomware too.
Bains wrote:
You said disable SMB for these hidden shares most of the time. That sounds like a great idea since those shares would not need to be accessed except in case of an emergency and the setting could be turned on at that time. In its place would I just use RSYNC as the file protocol??
You described the backup as I envisioned it – multiple days each independent of the other using the ReadyNAS backup capability – disk to disk operation.in our case within the same cabinet.
Yes, I was thinking there'd be one hidden SMB share used as the windows backup destination, and 7 rsync protocol shares (perhaps with https also enabled, so you check on them easily). You'd enable SMB either to audit them, or to restore data - otherwise it would be off.
Note to do this you'd need to set up the rsync backup jobs' source as an rsync server, using 127.0.0.1 as the source IP address.
What you did was choose local for both the source and the destination. That uses straight linux copy - which is not incremental.
If the backup share is large (with most stuff not changing) then you want incremental backup - which means rsync.
Incremental requires that you choose "remote" for either the source or destination. Since you want to isolate the destination (which is the one you enabled rsync for), then make the destination remote.
Then select "rsync server" as the protocol for the remote machine, and use 127.0.0.1 as the host IP address.
The backup source is on the left of the screen, the backup destination is shown on the right.
Set the backup source to "local" and the backup destination to "remote". It should already be defaulted to that.
On the left you should see one field - Location: - with "browse" next to it. On the right you should see 5 fields (host, protocol, share, user, password).
Choose the SMB local share on the left, by clicking on the "browse" button.
On the right, set
Host: 127.0.0.1
Protocol: remote rsync server
Share: destination-share-name
User: admin
Password: NAS admin password.
There's a test connection button you can try to confirm the connection.
Click "next" and you will be able to set a schedule, and some other options. Disable the schedule (clearing the "enable" button on the top left) and leave the other options for now. All these can be changed later.
Then click "finish".
After the job is added to the list, you can click on it, and choose "settings". On the advanced tab there is an option to "remove deleted files on target", which you should set.
Then try running the job. The backup should create a subfolder in the target share with the same name as the source share, and back up all the files to that subfolder. If you don't want the output in a subfolder, edit the backup settings again. Choose the "source" tab and put a / in the path field, then click apply.
Everybody has been incredibly helpful. My seemingly ‘dumb’ questions undoubtably have to do with my knowledge versus a different LINUX environment and heritage.
Windows centric folks may have some difficulty in understanding the ReadyNAS backup options – at least this Windows centric fellow. This short discussion will outline my confusion. Any help would be very useful.
Typically in the Windows world (business system environment) everyone is familiar with the concept of a Backup Job and the notion that backups come in ‘sets’ that represent the initial backup and then a form of differential or incremental backup from the base set. A set can span multiple backup events (either differential or incremental) and then the process cycles around to start again. Typically there is a notion of several backup sets being saved so there is a reasonable timeframe for data recovery of files. This cycle of removing older sets is typically referred to a purging.
The ReadyNAS firmware documentation uses the term ‘protocol’ regarding the backup process. I believe that refers to the transport level methods and not the backup selection process of files to be transported. Is that true??
Against that background here are the questions that puzzle me – others may be confused as well.
Windows/NAS(Timestamp) – apparently refers to a backup protocol independent of the transport method. It relates to incremental backups. What is the selection algorithm for a file to be in the incremental backup set? Is there only one incremental backup produced and older incremental backups are then overwritten? StephenB has indicated that this is a ‘straight up’ copy from source to destination. The firmware documentation indicates (ReadyNAS OS 6.2, page 199 ) talks about incremental backup. Which is currently correct??
Windows (Archive Bit) – apparently refers to a backup protocol and is covered in the 6.2 firmware manual. This option is absent from the 6.4.0 software. Is this a mistake or intentional?
FTP – my view is that this would refer to a transport protocol and includes the typical client/server FTP commands. What is the selection algorithm for a file to be in the incremental backup set? Is there only one incremental backup produced and older incremental backups are then overwritten?
NFS – my view is that is a transport protocol for distributed file system but it most likely has more robust capabilities. What is the selection algorithm for a file to be in the incremental backup set? Is there only one incremental backup produced and older incremental backups are then overwritten?
Rsync Server – seems to be a robust method of source/destination synching. As far as I can tell, the data to be selected is in the backup definition and the Rsync protocol offers a secure/different transport mechanism. Is that notion true? What is the selection algorithm for a file to be in the incremental backup set? Is there only one incremental backup produced and older incremental backups are then overwritten? Will it work for intra-system backups, e.g. to a different volume on the same ReadyNAS device?
Rsync over Remote SSH – seems to be a robust method of source/destination synching using the SSH capability/transport mechanism that offers substantially more security. As far as I can tell, the data to be selected is in the backup definition and the Rsync over Remote SSH protocol offers a different and more secure transport mechanism.
I am apologetic that this thread has expanded but if my questions are valid than the topic may be a good candidate for a ‘sticky’ on the forum.
Maybe start a separate thread on the various backup methods, and how to decide which is best. That would be helpful to a lot of people I'm sure. Ideally there'd be a table somewhere of the various backup features by transport protocol.
I didn't mean to imply that the windows timestamp method isn't incremental. Your local->local copy was a straight-up copy, using normal linux copy commands.
Rsync is definitely best for NAS->NAS incremental backup (which is what this amounts to). rsync-over-ssh just adds encryption to the link (tunneling rsync over port 22), which you don't need - you are staying within the same box after all.
NFS could also work - though in my experience, rsync is a little better. One thing I've seen is that NFS doesn't always preserve timestamps on folders (not sure why), but rsync always does.
FYI, it seems that the Windows Timestamp method does not do a straight copy. I created a test, ran and saw the results. Then added some stuff to the source and ran again and the new stuff was there but job took only seconds to run. Deleted the stuff from ths source and ran again. The destination did not change -- the stuff deleted was still there.
Would seem to indicate that the copy notion is not accurate -- time it took and the fact that deleted stuff was still there.
I tried the Rsynch using your excellent instructions and the job failed. The Test Connection worked. No indication of why the job failed.
FYI, it seems that the Windows Timestamp method does not do a straight copy. I created a test, ran and saw the results. Then added some stuff to the source and ran again and the new stuff was there but job took only seconds to run. Deleted the stuff from ths source and ran again. The destination did not change -- the stuff deleted was still there.
Would seem to indicate that the copy notion is not accurate -- time it took and the fact that deleted stuff was still there.
I tried the Rsynch using your excellent instructions and the job failed. The Test Connection worked. No indication of why the job failed.
Any ideas.
I didn't say that Windows Timestamp did a straight copy. If you use windows timestamp, make sure to set the source up as the remote source, and the destination as the local share. Otherwise you need SMB enabled for the destination (which is what we are avoiding).
Is the rsync service enabled on the NAS (system->settings)?. I actually tested my instructions as I posted them, and they worked on my RN102. Though my destination share was set up to be fully open, so there might be some security issue getting in your way. Also rsync was enabled on both the source and destination share (all my shares are set up that way).
I didn't say that Windows Timestamp did a straight copy. Sorry, that was my interpretation.
If you use windows timestamp, make sure to set the source up as the remote source, and the destination as the local share.
I am really puzzled here – both shares are on the same ReadyNAS system, just different share names. Otherwise you need SMB enabled for the destination (which is what we are avoiding).
SMB is not enabled on the destination and the job did ran. Here is the log.
Backup Job Name: Test-WindowsOnly
Backup Job Type: Incremental
Protocol: local
Backup Source: [AccountingFiles]/
Backup Destination: [Test]/
Backup Start Time: Thu Nov 12 2015 11:53:37
Backup Finish Time: Thu Nov 12 2015 11:53:38
Backup Status: Success
My complaint is that it did not remove the data that had been deleted in the source. Not what I expected.
Is the rsync service enabled on the NAS (system->settings)?. Yes
Also rsync was enabled on both the source and destination share (all my shares are set up that way).
Rsync was established in both shares but I had not set the Read/Write setting.
Thanks -- now I have changed all shares to have Rsync protocol.
I now have a backup method that seems to work. The firmware documentation discusses incremental but that would require that there is a log of the initial (full backup) files kept somewhere so that Rsync would know what stuff has changed. It looks to me like it does a sync between the source and the destination (what it is supposed to do) but there is no baseline log -- it just makes the destination the same as the source, Is that your view as well??
Nothing wrong with that approach but it is not what the norm is in a Windows environment where a difference log/file/record is kept. What that would mean is that if I wanted to have seven backups (to retain some historical data) I would then need to have seven destinations all the same size as the source and rotate the job among the destinations. Would that be your understanding as well?
If you use windows timestamp, make sure to set the source up as the remote source, and the destination as the local share.
I am really puzzled here – both shares are on the same ReadyNAS system, just different share names. Otherwise you need SMB enabled for the destination
If you use "local" for the source and destination shares, then you do get a straight-up linux copy. It's not using SMB or anything else. So while it would properly conceal the destination share from windows, it isn't incremental.
Since the backups will be fairly large, and likely have little churn we want incremental. So we are limited to using one of the backup protocols that does support incremental. Windows timestamp is one. But that requires SMB access through SAMBA (we aren't talking native windows NTFS here). So we use localhost (127.0.0.1), and from the system's point of view either the source or destination has to be remote.
If you chose to make the destination remote, then the destination needs SMB access enabled which you don't want. If you chose to make the source remote, you'd have been fine - incremental backups and concealed destination shares. Though you'd be going through SAMBA unnecessarily.
My complaint is that it did not remove the data that had been deleted in the source. Not what I expected.
In addition to not being incremental, the local linux straight-up copy just copies from source to destination. That's all it does, so files on the destination that are missing from the source are not purged. The rsync instructions I posted above included setting an advanced option to purge any files in the destination that aren't in the source (for rsync).
That's a mixed blessing btw - for some use cases you are better off keeping the deleted files on the target. However, I want it set myself (and I keep snapshots enabled on the destination share to let get deleted files back). I think you should probably keep snapshots off though - with your weekly cycle they'd probably take up too much space.
Here is an example of why the current backup documentation is inadequate. The notion that the source address would somehow affect the type of backup and the knowledge to tweak it needs to be documented.
I have posted a thread asking about these issues as you suggested. Encourage your management to have somebody focus on the answer.
I set up the Windows Timestamp with the source as ‘remote 127.0.0.1’ as you discussed. The job ran but I saw nothing in the definition for incremental. The results did not remove the deleted directories. When I went to recover files it lead me to a snapshot directory and it was a null set.
The Rsync job seemed to work as I would expect – deleted directories gone, renames worked, etc. I went to recover some files and it lead me to a snapshot related selection but that was a null set as well.
Are the snapshot files the incremental feature that is discussed?
The firmware manual says a restore is essentially a reversal of a backup job. I tried defining a restore job – the source being 127.0.0.1 and the backup directory and the destination being the local directory I could browse to. Testing the connection lead to an error. Any ideas?
The firmware manual says a restore is essentially a reversal of a backup job. I tried defining a restore job – the source being 127.0.0.1 and the backup directory and the destination being the local directory I could browse to. Testing the connection lead to an error. Any ideas?
It should reverse ok, but sometimes test connection fails when it shouldn't. Of course rsync needs to be enabled on both shares, etc.
Though I suspect in your case you'd be restoring to a user PC. I'd probably temporarily enable SMB on the backup share, and drag/drop (or better, use teracopy or robocopy) on the PC.
Let's summarize this thread. I will open a new thread regarding the Netgear implementation/use of the rsync command.
CryptoLocker and its variants are ‘in the wild’ and using an infected PC to encrypt most files as well as the file and directory names. The malware chases all local drives and any mapped drives as it encrypts the data. Once encrypted users are told to pay a ransom of between $700 and $70,000 dollars in bitcoins or never recover their data.
Currently the only way to feasibly recover the data is either pay a ransom or restore the data from backup files. The backup files should be on a ReadyNAS share that does not have SMB access enabled so the malware cannot detect the data – it is not part of a mapped drive.
The intention is to have backup of various Windows files and directories on a ReadyNAS that are the object of drive mapping in local PC network.
The backup share should be established without SMB protocol enabled. Turn SMB off in the Network Access tab in the file properties
The rsync protocol should be enabled and Read/Write access should be allowed. Use the Network Access tab in the file properties.
Now there is a location for file backups that will not be discovered by CryptoLocker.
The next step is to establish a backup job(s) to copy the ‘live’ mapped data to the essentially hidden data area.
