Truth be told, most of the SQL Server installations in your enterprise probably fall into one of two categories. Category one is developer machines that have installed SQL Server (i.e., one of the various install types -- Desktop Edition, Standard Edition, Enterprise Edition or the obvious Developer Edition). Category two is the sundry installations of Microsoft SQL Server Desktop Engine (MSDE) by various applications, including backup, network management or other utility packages that use MSDE as their information store. The common thread in the variations in both of these categories is that most of them probably don't need outside connectivity at all, other than by applications that exist on the host.
Now, for a quick quiz: How many of those installations that don't need to accept connections from other machines on the network are still listening for those connections? You got it -- most all of them. In a recent penetration test engagement, I found that almost 90% of the SQL Server installations in the company were only used by software installed on the same machine and never from other locations on the network. Additionally, of that 90%, all but two machines had both the TCP/IP and Named Pipes network libraries (netlibs) enabled and listening.
What we had there was an excellent example of excessive surface area. That is, the machines were open to casual discovery, brute-force attack and possible remote buffer overflow attacks when it was clear that no operational requirement called for this level of exposure. Recently, with MSDE Release A, Microsoft has started to install MSDE by default without any of the netlibs enabled in order to help you minimize the exposed surface area. However, many older installations of MSDE are still out there and listening.
The solution to the problem of excessive netlib support is simple. Any SQL Server or MSDE instance that does not require outside connectivity should disable all netlibs except for the shared memory netlib, which is enabled by default. The shared memory netlib only works with SQL Server instances that exist on the same box as the application using them and does not allow connections from outside the host.
If you are using SQL Server, the fix is very simple. Just load the Server Network Utility and disable all of the netlibs (under "Enabled Protocols") for each SQL Server instance you wish to protect. Then, stop and restart the SQL Server instances for this change to take effect.
If you're using MSDE, you may have to work a little harder. Of course, if there is a SQL Server installation on the same machine and the Server Network Utility is still installed, you should see the MSDE instance in the drop-down list. Then, you can remove the netlibs exactly the same way as previously described for SQL Server instances.
If you don't have access to the Server Network Utility on the host, then you'll need to edit the registry key that controls the netlib support directly. That key is located at
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSSQLServerMSSQLServerSuperSocketNetLibProtocolList
Simply edit the REG_MULTI_SZ value located there and delete any value data (which is probably "tcp np" by default for TCP/IP and Named Pipes). Once again, you'll need to stop and restart the MSDE instance for the change to take place.
With all of the netlibs disabled, only the shared memory netlib will be capable of communicating with the SQL Server. And this is important to understand about this netlib and your applications: In order to connect to the local SQL Server/MSDE instance, you can no longer use the name of the local machine (or IP address) as the server name in your connection strings. You'll need to replace the server name or IP address with a period "." or the word "(local)." Some applications will behave differently with each, so be sure to test thoroughly. Using one of those strings as the server name tells the local SQL Server client network subsystem to use the shared memory netlib instead of the network-based libraries.
Now that you know how to remove the netlibs and still connect to the SQL Server instances, you should educate your developers on how this is done since they will probably be the most prolific installers of local SQL Server/MSDE instances. Having their instances not listening should keep them safe from attack when they are at remote locations, hotspots or other public places where their machines are likely to come under attack. Minimizing surface area is a key piece of the security puzzle, and making this the default for all new SQL Server/MSDE installations will help immensely to harden your infrastructure.
Chip Andrews, CISSP, is the director of research and development for Special Ops Security Inc. and the founder of the SQLSecurity.com Web site, which focuses on Microsoft SQL Server security topics and issues.
