FTP backup as ransomeware protection

Patrick, I am able to configure FTP backups to my Synology NAS (DS215j) but only unsecured FTP despite the NAS supporting SFTP etc.  The NAS does have its own Firewall so have configured this to restrict FTP to my local network interface only.

Thank you, Steve.

Just a thought but could you use a bat file in a pre and post command to temporarily mount an smb share, backup to it and dismount the share immediately after? It could minimize the potential vector point by only connecting to it for the backup duration and Aap should theoretically protect it while in use.

" Just a thought but could you use a bat file in a pre and post command to temporarily mount an smb share, backup to it and dismount the share immediately after? It could minimize the potential vector point by only connecting to it for the backup duration and Aap should theoretically protect it while in use. "

If AAP protected .tib files on a NAS connected by SMB this would all be a moot point.  Unfortunately, NAS shares were apparently excluded from AAP's view.  Once that little oversight is corrected your suggestion is exactly what I will do. 

Actually, I don't think the pre command is needed: Windows will do the mount when ATI asks for the connection, and ATI has the connection credentials in an encrypted (or at least munged) registry record. 

I would love to hear I've misunderstood that AAP restriction but a couple people on this forum confirmed it.  Actually, I confirmed it by deleting a whole grundle of unneeded old .tib files from a NAS.  AAP didn't give a peep.

Hmmm, I suppose that is the way it works. Hadn't really tried myself.

I tried mapping the NAS drive as a local drive letter hoping it might consider it a local drive an not a network share, but no dice.  

Would be nice if we could add additional directories or shares to an allowed whitelist.  I imagine it would be very network and/or local resource intensive to monitor a remote share all of the time and that might be why network shares are not covered. 

For what it's worth, I have another license for a competing product that I compare and test with too.  The current, licensed version now also offers backup file protection from ransomeware... but it also has the same behavior for the backup files on network shares as Acronis does.

I'm not surprised that protection of NAS files lags behind protection for local files.  The routines for accessing NAS files are probably completely separate from the routines for accessing local files ... regardless of how similar their external behavior appears.  And the fact that this protection is lacking in products from two vendors may be a hint that providing protection for NAS files may be harder than it is for local files.  (Maybe the SMB routines have fewer places to set hooks for the intercept code.)

There is no way that code like AAP can completely protect .tib files on a NAS.  Acronis code running on computer A cannot prevent a Linux user running on computer B from deleting or overwriting .tib files on a NAS if the user has been given permission to do that.  AAP cannot even protect .tib files from being deleted or overwritten by an FTP connection originating from the computer running ATI.  Those are issues that AAP cannot address.  But being able to delete or overwrite .tib files over an SMB connection is a very big security hole.  

I deeply hope that Acronis finds a way to address this problem, but until then I'm going to continue working on a scheme for putting backup files on a NAS (or at least a share) without SMB access.  

