SQL Server applications rely on data, and protecting that data has never been more important than it is today. SQL Server is a popular target for hackers, so your data is at risk of being intentionally compromised. In addition, your data is at risk of being accidentally compromised. You can minimize these risks by hardening SQL Server, which involves reducing its surface area and controlling access to it.
Reducing the Surface Area
The pathways that can be exploited to gain access to or elevate privileges in SQL Server are referred to as the surface area. To reduce the surface area of SQL Server, apply the following best practices.
Install only the required SQL Server components. Installing SQL Server is often looked at as little more than a mundane task, but that’s when you need to begin your hardening efforts. When installing SQL Server, you shouldn’t include SQL Server Analysis Services (SSAS), SQL Server Integration Services (SSIS), or the Full-Text Engine and its Filter Daemon Launcher. It’s easy to add these components later if they’re required.
Don’t install SQL Server Reporting Services (SSRS) on the same server as the database engine. If you install SSRS on the same server as the database engine, Web services will open a hole in your security layer. Historically, IIS and Web services have had a lot of vulnerabilities, which allowed hackers to take control of the server, thus putting anything hosted on the server at risk. You can avoid this risk by not installing SSRS on the database server.
Disable the SQL Server services that won’t be immediately used. You should disable (or leave disabled) the services that aren’t being used. For example, you should:
- Disable the SQL Server VSS Writer service, which is the SQL Writer Service that’s used by the Volume Shadow Copy Service (VSS). It should be enabled only when it’s being actively used.
- Leave the Active Directory Helper service disabled. SQL Server will enable and disable it as needed.
- Leave the SQL Server Browser service disabled. This service, which typically isn’t required, responds to requests for SQL Server resources and redirects the caller to the correct port. Keeping the Browser service disabled will remove the redirector as an attack vector, helping to obscure the correct entry ways into your SQL Server components.
Don’t use the default TCP/IP ports. After installation, you should configure SQL Server to use nondefault numbers for the TCP/IP ports. The default ports are known entry points into SQL Server, and they have been exploited in the past. This is less of a concern if your server isn’t accessible through the Internet, but viruses, Trojan horses, and hackers have other ways to exploit these holes. This approach doesn’t remove an attack pathway; it merely conceals it. Thus, it’s known as security by obscurity.
Disable the network protocols that aren’t required. You should disable (or leave disabled) the network protocols that aren’t needed. In most cases, both Named Pipes and TCP/IP aren’t needed for connecting to SQL Server, so you should determine the best network protocol for your server and disable the other one. For example, Figure 1 shows Named Pipes disabled and TCP/IP enabled but configured to listen on a nondefault port.
Figure 1: Disabling the network protocols that aren’t required
In Figure 1, note the status of the Shared Memory and Virtual Interface Adapter (VIA) protocols. You can usually leave Shared Memory enabled because this protocol is used by only local connections on the server. However, you should leave the VIA protocol disabled unless you’re using VIA hardware.
Make sure that the antivirus and firewall software versions are current and configured correctly. To be properly protected, the server should be running a current version of the antivirus and firewall programs. In addition, they should be configured to close any ports that might have been left open by default. For example, you need to make sure that the firewall isn’t leaving the default port for SQL Server open.
Manage the surface area configurations. After you initially reduce the surface area, you need to manage its configurations. In SQL Server 2005, Microsoft introduced the Surface Area Configuration Manager (and its command-line counterpart sac.exe) for this purpose. However, this tool performs only the most common management tasks (e.g., enabling remote connections and supported protocols). To perform the less common tasks (e.g., designating service accounts and authentication mode), you need to use the SQL Server Configuration Manager, the system stored procedure sp_configure, or a Windows tool (e.g., Windows Management Instrumentation—WMI).