Thursday 4 February 2016

Protecting a Backup Repository from Malware and Ransomware

With the abundance of malware and ransomware it’s absolutely necessary that we take the time to examine our backup structures.

  1. Volume Shadow Copies
    • Obviously not a “backup”
    • Most ransomware today kills these
  2. Backup to Disk/NAS
    • Rotated or streamed off-site
  3. Cloud Backup
    • Streamed off-site
  4. Backup Tiers
    1. Current, off-site 1, off-site 2, 6 Month, 12 Month, ETC…

With our last mile issue up here we are very careful about anything Cloud since most upload speeds are not capable enough nor are the download speeds capable of a decent recovery time.

Now, what is _the most important_ aspect to our backup setup?


It must be a closed loop!

What does that mean?

That means that at no point in the backup structure can anyone have access to the backups via the network or console.

Now, since almost all of our backups are streamed across the wire it takes a bit of a process to make sure our loop is closed.

  • NAS
    • ShadowProtect user with unique pass phrase (SPUP) and MOD on the repository root folder
      • Other than the NAS Admin account no other user account is set up with access
      • Turn on the NAS Recycle Bin!
        • Most ransomware creates a new file then deletes the old one
        • Create a separate username and folder structure for user facing resources!
  • ShadowProtect
    • Network destination set up with SPUP
  • ShadowProtect Backups
    • Encrypted AES 256-bit with a long pass phrase
  • ImageManager
    • All managed backups are set up to be accessed via SPUP only
      • No repository, whether NAS or USB HDD is left with Users MOD
      • No repository is left without a restricted username and password protecting it!

Recently, we know of a domain joined standalone Hyper-V server get hit by ransomware. As a rule we don’t join a standalone Hyper-V to the guest domain. This is just one more reason for us not to do so.

And finally, some of the more obvious aspects around backups and domain operation in general:

  • Users are Standard Users on the domain
    • If they absolutely need local admin because they are still running QuickBooks 2009 then make that choice
    • Standard User accounts have _NO_ access to any aspect of the backup loop
      • None, Nada, Zippo, Zilch! ;)
    • Domain Admin accounts should have no access to any aspect of the backup loop
      • Many client sites have one or two users (hopefully not more?!?!?) that know these credentials
    • Access via UNC will pop up an authentication dialogue box.
      • Use the SPUP and _do not save_ the credentials!
  • Backups are managed by us, spot recovered by us, and quarterly bare metal/hypervisor restored by us
    • No client intervention other than perhaps the off-site rotation (we do this too)
  • If some user or users insist running as DOMAIN ADMINs then REMOVE Admin’s MOD from USB HDD/NAS NTFS/File System
    • Leave only the SPUP with MOD

So, what spawned this blog post?

Hearing of a ShadowProtect destination NAS getting wiped out by ransomware. This should not be possible on our managed networks ever!

What spawned our lockdown of the backup structures?

Many years back we had a user that neglected to rotate the tape libraries and a faulty BackupExec that reported all being rosy until their server went full-stop and we had to recover (one aspect of the recovery in an SBS environment).

When we arrived, the person rotating the magazines turned sheet white when we asked for the off-site magazines. Oops. :(

We dropped BackupExec as their support failed to help us after three days of wrangling (Thursday afternoon until we cut the cord at 1730Hrs Saturday evening). We did end up recovering the full 650GB of data short of 24 files belonging to one of the firm’s partners across four to five days.

After that we went to all of our clients and proposed a managed backup strategy where we took care of all aspects of the backup. They all approved the changes after hearing what happened at the one firm. ;)

So, we tested and switched all of our clients to ShadowProtect 3.x and set up all backups so that no user could access them.

In our not so humble opinion, backups are not, and should never be, a user’s responsibility.

Thus, they should never have access to them even if they rotate them!

TIP: Need to do a side-by-side recovery or migration? ForensiT’s User Profile Wizard

Philip Elder
Microsoft High Availability MVP
Co-Author: SBS 2008 Blueprint Book


Rob Pelletier said...

Looks great. Been doing some of this, but I guess I'm not taking it quite far enough. Thanks for sharing...

Enlighten me though: what is this MOD you refer to? I figure I should have been able to figure it out from the context, but I just can't quite get it...

Philip Elder Cluster MVP said...


MOD = R/Wr access at the NTFS level for that user/user group.

Ken Wallewein said...

Great posting Phil.

With the latest ransomware, I'm getting more and more paranoid. For LAN-based storage, I'm concerned whether permissions-based protection is enough.

Even if it's not a domain member, has no credentials in common with the server or domain, and no open shares, I'm concerned whether a Windows-based NAS or BDR might be susceptible to some sort of low-level network hack via NETBIOS or such.

I'm thinking that any LAN-based storage devices should be on a separate subnet, preferably accessible only via a firewall. And better get, using only ImageManager ftp updates to the BDR, which means there's no way for ransomware to get to the BDR via NETBIOS.

Do you think that might be over the top?

-- Ken

Philip Elder Cluster MVP said...


If that were the case then we'd have _way_ more problems on our hands than unauthorized network access to the backups.

Absoblogginlutely! said...

Some good points here Philip - and got me thinking about securing ours.
One other thought/solution would possibly be firewalling off the Shadowprotect destination so it's only accessible from the servers themselves and not the end user workstations so an infection on a workstation would not be able to access the share even if permissions were granted.
For the ultra paranoid, In an ideal world you would open up access to the destination server when the backup starts and then close it afterwards but I can see that becoming a management headache and would need some pretty clever scripting to change the permissions.