Yesterday I twice ran into a very serious problem with the ATI FTP client.  After 1.5 hours into a backup of a 1.4TB file - a backup that would have gone another 16 hours or so - ATI ran into a problem and did something to lock up the Windows TCP stack.  Existing connections continued to work (slowly) but no new connections could be formed.  Cancelling the backup did no good.  (I think ATI was no longer listening to it's GUI.)  I rebooted and restarted the backup.  That 2nd time it got 2.5 hours into the backup (but had transferred less data) when the same problem happened.

Now, it's possible that ATI was a victim rather than a perpetrator but I've never had this problem before, I haven't had it since, and it happened both times I tried doing that backup.

This was the first time I tried a large FTP backup since going to ATI 2018.  In the past I had no trouble backing up large files (but ran into problems deleting them).

I think perhaps FTP backups are not the solution to ransomware I had hoped.
Is anyone willing to convince me that SMB backups are safe enough?

Kees,

SMB backups are safe enough in themselves as SMB vulnerability to attack has been addressed in version 2.0 and 3.0.  Users need to disable SMB 1.0 on their machines to close the security hole that does exist however.  See the link below for more:

https://technet.microsoft.com/en-us/library/dn551363(v=ws.11).aspx

The issue that does exist is with malware that successfully takes over the admin account of your machine.  If that happens then network shares are vulnerable.  Although not a complete guarantee. safe internet practices, keeping your OS and apps patched with the latest updates should be enough to defend such attacks.

Patrick, I haven't tried to do any very large FTP backups - my test task was only around 22GB and that performed fine.  The one niggle I found was not having the 'Open location' option when using FTP that I see when using SMB to the same NAS destination.

I have disabled SMB 1.0 on both my Windows computer and also on my Synology NAS which is configured for a minimum SMB level of 2.0 and also supports 3.0.

Any malware / ransomware threat is most likely to originate from a Windows computer, so hopefully would be detected by a combination of my Security applications along with AAP before gets any opportunity to spread via SMB to my NAS files.  Fortunately I have never had any such problems personally in all my years of computing, though I have had to 'delouse' computers brought to me by other people, but this has been mainly virus and Trojan type infections, not any encrypting malware types.  To quote an old saying, the need to practice 'Safe HEX' is very much the way computing needs to be approached today!

Steve,  When you ran your test where you were able to delete .tib files on your Synology, were your NAS and computer configured with SMB 1.0 disabled?  I have configured my computer and Synology with SMB 1.0 disabled.

I have tried to duplicate your test, but everything I have tried resulted in a popup requesting credentials.

Regards,

Randy

I know I have SMB 1.0 disabled on my 2 PCs but I'm not sure about on my wife's laptop (which I don't have access to at the moment).  The laptop is our only computer whose primary backup device is a NAS so it is the one that really needs SMB 1.0 disabled.

I have reasonably good security software on our computers.   (Even if the US State Department considers it Russian spyware it seem to rate highly on anti-malware tests.)  It and AAP (which should play together nicely) will hopefully keep the backups safe and uncorrupted.  I'll try to stop obsessing about this.  :-)

Randy, I would need to try the test again when I have time as I can't remember the timing of when I disabled SMB 1.0 totally.

Randy, quick update on your question.  Yes, I can still delete files on my Synology NAS with SMB 1.0 disabled without any prompt for new credentials.

My further testing shows that if you use the 'Open location' option for the NAS backup, that ATI then leaves that SMB connection 'open' until the user logs off, as shown by using PS Get-SmbConnection command - and while the connection is open, all bets are off for what can be done to the destination files!

Unfortunately, SMB was designed to make file sharing easy.  Security didn't seem to be a primary design point and newer security implementations still have to deal with that reality.  Authentication at the file level would prevent unauthorized modification or deletion of files.  It would also make it a nightmare of copy a large folder of files.

It would be nice if a future version of SMB allowed two flavors of connection: one requiring share-level authentication; the other requiring file-level authentication (even if all files could be opened with the same key).  The something like ATI could open a file-level authentication connection.  The anything using that connection would have to authenticate for each file operation.

Hi Steve,

I just tried your Open location option on a backup on my networked NAS which runs SMB 3.1.1 SAMBA.  I have my Windows 10 Pro version 1709 setup with SMB 1.0 disabled 2.0 and 3.0 enabled.  When I run Get-SmbConnection with a share open in Explorer it shows Dialect 3.1.1 indicating the highest level of SMB 3.0 is being used.

If I attempt to Open location in True Image 2018 version 10410 for a backup located on an NAS share that was created on another of my PC's to the share I am greeted with a Windows Security box asking for my password for my machine name as user. 

If I open True Image on the machine which created the backup select that backup and choose Open location the NAS location immediately opens the NAS location which I would suspect as normal behavior however, you are correct in that this open connection remains open when TI is closed which I think is not intended.  The behavior should be the same as Windows Explorer and once the connection is closed the SMB connection should also close.

I have reported this to the Support Team.

Hi Bob, thanks for confirming what I have seen - I am also seeing SMB 3.1.1 being used, and have added this information to my open Support Case # 03156937 which I have been refusing to accept as 'resolved' so far.

Quick additional note:  The open SMB connection can be closed via PowerShell by using:

EXAMPLE 2

This example removes an SMB mapping to an SMB share without user confirmation.

Windows PowerShell

PS C:\> Remove-SmbMapping -RemotePath \\Contoso-SO\VMFiles -Force

Steve, Thanks for the update.  

To minimize the risk, I have decided to use "Custom" permissions on my Synology.  I use different synology accounts for each backup task.  Each account only has access to one shared folder.  The account has limited permissions...full read and limited write.  My assumption is that any process that gained access through the open SMB connection would not be able to delete or edit any of the existing files.

The only limitation is that ATI would not be able to perform any cleanup operations.  Currently, I don't use the automatic cleanup within ATI, so this is not a problem for me.

I will do some additional testing to see if a process can overwrite an existing file, thereby corrupting it.  Will report back.

Regards,

Randy

Thanks Steve,  This should assist users in closing an SMB session after using the Open location option for a backup file located on an NAS share. 

Something you can confirm to me:  If you start your PC and open TI then click select a backup on your NAS and run the PS get-smbconnection you should see the open connection.  Now if you select another backup on say an internal disk and wait a minute or so and then run PS get-smbconnection again do you still see the open connection?  You should not.

Now once again select the backup on the NAS and from the context menu choose any action, you do not have to follow through with whatever you choose just select the action.  Now close that action out, click select a backup not on your NAS then run the get-smbconnection, do you still see the open connection?  You should as I do.

Bob, I am getting different / inconsistent results when testing the steps you outlined!

After a restart, opening ATI and selecting a NAS backup, no SMB connections shown - this remains the same until I either click on the Destination or start a Validation, then I see the connections.

Clicking on another task (non NAS) etc makes no difference - no connection shown at that point.

Going back to the NAS task, still no connection(s) just by selecting it.

If I select the Recover page for the NAS task, then I get 3 connections, which reduces down to 1 but that connection remains even after closing ATI.  One difference at this point is that the remove-smbmapping command does not find any connections despite get-smbconnection showing the connection with NumOpens = 1

Thanks Steve,  I can report very similar behavior on my end.  This should help in pinpointing the issue.

All,

I have received a reply from support that this open SMB connection issue has been reproduced.  The good news is that the issue will be fixed in the next build update.

The not so good news is that the release of 10640 does not fix this issue.

As a note here the PS command that Steve posted

PS C:\> Remove-SmbMapping -RemotePath \\Contoso-SO\VMFiles -Force

can be truncated to Remove-SMBMapping which will close the current open connection after user confirmation of action.

Bob, thanks for the update on this one.  It is interesting that Acronis have kept insisting on my support case that this is working as designed!  I will send them a link to this topic thread.

"It is interesting that Acronis have kept insisting on my support case that this is working as designed! "

I suppose they could mean it.  That is sometimes referred to as BAD - Broken As Designed. :-)

Steve,

I think it is a matter of understanding of the root problem.  I have tested this a bit and if I perform a full custom one time backup to an NAS device the connection closes shortly after the backup completes.  That is normal and expected behavior.  If however I access the backup location using some but not all right click context menu choices then the connection remains open. 

In my contact with support I explained this in greater detail.  I suspect that has made the difference here.

Hi all

I'm user of ATI 2018, build 15470. Is issue of open SMB connection fixed?  My NAS has SMB 1.0 disabled, only 3.0 is active. Local computers has SMB 1.0 active because I need simple local network active to share files and printers (i'm no sure if system uses this mode).  Sometimes when I open ATI where is couple of defined backups to Qnap NAS, I can get into NAS from windows explorer although there is no credentials entered. The only credentials are in ATI defined during backup setup. After exit from ATI that connection is closed  a while after.  Is that OK that I can get into NAS folder from windows exproler during that short time (30 mi - 1 h) of backup proces and do everything with files? I have also non-.tib  backups on my NAS.

Is ATI 2020 different in that meaning?  I'm not sure if have all configured as should be.  How versions of SMB works actualy?  Can I configure my network in that way that I still can use simple folder sharing and never have acces to NAS network folders from windows exroloer even  during making backup? 

Thanks for your help. 
Best Regards. 

EDIT: I have found Get-SMBConnection command, and looks like my conection ATI - Server is SMB 3.1.1 

Also, my local connections between computers are SMB 3.1.1   

What does it mean in practice?  

Lukas, I do not use FTP for any of my ATI backup tasks so cannot comment directly on whether any issues related to the original focus of this topic have been resolved.

I have not seen any issues personally or raised in the forums about open SMB connections so would assume that Acronis did fix this per the update here from Enchantech back in late 2017.

I do not have SMB 1.0 enabled within my own home network.  This is disabled by default in all recent new installs of Windows 10 since the 1709 update and I disabled this myself for any systems that had been installed prior to 1709 or upgraded to Win 10 at an earlier build.

See webpage: How to kill off SMB1, NetBIOS, WINS and *still* have Windows' Network Neighbourhood better than ever - for help on this aspect.

Thank you Steve for links. Hope i'll find some usefull infos there :)

Best Regards