Best practices for protecting Rapid Recovery Core server and repositories from ransomware (4038350)

Some viruses that infect computer networks prevent user access to files and even entire systems. These viruses are often referred to as ransomware or cryptolocker viruses. When a system is infected with this malicious code, the files and folders on the system are encrypted by the virus which then demands a ransom to decrypt the data. The virus also attempts to spread from system to system and to encrypt any network shares it can access.

Once the data on systems has been encrypted, the only options for restoring the data are the following:

1. Restore from the last good backup
2. Pay the ransom (and hope it works)

The worst case scenario occurs when both production systems and backups are encrypted.

This article lists common steps that can be taken to prevent, or at least harden, Rapid Recover Core server against ransomware infection.

There are several steps that can be taken to decrease chances of ransomware infection and reduce restore times in case that infection or other type of damage did happen.

1. Software Configuration
   1. Make sure that Core server is regularly patched with Windows/Microsoft Updates.
   2. Install and maintain anti-virus software on the Core server. Ensure that exclusions rules for Rapid Recovery are in place.
   3. Keep web browsers and all software up to date with the latest security patches. Avoid using the Core server for web browsing or email.

2. Network Configuration

   1. Disable Network Shares: Disable all network shares on the Core server, including administrative shares. To do this, complete these steps:

      1. Open regedit.

      2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters.

      3. Set the value of AutoShareServer to 0. If the key doesn't exist, create it.

      4. Reboot the server for the changes to take effect.

   2. Disable SMBv1: Ensure that SMBv1 is disabled, as it is a known vulnerability. Follow the guidance in Microsoft article Detect, enable, and disable SMBv1, SMBv2, and SMBv3 in Windows to disable SMBv1.
3. Make sure that Rapid Recovery Core server is not joined to Active Directory domain
   1. Use local administrative account/password that does not match any account in AD
   2. If the Core needs to be joined to a domain, follow these recommendations regarding User Access Management (UAC):

      • Minimize User Accounts: Restrict access to the Core server by minimizing the number of user accounts with administrative privileges. 

      • Domain Binding: If your Core server is bound to a domain, restrict the Local Users and Local Administrators groups to only the essential domain accounts. 

      • Account Management: Remove the "Domain Admins" and "Domain Users" groups from the Local Users and Local Administrators groups. Limit access to named accounts only. 

      • Disable Unused Accounts: Ensure that all unnecessary local user accounts are disabled, including the default administrator account. If the default administrator account is needed, rename it and set a complex, unique password.

4. Repository Considerations
   1. Secure CIFS Shares: If using a CIFS share to host repository files, restrict access to the share to a single, unique account used exclusively by Rapid Recovery.
   2. NAS Security: If using a NAS to host repository files, ensure that the default password has been changed and that the NAS is configured with strong security settings.
5. Setup a Disaster Recovery (DR) site, and replicate Rapid Recovery Core data to it.
   1. It's recommended to place the DR site geographically remote, but not very far.
   2. It's better to setup a replication Core/storage on the physical server, which can be driven to the primary site for a faster restoration process (if the primary Core was compromised or there was a physical damage (fire, flood, lightning, etc.). If needed, VM can also be used as a target Core, in case the target Core's repository disk can be copied and attached to the primary site's Core.
   3. When using offsite replication, ensure that the target Core server is on a completely separate network. The only allowed traffic between the source and target Core servers should be on port 8006. This is the only port required for replication and its direction depends on replication's direction.
6. Backup and Recovery Preparations

In the event of a ransomware attack, even if the Core server is compromised, the following steps can help expedite recovery:

1. 1. Periodically, backup the Core Settings or export the HKLM/Software/AppRecovery registry key using regedit. Store the XML files and/or registry backup in a secure, offsite location.
   2. It's also recommended to export Encryption Keys (if any) to files using Core console, More (..), Encryption Keys. Store these files in the safe place.as well.
   3. Utilize hypervisors to setup Virtual Standby process for critical servers (Domain Controllers, SQL, Exchange, etc.)
   4. Test booting Virtual Standby VMs once in a while with networking disabled, to make sure that VMs are bootable. Never boot Virtual Standby VM while the originally protected machine is active in the same LAN.

When ransomware attacks the Core server, the OS is compromised and repository XML files are encrypted. New Core installation won't be able to detect repository data files without appropriate XML files. It's still possible to re-create the XML that describe the repository , but it may take a long time to bring the repository back to working state.