Protecting SQL Server from Ransomware

By: K. Brian Kelley   |   Updated: 2017-08-29   |   Comments   |   Related: > Security

Problem

The problem of ransomware seems to be increasing. Major organizations are being hit and their servers are being affected. I want to protect my SQL Server farm so I’m not the next victim. What can I do?

Solution

There are some basic things you can do to reduce your exposure to ransomware and other malicious software. Here is what we’ll consider from what is typically easiest to most difficult:

• Making sure servers are fully patched
• Implementing Antivirus
• Separating accounts for day-to-day activities and privileged access
• Blocking direct access from workstations except through SQL Server ports
• Whitelisting only legitimate Internet outbound traffic from SQL Server
• Disabling unnecessary services / protocols (like SMB 1.0)
• Privileged access workstations

Making sure servers are fully patched

Malware often is successful for one of two reasons:

• The user permits an operation (like an install) to happen.
• The malware takes advantage of a vulnerability to install itself and run.

In the first case, running with less than administrative access helps, but there are plenty of cases where malware will run in memory and do what it can do. For the average user in the enterprise, the user has access to a lot of files. Ransomware can go after these files. There’s not a whole lot we can do about this issue from a technical perspective except train for better security awareness, and even this is of limited effect (unfortunately).

The second case, where malware takes advantage of a security vulnerability, is something we can do something about if there are security patches released for the vulnerability. This is why keeping servers up-to-date on patching is so important.

Implementing Antivirus

I’m not a big fan of running antivirus on servers. I’ve seen antivirus conflict with taking database snapshots. I’ve also seen it cause network errors even with SSIS packages trying to connect to a SQL Server on the same system. This is due to the shims which antivirus programs shove into the operating system. However, this is a question about risk.

Given that, antivirus programs have some ability to spot known ransomware executables and signatures and prevent them from running. As a result, they can provide protection immediately should something get on a SQL Server. Antivirus isn’t fool-proof. After all, plenty of malware writers test their code against the most well-known antivirus engines. However, once a piece of malware has made a big enough dent, signatures become readily available as the AV companies have enough to build such. As a result, anti-virus will protect against most known threats.

Separating accounts for day-to-day activities and privileged access

Most malware will execute as the user, with the rights and privileges of said user. This is especially true of ransomware. While some malware will attempt to take advantage of other vulnerabilities to escalate privileges, this tends to work only on the local system, not remotely, unless it’s a particularly complex piece of malware. To this point, most ransomware is not. That means if the account you use to browse the web and check email doesn’t have privileges on your SQL Servers, should you accidentally encounter ransomware, your SQL Servers can’t be attacked by said ransomware. That ransomware doesn’t have the rights to do so.

Blocking direct access from workstations except through SQL Server ports

Ransomware needs standard access to files in order to encrypt them. That means for a network location, it needs a share to access. If accessing shares are blocked, then ransomware can’t affect the files on that system. In reality, users typically only access SQL Server through the SQL Server listening ports. They don’t need access to shares. In most cases, DBAs don’t need access to the shares, either. Therefore, if we reduce the surface area and block file/share access from workstations, then we block the means by which ransomware spreads across the network. This protects our SQL Servers from an infection on a workstation, which is the most likely source.

By the way, if you’re using remote access solutions such as Citrix, you’d want to apply the same restrictions against those systems, too.

Whitelisting only legitimate Internet outbound traffic from SQL Server

Many ransomware solutions require communications back to a server on the Internet. This is how the key pair can be maintained so that when someone pays, the people behind a particular ransomware can unlock the files. Do note, that’s not always the case. Some ransomware has appeared where the ransomware purports to have a decrypt option, but doesn’t. However, if the folks behind a ransomware package want to make money off of it, it behooves them to honor the transaction.

By blocking outbound connections from SQL Server, should a ransomware outbreak start on the server itself, you break the communications method to store the keys. Therefore, much of the ransomware we’ve seen then doesn’t encrypt. Again, it goes back to that idea of leveraging ransomware to make money. The owners of the ransomware want to ensure they can undo what has been done should someone pay up. Therefore, if the keys can’t be exchanged, most have built their ransomware to do nothing.

Disabling unnecessary services / protocols

This goes along with blocking direct access and whitelisting. Basically, we’re talking about a security best practice of reducing the surface area. There are a lot of potential components we can install that SQL Server and the OS don’t actually need. Some ransomware has targeted services and protocols that aren’t strictly necessary. For instance, some ransomware targeted a vulnerability in the SMB 1.0 protocol. The more we can remove these unnecessary services and protocols, the harder it is to compromise a particular SQL Server.

Privileged access workstations

Microsoft has published some guidance about what it calls “privileged access workstations.” This isn’t a new concept. The idea is that you have a separate of systems that you use to manage critical infrastructure and applications. When administrators need to work on, say, a SQL Server, they have to use this separate set of workstations. In this way, their organization can restrict access to infrastructure networks from the normal workstations. Also, because all of the special tools installed on the specific workstations dedicated for administration, AV and IDS/IPS tools installed on the regular workstations can be tightened down even more, especially those solutions which rely on heuristic detection of bad activity.

Also, the “privileged access workstations” are restricted in their access to the Internet to their own whitelist. Just like with this practice on SQL Servers, we prevent malware from coming down onto these systems unless the sites themselves have been compromised. Email is similarly blocked from those workstations. Therefore, the majority of vectors to introduce ransomware onto a system are blocked on privileged access workstations.

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.

About the author

K. Brian Kelley is a SQL Server author and columnist focusing primarily on SQL Server security.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips