Backup to NAS leaves SMB connection open. Any way to fix?


Author
Message
Patrick O'Keefe
Patrick O'Keefe
Proficient Member
Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)
Group: Forum Members
Posts: 268, Visits: 1.5K
After doing a backup to a NAS the SMB connection was left open.  Hours after the backup I could use File Explorer to access the backup's share without providing any credentials.  This was a files backup but I assume the same would be true with partition imaging.  This seems like a security hole to me, as any malware running under my userid would also have access to the share.

Have I missed some setting that would lessen this exposure?  (Yes, I know there is nothing to be done about the open connection during the backup.)  (And, yes, I know that not backing up to a NAS would lessen the exposure.  That's not a practical option at the moment.)  Can multiple backup executions be included in a single script?  If so, I could follow a useful backup with a meaningless one to a through-away share.

I know people have occasionally asked for Macrium support of backups over FTP.  A backup to a NAS over any non-SMB protocol would circumvent this exposure.  FTP has its own security holes, but SFTP or FTPS would help.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 65K
If you ran the backup within your user session, then I believe the connection is left open because that's how Windows operates and Reflect doesn't take any special measure to purge authenticated connections -- possibly because in some people's use case, they'll always have an SMB connection to the target share open in their user session since they might use their NAS for other things, and therefore having Reflect forcibly close that connection could disrupt other things.

Here's the more secure approach:
  • Create a separate share (not just a folder) on your NAS solely for Reflect backups.  That way even if you have a read/write connection open within your user session to some other portion of the NAS, you won't have a read/write connection open that can access your backups.
  • Create (or assign) a user account on your NAS that has read/write access to that share, and a separate user account that has read-only access.
  • In Reflect, go to Edit Defaults > Network and store the read/write credentials.
  • If you do NOT ever plan to use scheduled backups during normal operations, then edit your definition file and create a schedule entry for each backup type you use (Full, Diff, Inc) as a one-time occurrence set for a past date.  Obviously that will never run automatically, but it will give you a scheduled task that you can invoke manually at will.  More on this in a moment.
  • If you ever need to access your backups within your active user session, connect to the share with your read-only account.  After all, typically you'd only need read access to your backups anyway, e.g. to extract data.  If you need to delete backups, you can do so within Reflect (or briefly connect with read/write credentials).
The reason for having a scheduled task available for manual invocation is that backups invoked as scheduled tasks run in a separate user context from your logged-on Windows session.  That context does not get access to any authenticated network connections open in your user session -- nor does anything running in your user session get access to the authenticated and read/write network connection that Reflect will be opening to run the backup to your NAS.  This way, the only read/write access connection to the share containing your backups will exist in a completely separate context, and the only connection that will typically ever be open to that share within your user session will be read-only.

To invoke a scheduled task on demand, go to the Scheduled Backups tab within Reflect, right-click the desired job, and click Run Now.

Edited 18 June 2020 3:52 AM by jphughan
Patrick O'Keefe
Patrick O'Keefe
Proficient Member
Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)
Group: Forum Members
Posts: 268, Visits: 1.5K
Oh.  Maybe I have next to nothing to worry about.  The NAS in question contains nothing but backups of one sort or another, and (except for recovery purposes) is never accessed by anything but backup programs.  To limit vulnerability, it contains 4 shares - one for each computer being backed up.  Each/ share/computer combination has its own set of credentials.  And the Macrium backups will normally only be run by schedule.

The situation I reported - the open connection under my userid - was the result of the "run now" option at the end of the backup creation process.  If I understand what you said, I should see something else when the backups run by the schedule.  I should see that tomorrow.

"In Reflect, go to Edit Defaults > Network and store the read/write credentials"

It looks like that happened automatically when I was defining the backup; the credentials already exist there.
If you ever need to access your backups within your active user session, connect to the share with your read-only account. After all, typically you'd only need read access to your backups anyway, e.g. to extract data. If you need to delete backups, you can do so within Reflect (or briefly connect with read/write credentials).

I use an administrative account on the NAS that has r/w access to all shares and use FTP (using WinSCP) if I need to access the backups for any reason.  I try never to use SMB connections if there is an alternative.


jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 65K
Ok, so the key distinction is which "Run Now" option you used.  If you used the one under Backup Definition Files, then you would have started the backup job in your own user session.  As a result, if you already had a network connection to the target open in that session, Reflect would just be able to use that.  If not, then it would be able to create one if credentials were available.  If however the open connection only had read-only privileges, then I believe you would be stuck because Windows does not allow multiple connections to the same network target using different credentials within the same user session.  In that case, I believe the job would fail -- but I haven't tested that.

Backups started using a desktop shortcut (created by right-clicking a definition file and choosing "Create desktop shortcut") would also run within your user session.

But if you go to the Scheduled Tasks tab and use the "Run Now" option there, then you'll invoke an underlying Windows scheduled task.  In that case, the task will run under a different user context -- and by default under the SYSTEM account rather than your user account.  In that case, you need stored network credentials because the job won't have access to anything open in your user session and the Windows SYSTEM account has no "implicit" network access privileges the way regular Windows user accounts can in some network environments.

I realize it's a bit confusing and unintuitive, but part of that is due to how Windows works and the reality that scheduled tasks operate differently.  And there are legitimate reasons you might want to perform a manual execution within your own session (if you don't want to deal with schedules at all) or a scheduled task (to make sure that scheduled task execution will work properly without having to wait for a scheduled occurrence, or to start a backup in a way that you'll be able to log off your users session without cancelling the job.)

Edited 18 June 2020 5:26 AM by jphughan
Patrick O'Keefe
Patrick O'Keefe
Proficient Member
Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)
Group: Forum Members
Posts: 268, Visits: 1.5K
At the scheduled time for a backup I got a popup saying that the backup would run in 15 seconds.  I clicked for it to proceed right away.  I expected it to run under SYSTEM as you suggested, but instead, it again ran (or at least opened the SMB connection) under my userid.

