Protect SQL Server from Ransomware

The Challenge

Ransomware has become a persistent threat to the enterprise. Attackers are targeting the database servers of a broad range of targets. What can be done to protect the SQL Servers at your organization and ensure that they are protected?

Common Solutions

There are various steps that can be taken to limit the vulnerability of your servers and protect your organization from malicious attacks. Some are more sophisticated than others, but here is a basic rundown:

• • Apply the latest security patches on your servers
  • Deploy a robust antivirus software
  • Use a low-privilege account for non-admin access
  • Manage critical infrastructure only via “privileged access workstations”
  • Restrict direct access; allow access only via SQL Server ports
  • Allow only legitimate web traffic from the database server
  • Stop unnecessary services

Let’s look at each of these solutions in more detail.

 

Apply the latest security patches on your servers

Malicious software can get full or partial control over a computer system in a number of ways. However, the most common scenarios are a) Either the user was tricked to install the malware, or b) the malware was able to successfully exploit vulnerability in the system and launch its service.
The best way to address the first type of vulnerability and ensure that employees and other system users do not install malware is to raise their awareness of the threat via training and education. Computer users must be alert and aware of the threats, and exercise caution in their day-to-day operations. Limiting their access privileges may be helpful in certain situations, but even such steps can be of limited effect, as system users usually have access to miscellaneous organizational files that may be of interest to an attacker.

The second attack vector is more sophisticated, which is why the organization should take advantage of the security patches released by the software vendor. For most types of enterprises, the software vendor would be in a much better position to analyse the known existing threats and release security updates to plug any holes, in many cases before they even become known to the general public. This is one simple steps every organization can take and its importance can be emphasized strongly enough.

Implement an antivirus solution

There are advocates who argue that installing antivirus software on a database server has serious drawbacks and should be avoided, as they would quote various possible conflicts between the antivirus program and the database software.

Obviously, the antivirus software is not a perfect solution by itself, because authors of sophisticated malicious software would test against the most popular antivirus engines. However, ability to recognize a very large number of known exploits and patterns, and prevent them from installing and/or running makes antivirus software a very attractive proposition. This is essential instant protection and security for your SQL Server and a must have tool when managing security risk. The bottom line is that anti-virus software will successfully guard you against most known threats.

Use a low-privilege account for non-admin access

Generally, software is installed on a user account, and inherits the privileges of that user. Ransomware is not an exception. Occasionally, some especially sophisticated ransomware may find a way and creep up the access right tree and raise its access level, but even in those cases the damage would most likely be limited to the local workstation. Only really advanced malware that is specifically design for a given system would be able to get remote access to the database server, and thankfully, these don’t seem to be a common occurrence just yet. So the general advice here is to use low privilege account for your trivial daily office work, so that in the event of a ransomware attack, the malicious code has no access rights to your high-value assets, such as your SQL Server.

Use “privileged access workstations”

This point is the flip side of the one above. Using non-privileged workstation for your trivial routine work implies that you would, on the other hand, use an account with more authority (and security) to access SQL Server and manage critical infrastructure. Microsoft has documented well what they call “privileged access workstations”. There is nothing new with this idea – you simply segregate the management of your systems from the computers used for the company’s routine operations to reduce the security risks. These specialized terminals can access more broadly the critical enterprise infrastructure, compared to the regular workstations. They will also restrict emails, and whitelist their internet access to fit their purposes, restricting general web surfing. In addition, the software tools on these computers will differ greatly from what is installed on the normal computers. This is one additional protection from possible attacks via office workers’ Remote Access software of choice. Antivirus software can be tweaked accordingly as well, considering the different purpose of the privileged access workstations.

Allow access only via SQL Server ports

The trick here is to prevent ransomware from spreading across the network by eliminating the direct access from the computer work stations. This eliminates the access of the ransomware to the files on the network, which it needs in order to encrypt them. As the infection typically spreads from an initially infected workstation, the limited ability for accessing shares ensures that the ransomware won’t reach any files to hold hostage. Check with your DBAs to see what is the most secure access method and if they need network share access at all. And once you agree on a protocol, make sure that you apply those rules to any remote access solution that may be deployed at your organization (such are Remote Desktop, Citrix, etc.).

Allow only legitimate web traffic from the database server

Generally, ransomware needs to “call home”, i.e. communicate with its web server on the web somewhere, so that they can release the hostage files when the victims of their attack eventually agree to pay up. Now bear in mind that some ransomware doesn’t even have a decryption option, and the criminals behind it never even intended to release the hostage files. But in the cases when the attackers actually want to honour the transaction, they would need a communication path to do so. In those cases, blocking internet traffic would reduce the attackers’ ability to exchange keys, and in such a scenario many ransomwares would not be satisfied with their control of the local IT infrastructure enough to engage, and simply do nothing. So whitelisting only the proper web traffic out of your SQL Server is one way to reduce the chance for ransomware to get a hold of your systems.

Stop unnecessary services

Speaking of whitelisting and blocking direct access, another opportunity to improver it security is to eliminate any protocols that are not really needed. Don’t install any modules and components that are not required for SQL Server to run, as those non-cores services can be an attractive target. The more components run, the more difficult the task to protect the system as whole. This is more commonly known as “attack surface reduction”. Every software service enlarges the “attack surface”, i.e. the general software environment with all its end-points, which can be attacked. Making the attack surface as small as possible makes it more defensible, and therefore this practice is a common security measure.

 

Next Steps:

• Investigate who are the administrators on your SQL Server via a script.
• Understand how SQL Server talks on the network.
• Learn why using privileged accounts protects your SQL Servers.