Storagecraft: Protecting BDRs from Ransomware

Background

SMB is a chatty protocol that announces its shares to the network.  Ransomware has become very sophisticated and many variants will “listen” to the network looking for SMB shares.  A hidden share (with the $ after it) does not broadcast itself.  By further securing and locking down that share, may limit a ransomware variant from A) finding the share and B) Accessing the share.  Most ransomware variants first use the MS SID to encrypt anything that that user (who activate the malware) has access to, and then applies and tries passwords using different username to access other shares.  Some Linux based NAS appliances do not have the ability to use hidden shares.

While we do not know what will be released tomorrow, next month or for that matter anytime in the future, these steps may help limit the local backups from being compromised.  If we can limit or prevent access to the local backups, it will greatly reduce the time and money spent on the recovery.  If, after completing these steps…the backups do get compromised…then we will need to rely on the replicated data.

On the Windows BDR

  • A standalone machine (not a part of the domain)
  • No common password for the Administrator account that matches any password for a domain account
  • Create an account specifically for the backup…hard password and should only have user group membership.  Do not make the user any logical type name (such as backup, ShadowProtect, SPX, etc.)
  • Removing the ability for the above user to log on locally (local security policy)
  • Restricting the user from logging on in a remote desktop connection (local security policy). They should be denied since they are not part of the Administrators group…this is a safeguard.
  • Create the backup share as a hidden share.  Share name should not be any common name as the function such as: backup, ShadowProtect, StorageCraft etc.
  • Remove all ‘Share’ permissions.  Add the user from above.  Assign them only: Read, Write, Modify, Delete (not Full permissions).   The Administrators Group should not have share permissions.
  • Remove all ‘NTFS’ permissions (Security tab).  Add the user from above, as well as SYSTEM (SYSTEM needs access for ImageManager to run).  Assign them only: Read, Write, Modify, Delete (not Full permissions).   The Administrators Group should not have NTFS permissions.
  • So when viewing the permissions (Share/NTFS) there should be only be one user account listed and SYSTEM…nothing else.  If someone has Administrative permissions, it should prompt them to take ownership
On the server being protected as well as the managed folder in ImageManager:
  • Use the UNC path to the hidden share
  • Use the credentials that were set for the user on the BDR
For a Linux Based NAS
  • Should be standalone (not connected to AD)
  • No common password for the Admin user
  • Create an account specifically for the backup…hard password and should only have user group membership to the NAS.  Do not make the user any logical type name (such as backup, ShadowProtect, SPX, etc.)
  • Create the backup share as a hidden share.  Share name should not be any common name as the function such as: backup, ShadowProtect, StorageCraft etc.
  • Adjust the rights to the share.  Remove all users (even the admin) except for the account you created for the backup (rights need to be; read/modify/delete).
On the server being protected as well as the managed folder in ImageManager
  • Use the UNC path to the hidden share
  • Use the credentials that were set for the user on the BDR