Does AAP protect .tib files on unmapped NAS shares?
For several years I've been trying to devise ransomware protection for my Acronis backup. I've had limited success but perhaps Acronis has solved the problem for me. Will AAP protect against deletion of renaming of a .tib file from an unmapped NAS share? In my latest scheme I would have a NAS drive used only for ATI backups with Windows having no SMB connection until ATI starts its backup, and then having a post-backup script that terminates the SMB connection. I would prefer to not map the share to a drive letter unless AAP requires that.
BTW, I'm not sure where AAP sets its hooks in Windows but I know that an FTP client can delete .tib files from a NAS share with impunity. This is not much of a ransomware exposure since there is no obvious way the ransomware could obtain the share's credentials and (as far as I know) there is no way ransomware could exploit and existing FTP connection. However, a user can shoot himself/herself in the foot using FTP.
If you are logged in to your NAS then you should be able to move, delete, tib files on an unmapped share as you are an authenticated user. If you are not logged in then you will meet failure.
I do not use mapped drive shares either but I would assume that AAP would protect such just as it does with a local drive.
I think maybe I misunderstood how AAP is supposed to work so maybe I asked the wrong question. Let me ask what I really want to know: How do I protect .tib files from deletion or modification by anything except Acronis? In particular, how do I protect .tib files on a NAS share?
I ran a couple tests and was able to delete .tib files using both mapped and unmapped SMB connections. (I had to know the correct credentials which ransomware would probably not know, but that is native Windows protection, not AAP.)
I'm now running a long backup to that SHARE. ATI predicts it will take over 3 hours. The Powershell command (or cmdlet) Get-SmbConnection shows the connection:
ServerName ShareName UserName Credential Dialect NumOpens
---------- --------- -------- ---------- ------- --------
MYBOOKLIVE Public PUGET-116877\Patrick PUGET-116877\Patrick 2.0.2 1
WDMyCloud IPC$ NT AUTHORITY\SYSTEM NT AUTHORITY\private 3.1.1 1
WDMyCloud private NT AUTHORITY\SYSTEM NT AUTHORITY\private 3.1.1 1
Does that mean that malware that managed to run under NT AUTHORITY\SYSTEM while this backup was running would have access to the share and could modify or delete the .tib files? Is that right?
Does that SMB connection end when the backup completes or is it left open? (I guess I'll know in 3 hours.) If so I guess I should use a post-process command to delete the connection.
I'm probably being overly paranoid but that feel that this is a hope in AAP ... unless I really misunderstand what is going on.
Patrick, I have just tested this with my own Synology NAS by opening an Administrator level Powershell window and even with AAP turned on and active, I was able to delete one of my .tib files on the NAS without needing to provide any further credentials than those used by ATI to Open the location of my backup in Windows Explorer!
I think that this calls for a Support Case as it is a potential exposure that AAP is not protecting against!
Support Case 03156937 submitted for this issue by myself.
Thank you Steve. It takes me days to build up the strength to deal with Acronis support. I get tired of being told to collect
1. System information report on Windows
2. Short video session using a camera illustrating the issue.
3. Step-by-step description of the issue and backup settings
4. Reproduce the issue and collect Process Monitor logs
before they check to to see if the problem is reproducible. As near as I can tell, that's their new script. (A video? Process Monitor logs?
Should I continue to steel myself and contact support? If so, may I reference your case to add a bit of credibility?
Patrick, I always submit cases using the email option - I have too many other things to do than sit with a live chat session open to a Support agent!
You are very welcome to reference my support case and also this forum topic showing the dialogue that has taken place on this issue.
I have just submitted a short text document with the contents of the Powershell session where I was able to delete the tib file on my NAS with before & after directory listings etc, plus a couple of basic screen captures to explain the process in the simplest form. I await the first email from Support to ask for more information! So far I just have an automated response with the case number.
I have performed a test by creating file/folder backup to a NAS shared folder that was mapped to a drive letter. When creating the backup, even though the destination was a mapped drive, ATI asked for the NAS credentials. Also, the script file referenced the NAS address, not the mapped drive letter.
After the backup was complete, I used Windows explorer to navigate to the mapped drive, and was able to delete the .tib files, even though AAP was turned on.
My conclusion is that AAP does not protect .tib files that reside on a NAS shared drive...regardless of whether the drive is mapped to a drive letter or not.
FtrPilot
OK. AAP does not protect these NAS-based files. Even if Acronis eventually adds this protection we currently don't have it. I'm trying to understand the scope of the exposure for malware exploitation. (I already know and accept that AAP is not going to protect me from inadvertently deleting the files myself.)
Assume an unmapped share. And assume no other Windows users or services have the appropriate credentials. ATI has Windows establish an SMB connection using the NT AUTHORITY\SYSTEM security id. This connection stays open for (at least) the duration of the backup. My assumption (which I hope is wrong) is that any task running under that SID for the duration of the backup can open a new SMB connection to that server without providing the credentials. Is that correct?
Patrick, I have no Windows drive mapping to my Synology NAS and never have done so, plus I have no Windows User accounts which map to my Synology user for the ATI backups.
Having said this, by having ATI access the NAS backup location, that location is accessible from a separate Windows process invoked by starting Powershell as Administrator, from where the NAS was accessible without being asked for any credentials.
I tested this by using Get-SmbConnection in the Powershell window before I had ATI 'Open location' and this returned no SmbConnection information, whereas immediately after opening the location in Explorer from ATI, I could see the NAS information in Powershell, and could get a directory listing and delete a .tib file from the NAS with no challenge for credentials or from AAP.
Thanks Steve. I was afraid of that. I guess this exposure has existed since ATI could write to NAS shares. It just sounded like maybe AAP had eliminated it.
For now I'll go back to working with FTP backups. As far as I know there's no way to piggyback on top of an FTP connection.
Patrick, I will post updates when my support case gets started. I would consider using FTP but am dubious about doing so because ATI does not support using SFTP and don't really want to open unsecured FTP access on my NAS!
I would certainly prefer a secure transfer but I don't give internet access to the FTP server on my NAS and I trust those on my LAN. Now if only ATI's FTP client would talk with my NAS's FTP server. (That case got escalated to the Expert Team just today.)
Edit: FTP problem was worked on by a technician, seemed to be fixed, case closed. The problem returned 10 minutes later. I responded to the case email asking that the case not be closed. My response resulted in a new case being opened. <sigh>
Whether SMB or FTP, the fates are against my trying to get ransomware-proof backups.
This problem remains after updating to the latest ATIH 2018 Build #9850.