NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
CryptoLocker and a backup strategy
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, ...
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.
Well now we get to the pointof my ignorance.
I just used the Backup option/tab in Frontview
Selected Add Backup
Followed the GUI to add shares for source and destination.
Note that both the source and destination shares are in the same system
I do not know what protocol I used -- that is my point of ignorance
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.
I will start a new thread.
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.
Bains wrote:
I will start a new thread.
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?
Bains wrote:
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.
Bains wrote:
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.
You are amazing -- a font of good knowledge.
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?
Bains wrote:
I have posted a thread asking about these issues as you suggested. Encourage your management to have somebody focus on the answer.
I don't work for Netgear, so that would have come from mdgm or one of the other Netgear employees.
Bains wrote:
Are the snapshot files the incremental feature that is discussed?
No, snapshots are something different. This thread should give you the core idea: https://community.netgear.com/t5/ReadyNAS-in-Business/ReadyNAS-312-Need-Help-Understanding-Snapshots/m-p/936581#M3036
Bains wrote:
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.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