Those top 2 lines are the connections to the private share containing backups for this computer.
As before, I was able to browse the contents of that share using File Explorer without providing credentials.  The backups seem no more secure than if I put them on my public share.

Update:
On another computer I did not respond to the backup popup and Macrium did not open an SMB connection for my userid.  The only connection to the NAS was (the equivalent of) the 2nd line in my display - the one with Workgroup.  I think my concerns can be put to rest by preventing that popup from displaying - an option on the popup.

Edited 18 June 2020 5:21 PM by pokeefe
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 65K
The popup and whether you choose to click on it doesn't affect how the job starts.  Check Edit Defaults > Schedule to make sure your original PC is in fact configured to run scheduled backups as the SYSTEM account.  If so, then try the test after making sure you've cleared all SMB connections out of your user context.  If you launched the full Reflect application, maybe it opened an SMB connection in order to show your existing backup under the Restore tab?  I haven't experimented with that aspect in detail, but I do know that clicking OK vs. not clickin OK on that popup will not affect how the job actually runs.

Patrick O'Keefe
Patrick O'Keefe
Proficient Member
Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)
Group: Forum Members
Posts: 268, Visits: 1.5K
Interesting.  I get different results on two different computers even though the Check Edit Defaults > Schedule definitions are the same (other than the share name).  The backups are set to run under SYSTEM.  I'm going to reboot to clear out all SMB connections (although my Public one will be reestablished) and see when the connections to my backup share are opened.

Well, I'm confused.  On two different computers after reboot and before starting the MR GUI there were no SMB connections to the NAS with private shares.  Both computers have 2 MR backups defined with the private NAS as the destination.  (One computer has two other backups going to a local hard drive.)  All backups are scheduled to run under SYSTEM.

After starting MR on one computer I see

(4 open connections?)
After a few minutes I see


On the other computer after starting MR I see

and after a few minutes


All of these connections have my userid rather than the WORKGROUP/<computer name> that I say earlier (and really liked).  I'll dig into this a bit later.

Edited 18 June 2020 7:57 PM by pokeefe
Patrick O'Keefe
Patrick O'Keefe
Proficient Member
Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)
Group: Forum Members
Posts: 268, Visits: 1.5K
Ignore my previous post.  The information SMB information from my 2nd computer shows a connection to a different share than the one used by MR.  If MR had been trying to set up a connection under my userid it would have closed that connection  (In Windows, only one set of credentials is allowed for a given local-user / remote NAS combination ... if I understand correctly.) 

I definitely have more digging to do.

And more digging has been done.  I manually started a connection from File Explorer to share DS218_2/Private and then tried doing a backup to DS218_2/PUGET-116877 and got error message
Destination:
Backup Type: Full - Incremental specified but no backup set to append to
File Name: \\DS218_2\PUGET-116877\Prog Data\D4EB7DC652139ED1-00-00.mrbak
Attempting to connect to: '\\DS218_2\PUGET-116877\Prog Data'
WNetCancelConnection2: '2250'
Failure: User - PUGET-116877 - Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

Failure: User - No user - Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

Failure: User - anonymous - Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.


I could be wrong, but I think that the connection would have succeeded if it had been using SYSTEM rather than PUGET-116877\Patrick.  Just to be sure, I broke the connection to DS218_2/Private, retried the backup, and it suceeded.


Edited 19 June 2020 2:46 AM by pokeefe
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 65K
I don't think Reflect would close any existing connections to open a new one -- which the log you posted sort of implies.  But yes, Windows only allows one credential per network share within a given user context.  Or maybe it's one credential per network HOST rather than share.  I can't remember offhand and don't have a readily available environment to test that, but if you opened a connection to \\NAS\Share1 and a backup to \\NAS\Share2 failed with that error about an existing connection, that would suggest that the restriction is per host, not per share.

Anyhow, if the log you posted came from a job that you started interactively, i.e. not as an invocation of a scheduled task, then that result would be expected.  If you want to confirm the theory that it would have succeeded had you run the backup as SYSTEM, then open the connection within your user session as you did, confirm that the backup fails when run interactively as you found previously, and then BEFORE closing the connection within your user session, try running that backup again but this time as a manual invocation of the scheduled task, under the Scheduled Backups tab.  You can use ReflectMonitor to monitor the progress of a background job started a a scheduled task, which you can access either by right-clicking the system tray icon and clicking Show or by pressing Ctrl+Alt+M.

Patrick O'Keefe
Patrick O'Keefe
Proficient Member
Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)Proficient Member (367 reputation)
Group: Forum Members
Posts: 268, Visits: 1.5K
I don't think Reflect would close any existing connections to open a new one

You are right.  The new connection just failed to be made.  Interestingly, It failed differently on 2 computers.  I don't have the 2nd error message at hand right now.

Or maybe it's one credential per network HOST rather than share.

Yes.  I had forgotten that initially.  In fact, Windows saves the credential somewhere keyed by local-userid / remote host such that IP address and host name count as separate hosts.
Anyhow, if the log you posted came from a job that you started interactively, i.e. not as an invocation of a scheduled task, then that result would be expected.
I invoked it by choosing Run on the Backup Definition Files tab.  I should have figured that was not right.  Running it from the Scheduled Backups allowed the backup to run. It definitely started a new SMB connection:
and Process Explorer shows it running under NT AUTHORITY\SYSTEM.  (I assume that any malware that could do damage would also be running under NT AUTHORITY\SYSTEM, but I'm not going to get any more SMB security that this.  I'll try to stop worrying. Smile


GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search